gsoc

gsoc@lists.centos.org

69 discussions

Re: [CentOS-gsoc] [CentOS-devel] Getting started on contributing to CentOS
by Sankarshan Mukhopadhyay 06 Apr '15

06 Apr '15

On Mon, Apr 6, 2015 at 6:32 PM, Gow Tham <s_gowtham(a)live.com> wrote: > I have been using CentOS for quite a while now and would like to switch from > the user to a contributor. kbsingh mentioned on the ilug mailing list that > this was a good time to get acquainted with the community because of the > influx of new users due to the Google Summer of Code event. Looking at the > Summer of Code ideas page, (http://wiki.centos.org/GSoC/2015/Ideas ), the > one about writing a Lightweight Cloud instance contextualisation tool seemed > like a good place to start. How can I start with it ? A quick question - did you write up a draft of your proposal and push it to the GSoC Melange system for The CentOS Project? As per <https://www.google-melange.com/gsoc/events/google/gsoc2015> 27 March: 19:00 UTC - Student application deadline was the milestone by which applications were required to be in the system. -- sankarshan mukhopadhyay <https://about.me/sankarshan.mukhopadhyay>

2 1

Process for finalizing proposals
by Karsten Wade 02 Apr '15

02 Apr '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I'd like to propose a process, let's work through any ideas and fixes to it. At this point mentors need to be communicating with students about their proposals via the Melange tool. The goal is to help students get their proposals to be as good as possible. We are not accepting/denying any proposals at this point. Mentors need to rank and finalize the list for slot requests by 13 April, so let's make the deadline for that 10 April. This will include accepting top proposals, ranking them in order of quality, as that will help determine how many student slots we get. Mentors should be watching for how students communicate and respond around the proposals. This is an indication of how well they will fit in working in an open source project. Of course, there is always a lot to learn, and the mentors should be showing the students how to act in an open source project. The mentors need to decide ourselves how we want to do the final ranking of proposals and request for student slots. My thinking here is: 1. Mentors discuss on their private list about the ranking. 2. If we can't come to a clear consensus, then the admins (Jeff & I) can have 1:1 discussions with the mentors. 3. Then admins propose a final ranking to the mentors. 4. Discuss and come to consensus. Lars has suggested that we start with step 2 to avoid conflict of interest in the ranking. Any other ideas or thoughts there? Thanks - Karsten - -- Karsten 'quaid' Wade .^\ CentOS Doer of Stuff http://TheOpenSourceWay.org \ http://community.redhat.com @quaid (identi.ca/twitter/IRC) \v' gpg: AD0E0C41 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlUdbKUACgkQ2ZIOBq0ODEHGsQCg5TCN2VqSPFVu6FHeLO6epzy2 Tr8AoMu7iXZ+NW4+KEw4xD9avvxWIA1Z =a7f/ -----END PGP SIGNATURE-----

3 3

Update on mentors
by Karsten Wade 02 Apr '15

02 Apr '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi students: Just a quick update that if you haven't heard from your project's mentor yet, don't worry! We've had two things going on recently that have made some of the mentors very distracted: * A large update to CentOS 7 for the last month, * A small bit of shuffling around of who is mentoring which project. We'll have this sorted out within the next day or so. Some people are going on long holiday this weekend, so you may not see comments until early next week. Be prepared to respond as quickly as you can to those comments. Kind regards, - - Karsten - -- Karsten 'quaid' Wade .^\ CentOS Doer of Stuff http://TheOpenSourceWay.org \ http://community.redhat.com @quaid (identi.ca/twitter/IRC) \v' gpg: AD0E0C41 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlUdtdMACgkQ2ZIOBq0ODEGxsQCgqY7hurL/2D97hZp/nHeKo+Ol dmgAn2KPoJEoz+0+1AeQUM7DpizZgw0W =EGXn -----END PGP SIGNATURE-----

1 0

RootFS Build Factory IRC Log 2015-04-02
by Mandar Joshi 02 Apr '15

02 Apr '15

Hello everyone, I got a chance to discuss the build factory idea with imcleod and Evolution on IRC Freenode #centos-gsoc. They gave me some good inputs. While I work on improving my proposal based on those inputs, here is the entire log of the chat. ----------------------------------------------------------------------------------------------------------------------------- Conversation with #centos-gsoc at Thu 02 Apr 2015 12:49:44 AM IST on mndar(a)irc.freenode.net (irc) (12:49:44 AM) The topic for #centos-gsoc is: We are IN! || http://wiki.centos.org/GSoC/HowToApply || http://wiki.centos.org/GSoC/2015/ (12:49:44 AM) Topic for #centos-gsoc set by kbsingh!~kbsingh(a)n12.lon1.karan.org at 06:43:51 PM on 03/03/2015 (01:05:21 AM) mndar: hughesjr: Perhaps you might have already seen my email to you that I sent on 22 March. I learnt from Karsten Wade on the centos-devel mailing list that you are busy with the CentOS updates. I was wondering if you got the chance to review my proposal for RootFS Build Factory. sankarshan asked me if I've been in conversation with the mentor of this project. I am eager to discuss the project with you. (01:18:50 AM) lalatenduM left the room (quit: Quit: Leaving). (01:33:55 AM) mndar: right now I am trying to figure out if using ImageFactory is the best option for building ARM RootFS or whether we need a separate set of scripts. (01:34:11 AM) mndar: Evolution, imcleod: any thoughts? (01:37:20 AM) Evolution: I'm fine either way. (01:37:36 AM) Evolution: so long as there's 'one tool suite' to do so (01:39:20 AM) mndar: by 'one tool suite' you mean, a single tool should be able to generate x86 cloud images and ARM RootFS? (01:56:45 AM) kbsingh: quaid: around ? (01:58:09 AM) rbowen [~DrBacchus@apache/pony-mafia/rbowen] entered the room. (02:01:57 AM) kbsingh: quaid: meet rbowen ; rbowen meet quaid :) (02:05:19 AM) rbowen: quaid: I feel like maybe we've met somewhere before. (02:15:22 AM) The account has disconnected and you are no longer in this chat. You will automatically rejoin the chat when the account reconnects. Conversation with #centos-gsoc at Thu 02 Apr 2015 02:16:11 AM IST on mndar(a)irc.freenode.net (irc) (02:16:11 AM) The topic for #centos-gsoc is: We are IN! || http://wiki.centos.org/GSoC/HowToApply || http://wiki.centos.org/GSoC/2015/ (02:16:11 AM) Topic for #centos-gsoc set by kbsingh!~kbsingh(a)n12.lon1.karan.org at 06:43:51 PM on 03/03/2015 (02:16:42 AM) mndar left the room (quit: Ping timeout: 264 seconds). (02:33:39 AM) imcleod: mndar: I will try to get some initial review comments in in the next day or two. Regarding the specific question, I don't think it necessarily has to be based on ImageFactory. (02:49:08 AM) mndar1: imcleod: thanks. In the next 2-3 days, I'll play around a bit with ImageFactory. Check out what features it has. How it does things. Should I refer to https://github.com/imcleod/oz/tree/feature/arm_support or http://imgfac.org/ ? (02:50:17 AM) imcleod: mndar1: For this use case, the oz tree would probably be a better starting point. (02:51:19 AM) imcleod: The primary benefit of the Oz approach is that we get to use Anaconda, which means we get the install runtime (with yum/dnf, rpm versions, filesystem support) built for us. (02:51:58 AM) imcleod: Earlier image solutions used in Fedora did not use virt, and depended on things like running a yum transaction with the target being a subdir or a loopback device. (02:52:39 AM) imcleod: And this works, somewhat, if you are using similar versions of the host and target (e.g. F20 -> F20) but starts to break down when the diff between the host and target grows. (02:53:52 AM) mndar1: imcleod: when I initially read the problem statement on the ideas page, my first thought was to take the subdir/loopback device approach. (02:55:38 AM) imcleod: mndar1: Right. I believe the Fedora project is in fact still using that approach to make the ARM images for F21 and now F22. (02:55:55 AM) mndar1: do we need anaconda for ARM boards? Packages required to run a complete CentOS system can be put into a rootfs image using the 'Build Factory' (02:56:40 AM) imcleod: mndar1: But they do so using nested chroots (IIRC). So, for example, the version of yum used to generate the F21 rootfs for ARM was the F21 version of yum (and rpm, etc.) not the version running on the host doing the build. (02:57:37 AM) imcleod: mndar1: Anaconda actually does work now for ARM (and most of the other non x86_64 architectures). (02:58:11 AM) imcleod: mndar1: And the appeal of using the Anaconda approach is that it can essentially be the same thing that is already done to generate disk images for x86. (02:58:18 AM) imcleod: mndar1: It's an open question, in my mind. (02:59:28 AM) mndar1: imcleod: I didn't know that about Anaconda. Thanks. You've given me some good points to ponder over (02:59:59 AM) imcleod: mndar1: Cheers. (03:00:48 AM) mndar1: imcleod: do we also want something like this http://fedoraproject.org/wiki/Fedora_ARM_Installer? (03:08:58 AM) mndar1: imcleod: from what I've read so far Fedora has released one image which needs to be installed using slightly different techniques on each board. That's one approach. The second would be, as you mentioned, Anaconda. With Anaconda users will have to first copy over a bootable images to a SD card, boot with it and install CentOS to their NAND Flash or SATA HDD and then configure it (03:09:24 AM) mndar1: imcleod: another option is to create a preconfigured images using the 'Build Factory' (03:14:42 AM) imcleod: mndar1: I think the Fedora approach for F21 is pretty cool, in that it manages to provide a single base image where the only board-specific tweaks are related to the boot loader. (03:17:11 AM) mndar1: imcleod: can you do custom partitioning with those Fedora images? (03:18:01 AM) imcleod: mndar1: You cannot. You are more or less stuck with the partition layout they have given you, though there are built in tools to extend the main parition (containing /) to fill whatever sdcard you have used to do the install. (03:21:43 AM) mndar1: imcleod: my initial thoughts are that we should let the board vendor decide everything about partitions. If any user wants to custom partitions he can easily create his own image using the build factory. As far as the partitioning issue goes, your suggestion of using Anaconda seems to be the best option (03:24:47 AM) mndar1: imcleod: About Oz. So, it creates a virtual machine using libvirt and then installs native packages? It would save me some time if you could briefly tell me how Oz goes about generating images (03:33:23 AM) mndar1: imcleod: We want the build factory to be able to generate different images containing different packages. For that, the yum chroot option seems suitable (03:37:03 AM) mndar1: So the ideal/Fedora solution is https://fedoraproject.org/wiki/Architectures/ARM/F21/Installation#Download_… + ability to generate custom images based on packages listed in a template file (03:45:55 AM) mndar1: imcleod: thanks for all your inputs. I have to go now. its almost 4am over here -------------------------------------------------------------------------------------------------------------------------- Regards Mandar Joshi

1 0

xapi on CentOS 6
by Gautam Malu 31 Mar '15

31 Mar '15

Hi, I am a masters student at IIIT Hyderabad. I have applied for gsoc 2015, for xen in a box proposal. As a part of my proposal,I want to deliver xapi repo which can be used to build a custom installer ISO to install CentOS 6 + xen + xapi. Here is my full proposal http://www.google-melange.com/gsoc/proposal/public/google/gsoc2015/gautam_m… About building xapi packages for CentOS; I was able to build all xenserver packages with xenserver build root. (https://github.com/xenserver/buildroot) on CentOS 6.6 . This buildroot uses Xen4CentOS repo for xen packages, but it uses custom repo for Ocaml(4.01). The Base repo for CentOS 6.6 have ocaml 3.11. This buildroot required Ocaml 4.x. The gsoc would start in May end, if Ocaml 4.x packages are ready by then, Those could be used to build xapi. Is there any plan to have xapi as part of virt SIG. Is there any time-line for having ocaml 4.x packages in CentOS offical repo. Best regards, Gautam Malu

2 1

kpatch irc log 2015-03-30
by Corey Henderson 31 Mar '15

31 Mar '15

Some more musings this evening. kragniz cormander: evening cormander howdy kragniz how was your weekend? cormander great cormander opening weekend at the local amusement park kragniz nice kragniz I was at a hackathon making horrible sounding music cormander can't say i'v ever done that kragniz it was a fun 24 hours, but I don't think I'd want to listen to the output for a long period of time! cormander any more Q's on what to do for kpatch? any actual implementation done? kragniz no implementation done yet - where would you suggest I start? kragniz I was a little hesitant to start writing code before I'd received some acks from more people in terms of the overall design cormander not sure if others around have a vested technical interest in the details cormander I'd say, start withing making the /proc/version patch into an rpm cormander for fun, append "-kpatch-foo" to the current version kragniz that sounds like a great idea kragniz building that rpm by hand? kragniz also, a related question - is it okay to do development work on fedora? cormander go for it cormander as long as the end result works on EL7 kragniz yup kragniz I don't see any potential problems with it, other than maybe different library versions cormander kragniz: one thing you can mull over in your free time cormander is a naming schema for the patches cormander things get a little dicey when a single module contains multiple patches

1 0

Reminder - initial proposal deadline (27 March 19:00 UTC)
by Karsten Wade 26 Mar '15

26 Mar '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 We just rolled under the 24 hour mark for you to get your initial proposals in. The main thing is to get even a rough draft in to the system. For the next few weeks mentors will continue to work with you on refining your proposal. But it has to be in the system by the deadline. Working on the proposals this way is an important part of how the mentors will see you and your potential. Remember that this is open source development -- we have ways of doing things that may be new to you, such as turning in unfinished proposals and working openly on mailing lists/in Melange to improve your proposals. All of this is part of how open source projects work. Regards, - - Karsten - -- Karsten 'quaid' Wade .^\ CentOS Doer of Stuff http://TheOpenSourceWay.org \ http://community.redhat.com @quaid (identi.ca/twitter/IRC) \v' gpg: AD0E0C41 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlUUWP0ACgkQ2ZIOBq0ODEEqeACfWQVGvccHuYZs57bYKW9F1ZGC eJUAoJmGXg6kQhli1GnqIN3YOojzdopc =7RL2 -----END PGP SIGNATURE-----

1 0

Hello!
by Mark Murnane 26 Mar '15

26 Mar '15

My name is Mark Murnane, I am a Computer Engineering major at the University of Maryland, Baltimore County, in my Junior year. I have been working for three years now as a system administrator for our Com Sci department, where I provide Redhat desktops and server infrastructure. I've been working for a while now moving our legacy server environment from Solaris zones to Linux containers(under Docker), and am extremely interested in the project to create a yum plugin to manage containers. I am now very familiar with the current container tools and workflows, and know that distribution is something of a weak spot with current solutions. I also have a few questions about the project: The project description on the ideas page mentions that a 'yum upgrade container' command would be unnecessary. We rely heavily on container versioning, and generally prefer the encapsulation provided by replacing containers wholesale. Would a solution that supports updates be undesirable? The description only mentions Docker, but other systems for managing containers are available. Would a solution that supports multiple systems be allowed? I know that since version 218 systemd has supported using docker images directly. I don't believe it would be difficult to allow multiple systems to be configured. Thanks! -Mark

1 0

Feedback for GSOC2015 proposal
by Saket Sinha 25 Mar '15

25 Mar '15

Hi, I would like to participate to Google Summer of Code 2015 by contributing to Rootfs build factory implementation under the guidance of Jim Perrin. This is to seek feedback from the development community for the same. My proposal can be found at the below link - http://www.google-melange.com/gsoc/proposal/public/google/gsoc2015/disdi/58… Regards, Saket Sinha

1 0

kpatch delivery proposal
by Louis Taylor 25 Mar '15

25 Mar '15

Hi all, I'm a student at Aberystwyth University in Wales, United Kingdom. I've been working on a proposal for kpatch delivery, which you can read here: https://kragniz.eu/kpatch.txt I'd love it if you could have a read through and point out any potential problems with it. Cheers, Louis

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

gsoc