Suggest we get User community involved. If a user have tools written to current client libraries it will be impacted. So getting their feedback on impact and, for sure, continues reminder that this is coming and when will be good. From: Jay Bryant [mailto:jsbryant@electronicjungle.net] Sent: Thursday, December 6, 2018 9:31 AM To: Sean McGinnis <sean. mcginnis@gmx. com> Cc: openstack-discuss@lists.openstack.org Subject: Re: [tc][all] Train Community Goals [EXTERNAL EMAIL]
We talked about those things as separate phases. IIRC, the first phase was to include ensuring that python-openstackclient has full feature coverage for non-admin operations for all microversions, using the existing python-${service}client library or SDK as is appropriate. The next phase was to ensure that the SDK has full feature coverage for all microversions. After that point we could update OSC to use the SDK and start deprecating the service-specific client libraries.
That was my recollection as well.
This was my understanding as well and I think the phased approach is important to take given that I don't know that we have as many people with SDK experience. At least that is the case in Cinder.
I do think there is still a lot of foundation work that needs to be done before we can make it a cycle goal to move more completely to osc. Before we get there, I think we need to see more folks involved on the project to be ready for the increased attention.
Right now, I would classify this goal as a "huge lift".
I think that moving to OSC and away from the other client interfaces is a good goal. It will make for a better user experience and would hopefully help make documentation easier to understand. With that said, I know that there is a sizable gap between what OSC has for Cinder and what is available for python-cinderclient. If we make this a goal we are doing to need good organization and documentation of those gaps and volunteers to help make this change happen. On Thu, Dec 6, 2018 at 12:21 AM Sean McGinnis <sean.mcginnis@gmx.com<mailto:sean.mcginnis@gmx.com>> wrote:
In other words, does #1 mean each python-clientlibrary's OSC plugin is ready to rock and roll, or we talking about everyone rewriting all client interactions in to openstacksdk, and porting existing OSC plugins use that different python sdk.
We talked about those things as separate phases. IIRC, the first phase was to include ensuring that python-openstackclient has full feature coverage for non-admin operations for all microversions, using the existing python-${service}client library or SDK as is appropriate. The next phase was to ensure that the SDK has full feature coverage for all microversions. After that point we could update OSC to use the SDK and start deprecating the service-specific client libraries.
That was my recollection as well.
In other words, some projects could find it very easy or that they are already done, where as others could find themselves with a huge lift that is also dependent upon review bandwidth that is outside of their control or influence which puts such a goal at risk if we try and push too hard.
-Julia
I do think there is still a lot of foundation work that needs to be done before we can make it a cycle goal to move more completely to osc. Before we get there, I think we need to see more folks involved on the project to be ready for the increased attention. Right now, I would classify this goal as a "huge lift". Sean -- jsbryant@electronicjungle.net<mailto:jsbryant@electronicjungle.net>