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]
I like the number three, the one with kind and subkind which makes it very
easy to find the right one than listing them all.
···
On Fri, Nov 25, 2016 at 3:40 PM, Marek Hulán wrote:
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.
I also like the option with provisioning templates being separated by
template kind. It is much easier to navigate through.
···
On Fri, Nov 25, 2016 at 3:40 PM, Marek Hulán wrote:
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.
> 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.
>
I like kind + subkind the most.
···
On Fri, Nov 25, 2016 at 3:40 PM, Marek Hulán wrote:
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]
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
>
On pátek 25. listopadu 2016 15:40:53 CET 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]
>
> 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 Wed, Nov 30, 2016 at 10:13 AM, wrote:
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]
>> 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.
>>
>
> I like kind + subkind the most.
+1
···
> On Fri, Nov 25, 2016 at 3:40 PM, Marek Hulán wrote:
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]
And the PR was merged. Next steps I plan to look at soon:
update templates in core and rethink if we need to list templates explicitly
update metadata in all tempaltes so we could fully rely on them during
import/seed
···
On úterý 17. ledna 2017 10:57:26 CET Marek Hulán wrote:
> Thanks for the feedback, I opened a PR at [1]
>
> [1] https://github.com/theforeman/community-templates/pull/344
–
Marek
–
Marek
On pátek 25. listopadu 2016 15:40:53 CET 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]
I'm also +1 for ./$model/$kind/$name. It mirrors how I would search for
things in the UI too.
Dominic, would such a change have any impact on how you sync the templates
before each release? Is there a script or similar we can PR alongside this
change to keep things smooth on your end?
Oh, another thought, possibly half-baked - is there any impact on backwards
compatibility? IIRC foreman_templates doesn't actually care about the
directory structure (it's a **/*erb glob) but perhaps I've overlooked
something?
Sorry for late answer, the new structure should work with foreman_templates
just fine. Foreman core has a list of files it seeds, I'm happy to provide a
PR for it with new paths [1] if we change the structure in core too but we
could start seeding all we have there since we'd have metadata for each
template.
···
On čtvrtek 8. prosince 2016 16:58:24 CET Greg Sutcliffe wrote:
> Oh, another thought, possibly half-baked - is there any impact on backwards
> compatibility? IIRC foreman_templates doesn't actually care about the
> directory structure (it's a **/*erb glob) but perhaps I've overlooked
> something?
