@wallyworld - I’m exploring the spaces and subnets then.
- I’ll start with adding a new model:
juju add-model docker google/europe-north1
Added ‘docker’ model on google/europe-north1 with credential ‘juju-gce-1-sa’ for user ‘erik-lonroth’
- Trying to look at spaces:
cannot list spaces: spaces not supported (not supported)
ERROR cannot list spaces: spaces not supported (not supported)
OK, so there is an ERROR? Is this not supported on GCP? Is this a bug? Am I doing something wrong?
- I’ll now deploy my microsample, that I’ve changed now to try to use the “private-address” instead which I hope would NOT return the fan network. But I will also try to to use “network-get --bind-address” to see if this would also return the fan-network.
juju deploy cs:~erik-lonroth/charm-microsample-10
Located charm “cs:~erik-lonroth/charm-microsample-10”.
Deploying charm “cs:~erik-lonroth/charm-microsample-10”.
juju run --unit microsample/0 ‘network-get --bind-address website’
juju run --unit microsample/0 'network-get website'
- macaddress: c2:6f:4f:85:49:55
- hostname: ""
My conclusion is that the FAN network is used as the binding address on GCP which is not at all what happens on AWS, which delivers the 172-class-B network which also makes my service accessible when performing “juju expose microsample”.
This must be something wrong? At least, I’m not sure how to retrieve the tennant/project private 10.x.x.x address. I need this to get the service to properly be accessible from the public-address nat:ed to the private 10 address. This is a default behavior on AWS…
The workaround described in the bug works to remedy the situation: https://bugs.launchpad.net/juju/+bug/1761838