On Wed, Nov 30, 2016 at 10:13 AM, <[email protected]> wrote: > > 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". > > is this a usability issue? maybe check with Roxanne ?
> > > 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. > -- 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.
