=== CyberJacob is now known as zz_CyberJacob [09:37] I'm seeing "cannot resume transactions: exception: Cannot apply $addToSet modifier to non-array" repeatedly in my machine-0.log. What could be the cause of that? Cf. http://paste.ubuntu.com/23445701/ [14:31] I just noticed a snap-layer and want to install a snap as a resource. I've not written a reactive charm before, and I'm not certain when a resource becomes available. what would I pass to the @when decorator? [14:31] '.available' [14:33] it's what I'd expect, but just checking [14:47] I'm having trouble bootstrapping juju2 with a local apt cache server [14:49] icey what appears to be the trouble? [14:50] lazyPower: hangs at Installing curl, cpu-checker, bridge-utils, cloud-utils, tmux [14:51] is the local apt cache powered by squid? if so, you can check the logs of the squid-deb-proxy [14:51] lazyPower: apt-cacher-ng [14:51] lazyPower: nothing in its logs either [14:51] are you seeing any hits in the log? [14:51] yeah, seems like there's potentially a misconfiguration? [14:52] lazyPower: listening on : tcp 0 0 0.0.0.0:3142 0.0.0.0:* LISTEN 13949/apt-cacher-ng [14:52] icey: presumably you have --debug ? [14:52] unless there's something stopping a lxd container from reaching a public interface on my host [14:53] icey: how are you bootstrapping? [14:53] admcleod_: fairly boring, --debug shows nothing after I kill it [14:53] jrwren: "juju bootstrap lxd lxd --config apt-http-proxy=http://10.0.1.99:3142 --config apt-https-proxy=http://10.0.1.99:3142 --debug" [14:54] icey: 10.0.1.99 does not seem right. [14:54] jrwren: that's one of the IPs for my current host [14:54] the one that lxd is running on [14:54] icey: ok. nevermind. [14:54] icey: can you ssh to machine 0 and curl http://10.0.1.99:3142 ? [14:54] jrwren: the bootstrap never finishes [14:55] * skay_ neverminds, figured out the way to do it. [14:55] jrwren: let me attempt to redeploy and lxc exec into it [14:55] icey: lxc list, find the bootstrap machine and ssh with: ssh -i .local/share/juju/ssh/juju_id_rsa ubuntu@ [14:55] icey: maybe just incase also try setting http- and https-proxy [14:57] jrwren: seems like the lxd machine can't see the host network?! I get failed to connect with curl [14:57] icey: That sounds like hte problem. Now to find out why that is the case? [14:57] jrwren: mtr has no problem though [14:58] icey: in the container? [14:58] jrwren: yeah [14:58] icey: is there an iptables rule now allowing 3142 from that network? [14:58] jrwren: probably not [14:58] icey: is this standard lxdbr0 network config? [14:59] jrwren: it was a few months ago when I installed everything ;-) [14:59] icey: instead of 10.0.1.99 address, try the address from lxdbr0? `ip addr show dev lxdbr0` [15:00] adding the iptables rule makes it work on the 1.99 address [15:00] the bridge address would probably make more sense [15:01] but I'm /trying/ to build a demo method that other users woulc use and connect back to my machine for the apt cache [15:01] icey: Then it must be a firewall rule? [15:02] actually it still didn't work -_- [15:02] http://pastebin.ubuntu.com/23446805/ [15:03] there was a bug about that already I think [15:03] regarding an iptables rule added for 8443 [15:04] icey: that is an entirely different error. juju can't talk to lxd there. [15:04] icey: is lxd running? [15:04] jrwren: yeah, but the fix is still to add an iptables rule... [15:05] sudo iptables -I INPUT 4 -i lxdbr0 -p tcp --dport 8443 -j ACCEPT [15:05] fixes it [15:05] icey: ok, sounds like you need the same thing for port 3142 on all interfaces. [15:05] icey: ubuntu doesn't default to a deny all iptables ruleset, AFAIK. I think you are somehow a bit off the rails. [15:06] jrwren: yeah, needed tro add 8443 to let juju talk to lxc, and 3142 to let juju talk to the apt cacher -_- [15:06] jrwren: I think it's from ufw ;-) [15:06] icey: must be. I'm surprised we don't have that better documented given how popular ufw is. [16:22] cory_fu: here's that matrix test I mentioned in the standup: https://github.com/apache/bigtop/pull/158 And here's a branch of python-libjuju that will get you to the point where you're broken like I'm broken: https://github.com/petevg/python-libjuju/tree/bug/bundle-deploy-issues [16:24] cory_fu: You said you can call charm push from a CI script. True. The ugly part is that you have to also login through SSO and 2FA, right? So your build bot will have to do that from inside the CI. You also mentioned something about the blueslib? Whta is that? [16:25] kjackal_: This is how we're dealing with the charm store login in the RQ: https://github.com/juju-solutions/review-queue/pull/54 [16:26] kjackal_: Basically, you create and save the SSO token and make sure you clear your go cookies and it handles the auth with the SSO token which never expires [16:33] cory_fu: Interesting, so you need to pass the oauth token at deploy time and thats it [16:33] Yep [16:35] cory_fu: Is there a rest call to get the oauth token or do you "steal it" from your local session? [16:36] tvansteenburgh: ^ [16:36] kjackal_: I'm not sure [16:36] kjackal: you steal it [16:36] :) thanks tvansteenburgh, cory_fu! We should make this official! [16:38] petevg: i looked at the branch you posted above [16:39] tvansteenburgh: if you're pointing out that I edited auto generated code, I know. Going to file an issue -- the branch is just to work through the exceptions I was running into ... [16:40] petevg: no, that's not it [16:40] tvansteenburgh: [16:40] Uh oh :-) [16:41] petevg: i was just gonna point out that those edits should not in fact be necessary. you should be able to just do this http://pastebin.ubuntu.com/23447159/ [16:41] (without editing the auto-generated code) [16:42] petevg: stuff gets serialized automatically before being put on the wire [16:42] obviously i don't know what error you're hitting, so there may be more to it, but i just happened to notice that part [16:42] tvansteenburgh: I think petevg's main point with the change was the `params = dict()` line [16:42] tvansteenburgh: whoops. I forgot the serialize thing was still in there. [16:43] Which overwrites the params passed in [16:43] Yeah. The prob is the circular reference. [16:43] oh i see [16:43] I think it's in fact a naming conflict. The parameter name conflicts with a local var in the generated code [16:43] The serialize is me naively trying to figure out why the go side still doesn't like what I pass in ... [16:44] petevg: It's because it really should be a nested dict with the params passed in under a 'params' key [16:44] Oh, nm, you had that part [16:44] Yep :-) [16:45] petevg: I don't understand why this is failing. I was able to deploy a bundle without hitting this [16:46] tvansteenburgh: Did you by chance regenerate _client.py? [16:46] no [16:46] How did this ever work for me, then? [16:46] cory_fu: i think that you specified more constraints. [16:47] And you don't have machine shenanigans in your bundle. [16:47] Basically, my bundle is fancier, and exercises more code :-) [16:47] petevg: The generated plan from deploying the bundle definitely had an "add machine" step in it, though. I remember it from debugging [16:47] what's the actual error? [16:48] My current guess is that I need to provide a default for 'series'. Am eating an early lunch, and am planning on testing after. [16:50] tvansteenburgh: Ack. Matrix clobbered my logs when I stopped it. It appeared to be a response from the Go side, claiming that I hadn't passed it something that it could unpack into a valid MachineParams object. [16:51] Running again. Will paste shortly. [16:53] tvansteenburgh Le error: juju.errors.JujuAPIError: json: cannot unmarshal object into Go value of type []params.AddMachineParams [16:53] yeah [16:54] Noisy matrix logs here, for the curious: http://paste.ubuntu.com/23447199/ [16:54] petevg: well since i have regen'd the client in a while, it's possible that the params have changed in juju [16:54] petevg, tvansteenburgh: What do you think of this? https://github.com/juju/python-libjuju/pull/5 [16:54] have not regen'd rather [16:55] tvansteenburgh: Ooh. That would make sense ... [16:56] cory_fu: that def looks like a plausible fix for the circular reference issue. [17:04] petevg: that doesn't appear to be the problem. gotta break for lunch, will look closer when i get back [17:06] tvansteenburgh thank you very much for looking! Have a good lunch :-) [17:08] tvansteenburgh: cory_fu: here is the API for the store what it seems you can get the authtoken: https://github.com/juju/charmstore/blob/v5-unstable/docs/API.md I should have more info on restricting permisions on the tocken tomorrow [17:09] tvansteenburgh: cory_fu: there is this call GET /delegatable-macaroon [17:48] tvansteenburgh: https://github.com/juju-solutions/bundletester/pull/69 [17:51] kjackal: sure, but you're not gonna be able to discharge that macaroon without an oauth identity === zz_CyberJacob is now known as CyberJacob [19:09] petevg: did you get unblocked? [19:13] tvansteenburgh: I didn't (I was wrong about it needing a series as a default). [19:14] petevg: ok, looking now [19:27] tvansteenburgh: thank you for looking into it. :-) [20:11] petevg: afaict the problem is just that you have params: params: instead of just params: [20:12] tvansteenburgh: I tried just passing params in at one point. That might have been while other things were broken, though. I'll try again ... [20:16] tvansteenburgh: That works! (Well, it gets us to the point where a log message does the wrong thing with the return, but that's progress, and it gets me back out of the generated codebase, at least :-) ) [20:16] \o/ [20:16] tvansteenburgh: I see several instances in the generated code where we create a params argument, then create a dict with a 'params' key to pass to it. Should I assume that is never the correct thing to do, and submit a patch? [20:17] In any case, thank you :-) [20:19] petevg: i'm note sure yet :/ [20:19] Whee! [20:21] petevg: so for your thing to work you still have patched auto-gen'd code? [20:21] tvansteenburgh: yes. I need to rebase from cory_fu's branch, but I think the params will still try to nest itself. [20:29] petevg: i just noticed something else. AddMachines() takes a list of AddMachineParams objects [20:30] not a single instance [20:30] tvansteenburgh: is this on the Go side? [20:30] so, client_facade.AddMachines([params]) in your example [20:31] petevg: https://github.com/juju/python-libjuju/blob/master/juju/client/_client.py#L9077 [20:32] petevg: note the typing.Sequence [20:32] tvansteenburgh: Interesting. I am currently getting timeouts, and it looks like the machines aren't being added ... will try passing in a list. (Hooray for more hacking on generated code!) [20:33] petevg: why do you have to change auto-gen'd code? [20:37] tvansteenburgh: Yeah. I can just pass a list in from model.py [20:37] tvansteenburgh: Huh. It doesn't want a list. "cannot unmarshal array into Go value of type params.AddMachines" [20:44] petevg: can i see your current code? [20:45] tvansteenburgh: yes. Jumping into the matrix hangout ... [20:46] tvansteenburgh: Will also push to that branch shortly (I'm hacking in the site-packages in a virtual environment, so I have to copy stuff over ...) [20:47] I just want to try one more thing (working on embedding a list in the params key in the params dict.) [20:50] petevg: can you jump in here https://hangouts.google.com/hangouts/_/canonical.com/rq-next?authuser=0 [21:00] our /var/lib/juju on a 1.25.6 bootstrap system is 6.3G, any way to clear out some of it? [21:02] is the charm-get-cache safe to delete? [21:17] ci-oil-config has an error https://pastebin.canonical.com/170197/ [21:17] charm* [21:22] * lutostag oops, wrong channel for that last part... === beisner- is now known as beisner === hml_ is now known as hml === CyberJacob is now known as zz_CyberJacob