FedoraOS Server Platform ( FOSSP )

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

On 11/14/2013 11:44 PM, Miloslav Trmač wrote:
> On Tue, Nov 12, 2013 at 10:41 PM, "Jóhann B. Guðmundsson"
> <johannbg at gmail.com>  wrote:
>> 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:
>>> 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.
> That kind of defeats the point of having a "base" group.  Where will
> we find extra maintainers for doing the same kind of work one more
> time for the two "quite different" bases?

The "Base" layer is on top of the "Core" layer and it cannot be shared 
however the "Core" can and should.

The "Core" needs to cover embedded hence has to be as small as possible, 
the absolute minimum to deliver running system and this is the only part 
that can be "shared" if the aim is to have targeted platforms since for 
example our needs greatly differ from the workstation one thus we ( or 
they ) would have to start nitpick pieces out from the "Base" layer if 
it was shared.

FedoraOS is that "Core Layer" of the operating system
FedoraOS Server Platform "Is the "Base Layer for servers" what *we* 
define should be on it and made available to *all* administrator'
FedoraOS Server Platform Server Role is the "Server Application Layer" 
which provides the functionality the administrator is seeking.

The core layer in the GNU/Linux has becoming an ecosystem of it's own 
with it's own mutual direction with it's own momentum you can try to 
turn an blind eye to the fact that,that freight train is coming and run 
when it's far off in the distance and keep running before it catches up 
with you essentially do what the Debian community does crack open a 
beer, watch it come and cry "I want the core/base OS bits to be hot 
swappable!" as their famous last words or you can layout it's tracks and 
help steer it's direction or simply jump in it, buy a ticket and trust 
it's engineers while enjoying the ride.

The base Layer for servers is something we design,manage and control and 
need to different us from other distribution out there to become the 
server platform of choice for the administrator and that layer needs to 
be separated from the rest since applications in server roles can come 
and go as the marked demands it.

Server application layer is made up of application or application stack 
that each can come and go and each is maintained differently it.

>>> 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
> I'd rather have a fairly small list of things we guarantee to keep
> compatible, driven "top-down" by what the sysadmins will need to
> interact with, rather than "bottom-up" from the upstream components.
> Implicitly importing every feature a project may implement wholesale
> would be fairly restrictive if we ever wanted to change or replace the
> implementation of any particular feature.

Which is one of the reason why I came to the conclusion that we should 
keep each FedoraOS in it's own release cycle in it's own repositiory, 
FedoraOS Server Platform in another and each application in specific 
Fedora Server Role in their own.

This is a community driven distribution and as such we cannot guarantee 
anything heck I have yet to see the maintainer even just *one* that is 
willing to stand behind an long maintained release cycle so we cannot 
depend on anything or anyone but some people like pretend they can.

>>> 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.
> Not the ks files I have seen; they are at least as difficult as shell
> scripts,

Hmm perhaps a bit of history lesson is in order here an no one better to 
tell it other then Bryan Cantrill so I suggest you listen to [¹].

There is a reason why the shell is an administrator tool of chose which 
plays a big part in the success of the *nix platforms in the servers space.

> with the added difficulty that you can't easily test them
> without firing up a scratch machine (VM if you are lucky) and waiting
> for the installation to finish.
>
>> ks files area easy to deploy
> Only if you PXE already setup.

Last time I checked you still could perform a ks install in anaconda on 
a stick or it made somewhere available on the network so ?


