On Tue, Mar 7, 2017 at 7:24 PM, Zane Bitter <zbit...@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 -- __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
