[openstack-dev] [all][heat][oslo] Public show and validation clients methods

Terry Howe terrylhowe at gmail.com
Thu Jul 9 16:28:02 UTC 2015


I would think the python-openstackclient would smooth out a lot of the
rough edges particularly the find by name or id situation.  It already does
that for many services neutron being the biggest gap.  The
python-openstacksdk will eventually (soon) be able to address a lot of
those issues.


On Thu, Jul 9, 2015 at 9:26 AM, Sergey Kraynev <skraynev at mirantis.com>
wrote:

> Hi community.
>
> I want to raise couple questions about openstack clients.
> In Heat we use other python-*clients for manipulating service's resources,
> but some stuff placed in shell.py modules and we are forced to duplicate
> some existing code.
>
> There are couple examples which I met last time:
>  - getting resource by name or id
>
> All clients implement this logic in the shell.py module and it's not
> possible to re-use it from client
> directly as single call of some function "resolve_by_name_or_id"
> (unfortunately same is for Heat too ). As result all external developers
> (and we too as orchestration tool) should copy logic in our repos and
> implement similar resolve methods for all services/resources.
>
> - show command for clients
>
> some of clients use base Resource class and they have "._info" attribute,
> but it's private and use it is not right too. But I did not see another
> solution, because clients have not some *_show public method for it too
> (except neutron :) ). Also there is additional issue, when clients use
> their own classes, without this attribute, e.g. glance v2.
>
> So my question: can we create mentioned above public methods for such
> stuff and make it as standard for all clients or may be discuss list of
> common public "interfaces" for all clients?
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150709/03267297/attachment.html>


More information about the OpenStack-dev mailing list