Hi team,
past 2 weeks Martin and me have been working on a new CLI for Foreman.
Ideas from initial design started turning into reality and we finally
have some real code in our hands.
Until now it still lived in Martin's git repo [1] as a draft. I think it
is about time to move it to Foreman's org and make the repos official.
We used to call the cli Kartit which was rather a working title.
Previously Bryan Gupta was creating a cli named Hammer [2]. Our efforts
are built on the same technologies so it can be seen as a follow-up.
We like that awesome name and Bryan agreed we could reuse it.
Hammer - does it sound suitable to you? Any other suggestions you find
better?
After a short discussion today morning we come with following proposal
for dividing the current repo into 3 new (one gem per repo):
- hammer - containing the core libs
- hammer-foreman - containing the foreman specific commands
- hammer-katello-bridge - containing the wrapper around katello cli
Later, if Katello team decides to adopt Hammer and creates a native
plugin, we can create a repo hammer-katello in Katllo org. For now all
of them would be in Foreman's org as it makes no sense to install them
alone. In the future there will most likely be one more plugin
hammer-signo for commands connected to sso.
Does this division make sense?
I also tried to put together more CLI stories for our backlog:
- As a user, I'd like to have CLI localised (gettext support)
- As a user, I'd like CLI to log actions and failures
- As a user, I'd like Foreman CLI to have output format unified with
Katello
- As a developer, I'd like to have travis running tests for each CLI
pull request
- As a user, I'd like to have CLI packaged (and built in Koji)
(already on the backlog)
- As a CLI user, I'd like to store default parameter values
Cheers
Tomas
[1] https://github.com/mbacovsky/foreman_cli_draft
[2] https://github.com/theforeman/foreman-hammer
> Hi team,
> past 2 weeks Martin and me have been working on a new CLI for Foreman.
> Ideas from initial design started turning into reality and we finally
> have some real code in our hands.
> Until now it still lived in Martin's git repo [1] as a draft. I think it
> is about time to move it to Foreman's org and make the repos official.
+1
>
> We used to call the cli Kartit which was rather a working title.
> Previously Bryan Gupta was creating a cli named Hammer [2]. Our efforts
> are built on the same technologies so it can be seen as a follow-up.
> We like that awesome name and Bryan agreed we could reuse it.
> Hammer - does it sound suitable to you? Any other suggestions you find
> better?
>
+1
>
> After a short discussion today morning we come with following proposal
> for dividing the current repo into 3 new (one gem per repo):
> - hammer - containing the core libs
> - hammer-foreman - containing the foreman specific commands
> - hammer-katello-bridge - containing the wrapper around katello cli
> Later, if Katello team decides to adopt Hammer and creates a native
> plugin, we can create a repo hammer-katello in Katllo org. For now all
> of them would be in Foreman's org as it makes no sense to install them
> alone. In the future there will most likely be one more plugin
> hammer-signo for commands connected to sso.
>
> Does this division make sense?
+1
>
>
> I also tried to put together more CLI stories for our backlog:
> - As a user, I'd like to have CLI localised (gettext support)
> - As a user, I'd like CLI to log actions and failures
> - As a user, I'd like Foreman CLI to have output format unified with
> Katello
> - As a developer, I'd like to have travis running tests for each CLI
> pull request
> - As a user, I'd like to have CLI packaged (and built in Koji)
> (already on the backlog)
My assumption is that the cli can be on a different machine then the server.
> - As a CLI user, I'd like to store default parameter values
>
This looks good. The rest for me would be to continue to increase the
scope of the cli and api. In the end, the goal is to be able to do all
work via the cli.
– bk
···
On 06/27/2013 06:13 AM, Tomas Strachota wrote:
Sounds great guys… I'll try to check it out this weekend, and see
about getting you some feedback, but I've been super swamped.
One question… what do you guys feel about API compatibility? (My
vision was that the cli should be able to support older versions of
Foreman since we now have versioned APIs. I'd of course not expect to
support earlier than 1.0).
-Brian Gupta
···
On Thu, Jun 27, 2013 at 6:13 AM, Tomas Strachota wrote:
> Hi team,
> past 2 weeks Martin and me have been working on a new CLI for Foreman. Ideas
> from initial design started turning into reality and we finally have some
> real code in our hands.
> Until now it still lived in Martin's git repo [1] as a draft. I think it is
> about time to move it to Foreman's org and make the repos official.
>
> We used to call the cli Kartit which was rather a working title. Previously
> Bryan Gupta was creating a cli named Hammer [2]. Our efforts are built on
> the same technologies so it can be seen as a follow-up.
> We like that awesome name and Bryan agreed we could reuse it.
> Hammer - does it sound suitable to you? Any other suggestions you find
> better?
>
>
> After a short discussion today morning we come with following proposal for
> dividing the current repo into 3 new (one gem per repo):
> - hammer - containing the core libs
> - hammer-foreman - containing the foreman specific commands
> - hammer-katello-bridge - containing the wrapper around katello cli
> Later, if Katello team decides to adopt Hammer and creates a native plugin,
> we can create a repo hammer-katello in Katllo org. For now all of them would
> be in Foreman's org as it makes no sense to install them alone. In the
> future there will most likely be one more plugin hammer-signo for commands
> connected to sso.
>
> Does this division make sense?
>
>
> I also tried to put together more CLI stories for our backlog:
> - As a user, I'd like to have CLI localised (gettext support)
> - As a user, I'd like CLI to log actions and failures
> - As a user, I'd like Foreman CLI to have output format unified with
> Katello
> - As a developer, I'd like to have travis running tests for each CLI pull
> request
> - As a user, I'd like to have CLI packaged (and built in Koji) (already on
> the backlog)
> - As a CLI user, I'd like to store default parameter values
>
> Cheers
> Tomas
>
> [1] https://github.com/mbacovsky/foreman_cli_draft
> [2] https://github.com/theforeman/foreman-hammer
>
Our package builds are triggered from Jenkins build results, so tests
should run on there. Whether you want to do that as well as Travis or
instead of is up to you, but I'd say we must have some tests in Jenkins.
If the CLI is part of the Foreman project and releases, the repo should
be set up in the same way with a "develop" branch, merged into master on
each release and for it to follow the usual release process:
http://projects.theforeman.org/projects/foreman/wiki/Release_Process
This also means the CLI must be packaged for Debian. Will it be
released as a gem too?
···
On 27/06/13 11:13, Tomas Strachota wrote:
> I also tried to put together more CLI stories for our backlog:
> - As a user, I'd like to have CLI localised (gettext support)
> - As a user, I'd like CLI to log actions and failures
> - As a user, I'd like Foreman CLI to have output format unified with
> Katello
> - As a developer, I'd like to have travis running tests for each CLI
> pull request
> - As a user, I'd like to have CLI packaged (and built in Koji)
> (already on the backlog)
–
Dominic Cleal
Red Hat Engineering
We didn't intend to make the cli compatible with v1. We build it around
foreman-api gem using v2.
I'm not sure how difficult it would be to support v1. Most of command
options is created dynamically and could adapt without any effort. It
would be more complicated to adjust output as it can differ between
versions. I guess we would have to distinguish between output
definitions for each version.
T.
···
On 06/28/2013 12:36 AM, Brian Gupta wrote:
> On Thu, Jun 27, 2013 at 6:13 AM, Tomas Strachota wrote:
>> Hi team,
>> past 2 weeks Martin and me have been working on a new CLI for Foreman. Ideas
>> from initial design started turning into reality and we finally have some
>> real code in our hands.
>> Until now it still lived in Martin's git repo [1] as a draft. I think it is
>> about time to move it to Foreman's org and make the repos official.
>>
>> We used to call the cli Kartit which was rather a working title. Previously
>> Bryan Gupta was creating a cli named Hammer [2]. Our efforts are built on
>> the same technologies so it can be seen as a follow-up.
>> We like that awesome name and Bryan agreed we could reuse it.
>> Hammer - does it sound suitable to you? Any other suggestions you find
>> better?
>>
>>
>> After a short discussion today morning we come with following proposal for
>> dividing the current repo into 3 new (one gem per repo):
>> - hammer - containing the core libs
>> - hammer-foreman - containing the foreman specific commands
>> - hammer-katello-bridge - containing the wrapper around katello cli
>> Later, if Katello team decides to adopt Hammer and creates a native plugin,
>> we can create a repo hammer-katello in Katllo org. For now all of them would
>> be in Foreman's org as it makes no sense to install them alone. In the
>> future there will most likely be one more plugin hammer-signo for commands
>> connected to sso.
>>
>> Does this division make sense?
>>
>>
>> I also tried to put together more CLI stories for our backlog:
>> - As a user, I'd like to have CLI localised (gettext support)
>> - As a user, I'd like CLI to log actions and failures
>> - As a user, I'd like Foreman CLI to have output format unified with
>> Katello
>> - As a developer, I'd like to have travis running tests for each CLI pull
>> request
>> - As a user, I'd like to have CLI packaged (and built in Koji) (already on
>> the backlog)
>> - As a CLI user, I'd like to store default parameter values
>>
>> Cheers
>> Tomas
>>
>> [1] https://github.com/mbacovsky/foreman_cli_draft
>> [2] https://github.com/theforeman/foreman-hammer
>>
>
> Sounds great guys.. I'll try to check it out this weekend, and see
> about getting you some feedback, but I've been super swamped.
>
> One question.. what do you guys feel about API compatibility? (My
> vision was that the cli should be able to support older versions of
> Foreman since we now have versioned APIs. I'd of course not expect to
> support earlier than 1.0).
>
> -Brian Gupta
>
>> I also tried to put together more CLI stories for our backlog:
>> - As a user, I'd like to have CLI localised (gettext support)
>> - As a user, I'd like CLI to log actions and failures
>> - As a user, I'd like Foreman CLI to have output format unified with
>> Katello
>> - As a developer, I'd like to have travis running tests for each CLI
>> pull request
>> - As a user, I'd like to have CLI packaged (and built in Koji)
>> (already on the backlog)
>
> Our package builds are triggered from Jenkins build results, so tests
> should run on there. Whether you want to do that as well as Travis or
> instead of is up to you, but I'd say we must have some tests in Jenkins.
>
> If the CLI is part of the Foreman project and releases, the repo should
> be set up in the same way with a "develop" branch, merged into master on
> each release and for it to follow the usual release process:
>
> Release Process - Foreman
>
> This also means the CLI must be packaged for Debian. Will it be
> released as a gem too?
I'd agree that the CLI is the one piece of foreman that makes the most
sense to release as a gem. (foremancli is available as a a gem, and I
planned to do so with hammer as well.) If the team working on the cli
need any help making the gem they should feel free to ask. And I took
too long seems that hammer is now taken in the gem namespace.
http://rubygems.org/gems/hammer Guess we'll need to go with
foreman-hammer and katello-hammer with the common libs in
foreman-hammer-common?
I'm suggesting this as users installing will only care about the
package they care about, and the names should be simple and obvious.
e.g.
- I want to install standard hammer: gem install foreman-hammer
- I want to install the combined katello/hammer cli: gem install katello-hammer
Please let me know if you need any help with the gem stuff as I built
and maintain the foremancli gem (which admittedly atm requires little
to no work.)
BTW smart-proxy might make sense to release as a gem as well.
···
On Fri, Jun 28, 2013 at 5:20 AM, Dominic Cleal wrote:
> On 27/06/13 11:13, Tomas Strachota wrote:
–
Dominic Cleal
Red Hat Engineering
–
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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
>> I also tried to put together more CLI stories for our backlog:
>> - As a user, I'd like to have CLI localised (gettext support)
>> - As a user, I'd like CLI to log actions and failures
>> - As a user, I'd like Foreman CLI to have output format unified with
>> Katello
>> - As a developer, I'd like to have travis running tests for each CLI
>> pull request
>> - As a user, I'd like to have CLI packaged (and built in Koji)
>> (already on the backlog)
>
> Our package builds are triggered from Jenkins build results, so tests
> should run on there. Whether you want to do that as well as Travis or
> instead of is up to you, but I'd say we must have some tests in Jenkins.
We can change the story to use Jenkins then. I don't mind at all. The
point is to have tests triggered upon a pull request.
> If the CLI is part of the Foreman project and releases, the repo should
> be set up in the same way with a "develop" branch, merged into master on
> each release and for it to follow the usual release process:
>
> Release Process - Foreman
Having it tied to foreman builds seems logical to me. I see consistent
repo branch setup as a plus.
>
> This also means the CLI must be packaged for Debian. Will it be
> released as a gem too?
>
I think debian packages are kind of standard for foreman-related
projects. I agree we should create one. Do we have somebody skilled in
that area? If not I'll at least learn something new;)
I count with releasing a gem. We were not alone with such idea for a gem
name:
https://rubygems.org/search?&query=hammer
I guess we will have to use some prefix. Maybe foreman_hammer and
foreman_hammer_{foreman,katello,…}?
T.
···
On 06/28/2013 11:20 AM, Dominic Cleal wrote:
> On 27/06/13 11:13, Tomas Strachota wrote:
Also, since CLI tools are fairly self contained, you could reach out
to the maintainer of the Debian Sid package of foremancli:
http://packages.debian.org/sid/foremancli
···
On Fri, Jun 28, 2013 at 12:17 PM, Greg Sutcliffe wrote:
> On 28 June 2013 17:06, Tomas Strachota wrote:
>>
>>
>> I think debian packages are kind of standard for foreman-related projects.
>> I agree we should create one. Do we have somebody skilled in that area? If
>> not I'll at least learn something new;)
>
>
> I can help, ping me when you're ready to look at this.
>
> Greg
>
> --
> 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+unsubscribe@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
I can help, ping me when you're ready to look at this.
Greg
···
On 28 June 2013 17:06, Tomas Strachota wrote:
I think debian packages are kind of standard for foreman-related projects.
I agree we should create one. Do we have somebody skilled in that area? If
not I’ll at least learn something new;)
>> This also means the CLI must be packaged for Debian. Will it be
>> released as a gem too?
>
> I think debian packages are kind of standard for foreman-related
> projects. I agree we should create one. Do we have somebody skilled in
> that area? If not I'll at least learn something new;)
I volunteer Greg, but also think Marek might know about Debian packaging
too? 
The docs on how packages are built are here:
http://projects.theforeman.org/projects/foreman/wiki/Debian_Packaging
It has links to the foreman-rpms repo, and specifically the deb/* branches.
> I count with releasing a gem. We were not alone with such idea for a gem
> name:
> https://rubygems.org/search?&query=hammer
>
> I guess we will have to use some prefix. Maybe foreman_hammer and
> foreman_hammer_{foreman,katello,…}?
Hm, shame it's repetitive… anybody got a better idea? I don't.
···
On 28/06/13 17:06, Tomas Strachota wrote:
> On 06/28/2013 11:20 AM, Dominic Cleal wrote:
–
Dominic Cleal
Red Hat Engineering
Unfortunately I don't have too much experience with Debian packaging however
I'd be very happy to learn it Also I volunteer for testing.
···
On Friday 28 of June 2013 17:29:26 Dominic Cleal wrote:
> On 28/06/13 17:06, Tomas Strachota wrote:
> > On 06/28/2013 11:20 AM, Dominic Cleal wrote:
> >> This also means the CLI must be packaged for Debian. Will it be
> >> released as a gem too?
> >
> > I think debian packages are kind of standard for foreman-related
> > projects. I agree we should create one. Do we have somebody skilled in
> > that area? If not I'll at least learn something new;)
>
> I volunteer Greg, but also think Marek might know about Debian packaging
> too? :)
–
Marek
This sounds good. I was thinking about very similar approach:
Gems:
- hammer-cli - common libs
- hammer-cli-foreman - Foreman specific commands
- hammer-cli-katello - Katello specific commands
- hammer-cli-signo - plugin with commands for managing
SSO keys
- hammer-cli-foreman-admin - commands wrapping Foreman administration
tools
…
Standalone Foreman: hammer-cli + hammer-cli-foreman + optional?
hammer-cli-signo, hammer-cli-foreman-admin
Standalone Katello: hammer-cli + hammer-cli-katello + optional?
hammer-cli-signo, hammer-cli-katello-admin
Foreman + Katello: hammer-cli + hammer-cli-katello + hammer-cli_foreman
- hammer-cli-signo + probably some hammer-cli-katello-foreman that would
fix conflicting command in Katello and Foreman
This could help to reuse and extend our gems for other projects willing
to adopt our tool set
Does that make sense?
Martin
···
On 06/28/2013 06:55 PM, Brian Gupta wrote:
> On Fri, Jun 28, 2013 at 5:20 AM, Dominic Cleal wrote:
>> On 27/06/13 11:13, Tomas Strachota wrote:
>>> I also tried to put together more CLI stories for our backlog:
>>> - As a user, I'd like to have CLI localised (gettext support)
>>> - As a user, I'd like CLI to log actions and failures
>>> - As a user, I'd like Foreman CLI to have output format unified with
>>> Katello
>>> - As a developer, I'd like to have travis running tests for each CLI
>>> pull request
>>> - As a user, I'd like to have CLI packaged (and built in Koji)
>>> (already on the backlog)
>> Our package builds are triggered from Jenkins build results, so tests
>> should run on there. Whether you want to do that as well as Travis or
>> instead of is up to you, but I'd say we must have some tests in Jenkins.
>>
>> If the CLI is part of the Foreman project and releases, the repo should
>> be set up in the same way with a "develop" branch, merged into master on
>> each release and for it to follow the usual release process:
>>
>> http://projects.theforeman.org/projects/foreman/wiki/Release_Process
>>
>> This also means the CLI must be packaged for Debian. Will it be
>> released as a gem too?
> I'd agree that the CLI is the one piece of foreman that makes the most
> sense to release as a gem. (foremancli is available as a a gem, and I
> planned to do so with hammer as well.) If the team working on the cli
> need any help making the gem they should feel free to ask. And I took
> too long seems that hammer is now taken in the gem namespace.
> http://rubygems.org/gems/hammer Guess we'll need to go with
> foreman-hammer and katello-hammer with the common libs in
> foreman-hammer-common?
>
> I'm suggesting this as users installing will only care about the
> package they care about, and the names should be simple and obvious.
> e.g.
> - I want to install standard hammer: gem install foreman-hammer
> - I want to install the combined katello/hammer cli: gem install katello-hammer
>
> Please let me know if you need any help with the gem stuff as I built
> and maintain the foremancli gem (which admittedly atm requires little
> to no work.)
>
> BTW smart-proxy *might* make sense to release as a gem as well.
>
>>>> I also tried to put together more CLI stories for our backlog:
>>>> - As a user, I'd like to have CLI localised (gettext support)
>>>> - As a user, I'd like CLI to log actions and failures
>>>> - As a user, I'd like Foreman CLI to have output format unified with
>>>> Katello
>>>> - As a developer, I'd like to have travis running tests for each CLI
>>>> pull request
>>>> - As a user, I'd like to have CLI packaged (and built in Koji)
>>>> (already on the backlog)
>>> Our package builds are triggered from Jenkins build results, so tests
>>> should run on there. Whether you want to do that as well as Travis or
>>> instead of is up to you, but I'd say we must have some tests in Jenkins.
>>>
>>> If the CLI is part of the Foreman project and releases, the repo should
>>> be set up in the same way with a "develop" branch, merged into master on
>>> each release and for it to follow the usual release process:
>>>
>>> Release Process - Foreman
>>>
>>> This also means the CLI must be packaged for Debian. Will it be
>>> released as a gem too?
>> I'd agree that the CLI is the one piece of foreman that makes the most
>> sense to release as a gem. (foremancli is available as a a gem, and I
>> planned to do so with hammer as well.) If the team working on the cli
>> need any help making the gem they should feel free to ask. And I took
>> too long seems that hammer is now taken in the gem namespace.
>> http://rubygems.org/gems/hammer Guess we'll need to go with
>> foreman-hammer and katello-hammer with the common libs in
>> foreman-hammer-common?
>>
>> I'm suggesting this as users installing will only care about the
>> package they care about, and the names should be simple and obvious.
>> e.g.
>> - I want to install standard hammer: gem install foreman-hammer
>> - I want to install the combined katello/hammer cli: gem install katello-hammer
>>
>> Please let me know if you need any help with the gem stuff as I built
>> and maintain the foremancli gem (which admittedly atm requires little
>> to no work.)
>>
>> BTW smart-proxy might make sense to release as a gem as well.
>>
> This sounds good. I was thinking about very similar approach:
>
> Gems:
> - hammer-cli - common libs
> - hammer-cli-foreman - Foreman specific commands
> - hammer-cli-katello - Katello specific commands
> - hammer-cli-signo - plugin with commands for managing
> SSO keys
> - hammer-cli-foreman-admin - commands wrapping Foreman administration
> tools
What sort of things would go in here?
> …
>
> Standalone Foreman: hammer-cli + hammer-cli-foreman + optional?
> hammer-cli-signo, hammer-cli-foreman-admin
> Standalone Katello: hammer-cli + hammer-cli-katello + optional?
> hammer-cli-signo, hammer-cli-katello-admin
> Foreman + Katello: hammer-cli + hammer-cli-katello + hammer-cli_foreman
> + hammer-cli-signo + probably some hammer-cli-katello-foreman that would
> fix conflicting command in Katello and Foreman
>
> This could help to reuse and extend our gems for other projects willing
> to adopt our tool set
>
> Does that make sense?
I like this.
···
On 01/07/13 10:21, Martin Bačovský wrote:
> On 06/28/2013 06:55 PM, Brian Gupta wrote:
>> On Fri, Jun 28, 2013 at 5:20 AM, Dominic Cleal wrote:
>>> On 27/06/13 11:13, Tomas Strachota wrote:
–
Dominic Cleal
Red Hat Engineering
>>>>> I also tried to put together more CLI stories for our backlog:
>>>>> - As a user, I'd like to have CLI localised (gettext support)
>>>>> - As a user, I'd like CLI to log actions and failures
>>>>> - As a user, I'd like Foreman CLI to have output format unified with
>>>>> Katello
>>>>> - As a developer, I'd like to have travis running tests for each CLI
>>>>> pull request
>>>>> - As a user, I'd like to have CLI packaged (and built in Koji)
>>>>> (already on the backlog)
>>>> Our package builds are triggered from Jenkins build results, so tests
>>>> should run on there. Whether you want to do that as well as Travis or
>>>> instead of is up to you, but I'd say we must have some tests in Jenkins.
>>>>
>>>> If the CLI is part of the Foreman project and releases, the repo should
>>>> be set up in the same way with a "develop" branch, merged into master on
>>>> each release and for it to follow the usual release process:
>>>>
>>>> Release Process - Foreman
>>>>
>>>> This also means the CLI must be packaged for Debian. Will it be
>>>> released as a gem too?
>>> I'd agree that the CLI is the one piece of foreman that makes the most
>>> sense to release as a gem. (foremancli is available as a a gem, and I
>>> planned to do so with hammer as well.) If the team working on the cli
>>> need any help making the gem they should feel free to ask. And I took
>>> too long seems that hammer is now taken in the gem namespace.
>>> http://rubygems.org/gems/hammer Guess we'll need to go with
>>> foreman-hammer and katello-hammer with the common libs in
>>> foreman-hammer-common?
>>>
>>> I'm suggesting this as users installing will only care about the
>>> package they care about, and the names should be simple and obvious.
>>> e.g.
>>> - I want to install standard hammer: gem install foreman-hammer
>>> - I want to install the combined katello/hammer cli: gem install katello-hammer
>>>
>>> Please let me know if you need any help with the gem stuff as I built
>>> and maintain the foremancli gem (which admittedly atm requires little
>>> to no work.)
>>>
>>> BTW smart-proxy might make sense to release as a gem as well.
>>>
>> This sounds good. I was thinking about very similar approach:
>>
>> Gems:
>> - hammer-cli - common libs
>> - hammer-cli-foreman - Foreman specific commands
>> - hammer-cli-katello - Katello specific commands
>> - hammer-cli-signo - plugin with commands for managing
>> SSO keys
>> - hammer-cli-foreman-admin - commands wrapping Foreman administration
>> tools
> What sort of things would go in here?
In Katello there some scripts to help setup and diagnose katello like
katello-debug, katello-certs-debug, etc. I'm not sure if there are such
scripts in the Foreman, but it seemed interesting to include them in the
cli, so that you could run 'hammer-cli admin-tools --help' and see the
list with help and params in one place. The plugin would be bridge same
as we use with the current katello cli. But that is just an idea…
···
On 07/01/2013 07:27 PM, Dominic Cleal wrote:
> On 01/07/13 10:21, Martin Bačovský wrote:
>> On 06/28/2013 06:55 PM, Brian Gupta wrote:
>>> On Fri, Jun 28, 2013 at 5:20 AM, Dominic Cleal wrote:
>>>> On 27/06/13 11:13, Tomas Strachota wrote:
…
Standalone Foreman: hammer-cli + hammer-cli-foreman + optional?
hammer-cli-signo, hammer-cli-foreman-admin
Standalone Katello: hammer-cli + hammer-cli-katello + optional?
hammer-cli-signo, hammer-cli-katello-admin
Foreman + Katello: hammer-cli + hammer-cli-katello + hammer-cli_foreman
- hammer-cli-signo + probably some hammer-cli-katello-foreman that would
fix conflicting command in Katello and Foreman
This could help to reuse and extend our gems for other projects willing
to adopt our tool set
Does that make sense?
I like this.
Lukas put in the foreman debug scripts.
···
On 07/02/2013 05:04 AM, Martin Bačovský wrote:
> On 07/01/2013 07:27 PM, Dominic Cleal wrote:
>> On 01/07/13 10:21, Martin Bačovský wrote:
>>> On 06/28/2013 06:55 PM, Brian Gupta wrote:
>>>> On Fri, Jun 28, 2013 at 5:20 AM, Dominic Cleal >>>> wrote:
>>>>> On 27/06/13 11:13, Tomas Strachota wrote:
>>>>>> I also tried to put together more CLI stories for our backlog:
>>>>>> - As a user, I'd like to have CLI localised (gettext support)
>>>>>> - As a user, I'd like CLI to log actions and failures
>>>>>> - As a user, I'd like Foreman CLI to have output format
>>>>>> unified with
>>>>>> Katello
>>>>>> - As a developer, I'd like to have travis running tests for
>>>>>> each CLI
>>>>>> pull request
>>>>>> - As a user, I'd like to have CLI packaged (and built in Koji)
>>>>>> (already on the backlog)
>>>>> Our package builds are triggered from Jenkins build results, so tests
>>>>> should run on there. Whether you want to do that as well as Travis or
>>>>> instead of is up to you, but I'd say we must have some tests in
>>>>> Jenkins.
>>>>>
>>>>> If the CLI is part of the Foreman project and releases, the repo
>>>>> should
>>>>> be set up in the same way with a "develop" branch, merged into
>>>>> master on
>>>>> each release and for it to follow the usual release process:
>>>>>
>>>>> http://projects.theforeman.org/projects/foreman/wiki/Release_Process
>>>>>
>>>>> This also means the CLI must be packaged for Debian. Will it be
>>>>> released as a gem too?
>>>> I'd agree that the CLI is the one piece of foreman that makes the most
>>>> sense to release as a gem. (foremancli is available as a a gem, and I
>>>> planned to do so with hammer as well.) If the team working on the cli
>>>> need any help making the gem they should feel free to ask. And I took
>>>> too long seems that hammer is now taken in the gem namespace.
>>>> http://rubygems.org/gems/hammer Guess we'll need to go with
>>>> foreman-hammer and katello-hammer with the common libs in
>>>> foreman-hammer-common?
>>>>
>>>> I'm suggesting this as users installing will only care about the
>>>> package they care about, and the names should be simple and obvious.
>>>> e.g.
>>>> - I want to install standard hammer: gem install foreman-hammer
>>>> - I want to install the combined katello/hammer cli: gem install
>>>> katello-hammer
>>>>
>>>> Please let me know if you need any help with the gem stuff as I built
>>>> and maintain the foremancli gem (which admittedly atm requires little
>>>> to no work.)
>>>>
>>>> BTW smart-proxy *might* make sense to release as a gem as well.
>>>>
>>> This sounds good. I was thinking about very similar approach:
>>>
>>> Gems:
>>> - hammer-cli - common libs
>>> - hammer-cli-foreman - Foreman specific commands
>>> - hammer-cli-katello - Katello specific commands
>>> - hammer-cli-signo - plugin with commands for managing
>>> SSO keys
>>> - hammer-cli-foreman-admin - commands wrapping Foreman administration
>>> tools
>> What sort of things would go in here?
> In Katello there some scripts to help setup and diagnose katello like
> katello-debug, katello-certs-debug, etc. I'm not sure if there are such
> scripts in the Foreman, but it seemed interesting to include them in the
> cli, so that you could run 'hammer-cli admin-tools --help' and see the
> list with help and params in one place. The plugin would be bridge same
> as we use with the current katello cli. But that is just an idea...
