I don't disagree that the SDK lacks feature parity, which is oddly
enough one of the main reasons I'm actually using it, to find those
missing features, document them, maybe fix them, or if I can't fix them
annoy the right people who can. With the SDK there is at least always a
way to get around the lack of feature parity now by using the direct
calls to the proxy object. I don't think that's a good solution, but
it's a way to start using it and then start contributing back the actual
implementations of those features.
I've been bitten and annoyed too many times by how different and
inconsistent the various other clients are, and while some of them have
some great code and features, the fact that they work very differently
to the others just drives me mad.
Or even in the case of the neutronclient, there is
'neutronclient.client' and 'neutronclient.neutron.client'. The former is
the more supported and documented one it seems (although the code
terrifies me... it's a 2500 line single file), while the latter appears
to be an unfinished client that was meant to be more in line with the
other service clients but I think is lacking features and docs. I've
never dug enough into that to find out what's going on there.
Then we have the odd thing where most of the client list commands return
lists of objects, while some (I'm looking at you glance), returns a
generator. While I prefer returning lists, the SDK is at least always
consistent in that it returns generators for ALL list commands, and
ultimately you can always wrap those calls in a list() and it's the same
result.
And don't get me started on the swiftclient. :P
The SDK isn't perfect, but it can and will get better, and it's better
than the alternative, which is mostly a weird kind of inconsistent
madness. We can't make all those clients work the same, that would break
backwards compatibility and it would take too much effort. We can though
have a unified consistent SDK that will hopefully in future be the point
of first implementation for features rather than their own clients.
First, we need to get people using the SDK and seeing the benefit of it,
and that takes time, and people helping implement those missing features.
On 22/04/18 01:37, Volodymyr Litovka wrote:
> Hi Adrian,
>
> at the moment, "wildly different" python clients provide more, than
> Unified SDK. Not sure about all clients, but what I found and what
> finally turned me to client libraries is inability to to do actions on
> stack (e.g. suspend/resume) using Unified SDK (neither doc not source
> code contain any mentions on this, while python-heatclient describes
> this and can it to do). It's far from bleeding edge - it's huge gap in
> feature consistency.
There seems to be a fairly old patch that started adding this but was
rejected due to missing tests:
https://review.openstack.org/#/c/190551/ I can't find anything more recent, but I didn't look too hard.
While not ideal you can call _action directly yourself on a stack
object, but it isn't particularly elegant:
https://github.com/openstack/openstacksdk/blob/master/openstack/orchestration/v1/stack.py#L90 stack = conn.orchestration.get_stack(stack_id)
resp = stack._action(conn.orchestration, {'suspend': ''})
I know that doesn't really help that much, but it's the best I can
recommend right now. :(
>
> On 4/20/18 6:19 AM, Adrian Turjak wrote:
>> As someone who used to use all the standalone clients, I'm leaning very
>> heavily these days to using only the SDK and think we should encourage
>> most projects to treat the SDK as their first point of implementation
>> rather than all the wildly different python clients.
>>
>> So if you are new to OpenStack, the the SDK is the best and most
>> consistent option right now for interacting with OpenStack from python.
>> Sadly though the docs are lacking, but the docs for the other libraries
>> aren't that much better anyway half the time.
>>
>>
>> On 20/04/18 01:46, Chris Friesen wrote:
>>> On 04/19/2018 07:01 AM, Jeremy Stanley wrote:
>>>> On 2018-04-19 12:24:48 +1000 (+1000), Joshua Hesketh wrote:
>>>>> There is also nothing stopping you from using both. For example,
>>>>> you could use the OpenStack SDK for most things but if you hit an
>>>>> edge case where you need something specific you can then import
>>>>> the particular client lib.
>>>> [...]
>>>>
>>>> Or, for that matter, leverage OpenStackSDK's ability to pass
>>>> arbitrary calls to individual service APIs when you need something
>>>> not exposed by the porcelain layer.
>>> Is that documented somewhere? I spent some time looking at
>>> https://docs.openstack.org/openstacksdk/latest/ and didn't see
>>> anything that looked like that.
>>>
>> Not that I believe, but basically it amounts to that on any service
>> proxy object you can call .get .post etc. So if the SDK doesn't yet
>> support a given feature, you can still use the feature yourself, but you
>> need to do some raw requests work, which honestly isn't that bad.
>>
>> servers = list(conn.compute.servers())
>> vs
>> servers_resp = conn.compute.get("/servers")
>>
>> The direct calls on the proxy object use your current session (auth and
>> scope) against the endpoint specific to that service, and just return
>> the raw request itself when called directly. This works even for Swift
>> where the url has to include details about your account. It's
>> surprisingly elegant.
>>
>> Ideally when people use the SDK like this they should also submit a
>> patch to fill in the missing functionality. Adding to the SDK isn't that
>> bad and the codebase is much better than it used to be.
>>
>>> Thanks,
>>> Chris
>>>
>>> _______________________________________________
>>> Mailing list:
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>>> Post to : openstack@lists.openstack.org
>>> Unsubscribe :
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>>
>> _______________________________________________
>> Mailing list:
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>> Post to : openstack@lists.openstack.org
>> Unsubscribe :
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>
_______________________________________________
Mailing list:
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org
Unsubscribe :
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
