[00:37] <mup> Bug #1635097 changed: Can't assign SSH-Keys to user via maas-cli <MAAS:Invalid> <https://launchpad.net/bugs/1635097>
[00:49] <mup> Bug #1635097 opened: Can't assign SSH-Keys to user via maas-cli <MAAS:Invalid> <https://launchpad.net/bugs/1635097>
[00:55] <mup> Bug #1635097 changed: Can't assign SSH-Keys to user via maas-cli <MAAS:Invalid> <https://launchpad.net/bugs/1635097>
[03:11] <mup> Bug #1635493 opened: A wishlist to be able to destroy root filesystem after release <MAAS:New> <https://launchpad.net/bugs/1635493>
[07:08] <gaurangt> hi.. I've deployed MAAS in virtual environment and testing a charm.. but it is failing to use the storage disk which is already attached to the VM (though commissioning detected the disks properly).
[07:09] <gaurangt> I saw an error Error: /dev/sda: unrecognised disk label Error: /dev/sdb: unrecognised disk label
[07:09] <gaurangt> Any help would be really appreciated.
[08:51] <mup> Bug #1635560 opened: MAAS2: UnicodeDecodeError: 'ascii' codec can't decode byte 0xe2 in position 277: ordinal not in range(128) <canonical-bootstack> <MAAS:New> <https://launchpad.net/bugs/1635560>
[08:58] <gaurangt> anyone tried KVM + MAAS + Juju ?
[09:00] <mup> Bug #1635560 changed: MAAS2: UnicodeDecodeError: 'ascii' codec can't decode byte 0xe2 in position 277: ordinal not in range(128) <canonical-bootstack> <MAAS:New> <https://launchpad.net/bugs/1635560>
[09:03] <mup> Bug #1635560 opened: MAAS2: UnicodeDecodeError: 'ascii' codec can't decode byte 0xe2 in position 277: ordinal not in range(128) <canonical-bootstack> <MAAS:New> <https://launchpad.net/bugs/1635560>
[15:23] <mup> Bug #1635653 opened: Maas xenial dailies no longer able to deploy <MAAS:New> <maas-images:New> <https://launchpad.net/bugs/1635653>
[15:54] <Braven> hello all
[15:55] <Braven> I need help with setting up MAAS DNS setting for dhcp.
[16:39] <nturner> Are 2.1 updates going to be pushed to ppa:maas/stable?
[16:46] <brendand> nturner, it's in lp:maas/next
[16:46] <brendand> nturner, we could push it to stable as well i suppose
[16:57] <nturner> brendand: if one wanted to track 2.1 (vs. rolling on to 2.2alpha or whatever comes next), what's the best way?
[16:58] <nturner> also, is the fix for https://bugs.launchpad.net/maas/+bug/1632395 in maas/next?
[17:02] <brendand> nturner, maas/next is best. that will always be the latest development release
[17:02] <brendand> nturner, maas/stable is what's stable for that os version
[17:03] <nturner> brendand: so there's no way to track 2.1-stable on xenial?
[17:03] <brendand> nturner, the way to get 2.1 on xenial atm is to use next
[17:04] <nturner> tracking the dev version is great, but it could be nice to have one deployment that's tracking a stable release
[17:04] <brendand> nturner, and the bug is fixed in there
[17:04] <nturner> 2.1 seems pretty solid right now, but during the alpha phase, there was some breakage
[17:04] <nturner> presumably that will happen again during the next dev cycle
[17:05] <brendand> nturner, indeed
[17:05] <nturner> so if i want to maintain a deployment that tracks 2.1, I should upgrade to yakkety and track maas/stable it sounds
[17:05] <nturner> like.
[17:09] <brendand> nturner, well stable is defined as 'what's stable for that os'
[17:09] <brendand> eventually 2.1 will be backported to xenial, but for now it's only considered stable on yakkety
[17:09] <brendand> and it's not in that ppa yet
[17:09] <brendand> i say os, i mean release
[17:11] <brendand> so yeah, for now if you want a deployment using 2.1 that is stable your only choice is to just use yakkety straight up
[17:12] <brendand> no ppa
[17:15] <nturner> brendand: ok, that's cool
[17:18] <suchvenu> Hi
[17:19] <suchvenu> I am trying to deploy Openstack charm from the store : https://jujucharms.com/openstack-base/
[17:20] <suchvenu> I have a KVM and MAAS is configured in one guest from that box. Juju is installed and could deploy a sample charm as well.
[17:20] <suchvenu> However when i deploy Openstack charm from store I get "Failed deployment" as the status
[17:21] <suchvenu> The MAAS log ahows as :
[17:21] <suchvenu> Oct 20 15:38:32 maascontroller maas.node: [INFO] vm3: Status transition from DEPLOYING to FAILED_DEPLOYMENT Oct 20 15:38:32 maascontroller maas.node: [ERROR] vm3: Marking node failed: Node operation 'Deploying' timed out after 0:40:00. Oct 20 15:38:37 maascontroller maas.node: [INFO] vm4: Status transition from DEPLOYING to FAILED_DEPLOYMENT
[17:22] <suchvenu> Any idea on this error ? Will increasing the timeout fix the issue ?
[18:09] <swjen> hi! does any know why machines wont show up in MAAS after PXE boot? I am running MAAS 2.0 on bare metal and trying to "enlist" another bare metal machine. both are on the same vlan.
[18:30] <deej> Hey all, I'm running into an issue with MaaS 1.9 where nodes are getting an IP set up properly in DNS, but then getting a totally different IP via DHCP
[18:30] <deej> And I'm not sure where that DHCP IP is coming from or how to get rid of it, it only seems to happen occasionally
[18:30] <deej> Has anyone seen that before and/or can point me in the direction of how to get that extraneous IP out of the node definition?
[20:13] <pmatulis> what exactly does the 'abort' node action do again?
[20:15] <deej> pmatulis: Aborts a ongoing action, i.e. commissioning/deploying
[20:16] <pmatulis> deej, does it apply to any action?
[20:16] <deej> I assume so
[20:16] <deej> I actually don't know for sure
[20:17] <pmatulis> deej, ok
[22:04] <mup> Bug #1635735 opened: MaaS 1.9 not deleting discovered addresses from commissioning <MAAS:New> <https://launchpad.net/bugs/1635735>
=== LoRez is now known as Guest93096