[openstack-dev] [heat] Shared code between server and client

xuanlangjian xuanlangjian at gmail.com
Tue Oct 27 15:11:30 UTC 2015

I would like to see that we just need to maintain a common template_utils.py/template_format.py in heat client side.
But I still find some difference between client and server.
https://github.com/openstack/heat/blob/master/heat/common/template_format.py#L84-L87 <https://github.com/openstack/heat/blob/master/heat/common/template_format.py#L84-L87>
https://github.com/openstack/python-heatclient/blob/master/heatclient/common/template_format.py#L42 <https://github.com/openstack/python-heatclient/blob/master/heatclient/common/template_format.py#L42>

The option max_template_size only exists on server side, how do you handle with that if using the same function name ‘parse’?

> On Oct 23, 2015, at 07:13, Steve Baker <sbaker at redhat.com> wrote:
> On 23/10/15 08:49, Jay Dobies wrote:
>> I'm working on moving the functionality for merging environments from the client into the server [1]. I've only superficially looked at template_utils.py (in heatclient) but I'm guessing there is stuff in there I will want to use server-side.
>> The server has a requirement on heatclient, but I'm not sure what the convention is for using code in it. Can I directly call into a module in heatclient/common from the server or is the client dependency only intended to be used through the client-facing APIs?
>> [1] https://blueprints.launchpad.net/heat/+spec/multi-environments
> heat server already depends on heatclient, which was done so that some template parsing could live in heatclient and be shared by both (this isn't finished, and anyone who wants to pick it up is welcome to)
> So yes, this would be a valid case for heat calling heatclient functions.
> As an aside, it would be preferable if heatclient can somehow discover that it is interacting with a multi-env aware REST API, and fallback to local merging as appropriate.
> __________________________________________________________________________
> 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/20151027/4d17ba92/attachment.html>

More information about the OpenStack-dev mailing list