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