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] 
> [2] 
> [3] 
> [4] 
> [5] 
> [6] 
> 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 
For more options, visit

Reply via email to