[00:01] ok ill ask there [00:43] bdx: looks great; glad MAAS is working well for you =) [00:48] hey guys i tried #ubuntu-solutions - no joy [00:48] also trying in ubuntu-server [00:55] f1gjam: the traceback is saying juju tried to deploy a MAAS node but it failed to change state to "Deployed". Can you try using MAAS to deploy a node manually and see if it works? Which version of MAAS did you install? [01:22] Maas version 1.9 [01:23] MAAS Version 1.9.3+bzr4577-0ubuntu1 (trusty1) [01:23] going to deploy OS now [01:28] so the machine looks like its done [01:28] but MaaS is saying deploying still [01:30] is there a log i can follow to see what MaaS is waiting on? [01:36] f1gjam: hmm, that may indicate a lack of connectivity to the MAAS server from the deployed node [01:37] f1gjam: is there an installation log on the node details page? (it would be in the drop-down box alongside the commissioning results and summary) [01:38] f1gjam: are you able to SSH to the machine and check the cloud-init logs? [01:39] ok [01:39] so its finsihed but still saying deploying [01:40] do you want commissioning oupiut [01:46] sure would be cool if dns was modifiable from the gui ..... [01:47] i guess it wouldn't really make sense though [01:49] pushing for container hostname specification capibility ... I guess that would be on the juju side of things though eh? [01:49] ok i am going to sleep - will try again in the morning [01:50] f1gjam: yea, the more logs the better [01:50] you can easily get them shareable with the tool 'pastebinit' [01:51] flgjam: e.g. `cat /var/log/apache2/error.log | pastebinit` [01:52] flgjam: would return a url with your log [01:52] flgjam: you should try to compile a list of logs, and paste them on #ubuntu-solutions [01:53] flgjam: if no one is around, they will answer you when they come back [01:54] f1gjam: if there is commissioning output, that's good, but I was more interested in if there was an install log [06:33] Using MAAS 2.0 with an external DHCP server, I keep running into deployment issues. The servers start up, they get an IP, but when they try to go online to setup, they try an APIPA address and then default back to my gateway's IP address, but never successfully commision. Anyone else expirience this? [06:34] If I have MAAS act as DHCP/DNS server, I can commission, but I don't want to have to create a seperate routeable network segment if I don't have to. [12:04] hey mpontillo - Are you around. The installation of the OS failed. There isnt an install available either. === quack_quack_ is now known as quack_quack === tai271828_ is now known as tai271828 === hazmat_ is now known as hazmat [14:32] this is all i get: [ERROR] OS-LEN1: Marking node failed: Node operation 'Deploying' timed out after 0:40:00. [16:27] is there a proper up to date guide which tells you how to setup MaaS step by step? [18:01] f1gjam: the docs linked off of http://maas.io/ should be relatively up to date. can you take a look at the system console during the deployment to see if there are any errors? is there an installation log available in the node details page? [18:01] f1gjam: you might also check /var/log/maas/rsyslog/ for clues [18:02] * mpontillo won't be watching IRC closely, as it's the weekend, just so you know [18:03] hey mpontillo [18:03] ok going to check now [18:03] let me re-provision [18:03] since i released all the nodes [18:04] mpontillo, appreciate any help however slow it is :) [18:04] one question [18:04] do i need to do any iptables configuration [18:05] my networks are - 192.168.10.0/24 (External) - 192.168.20.0/24 (Internal) [18:06] when i look at the system being provisioned it seems to provision all the way.... albeit i cant logon ... [18:21] f1gjam: well, the deployed node must be able to access the MAAS server (to fetch SSH keys and send the indication that the node is now "Deployed"). Not sure about iptables; depends on your setup, but you'll want to verify that if a host is configured on that network it is able to reach MAAS [18:22] its installed [18:22] currenlty at [18:22] Source MaaS http://192.168.10.1/MAAS/metadata/curtin [18:22] f1gjam: often times if there is a firewall or NAT involved and the deployed node cannot reach MAAS, what you need to do is "sudo dpkg-reconfigure -plow maas-rack-controller" and make sure the URL to the MAAS region is set to one that will be able to be reached from the network the nodes are deployed on [18:22] rsyslog is empty [18:23] ok - so my network setup is as follows: [18:23] f1gjam: so what I would do is make sure that the 192.168.20.x IP address is being used for the MAAS URL. it's possible that the deployment network cannot reach the "external" IP you are using for the MAAS region? [18:23] 192.168.10.0/24 - MAAS IP 192.168.10.1 / GATEWAY = 192.168.10.254 (REAL FIREWALL/ROUTER) -This is my external network [18:24] 192.168.20.0/24 - MAAS given adress of 192.168.20.1 on interface eth1 [18:24] f1gjam: also make sure that all the proper subnet gateways are configured in MAAS (check the details page for each subnet under "Networks" in MAAS) [18:24] thats one quesion [18:24] so lets say external network 192.168.10.1 [18:25] has the correct gatwway etc... [18:25] but in 192.168.20.1 [18:25] f1gjam: okay, and how are the deployed nodes expected to get off-subnet? what is their router supposed to be? the MAAS server? [18:25] MAAS [18:25] 192.168.20.1 [18:25] f1gjam: okay then yes you'll need to ensure routing is enabled on the MAAS server and whatever iptables rules necessary are in place [18:26] why? [18:26] f1gjam: my guess is that the deployed nodes are trying to hit MAAS on the external IP address and it isn't working due to routing issues [18:26] I mean the document statues to set [18:27] f1gjam: alternatively you can do the dpkg-reconfigure command I suggested earlier to make sure the deployed nodes hit MAAS on the internal network interface [18:27] and change the MaaS IP? [18:27] to the internal address? [18:27] f1gjam: yes [18:28] https://screencloud.net/v/lVjd [18:29] https://screencloud.net/v/xzDb [18:31] https://screencloud.net/v/377 [18:37] brb [18:40] if i change the router ip to the REAL router for the .20 netowkr [18:40] i get [18:40] calling 192.168.20.254//latest/meta--data/instance-id sp im guessing it has to be the address of the MaaS server [19:04] f1gjam: ah, you are on MAAS 1.9? for some reason I was assuming you were on 2.0 [19:05] f1gjam: some of my instructions were wrong then. "sudo dpkg-reconfigure -plow maas-cluster-controller" (not rack-controller) [19:06] f1gjam: did you send a screenshot of the configuration of the eth0 interface? [19:07] f1gjam: there is no requirement that the router IP is the MAAS server. you can define the router IP on the cluster interface settings page [19:30] im back sorry was afk [19:30] the problem is [19:30] if i set the GW IP of eth0 which is the private interface to 192.168.20.254 [19:30] it those that error about [19:33] https://screencloud.net/v/3m9g <-- eth0 configuration (private network) [19:44] https://screencloud.net/v/64N [19:44] if i put the gateway as [19:44] 192.168.20.254 [19:44] I get that issue [20:15] f1gjam: oh, that's interesting. are you redirecting MAAS to an SSL-enabled site? [20:17] f1gjam: I would try running "dpkg-reconfigure -plow maas-cluster-controller" and make sure the MAAS URL is set to http://192.168.20.1:5240/MAAS/ [20:17] f1gjam: that way you'll ensure you are talking directly to MAAS without any thing in between [20:18] ok [20:18] but.. [20:18] if you look from that pick thats when i point it to the router as the default GW for the 192.168.20.x network [20:18] that issue doesnt come up [20:18] if i make the gateway 192.168.20.1 = MAAS [20:42] f1gjam: yeah, that is weird and I can't explain that right now (though I've seen it in the past, I wonder if it's some kind of a fallback); I'm pretty sure it should be using the MAAS URL configured on the cluster, not the gateway, to attempt to contact the cloud-init data source [21:22] mpontillo, sorry i disconnected [21:22] back now [22:23] https://screencloud.net/v/QUf === lifeless_ is now known as lifeless [23:30] Hello [23:31] i ned more info for mass