=== menn0 is now known as menn0-afk
[04:22] <mup> Bug # changed: 1621563, 1633181, 1636933, 1638380, 1651683, 1652566, 1652649
[04:37] <mup> Bug # opened: 1621563, 1633181, 1636933, 1638380, 1651683, 1652566, 1652649
[04:46] <mup> Bug # changed: 1621563, 1633181, 1636933, 1638380, 1651683, 1652566, 1652649
[06:20] <firl> anyone have any ideas why my vlan doesn't seem to be tagging on my bonded interface?
[06:22] <firl> "/etc/network/interfaces" has no tagging at all in the interface just the bonded configuration
[07:17] <mup> Bug #1672327 opened: Too long names for bridges <juju:New> <MAAS:New> <https://launchpad.net/bugs/1672327>
[11:08] <mup> Bug #1672676 opened: proxy_update_config.write_config is transactional but mutates non-database state <easy-to-fix> <txn-violation> <MAAS:Triaged> <https://launchpad.net/bugs/1672676>
[12:15] <kklimonda> I've created a reserved range for the subnet, but juju is still creating new containers from within this range. Is this not related? MAAS 2.2b2
[13:30] <hetfield_> hi all. i need a trigger to update an external dns when a lxc rises (i.e. by maas)
[13:30] <hetfield_> ops i meant juju
[13:35] <mup> Bug #1672718 opened: [2.2b3] smartctl-validate hangs on KVM-backed nodes <docteam> <hardware-testing> <MAAS:Triaged> <https://launchpad.net/bugs/1672718>
[13:46] <vogelc> pmatulis: I just wanted to get back to you and say that the dhcp relay function is working like a charm.
[13:55] <kklimonda> MAAS is actually also assigning IPs from the reserved range..
[14:02] <kklimonda> seems very similar to https://bugs.launchpad.net/maas/+bug/1314267
[14:02] <roaksoax> kklimonda: is there a bug filed for this ? do you have any other ranges created ?  are there no more available IP addresses ?are you using juju with a user and the range created belongs to the 'user' ?
[14:03] <kklimonda> the last question, about juju, is actually interesting
[14:03] <kklimonda> about juju user*
[14:04] <kklimonda> but I'm not sure if I follow - other juju users would ignore my IP reservation?
[14:04] <kklimonda> there is no bug, so far I don't have enough to go on and report it - I just started looking into it
[14:05] <roaksoax> kklimonda: just trying to gather info
[14:06] <kklimonda> ok, let me check credentials for juju first, to see if that's the same user
[14:06] <roaksoax> it would be interesting to know whether the reserved range is a reserved for user 'alice', and user alice is juju deploying, hence containers may be getting IP's frrom 'alice' range
[14:07] <kklimonda> it's the same user for both juju and MAAS
[14:07] <roaksoax> but if reserved range is for admin 'bob', and 'alice' user is deploying, and gets IP from 'bob' range, then that wold definitely be bad
[14:07] <kklimonda> however, those IPs were previously available, and I've only later expanded reservations
[14:07] <kklimonda> so I wonder if they are still cached somewhere, perhaps dhcpd.leases
[14:08] <kklimonda> but that part actually works as expected, I have a dynamic range for machines. How does Juju get an IP from MAAS? is it querying API?
[14:10] <roaksoax> kklimonda: juju asks maas for a machine that it can statically assign to the container
[14:10] <roaksoax> kklimonda: so it is one of two things: 1. juju requesting an IP from a <reserved> range or 2. maas providing an ip from a <reserved> range
[14:11] <roaksoax> it would be interesting to see what request juju sends
[14:11] <pmatulis> vogelc, thank you. nothing to improve in the docs?
[14:18] <kklimonda> roaksoax: how can I check it? juju controller logs, or maas logs?
[14:30] <vogelc> pmatulis: I think the docs are fine.  The capability is really going to save us time.
[14:35] <roaksoax> kklimonda: juju controller debug logs I'd guess
[14:38] <mup> Bug #1672735 opened: TimeoutError resolving DNS <MAAS:Triaged> <https://launchpad.net/bugs/1672735>
[14:59] <zeestrat> Hey, is there a way to choose which distro rescue mode boots as?
[15:00] <roaksoax> zeestrat: no, only Ubuntu
[15:00] <zeestrat> roaksoax: Sorry, was thinking more which version of Ubuntu
[15:00] <roaksoax> zeestrat: only xenial
[15:01] <roaksoax> zeestrat: the "commissioning" image
[15:01] <zeestrat> :(
[15:04] <brendand> zeestrat, you can change the minimum kernel version though
[15:09] <zeestrat> Alrighty. Thanks
[15:20] <mup> Bug #1672758 opened: Quanta S910-X31E system drilbur fails curtin installation - grub-install: error: will not proceed with blocklists. failed to install grub! <oil> <curtin:New> <MAAS:New> <https://launchpad.net/bugs/1672758>
[15:30] <mup> Bug #1672758 changed: Quanta S910-X31E system drilbur fails curtin installation - grub-install: error: will not proceed with blocklists. failed to install grub! <oil> <curtin:New> <MAAS:New> <https://launchpad.net/bugs/1672758>
[15:33] <stormmore> zeestrat, I am guessing there is a reason why you would ask about the rescue "image"?
[15:35] <zeestrat> stormmore: Just doing some dumb troubleshooting for a vendor who only supply utilities for trusty. But I made it work :)
[15:38] <stormmore> ah one of those situations
[15:38] <stormmore> that is why I start looking for a vendor who keeps up to date
[15:38] <stormmore> when*
[15:39] <mup> Bug #1672758 opened: Quanta S910-X31E system drilbur fails curtin installation - grub-install: error: will not proceed with blocklists. failed to install grub! <oil> <curtin:New> <MAAS:New> <https://launchpad.net/bugs/1672758>
[15:39] <zeestrat> stormmore: Yeah, you get what you pay for. Luckily we have lots of spares.
[15:42] <stormmore> zeestrat, good :) sounds like you might need them ;-) although if you have physical access you could always boot from a trusty live cd for the troubleshooting
[15:49] <zeestrat> stormmore: For those few moments we pxe boot or use the BMC. Just wanted to try out the rescue mode :) Looking forward to the new HW tests in the 2.2 beta
[15:50] <stormmore> zeestrat, legacy pxe environment ftw then?
[15:52] <zeestrat> stormmore: In this instance I managed to get the trusty package to work on xenial
[15:54] <stormmore> yeah that is also an option, depends what it actually uses from the OS. I vaguely remember installing a "jessie" package recently on to xenial
[16:30] <mup> Bug #1672758 changed: Quanta S910-X31E system drilbur fails curtin installation - grub-install: error: will not proceed with blocklists. failed to install grub! <oil> <curtin:Invalid> <MAAS:Invalid> <https://launchpad.net/bugs/1672758>
[16:33] <mup> Bug #1672758 opened: Quanta S910-X31E system drilbur fails curtin installation - grub-install: error: will not proceed with blocklists. failed to install grub! <oil> <curtin:Invalid> <MAAS:Invalid> <https://launchpad.net/bugs/1672758>
[16:45] <mup> Bug #1672758 changed: Quanta S910-X31E system drilbur fails curtin installation - grub-install: error: will not proceed with blocklists. failed to install grub! <oil> <curtin:Invalid> <MAAS:Invalid> <https://launchpad.net/bugs/1672758>
[17:49] <rainmaker> Hi all. I don't get it. I can power on and off a server from the BMC via MAAS, but when I try to commission it, it will fail with 'failed commissioning'. I get error "BMC busy". Anyone has any idea?
[17:49] <roaksoax> rainmaker: the bmc is probably locking up
[17:52] <rainmaker> locking up?
[17:54] <roaksoax> rainmaker: as in the BMC is not reliable enough and when it receives multiple requests it locks up
[17:54] <roaksoax> rainmaker: this is a common firmware issue
[17:55] <rainmaker> do you think upgrading the fw will help?
[17:57] <roaksoax> rainmaker: it definitely should, yes
[17:57] <roaksoax> rainmaker: the times we've seen the issue upgrading to a newerl firmware has usually solved the problem
[17:58] <kklimonda> has anyone worked on coreos deployment with maas?
[17:58] <rainmaker> thank you roaksoax
[18:32] <tmartins> Hey guys, I just installed MaaS Next on Ubuntu 16.04, the rackd.log shows something like: "Deferred AppCleanUp" Python error, what is that?
[18:33] <tmartins> Also, after installing "apt install maas", the package "maas-cluster-controller" was not installed, it depends on old maas-cli, maybe it is not required anymore?
[18:35] <roaksoax> tmartins: maas-rack-controller replaces maas-cluster-controller
[18:35] <roaksoax> tmartins: maas-cli -> 'maas'
[18:37] <tmartins> Oh, nice... Thank you!
[18:38] <tmartins> What about the "rackd.log" python error?
[18:45] <pmatulis> tmartins, are you following instructions that refer to maas-cluster-controller and maas-cli? if so, which docs?
[18:47] <tmartins> basically, I did this: 1- fresh ubuntu 16.04 with 2 NIC (MaaS UI ens3 / PXE on top of ens3.500), 2- add maas/next ppa, 3- apt install maas, 4- dpkg-reconfigure maas-region-controller, 5- maas-region createadmin
[18:47] <tmartins> that's pretty much what I did...
[18:47] <tmartins> using this as a base: https://insights.ubuntu.com/2016/01/23/maas-setup-deploying-openstack-on-maas-1-9-with-juju/
[18:47] <tmartins> didn't tryed Juju yet.
[18:49] <tmartins> Also I used tips from: https://docs.ubuntu.com/maas/2.1/en/installconfig-package-install ...
[18:53] <pmatulis> tmartins, ok, you're mixing versions. try to eschew 1.9 unless you absolutely need to run Trusty
[18:54] <tmartins> I don't think that I am mixing versions...  =/
[18:54] <tmartins> I just used those docs as a "bird view reference".
[18:55] <tmartins> The MaaS packages are all from the PPA MaaS Next.
[18:56] <pmatulis> tmartins, right, i meant from the docs POV
[18:58] <tmartins> Hmm... Okay, I'll research more on this subject... Maybe I'll downgrade to MaaS Stable, since I'm not seeing much difference to Next.
[18:59] <tmartins> Does MaaS talks with Dell's CMC (Chassis Management)?
[19:02] <roaksoax> lborda: yeah you are using 2.x, so use the instructions provided by pmatulis
[19:03] <mup> Bug #1672837 opened: [2.2b3] When adding an RSD pod, the action panel doesn't disappear until pod refreshed <rsd> <MAAS:Triaged> <https://launchpad.net/bugs/1672837>
[19:03] <mup> Bug #1672839 opened: [2.2b3] Refreshing a pod from the pod details page should show a spinner in the listing <rsd> <MAAS:New> <https://launchpad.net/bugs/1672839>
[19:03] <mup> Bug #1672841 opened: [UI] Pod refresh shows error <rsd> <MAAS:Confirmed> <MAAS RSD :Confirmed> <https://launchpad.net/bugs/1672841>
[19:06] <mup> Bug #1672837 changed: [2.2b3] When adding an RSD pod, the action panel doesn't disappear until pod refreshed <rsd> <MAAS:Triaged> <https://launchpad.net/bugs/1672837>
[19:06] <mup> Bug #1672839 changed: [2.2b3] Refreshing a pod from the pod details page should show a spinner in the listing <rsd> <MAAS:New> <https://launchpad.net/bugs/1672839>
[19:06] <mup> Bug #1672841 changed: [UI] Pod refresh shows error <rsd> <MAAS:Confirmed> <MAAS RSD :Confirmed> <https://launchpad.net/bugs/1672841>
[19:12] <tmartins> pmatulis, can you share a link do new docs?
[19:12] <mup> Bug #1672837 opened: [2.2b3] When adding an RSD pod, the action panel doesn't disappear until pod refreshed <rsd> <MAAS:Triaged> <https://launchpad.net/bugs/1672837>
[19:12] <mup> Bug #1672839 opened: [2.2b3] Refreshing a pod from the pod details page should show a spinner in the listing <rsd> <MAAS:New> <https://launchpad.net/bugs/1672839>
[19:12] <mup> Bug #1672841 opened: [UI] Pod refresh shows error <rsd> <MAAS:Confirmed> <MAAS RSD :Confirmed> <https://launchpad.net/bugs/1672841>
[19:15] <pmatulis> tmartins, the 2.1 you followed are the ones you should follow. 'devel' if you're using ppa:maas/next
[19:25] <tmartins> Ok, thanks!
[19:28] <pmatulis> tmartins, note that the devel docs are not guaranteed to be up to date
[19:28] <tmartins> That's okay...   =)
[19:29] <tmartins> There is only MaaS' feature that I don't like: it is the gateway of the bare-metal hosts by default. And it is hard to change that...   :-/
[19:30] <tmartins> If I change this, bare-metal cloud-init doesn't work anymore (it can't reach metadata service).
[19:32] <vogelc> Does anyone have a handy cli command to update a node to use static IP's?
[19:36] <pmatulis> roaksoax, can you update the mailing list in the topic please - https://lists.ubuntu.com/mailman/listinfo/maas-devel
[19:40] <tmartins> Does the PXE boot stuff works on top of VLAN tagged interfaces, like "eth1.500"?
=== menn0-afk is now known as menn0