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