F21 System Wide Change: Framework for Server Role Deployment
drago01 at gmail.com
Wed Apr 9 15:30:07 UTC 2014
On Wed, Apr 9, 2014 at 2:45 PM, Stephen Gallagher <sgallagh at redhat.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> On 04/09/2014 06:02 AM, drago01 wrote:
>> On Tue, Apr 8, 2014 at 3:08 PM, Stephen Gallagher
>> <sgallagh at redhat.com> wrote:
>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>>> On 04/08/2014 07:22 AM, drago01 wrote:
>>>> On Tue, Apr 8, 2014 at 12:53 PM, Jaroslav Reznik
>>>> <jreznik at redhat.com> wrote:
>>>>> = Proposed System Wide Change: Framework for Server Role
>>>>> Deployment =
> Change owner(s): Miloslav Trmač <mitr AT volny DOT cz>, Fedora Server
>>>>> Group <server AT lists DOT fedoraproject DOT org >
>>>>> Responsible WG: Server
>>>>> A new D-Bus service, and associated command-line tools, to
>>>>> deploy and manage Server Roles.
>>>>> == Detailed Description == A new D-Bus service will be made
>>>>> available, exposing available server roles, making it
>>>>> possible to deploy, configure and manage them. Appropriate
>>>>> functionality will also be exposed as a command-line
>>>>> == Scope == * Proposal owners: Write, document, package and
>>>>> test the D-Bus API. * Other developers: Possibly use the
>>>>> framework for development of new server roles. * Release
>>>>> engineering: Nothing * Policies and guidelines: Nothing
>>>> "Contingency mechanism: Do not ship the Server product with
>>>> Fedora 21. "
>>>> What? That's not a contingency plan thats a "nuke clause" ..
>>>> we could simply not ship any roles and add it in f21 (given
>>>> that we don't have many roles to begin with).
>>> Yes, it's a nuke clause. This Change Proposal is a blocker for
>>> shipping the Fedora Server. Without completing this Change,
>>> Fedora Server is not meaningful.
>> I am not sure I agree with that ... you can still install the
>> server packages you need which probably is necessary even with this
>> feature because ...
> Sorry, you misunderstand (and I wasn't terribly clear). Fedora is
> still useful as a server, but the Fedora Server *product* has no
> meaningful differentiation from "Fedora with server packages" without
> this. So if we don't deliver this, we may as well not ship specialized
> install media.
No my point was rather this framework will be only useful for a very
limited set of cases (domain controller and database as you stated
so for anyone having a different type of server he/she will have to
install packages by hand anyway. So if this feature its not done it
affect two specific usecases so there is no need for a "nuke clause"
if its not done just get it into F22 (with hopefully a larger set of
>> Which roles are we going to ship with F21?
> The two we're working for in F21 are "Domain Controller" (powered by
> FreeIPA) and "Database Server" (powered by PostgreSQL).
>> Database server and ? This feature is not "meaningful" if common
>> roles are not present. Like file server, web server, application
>> server, could / virt server etc.
> Well, a complete Domain Controller is certainly meaningful.
I didn't say it isn't.
> Also, please understand that the focus of Roles is to provide turn-key
> *infrastructure*, not abitrary applications. So we looked at what we
> could provide that would benefit the most potential use-cases. We
> acknowledged that nearly any application that an end-user would want
> to build would need access to a database server and that in real-world
> deployments, databases are generally kept distinctly separate from the
> server (or VM) providing the application. So it makes sense to provide
> this as a Serevr Role with easy set-up in order to support all the
> other things people want to do.
>> Also if I enable / install / activate the database server role
>> which database do I get?
> We selected PostgreSQL by overwhelming majority vote among the Server
> WG. A MariaDB Role may come in the future, but we're only building one
> right now.
Well the times where database means sql database are over (it depends
on the application(s) the user is going to use).
>> What if my applications need to talk to another database? Same for
>> application server etc.
> If your applications cannot use PostgreSQL, then you can always
> manually set up a different database. You just lose access to the
> simplicity of doing so via the role mechanism. This is additive; it
> doesn't replace the traditional way of doing things, but for the
> common use-cases we support it will make them vastly easier.
Sure I am not saying its not useful its just very limited currently
(lots of setups will have to use traditional methods anyway) and thus
does not warrant to not ship a server product at all if it is not
More information about the devel