>> 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> 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