Open Stack

My impression from discussions last week and this week on the ML was that
long term there would only be ONE API with the option to support a few
input formats by means of a translation layer under the covers. If you look
at [1], such as translation layer could be started as an external thing for
the time being, but then move into Heat at some point.
It would support for pushing native Heat DSL or other formats such as CFN,
TOSCA etc. thru the same API (maybe with some param indicating the format,
or the API recognizing the format), depending on which translation plugins
are installed.

>From an OpenStack Heat catalog perspective, it is still probably a good
idea to only have one format (native Heat DSL) in the catalog, but that
should not restrict the API.

Ziad Sawalha <ziad at sawalha.com> wrote on 24.04.2013 23:16:21:

> From: Ziad Sawalha <ziad at sawalha.com>
> To: OpenStack Development Mailing List
<openstack-dev at lists.openstack.org>,
> Date: 24.04.2013 23:16
> Subject: Re: [openstack-dev] [Heat] Template repository location
> (infra guidance needed)
>
> So will heat stop supporting cfn or will it continue to support it?
>
> And if not why cfn but not juju or CAMP?
>
>
> Typoed on an autocorrecting mobile device...
>
> On Apr 24, 2013, at 3:42 PM, "Monty Taylor" <mordred at inaugust.com> wrote:
>
> > I think you've hit on a point about why having multiple API/DSLs for
> > heat is not a good idea.
> >
> > While it might be a good experience for operators - it would be a
> > nightmare for users. If I have to ask if my cloud provider supports AWS
> > or Heat native templates, this whole endeavor will have failed.
> >
> > At the very least, OpenStack should have a template language, and it
> > should be the thing we expect all of the cloud vendors to supply. If
> > there is also something else, like AWS-compat template support - then
> > neat, but that shouldn't be what goes into our catalog.
> >
> > As for juju/puppet/chef - I believe those are strongly out of scope for
> > us. Again - if you want to use those to do your stuff - awesome - but I
> > don't think that an OpenStack catalog of content needs to provide
those.
> > juju has charm repos, puppet has puppetforge, etc.
> >
> > On 04/24/2013 04:26 PM, Ziad Sawalha wrote:
> >> How will browsing the catalog of blueprints work across the
> different API/DSLs?
> >>
> >> Think:
> >> - AWS cloud formations templates and cfn API
> >> - heat templates and Open API/DSL
> >> - juju charms
> >>
> >> Does each API maintain its own, independent blueprint browsing
> functionality or will there be one core catalog which links out to
> all the others? Think of a Wordpress entry in stackforge that links
> out to Wordpress templates on AWS and Wordpress juju charms and
> Wordpress cookbooks for ops code and puppet modules...
> >>
> >> Z
> >>
> >> Typoed on an autocorrecting mobile device...
> >>
> >> On Apr 24, 2013, at 1:05 PM, "Steven Hardy" <shardy at redhat.com> wrote:
> >>
> >>> On Wed, Apr 24, 2013 at 04:20:18PM +0000, Adrian Otto wrote:
> >>>> Steven,
> >>>>
> >>>> I don't think we need to use Stackforge at all anymore. Heat is
> integrated. Let's keep things simple, and use the Heat repo for
> Heat's work product. The way I see it is that if an OpenStack dev is
> creating a template as part of a Heat development effort, then the
> artifacts relating to that work belong in OpenStack.
> >>>
> >>> Well this is basically what I was thinking when we were discussing
> >>> stackforge in the team, hence my question when starting this thread.
> >>>
> >>> I agree that ideally this will be hosted under the openstack org (I'd
> >>> prefer this to stackforge if possible), but "the Heat repo" implies
the
> >>> main openstack/heat repo, which I would prefer to decouple from
example
> >>> templates, since they are example inputs not implementation (e.git
doesn't
> >>> make sense for users to have to install the service implementation to
get
> >>> access to the example templates when Heat is packaged)
> >>>
> >>>> We may want to consider a future setup where there is a central
> community repository where best practices for deployment of various
> applications and systems can be expressed as templates and stored in
> a registry or repo that can be browsed by OpenStack users. Think
> CPAN, or PIP. This is where templates could go that are not part of
> a coordinated release. That may or not belong in OpenStack, but I
> think that's actually a separate discussion.
> >>>
> >>> Agree, this sounds like a good future idea but out of scope for the
main
> >>> Heat project, I'm keen that we just have a reasonable number of
tested
> >>> examples to demonstrate our functionality.
> >>>
> >>> Ok, if Monty also says under the main openstack org then I'll kick of
> >>> requesting a new openstack/heat-templates repo (if anyone can direct
me to
> >>> the process for this it would be helpful ;)
> >>>
> >>> Thanks,
> >>>
> >>> 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
>