FedoraOS Server Platform ( FOSSP )

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

On 11/13/2013 08:45 PM, Simo Sorce wrote:
> On Wed, 2013-11-13 at 19:29 +0000, "Jóhann B. Guðmundsson" wrote:
>> I can answer that quickly you cant install multiple roles afterwards.
>>
>> And to answer your next question no you cannot switch roles either.
>>
>> What you can do is install FOSSP and then manually install mariadb and
>> corosync ( and all the server "generic" bits we on top of that ) and set
>> things up yourself.
>>
>> Server roles will need to be each in their own branch, with their own
>> repository and each on their own release cycle.
> I tend to disagree here. It would make any mistake an horrible
> experience for the user.

Explain in further detail.

>> This is what you would go in the FOSS home page help to choose the
>> server role(s) you need and would even as to delivery you ( with ks we
>> might be able to pull that of harder with VM's  ) optimized server role
>> for you infrastructure.
> I fail to parse this phrase.

Yeah understandably so thunderbird is freezing and failing faster, 
crashing harder here on F20 beta so I'm retyping ever thing so often.

In anycase we are no way near what I was referring to so you can just 
ice that thought for now.

>    
>>>> 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 )
>>> What do you mean by 'branches' in this case?
>> FOS and it's bits on it's own FOS master branch with their own ( yum )
>> repository with it's own release cycle
>> FOSSP and it's bits on it's own FOSSP master branch with their own ( yum
>> ) repository ( all server bits belong there ) with it's own release cycle
>> Each application in a defined server roles and it's bits on it's own
>> master branch with their own ( yum ) repository with it's own release cycle
> Isn't this going to create a lot of work and a lot of chance for
> incompatibility between the repositories ?

Depends on how we move forward and how you look at this.

So far a lot seem to be viewing and wanting to mutual existing Fedora 
into the outcome of all the WG  while re-using the same base to most extent
( which is what we are doing already so why are we bothering with this 
effort)

I do not share that vision and I actually thought this whole effort was 
about a change.

>>>> 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  )
>>> Why?
>> Inevitable evolution of how the coreOS bit are getting intertwined with
>> the kernel which means you can either try to continue to ignore that
>> fact or now re-act to it with that in mind.
> if the coreOS runs faster than all the bits we want to lie on top, how
> do we rely on it ?

With my QA hat on I would actually it would be more reliably then those 
bits are now separated.


>>>> 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 )
>>> How would that work? So, I install Fedora Server and install the
>>> mariadb role. in 3 months, a new mariadb upstream is released. Would
>>> this be pushed out as an update? Or would it be opt in if I wanted it?
>>> or ?
>> Not following you, you can always decide to update ( or not ) to the
>> bits made available to.
> What is the maintenance scheme for each role in your proposal ?

Minimal expectation of an maintenance scheme for an server application 
to be applicable to an server role is something we define together as 
well of the rest of server roles expectations.

>> I'm not sure you have realized this since I have not written it on the
>> FOSSP draft yet but we would be working closely with the mariadb
>> maintainers ( if they are willing to participate in this effort )
>> defining mariadb as one of the available relational dbms database
>> services server role and they themselves have full control over how long
>> they intend to support it as well as to how frequent they push update to
>> it to their mariadb server role repository.
> This means each role would vary wildly in stability. One group of
> developers could be rightfully (for a *server* product) conservative and
> another could keep pushing unstable changes that keep breaking the
> system, I do not find your plan workable.
>
>> We can only come up with a recommendation guidelines to server roles
>> where we say we would like you to do things this way but you are not
>> *forced* to follow it.
>>
>> One of the concerns that I have been approached with by maintainers in
>> relation to the work we are doing here, is if we are signing them up for
>> something they dont want to take a part of and my approach most
>> certainly does not quite the opposite and that's something to bear in
>> mind as well.
> I think the only thing we should really care for are prompt security
> releases and really critical bugs, if a product is not further updated
> it is not a big deal, but it would be a lot worse if a product is
> updated every 3 months to the latest and greatest (and most borked)
> release.

Re-stating ( since it's one of our role as an WG ).

" Minimal expectation of an maintenance scheme for an server application 
to be applicable to an server role is something we define together as 
well of the rest of server roles expectations."

JBG