Open Stack

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.

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.

Adrian

On Apr 24, 2013, at 8:53 AM, Monty Taylor <mordred at inaugust.com>
 wrote:

> 
> 
> On 04/24/2013 08:36 AM, Steven Hardy wrote:
>> On Wed, Apr 24, 2013 at 12:04:22PM +0200, Zane Bitter wrote:
>>> On 23/04/13 22:53, Steven Hardy wrote:
>>>> Hi,
>>>> 
>>>> We've had some discussions recently within the team about creating a
>>>> "heat-templates" repo somewhere, for the following reasons:
>>>> 
>>>> 1. Separate the existing example templates[1] from the main code repo
>>> 
>>> It's worth pointing out that, for better or worse - and, candidly,
>>> probably mostly the latter - many of the Heat "unit" tests rely on
>>> reading templates from the source tree. So we'll probably have to
>>> simplify those and pull them inline in the test code. Just throwing
>>> that out there.
>> 
>> That's a very good point, which I'd forgotten ;)
>> 
>> I think it's mostly a dependency on the basic wordpress template, so I
>> guess we could just move a copy of that template under the tests directory
>> - I'll look into the easiest fix.
>> 
>>>> 2. Provide a central place for us to put/review new heat-native/dsl/HOT
>>>>   templates when we define/implement the syntax [2]
>>>> 3. Somewhere to put the oz TDLs we currently bundle with heat-jeos[3] so
>>>>   that we can deprecate that tool and replace it with a simple shell-script
>>>>   or documentation.
>>>> 
>>>> So our discussions so far have revolved around creating a stackforge
>>>> "heat-templates" repo, which seems OK, but my question (for the
>>>> infra/release team) is, would it make more sense to make another repo under
>>>> the main openstack org, since these templates will be directly related to
>>>> Heat (although possibly not part of the coordinated release)?
>>>> 
>>>> I'm happy to go ahead and create a stackforge repo if another repo under
>>>> the main openstack github org is deemed a bad idea, but wanted
>>>> clarification/guidance before proceeding.
>>> 
>>> +1 for Stackforge
>> 
>> Ok, sounds like we have agreement on Stackforge, I'll set up a repo later
>> today.
> 
> Nope! I dissent.
> 
> It sounds like these are a part of heat - which to me means they should
> be in openstack/ just like python-heatclient. ESPECIALLY if the heat
> unit (or any testing of heat) uses them.
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev