10:34 a.m.
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 | mmcgrath(a)redhat.com | (312) 660-3547
Atomic | Red Hat Chicago | http://projectatomic.io/
10:43 a.m.
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
11:17 a.m.
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.
10:45 a.m.
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 | mmcgrath(a)redhat.com | (312) 660-3547
Atomic | Red Hat Chicago | http://projectatomic.io/
_______________________________________________
cloud mailing list
cloud(a)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.
11:03 a.m.
----- Original Message -----
From: "Daniel J Walsh" <dwalsh(a)redhat.com>
To: "Fedora Cloud SIG" <cloud(a)lists.fedoraproject.org>
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 | mmcgrath(a)redhat.com | (312) 660-3547
> Atomic | Red Hat Chicago | http://projectatomic.io/
> _______________________________________________
> cloud mailing list
> cloud(a)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(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
11:31 a.m.
On 03/09/2015 12:03 PM, Michael P. McGrath wrote:
----- Original Message -----
> From: "Daniel J Walsh" <dwalsh(a)redhat.com>
> To: "Fedora Cloud SIG" <cloud(a)lists.fedoraproject.org>
> 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 | mmcgrath(a)redhat.com | (312) 660-3547
>> Atomic | Red Hat Chicago | http://projectatomic.io/
>> _______________________________________________
>> cloud mailing list
>> cloud(a)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(a)lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/cloud
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
>
_______________________________________________
cloud mailing list
cloud(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
12:09 p.m.
----- Original Message -----
From: "Daniel J Walsh" <dwalsh(a)redhat.com>
To: "Fedora Cloud SIG" <cloud(a)lists.fedoraproject.org>
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" <dwalsh(a)redhat.com>
>> To: "Fedora Cloud SIG" <cloud(a)lists.fedoraproject.org>
>> 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 | mmcgrath(a)redhat.com | (312) 660-3547
>>> Atomic | Red Hat Chicago | http://projectatomic.io/
>>> _______________________________________________
>>> cloud mailing list
>>> cloud(a)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(a)lists.fedoraproject.org
>> https://admin.fedoraproject.org/mailman/listinfo/cloud
>> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
>>
> _______________________________________________
> cloud mailing list
> cloud(a)lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/cloud
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
_______________________________________________
cloud mailing list
cloud(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
12:50 p.m.
On 03/10/2015 01:09 PM, Michael P. McGrath wrote:
----- Original Message -----
> From: "Daniel J Walsh" <dwalsh(a)redhat.com>
> To: "Fedora Cloud SIG" <cloud(a)lists.fedoraproject.org>
> 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" <dwalsh(a)redhat.com>
>>> To: "Fedora Cloud SIG" <cloud(a)lists.fedoraproject.org>
>>> 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 | mmcgrath(a)redhat.com | (312) 660-3547
>>>> Atomic | Red Hat Chicago | http://projectatomic.io/
>>>> _______________________________________________
>>>> cloud mailing list
>>>> cloud(a)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(a)lists.fedoraproject.org
>>> https://admin.fedoraproject.org/mailman/listinfo/cloud
>>> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
>>>
>> _______________________________________________
>> cloud mailing list
>> cloud(a)lists.fedoraproject.org
>> https://admin.fedoraproject.org/mailman/listinfo/cloud
>> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
> _______________________________________________
> cloud mailing list
> cloud(a)lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/cloud
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
>
_______________________________________________
cloud mailing list
cloud(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
2:18 p.m.
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
<mattdm(a)fedoraproject.org>
Fedora Project Leader
11:14 a.m.
On Mon, Mar 9, 2015 at 10:34 AM, Michael P. McGrath <mmcgrath(a)redhat.com> 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 | mmcgrath(a)redhat.com | (312) 660-3547
Atomic | Red Hat Chicago | http://projectatomic.io/
_______________________________________________
cloud mailing list
cloud(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
12:17 p.m.
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-a...
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.
1:53 p.m.
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
<mattdm(a)fedoraproject.org>
Fedora Project Leader
1:59 p.m.
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
jzb(a)redhat.com | http://community.redhat.com/
Twitter: @jzb | http://dissociatedpress.net/
2:48 p.m.
On Tue, Mar 10, 2015 at 1:59 PM, Joe Brockmeier <jzb(a)redhat.com> 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
jzb(a)redhat.com | http://community.redhat.com/
Twitter: @jzb | http://dissociatedpress.net/
_______________________________________________
cloud mailing list
cloud(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
4:42 p.m.
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 <maxamillion(a)fedoraproject.org>
wrote:
On Tue, Mar 10, 2015 at 1:59 PM, Joe Brockmeier
<jzb(a)redhat.com> 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
> jzb(a)redhat.com | http://community.redhat.com/
> Twitter: @jzb | http://dissociatedpress.net/
>
>
> _______________________________________________
> cloud mailing list
> cloud(a)lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/cloud
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
>
_______________________________________________
cloud mailing list
cloud(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
5:37 p.m.
On Tue, Mar 10, 2015 at 3:48 PM, Adam Miller
<maxamillion(a)fedoraproject.org> wrote:
On Tue, Mar 10, 2015 at 1:59 PM, Joe Brockmeier
<jzb(a)redhat.com> 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
5:41 p.m.
On Tue, Mar 10, 2015 at 6:37 PM, Josh Boyer <jwboyer(a)fedoraproject.org> wrote:
On Tue, Mar 10, 2015 at 3:48 PM, Adam Miller
<maxamillion(a)fedoraproject.org> wrote:
> On Tue, Mar 10, 2015 at 1:59 PM, Joe Brockmeier <jzb(a)redhat.com> 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
8:02 p.m.
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
<mattdm(a)fedoraproject.org>
Fedora Project Leader
8:20 p.m.
----- Original Message -----
From: "Matthew Miller" <mattdm(a)fedoraproject.org>
To: "Fedora Cloud SIG" <cloud(a)lists.fedoraproject.org>
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
<mattdm(a)fedoraproject.org>
Fedora Project Leader
_______________________________________________
cloud mailing list
cloud(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
12:55 p.m.
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
jzb(a)redhat.com | http://projectatomic.io
Twitter: @jzb | http://dissociatedpress.net/
1:04 p.m.
----- Original Message -----
From: "Joe Brockmeier" <jzb(a)redhat.com>
To: cloud(a)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
jzb(a)redhat.com | http://projectatomic.io
Twitter: @jzb | http://dissociatedpress.net/
_______________________________________________
cloud mailing list
cloud(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
1:16 p.m.
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
jzb(a)redhat.com | http://community.redhat.com/
Twitter: @jzb | http://dissociatedpress.net/
1:20 p.m.
----- Original Message -----
From: "Joe Brockmeier" <jzb(a)redhat.com>
To: "Michael P. McGrath" <mmcgrath(a)redhat.com>, "Fedora Cloud
SIG" <cloud(a)lists.fedoraproject.org>
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
jzb(a)redhat.com | http://community.redhat.com/
Twitter: @jzb | http://dissociatedpress.net/
1:26 p.m.
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
jzb(a)redhat.com | http://community.redhat.com/
Twitter: @jzb | http://dissociatedpress.net/
2:58 p.m.
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
<mattdm(a)fedoraproject.org>
Fedora Project Leader
4:08 p.m.
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
4:13 p.m.
----- Original Message -----
From: "Ian McLeod" <imcleod(a)fedoraproject.org>
To: cloud(a)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(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
4:28 p.m.
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.
2:05 a.m.
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
4:29 p.m.
On Fri, Mar 13, 2015 at 05:13:29PM -0400, Michael P. McGrath wrote:
----- Original Message -----
> From: "Ian McLeod" <imcleod(a)fedoraproject.org>
> To: cloud(a)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.
FWIW this makes sense to me, too.
In a chicken-and-egg twist, Atomic may hold part of the key(s) to
making Rawhide more reliably stable and usable in the future. I think
Atomic stands a better chance for testing and visibility on $current
as already pointed out. So eventually that will, I hope, yield more
effective iteration on features that allow us to build if not a less
broken Rawhide overall, than at least a more easily recoverable one.
This issue may be somewhat orthogonal to problems with building or
composition of Rawhide. But still I hope it's a future possibility.
--
Paul W. Frields http://paul.frields.org/
gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717
http://redhat.com/ - - - - http://pfrields.fedorapeople.org/
The open source story continues to grow: http://opensource.com
4:35 p.m.
On 03/13/2015 04:13 PM, Michael P. McGrath wrote:
----- Original Message -----
> From: "Ian McLeod" <imcleod(a)fedoraproject.org>
> To: cloud(a)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(a)lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/cloud
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
>
10:04 a.m.
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
<mattdm(a)fedoraproject.org>
Fedora Project Leader
9:52 a.m.
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
jzb(a)redhat.com | http://community.redhat.com/
Twitter: @jzb | http://dissociatedpress.net/
9:52 a.m.
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
10:02 a.m.
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.
12:40 p.m.
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
1:49 p.m.
----- Original Message -----
From: "Colin Walters" <walters(a)verbum.org>
To: cloud(a)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(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
3:01 p.m.
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.
5:35 p.m.
On Mon, Mar 9, 2015 at 8:34 AM, Michael P. McGrath <mmcgrath(a)redhat.com> 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).
<rant>
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.
</rant>
11:32 a.m.
On Mon, Mar 9, 2015 at 5:35 PM, M. Edward (Ed) Borasky <znmeb(a)znmeb.net> wrote:
On Mon, Mar 9, 2015 at 8:34 AM, Michael P. McGrath
<mmcgrath(a)redhat.com> 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).
<rant>
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.
</rant>
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(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
8:43 p.m.
[ 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-A...
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/Tradem...
...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
10:11 a.m.
New subject: [atomic-devel] Atomic 2 week releases
On Tue, Apr 7, 2015 at 6:43 PM, Colin Walters <walters(a)verbum.org>
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/Tradem...
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
1:48 p.m.
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
<mattdm(a)fedoraproject.org>
Fedora Project Leader
1:51 p.m.
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-A...
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/Tradem...
...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(a)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
jzb(a)redhat.com | http://community.redhat.com/
Twitter: @jzb | http://dissociatedpress.net/
2:07 p.m.
New subject: [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.
2:53 p.m.
New subject: [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
<mattdm(a)fedoraproject.org>
Fedora Project Leader
3299
days inactive
3329
days old
45 comments
16 participants
participants (16)
-
Adam Miller -
Colin Walters -
Daniel J Walsh -
Dennis Gilmore -
Haïkel -
Ian McLeod -
Jason Brooks -
Joe Brockmeier -
Josh Boyer -
Karanbir Singh -
Kushal Das -
M. Edward (Ed) Borasky -
Matt Micene -
Matthew Miller -
Mike McGrath -
Paul W. Frields