Open Stack

On 04/12/2017 01:15 PM, Sean Dague wrote:
> On 04/12/2017 01:38 PM, Monty Taylor wrote:
>> 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.
>
> Just to provide a different though related perspective.
>
> This is what success looks like. Lots of different people writing
> different stuff, in different ways, talking to your API (which is the
> REST API, not a library). Everyone implementing the slices that are
> important for their consumers, and providing the fidelity that their
> consumers need.
>
> We should never think this is a bad thing.

++