On 2014-20-06 3:01, Joachim Thuau wrote:
(Felix - my apologies, i'm just going to start a new thread :)
As requested, a new thread to discuss the possibility of having a module
masquerading feature.
Have a look at PUP-2811 -- I'm going to try to keep that updated with
the output of this discussion.
What I am after is something akin to the debian package "provides"
property. When a Debian system needs an MTA, most packages shouldn't
care what MTA is installed, just that "MTA" as a feature is installed. I
can install any of exim, postfix, sendmail, qmail. The package name is
still "exim" or "postfix" or whatever, but they all provide a "mta"
package (which doesn't really exists, it's just so that it can be used
as a dependency). So when logwatch needs to make sure a MTA is installed
to send mails about the logs, it doesn't care which one, as long as
*something* provides a mail feature.
In the context of puppet modules, we could have competing modules
offering similar features, and a module that needs that feature, but
doesn't care which one is being used, as long as one *is*.
The example I have is around this:
Sssd and nslcd are both systems to get user information out of
ldap/active directory. They can't be installed together, and some other
modules needs to make sure some sort of auth has been setup prior doing
the changes...
One module for sssd:
class sssd as auth {
# setup sssd
}
One module for nslcd:
class nslcd as auth {
# setup nslcd
}
And one module that needs one of them:
class ssh_authz {
require auth
# setup some ssh authz that require one of the auth module to be applied
}
Then we have some nodes:
node nodeSSSD {
# do the right thing here... even if this is coming from ENC in
whatever order
include sssd
include ssh_authz
}
node nodeNSLCD {
# still should be able to apply in the right sequence based on the
require in ssh_authz
include ssh_authz
include nslcd
}
node broken-missing {
# fails because nothing provides "auth" that's required...
include ssh_authz
}
node broken-dups {
# duplicate resources, as both sssd and nslcd show up as "auth"
include sssd
include ssh_authz
include nslcd
}
I hope this could be useful especially around modules that potentially
provide similar features. If i provide a module for installing a piece
of software that requires a DB, we could simply say that we need some DB
module (and maybe some default, if none exists for the "puppet module
install". Maybe I have a "mysql" module that's pretty simple, and maybe
there is another one with much more control, and just need one of them
for that purpose...
hoping for a lively discussion around this...
Thanks,
Jok
I see this as an essential feature to support maintainable modules.
And by "this", I mean a mechanism that decouples the wanted Element and
its Container (where the Element is the thing we want/need/require, and
the Container is the named thing it is in, typically a Module).
This can be achieved by modules describing their provided and required
capabilities. These are described as name spaced names and they are
versioned. This creates an open ended system that can describe
dependencies on either modules (like now) by using a name in the Module
namespace, a gem in a gem namespace, a puppet class in a puppet name
space, new types of dependencies can be added etc.
As a very nice side effect the ability to describe provided capabilities
makes it possible for a described entity to list the same capability
multiple times with different versions, or version ranges, thus making
it possible to describe components as "backwards compatible", if not in
full, for a smaller portion of the services it contains.
The difficulty with this (any other similar solution) is the resolution
of the dependencies as it requires something like a SAT solver.
I worked on the implementation of such a system for Eclipse (Eclipse p2)
which has been in use for a couple of years now as *the* software
update/configuration mechanism for the Ecipse ecosystem. (If you are a
Puppet Labs Geppetto user you have already used it, as it is what
updates Geppetto with new releases).
While such a system (as p2) is very flexible and powerful, the main
problem is to explain why something is not installable (complete /
updateable) - i.e. when there are parts missing, or when there are
ambiguities. Even though p2 has such capabilities (thanks to the sat
solver in use) it is often still a bit of a puzzle when facing non
regular configurations (or tracking down the metadata that has bad
consequences).
If we do not attempt to solve the resolution, and simply validate the
constraints, the problem is much much simpler, but you also do not get
any help configuring a solution (except being slapped when the
configuration is wrong/incomplete).
It would be very interesting to conduct an experiment using p2 to
describe configurations in the puppet domain. The p2 system can be used
for other things than Java/OSGi/Eclipe and it is supported in the Nexus
repository manager.
- henrik
--
Visit my Blog "Puppet on the Edge"
http://puppet-on-the-edge.blogspot.se/
--
You received this message because you are subscribed to the Google Groups "Puppet
Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-dev/lo97g4%244ab%241%40ger.gmane.org.
For more options, visit https://groups.google.com/d/optout.
