Open Stack

>> 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 at 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 at electronicjungle.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20181206/84fc9449/attachment.html>