Scoping, defaults and relationships
Marcin Owsiany
Here's a requirement I'm trying to meet:
No package installation should be attempted before "apt-get update"
runs. (Because it may need to pick up custom package repositories).
However I do not want to repeat:
requires => Exec["apt-get update"]
every time I create a package instance.
Specifying
Package { require => Exec["apt-get update"] }
at the top level does not work when you specify another "require"
explicitly in some package instances. You would have to either:
1) repeat the default every time a "require" is set explicitly.
Obviously, that is error-prone and violates the DRY principle.
2) use the +> operator instead of => but it seems to work only for
amending resources of inherited classes?
So currently the only way to have this is to create a define.
However
- I'm reluctant to create one (since I was burnt by
http://reductivelabs.com/trac/puppet/ticket/446).
- Even though this would probably work, (since #446 is now fixed), I
still feel that it may be good if puppet natively provided such
feature, without forcing nearly everyone to create their own, but
identical "my_package()".
The idea would be to create some new syntax, which would work just like:
File { require => blah }
does, but make the "require" stick, instead of being replaced when you
specify one explicitly.
Maybe an example will make it easier to show what I mean. The following
manifest (where =>> is the hypotethical operator):
------------------------------------------------------------------------
File { require => $default }
file { a1: }
file { a2: require => $a }
class a {
File { require =>> $b1 }
include b
}
class b {
file { b1: }
file { b2: require => $b2 }
}
------------------------------------------------------------------------
.. should create the following dependency graph:
File[a1] -> $default
File[a2] -> $a
File[b1] -> $b1
File[b2] -> $b1
File[b2] -> $b2
I'm not sure about the exact syntax, but I do think that there should be
a "sticky" relation feature (possibly with another feature to "unstick"
that).
What do you think?
--
Marcin Owsiany <mar...@owsiany.pl> http://marcin.owsiany.pl/
GnuPG: 1024D/60F41216 FE67 DA2D 0ACA FC5E 3F75 D6F6 3A0D 8AA0 60F4 1216
"Every program in development at MIT expands until it can read mail."
-- Unknown
Luke Kanies
> I'm not sure about the exact syntax, but I do think that there
> should be
> a "sticky" relation feature (possibly with another feature to
> "unstick"
> that).
>
> What do you think?
I definitely want something like this feature -- I think I filed it as
an enhancement request a while ago.
Really, what we need is a way to specify a relationship to all
resources matching a given query, or of a given type.
I'm kind of thinking the idea of using our existing query language --
File <| ... |> -- combined with overrides *might* work, but it would
look silly because most times you wouldn't have any parameters:
Package <| |> { require => Exec[blah] }
I've been thinking of adding something like this anyway because people
sometimes need to override values in collected resources.
Generalizing this syntax into a query syntax that allowed you to
perform operations on sets of resources would be a good idea.
--
The one thing more difficult than following a regimen is not imposing it
on others. -- Marcel Proust
---------------------------------------------------------------------
Luke Kanies | http://reductivelabs.com | http://madstop.com
David Schmitt
Hash: SHA1
On Friday 09 May 2008, Luke Kanies wrote:
> On May 9, 2008, at 3:20 PM, Marcin Owsiany wrote:
> > I'm not sure about the exact syntax, but I do think that there
> > should be
> > a "sticky" relation feature (possibly with another feature to
> > "unstick"
> > that).
> >
> > What do you think?
>
> I definitely want something like this feature -- I think I filed it as
> an enhancement request a while ago.
>
> Really, what we need is a way to specify a relationship to all
> resources matching a given query, or of a given type.
>
> I'm kind of thinking the idea of using our existing query language --
> File <| ... |> -- combined with overrides *might* work, but it would
> look silly because most times you wouldn't have any parameters:
>
> Package <| |> { require => Exec[blah] }
>
> I've been thinking of adding something like this anyway because people
> sometimes need to override values in collected resources.
> Generalizing this syntax into a query syntax that allowed you to
> perform operations on sets of resources would be a good idea.
I believe I wrote something up about this a while ago, although I cannot find
it anymore.
Syntaxwise this would tie in best for me in the override syntax:
Package[*] { require => Class[apt] }
Although this would of course immediately lead to a loop on Package[apt].
Regards, DavidS
- --
The primary freedom of open source is not the freedom from cost, but the free-
dom to shape software to do what you want. This freedom is /never/ exercised
without cost, but is available /at all/ only by accepting the very different
costs associated with open source, costs not in money, but in time and effort.
- -- http://www.schierer.org/~luke/log/20070710-1129/on-forks-and-forking
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFIMpgL/Pp1N6Uzh0URAha+AJ0fxUOJeiSR1N/Y1m62suSZcI7vvwCfcicX
RlMNu5k86p+fD7j5/iLv39g=
=flGP
-----END PGP SIGNATURE-----
Luke Kanies
> I believe I wrote something up about this a while ago, although I
> cannot find
> it anymore.
>
> Syntaxwise this would tie in best for me in the override syntax:
>
> Package[*] { require => Class[apt] }
>
> Although this would of course immediately lead to a loop on
> Package[apt].
Other than that last little fatal bit, that should work well. It
wouldn't have really been possible six months ago, but the recent
refactorings make this pretty easy.
Any ideas how to fix the other problem? Seems pretty hard. It's
probably a better idea just to specify the relationship directly to
the apt-get command, which skips the problem but might expose more of
the class internals than we'd normally like.
Otherwise, anyone want to take a crack at solving it? I'd recommend a
globbing syntax in the language (so it supported more than just '*'),
and then it's just a question of iterating over all of the package
resources in the catalog (during compilation).
The hard part is that this has to happen once the catalog is done
being compiled (otherwise it would only affect those resources that
had already been created when the statement is evaluated). You'd
probably need to to add some code to parser/compiler.rb in the
'finish' method.
--
I love deadlines. I like the whooshing sound they make as they fly by.
--Douglas Adams
Marcin Owsiany
>
> On May 9, 2008, at 3:20 PM, Marcin Owsiany wrote:
>
> > I'm not sure about the exact syntax, but I do think that there
> > should be
> > a "sticky" relation feature (possibly with another feature to
> > "unstick"
> > that).
> >
> > What do you think?
>
>
> I definitely want something like this feature -- I think I filed it as
> an enhancement request a while ago.
Was that #1088 ? (I'll put a cross-reference to this thread there if
that is the one).
Blake Barnett
I do this currently by making a definition for edge cases. I use the
Package default, and when I have a package that requires a certain
situation I use a wrapper definition like:
define special::package(ensure = present, ... ) {
package { $name: ensure => $ensure }
}
Now the require is a metaparam on the define, and all my other
defaults work (I only define parameters that I don't use defaults for.
-Blake
Luke Kanies
>
> On Fri, May 09, 2008 at 03:59:12PM -0500, Luke Kanies wrote:
>>
>> On May 9, 2008, at 3:20 PM, Marcin Owsiany wrote:
>>
>>> I'm not sure about the exact syntax, but I do think that there
>>> should be
>>> a "sticky" relation feature (possibly with another feature to
>>> "unstick"
>>> that).
>>>
>>> What do you think?
>>
>>
>> I definitely want something like this feature -- I think I filed it
>> as
>> an enhancement request a while ago.
>
> Was that #1088 ? (I'll put a cross-reference to this thread there if
> that is the one).
Either that[1] or more generally #448, which posits a special syntax
just for creating relationships. Obviously the latter is harder, but
it's pretty clear that relationships are a special cross-resource
feature, so they should probably be something supported directly by
the language rather than hackishly using attributes.
1 - http://reductivelabs.com/trac/puppet/ticket/1088
2 - http://reductivelabs.com/trac/puppet/ticket/448
--
There is nothing worse than aggressive stupidity.
-- Johann Wolfgang von Goethe