Open Stack

Adrian,

I also have some input on the DSL proposal that I was planning to write
down in the next days. Therefore the question, how we plan to shape the
discussion.
Are we supposed to 'just' update the current DSL wiki page, or would it
make sense to have a DSL/Discussion page where we discuss open items and
then promote to the main DSL page when we reach agreement?

One of the items I would bring up, for example, is the inclusion of a type
system (e.g. component-type where we only have component today) to have one
place with all the metadata instead of repeating it in several places when
a component of some type is used. That is one item that would mapping to
TOSCA easier, but also will become useful quickly once people start
thinking of a type catalog that would, for example, populate the palette of
a drag&drop tool.
More details and some concrete proposals when I write this down in the
proper place ...

Regards,
Thomas

> From: Adrian Otto <adrian.otto at rackspace.com>
> To: OpenStack Development Mailing List
<openstack-dev at lists.openstack.org>,
> Date: 22.04.2013 15:24
> Subject: Re: [openstack-dev] [Heat] TOSCA support blueprint updated
> after design discussions at Havana summit
>
> I updated the BP accordingly. I will touch base with Alex about the
> dropped reference, and raise a discussion about the delta between
> DSL and DSL-2 as needed.
>
> --
> Adrian
>
> On Apr 22, 2013, at 5:38 AM, "Steven Hardy" <shardy at redhat.com> wrote:
>
> > On Mon, Apr 22, 2013 at 12:06:41PM +0000, Adrian Otto wrote:
> >> Steven,
> >>
> >> On Apr 22, 2013, at 4:52 AM, "Steven Hardy" <shardy at redhat.com> wrote:
> >>
> >>> On Fri, Apr 19, 2013 at 05:32:22PM +0200, Thomas Spatzier wrote:
> >>>>
> >>>> Heaters,
> >>>>
> >>>> I have just updated the blueprint [1] for adding TOSCA support in
Heat to
> >>>> reflect the outcome of discussions at the design summit.
> >>>> Please have a look if this matches your understanding as well and
post
> >>>> comments if anything should be changed.
> >>>>
> >>>> Thanks again to everyone at the summit for the great
> discussions we had. It
> >>>> was great to meat all of you and working with you!
> >>>>
> >>>> [1] https://blueprints.launchpad.net/heat/+spec/tosca-support
> >>>
> >>> Looks good, but I'm wondering if we should either revise the summary
> >>> wording (and title) to reflect the narrowed scope we discussed (e.g
"Add
> >>> support for translation of TOSCA templates to native DSL"), or raise
a new
> >>> BP and mark this one superseded?
> >>>
> >>> I've approved the DSL blueprint (and changed the title and
description a
> >>> bit, I hope Adrian is OK with that..):
> >>
> >> Thanks for the heads-up on this one. I would like to narrow the
> scope slightly. think the scope of each format should be handled as
> individual related blueprints. The spirit of mine is to enable the
> addition of *any* sensible format through a compatibility layer. So
> I would like to tweak it further to suggest that it should enable
> implementation of TOSCA, or others. It should be possible to resolve
> this blueprint with or without the completion of TOSCA support, and
> the TOSCA specific blueprint cited above can reference the blueprint
> below as a prerequisite.
> >
> > Sure, sounds reasonable - my intention was just to end up with a BP
which
> > tracks the native/superset DSL as we define/implement it - your
existing BP
> > seemed like a good candidate so I modified rather than raising a new
BP.
> >
> > I agree we should track implementaion of any translation tools (e.g the
> > TOSCA interpreter script discussed with Thomas) in separate BPs, or
maybe
> > not at all if it's a vendor-specific or minority format (hence
out-of-scope
> > for Heat)
> >
> >> I also think we should drop the reference to DSL2 for the time
> being. If we need to narrow the scope of the proposed spec, we can
> do that in a single place to simplify matters for those trying to
> follow where we are headed with this. I am happy to consider all
> viable approaches, and collaborate to find the one that best suits
> our collective interests.
> >
> > Ok, I just mentioned this so as to be inclusive of all who put a horse
in
> > the new-template-syntax race last week - I agree we should be primarily
> > focussed on defining the superset DSL in a collaborative way, such that
> > when we reach agreement/consensus we can implement it and hopefully
satisfy
> > all potential use-cases of Heat.
> >
> >>> https://blueprints.launchpad.net/heat/+spec/open-api-dsl
> >>>
> >>> We can use this to track the definition and implementation of the
native
> >>> DSL discussed at the summit.
> >>>
> >>> I've made the tosca-support BP depend on open-api-dsl, as my
understanding
> >>> is we're now aiming to add a standalone translation tool to do a
one-time
> >>> re-rendering of TOSCA into the native DSL format, once we've defined
and
> >>> implemented it.
> >>
> >> Perfect, thanks. If you have no objections to the additional
> update mentioned above, I will do that today. Otherwise, let's discuss
it.
> >
> > Sounds good, go for it :)
> >
> > Steve
> >
> > _______________________________________________
> > 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
>