For navigation (reading) IMHO kind/subkind works well (although I have to admit I am not a sysadmin - I didn't have to do it as my day job) What about modification use case? Is there any use case where a user wants to modify multiple templates from different kinds? For example something along the lines of "I want to modify all my kickstart templates".
On Friday, November 25, 2016 at 4:41:01 PM UTC+2, Marek Hulán wrote: > > Hello foreman devs, > > As I demonstrated on last community demo [1] templates can be now easily > exported from Foreman. I also mentioned that I'm working [2] on > foreman_templates feature to easily export all templates to a given git > repo. > Since the plugin can be used with any git repo, not just the community- > templates [3] one, I'd like to standardize the format of such repository. > > When we export templates from Foreman, we can only use template attributes > to > determine the resulting path in the repo. First obvious idea is to name > the > template file according to it's name in Foreman. That's probably not > enough > since it wold result in one directory mixing all partition tables, > provisioning templates and job templates. So I came up with structure like > $template_type/$name. For better look and feel of what it means, you can > see > it in one of my branches [4]. > > Currently we also separate provisioning templates into more directories. I > don't think the rule is well defined today. I think we could separate it > per > template kind. Again you can see this demonstrated in another branch at > [5]. > It applies only to provisioning templates, other types don't have template > kind attribute. > > Please share your ideas for other structuring or which of schema mentioned > > above you find better. The level of nesting does not matter from technical > point of view but I think 2 or 3 directories is the limit. > > The ultimate goal of making foreman_templates exporting compatible with > community-templates is making sharing of user changes easy, in fact just a > matter of opening PR from the forked repo. Another nice benefit would be > that > future changes in metadata, e.g. adding organizations and locations keys > would > be much easier, we'd just reexport all templates from Foreman with updated > export code. > > Since we now have metadata as a part of each template we could also > improve > seeding to avoid hard coding the list in seed files [6] > > [1] https://www.youtube.com/watch?v=M0-3x8AUfFQ > [2] https://github.com/theforeman/foreman_templates/pull/36 > [3] https://github.com/theforeman/community-templates > [4] https://github.com/ares/community-templates/tree/develop_kind_only > [5] > https://github.com/ares/community-templates/tree/develop_kind_and_subkind > [6] > https://github.com/theforeman/foreman/blob/develop/db/seeds.d/07-provisioning_templates.rb#L21-L94 > > > Thanks for all comments > > -- > Marek > -- You received this message because you are subscribed to the Google Groups "foreman-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