>> ks files are easy to adapt
> They mix many of different kinds of information into a single file
> (you can split it into more than one file but there's no standard way
> to do it, so every site differs and tools can't help).

It's not cross distributable either, so you know eventually it will die 
eventually if things continue to progress in certain direction but it 
fit's an short term goal perfectly.

>
>> 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'd much prefer if the configuration management method / file formats
> were, ideally, exactly the same for installation and post-install
> configuration changes: Same GUI interface, same
> $puppet_or_ther_config_mechanism file format and structure, only a
> different command/method to deploy them.

As an long term to goal ( 5 years time ) to achieve sure but in the 
meantime we need something and that something is ks.

> Not only it should be possible to add a role post-install, it should
> be possible to configure the role using exactly the same tools /
> interfaces (having only one set of documentation, and only one
> implementation to test).

Again you cannot achieve this if our end goal is to go provide the "best 
experience" because we cannot tune the installation to mix match of 
roles ( and quite frankly in today's age mixing roles is something that 
sounds more like and old habit ).

You cannot tune a database server and for example a web server on the 
same host heck you don't even partition these in a filesystem level the 
same and today is that really necessary.

>
> Kickstart might be a way to ultimately make the installation happen,
> or something we can ship to allow quickly installing a "clean,
> non-configured" role on a new server, but I don't think it's a
> suitable user interaction method for the common case.

Common/generic is the problem here , which is an place we already are at 
so why this effort if we are not going that extra mile that extra length 
to separate us from the masses?

>
>
>>> 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?
> I was expecting that "the default" is that the existing RPMs managed
> in dist-git continue to exist, and we will continue to make it
> possible to install them (or, perhaps, some fairly large subset of
> them) on the future Fedora Server.  So, even if we didn't ship any
> mail server role in Fedora Server 1.0, existing users could install
> the same kind of RPMs as in the past, and configure using them the
> same way as in the past.  (Well, the users might have to click once or
> twice to say "yes, I really want to set up a server with none of the
> nice roles", or something similar.)

I dont expect that I expect us to cherry pick application throw them 
through a migration process and become an application that files a 
specific role in FOSSP in fact I expect that for each "layer" and we 
clean things up in the process and make us agile again while doing so 
under another brand FedoraOS to keep the separation clear and without 
disrupting our existing Fedora userbase or the workflow they have gotten 
used to.

If you want something generic where you can install *anything* use 
Fedora however if you want something that serves a specific purpose use 
"FedoraOS"

>
> I don't currently see any need to noticeably disrupt the existing user
> base and workflow for the areas where we don't manage to implement
> server roles.  (I'm not sure about the areas where we do implement
> server roles - I could imagine that our integrated setup would make
> some possible deployments of the upstream project that differ from the
> Fedora Server model more difficult to set up, but that's purely
> theoretical at this point.)



We have become this big slow elephant glue together and thrown on the 
floor like a pile of packed spaghetti mess and we are as agile in IT 
industry as that pile of mess.

I thought "fedora.next" was an effort to try to turn the tide around and 
change that. Putting first back into Fedora not in the sense necessary 
of latest and the greatest from upstream but more in the sense, on top 
leading, not keep things, under the same old outdated mentality, the 
same outdate ways of doing things so if the intent is to keep things the 
same I really is not worthwhile for *anybody* participating in this effort.

Quite frankly looking at our whole ecosystem what we need is a 
generation change to flush out that outdated way's of thinking perhaps 
that's what's is slowly making us irrelevant and obsolete.

Anyway to be able to clean us up and make us agile again we need to keep 
that work separated from "Generic Fedora" because it will cause 
disruption and yes I'm aware of what that means work wise but it's 
absolutely necessary for us to do, to succeed in the long run.

>
>>> 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  )
> I think there are far too many upstreams that may make a big
> difference to the release to tie us into a single project.  Looking
> back at the past Fedora releases, can you recall a kernel-only ever
> being the first thing advertised about the release?  IIRC it's pretty
> much always something purely user-space or with a large user-space
> component.

Not following your thought process here if I'm understanding that 
correctly you can apply that argument to the entire distribution it 
would just be x12000

>> B) FOSSP needs to be on it's own release cycle  as in different from the FOS
>> as well as the Server Roles themselves
> "Needs"?  Why?  As a heuristic, keeping a synchronized release cycle
> would allow us to avoid testing cross-release interactions (we'd test
> FOS 1+FOSSP 1, and FOS 2+FOSSP 2, but not FOS 2 + FOSSP 1), so is "by
> default" more preferable to me.

Actually with my QA hat on FOS/FOSSP/FOSSR will break making things more 
manageable pieces for us in QA.

There is but one "FOS" there are 2 other ( base ) layers on top of that, 
the FOSSP and FOSW ( workstation ) ( or FOSD  desktop depending on how 
you view those things ).
The cloud stuff really falls under us and that SCL is being driven in 
the wrong direction and that direction actually slows down progress in 
certain are instead of enhancing it.

>
>> 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 )
> Same as B), and for the Fedora Server I'm picturing more integration
> work than we've done in the past, so being F1rst!!! to package an
> upstream release doesn't necessarily mean the Fedora Server Role
> should be immediately release as well.

Absolutely agree here.

1. https://www.youtube.com/watch?v=S0mviKhVmBI#t=1524