Open Stack

Just a question, not meant as anything bad against shade,

But would effort be better spent on openstacksdk?

Take the good parts of shade and just move it to openstacksdk, perhaps 
as a 'higher level api' available in openstacksdk?

Then ansible openstack components (which I believe use shade) could then 
switch to openstacksdk and all will be merry...

Thoughts?

Monty Taylor wrote:
> Hey everybody!
>
> This isn't the most normal thing I've done, but whatever.
>
> We've got this great library, shade, which people love to use to
> interact with their OpenStack clouds (even when they don't know they're
> using it, like when they're using Ansible) - and which we use in Infra
> behind nodepool to get test nodes for everyone's test jobs.
>
> Unfortunately, we have a somewhat ludicrously small contributor base
> right now (primarily me) Now, I'm pretty darned good and can produce a
> constant stream of patches - so you might not _think_ there's not a ton
> of developers, but I am, in the end, only one person, and that's not
> great. Shrews has been the other primary developer, but he's been
> focusing his attention on zuulv3 (which is a very good thing)
>
> In any case - I'd love some more folks to come in and do some things -
> and maybe none of you knew we were looking for new people! So come have
> fun with us! We have an IRC channel: #openstack-shade - and bugs are
> tracked in Storyboard (https://storyboard.openstack.org/#!/project/760)
>
> There is a worklist for bugs that have been triaged as important - that
> is, there is a clearly broken behavior out in production for someone:
>
> https://storyboard.openstack.org/#!/worklist/194
>
> The most important project (that's not terrible to get started on) is
> one I'm calling "restification" - which is that we're replacing our use
> of python-*client with making direct REST calls via keystoneauth. This
> is important so that we can ensure that we're supporting backwards
> compat for our users, while maintaining co-installability with OpenStack
> releases.
>
> https://storyboard.openstack.org/#!/worklist/195
>
> The process is as follows:
>
> - Pick a call or calls to migrate
> - Make a patch changing the unittests to use requests-mock instead of
> mocking the client object (this changes the test to validate the HTTP
> calls we're making, but shows that using the currently known to be
> working client calls)
> - Make a patch that replaces the submit_task call in
> shade/openstackclient.py (and removes the Task class from
> shade/_tasks.py) with a rest call using the appropriate
> self._{servicename}_client - this should not change any unit tests -
> that shows that the new call does the same things as the old call.
>
> Once you get the hang of it, it's fun - and it's a fun way to learn a
> ton about OpenStack's REST APIs.
>
> After that's done, we have some deeper tasks that need done related to
> caching and client-side rate limiting (we support these already, but we
> need to support them the same way everywhere) - and we have a whole
> mult-cloud/multi-threaded facade class to write that should be a ton of
> fun - but we need to finish restification before we do a ton of new things.
>
> If you want to start hacking with us - I recommend coming in and saying
> hi before you dive in to huge restification patches - and also start
> small - do one call and figure out the flow - going off and doing
> multi-day patches often leads to pain and suffering.
>
> Anyway - I hope some of you think interop client libraries are fun like
> I do - and would love to have you play with us!
>
> Thanks!
> Monty
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev