On 11/12/2013 08:12 PM, Kevin Fenzi wrote:
On Tue, 12 Nov 2013 16:32:13 +0000
"Jóhann B. Guðmundsson" <johannbg(a)gmail.com> wrote:
> Few notes about FedoraOS Server Platform ( FOSSP )
> Which touches serveral topics we have been discussing.
> 1. https://fedoraproject.org/wiki/User:Johannbg/FOSSP
Hey. Quite a document. ;)
Note this is an work in progress and without pictures ( as it says there
in the DRAFT statement ).
Is FOS (Fedora OS) the product from our base working group?
Or something else?
That depends heavily on the outcome of the base working group but as
things stand now what they have discussed and how I see us moving
forward to the future are quite different.
As you are well aware of I had already given the "FedoraOS" a great deal
of thought otherwise I would not have asked fesco to grant me time to
put my data together the community proposal an alternative to rings to
rule them all or PRD's.
For example I create this  in sometime in July, ( as well as briefly
mention this to Bill over beer at flock ) I asked the kernel community
about a new naming scheme in ( related to this ) and few other things
here and there.
As well as I was not chosen for that group so...
I'd not list some of those specific things FOSSP
'consists' of, as they
may be decided by the base working group. Perhaps we switch from dracut
to something else someday, etc. Additionally, some of them are subject
Of course that list was just a list to start working with as well as to
what is in those 16 server roles ( or even if we need more roles like
for example there is no role that covers "printing". )
I'll say again that I don't think we should provide kickstarts.
Additionally, I don't think we should try and provide images for every
featured stack. I'd prefer something like the netinstall iso with
anaconda tweaked for server use, and groups for package stacks.
I disagree ( with the exception of point you make about anaconda which I
agree with )
And here's why...
ks files are easy to maintain.
ks files area easy to deploy
ks files are easy to adapt
ks files are ready to use in already existing infrastructures.
No additional learning curve for "new format" for existing
administrators to learn since they are already familiar with ks syntax.
Dnf in the distant future could use them to directly install into ( os )
Minimal code changes would be needed for Anaconda.
Releasing a full blown iso ( with each role ) makes no sense while ready
to use virtual images for the cloud or just virtualsation in general
I even shall go as far as saying ks files should be our primary release
format ( or atleast the first one we implement )
We should talk with the Cloud WG and confirm what stuff they want to
handle and what they would like us to handle as well.
Quite frankly I dont grasp that separation there never should have been
an cloud WG to begin with.
Matt could have gotten what he wanted quite easily without it from my pov.
Both the hosting and the creation belongs within the server community.
I like the idea of getting something/fedup to provide some kind of
'before upgrade' report that can point out problems.
Dont forget the missing infrastructure or web tool which helps
administrators to dermine which server roles they are looking after and
The server roles section has a number of things that should be
before being decided on, IMHO. For an inital f21 timeframe we should
again look at just a few, IMHO.
You are not seriously suggesting that we disrupt our existing user base
and their workflow by implementing this as well as what ever comes out
of the other WG's into our existing release model?
Why do you think I came up with a new brand "FedoraOS" other then to
make a clear distinction between this was not Fedora but something new.
Not really we are nine voting members and each of us could select one
application that is in one server role ( or belongs in one but is not
listed there ) and write prd's about that application ( home assignment ).
And keeping things separate from "Fedora" in separated branches allows
us to move further at a faster pace. ( By my estimation we are the WG
that has the biggest momentum as things stand now )
Service packs sound interesting, but need more information to say for
sure. Are you seeing this as something like a point release? where all
the updates are rolled up and tested as a group, then people can
upgrade to x.1, x.2, etc? How often would this happen? Additionally we
would need a way to decide if something is Critical or not.
I'm not sure minor (x.x.1, x.x.2) releases add much value. Wouldn't
people who want those just apply updates as they come out?
Here things start to get interesting complicated and are in heavy state
of flux since I have reach the conclusion that
A) FOS release cycle should be tied to the kernel release cycle ( which
means roughly 3 FOS platform releases per year with the exception of the
kernel's LTS release which we would have to tie our LTS release upon )
B) FOSSP needs to be on it's own release cycle as in different from the
FOS as well as the Server Roles themselves
C) Server Roles each need to be on their own release cycle. ( mostly due
to upstream participation as in they control the release cycle of their
application after all they are the ones that have to maintain it )
Thanks for writing things up... helps as a way to start more
And hopefully sort things out in the process.