[02:24] <jtv> wallyworld: thanks for your reply to my simplestreams question... I have another fun one though.
[02:25] <wallyworld> ok
[02:25] <jtv> Is the Endpoint field in an ImageConstraint ever actually used?
[02:25] <wallyworld> yes
[02:25] <jtv> Where?
[02:25] <wallyworld> to determine which cloud to use - endpoint + region uniquely define the cloud
[02:26] <jtv> Okay, but where?  Not in simplestreams.go.
[02:26] <wallyworld> the index file contains region/endpoint pairsd
[02:26] <jtv> Nor in validation.go.
[02:26] <wallyworld> let me look
[02:26] <jtv> Yes, but I'm talking about the Endpoint field in the image constraint.
[02:27] <jtv> This parameter is awkward to obtain; the data suggests that the simplestreams metadata should be the source for that item in the first place.
[02:29] <wallyworld> jtv: in getImageIdsPath() in simplestreams.go - the CloudSpec structs are compared
[02:29] <jtv> Bugger.
[02:29] <wallyworld> no, simplestreams shouldn't e the source
[02:29] <wallyworld> a cloud deployment is defined by region + endpoint
[02:30] <wallyworld> that is a separate concept to simplestreams
[02:30] <jtv> I see.
[02:30] <wallyworld> i thought all the azure endpoints were well known?
[02:30] <wallyworld> lie for ec2?
[02:30] <wallyworld> like
[02:30] <wallyworld> in the ec2 case, they are hard coded
[02:30] <jtv> Yes, they are -- I got them from the simplestreams data.  :)
[02:31] <wallyworld> lol
[02:31] <wallyworld> to use simplestreams, one must first know one's cloud
[02:31] <jtv> We know our cloud.  It's "Azure."
[02:31] <wallyworld> in internals
[02:31] <wallyworld> the
[02:31] <jtv> Never heard of these endpoints until I saw them in the simplestreams data...
[02:31] <wallyworld> that's not simplestreams' fault :-P
[02:32] <jtv> Perhaps not.  But as far as I'm concerned, all endpoints could have been the same for Azure.
[02:32] <wallyworld> i think they are mostly?
[02:32] <jtv> Mostly.
[02:32] <jtv> Not as good as all.
[02:33] <wallyworld> i'd just take the shortcut the ec2 uses and enumerate them in code
[02:33] <jtv> "All" has cyclomatic complexity of 1.  "Mostly" has 2 or more.
[02:34] <bigjools> is endpoint just an api address?
[02:34] <jtv> Enumerating them in the code has the added advantage that a change in regions may require an immediate code update.
[02:35] <wallyworld> yes
[02:35] <wallyworld> typically
[02:36] <wallyworld> for openstack, its the url to use to query the identity service
[02:36] <wallyworld> for ec2, i *think* we actually don't use it, not sure
[02:38] <bigjools> jtv: china has a different endpoint iirc
[02:39] <jtv> bigjools: that's the problem I'm talking about, yes.
[02:39] <bigjools> but gwacl is currently hard-coding just the one anyway
[02:39] <jtv> Well I'm not sure that's the same thing in the first place.
[02:39] <jtv> Because we're hardcoding the URLs that the documentation gives as fixed.
[02:39] <bigjools> the problem is that there's two endpoints in Azure
[02:40] <bigjools> and I think I only saw one in simplestreams
[02:40] <jtv> Two.
[02:41] <bigjools> it lists the storage endpoint too?
[02:41] <bigjools> I didn't see it do that
[02:42] <jtv> It does, but you may have to skip over a lot of other data in the json to get to it.
[02:43] <bigjools> jtv: where? https://cloud-images.ubuntu.com/releases/streams/v1/com.ubuntu.cloud:released:azure.json
[02:44] <jtv> bigjools: search that page for "endpoint" and you'll find it.
[02:45] <bigjools> jtv: there's no storage endpoint there they are only management endpoints
[02:45] <jtv> What's a storage endpoint?
[02:45] <bigjools> there's a totally different URL for storage access
[02:45] <jtv> Oh, I missed your question.  But how do you get storage endpoints?
[02:45] <bigjools> exactly!
[02:45] <bigjools> they are hard-coded right now
[02:45] <bigjools> but I expect china has a different one like the management side does
[02:46] <jtv> Maybe.  But the documentation always says "here's the URL for this request" and never "here's the URL for this request outside of mainland Chia."
[02:46] <jtv> *China
[02:46] <bigjools> indeed
[02:46] <jtv> So it's not a given that these endpoints matter to us at all.
[02:47] <jtv> There is a documentation page about this.
[02:47] <jtv> It's consistently giving me "no data received."
[02:47] <jtv> Can anyone else see what's on http://windowsazure.cn/zh-cn/ ?
[02:47] <bigjools> the first time I saw the china endpoint was in the simplestreams data so I wonder where that was seen to know to put it in there?
[02:48] <jtv> bigjools: that's exactly what I'm trying to figure out as well.  Can you access that page I just linked to?
[02:48] <bigjools> yes, it's in chinese
[02:48] <jtv> Bugger.
[02:49] <jtv> I guess they don't serve that page in Asia or something.  :/
[02:49] <bigjools> chromium helpfully offers a translation
[02:50] <jtv> Ah yes, let Google, Microsoft, and the Chinese government slug it out.  Any mention of URLs?
[02:52] <bigjools> nope
[02:53] <bigjools> can't see any api doc links either
[02:53] <bigjools> I think we should ignore the endpoints for now
[02:56] <jtv> I agree --- except for the purposes of simplestreams, where they're required.  :(
[02:58] <bigjools> they are?
[02:59] <jtv> Yes... in simplestreams, the endpoint is the only thing that identifies Azure.
[03:00] <jtv> Ah, this blog post explains it: http://geekswithblogs.net/shaunxu/archive/2013/06/10/tips-an-tricks-of-developing-on-windows-azure-china.aspx
[03:01] <jtv> So it looks as if what we have now simply isn't going to work for mainland China anyway.
[03:01] <jtv> (Hong Kong seems to be on the international network, not the Chinese intranet)
[03:08] <bigjools> jtv: sorry, you need to know an endpoint in advance to make use of simplestreams data?
[03:09] <bigjools> and yes that blog shows that storage endpoint is different for china too
[03:09]  * bigjools curses bitey things and goes to get anti-itch cream
[03:15] <jtv> bigjools: yes, this is a pair of parameters we must provide to the imagemetadata code in order for it to find us an OS image: "region" and "endpoint."  The endpoint is the only thing that tells it we're looking for an Azure image, as opposed to (say) an image in EC2.
[03:16] <bigjools> ok
[03:21] <jtv> No worries, I'm implementing.
[03:21] <jtv> Can't have nothing at all working for all of mainland China...
[07:43] <sidnei> hey folks, trivial fix: https://codereview.appspot.com/12510043
[07:47] <thumper> sidnei: done
[07:47] <axw> heh, at the same time :)
[07:48] <sidnei> thanks :)
[07:59] <tasdomas> hi
[07:59] <tasdomas> does juju-core support peer relations?
[08:01] <thumper> tasdomas: yes
[08:02] <tasdomas> thumper: and these relations can be established between units running different services (as long as the relation name is the same)?
[08:02] <rogpeppe> mornin' all
[08:02] <thumper> no, peer relations are between units of one service
[08:02]  * rogpeppe is slightly scraped and bruised
[08:04] <tasdomas> thumper: is there any way to do service discovery in a juju environment?
[08:04]  * thumper hands tasdomas to rogpeppe
[08:05] <tasdomas> morning, rogpeppe
[08:05] <rogpeppe> tasdomas: hiya
[08:05]  * rogpeppe needs some context
[08:06] <rogpeppe> tasdomas: what do you mean by "service discovery" there?
[08:06] <tasdomas> rogpeppe, let's say I have two charms: a server charm and a client charm
[08:06] <tasdomas> tey both expose a relation
[08:06] <tasdomas> s/tey/they
[08:07] <tasdomas> is it possible for the client charm, when it is deployed, check if a service charm is already running in that environment
[08:07] <tasdomas> and initiate a relation automatically?
[08:08] <rogpeppe> tasdomas: no, relations must be added explicitly by the user
[08:09] <tasdomas> rogpeppe, I see, thanks!
[08:09] <rogpeppe> tasdomas: np
[08:24] <jtv> Any reviewers available for https://codereview.appspot.com/12512043 ?  It matches a gwacl API change, so I'd like to get it in quickly and minimize the window for inconvenience.
[08:45] <rogpeppe> jtv: looking
[08:49] <noodles775> dimitern: Thanks for the review yesterday. Do I just need to find a second LGTM? (https://codereview.appspot.com/12469044/ )
[08:50] <dimitern> noodles775: yep; only really trivial changes can land with a single LGTM
[08:50] <dimitern> jtv: looking as well
[08:52] <noodles775> Any reviewers able to do a second check on https://codereview.appspot.com/12469044/ (just updates juju init to create the environments.yaml by default, as per https://bugs.launchpad.net/bugs/1208491 )
[08:52] <_mup_> Bug #1208491: Juju init should write an environments.yaml <papercut> <juju-core:In Progress by michael.nelson> <https://launchpad.net/bugs/1208491>
[08:53] <rogpeppe> noodles775: i'll have a look after i've reviewed jtv's branch
[08:54] <noodles775> Thanks rogpeppe
[08:54] <dimitern> jtv: reviewed
[08:57] <rogpeppe> jtv: reviewed
[09:06] <rogpeppe> noodles775: reviewed
[09:09] <dimitern> rogpeppe: so
[09:09] <dimitern> rogpeppe: you said you're workng on agententity + unifying the common bits?
[09:09] <rogpeppe> dimitern: yup
[09:10] <dimitern> rogpeppe: how's that going?
[09:10] <rogpeppe> dimitern: i've got two CLs in the works; i'm about to propose one
[09:12] <dimitern> rogpeppe: ok
[09:16] <dimitern> rogpeppe: i was looking at the uniter code and came up with a list of client-side api stuff we need: http://paste.ubuntu.com/5954390/
[09:17] <rogpeppe> dimitern: quite a lot of stuff there doesn't need to be in separate API calls, but i'm sure you know that
[09:17] <dimitern> rogpeppe: now, from there I'll reverse it to a bunch of server-side calls
[09:17] <dimitern> rogpeppe: yeah, I know
[09:21] <rogpeppe> dimitern: https://codereview.appspot.com/12473043/
[09:22] <dimitern> rogpeppe: so your idea is to expose Entity and get rid of the functions that use it, leave only the interfaces?
[09:22] <rogpeppe> dimitern: yes
[09:23] <rogpeppe> dimitern: i don't see that those functions add anything over just doing a type conversion inline
[09:23] <dimitern> rogpeppe: maybe complement that with a bunch of errors in the errors package, describing X does not do Y
[09:24] <dimitern> rogpeppe: like "%q does not support lifecycles"
[09:24] <rogpeppe> dimitern: perhaps
[09:25] <rogpeppe> dimitern: if so, probably one error type would be sufficient
[09:35] <dimitern> rogpeppe: reviewed
[09:35] <rogpeppe> dimitern: thanks
[09:36] <noodles775> rogpeppe: do you think that we should support both flags together (ie. `juju init -f --show`), or just give one precedence?
[09:36] <rogpeppe> noodles775: i think it's probably ok to just ignore -f if --show is given
[09:36] <rogpeppe> noodles775: nothing to force
[09:36] <noodles775> Cool
[09:48] <jtv> Thanks dimitern & rogpeppe for your reviews!  Could either of you update gwacl on the build machine so I can land?  I'll also send out an email to juju-dev about updating dev systems.
[09:49] <dimitern> jtv: i'm on it
[09:49] <jtv> Merci.
[09:50] <rogpeppe> dimitern: responded. i'm interested in your thought on the "tagName" issue
[09:50] <rogpeppe> s/thought/thoughts/
[09:50] <dimitern> jtv: done
[09:51] <jtv> Thanks!
[09:51] <dimitern> rogpeppe: it is indeed from a tag, otherwise it's from an id or unitName, etc.
[09:52] <rogpeppe> dimitern: it's *from* a tag, yes, but it isn't a tag itself
[09:53] <rogpeppe> dimitern: because a tag has a "kind-" prefix, which this does not
[09:53] <dimitern> rogpeppe: and please use "test %d:" it makes more sense imho and as william said (and I agree) my eyes are trained to look for that in log outputs
[09:53] <dimitern> rogpeppe: ah, good point
[09:54] <dimitern> rogpeppe: can we call it fromTagSuffix then?
[09:54] <rogpeppe> dimitern: sgtm
[10:00] <dimitern> rogpeppe: replied
[10:06] <rogpeppe> dimitern: PTAL
[10:06] <dimitern> rogpeppe: looking now
[10:07] <dimitern> rogpeppe: only one comment - the argument to *TagSuffixToId should be called "suffix" I think
[10:07] <rogpeppe> dimitern: ah, good point
[10:08] <dimitern> rogpeppe: otherwise, LGTM  still
[10:18] <rogpeppe> anyone fancy a quick review? https://codereview.appspot.com/12473043
[10:25] <noodles775> rogpeppe: updated - thanks. https://codereview.appspot.com/12469044/
[10:26] <rogpeppe> noodles775: ah, that's not quite what i had in mind
[10:26] <rogpeppe> noodles775: i think that --show should print the generated configuration data without trying to write it to a file
[10:27] <rogpeppe> noodles775: otherwise it's just a shortcut for cat $HOME/.juju/environments.yaml
[10:28] <noodles775> rogpeppe: Right - I was wondering what the benefit was :) OK, hangon.
[10:31] <rogpeppe> noodles775: responded with a couple of suggestions following on from the above
[10:44] <noodles775> rogpeppe: done - sorry for the hand-holding.
[10:44] <rogpeppe> noodles775: not at all, thanks for going along with me
[10:47] <rogpeppe> noodles775: reviewed
[10:50] <wallyworld_> rogpeppe: i think you forgot my reviews from yesterday? (plugin args and env.yaml simplification)
[10:50] <rogpeppe> wallyworld_: oh bugger, sorry
[10:50] <wallyworld_> np :-)
[10:51] <rogpeppe> wallyworld_: looking now
[10:52] <wallyworld_> ty
[10:58] <noodles775> rogpeppe: s/ShowFile/Show/ pushed.
[10:58] <rogpeppe> noodles775: cool
[10:58] <rogpeppe> noodles775: thanks
[11:31] <dimitern> fwereade, rogpeppe, mgz, axw: standup
[11:53] <noodles775> rogpeppe: hrm, I tried `lbox submit` but apparently the perms have changed recently ( http://paste.ubuntu.com/5954761/ ). I'll check with John Meinel who apparently changed the perms recently.
[11:55] <rogpeppe> noodles775: the submit procedure has changed
[11:55] <rogpeppe> noodles775: we now go through a bot
[11:55] <rogpeppe> noodles775: the way to submit is this:
[11:56] <rogpeppe> noodles775: - set the commit message on the merge proposal (by copying and pasting from the mp description, making sure to include the codereview link)
[11:56] <rogpeppe> noodles775: - mark the merge proposal as Approved
[11:56] <rogpeppe> noodles775: the branch will then be merged some time later, when the bot has tested it (on the order of 15 minutes, depending on the size of the queue)
[11:57] <dimitern> noodles775: or, you can use rv-submit
[11:58] <dimitern> noodles775:  $ mkdir -p ~/.bazaar/plugins
[11:58] <dimitern> $ bzr branch lp:rvsubmit ~/.bazaar/plugins/rvsubmit
[11:58] <dimitern> $ bzr rv-submit (to land the branch)
[11:59] <axw> dimitern: sorry, was idling before (I guess you figured that out tho)
[12:00] <dimitern> axw: no worries, I remembered your tz and that you're not usually joining us for the standup, because it's too late for you
[12:00] <axw> yeah it is a bit - I can come back for a standup in the future if needed
[12:01] <axw> I'm off now, have a nice day
[12:01] <dimitern> axw: if you think it's not too late, be welcome - we're trying to keep it within 30m tops
[12:01] <dimitern> axw: you too!
[12:02] <axw> ok
[12:21] <ahasenack> hi guys, is it expected that the charm directory has tight permissions?
[12:21] <ahasenack> drwx------ 4 root root 4.0K Aug  6 00:11 /var/lib/juju/agents/unit-ubuntu-0/charm/
[12:21] <ahasenack> just wondering because the postgresql charm broke because of that, apparently that wasn't the case in pyjuju
[12:22] <ahasenack> https://bugs.launchpad.net/juju-core/+bug/1205286
[12:22] <_mup_> Bug #1205286: charm directory permissions now more restrictive <juju-core:New> <postgresql (Juju Charms Collection):Triaged> <postgresql-psql (Juju Charms Collection):Triaged> <https://launchpad.net/bugs/1205286>
[12:43] <noodles775> Thanks rogpeppe, dimitern. FWIW, it looks like you need to be a branch reviewer to use rv-submit: http://paste.ubuntu.com/5954888/
[12:43]  * noodles775 tries adding an approve vote to see if that helps.
[12:45] <dimitern> noodles775: well, if it doesn't, I can mark it as approved for you
[12:46] <noodles775> dimitern: it doesn't. Please do, thanks.
[12:46] <dimitern> noodles775: done, let's see - the bot should pick it up soon
[13:55]  * rogpeppe goes for lunch
[14:36] <rogpeppe> dimitern: ping
[14:36] <dimitern> rogpeppe: pong
[14:36] <rogpeppe> dimitern: i'm wanting to talk some things over to get my head straight
[14:36] <rogpeppe> dimitern: fancy a chat?
[14:37] <dimitern> rogpeppe: sure, just a sec
[14:37] <noodles775> Another easy (but maybe controversial) if anyone has time: https://codereview.appspot.com/12535043
[14:37] <rogpeppe> dimitern: standup hangout?
[14:38] <dimitern> rogpeppe: https://plus.google.com/hangouts/_/9557d0344a6e30b1320adbbf7a4406d3d7f27b09?hl=en
[15:42] <rogpeppe> wallyworld_: are you still around, by any chance?
[16:39] <natefinch> cd ..
[16:39] <natefinch> haha
[16:40] <natefinch> anyone know why I can commit and push, but bzr pull says no pull location known or specified?
[16:44] <sidnei> natefinch: try bzr pull --remember, and it will work from there on
[16:46] <natefinch> sidnei: thanks...  still getting used to bazaar
[17:59] <rogpeppe> a couple of branches i'd much appreciate reviews of, please: https://codereview.appspot.com/12473043/ and https://codereview.appspot.com/12551043
[17:59] <rogpeppe> time for me to go
[18:00] <rogpeppe> g'night all
[18:03] <natefinch> g'night rogpeppe