[tc][all] Train Community Goals
Arkady.Kanevsky at dell.com
Arkady.Kanevsky at dell.com
Thu Dec 6 15:53:06 UTC 2018
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 at electronicjungle.net]
Sent: Thursday, December 6, 2018 9:31 AM
To: Sean McGinnis <sean. mcginnis at gmx. com>
Cc: openstack-discuss at 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 at gmx.com<mailto: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<mailto:jsbryant at electronicjungle.net>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20181206/d4b3d0f5/attachment-0001.html>
More information about the openstack-discuss
mailing list