[00:35] <bdx> hey whats up guys
[00:37] <bdx> SOS https://imgur.com/a/2pm0g
[00:41] <bdx> here's the bug https://bugs.launchpad.net/maas/+bug/1724111
[00:41] <mup> Bug #1724111 opened: instances fail to enlist <MAAS:New> <https://launchpad.net/bugs/1724111>
[00:41] <bdx> roaksoax:^
[00:52] <bdx> possibly thats a cloud-init bug?
[00:52] <bdx> hmmm
[00:52] <bdx> sorry for blowing you up if it is
[00:52] <bdx> everyone
[02:28] <roaksoax> bdx: seems like the data source was not found
[02:29] <roaksoax> bdx: which could mean that the IP being given to use as a datasource, is not correct
[02:29] <roaksoax> bdx: check that /etc/maas/rackd.conf has a correct IP address the node can contact
[02:29] <bdx> I see
[02:29] <roaksoax> bdx: other than localhost
[02:31] <bdx> roaksoax: yeah ... so this is what I thought ... the pxe boot network isn't the same as the api/web endpoint network
[02:32] <bdx> possibly I can get access to the router/firewall and allow access between the pxe and mgmt nets
[02:34] <roaksoax> bdx: yeah as long as the machines can reach it, it should be good to go
[02:36] <bdx> yeah I knew the network that they were pxe booting on didn't have access to the network where the web_url lives, I guess I assumed the node would phone home on the same network it had pxe booted on, but yeah it makes sense, the api isn't listening there
[02:39] <roaksoax> bdx: yeah, the way it works is base don the IP the rack knows of the region
[02:44] <bdx> got it, that makes sense
[02:44] <bdx> roaksoax: thanks
[02:47] <mup> Bug #1724111 changed: instances fail to enlist <MAAS:Invalid> <https://launchpad.net/bugs/1724111>
[02:59] <bdx> roaksoax: is there anyway I can configure the snap to have a separate pxe net?
[03:17] <mup> Bug #1711760 opened: [2.3] resolv.conf is not set (during commissioning or testing) <MAAS:Fix Committed by andreserl> <cloud-init (Ubuntu):Confirmed> <resolvconf (Ubuntu):In Progress> <https://launchpad.net/bugs/1711760>
[07:47] <mup> Bug #1724155 opened: [2.3b1, UI] In the hardware test list, when a test doesn't have metrics remove the chevron <ui> <MAAS:New> <https://launchpad.net/bugs/1724155>
[08:14] <mup> Bug #1724158 opened: [2.3, UI] In hardware test list move the chevron to the end of the row to follow the pattern <ui> <MAAS:New> <https://launchpad.net/bugs/1724158>
[09:44] <mup> Bug #1724181 opened: maas-cli missing dependencies: netifaces, tempita <cpe-onsite> <maas (Ubuntu):New> <https://launchpad.net/bugs/1724181>
[09:53] <mup> Bug #1724181 changed: maas-cli missing dependencies: netifaces, tempita <cpe-onsite> <maas (Ubuntu):New> <https://launchpad.net/bugs/1724181>
[09:56] <mup> Bug #1724181 opened: maas-cli missing dependencies: netifaces, tempita <cpe-onsite> <maas (Ubuntu):New> <https://launchpad.net/bugs/1724181>
[12:41] <mup> Bug #1724235 opened: [2.3, HWTv2] Aborted test should not show as failure <MAAS:New> <https://launchpad.net/bugs/1724235>
[12:41] <mup> Bug #1724236 opened: not possible to restart a service while a browser session is open <MAAS:New> <https://launchpad.net/bugs/1724236>
[13:14] <mup> Bug #1724181 changed: maas-cli missing dependencies: netifaces, tempita <cpe-onsite> <MAAS:New> <MAAS 2.2:New> <https://launchpad.net/bugs/1724181>
[13:14] <mup> Bug #1724236 changed: not possible to restart a service while a browser session is open <MAAS:Invalid> <https://launchpad.net/bugs/1724236>
[13:14] <mup> Bug #1724181 opened: maas-cli missing dependencies: netifaces, tempita <cpe-onsite> <MAAS:New> <MAAS 2.2:New> <https://launchpad.net/bugs/1724181>
[14:12] <mup> Bug #1724252 opened: maas is unable to discover a bonded interface on a region controller if interfaces comprising it are 'disconnected' in the database and do not belong to a fabric <cpe-onsite> <MAAS:Triaged> <https://launchpad.net/bugs/1724252>
[15:43] <bdx> how can I assign a node to a zone?
[15:43] <bdx> is there a config in the ui somewhere, or do I need to use the api?
[15:44] <bdx> or cli
[15:51] <roaksoax> bdx: you can edit hte node and change the zone
[15:53] <bdx> roaksoax: really, excuse my blindness
[15:53] <bdx> omg
[15:53] <bdx> its the first param at the top
[15:54] <bdx> arrrggggg
[15:54] <bdx> roaksoax: thx
[15:55] <roaksoax> :)
[16:27] <TJ-> Is it possible to have Zone -> Sub-Zone hierarchy ?
[16:29] <roaksoax> TJ-: no
[16:31] <TJ-> Grrr. Can you suggest an alternative way I could design a deployment where I've got multiple power controllers and want 1 zone per controller, but want all the machines on those controllers to be part of a service-specific Zone too? Region seems not to be what I need since it runs a DB (which is elsewhere)
[16:32] <roaksoax> TJ-: you can use tags
[16:33] <TJ-> roaksoax: Aha. And they can be treated as groups for deploying, for example, HA, services ?
[16:36] <mup> Bug #1718016 changed: MAAS failed to respond to POST'd deploy request but still deployed node <cdo-qa> <cdo-qa-blocker> <foundations-engine> <internal> <MAAS:Invalid> <MAAS 2.2:Invalid> <https://launchpad.net/bugs/1718016>
[16:37] <roaksoax> TJ-: yeah, I would group per zone for HA services. e.g. 3 Zones (AZ's)
[16:38] <TJ-> roaksoax: it quickly gets to be a brain-twister, figuring out the logical relationships :)
[16:41] <TJ-> one other question if I may. Starting from scratch, a single machine that has the MAAS services aboard, is it possible later to bring that machine into the care of MAAS, or does that machine have to stay outside the managed machines? Maybe it's a 'device' rather than a 'machine' ?
[17:07] <roaksoax> TJ-: hehe, well, yeah the ZONES will be soon renamed to AZs to better clarify that they are availability zones. In that case, you will have machines in different zones for HA, and you can tag machines to sub-group them. e.g. 'storage' tags, and you will have machines with such tag across all zones for HA
[17:07] <roaksoax> TJ-: that's what we normally do
[17:08] <roaksoax> TJ-: on the latter question, what do you mean exactly?
[17:11] <TJ-> roaksoax: well, in a brand new deployment we need to boot-strap the MAAS installation. So we start with a virgin 16.04 server install, add MAAS (regiond and rackd) and configure. Then we start discovering devices/machines and so forth. Those are then managed/known by MAAS, but can MAAS be aware of its own regiond/rackd hosts
[17:12] <TJ-> roaksoax: in the power example, for example we have a CDU per rack, so if that's an AZ, a 'machine' on that CDU will have rackd. Does MAAS treat that machine differently to the machines 'under' it in the rack?
[17:13] <roaksoax> TJ-: MAAS will automatically make the machine a rack controller
[17:13] <roaksoax> TJ-: in 2.3, you could even deploy a rack controller yourself
[17:14] <roaksoax> TJ-: or if you deploy ubuntu on it yourself, and then you manually install a rack controller and point it to the same maas that deployed it, MAAS will automatically make that machine a rack controller
[17:14] <TJ-> That's the answer I was after, thanks
[17:14] <roaksoax> TJ-: what version of MAAS are you using though ?
[17:15] <TJ-> Not deployed yet so that's open to choice :)
[17:16] <TJ-> roaksoax: the question came about because I got to pondering the chicken-and-egg scenario of a completely new deploy of equipment
[17:18] <roaksoax> TJ-: well MAAS 2.3 already supports deploying rack controllers on its own
[17:18] <roaksoax> TJ-: however, it will use the snap instead of debian packages
[17:19] <roaksoax> TJ-: but you can use 2.2, which is the latest stable and if you install the rack yourself, maas will handle the transitition
[17:20] <TJ-> Thanks. Now I'm clearer now. After reading the Concepts and Terms and other Docs these questions weren't answered
[18:21] <mup> Bug #1724329 opened: curtin: Installation failed <MAAS:New> <https://launchpad.net/bugs/1724329>
[22:48] <mup> Bug #1724401 opened: cannot exit rescue mode <MAAS:New> <https://launchpad.net/bugs/1724401>
[23:12] <mup> Bug #1724402 opened: no output for failing test <MAAS:New> <https://launchpad.net/bugs/1724402>