[CentOS-gsoc] kpatch irc log 2015-03-17

[Corey Henderson]

	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!