[00:06] damn, need to do something about the slow tests in maasserver [00:07] bigjools: alright, all yours: [00:08] bigjools: https://code.launchpad.net/~andreserl/maas/maas_ipmi_autodetection/+merge/127911 [00:08] ok [00:09] * bigjools slaps apt [00:09] alright, I'm off [00:09] it is being a long day [00:09] ttyl [00:09] cheers [00:14] roaksoax: Oh wait! [00:19] bigjools, i was looking at that signal stuff [00:20] am i right that WORKING messages just get sent to /dev/null ? [00:26] i'm not really here, but our the idea was to have enlistment set up a new user in ipmi [00:26] and post that home [00:26] but in enlistment we don't have any creds. [00:26] ie, in enlist we'd create a temporary user 'maas-commissioning' in the ipmi and a password and such. [00:26] maas would then use that creds for commisioning and would wipe it after that. [00:27] that way, you always know that 'maas-commisioning' user is not intended for anything [00:27] and can be thrown away. [00:27] and after 'accept', its ok to trash the 'maas' user that might have been there. [00:27] and now, i'm gone [00:27] good night. [00:33] we can add power parameters to the enlistment API call [00:33] then you can do what you like === matsubara is now known as matsubara-afk [02:19] matsubara-afk: if you are around, for bug #1061286, what value did you enter into juju? (was it an integer or a decimal)? 'cpu_count' should be an integer, so I'm wondering who is converting it (or maybe you just entered 1.0 yourself) [02:19] Launchpad bug 1061286 in MAAS "juju bootstrap returned ERROR Invalid 'cpu_count' constraint '1.0'" [Critical,Triaged] https://launchpad.net/bugs/1061286 [03:19] bigjools: I addressed smoser's suggedstions, could you please :)? https://code.launchpad.net/~andreserl/maas/maas_ipmi_autodetection/+merge/127911 [03:24] roaksoax: you might as well land it, I'll approve. It's hard to make suggestions at this stage because anything I would change would be quite substantial I think. I don't want to block you. [03:27] bigjools: alright, may I ask what you see wrong with it? :) [03:33] no tests for starters :) [03:33] nothing fundamental, I'd just structure it very differently based on TDD [03:37] bigjools: right, but there's things that might be more difficult than others to have tested, maybe this is the case, maybe not [03:37] * bigjools → lunch [03:37] it's hard time-wise at the moment but we'd be very happy to help with that [04:25] roaksoax: I think the big thing is that if you refactor into small functions, then you can test the functions in isolation, rather than trying to test one-big-main function. [04:34] bigjools: if you're back from lunch, 'make sampledata' is failing because NodeGroup doesn't match. Was there an obvious change recently to fix that? [04:39] it appears that the 'master' nodegroup hasn't been defined? [04:39] though I can see it... :( [04:47] so, if I change all of the references to [master] to be 1 (the number of the master nodegroup) it works fine [04:47] I'm guessing whatever query it is supposed to be doing is querying on the wrong field? [05:20] bigjools: it looks like 'get_by_natural_key' changed from being the nodegroup's name to being the nodegroups UUID, but the sampledata wasn't updated [05:22] or maybe it has always been uuid, but the uuid used to be 'master' as well? [05:22] rvba seemed to do that change, I'll try to bring it up with him [05:56] jam: yeah it'll be rvb's change [05:56] bigjools: it looks like he did that Sept 10th, seems odd nobody would have noticed since then. [05:56] Should we be adding 'make sampledata' to the Jenkins run? [05:57] jam: we're obviously not depending on sampledata. Which is good :) [05:57] well, *I* use it for manual testing but yeah I agree with the basic premise [07:05] rvba: can you look at https://code.launchpad.net/~jameinel/maas/sampledata-nodegroup/+merge/127936 [07:05] it seems your NodeGroup changes broke the sampledata code. [07:07] jam: ok [07:12] rvba, allenap: Via the API, how does MAASClient send a list? Do you json.dumps() it and pass it as value=JSON_STR or do you pass it just as value=list and the list get URL encoded into the parameters? [07:14] jam: your change seems to be reasonable but nothing should be broken right now: when the sample data is loaded, the uuid of the master node group is 'master'. It's changed to a proper uuid only when the (master) cluster controller connects to it. What kind of breakage did you see? [07:17] rvba: 'make sampledata' for me fails with a NodeGroup matching query does not exist. [07:17] jam: on trunk? I don't get that failure :/ [07:17] rvba: and if I look at bin/database shell I see that the nodegroup has a real UUID [07:17] I see, the master nodegroup uuid has been changed. [07:17] rvba: how do you make sure the db is fully clean? isn't that what 'make sampledata' is doing? [07:18] And you try to reapply the sampledata. [07:18] I did run 'make distclean' in the middle. [07:18] rvba: well, this is in a tree that I have done work it and done a run in the past, and I'm trying to bring in new sampledata, yes. [07:18] I'm fine nuking it [07:18] but 'make distclean' didn't seem to do that. [07:20] You should not have to nuke it to load the sampledata. [07:22] rvba: sure, which is why using 'id' which doesn't change makes it easier :) [07:24] Right, the only problem is that you're now relying on the fact that the master nodegroup has id 1. That is reasonable but it's still implicit. [07:26] This nodegroup is created by ensure_master(). [07:37] jam: I've been doing rm -rf db [07:37] rvba: well, if you are changing the UUID we can't trust that, and that is the current 'natural' key. [07:38] w7z: well, with the patch I mentioned, it works whether you rm or not [07:38] w7z: also, don't you need to kill postgres before you delete the dir? [07:38] jam: true, that's why I've approved your branch. [07:39] rvba: yeah, I would be happy to comment it, but since that isn't possible either :) [07:39] well, maybe it is [07:39] jam: a better solution would be to have the masternodegroup in the sample data as well with an explicit id=1. [07:40] Instead of relying on ensure_master to create it with the right id. [07:40] But I'm probably nitpicking here. [07:47] jtv: I'm not sure if https://bugs.launchpad.net/maas/+bug/1061409 is the cause of commissioning getting blocked or not, I hack a fix in and it still blocks but I can't tell if it blocks in the same place [07:47] Ubuntu bug 1061409 in MAAS "upload_dhcp_leases runs even when interface is unmanaged" [Critical,Triaged] [07:47] oops wrong bug [07:47] ubot you suck [07:48] Ahem. You're blaming the wrong bot. [07:48] that bug is "MAASAPINotFound: Unknown metadata attribute: public-keys during commissioning" [07:49] I think the fix would be: if there are no SSH keys, return a success response that does not contain any keys. [07:49] That particular API doesn't use JSON, so AFAICS an empty string would be the appropriate response. [07:50] I hacked it to return "" [07:50] Right. [07:50] Same error, or different one? [07:50] commissioning hangs for me still but like I said I can't tell if it's the same :/ [07:50] w7z: there is a bug matsubara just opened about getting a failure trying to commision passing cpu_count [07:50] I tried it locally, and couldn't reproduce (without juju in the loop.) [07:50] Is that the one where cpu_count is 1.0? [07:50] jtv: yes [07:50] w7z: can you look into it? [07:51] I would guess that's unrelated. [07:51] heh... that's interesting [07:51] w7z: bug #1061286 [07:51] Launchpad bug 1061286 in MAAS "juju bootstrap returned ERROR Invalid 'cpu_count' constraint '1.0'" [Critical,Triaged] https://launchpad.net/bugs/1061286 [07:52] w7z: note that I can try 'masscli api m nodes acquire cpu_count=1.0' and it just tells me there are no nodes to acquire, but doesn't give me an InvalidConstraint failure. [07:52] what's the least stupid way of fixing that? changing int(n) to int(float(n))? [07:52] w7z: read the bug [07:52] do we want to allow float? [07:52] if so, do we want to round? [07:53] what should be happening if you pass something like 'abcda' [07:53] we want it to fail sanely as much as possible [07:53] looking at the report, diogo had a traceback, but it looks like that was just in the log [07:53] ah, your comments covers some stuff [07:53] it may not have been reported as anything other than BAD_REQUEST [07:53] right, answer to 1) is everything corretly happened [07:54] the juju output is good, and I think the maas log is just being thorough [07:54] can fix in juju maas provider and make maas more liberal [07:54] w7z: what is weird is that when I use 'maascli' I don't get InvalidConstraint [07:55] w7z: where did the 1.0 come from? Is that just the default for 'cpu' ? [07:55] yup. [07:55] w7z: which means this is critical to fix, since it breaks everyone :) [07:56] it's trivial at least [07:57] bigjools: is it possible that you get a traceback on the server if there are no SSH keys *but* the client just shrugs it off and moves on, and then hangs for unrelated reasons, with or without your fix? The bug as originally reported didn't seem to affect enlistment at all -- it was really just an annoying but otherwise harmless traceback in the server logs. [07:57] jtv: that is entirely possible [07:57] if asked, I'd have said int('1.0') returned 1... [07:57] the original bug was commissioning too, not enlistment [07:58] Strange. I saw that in the title, but the description said enlistment. [07:58] jam: if diogo wants to go again, he can set the cpu constraint to something else... I don't think it gets auto floatified [07:58] right, time for me to leave [07:58] I thought all numbers got floatified in JS. :) [07:58] Just like in good old Sinclair BASIC. [07:59] And probably a few others that I didn't bother with as much. [07:59] they do, but fortunately they're porting juju to go, not js :D [08:02] jtv: commissioning is grabbing meta data then hanging [08:03] user-data is last thing it grabs [08:03] I guess the server logs would tell you whether that succeeded. [08:03] then sits at a login prompt on the console [08:03] Login prompt? Hmmm [08:04] I guess the node's status in the DB stays COMMISSIONING? [08:04] yes [08:04] something going wrong in cloud-init I guess [08:04] Or the commissioning script? [08:05] yeah [08:21] jam: Sending a list is the same as sending multiple values in a query string: var=value1, var=value2, etc. Is that what you were after? [08:24] allenap: right, do I send it as a list, or do I json.dumps it first, sounds like I just send a list [08:34] jam: Yeah, just send a list. [08:35] jam: Now... I stumbled across something in Piston a while back... it looked like it might be able to accept JSON or YAML in place of multipart/form-data request bodies (pickle too, but they has wisely disabled that). [08:48] mgz: you're at gavins? [08:49] bigjools: hangout URL? [08:49] jam: at david's, gavin will be here this afternoon as well [08:49] but I may have trouble getting on hangout [09:02] mgz: want to join up on mumbel? [09:02] jup [09:11] mgz: https://code.launchpad.net/~jameinel/maas/tag-updating/+merge/127962 [09:12] ta [09:14] hey guys I am still have problem with my maas and I am maiking fresh instalation of maas. I want make my server work with existing DHCP server on my router, how can I do this? [09:14] In install tutorial is only say how "Set up a fresh DHCP server to work with MAAS." [09:14] Fajkowsky: you have to set it up so it works for PXE booting [09:14] so add next-server and filename settings [09:15] next-server= [09:15] filename=pxelinux.0 [09:15] so I will have two maas servers? [09:15] no [09:15] you need to tell the existing DHCP server to pxe boot via your maas server [09:16] my router will that know? [09:16] ok [09:17] you need to configure your routers dhcp settings [09:18] mgz: I think you broke juju [09:18] juju deploy doesn't work against maas [09:18] ok I try do this [09:21] bigjools: see discussion earlier [09:21] mgz: on here? [09:21] mgz: I don't see any error, it says it was successful but no nodes are allocated at all [09:22] do --constraints="cpu=1" [09:23] it's an unfortunate aspect of juju design that errors from deployment don't get reported back to the client in any sane manner [09:23] you should see one from bootstrap though, so I guess you already had an earlier environment bootstrapped? [09:23] bigjools: I still don't understand something. How can I add next-server? [09:24] mgz: I saw no errors from bootstrap [09:24] mgz: deploy just gives me instance-id: pending but I don't see even an "acquire" call in the maas log [09:24] ...I wonder if that's the same bug then... [09:25] Fajkowski: I don;'t know, you have to read your router's manual and see if it supports PXE [09:25] ok [09:25] mgz: indeed. this is version 0.5.1+bzr566-1 of juju [09:26] okay, not bug 1061286 and I claim innocence until proved otherwise :D [09:26] Launchpad bug 1061286 in MAAS "juju bootstrap returned ERROR Invalid 'cpu_count' constraint '1.0'" [Critical,Triaged] https://launchpad.net/bugs/1061286 [09:26] mgz: it's not that one no :) [09:26] this is weird nonetheless [09:27] bigjools: But there is option to install on "Existing DHCP server you don't control." [09:27] bigjools: so, the steps here are #1 run juju with -v and see if that gives more details [09:28] Fajkowski: that just means that you have to configure an external DHCP server [09:28] #2 use nova client to see if a machine got booted at all [09:28] #3 if so, ssh on and look at cloud-init and juju logs in /var/log for clues [09:29] mgz: it's not getting anywhere near that far [09:29] mgz: there's simply no "acquire" call being passed to MAAS's API [09:30] yet juju decides it got allocated a node. Bizarre. [09:30] so, just #1 then. [09:30] yup [09:30] but maybe the logging in the maas provider isn't helpful, and you need to hack a little more in [09:30] possible yeah :/ [09:30] but not sure why this would suddenly break [09:43] bigjools: any luck? the juju version you're using does not even have any of the maas provider changes, so I don't have any clever guesses [09:43] mgz: yeah I just worked that out. Not really getting anywhere, so trying from square 1 [09:44] poke me if I can help with anything [09:44] mgz: thanks [10:28] Reviewers needed! https://code.launchpad.net/~jtv/maas/bug-1058282-ditch-api/+merge/127959 [10:30] jtv: the branch name scared me when I got the email, but code looked good :) [10:31] mgz: I go for shock value [10:31] BOOM!! [10:33] jtv: is there a plan on profile name too? [10:35] Yes. It'll have to work like juju: there is one, default profile -- until you define a second one and then you must still specify one each time. [10:35] juju does have an envvar to back that up now as well [10:35] which is less annoying than -e all the time [10:37] Funny, that's exactly what I just outlined myself. [10:37] But time is short. [10:49] mgz: so, no nearer to finding anything out. I added full logging on maas and there's no request to even allocate a node! Yet it thinks it has got one ... [10:49] I suspect a nasty juju bug as there's some stale data hanging around somewhere [10:50] jtv: could you please have a look at https://code.launchpad.net/~rvb/maas/bug-1061409/+merge/127979 [10:51] jtv: I'll review the branch you just pupt up for review. [10:51] OK [10:51] ta [10:51] My system's not very responsive at the moment, which may complicate things. [10:51] bigjools: and the juju client logging isn't anything useful? I'd add things there [10:52] mgz: I gotta try and remember my way around it :( [10:55] bigjools: I'd suggest branching lp:juju then adding some log calls in juju/providers/maas/ maas.py and maybe launch.py then `python setup.py install --local` [10:57] yep [11:16] mgz: .... it's not even calling start_machine .... ! [11:16] * bigjools boggles [11:17] Does it assume that's already done!? [11:18] bigjools: my guess, you have some stale values in the file storage? [11:18] mgz: I destroyed env.... still does it. [11:18] but that could be it [11:18] what does a full list on maas's file-ish backend give? [11:18] reluctant to destroy again since it means waiting for a node to install [11:19] because this seems like a bug that would be worth fixing [11:19] don't destroy, just list the file stuff [11:20] just loads of files from today [11:23] mgz: two charm files, bootstrap-verify and provider-state. Seems normal. [11:24] * jtv reboots in hopes of a better system [11:31] mgz, how do I get round the contraints bug on bootstrap? [11:31] and wb :) [11:34] bigjools: so, as I was trying to say before network bounced me, bootstrap-verify and provider-state are what we need to know the contents of [11:34] bigjools: so, as I was trying to say before network bounced me, bootstrap-verify and provider-state are what we need to know the contents of [11:34] and my constraints work around doesn't work, but I'm submitting a juju fix now that you can pull in [11:34] I went back to system juju for now [11:36] * bigjools relocates [11:36] bigjools: so, inbetween all my dropping there, did you find an answer to your original mystery? [11:37] I'm just submitting a juju-side fix now, network-permitting [11:39] mgz: no :( [11:41] (third attempt) so, as I was trying to say before network bounced me, bootstrap-verify and provider-state are what we need to know the contents of [11:44] unfortunately they are no more :( [11:51] Daviey: are you currently able to run commissioning successfully? It is hanging for me. [11:52] bigjools: I haven't tried. Want me to? [11:53] Any news on where it hangs? [11:54] Daviey: it would be useful to confirm or deny my setup, thanks [11:54] Daviey: use latest daily package [11:54] jtv: I see metadata requests, then the console hits the login prompt [11:54] and that is it [11:55] And no "signal" call. :( [11:57] bigjools: i can only really test it on garage lab atm, which i'd rather avoid. [11:57] Daviey: figures :) [11:57] I'll soon have access to a rig in bluefin [11:59] mgz: so even after destroy-environment and wiping all filestorage on maas, it is still failing to acquire a node on deployment ! [12:07] roaksoax: please could you take a look at bug 1061547? [12:07] Launchpad bug 1061547 in MAAS "maas-import-squashfs: line 47: RELEASES: unbound variable" [Undecided,New] https://launchpad.net/bugs/1061547 [12:30] bigjools: I'm ready to start doing the maasserver side of farming work out to celery workers. You mentioned there should be lots of tests to crib from [12:31] however, there is only 1 test that 'uses_rabbit_fixture' [12:31] and it is disabled because it broke the test suite in other places. [12:31] celery fixture [12:31] not rabbit [12:32] bigjools: ah ok, lots of CeleryFixture [12:32] :) [12:34] Any reviewers around? https://code.launchpad.net/~jtv/maas/bug-1058282-ditch-api/+merge/127959 [12:35] jtv: poking allenap at that now [12:35] jtv: why 'pardir' repeated, instead of 'dirname()' repeated? [12:36] Because it doesn't expect me to nest. [12:36] Thanks mgz, but I think jam's already looking [12:36] technically, I think he was looking first :) [12:37] smoser: hi - commissioning is currently hanging for me after getting metada, have you seen this? [12:40] jtv: this does mean that the names people login with potentially collide, doesn't it? [12:40] maascli $LOGIN do stuff [12:40] so if we add a module 'foo' [12:41] and somebody called their login 'foo' [12:41] it would be ambiguous [12:41] I'm willing to have people deal with that (or re-add 'api') once we actually support it, though. [12:41] [You could select non-api via an option instead of an argument, for example] [12:41] [maascli --mod=api $LOGIN do stuff] [12:41] If we do add another module, api will be the default. In other words, there'll be some way of selecting another module explicitly if you want one. [12:42] If you look at the MP, it says that "api" is a sensible default even if we add more modules. [12:42] roaksoax: also bug 1061577 [12:43] Launchpad bug 1061577 in MAAS "IPMI configuration on highbank appears to fail" [Undecided,New] https://launchpad.net/bugs/1061577 [12:43] jam: selecting another module would probably happen through an option. The fact that we can also come up with wrong ways to do it doesn't affect us much. :) [12:49] Thanks jam! [13:03] mgz: found the source of the fault in the provisioning agent log: http://pastebin.ubuntu.com/1259905/ NFI why that happens though [13:04] ah, this looks fun [13:07] guess blame ipv6? [13:07] error looks like when trying to resolve the maas api endpoint at any rate [13:08] so, try doing that outside of juju, using twisted, see if you can get the same failure [13:14] rvba, bigjools: So I have a test that properly triggers calling the provisioningserver, however, all my tests are failing while the task code is trying to call back to the API [13:14] (getting a urllib2.open error) [13:14] I'm calling NodeGroup.objects.refresh_workers() [13:15] because if I don't, I get failures that we don't have credentials to contact the maas_url info [13:15] jam: you probably have to patch the method that calls back to the API so that it talks to the test API. [13:16] rvba: so... how do I actually test that the api calls are valid? [13:16] if I patch both side [13:16] then I'm not actually testing the thing, you know, works [13:16] jam: you won't patch it entirely, probably just the url used will be enough. [13:16] rvba: so there is a test service running? [13:16] what URL do I need to use? [13:16] mgz: what makes you say ipv6? [13:17] (I can certainly set the maas_url to whatever we want) [13:17] I would have thought the tests were already doing that, in fact. [13:17] jam: well, you need to simulate what self.client is doing. [13:18] jam: more precisely, patch the thing that calls the API with self.client. [13:18] rvba: well MAASClient has a different api than self.client [13:19] specifically, test.client takes {'op': ...} but MAASClient takes 'op' as a regular argument. [13:19] What do you mean 'a regular argument'? [13:20] rvba: In a test case you do: self.client.get(PATH, {'op': x, arg1: y, ...}) [13:20] in MAASClient you do client.get(PATH, x, arg1=x, arg2=y...) [13:21] MAASDispatcher.dispatch_query looks like it can be patched to use self.client instead of urllib2.Request [13:21] def dispatch_query(self, request_url, headers, method="GET", data=None): [13:23] jam: is that enough to get you going? AFAIK we haven't done that before. I'm happy to help you with your branch, especially if you have failing tests I can work on. [13:24] rvba: well lots of things failing because the nodegroup workers can't talk back to the api, but I think I can poke at it for a bit. [13:24] Ok, cool. [13:25] bigjools, did you get it resolved? [13:25] smoser: no :( got distracted trying to debug juju problems [13:25] smoser: I can debug with you now if you can help? [13:25] what is "hangs" [13:25] do you have any console log ? [13:26] it doesn't complete - I see metadata requests, then it gets to the login prompt on the console and that's it [13:26] the other VTs have nothing on them either [13:28] Do we still tell the nodes to use the region controller as a log server? If so, you may find logged information on the server. [13:29] we do actually [13:31] not sure it's used during commissioning; at least I can't see any commissioning logs [13:31] :/ [13:31] I will try again [13:35] bigjools, sorry for being dense. https://code.launchpad.net/~smoser/maas/preserve-sources-list/+merge/127825/comments/275328 [13:35] "untick" [13:35] but reguarding login prompt. thats expected. [13:35] ttyS0 (serial console) will have log [13:35] smoser: uncheck [13:35] you can change command line parameters on the kernel to remove ttyS0 [13:35] where is "uncheck" [13:36] i'm sorry. [13:36] its probably obvious. [13:36] smoser: click the green "extra options" and it opens up more text [13:37] and then uncheck "needs review" [13:37] it'll create the MP in WIP status [13:37] which prevents a diff being emailed out, primarily [13:38] hm.. wel i actually would have liked ot have the diff mailed out :) [13:38] bigjools, primarily i'm interested in comments on the test that is there. [13:38] smoser: well you created the MP and then changed it to WIP :) [13:38] bigjools, as i didn't want someone to "approve" just yet [13:38] ok so if you do as I mentioned, changing the status to "ready" later will send the email [13:39] anyway [13:39] I need to remove ttyS0 then ... [13:40] rvba: so there is another impedence mismatch. django.test.client.Client.get() returns python objects, while MAASClient.get() returns a string [13:41] actually, I might be wrong [13:41] I am wrong [13:41] bigjools, i have another solutoin to get some output on a tty [13:42] that i thought of yesterday when diego complained about the same thing. [13:42] fwiw, i still thikn 'console=ttyS0' is the right default. [13:42] smoser: it seems to have tty1 as default too though [13:42] both, I mean [13:42] You still might have to change to result of client.get/post so that it matches whaturllib2.urlopen returns. [13:42] jam: ^ [13:42] for any thing other than 3 systems, ttyS0 has a chance of being logged and remotely viewable, and graphics console has exactly zero percent chance of being logged. [13:42] yes [13:43] bigjools, right. if there is no ttyS0 device, then kernel goes to tty1. [13:43] (and kernel puts kernel messages on both) [13:43] but /dev/console ends up as the last valid entry on the cmdline [13:43] and messages from cloud-init are going to /dev/console [13:43] rvba: yeah, urlopen returns a file-like object that has a .status_code and a .content [13:43] rvba: but that looks a whole lot like what Client.get returns [13:44] Indeed. [13:44] I imagine they are both based on Httplib's response object. [13:44] smoser: will it rsyslog in commissioning mode? [13:45] it does not rsyslog to maas server. [13:46] we could make that happen, but cloud-inti woudl have to read the cmdline params to set up syslog. and it does not support that. [13:46] bigjools, theo ther thing we can do is that cloud-init can do python logging [13:46] and we can feed it a config file for that [13:46] via user-data [13:46] the simpler thing right now is: [13:46] http://paste.ubuntu.com/1259976/ [13:46] that will get you data on tty2 [13:46] well, more data. [13:47] ok I'll do that in 5 mins [13:50] mgz: so in another twist, I restarted the PA on the ZK node and now it works. WTF! [13:53] o_O [13:54] rvba: ok, so the return signatures sanely overlap,however the arguments do not. [13:54] rvba: MAASDispatcher wants 'data' which is already an encoded_multipart_data [13:54] where some arguments may be in the URL [13:54] and some are in the data itself. [13:55] so we have to parse everything back out of the data [13:55] to get it into a form to pass to a Django.Client.get() [13:55] I think I have to go up a level to MAASClient, and just curry argument parameters. [13:56] * rvba has another at MAASDispatcher. [13:56] another look* [13:57] rvba: dispatch_query takes a 'data' parameter, which is already encoded as multipart mime [13:57] Are you trying to build a dispatcher based on the django client? [13:57] Yep, that's what he's trying to do. [13:57] I tried that once, but the mismatch was great enough to make it a losing proposition. [13:58] jtv1: the provisioning server needs to talk to the api to get work done [13:58] It does, yes. [13:58] Well, that's basically what you're trying to do now, isn't? [13:58] Are there credentials I can pass it so it can just do it [13:58] or do we need to use the testing client and proxy it. [13:59] I'm thinking to not do the dispatcher, because it has already processed the data too much. [13:59] However, doing it at the MAASClient level looks more sane. [13:59] As you have to change some arguments [13:59] but the data is still in python-object form. [14:00] Time for me to bug out. See you all tomorrow. [14:00]