<div dir="ltr">Doug, Terry. <div><br></div><div>Thank you for the feedback. </div><div>I will create a BP with list of desired public methods and will add all projects to it.</div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><div dir="ltr">Regards,<div>Sergey.</div></div></div></div>
<br><div class="gmail_quote">On 9 July 2015 at 21:20, Doug Hellmann <span dir="ltr"><<a href="mailto:doug@doughellmann.com" target="_blank">doug@doughellmann.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Excerpts from Sergey Kraynev's message of 2015-07-09 18:26:09 +0300:<br>
<span class="">> Hi community.<br>
><br>
> I want to raise couple questions about openstack clients.<br>
> In Heat we use other python-*clients for manipulating service's resources,<br>
> but some stuff placed in shell.py modules and we are forced to duplicate<br>
> some existing code.<br>
><br>
> There are couple examples which I met last time:<br>
>  - getting resource by name or id<br>
><br>
> All clients implement this logic in the shell.py module and it's not<br>
> possible to re-use it from client<br>
> directly as single call of some function "resolve_by_name_or_id"<br>
> (unfortunately same is for Heat too ). As result all external developers<br>
> (and we too as orchestration tool) should copy logic in our repos and<br>
> implement similar resolve methods for all services/resources.<br>
><br>
> - show command for clients<br>
><br>
> some of clients use base Resource class and they have "._info" attribute,<br>
> but it's private and use it is not right too. But I did not see another<br>
> solution, because clients have not some *_show public method for it too<br>
> (except neutron :) ). Also there is additional issue, when clients use<br>
> their own classes, without this attribute, e.g. glance v2.<br>
><br>
> So my question: can we create mentioned above public methods for such stuff<br>
> and make it as standard for all clients or may be discuss list of common<br>
> public "interfaces" for all clients?<br>
<br>
</span>Until the SDK is ready for use, adding public methods or attributes<br>
seems like the best approach.<br>
<br>
Doug<br>
<span class=""><br>
><br>
> If it was raised early please point me, because this issue is really<br>
> painful, when you try to implement<br>
> common approach for all projects.<br>
><br>
> Regards,<br>
> Sergey.<br>
<br>
</span>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div><br></div>