Streamlining Provisioning with Katello

[ehelms]

Howdy,

We are working on improving usability and one of our target areas is
provisioning when Katello is present. To this end, we have identified a
number of areas we could tackle to improve this workflow. Below is an
outline of some ideas we have discussed and we welcome your feedback.

Kickstart Repositories
Background

• The 6Server kickstart repository doesn't work the same as the 6Server
  RPM repository and can be misleading to users

Proposal

• Hide the 6Server kickstart repository from users (and only expose x.y
  kickstart repos)

Puppet Module Repositories
Background

• In the content views section, puppet modules are treated as a single
  giant list for the org
• Currently the only real advantage to defining different puppet
  repositories is to lockdown the modules by setting permissions on the
  product the puppet modules belong to

Proposal

• Have a single product/repo for every organization for housing all puppet
  modules

Host Groups
Background

• A host group and the Activation Key associated with it could point to
  different environment/content views

Proposal

• Fix issue with Host content source not being inherited from host group
  properly
• Associate Activation Keys directly to hosts and hostgroups

Provisioning Setup
Background

• Provisioning setup has been streamlined with the automatic association
  of templates, however, the user is still required to associate a
  partitioning table to an OS before provisioning

Proposal

• Associate 'Kickstart default' paritition table automagically to Red Hat
  OS family when OS created to streamline quick start provisioning

Provision From a Content View
Background

• Currently, to provision a host, a user must start from a hostgroup or
  host to configure everything properly. There is no path to go from the
  content perspective to provisioning a host from that content.

Proposal

• Create a 'Provision From' workflow that starts from the Content View page
  • would lead users through creating a hostgroup and activation key
    combination
  • auto-populate certain attributes from the Content View
  • give users the option to provision at the end of creating the
    hostgroup/activation workflow
  • allow users to 'provision from' a content view to an already existing
    hostgroup that contains that content view
• Two potential UI workflow paths:
  • Content View -> Provision From -> Host Group Creation -> Puppet Class
    Association -> Activation Key Information -> Provision
  • Content View -> Provision From -> Content -> Networking -> Puppet ->
    Subscriptions -> Details -> Provision

Eric

[Bryan_Kearney]

> Howdy,
>
> We are working on improving usability and one of our target areas is
> provisioning when Katello is present. To this end, we have identified a
> number of areas we could tackle to improve this workflow. Below is an
> outline of some ideas we have discussed and we welcome your feedback.
>
> Kickstart Repositories
> Background
> * The 6Server kickstart repository doesn't work the same as the
> 6Server RPM repository and can be misleading to users
>
> Proposal
> * Hide the 6Server kickstart repository from users (and only expose
> x.y kickstart repos)

No issues from me on this.

>
> Puppet Module Repositories
> Background
> * In the content views section, puppet modules are treated as a single
> giant list for the org
> * Currently the only real advantage to defining different puppet
> repositories is to lockdown the modules by setting permissions on the
> product the puppet modules belong to
>
> Proposal
> * Have a single product/repo for every organization for housing all
> puppet modules

If there is a single repo… how do I control when content is synced from
the outside source? And, if I want to have puppet modules just for one
env stream (say, my internal systems) I can not not control that. This
seems a bit heavy handed.

>
> Host Groups
> Background
> * A host group and the Activation Key associated with it could point
> to different environment/content views
>
> Proposal
> * Fix issue with Host content source not being inherited from host
> group properly
> * Associate Activation Keys directly to hosts and hostgroups

What about ignoring the content view on the key if it is specified in
the host group?

>
> Provisioning Setup
> Background
> * Provisioning setup has been streamlined with the automatic
> association of templates, however, the user is still required to
> associate a partitioning table to an OS before provisioning
>
> Proposal
> * Associate 'Kickstart default' paritition table automagically to Red
> Hat OS family when OS created to streamline quick start provisioning
>
> Provision From a Content View
> Background
> * Currently, to provision a host, a user must start from a hostgroup
> or host to configure everything properly. There is no path to go from
> the content perspective to provisioning a host from that content.
>
> Proposal
> * Create a 'Provision From' workflow that starts from the Content View
> page
> - would lead users through creating a hostgroup and activation key
> combination
> - auto-populate certain attributes from the Content View
> - give users the option to provision at the end of creating the
> hostgroup/activation workflow
> - allow users to 'provision from' a content view to an already
> existing hostgroup that contains that content view
> * Two potential UI workflow paths:
> - Content View -> Provision From -> Host Group Creation -> Puppet
> Class Association -> Activation Key Information -> Provision
> - Content View -> Provision From -> Content -> Networking -> Puppet
> -> Subscriptions -> Details -> Provision

