![]() ![]() home/ubuntu/.cache/conjure-up/openstack-novalxd/steps/02_keypair/after-deploy home/ubuntu/.cache/conjure-up/openstack-novalxd/steps/02_keypair/ home/ubuntu/.cache/conjure-up/openstack-novalxd/steps/novarc home/ubuntu/.cache/conjure-up/openstack-novalxd/steps/00_process-providertype/metadata.yaml home/ubuntu/.cache/conjure-up/openstack-novalxd/steps/00_process-providertype/before-deploy home/ubuntu/.cache/conjure-up/openstack-novalxd/steps/00_process-providertype/ home/ubuntu/.cache/conjure-up/openstack-novalxd/steps/01_glance/metadata.yaml home/ubuntu/.cache/conjure-up/openstack-novalxd/steps/01_glance/glance.sh home/ubuntu/.cache/conjure-up/openstack-novalxd/steps/01_glance/after-deploy home/ubuntu/.cache/conjure-up/openstack-novalxd/steps/01_glance/ home/ubuntu/.cache/conjure-up/openstack-novalxd/steps/04_horizon/metadata.yaml home/ubuntu/.cache/conjure-up/openstack-novalxd/steps/04_horizon/after-deploy ![]() home/ubuntu/.cache/conjure-up/openstack-novalxd/steps/04_horizon/ home/ubuntu/.cache/conjure-up/openstack-novalxd/steps/03_neutron/metadata.yaml home/ubuntu/.cache/conjure-up/openstack-novalxd/steps/03_neutron/after-deploy home/ubuntu/.cache/conjure-up/openstack-novalxd/steps/03_neutron/neutron-ext-net home/ubuntu/.cache/conjure-up/openstack-novalxd/steps/03_neutron/neutron-tenant-net home/ubuntu/.cache/conjure-up/openstack-novalxd/steps/03_neutron/neutron.sh home/ubuntu/.cache/conjure-up/openstack-novalxd/steps/03_neutron/ home/ubuntu/.cache/conjure-up/openstack-novalxd/steps/ home/ubuntu/.cache/conjure-up/openstack-novalxd/conjure-up-localhost-e53-bootstrap.err home/ubuntu/.cache/conjure-up/openstack-novalxd/ home/ubuntu/.cache/conjure-up/conjure-up.log I would prefer a split-network with the private subnet being truly private and without using my MAAS node for routing to the public internet if there is a _address: '' /snap/bin/lxc versionĭISTRIB_DESCRIPTION="Ubuntu 16.04.5 LTS" Please attach tarball of ~/.cache/conjure-up: This may not be the correct way, but as no one answered, I found a method that is working. To test in MAAS I deployed a single Ubuntu node and ping'd the host name from the MAAS node.Īfter successfully pinging the Ubuntu node, I ssh'd into the Ubuntu node from the MAAS node using the host name and then I then ping'd from within the deployed Ubuntu node. ![]() MAAS handles DNS and provides DHCP on the private subnet for my scenarioĪdditionally, the private subnet still had to be both routed to an external internet and upstream DNS for deployment of nodes. The public subnet is unconfigured in all nodes. I enabled the private subnet route along with an internal upstream dns in my upstream router, which I believe makes it a flat network and no longer private. More documentation on how MAAS actually works behind the scenes relating to networking would be beneficial IMO. One other issue, when I tried to let MAAS manage the public subnet, (DHCP, Auto-assign) it wouldn't assign a dns or gateway although it did assign an IP, and without dns/gateway nothing was getting routed on the public subnet (host/address not found/unreachable). I am sure there are several ways to do the NAT'ing including using iptables. The dns needed to resolve quickly to eliminate timeout issues as well. YMMVĪlthough both the private and public VLAN's were enabled and set up under the subnets tab in MAAS, I needed to route the private VLAN (subnet) to the external internet (to download packages for deployment) and to an upstream dns (to resolve package ip addresses) accessible within my routed subnets. Hopefully this helps someone who is burning hours trying to figure out MAAS networking. However the cloud controller used previously is still listed when reinstalling with $ sudo snap install conjure-up -classic Tried to remove conjure-up with $ sudo snap remove conjure-up Unable to list controllers: /bin/sh: None: not found $ juju destroy-environment The node status shows ubuntu 16.04 LTS after the errors are posted.Įdit: I have tried to start over using conjure-down however I get the following error. Node post-installation failure - 'cloudinit' running modules for config It runs through initializing juju controller and shows deploying on a single node in maas until I see deploying machine script and then it stalls forever (hours) and I get the following errors:Įrrors that show up under "Events" Node post-installation failure - 'cloudinit' running config-apt-configure with frequency once-per-instance 2.5.2 installed with snap) Spell Selection - OpenStack with NovaKVMĭeploy all 16 applications in openstack-base Have both private and public VLANs connected to each node.įollowed instructions for setting up production openstack here: Successfully deployed MAAS 2.3 and 4 nodes have been commissioned and are ready to deploy.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |