do not unregister systems from satellite/portal on server resource delete

[James Slagle]

We should change the behavior to not unregister systems from portal/satellite on system resource delete in Heat.

There are several reasons:

- Accidental Overcloud stack deletes. This is apparently a problem. To avoid losing the system registrations in portal/satellite we should not delete by default.
- Not deleting by default will allow us to move the RHEL registration resources under a new nested stack resource so that it no longer overrides operator specific interfaces. See https://bugs.launchpad.net/tripleo/+bug/1709441 for more information. If we change this behavior in Pike, we could move the resources in Queens.
- When using the server blacklist, adding a server to the blacklist causes the registration resources to be deleted due to the use of Heat conditions. In such a case, we should not unregister the system(s) from satellite/portal.
- It's trivial to delete systems from portal/satellite in large batches at a time. We should rely on operators choosing to do this manually or opt-in because this task because it's a data destructive operation in external systems to TripleO.

The old behavior can be triggered using the DeleteOnRHELUnregistration.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/492970

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/492970
Committed: https://git.openstack.org/cgit/openstack/tripleo-heat-templates/commit/?id=35ed6c6065b1e263eb69725e71639a6ea6d54cc7
Submitter: Jenkins
Branch: master

commit 35ed6c6065b1e263eb69725e71639a6ea6d54cc7
Author: James Slagle <email address hidden>
Date: Fri Aug 11 08:05:10 2017 -0400

    Don't unregister on system/resource delete

    Don't unregister systems from the portal/satellite
    when deleting from Heat. There are several reasons why
    it's compelling to fix this behavior. See
    https://bugs.launchpad.net/tripleo/+bug/1710144
    for full information. The previous behavior can be triggered
    by setting the DeleteOnRHELUnregistration parameter to "true".

    Closes-Bug: #1710144
    Change-Id: I909a6f7a049dc23fc27f2231a4893d428f06a1f1

[OpenStack Infra (hudson-openstack)]

This issue was fixed in the openstack/tripleo-heat-templates 7.0.0.0rc1 release candidate.

[Jiří Stránský (jistr)]

This is an issue for FFWD upgrade, adding ocata/newton backport potential tags.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/ocata
Review: https://review.openstack.org/564813

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/newton
Review: https://review.openstack.org/564814

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/564813
Committed: https://git.openstack.org/cgit/openstack/tripleo-heat-templates/commit/?id=d0288b450dd65f3f2d93564433dea29aab41f0da
Submitter: Zuul
Branch: stable/ocata

commit d0288b450dd65f3f2d93564433dea29aab41f0da
Author: James Slagle <email address hidden>
Date: Fri Aug 11 08:05:10 2017 -0400

    Don't unregister on system/resource delete

    Don't unregister systems from the portal/satellite
    when deleting from Heat. There are several reasons why
    it's compelling to fix this behavior. See
    https://bugs.launchpad.net/tripleo/+bug/1710144
    for full information. The previous behavior can be triggered
    by setting the DeleteOnRHELUnregistration parameter to "true".

    Closes-Bug: #1710144
    Change-Id: I909a6f7a049dc23fc27f2231a4893d428f06a1f1
    (cherry picked from commit 35ed6c6065b1e263eb69725e71639a6ea6d54cc7)

[OpenStack Infra (hudson-openstack)]

This issue was fixed in the openstack/tripleo-heat-templates 6.2.14 release.

[Doug Hellmann (doug-hellmann)]

This issue was fixed in the openstack/tripleo-heat-templates 5.3.13 release.