Gents,
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.
Regards,
Lee
[cid:79A77799-DB4B-4D01-957B-D6A7D5D69476]
Lee Calcote
Sr. Software Engineering Manager
Cloud and Virtualization Group
Phone: 512-378-8835
Mail/Jabber/Video:
[email protected]<applewebdata://BF2BDB88-16CF-4E49-8251-92F7CF8AD490/[email protected]>
United States
www.cisco.com
From: Stan Lagun <[email protected]<mailto:[email protected]>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)"
<[email protected]<mailto:[email protected]>>
Date: Tuesday, July 22, 2014 at 4:37 PM
To: "OpenStack Development Mailing List (not for usage questions)"
<[email protected]<mailto:[email protected]>>
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
customizible
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
<mailto:[email protected]>
On Tue, Jul 22, 2014 at 8:05 PM, McLellan, Steven
<[email protected]<mailto:[email protected]>> wrote:
Hi,
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).
Thanks,
Steve
_______________________________________________
OpenStack-dev mailing list
[email protected]<mailto:[email protected]>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
