Open Stack

On Wed, Mar 8, 2017 at 4:08 AM, Steven Hardy <shardy at redhat.com> wrote:
> 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

Yea, possibly, but (1) doesn't really solve the use cases in the spec.
It'd certainly be a small improvement, but it's not really what users
are asking for.

(2) is much more difficult to reason about because we in fact have to
execute puppet to fully determine if changes have happened.

I don't really think these two are conflated. For some purposes, the
2nd is just a more abstract definition of the first. For better or
worse, part of the reason people are asking for this feature is
because they don't want to undo manual changes. While that's not
something we should really spend a lot of time solving for, the fact
is that OpenStack architecture allows for horizontally scaling compute
nodes without have to touch every other single node in your deployment
but TripleO can't take advantage of that.

So, just giving users a way to opt out of the generated unique
identifier triggering the puppet applys and other deployments,
wouldn't help them if they unintentionally changed some other hiera
data that triggers a deployment.

Plus, we have some deployments that are going to execute every time
outside of unique identifiers being generated (hosts-config.yaml).

> (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?

Possibly, as long as no other deployments are triggered. I think of
the use case more as:

add a compute node(s), don't touch any existing nodes to minimize risk

as opposed to:

add a compute node(s), don't re-run puppet on any existing nodes as I
know that it's not needed

For the scale out case, the desire to minimize risk is a big part of
why other nodes don't need to be touched.

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

Thanks, I hadn't considered that approach, but will look into it. I'd
guess you'd still need a parameter or map data fed into the jinja2
templating, so that it would not generate the deployment resources
based on what was desired to be disabled. Or, this could use
conditionals perhaps.



-- 
-- James Slagle
--