[openstack-dev] [Heat] Future Vision for Heat
adrian.otto at rackspace.com
Tue Apr 16 17:17:37 UTC 2013
Yes, if an alternate API were added that uses an imperative modeling style, it may not translate cleanly to the native (declarative) Heat DSL.
I suppose the imperative plan could be passed through the native API, or there may be a way to bypass the native API and stimulate the downstream parts of the system as needed. Clearly if there is a way for everything to go through the same API, that may be cleaner. We have not considered this use case in enough depth yet to be certain.
On Apr 16, 2013, at 6:49 AM, "Ziad Sawalha" <ziad at sawalha.com> wrote:
> If I understood this correctly, the native HEAT API is going to be declarative (yay!) and would go through a model interpreter which would spit out an imperative plan for execution (script, workflow, whatever). That is all good.
> But if I have an API that is imperative, would I not need to bypass the model interpreter and go straight to an engine. Is my logic correct? And if so, how do we accommodated for that in this design?
> On Apr 16, 2013, at 3:56 AM, Adrian Otto <adrian.otto at rackspace.com> wrote:
>> I attended the various sessions at the Design Summit today in Portland, and assembled as many of the ideas for future planning as I could. For the benefit of those who are not attending, or who were not in these sessions, I created this Wiki page to express what I think is an early consensus on where we could take things. Let's tweak this if it's not a good direction.
>> Keith will be doing an Unconference session on the Workflow Service idea… I believe on Wednesday afternoon.
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
More information about the OpenStack-dev