[00:33] <wallyworld> thumper: back?
[00:36] <davecheney> wallyworld: https://code.launchpad.net/~dave-cheney/+recipe/juju-core
[00:36] <davecheney> what has happened to the build recipe ?!?
[00:36] <davecheney> why don't the debs end in the series ?
[00:37] <wallyworld> i have no idea. my knowledge of packaging stuff is zero :-(
[00:37] <wallyworld> bigjools: ?
[00:37] <bigjools> sup
[00:37] <wallyworld> ^^^
[00:38] <davecheney> fuck
[00:38] <davecheney> this broke the release
[00:38] <davecheney> bugger it
[00:38] <davecheney> i can fix this in the release script
[00:38] <bigjools> what is the question for me, exactly?
[00:38] <wallyworld> [10:36:18] <davecheney> what has happened to the build recipe ?!?
[00:38] <wallyworld> [10:36:33] <davecheney> why don't the debs end in the series ?
[00:38] <davecheney> bigjools: why do the debs produced by the recipe no longer end in the series
[00:38] <bigjools> that makes no sense
[00:39] <bigjools> what do you mean by "end in the series" ?
[00:39] <davecheney> the name of the deb used it end in ~saucy
[00:39] <davecheney> for example
[00:39] <davecheney> now it ends in ~ubuntu13.10
[00:40] <bigjools> because your recipe says "{debupstream}-1~{revno:juju-core}"
[00:40] <davecheney> bigjools: that has never changed
[00:40] <davecheney> and that gives me -1~1739
[00:40] <davecheney> the remainder was added by the build bot
[00:41] <bigjools> I don't see any complete builds that don't have that
[00:41] <wallyworld> bigjools: [FULLYBUILT] juju-core - 1.13.2-4~1703~saucy1
[00:41] <davecheney> bigjools: https://code.launchpad.net/~juju/+archive/devel/+builds?build_text=&build_state=built
[00:41] <davecheney> somethign happened in the last two weeks
[00:41] <davecheney> look at the name of the 1.13.2 packages
[00:41] <davecheney> and earlier
[00:42] <bigjools> it has changed to use release names instead of code names by the looks of things
[00:42] <bigjools> which is correct IMHO
[00:43] <bigjools> nothing is broken
[00:43] <davecheney> bigjools: is it possible to change it back ?
[00:43] <davecheney> i was relying on that misfeature
[00:43] <bigjools> in what way?
[00:43] <davecheney> i used the series in the name of the file produce to deduce the series the deb was produced for
[00:44] <bigjools> can't you change it to look at the ubuntuNN.NN.N instead?
[00:45] <davecheney> i can
[00:45] <davecheney> but I wanted to know why this changed
[00:45] <bigjools> no idea
[00:45] <davecheney> who can I talk to about this ?
[00:45] <bigjools> I'd ask steve or william
[00:45] <wallyworld> i poked in laucnhpad-ops
[00:45] <wallyworld> waiting on a reply
[00:45]  * davecheney joins
[00:46] <bigjools> I asked in #launchpad-dev :)
[00:46] <bigjools> but there's probably better ways to deduce the series
[00:47] <davecheney> bigjools: suggestions welcome
[00:47] <davecheney> i have a deb file
[00:47] <davecheney> i'd like to know which series it came form
[00:47] <davecheney> maybe the changelog
[00:47] <bigjools> use the LP API
[00:48] <davecheney> bigjools: i have the file
[00:48] <davecheney> all i have is the file
[00:48] <wallyworld> davecheney: here's the answer
[00:48] <wallyworld> [10:46:35] <wgrant> wallyworld_: It's changed to ~ubuntuYY.MM.1
[00:48] <wallyworld> [10:46:45] <wgrant> As Ubuntu's backports have been for a while.
[00:48] <wallyworld> [10:46:53] <wgrant> Because in a few releases the alphabet will wrpa.
[00:48] <davecheney> the file is all i have
[00:48] <bigjools> where arey you getting the file?
[00:48] <davecheney> wallyworld: bigjools ok
[00:48] <davecheney> i'll fix it in code
[00:48] <davecheney> thanks for your help
[00:48] <bigjools> davecheney: where are you getting the deb from?
[00:49] <davecheney> the link from the recipe
[00:49] <davecheney> i'll just make a table to convert from number to name
[00:49] <bigjools> how are you accessing the recipe?
[00:49] <bigjools> hang on :)
[00:50] <davecheney> bigjools: manuallyu
[00:50] <davecheney> copy and paste the url
[00:50] <bigjools> you have a script that scrapes the page?
[00:50] <davecheney> http://bazaar.launchpad.net/~go-bot/juju-core/trunk/view/head:/doc/juju-core-release-process.txt
[00:50] <davecheney> i have a person that scrapes the page
[00:51] <bigjools> release notes should always talk about version numbers not code names, FWIW
[00:51] <bigjools> I was never comfortable with juju's config files containing "precise" etc
[00:51] <bigjools> should be 10.04
[00:51] <bigjools> 12.04 even
[00:52] <davecheney> bigjools: i don't think its possible to change that now
[00:52] <bigjools> it's always possible :)
[00:52] <bigjools> just work
[00:53] <davecheney> bigjools: if you feel strongly about it
[00:53] <davecheney> raise an issue
[00:53] <davecheney> it's not one anyones radar
[00:53] <bigjools> well I am just pointing out UBuntu policy
[00:54] <bigjools> given my prior work area
[00:54] <axw> it's kinda on my radar; I was thinking ahead about how tools might be named for non-Ubuntu targets, if we were to support them
[00:54] <bigjools> given that so many people get it wrong anyway it's not worth pushing hard
[00:54] <axw> LSB codename doesn't work so well for other distros
[00:54] <davecheney> lol at lsb
[00:54] <bigjools> but it's something to be aware of because Ubuntu may change things like you just experienced
[00:55] <davecheney> ubunutu doesn't start with the letter l
[00:55] <davecheney> bigjools: fair enough, i am so warned
[00:55] <bigjools> cool
[00:55] <bigjools> davecheney: anyway I am struggling from that large page of text to work out what exactly you're doing with the deb
[00:56] <bigjools> you get the deb url manually then?
[00:56] <bigjools> oh and the script parses the deb file name.
[00:56] <bigjools> you might want to specify that manually tbh
[00:57] <bigjools> in Ubuntu debs can be in more than one release if they didn't change between
[00:58] <davecheney> bigjools: that page just documents what happens now
[00:58] <davecheney> it does not describe what we want to happen
[00:58] <bigjools> fair enough
[00:58] <bigjools> I'd honestly make an LP API script to automate this
[00:59] <davecheney> bigjools: i'm sure someone will replace this with somthing much better
[00:59] <bigjools> ok.  said my piece :)
[01:00] <davecheney> thanks all for your help
[01:00] <bigjools> any time
[01:00] <davecheney> wasn't hard to work around
[01:07] <wallyworld> davecheney: i know i am stupid, but i'm getting a nil pointer panic and i can't see why :-( any clues? http://pastebin.ubuntu.com/6057264/
[01:08] <davecheney> wallyworld: can't do it like that
[01:08] <davecheney> what is happening is gocheck does this
[01:08] <davecheney> s := new(LegacyToolsSuite)
[01:08] <davecheney> legacy tools suite contains a ToolsSuite as a valid initalised to its zero value
[01:09] <davecheney> and inside that is a field called toolsTestHelper which is an interface
[01:09] <davecheney> the interface is initalised to it's zero value
[01:09] <davecheney> which is a nil pointer
[01:09] <wallyworld> why is polymorphism so hard in Go :-(
[01:09] <davecheney> cos there is no polymorphism
[01:10] <wallyworld> yeah :-(
[01:10] <wallyworld> kinda limiting
[01:10] <wallyworld> thanks, i'll rework it
[01:12] <davecheney> ok, i've found another bug with that change
[01:12] <davecheney> the version inside the 12.10 deb is 13.10
[01:13] <wallyworld> \o/
[01:13] <davecheney> http://paste.ubuntu.com/6057271/
[01:14] <wallyworld> i'll ask in launchpad-ops
[01:14] <davecheney> oh
[01:14] <davecheney> hang on
[01:14] <davecheney> something is wrong
[01:14] <davecheney> shit
[01:14] <davecheney> sorry
[01:14] <davecheney> i fucked up
[01:14] <wallyworld> :-)
[01:15] <wallyworld> thumper: ping
[01:27] <davecheney> axw: lp:~axwalk/juju-core/lp1218329-azure-released-images
[01:27] <thumper> wallyworld: hi
[01:27] <davecheney> are you able to backport that to the 1.14 branch ?
[01:27] <axw> davecheney: sure
[01:28] <davecheney> ta
[01:28] <davecheney> there is no bot
[01:28] <davecheney> merge manually
[01:28] <axw> okey dokey
[01:29] <wallyworld> thumper: hi, i was reviewing your pass-through-agent-config branch. i couldn't tell for sure, but are you ensuring the default value for dataDir is "/var/lib/juju". it looks like that is missing with the rework?
[01:29] <thumper> wallyworld: that is because it is dumb :)
[01:29] <thumper> it was saying "if it is empty"
[01:29] <thumper> it is never empty
[01:29] <thumper> agent.Config will not be created with an empty dataDir
[01:30] <wallyworld> ok. other than that, it all looks pretty mechanical
[01:46] <davecheney> right
[01:46] <davecheney> this release is a dud
[01:47] <davecheney> spot the bug., http://paste.ubuntu.com/6057341/
[01:51] <axw> davecheney: pushed to 1.14
[01:55] <davecheney> thanks
[01:55] <davecheney> might have been for naught
[01:55] <davecheney> the machiner can't restart properly
[01:56] <davecheney> it has a requirement on the api server being up
[01:56] <davecheney> and that races with the api server job
[01:56] <davecheney> restarting
[01:56] <davecheney> ok, it looks like it finally gets there
[01:56] <davecheney> but takes many many rstarts
[01:56]  * davecheney files bug
[02:00] <davecheney> https://bugs.launchpad.net/juju-core/+bug/1220027
[02:00] <_mup_> Bug #1220027: worker/provisioner: cannot restart cleanly due to hard dependency on api server <juju-core:Triaged> <https://launchpad.net/bugs/1220027>
[02:03] <thumper> I think this would be pretty easily solved if we didn't make everything fatal
[02:04] <thumper> that way the provisioner would try to start, fail and then retry
[02:04] <thumper> while the api server comes up
[02:04] <thumper> or,
[02:04] <thumper> we should make sure the at the api server comes up before we start any other jobs that depend on it
[02:04] <thumper> that sounds sensible
[02:05] <davecheney> thumper: i think we have to do that
[02:05] <davecheney> before the provisioniner didn't use the api to provision
[02:05] <davecheney> now it does
[02:05] <thumper> we used to have this for state
[02:05] <thumper> at least it made sure the state connection was valid
[02:05] <thumper> now we need a valid api endpoint
[02:08] <davecheney> this is the danger of testing on ec2
[02:08] <davecheney> we expect everything to be dog slow
[02:10] <davecheney> wallyworld: can someone sync tools to canonistack and hp cloud ?
[02:10] <wallyworld> davecheney: ok
[02:11] <davecheney> wallyworld: ta much
[02:16] <davecheney> axw: https://bugs.launchpad.net/juju-core/+bug/1218329
[02:16] <_mup_> Bug #1218329: Update default environment.yaml for Azure to use Precise for default-series <juju-core:Fix Committed by axwalk> <juju-core 1.14:Fix Committed> <https://launchpad.net/bugs/1218329>
[02:16] <davecheney> which rev was this fixed on 1.14 ?
[02:17] <thumper> axw: what is a simple way to copy a clice?
[02:17] <thumper> foo[:] ?
[02:18] <davecheney> thumper: nope
[02:18] <davecheney> use the copy() statement
[02:18] <thumper> works in python :P
[02:18] <davecheney> sorry functoin
[02:18] <thumper> builtin?
[02:18] <davecheney> that will give you a new slice with the same backing array
[02:19] <thumper> what benefit does that really give us over returning the slice itself?
[02:19] <axw> thumper: sorry missed... append([]x, y...)
[02:19] <thumper> it it shares the backing array
[02:19] <axw> []x{} rather
[02:19] <davecheney> thumper: i don't know, i don't know what the question is
[02:20] <thumper> davecheney: axw suggested in a review to return a copy of our caCert []byte instead of the one we have
[02:20] <thumper> just so it isn't misused
[02:20] <thumper> accidentally
[02:20] <axw> append([]byte{}, caCert...)
[02:20] <thumper> axw: does append(nil, caCert..) work?
[02:20] <thumper> or does it need to be a typed nil?
[02:20] <axw> umm. I don't recall
[02:21] <axw> don't think so, but I'll try
[02:21] <axw> thumper: nope
[02:21] <axw> (nope doesn't work; needs to be typed)
[02:23]  * thumper nods
[02:23]  * thumper uses append
[02:23] <axw> thumper: as for your question of "what benefit does that [returning a resliced slice] give" - none in this case
[02:23] <thumper> the new copy I get
[02:24]  * thumper returns a copy
[02:24] <thumper> and runs the tests prior to submitting
[02:24] <thumper> axw: I also fixed the comment.
[02:24] <axw> thumper: thanks
[02:35] <axw> oh god
[02:35] <axw> it's going to take ~24h to get to SFO
[02:38] <davecheney> axw: WHAT
[02:38] <davecheney> 4 hours to Syd
[02:38] <davecheney> then 14 to SFO
[02:38] <davecheney> 14 to LAX
[02:38] <davecheney> then 2 to SFO
[02:39] <axw> davecheney: not all in the air
[02:39] <axw> don't forget fun times waiting at the airports
[02:39] <wallyworld> davecheney: syncing finished for canonistack and hp cloud
[02:39] <davecheney> wallyworld: ta
[02:39] <davecheney> testing now
[02:39] <wallyworld> axw: serves you right for living in perth :-P
[02:40] <axw> wallyworld: yeah :(  let's all have the next one here.. ha ha
[02:40] <wallyworld> i'd rather europe :-)
[02:41] <axw> or that
[02:41] <davecheney> ooooooooooooooooooooooh
[02:42] <davecheney> now i understand what hazmat is talking about
[02:42] <davecheney> if the provisioner gets into the restart loop
[02:42] <axw> still a long flight, but at least there's cheap beer and good food at the end of it
[02:42] <davecheney> status will take ages
[02:42] <davecheney> because there is no api server
[02:42] <davecheney> axw: in SFO
[02:42] <axw> davecheney: ?
[02:42] <davecheney> uh, are you sure ?
[02:42] <axw> europe
[02:43] <axw> davecheney: what's the provisioner problem? this sounds a bit like an issue I saw with the local provider
[02:43] <davecheney> https://bugs.launchpad.net/juju-core/+bug/1220027
[02:43] <_mup_> Bug #1220027: worker/provisioner: cannot restart cleanly due to hard dependency on api server <papercut> <juju-core:Triaged> <juju-core 1.14:Triaged> <juju-core trunk:Triaged> <https://launchpad.net/bugs/1220027>
[02:44] <axw> mk
[02:44] <axw> that does look similar
[02:44] <davecheney> lucky(~) % juju bootstrap -v
[02:44] <davecheney> 2013-09-03 02:44:45 INFO juju.provider.openstack provider.go:126 opening environment "nec-az3"
[02:45] <davecheney> 2013-09-03 02:44:45 INFO juju.environs.tools tools.go:29 reading tools with major version 1
[02:45] <davecheney> 2013-09-03 02:44:45 INFO juju.environs.tools tools.go:37 filtering tools by series: precise
[02:45] <davecheney> 2013-09-03 02:44:48 INFO juju.environs.tools tools.go:44 falling back to public bucket
[02:45] <davecheney> 2013-09-03 02:44:48 INFO juju.environs.tools tools.go:93 picked newest version: 1.13.2
[02:45] <davecheney> wallyworld: did you sync tools to hp cloud ?
[02:45] <wallyworld> davecheney: supposedly
[02:45] <wallyworld> what public bucket are you using?
[02:46] <wallyworld> i've got https://region-a.geo-1.objects.hpcloudsvc.com/v1/60502529753910
[02:46] <davecheney>     public-bucket-url: https://region-a.geo-1.objects.hpcloudsvc.com/v1/60502529753910
[02:46] <davecheney> wallyworld: i am using az3
[02:46] <wallyworld> wtf, they're different
[02:46] <davecheney> they look the same to me
[02:46] <wallyworld> ok, so i need to sync to your's too
[02:47] <wallyworld> oh hang on
[02:47] <wallyworld> i can't read
[02:47] <wallyworld> they're the same
[02:48] <wallyworld> so looks like sync tools lied to me
[02:48] <davecheney> wallyworld: should I try a different az ?
[02:48] <davecheney> wallyworld: how do you have sync tools setup ?
[02:48] <davecheney> do you put the public bucket as your cotrol bucket then run juju-sync tools ?
[02:49] <wallyworld> no, i've not run it before,i assumed it would upload to the public bucket of the env
[02:49]  * davecheney has no idea
[02:50] <wallyworld> i'll take another look
[02:50] <wallyworld> davecheney: i forgot the --public
[02:50] <davecheney> bzzzzzzzzzzzzzzt
[02:50] <wallyworld> so it uploaded to my private bucket
[02:50] <wallyworld> sorry
[02:50] <davecheney> rofl
[02:50] <wallyworld> fuck off :-)
[02:51] <wallyworld> damn
[02:51] <wallyworld> auth error
[03:05] <wallyworld> davecheney: ok, i've had to do hp cloud by hand since there are different credentials for public bucket vs my normal account i think. i'll now do canonistack, but there are authentication issues there too
[03:08] <davecheney> let me try
[03:08] <davecheney> maybe my creds work for hp cloud
[03:12] <wallyworld> davecheney: i can upload via the web ui. but i think my creds to write to the public bucket differ from the creds i need to use to access my juju assets and so sync-tools doesn't like that
[03:13] <wallyworld> similar issue with canonistack - i'm having to do that by hand tool
[03:14] <wallyworld> davecheney: canonistack done too hopefully
[03:15] <davecheney> kk
[03:17] <davecheney> wallyworld: tools in hpcloud look good now
[03:17] <davecheney> thanks
[03:17] <wallyworld> great
[03:47]  * thumper goes to make coffee
[04:10]  * thumper puts the  music on loud to try to cover the screaming kids
[04:10] <thumper> they are playing some xbox game
[04:28]  * thumper shelves the logging work until someone can help explain the api
[04:29] <thumper> wallyworld: hey there
[04:29] <thumper> wallyworld: wotcha up to?
[04:29] <wallyworld> yo
[04:30] <wallyworld> tools stuff
[04:30] <thumper> call?
[04:30] <wallyworld> ok
[04:30] <thumper> wallyworld: https://plus.google.com/hangouts/_/775c25d6dba9048907bcf2c54e570e6a4008a22f?hl=en
[04:56]  * thumper back later
[09:18] <wallyworld> fwereade: you may have an interest in this https://codereview.appspot.com/13343046, i've used some new interfaces, get out the paint cans
[09:18] <fwereade> wallyworld, nice
[09:18] <fwereade> wallyworld, thanks
[09:18] <wallyworld> i'd be happy to discuss before/after the standup
[09:19]  * wallyworld unpacks his new Nexus 7 II tablet :-D
[09:46] <dimitern> fwereade: hey
[09:46] <fwereade> dimitern, heyhey
[09:47] <dimitern> fwereade: so looking at the code I think it's high time I start doing the migration from relation-id to relation-key tags
[09:47] <fwereade> dimitern, good plan, +1
[09:47] <dimitern> fwereade: this, and the relationunitswatcher are the only missing bits at server-side
[09:48] <dimitern> fwereade: otherwise most of the stuff that's left is mostly trivial
[09:51] <fwereade> dimitern, that is music to my ears :)
[09:52] <dimitern> fwereade: :)
[09:56] <dimitern> fwereade: I need to dig up logs for rogpeppe's findings on relation names format, do you know that site that has all irc logs in html format?
[09:57] <fwereade> dimitern, er not offhand, I usually just search and poke around until something shows up
[09:57] <dimitern> fwereade: ah, found it http://irclogs.canonical.com/YYYY/MM/DD/
[09:57] <fwereade> dimitern, same time as me :)
[09:59] <dimitern> fwereade: hmm, but this one doesn't have the freenode logs
[09:59] <dimitern> fwereade: so, for the record it's http://irclogs.ubuntu.com/2013/08/16/
[10:00] <fwereade> dimitern, cheers :)
[10:01] <dimitern> fwereade: [a-z][a-z0-9]*(-[a-z0-9]+)* seems to be the right regexp for relation names
[10:02] <dimitern> fwereade: so for the tag format itself, what do you think? "relation-<name>" with the format above, no changes to dashes, etc.?
[10:03] <dimitern> fwereade: ah, but that's just one name, we have "name1:service1 name2:service2"
[10:04] <dimitern> fwereade: so we need something like "relation-<name1>@<service1>|<name2>@<service2>" ?
[10:04] <fwereade> dimitern, yeah, I think so
[10:05] <fwereade> dimitern, the first step is tidying up the names considered to be valid in charms
[10:05] <dimitern> fwereade: hmm.. the pipe is not a valid filename char
[10:05] <dimitern> fwereade: maybe ~ ?
[10:05] <fwereade> dimitern, I would prefer to preserve filename-sanity if possible
[10:06] <fwereade> dimitern, # maybe?
[10:06] <dimitern> fwereade: "relation-my-relation123@some-service~my-other-relation42@remote-service23"
[10:06] <dimitern> fwereade: is it valid?
[10:06] <dimitern> fwereade: ok, I'll go with #
[10:07] <fwereade> dimitern, ehh I'm uncertain about swapping the service:relation ordering
[10:08] <fwereade> dimitern, seems mainly like an opportunity to make mistakes
[10:08] <fwereade> dimitern, I understand it fits nicely with @
[10:08] <dimitern> fwereade: ah, was it the other way around? no problem, wasn't sure
[10:08] <fwereade> dimitern, yeah, but then "service@relation" is kinda crazy
[10:09] <dimitern> fwereade: it kinda is
[10:10] <fwereade> dimitern, how abouut... relation-svc.rel#svc.rel perhaps?
[10:10] <dimitern> fwereade: dots?
[10:10] <fwereade> are they bad?
[10:10] <dimitern> fwereade: don't think so, just a bit weird, sgtm
[10:11] <fwereade> dimitern, svc.rel feels to me closest to svc:rel
[10:11] <fwereade> dimitern, and it's an endpoint on a specific service so i think the ordering is useful
[10:12] <dimitern> fwereade: according to wikipedia http://en.wikipedia.org/wiki/Filename dots should be ok
[10:12] <fwereade> dimitern, so I would hope indeed :)
[10:12] <dimitern> fwereade: but : is definitely not
[10:12] <fwereade> dimitern, quite so
[10:13] <fwereade> dimitern, svc:rel is the existing syntax though
[10:13] <jam> dimitern: are you saying "sane filenames on Linux" or "sane filenames on Windows". Because on Linux any 8-bit is allowed except for "/" and "\x00".
[10:13] <dimitern> jam: well, not really - some are shell special chars
[10:13] <dimitern> jam: and need escaping, which is ugly
[10:14] <jam> dimitern: they are "valid filename chars"
[10:14] <jam> it happens that shell likes to do things with them
[10:14] <dimitern> fwereade: so the conversion should be s/:/./ and s/ /#/ + "relation-" as prefix
[10:14] <jam> which is more about clarity "not shell characters" is not the same as "only filename chars"
[10:15] <jam> : ; ^ , {} [] " ' all have shell meaning but are valid in filenames
[10:15] <dimitern> jam: yeah, but let's not make our lives harder in the remote possibility we actually need to use tags as filenames :)
[10:15] <fwereade> dimitern, sgtm I think
[11:30] <jam> mgz, fwereade, dimitern, TheMue, wallyworld_: standup time: https://plus.google.com/hangouts/_/f497381ca4d154890227b3b35a85a985b894b471
[11:31] <mgz> ta
[11:33] <jam> fwereade: poke ?
[11:33] <fwereade> jam, oops, sorry
[11:52] <jam> TheMue: can you link me to the ssl bug ?
[11:53] <jam> wallyworld_: you may have hit: 1207294
[11:53] <jam> bug #1207294
[11:53] <_mup_> Bug #1207294: sync-tools fails with --public <juju-core:Triaged> <https://launchpad.net/bugs/1207294>
[11:54] <dimitern> fwereade: https://codereview.appspot.com/13490043
[11:54] <wallyworld_> jam: yes, at first glance could be
[11:55] <jam> mgz: do you know the status of https://bugs.launchpad.net/juju-core/+bug/1215949 and how we fix it?
[11:55] <_mup_> Bug #1215949: juju-core in the devel ppa does not use alternatives <juju-core:Triaged> <https://launchpad.net/bugs/1215949>
[11:55] <jam> would be really good to have for 1.14 (without having to go via Saucy)
[11:55] <mgz> sort of...
[11:55] <mgz> we just need to get that building from the ubuntu-branch packaging
[11:56] <mgz> the reason that's not quite trivial is the ubuntu packaging is set to build from a stable tarball, rather than pull trunk of everything,
[11:56] <mgz> so, if we update deps, we'd break the devel packaging potentially
[11:57] <mgz> could overlay everything still..
[12:03] <jam> mgz: things in ppa:juju/devel are still releases, so we can still build from *a* tarball
[12:16] <jam> wallyworld_: if you are still here, did this get landed: https://bugs.launchpad.net/goose/+bug/1132618
[12:16] <_mup_> Bug #1132618: swift service double lacks container list prefix filtering <swift-double> <Go OpenStack Exchange:Fix Committed by wallyworld> <https://launchpad.net/bugs/1132618>
[12:16] <jam> it looks old, but it is still open as "Critical"
[12:17] <jam> TheMue: another poke if you have the bug # for the ssh-hostname-verify stuff.
[12:17] <jam> There is an old bug #1074025 where we said we needed to support it, and then disabled it or something
[12:17] <_mup_> Bug #1074025: environs/config: juju must support ssl-hostname-verification config option <juju-core:Fix Released by dave-cheney> <https://launchpad.net/bugs/1074025>
[12:18] <jam> but I'm pretty sure there should be a new bug
[12:24] <jam> natefinch: https://codereview.appspot.com/13079045/ has been review
[12:24] <jam> reviewed
[12:25] <jam> TheMue: I think I found it, bug #1202163
[12:25] <_mup_> Bug #1202163: openstack provider should have config option to ignore invalid certs <cts> <papercut> <Go OpenStack Exchange:Confirmed> <juju-core:Triaged by jameinel> <https://launchpad.net/bugs/1202163>
[12:25] <dimitern> jam: could you take a look at https://codereview.appspot.com/13490043/ ?
[12:26] <jam> dimitern: you realize that # is also a shell character, meaning comment, and so if you type "foo#bar" it will get seen as just "foo"
[12:26] <jam> I personally think : is a less volatile "shell char"
[12:27] <TheMue> jam: I assigned it to you
[12:27] <dimitern> jam: but on windows it won't work
[12:28] <dimitern> jam: how about replacing # wit @ ?
[12:28] <TheMue> jam: it's https://bugs.launchpad.net/juju-core/+bug/1202163
[12:28] <_mup_> Bug #1202163: openstack provider should have config option to ignore invalid certs <cts> <papercut> <Go OpenStack Exchange:Confirmed> <juju-core:Triaged by jameinel> <https://launchpad.net/bugs/1202163>
[12:28] <jam> dimitern: so, I just tried "echo foo#bar" and I get "foo#bar" but "echo foo #bar" gives just "foo"
[12:29]  * TheMue just finished flight booking
[12:29] <dimitern> jam: but there's no space anywhere
[12:29] <dimitern> jam: echo relation-svc1.rel1#svc2.rel2 seems to work
[12:31] <jam> right, we're not allowed spaces, though I won't guarantee all shells act like my bash :)
[12:31] <jam> dimitern: though I would bias towards making it something you can easily write in a shell, vs something that can be turned into a filename
[12:32] <jam> and today, we already write them in the shell as "juju add-relation service:rel service:rel"
[12:34] <dimitern> jam: tags are not supposed to be typed I think - they're just used mostly over the wire in the API
[12:35] <jam> anyway, what you have is fine, and I don't mean to just cause churn, but I don't quite see what we actually gain rather than having them closer to the actual relation key
[12:35] <jam> I *think* "." isn't very nice in Mongo, (you don't want to put it into keys, because by default search uses "." to indicate a nested doc)
[12:36] <dimitern> jam: tags are not stored in mongo
[12:36] <dimitern> jam: they are constructed from mongo keys
[12:36] <jam> dimitern: sure, but it seems like playing nicer with mongo is better than playing nice with FS. Again, it would be possible to do it your way, but why mutate something that is close to fine as is?
[12:37] <jam> I would get rid of the space
[12:37] <jam> but why not have it be
[12:37] <jam> relation-service1:foo#service2:bar
[12:37] <dimitern> jam: because of windows mostly
[12:38] <jam> dimitern: if we aren't storing them in mongo, and we aren't writing them to disk, and we aren't typing them into the command line, I don't think we've actually gained anything over a simpler transform
[12:38] <dimitern> jam: rogpeppe can explain better than me the idea behind having all tags FS compatible
[12:39] <dimitern> jam: all the others are like that, why change it now?
[12:40] <jam> dimitern: do you know why we want Key based rather than Id based? I think I missed that conversation as well.
[12:40] <dimitern> jam: fwereade can explain better
[12:41] <dimitern> jam: it's something related to performance of keys/indices in mongo perhaps; and the key being more obvious what it's about, rather than an opaque number
[12:43] <dimitern> jam: also, rel ids are used in very few places - we use keys for most things
[12:55] <dimitern> jam: so..
[12:56] <dimitern> jam: can I get a review please? :)
[12:57] <dimitern> jam: thanks!
[13:10] <fwereade> dimitern, jam: the main thing is that tags were originally conceived as filesystem-safe, and it seems a bit capricious to drop that property
[13:10] <fwereade> jam, we can't have id based ones because they're reported as lists of keys from the watcher
[13:11] <dimitern> fwereade: right!
[13:11] <fwereade> jam, and need to convert them for the api *even* when the corresponding doc no longer exists
[13:11] <fwereade> jam, but that's where the id would be stored
[13:12] <jam> fwereade: I'd really be happier if clients never generate tags from other data, is there a reason the watcher or whatever can't talk in terms of tags?
[13:13] <fwereade> jam, tags don't exist at the db level
[13:13] <fwereade> jam, auto-converting from _id would just move the problem, not replace it
[13:13] <dimitern> fwereade: but we need to convert the stringswatcher to report tags, and we have the names package for conversions
[13:15] <fwereade> jam, I would also be happier if clients never generated tags from other data -- what situation are you thinking of?
[13:15] <dimitern> fwereade: or maybe just the api stringswatchers
[13:15] <fwereade> jam, the server is the thing that needs to convert _ids from a state watcher to tags for an api watcher
[13:16] <jam> fwereade: golang question. I have a "type Foo struct { Bar }" and I have a "f *Foo" object, but I want to call a function that takes a "*Bar" object. Is there an obvious way to do so that isn't (&f.Bar) ?
[13:16] <fwereade> jam, the existing problem is that it returns names and thus mixes vocabularies
[13:16] <fwereade> jam, don't think so
[13:16] <dimitern> jam: try f.Bar.Call()
[13:17] <dimitern> jam: ah, it's embedded
[13:18] <fwereade> dimitern, the reason not to fix stringswatcher api now is that things are already using it, and nobody but us is using it, so it doesn't get any worse with time
[13:18] <dimitern> fwereade: yeah, that's right
[13:20] <fwereade> jamespage, is there any action we should be taking for juju-core wrt https://bugs.launchpad.net/juju-core/+bug/1200878 ?
[13:20] <_mup_> Bug #1200878: Upgrade breaks existing pyjuju deployment <apport-collected> <papercut> <regression-release> <saucy> <juju-core:Triaged> <juju (Ubuntu):Fix Released> <juju-core (Ubuntu):Triaged> <https://launchpad.net/bugs/1200878>
[13:35] <dimitern> fwereade: before implementing relationunitswatcher I'll make a second attempt to remove the unitsettings from the relationunitchange struct
[13:37] <dimitern> fwereade: actually do you have some time for a g+?
[13:43] <jam> fwereade: bug #1200878 does sound like it is packaging-only
[13:44] <_mup_> Bug #1200878: Upgrade breaks existing pyjuju deployment <apport-collected> <papercut> <regression-release> <saucy> <juju-core:Triaged> <juju (Ubuntu):Fix Released> <juju-core (Ubuntu):Triaged> <https://launchpad.net/bugs/1200878>
[13:44] <jam> so more of a "juju-core (Upstream)" bug
[13:44] <jam> sorry juju-core (Ubuntu) only bug
[13:44] <jam> mgz: if you see jamespage can you ask him about ^^
[13:45] <jamespage> jam: its not packaging only
[13:45] <jamespage> fwereade, ^^
[13:46] <jamespage> the packaging upgrade just fine - but there is no way to upgrade a running py-juju environment to juju-core
[13:46] <jamespage> I restored py-juju to Saucy to allow people to continue managing py-juju environments....
[13:48] <jam> jamespage: I would argue that means we have a separate bug about a migration path, but bug #1200878 is about "apt-get upgrade" breaking a py-juju environment.
[13:48] <_mup_> Bug #1200878: Upgrade breaks existing pyjuju deployment <apport-collected> <papercut> <regression-release> <saucy> <juju-core:Triaged> <juju (Ubuntu):Fix Released> <juju-core (Ubuntu):Triaged> <https://launchpad.net/bugs/1200878>
[13:49] <jamespage> jam: I'm not concerned how this is represented in the bug tracker - so long as its documented that there is no migration path from py-juju to juju-core right now
[13:49] <jamespage> infact the bug was only about losing the ability to manage a py-juju environment
[13:49] <jamespage> not breaking it
[13:52] <jam> jamespage: fwereade: so last I recall we weren't going to spend effort trying to come up with a way to actually migrate a running environment. However, I wonder if "install GUI, get a Bundle, reinstall elsewhere" might be an answer?
[13:53] <fwereade> jamespage, jam: hazmat it looking into it somewhat actively now AIUI
[13:53] <jamespage> fwereade, indeed he is
[14:02] <dimitern> fwereade: ping
[14:02] <fwereade> dimitern, pong
[14:02] <dimitern> fwereade: g+?
[14:03] <fwereade> dimitern, sure, please start one
[14:03] <dimitern> fwereade: i'm running into issues with removing unitsettings's settings field and need some help understanding hookqueue and tests
[14:03] <dimitern> fwereade: https://plus.google.com/hangouts/_/f0bf3d6a8b15defb35894c5637399f0b87363f4b?hl=en
[14:08] <dimitern> fwereade: i'm waiting
[14:30] <sidnei> https://bugs.launchpad.net/juju-core/+bug/1220269
[14:30] <_mup_> Bug #1220269: update-<timestamp> directories being left behind <juju-core:New> <https://launchpad.net/bugs/1220269>
[15:13] <natefinch> jam, fwereade (and anyone else): what's your opinion on tests that simply duplicate the code in the function they're testing?  I hate not testing things, but I also hate duplicating code just for the sake of coverage metrics. For example: http://pastebin.ubuntu.com/6059183/
[15:14] <natefinch> jam, fwereade (and anyone else): (the os-specific functions have their own individual tests)
[15:14] <mgz> jam: I wonder if rather than exposing NonValidating as a thing inside goose, it mightn't be better to just have the alternate constructor take an http.Client object
[15:16] <mgz> then juju-core can just pass one in with the InsecureSkipVerify flag set, and maybe also reuse connections to other things
[15:23] <mgz> natefinch: do you still need help to get your azure branch landed?
[15:24] <natefinch> mgz: yeah... I've been procrastinating because I wasted so much time trying to get an azure environment up and running, I didn't want to waste more time on it until I knew it would be worth it.
[15:24] <natefinch> mgz: I probably should have hounded the red squad guys a little more to get it done
[15:24] <mgz> do you know what you wanted to test? we could just ask one of red to try it out.
[15:25] <natefinch> mgz: *nod* that's a decent idea. It's just the addressability stuff.  I think I'd have to write some custom code for it, since AFAIK, the addresses aren't actually used anywhere right now.... is that correct? Or is it one of those things where it's stubbed out and once it's not it'll get picked up?
[15:26] <mgz> just looking at hostname should do, but it would be a little easier with a few extra bits
[15:26] <mgz> an actual live test would be great...
[15:27] <natefinch> mgz: maybe allenap has an azure environment that works, or knows someone on red squad that does?
[15:28] <mgz> all of them should have a working setup
[15:48] <dimitern> fwereade: when you're back and have some time PTAL https://codereview.appspot.com/13494043 and also let's discuss how to live test it with the local provider
[15:53] <jam> natefinch: I would think we have helpers for patching the environment, but if we don't you code is ok.  I would probably change the comment to "unset JUJU_HOME to force OS specific home selection".
[15:53] <jam> natefinch: your test also gives us some ability to grow it as we might need to do something different on other platforms (though Darwin looks to still use $HOME for now at least)
[15:55] <jam> natefinch: "tests for tests sake" still fall in the "if I change X something lets me know that I might have broken something" other than just assuming I manually audited everything.
[18:21] <hazmat> is there any timeline on manual provisioning?
[21:19] <thumper> hi hazmat
[21:19] <thumper> hazmat: landed in trunk
[21:19] <thumper> hazmat: it may even be in 1.13.3, I'd have to check
[21:19] <thumper> hazmat: although axw does need to write some docs for it
[21:21] <hazmat> thumper, awesome
[21:21] <thumper> hazmat: new focus on that area is the null provider and manual bootstrap
[21:22] <hazmat> thumper, so the manual provisioning works with existing providers?
[21:22] <thumper> yes
[21:22] <hazmat> perfect
[21:22] <thumper> as long as the machine you are adding can see the bootstrap node
[21:22] <thumper> all is good
[21:22] <thumper> caveat:
[21:22] <thumper> unlikely to work with the local provider
[21:23] <thumper> as it gives a 10.3.0.0/24 address for storage
[21:23] <thumper> we should write that down
[21:23] <thumper> :)
[21:23] <hazmat> thumper, i was mostly considering maas as a context
[21:23] <thumper> should work fine there
[21:23] <hazmat> thumper, i wonder if will ever get to the point that we can consider undocumented features are a bug
[21:24] <thumper> yes, I think we should
[21:25] <hazmat> the stop gap for core dev documenting features was supposed to be rel notes, but this one didn't make it in.
[21:26] <thumper> no, it should have
[21:26]  * thumper will poke the right people :)
[21:40] <hazmat> thumper, got a moment to chat re manual bootstrap?
[21:41] <thumper> um... sure..
[22:46]  * thumper dies a little inside
[23:05]  * bigjools prods thumper
[23:05]  * thumper jumps
[23:05] <bigjools> there. not dead.
[23:06] <bigjools> (I have caffeine for that)
[23:42] <axw> thumper: my exchange's fibre got severed yesterday afternoon. apparently the current connectivity is a temporary workaround
[23:42] <axw> so if I'm not online today, that's why
[23:42] <axw> (and it's why I wasn't online from 3:30 yesterday)
[23:42] <thumper> ok, np
[23:42]  * thumper is heading off to the gym shortly
[23:45] <axw> enjoy