[00:00] <mpontillo> catbus1: well, it appears to disconnect periodically from the logs. that is why you see "Lost all connections to region controllers. Stopping service(s)"
[00:01] <catbus1> mpontillo: yes, that is probably because I was restarting region-controller.
[00:02] <catbus1> but then it shows rack controller is registered.
[00:03] <mpontillo> catbus1: right.. if that is no longer happening, I think everything should be fine
[00:04] <catbus1> mpontillo: all the logs seem to suggest everything is running fine, but why does sudo service maas-regiond status says the status is active (exited) and the maas-regiond pid doesn't exist.
[00:07] <mpontillo> catbus1: that is just how systemd represents it when a service has multiple worker processes. it's because there are four regiond workers running
[00:07] <mpontillo> catbus1: you want something more like this: for service in maas-regiond-worker@{1,2,3,4}; do service $service status; done
[00:07] <catbus1> mpontillo: ah ok
[00:08] <catbus1> mpontillo: I don't have access to the system now. will check next time. MAAS uses apache2 right?
[00:10] <mpontillo> catbus1: apache2 is not required, but with the maas-region-api package we ship /usr/share/maas/maas-http.conf -- this forwards /MAAS on the apache2 server to the MAAS HTTP server on port 5240
[00:11] <mpontillo> catbus1: it is symlinked in /etc/apache2/conf-enabled when MAAS is installed
[00:14] <catbus1> mpontillo: so apache2 is used by maas to provide http service, no? I don't follow.
[00:15] <catbus1> how do I check if the http service provided by maas is running fine
[00:16] <mpontillo> catbus1: from the region, you could do: curl -I http://localhost:5240/MAAS/
[00:16] <mpontillo> catbus1: if you get an error or timeout, it's not running
[00:19] <mpontillo> catbus1: if you wanted to script it, you could do something like --
[00:19] <mpontillo> curl -I --silent --fail http://localhost:5240/MAAS > /dev/null && echo "MAAS HTTP server is up and running." || echo "Failed to contact MAAS HTTP server."
[00:19] <mpontillo> replacing localhost with the IP of MAAS
[00:20] <mpontillo> catbus1: apache2 support is provided merely for convenience, so that users don't need to remember to type :5240 on the end of the MAAS hostname, open firewall ports, etc
[00:22] <catbus1> ok
[00:22] <catbus1> Thanks!
[00:26] <mpontillo> np
[00:38] <catbus1> mpontillo: running curl gives HTTP/1.1 302 FOUND. does that  mean it's running?
[00:39] <mpontillo> catbus1: yes
[00:39] <catbus1> ok
[00:39] <mpontillo> catbus1: that's a redirect to the login page, FYI
[00:40]  * catbus1 nods. It also shows "Location: http://<ip>:5240/MAAS/accounts/login/?next=%2FMAAS%2F". 
[00:41] <catbus1> #302 means redirect
[00:42] <mpontillo> yes.
[10:46] <KpuCko> is that anyway to make rack controller high avaliable? Im using maas 1.7
[10:56] <roaksoax> KpuCko: 1.7 does not have rack controllers nor supports HA
[10:56] <roaksoax> KpuCko: you need to use maas 2.0+
[10:56] <KpuCko> yes, thanks
[10:57] <KpuCko> i've read about this but im not sure, and prefered to ask ;>
[11:07] <roaksoax> KpuCko: region controller is typucally where the API lives
[11:07] <roaksoax> the rack controller is the one typically directly connected to the machines
[11:07] <roaksoax> and the one that provides DHCP/PXE services
[11:07] <roaksoax> KpuCko: both support HA
[11:08] <roaksoax> KpuCko: http://maas.io/docs/manage-maas-ha
[11:08] <KpuCko> yeah, yeah
[11:08] <KpuCko> thanks a lot
[11:09] <roaksoax> KpuCko: the rack controller HA is simple, you just need to connect another rack controller to the same VLAN
[11:09] <roaksoax> region ha will require a bit more work and configuration from additional services
[11:09] <KpuCko> yeah i do the same
[11:09] <KpuCko> now i have one region controller with two rack controllers (here is named cluster controllers)
[11:10] <KpuCko> so i can do region controller ha only in maas 2.0, right?
[11:12] <roaksoax> HA is only supported in MAAS 2.0+
[11:12] <KpuCko> yes, many thanks
[11:19] <mup> Bug # changed: 994761, 1039362, 1040465, 1043311, 1052874, 1052879, 1052881, 1052886, 1054040, 1054515, 1059642, 1064437, 1064796, 1076080, 1077942, 1082338, 1083244, 1084315, 1138032, 1178044, 1184816, 1214020, 1222650, 1222801, 1223734, 1224837, 1226060, 1227756, 1228284, 1235404, 1238567
[11:28] <mup> Bug # changed: 984730, 1073324, 1100342, 1199469, 1215447, 1235406, 1240051, 1250392, 1250503, 1251968, 1252754, 1254755, 1257965, 1258695, 1259872, 1270054, 1270857, 1273705, 1273941, 1274071, 1274424, 1274447, 1274553, 1274555, 1276561, 1276675, 1281299, 1282052, 1284418, 1327380, 1339734, 1340347
[11:28] <mup> Bug #1199469 changed: MaaS WebUI does not work after reboot <MAAS:Won't Fix> <maas (Ubuntu):Won't Fix> <https://launchpad.net/bugs/1199469>
[11:37] <mup> Bug # opened: 984730, 1073324, 1100342, 1199469, 1215447, 1235406, 1240051, 1250392, 1250503, 1251968, 1252754, 1254755, 1257965, 1258695, 1259872, 1270054, 1270857, 1273705, 1273941, 1274071, 1274424, 1274447, 1274553, 1274555, 1276561, 1276675, 1281299, 1282052, 1284418, 1327380, 1339734, 1340347
[11:37] <mup> Bug #1199469 opened: MaaS WebUI does not work after reboot <MAAS:Won't Fix> <maas (Ubuntu):Won't Fix> <https://launchpad.net/bugs/1199469>
[11:43] <mup> Bug # changed: 984730, 1073324, 1100342, 1199469, 1215447, 1235406, 1240051, 1250392, 1250503, 1251968, 1252754, 1254755, 1257965, 1258695, 1259872, 1270054, 1270857, 1273705, 1273941, 1274071, 1274424, 1274447, 1274553, 1274555, 1276561, 1276675, 1281299, 1282052, 1284418, 1327380, 1339734, 1340347
[11:43] <mup> Bug #1199469 changed: MaaS WebUI does not work after reboot <MAAS:Won't Fix> <maas (Ubuntu):Won't Fix> <https://launchpad.net/bugs/1199469>
[11:58] <mup> Bug # changed: 1240570, 1271694, 1274101, 1287452, 1291647, 1293939, 1294795, 1295167, 1298581, 1298778, 1298783, 1298785, 1298786, 1298787, 1303036, 1304228,
[11:58] <mup> 1311141, 1313685, 1395203, 1398196, 1398829, 1399764, 1402021, 1551636, 1555373, 1556153, 1559088, 1572646, 1604424, 1604460, 1605312, 1605517
[12:19] <mup> Bug #1596719 changed: Lenovo TS140 Server UEFI only supported by MaaS <MAAS:Invalid> <https://launchpad.net/bugs/1596719>
[15:44]  * D4RKS1D3 Hi 
[16:16] <osm> Hi guys, is it possible to upgrade from maas 1.9.4 to maas 2.0?
[16:16] <osm> or migrate database?
[16:19] <roaksoax> osm: it should just work
[16:22] <osm> database model is same?
[16:23] <roaksoax> osm: not the same, there's new migrations
[18:45] <nturner> What's the best way to ask curtin to use GPT with MAAS 2.0?  The notes at http://askubuntu.com/questions/646278/how-to-ask-curtin-to-use-gpt-instead-of-mbr-with-maas no longer seem to apply.
[18:48] <kiko> nturner, you mean, other than booting in UEFI mode?
[18:49] <nturner> kiko: right. I know grub can boot GPT in regular BIOS mode
[18:49] <kiko> it can, yes
[18:49] <nturner> btw, how does maas determine if the system is going to boot in UEFI mode or not?
[18:50] <kiko> you mean "has booted" rather than "is going to boot", no?
[18:50] <kiko> during commissioning and deployment we know that the machine booted in UEFI mode
[18:50] <kiko> and thus can partition accordingly
[18:50] <nturner> kiko: well, here I betray my ignorance =)  But I thought booting via PXE was neither
[18:51] <kiko> ah
[18:51] <kiko> sadly it seems both smoser and blake_r_ are out today
[18:51] <kiko> nturner, and you've tried to modify the curtin userdata?
[18:51] <kiko> perhaps roaksoax can give you a bit more technical advice
[18:53] <nturner> kiko: I added the block-meta stanza suggested at that askubuntu.com answer to the preseed file. It didn't seem to have any effect.
[18:53] <nturner> Still got a msdos partition table
[18:53] <nturner> Maybe I needed to restart something?
[18:57] <kiko> nope, it's provided when the deploy runs
[18:57] <kiko> hmm
[18:57] <kiko> roaksoax?
[19:50] <mup> Bug #1616201 opened: MAAS 2: database notification failure causes out-of-date DNS <landscape> <MAAS:New> <https://launchpad.net/bugs/1616201>
[20:37] <roaksoax> nturner: every single time we boot we check what the machine booted with
[20:38] <kiko> roaksoax, and when PXE-booting, you are still booting via either BIOS or UEFI, right?
[20:38] <roaksoax> kiko: PXE-booting is legacy
[20:38] <roaksoax> kiko: so we either do legacy or efi
[20:38] <roaksoax> we know every time we boot
[20:39] <kiko> roaksoax, that's confusing -- EFI also supports netboot, is that it?
[20:39] <kiko> and it's not PXE?
[20:40] <roaksoax> kiko: EFI never does "pxe"
[20:40] <roaksoax> kiko: pxe is pxelinux
[20:40] <kiko> roaksoax, oh, you confused me there
[20:41] <kiko> PXE is actually the IETF "standard"
[20:41] <kiko> which EFI can do, but not using PXELINUX
[20:41] <kiko> :)
[20:41] <kiko> anyway, we are agreeing
[20:41] <roaksoax> kiko: yeah, I guess we misuse the terms
[20:41] <kiko> when you boot in EFI mode, you do netboot, you just don't get pxelinux sent to you
[20:41] <roaksoax> kiko: efi does pxe, then it is told to netboot via grub
[20:41] <kiko> and when you boot in legacy mode, we do send pxelinux
[20:41] <kiko> yeah
[20:41] <roaksoax> while legacy does pxe then use pxelinux
[20:42] <kiko> yep
[20:42] <kiko> roaksoax, how do we check how we booted? I guess we know from the DHCP options?
[20:42] <kiko> roaksoax, do you know why nturner can't seem to get curtin to put down a GPT partition even when specifying userdata?
[20:42] <kiko> roaksoax, did that change in curtin2?
[20:42] <nturner> ok, I think I mostly follow. So if I can convince my motherboard to boot in EFI mode, it should network boot in a way that allows maas to detect that
[20:43] <kiko> err the curtin we use for maas2?
[20:43] <kiko> correct
[20:43] <nturner> roaksoax: in your first statement, are you referring to the get_partition_format_type check in curtin/commands/block_meta.py?
[20:43] <kiko> it's usually a single tweak
[20:44] <nturner> hmmm, changing the "Launch Storage OpROM Policy" from Legacy first to UEFI first didn't do the trick... maybe this mobo can't do EFI netboot?
[20:45] <kiko> it should be able to
[20:45] <nturner> should I be able to override this decision to use msdos instead of gpt partition type?
[20:45] <kiko> you should also
[20:45] <kiko> nturner, it's worth a dive into the curtin code to figure out why it's ignoring your userdata
[20:46] <nturner> kiko, yeah, I think I found where it should be acting on it
[20:46] <nturner> I assume the curtin code that runs at install time is baked into the images, though, so adding arbitrary tracing etc. is not a simple proposition
[20:46] <roaksoax> DHCP tells the firmware whether it should contact MAAS via tftp (for pxelinux) or HTTP (efi)
[20:46] <nturner> from what I see in the code, my userdata change looks right
[20:47] <roaksoax> based on that we know a machine booted either legacy or efi
[20:47] <nturner> roaksoax: so do I need to recommission a node after making bios changes?
[20:48] <nturner> oh, you're saying based on which resouce was fetched, we can tell which kind of boot it was
[20:48] <nturner> got it
[20:48] <roaksoax> nturner: yes you do
[20:49] <nturner> since I see TFTP requests in the event log, it sounds like I'm still booting in legacy pxelinux mode
[20:52] <roaksoax> nturner: you should see stuff like: 2016-08-23 20:47:02 [TFTP (UDP)] Datagram received from ('10.245.0.213', 1585): <RRQDatagram(filename=b'grubx64.efi', mode=b'octet', options=OrderedDict([(b'blksize', b'512')]))>
[20:53] <oz_>  hey guys does anyone have any good write up on how to deploy maas/autopilot using using vlan tagged interfaces i tried all different combinations and i cant get it to work
[20:54] <roaksoax> dpb1: ^^
[20:55] <oz_> if i use one ip ranage for publics, everything deploys fine as soon as i tag vlans on the nodes deployment fails
[21:06] <nturner> I think I have to conclude that this motherboard does not actually support EFI netboot.
[21:07] <nturner> Would it be reasonable for curtin to default to GPT partition tables when dealing with volumes larger than 2TB?
[21:13] <nturner> Interesting... maybe I finally succeeded in getting curtin to use gpt... now the PXELINUX "Booting to local disk ..." step fails with "WARN: No MBR magin, treating disk as raw."
[21:13] <nturner> And of course, it doesn't boot.
[21:14] <nturner> Does pxelinux only work with msdos partition tables?
[21:14] <nturner> Or is this just a sign that grub-install failed to put the right stuff at the front of the disk?
[21:14]  * nturner wonders
[21:45] <roaksoax> nturner: if you can file a bug about i can have someone look at it
[21:45] <nturner> roaksoax: sure
[21:46] <roaksoax> nturner: and it should be reasonable
[21:46] <nturner> by it do you mean...
[21:46] <roaksoax> nturner: but i do remember having a similar request in the past and it being addressed
[21:46] <nturner> forcing the use of gpt?
[21:46] <nturner> or booting from gpt in bios mode via pxelinux?
[21:46] <roaksoax> (curtin doing gpt on 2tb+ disks)
[21:46] <nturner> ah
[21:46] <nturner> ok
[21:47] <roaksoax> nturner: are u using 2.0?
[21:47] <nturner> roaksoax: yes, latest from dev ppa
[21:49] <roaksoax> nturner: which dev ppa are you using? ;) experimental3 ?
[21:50] <nturner> http://ppa.launchpad.net/maas/next/ubuntu
[21:50] <nturner> so, "dev" might not be quite the right adjective
[21:50] <nturner> :)
[21:52] <roaksoax> nturner: right so 2.0 GA then :)
[21:52] <nturner> ah, is it GA now? It was an RC last I looked
[21:55] <roaksoax> nturner: ah right, we only made GA vailable on ppa:maas/stable
[21:55] <roaksoax> nturner: but will fix that in a sec
[21:56] <roaksoax> nturner: filed https://bugs.launchpad.net/ubuntu/+source/maas/+bug/1616231
[21:57] <roaksoax>  
[21:57] <nturner> cool
[21:57] <nturner> I also filed https://bugs.launchpad.net/maas/+bug/1616232
[21:58] <roaksoax> nturner: i'll re-target mine then
[21:59] <nturner> roaksoax: yours is arguably a better description of the issue
[21:59] <roaksoax> nturner: i rephrased to have the ability to select what partition table
[22:00] <roaksoax> nturner: will use yours to fix the bug
[22:00] <nturner> roaksoax: thanks for looking at this
[22:01] <roaksoax> np! i think this was one of the things that dropped out of the radar unfortunately
[22:21] <mup> Bug #1616231 opened: Can't select partition table (MBR vs GPT) <MAAS:Confirmed> <MAAS trunk:Confirmed> <https://launchpad.net/bugs/1616231>
[22:21] <mup> Bug #1616232 opened: Installs should use GPT by default if volume is larger than 2TB <MAAS:Confirmed> <MAAS 2.0:Confirmed> <MAAS trunk:Confirmed> <https://launchpad.net/bugs/1616232>