[MISC] (8.0/edge) fix units not setting port

[paulomach]

issue

On vm charm, the 3rd unit added to the cluster ports, are not set open.

The code path is two way, at leader deploy time, after the cluster is created; or when a unit joins the cluster in the peer_relation_changed event.
On the later, if a unit back off (e.g. when another unit is joining), later join attempts will happen on other events, missing the set_ports call.
And that's why sometimes on machine we do not see ports being set on juju status.

solution

Add a new set_ports call every time a unit is initialized on the on_start handler.

[sinclert-canonical]

The code path is two way, at leader deploy time, after the cluster is created; or when a unit joins the cluster in the peer_relation_changed event. On the later, if a unit back off (e.g. when another unit is joining), later join attempts will happen on other events, missing the set_ports call.

Should we move the set_ports call to the start event then (probably at the end of the workload_initialize function)? That way, we would centralize the logic where the ports are set, and will happen regardless of unit role.

---

If approve, we need to port this to 8.4/edge as well.

[paulomach]

The code path is two way, at leader deploy time, after the cluster is created; or when a unit joins the cluster in the peer_relation_changed event. On the later, if a unit back off (e.g. when another unit is joining), later join attempts will happen on other events, missing the set_ports call.

Should we move the set_ports call to the start event then (probably at the end of the workload_initialize function)? That way, we would centralize the logic where the ports are set, and will happen regardless of unit role.

If approve, we need to port this to 8.4/edge as well.

on point: 984ce79

[Soundarya03]

Perhaps worth updating test_on_start unit test (in test_charm.py) to assert this behaviour now?

[Soundarya03]

Left a couple of questions. Thank you!

[Soundarya03]

There is one scenario that comes to mind as I review this change: what about charm upgrade? That is, if we have a unit currently deployed, which is broken with the missing ports issue, refreshing the charm to the latest version with this fix won't help resolve the issue. This is because we've currently plugged on_start and it is further guarded by can_start (so set_ports won't be invoked for already initialized units).
Isn't this relevant for a 8.0 charm specifically because this is already available as a stable release, and is already used in prod?