Open Stack

On 08/03/17 10:05, James Slagle wrote:
> On Tue, Mar 7, 2017 at 7:24 PM, Zane Bitter <zbitter at redhat.com> wrote:
>> On 07/03/17 14:34, James Slagle wrote:
>>>
>>> I've been working on this spec for TripleO:
>>> https://review.openstack.org/#/c/431745/
>>>
>>> which allows users to selectively disable Heat deployment resources
>>> for a given server (or server in the case of a *DeloymentGroup
>>> resource).
>>
>>
>> I'm not completely clear on what this means. You can selectively disable
>> resources with conditionals. But I think you mean that you want to
>> selectively disable *changes* to resources?
>
> Yes, that's right. The reason I can't use conditionals is that I still
> want the SoftwareDeploymentGroup resources to be updated, but I may
> want to selectively exclude servers from the group that is passed in
> via the servers property. E.g., instead of updating the deployment
> metadata for *all* computes, I may want to exclude a single compute
> that is temporarily unreachable, without that failing the whole
> stack-update.

Have you seen the filter function?

http://git.openstack.org/cgit/openstack/heat/tree/heat/engine/hot/functions.py#n1279

>>> I started by taking an approach that would be specific to TripleO.
>>> Basically mapping all the deployment resources to a nested stack
>>> containing the logic to selectively disable servers from the
>>> deployment (using yaql) based on a provided parameter value. Here's
>>> the main patch: https://review.openstack.org/#/c/442681/
>>>
>>> After considering that complexity, particularly the yaql expression,
>>> I'm wondering if it would be better to add this support natively to
>>> Heat.
>>>
>>> I was looking at the restricted_actions key in the resource_registry
>>> and was thinking this might be a reasonable place to add such support.
>>> It would require some changes to how restricted_actions work.
>>>
>>> One change would be a method for specifying that restricted_actions
>>> should not fail the stack operation if an action would have otherwise
>>> been triggered. Currently the behavior is to raise an exception and
>>> mark the stack failed if an action needs to be taken but has been
>>> marked restricted. That would need to be tweaked to allow specifying
>>> that that we don't want the stack to fail. One thought would be to
>>> change the allowed values of restricted_actions to:
>>>
>>> replace_fail
>>> replace_ignore
>>> update_fail
>>> update_ignore
>>> replace
>>> update
>>>
>>> where replace and update were synonyms for replace_fail/update_fail to
>>> maintain backwards compatibility.
>>
>>
>> Anything that involves the resource definition in the template changing but
>> Heat not modifying the resource is problematic, because that messes with
>> Heat's internal bookkeeping.
>
> I don't think this case would violate that principle. The template +
> environment files would match what Heat has done. After an update, the
> 2 would be in sync as to what servers the updated Deployment resource
> was triggered.

I'm afraid I can't agree; it isn't that straightforward. Also, if you 
want to implement a generic mechanism that applies to every kind of 
resource (like restricted_actions do) then it isn't enough for it to 
work in one particular use case.

>>> Another change would be to add logic to the Deployment resources
>>> themselves to consider if any restricted_actions have been set on an
>>> Server resources before triggering an updated deployment for a given
>>> server.
>>
>>
>> Why not just a property, "no_new_deployments_please: true"?
>
> That would actually work and be pretty straightforward I think. We
> could have a map parameter with server names and the property that the
> user could use to set the value.

The tricky part, since this would presumably be implemented in the 
software deployment API itself, would be how to keep the Heat 
SoftwareDeployment resource in sync with what's actually happening, so 
that the Right Thing happens again when you start doing new deployments.

cheers,
Zane.

> The reason why I was initially not considering this route was because
> it doesn't allow the user to disable only some deployments for a given
> server. It's all or nothing. However, it's much simpler than a totally
> flexible option, and it addresses 2 of the largest use cases of this
> feature. I'll look into this route a bit more.
>