[00:28] terje: cluster controllers/node-groups are deprecated in 2.0. Now we have "rack controllers" [00:49] Bug #1602468 opened: [1.9] loading initial data for maasserver: maas-region-admin reports duplicate key error during package install [01:10] Bug #1602477 opened: [2.0b1, UI] MAAS changes the order of DNS servers in the WebUI. [01:58] Bug #1602482 opened: [2.0rc2] Incorrect DNS records [02:07] Bug #1602486 opened: [2.0rc1] Rack controller filtering messages out of syslog doesn't work [02:07] Bug #1602487 opened: [2.0 RC1] Deploying node not powered on - Unable to change power state to 'on' for node krastin: another action is already in progress for that node. [02:22] Bug #1602486 changed: [2.0rc1] Rack controller filtering messages out of syslog doesn't work [02:22] Bug #1602487 changed: [2.0 RC1] Deploying node not powered on - Unable to change power state to 'on' for node krastin: another action is already in progress for that node. [02:28] Bug #1599523 opened: [SRU] MAAS 2.0rc2 to Xenial [02:28] Bug #1599523 changed: [SRU] MAAS 2.0rc2 to Xenial [02:28] Bug #1602486 opened: [2.0rc1] Rack controller filtering messages out of syslog doesn't work [02:28] Bug #1602487 opened: [2.0 RC1] Deploying node not powered on - Unable to change power state to 'on' for node krastin: another action is already in progress for that node. [02:28] Bug #1602488 opened: [2.1rc1] AMT: If I quickly deploy and quickly release a machine, it ends up powered on [02:34] Bug #1599523 changed: [SRU] MAAS 2.0rc2 to Xenial [02:34] Bug #1602488 changed: [2.1rc1] AMT: If I quickly deploy and quickly release a machine, it ends up powered on [02:34] Bug #1599523 opened: [SRU] MAAS 2.0rc2 to Xenial [02:37] Bug #1599523 opened: [SRU] MAAS 2.0rc2 to Xenial [02:37] Bug #1599523 changed: [SRU] MAAS 2.0rc2 to Xenial [02:37] Bug #1602488 opened: [2.1rc1] AMT: If I quickly deploy and quickly release a machine, it ends up powered on === CyberJacob is now known as zz_CyberJacob === zz_CyberJacob is now known as CyberJacob [13:23] Bug #1572340 changed: PXE boot fails when two interfaces are managed

