[00:01] <mup> Bug #1498221 opened: Subnet API should provide summary information regarding IPv4 address allocation <networking> <MAAS:In Progress by mpontillo> <https://launchpad.net/bugs/1498221>
[00:01] <mup> Bug #1498224 opened: As a MAAS administrator, I want to ask MAAS to reserve N arbitrary addresses in a Subnet or Space <networking> <MAAS:Triaged> <https://launchpad.net/bugs/1498224>
[00:16] <mup> Bug #1498225 opened: Unable to import maas images due to uec2roottar.ImageFileError <arm64> <hyperscale> <MAAS:Triaged> <https://launchpad.net/bugs/1498225>
[02:28] <mup> Bug #1498262 opened: yield deferToThread(inner_start_up) cause ERROR <MAAS:New> <https://launchpad.net/bugs/1498262>
[02:31] <mup> Bug #1498262 changed: yield deferToThread(inner_start_up) cause ERROR <MAAS:New> <https://launchpad.net/bugs/1498262>
[02:37] <mup> Bug #1498262 opened: yield deferToThread(inner_start_up) cause ERROR <MAAS:New> <https://launchpad.net/bugs/1498262>
[02:40] <mup> Bug #1498262 changed: yield deferToThread(inner_start_up) cause ERROR <MAAS:New> <https://launchpad.net/bugs/1498262>
[02:43] <mup> Bug #1498262 opened: yield deferToThread(inner_start_up) cause ERROR <MAAS:New> <https://launchpad.net/bugs/1498262>
[07:00] <binoy> http://askubuntu.com/questions/675240/post-request-using-python-maas-client/676680
[11:13] <binoy> http://askubuntu.com/questions/675240/post-request-using-python-maas-client/677023#677023
[13:51] <mup> Bug #1498503 opened: Not all maas related services removed with apt-get purge <MAAS:New> <https://launchpad.net/bugs/1498503>
[14:09] <mup> Bug #1498503 changed: Not all maas related services removed with apt-get purge <MAAS:New> <https://launchpad.net/bugs/1498503>
[14:12] <mup> Bug #1498503 opened: Not all maas related services removed with apt-get purge <MAAS:New> <https://launchpad.net/bugs/1498503>
[14:15] <mup> Bug #1498513 opened: Offensive term combination found in MAAS 1.8 <MAAS:New> <https://launchpad.net/bugs/1498513>
[15:24] <mup> Bug #1367854 changed: Commissioning with a 6TB disk yields incorrect "Disk space" value <papercut> <trivial> <ui> <MAAS:Fix Released> <https://launchpad.net/bugs/1367854>
[15:24] <mup> Bug #1498513 changed: Offensive term combination found in MAAS 1.8 <MAAS:Opinion> <https://launchpad.net/bugs/1498513>
[17:43] <mup> Bug #1498600 opened: Errors that occur during startup inside "yield deferToThread(inner_start_up)" are hidden <support> <MAAS:Triaged> <https://launchpad.net/bugs/1498600>
[17:43] <mup> Bug #1498601 opened: Errors that occur during startup inside "yield deferToThread(inner_start_up)" are hidden <support> <MAAS:Triaged> <https://launchpad.net/bugs/1498601>
[18:19] <mup> Bug #1478638 changed: Always use MAC address for IPMI if MAAS connected directly <MAAS:Won't Fix> <https://launchpad.net/bugs/1478638>
[19:20] <h0mer> How does one get Maas to re-calculate the resources ina  machine without releasing and redeploying it?  Basically I changed the amount of memory in a node, but the Maas Page still shows the older Memory capacity.
[19:31] <rbasak> h0mer: I think you need to recommission it, which means you have to release first and redeploy after. I'm sure it's possible to hack around this, but in principle MAAS doesn't get to run code on the machine while it is deployed, since it is "owned" by the user it has been deployed to, so I think that makes sense.
[19:31] <rbasak> h0mer: why is this a problem for you? Surely what MAAS thinks the machine has shouldn't really pose a problem since it isn't making any decisions based on it as it the machine is already deployed?
[19:36] <h0mer> Because I'm deploying openstack on top of it (using landscape), which now seems to think that each machine only has 96GB because that's what MAAS is telling it.
[19:37] <h0mer> (I upgraded them to 144GB each)
[19:39] <h0mer> it took me a helluva long time to get Maas/Landscape/Openstack deployed (Landscape kept stopping at random times), I don't want to have to go through the re-install of the entire stack again, which is like a 1/2 day long adventure.
[19:40] <h0mer> followed by another day or two to get Landscape to deploy openstack correctly.
[19:44] <h0mer> It'd be nice if Maas could be put into another state like "maintainence" in which it boots the machine through PXE and liveboots whatever base linux install and re-does the system resources calculation.  Just a thought for a future enhancement
[19:52] <h0mer> I'm currently setting up test beds to test-run different automated openstack deployment technologies (packstack, ansible, landscape etc...), and I don't see how Landscape/Maas/Juju can be used in a production environment if every small hardware change requires me to re-commission the nodes and subsequently re-install the entire software stack.
[20:05] <kiko> h0mer, you can't really do that right now; it's a feature we'd like to work on but it doesn't work like that today
[20:05] <kiko> to be honest, reinstalling a node in a scale-out environment is fairly common task, right?
[20:10] <h0mer> True.  It is fairly common (I'm actually doing it right now).  Thing is, if I did a base openstack install (individual components on each machine), I could modify it manually to pick up the new memory space without having to bring down the entire region.  I'm trying to see what the best way to do that with the current Maas/Landscape Install.  If it's not possible, that's fine, just curious.  I'd
[20:10] <h0mer> think this would be a big issue especially when trying to market this technology to companies trying to set up this software stack no?
[20:11] <kiko> h0mer, I'm otp so a bit slow to respond, but it hasn't been a /major/ issue, though it is inconvenient
[20:12] <h0mer> And I'm just more curious how Cannonical deals with this problem using it's "managed cloud" solution.
[20:12] <kiko> h0mer, having said that, re-commissioning only affects the data in MAAS
[20:12] <kiko> well
[20:12] <kiko> we always deploy HA clouds
[20:12] <kiko> so it's always possible to do rolling re-commissions
[20:13] <h0mer> what exactly is meant by high availability clouds?
[20:13] <kiko> clouds where any node can be brought down without suffering loss of service
[20:13] <h0mer> sorry i meant... how exactly is that achieved
[20:13] <kiko> ah
[20:14] <kiko> https://wiki.ubuntu.com/ServerTeam/OpenStackHA
[20:14] <h0mer> because that would kind of fix this issue (to an extent)
[20:19] <h0mer> Question: Is it posible to get the free versoin of Landscape (with up to 10 registered computers) to support something like 14-15 nodes in a test bed?  Just curious, because that's how many nodes I've been able to allocate to this side project (for this company I work for).  Currently have 4 nodes sitting around doing nothing..
[20:42] <kiko> h0mer, I'd send that question to shawn.madden@canonical.com and CC: me; he'd probably like to have a test user for the openstack autopilot
[21:00] <mad4comp> kiko
[21:01] <kiko> me
[21:01] <kiko> h0mer, yes?
[21:01] <h0mer> did you want me to cc you
[21:01] <h0mer> ?
 h0mer, I'd send that question to shawn.madden@canonical.com and CC: me; he'd probably like to have a test user for the openstack autopilot
[21:01] <kiko> :)
[21:01] <kiko> kiko@canonical.com
[21:01] <h0mer> ah okay
[21:02] <kiko> sorry, I didn't realize I didn't give you my email
[21:06] <h0mer> no problem.  Sorry for the late response, got caught up in some juju issues.
[21:12] <h0mer> alright sent out an email
[21:12] <h0mer> thank  you
[21:28] <mup> Bug #1498659 opened: Can't import images <MAAS:Confirmed for allenap> <https://launchpad.net/bugs/1498659>
[21:34] <mup> Bug #1498659 changed: Can't import images <MAAS:Confirmed for allenap> <https://launchpad.net/bugs/1498659>
[21:37] <mup> Bug #1498659 opened: Can't import images <MAAS:Confirmed for allenap> <https://launchpad.net/bugs/1498659>