[02:37] bigjools: ping [02:38] shang: hi [02:38] bigjools: hey, had a quick question about the status on the maas backporting to 12.04 [02:39] that's up to roaksoax [02:39] aha! [02:39] shang: i uploaded to -proposed, it is up to the SRU team [02:39] to review [02:39] roaksoax: ah, great! thanks for the info [02:40] np [02:40] * roaksoax sleeps [02:40] night [02:40] nn roaksoax === jtv1 is now known as jtv [10:51] Limitations of Ubuntu Cloud Infrastructure with respect to OS? | http://askubuntu.com/q/267700 [14:08] robotfuel: howdy!! [14:08] err [14:08] sorry [14:08] rvba: howdy!! [14:10] roaksoax: hi [14:11] rvba: so I need your feedback on https://code.launchpad.net/~andreserl/maas/ipmi_usercreation_ilo_versions_trunk/+merge/148579 [14:14] rvba: or a recommendation on how to get bigjools request done :) [14:14] roaksoax: you mean Julian's request right? [14:15] rvba: yeah [14:26] mgz: howdy! you worked on the constraints side right? [14:31] mgz: any ideas on bug #1154803 [14:31] bug 1154803 in MAAS "Constraints prevents the allocation of nodes if they are equal to the HW." [High,Triaged] https://launchpad.net/bugs/1154803 [14:31] allenap: howdy!! So I was wondering if there are any updates on the nodegroup thing when nodes are being unmanaged? [14:32] (not managed by dns/dhcp) [14:34] 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] 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] roaksoax: One of use needs to figure out how to rearrange the lab and talk to retoaded about getting it done. [14:36] roaksoax: Basically, the test lab is not a supported configuration :) [14:36] 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] allenap: awesome! thanks!! [14:39] 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] roaksoax: aye (sorry, net connection flakey today) [14:48] roaksoax: what can I help you with? [14:59] mgz: howdy! bug ##1154803 [14:59] mgz: howdy! bug #1154803 [14:59] bug 1154803 in MAAS "Constraints prevents the allocation of nodes if they are equal to the HW." [High,Triaged] https://launchpad.net/bugs/1154803 [15:00] allenap: uhmmm i guess I could setup up an environment like that [15:00] allenap: though, shouldn't it be simple enough to tell maas that the node is booting in X cluster? [15:06] roaksoax: Do you mean, we adjust the database once it's enlisted? [15:09] 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] the maas logging being unhelpful there is unfortunate [15:15] my suspicion is his machine with maas-name: zookeeper.hdl does not in fact get a cpu recognised [15:15] 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] 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] roaksoax: commented on the bug [15:22] allenap: mgz sorry meeting [15:24] ah, the guy is you. have a look when you're done with the meeting. :) [15:28] mgz: i tested removing maas-name [15:28] mgz: and it didn't work [15:28] i had tested every possibloe escenario [15:28] mgz: and it came down to having the CPU being 1 in the maas node, and 1.0 in the constraint [15:29] mgz: so setting the cpu=1.0 constraint to cpu=0, allowed me to deploy [15:30] but you didn't try 0.5? [15:30] mgz: no I didn't [15:30] 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] I have tested that code with exact values, and it works. [15:31] 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] mgz: let me access those nodes and test again [15:31] so, something may well be borked in picking out machines, but it's not the cpu constraint [15:32] (or at least, it more complex than just gt vs. gtc) [15:32] *gte [15:37] ok this seems to be happening with default constraints only [15:37] mgz: ^^ [15:40] 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] roaksoax: if you can narrow down the *exact* constrain change needed to make it work, that would be really helpful [15:42] set one thing in turn to =any and see what works [15:42] mgz: sure I'll retest [15:42] set back to default with = [15:44] cool [15:45] will retest [15:49] 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] allenap: ok cool === kentb is now known as kentb-out