Hi, On 01/30/2012 10:28 PM, Nick wrote: > It did sound similar, yes - but unless I misunderstand it, not identical. For > example, I don't understand how Constraints would avoid the problems with > unifying resources that Nan mentioned.
as far as I understand, there is no need to merge anything. The catalog will or will not contain a certain resource. If existing, the resource will have a certain set of parameteres and metaparameters. Each constraint can be individually compared to this state. If a constrained resource does not exist, or any of its (meta)parameters deviate from what the constraint defines, the catalog is no longer valid. The beauty of this design is that the language is very expressive and all validation can be done by the master. Err, right, John? :-) > John's example appeared to be wrapping an existing Resource with something > which > puts constraints on it, i.e. a layer on top of "Resources". It implies a > regular > Resource to wrap somewhere. > > Whereas what I had in mind was something which in principle at least, was more > basic than a Resource. With an "Assertion" there is nothing being managed, or > mutated, by definition. It defines conditions on a resource (lower-case 'r') > which can be checked, and merged, but doesn't imply that any Resource > (upper-case 'R') need to be declared. It's quite possible that one wouldn't > bother, if you don't need to manage or mutate anything. Ah, so you'd have the agent verify if all assertions (which need to appear as first-class citizens in the catalog) hold true, and otherwise fail the catalog? That strikes me as very elegant indeed. How will situations be handled where assertions won't hold true until parts of the catalog have been applied? > So Resources (upper case 'R') could be thought of as extensions to Assertions > which also supply rules to mutate a system's state, should the conditions of > the > Assertion not be met, so that the conditions *are* met. Let's not alienate the community by declassing the proven and beloved Resources ;-) but I've got to say, this idea does hold merit. So does the constraint idea. Something tells me that both might be of benefit, but I'm afraid of years of user confusion to come when everyone is tasked with understanding the difference between the two and to decide when to use which. If we need to take a pick, there's two things I'd have to say for constraints: 1. They're more closely tailored to the problem at hand. 2. They're stronger in chorus with what puppet is today. Assertions would probably widen the borders of what's possible with puppet (and how easy it is), and they would allow/require us to part with some paradigms. I'm torn whether we want this sooner than seeing the multiple declaration problem sorted out in a less intrusive way. Cheers, Felix -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
