matching subnets to zones: cannot use space "alpha" as deployment target: no subnets

[Jason Hobbs]

On a juju 2.8.1 deployment of kubernetes on top of maas, a machine failed to come up with this error:

'matching subnets to zones: cannot use space "alpha" as deployment target: no subnets'

We don't have any constraints or references to this "alpha" space. It's not clear where this is coming from, but it caused the deployment to fail.

https://solutions.qa.canonical.com/qa/testRun/821bb62e-178e-44ed-a327-be12ac195b7b for more details.

[Jason Hobbs (jason-hobbs)]

sub'd to field high, this is blocking testing of k8s on maas.

[Jason Hobbs (jason-hobbs)]

drop'd field high and marked incomplete for now; this could be due to lack of a binding specified for one of my applications.

If so, this will turn into a bug about the lack of clarity in the error message.

[Joseph Phillips (manadart)]

This came up on Discourse:
https://discourse.juju.is/t/where-are-bindings-alpha-coming-from

I've updated the model config doc with "default-space":
https://juju.is/docs/configuring-models

[Launchpad Janitor (janitor)]

[Expired for juju because there has been no activity for 60 days.]

[David Lawson (deej)]

We've run into a similar situation with an existing Openstack deploy on a MaaS cloud, we haven't added any units since we've upgraded to 2.8.x and I'm trying to add a new set of infrastructure LXDs on a machine that we added with the manual provider (long story) and am running into this error:

17/lxd/2 down pending bionic matching subnets to zones: cannot use space "alpha" as deployment target: no subnets

The client version for this is 2.8.6 from a snap and the controller is currently 2.8.3.

The application I'm trying to add a unit to does have a constraint set:

$ juju get-constraints openstack-dashboard
spaces=private

I've also configured a default space for the environment:

default-space model private

Here's the defined spaces:

 juju spaces
Name Space ID Subnets
alpha 0
private 1 10.48.0.0/21
public 2 10.48.8.0/24
                     162.213.32.0/24
undefined 3 10.0.3.0/24
                     192.168.122.0/24

On trying to add a unit I see this in the machine logs:

2020-12-04 20:34:17 ERROR juju.worker.provisioner provisioner_task.go:998 17/lxd/2%!(EXTRA *errors.Err=fetching provisioning info for machine "17/lxd/2": matching subnets to zones: cannot use space "alpha" as deployment target: no subnets)

I'm happy to provide any troubleshooting information necessary, can you give us some suggestions for a workaround?

[Joseph Phillips (manadart)]

Ensure that you have a model configuration for "default-space" that is one of those containing subnets.

Then check the bindings for the application you are adding a unit to. Ensure that it has no bindings to the alpha space.

[David Lawson (deej)]

The model does have a default space, the application has a binding to that space and the space has a subnet attached:

https://pastebin.canonical.com/p/Z3JDTT8CQM/

[Joseph Phillips (manadart)]

I came across this yesterday, and it was due to an application with a default binding to the alpha space.

I had set the model-config after deploying the application, so I then had to change the bindings before deployment would work.

I think we can enhance the error with more detail as has been suggested.

[Patrik Arlos (pal-arlos)]

I experienced this when deploying the OpenStack bundle (73), on top of MAAS (3.0.0-beta5) using Juju 2.9.0. I populated the overlay file, and the deployment failed randomly with one or two hosts having the 'alpha' issue.

In my case, I could identify the application (ceph-osd) that was not included in the openstack-base-spaces-overlay.yaml, adding it and just pointing the default ("": *defaultnetwork), seems to have solved my issue.

Would have been good if something stated what unit/application requested the alpha space.

BR/P

[Brent Barr (brentbarr)]

Still a major issue- Instructions here:
https://github.com/openstack-charmers/openstack-bundles/blob/master/stable/openstack-base/README.md

Failed two out of three machines, for the 'alpha' issue. First machine was fine.
Made the change as per Patrik (Thank you!), and removed/re-issued.

Simple fix- Make this change to openstack-base-spaces-overlay.yaml:
applications:
  ceph-osd:
    bindings:
      "": *public-space

[Andrew Scribner (ca-scribner)]

I have encountered this running Juju on my home MAAS. In my configuration I can do

    juju deploy charmed-kubernetes --trust

and everything works fine, but if I do

    juju set-model-constraints "spaces=maas-external,maas-internal"
    juju deploy charmed-kubernetes --trust

all machines try to use the alpha space.

Setting the default-space=maas-external results in an odd error where machines all show that they're trying to use {'interfaces', '['2:space=2']}

[Trent Lloyd (lathiat)]

I am also encountering this on 3.1.6, as mentioned, you need to set a default binding in the bundle.

I already have 'juju model-config default-binding=vsw0' but it's not sufficient. I also have to add:
bindings:
  "": vsw0

To any model that also sets "spaces=" in constraints. Using juju with the MAAS provider, auto creating VMs in an LXD VM pod.