| axw | wallyworld: I've just left a comment on your PR about a major issue, but still going through it | 00:59 |
|---|---|---|
| wallyworld | ok, ty | 00:59 |
| wallyworld | fair point | 01:01 |
| wallyworld | veebers: that unit test that failed on CI works fine for me - not interactive auth failures | 01:01 |
| wallyworld | *no | 01:01 |
| wallyworld | i've got an up-to-date zesty | 01:02 |
| wallyworld | axw: part of the issue is that passing in collections to watch from the apiserver facade breaks layering elsewhere. the collections are not exposed at that layer. i'll have to try and think of something else | 01:10 |
| axw | wallyworld: you don't need to specify collections, just concepts | 01:11 |
| axw | wallyworld: we still talk about application offers above the state layer do we not? | 01:11 |
| axw | wallyworld: I'm not suggesting you pass in the collection names, but rather pass in a struct/bool saying whether or not to include "application offers" | 01:12 |
| axw | wallyworld: and that should be decided at the apiserver, where we normally do the permission checking | 01:12 |
| wallyworld | we do. it comes down to how to map that. does the struct has a single bool - watch everything except offers. or do all the things to watch need to be enumerated etc. i liked the perm approach because it was sort of role based | 01:12 |
| wallyworld | i could start out with a bool i guess | 01:13 |
| axw | wallyworld: my point is that we don't do role checking in the state layer. *that* is a layer violation | 01:13 |
| wallyworld | that is true | 01:13 |
| axw | wallyworld: IMO, a struct with a single bool just for application offers. everything else is on by default and can't be controlled, until/unless we need to do that | 01:13 |
| wallyworld | but there's no easy way to map the concept of a role to a what do i do | 01:14 |
| wallyworld | that works for now | 01:14 |
| veebers | wallyworld: let me dig around, I'll have more questions for you in a bit :-) | 01:45 |
| wallyworld | ok | 01:46 |
| menn0 | thumper: ping? | 01:58 |
| thumper | pong | 01:58 |
| menn0 | thumper: actually, switching to onyx channel | 01:59 |
| wallyworld | veebers: will be there soon, just in another meeting | 02:15 |
| veebers | wallyworld: ack | 02:16 |
| wallyworld | burton-aus: test! | 02:31 |
| burton-aus | wallyworld Got it. | 03:23 |
| thumper | hmm... | 05:55 |
| thumper | if I have an api connection to a controller... | 05:55 |
| thumper | how do I download some tools... | 05:55 |
| thumper | ugh... | 06:03 |
| * thumper will look Monday | 06:03 | |
| thumper | have a good weekend everyone | 06:03 |
| wallyworld | jam: unless i am wrong, it looks like our bot runs unit tests with mongo 2.4.9 | 06:22 |
| wallyworld | it seems i am getting a landing error due to a 2.4.9 vs 3.2 thing. i need to re-test locally with 2.4.9 to be sure | 06:23 |
| wallyworld | did you think we were still using 2.4.9? | 06:23 |
| wallyworld | but i can't get the tests to fail locally (incl with --race). but the bot is not happy with some inernal mongo error (or so it seems) | 06:24 |
| === frankban|afk is now known as frankban | ||
| jam | wallyworld: yes, everything on trusty uses 2.4 | 08:32 |
| jam | wallyworld: so you have to support both | 08:32 |
| jam | wallyworld: as in, juju bootstrap --series=trusty *also* uses 2.4 (from what I understood) | 08:32 |
| rogpeppe | a small fix to juju/utils to help it pass juju tests: https://github.com/juju/utils/pull/275 | 12:04 |
| rogpeppe | wpk: you might want to take a look at this ^ | 12:05 |
| anastasiamac | rogpeppe: lgtm | 12:05 |
| rogpeppe | anastasiamac: ta! | 12:05 |
| rogpeppe | anastasiamac: hi, BTW :) | 12:05 |
| anastasiamac | rogpeppe: thnx for following it up :) hi \o/ | 12:05 |
| rogpeppe | anastasiamac: only trying to fix tests in juju-core that were broken when i updated utils... | 12:06 |
| SimonKLB | i guess it is by design that you're not able to access relation data from "relation B" while youre in the context of "relation A" - but does anyone here have a viable solution to get around that? | 12:16 |
| SimonKLB | in this case both relation A and B is related on the same interface (if that matters at all) | 12:16 |
| SimonKLB | say you have 3 different data-sources and you want to grab the connection information of all 3 when configuring your charmed application | 12:18 |
| jrwren | SimonKLB: AFAIK you can always access any relation data. What are you seeing which suggests that you cannot? | 12:25 |
| SimonKLB | "error: permission denied" | 12:26 |
| jrwren | from which command? | 12:27 |
| SimonKLB | relation-get -r [id] | 12:28 |
| jrwren | that is very surprising. I've never seen that. Maybe the relation does not actually exist? | 12:28 |
| jrwren | does it show in relation-list -r [id] ? | 12:29 |
| jrwren | is the [id] used one that is related to the unit for which the hook is running? does it show in relation-ids? | 12:30 |
| SimonKLB | jrwren: yes i grabbed it from relation-ods | 12:32 |
| SimonKLB | ids* | 12:32 |
| SimonKLB | relation-list -r [id] works fine | 12:33 |
| SimonKLB | shows the correct charm/unit-no | 12:33 |
| SimonKLB | jrwren: http://paste.ubuntu.com/24426504/ | 12:34 |
| jrwren | that has got to be a bug or something very strange going on. It worked with one id but not another. What version of juju is this? | 12:36 |
| jrwren | why does your relation-get not require a unit id? | 12:36 |
| SimonKLB | jrwren: could it be that it gets it from an env? | 12:37 |
| SimonKLB | juju version: 2.2-beta2-xenial-amd64 | 12:37 |
| jrwren | SimonKLB: not afaik, but this is the edge of my juju knowledge. | 12:37 |
| SimonKLB | echo $JUJU_REMOTE_UNIT | 12:38 |
| SimonKLB | charmscaler-metric-cpu/0 | 12:38 |
| SimonKLB | that is probably it | 12:38 |
| wpk | rogpeppe: ok, I'll fix the PR for juju/juju change | 12:38 |
| jrwren | ah. I see. interesting. | 12:38 |
| wpk | rogpeppe: it didn't feel right tbh | 12:39 |
| rogpeppe | wpk: i've changed it | 12:39 |
| rogpeppe | wpk: another change was needed in juju-core because of the ordering change - that's landing in https://github.com/juju/juju/pull/7254 | 12:39 |
| jrwren | SimonKLB: yup, beyond my knowledge. | 12:39 |
| SimonKLB | that's ok! anyone else? | 12:40 |
| jrwren | SimonKLB: one last thought, is it a container-scoped relation? | 12:44 |
| SimonKLB | jrwren: nope, global | 12:46 |
| jrwren | SimonKLB: ok, thanks. It shall be interesting to learn of the resolution. | 12:46 |
| SimonKLB | me too :D | 12:47 |
| wpk | rogpeppe: I mean for https://github.com/juju/juju/pull/7162 | 12:47 |
| wpk | rogpeppe: I'm waiting with this merge as it can really break stuff | 12:47 |
| wpk | rogpeppe: (as it makes proxy settings truly global, at least on Xenial) | 12:48 |
| rogpeppe | wpk: i just made a comment on that PR | 12:50 |
| wpk | rogpeppe: thanks | 12:53 |
| === bdx_ is now known as bdx | ||
| bdx | I'm wondering how/why machine spaces constraints are all of the sudden being passed through to the lxd containers on them ..... https://bugs.launchpad.net/juju/+bug/1684143/comments/10 | 16:49 |
| mup | Bug #1684143: applications deployed to lxd on aws instances failing <juju:New> <https://launchpad.net/bugs/1684143> | 16:49 |
| bdx | I hadn't experienced this up until this week .... all prvious lxd deploys to instances in the past had never experienced this issue | 16:50 |
| bdx | I have lxd on top of aws instance instance deploys that I sent off all last week, and for all of time prior to hitting this this week | 16:51 |
| === frankban is now known as frankban|afk | ||
| balloons | hml, externalreality, someone want to have a glance at https://github.com/juju/juju/pull/7257? | 19:55 |
| mup | Bug #1685382 opened: max_user_instances in inotify runs low on juju-db units - version 1.25.6 <canonical-bootstack> <juju-core:New> <https://launchpad.net/bugs/1685382> | 23:14 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!