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!