Open Stack

On 9/26/2018 3:01 PM, Doug Hellmann wrote:
> Monty Taylor<mordred at 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