[09:36] <mup> Bug #1702438 opened: [2.2] No way to specify protocol when adding a VMware chassis <cpe> <cpe-sa> <MAAS:New> <https://launchpad.net/bugs/1702438>
[13:49] <gimmic> http://paste.ubuntu.com/25025233/
[13:50] <gimmic> trying to deploy to a node after clearing the default storage configuration and specifying raid0 across three drives
[14:10] <gimmic> I am assuming it is having problems clearing the partitions
[14:10] <gimmic> Eventually failing on 14.04 with "/sys/class/block/dm-11 had no syspath (/sys/class/block/dm-11)"
[14:19] <roaksoax> gimmic: that seems like a curtin issue. Curtin  should be clearing what was leftover on the disk before proceeding
[14:19] <gimmic> Yeah. I saw a curtin update and hoped it fixed it, not so lucky
[14:31] <gimmic> To test, is there a good way to boot the machine to a workable state I can clear the drive configurations out of myself?
[14:31] <gimmic> Maybe recommission the host and allow ssh?
[14:41] <roaksoax> gimmic: rescue mode ?
[14:42] <gimmic> Hadn't used rescue mode yet. Commissioning w/ ssh on worked. I verified /dev/sda4 was still allocated to a vg
[14:44] <gimmic> oh, unless that was the commission bits. Need caffiene
[14:46] <roaksoax> gimmic: no, commissioning doesn't do anything with storage, so you are correct
[15:36] <tlian> QUESTION: What port/service does MAAS talk to in adding (enlisting & commissiong) new machine?
[15:36] <tlian> I am seeing the following error
[15:36] <tlian> maasserver.websockets.protocol: [critical] Error on request (88) machine.action: No rack controllers can access the BMC of node: servername
[15:37] <tlian> MAAS and the HW management network (Cloud service) are on a different Network.  So, the issue is similar to this https://bugs.launchpad.net/maas/+bug/1547275
[15:37] <tlian> Now I need to go talk to Cloud service team to open up a port so it can communicate with MAAS. What port/service (http/https/ssh ...) should I have them open?
[15:38] <roaksoax> tlian: that seems like your rack controller cannot communicate with the BMC's of the machines
[15:38] <roaksoax> tlian: I'm guessing that's IPMI machines
[15:38] <roaksoax> so that would be IPMI ports
[15:38] <tlian> yes. correct
[15:39] <tlian> roaksoax: thank. I will give that a shot
[15:41] <julen> hi! I am having a little issue as well... with commissioning
[15:41] <julen> are there some extra settings for the using MaaS behind a http_proxy, which are not just adding the proxy address on the controller?
[15:43] <julen> While attempting to commission a node, it ends up with "Failed commissioning" and the syslog says that the systemd-timesynctl was timed out
[15:47] <julen> ... and why is the node not getting the http_proxy variable as global?  ... yes, apt works, but the rest of snapd and stuff keep producing errors
[15:47] <julen> roaksoax?
[16:10] <mup> Bug #1702509 opened: [2.2.1] DNS locks up regularly <MAAS:Triaged> <MAAS 2.2:Triaged> <https://launchpad.net/bugs/1702509>
[16:29] <gimmic> roaksoax: yup, if I clean up the LVM the system deploys!
[16:29] <gimmic> Is there any way I can script the partition management better? I have hundreds of nodes
[16:29] <gimmic> the whole point of maas is that I don't have to worry about touching the bare metal as much
[16:29] <gimmic> going to validate it now with a fresh node and see if pre-emptively nuking the straggler LVM fixes it
[16:31] <gimmic> Basically, the templated storage pre-config is not good for my environment at all
[16:40] <gimmic> Another question.. why doesn't maas show me what the dhcp leased address is for a node? It knows what it is, it knows the dhcp pool, it knows the arp table.. I can manually look it up but (auto assign) doesn't help much.
[16:40] <gimmic> It should show (auto assigned: 10.10.20.23)
[16:46] <mup> Bug #1702517 opened: Postgres installed with MAAS logs very aggressively <MAAS:New> <https://launchpad.net/bugs/1702517>
[16:53] <gimmic> roaksoax: so the installation process seems to fail to properly remove the vg 'vg_lscratch' during deployment
[16:53] <gimmic> I wish there was a "erase disk partitions prior to deployment" checkbox
[16:54] <gimmic> seems like that would clear it all up
[16:54] <gimmic> maybe during comissioning
[17:00] <roaksoax> gimmic: 'release' your failed deployment machine and erase the disks : )
[17:00] <roaksoax> gimmic: or you can create your own commssioning script
[17:02] <julen> roaksoax: I am just looking into that. I just want to try to get the http_proxy variable set as global
[17:04] <julen> I have tried adding something after driver_04_load in the /etc/maas/preseeds/curtin_userdata but it does not take it while commissioning
[17:10] <gimmic> roaksoax: I think even saying erase the disks is failing to clean up this lvm mess
[17:14] <gimmic> these nodes are hosed. Easiest way I found to clean up the partitions is just to dd zeroes at the start of each.. ugh
[17:55] <mup> Bug #1702527 opened: cannot delete already existing subnets <MAAS:New> <https://launchpad.net/bugs/1702527>
[18:05] <gimmic> Are there any examples of commissioning scripts?
[18:06] <gimmic> roaksoax: telling the failed node to erase disks seems to have hung
[18:06] <julen> gimmic: I am also looking into that right now
[18:07] <julen> There is this page: https://insights.ubuntu.com/2017/06/02/customising-maas-installs/
[18:07] <gimmic> I assume my issue is related to the same reason curtin is failing, "WARNING: Duplicate VG name vg_lscratch" and issues removing it cleanly
[18:07] <julen> but it seems a little outdated
[18:08] <gimmic> My issue seems to arise from how we repurposed drives from similar nodes to populate out the systems
[18:08] <julen> I guess both of our problems could be solved the same way: finding out how to modify the preseed
[18:08] <gimmic> so we have duplicate vgs in lvm, but I don't even want to use LVM. I just want to nuke the disk partitions from orbit and install
[18:09] <julen> gimmic: and it is failing while commissioning, right?
[18:09] <gimmic> Initially. Then it fails during deployment too
[18:09] <julen> I cannot even manage to get the commissioning properly
[18:11] <julen> a good question would be... on the older documentation, it says that one could modify the preseeds at /etc/maas/preseeds, but at the moment they look quite cryptic
[18:11] <julen> the "commissioning" file contains just "{{preseed_data}}", but where is that defined??
[18:46] <julen> gimmic: still there?
[18:46] <gimmic> Yup
[18:46] <julen> I just found out how it works
[18:47] <gimmic> still poking around
[18:47] <julen> it's actually quite simple
[18:47] <julen> your thing is more tricky, but you can probably get a lot done with a commissioning script
[18:48] <julen> do you already know how to do it?
[18:48] <gimmic> im currently looking at throwing them all into rescue mode and simply tackling it with a remote bash script
[18:49] <gimmic> I would still need a custom deploy script to do some other tweaks, like setting up the storage automagically and allocating matching IP addresses
[18:49] <julen> but the commissioning script part, you already understand it, right?
[20:21] <roaksoax> gimmic: it could be that it is actually erasing which takes time
[20:21] <roaksoax> gimmic: therey should be a quick erase option
[20:22] <mup> Bug #1702560 opened: faild deploy windows 2012r2, but  boot stay ok <MAAS:New> <https://launchpad.net/bugs/1702560>
[21:04] <mup> Bug #1702567 opened: Make package-dev does not include maas_api_helper.py <MAAS:Triaged> <https://launchpad.net/bugs/1702567>
[23:28] <mup> Bug #1702517 changed: Postgres installed with MAAS logs very aggressively <MAAS:Invalid> <https://launchpad.net/bugs/1702517>