Step ones sounds more like a "Create a hostgroup" rather than "Provision
from". If you called it create a hostgroup I think I wouold be good.

• bk

···

On 10/29/2014 08:34 PM, Eric D Helms wrote:

[ehelms]

>
>
>
>> Howdy,
>>
>> We are working on improving usability and one of our target areas is
>> provisioning when Katello is present. To this end, we have identified a
>> number of areas we could tackle to improve this workflow. Below is an
>> outline of some ideas we have discussed and we welcome your feedback.
>>
>> Kickstart Repositories
>> Background
>> * The 6Server kickstart repository doesn't work the same as the
>> 6Server RPM repository and can be misleading to users
>>
>> Proposal
>> * Hide the 6Server kickstart repository from users (and only expose
>> x.y kickstart repos)
>>
>
> No issues from me on this.
>
>
>> Puppet Module Repositories
>> Background
>> * In the content views section, puppet modules are treated as a single
>> giant list for the org
>> * Currently the only real advantage to defining different puppet
>> repositories is to lockdown the modules by setting permissions on the
>> product the puppet modules belong to
>>
>> Proposal
>> * Have a single product/repo for every organization for housing all
>> puppet modules
>>
>
> If there is a single repo… how do I control when content is synced from
> the outside source? And, if I want to have puppet modules just for one env
> stream (say, my internal systems) I can not not control that. This seems a
> bit heavy handed.
>
>
>> Host Groups
>> Background
>> * A host group and the Activation Key associated with it could point
>> to different environment/content views
>>
>> Proposal
>> * Fix issue with Host content source not being inherited from host
>> group properly
>> * Associate Activation Keys directly to hosts and hostgroups
>>
>
> What about ignoring the content view on the key if it is specified in the
> host group?
>
>
>> Provisioning Setup
>> Background
>> * Provisioning setup has been streamlined with the automatic
>> association of templates, however, the user is still required to
>> associate a partitioning table to an OS before provisioning
>>
>> Proposal
>> * Associate 'Kickstart default' paritition table automagically to Red
>> Hat OS family when OS created to streamline quick start provisioning
>>
>> Provision From a Content View
>> Background
>> * Currently, to provision a host, a user must start from a hostgroup
>> or host to configure everything properly. There is no path to go from
>> the content perspective to provisioning a host from that content.
>>
>> Proposal
>> * Create a 'Provision From' workflow that starts from the Content View
>> page
>> - would lead users through creating a hostgroup and activation key
>> combination
>> - auto-populate certain attributes from the Content View
>> - give users the option to provision at the end of creating the
>> hostgroup/activation workflow
>> - allow users to 'provision from' a content view to an already
>> existing hostgroup that contains that content view
>> * Two potential UI workflow paths:
>> - Content View -> Provision From -> Host Group Creation -> Puppet
>> Class Association -> Activation Key Information -> Provision
>> - Content View -> Provision From -> Content -> Networking -> Puppet
>> -> Subscriptions -> Details -> Provision
>>
>
>
> Step ones sounds more like a "Create a hostgroup" rather than "Provision
> from". If you called it create a hostgroup I think I wouold be good.

What about the case where, starting from a content view, you want to
provision from a pre-created host group that includes the content view
instead of having to create a new one every time?

···

On Thu, Oct 30, 2014 at 7:53 AM, Bryan Kearney wrote: > On 10/29/2014 08:34 PM, Eric D Helms wrote:

• bk

–
You received this message because you are subscribed to the Google Groups
"Foreman users" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to foreman-users+unsubscribe@googlegroups.com.
To post to this group, send email to foreman-users@googlegroups.com.
Visit this group at http://groups.google.com/group/foreman-users.
For more options, visit https://groups.google.com/d/optout.

[Mike_McCune]

