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@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
--
Volodymyr Litovka
"Vision without Execution is Hallucination." -- Thomas Edison
___
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
