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?
Some of the main use cases in TripleO for such a feature are scaling
out compute nodes where you do not need to rerun Puppet (or make any
changes at all) on non-compute nodes, or to exclude nodes from hanging
a stack-update if you know they are unreachable or degraded for some
reason. There are others, but those are 2 of the major use cases.
I think you're running up against a limitation of the scaling group
implementation in Heat. In AWS Autoscaling, you have a LaunchConfig
associated with a group that is used when scaling up to create new
members, but existing members are not changed when you specify a new
LaunchConfig unless you also specifically include a rolling update
UpdatePolicy. (That isn't a great interface in CloudFormation, but it
works and I can't actually think of anything better.)
Heat's AWS-style resources work similarly. Heat's native autoscaling
group resources don't have a separate LaunchConfig, and although they
used to work similarly to the AWS ones with respect to when they would
update existing members, IIRC somebody decided that was a "bug" and
"fixed" it.
In any event, TripleO uses ResourceGroup, and the very existence of
ResourceGroup is predicated on the idea that you can just generate the
nested template by making copies of the inline resource definition -
that is, the idea that you'll *never* need this feature which it turns
out you do, in fact, need. TripleO can't move away from ResourceGroup
because it relies on it to auto-assign pre-chosen names for specific
servers.
Senlin, for the record, gets this right.
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.
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"?
It also might be nice to allow specifying restricted_actions on the
server's name property (which typically is the hostname) instead of
having to use the resource name. The reason being is that it is not
really feasibly to expect operators/users to have to represent the
full nested_stack structure in their resource_registry. They would
have to query and record nested_stack names just to refer to a given
server resource. Each ResourceGroup nested stack would be have to be
individually represented, etc. Unless there is another way I'm
overlooking.
Whether or not the restricted_actions approach is taken, is Heat
interested in this functionality natively? I think it would make for a
much cleaner implementation than something TripleO specific. I can
work on a Heat spec if there's interest, though I'd like to get some
early feedback.
Thanks.
__________________________________________________________________________
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
