On 08/08/2016 10:10 PM, Jon Stanley wrote:
I’m quite concerned about the status of the Fedora Server Working
group after the departure of Stephen - he provided excellent
leadership and is definitely missed from the working group. However,
things seem to have fallen by the wayside since his departure. Perhaps
the members that are at Flock can meet and hammer out what the future
of the working group should be. From my perspective, there are a few
things:
We need to be a viable upstream for some of our downstream
derivatives, and be a thought leader for what folks want to see there.
I know that this can be a little controversial among some people, but
we cannot ignore the fact that we are the upstream of one of the major
Linux server vendors in the world. It would be foolish of us to do so.
This is most emphatically true. I think one of the reasons that Server has been
meandering a bit lately is that it hasn't received any clear direction from
anywhere lately. It had been hoped that such direction would come from two
places: Red Hat indicating its desires for future RHEL and from third parties
(represented in part by you, Jon, and Mike Wolf and other non-Red Hatters in the
Server SIG).
I think it is fairly clear however that without at least one of those entities
taking a firm hand in things, the Server SIG tends to default to just "keeping
the lights on".
At Flock last week, we had several very productive discussions on where the
Server Edition could and should go over the next twelve months. I'll try to
relate some of the high-level ideas here and we can hopefully drill down into
them further in either this email thread or during meetings (or both).
First, we finally got some word of plans from Red Hat. As many of you are
probably aware, Langdon White has been leading up the Modularity WG in Fedora.
The idea behind this effort is to treat certain parts of Fedora as complete
units in terms of the features and API they provide, rather than as individual
packages. Up to this point, their presence in the Fedora Project has been felt
as largely a research project. Moving forward from Flock, the Modularity WG has
reached out to the Server Working Group with some rather ambitious plans: By
Fedora 26, they want to produce the Server Edition as a reference implementation
of their "base" and "platform" modules. (Whether or not that would
completely
replace the traditional deliverable at the same time is an open question, but
current sense is "not before F27 at the earliest).
What does this mean for the Server WG? Well, first of all it will need to be
discussed whether or not this is a strategy we want to get behind. If it is,
then the role of the WG will be to aid in the actual *delivery* of the
Modularized Server Edition. The Modularity WG will aid in the creation of
modules themselves, but it will be the responsibility of the Server SIG to craft
them into something we can be proud to deliver.
More than that, we need to be a fountain of innovation in the server
ecosystem - regardless of what our downstream constituents want or are
paying for. I think that RoleKit is a good example of this. It started
as something that our downstream wanted and funded. They then changed
their mind on that for reasons that I’m not privy to, but the work has
continued, albeit slower.
The development of rolekit is actually a bit of a strange story. It was really a
skunkworks project that I managed to get some of engineering management
sufficiently on board with that I was able to get a functioning prototype out
the door. The hope was that this would pick up steam, gather a community and
become an obvious feature to pull into RHEL. Alas, the project didn't advance
beyond that prototype and rather than continue to invest in it (particularly
with the acquisition of Ansible and Red Hat investment into
OpenShift/Kubernetes), it was shelved.
At Flock, we discussed this as well: the *idea* of Roles applied to a system is
absolutely still sound. Furthermore, the crowd generally agreed that Cockpit
needs to have some mechanism to close the gap with Microsoft Server Manager in
setting up fundamental roles like a domain controller and storage manager. Those
in attendance however liked the idea of migrating our role strategy over to
something a bit different.
At a very high level, this new role strategy could also be tied to the
modularization strategy. In addition to the platform modules that we will
produce, we will also produce roles as "content modules" (essentially a
complete
functional implementation of the role as a self-contained add-on). Beyond that,
we looked at management of those roles and are very keenly interested in the
idea of building and deploying them through carefully curated Ansible playbooks
rather than rolekit.
As a medium-term strategy, it would be excellent to have someone working on an
implementation in Cockpit that could walk someone through the generation of
these playbooks and also export them for reuse in the future.
We need to decide what our deliverables are going to be. The cloud
working group has shifted towards a minimal OS and containers as the
solution. Is this something that we should adopt, and deliver the best
containers that there are for various server roles?
Is the deliverable something else entirely? Do we stay the course that
we have been of producing a general purpose OS with some tweaking? I’d
like to see the server product be differentiated from a “choose your
own adventure” system that anyone can build today, but be something
with some thought behind the integration of various components and
making sure that things work well together. Is there room for the
“choose your own adventure” course? Of course - some people will
choose that.
We need to go back to the initial PRD
(
https://fedoraproject.org/wiki/Server/Product_Requirements_Document)
that the working group was formed with and see if it’s still valid and
viable, or if we need to change it, and if so in what way? What does
that lead to in terms of deliverables?
See Josh's reply. We spend the PRD session at Flock walking through the
non-implementation parts of the Kellogg Logic Model to describe what we want to
do in order to satisfy our Mission and Vision. We will clean it up to read
better in the next week or two and then we can start filling in the
implementation side of things.
I’m willing to help with some of this work, but I cannot lead it
since
I’m busy with $DAYJOB, but I’ll help in absolutely any way that I’m
able to.
I'm looking at finding someone to stand up and drive this along. More to come
hopefully in the next couple weeks on this topic.