On Tue, 12 Nov 2013 21:41:34 +0000
"Jóhann B. Guðmundsson" <johannbg(a)gmail.com> wrote:
> 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.
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?
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. If you install MariaDB role and want to add say Corosync
how do you do that?
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
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.
> We should talk with the Cloud WG and confirm what stuff they
> 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
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.
> I like the idea of getting something/fedup to provide some kind
> '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.
> 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
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
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
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.
And keeping things separate from "Fedora" in separated
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?
> 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? The kernel is one of the more stable parts of the platform, and
it's release cycle is somewhat fluid. Additionally, lots of the time
people don't see much change there with new stuff.
B) FOSSP needs to be on it's own release cycle as in different
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
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
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?