[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] <rbasak> 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] <rbasak> 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] <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: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] <roaksoax> jtv: ping
[14:59] <jtv> Hi roaksoax
[14:59] <roaksoax> jtv: howdy!! so I was wondering something
[15:00] <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:01] <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:02] <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:03] <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:04] <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:05] <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:06] <jtv> What are you seeing?
[15:06] <roaksoax> jtv: stuff like: http://pastebin.ubuntu.com/5758493/
[15:07] <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:08] <jtv> Oh dear
[15:08] <jtv> This looks a bit as if piston's put() no longer returns anything.
[15:09] <jtv> Let me just see if I can try that on a Saucy system.
[15:10] <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:23] <jtv> roaksoax: seeing errors too...  :(
[15:30] <roaksoax> boomer
[15:34] <jtv> Boomer?  Isn't that the robot dog from the original Battlestar Galactica series?
[15:37] <roaksoax> lol no idea :)
[15:46] <ehw> er… no that was moffet
[15:46] <ehw> boomer was the (only?) African-American pilot
[15:49] <jtv> Ah thanks
[16:00] <ehw> just doing my job *tips hat*
[16:19] <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:22] <roaksoax> jtv: so I'm looking at this: https://jenkins.qa.ubuntu.com/job/maas-merger-trunk/319/console
[16:24] <jtv> Hmmm
[16:25] <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:26] <jtv> Yes, IIRC render_preseed has to decide which one it should render.
[16:27] <roaksoax> jtv: right, that's only for commissioning or install
[16:27] <roaksoax> jtv: but enlistment has its own render_enlistment_preseed
[16:28] <roaksoax> jtv: since there's *no* node status for enlistment, then obviously the test would be testing the wrong stuff :)
[16:30] <roaksoax> jtv: so we are basically saying "node.status is commissioning, but test the enlistment preseed" ((i think)
[16:31] <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:32] <roaksoax> jtv: however, the tests are testing for the enlistment preseed using render_preseed
[16:33] <jtv> Ah.  Maybe the test could assume at some point that the status didn't matter, and that changed?
[16:34] <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:36] <roaksoax> jtv: http://pastebin.ubuntu.com/5758742/ --> you'll find the explanation there
[16:37] <jtv> Damn non-wrapping pastebin...
[16:38] <roaksoax> yeah!
[16:39] <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:41] <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:43] <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:44] <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:46] <roaksoax> jtv: so this is what it should kinda do http://paste.ubuntu.com/5758765/ (note that it is just an example)
[16:47] <jtv> Any idea why this worked before and breaks now?
[16:49] <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:50] <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:51] <jtv> Doesn't look quite right to circumvent the test scenarios like that though...
[16:52] <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:53] <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:55] <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:56] <jtv> So then maybe that could just return if this-is-an-enlistment-preseed-type?
[17:01] <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:02] <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:03] <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:05] <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:06] <jtv> roaksoax: don't forget to update those comments!  It's no longer "each possible value" of preseed type.
[17:09] <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:11] <jtv> roaksoax: careful!  The comments should say "why" — the "what" is often clear from the code already.
[17:12] <jtv> You could say something like "test against all preseed types, except the enlistment ones.  Those have their own test case."
[17:13] <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:14] <ehw> does anyone have any go-juju maas docs I can follow? I'm having… issues getting this running
[17:15] <roaksoax> jtv: ok, updated
[17:16] <roaksoax> jtv: https://code.launchpad.net/~andreserl/maas/consolidate_maas_ipmi_autodetect/+merge/167806
[17:16] <jtv> Looking...
[17:17] <jtv> (diff still updating)
[17:17] <roaksoax> jtv: done now
[17:18]  * jtv reloads
[17:19] <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:20] <jtv> \o/
[17:20] <roaksoax> \o/
[17:20] <jtv> Then land it!
[17:24]  * jtv is off