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

Reply via email to