>
>
>> Howdy,
>>
>> We are working on improving usability and one of our target areas is
>> provisioning when Katello is present. To this end, we have identified a
>> number of areas we could tackle to improve this workflow. Below is an
>> outline of some ideas we have discussed and we welcome your feedback.
>>
>> Kickstart Repositories
>> Background
>> * The 6Server kickstart repository doesn't work the same as the
>> 6Server RPM repository and can be misleading to users
>>
>> Proposal
>> * Hide the 6Server kickstart repository from users (and only expose
>> x.y kickstart repos)
>
> No issues from me on this.
>

+1

>>
>> Puppet Module Repositories
>> Background
>> * In the content views section, puppet modules are treated as a single
>> giant list for the org
>> * Currently the only real advantage to defining different puppet
>> repositories is to lockdown the modules by setting permissions on the
>> product the puppet modules belong to
>>
>> Proposal
>> * Have a single product/repo for every organization for housing all
>> puppet modules
>
> If there is a single repo… how do I control when content is synced from
> the outside source? And, if I want to have puppet modules just for one
> env stream (say, my internal systems) I can not not control that. This
> seems a bit heavy handed.
>

seems a bit much, is this really causing that much heartburn? Being able
to get Puppet modules from various sources and not being restricted to 1
source seems valuable. What if you want stuff fed from local disk, a
remote http hosted modules dir and the Puppet Forge?

I could see perhaps one product, but the single repo restriction seems
way overboard.

>>
>> Host Groups
>> Background
>> * A host group and the Activation Key associated with it could point
>> to different environment/content views
>>
>> Proposal
>> * Fix issue with Host content source not being inherited from host
>> group properly
>> * Associate Activation Keys directly to hosts and hostgroups
>
> What about ignoring the content view on the key if it is specified in
> the host group?
>

since the a-key is what determines what view you get during registration
I'd argue we should drive it entirely from the Activation Key. Only
specify it once and reduce the confusion. Why not just put the
Activation Key front and center on the Host and Host Group main details
screen?

>>
>> Provisioning Setup
>> Background
>> * Provisioning setup has been streamlined with the automatic
>> association of templates, however, the user is still required to
>> associate a partitioning table to an OS before provisioning
>>
>> Proposal
>> * Associate 'Kickstart default' paritition table automagically to Red
>> Hat OS family when OS created to streamline quick start provisioning
>>

+1

>> Provision From a Content View
>> Background
>> * Currently, to provision a host, a user must start from a hostgroup
>> or host to configure everything properly. There is no path to go from
>> the content perspective to provisioning a host from that content.
>>
>> Proposal
>> * Create a 'Provision From' workflow that starts from the Content View
>> page
>> - would lead users through creating a hostgroup and activation key
>> combination
>> - auto-populate certain attributes from the Content View
>> - give users the option to provision at the end of creating the
>> hostgroup/activation workflow
>> - allow users to 'provision from' a content view to an already
>> existing hostgroup that contains that content view
>> * Two potential UI workflow paths:
>> - Content View -> Provision From -> Host Group Creation -> Puppet
>> Class Association -> Activation Key Information -> Provision
>> - Content View -> Provision From -> Content -> Networking -> Puppet
>> -> Subscriptions -> Details -> Provision
>
>
> Step ones sounds more like a "Create a hostgroup" rather than "Provision
> from". If you called it create a hostgroup I think I wouold be good.
>

would be interesting to see mockups of this workflow vs the individual
bits and pieces you do now to setu the CV, the AKey and the Host Group.
I could see it being clearer than the existing Host Group driven screens.

Mike

···

On 10/30/2014 04:53 AM, Bryan Kearney wrote: > On 10/29/2014 08:34 PM, Eric D Helms wrote:

–
Mike McCune
mmccune AT redhat.com
Red Hat Engineering | Portland, OR
Systems Management | 650-254-4248

[Justin_Sherrill]

Its also creating the activation key, and also the thought was to make
it easier for a new user to figure things out. "provision from" is much
more intuitive than "Create Host Group". We'd still make it clear that
a host group and activation key are being created within the workflow.

-Justin

···

