Open Stack

Adrian,

> From: Adrian Otto <adrian.otto at rackspace.com>
> To: OpenStack Development Mailing List
<openstack-dev at lists.openstack.org>,
> Date: 22.04.2013 23:24
> Subject: Re: [openstack-dev] [Heat] TOSCA support blueprint updated
> after design discussions at Havana summit
>
> Thomas,
>
> On Apr 22, 2013, at 1:45 PM, Thomas Spatzier <thomas.spatzier at de.ibm.com>
>  wrote:
>
> > 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?
>
> Let's link to an ether pad where we can work together on segments
> that need revision. See below:

Perfect, I will add my thoughts to the linked etherpad and post and update
when I have something you all should look at.

>
> > 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 …
>
> Let's start here and see if that helps facilitate the interaction:
>
> https://etherpad.openstack.org/heat-dsl-questions
>
> It is liked from the DSL wiki page at: https://wiki.openstack.org/
> wiki/Heat/DSL
>
> Cheers,
>
> Adrian
>
>
> >
> > 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
> >>
> >
> >
> > _______________________________________________
> > 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
>