> > > 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...
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.
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
> > 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.
luke
_______________________________________________
rel-eng mailing list
rel-eng(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/rel-eng