Open Stack

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