Open Stack

----- Original Message -----
> From: "Jay Dobies" <jason.dobies at redhat.com>
> To: openstack-dev at lists.openstack.org
> Sent: Tuesday, 25 August, 2015 2:31:02 PM
> Subject: Re: [openstack-dev] [TripleO] Encapsulating logic and state in the client
> 
> > Thinking about this further, the interesting question to me is how much
> > logic we aim to encapsulate behind an API. For example, one of the simpler
> > CLI commands we have in RDO-Manager (which is moving upstream[1]) is to
> > run introspection on all of the Ironic nodes. This involves a series of
> > commands that need to be run in order and it can take upwards of 20
> > minutes depending how many nodes you have. However, this does just
> > communicate with Ironic (and ironic inspector) so is it worth hiding
> > behind an API? I am inclined to say that it is so we can make the end
> > result as easy to consume as possible but I think it might be difficult
> > to draw the line in some cases.
> >
> > The question then rises about what this API would look like? Generally
> > speaking I feel like it looks like a workflow API, it shouldn't offer
> > many (or any?) unique features, rather it manages the process of
> > performing a series of operations across multiple APIs. There have been
> > attempts at doing this within OpenStack before in a more general case,
> > I wonder what we can learn from those.
> 
> This is where my head is too. The OpenStack on OpenStack thing means we
> get to leverage the existing tools and users can leverage their existing
> knowledge of the products.
> 
> But what I think an API will provide is guidance on how to achieve that
> (the big argument there being if this should be done in an API or
> through documentation). It coaches new users and integrations on how to
> make all of the underlying pieces play together to accomplish certain
> things.
> 
> To your question on that ironic call, I'm split on how I feel.
> 
> On one hand, I really like the idea of the TripleO API being able to
> support an OpenStack deployment entirely on its own. You may want to go
> directly to some undercloud tools for certain edge cases, but for the
> most part you should be able to accomplish the goal of deploying
> OpenStack through the TripleO APIs.
> 
> But that's not necessarily what TripleO wants to be. I've seen the
> sentiment of it only being tools for deploying OpenStack, in which case
> a single API isn't really what it's looking to do. I still think we need
> some sort of documentation to guide integrators instead of saying "look
> at the REST API docs for these 5 projects", but that documentation is
> lighter weight than having pass through calls in a TripleO API.

I don't really feel like documentation is enough. If we want to have a 
consistent result between multiple clients (i.e. a CLI and UI that may 
not even be Python). We have already seen how two Python implementations 
of the same thing can vary (Tuskar-UI vs RDO-Manager CLI).

I see the API being like the RDO-Manager CLI is at the moment, something
you can use for generic workflow but then you can as you say go directly
to the services if needed. It would just make the generic workflow
consistent for consumers of that idea.

Having said that, I do still share your general concerns. So I am thinking
out loud a bit here.

> >> Unfortunately, as undesirable as these are, they're sometimes necessary
> >> in the world we currently live in. The only long-term solution to this
> >> is to put all of the logic and state behind a ReST API where it can be
> >> accessed from any language, and where any state can be stored
> >> appropriately, possibly in a database. In principle that could be
> >> accomplished either by creating a tripleo-specific ReST API, or by
> >> finding native OpenStack undercloud APIs to do everything we need. My
> >> guess is that we'll find a use for the former before everything is ready
> >> for the latter, but that's a discussion for another day. We're not there
> >> yet, but there are things we can do to keep our options open to make
> >> that transition in the future, and this is where tripleo-common comes in.
> >>
> >> I submit that anything that adds logic or state to the client should be
> >> implemented in the tripleo-common library instead of the client plugin.
> >> This offers a couple of advantages:
> >>
> >> - It provides a defined boundary between code that is CLI-specific and
> >> code that is shared between the CLI and GUI, which could become the
> >> model for a future ReST API once it has stabilised and we're ready to
> >> take that step.
> >> - It allows for an orderly transition when that happens - we can have a
> >> deprecation period during which the tripleo-common library is imported
> >> into both the client and the (future, hypothetical) ReST API.
> >>
> >> cheers,
> >> Zane.
> >>
> >> __________________________________________________________________________
> >> OpenStack Development Mailing List (not for usage questions)
> >> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>
> >
> > [1]: https://review.openstack.org/#/c/215186/3/gerrit/projects.yaml,cm
> >
> > __________________________________________________________________________
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> 
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>