basic plan for two-week atomic images

[Matthew Miller]

On Wed, May 27, 2015 at 11:37:18AM -0500, Adam Miller wrote:
> >> > 2. Images built from those nightly (I think right now only rawhide?)
> >> once f22 is final only rawhide.
> > What would it take to make those happen post-release?
> If we could get a clearly defined list of what these items are I would
> be happy to work towards getting them done. I just don't know how that

Going back to this old thread. :) What's the list you need here? I
assume it's:

- downloadable Atomic qcow2 (and raw.xz)
- Same image uploaded to EC2 (and hopefully others)
- installer ISO?


> >> > 3. Images go through automated tests, automatically (tunir; not fully
> >> >    automatic yet, right?)
> >> there is zero automated testing available, but we really need it, afaik it is
> >> all manual
> > See <https://fedoraproject.org/wiki/Changes/tunir>. Plus glorious
> > Taskotron future, I'm sure. :)
> I'm not sure where in the phases this should fit, it seems like a
> giant forklift of work to me given that the base Fedora distro that
> Atomic is going to be pulling it's bits from doesn't even have this
> functionality. Am I mistaken or possibly missing something? (Please
> correct me if I am)

I think initially, this will be basic smoketests. Currently, I believe
those are https://github.com/kushaldas/tunirtests — Kushal, can you
correct me if I'm wrong. So, we don't need to forklift the whole
thing... just get these running automatically.



> >> We need people to test, and a process to move things through stages.
> >> build all the images, etc. a location to put things, i,e lots of
> >> things
> This largely piggy backs off my previous point. Automatic "graduation"
> will require a decent amount of work and probably commitment from the
> QA group. I won't speak to their capacity to cater to this but I think
> what is ultimately being asked of them should be brought to their
> attention as early as possible to get their input.

I don't think we can ask a lot more of the QA group — we may need more,
new bodies.


> > Let's work at building the full list of lots of things. If we want to
> > have people testing, I'd say that'd go something like:
> >   - every two weeks, latest image to pass is flagged as needing human
> >     testing, a la a package update in bodhi
> >   - some sort of karma system — maybe it _is_ bodhi, but don't want to
> >     block on that
> If it were to be Bodhi, would the Atomic tree (or image) then be just
> another build artifact pushed through and sync'd like an rpm? So for
> at least the near term, it would require human intervention of
> submitting an update?

Yeah. Although maybe that update could be summitted by a bot of some
sort? Presumably the same bot running Tunir. This would have the logic
for "two weeks mark has passed; find the latest image to pass tests
with this period, submit as update (or raise alarm if nothing has
succeeded)".

> > Atomic devs have expressed a strong worry about the lack of
> > something like this, unless I'm misunderstanding. Possibly an
> > alternate image including updates-testing would suffice (or, maybe,
> > is actually separately necessary, since atomic doesn't let
> > individual testers just pull in individual RPMs to test).
> If I remember correctly, there are also concerns about things ending
> up in Atomic trees that actually never see the light of day in Fedora
> because they might never make it to stable. What's the policy on that
> sort of thing? (Or is there one? I suspect this could be uncharted
> territory because Atomic is effectively a new Operating System product
> with it's own lifecycle aiming to operate within the Fedora umbrella)

It's a little bit uncharted territory if we're using F22 as a base
rather than Rawhide. For Rawhide, it's happened before (and
theoretically should be SOP for a Change proposal which doesn't work
out). But even with F22 base, as long as name-epoch-version-release
marches forward, and the packages which are subject to such churn are
clearly described as volatile, I don't see a problem.


> I suspect that if/when the testing automation is in place the double
> gate wouldn't be needed, especially if this is just considered a
> development release. But I think that's where part of the problem lies
> is that the Atomic dev teams wants to use a stable OS as something
> that is re-rev'd with components updated and replaced but still call
> it "Fedora $VERSION" when in fact, it is not the same as what others
> will get from Fedora $VERSION unless they install from either the
> Atomic image or this dev tree. (depending on what the decisions are
> there)

I think mostly the components that will get updated and replaced are
under the general Atomic umbrella, right? (Kubernetes, Atomic,
Docker...) Do we have concrete examples of things outside of that? I
know there was a theoretical example of systemd, but maybe that can be
coordinated with a mainline update. And the kernel is on an aggressive
update schedule anyway.

My suggestion, at least, is to try this approach with an eye towards
building the thing you talk about in this next paragraph for post-F23,
if it turns out to be necessary.

> Basically this again. If anything I think if Fedora Atomic wants to be
> it's own product then it should exist slightly differently such that
> it has it's own set of koji tags, inherits from $current, but
> subplants the components it needs. This would however be a massive
> shift because as it turns out that is something that's never been done
> before and I think this would require a whole new Bodhi stream since
> it's effectively a new product//release. If it's not Rawhide but it's
> not Fedora $current, then It's basically it's own Distro that's just
> based on Fedora and if it were to exist within the Fedora umbrella
> then I think there need to be policy changes and that's going to be a
> giant pile of other work to sort out how that's all going to fit.

-- 
Matthew Miller
<mattdm at fedoraproject.org>
Fedora Project Leader