| === ehw|afk is now known as ehw | ||
| _nbk_ | hello, | 10:16 |
|---|---|---|
| _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:17 |
| rbasak | Sounds like that could be a problem related to IPMI on that hardware. What hardware is it? | 10:21 |
| _nbk_ | both boxes core i5, asus board P8H67-I | 10:31 |
| _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:32 |
| rbasak | What's the error exactly? | 10:47 |
| _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 :-( | 10:58 |
| _nbk_ | syslog shows all errors about bmc-config but not the error about the ssl certificate | 11:00 |
| rbasak | Use a camera, perhaps? | 11:03 |
| rbasak | It might be worth installing one node manually and checking that freeipmi works correctly with the BMC on it. | 11:03 |
| _nbk_ | i use my phone to take a picture. | 11:04 |
| _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:34 |
| _nbk_ | so what can i do to get the 1st node enlisted? | 11:39 |
| roaksoax | jtv: ping | 14:59 |
| jtv | Hi roaksoax | 14:59 |
| roaksoax | jtv: howdy!! so I was wondering something | 14:59 |
| roaksoax | jtv: how to compare that {} is {} in a test? | 15:00 |
| roaksoax | jtv: MismatchError: None is not {} | 15:00 |
| jtv | Then clearly it's not {}. :) | 15:00 |
| jtv | You can test that x is an empty dict by doing self.assertEqual(x, {}) | 15:01 |
| roaksoax | jtv: yeah, so I was comparing None with {}. but I want to compare that {} is {} | 15:01 |
| jtv | I think I may be missing something here... one of the two must be a variable, and the other a constant, right? | 15:01 |
| jtv | Because we already know that {} equals {}, although {} is not {} in the sense of the "is" operator. | 15:02 |
| roaksoax | jtv: http://paste.ubuntu.com/5758477/ | 15:02 |
| jtv | That should work, if get_snippet_dir() really returns {}. | 15:02 |
| jtv | Ahem — get_snippet_context | 15:03 |
| jtv | nog get_snippet_dir | 15:03 |
| roaksoax | jtv: yeah, that worked! thanks! (and yeah was adding that test as per your recommendation) | 15:03 |
| jtv | Ah :) | 15:03 |
| jtv | Some background: there's "{} == {}" (which is true), | 15:04 |
| jtv | and there's "{} is {}" (which is false). | 15:04 |
| jtv | The reason the latter is false is that "is" compares the identity of the objects. | 15:04 |
| roaksoax | jtv: test_get_snippet_context_empty_if_no_snippets ->> the test renamed like this sounds better? | 15:04 |
| jtv | Yes, that's good. | 15:05 |
| roaksoax | jtv: right, I see, similar to the 'is None' to 'if not None' case | 15:05 |
| jtv | Yeah — there's only one None. | 15:05 |
| roaksoax | jtv: btw... are the tests broken in saucy? | 15:05 |
| jtv | 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 |
| jtv | Tests should work in Saucy, I think. But there are sometimes changes that break them. | 15:05 |
| jtv | What are you seeing? | 15:06 |
| roaksoax | jtv: stuff like: http://pastebin.ubuntu.com/5758493/ | 15:06 |
| roaksoax | 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:07 |
| jtv | Oh dear | 15:08 |
| jtv | This looks a bit as if piston's put() no longer returns anything. | 15:08 |
| jtv | Let me just see if I can try that on a Saucy system. | 15:09 |
| roaksoax | jtv: yeah, better double check cause I did a raring->suacy upgrade which might have left something unclean, hence causing this | 15:10 |
| jtv | Right. It shouldn't, but then again, there shouldn't be any failures. | 15:10 |
| jtv | roaksoax: seeing errors too... :( | 15:23 |
| roaksoax | boomer | 15:30 |
| jtv | Boomer? Isn't that the robot dog from the original Battlestar Galactica series? | 15:34 |
| roaksoax | lol no idea :) | 15:37 |
| ehw | er… no that was moffet | 15:46 |
| ehw | boomer was the (only?) African-American pilot | 15:46 |
| jtv | Ah thanks | 15:49 |
| ehw | just doing my job *tips hat* | 16:00 |
| jtv | 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:19 |
| roaksoax | jtv: so I'm looking at this: https://jenkins.qa.ubuntu.com/job/maas-merger-trunk/319/console | 16:22 |
| jtv | Hmmm | 16:24 |
| roaksoax | 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:25 |
| jtv | Yes, IIRC render_preseed has to decide which one it should render. | 16:26 |
| roaksoax | jtv: right, that's only for commissioning or install | 16:27 |
| roaksoax | jtv: but enlistment has its own render_enlistment_preseed | 16:27 |
| roaksoax | jtv: since there's *no* node status for enlistment, then obviously the test would be testing the wrong stuff :) | 16:28 |
| roaksoax | jtv: so we are basically saying "node.status is commissioning, but test the enlistment preseed" ((i think) | 16:30 |
| jtv | 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 |
| roaksoax | jtv: oh no, i know wthat the issue is. | 16:31 |
| jtv | ? | 16:31 |
| roaksoax | jtv: so the running code calls render_enlistment_preseed for enlistment, and for everything else, render_preseed is called | 16:31 |
| roaksoax | jtv: however, the tests are testing for the enlistment preseed using render_preseed | 16:32 |
| jtv | Ah. Maybe the test could assume at some point that the status didn't matter, and that changed? | 16:33 |
| roaksoax | jtv: so the status always matters, if a node enlist then it has no node status | 16:34 |
| roaksoax | jtv: so the test is testing depending on PRESEED_TYPE, | 16:34 |
| roaksoax | jtv: http://pastebin.ubuntu.com/5758742/ --> you'll find the explanation there | 16:36 |
| jtv | Damn non-wrapping pastebin... | 16:37 |
| roaksoax | yeah! | 16:38 |
| roaksoax | 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:39 |
| jtv | 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:41 |
| roaksoax | 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 |
| roaksoax | and that's where the difference lies in the code | 16:43 |
| jtv | Yes, I recall it being something like that. | 16:43 |
| roaksoax | however, in the tests they do test as if both type of preseeds where the same | 16:44 |
| jtv | Maybe it was a matter of the node itself being None... | 16:44 |
| jtv | Ah | 16:44 |
| roaksoax | jtv: so this is what it should kinda do http://paste.ubuntu.com/5758765/ (note that it is just an example) | 16:46 |
| jtv | Any idea why this worked before and breaks now? | 16:47 |
| roaksoax | 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:49 |
| roaksoax | jtv: so doing this would fix it: http://paste.ubuntu.com/5758777/ | 16:50 |
| roaksoax | (or should) | 16:50 |
| roaksoax | I'm gonna test that | 16:50 |
| jtv | Doesn't look quite right to circumvent the test scenarios like that though... | 16:51 |
| roaksoax | jtv: this is what it does the test itself though: preseed = render_preseed(node, self.preseed, "precise") | 16:52 |
| roaksoax | where self.preseed would be *all* preseeds | 16:52 |
| jtv | Yes, IIRC the code was deliberately kept very indifferent to that. | 16:52 |
| jtv | Maybe the test can be split up into two scenarios? | 16:52 |
| jtv | One for enlistment preseeds, one for the rest? | 16:53 |
| jtv | Although it is nice to know that all scenarios are tested, even in stupid combinations... | 16:53 |
| roaksoax | jtv: in reality it is already split in 2 different scenarios | 16:55 |
| roaksoax | the problem was that the render_preseed scenario was also testing for enlistment preseeds | 16:55 |
| jtv | So then maybe that could just return if this-is-an-enlistment-preseed-type? | 16:56 |
| roaksoax | jtv: so how can I filter here: http://pastebin.ubuntu.com/5758815/ | 17:01 |
| roaksoax | jtv: something like. startswidth('ENLIST') | 17:01 |
| roaksoax | to filter the nelistment preseeds out of it | 17:01 |
| jtv | Is the filtering appropriate for the entire test case? Or just for some of the test functions inside it? | 17:02 |
| jtv | 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 |
| roaksoax | jtv: there's just 2 functions for the class that test this, and both functions uses it | 17:02 |
| roaksoax | jtv: so I would say that it is necessary to filter it | 17:02 |
| jtv | If it's the entire test case, then list comprehensions also support "if": | 17:02 |
| jtv | scenarios = [ | 17:03 |
| jtv | (name, {'preseed': value}) | 17:03 |
| jtv | for name, value in map_enum(PRESEED_TYPE).items() | 17:03 |
| jtv | if not value.startswith('ENLIST')] | 17:03 |
| roaksoax | jtv: ok awesome! thakns | 17:03 |
| jtv | Good luck... I'll see what I can find out about the Saucy failures. | 17:05 |
| roaksoax | jtv: ok this does it: http://paste.ubuntu.com/5758825/ | 17:05 |
| jtv | roaksoax: don't forget to update those comments! It's no longer "each possible value" of preseed type. | 17:06 |
| roaksoax | 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:09 |
| jtv | roaksoax: careful! The comments should say "why" — the "what" is often clear from the code already. | 17:11 |
| jtv | You could say something like "test against all preseed types, except the enlistment ones. Those have their own test case." | 17:12 |
| jtv | (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:13 |
| ehw | does anyone have any go-juju maas docs I can follow? I'm having… issues getting this running | 17:14 |
| roaksoax | jtv: ok, updated | 17:15 |
| roaksoax | jtv: https://code.launchpad.net/~andreserl/maas/consolidate_maas_ipmi_autodetect/+merge/167806 | 17:16 |
| jtv | Looking... | 17:16 |
| jtv | (diff still updating) | 17:17 |
| roaksoax | jtv: done now | 17:17 |
| * jtv reloads | 17:18 | |
| jtv | roaksoax: looks like it's even going to extend enlistment-preseed test coverage a bit... Do tests pass now? | 17:19 |
| roaksoax | jtv: yeah they do | 17:19 |
| jtv | \o/ | 17:20 |
| roaksoax | \o/ | 17:20 |
| jtv | Then land it! | 17:20 |
| * jtv is off | 17:24 | |
| === kentb is now known as kentb-out | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!