[02:32] Bug #1657162 changed: [2.1] cli docs refer to non-existent commands [02:32] Bug #1664996 changed: MaaS Install Rack Controller: Instructions Unclear [02:32] Bug #1666274 changed: MAAS HA broken URL

[09:06] brendand: ping? [09:09] babbageclunk, oh hey [09:10] brendand: hey - did you get anywhere with the Juju 2.2 problem? [09:10] I've knocked up a little websocket client that might let us get a bit more detail. [09:11] it basically just connects and sends a login [09:11] babbageclunk, oh cool [09:11] babbageclunk, let me get that instance spun up again. if you're short on time you can send me instructions, or we can have a hangout if you want [09:13] brendand: sending it through now - happy to hangout once the maas is spun up [09:25] brendand: I'll be afk for a bit so I won't see IRC responses but send me an email and I'll jump back onto my computer. [09:25] babbageclunk, np [09:28] brendand: oh, also no worries if you're in the middle of something else - happy to try some other time if that's better? [09:34] babbageclunk, no no, i really want to get this solved [09:34] brendand: ok cool [09:47] babbageclunk, ping [09:48] brendand: hey - have a hangout handy? [09:50] brendand: https://hangouts.google.com/hangouts/_/canonical.com/brendan-xtian [09:50] babbageclunk, thanks, i was just making one , but cheers [12:20] hi === fab is now known as Guest95025 [12:22] I am running a MAAS installation on MAAS Version 2.1.3+bzr5573-0ubuntu1 and want to know when new content is considered as stable and if I am on the latest version? I am using the ppa:maas/stable and update it via apt-get update/upgrade regulrarly [12:23] On https://launchpad.net/~maas/+archive/ubuntu/stable/+packages I found some other builds (different versions after the "bzr" code).. therefore I am not sure if I am current [12:27] Guest95025: 2.1.5 is the latest in the ppa:maas/stable [12:28] thanks for the input. Are the PPA stored in linux after adding them via sudo add-apt-repository ppa:maas/stable? I wonder why apt-get update / upgrade does not update the packages... [12:29] just re-added the PPA; how he founds 2.1.5 [12:29] Guest95025: Yeah, add-apt-repository should add an entry in /etc/apt/sources.list.d [12:31] -rw-r--r-- 1 root root 126 Apr 20 14:27 maas-ubuntu-stable-xenial.list <-- should be the culprit; is there any system routine, which removes them? [12:33] Hmm however that's off-topic. Another question: is there a document which defines or indicates when a new version is getting defined as stable? [12:34] I found the general release plan https://launchpad.net/maas/+series; however it does not indicate when 2.1.6 is becomming the next stable or when 2.2 or 2.3 are taking over? [13:01] I got another Question regarding https://bugs.launchpad.net/maas/+bug/1660743; does anybody know why MAAS does not offer DHCP service after making an IP Binding for a MAC? After listing it on the NODES tab, no more IP is provided :-/ [13:02] Could be a bug or maybe a faulty configuration on my side. [13:02] Guest95025, the latter doesn't make sense [13:02] kiko: what do you mean? [13:04] Guest95025, I mean, it's a bug or config problem. but the bug you referred to.. just appears to be cosmetic? [13:05] kiko: I dont think it is cosmetic; Whenever I create a VM to let it beeing installed via MAAS, I expect MAAS to provide an ip. Otherwise, MAAS cannot connect to install an image there? [13:05] MAAS always should prove DHCP IP [13:07] when I click under NODES the new machine and click COMMISSION, there is an error message from MAAS "MAAS is not providing DHCP" [13:08] An nmap to all Ips managed by MAAS also indicate that the VM retrieved no IP address; before the VM is displayed within "NODES" nmap returned an IP for the VM... === lutostag_ is now known as lutostag [17:42] Bug #1684111 changed: MaaS assigns static IP addresses from dynamic range === frankban is now known as frankban|afk [19:52] trying to add a dhcp snippet for next-server. i was able to add it for my first subnet, but the others reject with Unable to validate DHCP config, no available rack controller. [19:53] all subnets are set for dhcp management [19:53] :/ [19:56] managed allocation, i mean [19:59] and when i look in dhcpd.conc insee identical blov [20:00] blocks for each subnet, except for their ranges obviosly, and the one subnet that worked has the added snippet. [20:00] verified all subnets using the same rack controller [20:00] which shows healthy [20:30] xygnal: I just pinged the guy on the team who implemented that [20:31] ltrager: ^ [20:41] xygnal: what config are you trying to use? [20:43] define config? [20:45] all untagged vlan, all same fabric, multiple subnets [20:45] the snippet you are trying to use [20:46] ah, trying to add a next-server block to each subnet [20:46] worked for the first subnet, others refuse with that error [20:48] next-server ip.ad.dr.ess; is the actual code strong [20:48] with a real IP obviously [20:49] hm.... I wonder if its because i'm setting next-server that is in a differnet subnet [20:49] we are using DHCP forwarding I believe (routers forwarding DHCP to our server) [20:50] thinking about it now, yeah. The IP I am giving it for the first subnet is the same subnet, I believe. BUt the other subnets, it would be external. [20:50] perhaps that is why [20:50] honestly just testing possible solutions (from other bug reports) about the problem we are having [20:51] where nodes comissioning are given an IP address on the WRONG subnet, and fail comission [21:09] xygnal: so what MAAS does is pass the config you give it to DHCPD, it then validates the config as it is what is using it [21:09] xygnal: your saying your just using next-server ? === lutostag_ is now known as lutostag === mup_ is now known as mup [22:10] ltrager correct. Thats all I added. Worked for the first subnet, same exact syntax with another subnet selected from the dropdown, i get that error [22:18] whats the proper way to remove a node from the dhcp leases file [22:18] I see *6* copies of the lease for this box failing comission, I want to remove it without confusing MAAS [22:19] so that I can comission again 'clean' [22:20] xygnal: leases should be cleaned up for you [22:20] blake_r, mpontillo: ^? [22:23] xygnal: can you show me the error you are seeing, I havn't been able to reproduce it [22:24] xygnal: are you sure the lease is still active? the ISC lease file is like a transaction log, not a snapshot of current lease state [22:24] xygnal: the leases clean them self up, the dhcpd.leases file itself is append only so those leases will never go awat [22:24] that is how isc-dhcp works [22:24] but the ip address will go free after 10 minutes [22:27] gotcha [22:28] so you using dhcp relay [22:28] does your dhcpd.conf look correct? [22:29] I'm wondering if next-server can only be used once? [22:30] Its a per-subnet keyword [22:31] I can put it in global and it accepts it but somehow i imagine it doesnt work [22:31] we are using dhcp relay in that we have them forwarding DHCP requests from those subnets to our own server [22:31] xygnal: could you post the full error message your getting? [22:32] ltrager the full error was pasted above [22:32] xygnal can you post the maas generated dhcpd.conf and your dhcp relay config on the bug [22:32] blake: the one I just updated? [22:33] is commissioning getting the wrong IP or is it just deployment [22:33] yes the bug your commenting on [22:33] we apparently dont have any relay configured in MAAS itself. [22:33] I think we did not think we needed it [22:33] as all of the subnets are in the same fabric and vlan [22:34] and the forwarding of DHCP requests is being done via the router [22:35] if we need to have dhcp relay components beyond this enabled and configured, please point me to the info on it [22:35] so I can make sure we are doing that correctly [22:35] still want the config, or is my config 'invalid' the way we are using it? [22:36] yeah. the docs seem to reference relaying between VLANs, and we are not using VLANs [22:37] xygnal: you must tell MAAS which VLAN is the VLAN the traffic is being relayed to [22:37] all one fabric, one network interface, untagged, many subnets [22:37] there is no VLAN. All untagged. [22:38] xygnal: for example, browse to the VLAN with the helper address in the UI, and there should be a "Relay DHCP" command; you should use that to specify which VLAN on the rack receives the relayed DHCP traffic [22:39] xygnal: ... I'm confused then; how would the DHCP server know which network to provide the IP from if it's just a single flat network? [22:39] xygnal: yeah I am with mpontillo, if its flat the dhcp relay is not needed [22:39] thats why we didnt enable dhcp relay [22:40] xygnal: ok, maybe I was confused since your attachment on the bug was called "dhcp_relay.pdf" ;-) [22:40] yes... corey wrote that part [22:41] we forward the DHCP traffic from the routers of each subnet [22:41] so when the DHCP request comes in, it comes from the IP of that router [22:42] xygnal: yes, I understand that. but that still sounds a bit unconventional. so a host comes online and it broadcasts out a DHCP request. so all the routers on the network with a configured IP helper address are going to forward that DHCP request to MAAS. first one wins? [22:42] we had hoped that hte source address of the forward would be the clue DHCPD needed to know which subnet it should be [22:43] as the source address of the forward is aways the router for that subnet [22:43] but i'm guessing that does not work? is that an official it wont work? [22:43] need to be sure if we are going back to the drawing board [22:44] xygnal: you have indeed described how DHCP works, in general, but I do not believe it will work in that specific configuration you described, with multiple forwarders on the same L2 networks [22:44] *network [22:45] xygnal: what is going to happen is you will amplify the DHCP requests on that network segment and the DHCP server will see N request packets, where N is the number of routers configured with an IP helper address [22:45] wait wait [22:45] ok [22:45] so if i have multiple subnets listed in one fabric, which means all one shared-network entry in DHCPd.conf [22:46] it can't tell which host should go in which one? [22:46] is that BECAUSE of the forwarding on the switches that it is unable to tell? [22:46] xygnal: yeah; MAAS needs to know which networks are on with fabrics (and/or VLANs) it sounds like maybe you need to create multiple fabrics in MAAS [22:47] we tried multiple fabrics, and that allows comissions to pass, but then deployments failed to get a DHCP address at all and fails with Unconfigured for network [22:48] when digging on how you are supposed to do multiple subnets on the same interface, the shared-networks option in dhcpd,conf appeared to be the right syntax to use [22:48] xygnal: the fabrics in MAAS should match your network topology and you should browse to the untagged/default VLAN on each fabric and tell it which fabric on the rack controller the traffic is being relayed to [22:48] and one fabric = one shared-network in dhcpd.conf [22:48] xygnal: MAAS should configure that appropriately if the fabrics are modeled correctly [22:49] i'm a little confused on what correct configuration would be then [22:49] I thought relaying could not be used unless we had VLANs being used [22:50] so seperate subnets on the same untagged VLAN should be in seperate fabrics? [22:50] one per subnet? [22:53] xygnal: can you post a topology diagram of your network somehow? it's unclear to me exactly what you're doing. separate subnets on the same untagged VLAN is just fine, but I very much doubt that multiple DHCP relays on the same L2 segment will work in any scenario, MAAS or not [22:55] yes its the switch for each subnet that is forwarding [22:55] so each subnet has ONE forwarder [22:55] dedicated to that subnet [22:56] dont think I have a toplogy handy. I'll talk to Corey about that tomorrow to see if he alrady has something. [22:57] all of the switches are on VLAN500, but that is the 'native vlan', so no tagging is needed [22:57] native vlan, as in, on the cisco switch's settings [22:58] there should never be any forwarding by more than one switch for the same subnet [22:58] so i'm a little confused about how you think multiple forwarders is a problem there [23:03] xygnal: yes, if each L2 and each L3 subnet has one forwarder, that should be fine. I may have misunderstood one of your earlier statements. sounds like the issue is that each L2 needs to be modeled as a separate fabric in MAAS [23:04] these are all the same L2 then, no? Its L3 that is different subnet to subnet [23:07] ok i see [23:08] each subnet is a seperate [23:08] its own L2 vlan (port-tagged) [23:08] so we would need a fabric for each subnet then [23:08] yes? [23:09] we tried the separate fabric, and that got us past Comission failures, but thats when we started having Deploy failures that would fail with no network (Unmanaged) even though it had a network when we selected Deploy [23:09] we'll switch over the seperate Fabrics per L2 [23:10] gather data on the DEPLOY problem [23:10] and update the bug report [23:10] sound good? [23:21] xygnal: yeah, so each port-tagged subnet would be considered its own l2 and thus its own fabric, that's where you had me confused. in MAAS a VLAN on a fabric should be its own broadcast domain [23:24] xygnal: is each subnet configured on the same interface on the rack controller? I fear that might be throwing off MAAS too. [23:24] xygnal: because when MAAS looks at that network it may assume all those subnets are thus on the same L2, even if it's on the same L2 only on the rack controller? [23:33] Bug #1683909 changed: [2.2] Subnet changes during deployment