[03:33] <bigjools> jtv: may I avail myself of your reviewing powers please https://code.launchpad.net/~julian-edwards/maas/timer-commands/+merge/233296
[03:33] <jtv> *trumpet music blares briefly*
[03:34] <bigjools> is that like the reaping music in Hunger Games?
[03:47] <jtv> Can't discuss that here.  Probably illegal.
[03:47] <jtv> Anyway, your review is done.
[03:49] <bigjools> thanks
[05:09] <newell> Hola all
[08:11] <jtv> Controlling the power on our NUCs would be so much easier if amttool supported IPv6...
[08:26] <jtv> Bah.  Doesn't look as if wsman supports IPv6 either.  :(
[10:10] <rvba> allenap: it seems we've got many different ways to test methods that call the RPC stuff in the code base… I assume this is due to the fact that you're refined it recently… can you point me to the most up-to-example version?
[10:12] <allenap> rvba: It depends on what you want to do :) call_responder is best when you’re testing a single RPC method directly.
[10:13] <rvba> allenap: I want to test this: a RPC method should be called as a side-effect of changing a node's status.
[10:13] <allenap> rvba: Mock(Live)?(ClusterToRegion|RegionToCluster)Fixture are best when testing code that uses RPC. The Live variants are best when there isn’t an opportunity to pump IO in the test, by hand as it were.
[10:14] <rvba> allenap: okay, thanks; that's what I started using.  There are places in the code that use pure mocking instead of this.
[10:15] <allenap> rvba: Personally I would be tempted to write a helper in maasserver.clusterrpc somewhere, test that on its own, then use patch_autospec to test that *that* is called when changing a node’s status.
[10:16] <rvba> allenap: I don't understand… what would that helper do?
[10:22] <rvba> allenap: couldn't we get MockRegionToClusterRPCFixture to use patch_autospec under the hood to create "valid" mocks for all the registered methods?
[10:39] <allenap> rvba: We’re actually getting something similar because all calls are being validated against the RPC schema.
[10:39] <rvba> allenap: ah, okay.
[10:39] <rvba> allenap: still, it's not exactly the same thing as having mocks already setup.
[10:40] <allenap> rvba: The helper would be a thin wrapper around getting a client and making the remote call. It’s a conveniently small thing to test, but also provides a good point at which to mock.
[10:40] <allenap> rvba: What kind of mocks do you want? When running the pserv tests I don’t really want to bring up the database and Django.
[10:41] <rvba> allenap: well, just mock objects;  and then you can configure them if you want.  I don't see how that's related to Django at all but I must be missing something.
[10:48] <allenap> rvba: If you’re using addEventLoop (from the cluster) or addCluster (from the region) with the end-to-end fixtures, then you can specify which calls to mock, and it does provide stubs for you to customise. It’s hard to customise those to have some default behaviour when that behaviour is defined elsewhere (e.g. provisioningserver shouldn’t import
[10:48] <allenap> maasserver, and that’s where Django comes in) and might require a database with sample data. I also don’t think that would be a good way to write unit tests.
[10:49] <rvba> allenap: fair enough.
[14:18] <gQuigs> ~$ maas maas-mini-test maas get-config maas_name=unicode
[14:18] <gQuigs> No provided name!
[14:18]  * gQuigs doesn't understand how to query get-config
[14:19] <gQuigs> ideally, I'd like to be able to just get all the config back
[15:04] <rvba> allenap: I'm still not completely satisfied with the explanation you gave me on ~allenap/maas/rpc-start-nodes-extra… why were we excluding nodes with MACs?  If this is still a requirement, why aren't you changing all the call sites to eliminate the nodes with MACs before calling start_nodes.  And if you think start_nodes is the wrong place to do this, why did you do something very similar in stop_nodes?
[15:05] <rvba> allenap: sorry, lots of questions :)
[15:08] <allenap> rvba: I honestly don’t know why we were excluding nodes without MACs.
[15:09] <allenap> It seems bizarre to make that decision then. Worse yet to exclude them without warning, just silently drop them.
[15:10] <allenap> rvba: I’m not sure the call sites need changing… well, I don’t know. How do we get to a point where we have a node without a MAC address?
[15:11] <rvba> allenap: the only explanation I can see is that for some reason we know we can't power them up.  In which case it's logical to exclude them.
[15:11] <rvba> allenap: yeah, I know, that's why the whole thing is weird.
[15:11] <allenap> rvba: stop_nodes() doesn’t exclude nodes without MACs, only those where the power_info tuple has can_be_stopped=False.
[15:12] <rvba> allenap: right.
[15:12] <rvba> allenap: I'm temped to agree with you and get rid of it… but because I don't understand why we were doing this in the first place I'm a bit confused…
[15:12] <allenap> rvba: On one hand I want to remove it and see if anything happens.
[15:13] <rvba> gQuigs:  ~$ maas maas-mini-test maas get-config name=myconfig
[15:14] <gQuigs> rvba: oh, wow..  thanks!
[15:18] <rvba> allenap: I think we did this because get_primary_mac is used by get_effective_power_parameters
[15:19] <rvba> allenap: but there is support for when get_primary_mac return None
[15:19] <rvba> allenap: okay, let's get rid of it.
[15:21] <allenap> rvba: Cool.
[15:21] <allenap> rvba: Thanks, by the way. It’s good to have these kinds of discussions :)
[15:23] <rvba> allenap: heh, you're welcome :)
[15:34] <roaksoax> rvba: isn't the primary mac also for networking?
[15:35] <roaksoax> rvba: we only do mapping for primary mac
[15:35] <roaksoax> for DNS
[15:39] <rvba> roaksoax: no, we populate the DNS with what's in the staticIP table. And this is, in turn, uses the MAC on the managed interface.
[16:02] <roaksoax> rvba: ok