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

Sergey Kraynev skraynev at mirantis.com
Tue Jul 14 11:08:09 UTC 2015


Doug, Terry.

Thank you for the feedback.
I will create a BP with list of desired public methods and will add all
projects to it.

Regards,
Sergey.

On 9 July 2015 at 21:20, Doug Hellmann <doug at doughellmann.com> wrote:

> Excerpts from Sergey Kraynev's message of 2015-07-09 18:26:09 +0300:
> > 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?
>
> Until the SDK is ready for use, adding public methods or attributes
> seems like the best approach.
>
> Doug
>
> >
> > If it was raised early please point me, because this issue is really
> > painful, when you try to implement
> > common approach for all projects.
> >
> > Regards,
> > Sergey.
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150714/75b162c9/attachment-0001.html>


More information about the OpenStack-dev mailing list