=== ehw|afk is now known as ehw [10:16] <_nbk_> hello, [10:17] <_nbk_> i need help to enlist the 1st node. It does not show up in the List on the controller in the Browser. [10:17] <_nbk_> On the node screen an error message is running: "bmc-config:xxxx map pfn expected mapping type uncached-minus xxxx-xxx, got write-back" [10:21] Sounds like that could be a problem related to IPMI on that hardware. What hardware is it? [10:31] <_nbk_> both boxes core i5, asus board P8H67-I [10:32] <_nbk_> the node is booting fine from the maas-controller but after all these bmc- messages it also has a curl error about the ssl certificate [10:47] What's the error exactly? [10:58] <_nbk_> i could not read the error about curl and the ssl certificate so fast. i will reboot the node and try again. I have a bad netskin in my eyes :-( [11:00] <_nbk_> syslog shows all errors about bmc-config but not the error about the ssl certificate [11:03] Use a camera, perhaps? [11:03] It might be worth installing one node manually and checking that freeipmi works correctly with the BMC on it. [11:04] <_nbk_> i use my phone to take a picture. [11:34] <_nbk_> curl: (60) SSL_Certificate problem, verify that the CA cert is OK. Details:error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed [11:34] <_nbk_> More details here: http://curl.haxx.se/docs/sslcerts.html [11:34] <_nbk_> i would like to use the -k (or --insecure) option on that screen because i have the self signed certificate. [11:39] <_nbk_> so what can i do to get the 1st node enlisted? [14:59] jtv: ping [14:59] Hi roaksoax [14:59] jtv: howdy!! so I was wondering something [15:00] jtv: how to compare that {} is {} in a test? [15:00] jtv: MismatchError: None is not {} [15:00] Then clearly it's not {}. :) [15:01] You can test that x is an empty dict by doing self.assertEqual(x, {}) [15:01] jtv: yeah, so I was comparing None with {}. but I want to compare that {} is {} [15:01] I think I may be missing something here... one of the two must be a variable, and the other a constant, right? [15:02] Because we already know that {} equals {}, although {} is not {} in the sense of the "is" operator. [15:02] jtv: http://paste.ubuntu.com/5758477/ [15:02] That should work, if get_snippet_dir() really returns {}. [15:03] Ahem — get_snippet_context [15:03] nog get_snippet_dir [15:03] jtv: yeah, that worked! thanks! (and yeah was adding that test as per your recommendation) [15:03] Ah :) [15:04] Some background: there's "{} == {}" (which is true), [15:04] and there's "{} is {}" (which is false). [15:04] The reason the latter is false is that "is" compares the identity of the objects. [15:04] jtv: test_get_snippet_context_empty_if_no_snippets ->> the test renamed like this sounds better? [15:05] Yes, that's good. [15:05] jtv: right, I see, similar to the 'is None' to 'if not None' case [15:05] Yeah — there's only one None. [15:05] jtv: btw... are the tests broken in saucy? [15:05] That's why you can compare with "is None." The "is" operator basically compares the pointers you pass it, instead of the things they point to. [15:05] Tests should work in Saucy, I think. But there are sometimes changes that break them. [15:06] What are you seeing? [15:06] jtv: stuff like: http://pastebin.ubuntu.com/5758493/ [15:07] jtv: so I upgraded to saucy and tests are now broken, initially thought it was because i did something (like have maas installed), but I removed it and dunno whether it is related [15:08] Oh dear [15:08] This looks a bit as if piston's put() no longer returns anything. [15:09] Let me just see if I can try that on a Saucy system. [15:10] jtv: yeah, better double check cause I did a raring->suacy upgrade which might have left something unclean, hence causing this [15:10] Right. It shouldn't, but then again, there shouldn't be any failures. [15:23] roaksoax: seeing errors too... :( [15:30] boomer [15:34] Boomer? Isn't that the robot dog from the original Battlestar Galactica series? [15:37] lol no idea :) [15:46] er… no that was moffet [15:46] boomer was the (only?) African-American pilot [15:49] Ah thanks [16:00] just doing my job *tips hat* [16:19] roaksoax: at least some of the errors seem to be related to a change in django 1.5. The tests seem to hang, so I'm not seeing the other ones yet. [16:22] jtv: so I'm looking at this: https://jenkins.qa.ubuntu.com/job/maas-merger-trunk/319/console [16:24] Hmmm [16:25] jtv: it seems that the tests are testing the rendering of the preseeds (including the enlistment preseed, but instead of calling render_enlistment_preseed for the case of enlistment, it is calling render_preseed [16:26] Yes, IIRC render_preseed has to decide which one it should render. [16:27] jtv: right, that's only for commissioning or install [16:27] jtv: but enlistment has its own render_enlistment_preseed [16:28] jtv: since there's *no* node status for enlistment, then obviously the test would be testing the wrong stuff :) [16:30] jtv: so we are basically saying "node.status is commissioning, but test the enlistment preseed" ((i think) [16:31] I don't remember what it was that drove the decision "oh, this node is enlisting" but we'd probably have a comment to mark the spot. [16:31] jtv: oh no, i know wthat the issue is. [16:31] ? [16:31] jtv: so the running code calls render_enlistment_preseed for enlistment, and for everything else, render_preseed is called [16:32] jtv: however, the tests are testing for the enlistment preseed using render_preseed [16:33] Ah. Maybe the test could assume at some point that the status didn't matter, and that changed? [16:34] jtv: so the status always matters, if a node enlist then it has no node status [16:34] jtv: so the test is testing depending on PRESEED_TYPE, [16:36] jtv: http://pastebin.ubuntu.com/5758742/ --> you'll find the explanation there [16:37] Damn non-wrapping pastebin... [16:38] yeah! [16:39] jtv: so see what I mean? so test_render_preseed should only test for escenarios with COMMISSIONING, DEFAULT preseeds, while test_enlistment_preseed should test for ENLIST and ENLIST_USERDATA [16:41] I have no idea why load_preseed_template consists of exactly (1) an enclosed function definition and (2) a call to that function. I feel like punching someone. [16:43] jtv: I'm guessing that the key here is that the preseeds (default, commissioning) are being loaded depending on the node.status, while the enlistment preseeds are not [16:43] and that's where the difference lies in the code [16:43] Yes, I recall it being something like that. [16:44] however, in the tests they do test as if both type of preseeds where the same [16:44] Maybe it was a matter of the node itself being None... [16:44] Ah [16:46] jtv: so this is what it should kinda do http://paste.ubuntu.com/5758765/ (note that it is just an example) [16:47] Any idea why this worked before and breaks now? [16:49] jtv: yes, it is broken now becuase the maas_ipmi_autodetect stuff for enlistment is inserted in the context in render_enlistment_preseed, but since test_render_preseed calls render_preseed() for the enlist/enlist_userdata templates, then they cannot find the variable in the context [16:50] jtv: so doing this would fix it: http://paste.ubuntu.com/5758777/ [16:50] (or should) [16:50] I'm gonna test that [16:51] Doesn't look quite right to circumvent the test scenarios like that though... [16:52] jtv: this is what it does the test itself though: preseed = render_preseed(node, self.preseed, "precise") [16:52] where self.preseed would be *all* preseeds [16:52] Yes, IIRC the code was deliberately kept very indifferent to that. [16:52] Maybe the test can be split up into two scenarios? [16:53] One for enlistment preseeds, one for the rest? [16:53] Although it is nice to know that all scenarios are tested, even in stupid combinations... [16:55] jtv: in reality it is already split in 2 different scenarios [16:55] the problem was that the render_preseed scenario was also testing for enlistment preseeds [16:56] So then maybe that could just return if this-is-an-enlistment-preseed-type? [17:01] jtv: so how can I filter here: http://pastebin.ubuntu.com/5758815/ [17:01] jtv: something like. startswidth('ENLIST') [17:01] to filter the nelistment preseeds out of it [17:02] Is the filtering appropriate for the entire test case? Or just for some of the test functions inside it? [17:02] If it's just a few test functions inside it, you can put an "if" inside the test. For instance, you could just "return" early on if the preseed type starts with ENLIST. [17:02] jtv: there's just 2 functions for the class that test this, and both functions uses it [17:02] jtv: so I would say that it is necessary to filter it [17:02] If it's the entire test case, then list comprehensions also support "if": [17:03] scenarios = [ [17:03] (name, {'preseed': value}) [17:03] for name, value in map_enum(PRESEED_TYPE).items() [17:03] if not value.startswith('ENLIST')] [17:03] jtv: ok awesome! thakns [17:05] Good luck... I'll see what I can find out about the Saucy failures. [17:05] jtv: ok this does it: http://paste.ubuntu.com/5758825/ [17:06] roaksoax: don't forget to update those comments! It's no longer "each possible value" of preseed type. [17:09] jtv: http://paste.ubuntu.com/5758831/ -> alright, this way the test_render_preseed tests everything but enlistment preseeds, and test_render_enlistment_preseed() will test all enlistment preseeds other than just one [17:11] roaksoax: careful! The comments should say "why" — the "what" is often clear from the code already. [17:12] You could say something like "test against all preseed types, except the enlistment ones. Those have their own test case." [17:13] (It may seem silly to say what's coming later in the file, but somebody who's reading it has to start somewhere and then all the other stuff is still a mystery to them) [17:14] does anyone have any go-juju maas docs I can follow? I'm having… issues getting this running [17:15] jtv: ok, updated [17:16] jtv: https://code.launchpad.net/~andreserl/maas/consolidate_maas_ipmi_autodetect/+merge/167806 [17:16] Looking... [17:17] (diff still updating) [17:17] jtv: done now [17:18] * jtv reloads [17:19] roaksoax: looks like it's even going to extend enlistment-preseed test coverage a bit... Do tests pass now? [17:19] jtv: yeah they do [17:20] \o/ [17:20] \o/ [17:20] Then land it! [17:24] * jtv is off === kentb is now known as kentb-out