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