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 [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.
>

-- 
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