On 09/27/2016 07:11 PM, Chris Murphy wrote:
Hi,
I was asked to start this in today's Server meeting. The genesis for
me was, I have more questions than answers and I'm fairly convinced
I'm not the only person who's kinda shrugging not knowing what all the
questions even are. Answers are important too, but good questions to
properly explore scope and liabilities have to come first.
Agreed, thanks.
Cloud WG folks had decided a while ago to focus on Atomic Host, and
sounds like now they only want to do that, and form a new Atomic WG.
[1][2]
I see 8 base images for Cloud that aren't rpm-ostree based. Are they
in need of a new home?
As best I can tell, "yes".
Who's using them?
No idea
Are they all needed? Does it
make sense for Server WG to produce the non-Atomic Cloud deliverable
images?
So, my thoughts here is that we essentially retire *all* of them and then let
the Server WG decide to resurrect one or more of them that fits with their
mission. I think it's better to start from zero and add back in the ones that we
want rather than to analyze what we have and try to decide which ones to abandon.
At the last Cloud meeting, it was floated whether some Cloud people
should move over to Server, or vice versa. Should there be an
Atomic/Container WG? i.e. a fourth product deliverable?
I don't think we need another WG for this. The space is already a bit crowded.
Also membership on a WG isn't required for taking action; anyone who has
experience generating these images that wants to keep doing so is highly
encouraged to join the server(a)lists.fedoraproject.org mailing list, come to the
Server SIG meetings and participate in whatever way they see fit. The WG exists
mainly as an advisory body like FESCo: it's really there mostly to set general
direction and resolve disputes.
Frankly, if someone comes and does a whole bunch of work for the Server SIG,
there's a high probability that they will eventually be offered a seat on the WG
as well. It's *intended* that the chairs be held by people doing active work, so
people semi-regularly decide to give up their seat to others.
Being contrary, I wondered about consolidation as a solution rather
than adding another WG and product. [3] Does anyone see Cloud WG, or
Server WG as spread too thinly? What estimate do you have for overlap
in work between Cloud and Server? Is there an economy of scale by
combining them? And is it both useful and practical to have subgroups
within a WG, to split out the sub variants of Server: hardware, cloud,
atomic host?
I don't know that we need the overhead of additional official *groups*. I think
we can probably keep it all to just the Server SIG for now and work as a team.
Server and Workstation WGs have expressed interest in moving to
rpm-ostree based deployments also. So I'm confused by what an Atomic
WG would produce that's unique.
Last I heard, they weren't trying to be an "Atomic WG", but rather build a
complete container management solution atop OpenShift:
https://fedoraproject.org/wiki/Objectives/ProjectFAO
That being said, I'd kind of like to get to a point where Project FAO is
basically just a tool container running atop a Fedora Server os-tree image.
There are huge differences between
conventional and rpm-ostree deployments. Does it make sense for an
Atomic WG to have no outputs? And instead is liason with Server and
Workstation WGs, QA, Docs, releng, and others, to help in the
transition to this new way of delivering and maintaining Fedora?
See above, but I think that's where I'd like us to be in a couple years, but I
think convergence will take some time.
It might be that the Cloud and Server PRD refreshes help sort some
of
this stuff out too.
Yes, I was hoping that some of this would fall out from the Server PRD process
as a natural by-product.
OK I have more questions but this is long enough. I'm certain
others
can ask better questions, or versions of these ones, and in particular
the questions I haven't asked.
Thank you very much for getting this conversation started, Chris. I think it's
very important to try to get everyone talking and eventually on the same page.