On 10/30/2014 07:53 AM, Bryan Kearney wrote: > > > On 10/29/2014 08:34 PM, Eric D Helms wrote: >> Howdy, >> >> We are working on improving usability and one of our target areas is >> provisioning when Katello is present. To this end, we have identified a >> number of areas we could tackle to improve this workflow. Below is an >> outline of some ideas we have discussed and we welcome your feedback. >> >> _Kickstart Repositories_ >> Background >> * The 6Server kickstart repository doesn't work the same as the >> 6Server RPM repository and can be misleading to users >> >> Proposal >> * Hide the 6Server kickstart repository from users (and only expose >> x.y kickstart repos) > > No issues from me on this. > >> >> _Puppet Module Repositories_ >> Background >> * In the content views section, puppet modules are treated as a single >> giant list for the org >> * Currently the only real advantage to defining different puppet >> repositories is to lockdown the modules by setting permissions on the >> product the puppet modules belong to >> >> Proposal >> * Have a single product/repo for every organization for housing all >> puppet modules > > If there is a single repo.. how do I control when content is synced > from the outside source? And, if I want to have puppet modules just > for one env stream (say, my internal systems) I can not not control > that. This seems a bit heavy handed. > >> >> _Host Groups_ >> Background >> * A host group and the Activation Key associated with it could point >> to different environment/content views >> >> Proposal >> * Fix issue with Host content source not being inherited from host >> group properly >> * Associate Activation Keys directly to hosts and hostgroups > > What about ignoring the content view on the key if it is specified in > the host group? > >> >> _Provisioning Setup_ >> Background >> * Provisioning setup has been streamlined with the automatic >> association of templates, however, the user is still required to >> associate a partitioning table to an OS before provisioning >> >> Proposal >> * Associate 'Kickstart default' paritition table automagically to Red >> Hat OS family when OS created to streamline quick start provisioning >> >> _Provision From a Content View_ >> Background >> * Currently, to provision a host, a user must start from a hostgroup >> or host to configure everything properly. There is no path to go from >> the content perspective to provisioning a host from that content. >> >> Proposal >> * Create a 'Provision From' workflow that starts from the Content View >> page >> - would lead users through creating a hostgroup and activation key >> combination >> - auto-populate certain attributes from the Content View >> - give users the option to provision at the end of creating the >> hostgroup/activation workflow >> - allow users to 'provision from' a content view to an already >> existing hostgroup that contains that content view >> * Two potential UI workflow paths: >> - Content View -> Provision From -> Host Group Creation -> Puppet >> Class Association -> Activation Key Information -> Provision >> - Content View -> Provision From -> Content -> Networking -> Puppet >> -> Subscriptions -> Details -> Provision > > > Step ones sounds more like a "Create a hostgroup" rather than > "Provision from". If you called it create a hostgroup I think I wouold > be good. > > - bk >

[Bryan_Kearney]

So, a host group is just a pre-population of the host record. so, I
could see a path which is Contnet View -> Host skipping the hostgroup.

– bk

···

On 10/30/2014 08:19 AM, Eric D Helms wrote: > > What about the case where, starting from a content view, you want to > provision from a pre-created host group that includes the content view > instead of having to create a new one every time?

[Bryan_Kearney]

My point is that if you say "DO X" I would not have expected the side
effects on the level of creating a host group and activation key. I
would have expected X to be done, and maybe some audit events.

– bk

···

