gsoc March 2015

gsoc@lists.centos.org

25 participants
36 discussions

kpatch irc log 2015-03-18
by Corey Henderson 24 Mar '15

24 Mar '15

Mentor's note; hopefully fewer questions means we're getting closer to proposal writing ;) cormander howdy kragniz cormander: hi there! kragniz how goes with you? cormander good kragniz cormander: cool! kragniz I've been thinking a little about the tooling to create the patch packages cormander great kragniz so assuming we're doing the one rpm per patch route, we need to create an rpm for each supported kernel, right? cormander that will get very messy cormander I would put all versions that applies to in it [ERROR] The command “path/to/kpatch/repo/<kernel” is not known to the server. cormander like so; /path/to/kpatch/repo/<kernel version>/patch-name/module.ko cormander or maybe the reverse; /path/patch-name/<kernel-version>/module.ko --- up to you kragniz olay, so contain builds of the patch against all supported kernels cormander right cormander in the %post script of the rpm, the userspace script you write will determine if an update to the package actually changed the checksum of the module for the current running version cormander and only remove / reinsert it if so cormander when you generate the rpm, what your patching is in newer kernels, so you won't have to "add" more versions later cormander unless you have a future patch touch the same thing that a previous patch does - cormander and you'll have a list of newer modules that are smaller, and and bunch of updated files for older kernel versions kragniz that sounds good kragniz is there a drawback to reloading current patches anyway? cormander you run the risk of hitting a function that's on the kernel stack kragniz other than the risk of breaking something cormander and failing to re-insert it cormander so, best to only remove/re-insert stuff when you have to kragniz okay, that sounds reasonable kragniz so the input for this build system would be a source patch, and it would build kpatch modules for all kernels it applies cleanly against, or would we provide some version limitation? kragniz ie, something.patch is for kernels 3.14 - 3.16 only cormander version limitation. more specifically, release limitation cormander we're only doing EL7 kernels kragniz okay, cool kragniz I need to run for about half an hour, sorry! cormander no problem, just say my name when you're back kragniz will do cormander also - just because a patch cleanly applies doesn't mean it's correct. It can even be dangerous. Patch selection is a painfully manual process. Hard to automate cormander also, patches often don't cleanly go into kernels that need it cormander you can assume that patch selection is out of scope. The real meal of the deal here is the build and release automation |<-- imcleod_ has left freenode (Ping timeout: 244 seconds) cormander kragniz: going to sign off shortly, unless you're still around

2 1

GSoC 2015 Draft of Proposal on On premise vagrant hosting system
by Hanok 24 Mar '15

24 Mar '15

Greeting, I wrote a proposal on "On premise Varant Hosting System".I hoping to get feedback on this,so that i may make some changes. Regards,Hanok KodavatikantiNIT rourkela.

2 1

GSOC 2015- Rootfs build factory implementation
by Saket Sinha 24 Mar '15

24 Mar '15

Hi, I am looking forward to participate in GSOC 2015 With CentOS community in Rootfs build factory implementation for ARM and other platforms. This is to discuss the idea further in order to build my understanding of the project. ARM is now supported by most of Linux distors. To discuss a few we have Debian, Fedora, Gentoo Linux, Arch Linux etc. Debain has something called debootstrap for creating an architecture specific rootfs. Fedora uses fedora remix for supporting different non-x86 boards(or platforms). >From http://fedoraproject.org/wiki/Architectures/ARM/Creating_Remixes what I could find that you can create your own fedora remix by using a tool called appliance-tools over a fedora disk image. So here are we trying to implement a similar implementation for CentOS ? Please let me know if my understanding of the project is right. Regards, Saket Sinha

2 1

Application deadline 27 Mar
by Karsten Wade 23 Mar '15

23 Mar '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Reminder that students need to get their application in to the Melange tool by 27 March 19:00 UTC. https://www.google-melange.com/gsoc/homepage/google/gsoc2015 Once the application is in the system you will have a few weeks to work with mentors to improve your proposal. But it absolutely *must* be turned in by 27 March 19:00 UTC, we cannot add your proposal to the system after that date. That is 3 days and 20 hours from now. How are things going? Any questions on the process? 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 iEUEARECAAYFAlUQjx0ACgkQ2ZIOBq0ODEHregCYjqTeGXcu1MBIDf+yhM5pFJbz gQCg5hOZR8s29vLcvVS6Eh7XVWoBQ8A= =5EfD -----END PGP SIGNATURE-----

1 0

Develop a kpatch delivery mechanism
by vladiksonic＠mail.ru 22 Mar '15

22 Mar '15

Hello! I have written the second proposal (well, first draft), this one is for kpatch delivery mechanism. Link: https://github.com/hotab/CentOS-application/blob/master/Proposal-2.md (also found on google melange for organisation members). Same as the last time - I am open for criticism. Good luck, Vladislav Babkin

