Le 16/11/2016 à 09:34:50+0100, Craig Dunn a écrit
>
>
>
> Firstly, the idea behind roles and profiles is that profiles are used to
> define
> logical "technology stacks" composing of your component modules. That is to
> say, that profiles are the layer where you declare how your component modules
> are implemented to model the technology unit you are trying to manage. Roles
> are a way to represent a more "business logic" view of Puppet and are
> generally
> just wraps one or more profiles that make up that business logic, eg: a
> "application server" is all you should care about at a business logic level,
> the technology stacks (profiles) that are included to make up the role of an
> application server may include "webserver", "security", "base", "tomcat"....
> Ironically the value of roles is their simplicity, by keeping them
> essentially
> dumb and limiting their responsibility to just including profiles it provides
> a
> nice layer of separation between business logic representation and
> implementation details.
>
> With the above in mind, I think having hiera data populate role classes blurs
> that line and you end up with implementation details in both roles and
> profiles
> and it starts not making sense to have that further layer of abstraction.
>
> Going further, the best environments I have seen only need to populate profile
> class with hiera data in the most extreme of edge cases. Good component
> modules should be able to get all the data they need by using data bindings
> and
> a well thought out hiera hierarchy should prove sufficient for ensuring that
> things get configured correctly, and often your profiles will generally just
> "include ::class" and let data bindings do the rest - obviously this isn't
> always the case, sometimes you need to do specific implementation around
> component modules, such as component modules which expose a defined resource
> type but have no "create_resources" style of dynamically creating the
> resources
> that it provides, which is what profiles serve to do, and in some cases it
> might make sense to populate profile data from hiera to achieve this.
This is exaclty what I try to do. Event I sometime use create_resources (or
now loop). But I don't see how I can do for a data needed by two profile
like a share password. Or if I take your sample "webserver", "security", "base",
"tomcat". If I installed tomcat in some place ('/opt/tomcat') how the
module who manage the war going to kown where to put the war ?
>
> So in summary; If you have a lot of data in hiera for your roles/profiles,
> you
> might want to look at why this is and see if having a more suitable hierarchy
> and relying on native data binding lookups from the component modules isn't an
> option... If you genuinely need data populated at this level, then it's part
> of the implementation of your technology stack, therefore should be at the
> profile level, not the role level.
>
Ok got it.
> I highly recommend you read this post by Gary Larizza ... http://
> garylarizza.com/blog/2014/02/17/puppet-workflow-part-2/
thanks....google already give me that link.
> Disclaimer: all of this is just opinions, but they're well tested opinions ;)
Every opinions are good for me.
Thanks again.
Regards.
--
Albert SHIH
DIO bâtiment 15
Observatoire de Paris
5 Place Jules Janssen
92195 Meudon Cedex
France
xmpp: j...@obspm.fr
Heure local/Local time:
mer 16 nov 2016 10:09:08 CET
--
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 puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/20161116091809.GA28733%40pcjas.obspm.fr.
For more options, visit https://groups.google.com/d/optout.
