On 07/04/14 00:27, Steve Baker wrote:
On 05/04/14 04:47, Tomas Sedovic wrote:
Hi All,
I was wondering if the time has come to document what exactly are we
doing with tripleo-heat-templates and merge.py[1], figure out what needs
to happen to move away and raise the necessary blueprints on
On 04/06/2014 11:27 PM, Steve Baker wrote:
On 05/04/14 04:47, Tomas Sedovic wrote:
Hi All,
I was wondering if the time has come to document what exactly are we
doing with tripleo-heat-templates and merge.py[1], figure out what needs
to happen to move away and raise the necessary blueprints on
On 06/04/14 23:27, Steve Baker wrote:
On 05/04/14 04:47, Tomas Sedovic wrote:
Hi All,
snip
The maintenance burden of merge.py can be gradually reduced if features
in it can be deleted when they are no longer needed. At some point in
this process merge.py will need to accept HOT templates,
On 05/04/14 04:47, Tomas Sedovic wrote:
Hi All,
I was wondering if the time has come to document what exactly are we
doing with tripleo-heat-templates and merge.py[1], figure out what needs
to happen to move away and raise the necessary blueprints on Heat and
TripleO side.
(merge.py is a
Hi All,
I was wondering if the time has come to document what exactly are we
doing with tripleo-heat-templates and merge.py[1], figure out what needs
to happen to move away and raise the necessary blueprints on Heat and
TripleO side.
(merge.py is a script we use to build the final TripleO Heat
Excerpts from Tomas Sedovic's message of 2014-04-04 08:47:46 -0700:
Hi All,
I was wondering if the time has come to document what exactly are we
doing with tripleo-heat-templates and merge.py[1], figure out what needs
to happen to move away and raise the necessary blueprints on Heat and
On 04/04/14 13:58, Clint Byrum wrote:
We could keep roughly the same structure: a separate template for each
OpenStack service (compute, block storage, object storage, ironic, nova
baremetal). We would then use Heat environments to treat each of these
templates as a custom resource (e.g.
