mupBug #1544385 opened: Deploy of Virtual Machine fail using MAAS <architecture-ppc64le> <bugnameltc-136402> <severity-high> <targetmilestone-inin14044> <maas (Ubuntu):New> <https://launchpad.net/bugs/1544385>02:29
mupBug #1544385 changed: Deploy of Virtual Machine fail using MAAS <architecture-ppc64le> <bugnameltc-136402> <severity-high> <targetmilestone-inin14044> <maas (Ubuntu):New> <https://launchpad.net/bugs/1544385>02:32
mupBug #1544385 opened: Deploy of Virtual Machine fail using MAAS <architecture-ppc64le> <bugnameltc-136402> <severity-high> <targetmilestone-inin14044> <maas (Ubuntu):New> <https://launchpad.net/bugs/1544385>02:35
mupBug #1274432 changed: MAAS does not make me a sandwich <MAAS:Opinion> <https://launchpad.net/bugs/1274432>10:03
mupBug #1274432 opened: MAAS does not make me a sandwich <MAAS:Opinion> <https://launchpad.net/bugs/1274432>10:06
mupBug #1274432 changed: MAAS does not make me a sandwich <MAAS:Opinion> <https://launchpad.net/bugs/1274432>10:15
haasnWhen trying to commission a particular machine, I get kernel stack traces constantly during boot11:10
haasn(and it seems “stuck”)11:10
haasnBut it worked in the past, not sure what has changed11:10
haasnIs there any way I can set like a “fallback“ or “backup” commissioning image that uses an older version or something?11:11
mupBug #1274432 opened: MAAS does not make me a sandwich <MAAS:In Progress by mpontillo> <https://launchpad.net/bugs/1274432>12:46
haasnI don't understand this error: “Cluster interface only has a dynamic range”. I get this when I leave a node's interface on ‘Auto assign’. It's attached to an interface that the maas cluster controller is managing DHCP+DNS on, so huh?12:47
haasnOh, I think I get it: I need to configure a separate “static” range12:47
mpontillohaasn: yes; in MAAS 1.9 you need a static range to be defined on the cluster interface in order for MAAS to know which IP address pool it is allowed to automatically allocate from12:54
haasn“Must be in the same network as the dynamic range” is a bit misleading. I took this to mean that the static range must be a subnet. But in reality, they cannot overlap12:55
mpontillohaasn: correct; the dynamic range is for addresses offered by DHCP. the static range (which must be in the same CIDR) is for addresses that MAAS assigns to deployed nodes.12:56
haasnI'm just suggesting the documentation be rewritten to make this a bit clearer12:57
mpontillohaasn: you can set the node to DHCP if you prefer it to use a single pool. when you use AUTO, we'll write the IP address to /etc/network/interfaces when the node deploys, so there is no dependency on DHCP12:57
haasnmpontillo: I'm actually missing a third option: Use the static IP detected when commissioning12:58
mpontillohaasn: that's a good point; it's funny that you mention that, because I was going to re-work some of the networking documentation today ;-)12:58
haasnFor one of my clusters I'm using a flat networking setup with an external DHCP server, I'd like it to hard-code the IPs assigned to the node by that DHCP12:58
haasnI can set it to ‘DHCP’ but then it still needs DHCP on every boot :p12:58
haasn(Then again, I guess it always does for PXE)12:58
mpontillohaasn: yes, unmanaged networks are a little more difficult for MAAS to support, but it can be done. but you may be able to use static assignment in this case (although it's true that we may not auto-fill the field with the address we saw during commissioning)13:00
mpontillohaasn: because in MAAS's view, that was an ephemeral address we saw when the node DHCP'd; it would be dangerous to allow the user to use it statically, when we aren't sure if the DHCP server has reassigned it13:00
haasnI guess it's not a big deal13:01
haasnbut I would like to be able to change the default setting for a particular subnet13:01
haasni.e. default “Auto assign” or default “DHCP”13:01
haasn(In the interface settings for the cluster)13:01
mpontillohaasn: that's not a bad idea (you might consider filing a "Wishlist" bug), but I would be more interested in understanding why MAAS can't handle your DHCP services. MAAS works better with that end-to-end integration, in my experience13:04
haasnmpontillo: Because this cluster is managing a few “spare” hosts that are in a public subnet including many other hosts, most of which have advanced DHCP requirements (e.g. unusual PXE setups, hardcoded MAC addresses everywhere, etc.)13:05
haasnSo I really can't change the fact that an external DHCP is managing this subnet, and I can't exactly have two DHCP servers running in the same broadcast domain13:06
mpontillohaasn: right. if you were able to include arbitrary configuration snippets into the DHCP server, would that allow you to use MAAS for DHCP?13:06
haasnmpontillo: Unlikely. I don't see a point either, the external DHCP server is running off ~600 lines of dhcpd.conf, redundant power supplies, etc.  Moving a big part of the server farm infrastructure into some the MAAS controller (which is just a virtual host) is not something that I feel comfortable doing in any situation13:08
mpontillohaasn: understood. thanks.13:11
mpontillohaasn: can I ask what software that DHCP server is running? if you had a way to integrate it more tightly with MAAS, so that MAAS could get a more complete view of the network, would you be willing to consider doing that?13:12
haasnmpontillo: ISC dhcpd13:13
haasnI don't plan on using MAAS heavily in this subnet13:13
haasn(I do plan on using MAAS heavily in a different subnet)13:13
haasnBut for the purposes of this subnet MAAS is just an easy “get me some spare hardware so I can test some stuff now” button13:14
haasnSo I sort of want to keep it isolated13:14
haasnThe setup right now is that ISC handles PXE for the nodes (hard-coded via MAC addresses) and forwards them to MAAS via next-server13:15
mpontillohaasn: thanks. for "unmanaged" networks such as these, the behavior actually changed between MAAS 1.8 and MAAS 1.9. In MAAS 1.8, when we deploy a node, we leave it configured to DHCP. In MAAS 1.9, we write the IP address to /e/n/i for reliability13:16
mpontillohaasn: this has the advantage that the nodes can still boot without DHCP, but the disadvantage that you must have a static range defined (unless you choose DHCP)13:17
mpontillohaasn: it sounds like that's the basic issue you were hitting13:17
haasnmpontillo: I did run into one issue when migrating to v1.9 where it would auto-assign a new deployment the IP .1, which was the default gateway of the subnet (and that was not a fun IP clash to run into :p)13:18
haasnEven though I had no subnet range configured iirc13:18
haasn(Or maybe I did, for the purpose of having it statically assign these)13:19
mpontillohaasn: ouch. while that does sounds like a bug to me, I can see how MAAS might be confused in that case. (if it doesn't have any information on that subnet, it would think that all the IP addresses in that subnet are free for the taking)13:20
mpontillohaasn: I think we need to improve MAAS's network discovery in order to prevent situations like this.13:21
mpontillohaasn: like DHCP, we should never assign an address that we can tell is already in use13:21
haasnmpontillo: It could do an effort to try an ARP on the IP before assigning13:28
haasnAnd maybe also a ping13:28
mpontillohaasn: agreed. the subtle issue regarding ARP is that there is no requirement that the MAAS server actually be on the same L2 network as the host being deployed (though admittedly it's difficult to convince MAAS to allow this, at the moment)13:29
haasnmpontillo: I guess the idea is to “try many, fail if any fail”13:29
haasnServers might be ignoring ping, too13:29
mpontillohaasn: indeed.13:30
Lyncos1 I'm trying to figure out how to make a custom Ubuntu/Debian image for maas.. but cannot find the relevant documentation... the only thing I find is scripts to do Redhat or Centos stuff15:36
=== redelmann is now known as rudi|comida
haasnmpontillo: Could also display a warning if the reverse DNS entry for the IP doesn't match the detected hostname for a node16:06
haasnIncidentally, I still can't figure out why maas refuses to use the existing hostnames of machines with two attached NICs16:06
haasnOnly one of them gets an IP (the other is ignored)16:07
haasnAnd that IP has an associated hostname16:07
roaksoaxhaasn: maas only creates a dns entry for the IP used for PXE booting16:08
haasnroaksoax: Then my behavior seems to be a bug16:09
haasnBecause that's the only interface that's allow to PXE boot to begin with (because the other doesn't even have a DHCP entry)16:10
haasnBut as soon as I take a second NIC, and plug it into the same network16:10
haasnIt ignores the existing hostname and generates a random one16:10
haasn(Or even into a different network. Even one that is not internet-facing)16:10
haasnAlthough, perplexingly, it works fine on another machine - which has 4 NICs, two of which are plugged into different network16:11
haasnHmm. Maybe, just maybe, it's complaining about the interface ordering? The affected machine has the PXE/boot/connected interface as eth1 and the other one (no PXE, only internal IP) as eth016:12
haasnActually I think the one with 4 NICs only works because it got detected when only one was plugged in16:12
haasnThe one that doesn't work got detected afterwards16:12
haasnAnyway it wouldn't be as big of a deal if I could figure out a way to change a node's name16:13
haasnIt seems to be set in stone once detected16:13
haasnI could just manually rename it from “tight-bread” to “wsl44” and that way it would actually make sense next to wsl42, wsl43 and wsl4516:14
haasnCan I do this via the API?16:14
haasnAlso has the wrong value in /etc/hostname on a deployed system :/16:17
haasn(Which actually causes some issues, because now e.g. sudo complains about not being able to resolve the host - which of course it can't, as it's a made up name rather than the perfectly fine host name that the machine should already have)16:18
roaksoaxhaasn: that's probably because the second interface is DHCP'ing from MAAS' dynamic range16:35
roaksoaxhaasn: and that is given a different DNS name16:35
haasnroaksoax: The problem persists even if it's plugged into the same network (with no maas DHCP)16:37
=== cpaelzer is now known as cpaelzer_afk
=== rudi|comida is now known as redelmann
mupBug #1544385 changed: Deploy of Virtual Machine fail using MAAS <architecture-ppc64le> <bugnameltc-136402> <severity-high> <targetmilestone-inin14044> <maas (Ubuntu):New> <https://launchpad.net/bugs/1544385>20:50
mupBug #1544385 opened: Deploy of Virtual Machine fail using MAAS <architecture-ppc64le> <bugnameltc-136402> <severity-high> <targetmilestone-inin14044> <maas (Ubuntu):New> <https://launchpad.net/bugs/1544385>20:53
mupBug #1544385 changed: Deploy of Virtual Machine fail using MAAS <architecture-ppc64le> <bugnameltc-136402> <severity-high> <targetmilestone-inin14044> <maas (Ubuntu):New> <https://launchpad.net/bugs/1544385>20:59
=== cpaelzer_afk is now known as cpaelzer
mupBug #1544743 opened: changing fabrics and other entries in network/storage is a bit flaky <landscape> <MAAS:New> <https://launchpad.net/bugs/1544743>21:47
mupBug #1544743 changed: changing fabrics and other entries in network/storage is a bit flaky <landscape> <MAAS:New> <https://launchpad.net/bugs/1544743>21:50
mupBug #1544743 opened: changing fabrics and other entries in network/storage is a bit flaky <landscape> <MAAS:New> <https://launchpad.net/bugs/1544743>21:59
mupBug #1544757 opened: Maas 1.9 Power Drivers for HP Moonshot are no longer stable <hyperscale> <MAAS:New for newell-jensen> <MAAS 1.10:New> <MAAS 1.9:New> <https://launchpad.net/bugs/1544757>22:47
=== wolverin_ is now known as wolverineav

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!