Re: [openstack-dev] [sdk][ptl] PTL Candidacy for Rocky

[Sławomir Kapłoński]

Big +1 from me :)

— 
Best regards
Slawek Kaplonski
sla...@kaplonski.pl



> Wiadomość napisana przez Monty Taylor  w dniu 
> 31.01.2018, o godz. 16:54:
> 
> Hi everybody!
> 
> I'd like to run for PTL of OpenStackSDK again
> 
> This last cycle was pretty exciting. We merged the shade and openstacksdk 
> projects into a single team. We shifted os-client-config to that team as 
> well. We merged the code from shade and os-client-config into openstacksdk, 
> and then renamed the team.
> 
> It wasn't just about merging projects though. We got some rework done to base 
> the Proxy classes on keystoneauth Adapters providing direct passthrough REST 
> availability for services. We finished the Resource2/Proxy2 transition. We 
> updated pagination to work for all of the OpenStack services - and in the 
> process uncovered a potential cross-project goal. And we tied services in 
> openstacksdk to services listed in the Service Types Authority.
> 
> Moving forward, there's tons to do.
> 
> First and foremost we need to finish integrating the shade code into the sdk 
> codebase. The sdk layer and the shade layer are currently friendly but 
> separate, and that doesn't make sense long term. To do this, we need to 
> figure out a plan for rationalizing the return types - shade returns 
> munch.Munch objects which are dicts that support object attribute access. The 
> sdk returns Resource objects.
> 
> There are also multiple places where the logic in the shade layer can and 
> should move into the sdk's Proxy layer. Good examples of this are swift 
> object uploads and downloads and glance image uploads.
> 
> I'd like to move masakari and tricircle's out-of-tree SDK classes in tree.
> 
> shade's caching and rate-limiting layer needs to be shifted to be able to 
> apply to both levels, and the special caching for servers, ports and
> floating-ips needs to be replaced with the general system. For us to do that 
> though, the general system needs to be improved to handle nodepool's batched 
> rate-limited use case as well.
> 
> We need to remove the guts of both shade and os-client-config in their repos 
> and turn them into backwards compatibility shims.
> 
> We need to work with the python-openstackclient team to finish getting the 
> current sdk usage updated to the non-Profile-based flow, and to make sure 
> we're providing what they need to start replacing uses of python-*client with 
> uses of sdk.
> 
> I know the folks with the shade team background are going to LOVE this one, 
> but we need to migrate existing sdk tests that mock sdk objects to 
> requests-mock. (We also missed a few shade tests that still mock out methods 
> on OpenStackCloud that need to get transitioned)
> 
> Finally - we need to get a 1.0 out this cycle. We're very close - the main 
> sticking point now is the shade/os-client-config layer, and specifically 
> cleaning up a few pieces of shade's API that weren't great but which we 
> couldn't change due to API contracts.
> 
> I'm sure there will be more things to do too. There always are.
> 
> In any case, I'd love to keep helping to pushing these rocks uphill.
> 
> Thanks!
> Monty
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [sdk][ptl] PTL Candidacy for Rocky

[Monty Taylor]

Hi everybody!

I'd like to run for PTL of OpenStackSDK again

This last cycle was pretty exciting. We merged the shade and 
openstacksdk projects into a single team. We shifted os-client-config to 
that team as well. We merged the code from shade and os-client-config 
into openstacksdk, and then renamed the team.


It wasn't just about merging projects though. We got some rework done to 
base the Proxy classes on keystoneauth Adapters providing direct 
passthrough REST availability for services. We finished the 
Resource2/Proxy2 transition. We updated pagination to work for all of 
the OpenStack services - and in the process uncovered a potential 
cross-project goal. And we tied services in openstacksdk to services 
listed in the Service Types Authority.


Moving forward, there's tons to do.

First and foremost we need to finish integrating the shade code into the 
sdk codebase. The sdk layer and the shade layer are currently friendly 
but separate, and that doesn't make sense long term. To do this, we need 
to figure out a plan for rationalizing the return types - shade returns 
munch.Munch objects which are dicts that support object attribute 
access. The sdk returns Resource objects.


There are also multiple places where the logic in the shade layer can 
and should move into the sdk's Proxy layer. Good examples of this are 
swift object uploads and downloads and glance image uploads.


I'd like to move masakari and tricircle's out-of-tree SDK classes in tree.

shade's caching and rate-limiting layer needs to be shifted to be able 
to apply to both levels, and the special caching for servers, ports and
floating-ips needs to be replaced with the general system. For us to do 
that though, the general system needs to be improved to handle 
nodepool's batched rate-limited use case as well.


We need to remove the guts of both shade and os-client-config in their 
repos and turn them into backwards compatibility shims.


We need to work with the python-openstackclient team to finish getting 
the current sdk usage updated to the non-Profile-based flow, and to make 
sure we're providing what they need to start replacing uses of 
python-*client with uses of sdk.


I know the folks with the shade team background are going to LOVE this 
one, but we need to migrate existing sdk tests that mock sdk objects to 
requests-mock. (We also missed a few shade tests that still mock out 
methods on OpenStackCloud that need to get transitioned)


Finally - we need to get a 1.0 out this cycle. We're very close - the 
main sticking point now is the shade/os-client-config layer, and 
specifically cleaning up a few pieces of shade's API that weren't great 
but which we couldn't change due to API contracts.


I'm sure there will be more things to do too. There always are.

In any case, I'd love to keep helping to pushing these rocks uphill.

Thanks!
Monty

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev