[02:37] <shang> bigjools: ping
[02:38] <bigjools> shang: hi
[02:38] <shang> bigjools: hey, had a quick question about the status on the maas backporting to 12.04
[02:39] <bigjools> that's up to roaksoax
[02:39] <shang> aha!
[02:39] <roaksoax> shang: i uploaded to -proposed, it is up to the SRU team
[02:39] <roaksoax> to review
[02:39] <shang> roaksoax: ah, great! thanks for the info
[02:40] <roaksoax> np
[02:40]  * roaksoax sleeps
[02:40] <roaksoax> night
[02:40] <bigjools> nn roaksoax
[10:51] <AskUbuntu> Limitations of Ubuntu Cloud Infrastructure with respect to OS? | http://askubuntu.com/q/267700
[14:08] <roaksoax> robotfuel: howdy!!
[14:08] <roaksoax> err
[14:08] <roaksoax> sorry
[14:08] <roaksoax> rvba: howdy!!
[14:10] <rvba> roaksoax: hi
[14:11] <roaksoax> rvba: so I need your feedback on https://code.launchpad.net/~andreserl/maas/ipmi_usercreation_ilo_versions_trunk/+merge/148579
[14:14] <roaksoax> rvba: or a recommendation on how to get bigjools request done :)
[14:14] <rvba> roaksoax: you mean Julian's request right?
[14:15] <roaksoax> rvba: yeah
[14:26] <roaksoax> mgz: howdy! you worked on the constraints side right?
[14:31] <roaksoax> mgz: any ideas on bug #1154803
[14:31] <roaksoax> allenap: howdy!! So I was wondering if there are any updates on the nodegroup thing when nodes are being unmanaged?
[14:32] <roaksoax> (not managed by dns/dhcp)
[14:34] <allenap> roaksoax: I spoke with rvba this morning about this. We can revert the fix he added to only check managed interfaces, create a package, then you can test that. However...
[14:35] <allenap> roaksoax: this will break MAAS in the test lab. The primary QA tests will be fine, but there's a secondary multi-cluster script that runs too (iirc from rvba), and this will break.
[14:35] <allenap> roaksoax: One of use needs to figure out how to rearrange the lab and talk to retoaded about getting it done.
[14:36] <allenap> roaksoax: Basically, the test lab is not a supported configuration :)
[14:36] <allenap> roaksoax: I am super busy today, so I doubt I'll have time for it though :-/ I ought to have time on Sunday though.
[14:37] <roaksoax> allenap: awesome! thanks!!
[14:39] <allenap> roaksoax: In short, MAAS does not support having two different clusters on the same subnet. Do you have somewhere you can QA where you have separate subnets?
[14:40] <mgz> roaksoax: aye (sorry, net connection flakey today)
[14:48] <mgz> roaksoax: what can I help you with?
[14:59] <roaksoax> mgz: howdy! bug ##1154803
[14:59] <roaksoax> mgz: howdy! bug #1154803
[15:00] <roaksoax> allenap: uhmmm i guess I could setup up an environment like that
[15:00] <roaksoax> allenap: though, shouldn't it be simple enough to tell maas that the node is booting in X cluster?
[15:06] <allenap> roaksoax: Do you mean, we adjust the database once it's enlisted?
[15:09] <mgz> roaksoax: so, the guy's diagnosis in that bug is certainly wrong, but it's not clear to me what exactly is broken
[15:12] <mgz> the maas logging being unhelpful there is unfortunate
[15:15] <mgz> my suspicion is his machine with maas-name: zookeeper.hdl does not in fact get a cpu recognised
[15:15] <mgz> or he just got confused, as that maas-name had been assigned, and thought removing the cpu constraint was what made it work, when actually removing the maas-name was what was needed
[15:18] <mgz> if fact, I'm almost certain it's just that he set a maas-name constraint, bootstrapped, then couldn't create any other machines
[15:22] <mgz> roaksoax: commented on the bug
[15:22] <roaksoax> allenap: mgz sorry meeting
[15:24] <mgz> ah, the guy is you. have a look when you're done with the meeting. :)
[15:28] <roaksoax> mgz: i tested removing maas-name
[15:28] <roaksoax> mgz: and it didn't work
[15:28] <roaksoax> i had tested every possibloe escenario
[15:28] <roaksoax> mgz: and it came down to having the CPU being 1 in the maas node, and 1.0 in the constraint
[15:29] <roaksoax> mgz: so setting the cpu=1.0 constraint to cpu=0, allowed me to deploy
[15:30] <mgz> but you didn't try 0.5?
[15:30] <roaksoax> mgz: no I didn't
[15:30] <mgz> there's nothing in the report that shows cpu was the issue, and I can't see any reason it should be, provided you actually had a spare machine with populated cpu count
[15:31] <mgz> I have tested that code with exact values, and it works.
[15:31] <roaksoax> allenap: so my understanding is that in order to determine from what cluster a node belongs to, the network of the enlisting node is compared to the network of a configured managed interface, if there are non, then the node is assigned to the default cluster right?
[15:31] <roaksoax> mgz: let me access those nodes and test again
[15:31] <mgz> so, something may well be borked in picking out machines, but it's not the cpu constraint
[15:32] <mgz> (or at least, it more complex than just gt vs. gtc)
[15:32] <mgz> *gte
[15:37] <roaksoax> ok this seems to be happening with default constraints only
[15:37] <roaksoax> mgz: ^^
[15:40] <roaksoax> allenap: however, that is not ideal because we are assigning a node to a different nodegroup than the one it booted from. So we need to come up with a way to always figure out from what nodegroup it booted from.
[15:41] <mgz> roaksoax: if you can narrow down the *exact* constrain change needed to make it work, that would be really helpful
[15:42] <mgz> set one thing in turn to =any and see what works
[15:42] <roaksoax> mgz: sure I'll retest
[15:42] <mgz> set back to default with =
[15:44] <roaksoax> cool
[15:45] <roaksoax> will retest
[15:49] <allenap> roaksoax: Currently it checks the managed interfaces. Reverting rvba's change will make it check all interfaces, so should do the right thing.
[15:49] <roaksoax> allenap: ok cool