[00:11] my first time with maas, and a stack of dell PE R710 systems. all systems are set to boot from pxe, and they enlist then power off. mass doesn't seem to be able to power them back on for comissioning though [00:12] it seems the nodes are shown in maas to use ipmi 2.0 over lan with IP 192.168.0.120, which is the default idrac setting. however, there are no interfaces on the maas controller that would talk to that subnet. what gives? shouldn't maas set the IPs for idrac during enlisting? [01:06] Bug #1754335 changed: [2.4, UI] Node action form takes a long time to disappear [02:19] smartctl validate empty file what does this mean? [02:19] I am hitting the ipmi successfully. [02:19] it says power on and its green [02:20] but when it tries to comission.. nothing happens.. or the result is it fails. [02:20] I manually added the node as I didn't see it in the Dashboared. [03:21] Bug #1754335 opened: [2.4, UI] Node action form takes a long time to disappear === frankban|afk is now known as frankban [12:37] Bug #1763010 opened: Block devices not discovered during commissioning [12:40] Bug #1763010 changed: Block devices not discovered during commissioning [13:52] Good Morning [13:52] Bug #1763010 opened: Block devices not discovered during commissioning [13:58] is maas supposed to set up automatically NAT between the controller and fabrics? my enlisting and comissioning fails, while the logs indicate that the nodes can't reach outside world [14:00] documentation is a bit sparse, or perhaps I'm not looking in the right place [14:02] ananke: nope [14:02] ananke: maas won't setup NAT [14:03] thank you, that may explain a lot of the issues I'm having [14:04] looks like eventually the nodes fetch stuff directly from maas, presumably using it as a proxy. however, once enlisted, maas doesn't show any relevant data as to the amount of cores/mem/etc on the nodes. it does have the right IPMI setup, and it can power cycle them [14:06] Can/Does an deployed MAAS change/update how nodes are commissioned? Got a challenge... Suddenly nodes could not be commissioned, ended up in busybox... complaining some missing driver. But the nodes were commissioned before... [14:07] No change on my behalf.. and now, when testing the issue again, they commission just fine.. [14:16] parlos_: hah. I have yet been able to comission a single node [14:16] each node boots, loads the image, but then logs on maas show a metric ton of ureadahead errors [14:16] Took me a while before I got it working too. Had a way too complicated network environment, >2 nics [14:16] eg: Apr 11 14:13:45 fast-stork ureadahead[1052]: ureadahead:/usr/lib/tmpfiles.d/x11.conf: Error retrieving chunk extents: Operation not supported [14:17] parlos_: I just have two nics: one for external network, another for internal (where all the nodes reside) [14:17] Is this at the first boot? I.e. pre-commisson? [14:17] this is during comission. however, I'm not convinced enlisting works correctly either [14:18] because the nodes don't show cores/cpu/etc in the maas interface [14:18] during enlistment it will not show any hw specs...(AFAIK) [14:18] ahh, ok [14:21] maas UI shows comissioning failed, and then for each module it has an empty log file [14:21] :( [14:22] do you have access to the console of the devices? [14:22] my experience from first MAAS deployment, was that viewing the console helped. [14:23] I do, but I honestly am not sure what I would be looking at. for example the system just spent 5 mins waiting for something, then mass comissioning image proceeded with shutdown [14:24] in my case, the device, me and maas disagreed on what was the first interface. Hence, it did the enlistment on interface X, then during commisioning it thought X was now Y... [14:24] If it waits, then i guess it tries to reach an IP and it cant... [14:25] so here's full dump of /var/log/maas/rsyslog//date/messages: http://ix.io/17wV [14:26] I'm not sure if that's the right place to look at to determine what actual aspects of comissioning failed or not [14:27] ananke: yes maas has a caching proxy and by default apt would attempt to use it unless you disabled it [14:27] parlos_: could be a kernel issue [14:28] did not change kernel... [14:28] roaksoax: nope, didn't disable it. however, it seems to try direct route first, before it tries the proxy. this is a fresh install of ubuntu 16.04 with maas 2.3.0 [14:30] ananke, are there multiple boots in that log? [14:30] parlos_: just one [14:31] ~9 minutes from start to finish [14:33] Ok, its a bit confusing.. at 14:12:58 its looks that its the kernel boot, but prior to this we got ssh keys (before kernel??) could be wrong.. [14:34] parlos_: indeed, that does look confusing. however, that's how the rsyslog on the maas controller seems to have recorded this [14:38] what user can I ssh as to the given node while it's being comissioned? [14:39] nope.... [14:39] can you get a console via the BMC? [14:40] so what's the point of having 'Allow SSH access and prevent machine from powering off' check box for comissioning? [14:41] dunno, have never tried it.. [14:41] I have the luxury to use iDrac so I have console access.. [14:41] ahh: 'As long as you've added your SSH key to MAAS, you can simply connect with SSH to the node's IP with a username of ubuntu.' [14:42] parlos_: these systems have idrac express, so no remote console [14:43] i got those too.. then I walk into the noisy room, and the KVM... [14:43] What is your network cfg? [14:43] for the nodes? [14:44] I have a dozen R710s that we were going to surplus, and instead I figured I can try maas/openstack/openshift/whatever on them [14:44] :) got R715s.. [14:44] parlos_: i have one system to act as the maas controller. it has two NICs: external and internal. internal is connected to a basic switch with a flat network [14:45] and the nodes are connected to the switch with one nic, where is the BMC connecteD? [14:45] the rest of the r710s are then connected to that switch, with their primary interface. i set them to use only pxe boot, from that first nic. idrac is set to be shared lan mode [14:45] correct [14:46] did you disable the other nics? [14:46] (ok on idrac) [14:46] nope, since my plan was to eventually use those other nics for something else (perhaps external network) [14:47] and clearly, they do use that one interface, since they boot, get the initial image, and the maas controller receives logs from them [14:48] ok, my setup is similar. But nic2 is connected to another switch. 3+4 are disabled. [14:48] so now the question is what exactly fails during the comissioning [14:49] agree, but the log is not clear... [14:50] Do you have some other HW platform that you could test? as to see if there is an MAAS kernel to R710 issue? [14:51] parlos_: unfortunately, not in that data center. I have another rack full of gear in another location, but I haven't finished the setup yet [14:52] I would however be surprised it it was a kernel-hw issue... How are the discs configed? [14:52] hw raid? [14:52] yes. perc 6i, two disks in each node with raid 1 [14:54] so a very basic setup [14:55] I'll see if logging into the nodes while they're in the process of comissioning will yield any clues [14:56] not r710 directly, but another guy had an issue with HP dl380, and it was a bios issue..to new.. [14:57] I got all of the r710s up to bios 6.4.0/6.5.0, and tried to get all of the idracs updated too [14:58] There is an issue/bug at https://bugs.launchpad.net/ubuntu/+source/ureadahead/+bug/1628438 [14:58] In MAAS does it list "Commision failed?" [15:00] yes [15:01] and I saw that bug earlier, sadly it leads to nowhere [15:02] I'd try to get console access, and view the output. From the syslog we do not see the thing that caused the Error that resulted in a fail... [15:05] parlos_: I'm not sure I can even login to the console though [15:05] you dont have to login, just watch the output.. [15:05] as in, it's not like there is a login prompt [15:06] that's the thing. there's nothing out of the ordinary. and comissioning failed errors appear on the maas controller long time before the nodes finish and shut down [15:08] It sounds to me that then node cannot properly talk to the maas server.. (for some reason). [15:09] afaik, so it boots, starts some actions (based on the tftp/pexe info), then as some point it need to talk to the maas. The maas waits for this, and if this does not happen [15:10] MAAS calls it failed, while the node timesout and tries again...eventually it gives up and shuts down. [15:13] ok,. have to go. Have a nice day, and good luck! [15:14] hi guys, currently the network configuration on the depoloyed node is in /etc/network/interfaces.d/*.cfg rather than /etc/network/interfaces. Is there a way to tell MAAS to do it at /etc/network/interfaces? thank you [15:16] Bug #1763059 opened: [2.4] DHCP is being configured on a rack controller that is not set to run DHCP [15:29] srihas: no, network config is done by cloud-init and does it in interfaces.d/*.cfg [15:30] parlos: hceck that rackd.conf:maas_url has the IP of the region instead of localhost [15:32] roaksoax: I saw a bug that JUJU is looking at interfaces file, will it be a problem if I am going to dpeloy OpenStack with JUJU later on this node? [15:50] srihas: juju should be handling e/n/i.d/*.cfg just fine [15:50] roaksoax: thank you :) [16:02] is there a way to login from the console of a system that's in the process of being comissioned, other than the ssh? [16:16] ahh ffs, I see one of the potential problems [16:17] when I hit 'comission', maas powers on the system. before that system has a chance to even fully POST, maas issues a forced reboot via the ipmi [16:17] wtf [16:19] then it claims they failed comissioning, while the nodes are booted into some maas image [16:19] that's insane [16:20] why would maas wait so little time for them to post? is that a configurable option? === frankban is now known as frankban|afk [16:28] it power cycles them after roughly 60 seconds. that's crazy [16:30] I feel like this is a bug, since I never configured any timeout settings in maas [16:35] ahh ffs: https://bugs.launchpad.net/maas/+bug/1635107 [16:59] ananke: /win 4 [16:59] err [16:59] sry [17:04] Bug #1763093 opened: Gateway can be choose in wrong subnet [18:28] when I add a physical interface to a node I'm about to comission, I see Error: node must be connected to a network. [18:28] Does the node need to have internet access? [18:29] I mean.. its connected to an internal network with no internet access [18:36] Hey__: no [18:36] Hey__: if it is to *commission* no [18:36] if it is to deploy, yes [18:47] Bug #1763147 opened: [2.4, UI] Overall service status' not updating correctly === iatrou_ is now known as iatrou === icey_ is now known as icey === aimeeu__ is now known as aimeeu [20:35] Bug #1763169 opened: [2.4, enhancement] Add UI option to allow/disallow proxy usage [20:44] Bug #1763169 changed: [2.4, enhancement] Add UI option to allow/disallow proxy usage [20:47] Bug #1763169 opened: [2.4, enhancement] Add UI option to allow/disallow proxy usage [21:29] roaksoax, under Nodes > Interfaces I geat an error it says Error: Node must be connected to a network. but the node is connected [21:30] roaksoax, blake_r, newell_ do you guys remember what file is handed out when a Power8 box PXE boots via MAAS? is it the same pxelinux.0 file that x86 gets? [21:30] or does it get a different file in /var/lib/maas/boot-resources/* [21:40] bladernr: power8 uses powernv afair [21:41] bladernr: which uses petitboot...which is the binary bootloader so no pxelinux.0 file needs to be downloaded. [21:42] hrmmm... yeah, that's what I recall. I'm looking at an openpower box (well, looking at a dump of the petitboot menu) and it's grabbing pxelinux.0 from MAAS. [21:42] and then complains that some temp file is not a valid ELF binary [21:42] meh, was just checking, the whole thing's a bit of a mess. [21:42] thanks! [21:44] bladernr: /var/lib/maas/dhcpd.conf will tell you what file is for power 8 [21:45] ahhh thanks roaksoax that's the confirmation I needed. [21:46] bladernr: https://pastebin.ubuntu.com/p/fKNqvd9v7G/ [22:19] I am having problems commissioning nodes. I don't see the node in the Dashboard, I only see it in Observed under subnet. So I add it manually. adding the ipmi interfaces [22:20] When I Select Commission, it runs for a while then fails. [22:20] What logs do I check to see what the issue is? [22:21] Events show Queried node's BMC - Power state quried o:on [22:30] what power type do I use for hyper-v? [22:33] ohh..i see. for that VM, I had to do it manually [23:42] Bug #1763214 opened: [2.4, UI, vanilla] Zone details page not formatted correctly [23:42] Bug #1763215 opened: [2.4, UI, vanilla] Group by on 'Subnets' tab is wrapped [23:45] Bug #1763216 opened: [2.4, UI, vanilla] Subnet in interfaces table is gone [23:45] Bug #1763217 opened: [2.4, UI, vanilla] Delete subnet text is wrapped and missing warning icon [23:45] Bug #1763218 opened: [2.4, UI, vanilla] Delete range (inside subnet) text is wrapped [23:48] Bug #1763219 opened: [2.4, UI, vanilla] Delete fabric confirmation text is misplaced [23:48] Bug #1763220 opened: [2.4, UI, vanilla] Compose pod action form has misplaced buttons