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-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
