Martin Bacovsky is working on another (ruby based) proposal. His
solution will follow soon.
Regards
Tomas
CLI for Foreman
···
===============
The goal of this task was to create an official CLI for Foreman that
would ideally be extensible with plugins.
Three framework options came up from the first exploration:
* Thor[1] or Boson[2] (in ruby, Martin Bacovsky looked at them and
will cover the outcome in a dedicated email)
* Okaara[3] (in python)
I experimented with Okaara and will try to draw the design in following
lines.
Okaara
From it’s documentation:
Okaara is a series of utilities for writing command line interfaces in
Python. The provided functionality can be broken down into three
categories: reading and writing utilities, an interactive shell
framework, and a command line interface framework.
Okaara was created as a part of Pulp’s project that successfully uses it
for it’s admin and consumer CLIs. It has lot in common with Katello
CLI’s codebase. They solve the same problems but Okaara is usually more
general purpose solution.
The Design
Given the fact there are duplicities in Katello CLI vs Okaara, all three
projects (Katello, Foreman, Pulp) could benefit if we used Okaara also
for Foreman’s CLI.
My idea is to create an Okaara based CLI project that would provide
common behavior desired for Foreman and Katello cli, giving it same look
and feel. I use working title Pertinax.
Pertinax would introduce modularity. I’ve already created a draft of
such functionality. I took it from pulp-admin (this piece was not part
of Okaara) and made it a bit more universal. It uses python entry
points4 for adding custom commands via initializer function. See
Pulp’s documentation5 for details about this approach.
Usage of Pertinax would also enable to get rid of duplicities in
Katello. I was very successful with porting current cli code to Okaara.
All the modifications were made on level of the base classes. There was
only very little to change on the commands itself (init functions,
imports). There’s example diff of necessary changes for commands org and
provider6.
Foreman cli would use directly Pertinax without need of any changes.
Commands have very simple structure. I created an example of command
user7.
There are currently no api bindings for Foreman in Python. I solved that
issue by modifying existing apipie generator of ruby bindings. More on
that topic later.
Python Bindings
There are no released python api bindings at the moment. I modified
templates existing generator of ruby bindings10 to produce python
output. It serves the purpose but the directory structure is not the
cleanest as original generator was intended to be used only for ruby.
This part would need some polishing.
I think it is worth finishing the generator even if we decide not to use
python for our cli. Official python bindings might be valuable for the
community.
Benefits/Drawbacks of This Solution
I tried to cover all the requirements I can imagine. So to summarize it
I see following benefits/drawbacks:
[+] one can share commands from both Katello and Foreman for
integration into a common cli
[+] command completion and shell is solved once for both
[+] cli is easily extensible via python entry points4
[?] we’d have to polish python bindings generator; on the other hand
when we have it, it’s definitely a benefit
[-] we’d be introducing another language into the project
Current Status
there’s a simple draft for python based foreman cli8
pertinax9 is currently a common set of libs extracted from katello,
we should eventually give it better structure
apipie python bindings generator is now only modification of
foreman_api10, we should split it
by experimenting with Okaara I actually ported katello; the transition
was smooth, we’d only have to get rid of libs that are now redundant
Looks good, especially if you can generate it. How much of the pertinax
stuff would be useful in upstream okaara?
– bk
···
On 04/29/2013 04:42 AM, Tomas Strachota wrote:
> Hi team,
> I'm sending my design proposal for Foreman CLI.
>
> See my gist for better reading experience:
> https://gist.github.com/tstrachota/fb4c84d422841008fd6b#file-foreman-cli-on-okaara-md
>
>
> Martin Bacovsky is working on another (ruby based) proposal. His
> solution will follow soon.
>
> Regards
> Tomas
>
>
> Hi team,
> I'm sending my design proposal for Foreman CLI.
>
> See my gist for better reading experience:
> https://gist.github.com/tstrachota/fb4c84d422841008fd6b#file-foreman-cli-on-okaara-md
>
> Martin Bacovsky is working on another (ruby based) proposal. His solution
> will follow soon.
>
> Regards
> Tomas
>
>
> CLI for Foreman
> ===============
> The goal of this task was to create an official CLI for Foreman that would
> ideally be extensible with plugins.
> Three framework options came up from the first exploration:
> * Thor1 or Boson2 (in ruby, Martin Bacovsky looked at them and will
> cover the outcome in a dedicated email)
> * Okaara3 (in python)
> I experimented with Okaara and will try to draw the design in following
> lines.
>
> Okaara
> ======
> From it's documentation:
>
> Okaara is a series of utilities for writing command line interfaces in
> Python. The provided functionality can be broken down into three categories:
> reading and writing utilities, an interactive shell framework, and a command
> line interface framework.
>
> Okaara was created as a part of Pulp's project that successfully uses it for
> it's admin and consumer CLIs. It has lot in common with Katello CLI's
> codebase. They solve the same problems but Okaara is usually more general
> purpose solution.
>
> The Design
> ==========
>
> Given the fact there are duplicities in Katello CLI vs Okaara, all three
> projects (Katello, Foreman, Pulp) could benefit if we used Okaara also for
> Foreman's CLI.
>
> My idea is to create an Okaara based CLI project that would provide common
> behavior desired for Foreman and Katello cli, giving it same look and feel.
> I use working title Pertinax.
>
> Pertinax would introduce modularity. I've already created a draft of such
> functionality. I took it from pulp-admin (this piece was not part of Okaara)
> and made it a bit more universal. It uses python entry points4 for adding
> custom commands via initializer function. See Pulp's documentation5 for
> details about this approach.
>
> Usage of Pertinax would also enable to get rid of duplicities in Katello. I
> was very successful with porting current cli code to Okaara. All the
> modifications were made on level of the base classes. There was only very
> little to change on the commands itself (init functions, imports). There's
> example diff of necessary changes for commands org and provider6.
>
> Foreman cli would use directly Pertinax without need of any changes.
> Commands have very simple structure. I created an example of command
> user7.
>
> There are currently no api bindings for Foreman in Python. I solved that
> issue by modifying existing apipie generator of ruby bindings. More on that
> topic later.
>
> Python Bindings
> ===============
>
> There are no released python api bindings at the moment. I modified
> templates existing generator of ruby bindings10 to produce python output.
> It serves the purpose but the directory structure is not the cleanest as
> original generator was intended to be used only for ruby. This part would
> need some polishing.
>
> I think it is worth finishing the generator even if we decide not to use
> python for our cli. Official python bindings might be valuable for the
> community.
Tomas,
Hi there!! Great that you are working on CLI. I published the initial
"foremancli" which was a ruby based "read-only" cli tool. I also
started work on a next gen cli that would enable use of all API
features via a CLI. It was tentatively named "hammer", which was kind
of a play on Chef's knife and tied in with the naming them of the Thor
library which I though we might use. I struggled with Thor and did not
like it, and evaluated many of the pre-canned CLI ruby libs, and was
not happy. (We can discuss offline if you wish, but most of my
feedback is in the archives I believe.)
After some time struggling with finding the perfect Ruby CLI library,
work incidentally began to refactor the Foreman API using
APIPIE, which in addition to generating "free" API docs, also brought
to the the table a CLI generator, that would build a CLI that included
all the features in Foreman that had been ported to APIPIE.
I had then decided to wait till the APIPIE migration was complete and
see if a generated API would be useful. At this point my attention has
drifted, and I don't know if the API migration/refactor is complete.
If it is, I encourage you to try APIPIE generation, and see if it
brings us to a good starting point. If this works, I suspect it will
be MUCH easier to maintain.
Cheers,
Brian
···
On Mon, Apr 29, 2013 at 4:42 AM, Tomas Strachota wrote:
Benefits/Drawbacks of This Solution
I tried to cover all the requirements I can imagine. So to summarize it I
see following benefits/drawbacks:
[+] one can share commands from both Katello and Foreman for integration
into a common cli
[+] command completion and shell is solved once for both
[+] cli is easily extensible via python entry points4
[?] we’d have to polish python bindings generator; on the other hand when
we have it, it’s definitely a benefit
[-] we’d be introducing another language into the project
Current Status
there’s a simple draft for python based foreman cli8
pertinax9 is currently a common set of libs extracted from katello, we
should eventually give it better structure
apipie python bindings generator is now only modification of
foreman_api10, we should split it
by experimenting with Okaara I actually ported katello; the transition was
smooth, we’d only have to get rid of libs that are now redundant
> * [+] one can share commands from both Katello and Foreman for
> integration into a common cli
> * [+] command completion and shell is solved once for both
> * [+] cli is easily extensible via python entry points[4]
> * [?] we'd have to polish python bindings generator; on the other
> hand when we have it, it's definitely a benefit
> * [-] we'd be introducing another language into the project
[+] We will get Python bindings as a bonus. With all respect to Ruby,
Python is well established stack with many users in the wild
[+] Python is on all platforms (usually preinstalled). For example on
MacOS there is always one.
> Current Status
> ==============
> * I've got small update for Okaara
On the picture, we can see lot of features in Pertinax - how much of
this effort can be pushed into Okaara?
Nice writeup.
···
On Mon, Apr 29, 2013 at 10:42:52AM +0200, Tomas Strachota wrote:
>> * [+] one can share commands from both Katello and Foreman for
>> integration into a common cli
>> * [+] command completion and shell is solved once for both
>> * [+] cli is easily extensible via python entry points[4]
>> * [?] we'd have to polish python bindings generator; on the other
>> hand when we have it, it's definitely a benefit
>> * [-] we'd be introducing another language into the project
>
> [+] We will get Python bindings as a bonus. With all respect to Ruby,
> Python is well established stack with many users in the wild
>
> [+] Python is on all platforms (usually preinstalled). For example on
> MacOS there is always one.
>
>> Current Status
>> ==============
>> * I've got small update for Okaara
>
> On the picture, we can see lot of features in Pertinax - how much of
> this effort can be pushed into Okaara?
I think command completion, config handling and option validations might
be candidates. We'll see if Okaara guys like it:)
The other stuff is rather specific to our needs.
···
On 04/30/2013 09:05 AM, Lukas Zapletal wrote:
> On Mon, Apr 29, 2013 at 10:42:52AM +0200, Tomas Strachota wrote:
>> Hi team,
>> I'm sending my design proposal for Foreman CLI.
>>
>> See my gist for better reading experience:
>> https://gist.github.com/tstrachota/fb4c84d422841008fd6b#file-foreman-cli-on-okaara-md
>>
>> Martin Bacovsky is working on another (ruby based) proposal. His solution
>> will follow soon.
>>
>> Regards
>> Tomas
>>
>>
>> CLI for Foreman
>> ===============
>> The goal of this task was to create an official CLI for Foreman that would
>> ideally be extensible with plugins.
>> Three framework options came up from the first exploration:
>> * Thor1 or Boson2 (in ruby, Martin Bacovsky looked at them and will
>> cover the outcome in a dedicated email)
>> * Okaara3 (in python)
>> I experimented with Okaara and will try to draw the design in following
>> lines.
>>
>> Okaara
>> ======
>> From it's documentation:
>>
>> Okaara is a series of utilities for writing command line interfaces in
>> Python. The provided functionality can be broken down into three categories:
>> reading and writing utilities, an interactive shell framework, and a command
>> line interface framework.
>>
>> Okaara was created as a part of Pulp's project that successfully uses it for
>> it's admin and consumer CLIs. It has lot in common with Katello CLI's
>> codebase. They solve the same problems but Okaara is usually more general
>> purpose solution.
>>
>> The Design
>> ==========
>>
>> Given the fact there are duplicities in Katello CLI vs Okaara, all three
>> projects (Katello, Foreman, Pulp) could benefit if we used Okaara also for
>> Foreman's CLI.
>>
>> My idea is to create an Okaara based CLI project that would provide common
>> behavior desired for Foreman and Katello cli, giving it same look and feel.
>> I use working title Pertinax.
>>
>> Pertinax would introduce modularity. I've already created a draft of such
>> functionality. I took it from pulp-admin (this piece was not part of Okaara)
>> and made it a bit more universal. It uses python entry points4 for adding
>> custom commands via initializer function. See Pulp's documentation5 for
>> details about this approach.
>>
>> Usage of Pertinax would also enable to get rid of duplicities in Katello. I
>> was very successful with porting current cli code to Okaara. All the
>> modifications were made on level of the base classes. There was only very
>> little to change on the commands itself (init functions, imports). There's
>> example diff of necessary changes for commands org and provider6.
>>
>> Foreman cli would use directly Pertinax without need of any changes.
>> Commands have very simple structure. I created an example of command
>> user7.
>>
>> There are currently no api bindings for Foreman in Python. I solved that
>> issue by modifying existing apipie generator of ruby bindings. More on that
>> topic later.
>>
>> Python Bindings
>> ===============
>>
>> There are no released python api bindings at the moment. I modified
>> templates existing generator of ruby bindings10 to produce python output.
>> It serves the purpose but the directory structure is not the cleanest as
>> original generator was intended to be used only for ruby. This part would
>> need some polishing.
>>
>> I think it is worth finishing the generator even if we decide not to use
>> python for our cli. Official python bindings might be valuable for the
>> community.
>
> Tomas,
>
> Hi there!! Great that you are working on CLI. I published the initial
> "foremancli" which was a ruby based "read-only" cli tool. I also
> started work on a next gen cli that would enable use of all API
> features via a CLI. It was tentatively named "hammer", which was kind
> of a play on Chef's knife and tied in with the naming them of the Thor
> library which I though we might use. I struggled with Thor and did not
> like it, and evaluated many of the pre-canned CLI ruby libs, and was
> not happy. (We can discuss offline if you wish, but most of my
> feedback is in the archives I believe.)
>
> After some time struggling with finding the perfect Ruby CLI library,
> work incidentally began to refactor the Foreman API using
> APIPIE, which in addition to generating "free" API docs, also brought
> to the the table a CLI generator, that would build a CLI that included
> all the features in Foreman that had been ported to APIPIE.
>
> I had then decided to wait till the APIPIE migration was complete and
> see if a generated API would be useful. At this point my attention has
> drifted, and I don't know if the API migration/refactor is complete.
> If it is, I encourage you to try APIPIE generation, and see if it
> brings us to a good starting point. If this works, I suspect it will
> be MUCH easier to maintain.
>
> Cheers,
> Brian
Hi Brian!
Thanks for the tip. I have used some basic generators from apipie to
commands in Katello earlier. It simplified the work a lot. One can
perfectly generate bundings. But things got complicated when it came to
commands.
It is still necessary to keep possibility to override the generated
commands because we often need to customize the behavior (eg. for
interactive user i/o).
We'll definitely use as much information from apipie as possible to make
the work easier. I thing that mbacovsky played with that idea a bit more.
Regards
Tomas
···
On 04/30/2013 09:29 AM, Brian Gupta wrote:
> On Mon, Apr 29, 2013 at 4:42 AM, Tomas Strachota wrote:
Benefits/Drawbacks of This Solution
I tried to cover all the requirements I can imagine. So to summarize it I
see following benefits/drawbacks:
[+] one can share commands from both Katello and Foreman for integration
into a common cli
[+] command completion and shell is solved once for both
[+] cli is easily extensible via python entry points4
[?] we’d have to polish python bindings generator; on the other hand when
we have it, it’s definitely a benefit
[-] we’d be introducing another language into the project
Current Status
there’s a simple draft for python based foreman cli8
pertinax9 is currently a common set of libs extracted from katello, we
should eventually give it better structure
apipie python bindings generator is now only modification of
foreman_api10, we should split it
by experimenting with Okaara I actually ported katello; the transition was
smooth, we’d only have to get rid of libs that are now redundant
···
On 04/30/2013 05:08 AM, Tomas Strachota wrote:
> On 04/30/2013 09:05 AM, Lukas Zapletal wrote:
>> On Mon, Apr 29, 2013 at 10:42:52AM +0200, Tomas Strachota wrote:
>>> * [+] one can share commands from both Katello and Foreman for
>>> integration into a common cli
>>> * [+] command completion and shell is solved once for both
>>> * [+] cli is easily extensible via python entry points[4]
>>> * [?] we'd have to polish python bindings generator; on the other
>>> hand when we have it, it's definitely a benefit
>>> * [-] we'd be introducing another language into the project
>>
>> [+] We will get Python bindings as a bonus. With all respect to Ruby,
>> Python is well established stack with many users in the wild :-)
>>
>> [+] Python is on all platforms (usually preinstalled). For example on
>> MacOS there is always one.
>>
>>> Current Status
>>> ==============
>>> * I've got small update for Okaara
>>
>> On the picture, we can see lot of features in Pertinax - how much of
>> this effort can be pushed into Okaara?
>
> I think command completion, config handling and option validations might
> be candidates. We'll see if Okaara guys like it:)
> The other stuff is rather specific to our needs.
