OK, now we're getting somewhere! Thanks for the logs Jason!
I can indeed see there's a Ports: null, PortRanges: null in the Deltas reported by AllWatcher. In one case only - unit nova-compute/0, for which I can previously see an error: 2015-02-25 21:23:01 ERROR juju.state.unit unit.go:648 unit nova-compute/0 cannot get assigned machine: unit "nova-compute/0" is not assigned to a machine
But later it gets assigned to machine 4. So the problem seems a minor issue - race condition between a new unit getting created for a service and assigning it to a machine. Because port ranges are associated with machines, not units anymore, having null Ports and PortRanges makes sense in this case. This is easily fixable by just lying - i.e. returning empty ports and ranges lists when in fact there are none associated yet (i.e. in PR #1595 that fixed the other cases we should in both cases in updated() ensure if info.Ports has length of 0, set it to an empty slice).
However, this issue at first glance, should be happening much less frequently than it is in practise. Either the deployer is too quick to check the status after adding the nova-compute service (and before its first unit is assigned), or juju's watcher is reporting it too early (and not handling the Ports / PortRanges case being nil) - most likely the latter, as juju should be resilient against this.
OK, now we're getting somewhere! Thanks for the logs Jason!
I can indeed see there's a Ports: null, PortRanges: null in the Deltas reported by AllWatcher. In one case only - unit nova-compute/0, for which I can previously see an error: 2015-02-25 21:23:01 ERROR juju.state.unit unit.go:648 unit nova-compute/0 cannot get assigned machine: unit "nova-compute/0" is not assigned to a machine
But later it gets assigned to machine 4. So the problem seems a minor issue - race condition between a new unit getting created for a service and assigning it to a machine. Because port ranges are associated with machines, not units anymore, having null Ports and PortRanges makes sense in this case. This is easily fixable by just lying - i.e. returning empty ports and ranges lists when in fact there are none associated yet (i.e. in PR #1595 that fixed the other cases we should in both cases in updated() ensure if info.Ports has length of 0, set it to an empty slice).
However, this issue at first glance, should be happening much less frequently than it is in practise. Either the deployer is too quick to check the status after adding the nova-compute service (and before its first unit is assigned), or juju's watcher is reporting it too early (and not handling the Ports / PortRanges case being nil) - most likely the latter, as juju should be resilient against this.
This affects 1.21, 1.22 and 1.23 equally.