=== jfarschman is now known as MilesDenver === jfarschman is now known as MilesDenver === jfarschman is now known as MilesDenver === jfarschman is now known as MilesDenver === jfarschman is now known as MilesDenver === jfarschman is now known as MilesDenver === kickinz1|afk is now known as kickinz1 === jfarschman is now known as MilesDenver === CyberJacob|Away is now known as CyberJacob === jfarschman is now known as MilesDenver === jfarschman is now known as MilesDenver === jfarschman is now known as MilesDenver [09:22] allenap: I'm trying to test some things but bug https://bugs.launchpad.net/maas/+bug/1365742 is getting in the way. [09:22] Launchpad bug 1365742 in MAAS "Logged OOPS ... NoSuchEventType: Event type with name=NODE_POWER_ON_FAILED could not be found." [High,Triaged] [09:23] I'm seeing http://paste.ubuntu.com/8325785/ over and over. [09:23] What does the "No exception type: No exception value" error mean? [09:23] rvba: Okay, I’ll look at that now. [09:24] allenap: Ta, I'm happy to help (I really need this solved). Let's work together on this. === CyberJacob is now known as CyberJacob|Away [10:07] allenap: any idea what might be wrong? [10:08] 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] 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] gmb: Yes indeedee. [10:11] allenap: I think you need real systems. [10:11] Here’s one I prepared earlier... [10:13] 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! === kickinz1 is now known as kickinz1|afk [10:20] allenap: Cool. Ping when free, then. === jfarschman is now known as MilesDenver === jtv1 is now known as jtv [10:55] allenap: https://bugs.launchpad.net/bugs/1368685 … weird, never seen this… [10:55] Launchpad bug 1368685 in MAAS "After commissioning NUC reboots instead of shutting down" [High,Triaged] === kickinz1|afk is now known as kickinz1 [11:15] * gmb -> lunch === jfarschman is now known as MilesDenver [11:24] rvba: I can’t reproduce https://bugs.launchpad.net/maas/+bug/1365742 now. [11:24] Launchpad bug 1365742 in MAAS "Logged OOPS ... NoSuchEventType: Event type with name=NODE_POWER_ON_FAILED could not be found." [High,Triaged] [11:24] rvba: What do you do? [11:24] allenap: I just uninstall amtterm and commission nodes. [11:43] 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] 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] allenap: the decorators are just belt and braces right? The real changes are 'yield' and 'wait' correct? [11:48] rvba: They are, yes, though the asynchronous decorator does automatically use crochet when calling an async function from outside of the reactor. [11:49] allenap: all of this code runs in pserv… why is crochet involved at all? [11:55] 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] 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] 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] rvba: I mean crochet shouldn’t be used (much) in pserv. [11:57] My understanding was that crochet was only there as a bridge between Django and twisted. [11:58] rvba: It’s a bridge between any threaded code and the reactor. [11:59] 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] s/find/fine/ [12:00] allenap: so: reactor → threaded code using deferToThread and to talk *back* you can use crochet? [12:02] allenap: back to the point, why did you say this shouldn't be in pserv? I really don't understand. [12:14] 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] straight onto the next `yield client(…)`. At that point there’s a race. [12:15] allenap: okay, I misunderstood what you said. To me, "not in pserv" means "not in the cluster", i.e. in the region. [12:15] 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] allenap: yeah, I get it now. [12:16] rvba: Cool. I don’t mind fixing it, unless you’re desperate to do it? [12:17] gmb: I’m going to have a quick lunch. Want to talk right after that? [12:17] allenap: You already have a diff, I'll test it… maybe you can put the branch together in the meantime. [12:18] rvba: Okay. I hope the diff fixes it :) [12:18] * allenap goes for lunch === jfarschman is now known as MilesDenver [12:47] allenap: I’m free from now until ~14:15, then I’m getting on a train, so whatever works for you :) [12:51] allenap: looks like your diff fixes the problem. === jfarschman is now known as MilesDenver [13:30] rvba: \o/ [13:31] rvba: Want to review it? :) https://code.launchpad.net/~allenap/maas/rpc-power-sync-async-mix-up/+merge/234465 [13:33] allenap: nice; why don't we need run_tests_with = MAASTwistedRunTest again? === jfarschman is now known as MilesDenver [13:47] 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] blake_r: Are you going to resurrect your work on the report_boot_images task? [13:58] allenap: he is away to day unfortunately === cmagina_ is now known as cmagina [14:02] roaksoax: Okay, I’ll see if I can find his work and finish it off. [14:04] allenap: thanks! I see he has just one branch left! [14:07] allenap: although, I'd say you should finish the update_node_tags card first though [14:07] roaksoax: Agreed, that’s what I’m working on now. [14:07] allenap: perfect! tha nks [14:14] allenap: doing another round of testing now that your code has landed. === jfarschman is now known as MilesDenver [14:34] 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] 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] roadmr: you can just drop a curtin image in MAAS, and MAAS would install it [14:37] roadmr: the image would be a cloud image like, which smoser could provide more input on [14:39] roaksoax: oh so the image needs some metadata or extra stuff? [14:54] roadmr: not really. The only thing that the image would need is just basically be like a cloud image [14:55] roadmr: smoser would have a better idea of what it needs in regards to curtin/cloud-init [14:55] roadmr: the thing is that once installed, cloud-init contacts the MAAS server to run final tasks [14:55] 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] 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] roadmr: I think you'd just need to have cloud-init in your image [14:56] roadmr: if you are using MAAS 1.7, you would just be able to upload the image to MAAS via the CLI [14:57] roaksoax: oh! well I'm not, but that can be easily remedied. /me upgrades [14:57] roaksoax: (we get to dictate requirements, yay, so if MAAS 1.7 makes things significantly easier, we can just require that) [15:01] 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] roaksoax: I will! thanks! now let's see about upgrading this thing === kickinz1 is now known as kickinz1|afk === jfarschman is now known as MilesDenver === matsubara is now known as matsubara-lunch === matsubara-lunch is now known as matsubara [17:53] 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] 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] and then service squid-deb-proxy restart to solve the issue [17:55] 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] Shall I open a bug for that? === roadmr is now known as roadmr_afk === roadmr_afk is now known as roadmr === jfarschman is now known as MilesDenver [19:25] 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] hey there [20:55] I've got a maas install from experimental on trusty [20:55] and I can't get boot images to load [20:55] does anyone know a workaround for that? [20:56] * kiko looks at blake_r and roaksoax [21:03] OK, well after checking, the bug about squid-deb-proxy is already reported: https://bugs.launchpad.net/maas/+bug/1300266 [21:03] Launchpad bug 1300266 in MAAS "squid-deb-proxy returns 403 when admin configures a custom APT archive" [High,Triaged] [21:30] kiko: when you click on the webui it does not download the images? [21:30] kiko: try: maas admin boot-resources import [21:30] will do [21:30] kiko: and check progress wiht: maas admin boot-resource read 1 | grep progress [21:31] oh nice [21:31] kiko: all the functionality is there, we just have to make it available in the WebUI [21:32] kiko: so that will donwload the images to the DB [21:32] kiko: and then it will tell the clusters to import the images === Beret- is now known as Beret === CyberJacob|Away is now known as CyberJacob === beisner- is now known as beisner === ming is now known as Guest38185 === CyberJacob is now known as CyberJacob|Away