Atomic 2 week releases
Hey all, I wanted to start a thread about doing more frequent Atomic releases in Fedora. In particular I'd like to start building a new atomic release every two weeks that includes the latest version of Docker, Kubernetes, and OSTree for the Fedora Atomic images. The problem I'm trying to solve here is that there is a lot of work going on upstream in the Docker and Kubernetes communities and there isn't a very good way to consume that upstream work on a Red Hat/Fedora/CentOS system today. By focusing on more regular releases, we can fix some of the issues we've seen (like demoing new features at a conference that people can't actually use). There are still some details to work out like whether to base this image on Fedora $CURRENT or rawhide and what to do when the builds fail. Fortunately, this can possibly be done without much additional change to the release process. We're already rebuilding the docker/kubernetes/ostree rpms almost daily, and there are nightly builds as well (at least in rawhide). If we can pull a 2 week process off, I'd like to see that followed by a 4 week process in CentOS which will behave similarly but with the slightly slower-moving, more stable bits. Thoughts? [1] http://www.projectatomic.io/download/ -- Mike McGrath | mmcgr...@redhat.com | (312) 660-3547 Atomic | Red Hat Chicago | http://projectatomic.io/ ___ cloud mailing list cloud@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Atomic 2 week releases
On 03/09/2015 03:34 PM, Michael P. McGrath wrote: > Hey all, I wanted to start a thread about doing more frequent Atomic releases > in Fedora. > In particular I'd like to start building a new atomic release every two weeks > that > includes the latest version of Docker, Kubernetes, and OSTree for the Fedora > Atomic > images. > > The problem I'm trying to solve here is that there is a lot of work going on > upstream in > the Docker and Kubernetes communities and there isn't a very good way to > consume that > upstream work on a Red Hat/Fedora/CentOS system today. By focusing on more > regular > releases, we can fix some of the issues we've seen (like demoing new features > at a > conference that people can't actually use). > > There are still some details to work out like whether to base this image on > Fedora > $CURRENT or rawhide and what to do when the builds fail. Fortunately, this > can possibly > be done without much additional change to the release process. We're already > rebuilding > the docker/kubernetes/ostree rpms almost daily, and there are nightly builds > as well > (at least in rawhide). > > If we can pull a 2 week process off, I'd like to see that followed by a 4 > week process > in CentOS which will behave similarly but with the slightly slower-moving, > more stable bits. > > Thoughts? With the centos hat on, +1, lets do it! -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc ___ cloud mailing list cloud@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Atomic 2 week releases
On 03/09/2015 11:34 AM, Michael P. McGrath wrote: > Hey all, I wanted to start a thread about doing more frequent Atomic releases > in Fedora. > In particular I'd like to start building a new atomic release every two weeks > that > includes the latest version of Docker, Kubernetes, and OSTree for the Fedora > Atomic > images. > > The problem I'm trying to solve here is that there is a lot of work going on > upstream in > the Docker and Kubernetes communities and there isn't a very good way to > consume that > upstream work on a Red Hat/Fedora/CentOS system today. By focusing on more > regular > releases, we can fix some of the issues we've seen (like demoing new features > at a > conference that people can't actually use). > > There are still some details to work out like whether to base this image on > Fedora > $CURRENT or rawhide and what to do when the builds fail. Fortunately, this > can possibly > be done without much additional change to the release process. We're already > rebuilding > the docker/kubernetes/ostree rpms almost daily, and there are nightly builds > as well > (at least in rawhide). > > If we can pull a 2 week process off, I'd like to see that followed by a 4 > week process > in CentOS which will behave similarly but with the slightly slower-moving, > more stable bits. > > Thoughts? > > [1] http://www.projectatomic.io/download/ > > -- > Mike McGrath | mmcgr...@redhat.com | (312) 660-3547 > Atomic | Red Hat Chicago | http://projectatomic.io/ > ___ > cloud mailing list > cloud@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/cloud > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct I guess the question here would be around where we would do the releases? In a perfect world, I would like to see "Daily" releases in Rawhide, as long was we had an installable tree. Every two weeks would be in Fedora Stable. If others wanted to back port to Fedora Stable-1 that would be ok, but I don't see that as the primary focus. We would be doing a lot of this with the Docker Devel branch, along with some patches that we are experimenting with. I am sure K8s would be doing something similar. ___ cloud mailing list cloud@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Atomic 2 week releases
- Original Message - > From: "Daniel J Walsh" > To: "Fedora Cloud SIG" > Sent: Monday, March 9, 2015 10:45:42 AM > Subject: Re: Atomic 2 week releases > > > On 03/09/2015 11:34 AM, Michael P. McGrath wrote: > > Hey all, I wanted to start a thread about doing more frequent Atomic > > releases in Fedora. > > In particular I'd like to start building a new atomic release every two > > weeks that > > includes the latest version of Docker, Kubernetes, and OSTree for the > > Fedora Atomic > > images. > > > > The problem I'm trying to solve here is that there is a lot of work going > > on upstream in > > the Docker and Kubernetes communities and there isn't a very good way to > > consume that > > upstream work on a Red Hat/Fedora/CentOS system today. By focusing on more > > regular > > releases, we can fix some of the issues we've seen (like demoing new > > features at a > > conference that people can't actually use). > > > > There are still some details to work out like whether to base this image on > > Fedora > > $CURRENT or rawhide and what to do when the builds fail. Fortunately, this > > can possibly > > be done without much additional change to the release process. We're > > already rebuilding > > the docker/kubernetes/ostree rpms almost daily, and there are nightly > > builds as well > > (at least in rawhide). > > > > If we can pull a 2 week process off, I'd like to see that followed by a 4 > > week process > > in CentOS which will behave similarly but with the slightly slower-moving, > > more stable bits. > > > > Thoughts? > > > > [1] http://www.projectatomic.io/download/ > > > > -- > > Mike McGrath | mmcgr...@redhat.com | (312) 660-3547 > > Atomic | Red Hat Chicago | http://projectatomic.io/ > > ___ > > cloud mailing list > > cloud@lists.fedoraproject.org > > https://admin.fedoraproject.org/mailman/listinfo/cloud > > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct > I guess the question here would be around where we would do the releases? > > In a perfect world, I would like to see "Daily" releases in Rawhide, as > long was we had an installable > tree. Every two weeks would be in Fedora Stable. If others wanted to > back port to Fedora Stable-1 > that would be ok, but I don't see that as the primary focus. > > We would be doing a lot of this with the Docker Devel branch, along with > some patches that we are experimenting > with. > > I am sure K8s would be doing something similar. > What version of docker would be in Fedora $CURRENT? stable or devel? And would that version go out to both Atomic Fedora *and* regular Fedora users or just Atomic Fedora? -Mike > > ___ > cloud mailing list > cloud@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/cloud > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct > ___ cloud mailing list cloud@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Atomic 2 week releases
As part of the Cloud WG, this is something we wanted to do from the beginning. Personally, I'd prefer having two sets of images: * unstable: based on rawhide * testing: based on current stable + newer set of packages The main blocker is our infrastructure, which is something that Kushal and Mike are trying to (partly) address by fleshing up our CI for our images. Definitive answer will depend on what we can do with our current Rel-Eng infra. Regards, H. ___ cloud mailing list cloud@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Atomic 2 week releases
On Mon, Mar 9, 2015 at 10:34 AM, Michael P. McGrath wrote: > Hey all, I wanted to start a thread about doing more frequent Atomic releases > in Fedora. > In particular I'd like to start building a new atomic release every two weeks > that > includes the latest version of Docker, Kubernetes, and OSTree for the Fedora > Atomic > images. > > The problem I'm trying to solve here is that there is a lot of work going on > upstream in > the Docker and Kubernetes communities and there isn't a very good way to > consume that > upstream work on a Red Hat/Fedora/CentOS system today. By focusing on more > regular > releases, we can fix some of the issues we've seen (like demoing new features > at a > conference that people can't actually use). > > There are still some details to work out like whether to base this image on > Fedora > $CURRENT or rawhide and what to do when the builds fail. Fortunately, this > can possibly > be done without much additional change to the release process. We're already > rebuilding > the docker/kubernetes/ostree rpms almost daily, and there are nightly builds > as well > (at least in rawhide). For those not familiar with the current release process of Atomic, can you provide a link to documentation on how that is done as well as what tooling is involved? Thank you, -AdamM > > If we can pull a 2 week process off, I'd like to see that followed by a 4 > week process > in CentOS which will behave similarly but with the slightly slower-moving, > more stable bits. > > Thoughts? > > [1] http://www.projectatomic.io/download/ > > -- > Mike McGrath | mmcgr...@redhat.com | (312) 660-3547 > Atomic | Red Hat Chicago | http://projectatomic.io/ > ___ > cloud mailing list > cloud@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/cloud > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct ___ cloud mailing list cloud@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Atomic 2 week releases
On Mon, Mar 9, 2015, at 12:14 PM, Adam Miller wrote: > For those not familiar with the current release process of Atomic, can > you provide a link to documentation on how that is done as well as > what tooling is involved? Keep in mind that the original vision for Atomic was *not* to be a distribution itself - merely technology that flows-into/is-consumed-by the 3 distribution family. So when we're talking about "release process for Atomic", that question is necessarily distribution specific, although the ideal is that they share code. With that in mind then, for Fedora 21, Atomic is offered solely as a cloud image. That cloud image though is generated via the "ostreesetup" kickstart verb: https://git.fedorahosted.org/cgit/spin-kickstarts.git/tree/fedora-cloud-atomic.ks#n33 This replaces a traditional %packages section; anaconda here is *replicating*, not assembling. The tree is built on a separate server using rpm-ostree: https://git.fedorahosted.org/cgit/releng/tree/scripts/run-pungi#n39 Now for Fedora 22, we're trying to expand the scope: https://fedoraproject.org/wiki/Changes/AtomicHost Concurrently, CentOS has two yum repositories: virt7 and atomic7, that contain docker/kubernetes and the ostree/atomic stack, respectively. These are layers on top of the CentOS7.0 base, distinct from the Fedora "one big repo on one release cycle" model. These RPMs are built using the CentOS CBS Koji: http://cbs.centos.org/koji/ Then for Atomic, the RPMs are composed into a tree by a script. We're still working on an Anaconda based CentOS, as backporting the ostreesetup changes has proved very painful. That problem should sort itself out over time however. Right now, I am looking at: https://fedorahosted.org/rel-eng/ticket/6119 to further the Fedora integration. ___ cloud mailing list cloud@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Atomic 2 week releases
On Mon, Mar 9, 2015, at 11:34 AM, Michael P. McGrath wrote: > Hey all, I wanted to start a thread about doing more frequent Atomic releases > in Fedora. > In particular I'd like to start building a new atomic release every two weeks > that > includes the latest version of Docker, Kubernetes, and OSTree for the Fedora > Atomic > images. There's also other components; while etcd and flannel could be thought of as "kubernetes enablers" and fall under the same umbrella, they are distinct projects with their own release cycle. Also, it's worth keeping in mind that it would be nice if we made more use of newer systemd features, which is a big project with its own cycle. Finally, I'll also note that rpm-ostree does link to the packaging stack (libhif -> hawkey/librepo) which necessarily implies some ties to the cycle of those components. > There are still some details to work out like whether to base this image on > Fedora > $CURRENT or rawhide and what to do when the builds fail. Not just build failure, but runtime failure. > Fortunately, this can possibly > be done without much additional change to the release process. We're already > rebuilding > the docker/kubernetes/ostree rpms almost daily, and there are nightly builds > as well > (at least in rawhide). I'm not actually doing the ostree side very often right now, but that will hopefully change as more user-visible features land. Anyways, the bottom line for me on this is: Before we can do two weeks, we need to be able to do rawhide. There are parts of this that work (tree and cloud images are carryover from F22), but the installer and PXE-to-Live are blocked on: https://fedorahosted.org/rel-eng/ticket/6119 ___ cloud mailing list cloud@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Atomic 2 week releases
- Original Message - > From: "Colin Walters" > To: cloud@lists.fedoraproject.org > Sent: Monday, March 9, 2015 12:40:39 PM > Subject: Re: Atomic 2 week releases > > On Mon, Mar 9, 2015, at 11:34 AM, Michael P. McGrath wrote: > > Hey all, I wanted to start a thread about doing more frequent Atomic > > releases in Fedora. > > In particular I'd like to start building a new atomic release every two > > weeks that > > includes the latest version of Docker, Kubernetes, and OSTree for the > > Fedora Atomic > > images. > > There's also other components; while etcd and flannel could be thought of as > "kubernetes enablers" > and fall under the same umbrella, they are distinct projects with their own > release cycle. > > Also, it's worth keeping in mind that it would be nice if we made more use of > newer systemd > features, which is a big project with its own cycle. > > Finally, I'll also note that rpm-ostree does link to the packaging stack > (libhif -> hawkey/librepo) > which necessarily implies some ties to the cycle of those components. > Nod, it's just hard to list all of those out. Perhaps in the future we should call them "Atomic components." > > There are still some details to work out like whether to base this image on > > Fedora > > $CURRENT or rawhide and what to do when the builds fail. > > Not just build failure, but runtime failure. > This one's new to me, I'm aware of the issues with building images but I was under the impression that the composed OStree was still happening successfully whenever rawhide was building. Are you saying there are sometimes where upgrading to those trees would have resulted in an unbootable system? -Mike > > Fortunately, this can possibly > > be done without much additional change to the release process. We're > > already rebuilding > > the docker/kubernetes/ostree rpms almost daily, and there are nightly > > builds as well > > (at least in rawhide). > > I'm not actually doing the ostree side very often right now, but that will > hopefully > change as more user-visible features land. > > Anyways, the bottom line for me on this is: > > Before we can do two weeks, we need to be able to do rawhide. There are > parts > of this that work (tree and cloud images are carryover from F22), but the > installer > and PXE-to-Live are blocked on: > https://fedorahosted.org/rel-eng/ticket/6119 > > ___ > cloud mailing list > cloud@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/cloud > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct > ___ cloud mailing list cloud@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Atomic 2 week releases
On Mon, Mar 9, 2015, at 02:49 PM, Michael P. McGrath wrote: > > This one's new to me, I'm aware of the issues with building images but I > was under the impression that the composed OStree was still happening > successfully > whenever rawhide was building. Are you saying there are sometimes where > upgrading > to those trees would have resulted in an unbootable system? Ah, I meant RPMs. Generally if the RPMs work, the tree will as well. It's possible there are tree-specific issues but so far that's been generally rare. I just meant more the generic runtime issues that always happen. A random example from a few days ago in rawhide is an NSS build breaking curl or so, and thus breaking everything that uses libcurl, which is obviously a lot. ___ cloud mailing list cloud@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Atomic 2 week releases
On Mon, Mar 9, 2015 at 8:34 AM, Michael P. McGrath wrote: > Hey all, I wanted to start a thread about doing more frequent Atomic releases > in Fedora. > In particular I'd like to start building a new atomic release every two weeks > that > includes the latest version of Docker, Kubernetes, and OSTree for the Fedora > Atomic > images. > > The problem I'm trying to solve here is that there is a lot of work going on > upstream in > the Docker and Kubernetes communities and there isn't a very good way to > consume that > upstream work on a Red Hat/Fedora/CentOS system today. By focusing on more > regular > releases, we can fix some of the issues we've seen (like demoing new features > at a > conference that people can't actually use). IMHO RHEL/CentOS have got to be solid / stable / secure, etc. Documented, tested, ready to build *production* services upon. Training, professional certification - the works! Docker may be there - I've only played with it for about six months and aside from some annoying SELinux phenomena, it seems to be good and it's definitely popular. But Atomic and Kubernetes? Where's the documentation? "Use the source, Luke" is not an acceptable answer. So please ... have at it in Fedora, I'll be a willing guinea pig and all that. But RHEL/CentOS? Please wait till it has some mileage on it in Fedora. ___ cloud mailing list cloud@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Atomic 2 week releases
- Original Message - > From: "Daniel J Walsh" > To: "Fedora Cloud SIG" > Sent: Tuesday, March 10, 2015 11:31:27 AM > Subject: Re: Atomic 2 week releases > > > On 03/09/2015 12:03 PM, Michael P. McGrath wrote: > > - Original Message - > >> From: "Daniel J Walsh" > >> To: "Fedora Cloud SIG" > >> Sent: Monday, March 9, 2015 10:45:42 AM > >> Subject: Re: Atomic 2 week releases > >> > >> > >> On 03/09/2015 11:34 AM, Michael P. McGrath wrote: > >>> Hey all, I wanted to start a thread about doing more frequent Atomic > >>> releases in Fedora. > >>> In particular I'd like to start building a new atomic release every two > >>> weeks that > >>> includes the latest version of Docker, Kubernetes, and OSTree for the > >>> Fedora Atomic > >>> images. > >>> > >>> The problem I'm trying to solve here is that there is a lot of work going > >>> on upstream in > >>> the Docker and Kubernetes communities and there isn't a very good way to > >>> consume that > >>> upstream work on a Red Hat/Fedora/CentOS system today. By focusing on > >>> more > >>> regular > >>> releases, we can fix some of the issues we've seen (like demoing new > >>> features at a > >>> conference that people can't actually use). > >>> > >>> There are still some details to work out like whether to base this image > >>> on > >>> Fedora > >>> $CURRENT or rawhide and what to do when the builds fail. Fortunately, > >>> this > >>> can possibly > >>> be done without much additional change to the release process. We're > >>> already rebuilding > >>> the docker/kubernetes/ostree rpms almost daily, and there are nightly > >>> builds as well > >>> (at least in rawhide). > >>> > >>> If we can pull a 2 week process off, I'd like to see that followed by a 4 > >>> week process > >>> in CentOS which will behave similarly but with the slightly > >>> slower-moving, > >>> more stable bits. > >>> > >>> Thoughts? > >>> > >>> [1] http://www.projectatomic.io/download/ > >>> > >>> -- > >>> Mike McGrath | mmcgr...@redhat.com | (312) 660-3547 > >>> Atomic | Red Hat Chicago | http://projectatomic.io/ > >>> ___ > >>> cloud mailing list > >>> cloud@lists.fedoraproject.org > >>> https://admin.fedoraproject.org/mailman/listinfo/cloud > >>> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct > >> I guess the question here would be around where we would do the releases? > >> > >> In a perfect world, I would like to see "Daily" releases in Rawhide, as > >> long was we had an installable > >> tree. Every two weeks would be in Fedora Stable. If others wanted to > >> back port to Fedora Stable-1 > >> that would be ok, but I don't see that as the primary focus. > >> > >> We would be doing a lot of this with the Docker Devel branch, along with > >> some patches that we are experimenting > >> with. > >> > >> I am sure K8s would be doing something similar. > >> > > What version of docker would be in Fedora $CURRENT? stable or devel? And > > would that version go out to both Atomic Fedora *and* regular Fedora users > > or just Atomic Fedora? > > > > -Mike > Those are the questions I would like to have answered. Stable in current, devel in rawhide. We just don't yet have the toolchains to split different versions of our packages onto the same Fedora. We'll have to see if there's a way to do it when Adam joins up. -Mike > >> ___ > >> cloud mailing list > >> cloud@lists.fedoraproject.org > >> https://admin.fedoraproject.org/mailman/listinfo/cloud > >> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct > >> > > ___ > > cloud mailing list > > cloud@lists.fedoraproject.org > > https://admin.fedoraproject.org/mailman/listinfo/cloud > > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct > > ___ > cloud mailing list > cloud@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/cloud > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct > ___ cloud mailing list cloud@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Atomic 2 week releases
On 03/10/2015 01:09 PM, Michael P. McGrath wrote: > - Original Message - >> From: "Daniel J Walsh" >> To: "Fedora Cloud SIG" >> Sent: Tuesday, March 10, 2015 11:31:27 AM >> Subject: Re: Atomic 2 week releases >> >> >> On 03/09/2015 12:03 PM, Michael P. McGrath wrote: >>> - Original Message - >>>> From: "Daniel J Walsh" >>>> To: "Fedora Cloud SIG" >>>> Sent: Monday, March 9, 2015 10:45:42 AM >>>> Subject: Re: Atomic 2 week releases >>>> >>>> >>>> On 03/09/2015 11:34 AM, Michael P. McGrath wrote: >>>>> Hey all, I wanted to start a thread about doing more frequent Atomic >>>>> releases in Fedora. >>>>> In particular I'd like to start building a new atomic release every two >>>>> weeks that >>>>> includes the latest version of Docker, Kubernetes, and OSTree for the >>>>> Fedora Atomic >>>>> images. >>>>> >>>>> The problem I'm trying to solve here is that there is a lot of work going >>>>> on upstream in >>>>> the Docker and Kubernetes communities and there isn't a very good way to >>>>> consume that >>>>> upstream work on a Red Hat/Fedora/CentOS system today. By focusing on >>>>> more >>>>> regular >>>>> releases, we can fix some of the issues we've seen (like demoing new >>>>> features at a >>>>> conference that people can't actually use). >>>>> >>>>> There are still some details to work out like whether to base this image >>>>> on >>>>> Fedora >>>>> $CURRENT or rawhide and what to do when the builds fail. Fortunately, >>>>> this >>>>> can possibly >>>>> be done without much additional change to the release process. We're >>>>> already rebuilding >>>>> the docker/kubernetes/ostree rpms almost daily, and there are nightly >>>>> builds as well >>>>> (at least in rawhide). >>>>> >>>>> If we can pull a 2 week process off, I'd like to see that followed by a 4 >>>>> week process >>>>> in CentOS which will behave similarly but with the slightly >>>>> slower-moving, >>>>> more stable bits. >>>>> >>>>> Thoughts? >>>>> >>>>> [1] http://www.projectatomic.io/download/ >>>>> >>>>> -- >>>>> Mike McGrath | mmcgr...@redhat.com | (312) 660-3547 >>>>> Atomic | Red Hat Chicago | http://projectatomic.io/ >>>>> ___ >>>>> cloud mailing list >>>>> cloud@lists.fedoraproject.org >>>>> https://admin.fedoraproject.org/mailman/listinfo/cloud >>>>> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct >>>> I guess the question here would be around where we would do the releases? >>>> >>>> In a perfect world, I would like to see "Daily" releases in Rawhide, as >>>> long was we had an installable >>>> tree. Every two weeks would be in Fedora Stable. If others wanted to >>>> back port to Fedora Stable-1 >>>> that would be ok, but I don't see that as the primary focus. >>>> >>>> We would be doing a lot of this with the Docker Devel branch, along with >>>> some patches that we are experimenting >>>> with. >>>> >>>> I am sure K8s would be doing something similar. >>>> >>> What version of docker would be in Fedora $CURRENT? stable or devel? And >>> would that version go out to both Atomic Fedora *and* regular Fedora users >>> or just Atomic Fedora? >>> >>> -Mike >> Those are the questions I would like to have answered. > Stable in current, devel in rawhide. We just don't yet have the toolchains to > split different versions of our packages onto the same Fedora. We'll have to > see if there's a way to do it when Adam joins up. > > -Mike I was thinking a long the lines of putting a new docker package into updates at the same time we release it to atomic. Then after a couple of weeks releasing the docker package to updates. But yes we will be shipping docker upstream minor releases as updates along with some experimental patches (Patches that have not made it upstream yet.) >>>> ___ >>>> cloud mailing list >>>> cloud@lists.fedoraproject.org >>>> https://admin.fedoraproject.org/mailman/listinfo/cloud >>>> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct >>>> >>> ___ >>> cloud mailing list >>> cloud@lists.fedoraproject.org >>> https://admin.fedoraproject.org/mailman/listinfo/cloud >>> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct >> ___ >> cloud mailing list >> cloud@lists.fedoraproject.org >> https://admin.fedoraproject.org/mailman/listinfo/cloud >> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct >> > ___ > cloud mailing list > cloud@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/cloud > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct ___ cloud mailing list cloud@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Atomic 2 week releases
On Mon, Mar 09, 2015 at 01:17:44PM -0400, Colin Walters wrote: > Keep in mind that the original vision for Atomic was *not* to be a > distribution itself - merely technology that > flows-into/is-consumed-by the 3 distribution family. So when we're > talking about "release process for Atomic", that question is > necessarily distribution specific, although the ideal is that they > share code. [...] > Now for Fedora 22, we're trying to expand the scope: > https://fedoraproject.org/wiki/Changes/AtomicHost So, I'm wondering if for F22 (or F23, if we feel like that ship is out in the harbor losing sight of land already), we want to do one of two things: A. Move Atomic out of the Cloud Edition, and treat it as a spin, with a home at "http://atomic.fedoraproject.org/"; (not currently valid), similar to http://kde.fedoraproject.org — with its own design, theming, etc. Here, the Cloud WG / Cloud SIG would focus more on cloud/virt-guest issues, and possible also cloud infrastructure (openstack, eucalyptus, etc., which we have kind of let fall to the wayside). The Cloud Base image would be the primary Fedora Edition, and Fedora Atomic would be more ... stand-alone. B. The other way around: double down on Atomic as the primary thing the Cloud WG releases as the Fedora cloud product. Here, the focus would be more on containers as the basis for the future of "cattle-style" scale-out computing, and Atomic as Fedora's cool solution for that. The Cloud Base image would be the one changed into a spin — after all, going back to the Lego metaphor for the Fedora editions, the products are supposed to be focused on "batteries included" solutions, and while an awesome building block, the minimal base doesn't quite do that. C. Nah, keep doing the two different things and present in parallel, as we've been doing. -- Matthew Miller Fedora Project Leader ___ cloud mailing list cloud@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Atomic 2 week releases
On 03/10/2015 02:53 PM, Matthew Miller wrote: > So, I'm wondering if for F22 (or F23, if we feel like that ship is out > in the harbor losing sight of land already), we want to do one of two > things: > > A. Move Atomic out of the Cloud Edition, and treat it as a spin, with a >home at "http://atomic.fedoraproject.org/"; (not currently valid), >similar to http://kde.fedoraproject.org — with its own design, theming, >etc. > >Here, the Cloud WG / Cloud SIG would focus more on cloud/virt-guest >issues, and possible also cloud infrastructure (openstack, >eucalyptus, etc., which we have kind of let fall to the wayside). >The Cloud Base image would be the primary Fedora Edition, and Fedora >Atomic would be more ... stand-alone. > > B. The other way around: double down on Atomic as the primary thing the >Cloud WG releases as the Fedora cloud product. Here, the focus would be >more on containers as the basis for the future of "cattle-style" >scale-out computing, and Atomic as Fedora's cool solution for that. >The Cloud Base image would be the one changed into a spin — after >all, going back to the Lego metaphor for the Fedora editions, the >products are supposed to be focused on "batteries included" >solutions, and while an awesome building block, the minimal base >doesn't quite do that. > > C. Nah, keep doing the two different things and present in parallel, as >we've been doing. Let's discuss this at this week's meeting? My gut is to pursue Atomic as a spin (A) rather than asking the Cloud WG to double-down on Atomic, but maybe the rest of the Working Group feels differently... Best, jzb -- Joe Brockmeier | Principal Cloud & Storage Analyst j...@redhat.com | http://community.redhat.com/ Twitter: @jzb | http://dissociatedpress.net/ signature.asc Description: OpenPGP digital signature ___ cloud mailing list cloud@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Atomic 2 week releases
On Tue, Mar 10, 2015 at 1:59 PM, Joe Brockmeier wrote: > On 03/10/2015 02:53 PM, Matthew Miller wrote: >> So, I'm wondering if for F22 (or F23, if we feel like that ship is out >> in the harbor losing sight of land already), we want to do one of two >> things: >> >> A. Move Atomic out of the Cloud Edition, and treat it as a spin, with a >>home at "http://atomic.fedoraproject.org/"; (not currently valid), >>similar to http://kde.fedoraproject.org — with its own design, theming, >>etc. >> >>Here, the Cloud WG / Cloud SIG would focus more on cloud/virt-guest >>issues, and possible also cloud infrastructure (openstack, >>eucalyptus, etc., which we have kind of let fall to the wayside). >>The Cloud Base image would be the primary Fedora Edition, and Fedora >>Atomic would be more ... stand-alone. >> >> B. The other way around: double down on Atomic as the primary thing the >>Cloud WG releases as the Fedora cloud product. Here, the focus would be >>more on containers as the basis for the future of "cattle-style" >>scale-out computing, and Atomic as Fedora's cool solution for that. >>The Cloud Base image would be the one changed into a spin — after >>all, going back to the Lego metaphor for the Fedora editions, the >>products are supposed to be focused on "batteries included" >>solutions, and while an awesome building block, the minimal base >>doesn't quite do that. >> >> C. Nah, keep doing the two different things and present in parallel, as >>we've been doing. > > Let's discuss this at this week's meeting? My gut is to pursue Atomic as > a spin (A) rather than asking the Cloud WG to double-down on Atomic, but > maybe the rest of the Working Group feels differently... > FWIW +1 for Spin (A) -AdamM > Best, > > jzb > -- > Joe Brockmeier | Principal Cloud & Storage Analyst > j...@redhat.com | http://community.redhat.com/ > Twitter: @jzb | http://dissociatedpress.net/ > > > ___ > cloud mailing list > cloud@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/cloud > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct > ___ cloud mailing list cloud@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Atomic 2 week releases
Is there a possibility of an Atomic Edition that doesn't shift the Cloud Edition focus away from being a good base? Atomic is a specialized case for general cloud workloads, and containerizing everything probably won't be a near time thing. But then, I don't know what constitutes criteria for a top level edition vs a spin. -Matt M On Tue, Mar 10, 2015 at 3:48 PM, Adam Miller wrote: > On Tue, Mar 10, 2015 at 1:59 PM, Joe Brockmeier wrote: > > On 03/10/2015 02:53 PM, Matthew Miller wrote: > >> So, I'm wondering if for F22 (or F23, if we feel like that ship is out > >> in the harbor losing sight of land already), we want to do one of two > >> things: > >> > >> A. Move Atomic out of the Cloud Edition, and treat it as a spin, with a > >>home at "http://atomic.fedoraproject.org/"; (not currently valid), > >>similar to http://kde.fedoraproject.org — with its own design, > theming, > >>etc. > >> > >>Here, the Cloud WG / Cloud SIG would focus more on cloud/virt-guest > >>issues, and possible also cloud infrastructure (openstack, > >>eucalyptus, etc., which we have kind of let fall to the wayside). > >>The Cloud Base image would be the primary Fedora Edition, and Fedora > >>Atomic would be more ... stand-alone. > >> > >> B. The other way around: double down on Atomic as the primary thing the > >>Cloud WG releases as the Fedora cloud product. Here, the focus would > be > >>more on containers as the basis for the future of "cattle-style" > >>scale-out computing, and Atomic as Fedora's cool solution for that. > >>The Cloud Base image would be the one changed into a spin — after > >>all, going back to the Lego metaphor for the Fedora editions, the > >>products are supposed to be focused on "batteries included" > >>solutions, and while an awesome building block, the minimal base > >>doesn't quite do that. > >> > >> C. Nah, keep doing the two different things and present in parallel, as > >>we've been doing. > > > > Let's discuss this at this week's meeting? My gut is to pursue Atomic as > > a spin (A) rather than asking the Cloud WG to double-down on Atomic, but > > maybe the rest of the Working Group feels differently... > > > > FWIW +1 for Spin (A) > > -AdamM > > > Best, > > > > jzb > > -- > > Joe Brockmeier | Principal Cloud & Storage Analyst > > j...@redhat.com | http://community.redhat.com/ > > Twitter: @jzb | http://dissociatedpress.net/ > > > > > > ___ > > cloud mailing list > > cloud@lists.fedoraproject.org > > https://admin.fedoraproject.org/mailman/listinfo/cloud > > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct > > > ___ > cloud mailing list > cloud@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/cloud > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct > ___ cloud mailing list cloud@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Atomic 2 week releases
On Tue, Mar 10, 2015 at 3:48 PM, Adam Miller wrote: > On Tue, Mar 10, 2015 at 1:59 PM, Joe Brockmeier wrote: >> On 03/10/2015 02:53 PM, Matthew Miller wrote: >>> So, I'm wondering if for F22 (or F23, if we feel like that ship is out >>> in the harbor losing sight of land already), we want to do one of two >>> things: >>> >>> A. Move Atomic out of the Cloud Edition, and treat it as a spin, with a >>>home at "http://atomic.fedoraproject.org/"; (not currently valid), >>>similar to http://kde.fedoraproject.org -- with its own design, theming, >>>etc. >>> >>>Here, the Cloud WG / Cloud SIG would focus more on cloud/virt-guest >>>issues, and possible also cloud infrastructure (openstack, >>>eucalyptus, etc., which we have kind of let fall to the wayside). >>>The Cloud Base image would be the primary Fedora Edition, and Fedora >>>Atomic would be more ... stand-alone. >>> >>> B. The other way around: double down on Atomic as the primary thing the >>>Cloud WG releases as the Fedora cloud product. Here, the focus would be >>>more on containers as the basis for the future of "cattle-style" >>>scale-out computing, and Atomic as Fedora's cool solution for that. >>>The Cloud Base image would be the one changed into a spin -- after >>>all, going back to the Lego metaphor for the Fedora editions, the >>>products are supposed to be focused on "batteries included" >>>solutions, and while an awesome building block, the minimal base >>>doesn't quite do that. >>> >>> C. Nah, keep doing the two different things and present in parallel, as >>>we've been doing. >> >> Let's discuss this at this week's meeting? My gut is to pursue Atomic as >> a spin (A) rather than asking the Cloud WG to double-down on Atomic, but >> maybe the rest of the Working Group feels differently... >> > > FWIW +1 for Spin (A) Please consider this in-depth. A Spin might sound good for a number of reasons and those might be the most important factor. However at the moment with Atomic being a deliverable of the Cloud Edition, its placement in the various websites and promotion is rather high. The Spins are not at the same level as the Editions in terms of reach and impact. Atomic could make its own promotion through various means, but get.fedoraproject.org is not going to list Workstation, Server, Cloud, and Atomic if it moves to a Spin. I know Stephen is working on how Spins and other non-Edition images are dealt with, and the Council is very interested in this as well. That isn't in place yet, and to be honest I would be surprised if it was for F22 at all. Perhaps Atomic has enough momentum that a change here won't matter, but it is at least something everyone should be aware of. josh ___ cloud mailing list cloud@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Atomic 2 week releases
On Tue, Mar 10, 2015 at 6:37 PM, Josh Boyer wrote: > On Tue, Mar 10, 2015 at 3:48 PM, Adam Miller > wrote: >> On Tue, Mar 10, 2015 at 1:59 PM, Joe Brockmeier wrote: >>> On 03/10/2015 02:53 PM, Matthew Miller wrote: So, I'm wondering if for F22 (or F23, if we feel like that ship is out in the harbor losing sight of land already), we want to do one of two things: A. Move Atomic out of the Cloud Edition, and treat it as a spin, with a home at "http://atomic.fedoraproject.org/"; (not currently valid), similar to http://kde.fedoraproject.org -- with its own design, theming, etc. Here, the Cloud WG / Cloud SIG would focus more on cloud/virt-guest issues, and possible also cloud infrastructure (openstack, eucalyptus, etc., which we have kind of let fall to the wayside). The Cloud Base image would be the primary Fedora Edition, and Fedora Atomic would be more ... stand-alone. B. The other way around: double down on Atomic as the primary thing the Cloud WG releases as the Fedora cloud product. Here, the focus would be more on containers as the basis for the future of "cattle-style" scale-out computing, and Atomic as Fedora's cool solution for that. The Cloud Base image would be the one changed into a spin -- after all, going back to the Lego metaphor for the Fedora editions, the products are supposed to be focused on "batteries included" solutions, and while an awesome building block, the minimal base doesn't quite do that. C. Nah, keep doing the two different things and present in parallel, as we've been doing. >>> >>> Let's discuss this at this week's meeting? My gut is to pursue Atomic as >>> a spin (A) rather than asking the Cloud WG to double-down on Atomic, but >>> maybe the rest of the Working Group feels differently... >>> >> >> FWIW +1 for Spin (A) > > Please consider this in-depth. A Spin might sound good for a number > of reasons and those might be the most important factor. However at > the moment with Atomic being a deliverable of the Cloud Edition, its > placement in the various websites and promotion is rather high. The > Spins are not at the same level as the Editions in terms of reach and > impact. Atomic could make its own promotion through various means, > but get.fedoraproject.org is not going to list Workstation, Server, > Cloud, and Atomic if it moves to a Spin. > > I know Stephen is working on how Spins and other non-Edition images > are dealt with, and the Council is very interested in this as well. > That isn't in place yet, and to be honest I would be surprised if it > was for F22 at all. Perhaps Atomic has enough momentum that a change > here won't matter, but it is at least something everyone should be > aware of. Addendum: For all I know, Atomic might be such a hot ticket item in the Cloud world that moving it to a Spin would detract from the Fedora Cloud Edition itself. I was not meaning to imply one way or another that Atomic is reliant on Cloud or vice versa. I simply want to point out the less technical aspects of such a move. josh ___ cloud mailing list cloud@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Atomic 2 week releases
On Tue, Mar 10, 2015 at 06:37:28PM -0400, Josh Boyer wrote: > Please consider this in-depth. A Spin might sound good for a number > of reasons and those might be the most important factor. However at > the moment with Atomic being a deliverable of the Cloud Edition, its > placement in the various websites and promotion is rather high. The > Spins are not at the same level as the Editions in terms of reach and > impact. Atomic could make its own promotion through various means, > but get.fedoraproject.org is not going to list Workstation, Server, > Cloud, and Atomic if it moves to a Spin. So, following the parallel thread on the CentOS devel list... http://lists.centos.org/pipermail/centos-devel/2015-March/012961.html I think part of this decision fits into how ready we are to promote Fedora Atomic as a user solution as opposed to a development / hacking target. If it's still mostly the former, it might be _better_ to not over-promote it in that way. -- Matthew Miller Fedora Project Leader ___ cloud mailing list cloud@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Atomic 2 week releases
- Original Message - > From: "Matthew Miller" > To: "Fedora Cloud SIG" > Sent: Tuesday, March 10, 2015 8:02:34 PM > Subject: Re: Atomic 2 week releases > > On Tue, Mar 10, 2015 at 06:37:28PM -0400, Josh Boyer wrote: > > Please consider this in-depth. A Spin might sound good for a number > > of reasons and those might be the most important factor. However at > > the moment with Atomic being a deliverable of the Cloud Edition, its > > placement in the various websites and promotion is rather high. The > > Spins are not at the same level as the Editions in terms of reach and > > impact. Atomic could make its own promotion through various means, > > but get.fedoraproject.org is not going to list Workstation, Server, > > Cloud, and Atomic if it moves to a Spin. > > So, following the parallel thread on the CentOS devel list... > http://lists.centos.org/pipermail/centos-devel/2015-March/012961.html > > I think part of this decision fits into how ready we are to promote > Fedora Atomic as a user solution as opposed to a development / hacking > target. If it's still mostly the former, it might be _better_ to not > over-promote it in that way. > From the project atomic side, we're looking to promote both the Fedora and CentOS versions for different things. That said, there are many masters to worry about here. Fedora in particular will have their rawhide and stable releases promoted differently on the Fedora sites and the project atomic page will likely promote things a little differently and that is probably Ok as long as everyone ultimately has a choice to download whatever they want. I think the promotion part is largely just a way to direct people who otherwise don't know how to make an informed decision. On the Project Atomic side I'm mostly concerned with the emerging tech. Getting new features in front of people as soon as possible. In the short term, Fedora rawhide really is the only place to do that. Longer term though there is a desire to base the Atomic dependent packages (docker, kubernetes, etcd, ostree, etc.) on something more stable. Once Adam starts and once the tool chain matures we can always make changes. -Mike > > -- > Matthew Miller > > Fedora Project Leader > ___ > cloud mailing list > cloud@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/cloud > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct > ___ cloud mailing list cloud@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Atomic 2 week releases
Sorry I replied to this earlier but seems it got lost somewhere, or maybe I just thought I did, either way On Monday, March 09, 2015 01:17:44 PM Colin Walters wrote: > On Mon, Mar 9, 2015, at 12:14 PM, Adam Miller wrote: > > For those not familiar with the current release process of Atomic, can > > you provide a link to documentation on how that is done as well as > > what tooling is involved? > > Keep in mind that the original vision for Atomic was *not* to be a > distribution itself - merely technology that flows-into/is-consumed-by the > 3 distribution family. So when we're talking about "release process for > Atomic", that question is necessarily distribution specific, although the > ideal is that they share code. > > With that in mind then, for Fedora 21, Atomic is offered solely as a cloud > image. That cloud image though is generated via the "ostreesetup" > kickstart verb: > https://git.fedorahosted.org/cgit/spin-kickstarts.git/tree/fedora-cloud-ato > mic.ks#n33 > > This replaces a traditional %packages section; anaconda here is > *replicating*, not assembling. The tree is built on a separate server > using rpm-ostree: > https://git.fedorahosted.org/cgit/releng/tree/scripts/run-pungi#n39 This is not entirely true, it is just part of the picture. You can install on bare metal using anaconda with extlinux, exactly the same as we do to make the cloud image. But it is not advertised or really well documented. We make trees with every updates push in Fedora 21 so you always have the latest bits available. we make nightly rawhide and branched trees as well as milestone trees for Fedora composes. the nightly compose process also installs the trees into cloud and vagrant images. the same atomic images we have in Fedora 22 on. Dennis signature.asc Description: This is a digitally signed message part. ___ cloud mailing list cloud@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Atomic 2 week releases
On 03/10/2015 06:37 PM, Josh Boyer wrote: > > I know Stephen is working on how Spins and other non-Edition images > are dealt with, and the Council is very interested in this as well. > That isn't in place yet, and to be honest I would be surprised if it > was for F22 at all. Perhaps Atomic has enough momentum that a change > here won't matter, but it is at least something everyone should be > aware of. Thanks for the note. It's definitely worth considering from that angle. We can promote Fedora Atomic Host from Project Atomic as well, but I've no illusions that Project Atomic is as visible as Fedora. Definitely something to consider, thanks! Best, jzb -- Joe Brockmeier | Principal Cloud & Storage Analyst j...@redhat.com | http://community.redhat.com/ Twitter: @jzb | http://dissociatedpress.net/ signature.asc Description: OpenPGP digital signature ___ cloud mailing list cloud@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Atomic 2 week releases
On Wed, Mar 11, 2015, at 10:52 AM, Dennis Gilmore wrote: > > This is not entirely true, it is just part of the picture. You can install on > bare metal using anaconda with extlinux, exactly the same as we do to make > the > cloud image. But it is not advertised or really well documented. But that won't get you the partitioning defaults if used interactively, which is an important part of Atomic. This is https://github.com/projectatomic/fedora-productimg-atomic That and having the content embedded so that it can install offline. These are the current two reasons that Atomic needs a separate installer ISO build. ___ cloud mailing list cloud@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Atomic 2 week releases
On 03/09/2015 12:03 PM, Michael P. McGrath wrote: > - Original Message - >> From: "Daniel J Walsh" >> To: "Fedora Cloud SIG" >> Sent: Monday, March 9, 2015 10:45:42 AM >> Subject: Re: Atomic 2 week releases >> >> >> On 03/09/2015 11:34 AM, Michael P. McGrath wrote: >>> Hey all, I wanted to start a thread about doing more frequent Atomic >>> releases in Fedora. >>> In particular I'd like to start building a new atomic release every two >>> weeks that >>> includes the latest version of Docker, Kubernetes, and OSTree for the >>> Fedora Atomic >>> images. >>> >>> The problem I'm trying to solve here is that there is a lot of work going >>> on upstream in >>> the Docker and Kubernetes communities and there isn't a very good way to >>> consume that >>> upstream work on a Red Hat/Fedora/CentOS system today. By focusing on more >>> regular >>> releases, we can fix some of the issues we've seen (like demoing new >>> features at a >>> conference that people can't actually use). >>> >>> There are still some details to work out like whether to base this image on >>> Fedora >>> $CURRENT or rawhide and what to do when the builds fail. Fortunately, this >>> can possibly >>> be done without much additional change to the release process. We're >>> already rebuilding >>> the docker/kubernetes/ostree rpms almost daily, and there are nightly >>> builds as well >>> (at least in rawhide). >>> >>> If we can pull a 2 week process off, I'd like to see that followed by a 4 >>> week process >>> in CentOS which will behave similarly but with the slightly slower-moving, >>> more stable bits. >>> >>> Thoughts? >>> >>> [1] http://www.projectatomic.io/download/ >>> >>> -- >>> Mike McGrath | mmcgr...@redhat.com | (312) 660-3547 >>> Atomic | Red Hat Chicago | http://projectatomic.io/ >>> ___ >>> cloud mailing list >>> cloud@lists.fedoraproject.org >>> https://admin.fedoraproject.org/mailman/listinfo/cloud >>> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct >> I guess the question here would be around where we would do the releases? >> >> In a perfect world, I would like to see "Daily" releases in Rawhide, as >> long was we had an installable >> tree. Every two weeks would be in Fedora Stable. If others wanted to >> back port to Fedora Stable-1 >> that would be ok, but I don't see that as the primary focus. >> >> We would be doing a lot of this with the Docker Devel branch, along with >> some patches that we are experimenting >> with. >> >> I am sure K8s would be doing something similar. >> > What version of docker would be in Fedora $CURRENT? stable or devel? And > would that version go out to both Atomic Fedora *and* regular Fedora users > or just Atomic Fedora? > > -Mike Those are the questions I would like to have answered. >> ___ >> cloud mailing list >> cloud@lists.fedoraproject.org >> https://admin.fedoraproject.org/mailman/listinfo/cloud >> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct >> > ___ > cloud mailing list > cloud@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/cloud > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct ___ cloud mailing list cloud@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Atomic 2 week releases
On Mon, Mar 9, 2015 at 5:35 PM, M. Edward (Ed) Borasky wrote: > On Mon, Mar 9, 2015 at 8:34 AM, Michael P. McGrath > wrote: >> Hey all, I wanted to start a thread about doing more frequent Atomic >> releases in Fedora. >> In particular I'd like to start building a new atomic release every two >> weeks that >> includes the latest version of Docker, Kubernetes, and OSTree for the Fedora >> Atomic >> images. >> >> The problem I'm trying to solve here is that there is a lot of work going on >> upstream in >> the Docker and Kubernetes communities and there isn't a very good way to >> consume that >> upstream work on a Red Hat/Fedora/CentOS system today. By focusing on more >> regular >> releases, we can fix some of the issues we've seen (like demoing new >> features at a >> conference that people can't actually use). > > > IMHO RHEL/CentOS have got to be solid / stable / secure, etc. > Documented, tested, ready to build *production* services upon. > Training, professional certification - the works! > > Docker may be there - I've only played with it for about six months > and aside from some annoying SELinux phenomena, it seems to be good > and it's definitely popular. > > But Atomic and Kubernetes? Where's the documentation? "Use the source, > Luke" is not an acceptable answer. > > So please ... have at it in Fedora, I'll be a willing guinea pig and > all that. But RHEL/CentOS? Please wait till it has some mileage on it > in Fedora. > I think the proposal here isn't to impede directly on any of these distribution's core releases but instead to add an Atomic Release. Effectively what is currently available will continue to be available exactly as it is, but if you are interested in releases of these distros based on the upstream Atomic toolset, this is the proposed release cadence for it. -AdamM > ___ > cloud mailing list > cloud@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/cloud > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct ___ cloud mailing list cloud@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Atomic 2 week releases
On Tue, Mar 10, 2015 at 01:09:16PM -0400, Michael P. McGrath wrote: > Stable in current, devel in rawhide. We just don't yet have the toolchains to > split different versions of our packages onto the same Fedora. We'll have to > see if there's a way to do it when Adam joins up. If it turns out to be important, we could also consider one of: 1. Versioned packages! http://fedoraproject.org/wiki/Packaging:NamingGuidelines#MultiplePackages This'd be a little easier if the stable version numbers lasted a long time. Possibly we could get an exception and carry something like 'docker-dev' as a sparate package. I don't think we'd want to do this for whole stacks, though. 2. Software collections. This is *so close* to being an actual thing, and it _might_ be a way. But I think that if we do need things to go at a separate cadence, rpm-ostree gives us a helpful layer of separation, because if we had a side tag in koji or even a whole new repo meant to be layered, those wouldn't need to be enabled on anyone's actual system — just for ostree compose. That's probably getting ahead of things here, though. :) -- Matthew Miller Fedora Project Leader ___ cloud mailing list cloud@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Atomic 2 week releases
On 03/10/2015 09:20 PM, Michael P. McGrath wrote: > Fedora in particular will have their > rawhide and stable releases promoted differently on the Fedora sites and > the project atomic page will likely promote things a little differently > and that is probably Ok as long as everyone ultimately has a choice to > download whatever they want. I think the promotion part is largely just > a way to direct people who otherwise don't know how to make an informed > decision. If we don't have a unified story between Project Atomic and Fedora w/r/t what to download and what we think people "should" use, it's going to be confusing. I'm very concerned that an Atomic that conforms to the normal Fedora release cycle + a fast-moving Fedora-based Atomic from Project Atomic is going to be a messaging nightmare. Some people's entry point to the discussion is via Project Atomic, some enter via Fedora - and then of course we get people coming from third parties who are writing about Project Atomic for a variety of reasons and with a varying level of understanding about what Atomic is. We've seen people just assume "oh, there's a CentOS build that says Atomic, it *must* be a rebuild of RHEL Atomic" (which is wrong) and come away disappointed. Assuming we'll be OK as "everyone has a choice to download what they want" may be overly optimistic here. The more I think about this, the more I think we really need a unified story rather than having two separate entry paths to Atomic for Fedora. > On the Project Atomic side I'm mostly concerned with the emerging tech. > Getting new features in front of people as soon as possible. In the > short term, Fedora rawhide really is the only place to do that. Longer term > though there is a desire to base the Atomic dependent packages (docker, > kubernetes, etcd, ostree, etc.) on something more stable. -- Joe Brockmeier | Project Atomic Doer of Things j...@redhat.com | http://projectatomic.io Twitter: @jzb | http://dissociatedpress.net/ signature.asc Description: OpenPGP digital signature ___ cloud mailing list cloud@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Atomic 2 week releases
- Original Message - > From: "Joe Brockmeier" > To: cloud@lists.fedoraproject.org > Sent: Friday, March 13, 2015 12:55:51 PM > Subject: Re: Atomic 2 week releases > > On 03/10/2015 09:20 PM, Michael P. McGrath wrote: > > Fedora in particular will have their > > rawhide and stable releases promoted differently on the Fedora sites and > > the project atomic page will likely promote things a little differently > > and that is probably Ok as long as everyone ultimately has a choice to > > download whatever they want. I think the promotion part is largely just > > a way to direct people who otherwise don't know how to make an informed > > decision. > > If we don't have a unified story between Project Atomic and Fedora w/r/t > what to download and what we think people "should" use, it's going to be > confusing. I'm very concerned that an Atomic that conforms to the normal > Fedora release cycle + a fast-moving Fedora-based Atomic from Project > Atomic is going to be a messaging nightmare. > > Some people's entry point to the discussion is via Project Atomic, some > enter via Fedora - and then of course we get people coming from third > parties who are writing about Project Atomic for a variety of reasons > and with a varying level of understanding about what Atomic is. We've > seen people just assume "oh, there's a CentOS build that says Atomic, it > *must* be a rebuild of RHEL Atomic" (which is wrong) and come away > disappointed. > > Assuming we'll be OK as "everyone has a choice to download what they > want" may be overly optimistic here. > > The more I think about this, the more I think we really need a unified > story rather than having two separate entry paths to Atomic for Fedora. > Perhaps I'm missing something then. Is there something specific to Fedora that you're concerned about that somehow we can ignore with CentOS and RHEL Atomic Host? I would think we'd need to align as best as we can with all of our communities. The messaging seems pretty simple to me and properly aligned with the communities. Fedora = Newest CentOS = Stable RHEL = Supported I get that there are several offerings that Fedora has, I don't feel compelled to list them all on projectatomic.io to people who likely won't have the information to make an informed decision anyway. We pick one for them, give a few word description on what it is, and set them loose. -Mike > > On the Project Atomic side I'm mostly concerned with the emerging tech. > > Getting new features in front of people as soon as possible. In the > > short term, Fedora rawhide really is the only place to do that. Longer > > term > > though there is a desire to base the Atomic dependent packages (docker, > > kubernetes, etcd, ostree, etc.) on something more stable. > > > -- > Joe Brockmeier | Project Atomic Doer of Things > j...@redhat.com | http://projectatomic.io > Twitter: @jzb | http://dissociatedpress.net/ > > > ___ > cloud mailing list > cloud@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/cloud > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct > ___ cloud mailing list cloud@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Atomic 2 week releases
On 03/13/2015 02:04 PM, Michael P. McGrath wrote: > I get that there are several offerings that Fedora has, I don't feel > compelled to list them all on projectatomic.io to people who likely won't > have the information to make an informed decision anyway. We pick one > for them, give a few word description on what it is, and set them loose. But people will find the Fedora offerings through other channels, then wind up on ProjectAtomic and wonder why the documentation there doesn't fit what they have (as one example). I'm not arguing against the alignment of Fedora == newest, CentOS == stable, RHEL == Supported. I'm saying I think it would benefit us all to align on one Atomic offering from Fedora rather than having competing Fedora-based offerings that are going to be misunderstood / hard to clarify. (Not to mention dilute efforts w/r/t testing and promotion between Fedora and Project Atomic.) Best, jzb -- Joe Brockmeier | Project Atomic Doer of Things j...@redhat.com | http://community.redhat.com/ Twitter: @jzb | http://dissociatedpress.net/ signature.asc Description: OpenPGP digital signature ___ cloud mailing list cloud@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Atomic 2 week releases
- Original Message - > From: "Joe Brockmeier" > To: "Michael P. McGrath" , "Fedora Cloud SIG" > > Sent: Friday, March 13, 2015 1:16:41 PM > Subject: Re: Atomic 2 week releases > > On 03/13/2015 02:04 PM, Michael P. McGrath wrote: > > I get that there are several offerings that Fedora has, I don't feel > > compelled to list them all on projectatomic.io to people who likely won't > > have the information to make an informed decision anyway. We pick one > > for them, give a few word description on what it is, and set them loose. > > But people will find the Fedora offerings through other channels, then > wind up on ProjectAtomic and wonder why the documentation there doesn't > fit what they have (as one example). > > I'm not arguing against the alignment of Fedora == newest, CentOS == > stable, RHEL == Supported. I'm saying I think it would benefit us all to > align on one Atomic offering from Fedora rather than having competing > Fedora-based offerings that are going to be misunderstood / hard to > clarify. > Perhaps we're already aligned then. What would Fedora pick as its 'best' Atomic release and how often does it get released? -Mike > (Not to mention dilute efforts w/r/t testing and promotion between > Fedora and Project Atomic.) > > Best, > > jzb > -- > Joe Brockmeier | Project Atomic Doer of Things > j...@redhat.com | http://community.redhat.com/ > Twitter: @jzb | http://dissociatedpress.net/ > > ___ cloud mailing list cloud@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Atomic 2 week releases
On 03/13/2015 02:20 PM, Michael P. McGrath wrote: > Perhaps we're already aligned then. What would Fedora pick as its 'best' > Atomic release and how often does it get released? Not exclusively my call, of course, but I would choose the rapid-release version over a version that follows the standard Fedora release cycle. That is, of course, if we can consistently produce an Atomic host that is usable without serious breakage. We are on the hook for an Atomic Host release for F22, but I think I'd rather message why we're putting our weight behind a rapid-release host based on Fedora than dealing with two competing Fedora-based offerings. Best, jzb -- Joe Brockmeier | Project Atomic Doer of Things j...@redhat.com | http://community.redhat.com/ Twitter: @jzb | http://dissociatedpress.net/ signature.asc Description: OpenPGP digital signature ___ cloud mailing list cloud@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Atomic 2 week releases
On Fri, Mar 13, 2015 at 02:26:42PM -0400, Joe Brockmeier wrote: > We are on the hook for an Atomic Host release for F22, but I think I'd > rather message why we're putting our weight behind a rapid-release host > based on Fedora than dealing with two competing Fedora-based offerings. Has the spinner deciding whether the rapid-release host will be based on Rawhide or on $current come to a definitive rest yet? If the focus is on Rawhide, and we don't have interest / resources in keeping the $current branch up to date, I share Joe's concern — not just for confusion due to too many options, but also because in that case $current would almost always be the wrong choice (lagging CentOS and even RHEL). I think this would weigh heavily towards presenting that rawhide-based output on its own atomic.fpo home, because if $current is really going to be $outofdate, new users _will_ inevitably get the wrong thing. If development is done in Rawhide but also released to $current on a two-week cycle, I might have other worries, but this wouldn't be one of them. :) -- Matthew Miller Fedora Project Leader ___ cloud mailing list cloud@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Atomic 2 week releases
On 03/13/2015 02:58 PM, Matthew Miller wrote: > On Fri, Mar 13, 2015 at 02:26:42PM -0400, Joe Brockmeier wrote: >> We are on the hook for an Atomic Host release for F22, but I think I'd >> rather message why we're putting our weight behind a rapid-release host >> based on Fedora than dealing with two competing Fedora-based offerings. > Has the spinner deciding whether the rapid-release host will be based > on Rawhide or on $current come to a definitive rest yet? > > If the focus is on Rawhide, and we don't have interest / resources in > keeping the $current branch up to date, I share Joe's concern — not > just for confusion due to too many options, but also because in that > case $current would almost always be the wrong choice (lagging CentOS > and even RHEL). I think this would weigh heavily towards presenting > that rawhide-based output on its own atomic.fpo home, because if > $current is really going to be $outofdate, new users _will_ inevitably > get the wrong thing. > > If development is done in Rawhide but also released to $current on a > two-week cycle, I might have other worries, but this wouldn't be one of > them. :) > > Apologies for joining in late folks. I'd like to summarize (I hope) a few points that have been made in this thread and in a handful of side-conversations. If we want something that is able to be consistently released every two weeks, we will likely struggle with rawhide. Although we all want rawhide to be usable day to day, it is not guaranteed to be stable and/or able to be built. We, the Atomic team, are in no position to either A) force it to be stable or B) apply even more effort as part of Atomic beyond the core work to ensure that rawhide stabilizes every two weeks. So this pushes us in the $current direction. The primary concern with $current is that Atomic may, for a narrow set of core packages, wish to run slightly ahead of what is in updates-stable for $current. However, I think this is more of a hypothetical/future concern at the moment. The core elements (docker, kubernetes, and rpm-ostree/ostree) are being pushed out to updates-testing (and our CentOS CBS builds) pretty rapidly. If we have a problem, it's that they are not being tested and/or promoted. So, two concrete options to consider: * Option 1 We target our 2 week release efforts at $current, which should involve a greater focus on testing and karma-ing the Atomic components as they show up in updates-testing. This gets us the stable base and gets non-Atomic $current users a nice flow of updates to popular and topical packages. And, at the risk of stating the obvious, this in no way prevents rawhide Atomic spins. The road to updates-testing passes through rawhide and the rawhide nightly compose, AIUI, already includes attempts at Atomic tree composes and Atomic images builds. * Option 2 If at some point we feel we must carry some Atomic-focused updates that are not appropriate for $current, we maintain a very small side-tag to hold them. This is essentially what we are already doing for CentOS in the "atomic7-testing" tag on the CBS koji instance here: http://cbs.centos.org/koji/taginfo?tagID=40 Who exactly manages this tag and how content is promoted into it is TBD. I personally think we should at least try Option 1 with 2 as a fallback. Thoughts? -Ian ___ cloud mailing list cloud@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Atomic 2 week releases
- Original Message - > From: "Ian McLeod" > To: cloud@lists.fedoraproject.org > Sent: Friday, March 13, 2015 4:08:46 PM > Subject: Re: Atomic 2 week releases > > > On 03/13/2015 02:58 PM, Matthew Miller wrote: > > On Fri, Mar 13, 2015 at 02:26:42PM -0400, Joe Brockmeier wrote: > >> We are on the hook for an Atomic Host release for F22, but I think I'd > >> rather message why we're putting our weight behind a rapid-release host > >> based on Fedora than dealing with two competing Fedora-based offerings. > > Has the spinner deciding whether the rapid-release host will be based > > on Rawhide or on $current come to a definitive rest yet? > > > > If the focus is on Rawhide, and we don't have interest / resources in > > keeping the $current branch up to date, I share Joe's concern — not > > just for confusion due to too many options, but also because in that > > case $current would almost always be the wrong choice (lagging CentOS > > and even RHEL). I think this would weigh heavily towards presenting > > that rawhide-based output on its own atomic.fpo home, because if > > $current is really going to be $outofdate, new users _will_ inevitably > > get the wrong thing. > > > > If development is done in Rawhide but also released to $current on a > > two-week cycle, I might have other worries, but this wouldn't be one of > > them. :) > > > > > Apologies for joining in late folks. I'd like to summarize (I hope) a few > points that have been made in this thread and in a handful of > side-conversations. > > If we want something that is able to be consistently released every two > weeks, we will likely struggle with rawhide. Although we all want rawhide > to be usable day to day, it is not guaranteed to be stable and/or able to be > built. We, the Atomic team, are in no position to either A) force it to be > stable or B) apply even more effort as part of Atomic beyond the core work > to ensure that rawhide stabilizes every two weeks. > > So this pushes us in the $current direction. > > The primary concern with $current is that Atomic may, for a narrow set of > core packages, wish to run slightly ahead of what is in updates-stable for > $current. However, I think this is more of a hypothetical/future concern at > the moment. The core elements (docker, kubernetes, and rpm-ostree/ostree) > are being pushed out to updates-testing (and our CentOS CBS builds) pretty > rapidly. If we have a problem, it's that they are not being tested and/or > promoted. > > So, two concrete options to consider: > > * Option 1 > > We target our 2 week release efforts at $current, which should involve a > greater focus on testing and karma-ing the Atomic components as they show up > in updates-testing. > > This gets us the stable base and gets non-Atomic $current users a nice flow > of updates to popular and topical packages. > > And, at the risk of stating the obvious, this in no way prevents rawhide > Atomic spins. The road to updates-testing passes through rawhide and the > rawhide nightly compose, AIUI, already includes attempts at Atomic tree > composes and Atomic images builds. > So the Atomic spins would be $current + the updates-testing packages we care about (and have tested / have some influence over). That spin would then be copied to the mirrors and we'd be able to link to it. There's a nice side benefit there which is if someone who's running non-atomic Fedora wants to look at the latest of docker, kubernetes, etcd, ostree, whatever, they could just enable updates-testing and have access. Sounds like all of the benefits of the original rawhide suggestion with none of the pain. > * Option 2 > > If at some point we feel we must carry some Atomic-focused updates that are > not appropriate for $current, we maintain a very small side-tag to hold > them. This is essentially what we are already doing for CentOS in the > "atomic7-testing" tag on the CBS koji instance here: > > http://cbs.centos.org/koji/taginfo?tagID=40 > > Who exactly manages this tag and how content is promoted into it is TBD. > > I personally think we should at least try Option 1 with 2 as a fallback. > > Thoughts? > +1 to at least trying option 1. -Mike > -Ian > > ___ > cloud mailing list > cloud@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/cloud > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct > ___ cloud mailing list cloud@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Atomic 2 week releases
On Fri, Mar 13, 2015, at 05:13 PM, Michael P. McGrath wrote: > > So the Atomic spins would be $current + the updates-testing packages we > care about (and have tested / have some influence over). That spin > would then be copied to the mirrors and we'd be able to link to it. > > There's a nice side benefit there which is if someone who's running non-atomic > Fedora wants to look at the latest of docker, kubernetes, etcd, ostree, > whatever, they could just enable updates-testing and have access. > > Sounds like all of the benefits of the original rawhide suggestion with > none of the pain. Yeah. We can do much better than we are now at just running through the current official process. Also, rather crucially there are no trademark concerns with images generated from updates-testing or just updates. I'd still like to experiment with a side repo implementing continuous delivery and actually making use of the fact that both Docker and ostree allow rollbacks and are by their nature more agile - will post more about that later. But option #1 here has my vote for now - it's a matter of trying it for a few months or so, we can always re-evaluate. ___ cloud mailing list cloud@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Atomic 2 week releases
On Fri, Mar 13, 2015 at 05:13:29PM -0400, Michael P. McGrath wrote: > - Original Message - > > From: "Ian McLeod" > > To: cloud@lists.fedoraproject.org > > Sent: Friday, March 13, 2015 4:08:46 PM > > Subject: Re: Atomic 2 week releases > > > > > > On 03/13/2015 02:58 PM, Matthew Miller wrote: > > > On Fri, Mar 13, 2015 at 02:26:42PM -0400, Joe Brockmeier wrote: > > >> We are on the hook for an Atomic Host release for F22, but I think I'd > > >> rather message why we're putting our weight behind a rapid-release host > > >> based on Fedora than dealing with two competing Fedora-based offerings. > > > Has the spinner deciding whether the rapid-release host will be based > > > on Rawhide or on $current come to a definitive rest yet? > > > > > > If the focus is on Rawhide, and we don't have interest / resources in > > > keeping the $current branch up to date, I share Joe's concern — not > > > just for confusion due to too many options, but also because in that > > > case $current would almost always be the wrong choice (lagging CentOS > > > and even RHEL). I think this would weigh heavily towards presenting > > > that rawhide-based output on its own atomic.fpo home, because if > > > $current is really going to be $outofdate, new users _will_ inevitably > > > get the wrong thing. > > > > > > If development is done in Rawhide but also released to $current on a > > > two-week cycle, I might have other worries, but this wouldn't be one of > > > them. :) > > > > > > > > Apologies for joining in late folks. I'd like to summarize (I hope) a few > > points that have been made in this thread and in a handful of > > side-conversations. > > > > If we want something that is able to be consistently released every two > > weeks, we will likely struggle with rawhide. Although we all want rawhide > > to be usable day to day, it is not guaranteed to be stable and/or able to be > > built. We, the Atomic team, are in no position to either A) force it to be > > stable or B) apply even more effort as part of Atomic beyond the core work > > to ensure that rawhide stabilizes every two weeks. > > > > So this pushes us in the $current direction. > > > > The primary concern with $current is that Atomic may, for a narrow set of > > core packages, wish to run slightly ahead of what is in updates-stable for > > $current. However, I think this is more of a hypothetical/future concern at > > the moment. The core elements (docker, kubernetes, and rpm-ostree/ostree) > > are being pushed out to updates-testing (and our CentOS CBS builds) pretty > > rapidly. If we have a problem, it's that they are not being tested and/or > > promoted. > > > > So, two concrete options to consider: > > > > * Option 1 > > > > We target our 2 week release efforts at $current, which should involve a > > greater focus on testing and karma-ing the Atomic components as they show up > > in updates-testing. > > > > This gets us the stable base and gets non-Atomic $current users a nice flow > > of updates to popular and topical packages. > > > > And, at the risk of stating the obvious, this in no way prevents rawhide > > Atomic spins. The road to updates-testing passes through rawhide and the > > rawhide nightly compose, AIUI, already includes attempts at Atomic tree > > composes and Atomic images builds. > > > > So the Atomic spins would be $current + the updates-testing packages we > care about (and have tested / have some influence over). That spin > would then be copied to the mirrors and we'd be able to link to it. > > There's a nice side benefit there which is if someone who's running non-atomic > Fedora wants to look at the latest of docker, kubernetes, etcd, ostree, > whatever, they could just enable updates-testing and have access. > > Sounds like all of the benefits of the original rawhide suggestion with > none of the pain. > > > * Option 2 > > > > If at some point we feel we must carry some Atomic-focused updates that are > > not appropriate for $current, we maintain a very small side-tag to hold > > them. This is essentially what we are already doing for CentOS in the > > "atomic7-testing" tag on the CBS koji instance here: > > > > http://cbs.centos.org/koji/taginfo?tagID=40 > > > > Who exactly manages this tag and how content is promoted into it is TBD. > > > > I personally think we
Re: Atomic 2 week releases
On 03/13/2015 04:13 PM, Michael P. McGrath wrote: > - Original Message - >> From: "Ian McLeod" >> To: cloud@lists.fedoraproject.org >> Sent: Friday, March 13, 2015 4:08:46 PM >> Subject: Re: Atomic 2 week releases >> >> >> On 03/13/2015 02:58 PM, Matthew Miller wrote: >>> On Fri, Mar 13, 2015 at 02:26:42PM -0400, Joe Brockmeier wrote: >>>> We are on the hook for an Atomic Host release for F22, but I think I'd >>>> rather message why we're putting our weight behind a rapid-release host >>>> based on Fedora than dealing with two competing Fedora-based offerings. >>> Has the spinner deciding whether the rapid-release host will be based >>> on Rawhide or on $current come to a definitive rest yet? >>> >>> If the focus is on Rawhide, and we don't have interest / resources in >>> keeping the $current branch up to date, I share Joe's concern — not >>> just for confusion due to too many options, but also because in that >>> case $current would almost always be the wrong choice (lagging CentOS >>> and even RHEL). I think this would weigh heavily towards presenting >>> that rawhide-based output on its own atomic.fpo home, because if >>> $current is really going to be $outofdate, new users _will_ inevitably >>> get the wrong thing. >>> >>> If development is done in Rawhide but also released to $current on a >>> two-week cycle, I might have other worries, but this wouldn't be one of >>> them. :) >>> >>> >> Apologies for joining in late folks. I'd like to summarize (I hope) a few >> points that have been made in this thread and in a handful of >> side-conversations. >> >> If we want something that is able to be consistently released every two >> weeks, we will likely struggle with rawhide. Although we all want rawhide >> to be usable day to day, it is not guaranteed to be stable and/or able to be >> built. We, the Atomic team, are in no position to either A) force it to be >> stable or B) apply even more effort as part of Atomic beyond the core work >> to ensure that rawhide stabilizes every two weeks. >> >> So this pushes us in the $current direction. >> >> The primary concern with $current is that Atomic may, for a narrow set of >> core packages, wish to run slightly ahead of what is in updates-stable for >> $current. However, I think this is more of a hypothetical/future concern at >> the moment. The core elements (docker, kubernetes, and rpm-ostree/ostree) >> are being pushed out to updates-testing (and our CentOS CBS builds) pretty >> rapidly. If we have a problem, it's that they are not being tested and/or >> promoted. >> >> So, two concrete options to consider: >> >> * Option 1 >> >> We target our 2 week release efforts at $current, which should involve a >> greater focus on testing and karma-ing the Atomic components as they show up >> in updates-testing. >> >> This gets us the stable base and gets non-Atomic $current users a nice flow >> of updates to popular and topical packages. >> >> And, at the risk of stating the obvious, this in no way prevents rawhide >> Atomic spins. The road to updates-testing passes through rawhide and the >> rawhide nightly compose, AIUI, already includes attempts at Atomic tree >> composes and Atomic images builds. >> > So the Atomic spins would be $current + the updates-testing packages we > care about (and have tested / have some influence over). That spin > would then be copied to the mirrors and we'd be able to link to it. Actually, the idea is that Atomic spins would be $current + updates (not testing), coupled with "updates" being more actively and aggressively managed by those involved with Atomic. > > There's a nice side benefit there which is if someone who's running non-atomic > Fedora wants to look at the latest of docker, kubernetes, etcd, ostree, > whatever, they could just enable updates-testing and have access. > > Sounds like all of the benefits of the original rawhide suggestion with > none of the pain. > >> * Option 2 >> >> If at some point we feel we must carry some Atomic-focused updates that are >> not appropriate for $current, we maintain a very small side-tag to hold >> them. This is essentially what we are already doing for CentOS in the >> "atomic7-testing" tag on the CBS koji instance here: >> >> http://cbs.centos.org/koji/taginfo?tagID=40 >> >> Who exactly manages this tag and how content is promoted into it is TBD. >> >> I personally think we should at least try Option 1 with 2 as a fallback. >> >> Thoughts? >> > +1 to at least trying option 1. > > -Mike > >> -Ian >> >> ___ >> cloud mailing list >> cloud@lists.fedoraproject.org >> https://admin.fedoraproject.org/mailman/listinfo/cloud >> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct >> ___ cloud mailing list cloud@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Atomic 2 week releases
On Fri, Mar 13, 2015 at 04:35:45PM -0500, Ian McLeod wrote: > > So the Atomic spins would be $current + the updates-testing > > packages we care about (and have tested / have some influence > > over). That spin would then be copied to the mirrors and we'd be > > able to link to it. > Actually, the idea is that Atomic spins would be $current + updates > (not testing), coupled with "updates" being more actively and > aggressively managed by those involved with Atomic. As I understand it, the concern here was possible wish for changes in something not part of the collection of software unique to Atomic. That is, if kubernetes needs to be updated, that's probably no big deal because at least as of now, Atomic is the main reason it's in the distro at all. And of course that's even more so for rpm-ostree and the `atomic` command itself. But it's a little less true for Docker, which is also important for developer workstations and possibly for Fedora Server. The other examples I've heard are the kernel and systemd — possibly some new features would be desired. I think the kernel is actually no problem here: the Fedora kernel team has a policy of following upstream closely, even updating in the $current and $current-1 releases. However, it's more unclear with systemd, and if newer systemd features are needed in $current we'll need to work closely with the systemd team. I don't think that will be a problem (and particularly, I think the systemd update example is mostly theoretical, right?), but it's definitely something to plan for _before_ we end up in a corner. -- Matthew Miller Fedora Project Leader ___ cloud mailing list cloud@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Atomic 2 week releases
On 13/03/15, Colin Walters wrote: > On Fri, Mar 13, 2015, at 05:13 PM, Michael P. McGrath wrote: > Yeah. We can do much better than we are now at just running through the > current > official process. Also, rather crucially there are no trademark concerns with > images generated from updates-testing or just updates. > > I'd still like to experiment with a side repo implementing continuous delivery > and actually making use of the fact that both Docker and ostree allow > rollbacks > and are by their nature more agile - will post more about that later. But > option #1 > here has my vote for now - it's a matter of trying it for a few months or so, > we > can always re-evaluate. I have a new tool available called Tunir[1] , which can be used to test the updated atomic images automatically. I already the Fedora test cases[2] running in Tunir. [1] http://kushaldas.in/posts/tunir-a-simple-ci-with-less-pain.html [2] https://github.com/kushaldas/tunirtests Kushal -- Fedora Cloud Engineer CPython Core Developer Director @ Python Software Foundation http://kushaldas.in ___ cloud mailing list cloud@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Atomic 2 week releases
[ Resurrecting, adding atomic-devel CC ] On Mon, Mar 9, 2015, at 11:34 AM, Michael P. McGrath wrote: > Hey all, I wanted to start a thread about doing more frequent Atomic releases > in Fedora. > In particular I'd like to start building a new atomic release every two weeks > that > includes the latest version of Docker, Kubernetes, and OSTree for the Fedora > Atomic > images. Most people in this thread seemed to be in favor of Atomic Host as a spin. Now, I use the word "Host" specifically here because I think it's important to distinguish Atomic Host from the "docker + kubernetes as RPMs" set. We should be able to get RPMs through Bodhi. (See https://lists.projectatomic.io/projectatomic-archives/atomic-devel/2015-April/msg00013.html on that topic) But we need to more fully flesh out the ramifications of a Host move out. It would mean: - Dropping the (currently rather minimal) OSTree repo + cloud image from mainline rel-eng - Standing up more regular code drops in https://alt.fedoraproject.org/pub/alt/fedora-atomic/images/f22/ (But if we do do this I'd like to keep open communication channels such that some or all parts of Atomic Host could be more integrated with "mainline" in the future) I mentioned this before, but a critical hinge point is whether the tree + images are entirely composed of RPMs built in Fedora. AIUI for example, if we had a COPR (or whatever) with a more bleeding edge Docker[0], or carried a patched systemd temporarily[1], I believe that would run afoul of: https://fedoraproject.org/wiki/Legal:Trademark_guidelines?rd=Legal/TrademarkGuidelines#Virtual_images_or_appliances_with_combinations_of_Fedora_software_with_non-Fedora_or_modified_Fedora_software ...at least, I assumed so offhand, but reading it, in that page "Fedora software" isn't defined - does COPR count or not? Anyways...my bottom line here is that it feels really weird to me to fight all the way for F22 and sustain that only to split it out after. It's a lot simpler to say F21 was our first try, we learned some things, but a lot more work needs to be done, it'll be faster to iterate outside and then merge back when it's ready, which may be F23 or whatever. [0] OSTree was born to do continuous delivery, and the fact that it's wedged after the slow, plodding, conservative mainline koji + "daily build" + bodhi IMO weakens its value a lot. We could also be a lot more aggressive with updates to the RPMs that go into Docker containers - if some http library breaks it may just affect your app and not the host, etc. [1] https://bugzilla.redhat.com/show_bug.cgi?id=1197204 ___ cloud mailing list cloud@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Atomic 2 week releases
On Tue, Apr 07, 2015 at 09:43:13PM -0400, Colin Walters wrote: > Anyways...my bottom line here is that it feels really weird to me to fight all > the way for F22 and sustain that only to split it out after. It's a lot > simpler > to say F21 was our first try, we learned some things, but a lot more work > needs to be done, it'll be faster to iterate outside and then merge back > when it's ready, which may be F23 or whatever. This is a straightforward narrative — which, as my mind turns to towards press and interviews around the F22 release, is kind of what I'm focused on. I need a good story. :) -- Matthew Miller Fedora Project Leader ___ cloud mailing list cloud@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Atomic 2 week releases
On 04/07/2015 09:43 PM, Colin Walters wrote: > [ Resurrecting, adding atomic-devel CC ] > > On Mon, Mar 9, 2015, at 11:34 AM, Michael P. McGrath wrote: >> Hey all, I wanted to start a thread about doing more frequent Atomic >> releases in Fedora. >> In particular I'd like to start building a new atomic release every two >> weeks that >> includes the latest version of Docker, Kubernetes, and OSTree for the Fedora >> Atomic >> images. > > Most people in this thread seemed to be in favor of Atomic Host as a spin. > Now, > I use the word "Host" specifically here because I think it's important to > distinguish Atomic Host > from the "docker + kubernetes as RPMs" set. We should be able > to get RPMs through Bodhi. > > (See > https://lists.projectatomic.io/projectatomic-archives/atomic-devel/2015-April/msg00013.html > on that topic) > > But we need to more fully flesh out the ramifications of a Host move out. It > would mean: > > - Dropping the (currently rather minimal) OSTree repo + cloud image from > mainline rel-eng > - Standing up more regular code drops in > https://alt.fedoraproject.org/pub/alt/fedora-atomic/images/f22/ Correct. > (But if we do do this I'd like to keep open communication channels such that > some or > all parts of Atomic Host could be more integrated with "mainline" in the > future) Absolutely. My intent here is not to never again offer an Atomic Host (or some other variant that uses rpm-ostree) as a Fedora Cloud (or Server) edition - but to let us Move Fast And Break Things outside the usual Fedora release cycle. The bottom line for me is that we are pushing out new things too quickly for them to fit well w/in the usual release criteria for Fedora. > I mentioned this before, but a critical hinge point is whether the tree + > images are > entirely composed of RPMs built in Fedora. AIUI for example, if we had a COPR > (or whatever) with a more bleeding edge Docker[0], or carried a patched > systemd > temporarily[1], I believe that would run afoul of: > https://fedoraproject.org/wiki/Legal:Trademark_guidelines?rd=Legal/TrademarkGuidelines#Virtual_images_or_appliances_with_combinations_of_Fedora_software_with_non-Fedora_or_modified_Fedora_software > > ...at least, I assumed so offhand, but reading it, in that page > "Fedora software" isn't defined - does COPR count or not? Copr doesn't count. Talked to Tom Callaway about this briefly just now and basically - it must be built in Koji to be part of a Spin, unless we get an exception. One possible way around this would be to build packages in Koji that are named slightly differently or have versions (e.g. "docker-1.6" instead of just "docker" or maybe even "docker-atomic") but that might be a heck of a lot of hassle. > Anyways...my bottom line here is that it feels really weird to me to fight all > the way for F22 and sustain that only to split it out after. It's a lot > simpler > to say F21 was our first try, we learned some things, but a lot more work > needs to be done, it'll be faster to iterate outside and then merge back > when it's ready, which may be F23 or whatever. I think we agree there? Except I'm thinking the merge back would be more w/in the F25 timeline - I don't expect Docker, Kubernetes, etc. to really slow down for the next 12-18 months. > [0] OSTree was born to do continuous delivery, and the fact that it's wedged > after the slow, plodding, conservative mainline koji + "daily build" + > bodhi > IMO weakens its value a lot. We could also be a lot more aggressive > with updates to the RPMs that go into Docker containers - if some http > library > breaks it may just affect your app and not the host, etc. > [1] https://bugzilla.redhat.com/show_bug.cgi?id=1197204 > ___ > cloud mailing list > cloud@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/cloud > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct > -- Joe Brockmeier | Principal Cloud & Storage Analyst j...@redhat.com | http://community.redhat.com/ Twitter: @jzb | http://dissociatedpress.net/ signature.asc Description: OpenPGP digital signature ___ cloud mailing list cloud@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [atomic-devel] Atomic 2 week releases
On Tue, Apr 7, 2015 at 6:43 PM, Colin Walters wrote: [ Resurrecting, adding atomic-devel CC ] [snip] I mentioned this before, but a critical hinge point is whether the tree + images are entirely composed of RPMs built in Fedora. AIUI for example, if we had a COPR (or whatever) with a more bleeding edge Docker[0], or carried a patched systemd temporarily[1], I believe that would run afoul of: https://fedoraproject.org/wiki/Legal:Trademark_guidelines?rd=Legal/TrademarkGuidelines#Virtual_images_or_appliances_with_combinations_of_Fedora_software_with_non-Fedora_or_modified_Fedora_software A Fedora Remix might be an option: https://fedoraproject.org/wiki/Remix#Are_Remixes_and_Spins_different.3F ...at least, I assumed so offhand, but reading it, in that page "Fedora software" isn't defined - does COPR count or not? Anyways...my bottom line here is that it feels really weird to me to fight all the way for F22 and sustain that only to split it out after. It's a lot simpler to say F21 was our first try, we learned some things, but a lot more work needs to be done, it'll be faster to iterate outside and then merge back when it's ready, which may be F23 or whatever. This makes sense to me. There's some loss in pulling back from being an official Fedora release, but for now, in order to do Atomic well, we may need more flexibility than the current policies permit. Jason [0] OSTree was born to do continuous delivery, and the fact that it's wedged after the slow, plodding, conservative mainline koji + "daily build" + bodhi IMO weakens its value a lot. We could also be a lot more aggressive with updates to the RPMs that go into Docker containers - if some http library breaks it may just affect your app and not the host, etc. [1] https://bugzilla.redhat.com/show_bug.cgi?id=1197204 ___ cloud mailing list cloud@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [atomic-devel] Atomic 2 week releases
On Wed, Apr 8, 2015, at 02:51 PM, Joe Brockmeier wrote: > Copr doesn't count. Talked to Tom Callaway about this briefly just now > and basically - it must be built in Koji to be part of a Spin, unless we > get an exception. A side tag as mattdm mentioned somewhere solves that, no need to rename. Though this also seems like something that could go back up to the Council..."newer upstream versions of packages already in Fedora for a project under the Fedora umbrella" seems like it'd be quite a different thing compared to the other types of projects the trademark guidelines are addressing. ___ cloud mailing list cloud@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [atomic-devel] Atomic 2 week releases
On Wed, Apr 08, 2015 at 03:07:19PM -0400, Colin Walters wrote: > Though this also seems like something that could go back up to the > Council..."newer upstream versions of packages already in Fedora for > a project under the Fedora umbrella" seems like it'd be quite > a different thing compared to the other types of projects the > trademark guidelines are addressing. Agreed! -- Matthew Miller Fedora Project Leader ___ cloud mailing list cloud@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Need owner of Atomic 2 Week releases
Hey folks, creating a separate thread for this longer term discussion. We're getting ready to release our first 2 week atomic update on Tuesday and Dusty Mabe has raised 2 potential release blockers that were not part of automated testing. It's good that he caught them, but it's also a bit of a stroke of luck. Since there is no official QE for this release, who should own verifying that there are no release blocking bugs prior to every automated release and escalating if there are? If no one raises the blocker, we'll have no way to block the release. This is something that we need an answer to fairly quickly since we don't even have confidence that the current release is good other than the current reports. And we'll be taking this plunge again in just 2 weeks. Thanks for your attention to this, -- Amanda Carter ___ cloud mailing list cloud@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Need owner of Atomic 2 Week releases
On 11/13/2015 10:41 AM, Amanda Carter wrote: Hey folks, creating a separate thread for this longer term discussion. We're getting ready to release our first 2 week atomic update on Tuesday and Dusty Mabe has raised 2 potential release blockers that were not part of automated testing. It's good that he caught them, but it's also a bit of a stroke of luck. Since there is no official QE for this release, who should own verifying that there are no release blocking bugs prior to every automated release and escalating if there are? If no one raises the blocker, we'll have no way to block the release. This is something that we need an answer to fairly quickly since we don't even have confidence that the current release is good other than the current reports. And we'll be taking this plunge again in just 2 weeks. Thanks for your attention to this, We should really have a blocker review process for these similar to the ones we have for normal Fedora releases. Primary items that we should be concerned with in the review are rpms like the following: kernel: docker: etcd: kubernetes: cloud-init: ostree: atomic: cockpit: Dusty ___ cloud mailing list cloud@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Need owner of Atomic 2 Week releases
On Fri, Nov 13, 2015 at 10:41 AM, Amanda Carter wrote: > Hey folks, creating a separate thread for this longer term discussion. We're > getting ready to release our first 2 week atomic update on Tuesday and Dusty > Mabe has raised 2 potential release blockers that were not part of automated > testing. It's good that he caught them, but it's also a bit of a stroke of > luck. Since there is no official QE for this release, who should own > verifying that there are no release blocking bugs prior to every automated > release and escalating if there are? If no one raises the blocker, we'll have > no way to block the release. Other than adding "making sure that anything found manually gets tests added so it doesn't reoccur", I don't have much to add to this except for saying that I also recognize the need. Paul Frields tells me that no one on his team (Fedora Infrastructure Engineering) is in the right position to do this overall. That team -- along with Fedora Release Engineering -- has been working on making sure that the release artifacts get constructed, but aren't experts in what goes _in_ them. (It's nice that we're at the point where the problems are on the inside, I guess!) I think it needs to be someone who is deeply connected to the teams working on Atomic development, but who is also given this is a core responsibility and guaranteed the time for making sure things work in Fedora specifically. I hope that over time we can grow community around this, but that's in a chicken and egg situation. (I can elaborate on that if it's not obvious to everyone...) -- Matthew Miller • Fedora Project Leader ___ cloud mailing list cloud@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Need owner of Atomic 2 Week releases
On Fri, Nov 13, 2015 at 11:35 AM, Dusty Mabe wrote: > > > On 11/13/2015 10:41 AM, Amanda Carter wrote: >> >> Hey folks, creating a separate thread for this longer term discussion. >> We're getting ready to release our first 2 week atomic update on Tuesday and >> Dusty Mabe has raised 2 potential release blockers that were not part of >> automated testing. It's good that he caught them, but it's also a bit of a >> stroke of luck. Since there is no official QE for this release, who should >> own verifying that there are no release blocking bugs prior to every >> automated release and escalating if there are? If no one raises the blocker, >> we'll have no way to block the release. >> >> This is something that we need an answer to fairly quickly since we don't >> even have confidence that the current release is good other than the current >> reports. And we'll be taking this plunge again in just 2 weeks. >> >> Thanks for your attention to this, >> > > We should really have a blocker review process for these similar to the ones > we have for normal Fedora releases. Primary items that we should be Are these 2 week images built from updates that are currently in stable, or are they built from updates-testing as well? I ask because it matters for things outside of atomic. The release blocker review process works because it catches things _before_ they are released for general availability. If the 2 week atomic images are only composed from already stable updates, then the packages are already out there in the project otherwise. So if you have something "blocker" in an atomic image, you are now forced to wait for an update to make it through the entire fedora updates process before you can ship your 2 week image. For something like the kernel, that might very well mean you don't ship a 2 week image because the fix is not in stable in sufficient time. The atomic images might be better served by doing tests on updates-testing packages that are included to ensure that blockers don't otherwise show up as a surprise. I would also recommend reaching out to the package owners for each important package in advance so that the atomic sig is aware of what is planned for updates and such. josh ___ cloud mailing list cloud@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Need owner of Atomic 2 Week releases
On Fri, Nov 13, 2015 at 10:50 AM, Josh Boyer wrote: > On Fri, Nov 13, 2015 at 11:35 AM, Dusty Mabe wrote: >> >> >> On 11/13/2015 10:41 AM, Amanda Carter wrote: >>> >>> Hey folks, creating a separate thread for this longer term discussion. >>> We're getting ready to release our first 2 week atomic update on Tuesday and >>> Dusty Mabe has raised 2 potential release blockers that were not part of >>> automated testing. It's good that he caught them, but it's also a bit of a >>> stroke of luck. Since there is no official QE for this release, who should >>> own verifying that there are no release blocking bugs prior to every >>> automated release and escalating if there are? If no one raises the blocker, >>> we'll have no way to block the release. >>> >>> This is something that we need an answer to fairly quickly since we don't >>> even have confidence that the current release is good other than the current >>> reports. And we'll be taking this plunge again in just 2 weeks. >>> >>> Thanks for your attention to this, >>> >> >> We should really have a blocker review process for these similar to the ones >> we have for normal Fedora releases. Primary items that we should be > > Are these 2 week images built from updates that are currently in > stable, or are they built from updates-testing as well? > > I ask because it matters for things outside of atomic. The release > blocker review process works because it catches things _before_ they > are released for general availability. If the 2 week atomic images > are only composed from already stable updates, then the packages are > already out there in the project otherwise. > > So if you have something "blocker" in an atomic image, you are now > forced to wait for an update to make it through the entire fedora > updates process before you can ship your 2 week image. For something > like the kernel, that might very well mean you don't ship a 2 week > image because the fix is not in stable in sufficient time. > > The atomic images might be better served by doing tests on > updates-testing packages that are included to ensure that blockers > don't otherwise show up as a surprise. I would also recommend > reaching out to the package owners for each important package in > advance so that the atomic sig is aware of what is planned for updates > and such. > > josh I'd also point out that the nature of Atomic's rollback features make it better suited to less testing in that they can always roll back. The problem that I see comes if there's a bug that lasts through several releases causing a fairly bad trust scenario w/ upgrades. -- Mike McGrath | mmcgr...@redhat.com | (312) 660-3547 Atomic | Red Hat Chicago | http://projectatomic.io/ ___ cloud mailing list cloud@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Need owner of Atomic 2 Week releases
On Fri, Nov 13, 2015 at 12:56 PM, Michael McGrath wrote: > On Fri, Nov 13, 2015 at 10:50 AM, Josh Boyer > wrote: >> On Fri, Nov 13, 2015 at 11:35 AM, Dusty Mabe wrote: >>> >>> >>> On 11/13/2015 10:41 AM, Amanda Carter wrote: Hey folks, creating a separate thread for this longer term discussion. We're getting ready to release our first 2 week atomic update on Tuesday and Dusty Mabe has raised 2 potential release blockers that were not part of automated testing. It's good that he caught them, but it's also a bit of a stroke of luck. Since there is no official QE for this release, who should own verifying that there are no release blocking bugs prior to every automated release and escalating if there are? If no one raises the blocker, we'll have no way to block the release. This is something that we need an answer to fairly quickly since we don't even have confidence that the current release is good other than the current reports. And we'll be taking this plunge again in just 2 weeks. Thanks for your attention to this, >>> >>> We should really have a blocker review process for these similar to the ones >>> we have for normal Fedora releases. Primary items that we should be >> >> Are these 2 week images built from updates that are currently in >> stable, or are they built from updates-testing as well? >> >> I ask because it matters for things outside of atomic. The release >> blocker review process works because it catches things _before_ they >> are released for general availability. If the 2 week atomic images >> are only composed from already stable updates, then the packages are >> already out there in the project otherwise. >> >> So if you have something "blocker" in an atomic image, you are now >> forced to wait for an update to make it through the entire fedora >> updates process before you can ship your 2 week image. For something >> like the kernel, that might very well mean you don't ship a 2 week >> image because the fix is not in stable in sufficient time. >> >> The atomic images might be better served by doing tests on >> updates-testing packages that are included to ensure that blockers >> don't otherwise show up as a surprise. I would also recommend >> reaching out to the package owners for each important package in >> advance so that the atomic sig is aware of what is planned for updates >> and such. >> >> josh > > > I'd also point out that the nature of Atomic's rollback features make > it better suited to less testing in that they can always roll back. > The problem that I see comes if there's a bug that lasts through > several releases causing a fairly bad trust scenario w/ upgrades. > > -- > Mike McGrath | mmcgr...@redhat.com | (312) 660-3547 > Atomic | Red Hat Chicago | http://projectatomic.io/ One other thing I forgot to mention, Dennis requested some additional QA for this to do some basic smoke tests. We're working on setting something up that can be used for a basic smoke test until something more permanent can be setup. I've cc'd Ari who's familiar. Ari, can you give a quick update on what your team is thinking at this point? Something automated would help greatly for at least one part of the 2 week release (though bugs would still need to be handled). -- Mike McGrath | mmcgr...@redhat.com | (312) 660-3547 Atomic | Red Hat Chicago | http://projectatomic.io/ ___ cloud mailing list cloud@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [atomic-devel] Need owner of Atomic 2 Week releases
> On Nov 13, 2015, at 5:47 PM, Matthew Miller wrote: > > On Fri, Nov 13, 2015 at 10:41 AM, Amanda Carter wrote: >> Hey folks, creating a separate thread for this longer term discussion. We're >> getting ready to release our first 2 week atomic update on Tuesday and Dusty >> Mabe has raised 2 potential release blockers that were not part of automated >> testing. It's good that he caught them, but it's also a bit of a stroke of >> luck. Since there is no official QE for this release, who should own >> verifying that there are no release blocking bugs prior to every automated >> release and escalating if there are? If no one raises the blocker, we'll >> have no way to block the release. > > Other than adding "making sure that anything found manually gets tests > added so it doesn't reoccur", I don't have much to add to this except > for saying that I also recognize the need. > > Paul Frields tells me that no one on his team (Fedora Infrastructure > Engineering) is in the right position to do this overall. That team -- > along with Fedora Release Engineering -- has been working on making > sure that the release artifacts get constructed, but aren't experts in > what goes _in_ them. (It's nice that we're at the point where the > problems are on the inside, I guess!) > > I think it needs to be someone who is deeply connected to the teams > working on Atomic development, but who is also given this is a core > responsibility and guaranteed the time for making sure things work in > Fedora specifically. This is a very small community of people to choose from. Can we figure out a way to skew this so that we can ramp someone up? For example, I would consider offering to help, and I think my manager would give me some time to do the work, but I am not connected to all of these Fedora teams. If we find someone who is deep in 1-2 teams have some committed folks to ramp them up we can both solve this problem and grow our number of people able to do this kind of work. regards, bex ___ cloud mailing list cloud@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/cloud@lists.fedoraproject.org
Re: [atomic-devel] Need owner of Atomic 2 Week releases
On Sat, Nov 21, 2015 at 3:26 AM, Brian (bex) Exelbierd wrote: > >> On Nov 13, 2015, at 5:47 PM, Matthew Miller wrote: >> >> On Fri, Nov 13, 2015 at 10:41 AM, Amanda Carter wrote: >>> Hey folks, creating a separate thread for this longer term discussion. >>> We're getting ready to release our first 2 week atomic update on Tuesday >>> and Dusty Mabe has raised 2 potential release blockers that were not part >>> of automated testing. It's good that he caught them, but it's also a bit of >>> a stroke of luck. Since there is no official QE for this release, who >>> should own verifying that there are no release blocking bugs prior to every >>> automated release and escalating if there are? If no one raises the >>> blocker, we'll have no way to block the release. >> >> Other than adding "making sure that anything found manually gets tests >> added so it doesn't reoccur", I don't have much to add to this except >> for saying that I also recognize the need. >> >> Paul Frields tells me that no one on his team (Fedora Infrastructure >> Engineering) is in the right position to do this overall. That team -- >> along with Fedora Release Engineering -- has been working on making >> sure that the release artifacts get constructed, but aren't experts in >> what goes _in_ them. (It's nice that we're at the point where the >> problems are on the inside, I guess!) >> >> I think it needs to be someone who is deeply connected to the teams >> working on Atomic development, but who is also given this is a core >> responsibility and guaranteed the time for making sure things work in >> Fedora specifically. > > This is a very small community of people to choose from. Can we figure out a > way to skew this so that we can ramp someone up? For example, I would > consider offering to help, and I think my manager would give me some time to > do the work, but I am not connected to all of these Fedora teams. If we find > someone who is deep in 1-2 teams have some committed folks to ramp them up we > can both solve this problem and grow our number of people able to do this > kind of work. I'd be happy to fill the gaps from the Fedora side to the best of my abilities. I also look forward to using the interaction as an opportunity to learn more about the finer points of Atomic. -AdamM > > regards, > > bex > ___ > cloud mailing list > cloud@lists.fedoraproject.org > http://lists.fedoraproject.org/admin/lists/cloud@lists.fedoraproject.org ___ cloud mailing list cloud@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/cloud@lists.fedoraproject.org
