[01:45] <mup> Bug #1674864 opened: MAAS deployment failed due to data source user-data 500 Internal Server Error, after using set default gateway <MAAS:New> <https://launchpad.net/bugs/1674864>
[02:45] <mup> Bug #1674864 changed: MAAS deployment failed due to data source user-data 500 Internal Server Error, after using set default gateway <MAAS:New> <https://launchpad.net/bugs/1674864>
[02:45] <mup> Bug #1674866 opened: Default gateway (per-subnet) should have a metric value <MAAS:New> <https://launchpad.net/bugs/1674866>
[08:58] <Tim_> Hello
[11:07] <bryanb229> is there anyone active in this channel?
[11:08] <bryanb229> ive logged in multiple time and see people online but no one ever types any messages
[11:09] <brendand> bryanb229, it's active
[11:09] <brendand> some times are quieter than others
[11:18] <mup> Bug #1674959 opened: [UI] Close Add Pod button is redundant on pods page <MAAS:New> <https://launchpad.net/bugs/1674959>
[11:48] <mup> Bug #1674959 changed: [UI] Close Add Pod button is redundant on pods page <ui> <ux> <MAAS:Opinion> <https://launchpad.net/bugs/1674959>
[12:00] <mup> Bug #1674959 opened: [UI] Close Add Pod button is redundant on pods page <ui> <ux> <MAAS:Opinion> <https://launchpad.net/bugs/1674959>
[12:03] <mup> Bug #1674959 changed: [UI] Close Add Pod button is redundant on pods page <ui> <ux> <MAAS:Opinion> <https://launchpad.net/bugs/1674959>
[12:52] <mup> Bug #1674991 opened: [2.1] Cannot skip 2nd stage of intro config journey <MAAS:Incomplete> <https://launchpad.net/bugs/1674991>
[13:04] <mup> Bug #1674991 changed: [2.1] Cannot skip 2nd stage of intro config journey <MAAS:Incomplete> <https://launchpad.net/bugs/1674991>
[13:43] <mup> Bug #1675017 opened: [CLI] interface link-subnet command cannot refer to interface by device name <MAAS:New> <https://launchpad.net/bugs/1675017>
[13:49] <mup> Bug #1675017 changed: [CLI] interface link-subnet command cannot refer to interface by device name <MAAS:New> <https://launchpad.net/bugs/1675017>
[13:58] <mup> Bug #1675017 opened: [CLI] interface link-subnet command cannot refer to interface by device name <MAAS:New> <https://launchpad.net/bugs/1675017>
[14:46] <mup> Bug #1670499 changed: maas 2.1.3 nodes do not deploy, Juju reports 'started but not deployed' <cdo-qa> <cdo-qa-blocker> <juju:Invalid> <MAAS:Incomplete> <https://launchpad.net/bugs/1670499>
[14:46] <mup> Bug #1671605 changed: Unbootable system after installation <cdo-qa-blocker> <curtin:Invalid> <MAAS:Incomplete> <https://launchpad.net/bugs/1671605>
[14:46] <mup> Bug #1673726 changed: scsi ids with vmware are not correctly used <MAAS:Incomplete> <https://launchpad.net/bugs/1673726>
[16:07] <dfin> Hello all, is there a way to debug the commissioning process in 2.1? I've been stuck for a couple days and about to call it quits :/
[16:09] <pmatulis> dfin, logs are a good place to start
[16:09] <dfin> Right, but I can't log in to the commissioned machine and I couldn't get the backdoor hack to work
[16:10] <dfin> Specifcially, I can see in the MAAS logs that the initial PXE is going well, but the node  I'm trying to provision just sits there at a login prompt
[16:11] <pmatulis> dfin, and the web UI says 'Commissioning failed'?
[16:11] <dfin> yes, after it hits the 20 min timout
[16:12] <pmatulis> dfin, what kind of machine is powering the node? bare-metal, virtual
[16:13] <dfin> BM - Dell 6730xd
[16:13] <dfin> *r730
[16:15] <dfin> MAAS itself is in a VMware cluster on the same vlan
[16:15] <pmatulis> dfin, what power type was chosen?
[16:15] <dfin> IPMI 2, which is working
[16:16] <dfin> At least, it powers on the machine
[16:16] <dfin> and I can make it power the machine off via the web ui
[16:17] <ybaumy> when will the maas patch released into beta release for the disk boot order
[16:18] <ybaumy> there is a patch available and i need it
[16:18] <ybaumy> https://bugs.launchpad.net/maas/+bug/1673724
[16:19] <pmatulis> dfin, any firmware updates available for the BMC?
[16:20] <dfin> pmatulis: I don't think so - let me check
[16:21] <dfin> pmatulis: I am on the latest firmware version
[16:24] <dfin> I _suspect_ that something is up with the scripts run on squashfs, but I can't get in there to check. Just a suspicion though...
[16:30] <pmatulis> dfin, i'm sorry i don't know what else i can add. hopefully someone else here can chime in. i wouldn't give up just yet though. there's a good reason why it's not working
[16:30] <pmatulis> dfin, do you have other machines that work?
[16:30] <dfin> pmatulis: no, this is the pilot machine
[16:30] <pmatulis> dfin, maybe try a quick KVM-backed or VMware-backed node
[16:31] <pmatulis> to see if there's a wider problem
[16:31] <dfin> I'll do that
[16:37] <dfin> pmatulis: whatever the case, thanks for your help
[16:40] <dfin> yeah, same thing with a VMware node. I'll see if it times out
[16:40] <pmatulis> is DNS working? pretty sure commissioning requires it
[16:42] <dfin> DNS is what way. Like the MAAS DNS?
[16:42] <dfin> I have a working DNS server for our internal domains
[16:44] <pmatulis> nodes should be able to contact the internet and have DNS working. network-wise. i'll be back later
[16:44] <dfin> sure
[16:46] <pmatulis> check the proxy logs during commissioning. you should see requests go out
[16:46] <pmatulis> i'm pretty sure
[16:51] <ybaumy> is someone from the devs here?
[16:52] <zeestrat> ybaumy: Yes, though they might be out due to different TZ.
[16:53] <ybaumy> zeestrat: i need a patch for maas beta applied
[16:53] <ybaumy> https://bugs.launchpad.net/maas/+bug/1673724
[16:54] <ybaumy> when can i expect a release for this
[16:55] <brendand> ybaumy, that's going to be in the next release, out soon
[16:56] <ybaumy> brendand: thats great to hear because its really important. would i get that earlier if i had a support aggreement with canonical?
[17:05] <brendand> ybaumy, if you're willing to use a ppa you can get it now but would have to accept that it hasn't been tested fully yet
[17:09] <ybaumy> brendand: im using devel
[17:09] <brendand> ybaumy, which ppa?
[17:10] <ybaumy> brendand: http://ppa.launchpad.net/maas/next/ubuntu xenial main
[17:13] <mup> Bug #1675095 opened: [2.2] MAAS selecting the incorrect NTP server for deployed machines <MAAS:Triaged> <https://launchpad.net/bugs/1675095>
[17:29] <cnf> jamespage: ii'll ask here, if i delete NICs in maas, can i get them back later without knowing the MAC addresses?
[18:37] <mup> Bug #1675123 opened: [2.2, UI] Interfaces UI shows two items for the subnet <MAAS:Triaged> <https://launchpad.net/bugs/1675123>
[18:46] <mup> Bug #1675123 changed: [2.2, UI] Interfaces UI shows two items for the subnet <MAAS:Triaged> <https://launchpad.net/bugs/1675123>
[18:58] <mup> Bug #1675123 opened: [2.2, UI] Interfaces UI shows two items for the subnet <MAAS:Triaged> <https://launchpad.net/bugs/1675123>
[20:49] <smgoller> Does anyone have any experience deploying coreos with maas?
[21:10] <mup> Bug #1675123 changed: [2.2, UI] Interfaces UI shows two items for the subnet <MAAS:Triaged> <https://launchpad.net/bugs/1675123>
[21:36] <roaksoax> smgoller: maas doesn't support coreos
[21:42] <smgoller> roaksoax: thanks
[21:43] <smgoller> so I notice when juju creates containers on machines it allocates via maas, the containers show up on the maas node details page. Is there a way to manage that outside of juju?
[21:43] <smgoller> I guess the simple question is, if I create lxd containers on maas-deployed machines, will they show up?
[21:51] <roaksoax> smgoller: if you register them in MAAS they would
[21:51] <roaksoax> smgoller: what juju does is basically "
[21:51] <roaksoax> "hey maas, register this container that I've just created and give it an static IP address"
[21:52] <roaksoax> smgoller: and maas adds a container, and using the mac it provides it an "static" IP address that's delivered by DHCP (or juju configures it statically)
[21:52] <roaksoax> if that makes sense
[21:52] <smgoller> so maas is doing the actual container creation
[21:53] <smgoller> er
[21:53] <smgoller> sorry
[21:53]  * smgoller goes to look at the juju maas drivers
[21:53] <roaksoax> smgoller: juju is doing the container creation and telling MAAS about the existance of the container
[21:54] <smgoller> right
[21:56] <smgoller> any info on how juju tells maas about the container?
[21:57] <roaksoax> smgoller: it just makes a API call. I'd think it adds a device with a parent
[21:57] <roaksoax> smgoller: and then asks for an IP with link-subnet
[22:22] <xygnal> I have two subbnets on the same untagged fabric.  Although deploying works fine giving it the right auto-assigned address,  comission fails because it picks an dynamic IP in the opposite subnet than its in
[22:22] <xygnal> the result is that it gets its DHCP response and address during comission, but it cannot connect, because its the wrong address for that subnet
[22:23] <xygnal> I am I running into limitations, or bugs?
[22:36] <xygnal> looks like it might have worked when I seperated that second subnet into its own fabric
[22:47] <Fl1nt> Good evening everyone!
[22:49] <Fl1nt> Quick question, what kind of "scripts" the commissioning scripts can be? As they seems to be launched by cloud-init, I would say nearly anyone but I need to be sure as I want to use it to manage the Hardware RAID configuration.
[23:03] <Fl1nt> anyone?