[07:01] <rvba> bigjools: did you QA the fix for https://bugs.launchpad.net/maas/+bug/1341001? (I can help with that if you didn't)
[07:01] <bigjools> rvba: I did not
[07:02] <bigjools> bit sidetracked by other stuff today
[07:02] <rvba> Okay, I'll do it now.
[07:40] <bigjools> easy review karma: https://code.launchpad.net/~julian-edwards/maas/cluster-task--report-last-import-time/+merge/226782
[07:44] <rvba> bigjools: approved
[07:44] <bigjools> rvba: thanks
[07:46] <bigjools> "make lint" always makes me chuckle
[08:18] <rvba> allenap: hi, I see you've changed the RPC stuff so that exceptions are properly propagated.
[08:20] <rvba> jtv: I'm still in the process of making sure it's repeatable but when I tried upgrading my 1.5.2 installation to trunk I got: http://paste.ubuntu.com/7797346/.  Any idea where this is coming from?
[08:21] <jtv> rvba: yes, that's a known bug — fix is in review.
[08:21] <rvba> Ah okay.  Ta.
[08:21] <jtv> bigjools: I replied to your review.
[08:22] <rvba> allenap: the error I'm getting on the cluster when a NoSuchNode is raised on the Region looks like this: 'Node with system_id=Node with system_id=unknown-system-id-dPaTUv could not be found. could not be found.'
[08:22] <rvba> allenap: Looks like the code from paste.ubuntu.com/7797390/ is "applied" twice or something.
[08:22] <allenap> rvba: Ah, that’ll be because you’ve customised __init__ to munge the message.
[08:23] <rvba> allenap: I see, the error is "recreated" on the other side…
[08:23] <rvba> Right?
[08:23] <allenap> rvba: Yep.
[08:24] <allenap> rvba: You could instead customise __str__ (and __unicode__).
[08:24] <rvba> allenap: that's precisely what I'm trying now :).
[08:57] <rvba> jtv: lp:~jtv/maas/bug-1340896 is the branch that fixes the upgrade problem right?
[08:58] <jtv> Yes.
[08:58] <jtv> See the bug.
[08:59] <jtv> You might actually have insights useful for the review discussion.
[08:59] <rvba> Okay, I'll look at it in a bit.  I'm in the middle of doing some QA now and I'd like to get that sorted first…
[09:04] <rvba> jtv: got the same upgrade problem with the fixes from that branch :/
[09:06] <jtv> Hrrrh!?
[09:07] <rvba> It's possible that my installation is broken… I've been fighting with it all morning.
[09:07] <jtv> Then maybe we need 3 migrations after all...
[09:07] <jtv> But I did make it go through the migrations forwards and backwards with cluster interfaces present.
[09:07] <jtv> (And I observed the changes in an SQL shell)
[09:09]  * rvba switches to maas/1.6
[09:10] <rvba> jtv: happy to do some more testing later (and have a look at that branch/bug) but right now, I just want to get through with the QA.
[09:10]  * rvba backports fix.
[09:11] <jtv> rvba: right 1.6 doesn't have those schema changes, so the problem won't happen there.
[09:11] <rvba> Yep, that's why I'm using it.
[09:12] <jtv> OK
[09:13] <jtv> Would love to hear more if you run into that migration problem again — I did a similar experiment here and didn't have the problem.
[09:15] <bigjools> rvba: did you look at why CI is failing?
[09:15] <rvba> bigjools: no; still busy QAing the fix for https://bugs.launchpad.net/maas/+bug/1341001
[09:16] <rvba> bigjools: error installing: http://paste.ubuntu.com/7797564/
[09:17] <bigjools> rvba: looks like a dependent package is broken
[09:18] <bigjools> very hard to see which one though
[09:21] <rvba> bigjools: job #215 failed with the error I pasted above.  job #214 failed because the cluster didn't connect to the region (I'm assuming this is somehow related to the problems Jeroen is working on);  but the dependent packages were exactly the same in the two runs.
[09:22] <bigjools> rvba: could have been an upload in the interim.  Is this utopic or trusty?  they both fail
[09:22] <rvba> bigjools: utopic.  Like I said, I retrieve the list of the packages that have been installed and there is no difference.
[09:23] <bigjools> rvba: same versions?
[09:23] <rvba> Yes
[09:23] <bigjools> ok
[09:23] <bigjools> weird then
[09:23] <bigjools> very weird
[09:23] <rvba> I'm diffing the lines:
[09:23] <rvba> Get:1 http://archive.ubuntu.com/ubuntu/ utopic/main libc-bin amd64 2.19-4ubuntu1 [1169 kB]
[09:23] <rvba> …
[09:23] <bigjools> k
[09:24] <rvba> I'm running a test on 1.6 (topic-adt-maas-manual).
[09:26] <rvba> bigjools: the failure of the trusty job is different.  That job uses Trusty.  Seems like revision 2290 of lp:maas/1.5 broke the build (unless it's spurious).
[09:27] <rvba> bigjools: 2290 is the backport of the nonce stuff.
[09:27] <bigjools> rvba: fuck
[09:27] <rvba> bigjools: I started another job, just to make sure the failure is consistent.
[09:28] <bigjools> ok thanks
[09:28] <bigjools> back it out if it fails again
[09:28] <rvba> k
[09:30] <rvba> bigjools: allenap: fwiw there is a card on the board (in the robustness lane) for the "Move power-related tasks over to twisted" task.
[09:30] <rvba> And no, I'm not insisting ;).
[09:30] <bigjools> it'll need breaking down, but that's ok
[09:32] <rvba> bigjools: QA ok for the fix for https://bugs.launchpad.net/maas/+bug/1341001
[09:37] <rvba> bigjools: hum, the precise job also failed and the MAAS version didn't change.  Something might be wrong with the lab itself.
[09:38] <bigjools> rvba: yeah, that would be my next suspect
[09:41] <rvba> bigjools: I'm backporting the fix for https://bugs.launchpad.net/maas/+bug/1341001 to 1.6
[09:41] <bigjools> rvba: thank you
[09:41] <bigjools> you're too kind :)
[10:29] <rvba> allenap: I still get the repeated exception message when I customize __str__/__unicode__ on my exception class.
[10:29] <allenap> rvba: Can you show me the code?
[10:32] <rvba> allenap: just one sec…
[10:34] <rvba> allenap: http://paste.ubuntu.com/7797848/
[10:35] <rvba> allenap: http://paste.ubuntu.com/7797873/ wqorks
[10:35] <rvba> works*
[10:36] <allenap> rvba: Intriguing. I like the alternative constructor pattern. (Though don’t inherit from BaseException.)
[10:36] <rvba> allenap: right (I got rid of BaseException)
[10:39] <rvba> allenap: where in the code does the exception recreation happen?
[10:42] <allenap> rvba: See eb_massage_error in MAAS, or _massageError in amp.py.
[10:43] <rvba> allenap: I'm confused, why is this in src/provisioningserver/rpc/testing/__init__.py ?  i.e. in what seem to be a testing utility?
[10:43] <rvba> seems*
[10:45] <allenap> rvba: Because it’s a testing utility that avoids mimics a remote call without having to do messy stuff with sockets and suchlike.
[10:46] <allenap> s/avoids /
[10:46] <rvba> allenap: but outside of testing, the error is also recreated on the caller's side right?
[10:47] <allenap> rvba: Yes. eb_massage_error is meant to make call_responder behave more like a real RPC call.
[10:48] <rvba> allenap: all right.  It feels a bit weird that we have to manually recreate that behavior in testing but okay..
[10:52] <rvba> bigjools: the 1.5 (trusty) job passed.  It was indeed a problem with a node, the nonce stuff is okay.
[10:53] <bigjools> cool
[10:53] <bigjools> thanks for checking it out
[10:53] <rvba> I'm running all the other jobs now.
[10:54] <rvba> A run with 1.6 is in progress now.
[10:54] <rvba> If this one passes, it will be time to release another beta package.
[11:21] <bigjools> let me know
[11:43] <rvba> bigjools: test passed (revision 2534 on lp:maas/1.6).
[11:45] <bigjools> thanks
[11:47] <jtv> Trusty CI is better now.
[11:47] <jtv> Oh, that's 1.5.  :(
[11:51] <jtv> The failure has changed.  Could it be that the CI needs to refresh its knowledge of the API?
[11:59] <jtv> But then why did previous updates to the NGI succeed?
[12:01] <jtv> Ahh, no, it didn't.
[12:02] <rvba> jtv: looks like it's the parsing of MAAS' output that failed.
[12:03] <rvba> jtv: no, I'm wrong, it's related to the recent addition of the NGI's name.
[12:06] <jtv> Yes.  Question is, how?
[12:06] <jtv> The API doesn't expect values for all of the form fields, does it?
[12:07] <rvba> Depends on the form that handles the data.
[12:08] <jtv> The field is taken directly from the model, and it's blank=True null=False.
[12:09] <jtv> The form's cleaning provides a value if it's blank.
[12:09] <jtv> Or at least, that's the theory.
[12:11] <jtv> The parsing fails because _set_up_dhcp needs to check manually for an error return from _run_maas_cli, and doesn't.
[12:11] <jtv> It receives error output and assumes it gets usable json.
[12:12] <rvba> Right.
[12:12] <jtv> The only hint we get from the CLI is "name" — which we don't specify, so that's why I wonder if there's a problem with that.
[12:14] <jtv> I'm going to see if I can reproduce the problem with a simple API/CLI update.
[12:14] <rvba> Should do the trick.
[12:23] <jtv> Seems to work on the API...  :/
[12:31] <jtv> class Action(Command):
[12:31] <jtv>     uri = property(lambda self: self.handler["uri"])
[12:31] <jtv>     def __call__(self, options):
[12:31] <jtv>         uri = self.uri.format(**vars(options))
[12:32] <jtv> ^ This is why we don't want code to be clever or "use the language to its full."
[12:32] <jtv> That last assignment is the source of the error.
[12:32] <jtv> Whoopee, right?
[12:34] <rvba> What's 'options'?
[12:34] <jtv> Parameter to __call__.
[12:34] <rvba> No shit :)
[12:35] <jtv> If you want to know more, and so do I, let's ask allenap...
[12:35] <rvba> heh
[12:36]  * allenap reads backwards
[12:37] <jtv> allenap: the main thing is that bit of code (class Action(Command):) from the CLI.
[12:37] <allenap> jtv: What’s going wrong?
[12:37] <jtv> KeyError.
[12:38] <jtv> In that self.uri.format line.
[12:39] <allenap> jtv: Is it saying which key is missing?
[12:39] <jtv> Yes.  It's ‘name’.
[12:40] <allenap> So that’s something in the URI template that Django/Piston generates.
[12:40] <jtv> Where do they get the information for generating that URI template?
[12:41] <allenap> It comes from the Piston handler class.
[12:41] <allenap> resource_uri_template
[12:41] <jtv> Then I think understanding dawns.
[12:41] <allenap> See describe_handler in maasserver.apidoc.
[12:42] <jtv> The CLI call isn't passing the name field, which is supposed to go in the URL path.
[12:46] <allenap> jtv: That implies that the CLI doesn’t know the name field is required. I think that parameters can be declared, but they need to be part of the URL path that a Django/Piston handler is registered with, or something like that.
[12:47] <allenap> Which it should be :-/
[12:47] <jtv> The CLI doesn't know that the name field is _not_ required.  :(
[12:48] <jtv> So the URI template says "give me <name> here" and the CLI code tries to take <name> from its parameters dict, which doesn't have it.
[12:49] <allenap> jtv: What does the URL look like?
[12:50] <jtv> http://localhost:5240/api/1.0/nodegroups/{uuid}/interfaces/{name}/
[12:50] <allenap> jtv: Why is the name optional?
[12:50] <allenap> What behaviour does that produce?
[12:52] <allenap> Without the {name} filled in, I think that should resolve to the NodeGroupInterfacesHandler. With {name} it should resolve to NodeGroupInterfaceHandler, i.e. the singular.
[12:52] <jtv> The URL used to have the network interface name in it.  That's been changed to be the cluster interface name.
[12:52] <jtv> So the request doesn't need to pass ‘name’ as a field, only as part of the URL.
[12:55] <allenap> jtv: Can you paste the error for me? I don’t have the CI email any more :-/
[12:57] <jtv> No point.  You get less useful information than this.
[12:58] <jtv> The problem is that the CLI takes the positional URL parameters by name instead of positionally.
[12:58] <jtv> No idea how to fix that.  :(
[13:00] <allenap> jtv: Maybe the CI script needs to do `maas refresh` to get updated API descriptions?
[13:01] <rvba> allenap: the CI use a new VM instance (to install MAAS) for each run.
[13:09] <jtv> allenap: no, a refresh doesn't do it.  The problem is that the CLI takes the positional parameters from the dict of keyword arguments — which I suppose also spells trouble for any case where an identifying field is editable.
[13:19] <allenap> jtv: Do you have some instructions so that I can reproduce this?
[13:20] <jtv> allenap: ./bin/maas <profile> node-group-interface update <uuid> <name>
[13:20] <jtv> Produces: ./bin/maas: error: u'name'
[13:21] <jtv> Debugging shows that it's a KeyError while attempting to format that URI.
[13:23] <jtv> To add to the fun, passing ‘name’ as a named parameter doesn't help.
[13:27] <allenap> jtv: It also believes that the name is required for bin/maas <profile> node-group-interface read
[13:28] <jtv> Duh.
[13:28] <jtv> The problem is that the CLI code passes that parameter around by name, instead of positionally.
[13:30] <allenap> jtv: NodeGroupInterfaceHandler.resource_uri is still returning ‘interface’ as a parameter. Not sure if that would explain everything, but it’s worth giving a go.
[13:30]  * allenap gives it a go.
[13:31] <jtv> Passing name and interface both doesn't change it for me.  :(
[13:32] <allenap> https://www.irccloud.com/pastebin/vlInRrAc
[13:32] <allenap> jtv: ^ try applying that, restarting, refreshing the cli.
[13:43] <matsubara> allenap, jtv: fwiw, I filed https://bugs.launchpad.net/maas/+bug/1342117 for the cryptic error: u'name' failure
[13:43] <jtv> Thanks matsubara. We're just looking into it.
[13:44] <matsubara> jtv, yep, I saw the backlog. Thanks. (And thanks for fixing the other nodegroup crash!)
[14:03] <jtv> allenap: your paste (with a refresh) fixes the problem!
[14:04] <jtv> I thought that part where these methods substitute a fixed string was only there for documentation..?
[14:05] <allenap> jtv: There’s still an oddity where `… node-group-interfaces list` requires a `uuid` argument. I think NodeGroupInterfacesHandler.resource_uri needs adjusting.
[14:06] <allenap> jtv: Nope, waste not want not: it was repurposed for driving the CLI too :)
[14:07] <allenap> jtv: Actually, and I don’t know why, NodeGroupInterfaces.list() takes a uuid argument, which I think it probably shouldn’t.
[14:58] <jtv> allenap: IIRC NodeGroupInterfaces.list lists the cluster interfaces for one cluster — and so you need to tell it which cluster.
[15:09] <jtv> Exceedingly small branch for review: https://code.launchpad.net/~jtv/maas/ngi-name-ci-breakage/+merge/226859
[21:26] <dergrunepunkt> hi, I'm using maas + juju + virsh, installed as the doc said and it's working
[21:27] <dergrunepunkt> I have the nodes installed and when they boot they show as "enlisted-node-XXX"
[21:27] <dergrunepunkt> but I cant get juju to do the bootstrap
[21:28] <dergrunepunkt> because every time I run "juju boostrap" it starts a VM and the operating system installation runs again
[21:28] <dergrunepunkt> what I am doing wrong?
[21:42] <schegi_> hi out there, have a maas lxc related question can someone help??
[21:46] <rbasak> schegi_: nobody will know until you actually ask your question
[21:48] <schegi_> thought it was more juju related, bootstraped a maas environemt and was wondering how to define the bridge device which is used if an service is deployed in a container.
[21:48] <schegi_> asked in the juju channel
[22:11] <dergrunepunkt_> why maas keeps reinstalling a node?