On 10/30/2014 01:06 PM, Justin Sherrill wrote: > On 10/30/2014 07:53 AM, Bryan Kearney wrote: >> >> >> On 10/29/2014 08:34 PM, Eric D Helms wrote: >>> Howdy, >>> >>> We are working on improving usability and one of our target areas is >>> provisioning when Katello is present. To this end, we have identified a >>> number of areas we could tackle to improve this workflow. Below is an >>> outline of some ideas we have discussed and we welcome your feedback. >>> >>> _Kickstart Repositories_ >>> Background >>> * The 6Server kickstart repository doesn't work the same as the >>> 6Server RPM repository and can be misleading to users >>> >>> Proposal >>> * Hide the 6Server kickstart repository from users (and only expose >>> x.y kickstart repos) >> >> No issues from me on this. >> >>> >>> _Puppet Module Repositories_ >>> Background >>> * In the content views section, puppet modules are treated as a single >>> giant list for the org >>> * Currently the only real advantage to defining different puppet >>> repositories is to lockdown the modules by setting permissions on the >>> product the puppet modules belong to >>> >>> Proposal >>> * Have a single product/repo for every organization for housing all >>> puppet modules >> >> If there is a single repo.. how do I control when content is synced >> from the outside source? And, if I want to have puppet modules just >> for one env stream (say, my internal systems) I can not not control >> that. This seems a bit heavy handed. >> >>> >>> _Host Groups_ >>> Background >>> * A host group and the Activation Key associated with it could point >>> to different environment/content views >>> >>> Proposal >>> * Fix issue with Host content source not being inherited from host >>> group properly >>> * Associate Activation Keys directly to hosts and hostgroups >> >> What about ignoring the content view on the key if it is specified in >> the host group? >> >>> >>> _Provisioning Setup_ >>> Background >>> * Provisioning setup has been streamlined with the automatic >>> association of templates, however, the user is still required to >>> associate a partitioning table to an OS before provisioning >>> >>> Proposal >>> * Associate 'Kickstart default' paritition table automagically to Red >>> Hat OS family when OS created to streamline quick start provisioning >>> >>> _Provision From a Content View_ >>> Background >>> * Currently, to provision a host, a user must start from a hostgroup >>> or host to configure everything properly. There is no path to go from >>> the content perspective to provisioning a host from that content. >>> >>> Proposal >>> * Create a 'Provision From' workflow that starts from the Content View >>> page >>> - would lead users through creating a hostgroup and activation key >>> combination >>> - auto-populate certain attributes from the Content View >>> - give users the option to provision at the end of creating the >>> hostgroup/activation workflow >>> - allow users to 'provision from' a content view to an already >>> existing hostgroup that contains that content view >>> * Two potential UI workflow paths: >>> - Content View -> Provision From -> Host Group Creation -> Puppet >>> Class Association -> Activation Key Information -> Provision >>> - Content View -> Provision From -> Content -> Networking -> Puppet >>> -> Subscriptions -> Details -> Provision >> >> >> Step ones sounds more like a "Create a hostgroup" rather than >> "Provision from". If you called it create a hostgroup I think I wouold >> be good. >> >> - bk >> > Its also creating the activation key, and also the thought was to make > it easier for a new user to figure things out. "provision from" is much > more intuitive than "Create Host Group". We'd still make it clear that > a host group and activation key are being created within the workflow. > > -Justin >

[ehelms]

>
>>
>>
>>
>>> Howdy,
>>>
>>> We are working on improving usability and one of our target areas is
>>> provisioning when Katello is present. To this end, we have identified a
>>> number of areas we could tackle to improve this workflow. Below is an
>>> outline of some ideas we have discussed and we welcome your feedback.
>>>
>>> Kickstart Repositories
>>> Background
>>> * The 6Server kickstart repository doesn't work the same as the
>>> 6Server RPM repository and can be misleading to users
>>>
>>> Proposal
>>> * Hide the 6Server kickstart repository from users (and only expose
>>> x.y kickstart repos)
>>>
>>
>> No issues from me on this.
>>
>>
> +1
>
>
>>> Puppet Module Repositories
>>> Background
>>> * In the content views section, puppet modules are treated as a single
>>> giant list for the org
>>> * Currently the only real advantage to defining different puppet
>>> repositories is to lockdown the modules by setting permissions on the
>>> product the puppet modules belong to
>>>
>>> Proposal
>>> * Have a single product/repo for every organization for housing all
>>> puppet modules
>>>
>>
>> If there is a single repo… how do I control when content is synced from
>> the outside source? And, if I want to have puppet modules just for one
>> env stream (say, my internal systems) I can not not control that. This
>> seems a bit heavy handed.
>>
>>
> seems a bit much, is this really causing that much heartburn? Being able
> to get Puppet modules from various sources and not being restricted to 1
> source seems valuable. What if you want stuff fed from local disk, a remote
> http hosted modules dir and the Puppet Forge?
>
> I could see perhaps one product, but the single repo restriction seems
> way overboard.
>
>
>>> Host Groups
>>> Background
>>> * A host group and the Activation Key associated with it could point
>>> to different environment/content views
>>>
>>> Proposal
>>> * Fix issue with Host content source not being inherited from host
>>> group properly
>>> * Associate Activation Keys directly to hosts and hostgroups
>>>
>>
>> What about ignoring the content view on the key if it is specified in
>> the host group?
>>
>>
> since the a-key is what determines what view you get during registration
> I'd argue we should drive it entirely from the Activation Key. Only
> specify it once and reduce the confusion. Why not just put the Activation
> Key front and center on the Host and Host Group main details screen?

