Open Stack

On Monday, 28 January 2019 11:20:42 CET Artem Goncharov wrote:
> Hi everybody,
> 
> One of the community goals for Train is to work on deprecation of
> individual clients in favor of unified OpenStackClient.  This in turn
> consists (or might consist) from few individual targets:
> - bringing current state of the CLI support for each service on par with
> native service client (especially covering changes added with latest
> microversions)
> - ensuring SDK also supports all of the service/resource/attribute/method
> - switching OSC service to SDK, as soon as it is on the same level, as
> native service client (someone might argue, that this is a mandatory part
> for reaching the target, but I personally this should be as important for
> reaching the goal (in addition to avoid double work))
> - deprecating individual clients (when prerequisites are fulfilled)
> 
> In order to drive a bit the whole goal I have started working on gathering
> differences we have for services in OSC:
> https://etherpad.openstack.org/p/osc-gaps-analysis.

An important detail about this email is that it focuses solely on the services 
handled in the core of openstackclient and openstacksdk (the Group Formerly 
Know As Core).

I have two points about this:
- switching to OSC and this fullfilling the goal should not be connected to 
switching to SDK - which is an importang goal in itself, but I suspect that 
the effort may be higher than just adding the missing bits to the existing OSC 
clients;
- the entire analysis does not consider the OSC support for all the other 
projects, which may or not may have switched and which may support OSC more 
than SDK, so that it would be better to postpone the coordinated switch.

Ciao
-- 
Luigi