I'm hoping to reach a decision on how we handle docker rpms (vanilla +/- rh patches)
There's the default docker that CentOS gets in extras from RHEL which comes with RH patches (of course). But this kinda comes quite a bit after upstream docker releases.
Next up is 'docker' in virt SIG which usually tracks upstream releases. Would people prefer this build be vanilla upstream or with RH patches included.
Then there is 'docker-master' in virt SIG which is a daily rebuild of docker upstream master branch + redhat patches.
We could either:
a) ship 'docker' in virt SIG with RH patches and also provide a 'docker-upstream' which is a vanilla upstream package
b) ship 'docker' in virt SIG without any RH patches and provide a 'docker-redhat' with RH patches
c) ...anything else??
Comments?
On 04/16/2015 03:52 PM, Lokesh Mandvekar wrote:
I'm hoping to reach a decision on how we handle docker rpms (vanilla +/- rh patches)
There's the default docker that CentOS gets in extras from RHEL which comes with RH patches (of course). But this kinda comes quite a bit after upstream docker releases.
Next up is 'docker' in virt SIG which usually tracks upstream releases. Would people prefer this build be vanilla upstream or with RH patches included.
Then there is 'docker-master' in virt SIG which is a daily rebuild of docker upstream master branch + redhat patches.
We could either:
a) ship 'docker' in virt SIG with RH patches and also provide a 'docker-upstream' which is a vanilla upstream package
b) ship 'docker' in virt SIG without any RH patches and provide a 'docker-redhat' with RH patches
c) ...anything else??
Well, I think we should ship an AS-IS downstream from the RHEL platform as one of the options.
As far as the "more progressive / newer" option, I would think one with some RH patches (assuming the RH patches make it more stable than vanilla upstream) would be desired. I this being just the vanilla upstream if we really wanted. But I would think optimized with RH patches would likely be better than pure vanilla.
in both cases though, we should "fix" these to actually work whether they are broken upstream or not.
On 04/17/2015 10:40 AM, Johnny Hughes wrote:
On 04/16/2015 03:52 PM, Lokesh Mandvekar wrote:
I'm hoping to reach a decision on how we handle docker rpms (vanilla +/- rh patches)
There's the default docker that CentOS gets in extras from RHEL which comes with RH patches (of course). But this kinda comes quite a bit after upstream docker releases.
Next up is 'docker' in virt SIG which usually tracks upstream releases. Would people prefer this build be vanilla upstream or with RH patches included.
Then there is 'docker-master' in virt SIG which is a daily rebuild of docker upstream master branch + redhat patches.
We could either:
a) ship 'docker' in virt SIG with RH patches and also provide a 'docker-upstream' which is a vanilla upstream package
b) ship 'docker' in virt SIG without any RH patches and provide a 'docker-redhat' with RH patches
c) ...anything else??
Well, I think we should ship an AS-IS downstream from the RHEL platform as one of the options.
As far as the "more progressive / newer" option, I would think one with some RH patches (assuming the RH patches make it more stable than vanilla upstream) would be desired. I this being just the vanilla upstream if we really wanted. But I would think optimized with RH patches would likely be better than pure vanilla.
in both cases though, we should "fix" these to actually work whether they are broken upstream or not.
Holy moley .. I read that to myself and it sounded fine :)
What I mean is .. one should be the rhel released one (but we can patch it if it is really broken).
The other one can either be vanilla or newer with RH patches in .. which ever is more stable.
The goal being things that can reasonably be expected to work, on el7, though one is newer and moves a bit faster.
I think patching in RH patches to the faster moving one is likely to make it work better on CentOS. Hopefully that makes more sense :)
On Thu, Apr 16, 2015 at 9:52 PM, Lokesh Mandvekar lsm5@fedoraproject.org wrote:
I'm hoping to reach a decision on how we handle docker rpms (vanilla +/- rh patches)
There's the default docker that CentOS gets in extras from RHEL which comes with RH patches (of course). But this kinda comes quite a bit after upstream docker releases.
Next up is 'docker' in virt SIG which usually tracks upstream releases. Would people prefer this build be vanilla upstream or with RH patches included.
Then there is 'docker-master' in virt SIG which is a daily rebuild of docker upstream master branch + redhat patches.
We could either:
a) ship 'docker' in virt SIG with RH patches and also provide a 'docker-upstream' which is a vanilla upstream package
b) ship 'docker' in virt SIG without any RH patches and provide a 'docker-redhat' with RH patches
What do the RH patches actually do?
I think either one could make sense depending on how much value the patches provide / how much they cost to port to the latest release.
-George
On Mon, Apr 20, 2015 at 12:25:46PM +0100, George Dunlap wrote:
On Thu, Apr 16, 2015 at 9:52 PM, Lokesh Mandvekar lsm5@fedoraproject.org wrote:
I'm hoping to reach a decision on how we handle docker rpms (vanilla +/- rh patches)
There's the default docker that CentOS gets in extras from RHEL which comes with RH patches (of course). But this kinda comes quite a bit after upstream docker releases.
Next up is 'docker' in virt SIG which usually tracks upstream releases. Would people prefer this build be vanilla upstream or with RH patches included.
Then there is 'docker-master' in virt SIG which is a daily rebuild of docker upstream master branch + redhat patches.
We could either:
a) ship 'docker' in virt SIG with RH patches and also provide a 'docker-upstream' which is a vanilla upstream package
b) ship 'docker' in virt SIG without any RH patches and provide a 'docker-redhat' with RH patches
I've pretty much decided that 'docker' in virt SIG would only track upstream sources (no RH patches in it). Don't want this to sound like "I don't care what anyone says", but docker upstream and many CentOS users want a build which will only track upstream docker sources. Having 'docker' in virt SIG to be this build sounds like the way to go.
For anyone interested in RH patches, there's 'docker-master' in virt SIG (docker master branch + RH patches) and 'docker' in CentOS-Extras of course. Also, I could add anything else to make anyone else happy.
What do the RH patches actually do?
Some docker behavior does get modified, like adding and blocking registries, checking for confirmation before pushing to public registries. AFAIK, patches were added only with permission from upstream docker and we're working towards upstreaming those patches too.
I think either one could make sense depending on how much value the patches provide / how much they cost to port to the latest release.
These patches are desirable to enterprise users, but I've been hearing a lot directly/indirectly from CentOS users that they only want vanilla docker behavior. Porting/rebasing is taken care of by RH folks on a daily basis.
-George _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
On 04/20/2015 01:06 PM, Lokesh Mandvekar wrote:
I've pretty much decided that 'docker' in virt SIG would only track upstream sources (no RH patches in it). Don't want this to sound like "I don't care what anyone says", but docker upstream and many CentOS users want a build which will only track upstream docker sources. Having 'docker' in virt SIG to be this build sounds like the way to go.
Agree. It would be nice to hear what the Atomic SIG folks think about this though as they're direct consumers.
For anyone interested in RH patches, there's 'docker-master' in virt SIG (docker master branch + RH patches) and 'docker' in CentOS-Extras of course. Also, I could add anything else to make anyone else happy.
What do the RH patches actually do?
Some docker behavior does get modified, like adding and blocking registries, checking for confirmation before pushing to public registries. AFAIK, patches were added only with permission from upstream docker and we're working towards upstreaming those patches too.
I think either one could make sense depending on how much value the patches provide / how much they cost to port to the latest release.
These patches are desirable to enterprise users, but I've been hearing a lot directly/indirectly from CentOS users that they only want vanilla docker behavior. Porting/rebasing is taken care of by RH folks on a daily basis.
Is this mainly just do to the private auth bug reported by quay.io users or is it more widespread than that?
On 04/20/2015 03:43 PM, Jim Perrin wrote:
I've pretty much decided that 'docker' in virt SIG would only track upstream sources (no RH patches in it). Don't want this to sound like "I don't care what anyone says", but docker upstream and many CentOS users want a build which will only track upstream docker sources. Having 'docker' in virt SIG to be this build sounds like the way to go.
Agree. It would be nice to hear what the Atomic SIG folks think about this though as they're direct consumers.
FWIW, I would lean towards Docker+patches. But I assume we'd have that in the RHELAH rebuild even if not in virt SIG packages.
Best,
jzb
On Mon, Apr 20, 2015, at 03:43 PM, Jim Perrin wrote:
Agree. It would be nice to hear what the Atomic SIG folks think about this though as they're direct consumers.
This sounds obvious but it's worth restating - the best end result is for patches to be upstream as much as possible. Some of the patches *do* affect behavior in an important way, and finding a path forward that keeps all parties happy enough is the critical problem to solve.
Something RPM could be better at is notifying you when a package has patches, particularly nontrivial ones. This is something that really should be expressible in the metadata.
# rpm -q docker docker-1.6.0-3.x86_64 (6 patches)
or something. Anyways...in the short term I guess I'm ok with the CentOS Atomic Spin being vanilla but, let's keep the situation fluid here as (I just saw Dan follow up) some of the patches are really useful.
On Mon, Apr 20, 2015 at 7:06 PM, Lokesh Mandvekar lsm5@fedoraproject.org wrote:
I've pretty much decided that 'docker' in virt SIG would only track upstream sources (no RH patches in it). Don't want this to sound like "I don't care what anyone says", but docker upstream and many CentOS users want a build which will only track upstream docker sources. Having 'docker' in virt SIG to be this build sounds like the way to go.
It sounds like you care what "many CentOS users want", which is hardly "I don't care what anyone says". :-)
That sounds like a perfectly reasonable decision.
-George
On 04/21/2015 08:55 AM, George Dunlap wrote:
On Mon, Apr 20, 2015 at 7:06 PM, Lokesh Mandvekar lsm5@fedoraproject.org wrote:
I've pretty much decided that 'docker' in virt SIG would only track upstream sources (no RH patches in it). Don't want this to sound like "I don't care what anyone says", but docker upstream and many CentOS users want a build which will only track upstream docker sources. Having 'docker' in virt SIG to be this build sounds like the way to go.
It sounds like you care what "many CentOS users want", which is hardly "I don't care what anyone says". :-)
That sounds like a perfectly reasonable decision.
-George _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
I have not chimed in on this yet, but the patches include stuff to make docker run better on a systemd based system. Going purely upstream eliminates us from experimenting and testing some of our ideas.
Current patches include fixes for SELinux, patches to allow systemd to run within a container without requiring --privileged mode. Handling of multiple registries, Proper integration into the systemd, MachineCtl, journald.
And most importantly customers running on rhel will have a different experience then on Centos.
On Tue, Apr 21, 2015 at 2:50 PM, Daniel J Walsh dwalsh@redhat.com wrote:
I have not chimed in on this yet, but the patches include stuff to make docker run better on a systemd based system. Going purely upstream eliminates us from experimenting and testing some of our ideas.
By "us" I take it you mean RedHat engineering? I don't see how the CentOS Virt SIG going with upstream-only has any effect on RedHat doing anything.
Current patches include fixes for SELinux, patches to allow systemd to run within a container without requiring --privileged mode. Handling of multiple registries, Proper integration into the systemd, MachineCtl, journald.
And most importantly customers running on rhel will have a different experience then on Centos.
Users who use the version of Docker from CentOS Extras will be using RHEL bits and having the same experience.
Users who opt in for the Virt SIG have specifically chosen *not* to run the RHEL version for some reason; presumably they want to have a different experience. :-)
The SELinux fixes and patches to allow systemd to run without --privileged mode sound useful to me (as someone outside looking in), but I would leave it for Lokesh (and people from the Atomic SIG) to determine which patches, if any, are worth porting over.
For comparison, the Xen dom0 kernel is mostly a vanilla upstream kernel, but with a few driver tweaks, and the blktap2 driver; the Xen tools is mostly a vanilla upstream tools package, but with XenServer's "blktap2.5" patched in.
-George
On 04/21/2015 08:50 AM, Daniel J Walsh wrote:
On 04/21/2015 08:55 AM, George Dunlap wrote:
On Mon, Apr 20, 2015 at 7:06 PM, Lokesh Mandvekar lsm5@fedoraproject.org wrote:
I've pretty much decided that 'docker' in virt SIG would only track upstream sources (no RH patches in it). Don't want this to sound like "I don't care what anyone says", but docker upstream and many CentOS users want a build which will only track upstream docker sources. Having 'docker' in virt SIG to be this build sounds like the way to go.
It sounds like you care what "many CentOS users want", which is hardly "I don't care what anyone says". :-)
That sounds like a perfectly reasonable decision.
-George _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
I have not chimed in on this yet, but the patches include stuff to make docker run better on a systemd based system. Going purely upstream eliminates us from experimenting and testing some of our ideas.
Current patches include fixes for SELinux, patches to allow systemd to run within a container without requiring --privileged mode. Handling of multiple registries, Proper integration into the systemd, MachineCtl, journald.
And most importantly customers running on rhel will have a different experience then on Centos.
Which is why I thought we want RH type behavior (ie patches) on both our fast moving and RHEL Atomic Host downstream branches for C7. We need stuff that works correctly with SELINUX and systemd on CentOS-7. So, IMHO, we want newer docker and RH patches.
On Tue, Apr 21, 2015 at 11:05:46AM -0500, Johnny Hughes wrote:
On 04/21/2015 08:50 AM, Daniel J Walsh wrote:
On 04/21/2015 08:55 AM, George Dunlap wrote:
On Mon, Apr 20, 2015 at 7:06 PM, Lokesh Mandvekar lsm5@fedoraproject.org wrote:
I've pretty much decided that 'docker' in virt SIG would only track upstream sources (no RH patches in it). Don't want this to sound like "I don't care what anyone says", but docker upstream and many CentOS users want a build which will only track upstream docker sources. Having 'docker' in virt SIG to be this build sounds like the way to go.
It sounds like you care what "many CentOS users want", which is hardly "I don't care what anyone says". :-)
That sounds like a perfectly reasonable decision.
-George _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
I have not chimed in on this yet, but the patches include stuff to make docker run better on a systemd based system. Going purely upstream eliminates us from experimenting and testing some of our ideas.
Current patches include fixes for SELinux, patches to allow systemd to run within a container without requiring --privileged mode. Handling of multiple registries, Proper integration into the systemd, MachineCtl, journald.
And most importantly customers running on rhel will have a different experience then on Centos.
Which is why I thought we want RH type behavior (ie patches) on both our fast moving and RHEL Atomic Host downstream branches for C7. We need stuff that works correctly with SELINUX and systemd on CentOS-7. So, IMHO, we want newer docker and RH patches.
Given the conflicting requirements, would it make sense to have appropriate tags such that, a particular 'docker' (something with RH patches) build only makes it to atomic, while another 'docker' build makes it to virt7-release (only upstream docker sources)
I'm guessing now with dist-gits coming up and mapping koji tags to dist-git branches should make this a lot easier.
We already have virt7-docker-master-el7 (daily rebuilds) and virt7-docker-upstream-el7 (tracking upstream sources), I guess having a virt7-docker-atomic-el7 (something which atomic hosts could consume) will solve this problem.
What say?
CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
----- Original Message -----
From: "Lokesh Mandvekar" lsm5@fedoraproject.org To: "The CentOS developers mailing list." centos-devel@centos.org Sent: Wednesday, April 22, 2015 9:07:12 AM Subject: Re: [CentOS-devel] RH patches v/s vanilla docker in CentOS
...
Given the conflicting requirements, would it make sense to have appropriate tags such that, a particular 'docker' (something with RH patches) build only makes it to atomic, while another 'docker' build makes it to virt7-release (only upstream docker sources)
+1
I think it makes sense for everything atomic needs to live in atomic7, and if atomic wants the same version as virt has, great, if not, atomic could have its own.
Jason
----- Original Message -----
From: "Jason Brooks" jbrooks@redhat.com To: "The CentOS developers mailing list." centos-devel@centos.org Sent: Wednesday, April 29, 2015 4:04:52 PM Subject: Re: [CentOS-devel] RH patches v/s vanilla docker in CentOS
----- Original Message -----
From: "Lokesh Mandvekar" lsm5@fedoraproject.org To: "The CentOS developers mailing list." centos-devel@centos.org Sent: Wednesday, April 22, 2015 9:07:12 AM Subject: Re: [CentOS-devel] RH patches v/s vanilla docker in CentOS
...
Given the conflicting requirements, would it make sense to have appropriate tags such that, a particular 'docker' (something with RH patches) build only makes it to atomic, while another 'docker' build makes it to virt7-release (only upstream docker sources)
+1
I think it makes sense for everything atomic needs to live in atomic7, and if atomic wants the same version as virt has, great, if not, atomic could have its own.
I just tried a tree compose w/ docker-master, but it Provides docker-io, not docker, so yum's trying to pull in plain "docker" as well, which conflicts...
Jason
On Wed, Apr 29, 2015 at 07:16:30PM -0400, Jason Brooks wrote:
----- Original Message -----
From: "Jason Brooks" jbrooks@redhat.com To: "The CentOS developers mailing list." centos-devel@centos.org Sent: Wednesday, April 29, 2015 4:04:52 PM Subject: Re: [CentOS-devel] RH patches v/s vanilla docker in CentOS
----- Original Message -----
From: "Lokesh Mandvekar" lsm5@fedoraproject.org To: "The CentOS developers mailing list." centos-devel@centos.org Sent: Wednesday, April 22, 2015 9:07:12 AM Subject: Re: [CentOS-devel] RH patches v/s vanilla docker in CentOS
...
Given the conflicting requirements, would it make sense to have appropriate tags such that, a particular 'docker' (something with RH patches) build only makes it to atomic, while another 'docker' build makes it to virt7-release (only upstream docker sources)
+1
I think it makes sense for everything atomic needs to live in atomic7, and if atomic wants the same version as virt has, great, if not, atomic could have its own.
I just tried a tree compose w/ docker-master, but it Provides docker-io, not docker, so yum's trying to pull in plain "docker" as well, which conflicts...
Ah ok, I can update it to 'Provides: docker' as well. But would that help solve the conflict or would it still get confused between 'docker' and 'docker-master'. Maybe, docker-master deserves to be in a separate tag, virt7-nightly perhaps??
Jason
CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
----- Original Message -----
From: "Lokesh Mandvekar" lsm5@fedoraproject.org To: "The CentOS developers mailing list." centos-devel@centos.org Sent: Thursday, April 30, 2015 6:37:58 AM Subject: Re: [CentOS-devel] RH patches v/s vanilla docker in CentOS
On Wed, Apr 29, 2015 at 07:16:30PM -0400, Jason Brooks wrote:
----- Original Message -----
From: "Jason Brooks" jbrooks@redhat.com To: "The CentOS developers mailing list." centos-devel@centos.org Sent: Wednesday, April 29, 2015 4:04:52 PM Subject: Re: [CentOS-devel] RH patches v/s vanilla docker in CentOS
----- Original Message -----
From: "Lokesh Mandvekar" lsm5@fedoraproject.org To: "The CentOS developers mailing list." centos-devel@centos.org Sent: Wednesday, April 22, 2015 9:07:12 AM Subject: Re: [CentOS-devel] RH patches v/s vanilla docker in CentOS
...
Given the conflicting requirements, would it make sense to have appropriate tags such that, a particular 'docker' (something with RH patches) build only makes it to atomic, while another 'docker' build makes it to virt7-release (only upstream docker sources)
+1
I think it makes sense for everything atomic needs to live in atomic7, and if atomic wants the same version as virt has, great, if not, atomic could have its own.
I just tried a tree compose w/ docker-master, but it Provides docker-io, not docker, so yum's trying to pull in plain "docker" as well, which conflicts...
Ah ok, I can update it to 'Provides: docker' as well. But would that help solve the conflict or would it still get confused between 'docker' and 'docker-master'. Maybe, docker-master deserves to be in a separate tag, virt7-nightly perhaps??
It looks like kubernetes depends on docker or docker-io, so no problem there. In my compose, it's the atomic pkg that's calling for docker. Maybe the atomic pkg is what needs changing.
Jason
Jason
CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
-- Lokesh Freenode, OFTC: lsm5 GPG: 0xC7C3A0DD
CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
On 04/21/2015 12:05 PM, Johnny Hughes wrote:
Which is why I thought we want RH type behavior (ie patches) on both our fast moving and RHEL Atomic Host downstream branches for C7. We need stuff that works correctly with SELINUX and systemd on CentOS-7. So, IMHO, we want newer docker and RH patches.
I certainly do - it doesn't make sense to me to have a faster moving Atomic missing the RHT patches and then put them into the rebuild. Let's be consistent as much as possible.
Now, what the virt-SIG does is really up to them, maybe they intend to always ship vanilla upstream -- which is fine, but IMO it would make more sense to have a consistent story as much as possible.
Best,
jzb
On Mon, Apr 27, 2015 at 12:54:09PM -0400, Joe Brockmeier wrote:
On 04/21/2015 12:05 PM, Johnny Hughes wrote:
Which is why I thought we want RH type behavior (ie patches) on both our fast moving and RHEL Atomic Host downstream branches for C7. We need stuff that works correctly with SELINUX and systemd on CentOS-7. So, IMHO, we want newer docker and RH patches.
I certainly do - it doesn't make sense to me to have a faster moving Atomic missing the RHT patches and then put them into the rebuild. Let's be consistent as much as possible.
Now, what the virt-SIG does is really up to them, maybe they intend to always ship vanilla upstream -- which is fine,
Well, I'd say my intent is to entertain as many people as I can, so CentOS can retain and gain more users :). I'm willing to maintain as many variants of docker to make everyone happy, but the current state of SIG package maintenance on CentOS is probably not optimal for that. Perhaps once dist-gits are available things will be easier. Or maybe I'm just doing it all wrong (corrections welcome).
but IMO it would make more sense to have a consistent story as much as possible.
Sure, many devs on this list and this thread are in favor of the RH patches, but then again, there are many users and Docker upstream itself looking for a vanilla build. That's the reason we need to account for this case too.
Best,
jzb
-- Joe Brockmeier | Principal Cloud & Storage Analyst jzb@redhat.com | http://community.redhat.com/ Twitter: @jzb | http://dissociatedpress.net/
CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
-
Colin Walters -
Daniel J Walsh -
George Dunlap -
Jason Brooks -
Jim Perrin -
Joe Brockmeier -
Johnny Hughes -
Lokesh Mandvekar