FAD Goals and deliverables

[Peter Robinson]

>> > > 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 at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/rel-eng