On 04/12/2017 11:21 AM, Joshua Harlow wrote:
Just a question, not meant as anything bad against shade,
But would effort be better spent on openstacksdk?
tl;dr - great in practice, falls apart in the details
I don't think so - but it was an original thought, so it's certainly a
reasonable question.
openstacksdk is an SDK exposing the OpenStack APIs. It does not hide
differences between APIs, nor abstract into different concepts. shade
does. So I think they have different audiences and different intends in
mind.
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...
The thing is - for shade's needs, openstacksdk is both too much and not
enough simultaneously. (this is not intended to be a dig against sdk -
their goal in life is not to be a rest layer for shade, it's to be an
SDK for the OpenStack APIs)
To handle nodepool scale, shade needs to do some really specific things
related to exactly when and how remote interactions happen. In services
of its users, openstacksdk hides those interactions - which I think is a
nice feature for its users, but unfortunately removes shade's ability to
control those interactions in the way it needs to.
At the same time, the object model wrapper with magic generators and
whatnot doesn't add much value to shade past "get('/servers').json()" to
be quite honest.
So - I think handling our needs would be very annoying to the SDK folks,
and it would just unnecessarily make things complex for both sides.
In any case, like I said, it's a completely fair and legit question -
but as of right now I don't think it would actually make anyone's lives
better.
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
__________________________________________________________________________
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
