[tc][all] Train Community Goal - CLI
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. I tried to analyze current state going from the API side, where for each service we have a set of resources (with corresponding attributes) and methods on those. To achieve that I was "parsing" a service documentation (do not kick me too hard for that ;-) and processing it further, leaving overall info as "yaml" since there is lots of info and in the background there are still some source "documents". Resulting document in some form represent a current status and a todo list. I would be happy if people who feel responsible for implementing CLI would have a look on that and provide a feedback, whether they find the whole analysis helpful or not (if not whether there are better ideas on how to track status and todo). There is still a lot to be done even to figure out the current status, but I feel we need to start moving if we want to achieve the target (even switching just a few services would be already an achievement). So, if you are willing to support the goal - please join me. Any help and work is welcome. Regards, Artem
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
On Mon, Jan 28, 2019 at 11:58 AM Luigi Toscano <ltoscano@redhat.com> wrote:
On Monday, 28 January 2019 11:20:42 CET Artem Goncharov wrote:
Hi everybody,
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).
Right
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;
agree, that it must not be connected. While doing analysis I thought it will be helpful to track status for both at the same time. We might need to "push" on this also.
- 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.
Sure it does not. I am not sure a single person would be ever feasible doing a complete analysis for all possible plugins. As you already mentioned - let's focus on core services first. But if you are able to support in extending the list for any other services - you are of course welcome.
Ciao -- Luigi
participants (2)
-
Artem Goncharov
-
Luigi Toscano