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 foreman-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to