Open Stack

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-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev