Open Stack

Hi Steve,

Sorry I've missed this discussion for a while, but it looks like I have to
add my 5 cents here now.

Initially our intension was to make each Murano component "self
deployable", i.e. to incapsulate within its "deploy" method all the
necessary actions to create the component, including generation of Heat
snippet, merging it to the environment's template, pushing this template to
Heat and doing any post-heat configuration if needed via Murano Agent.

That's why the deploy method of NeutronNetwork class is
doing $.environment.stack.push() - to make sure that the network is created
when this method is called, regardless of the usages of this network in
other components of the Environment. If you remove it from there, the call
to network.deploy() will simply update the template in the
environment.stack, but the actual update will not happen. So, the deploy
method will not actually deploy anything - it will just prepare some
snippet for future pushing.

I understand your concerns though. But probably the solution should be more
complex - and I like the idea of having event-based workflow proposed by
Stan above.
I even don't think that we do really need the deploy() methods in the Apps
or Components.
Instead, I suggest to have more fine-grained workflow steps which are
executed by higher-level entity , such as Environment.

For example, heat-based components may have "createHeatSnippet()" methods
which just return a part of the heat template corresponding to the
component. The deploy method of the environment may iteratively process all
its components (and their nested components as well, of course), call this
createHeatSnippet methods, merge the results into a single template - and
then push this template as a single call to Heat. Then a post-heat config
phase may be executed, if needed to run something with Murano Agent (as
Heat Software Config is now the recommended way to deploy the software,
there should be not too many of such needs - only for Windows-based
deployments and other legacy stuff).


--
Regards,
Alexander Tivelkov


On Tue, Jul 22, 2014 at 2:59 PM, Lee Calcote (lecalcot) <lecalcot at cisco.com>
wrote:

>  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
>
>     *Lee Calcote*
>
>
> *     Sr. Software Engineering Manager     Cloud and Virtualization Group *
>     Phone: 512-378-8835
>     Mail/Jabber/Video: *lecalcot at cisco.com*
>
>     United States
>     www.cisco.com
>
>   From: Stan Lagun <slagun at mirantis.com>
> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev at lists.openstack.org>
> Date: Tuesday, July 22, 2014 at 4:37 PM
> To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev at lists.openstack.org>
> 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
>
>  <slagun at mirantis.com>
>
>
> On Tue, Jul 22, 2014 at 8:05 PM, McLellan, Steven <steve.mclellan at hp.com>
> 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
>> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140724/effb3c0f/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 58FAC4D7-2CCF-4C43-B2C5-2290DEEFD664[1].png
Type: image/png
Size: 1773 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140724/effb3c0f/attachment.png>