On 12.12.2013 17:10, Mark McLoughlin wrote:
On Wed, 2013-12-11 at 13:33 +0100, Jiří Stránský wrote:
Hi all,
TL;DR: I believe that "As an infrastructure administrator, Anna wants a
CLI for managing the deployment providing the same fundamental features
as UI." With the planned architecture changes (making tuskar-api thinner
and getting rid of proxying to other services), there's not an obvious
way to achieve that. We need to figure this out. I present a few options
and look forward for feedback.
..
1) Make a thicker python-tuskarclient and put the business logic there.
Make it consume other python-*clients. (This is an unusual approach
though, i'm not aware of any python-*client that would consume and
integrate other python-*clients.)
2) Make a thicker tuskar-api and put the business logic there. (This is
the original approach with consuming other services from tuskar-api. The
feedback on this approach was mostly negative though.)
FWIW, I think these are the two most plausible options right now.
My instinct is that tuskar could be a stateless service which merely
contains the business logic between the UI/CLI and the various OpenStack
services.
That would be a first (i.e. an OpenStack service which doesn't have a
DB) and it is somewhat hard to justify. I'd be up for us pushing tuskar
as a purely client-side library used by the UI/CLI (i.e. 1) as far it
can go until we hit actual cases where we need (2).
For the features that we identified for Icehouse, we probably don't need
to store any data necessarily. But going forward, it's not entirely
sure. We had a chat and identified some data that is probably not suited
for storing in any of the other services (at least in their current state):
* Roles (like Compute, Controller, Object Storage, Block Storage) - for
Icehouse we'll have these 4 roles hardcoded. Going forward, it's
probable that we'll want to let admins define their own roles. (Is there
an existing OpenStack concept that we could map Roles onto? Something
similar to using Flavors as hardware profiles? I'm not aware of any.)
* Links to Flavors to use with the roles - to define on what hardware
can a particular Role be deployed. For Icehouse we assume homogenous
hardware.
* Links to Images for use with the Role/Flavor pairs - we'll have
hardcoded Image names for those hardcoded Roles in Icehouse. Going
forward, having multiple undercloud Flavors associated with a Role,
maybe each [Role-Flavor] pair should have it's own image link defined -
some hardware types (Flavors) might require special drivers in the image.
* Overcloud heat template - for Icehouse it's quite possible it might be
hardcoded as well and we could just just use heat params to set it up,
though i'm not 100% sure about that. Going forward, assuming dynamic
Roles, we'll need to generate it.
^ So all these things could probably be hardcoded for Icehouse, but not
in the future. Guys suggested that if we'll be storing them eventually
anyway, we might build these things into Tuskar API right now (and
return hardcoded values for now, allow modification post-Icehouse). That
seems ok to me. The other approach of having all this hardcoding
initially done in a library seems ok to me too.
I'm not 100% sure that we cannot store some of this info in existing
APIs, but it didn't seem so to me (to us). We've talked briefly about
using Swift for it, but looking back on the list i wrote, it doesn't
seem as very Swift-suited data.
One example worth thinking through though - clicking "deploy my
overcloud" will generate a Heat template and sent to the Heat API.
The Heat template will be fairly closely tied to the overcloud images
(i.e. the actual image contents) we're deploying - e.g. the template
will have metadata which is specific to what's in the images.
With the UI, you can see that working fine - the user is just using a UI
that was deployed with the undercloud.
With the CLI, it is probably not running on undercloud machines. Perhaps
your undercloud was deployed a while ago and you've just installed the
latest TripleO client-side CLI from PyPI. With other OpenStack clients
we say that newer versions of the CLI should support all/most older
versions of the REST APIs.
Having the template generation behind a (stateless) REST API could allow
us to define an API which expresses "deploy my overcloud" and not have
the client so tied to a specific undercloud version.
Yeah i see that advantage of making it an API, Dean pointed this out
too. The combination of this and the fact that we'll need to store the
Roles and related data eventually anyway might be the tipping point.
Thanks! :)
Jirka
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
