Open Stack

On Tue, Mar 07, 2017 at 02:34:50PM -0500, 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).
> 
> 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.

Thanks for raising this, I know it's been a pain point for some users of
TripleO.

However I think we're conflating two different issues here:

1. Don't re-run puppet (or yum update) when no other changes have happened

2. Disable deployment resources when changes have happened

(1) is actually very simple, and is the default behavior of Heat
(SoftwareDeployment resources never update unless either the config
referenced or the input_values change).  We just need to provide an option
to disable the DeployIdentifier/UpdateIdentifier timestamps from being
generated in tripleoclient.

(2) is harder, because the whole point of SoftwareDeploymentGroup is to run
the exact same configuration on a group of servers, with no exceptions.

As Zane mentions (2) is related to the way ResourceGroup works, but the
problem here isn't ResourceGroup per-se, as it would in theory be pretty
easy to reimplement SoftwareDeploymentGroup to generate it's nested stack
without inheriting from ResourceGroup (which may be needed if you want a
flag to make existing Deployments in the group immutable).

I'd suggest we solve (1) and do some testing, it may be enough to solve the
"don't change computes on scale-out" case at least?

One way to potentially solve (2) would be to unroll the
SoftwareDeploymentGroup resources and instead generate the Deployment
resources via jinja2 - this would enable completely removing them on update
if that's what is desired, similar to what we already do for upgrades to
e.g not upgrade any compute nodes.

Steve

> 
> 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.
> 
> 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.
> 
> 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.
> 
> -- 
> -- James Slagle
> --
> 
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-- 
Steve Hardy
Red Hat Engineering, Cloud