| mup | Bug #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 |
|---|---|---|
| mup | Bug #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 |
| mup | Bug #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 |
| mup | Bug #1274432 changed: MAAS does not make me a sandwich <MAAS:Opinion> <https://launchpad.net/bugs/1274432> | 10:03 |
| mup | Bug #1274432 opened: MAAS does not make me a sandwich <MAAS:Opinion> <https://launchpad.net/bugs/1274432> | 10:06 |
| mup | Bug #1274432 changed: MAAS does not make me a sandwich <MAAS:Opinion> <https://launchpad.net/bugs/1274432> | 10:15 |
| haasn | When trying to commission a particular machine, I get kernel stack traces constantly during boot | 11:10 |
| haasn | (and it seems “stuck”) | 11:10 |
| haasn | But it worked in the past, not sure what has changed | 11:10 |
| haasn | Is there any way I can set like a “fallback“ or “backup” commissioning image that uses an older version or something? | 11:11 |
| mup | Bug #1274432 opened: MAAS does not make me a sandwich <MAAS:In Progress by mpontillo> <https://launchpad.net/bugs/1274432> | 12:46 |
| haasn | I 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 |
| haasn | Oh, I think I get it: I need to configure a separate “static” range | 12:47 |
| mpontillo | haasn: 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 from | 12: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 overlap | 12:55 |
| mpontillo | haasn: 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 |
| haasn | I'm just suggesting the documentation be rewritten to make this a bit clearer | 12:57 |
| mpontillo | haasn: 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 DHCP | 12:57 |
| haasn | mpontillo: I'm actually missing a third option: Use the static IP detected when commissioning | 12:58 |
| mpontillo | haasn: 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 |
| haasn | For 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 DHCP | 12:58 |
| haasn | I can set it to ‘DHCP’ but then it still needs DHCP on every boot :p | 12:58 |
| haasn | (Then again, I guess it always does for PXE) | 12:58 |
| mpontillo | haasn: 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 |
| mpontillo | haasn: 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 it | 13:00 |
| haasn | I guess it's not a big deal | 13:01 |
| haasn | but I would like to be able to change the default setting for a particular subnet | 13:01 |
| haasn | i.e. default “Auto assign” or default “DHCP” | 13:01 |
| haasn | (In the interface settings for the cluster) | 13:01 |
| mpontillo | haasn: 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 experience | 13:04 |
| haasn | mpontillo: 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 |
| haasn | So 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 domain | 13:06 |
| mpontillo | haasn: 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 |
| haasn | mpontillo: 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 situation | 13:08 |
| mpontillo | haasn: understood. thanks. | 13:11 |
| mpontillo | haasn: 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 |
| haasn | mpontillo: ISC dhcpd | 13:13 |
| haasn | I don't plan on using MAAS heavily in this subnet | 13:13 |
| haasn | (I do plan on using MAAS heavily in a different subnet) | 13:13 |
| haasn | But for the purposes of this subnet MAAS is just an easy “get me some spare hardware so I can test some stuff now” button | 13:14 |
| haasn | So I sort of want to keep it isolated | 13:14 |
| haasn | The setup right now is that ISC handles PXE for the nodes (hard-coded via MAC addresses) and forwards them to MAAS via next-server | 13:15 |
| mpontillo | haasn: 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 reliability | 13:16 |
| mpontillo | haasn: 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 |
| mpontillo | haasn: it sounds like that's the basic issue you were hitting | 13:17 |
| haasn | ah | 13:17 |
| haasn | mpontillo: 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 |
| haasn | Even though I had no subnet range configured iirc | 13:18 |
| haasn | (Or maybe I did, for the purpose of having it statically assign these) | 13:19 |
| mpontillo | haasn: 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 |
| mpontillo | haasn: I think we need to improve MAAS's network discovery in order to prevent situations like this. | 13:21 |
| mpontillo | haasn: like DHCP, we should never assign an address that we can tell is already in use | 13:21 |
| haasn | mpontillo: It could do an effort to try an ARP on the IP before assigning | 13:28 |
| haasn | And maybe also a ping | 13:28 |
| mpontillo | haasn: 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 |
| haasn | mpontillo: I guess the idea is to “try many, fail if any fail” | 13:29 |
| haasn | Servers might be ignoring ping, too | 13:29 |
| mpontillo | haasn: indeed. | 13:30 |
| Lyncos1 | Hi, | 15:36 |
| 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 stuff | 15:36 |
| === redelmann is now known as rudi|comida | ||
| haasn | mpontillo: Could also display a warning if the reverse DNS entry for the IP doesn't match the detected hostname for a node | 16:06 |
| haasn | Incidentally, I still can't figure out why maas refuses to use the existing hostnames of machines with two attached NICs | 16:06 |
| haasn | Only one of them gets an IP (the other is ignored) | 16:07 |
| haasn | And that IP has an associated hostname | 16:07 |
| roaksoax | haasn: maas only creates a dns entry for the IP used for PXE booting | 16:08 |
| haasn | roaksoax: Then my behavior seems to be a bug | 16:09 |
| haasn | Because 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 |
| haasn | But as soon as I take a second NIC, and plug it into the same network | 16:10 |
| haasn | It ignores the existing hostname and generates a random one | 16:10 |
| haasn | (Or even into a different network. Even one that is not internet-facing) | 16:10 |
| haasn | Although, perplexingly, it works fine on another machine - which has 4 NICs, two of which are plugged into different network | 16:11 |
| haasn | Hmm. 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 eth0 | 16:12 |
| haasn | Actually I think the one with 4 NICs only works because it got detected when only one was plugged in | 16:12 |
| haasn | The one that doesn't work got detected afterwards | 16:12 |
| haasn | Anyway it wouldn't be as big of a deal if I could figure out a way to change a node's name | 16:13 |
| haasn | It seems to be set in stone once detected | 16:13 |
| haasn | I could just manually rename it from “tight-bread” to “wsl44” and that way it would actually make sense next to wsl42, wsl43 and wsl45 | 16:14 |
| haasn | Can I do this via the API? | 16:14 |
| haasn | Also 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 |
| roaksoax | haasn: that's probably because the second interface is DHCP'ing from MAAS' dynamic range | 16:35 |
| roaksoax | haasn: and that is given a different DNS name | 16:35 |
| haasn | roaksoax: 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 | ||
| mup | Bug #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 |
| mup | Bug #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 |
| mup | Bug #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 | ||
| mup | Bug #1544743 opened: changing fabrics and other entries in network/storage is a bit flaky <landscape> <MAAS:New> <https://launchpad.net/bugs/1544743> | 21:47 |
| mup | Bug #1544743 changed: changing fabrics and other entries in network/storage is a bit flaky <landscape> <MAAS:New> <https://launchpad.net/bugs/1544743> | 21:50 |
| mup | Bug #1544743 opened: changing fabrics and other entries in network/storage is a bit flaky <landscape> <MAAS:New> <https://launchpad.net/bugs/1544743> | 21:59 |
| mup | Bug #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!