Open Stack

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.g it 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
>