On 08/03/17 10:05, James Slagle wrote:
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.
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.
__________________________________________________________________________
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
