<div dir="ltr"><div><div><div><div><div><div><div><div>Hello,<br><br></div>Thanks Angus, Clint, I've got your design.<br><br></div>It seems that Murano can built on top of that. With service metadata knowledge Murano can generate HOT templates with set of interdependent configs. <br>
</div>Here is what will be needed:<br><br></div>1. Ability to implement support for custom software configuration tool (type: OS::SoftwareConfig::MuranoAgent)<br></div>2. Ability to provide arbitrary input values for the config<br>
3. Ability to return arbitrary (JSON-compatible) data structure from config application and use attributes of that structure as an input for other configs<br></div>4. Ability to provide config body that is an input to Murano Agent of arbitrary size<br>
</div>5. Work well with large graph of configs with a lot of dependencies. Independent configs on different VMs should be applied in parallel.<br><br></div>Does it confirm to your plans?<br><div><div><div><div><div><div>
<div>
<div><div><div><div><br><div><br></div></div></div></div></div></div></div></div></div></div></div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Oct 11, 2013 at 3:47 AM, Clint Byrum <span dir="ltr"><<a href="mailto:clint@fewbar.com" target="_blank">clint@fewbar.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Excerpts from Angus Salkeld's message of 2013-10-10 15:27:48 -0700:<br>
<div class="im">> On 10/10/13 11:59 +0400, Stan Lagun wrote:<br>
> >This rises number of questions:<br>
> ><br>
> >1. What about conditional dependencies? Like config3 depends on config1 AND<br>
> >config2 OR config3.<br>
><br>
> We have the AND, but not an OR. To depend on two resources you just<br>
> have 2 references to the 2 resources.<br>
><br>
<br>
</div>AND is concrete. OR is not. I don't actually think it is useful for what<br>
Heat is intended to do. This is not not packaging, this is deploying.<br>
For deploying, Heat needs to know _what to do_, not "what is possible".<br>
<div class="im"><br>
> ><br>
> >2. How do I pass values between configs? For example config1 requires value<br>
> >from user input and config2 needs an output value obtained from applying<br>
> >config1<br>
><br>
> {Fn::GetAtt: [config2, the_name_of_the_attribute]}<br>
><br>
<br>
</div>This is a little bit misleading. Heat does not have any good ways to<br>
get a "value obtained from applying config1". The "data" attribute of<br>
the WaitCondition is the only way I know, and it is really unwieldy,<br>
as it can basically only dump a json string of all of the things each<br>
signaler has fed back in.<br>
<br>
That said, I wonder how many of the "value obtained from applying config1"<br>
would be satisfied by the recently proposed "random string generation"<br>
resource. Most of the time what people want to communicate back is just<br>
auth details. If we push auth details in from Heat to both sides, that<br>
alleviates all of my current use cases for this type of feature.<br>
<div class="im"><br>
> ><br>
> >3. How would you do error handling? For example config3 on server3 requires<br>
> >config1 to be applied on server1 and config2 on server2. Suppose that there<br>
> >was an error while applying config2 (and config1 succeeded). How do I<br>
> >specify reaction for that? Maybe I need then to try to apply config4 to<br>
> >server2 and continue or maybe just roll everything back<br>
><br>
> We currently have no "on_error" but it is not out of scope. The<br>
> current action is either to rollback the stack or leave it in the<br>
> failed state (depending on what you choose).<br>
><br>
<br>
</div>Right, I can definitely see more actions being added as we identify the<br>
commonly desired options.<br>
<div><div class="h5"><br>
> ><br>
> >4. How these config dependencies play with nested stacks and resources like<br>
> >LoadBalancer that create such stacks? How do I specify that myConfig<br>
> >depends on HA proxy being configured if that config was declared in nested<br>
> >stack that is generated by resource's Python code and is not declared in my<br>
> >HOT template?<br>
><br>
> It is normally based on the actual data/variable that you are<br>
> dependant on.<br>
> loadbalancer: depends on autoscaling instance_list<br>
> (actually in the loadbalancer config would be a "GetAtt: [scalegroup, InstanceList]")<br>
><br>
> Then if you want to depend on that config you could depend on an<br>
> attribute of that resource that changes on reconfigure.<br>
><br>
> config1:<br>
> type: OS::SoftwareConfig::Ssh<br>
> properties:<br>
> script: {GetAtt: [scalegroup, InstanceList]}<br>
> hosted_on: loadbalancer<br>
> ...<br>
><br>
> config2:<br>
> type: OS::SoftwareConfig::Ssh<br>
> properties:<br>
> script: {GetAtt: [config1, ConfigAppliedCount]}<br>
> hosted_on: somewhere_else<br>
> ...<br>
><br>
> I am sure we could come up with some better syntax for this. But<br>
> the logic seems easily possible to me.<br>
><br>
> As far as nested stacks go: you just need an output to be useable<br>
> externally - basically design your API.<br>
><br>
> ><br>
> >5. The solution is not generic. For example I want to write HOT template<br>
> >for my custom load-balancer and a scalable web-servers group. Load balancer<br>
> >config depends on all configs of web-servers. But web-servers are created<br>
> >dynamically (autoscaling). That means dependency graph needs to be also<br>
> >dynamically modified. But if you explicitly list config names instead of<br>
> >something like "depends on all configs of web-farm X" you have no way to<br>
> >describe such rule. In other words we need generic dependency, not just<br>
> >dependency on particular config<br>
><br>
> Why won't just depending on the scaling group be enough? if it needs<br>
> to be updated it will update all within the group before progressing<br>
> to the dependants.<br>
><br>
<br>
</div></div>In the example, loadbalancer doesn't have to depend on all of the nodes<br>
being configured. Why would it? It gets a signal when the list changes,<br>
but it can be created as soon as the _group_ is created.<br>
<br>
Anyway, no dependency is needed. Your LB has health checks, you feed<br>
them in, and when the webservers are configured, they pass, and it sends<br>
traffic there.<br>
<div class="im"><br>
> ><br>
> >6. What would you do on STACK UPDATE that modifies the dependency graph?<br>
> ><br>
> >The notation of configs and there<br>
><br>
> What we normally do go through the resources, see what can be updated:<br>
> - without replacement<br>
> - needs deleting<br>
> - is new<br>
> - requires updating<br>
><br>
> Each resource type can define what will require replacing or not.<br>
><br>
> I think we can achieve what you want with some small improvements to<br>
> the HOT format and with some new resource types - IMHO.<br>
<br>
</div>Agree with Angus here. I think we're closer to your use case than you<br>
think. :)<br>
<div class="HOEnZb"><div class="h5"><br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br><div dir="ltr"><span style="border-collapse:separate;color:rgb(0,0,0);font-family:'Times New Roman';font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;font-size:medium"><span style="font-family:arial;font-size:small">Sincerely yours<br>
Stanislav (Stan) Lagun<br>Senior Developer<br>Mirantis</span></span><br><span style="border-collapse:separate;color:rgb(0,0,0);font-family:'Times New Roman';font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;font-size:medium"><span style="font-family:arial;font-size:small"><span style="font-size:10.0pt;font-family:"Arial","sans-serif"" lang="EN-US">35b/3, Vorontsovskaya
St.</span><br>Moscow, Russia<br>Skype: stanlagun<br><a href="http://www.mirantis.com/" target="_blank">www.mirantis.com</a><br><a href="mailto:slagun@mirantis.com" target="_blank">slagun@mirantis.com</a></span></span></div>
</div>