FedoraOS Server Platform ( FOSSP )

[Miloslav Trmač]

On Fri, Nov 15, 2013 at 1:04 PM, "Jóhann B. Guðmundsson"
<johannbg at gmail.com> wrote:
> 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?
>
<snip>
> 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'

Never mind the naming, what's the point of the base WG if we won't use
what they produce?


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

I can't see how release cycles and repositories (which are pretty much
per-package) are related to the concern that per-package stability
promises may not be what we want.


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

Yes, primarily, "you don't have any other option".  (Insert rant about
shell making the rare things easy and the common things difficult,
starting with quoting variable expansions.)

Regardless whether shell is a good language or not, it is a
_language_, hence impossible to generally manage with higher-level
software.

>>> 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
Right, I forgot about that option.

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

I think "write a kickstart shell script" or "set up your own
puppet-based management infrastructure" is exactly where we are at.
We can go many extra miles further from there :)


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

"Sometimes you get to do a complete reboot, and when you can, it's a
beautiful thing" (or something like that, I can't find the exact quote
about Java).  Yes, I'm also maintaining a list of items a
from-the-ground-up-rewritten-and-cleaned-up OS should have (starting
with a better language, and a real common runtime so that there aren't
hundreds of string and hashing libraries, and on from there).

I'm afraid Fedora.next isn't that complete-cleanup OS though.
1) We don't have the consensus on the need to reinvent.
("kickstarts/puppet/shell/X11/fork()/... work just fine, thank you")
2) We don't have the manpower and time.  It took ~10 years for Linux
to become reasonably-feature complete, with a world-wide collaboration
pretty much on one project, _which was sorely needed because nothing
like it existed_.  We don't have 10 years, we are one project among
many, and everyone has other options (perhaps not as good but better
than spending a month programming a missing component).
3) The various upstreams will continue expanding and modifying the
"Linux" ecosystem faster than we can "clean it up" for FedoraOS.

(Or perhaps you have a much more limited "clean up" in mind?)

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

The trouble is that flushing out that outdated ways of thinking
automatically implies flushing out all the working software with no
replacement but well-intentioned ideas.  So I think we can practically
only choose _specific areas that matter to us_ (perhaps configuration
and monitoring) and fix those, and _only_ those.

Perhaps, sometime somewhere, someone will start from scratch, and
design a complete new thing that is so great that the community will
eventually migrate, but I honestly can't see that.  I've seen far too
many "this is my hobby OS kernel that has better API than Linux",
"this is my hobby language that is better than C++ and Java", "this is
my better IPC", "this is my unified configuration library" projects
that have had no chance to ever gather critical mass.

Of course, that leads to the question "why can't Fedora lead the
change? It is big enough after all".  Yes, perhaps it is big enough,
but _only if we stay as big as we are_, not if we throw out all
existing packages and then try to introduce a new mechanism from the
position of a big distribution while actually being one of the
smallest ones.

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

I don't think it's necessary, any more.  It might have been necessary
5 years ago, but now the kernel has enough namespacing technology (...
which I otherwise... don't like) that it's fairly feasible to keep
compatibility.  For example, create /FedoraOld1/{bin,etc,usr,...}, let
the old system live in there, and take over / for the all new design.
(FedoraOld1 because there _will_ be FedoraOld2; we wouldn't get it
exactly right either.)

Anyway, to me this is all hypothetical at this point - we might need a
disruptive change some time, but until we are actually faced with an
user-visible functionality that needs one we shouldn't let the
possibility of disruption stop us from getting non-disruptive work
done.
    Mirek