For me, pushing the content onto the activation key doesn't make as much as
sense as the activation key pulling content information from the host
group. If the host group is my representation or "template" for a host then
I would want the content/installation media stored within that
representation and let the activation key drive configuring the content and
host post installation.

···

On Thu, Oct 30, 2014 at 2:04 PM, Mike McCune wrote: > On 10/30/2014 04:53 AM, Bryan Kearney wrote: >> On 10/29/2014 08:34 PM, Eric D Helms wrote:

Provisioning Setup
Background

• Provisioning setup has been streamlined with the automatic
  association of templates, however, the user is still required to
  associate a partitioning table to an OS before provisioning

Proposal

• Associate ‘Kickstart default’ paritition table automagically to Red
  Hat OS family when OS created to streamline quick start provisioning

+1

Provision From a Content View

Background

• Currently, to provision a host, a user must start from a hostgroup
  or host to configure everything properly. There is no path to go from
  the content perspective to provisioning a host from that content.

Proposal

• Create a ‘Provision From’ workflow that starts from the Content View
  page

• would lead users through creating a hostgroup and activation key
  combination
• auto-populate certain attributes from the Content View
• give users the option to provision at the end of creating the
  hostgroup/activation workflow
• allow users to ‘provision from’ a content view to an already
  existing hostgroup that contains that content view

• Two potential UI workflow paths:

• Content View -> Provision From -> Host Group Creation -> Puppet
  Class Association -> Activation Key Information -> Provision
• Content View -> Provision From -> Content -> Networking -> Puppet
  -> Subscriptions -> Details -> Provision

Step ones sounds more like a “Create a hostgroup” rather than “Provision
from”. If you called it create a hostgroup I think I wouold be good.

would be interesting to see mockups of this workflow vs the individual
bits and pieces you do now to setu the CV, the AKey and the Host Group. I
could see it being clearer than the existing Host Group driven screens.

Mike

–
Mike McCune
mmccune AT redhat.com
Red Hat Engineering | Portland, OR
Systems Management | 650-254-4248

–
You received this message because you are subscribed to the Google Groups
"Foreman users" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to foreman-users+unsubscribe@googlegroups.com.
To post to this group, send email to foreman-users@googlegroups.com.
Visit this group at http://groups.google.com/group/foreman-users.
For more options, visit https://groups.google.com/d/optout.

[stbenjam]

Why even lock it down to one product? Users should be able to organize
things as they see fit.

You can mix puppet and yum content in a product, so I can certainly
see cases where a user may want to keep some repos with some puppet
content.

I think the actual Puppet module repo <-> Content View relationship
should be re-evaluated, and that you should be able to assign a puppet
repo to a content view and be limited to the modules present in those
repos. A user may want to select the latest version of a module in a
specific repository, instead of the globally latest version.

Additionally, and maybe I digressing a bit from the repo topic, but
there's some usability concerns I have about how we work with puppet
modules in general, it's a lot of overhead.

I would like to see some features like r10k. First, importing/exporting
a Librarian Puppetfile to/from a CVE, but even more importantly: using
git branches to manage the puppet modules present in a CVE, with an
option to monitor for changes and pushing those out to the smart
proxies. In this use case, I would assign a git repo to a content
view as the Puppet module source, and if I push to the 'Production'
branch, Katello will automatically republish the puppet modules in
Production with those modules (perhaps via the new incremental updates!).

···

On Thu, Oct 30, 2014 at 11:04:01AM -0700, Mike McCune wrote: > >>* Have a single product/repo for every organization for housing all > >>puppet modules > > > >If there is a single repo.. how do I control when content is synced from > >the outside source? And, if I want to have puppet modules just for one > >env stream (say, my internal systems) I can not not control that. This > >seems a bit heavy handed.

