Below is all really complicated and I keep losing track of what is going on.
We have all profile classes in a single puppet module (in git). Then in a role
class I would:
include ::profile::common
include ::profile::this
include ::profile::other::that
I presume if somebody had a Super Special Flower sort of "business need"
(hasn't happened yet) I'd have them start up another profile module, and then
their role would look like this:
include ::profile::common
include ::ssf::this
include ::ssf::that
Other than that I don't really see what advantage you get from git submodules
as opposed to r10k. You can include a class from any profile-level module and
that will probably work for you. Would you mind expounding on what git
submodules gets you here?
On Fri, Jan 01, 2016 at 12:15:59AM -0800, Fraser Goffin wrote:
> 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 [1][email protected].
> To view this discussion on the web visit
>
> [2]https://groups.google.com/d/msgid/puppet-users/e062e2f4-15ee-4477-81aa-bb9465ebcbef%40googlegroups.com.
> For more options, visit [3]https://groups.google.com/d/optout.
>
> References
>
> Visible links
> 1. mailto:[email protected]
> 2.
> https://groups.google.com/d/msgid/puppet-users/e062e2f4-15ee-4477-81aa-bb9465ebcbef%40googlegroups.com?utm_medium=email&utm_source=footer
> 3. https://groups.google.com/d/optout
--
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/20160101205714.GA26868%40iniquitous.heresiarch.ca.
For more options, visit https://groups.google.com/d/optout.
