On 9/26/2018 3:01 PM, Doug Hellmann wrote:
Monty Taylor<mord...@inaugust.com> writes:
On 09/26/2018 01:55 PM, Tim Bell wrote:
Doug,
Thanks for raising this. I'd like to highlight the goal "Finish moving legacy
python-*client CLIs to python-openstackclient" from the etherpad and propose this
for a T/U series goal.
I would personally like to thank the person that put that goal in the
etherpad...they must have had amazing foresight and unparalleled modesty.
To give it some context and the motivation:
At CERN, we have more than 3000 users of the OpenStack cloud. We write an
extensive end user facing documentation which explains how to use the OpenStack
along with CERN specific features (such as workflows for requesting
projects/quotas/etc.).
One regular problem we come across is that the end user experience is
inconsistent. In some cases, we find projects which are not covered by the
unified OpenStack client (e.g. Manila). In other cases, there are subsets of
the function which require the native project client.
I would strongly support a goal which targets
- All new projects should have the end user facing functionality fully exposed
via the unified client
- Existing projects should aim to close the gap within 'N' cycles (N to be
defined)
- Many administrator actions would also benefit from integration (reader roles
are end users too so list and show need to be covered too)
- Users should be able to use a single openrc for all interactions with the
cloud (e.g. not switch between password for some CLIs and Kerberos for OSC)
The end user perception of a solution will be greatly enhanced by a single
command line tool with consistent syntax and authentication framework.
It may be a multi-release goal but it would really benefit the cloud consumers
and I feel that goals should include this audience also.
++
It's also worth noting that we're REALLY close to a 1.0 of openstacksdk
(all the patches are in flight, we just need to land them) - and once
we've got that we'll be in a position to start shifting
python-openstackclient to using openstacksdk instead of python-*client.
This will have the additional benefit that, once we've migrated CLIs to
python-openstackclient as per this goal, and once we've migrated
openstackclient itself to openstacksdk, the number of different
libraries one needs to install to interact with openstack will be
_dramatically_ lower.
Would it be useful to have the SDK work in OSC as a prerequisite to the
goal work? I would hate to have folks have to write a bunch of things
twice.
Do we have any sort of list of which projects aren't currently being
handled by OSC? If we could get some help building such a list, that
would help us understand the scope of the work.
I started documenting the compute API gaps in OSC last release [1]. It's
a big gap and needs a lot of work, even for existing CLIs (the cold/live
migration CLIs in OSC are a mess, and you can't even boot from volume
where nova creates the volume for you). That's also why I put something
into the etherpad about the OSC core team even being able to handle an
onslaught of changes for a goal like this.
As far as admin features, I think we've been hesitant to add those to
OSC in the past, but I can see the value. I wonder if having them in a
separate library makes sense? Or is it better to have commands in the
tool that regular users can't access, and just report the permission
error when they try to run the command?
I thought the same, and we talked about this at the Austin summit, but
OSC is inconsistent about this (you can live migrate a server but you
can't evacuate it - there is no CLI for evacuation). It also came up at
the Stein PTG with Dean in the nova room giving us some direction. [2] I
believe the summary of that discussion was:
a) to deal with the core team sprawl, we could move the compute stuff
out of python-openstackclient and into an osc-compute plugin (like the
osc-placement plugin for the placement service); then we could create a
new core team which would have python-openstackclient-core as a superset
b) Dean suggested that we close the compute API gaps in the SDK first,
but that could take a long time as well...but it sounded like we could
use the SDK for things that existed in the SDK and use novaclient for
things that didn't yet exist in the SDK
This might be a candidate for one of these multi-release goals that the
TC started talking about at the Stein PTG. I could see something like
this being a goal for Stein:
"Each project owns its own osc-<service_type> plugin for OSC CLIs"
That deals with the core team and sprawl issue, especially with stevemar
being gone and dtroyer being distracted by shiny x-men bird related
things. That also seems relatively manageable for all projects to do in
a single release. Having a single-release goal of "close all gaps across
all service types" is going to be extremely tough for any older projects
that had CLIs before OSC was created (nova/cinder/glance/keystone). For
newer projects, like placement, it's not a problem because they never
created any other CLI outside of OSC.
[1] https://etherpad.openstack.org/p/compute-api-microversion-gap-in-osc
[2] https://etherpad.openstack.org/p/nova-ptg-stein (~L721)
--
Thanks,
Matt
_______________________________________________
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
