[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [atomic-devel] Atomic 2 week releases



On 04/07/2015 09:43 PM, Colin Walters wrote:
> [ Resurrecting, adding atomic-devel CC ]
> 
> On Mon, Mar 9, 2015, at 11:34 AM, Michael P. McGrath wrote:
>> Hey all, I wanted to start a thread about doing more frequent Atomic releases in Fedora.
>> In particular I'd like to start building a new atomic release every two weeks that
>> includes the latest version of Docker, Kubernetes, and OSTree for the Fedora Atomic
>> images.
> 
> Most people in this thread seemed to be in favor of Atomic Host as a spin.  Now,
> I use the word "Host" specifically here because I think it's important to distinguish Atomic Host
> from the "docker + kubernetes as RPMs" set.  We should be able
> to get RPMs through Bodhi.
> 
> (See https://lists.projectatomic.io/projectatomic-archives/atomic-devel/2015-April/msg00013.html on that topic)
> 
> But we need to more fully flesh out the ramifications of a Host move out.  It would mean:
> 
>  - Dropping the (currently rather minimal) OSTree repo + cloud image from mainline rel-eng
>  - Standing up more regular code drops in https://alt.fedoraproject.org/pub/alt/fedora-atomic/images/f22/

Correct.

> (But if we do do this I'd like to keep open communication channels such that some or
>  all parts of Atomic Host could be more integrated with "mainline" in the future)

Absolutely. My intent here is not to never again offer an Atomic Host
(or some other variant that uses rpm-ostree) as a Fedora Cloud (or
Server) edition - but to let us Move Fast And Break Things outside the
usual Fedora release cycle.

The bottom line for me is that we are pushing out new things too quickly
for them to fit well w/in the usual release criteria for Fedora.

> I mentioned this before, but a critical hinge point is whether the tree + images are
> entirely composed of RPMs built in Fedora.  AIUI for example, if we had a COPR
> (or whatever) with a more bleeding edge Docker[0], or carried a patched systemd
> temporarily[1], I believe that would run afoul of:
> https://fedoraproject.org/wiki/Legal:Trademark_guidelines?rd=Legal/TrademarkGuidelines#Virtual_images_or_appliances_with_combinations_of_Fedora_software_with_non-Fedora_or_modified_Fedora_software
> 
> ...at least, I assumed so offhand, but reading it, in that page
> "Fedora software" isn't defined - does COPR count or not?

Copr doesn't count. Talked to Tom Callaway about this briefly just now
and basically - it must be built in Koji to be part of a Spin, unless we
get an exception.

One possible way around this would be to build packages in Koji that are
named slightly differently or have versions (e.g. "docker-1.6" instead
of just "docker" or maybe even "docker-atomic") but that might be a heck
of a lot of hassle.

> Anyways...my bottom line here is that it feels really weird to me to fight all
> the way for F22 and sustain that only to split it out after.  It's a lot simpler
> to say F21 was our first try, we learned some things, but a lot more work
> needs to be done, it'll be faster to iterate outside and then merge back
> when it's ready, which may be F23 or whatever.

I think we agree there? Except I'm thinking the merge back would be more
w/in the F25 timeline - I don't expect Docker, Kubernetes, etc. to
really slow down for the next 12-18 months.

> [0] OSTree was born to do continuous delivery, and the fact that it's wedged
>      after the slow, plodding, conservative mainline koji + "daily build" + bodhi
>      IMO weakens its value a lot.  We could also be a lot more aggressive
>      with updates to the RPMs that go into Docker containers - if some http library
>      breaks it may just affect your app and not the host, etc.
> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1197204
> _______________________________________________
> cloud mailing list
> cloud lists fedoraproject org
> https://admin.fedoraproject.org/mailman/listinfo/cloud
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
> 


-- 
Joe Brockmeier | Principal Cloud & Storage Analyst
jzb redhat com | http://community.redhat.com/
Twitter: @jzb  | http://dissociatedpress.net/

Attachment: signature.asc
Description: OpenPGP digital signature


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]