While working on some katello/foreman documentation focused on the
hammer cli, I recently realized how much less scriptable it is than the
old cli katello used to use. For example, previously you could simply
script something like (in pseudo-cli):
cli product create --name=Foo --organization=ACME
cli repo create --name=Bar --product=Foo --url=http://somegreatrepo/
cli repo sync --name=Bar
and your repo would be off syncing. Now if you were going to do
something similar you would have to do:
cli product create --name=Foo --organization=ACME
PROD_ID=cli product info --name=Foo --organization-id=ACME_Corporation | grep ID | head -n 1 | awk '{ print $2 }'
cli repository create --name=Bar --organization=ACME --product-id=$PROD_ID
REPO_ID=cli --csv repository list --organization-id=ACME_Corporation | grep ',Bar$' | awk -F ',' '{print $1}'
cli repository synchronize --id=$REPO_ID
This much much harder to script and seems like a huge stepback on this
front (hammer is AWESOME otherwise). The nature of hammer makes this
more complicated to do I understand, but is this a problem we want to solve?
-Justin
tomas is starting to look at this… I agree… it is a big issue.
– bk
···
On 04/02/2014 12:07 PM, Justin Sherrill wrote:
> While working on some katello/foreman documentation focused on the
> hammer cli, I recently realized how much less scriptable it is than the
> old cli katello used to use. For example, previously you could simply
> script something like (in pseudo-cli):
>
>
> cli product create --name=Foo --organization=ACME
> cli repo create --name=Bar --product=Foo --url=http://somegreatrepo/
> cli repo sync --name=Bar
>
>
> and your repo would be off syncing. Now if you were going to do
> something similar you would have to do:
>
> cli product create --name=Foo --organization=ACME
> PROD_ID=`cli product info --name=Foo
> --organization-id=ACME_Corporation | grep ID | head -n 1 | awk '{
> print $2 }'`
> cli repository create --name=Bar --organization=ACME --product-id=$PROD_ID
> REPO_ID=`cli --csv repository list --organization-id=ACME_Corporation |
> grep ',Bar$' | awk -F ',' '{print $1}'`
> cli repository synchronize --id=$REPO_ID
>
>
> This much much harder to script and seems like a huge stepback on this
> front (hammer is AWESOME otherwise). The nature of hammer makes this
> more complicated to do I understand, but is this a problem we want to
> solve?
>
> -Justin
>
I agree. The current implementation of name -> id translation doesn't
play well with katello api where most of the resources is scoped under
organization. I created a prototype of a new cross-cli approach that
should solve it for both foreman and katello part. It seems to work fine
so far.
I'd like to do a short demo. Let's say on Monday 14:30 (Brno time)?
Would that work for you?
Tomas
···
On 04/02/2014 06:08 PM, Bryan Kearney wrote:
> On 04/02/2014 12:07 PM, Justin Sherrill wrote:
>> While working on some katello/foreman documentation focused on the
>> hammer cli, I recently realized how much less scriptable it is than the
>> old cli katello used to use. For example, previously you could simply
>> script something like (in pseudo-cli):
>>
>>
>> cli product create --name=Foo --organization=ACME
>> cli repo create --name=Bar --product=Foo --url=http://somegreatrepo/
>> cli repo sync --name=Bar
>>
>>
>> and your repo would be off syncing. Now if you were going to do
>> something similar you would have to do:
>>
>> cli product create --name=Foo --organization=ACME
>> PROD_ID=`cli product info --name=Foo
>> --organization-id=ACME_Corporation | grep ID | head -n 1 | awk '{
>> print $2 }'`
>> cli repository create --name=Bar --organization=ACME
>> --product-id=$PROD_ID
>> REPO_ID=`cli --csv repository list --organization-id=ACME_Corporation |
>> grep ',Bar$' | awk -F ',' '{print $1}'`
>> cli repository synchronize --id=$REPO_ID
>>
>>
>> This much much harder to script and seems like a huge stepback on this
>> front (hammer is AWESOME otherwise). The nature of hammer makes this
>> more complicated to do I understand, but is this a problem we want to
>> solve?
>>
>> -Justin
>>
> tomas is starting to look at this... I agree... it is a big issue.
> -- bk
>
I guess you are complaining about the fact that label or name cant be used as a parameter. The older cli would do something like do a search call that takes in the label and gets the id. Basically this step.
"""
PROD_ID=`cli product info --name=Foo --organization-id=ACME_Corporation | grep ID | head -n 1 | awk '{ print $2 }')
"""
so you could pass in name or label, the cli will magically run this inside and then call the id. Not sure how hard is it to implement though :)…
Partha
···
----- Original Message -----
> From: "Justin Sherrill"
> To: foreman-dev@googlegroups.com
> Sent: Wednesday, April 2, 2014 12:13:23 PM
> Subject: Re: [foreman-dev] Scriptability of hammer
>
> On 04/02/2014 12:08 PM, Bryan Kearney wrote:
> > On 04/02/2014 12:07 PM, Justin Sherrill wrote:
> >> While working on some katello/foreman documentation focused on the
> >> hammer cli, I recently realized how much less scriptable it is than the
> >> old cli katello used to use. For example, previously you could simply
> >> script something like (in pseudo-cli):
> >>
> >>
> >> cli product create --name=Foo --organization=ACME
> >> cli repo create --name=Bar --product=Foo --url=http://somegreatrepo/
> >> cli repo sync --name=Bar
> >>
> >>
> >> and your repo would be off syncing. Now if you were going to do
> >> something similar you would have to do:
> >>
> >> cli product create --name=Foo --organization=ACME
> >> PROD_ID=`cli product info --name=Foo
> >> --organization-id=ACME_Corporation | grep ID | head -n 1 | awk '{
> >> print $2 }'`
> >> cli repository create --name=Bar --organization=ACME
> >> --product-id=$PROD_ID
> >> REPO_ID=`cli --csv repository list --organization-id=ACME_Corporation |
> >> grep ',Bar$' | awk -F ',' '{print $1}'`
> >> cli repository synchronize --id=$REPO_ID
> >>
> >>
> >> This much much harder to script and seems like a huge stepback on this
> >> front (hammer is AWESOME otherwise). The nature of hammer makes this
> >> more complicated to do I understand, but is this a problem we want to
> >> solve?
> >>
> >> -Justin
> >>
> > tomas is starting to look at this... I agree... it is a big issue.
> > -- bk
> >
> great to hear!
>
> --