Thank you for such detailed feedback. It all makes sense now.
I have pushed an update
<https://github.com/desertkun/hiera-editor/releases/tag/v0.1.3> that makes
the editor to support hierarchy. It now shows on what level of hierarchy
each property of the class is defined (by color-coding)
[image: colors.png]
You can also switch to desired level in the drop-down, and make changes on
that level.
It also now evaluates actual pp files and shows resolved classes, so you
can use Hiera Editor with puppet-resolved classes.
[image: pp.png]
Unfortunately, a connection to Puppet Server is a requirement now (it needs
to download facts and node list). But I've tried to make that process as
less painful as possible.
Couple questions.
1. You have facts like "trusted.extensions.pp_role" in your examples.
Could you please elaborate on those so I can also support them?
2. How would you like to see hiera-enc working? To automatically
decrypt/encrypt values, we need the keys. Those are essential not only to
change values, but also to accurately evaluate properties (for example, a
condition that fails if password too short). Hiera-enc states that you
should really keep the keys on the Puppet Server only. How about
password-encrypted keys? You can use them within the editor, but you have
to enter a master password each time the editor is launched.
On Wednesday, January 9, 2019 at 3:09:59 PM UTC+2, Karsten Heymann wrote:
>
>
>
> Am Mi., 9. Jan. 2019 um 12:48 Uhr schrieb desertkun <dese...@gmail.com
> <javascript:>>:
>
>>
>> ** 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/063391f6-922f-4111-9e3c-3020f07464e6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
