Hi There,
Am using maas 2.8 stable version
am getting this error when adding a machine in maas.can anyone help me to resolve this issue
can not apply stage final no datasource found.
i don’t know why its happen.Please guide me if anyone have idea about this issue.
Thanks,
John
seems like a race condition of some sort. happens sporadically for me. buggy software somwhere. I’m using virtualbox, so maybe that’s part of it. I’m using 3.1
I am hitting the same issue, after repeated attempts to enlist a machine which was previously enlisted fine. I deleted it to try something, and now can’t get it enlisted again with the above error.
We are running 3.2.0 on 1 regiond and 2 separate rackd controllers, and this is the first time we have tried to enlist a machine with that version, and probably for some months.
did you try this:
lxc network set lxdbr0 dns.mode=none
lxc network set lxdbr0 ipv4.dhcp=false
lxc network set lxdbr0 ipv6.dhcp=false
as recommended in the docs?
there’s also a related set of recommendations from the LXD architect.
Let me know if these don’t work.
Since netplan is a story of it’s own I had to rename my vlan subinterfaces to bring them up.
Now MAAS doesn’t provide metadata to cloud-init anymore, I’m seeing the same error as @antojohnaz.
EDIT: Not using LXD, but MAAS is through snap as that seems to be the only supported option.
TL&DR: I solved it on my end by specifying DNS and default gateway equal to the interface of the MAAS rack controller for the MAAS DHCP on the private subnet
Long: I am using two subnets:
It looks like that MAAS is serving its public address (192.168.1.123) as the API endpoint for some of these python scripts. Without a default gateway, the PXE booted clients do not know how to reach this address from their own IP (192.168.10.0/24). By providing 192.168.10.10 as the default gateway, the packages at least reach the MAAS rack server, where it can respond with the proper info.
All of this is just based on how I imagine things work, would like to see an official response here.
So the above solution works for a specific network topology, but generally this issue happens when a deploying or commissioning machine cannot reach MAAS, this is often due to the DNS name for a given rack controller is unable to be resolved for the booting machine.
The boot interface should receive a lease from MAAS’ DHCP, a relay forwarding to MAAS, or a DHCP server with MAAS configured as the next-server.’
DNS should be set to the rack controller’s IP within the desired subnet. MAAS’ DNS will forward queries externally when configured to do so. This would be the default when commissioning or deploying a machine.There are alternatives, such as using netplan config to configure specific servers for a given domain, but this will be the most straight forward option.
The default gateway should be whatever is responsible for nat’ing the network, i.e if it’s a bridge network and the machines are VMs, the physical host’s IP on that bridge, or the router in the case of a physical network.
Thanks for the detailed answer.
… the DNS name for a given rack controller is unable to be resolved for the booting machine
I assume this DNS name is the hostname.domain specified for the rack controller, the default domain being just .maas? In my case I do not have control over the “public” DNS server, so the MAAS server MUST be the sole DNS server for the machines, especially during deployment, when I do not have any control over other NICs (as MAAS uses the PXE NIC exclusively during this phase).
The default gateway should be whatever is responsible for nat’ing the network
In my case, there are two networks, and I must not have two gateways. My solution somehow helps during deployment, but once deployed, the second NIC gets its IP address from the “public” DHCP server, together with an additional default gateway (which is actually the correct one, as MAAS itself should not do the NAT/routing).