Been using the Roles and Profiles pattern for a while, but only recently
had the need to create a Profile that is required in a number of Roles.
Typically we use Git sub-modules when we want to do this sort of thing, but
I don't want to make this a discussion about Git sub-modules vs. other
constructs, but rather ask about the effect of doing so iro Puppet, and
whether the solution described here seems reasonable (or not).
The problem (if indeed there is one) arises because of the structure needed
to create a Git repo and the 'normal' structure of Profile classes, or at
least how they are generally shown in examples. Like so :-
./module/profiles/manifests/my_profile1.pp
Note the class my_profile1 exists directly within the manifests folder of
profiles and might look like this :-
class profiles::my_profile1 {
include my_module1
include my_module2
...
}
... and if I wanted to use that classes from a 'role' I might use something
like :-
class roles::my_role {
include profiles::my_profile1
... include other profiles
}
However, when I create a repo in Git, I would want that repo to be called
(in this case) 'my_profile1', and, when I add it as a sub-module, that
would be the folder name that is created, which clearly doesn't follow the
folder structure above. Hmmm
Of course profile classes don't *have* to be placed as I have shown, so, I
*could* create a folder called 'my_profile1' *below* profile/manifests, but
then I would need to decide what to call that class and I would also need
to reference it differently from the 'role'.
For example, I *could* call the class 'impl' (not very imaginative I know),
so I would end up with :-
./module/profiles/manifests/my_profile1/impl.pp
containing :-
class profiles::my_profile1::impl {
include my_module1
include my_module2
...
}
and called from the 'role' class, thus :-
class roles::my_role {
include profiles::my_profile1::impl
... include other profiles
}
This is just a first attempt and it works and doesn't seem too bad (at
least in the sense that the structure is reasonably intuitive and the
profile class name is fairly descriptive of its intent). It might get a bit
clumsy if I wanted to create further sub-classes of the main profile to
break-out functionality from 'impl', but thats perhaps unlikely. There do
also appear to be some advantages over dumping all profile classes in a
single folder (such as ... it's cleaner to add [say] an *examples* folder
within my_profile1 for testing, thus keeping everything related to this
class together, ... ).
But is there another (perhaps better) approach that achieves the same thing
(allows a profile class to be shared amongst roles and stored in Git as an
independantly versioned repo and referenced as a sub-module) ?
Kind Regards
Fraser.
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" 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-users/e062e2f4-15ee-4477-81aa-bb9465ebcbef%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
