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 <[email protected]> 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: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
