On Thu, Dec 6, 2018 at 11:29 AM Artem Goncharov <artem.goncharov@gmail.com> wrote:


On Thu, Dec 6, 2018, 16:19 Lance Bragstad <lbragstad@gmail.com> wrote:
Today in the TC meeting, we discussed the status of the three candidate goals [0]. Ultimately, we as the TC, are wondering who would be willing to drive the goal work.

Having a champion step up early on will help us get answers to questions about the feasibility of the goal, it's impact across OpenStack, among other things that will help us, as a community, make an informed decision.

Remember, championing a goal doesn't need to fall on a single individual. With proper communication, work can be spread out to lighten the load.

What I'd like is to open this up to the community and see who would be willing to drive the proposed goals. If you have any questions about championing a goal, please don't hesitate to swing by #openstack-tc, or you can ping me privately.

I was waiting for the start of switching osc "services" to SDK for quite a while now. I am definitely interested and committed to support the real coding work here. I would also like to volunteer driving the goal if noone objects.

Thanks chiming in, Artem!

As others in the thread have eluded to, this could very well be a multi-step effort. A big part of that is going to be figuring out where the different projects are in relation to the desired end state.

Would you be open to starting some preliminary work to help collect some of that information? Matt's etherpad for the compute API gap analysis with OSC is a good example.
 


On Thu, Dec 6, 2018 at 12:20 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

Artem