For what it’s worth - We’ve long accounting for “extension points” within our 
VM and physical server provisioning flows, where developers may drop in code to 
augment OOTB behavior with customer/solution-specific needs.  While there are 
many extension points laced throughout different points in the provisioning 
flow, we pervasively injected “pre” and “post” provisioning extension points to 
allow for easy customization (like the one being attempted by Steve).

The notions of prepareDeploy and finishDeploy resonant well.

    Lee Calcote
    Sr. Software Engineering Manager
    Cloud and Virtualization Group

    Phone: 512-378-8835

    United States

From: Stan Lagun <<>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
Date: Tuesday, July 22, 2014 at 4:37 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
Subject: Re: [openstack-dev] [Murano]

Hi Steve,

1. There are no objections whatsoever if you know how to do it without breaking 
the entire concept
2. I thing that deployment workflow need to be broken to more fine-grained 
steps. Maybe instead of single "deploy" methdos have "prepareDeploy" (which 
doesn't push the changes to Heat), "deploy" and "finishDeploy". Maybe 
more/other methods need to be defined. This will make the whole process more 
3. If you want to have single-instance applications based on a fixed prebuild 
image then maybe what you need is to have your apps inhertir both Application 
and Instance classes and then override Instance's deploy method and add HOT 
snippet before VM instantiation. This may also require ability for child class 
to bind fixed values to parent class properties (narrowing class public 
contract, hiding those properties from user). This is not yet supported in 
MuranoPL but can be done in UI form as a temporary workaround
4. Didn't get why you mentioned object model. Object model is mostly user 
input. Do you suggest passing HOT snippets as part of user input? If so that 
would be something I oppose to
5. I guess image tagging would be better solution to image-based deployment
6. Personally I believe that problem can be eficently solved by Murano today or 
in the nearest future without resorting to pure HOT packages. This is not 
against Murano design and perfectly alligned with it

Sincerely yours,
Stan Lagun
Principal Software Engineer @ Mirantis


On Tue, Jul 22, 2014 at 8:05 PM, McLellan, Steven 
<<>> wrote:

This is a little rambling, so I’ll put this summary here and some discussion 
below. I would like to be able to add heat template fragments (primarily 
softwareconfig) to a template before an instance is created by Heat. This could 
be possible by updating but not pushing the heat template before 
instance.deploy, except that instance.deploy does a stack.push to configure 
networking before it adds information about the nova instance. This seems like 
the wrong place for the networking parts of the stack to be configured (maybe 
in the Environment before it tries to deploy applications). Thoughts?


The long version:

I’ve been looking at using disk-image-builder (a project that came out of 
triple-o) to build images for consumption through Murano. Disk images are built 
from a base OS plus a set of ‘elements’ which can include packages to install 
when building the image, templatized config file etc, and allows for 
substitutions based on heat metadata at deploy time. This uses a lot of the 
existing heat software config agents taking configuration from StructuredConfig 
and StructuredDeployment heat elements.

I’m typically finding for our use cases that instances will tend to be single 
purpose (that is, the image will be created specifically to run a piece of 
software that requires some configuration). Currently Murano provisions the 
instance, and then adds software configuration as a separate stack-update step. 
This is quite inefficient since os-refresh-config ends up having to re-run, and 
so I’m wondering if there’s strong opposition to allowing the object model to 
support injection of software configuration heat elements before the instance 
is deployed.

Alternatively maybe this is something that is best supported by pure HOT 
packages, but I think there’s value having murano’s composition ability even if 
just to be able to combine heat fragments (perhaps in the drag & drop manner 
that was briefly discussed in Atlanta).



OpenStack-dev mailing list<>

OpenStack-dev mailing list

Reply via email to