infinitely scale up k8s managed units after upgraded controller

[Yang Kelvin Liu]

## current resources of the caas model ->
kubectl get all -n testcaas1
NAME READY STATUS RESTARTS AGE
po/juju-operator-mysql 1/1 Running 0 12s
po/juju-unit-mysql-0 0/1 ContainerCreating 0 2s

NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
svc/juju-mysql ClusterIP 10.152.183.245 <none> 3306/TCP 2s

## ran `juju upgrade-model --build-agent -m controller`

## operator/agent lost, and juju ran into infinitely scale up new units
kubectl get all -n testcaas1
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
deploy/juju-mysql 242 242 242 8 12m

NAME DESIRED CURRENT READY AGE
rs/juju-mysql-6fc5f55fbf 242 242 8 12m

NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
deploy/juju-mysql 242 242 242 8 12m

NAME DESIRED CURRENT READY AGE
rs/juju-mysql-6fc5f55fbf 242 242 8 12m

[Yang Kelvin Liu (kelvin.liu)]

How to reproduce:

1. deploy charm with `juju-managed-units` enabled;
2. updated controller to `d516a4aa7ac454571e28a4d0eeb93e89c4915e13` build.

[Ian Booth (wallyworld)]

juju-managed-units=true is deprecated and not supported at this stage.

It already defaults to false. The option to set it when deploying a charm should be removed - just retain the back end worker for now just in case.

[Yang Kelvin Liu (kelvin.liu)]

Hi Ian,
so the problem is any existing juju managed units will get this problem when they upgrade juju to later version that has my change. Do we need to consider an migration plan or not in this case?

thx

[Ian Booth (wallyworld)]

k8s is / was behind a feature flag. It's not yet been released. There's no upgrade concerns to worry about. The juju-managed-units bit was effectively deprecated before the first beta release.

[Yang Kelvin Liu (kelvin.liu)]

Understood, so we can probably consider to just close this bug.

[John A Meinel (jameinel)]

If the flag doesn't work, it presents a pitfall for users.
If we want to get rid of it, lets do so before we close this bug.

[Ian Booth (wallyworld)]

The flag works but a bug has been found. But it's not meant to be used as the idea behind it was not to proceed to release (the scope changed). As John says, the idea is to use this bug to ensure the flag gets removed before 2.4 is released.