hi
since we now have a GA kernel and a zero day update kernel, does someone want to have a go at creating the scripts / automation needed to deliver kpatch content ?
- KB
On 06/20/2014 12:15 PM, Karanbir Singh wrote:
hi
since we now have a GA kernel and a zero day update kernel, does someone want to have a go at creating the scripts / automation needed to deliver kpatch content ?
- KB
Sat through a basic presentation on this, and on the surface it seems reasonably easy to implement at the local level. Distro wide, it will become an exercise in deployment of patches, as not all things can be patched. There's also a reasonably insignificant (or so I'm told) performance penalty that will grow as more things are added to the kpatch list without a reboot.
On 06/20/2014 06:30 PM, Jim Perrin wrote:
On 06/20/2014 12:15 PM, Karanbir Singh wrote:
hi
since we now have a GA kernel and a zero day update kernel, does someone want to have a go at creating the scripts / automation needed to deliver kpatch content ?
- KB
Sat through a basic presentation on this, and on the surface it seems reasonably easy to implement at the local level. Distro wide, it will become an exercise in deployment of patches, as not all things can be patched. There's also a reasonably insignificant (or so I'm told) performance penalty that will grow as more things are added to the kpatch list without a reboot.
something really cool is that the kpatch process itself works quite nicely with git, we could potentially deliver a tool that allows people to self-implement, rather than needing to ship kpatch payload ( otherwise, were potentially looking at a yum plugin of sorts and a rpm based wrapper )
does that sound like something we could target ?
- KB
On 06/20/2014 06:13 PM, Karanbir Singh wrote:
On 06/20/2014 06:30 PM, Jim Perrin wrote:
On 06/20/2014 12:15 PM, Karanbir Singh wrote:
hi
since we now have a GA kernel and a zero day update kernel, does someone want to have a go at creating the scripts / automation needed to deliver kpatch content ?
- KB
Sat through a basic presentation on this, and on the surface it seems reasonably easy to implement at the local level. Distro wide, it will become an exercise in deployment of patches, as not all things can be patched. There's also a reasonably insignificant (or so I'm told) performance penalty that will grow as more things are added to the kpatch list without a reboot.
something really cool is that the kpatch process itself works quite nicely with git, we could potentially deliver a tool that allows people to self-implement, rather than needing to ship kpatch payload ( otherwise, were potentially looking at a yum plugin of sorts and a rpm based wrapper )
does that sound like something we could target ?
Possibly, however; we haven't seen upstream deliver a kpatch, and I'm not convinced they intend to provide anything more than the functionality to make one yourself.
So, we would have to extract and prepare the source of the old kernel, and the new. Diff them to generate a patch that could be distributed through git.
That patch may or may not be able to be applied via kpatch. Additionally, how far back would we like to provide diffs? Do we start with the release kernel for each minor version and keep a diff? Do we only patch for the previous kernel version?
I can see this feature being incredibly popular with hosters, but it would require a fair bit of planning on our part to implement properly.
-----Original Message----- From: centos-devel-bounces@centos.org [mailto:centos-devel- bounces@centos.org] On Behalf Of Jim Perrin Sent: 21 June 2014 03:08 To: The CentOS developers mailing list. Subject: Re: [CentOS-devel] kpatch process
On 06/20/2014 06:13 PM, Karanbir Singh wrote:
On 06/20/2014 06:30 PM, Jim Perrin wrote:
On 06/20/2014 12:15 PM, Karanbir Singh wrote:
hi
since we now have a GA kernel and a zero day update kernel, does someone want to have a go at creating the scripts / automation needed to deliver kpatch content ?
- KB
Sat through a basic presentation on this, and on the surface it seems reasonably easy to implement at the local level. Distro wide, it will become an exercise in deployment of patches, as not all things can be patched. There's also a reasonably insignificant (or so I'm told) performance penalty that will grow as more things are added to the kpatch list without a reboot.
something really cool is that the kpatch process itself works quite nicely with git, we could potentially deliver a tool that allows people to self-implement, rather than needing to ship kpatch payload ( otherwise, were potentially looking at a yum plugin of sorts and a rpm based wrapper )
does that sound like something we could target ?
Possibly, however; we haven't seen upstream deliver a kpatch, and I'm not convinced they intend to provide anything more than the functionality to make one yourself.
So, we would have to extract and prepare the source of the old kernel, and the new. Diff them to generate a patch that could be distributed through git.
That patch may or may not be able to be applied via kpatch. Additionally, how far back would we like to provide diffs? Do we start with the release kernel for each minor version and keep a diff? Do we only patch for the previous kernel version?
I can see this feature being incredibly popular with hosters, but it would require a fair bit of planning on our part to implement properly.
Kpatch is a really interesting technology for the CERN cloud use cases on the hypervisors which are long running servers.
However, I think we should focus on getting the builds done first so we have something to patch :-) I would favour a centrally provided set of patches in view of the complexity of the process and the benefits of community testing.
Tim
-- Jim Perrin The CentOS Project | http://www.centos.org twitter: @BitIntegrity | GPG Key: FA09AD77 _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
-
Jim Perrin -
Karanbir Singh -
Tim Bell