Open Stack

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.

>> 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.

>
>> 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 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.

-- 
-- James Slagle
--