–
Stephen Benjamin

---

Red Hat GmbH | http://de.redhat.com/ | Sitz: Grasbrunn
Handelsregister: Amtsgericht München, HRB 153243
Geschäftsführer: Charles Cachera, Michael Cunningham,
Michael O’Neill, Charles Peters

[ehelms]

>
>
>
>>
>>>
>>>
>>>
>>>> Howdy,
>>>>
>>>> We are working on improving usability and one of our target areas is
>>>> provisioning when Katello is present. To this end, we have identified a
>>>> number of areas we could tackle to improve this workflow. Below is an
>>>> outline of some ideas we have discussed and we welcome your feedback.
>>>>
>>>> Kickstart Repositories
>>>> Background
>>>> * The 6Server kickstart repository doesn't work the same as the
>>>> 6Server RPM repository and can be misleading to users
>>>>
>>>> Proposal
>>>> * Hide the 6Server kickstart repository from users (and only expose
>>>> x.y kickstart repos)
>>>>
>>>
>>> No issues from me on this.
>>>
>>>
>>>> Puppet Module Repositories
>>>> Background
>>>> * In the content views section, puppet modules are treated as a single
>>>> giant list for the org
>>>> * Currently the only real advantage to defining different puppet
>>>> repositories is to lockdown the modules by setting permissions on the
>>>> product the puppet modules belong to
>>>>
>>>> Proposal
>>>> * Have a single product/repo for every organization for housing all
>>>> puppet modules
>>>>
>>>
>>> If there is a single repo… how do I control when content is synced
>>> from the outside source? And, if I want to have puppet modules just
>>> for one env stream (say, my internal systems) I can not not control
>>> that. This seems a bit heavy handed.
>>>
>>>
>>>> Host Groups
>>>> Background
>>>> * A host group and the Activation Key associated with it could point
>>>> to different environment/content views
>>>>
>>>> Proposal
>>>> * Fix issue with Host content source not being inherited from host
>>>> group properly
>>>> * Associate Activation Keys directly to hosts and hostgroups
>>>>
>>>
>>> What about ignoring the content view on the key if it is specified in
>>> the host group?
>>>
>>>
>>>> Provisioning Setup
>>>> Background
>>>> * Provisioning setup has been streamlined with the automatic
>>>> association of templates, however, the user is still required to
>>>> associate a partitioning table to an OS before provisioning
>>>>
>>>> Proposal
>>>> * Associate 'Kickstart default' paritition table automagically to Red
>>>> Hat OS family when OS created to streamline quick start provisioning
>>>>
>>>> Provision From a Content View
>>>> Background
>>>> * Currently, to provision a host, a user must start from a hostgroup
>>>> or host to configure everything properly. There is no path to go from
>>>> the content perspective to provisioning a host from that content.
>>>>
>>>> Proposal
>>>> * Create a 'Provision From' workflow that starts from the Content View
>>>> page
>>>> - would lead users through creating a hostgroup and activation key
>>>> combination
>>>> - auto-populate certain attributes from the Content View
>>>> - give users the option to provision at the end of creating the
>>>> hostgroup/activation workflow
>>>> - allow users to 'provision from' a content view to an already
>>>> existing hostgroup that contains that content view
>>>> * Two potential UI workflow paths:
>>>> - Content View -> Provision From -> Host Group Creation -> Puppet
>>>> Class Association -> Activation Key Information -> Provision
>>>> - Content View -> Provision From -> Content -> Networking -> Puppet
>>>> -> Subscriptions -> Details -> Provision
>>>>
>>>
>>>
>>> Step ones sounds more like a "Create a hostgroup" rather than
>>> "Provision from". If you called it create a hostgroup I think I wouold
>>> be good.
>>>
>>> - bk
>>>
>>> Its also creating the activation key, and also the thought was to make
>> it easier for a new user to figure things out. "provision from" is much
>> more intuitive than "Create Host Group". We'd still make it clear that
>> a host group and activation key are being created within the workflow.
>>
>> -Justin
>>
>>
> My point is that if you say "DO X" I would not have expected the side
> effects on the level of creating a host group and activation key. I would
> have expected X to be done, and maybe some audit events.

