On 11/14/2013 11:44 PM, Miloslav Trmač wrote:
On Tue, Nov 12, 2013 at 10:41 PM, "Jóhann B. Guðmundsson"
> 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(a)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
>> 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
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
> learn since they are already familiar with ks syntax.
> Dnf in the distant future could use them to directly install into ( os )
> 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
> 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
If you want something generic where you can install *anything* use
Fedora however if you want something that serves a specific purpose use
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
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.