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
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.
On Fri, Nov 1, 2013 at 1:26 PM, Simo Sorce simo@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
On Fri, Nov 1, 2013 at 11:08 AM, "Jóhann B. Guðmundsson" johannbg@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
-----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@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.
server@lists.fedoraproject.org
-
Jóhann B. Guðmundsson -
Miloslav Trmač -
Simo Sorce -
Stephen Gallagher