On Wed, Nov 30, 2016 at 10:13 AM, <ssht...@redhat.com> 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  templates can be now easily
>> exported from Foreman. I also mentioned that I'm working  on
>> foreman_templates feature to easily export all templates to a given git
>> Since the plugin can be used with any git repo, not just the community-
>> templates  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
>> template file according to it's name in Foreman. That's probably not
>> since it wold result in one directory mixing all partition tables,
>> provisioning templates and job templates. So I came up with structure
>> $template_type/$name. For better look and feel of what it means, you can
>> it in one of my branches .
>> Currently we also separate provisioning templates into more directories.
>> don't think the rule is well defined today. I think we could separate it
>> template kind. Again you can see this demonstrated in another branch at
>> It applies only to provisioning templates, other types don't have
>> kind attribute.
>> Please share your ideas for other structuring or which of schema
>> above you find better. The level of nesting does not matter from
>> 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
>> matter of opening PR from the forked repo. Another nice benefit would be
>> future changes in metadata, e.g. adding organizations and locations keys
>> be much easier, we'd just reexport all templates from Foreman with
>> export code.
>> Since we now have metadata as a part of each template we could also
>> seeding to avoid hard coding the list in seed files 
>>  https://www.youtube.com/watch?v=M0-3x8AUfFQ
>>  https://github.com/theforeman/foreman_templates/pull/36
>>  https://github.com/theforeman/community-templates
>>  https://github.com/ares/community-templates/tree/develop_kind_only
>>  https://github.com/ares/community-templates/tree/develop_
>>  https://github.com/theforeman/foreman/blob/develop/db/seeds.
>> Thanks for all comments
> 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.
You received this message because you are subscribed to the Google Groups
To unsubscribe from this group and stop receiving emails from it, send an email
For more options, visit https://groups.google.com/d/optout.