----- Original Message ----- > From: "Matthew Miller" <mattdm@xxxxxxxxxxxxxxxxx> > To: "Fedora Cloud SIG" <cloud@xxxxxxxxxxxxxxxxxxxxxxx> > Sent: Monday, June 15, 2015 10:17:31 AM > Subject: Re: basic plan for two-week atomic images > > 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? > At this point I would settle for anything I could put here: http://dl.fedoraproject.org/pub/alt/fedora-atomic/images/testing/ and blog about. > > > >> > 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. > Kubernetes might be removed from the list soon if we can containerize it, there's extra work to do so but that might simplify the atomic builds a bit. -Mike > 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@xxxxxxxxxxxxxxxxx> > Fedora Project Leader > _______________________________________________ > cloud mailing list > cloud@xxxxxxxxxxxxxxxxxxxxxxx > https://admin.fedoraproject.org/mailman/listinfo/cloud > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct > _______________________________________________ cloud mailing list cloud@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
