Changing target and subinstallation names

[robertgraeff]

How to categorize this issue?

/area robustness
/kind bug
/priority 3

What happened:

I have successfully deployed an installation with three subinstallations. (One subinstallation would probably suffice to reproduce the error.) Each of the three subinstallations has one deployitem.

In a new version, I change the following in the blueprint of the root installation:

• the name of the target import parameter,
• the names of the three subinstallations.

I update the installation accordingly. After the update, the objects remains in the following state:

▶ landscaper-cli inst inspect -n example scaling-many-deployitems -e
[CleanupOrphaned] Installation scaling-many-deployitems
    Last error: some orphaned subinstallations are still deleting
    ├── [🏗️ Deleting] Installation subinst-scaling-item000-phfbw
    │   Last error: deletion of some sub objects pending
    │   └── [🏗️ Deleting] Execution subinst-scaling-item000-phfbw
    │       └── [✅ Succeeded] DeployItem subinst-scaling-item000-phfbw-default-deploy-item-tz66h
    ├── [🏗️ Deleting] Installation subinst-scaling-item001-n94q4
    │   Last error: deletion of some sub objects pending
    │   └── [🏗️ Deleting] Execution subinst-scaling-item001-n94q4
    │       └── [✅ Succeeded] DeployItem subinst-scaling-item001-n94q4-default-deploy-item-k74l2
    ├── [🏗️ Deleting] Installation subinst-scaling-item002-xh2mc
    │   Last error: deletion of some sub objects pending
    │   └── [🏗️ Deleting] Execution subinst-scaling-item002-xh2mc
    │       └── [✅ Succeeded] DeployItem subinst-scaling-item002-xh2mc-default-deploy-item-htgbh
    ├── [] Installation subinst2-scaling-item000-l65sd
    ├── [] Installation subinst2-scaling-item001-zdz52
    └── [] Installation subinst2-scaling-item002-rq59g

Three new subinstallation subinst2-... have been created. The three old (orphaned) subinstallations are about to be deleted. They have a new jobID. However, no deployer picks them up, so that their phase is still Succeeded from before.

After 5 minutes, all objects fail, because the three old (orphaned) deployitems have not been picked up by a deployer. They are not being picked up, because they still reference the old target which no longer exists. (The original target is unchanged. But its copy in the context of the root installation has a new name. The name of the target import parameter in the blueprint has changed, and the name of the copied target is derived from it.)

A delete will only delete the three new subinstallations. After that, also a landscaper-cli inst force-delete does not work, because the object tree is no longer complete.

What you expected to happen:

How to reproduce it (as minimally and precisely as possible):

Anything else we need to know?:

Environment:

• Landscaper version:
• Kubernetes version (use kubectl version):
• Others:

[gardener-robot]

@robertgraeff Label area/todo does not exist.

[achimweigel]

@robertgraeff shouldn't we move this to the internal project and put it on the todo list?