Open Stack

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.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
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev