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:00 |
---|---|---|
catbus1 | mpontillo: yes, that is probably because I was restarting region-controller. | 00:01 |
catbus1 | but then it shows rack controller is registered. | 00:02 |
mpontillo | catbus1: right.. if that is no longer happening, I think everything should be fine | 00:03 |
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:04 |
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:07 |
catbus1 | mpontillo: I don't have access to the system now. will check next time. MAAS uses apache2 right? | 00:08 |
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:10 |
mpontillo | catbus1: it is symlinked in /etc/apache2/conf-enabled when MAAS is installed | 00:11 |
catbus1 | mpontillo: so apache2 is used by maas to provide http service, no? I don't follow. | 00:14 |
catbus1 | how do I check if the http service provided by maas is running fine | 00:15 |
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:16 |
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:19 |
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:20 |
catbus1 | ok | 00:22 |
catbus1 | Thanks! | 00:22 |
mpontillo | np | 00:26 |
catbus1 | mpontillo: running curl gives HTTP/1.1 302 FOUND. does that mean it's running? | 00:38 |
mpontillo | catbus1: yes | 00:39 |
catbus1 | ok | 00:39 |
mpontillo | catbus1: that's a redirect to the login page, FYI | 00:39 |
* catbus1 nods. It also shows "Location: http://<ip>:5240/MAAS/accounts/login/?next=%2FMAAS%2F". | 00:40 | |
catbus1 | #302 means redirect | 00:41 |
mpontillo | yes. | 00:42 |
=== frankban|afk is now known as frankban | ||
KpuCko | is that anyway to make rack controller high avaliable? Im using maas 1.7 | 10:46 |
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:56 |
KpuCko | i've read about this but im not sure, and prefered to ask ;> | 10:57 |
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:07 |
roaksoax | KpuCko: http://maas.io/docs/manage-maas-ha | 11:08 |
KpuCko | yeah, yeah | 11:08 |
KpuCko | thanks a lot | 11:08 |
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:09 |
KpuCko | so i can do region controller ha only in maas 2.0, right? | 11:10 |
roaksoax | HA is only supported in MAAS 2.0+ | 11:12 |
KpuCko | yes, many thanks | 11:12 |
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:19 |
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:28 |
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:37 |
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:43 |
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 | 11:58 |
mup | Bug #1596719 changed: Lenovo TS140 Server UEFI only supported by MaaS <MAAS:Invalid> <https://launchpad.net/bugs/1596719> | 12:19 |
* D4RKS1D3 Hi | 15:44 | |
osm | Hi guys, is it possible to upgrade from maas 1.9.4 to maas 2.0? | 16:16 |
osm | or migrate database? | 16:16 |
roaksoax | osm: it should just work | 16:19 |
osm | database model is same? | 16:22 |
roaksoax | osm: not the same, there's new migrations | 16:23 |
=== Guest25180 is now known as med_ | ||
=== med_ is now known as medberry | ||
=== medberry is now known as med_ | ||
=== frankban is now known as frankban|afk | ||
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:45 |
kiko | nturner, you mean, other than booting in UEFI mode? | 18:48 |
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:49 |
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:50 |
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:51 |
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:53 |
kiko | nope, it's provided when the deploy runs | 18:57 |
kiko | hmm | 18:57 |
kiko | roaksoax? | 18:57 |
mup | Bug #1616201 opened: MAAS 2: database notification failure causes out-of-date DNS <landscape> <MAAS:New> <https://launchpad.net/bugs/1616201> | 19:50 |
roaksoax | nturner: every single time we boot we check what the machine booted with | 20:37 |
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:38 |
kiko | roaksoax, that's confusing -- EFI also supports netboot, is that it? | 20:39 |
kiko | and it's not PXE? | 20:39 |
roaksoax | kiko: EFI never does "pxe" | 20:40 |
roaksoax | kiko: pxe is pxelinux | 20:40 |
kiko | roaksoax, oh, you confused me there | 20:40 |
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:41 |
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:42 |
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:43 |
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:44 |
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:45 |
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:46 |
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:47 |
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:48 |
nturner | since I see TFTP requests in the event log, it sounds like I'm still booting in legacy pxelinux mode | 20:49 |
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:52 |
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:53 |
roaksoax | dpb1: ^^ | 20:54 |
oz_ | if i use one ip ranage for publics, everything deploys fine as soon as i tag vlans on the nodes deployment fails | 20:55 |
nturner | I think I have to conclude that this motherboard does not actually support EFI netboot. | 21:06 |
nturner | Would it be reasonable for curtin to default to GPT partition tables when dealing with volumes larger than 2TB? | 21:07 |
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:13 |
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:14 | |
roaksoax | nturner: if you can file a bug about i can have someone look at it | 21:45 |
nturner | roaksoax: sure | 21:45 |
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:46 |
roaksoax | nturner: are u using 2.0? | 21:47 |
nturner | roaksoax: yes, latest from dev ppa | 21:47 |
roaksoax | nturner: which dev ppa are you using? ;) experimental3 ? | 21:49 |
nturner | http://ppa.launchpad.net/maas/next/ubuntu | 21:50 |
nturner | so, "dev" might not be quite the right adjective | 21:50 |
nturner | :) | 21:50 |
roaksoax | nturner: right so 2.0 GA then :) | 21:52 |
nturner | ah, is it GA now? It was an RC last I looked | 21:52 |
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:55 |
roaksoax | nturner: filed https://bugs.launchpad.net/ubuntu/+source/maas/+bug/1616231 | 21:56 |
roaksoax | 21:57 | |
nturner | cool | 21:57 |
nturner | I also filed https://bugs.launchpad.net/maas/+bug/1616232 | 21:57 |
roaksoax | nturner: i'll re-target mine then | 21:58 |
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 | 21:59 |
roaksoax | nturner: will use yours to fix the bug | 22:00 |
nturner | roaksoax: thanks for looking at this | 22:00 |
roaksoax | np! i think this was one of the things that dropped out of the radar unfortunately | 22:01 |
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> | 22:21 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!