5:08 a.m.
Greetings you all
So here's the thing throughout Fedora history there has always been the
attempt to put a one label ( target users ) on the entire community and
always has it failed ( understandably so ) and trying to do so here in
the form of an single "PRD" for the server community will fail in the
same manner since each of the existing server application or application
stack exist to address a particular problem or fill in a missing space
in the IT sector which means each of this exist to address *different*
set of target audience thus we will never be able to .
In anycase people have failed to realise this all this after all these
years and still try to put one label on everything in a such a diverse
community ( and in our case the server aspect of the project ) and since
I suck at writing analogies or explain why that is people simply have to
come to conclusion by themselves.
Now what I believe what we stand for, what our true purpose is, our
core, our essence, our mission statement Fedora Server WG can be
summarized into this one sentence...
"Fedora Server WG where we discover product solutions that work well for
our users, our administrators, our developers and our project."
--> T-shirt anyone <-- ;)
We should be identifying which server applications work well on their
own or work well with each other out of those 500+ we have ( think of
them as ingredients ).
Once we have done that we add a Fedora secret sauce ( what we feel they
are lacking for the 21 century which for example could be that missing
configuration api ) and form a PRD for that recipe and implement it.
In anycase that's my view and we need to hash out if people think of
"Fedora server" as single product and an PRD can be applied to it as
such or multiple products.
JBG
7:26 a.m.
On Fri, 2013-11-01 at 10:08 +0000, "Jóhann B. Guðmundsson" wrote:
Greetings you all
So here's the thing throughout Fedora history there has always been the
attempt to put a one label ( target users ) on the entire community and
always has it failed ( understandably so ) and trying to do so here in
the form of an single "PRD" for the server community will fail in the
same manner since each of the existing server application or application
stack exist to address a particular problem or fill in a missing space
in the IT sector which means each of this exist to address *different*
set of target audience thus we will never be able to .
In anycase people have failed to realise this all this after all these
years and still try to put one label on everything in a such a diverse
community ( and in our case the server aspect of the project ) and since
I suck at writing analogies or explain why that is people simply have to
come to conclusion by themselves.
Now what I believe what we stand for, what our true purpose is, our
core, our essence, our mission statement Fedora Server WG can be
summarized into this one sentence...
"Fedora Server WG where we discover product solutions that work well for
our users, our administrators, our developers and our project."
--> T-shirt anyone <-- ;)
We should be identifying which server applications work well on their
own or work well with each other out of those 500+ we have ( think of
them as ingredients ).
Once we have done that we add a Fedora secret sauce ( what we feel they
are lacking for the 21 century which for example could be that missing
configuration api ) and form a PRD for that recipe and implement it.
In anycase that's my view and we need to hash out if people think of
"Fedora server" as single product and an PRD can be applied to it as
such or multiple products.
Jóhann,
I've been in the integration business since forever, starting many, many
years ago when I was a simple Unix administrator.
What you say is not at all w/o merit, but I do not think it is the goal
of the Server WG. Integrating applications is easier said than done, and
takes a lot of time, and can't be done in isolation.
I think we should definitely look at the big picture, and do the best we
can to provide defaults, configurations or guides, to make as many
components as possible play together. But it is not our core mission to
go and modify single components. I think our mission is more to interact
with upstream and tell them what we think would greatly improve the
situation for us and encourage them to provide those changes. In
exchange we should react fast when they provide us what we asked,
backporting or rebasing packages fast so upstream can see the changes
requested flow rapidly into Fedora Server, with the hope of creating
positive feedback loops.
I think what we want to do primarily though is build a foundation for
all the interesting projects to run on. Provide the best possible,
solid, core OS, people can depend on, where changes are pondered not
only against the benefit they can bring to new admins but also how
disruptive they would be to developers and existing admins. Our duty is
to provide excellent transition tools for those times when disruptive
change is necessary w/o having the ecosystem suffer for multiple
releases.
Simo.
--
Simo Sorce * Red Hat, Inc * New York
8:17 a.m.
On Fri, Nov 1, 2013 at 1:26 PM, Simo Sorce <simo(a)redhat.com> wrote:
What you say is not at all w/o merit, but I do not think it is the
goal
of the Server WG. Integrating applications is easier said than done, and
takes a lot of time, and can't be done in isolation.
I think we should definitely look at the big picture, and do the best we
can to provide defaults, configurations or guides, to make as many
components as possible play together. But it is not our core mission to
go and modify single components. I think our mission is more to interact
with upstream and tell them what we think would greatly improve the
situation for us and encourage them to provide those changes.
I'm leaning towards the view that "upstream first" doesn't work well
when trying to integrate the high number of individual components that
we are now facing, and especially the degenerate version "upstream
only" really doesn't work.
I think what we want to do primarily though is build a foundation
for
all the interesting projects to run on. Provide the best possible,
solid, core OS, people can depend on, where changes are pondered not
only against the benefit they can bring to new admins but also how
disruptive they would be to developers and existing admins. Our duty is
to provide excellent transition tools for those times when disruptive
change is necessary w/o having the ecosystem suffer for multiple
releases.
Agreed completely.
Mirek
8:15 a.m.
On Fri, Nov 1, 2013 at 11:08 AM, "Jóhann B. Guðmundsson"
<johannbg(a)gmail.com> wrote:
"Fedora Server WG where we discover product solutions that work
well for our
users, our administrators, our developers and our project."
--> T-shirt anyone <-- ;)
We should be identifying which server applications work well on their own or
work well with each other out of those 500+ we have ( think of them as
ingredients ).
Once we have done that we add a Fedora secret sauce ( what we feel they are
lacking for the 21 century which for example could be that missing
configuration api ) and form a PRD for that recipe and implement it.
I agree with the focus on "product solutions" and the end-user-visible goal.
From an implementation point of view, I don't think creating many
individual "recipes" is optimal.
If you look at user's interaction, and correspondingly
implementation/packaging/integration complexity, for a server-provided
service (e.g. a daemon), and at the underlying "infrastructure" (for
lack of better word), it basically goes like this:
- The service: set up access rights 1-5 primary parameters (mail
server: place to store mail; DB server: place to store the database,
access rights; ...)
- The underlying server "infrastructure": set up
- Networking (several parameters per interface, perhaps bonding/vLANs / ...
- Storage (arbitrarily complex stack)
- Identity database
- Setting up updates
...
(Obviously the situation is actually more complex than "1-5 primary
parameters" for the service, there may be dozens or hundreds of
tunables, but the same is true for the underlying server
infrastructure components, so the relationship holds.)
So, it doesn't make much sense to me to make individual recipes
starting with the application, and potentially diverging in the
"infrastructure"; rather, the "infrastructure" should be common and
the base of the product, with the various services being treated more
like "applications" for the infrastructure (potentially some
"bundled"
and some separate). That doesn't mean that the
services/"applications" are less important, but it does mean that the
"infrastructure" is the same for all of them (which may require
adjusting both the "applications" and the "infrastructure").
Mirek
10:46 a.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 11/01/2013 09:15 AM, Miloslav Trmač wrote:
On Fri, Nov 1, 2013 at 11:08 AM, "Jóhann B. Guðmundsson"
<johannbg(a)gmail.com> wrote:
> "Fedora Server WG where we discover product solutions that work
> well for our users, our administrators, our developers and our
> project." --> T-shirt anyone <-- ;)
>
> We should be identifying which server applications work well on
> their own or work well with each other out of those 500+ we have
> ( think of them as ingredients ).
>
> Once we have done that we add a Fedora secret sauce ( what we
> feel they are lacking for the 21 century which for example could
> be that missing configuration api ) and form a PRD for that
> recipe and implement it.
I agree with the focus on "product solutions" and the
end-user-visible goal.
From an implementation point of view, I don't think creating many
individual "recipes" is optimal.
Well, I think this may depend on how we define such recipes. I think
there's certainly value in defining a sert of roles (possibly stolen
directly from the Evil Empire) that we can provide as a
standard-and-recommended approach to certain problem spaces.
For example, while Fedora will likely always provide packages for
OpenLDAP and 389 DS, it probably makes sense for us to say "FreeIPA
(built atop 389 DS) is the recommended LDAP server in the Fedora
Server". We can then focus our efforts on making the setup and
configuration experience of FreeIPA be awesome. I'd like to see us do
this with something like pre-written configuration tools (ansible,
puppet, cfengine, etc.) and provide a simplistic UI for deploying
them. (This could be a remote GUI, a curses UI or *other*. I'm not
defining that right now and don't want to rat-hole)
For some other examples (and yes, some of these could easily become
flamewars):
Fedora Server prefers postfix as the SMTP server and provides a
role-assignment to set it up.
Fedora Server prefers Samba 4 as the file-sharing server and provides
a role-assignment to set it up.
Fedora Server prefers FreeIPA (again) as the DNS server and provides a
role-assignment to set it up.
Fedora Server prefers OpenSSH-lpk as the secure-shell server and
installs it by default.
Fedora Server prefers Apache HTTPD 2.4 as the web-server and provides
copious documentation on how to tweak it.
Fedora Server prefers PostgreSQL as a database server and provides a
role-assignment to set it up (and create additional databases).
And so on. I'm sure there are plenty of other examples we could come
up with.
A few points:
1) We should allow anyone who wants to install an alternative to do
so, but they may need to fend for themselves the way they do now.
2) We are selecting a very limited list of solutions that we are going
to polish up and make easy to deploy in recommended configurations.
3) The use of our simplified tools to deploy must not interfere with
the ability of the administrator to tweak them the way they can today.
We are only talking about providing useful defaults to get people up
and running quickly.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.15 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlJzzNoACgkQeiVVYja6o6MBGgCfW+Fse/bNMRf7ncZuwir2Pba0
/+QAn21Y8mZ30ZDMNz4g9PHL1GwPtEhz
=FGMQ
-----END PGP SIGNATURE-----
3829
days inactive
3829
days old
server@lists.fedoraproject.org
4 comments
4 participants
participants (4)
-
Jóhann B. Guðmundsson -
Miloslav Trmač -
Simo Sorce -
Stephen Gallagher