Hi,
I'm working on implementing host related commands in Hammer (CLI for
Foreman). For most of the rest of the CLI commands we chose to mimic the
API as first step. For hosts it doesn't work. There is a lot of
parameters with varying level of nesting which is difficult to translate
to CLI args. The result usability is poor (no surprise :-/)
We tried to focus on following stories
- As an user I want to create host from my scripts
- As an user I want to keep and reuse (and possibly share) my host
parameters
- As a novice user I want to be able to figure out the right prams for
my host
Here is what we come up with Tomas after short brainstorming yesterday:
We would like to introduce host templates in CLI which will be stored
set of arguments with some name. It shall be
-
produced by CLI wizard guiding you through the setup (similar to
UI) (or by existing host inspection if possible)
-
stored locally in some template folder as yaml file identified by name
-
possible to view, edit, clone, export, import
-
used as in:
hammer host create --name my_host --template
simple_libvirt_host --environment test …
where args on CLI have precedence and override those from template
This would introduce following commands to the hammer:
- host template create # the wizard
- host template update # the wizard wit defaults set to values from
existing template
- host template update network # update template and skip parts
other then network related
- host template update os
- host template update vm
- host template list
- host template info
- host template delete
- host template dump #dump template to stdout or file to share
- host template load #load template from file
I would like to discuss if this approach would be acceptable for the
users and if it will match their use cases.
I appreciate any comments and ideas.
Regards,
Martin
This sounds like what host groups are meant to achieve, so I'd prefer
not to see duplicate functionality and making it CLI-only.
Most of the args mentioned in your other post, such as OS, Puppet
proxies, environment should flow from the host group. I can imagine
though that this has been optimised for the UI (with AJAX helpers and
the like), so perhaps it doesn't work automatically through the API…
but if that's the case, then that's the bug to fix, not to add another
layer of functionality.
···
On 27/08/13 10:01, Martin Bačovský wrote:
> Hi,
>
> I'm working on implementing host related commands in Hammer (CLI for
> Foreman). For most of the rest of the CLI commands we chose to mimic the
> API as first step. For hosts it doesn't work. There is a lot of
> parameters with varying level of nesting which is difficult to translate
> to CLI args. The result usability is poor (no surprise :-/)
>
> We tried to focus on following stories
>
> - As an user I want to create host from my scripts
> - As an user I want to keep and reuse (and possibly share) my host
> parameters
> - As a novice user I want to be able to figure out the right prams for
> my host
>
> Here is what we come up with Tomas after short brainstorming yesterday:
>
> We would like to introduce host templates in CLI which will be stored
> set of arguments with some name. It shall be
> - produced by CLI wizard guiding you through the setup (similar to
> UI) (or by existing host inspection if possible)
> - stored locally in some template folder as yaml file identified by name
> - possible to view, edit, clone, export, import
–
Dominic Cleal
Red Hat Engineering
>> Hi,
>>
>> I'm working on implementing host related commands in Hammer (CLI for
>> Foreman). For most of the rest of the CLI commands we chose to mimic the
>> API as first step. For hosts it doesn't work. There is a lot of
>> parameters with varying level of nesting which is difficult to translate
>> to CLI args. The result usability is poor (no surprise :-/)
>>
>> We tried to focus on following stories
>>
>> - As an user I want to create host from my scripts
>> - As an user I want to keep and reuse (and possibly share) my host
>> parameters
>> - As a novice user I want to be able to figure out the right prams for
>> my host
>>
>> Here is what we come up with Tomas after short brainstorming yesterday:
>>
>> We would like to introduce host templates in CLI which will be stored
>> set of arguments with some name. It shall be
>> - produced by CLI wizard guiding you through the setup (similar to
>> UI) (or by existing host inspection if possible)
>> - stored locally in some template folder as yaml file identified by name
>> - possible to view, edit, clone, export, import
> This sounds like what host groups are meant to achieve, so I'd prefer
> not to see duplicate functionality and making it CLI-only.
Yes, there is quite big overlap with hostgroups. But when I tried to
figure out the "right" args
biggest frustration came from the compute_attributes and
interface_attributes which are not covered by hostgroup.
Is there any way to pre set them elsewhere? Would it make sense to add
them to HG?
And yes the templates would be pure CLI. No support in foreman is
necessary. It is just saved params for the API call with some commands
to work with it.
>
> Most of the args mentioned in your other post, such as OS, Puppet
> proxies, environment should flow from the host group. I can imagine
> though that this has been optimised for the UI (with AJAX helpers and
> the like), so perhaps it doesn't work automatically through the API…
> but if that's the case, then that's the bug to fix, not to add another
> layer of functionality.
>
Good point, some of the args are required when don't have to be. I'll
add check that, it seems it is jjust in apidoc and api bindings.
But it does not relieve the pain of compute/interface_attributes…
Regards,
Martin
···
On 08/27/2013 11:27 AM, Dominic Cleal wrote:
> On 27/08/13 10:01, Martin Bačovský wrote:
> Hi,
>
> I'm working on implementing host related commands in Hammer (CLI for
> Foreman). For most of the rest of the CLI commands we chose to mimic the
> API as first step. For hosts it doesn't work. There is a lot of
> parameters with varying level of nesting which is difficult to translate
> to CLI args. The result usability is poor (no surprise :-/)
>
> We tried to focus on following stories
>
> - As an user I want to create host from my scripts
> - As an user I want to keep and reuse (and possibly share) my host
> parameters
> - As a novice user I want to be able to figure out the right prams for
> my host
>
> Here is what we come up with Tomas after short brainstorming yesterday:
>
> We would like to introduce host templates in CLI which will be stored
> set of arguments with some name. It shall be
> - produced by CLI wizard guiding you through the setup (similar to UI)
> (or by existing host inspection if possible)
> - stored locally in some template folder as yaml file identified by name
> - possible to view, edit, clone, export, import
> - used as in:
>
> hammer host create --name my_host --template simple_libvirt_host
> --environment test …
>
> where args on CLI have precedence and override those from template
>
> This would introduce following commands to the hammer:
>
> - host template create # the wizard
> - host template update # the wizard wit defaults set to values from
> existing template
> - host template update network # update template and skip parts other
> then network related
> - host template update os
> - host template update vm
> - host template list
> - host template info
> - host template delete
> - host template dump #dump template to stdout or file to share
> - host template load #load template from file
>
>
> I would like to discuss if this approach would be acceptable for the
> users and if it will match their use cases.
I really like the idea of making many of the same hosts using a
template; it's particularly useful when scripted. That being said, I
think we should introduce the concept of templates directly into Foreman
instead of a CLI-only implementation.
That being said, we can probably use hostgroups to accomplish a lot of
what the CLI needs. They already provide basics like classes, params, OS
metadata, and the like. Maybe having an interactive hostgroup creation
wizard would be a good stop-gap measure until the CLI is more complete?
···
On 08/27/2013 05:01 AM, Martin Bačovský wrote:
I appreciate any comments and ideas.
Regards,
Martin
>>> Hi,
>>>
>>> I'm working on implementing host related commands in Hammer (CLI for
>>> Foreman). For most of the rest of the CLI commands we chose to mimic the
>>> API as first step. For hosts it doesn't work. There is a lot of
>>> parameters with varying level of nesting which is difficult to translate
>>> to CLI args. The result usability is poor (no surprise :-/)
>>>
>>> We tried to focus on following stories
>>>
>>> - As an user I want to create host from my scripts
>>> - As an user I want to keep and reuse (and possibly share) my host
>>> parameters
>>> - As a novice user I want to be able to figure out the right prams for
>>> my host
>>>
>>> Here is what we come up with Tomas after short brainstorming yesterday:
>>>
>>> We would like to introduce host templates in CLI which will be stored
>>> set of arguments with some name. It shall be
>>> - produced by CLI wizard guiding you through the setup (similar to
>>> UI) (or by existing host inspection if possible)
>>> - stored locally in some template folder as yaml file identified by name
>>> - possible to view, edit, clone, export, import
>> This sounds like what host groups are meant to achieve, so I'd prefer
>> not to see duplicate functionality and making it CLI-only.
> Yes, there is quite big overlap with hostgroups. But when I tried to
> figure out the "right" args
> biggest frustration came from the compute_attributes and
> interface_attributes which are not covered by hostgroup.
> Is there any way to pre set them elsewhere? Would it make sense to add
> them to HG?
Most definitely, the compute_attibutes issue really needs fixing and I
think was in scope for the host group redesign that we keep mentioning.
There's no way to preset them at the moment, so you're right that it's
a problem, I just don't think adding another mechanism local to the CLI
is the right way to do it.
> And yes the templates would be pure CLI. No support in foreman is
> necessary. It is just saved params for the API call with some commands
> to work with it.
Yeah, that's a shame to me and I think we should avoid adding it if
possible.
···
On 27/08/13 10:55, Martin Bačovský wrote:
> On 08/27/2013 11:27 AM, Dominic Cleal wrote:
>> On 27/08/13 10:01, Martin Bačovský wrote:
–
Dominic Cleal
Red Hat Engineering
Is seems that templates and hostgroups would overlap a lot so improving
hostgroups makes much more sense.
On the other hand it doesn't address the cli usability part. As Sam
suggested we should then have some wizard to create hostgroup and
probably also host. Ivan suggested the wizard to produce the "right" CLI
args insted of template. Though I like it I'm tempted to keep them named
and stored somewhere, but not necessarily for the start.
So my new suggestion is:
- improve hostgroups to keep more settings
- add more args logic to hammer (like in UI)
- add params like --network-type=NAT that translates to proper API
args
- add wizards for hostgroup and host something like:
$hammer hostgroup wizard
… questions …
To create hostgroup XY run "hostgroup create --name XY --…"
Would that be more acceptable?
Martin
···
On 08/27/2013 08:40 PM, Sam Kottler wrote:
> On 08/27/2013 05:01 AM, Martin Bačovský wrote:
>> Hi,
>>
>> I'm working on implementing host related commands in Hammer (CLI for
>> Foreman). For most of the rest of the CLI commands we chose to mimic the
>> API as first step. For hosts it doesn't work. There is a lot of
>> parameters with varying level of nesting which is difficult to translate
>> to CLI args. The result usability is poor (no surprise :-/)
>>
>> We tried to focus on following stories
>>
>> - As an user I want to create host from my scripts
>> - As an user I want to keep and reuse (and possibly share) my host
>> parameters
>> - As a novice user I want to be able to figure out the right prams for
>> my host
>>
>> Here is what we come up with Tomas after short brainstorming yesterday:
>>
>> We would like to introduce host templates in CLI which will be stored
>> set of arguments with some name. It shall be
>> - produced by CLI wizard guiding you through the setup (similar to UI)
>> (or by existing host inspection if possible)
>> - stored locally in some template folder as yaml file identified by name
>> - possible to view, edit, clone, export, import
>> - used as in:
>>
>> hammer host create --name my_host --template simple_libvirt_host
>> --environment test ...
>>
>> where args on CLI have precedence and override those from template
>>
>> This would introduce following commands to the hammer:
>>
>> - host template create # the wizard
>> - host template update # the wizard wit defaults set to values from
>> existing template
>> - host template update network # update template and skip parts other
>> then network related
>> - host template update os
>> - host template update vm
>> - host template list
>> - host template info
>> - host template delete
>> - host template dump #dump template to stdout or file to share
>> - host template load #load template from file
>>
>>
>> I would like to discuss if this approach would be acceptable for the
>> users and if it will match their use cases.
> I really like the idea of making many of the same hosts using a
> template; it's particularly useful when scripted. That being said, I
> think we should introduce the concept of templates directly into Foreman
> instead of a CLI-only implementation.
>
> That being said, we can probably use hostgroups to accomplish a lot of
> what the CLI needs. They already provide basics like classes, params, OS
> metadata, and the like. Maybe having an interactive hostgroup creation
> wizard would be a good stop-gap measure until the CLI is more complete?
>
