Open Stack

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.

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 at 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 at lists.openstack.org
> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

-- 
Volodymyr Litovka
   "Vision without Execution is Hallucination." -- Thomas Edison