Open Stack

On 04/05/17 03:20, Dean Troyer wrote:
> On Mon, May 1, 2017 at 11:11 PM, Adrian Turjak <adriant at catalyst.net.nz> wrote:
>> As part of my dev work I recently put together a cool little tool which
>> lets me have much easier access to the various OpenStack python clients
>> in the scope of a python interpreter session. The first version was a
>> little rough and without os-client-config support. The current version
>> is now a plugin for the openstackclient and introduces a command that
>> simply authenticates you, sets up the environment and helper tools, and
>> then drops you into an ipython interactive session. The helper stuff is
>> fairly simple, but combined with the features of ipython it really lets
>> you start playing with the tools quickly, and by piggybacking onto
>> openstackclient I get access to a lot of the niceties and inbuilt auth
>> mechanisms.
>>
>> It is useful for learning, testing, or development against the various
>> openstack client libraries, and even as an ops tool to quickly run some
>> basic actions without having to resort to weird or silly bash command
>> combinations.
> This is at the other end of the spectrum of client usage from the CLI
> in that it takes a very developer-like view of the APIs.  OSC has its
> interactive mode (using cmd2) that is just a command loop without even
> the ability to change global settings.  My hunch is that something in
> between would be really useful, but I am not interested in creating
> yet another DSL for this to include flow control and branching.
>
> You mentioned Shade, which falls somewhere in between as it implements
> a lot of logic to hide differences in clouds and ease dealing with
> some of our API warts.  What would you think about producing a Python
> mirror of the CLI interface with resource names, option names,
> everything, but in Python.  I have not thought all the way through
> this yet, but think we could take advantage of using the cliff command
> classes and be able to re-use all of the bits already written.
>
> This also magnifies the things we need to add to (or factor out of)
> OSC to make it truly useful, such as manipulation of the global
> options, maintaining multiple client contexts, etc.
>
> Thanks for sharing!
> dt
A new DSL is probably a terrible idea for obvious reasons:
https://xkcd.com/927/

A good interpreter like ipython combined with a reasonably easy way to
access the existing myriad of client libraries gets us most of the way.
While making yet another wrapper layer to simplify everything could
work, I feel that we have enough libraries already, and no one really
knows them all that well, and a lot of them are seriously lacking good
docs outside of the code itself. While the idea of making a interpreter
specific layer for the APIs would be interesting, I feel like it would
be wasted effort that could go towards promoting better consistency and
quality among the various existing python tools.

The project specific python libraries have a fairly similar command
structure to OSC as is, but it is interesting to compare them all:

OSC:       openstack <resource> <action>
vs
clients:   <service_type_client>.<resource>.<action>
vs
SDK:      <connection>.<service_type>.<action>_<resource>
vs
shade:   <cloud>.<action>_<resource>

There are of course differences between some of the
python-<service>clients structurally but a lot of them tend to follow
the same pattern. Then there is minor but annoying stuff like some
list() commands return lists, while others return generators.

I don't think writing yet another python library is a good idea even if
specific to python interpreter interactions. I think we just need to
document and educate about all the existing client options really well,
and have tools like this that promote them.

Including non-python libraries, because often those feel like second
class citizen, and often we forget about them entirely. I had to
recommend a good java library to a client recently and after testing a
bunch I found that only openstack4j was actually easy to use, and had
proper identity v3 support. The most recommended javaSDK is jclouds and
it was so very confusing and badly documented at a glance and from a new
user perspective.

My goal with this tool was mainly to promote better literacy for the
existing python libraries among our team here at Catalyst and give our
cloud customers a place to start prototyping interactions when building
applications that talk to the APIs. Well... and build something I myself
wanted to use!

Less new libraries and standards unless we actually deprecate old stuff!
More docs, polish for existing libraries, and better ways to use them! :P