1 0

RootFS Build Factory Proposal
by Mandar Joshi 21 Mar '15

21 Mar '15

Hello, I've uploaded my proposal for RootFS Build Factory to github. You can view it here https://github.com/mndar/gsoc2015 I welcome any suggestions. Regards Mandar Joshi

1 0

Rootfs Build Factory Idea. About CentOS for ARM not being available yet
by Mandar Joshi 18 Mar '15

18 Mar '15

Hello, I am working on a proposal for the Rootfs build factory idea http://wiki.centos.org/GSoC/2015/Ideas#rootfs-build-factory Right now, I am working out the details, they are not yet ready for presentation. They are just in the form of notes right now. I discussed this project a bit on centos-gsoc on freenode last week. I think we should use Python and Bash scripts for this project. We have 2 months before the GSoC coding period starts. Since the CentOS ARM images are not ready yet (at least not yet publicly available), should we include the development of CentOS for ARM in the GSoC Project? I would like to contribute to the CentOS ARM project. About me: My primary area of interest is Linux and my programming languages of choice are C and Python. As part of my academics I have studied C, C++, Data Structures, Computer Networks, Software Engineering, Object Oriented Analysis and Design, Microcontrollers, Image Processing, Operating Systems and Database Systems to name a few. I am presently in my third year of college. I have work experience as a software developer and as a system admin. As a software developer I worked on a wide range of projects ranging from development of system services using Microsoft .NET, Networking services to Embedded Linux and Point-Of-Sale terminals along with Smart Cards. I have used numerous open source libraries under Linux including GTK+, Clutter, Qt, Curl, BlueZ, FLTK, Gstreamer and worked with few databases (MySQL, MS SQL, Oracle, SQLite). I've also done development using Python(Twisted) and some web development using Django, PHP, Ruby, Javascript. I have vast experience in installing and configuring various Linux distributions including Gentoo,Fedora,Cent OS, Debian,Knoppix,Ubuntu. I have also contributed couple of patches to the Linux kernel (ALSA Project) to add support for a volume knob and LED for a USB sound card . Details of the projects I've worked on are here http://mndar.phpnet.us/resume or http://mndar.github.io/resume/ In my free time I like to drive, listen to music and enjoy configuring/fixing computers. I am subscribed to the centos-devel list as well. I look forward to your feedback. Regards Mandar Joshi

1 0

kpatch irc log 2015-03-17
by Corey Henderson 18 Mar '15

18 Mar '15