That's fair, the creation of a hostgroup and activation key combination
could be a 'Would you like to save this setup' type of question for the
user at the end of the workflow.

···

On Thu, Oct 30, 2014 at 2:01 PM, Bryan Kearney wrote: > On 10/30/2014 01:06 PM, Justin Sherrill wrote: >> On 10/30/2014 07:53 AM, Bryan Kearney wrote: >>> On 10/29/2014 08:34 PM, Eric D Helms wrote:

– bk

–
You received this message because you are subscribed to the Google Groups
"Foreman users" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to foreman-users+unsubscribe@googlegroups.com.
To post to this group, send email to foreman-users@googlegroups.com.
Visit this group at http://groups.google.com/group/foreman-users.
For more options, visit https://groups.google.com/d/optout.

[Bryan_Kearney]

TBH… the more I see how activation keys work in Katello, the more I
think they should "just" be:

• Credentials
• Subscriptions
• host collections
• product content

And, TBH, looking at what Lzap is thinking around discovery I could see
dropping host collections from this list. The idea of having dynamic
rules which are applied to new hosts seems much cooler.

– bk

···

On 10/30/2014 02:29 PM, Eric D Helms wrote: > > > On Thu, Oct 30, 2014 at 2:04 PM, Mike McCune > wrote: > > On 10/30/2014 04:53 AM, Bryan Kearney wrote: > > > > On 10/29/2014 08:34 PM, Eric D Helms wrote: > > Howdy, > > We are working on improving usability and one of our target > areas is > provisioning when Katello is present. To this end, we have > identified a > number of areas we could tackle to improve this workflow. > Below is an > outline of some ideas we have discussed and we welcome your > feedback. > > _Kickstart Repositories_ > Background > * The 6Server kickstart repository doesn't work the same as the > 6Server RPM repository and can be misleading to users > > Proposal > * Hide the 6Server kickstart repository from users (and only > expose > x.y kickstart repos) > > > No issues from me on this. > > > +1 > > > _Puppet Module Repositories_ > Background > * In the content views section, puppet modules are treated > as a single > giant list for the org > * Currently the only real advantage to defining different puppet > repositories is to lockdown the modules by setting > permissions on the > product the puppet modules belong to > > Proposal > * Have a single product/repo for every organization for > housing all > puppet modules > > > If there is a single repo.. how do I control when content is > synced from > the outside source? And, if I want to have puppet modules just > for one > env stream (say, my internal systems) I can not not control > that. This > seems a bit heavy handed. > > > seems a bit much, is this really causing that much heartburn? Being > able to get Puppet modules from various sources and not being > restricted to 1 source seems valuable. What if you want stuff fed > from local disk, a remote http hosted modules dir and the Puppet Forge? > > I could see perhaps one *product*, but the single repo restriction > seems way overboard. > > > _Host Groups_ > Background > * A host group and the Activation Key associated with it > could point > to different environment/content views > > Proposal > * Fix issue with Host content source not being inherited > from host > group properly > * Associate Activation Keys directly to hosts and hostgroups > > > What about ignoring the content view on the key if it is > specified in > the host group? > > > since the a-key is what determines what view you get during > registration I'd argue we should drive it entirely from the > Activation Key. Only specify it once and reduce the confusion. Why > not just put the Activation Key front and center on the Host and > Host Group main details screen? > > > For me, pushing the content onto the activation key doesn't make as much > as sense as the activation key pulling content information from the host > group. If the host group is my representation or "template" for a host > then I would want the content/installation media stored within that > representation and let the activation key drive configuring the content > and host post installation.

[Byron_Miller]

I agree with everything Stephen said below regarding puppet. Being able to
tie in git branches into the workflow would be awesome.

···

On Thu, Oct 30, 2014 at 11:04:01AM -0700, Mike McCune wrote: > > I would like to see some features like r10k. First, importing/exporting > a Librarian Puppetfile to/from a CVE, but even more importantly: using > git branches to manage the puppet modules present in a CVE, with an > option to monitor for changes and pushing those out to the smart > proxies. In this use case, I would assign a git repo to a content > view as the Puppet module source, and if I push to the 'Production' > branch, Katello will automatically republish the puppet modules in > Production with those modules (perhaps via the new incremental updates!). > > >