Re: F21 System Wide Change: Framework for Server Role Deployment

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 04/09/2014 07:28 PM, Rob K wrote:
> On 10/04/2014 7:50 AM, Jeffrey Ollie wrote:
> 
>> +1 - What are 'server roles'? Are we just reinventing 
>> Ansible/Puppet/et al here? Yeah, why is someone spending time
>> creating a new Fedora-specific configuration management system
>> rather than just shipping an Ansible playbook or a Salt formula
>> or whatever?
> 
> Pretty much this. The world has enough reinvented wheels as it is.
> I'd like to see a clear use case and implementation example
> without handwaving about dbus and so on.
> 

Ok, first we probably need to clarify a few things: the Server Role
Deployment Framework is meant to describe a layer more than a specific
implementation.

The purpose of this layer is to provide a vastly simplified mechanism
for deploying common infrastructure services in a best-practices
manner. The idea is that this layer should intentionally limit choices
to those that are known to work in the vast majority of cases. This
will hopefully make our volunteer support teams happy, as it means
that there should be a reduction in the number of edge-cases and poor
configuration choices.

Second, we really envision this as being the mechanism that a tool
such as Ansible would call out to in order to perform these
operations. Instead of writing a complicated and custom configuration
for complex services like a domain controller, an ansible playbook
should be able to instead just invoke our tool (or D-BUS API, or
OpenLMI remote interface, etc.) to do all of the work for them.

In other words, instead of coordinating the placement of a dozen or so
configuration files and custom command-line tools to set up a service,
these config management utilities should instead be able to operate
against a single interface.

Furthermore, we expect this approach to improve our users' experience
when it comes to software updates on their systems. Implicit in the
inclusion of a package in a Server Role is also an additional
guarantee on its stability: we intend to end the days where packages
that need to be tested together are instead only testing on their own
(a classic example being the semi-regular cases where a 389DS update
causes deployments of FreeIPA to fail). By ensuring that these
packages are all tested as a unit, we can make much more confident
claims about Fedora's suitability as a production server.

I hope that addresses some of your concerns.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlNGhtcACgkQeiVVYja6o6Oh8ACgpmctP4O+lLEWflu3XSiLfV54
TUcAn1Ju0P461WXUsnS5rEGKTBHVSblO
=3oPJ
-----END PGP SIGNATURE-----
-- 
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct





[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux