Am Mi., 9. Jan. 2019 um 12:48 Uhr schrieb desertkun <desert...@gmail.com>:
>
> ** Have you thoght about integrating support for hiera-enc?*
>
>
>
> Wasn’t aware of it, so I need time to investigate what it does.
>
>
It allows to encrypt entries (value) in hiera so that they don't end up in
clear text for example in the git history of the puppet code.
> ** Some kind of git commit function for the changes done would be a neat
> feature. This would certain parts of our coworkers to stay completely in
> this kind of editor as they probably only interact with hiera data. If you
> are interested I have some ideas how this could be implemented in a safe
> and convenient way.*
>
>
>
> Yes, that is definitely planned. I want it to the level the editor would
> highlight classes/yaml files/directories with green/blue/red colors to
> indicate staging status. Obviously, with commit/discard buttons. I also
> want to implement actual module installation (assuming everyone just adds
> them as submodules to their repo).
>
I would think that nowadays using a Puppetfile is the preferred way to
install modules.
** Is there support for changing a value at every depth of the configured
> hiera hierachy?*
>
>
>
> Not quite sure about that, it can edit classes (their fields) and
> resources (and their fields), would appreciate an example of what you mean.
>
The way we use hiera is that we have the following hierachy definded in
hiera.yaml (this is still hiera 3, but the principle stays the same with
hiera 5+):
hiera.yaml:
:hierarchy:
- "hostname/%{fqdn}"
- "roles_%{trusted.extensions.pp_apptier}/%{trusted.extensions.pp_role}"
- "roles_%{trusted.extensions.pp_apptier}/default"
- "roles_common/%{trusted.extensions.pp_role}"
- common
The hiera data folder in our environments looks this way:
$ tree -d
.
├── hostname
├── roles_common
├── roles_labor
├── roles_prod
└── roles_staging
With yaml files in every folder and a common.yaml in the main folder. Now
when in the puppet code a variable is looked up, the hierachy list above is
evaluated and checked on which level a variable is set.
Example: A webserver with the hostname web-01.mydomain, the apptier staging
and the role web uses the class profiles::webserver and in there looks up
the variable profiles::webserver::servername. Now when compiling the
catalog the following hiera files are sequentially checked if they contain
a "profiles::webserver::servername: whatever" variable:
hostname/web-01.mydomain.yaml
roles_staging/web.yaml
roles_staging/default.yaml
roles_common/web.yaml
common.yaml
Depending if I want to set a variable only for a specific server, for all
staging web server, for all staging servers, for all prod/lab/staging web
servers or for every system known, the variable can be edited on any of
these levels. This is the main benefit of using hiera, you can define a
variable as general and as specific as needed without repeating yourself.
The main feature I would expect from a hiera editor would be to make this
layered setup as approachable and transparent as possible,
> ** Are you aware of jerakia (http://jerakia.io/ <http://jerakia.io/>). We
> don't use it yet but are considering it to be able to use our "hiera" data
> from ansible too. But I think it's a very interesting project.*
>
>
>
> I am not but I am pretty sure we have different goals. I want make a tool
> for those who have no idea what Puppet is but need to use it.
>
This wasn't ment as a competing project, more as a hint to a possible
alternative backend that could be supported additionally to hiera.
> ** Is the hieraresources part optional? We don't want to use hiera to
> define arbitrary resources as it would work around the way we define roles
> and profiles.*
>
>
>
> It is, you can just do hiera_include('classes') instead if you only need
> to manage classes. But as long as you won’t create any resource in the tool
> it won’t populate the `resources` hash and thus the second line
> hiera_resources('resources') of the hieraresources module won’t do
> anything. I implemented this because there is a case when you actually need
> your instances of profiles several times.
>
I think we use hiera in a different way. We don't load any classes from
hiera at all, instead we use an enc script for this. So the only purpose
hiera does serve us is to set the variables for the profiles loaded by the
roles our servers use. Every server "automatically" loads
roles::<tier>::<role>.pp and in this file all the server's profiles are
included ('contain'd to be precise). But I understand that loading classes
not from hiera makes it much more difficult to decide which variables are
used by a server.
This all isn't ment to say that our solution is any better than what you
seem to propose, but just as a heads up that I think it's quite important
that you document the assumptions you have about how a user uses
puppet/hiera in order to be able to use your tool.
Best regards,
Karsten
--
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/CAL017hC%3D7X0Xts%3DcFXAZqsPAq4p0Vx54zi5dwNybXUz5tfdvvw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
