On Monday, June 23, 2014 7:45:05 AM UTC-5, henrik lindberg wrote: > > > 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). >
Agreed. > > This can be achieved by modules describing their provided and required > capabilities. These are described as name spaced names and they are > versioned. That's so easy to say, yet so fraught with difficulties. In particular, the biggest issues I see revolve around the meanings of capability names. Capability names defined and maintained by the modules that require them present a potential problem because capability provider modules can't be expected to know and declare all the capabilities that they in fact provide. Running with the authentication example, if module 'ssh' requires capability ssh::authentication::service, then why should it be the responsibility of nsssd and nslcd to know about that in order to declare that they provide it? And then, what if I switch out puppetlabs-ssh for example42-ssh, which happens also to require a capability of the same name? What system or procedure can make sure that puppetlabs and example42 agree on the meaning of that capability? I think the capability consumer must declare what capabilities it requires, yes, but it must be up to the user to bind capability providers to the names. At least, it must be within the user's power to do so. Indeed, I'm having trouble how the desired decoupling is achieved any other way. > 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. > > So far, this sounds a lot like the dependency features of software packaging formats such as RPM and DEB. But look at what's happened in that space, especially with RPMs: despite the commonality of the format, RPMs are for the most part partitioned by family (RedHat vs. SUSE vs. ...) and distro version, with comparatively poor compatibility across those lines. It think the fact that they have even that much coherency is related to the distro maintainer serving as central heavyweight with strong influence on which capability names are used and what they mean. > The difficulty with this (any other similar solution) is the resolution > of the dependencies as it requires something like a SAT solver. > > I think you're saying that given a set of available modules, one needs the equivalent of a SAT solver to find a self-consistent subset that provides a given collection of capabilities. But that's a problem for the user to solve, so in addition to computing an answer (perhaps with the help of a tool), he has the alternative of redefining the problem to make it easy by creating new modules or modifying existing ones. I guess that could be a problem that you want an enhanced module tool to be able to handle, but that seems a side issue to me. The problem that the catalog builder has to solve is much simpler: whether a given collection of classes and resources (i.e. the contents of one catalog) has any unsatisfied requirements. Moreover, I'm inclined to think that even though SAT is in general a hard problem (NP-complete, in fact), the instances likely to arise in a Puppet context are all fairly easily computable. There will be few components -- usually just one -- providing any given capability, and few exclusion constraints. I don't think you actually need a very clever SAT solver there. Also, all that is moot if, as I suggested, it is the user's responsibility to bind provider components to capability names. > 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). > > At least as a first go, I think it would be fine to stop at validating. That's a pretty natural extension of the current system, and it seems like it would present a fairly low barrier to entry. > 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. > > It's nice to have a variety of interesting problems from which to choose. :-) John -- 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/bb413e2c-7513-4422-a129-0967cd1c0603%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
