FedoraOS Server Platform ( FOSSP )

[Miloslav Trmač]

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?


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


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

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

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

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

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.


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

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

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

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