FedoraOS Server Platform ( FOSSP )

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

On 11/13/2013 04:19 PM, Kevin Fenzi wrote:
> On Tue, 12 Nov 2013 21:41:34 +0000
> "Jóhann B. Guðmundsson"<johannbg at gmail.com>  wrote:
>
> ...snip...
>
>>> 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 )
> I strongly disagree, and here's why: :)
>
> First, what would be the difference between say (for example) the
> MariaDB and Postgresl kickstart files? Would it just be the things
> listed in the %packages section? or changes beyond that?

Changes beyond. ( otherwise this entire server wg effort is meaningless )

In other words simply doing yum install MariaDB on Fedora != the same 
experience as deploying FOSSP with the MariaDB in a Database Role via 
our delivery methods.

> If it's just in the packages section, we aren't adding any value there.
> Users could as easily click that role in the installer, or use their
> own kickstart with their more detailed local config. Or yum/dnf install
> it after the fact. Shipping our kickstart there just means more
> deliverables for us that no one would use.
>
> If it's more than just the packages section, then we are making it so
> you can only install roles via this method and can't easily do so after
> the install.

Yes that is the purpose we are delivering best out of the box experience 
in server roles.

>   If you install MariaDB role and want to add say Corosync
> how do you do that?

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.

> If we instead have (at most) one ks file (just for the base install/our
> best practices), and use comps groups for all the roles, it will
> instead be easy to mix and match as many or as few roles as the end
> user wants.
>
> Additionally, comps groups would be portable to the other working
> groups deliverables. In cases where say a workstation user wanted to
> install mariadb to test something, they could easy do so. If we
> delivered a kickstart they could not.

For the first we are not going to be play mix match with what ever the 
workstation or other WG comes up with and what we are working on.

>>> 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.
> ok, thats a valid point of view. However, we have what we have, so we
> should communicate with them and see what we can work out.

Yeah sure we can try that.

>>> 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
> This could just be organized in comps so it's clear... perhaps using a
> server keyword or something higher level.

No it cannot so ignore comps altogether we need alternative route and 
this tool is entirely outside comps what so ever.

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.

>   
>>> 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?
> As opposed to? I think building on what parts of what we have that are
> still good for our needs is a much better idea than burning down
> everything and building new stuff that is very similar, or serves the
> same purpose.

We would not be burning down everything Fedora would still be Fedora 
generically useful or useless depending how you look at it.

FedoraOS as I see it is something we add separately to the side ( at 
least to begin with ) and has a specific purpose in each of it's "layer".


>   
>> 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.
> No idea. I have not seen your FedoraOS proposal.
>   
>> 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 ).
> Only if we all agree this is the way to go.
>
> I think 9 or 15 roles is going to be a lot of work, and not sure if we
> will be able to handle that. But perhaps it's good to start big and
> work from there.

If you think this is starting big ( I was thinking this was starting 
small )

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

>>> 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  )
> 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.


>> B) FOSSP needs to be on it's own release cycle  as in different from
>> the FOS as well as the Server Roles themselves
> I think there's a number of disadvantages to splitting out release
> cycles per product. I guess it will somewhat depend on what the Base
> group decides on. Having seperate releases means that the different
> products can't share things like freezes, press cycles, testing of some
> components, etc.

I see nothing but advantage in what you see as disadvantage.

>> 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.

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.

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.

JBG