Hotab Hello kragniz cormander: \o cormander howdy kragniz Hotab: hello there! kragniz cormander: can we talk a little about what would be user facing on kpatch delivery? kragniz (I'm rather short on time this evening, sadly) cormander ideally just an rpm with a simple userspace application cormander python is fine if you prefer cormander that ties yum and kpatch together Hotab BTW, I thought about QA. How do we face bugs where patches iterfere with each other, even though they patch different functions? kragniz okay, and this would do the listing and other stuff? Hotab interfere* cormander can you give a specific example of patches affecting different functions, yet interfering? cormander basically, this userspace script would do anything we need in usersapce that kpatch tools or yum doesn't do cormander I'm not sure what that is yet. It's implementation details Hotab I do not have an example at hand, but it can be there if one function uses another, and gets unexpected result, for example. Or are these situations impossible/extremely rare? cormander extremely rare because we never change the ABI with these patches cormander function return type and argument lists are off-limits cormander QA is important, and yes we need to somehow test each function that's patched, though I would say testing patch integration is out of scope, so long as different modules don't touch the same functions cormander all we need to test is that each patch can go in with the rest, and all insert into the kernel w/o error Hotab Well, that makes it more straightforward. Like - apply everything and test. Or one by one. cormander yes cormander probably should do both, just because it isn't that much hader; insert, test, insert, test, then after they are all in, run all the tests again kragniz cormander: good point! I'm currently thinking about yum metapackages, where the user would install a single package which manages the patches currently installed kragniz cormander: grr irc over dodgy 3g connection at the moment cormander I've never dealt with yum metepackages. If you think it'll do the job, great cormander the next step, after I answer all of both of your questions, is to write up the project proposals Hotab What should a proposal include? I have looked through boost template (https://svn.boost.org/trac/boost/wiki/SoCSubmissionTemplate). Is it good enough? (well, obviously we change background information a bit, and centos does not have programming competency tests) cormander there was an email from Karsten Wade about 5 hours ago on the centos-gsoc mailling list giving some examples cormander http://lists.centos.org/pipermail/centos-gsoc/2015-March/000044.html Hotab Hmm... took a quick look at proposals for projects sent to Fedora. Seems that this template works. cormander Hotab: kragniz: 20 minute warningwill head to bed after that Hotab ok Hotab Should we autoinstall patches (well, compatible ones) present on kernel updates? And how should it work if the kernel is updated, but the patches repo is not (yet)? cormander no, and doesn't matter cormander updates to the kernel require a reboot, so nothing kpatch side needs to change cormander I can see this situation where they update to the latest kernel, but don't reboot for some time, and there are kpatch modules available at that time, cormander when they finally do reboot, cormander and those kpatches would get applied at boot time, assuming they keep the kpatch packages up to date cormander Hotab: did that answer your question? Hotab So it will require manual command to install them after the kernel, or some autoupdate? cormander if they specifically update just the kernel with yum, for example cormander then yes, they would also need to manually update kpatch too cormander but if they just do a "yum update" cormander yum should pull down the latest kernel and any updated kpatches cormander but that's all done for you by yum anyway, so no need to worry about it Hotab Well, that answers it cormander yesterday in the chat (I emailed the log of it to the centos-gsoc list) I mentioned each kpatch module being its own rpm cormander another approach would be to just roll all the kpatches into one rpm, and still apply them all individually cormander both have their pros and cons, and it's just about deciding how you want all the other parts to work cormander under this one-rpm method, you'd have a package named something like; kernel-kpatch-modules. it would contain each patch for each applicable kernel version. Upon install / update, the userspace script I mentioned earlier this evening would determine what is already inserted, what needs to be removed / reinserted, and what is new and needs to be inserted cormander easier time with yum, but need custom %pre and %post scripts cormander if each module is its own rpm, you have more to manage with yum, but the updates / installs handle themselves cormander other ideas are surely welcomeall goes into your proposal Hotab Both seem sound. Another con against all-in-one approach - we will redownload all the patches, even though we updated only some of them. And the package might grow in side with time, and rather dramatically. Hotab size* cormander true, but depending on how you slice it, cormander you'll have that problem with individual rpms anyway cormander because in each update, you have to provide new patches for the older kernel versions cormander it just won't all be lumped together into one rpm Hotab Then again, I think that the user is not likely to have all the rmps installed at once (or am I mistaken?) cormander they'd have to, unless we write some yum plugin that had some logic to only download stuff for their running kernel cormander but like I said earlier, if they update their kernel then wait a few months to reboot, without doing another update cormander they'll boot an old kernel with no patches for it cormander IMHO it's safest to just give them everything and let the userspace scripts decide what is needed cormander but, I could be wrong cormander okay so I have to get up for work in less than 7 hours ... but I'm starting my day from home. So I'll be online in IRC for an hour or two at that time Hotab I probably will be in university at that time (for me it will be 2 PM). So I am not likely to be here. cormander okay. well email the list if you have any questions. want to stray away from individual emails cormander g'night / g'day!

1 0

What proposals might look like
by Karsten Wade 18 Mar '15

18 Mar '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 One of the mentors asked me today what an accepted proposal might look like. There are a few resources out there, this one is considered to be canonical by many and well-referenced: http://en.flossmanuals.net/GSoCStudentGuide/ch008_writing-a-proposal/ I don't think any past proposals are viewable, but if someone finds a link to a set of accepted proposals, that would be great. Here is a set of proposals that came in for the Fedora Summer Coding 2010 that I ran independently of GSoC (the year Fedora Project didn't get in to GSoC.) https://fedoraproject.org/wiki/Category:Summer_Coding_2010_proposals ... and here is the list of accepted projects: https://fedoraproject.org/wiki/Summer_Coding_2010_projects Many of the mentors who worked with those students and/or helped write the proposals were GSoC mentors in previous years. 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 v1 iEYEARECAAYFAlUItSIACgkQ2ZIOBq0ODEFNcQCgqt+oCpO9hnczhrdK6IBuK+iD jiwAnA9RogKfW4Xeb9LG2523W68VrWOu =Ovio -----END PGP SIGNATURE-----

2 1

GSoC 2015 self hosting vagrant boxes
by Hanok 18 Mar '15

18 Mar '15

Greetings, My name is Hanok.I am currently in my last semester studying CSE in NIT Rourkela.I am interested to work on the self hosted vagrant images across a group.As of my past experience,i contributed to the OVPL(One VM Per Lab) which is basically creating the vagrant boxes to deploy a lab application in the server automatically through a web interface.I have good python,C,C++ and web designing skills.My contributions and projects can be found at https://github.com/Hanokk. I want to extend my knowledge in the same through the gsoc project.I haven't participated in any of the previous GSoC programs.So,please do reply how to proceed with the furthur. Thank You Regards,Hanok Kodavatikanti,NIT Rourkela.(mob):+919692257021

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

gsoc March 2015