[00:54] <mup> Bug #1628331 opened: 21a4:Unhandled failure during AMP request <cdo-qa> <MAAS:New> <https://launchpad.net/bugs/1628331>
[01:03] <mup> Bug #1628331 changed: 21a4:Unhandled failure during AMP request <cdo-qa> <MAAS:New> <https://launchpad.net/bugs/1628331>
[01:09] <mup> Bug #1628331 opened: 21a4:Unhandled failure during AMP request <cdo-qa> <MAAS:New> <https://launchpad.net/bugs/1628331>
[01:09] <mup> Bug #1628333 opened: 2.1a4:rackd.log reports Permission denied: /etc/maas/rackd.conf <cdo-qa> <MAAS:New> <https://launchpad.net/bugs/1628333>
[01:15] <mup> Bug #1628333 changed: 2.1a4:rackd.log reports Permission denied: /etc/maas/rackd.conf <cdo-qa> <MAAS:New> <https://launchpad.net/bugs/1628333>
[01:24] <mup> Bug #1628333 opened: 2.1a4:rackd.log reports Permission denied: /etc/maas/rackd.conf <cdo-qa> <MAAS:New> <https://launchpad.net/bugs/1628333>
[01:24] <mup> Bug #1628338 opened: 2.1a4:syslog flooded with whoami requests <cdo-qa> <MAAS:New> <https://launchpad.net/bugs/1628338>
[08:11] <herb64> Hi all, using MAAS deploying KVM domains. Enlistment: OK, Commissioning: OK, But deployment fails, if using the interface set to "auto-assign"
[08:13] <herb64> Deployment works with interface set to "DHCP" or "Static assign"
[08:15] <herb64> With "auto-assign" the node hangs, because it does not get an IP. tcpdump shows, that MAAS sends TWO offers: first the one with first address from "auto-assign" range, the second with the IP from dynamic range used during enlistment/commissioning
[08:16] <herb64> the node then requests the second one and gets back a DHCPNAK... now hanging
[08:16] <herb64> any ideas or known bugs?
[08:16] <herb64> using MAAS 2.0.0+bzr5189-0ubuntu1
[08:18] <herb64> for me ,it looks like MAAS has a bug, that causes the second offer to be sent out, although the first one should only be sent
[11:58] <hbogert> hi all
[11:59] <hbogert> I've just installed MAAS and it the provisioning of a VPS on proxmox went well, however, after commission, restarting the vps reboots and pxe is still serving and reinstalling the VPS
[11:59] <hbogert> is this intended behaviour?
[12:22] <hbogert> nvm my question I misunderstood what 'commission' meant. Though what does the 'acquire' status mean?
[12:36] <zeestrat> hbogert1: Someone probably has a more accurate description, however I believe acquiring a node simply reserves it for that specific user.
[13:03] <hbogert1> zeestrat: thanks
[13:06] <hbogert1> What does reserving a network range actually mean? Does it mean it is allowed for MAAS to actually use those IPs for static IP configuration. Or does it mean it should NOT use IPs in that range? Either way, currently the webui does not prohibit me from using IPs either in a reserved range, or not in a reserved range.
[13:18] <zeestrat> hbogert1: I think it just reserves a range so MAAS won't allocate those IP's when commisioning and deploying nodes with an interface set to auto assign.
[13:32] <mup> Bug #1628514 opened: the docs link in the footer of maas.io links to different docs than the docs link in header <MAAS:New> <https://launchpad.net/bugs/1628514>
[13:50] <hbogert1> zeestrat: thanks again, that's probably it, I'll check
[14:12] <rock__> roaksoax: Hi. From MAAS UI, If we select a node and click on "Acquire" then what will happen to the node?
[14:16] <roaksoax> rock__: it will be "owned" by whomever acquires it
[14:17] <rock__> roaksoax: OK. Thank you.
[14:18] <rock__> roaksoax: How can we integrate MAAS with other technologies?
[14:19] <rock__> roaksoax: And MAAS will manage only ubuntu certified servers?
[14:20] <rock__> roaksoax: Will MAAS check for Ubuntu certification of the server?
[14:21] <roaksoax> rock__: maas cna manage non-certified ubuntu hardware provided they follow standards the same way as certified
[14:22] <roaksoax> rock__: define integrate other technologies
[14:23] <rock__> roaksoax: where exactly we need to define and how to integrate them. Do we have any procedure for that?
[14:37] <roaksoax> rock__: you woulf probably need custom engineering if you want to integrate with other technologies
[14:37] <roaksoax> rock__: or if other software wants to tak to maas, it could do it via the API
[14:38] <rock__> roaksoax: Hmmm. Thanks.
[14:38] <rock__> roaksoax: How can we explain others about MAAS networking in a better way? For people who don't know about MAAS.
[14:42] <mup> Bug #1628547 opened: [2.1 ipv6] omshell seems to hate ipv6 sometimes <maas-ipv6> <MAAS:New> <https://launchpad.net/bugs/1628547>
[14:51] <roaksoax> rock__: depends on what you want to do. If you want MAAS to say, do things wiht other software it doesn't currently do, then you need custom engineering. If you want other tehcnology use MAAS as a backend, then you could use the MAAS api, but really depends on what you are looking for
[14:52] <roaksoax> rock__: what would you like to explain ? The documentation follow a good overview of MAAS networking, which largely matches conventional terms (other than probbaly spaces)
[14:54] <rock__> roaksoax: Actually, I have a little experience with MAAS. I did openstack autopilot setup using MAAS  and MAAS + openstack base bundle setup. Got some good knowledge on MAAS with your help and other community guys help.
[14:55] <rock__> roaksoax: We want to have "stack meetup" Event every week friday at our office.
[14:56] <rock__> roaksoax: This friday i want to present MAAS [Metal as a service] to my collegues.
[14:56] <roaksoax> rock__: http://maas.io/docs/intro-concepts
[14:58] <rock__> roaksoax: OK. thank you.
[15:03] <rock__> roaksoax: From MAAS UI, I will select one node and then I will do first "mark broken" next I will do "Mark fixed" Then that node functionality will come back (or) go away.
[15:10] <roaksoax> rock__: mark broken sets the node that it was broken
[15:10] <roaksoax> mark fixed will move it to a state
[15:10] <roaksoax> that was previously or a state that needs action
[15:10] <roaksoax> for example, you may need to commission your node again
[15:18] <rock__> roaksoax: Oh. thank you. For example,
[15:19] <rock__> I have an Openstack-autopilot setup. If I take one node and released it. Then we can't fetch it back as it is right ?
[18:24] <maxiepax> Hi Everyone! I've been reading through the network documentation to see if we can use maas at work, however one thing still puzzles me. If we have different departments, who are used to being on different VLANs, then settings physical network ports to trunk, and then configuring the OS network interface to account for tagged vlan traffic works. However, nothing is preventing the user to swap VLAN and gain access to networks where th
[18:26] <maxiepax> i havn't been able to see if there is any orchestration available to allocate physical machines onto a VLAN by orchestrating the physical network? Did i miss something? or is the default simply to have racks in seperate L2's and route them, or by using trunk for Vlans (unsecure in one way)?
[18:26] <maxiepax> If it's the later, i do see one solution to f.ex use Dells -ON switches with Cumulus to run a pre deployment puppet command to allow the machine to be placed on the correct vlan.
[18:57] <x58> maxiepax: AFAIK there is no way to orchestrate the physical network.
[18:57] <spaok> I think the new hotness is moving to BGP
[18:58] <x58> BGP from the host to the rest of the network... absolutely.
[18:58] <spaok> things like Calico
[19:01] <x58> I love and use Calico :-D
[19:01] <spaok> I've been meaning to try it, the place I need it they don't support yet
[19:04] <mup> Bug #1628645 opened: MAAS incorrectly interprets DHCP packets when detecting external DHCP <MAAS:Triaged by mpontillo> <MAAS 1.9:Triaged by mpontillo> <MAAS 2.0:New for mpontillo> <https://launchpad.net/bugs/1628645>
[19:10] <spaok> does anyone know if you can load kernel modules during MAAS deployment? seems like it doesn't work
[19:11] <spaok> or do I need to install and load during the pre phase?