-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
As mentioned before, I've attempted to put together a user-perspective on what "roles" should look like in Fedora Server, using FreeIPA as a representative example. I want to thank Andreas Nilsson of the Cockpit project for helping out substantially with the mock-ups.
The proposal is fairly wordy, so I put it up on my blog for perusal. I can copy it into the Server WG blog later, if we agree it's not completely off-base.
http://sgallagh.wordpress.com/2013/12/09/proposal-freeipa-role-for-fedora-se...
On Mon, 2013-12-09 at 14:53 -0500, Stephen Gallagher wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
As mentioned before, I've attempted to put together a user-perspective on what "roles" should look like in Fedora Server, using FreeIPA as a representative example. I want to thank Andreas Nilsson of the Cockpit project for helping out substantially with the mock-ups.
The proposal is fairly wordy, so I put it up on my blog for perusal. I can copy it into the Server WG blog later, if we agree it's not completely off-base.
http://sgallagh.wordpress.com/2013/12/09/proposal-freeipa-role-for-fedora-se...
Uhmmmm let me try to decipher what a role is in your view, based on the process you described.
1. A set of packages 2. A configuration mechanism to make a basic configuration of such packages, including pre-requisites. 3. A UI (whether graphical or command line base doesn't matter) to drive the process.
Is that all ?
Simo.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 12/09/2013 07:45 PM, Simo Sorce wrote:
On Mon, 2013-12-09 at 14:53 -0500, Stephen Gallagher wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
As mentioned before, I've attempted to put together a user-perspective on what "roles" should look like in Fedora Server, using FreeIPA as a representative example. I want to thank Andreas Nilsson of the Cockpit project for helping out substantially with the mock-ups.
The proposal is fairly wordy, so I put it up on my blog for perusal. I can copy it into the Server WG blog later, if we agree it's not completely off-base.
http://sgallagh.wordpress.com/2013/12/09/proposal-freeipa-role-for-fedora-se...
Uhmmmm let me try to decipher what a role is in your view, based on the process you described.
- A set of packages 2. A configuration mechanism to make a basic
configuration of such packages, including pre-requisites. 3. A UI (whether graphical or command line base doesn't matter) to drive the process.
Is that all ?
I was too focused on the user experience explanation that I missed a few conceptual pieces I wanted to talk about. I'll write a second blog post on that in a little while, but here is the basic gist of it:
== Mechanism == * We want to have a role inventory so that we can trivially query which roles are deployed on a target system (with additional per-role meta-data). Ideally, I'd like to see us also presenting this inventory via discovery mechanisms like Avahi or OpenSLP for other monitoring tools to consume. * We should support role dependencies and conflicts. For example, it's acceptable to have both the "BIND 9" role in our tool belt, as well as the "FreeIPA DNS Server" role (which uses BIND 9 under the hood but integrates its operation with FreeIPA). The latter should only be possible to deploy to a server that already has the FreeIPA role deployed, whereas the BIND 9 role could be deployed to a machine without FreeIPA installed.
== Policy Compliance == We talked a bit about having strict upgrade policies and backwards-compatibility guarantees. I'd like to highlight a few specific policies we should require: * Updates must occur without requiring user intervention beyond initiating it. No questions should be posed to the user. * Updates must be atomic; if a role incorporates multiple underlying technologies (e.g. FreeIPA with 389 and MIT Kerberos), the complete set must be upgraded together with a complete set of tested components. Do not update piecemeal; it usually breaks. * *Upgrades* to major new releases that offer substantially different functionality and that have no fully automatic upgrade path should NOT be considered an update to the current role. E.g. a BIND 9 role must not upgrade to a BIND 10 role. Instead, it should be expected that a new role is created and tools *may* be offered to port the configuration. (Note: Upgrade tools are absolutely not a short-term goal. In practice, most environments would likely just deploy a new role on a new [physical|virtual] machine anyway).
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
On Tue, 10 Dec 2013 07:13:30 -0500 Stephen Gallagher sgallagh@redhat.com wrote:
I was too focused on the user experience explanation that I missed a few conceptual pieces I wanted to talk about. I'll write a second blog post on that in a little while, but here is the basic gist of it:
== Mechanism ==
- We want to have a role inventory so that we can trivially query
which roles are deployed on a target system (with additional per-role meta-data). Ideally, I'd like to see us also presenting this inventory via discovery mechanisms like Avahi or OpenSLP for other monitoring tools to consume.
I think we should be very very careful there not to provide too much help to attackers. :) "Oh, that machine is telling me it's the FreeIPA server version foo. Cool"
- We should support role dependencies and conflicts. For example,
it's acceptable to have both the "BIND 9" role in our tool belt, as well as the "FreeIPA DNS Server" role (which uses BIND 9 under the hood but integrates its operation with FreeIPA). The latter should only be possible to deploy to a server that already has the FreeIPA role deployed, whereas the BIND 9 role could be deployed to a machine without FreeIPA installed.
What implementation do you see for this? packages? config file?
== Policy Compliance == We talked a bit about having strict upgrade policies and backwards-compatibility guarantees. I'd like to highlight a few specific policies we should require:
- Updates must occur without requiring user intervention beyond
initiating it. No questions should be posed to the user.
- Updates must be atomic; if a role incorporates multiple underlying
technologies (e.g. FreeIPA with 389 and MIT Kerberos), the complete set must be upgraded together with a complete set of tested components. Do not update piecemeal; it usually breaks.
Yeah, or if it is peicemeal, make sure anything that goes out is tested to not break things.
- *Upgrades* to major new releases that offer substantially different
functionality and that have no fully automatic upgrade path should NOT be considered an update to the current role. E.g. a BIND 9 role must not upgrade to a BIND 10 role. Instead, it should be expected that a new role is created and tools *may* be offered to port the configuration. (Note: Upgrade tools are absolutely not a short-term goal. In practice, most environments would likely just deploy a new role on a new [physical|virtual] machine anyway).
Yeah.
kevin
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 12/10/2013 09:24 AM, Kevin Fenzi wrote:
On Tue, 10 Dec 2013 07:13:30 -0500 Stephen Gallagher sgallagh@redhat.com wrote:
I was too focused on the user experience explanation that I missed a few conceptual pieces I wanted to talk about. I'll write a second blog post on that in a little while, but here is the basic gist of it:
== Mechanism == * We want to have a role inventory so that we can trivially query which roles are deployed on a target system (with additional per-role meta-data). Ideally, I'd like to see us also presenting this inventory via discovery mechanisms like Avahi or OpenSLP for other monitoring tools to consume.
I think we should be very very careful there not to provide too much help to attackers. :) "Oh, that machine is telling me it's the FreeIPA server version foo. Cool"
I didn't say it had to be broadcast. I was thinking more of using something like OpenLMI, which requires authentication, to query it.
- We should support role dependencies and conflicts. For
example, it's acceptable to have both the "BIND 9" role in our tool belt, as well as the "FreeIPA DNS Server" role (which uses BIND 9 under the hood but integrates its operation with FreeIPA). The latter should only be possible to deploy to a server that already has the FreeIPA role deployed, whereas the BIND 9 role could be deployed to a machine without FreeIPA installed.
What implementation do you see for this? packages? config file?
I was intentionally avoiding specifying an implementation for fear that we'd end up talking about that rather than high-level goals and user experience. Remember, we don't need an implementation for the PRD, just a set of things we want to achieve.
== Policy Compliance == We talked a bit about having strict upgrade policies and backwards-compatibility guarantees. I'd like to highlight a few specific policies we should require: * Updates must occur without requiring user intervention beyond initiating it. No questions should be posed to the user. * Updates must be atomic; if a role incorporates multiple underlying technologies (e.g. FreeIPA with 389 and MIT Kerberos), the complete set must be upgraded together with a complete set of tested components. Do not update piecemeal; it usually breaks.
Yeah, or if it is peicemeal, make sure anything that goes out is tested to not break things.
We've proven in the past that we don't have the resources to do a complicated matrix. I'd like to hear from QA on this, but I suspect enforcing full-role testing will make life easier for them.
Obviously, "bug fixes" should have some leeway, but no one should be upgrading major versions independently of a role upgrade.
- *Upgrades* to major new releases that offer substantially
different functionality and that have no fully automatic upgrade path should NOT be considered an update to the current role. E.g. a BIND 9 role must not upgrade to a BIND 10 role. Instead, it should be expected that a new role is created and tools *may* be offered to port the configuration. (Note: Upgrade tools are absolutely not a short-term goal. In practice, most environments would likely just deploy a new role on a new [physical|virtual] machine anyway).
Yeah.
kevin _______________________________________________ server mailing list server@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/server
On Mon, Dec 9, 2013 at 8:53 PM, Stephen Gallagher sgallagh@redhat.com wrote:
http://sgallagh.wordpress.com/2013/12/09/proposal-freeipa-role-for-fedora-se...
This seems like a nice installation path. For a "featured role" I'd expect more than a nice installation, though: - Automatic integration to the machine-wide monitoring system (at the very least, answering "is it up?", ideally also some key metrics) - Automatic inclusion into the machine's backup regime, if any, including any possible special tasks (creating a consistent DB snapshot to be backed up, for example) - Integration into the machine's configuration system (e.g. reacting to networking setup changes?)
Also, the same installation functionality should be available for automated deployment methods (this is kind of weird for the One And Only IPA server, more necessary for any other role). Mirek
On Tue, 2013-12-10 at 15:06 +0100, Miloslav Trmač wrote:
On Mon, Dec 9, 2013 at 8:53 PM, Stephen Gallagher sgallagh@redhat.com wrote:
http://sgallagh.wordpress.com/2013/12/09/proposal-freeipa-role-for-fedora-se...
This seems like a nice installation path. For a "featured role" I'd expect more than a nice installation, though:
- Automatic integration to the machine-wide monitoring system (at the
very least, answering "is it up?", ideally also some key metrics)
- Automatic inclusion into the machine's backup regime, if any,
including any possible special tasks (creating a consistent DB snapshot to be backed up, for example)
- Integration into the machine's configuration system (e.g. reacting
to networking setup changes?)
I would like it to see react as in preventing changes too where necessary, many roles will break if you change the hostname for example, but for a FreeIPA Server that acts as DNS server also changing the IP address should be prevented to change unless you go through some special procedure.
Also, the same installation functionality should be available for automated deployment methods (this is kind of weird for the One And Only IPA server, more necessary for any other role).
You are forgetting replicas :)
Simo.
On Tue, 10 Dec 2013 15:06:27 +0100 Miloslav Trmač mitr@volny.cz wrote:
On Mon, Dec 9, 2013 at 8:53 PM, Stephen Gallagher sgallagh@redhat.com wrote:
http://sgallagh.wordpress.com/2013/12/09/proposal-freeipa-role-for-fedora-se...
This seems like a nice installation path. For a "featured role" I'd expect more than a nice installation, though:
- Automatic integration to the machine-wide monitoring system (at the
very least, answering "is it up?", ideally also some key metrics)
- Automatic inclusion into the machine's backup regime, if any,
including any possible special tasks (creating a consistent DB snapshot to be backed up, for example)
- Integration into the machine's configuration system (e.g. reacting
to networking setup changes?)
So, would that imply that we need at least:
machine wide monitoring backups
roles first that all other roles depend on?
Also, the same installation functionality should be available for automated deployment methods (this is kind of weird for the One And Only IPA server, more necessary for any other role). Mirek
Yeah, I still need to sit down and look at cockpit for this, but ideally: gui, tui and pass it data modes are desired from any solution we pick.
kevin
On Tue, Dec 10, 2013 at 3:26 PM, Kevin Fenzi kevin@scrye.com wrote:
On Tue, 10 Dec 2013 15:06:27 +0100 Miloslav Trmač mitr@volny.cz wrote:
This seems like a nice installation path. For a "featured role" I'd expect more than a nice installation, though:
- Automatic integration to the machine-wide monitoring system (at the
very least, answering "is it up?", ideally also some key metrics)
- Automatic inclusion into the machine's backup regime, if any,
including any possible special tasks (creating a consistent DB snapshot to be backed up, for example)
- Integration into the machine's configuration system (e.g. reacting
to networking setup changes?)
So, would that imply that we need at least:
machine wide monitoring backups
roles first that all other roles depend on?
The way I think about it, no, these would not be installable roles - there would be a basic infrastructure included in every Server install (whether that is a daemon or only a .d directory to drop configuration into is an implementation aspect); one would never decide to "install" machine-wide monitoring, it should be available for every system out of the box.
I'm not sure there would be a consensus for this approach, having Server somewhat "fat", even if some subset of users would not use all of the functionality - i.e. with a "really minimally minimal" setup a) unsupported, b) delegated to Cloud, c) a second-class citizen. Mirek
On Tue, Dec 10, 2013 at 04:41:27PM +0100, Miloslav Trmač wrote:
The way I think about it, no, these would not be installable roles - there would be a basic infrastructure included in every Server install (whether that is a daemon or only a .d directory to drop configuration into is an implementation aspect); one would never decide to "install" machine-wide monitoring, it should be available for every system out of the box.
THIS!
IMHO, this is the thing that can be a major differentiator for the Fedora Server build - a tested, integrated infrastructure underlying the project (or whatever it's currently called).
I know it's all supposed to be about choice, but as there isn't the staffing available to support everything, we need to pick one configuration manager (hopefully one that isn't written in ruby), one monitoring system, one messaging/notification system, one backup system...etc, and integrate them into the base server and all the roles (that word is getting a little overloaded, isn't it?) that we are going to implement.
I feel that work done on that infrastructure up front will have a major impact on the quality of the released product. Is it possible that some of the fedora infrastructure stuff can be used as a base?
server@lists.fedoraproject.org