[13:23] Bug #1591250 changed: 1.9.3 changelog information missing from maas.ubuntu.com/docs1.9/changelog.html [14:20] Bug #1599523 changed: [SRU] MAAS 2.0rc2 to Xenial [14:51] Bug #1602721 opened: [2.0rc2] Can't get node-results via cli/api [14:52] Anyone here using sstreams-mirror? [14:53] I'm trying to figure out how to get simplestreams to sync -both- amd64 and i386 in the same command. If I run them in two separate commands, passing each arch, the second pass wipes out the mirror ffrom the first pass [14:55] setuid: in the filter you'd do something like amd64|i386 or similar [14:55] can't remember of the top of my head [14:55] smoser: ^^ do you ? [14:56] setuid, 'arch~(i386|amd64)' [14:56] I've tried all of the obvious array expansions, without luck [14:56] you have to do regex. [14:56] hrm, ok... I'll give that one a shot. Tried , : space, and others... pipe it is! [14:56] its regex [14:56] i didn't write that. talk to larry wall i think [14:57] it was the simplist immediately powerful well defined operator [14:57] right, wasn't easy to find the parsing bit of simplestreams.py for what pcre they were using [14:57] one moment, giving that a shot now [14:59] Looks like its working... now if I could only do release and daily in the same pass but I'll add a second line for that [14:59] it's not picking up xenial, only precise and trusty, even though I see xenial in the repo I'm pointing to [15:00] https://images.maas.io/ephemeral-v2/daily/ [15:00] Bug #1602721 changed: [2.0rc2] Can't get node-results via cli/api [15:00] passing in: 'release~(xenial|trusty|precise)' [15:03] Bug #1602721 opened: [2.0rc2] Can't get node-results via cli/api [15:06] Bug #1602721 changed: [2.0rc2] Can't get node-results via cli/api [15:15] Bug #1602721 opened: [2.0rc2] Can't get node-results via cli/api [15:18] thansk roaksoax [15:18] I have an idea that I'm trying to persue. Just wish to vet it here. [15:19] I'm installing xenial on baremetal and installing maas there. Then, using uvtool, I'm creating an xenial VM, where I'd like to install juju-core. [15:20] and bootstrap that instance of juju to my instance of maas. [15:20] does this idea make sense or is there perhaps a better way to do that? [15:44] terje, functionally, they're different machines to juju, so it shouldn't ma... wait, you're going to use juju inside a maas-managed kvm instance, to update maas? [15:45] Why not use the baremetal and install maas in a kvm instance, then use a second kvm instance to run juju [15:45] that way, you can swap out your main maas kvm instance with another as needed for rolling upgrades/downgrades/updates/testing [15:46] If maas is installed on your baremetal box, you're locked in [15:46] Unless I misunderstood your goal [16:39] Bug #1594991 opened: [2.0RC1] MAAS displays every power query on the summarized view of node event log [17:12] smoser, Weird, I am trying to sync the daily images, but it's only getting trusty and precise, despite adding yakkety and xenial to the sstream command... and I can see them in the directory, so they ARE there [17:12] https://images.maas.io/ephemeral-v2/daily/xenial/ [17:12] command I'm using is: [17:12] sudo /usr/bin/sstream-mirror --keyring=/usr/share/keyrings/ubuntu-cloudimage-keyring.gpg https://images.maas.io/ephemeral-v2/daily/ /maas/images/ephemeral-v2/daily/ 'arch~(amd64)' 'subarch~(generic|hwe-t)' 'release~(yakkety|xenial)' --max=1 --verbose === mup_ is now known as mup [17:31] setuid, if you add a -v i think it will tell you that it filtered them out [17:31] but its filtering out becauase subarch is the "primary subarch" [17:31] subarches (plural) is a comma delimited list of subarches that are supported. [17:32] so actually, the easiest thing for you to do is to *drop* the subarch~ entirely [17:32] and it will dtrt [17:32] ah! [17:32] for both daily and releases, I bet... trying that now [17:33] Goes from 2.8Gb to 17Gb [18:13] setuid: ok, that's a good idea. [18:14] baremetal, +2 uvt-kvm instances (maas, juju) [18:15] only, uvt-kvm wants to use the 'default' network in libvirt (192.168.122/24). [18:16] so my maas server won't see the pxe requestws [18:16] so, prolly that's not going to work. :/ [19:30] Bug #1556137 changed: Juju 2.0: cannot connect to LXC container when deploying bundle with LXC container placement with maas 1.9.1 as provider <2.0-count>

[19:51] Bug #1556137 opened: Juju 2.0: cannot connect to LXC container when deploying bundle with LXC container placement with maas 1.9.1 as provider <2.0-count>

[19:54] Bug #1556137 changed: Juju 2.0: cannot connect to LXC container when deploying bundle with LXC container placement with maas 1.9.1 as provider <2.0-count>

[21:06] Hi smoser, I see you worked on this issue: https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1563296 [21:06] Is the fix still to add /etc/cloud/cloud.cfg.d/99-snappy-disable-network-config.cfg ? [21:06] even in xenial? [21:28] Bug #1602846 opened: 502 proxy errors after upgrading to MAAS 2.0 rc2 [21:28] Bug #1602848 opened: Spurious failure in test_get_hostname_ip_mapping_returns_fqdn_and_other [21:28] Bug #1602850 opened: Update Maas 2.0 Documentation to include the "maas-rack support-dump" feature [22:35] hi, where is the django controller for the api call that returns nodes interfaces to cloud-init for curtin? [23:37] Bug #1598358 opened: Node is started but not deployed