[09:22] <rvba> allenap: I'm trying to test some things but bug https://bugs.launchpad.net/maas/+bug/1365742 is getting in the way.
[09:23] <rvba> I'm seeing http://paste.ubuntu.com/8325785/ over and over.
[09:23] <rvba> What does the "No exception type: No exception value" error mean?
[09:23] <allenap> rvba: Okay, I’ll look at that now.
[09:24] <rvba> allenap: Ta, I'm happy to help (I really need this solved).  Let's work together on this.
[10:07] <rvba> allenap: any idea what might be wrong?
[10:08] <gmb> allenap: When you’re done helping rvba, do you have time to chat about serialising power commands? (This is the thing that Kiko reckons needs Face Time. I’m not so sure…)
[10:10] <allenap> rvba: Nope, not yet. I’m going to try and reproduce it on my NUCs. Or can I reproduce it in a dev environment?
[10:11] <allenap> gmb: Yes indeedee.
[10:11] <rvba> allenap: I think you need real systems.
[10:11] <allenap> Here’s one I prepared earlier...
[10:13] <rvba> allenap: I put debugging statements everywhere in send_event_node (src/provisioningserver/events.py) and I can see that everything looks normal: no need to register the event type (because it already exists) and I still see the exception in pserv's log!
[10:20] <gmb> allenap: Cool. Ping when free, then.
[10:55] <rvba> allenap: https://bugs.launchpad.net/bugs/1368685 … weird, never seen this…
[11:15]  * gmb -> lunch
[11:24] <allenap> rvba: I can’t reproduce https://bugs.launchpad.net/maas/+bug/1365742 now.
[11:24] <allenap> rvba: What do you do?
[11:24] <rvba> allenap: I just uninstall amtterm and commission nodes.
[11:43] <allenap> rvba: I think I see what it might be. Try applying http://paste.ubuntu.com/8326460/ to a branch and running bin/test.pserv.
[11:43] <allenap> rvba: The power commands mix synchronous and asynchronous code and get it slightly wrong.
[11:44]  * rvba reads the docstring of the 'synchronous' decorator.
[11:48] <rvba> allenap: the decorators are just belt and braces right?  The real changes are 'yield' and 'wait' correct?
[11:48] <allenap> rvba: They are, yes, though the asynchronous decorator does automatically use crochet when calling an async function from outside of the reactor.
[11:49] <rvba> allenap: all of this code runs in pserv… why is crochet involved at all?
[11:55] <allenap> rvba: It shouldn’t be in pserv; that’s really for the benefit of the region. That’s what alerted me to this problem, because I saw mention of EventualResult in pserv.log.
[11:57] <rvba> allenap: why shouldn't it be in pserv?  The cluster is in charge of all the power-related operations.  Then it reports back to the region via RPC.
[11:57] <allenap> rvba: Fwiw, the crochet functions run_in_reactor and wait_for_reactor are okay to use in pserv, though they’re not needed much. We just don’t want to use crochet to start up the reactor there.
[11:57] <allenap> rvba: I mean crochet shouldn’t be used (much) in pserv.
[11:57] <rvba> My understanding was that crochet was only there as a bridge between Django and twisted.
[11:58] <allenap> rvba: It’s a bridge between any threaded code and the reactor.
[11:59] <allenap> rvba: So if, say, a power action in pserv needs to use RPC, it’s find to use crochet.run_in_reactor, say.
[11:59] <allenap> s/find/fine/
[12:00] <rvba> allenap: so: reactor → threaded code using deferToThread and to talk *back* you can use crochet?
[12:02] <rvba> allenap: back to the point, why did you say this shouldn't be in pserv?  I really don't understand.
[12:14] <allenap> rvba: I saw “Unhandled error in EventualResult” in pserv.log. EventualResult is part of crochet. But send_event_node must clearly be run in the reactor… if it’s run outside of the reactor the `yield client(…)` bits would be returning EventualResult objects, which inlineCallbacks doesn’t recognise and wouldn’t wait for; it would then proceed
[12:14] <allenap> straight onto the next `yield client(…)`. At that point there’s a race.
[12:15] <rvba> allenap: okay, I misunderstood what you said.  To me, "not in pserv" means "not in the cluster", i.e. in the region.
[12:15] <allenap> rvba: In other words, both of those client(…) calls in send_event_node would be called in very quick succession, and nothing would be waiting for the first (or the second) call to complete.
[12:16] <rvba> allenap: yeah, I get it now.
[12:16] <allenap> rvba: Cool. I don’t mind fixing it, unless you’re desperate to do it?
[12:17] <allenap> gmb: I’m going to have a quick lunch. Want to talk right after that?
[12:17] <rvba> allenap: You already have a diff, I'll test it… maybe you can put the branch together in the meantime.
[12:18] <allenap> rvba: Okay. I hope the diff fixes it :)
[12:18]  * allenap goes for lunch
[12:47] <gmb> allenap: I’m free from now until ~14:15, then I’m getting on a train, so whatever works for you :)
[12:51] <rvba> allenap: looks like your diff fixes the problem.
[13:30] <allenap> rvba: \o/
[13:31] <allenap> rvba: Want to review it? :) https://code.launchpad.net/~allenap/maas/rpc-power-sync-async-mix-up/+merge/234465
[13:33] <rvba> allenap: nice; why don't we need run_tests_with = MAASTwistedRunTest again?
[13:47] <allenap> rvba: The ones that use the IOPump don’t touch the reactor. Some of them used that so they could return a Deferred and let the test runner figure out if there was a failure, but the Deferred had all fired so I used extract_result() to check them.
[13:49] <allenap> blake_r: Are you going to resurrect your work on the report_boot_images task?
[13:58] <roaksoax> allenap: he is away to day unfortunately
[14:02] <allenap> roaksoax: Okay, I’ll see if I can find his work and finish it off.
[14:04] <roaksoax> allenap: thanks! I see he has just one branch left!
[14:07] <roaksoax> allenap: although, I'd say you should finish the update_node_tags card first though
[14:07] <allenap> roaksoax: Agreed, that’s what I’m working on now.
[14:07] <roaksoax> allenap: perfect! tha nks
[14:14] <rvba> allenap: doing another round of testing now that your code has landed.
[14:34] <roadmr> roaksoax: ok, it's for that provisioning project we discussed a while back. I have an ubuntu desktop image that can be installed with curtin, now I'd like to be able to select it for maas to install it on a node
[14:36] <roadmr> roaksoax: I poked a bit at things and I'm not sure if I have to just drop the image somewhere in the maas server, or if I have to provide a more complex structure (simplestreams, a keyring, that stuff)
[14:37] <roaksoax> roadmr: you can just drop a curtin image in MAAS, and MAAS would install it
[14:37] <roaksoax> roadmr: the image would be a cloud image like, which smoser could provide more input on
[14:39] <roadmr> roaksoax: oh so the image needs some metadata or extra stuff?
[14:54] <roaksoax> roadmr: not really. The only thing that the image would need is just basically be like a cloud image
[14:55] <roaksoax> roadmr: smoser would have a better idea of what it needs in regards to curtin/cloud-init
[14:55] <roaksoax> roadmr: the thing is that once installed, cloud-init contacts the MAAS server to run final tasks
[14:55] <roadmr> roaksoax: oh I see... I already tested installing my image with curtin so that part is done, I'd need to look into cloud-init
[14:56] <roadmr> roaksoax: once the image is ready, where should I put it? I'm looking in /var/lib/maas/boot-resources, there's a lot of structure there so I'm wondering where it should go
[14:56] <roaksoax> roadmr: I think you'd just need to have cloud-init in your image
[14:56] <roaksoax> roadmr: if you are using MAAS 1.7, you would just be able to upload the image to MAAS via the CLI
[14:57] <roadmr> roaksoax: oh! well I'm not, but that can be easily remedied. /me upgrades
[14:57] <roadmr> roaksoax: (we get to dictate requirements, yay, so if MAAS 1.7 makes things significantly easier, we can just require that)
[15:01] <roaksoax> roadmr it does. you'd just need to upload an image and that's it. I'd recommend you talk to smoser for this
[15:03] <roadmr> roaksoax: I will! thanks! now let's see about upgrading this thing
[17:53] <fgiraldeau> Hello! I installed MAAS, and then defined a faster deb mirror. The setting in /etc/apt/sources.list is correct, but I was getting 403 Forbidden on the Package file while doing "apt-get update"
[17:54] <fgiraldeau> I had to change the setting in squid-deb-proxy, adding the new mirror in the file /etc/squid-deb-proxy/mirror-dstdomain.acl.d/10-default
[17:54] <fgiraldeau> and then service squid-deb-proxy restart to solve the issue
[17:55] <fgiraldeau> I think that changing the MAAS mirror setting in the web interface should add the mirror to the squid repo, otherwise it won't work
[17:55] <fgiraldeau> Shall I open a bug for that?
[19:25] <roadmr> roaksoax: ok, I got maas 1.7 up and running, how do I upload my image? I got maas (cli) setup and logged in. If there's a doc describing this, I'm happy to dive in and read it
[20:55] <kiko> hey there
[20:55] <kiko> I've got a maas install from experimental on trusty
[20:55] <kiko> and I can't get boot images to load
[20:55] <kiko> does anyone know a workaround for that?
[20:56]  * kiko looks at blake_r and roaksoax 
[21:03] <fgiraldeau> OK, well after checking, the bug about squid-deb-proxy is already reported: https://bugs.launchpad.net/maas/+bug/1300266
[21:30] <roaksoax> kiko: when you click on the webui it does not download the images?
[21:30] <roaksoax> kiko: try: maas admin boot-resources import
[21:30] <kiko> will do
[21:30] <roaksoax> kiko: and check progress wiht: maas admin boot-resource read 1 | grep progress
[21:31] <kiko> oh nice
[21:31] <roaksoax> kiko: all the functionality is there, we just have to make it available in the WebUI
[21:32] <roaksoax> kiko: so that will donwload the images to the DB
[21:32] <roaksoax> kiko: and then it will tell the clusters to import the images