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 <[email protected] > <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 [email protected]. 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.
