FAD Goals and deliverables

[Dennis Gilmore]

On Tuesday, May 19, 2015 03:56:59 PM Peter Robinson wrote:
> >> > > 2) integrated ability to make atomic installer and pxe to live in
> >> > > pungi
> >> > 
> >> > Downstream Atomic operates on an asynchronous schedule, so there
> >> > are going to be few times when we actually want to generate two
> >> > installers
> >> > and trees/etc simultaneously.
> >> > 
> >> > The CentOS Atomic SIG is also planning to do regular 4 week releases,
> >> > again asynchronously of the CentOS Core rebuild.
> >> > 
> >> > We would also like the ability to do faster and more regular releases
> >> > of Fedora Atomic Host - a 2 week interval has been discussed.
> >> 
> >> This is a big part of why we need it integrated into the tooling. we can
> >> define a pungi config that has a subset of the full compose, i.e. the
> >> atomic, and possibly cloud and/or livecd bits.
> >> we can then make them as part of the
> >> updates push process and  promote them to stable at any time.
> > 
> > So you're saying bodhi should run pungi as a part of the push process
> > and handle creating installers, trees, and pxe images? Do you want
> > people to have to submit these things to go through the testing->stable
> > karma cycle through the bodhi interface?
> 
> Well bodhi2 has to be able to orchestrate the updates process for any
> of the products we produce, whether that be pure yum repos or
> cloud/docker/atomic trees/installers/images and be extensible enough
> to be able to handle app-c or what ever is coming down the pipe
> next...
correct,  Bodhi needs to be able to manage the full list of update 
deliverables.  That does not mean that Bodhi has to do all or even any of it. 
but it needs to ensure that all deliverables for updates are made and pushed 
as a batch. 

> > Bodhi has already seen a tremendous amount of feature-creep, so I want
> > to make sure the expectations are set appropriately. My primary focus
> 
> Well ultimately bodhi2 has been in discussion for as long as I can
> remember and since then we as a distro have had the product split but
> also things like docker, atomic and other technologies come along we
> need to update. That might be considered feature creep but it's
> feature creep that needs to be dealt with :-)
> 
> > with it at the moment is to have bodhi2 get the existing bits out to the
> > mirrors for testing as fast as possible. It is not designed to create
> > the bits, it's designed to take what's already built/composed and
> > facilitate community testing. It is designed for updates, not releases,
> > which it sounds like the 2-week model is about.
> 
> We it needs to orchestrate the bits, whatever they are.
> 
> In terms of a "two week" new atomic compose, that does sound more like
> it fits in the pungi4/distill side of things which I agree is out of
> scope for "updates" because it's not really an update of exisiting but
> a new compose.

the two week atomic compose is irrelevant to this discussion. how that gets 
done needs to be a different discussion. 

> > Instead of making bodhi an arbitrary task-runner for various releng
> > tasks, I think that effort should be focused on Koji plugins + The
> > ComposeDB. The goal has always been to outsource the mashing of the
> > updates repos to our build farm, and I think these various
> > trees/images/containers/installers are in the same boat. I'm fine with
> > bodhi potentially kicking off these various tasks, but it is not
> > designed to be a compose farm.
> 
> Agreed
Doing the tasks external to bodhi2 is prefectly fine and likely needed. we can 
not do things by fedmsg due to not having guaranteed delivery, so either it 
needs to  be done via direct calls etc. or we need to do something to 
guarantee delivery.

The updates deliverables going forward will look like a a subset of a release 
compose. We really should be building updated Docker base images as an today 
as part of the updates process.  but do we need to do them every time we push 
updates?  no. same as the atomic tree. we really only need to fire off 
updating some deliverables when something in them changes.  right now we do 
not have a way to know that, it is where the composedb will come in. while I 
had never envisioned composedb as doing composes. perhaps it could.  or we 
have a different system that orchestrates things.   In the end if Bodhi is not 
going to meet the needs for updates management, we will need to talk about 
something to replace it that does meet the needs of updates management in 
Fedora.  in Fedora 23 every time something in the atomic tree changes we will 
need to make the pxe-to-live bits so that people can boot into the newest 
snapshot. that there is a desire to have updated installers with the latest 
content to me means it falls into the realm of update deliverable, 

we also have to make updated cloud images, potentially we should be looking at 
livecds.  In an ideal world we would make only deliverables that have changed. 

> >> > That doesn't mean that the code can't be shared - but it does make
> >> > the "release mainline and Atomic together as one big blob" is an
> >> > unusual case.
> >> 
> >> not at all.
> > 
> > [...]
> > 
> >> > So there may be a more fundamental decision to make about whether
> >> > Atomic should simply be part of that "big set" release at all.
> >> 
> >> not at all.
> > 
> > With regard to updates, I am in favor of getting bits out asynchronously
> > as fast as possible. This means repos would hit first, then the various
> > installers/trees/images trickle out shortly after as soon as they
> > complete.

I am completely opposed to pushing things out asyncronously, at least unless 
we have better messaging. If the next heart bleed comes along, we say we have 
pushed the fix, end users will get confused if the update is only available if 
you are on a system that is updated by yum.  If there is no atomic tree, or 
docker base image, or some other consumable deliverable format available, 
users will ask whats going on, assume we are incompetent or worse.  to me 
bodhi needs to ensure that when the deliverables go out all intended 
deliverables go out.

Dennis
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.fedoraproject.org/pipermail/rel-eng/attachments/20150519/05707424/attachment.sig>