-----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
