[08:07] <mup> Bug #1686887 opened: juju does not properly prioritize constraints in a v4 bundle <bundles> <cpe> <juju:Incomplete> <MAAS:New> <https://launchpad.net/bugs/1686887>
[11:58] <mup> Bug #1689288 opened: Unable to update VLAN interface <MAAS:New> <https://launchpad.net/bugs/1689288>
[12:01] <mup> Bug #1689288 changed: Unable to update VLAN interface <MAAS:New> <https://launchpad.net/bugs/1689288>
[12:04] <mup> Bug #1689288 opened: Unable to update VLAN interface <MAAS:New> <https://launchpad.net/bugs/1689288>
[15:47] <mup> Bug #1689334 opened: [Device discovery] When adding a device the feedback should appear on the same row in the table as the device <ui> <MAAS:New> <https://launchpad.net/bugs/1689334>
[15:56] <mup> Bug #1689334 changed: [Device discovery] When adding a device the feedback should appear on the same row in the table as the device <ui> <MAAS:New> <https://launchpad.net/bugs/1689334>
[15:59] <mup> Bug #1689334 opened: [Device discovery] When adding a device the feedback should appear on the same row in the table as the device <ui> <MAAS:New> <https://launchpad.net/bugs/1689334>
[16:02] <mup> Bug #1689334 changed: [Device discovery] When adding a device the feedback should appear on the same row in the table as the device <ui> <MAAS:New> <https://launchpad.net/bugs/1689334>
[16:05] <mup> Bug #1689334 opened: [Device discovery] When adding a device the feedback should appear on the same row in the table as the device <ui> <MAAS:New> <https://launchpad.net/bugs/1689334>
[17:32] <mup> Bug #1688676 changed: Unable to delete rack controller running in snap <MAAS:Triaged> <https://launchpad.net/bugs/1688676>
[19:19] <xygnal> mpontillo:  applied your code for the dhcp hostmap triggers.  does reigond need a restrt or just rackd?
[19:35] <mpontillo> xygnal: the region needs to be restarted for that one. the triggers allow the region to notice when the host maps change and push the changes down to the rack
[19:38] <xygnal> mpontillo: ty.  one more unrelaated question for you.  We are building an API of our own that lets us control certain details of what users ask for
[19:38] <xygnal> mpontillo:  it should work out for us, but one problem - a UI user could bypass this and build direcly in the UI instead.   Is there/will there be a way to change this?
[19:39] <mpontillo> xygnal: hmm, don't give them access to username/password or API keys maybe?
[19:39] <xygnal> xygnal:  certain members on my team are quite obsessed with the idea of having a UI for the users, and they dont want to write their own.  thus they want them to be able to use the UI.
[19:40] <xygnal> mpontillo is it safe to assume MAAS will never embrace that level of control?
[19:41] <xygnal> mpontillo: one of the reasons for the API is being able to set things like user_data, which are not even exposed in the UI in the first place.
[20:03] <mpontillo> xygnal: well, fine-grained permission control is something that is on the roadmap. and I can't guarantee that we won't enhance the UI to support something like that; we have some customers whose requirement is for the UI to do everything the API can do.
[20:03] <mpontillo> xygnal: so I hate to sound like a sales drone, but if you want to influence the roadmap, consider buying a support contract =)
[20:04] <mpontillo> xygnal: I do not believe we have any plans to expose that degree of functionality in the near future though.
[20:06] <mpontillo> xygnal: or invest engineering time into contributing to MAAS yourself. patches welcome =)
[20:09] <xygnal> mpontillo we might just do either one of those
[20:09] <xygnal> :)
[20:11] <mpontillo> looking forward to it
[20:37] <xygnal> mpontillo do you have your own maas-specific support contracts, or do you piggy back on ubuntu's Advanced service or such?
[20:42] <mpontillo> xygnal: I believe our normal Ubuntu Server contacts cover MAAS, but sometimes customers who need specific features will negotiate with our sales team for non-recurring engineering
[21:58] <Bigtexun> Hey there!  I'm working with MAAS Version 2.1.3+bzr5573-0ubuntu1 (16.04.1), which is working great for deploying ubuntu nodes.  However I'm seeing issues with both centos7 and centos6.6.  6.6 deployes fine, but does not install my ssh key, so I can't log into the node.  7 starts to deploy, but once it boots up from the local filesystem, cloud-init complains
[21:58] <Bigtexun> about a routing problem, asbd the interface chart chows that the only network interface present is the loopback interface, the ethernet interfaces are missing (or more properly the driver isn't present or didn't detect the ethernets.  The hardware is a HP DL360g7.  The same physical node is used for all tests, so the hardware is a constant.  I see a bug
[21:58] <Bigtexun> report for the dl360g7, but the reported bug doesn't seem to be the same.  The console messages I saw that show the problem won't be logged on the MAAS server as there is no network connection present to send the logs back to the rack
[21:59] <Bigtexun> Is there anything I am missing on getting centos running?
[22:41] <mup> Bug #1688010 changed: [2.2rc4] Image selection for Ubuntu Core and Other repeat options <MAAS:Triaged by ltrager> <https://launchpad.net/bugs/1688010>
[22:44] <mup> Bug #1688010 opened: [2.2rc4] Image selection for Ubuntu Core and Other repeat options <MAAS:Triaged by ltrager> <https://launchpad.net/bugs/1688010>
[22:47] <mup> Bug #1688010 changed: [2.2rc4] Image selection for Ubuntu Core and Other repeat options <MAAS:Triaged by ltrager> <https://launchpad.net/bugs/1688010>