[09:02] <rvba> jtv: time for a tiny review? https://code.launchpad.net/~rvb/maas-test/unify-logging/+merge/201141
[09:03] <jtv> Coming...
[09:03] <rvba> Thanks.
[11:59] <jtv> rvba: ahem
[12:00] <jtv> To continue...
[12:00] <rvba> jtv: we've got multiple migrations, not just one.
[12:00] <jtv> That's fine, but the point is that if a migration creates the default zone, it needs to do so according to the prevailing schema at the time.
[12:01] <jtv> Not the schema as the model code sees it, which may have moved ahead.
[12:01] <rvba> Yeah, I know.
[12:01] <rvba> So?
[12:01] <jtv> Just saying we can't call the same get_default_zone() function from the migration and the regular code.
[12:02] <rvba> That's true, we need to duplicate that (tiny bit) of code.
[12:02] <rvba> As always with data migrations.
[12:02] <rvba> Well, the code will be initially duplicated.
[12:02] <jtv> OK, then that answers my question.
[12:02] <rvba> Later on, if the model change it won't be an exact duplicate.
[12:02] <rvba> changes*
[12:10] <rvba> jtv: definitely.
[12:10] <rvba> jtv: see what some people have done: https://github.com/brightinteractive/django-test-extras/blob/master/test_extras/testcases.py
[12:10] <rvba> jtv: see the  DataPreservingTransactionTestCaseMixin class
[12:11]  * jtv has toyed with the idea of 2pc for this, but restrained himself
[12:13] <jtv> (I think nowadays it would be possible to detect whether a test had modified the database, and skip the reset if possible — but I doubt it's quite worth the effort today)
[12:18]  * gmb lunches
[13:19] <rvba> Hi roaksoax.  Did you get a chance to have a look at the packaging problem I was referring to in the email I sent you the other day?
[13:29] <gmb> rvba, allenap: Can I get some love for a branch/ https://code.launchpad.net/~gmb/maas-test/revert-reporting-changes/+merge/201149
[13:29] <rvba> gmb: sure, I'll have a look now.
[13:29] <gmb> Cheers
[13:35] <allenap> rvba: Can you give me your thoughts on using something like https://github.com/petrounias/json-schema-toolkit for power_parameters validation?
[13:36] <rvba> k, having a look now.
[13:41] <rvba> allenap: looks a bit like what we already have for power_parameters validation.  Looks better integrated though.
[13:54] <allenap> rvba: I’m thinking about how drivers can share their power schema with the region, and I stumbled on json schema and then this project.
[13:55] <allenap> rvba: It would be best if we don’t have to install hardware drivers both on the cluster and region, which we would need if each driver has its own DictCharField (i.e. like in POWER_TYPE_PARAMETERS).
[13:56] <rvba> allenap: right, now I see what the problem is.
[13:57] <allenap> rvba: If you have time, can you estimate what it would take to try this out?
[13:58] <rvba> allenap: I'll have another look later today (I want to finish the AZ branch today).  But trying it out, once we know exactly what we're looking for, should be pretty easy.
[13:59] <allenap> rvba: Tip top, thanks.
[14:02] <allenap> rvba: Can you also think about json schema in general? This code isn’t packages, and neither are its dependencies, but we might be able to satisfy our needs with something lighter. For example, https://python-jsonschema.readthedocs.org/en/latest/ is in main already.
[14:04] <rvba> allenap: okay, I'll try to set aside some time to do that today.  If I don't make it, let's talk about this on Monday morning. Okay?
[14:04] <allenap> For example, could we translate a subset of json schema into DictCharField and co. at runtime?
[14:04] <rvba> Yeah, I understand that's the goal.
[14:04] <allenap> rvba: Yeah, that’s grand. I don’t mean to derail what you’re doing right now.
[14:04] <rvba> The schema would be defined on the cluster, and it would then send it to the region.
[14:05] <rvba> allenap: don't worry, I'm not letting anything derail me today.  I really wanna get rid of the AZ branch :).
[14:23] <gmb> allenap: Can you think of a nice way to get identifying information for a system, such that we can use it for de-duping mass-test reports? We don't want it to be too verbose, but it'd be nice to have something human readable.
[14:31] <gmb> lshw would seem to do the trick, but it's a bit wordy.
[14:36] <jtv> rvba: even a review won't derail you?  I have one pending and am working on a follow-up. :)
[14:38] <rvba> gmb: maybe a combination of the humanly-readable part of what lshw returns plus /var/lib/dbus/machine-id would do the trick.
[14:38] <gmb> rvba: Ah, I didn't know about /var/lib/dbus/machine-id. That'd be perfect. Thanks!
[14:42] <rvba> gmb: hang on, now that I think of it, /var/lib/dbus/machine-id being purely software-defined, it won't stay the same.
[14:43] <rvba> gmb: you need something hardware-dependent.
[14:44] <gmb> Damn.
[14:44] <rvba> gmb: maybe the main board product UUID, as set by the board manufacturer
[14:44] <rvba> i.e. /sys/class/dmi/id/product_uuid
[14:45] <gmb> rvba: That would work. However, another thought: we need to run this on the machine being tested... do we actually have any capacity to do that in maas-test?
[14:45] <gmb> I don't *think* we do.
[14:45] <rvba> Just one sec…
[14:46] <rvba> Yes, actually, gathering lshw output is part of the commissioning process.
[14:46] <rvba> All the info you need is in there.
[14:46] <gmb> Ahah!
[14:46] <gmb> Brilliant.
[14:46] <gmb> rvba: So that's fetchable from the MAAS instance?
[14:46] <rvba> Yep
[14:46] <rvba> All is in the db.
[14:46] <rvba> s/All/Everything/
[14:46] <gmb> Excellent, that's fantastic.
[14:47] <gmb> I'll get working on that now.