FedoraOS Server Platform ( FOSSP )

["Jóhann B. Guðmundsson"]

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 at gmail.com> wrote:
>
>> Few notes about FedoraOS Server Platform ( FOSSP )
>>
>> Which touches serveral topics we have been discussing.
>>
>> JBG
>>
>> 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 ).

>
> Some questions/comments:
>
> 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 [1] 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
> to debate.

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 ) 
containers
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 
however does.

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 
should deploy

> The server roles section has a number of things that should be debated
> 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 discussion

And hopefully sort things out in the process.

JBG