Open Stack

Hi Adrian,

thanks for the summary during the summit. Some questions on the
architecture:

What is the purpose of the "model interpreter" within the REST API module?
As I see this architecture now, the model interpreter is responsible for
parsing the new DSL that you proposed to build up an internal model, right?
So is there a need for another model interpreter once we agree on the
common format? I'm asking this because I'm a little fuzzy on the
distinction between the 'model interpreter' and the 'model processor'.
Further, how is the REST API knowing to which engine we need to forward
this too (is this federation of Heat engines reflecting the current
implementation or is this part of the new architecture)?

I was also studying the DSL and added some questions to
https://etherpad.openstack.org/heat-dsl-questions. As I did deeper I will
have some more ;).

Thanks,
-Florian

Adrian Otto <adrian.otto at rackspace.com> wrote on 04/22/2013 11:39:53 PM:
> From: Adrian Otto <adrian.otto at rackspace.com>
> To: OpenStack Development Mailing List
<openstack-dev at lists.openstack.org>,
> Date: 04/22/2013 11:43 PM
> Subject: Re: [openstack-dev] [Heat] Future Vision for Heat
>
> Thomas,
>
> Good suggestion. I tweaked the diagram, and posted a revision at:
>
> https://wiki.openstack.org/wiki/File:Heat-Vision.png
>
> If you refresh it in your browser you should see the changes. If
> there are more improvements we can make, I'd be happy to continue
> tweaking on it.
>
> Adrian
>
> On Apr 22, 2013, at 1:52 PM, Thomas Spatzier <thomas.spatzier at de.ibm.com>
>  wrote:
>
> > Hi all,
> >
> > a technical question or suggestion on the current architecture chart at
the
> > Heat Vision wiki page: having multiple "Model Interpreter" boxes as in
the
> > current diagram looks a bit confusing to me. What about having exactly
one
> > interpreter in the final version, and this one interprets the core
model
> > (Heat DSL) - probably this is what I would see in what is called "Model
> > Processor" at the moment. I.e. something that looks at a Heat DSL
> > Blueprint, analyzes the topology and derives the right steps from it.
> > The Heat REST API box would not need a "Model Interpreter" then. The
box in
> > the green component on the upper right corner is something I would call
a
> > "Model Translator" which takes an alternative format (like TOSCA, or
later
> > cfn) as input and translates it to the core format which is then passed
to
> > the Heat API.
> >
> > Thoughts?
> >
> > Regards,
> > Thomas
> >
> >> From: Steven Hardy <shardy at redhat.com>
> >> To: OpenStack Development Mailing List
> > <openstack-dev at lists.openstack.org>,
> >> Date: 22.04.2013 16:39
> >> Subject: Re: [openstack-dev] [Heat] Future Vision for Heat
> >>
> >> On Mon, Apr 22, 2013 at 01:47:59PM +0000, Tripp, Travis S wrote:
> >>> Hi All,
> >>>
> >>> Was there discussion on what is the "short" term vs "long" term?
> >> More specifically, how much of this do you think we can count on for
> > Havana?
> >>
> >> Firstly note, as in my disclaimer at the top of the "Vision" page,
that
> > the
> >> wiki page generated by Adrian, while useful to focus discussion, does
not
> >> represent a formal roadmap produced by the Heat core team.
> >>
> >> As such there are a number of items on that page which do not feature
in
> >> our current list of priorities at all (in particular the event
processor
> >> and task system bits)
> >>
> >> That said, we have some BP's related to items in that page, so these
> > should
> >> be used as the definitive reference of what we're aiming at delivering
> > for
> >> havana (I'm still in the process of targeting/approving these):
> >>
> >> https://blueprints.launchpad.net/heat
> >> https://blueprints.launchpad.net/heat/havana
> >>
> >> The main BPs related to Adrian's Vison page/diagram are:
> >>
> >> https://blueprints.launchpad.net/heat/+spec/open-api-dsl
> >> https://blueprints.launchpad.net/heat/+spec/tosca-support
> >> https://blueprints.launchpad.net/heat/+spec/watch-ceilometer
> >>
> >> It may be that we define some additional BPs (in particular related to
> > the
> >> AutoScaling API and Workflow-library discussions), if/when it becomes
> > clear
> >> that there are contributors willing to work on defining and
implementing
> >> them.
> >>
> >> So the short answer to your Havana question is "it depends" - we
> > currently
> >> have a very small core team, and as such are unlikely to have
resources
> >> sufficient to implement all the interesting ideas discussed at Summit
(or
> >> on Adrians wiki page) - so how much we achieve over the next cycle is
> >> absolutely dependent on the level of additional contribution we get
from
> >> those interested in and defining, implementing, and maintining these
new
> >> features.
> >>
> >> HTH!
> >>
> >> Steve
> >>
> >>>
> >>> Thanks,
> >>> Travis
> >>>
> >>> -----Original Message-----
> >>> From: Adrian Otto [mailto:adrian.otto at rackspace.com]
> >>> Sent: Thursday, April 18, 2013 3:10 AM
> >>> To: OpenStack Development Mailing List
> >>> Subject: Re: [openstack-dev] [Heat] Future Vision for Heat
> >>>
> >>> I have further refined the Vision Wiki page in accordance with
> >> further feedback from the core team. This is a shorter term vision
> >> that more closely matches what we will evolve toward in the short
therm.
> >>>
> >>> https://wiki.openstack.org/wiki/Heat/Vision
> >>
> >> _______________________________________________
> >> OpenStack-dev mailing list
> >> OpenStack-dev at lists.openstack.org
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>
> >
> >
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> 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/20130423/9a20da50/attachment.html>