| === mjs0 is now known as menn0 | ||
| * babbageclunk goes out for a walk. | 02:46 | |
| babbageclunk | axw: thanks for the comments - can you expand on your first one a bit though? I think that's something I didn't know about. | 05:14 |
|---|---|---|
| axw | babbageclunk: the private-address relation setting is only ever set when a unit enters scope | 05:14 |
| axw | babbageclunk: and juju will not attempt to replace the value afterwards | 05:15 |
| axw | babbageclunk: because juju can't tell if it set the value, or the charm did | 05:15 |
| babbageclunk | axw: And after that the charm can monkey with it if it wants? | 05:15 |
| axw | babbageclunk: right, e.g. for "proxy charms", which report the address of some other thing on a different machine | 05:15 |
| axw | babbageclunk: so, it's up to the charm to update the private-address relation setting if it sees the addresses change | 05:16 |
| babbageclunk | axw: So I think that makes the existing approach where we put in the public address in invalid, doesn't it? | 05:17 |
| axw | babbageclunk: well, it'll work up until the point where the public address changes | 05:18 |
| axw | babbageclunk: but yes, I think we're buggered after that | 05:18 |
| axw | babbageclunk: I think we need network-get for this to work | 05:18 |
| babbageclunk | axw: or if the charm updates private-address itself without knowing that it's in a cross-model situation | 05:19 |
| axw | babbageclunk: actually, network-get already exists and is what should be used | 05:19 |
| axw | babbageclunk: so we just need to make sure network-get does the right thing for remote relations | 05:19 |
| axw | i.e. uses the remote space & endpoint binding info to determine which address to report | 05:19 |
| babbageclunk | axw: ok | 05:19 |
| axw | babbageclunk: juju help-tool network-get, if you're not familiar with it | 05:20 |
| babbageclunk | axw: I got confused reading Ian's comments - it seems like the two of them are at odds to me. | 05:21 |
| babbageclunk | In the first one he's suggesting to get the information at the point it's needed, and in the second he agrees that we should store the spaces and bindings in the model. | 05:22 |
| axw | babbageclunk: indeed, I'm a bit lost there too. IMO we just store the remote spaces and remote application endpoint bindings when creating the remote application entity in state. then we can determine the address to use by querying state, rather than the remote side again | 05:25 |
| babbageclunk | axw: Yeah, that makes sense to me. | 05:25 |
| axw | babbageclunk: so network-get would call through to the controller, which would check the routability from that existing info, and either return the cloud-local or the public address | 05:26 |
| axw | and similar when doing EnterScope | 05:26 |
| babbageclunk | axw: Yup yup. | 05:26 |
| babbageclunk | axw: Ok, I'll write that up as I understand it and keep going forward with that. | 05:27 |
| babbageclunk | axw: Thanks! | 05:27 |
| axw | babbageclunk: cool, no worries | 05:27 |
| wpk | https://github.com/juju/utils/pull/278 anyone | 08:06 |
| wpk | ? | 08:06 |
| rogpeppe | axw: ping | 08:33 |
| axw | rogpeppe: pong | 08:33 |
| rogpeppe | axw: hiya | 08:34 |
| rogpeppe | axw: just wondering what the best thing to do about fixing the model-defaults command - it makes an API connection at Init time, which isn't allowed any more (and was never a great idea anyway IMO) | 08:34 |
| rogpeppe | axw: the idea that you can't tell if you've provided a cloud argument without going to the API and looking it up seems odd | 08:35 |
| rogpeppe | axw: perhaps i should just move all that logic to Run, but my "this is not right" head is getting in the way here :) | 08:36 |
| * axw looks | 08:37 | |
| axw | rogpeppe: that command is pretty gross, but I don't think we can break the ambiguity now | 08:39 |
| axw | rogpeppe: I think the best we can do really is to move it to Run | 08:39 |
| rogpeppe | axw: ok, will do :-\ | 08:39 |
| axw | rogpeppe: since the cloud names known to the client aren't necessarily the same as what's in the controller | 08:39 |
| rogpeppe | axw: indeed. and neither are the model keys | 08:39 |
| axw | yep | 08:40 |
| rogpeppe | axw: it would be a bit of a problem if someone made a cloud with a name that matched a model config key... | 08:40 |
| rogpeppe | axw: thanks for your review of my rather large PR, BTW | 08:41 |
| axw | rogpeppe: no worries | 08:41 |
| rogpeppe | wpk: reviewed https://github.com/juju/utils/pull/278 | 08:43 |
| wpk | rogpeppe: thanks, updated | 08:53 |
| === frankban|afk is now known as frankban | ||
| blahdeblah | kwmonroe, cory_fu: Either of you around at the moment? (Or anyone else who knows about cwr-ci.) | 11:10 |
| blahdeblah | Just wondering if you can clarify one point from the cwr-ci README: how must we refer to the charm to be tested in the bundle? | 11:11 |
| blahdeblah | The doc says to run "juju run-action cwr/0 cwr-charm-commit repo=http://github.com/myself/my-awesome-charm charm-name=awesome-charm reference-bundle=~awesome-team/awesome-bundle" | 11:11 |
| blahdeblah | However if I "charm proof" a bundle with anything but a pinned awesome-charm revision, I get a warning. | 11:12 |
| blahdeblah | So the question is: how do I reference the charm within the testing bundle? | 11:12 |
| blahdeblah | Or maybe it doesn't matter? Can I just deploy the bundle then CWR will deploy the bundle, then upgrade to the git version of my charm? | 11:13 |
| blahdeblah | Also, I've just (apparently) successfully pushed, granted, and published the bundle I want to start with, but it's not showing up in the store: http://pastebin.ubuntu.com/24498131/ Am I doing something wrong? | 11:28 |
| rick_h | blahdeblah: yea, I'd not worry about the warning about the version number on the charm | 12:01 |
| rick_h | blahdeblah: it's a warning that the charm could move under you and that bundle might be broken if you don't realize it, but it's just a warning | 12:02 |
| blahdeblah | rick_h: thanks - any idea about how to a) make the bundle visible, and b) refer to the charm to be tested by cwr-ci within the bundle? | 12:03 |
| rick_h | blahdeblah: so to make the bundle visible you have to grant EVERYONE permission to it with the charm cli tool. | 12:03 |
| rick_h | blahdeblah: as far as cwr-ci part I'm not sure. | 12:03 |
| blahdeblah | rick_h: You mean EVERYONE in caps? Or everyone just like the pastebin above shows? | 12:04 |
| rick_h | blahdeblah: sorry looking. I missed the pastebin | 12:05 |
| rick_h | blahdeblah: try the grant command w/o the revision on the url | 12:08 |
| rick_h | blahdeblah: and try a `charm show cs:~paulgear/bundle/ntp-server perm` | 12:09 |
| rick_h | blahdeblah: to check the permissions | 12:09 |
| === daniel is now known as Guest47234 | ||
| === Guest47234 is now known as Odd_Bloke | ||
| === frankban is now known as frankban|afk | ||
| blahdeblah | rick_h: thanks - that did the trick | 23:02 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!