[00:03] <wallyworld> thumper: you around?
[00:07] <bradm> anyone know much about neutron?  having issues with a juju deployed openstack
[00:14] <wallyworld> bradm, mgz knows most about neutron but he's probably asleep
[00:15] <bradm> wallyworld: I seem to be on the wrong side of the world to be dealing with neutron, everyone who seems to know it is asleep
[00:16] <wallyworld> yeah :-(
[00:25] <thumper> wallyworld: hi
[00:25] <wallyworld> gday
[00:25] <wallyworld> got time for a chat?
[00:26] <thumper> yup
[00:26] <thumper> ish
[00:27] <wallyworld> it will be quick, just a heads up from the standup last night
[00:28] <wallyworld> https://plus.google.com/hangouts/_/calendar/bWFyay5yYW1tLWNocmlzdGVuc2VuQGNhbm9uaWNhbC5jb20.sbtpoheo4q7i7atbvk9gtnb3cc?authuser=1
[01:12] <davecheney> 2014-02-26 01:11:42 ERROR juju runner.go:220 worker: exited "environ-provisioner": failed to process updated machines: error executing "lxc-ls": wait: no child processes
[01:12] <davecheney> 2014-02-26 01:11:43 ERROR juju.container.lxc lxc.go:166 failed getting all instances: error executing "lxc-ls": wait: no child processes
[01:12] <davecheney> ^ local provider peeps
[01:12] <davecheney> any ideas ?
[01:14] <axw> can't say I've seen that. busted packages again? :(
[01:17] <davecheney> is lxc-ls bailing before the wait occurs ?
[01:19] <axw> ah, I read it as an error coming back from lxc-ls
[01:19] <davecheney> ubuntu@winton-02:~$ lxc-ls
[01:19] <davecheney> ubuntu@winton-02:~$ echo $?
[01:19] <davecheney> 0
[01:19] <axw> not sure.
[01:19] <davecheney> weird
[01:19] <axw> try lxc-ls -1
[01:19] <axw> (one, not ell)
[01:20] <axw> and again as root
[01:20] <davecheney> ubuntu@winton-02:~$ sudo lxc-ls
[01:20] <davecheney> dave  foo   ken   ryu
[01:20] <davecheney> interesting
[01:20] <davecheney> ubuntu@winton-02:~$ ps auxww | grep jujud
[01:20] <davecheney> root     24736  3.0  7.5 8262756 621576 ?      Ssl  Feb22 174:19 /home/ubuntu/.juju/local/tools/machine-0/jujud machine --data-dir /home/ubuntu/.juju/local --machine-id 0 --debug
[01:20] <davecheney> but the machine agent is running as root
[01:21] <axw> does "sudo lxc-ls -1" do anything different?
[01:21] <axw> doubtful..
[01:23] <axw> davecheney: the golxc code is just doing exec.Command("lxc-ls", "-1").CombinedOutput()
[01:23] <axw> so... *shrug*
[01:23] <davecheney> ubuntu@winton-02:~$ sudo lxc-ls -1
[01:23] <davecheney> dave
[01:23] <davecheney> foo
[01:23] <davecheney> ken
[01:23] <davecheney> ryu
[01:23] <davecheney> same, but different
[01:23] <davecheney> screw it
[01:24] <axw> yeah -1 just means one per line, didn't think it'd matter
[01:24] <davecheney> gonna destroy and start again
[01:31] <thumper> waigani: ping - standup
[01:50] <davecheney> + /home/ubuntu/bin/juju destroy-environment -y local
[01:50] <davecheney> + /home/ubuntu/bin/juju bootstrap
[01:50] <davecheney> ERROR cannot use 37017 as state port, already in use
[01:50] <davecheney> sigh
[01:51] <davecheney> bloody hell
[01:51] <davecheney> what ?
[01:51] <davecheney> there is nothing listening on that port ....
[01:52] <davecheney> ERROR cannot use 37017 as state port, already in use
[01:52] <davecheney> ubuntu@winton-02:~$ ss | grep 37017
[01:52] <davecheney> ubuntu@winton-02:~$
[01:54] <mwhudson> davecheney: i don't think that's a good way to check
[01:54] <mwhudson> you want ss -nl i think?
[01:59] <davecheney> oh
[01:59] <davecheney> serves me right for using hipster tools
[01:59] <davecheney> i'll go back netstat -anp next time
[01:59] <davecheney> ubuntu@winton-02:~$ sudo !!
[01:59] <davecheney> sudo netstat -anp | grep 37
[01:59] <davecheney> tcp        0      0 0.0.0.0:37017           0.0.0.0:*               LISTEN      24711/mongod
[02:00] <davecheney> intersting
[02:00] <davecheney> i wonder why it didn't die
[02:29] <thumper> axw, wallyworld, waigani: we'll just use this one... https://plus.google.com/hangouts/_/calendar/dGltLnBlbmhleUBjYW5vbmljYWwuY29t.kieq2g96khnegtjsretb0l4clo
[02:31] <wallyworld> thumper: says not allowed to join
[02:31] <thumper> pfft
[02:31] <axw> same
[02:31]  * thumper sighs
[02:31] <thumper> this was the one from the package review
[02:32] <thumper> you are now invited
[03:03] <jam> thumper: poke, are you still online?
[03:03] <thumper> jam: yes, am with the team talking timings :)
[03:06] <jam> thumper: I'm available for video chat for a bit if you want
[03:20] <thumper> jam: available now
[03:31] <jam> thumper: starting up G+ hangout now
[03:31] <thumper> kk
[03:31] <jam> thumper: https://plus.google.com/hangouts/_/7ecpikfgr7oi6hsg74ds6jdcl0
[04:45] <bigjools> thumper: seriously lol-ing at your twitter conversation this morning
[06:23] <axw> oh wtf
[06:25]  * axw stops wtf'ing
[06:25] <axw> the bot marked the wrong MP as merged
[07:01] <jam> axw: where?
[07:02] <jam> I can't say that I've seen that before
[07:02] <jam> the bot doesn't actually do it
[07:02] <jam> Launchpad detects when the tip revision has been merged into trunk
[07:02] <jam> so it is generally accurate
[07:02] <axw> jam: https://code.launchpad.net/~axwalk/juju-core/lp1281071-rsyslog-tls/+merge/207889
[07:02] <axw> what I did was I created another branch, merged that one in but removed all the stuff I didn't care about
[07:03] <axw> so LP saw the merged revisions
[07:03] <jam> axw: the above branch is "andrew.wilkins@canonical.com-20140225140210-4206fc8pbnfkpb46" which is rev 2349.2.5 in trunk
[07:03] <jam> so that MP was *merged*, just from something else
[07:05] <axw> yeah, makes sense - I just haven't done that before and was a bit surprised
[07:05] <jam> be careful when clicking near tabs :)
[07:06] <axw> :)
 yeah, makes sense - I just haven't done that before and was a bit surprised
[07:06] <axw> jam: yes, the rev is there, I just took out most of what's in that MP
[09:25] <dimitern> fwereade, wrtp, i'd appreciate a review and some direction on https://codereview.appspot.com/66540044
[09:29] <wrtp> dimitern: looking
[09:51] <wrtp> dimitern: reviewed
[09:52] <dimitern> wrtp, ta!
[09:56] <mattyw> dimitern, your review here: https://codereview.appspot.com/67870043/ do you mean I need to implement the new status code in FullStatus only - and not in Status?
[09:58] <dimitern> mattyw, FullStatus only - Status uses FS internally, when needed (1.16 compat mode)
[09:59] <dimitern> fwereade, wrtp, so, it seems we'll need to define the next agent conf version - should it be 1.17 or 1.18? I'm thinking of adding Version, DataDir, LogDir, possibly Jobs as fields
[10:00] <rogpeppe> dimitern: i don't think it makes sense to define formats for dev versions
[10:00] <mattyw> dimitern, ok thanks
[10:00] <rogpeppe> dimitern: so i'd suggest 1.18
[10:02] <dimitern> rogpeppe, ok, and in that version we'll use a single file + version, no format separately
[10:02] <rogpeppe> dimitern: yeah
[10:02] <dimitern> rogpeppe, can you think of any other fields we might need to define except the ones above?
[10:03] <rogpeppe> dimitern: what is "Version" there? the agent configuration version?
[10:05] <dimitern> rogpeppe, ok Format then
[10:05] <rogpeppe> dimitern: what does it hold?
[10:07] <dimitern> rogpeppe, the agent conf format version
[10:10] <rogpeppe> dimitern: i'm not sure we want to expose that outside of the agent package
[10:10] <rogpeppe> dimitern: and i don't think it should be a regular field
[10:10] <rogpeppe> dimitern: i suggest that we store the version on a line of its own before any of the other conf data
[10:10] <dimitern> rogpeppe, expand?
[10:11] <rogpeppe> dimitern: then we can read the version and use it to decide how to parse the rest of the config data
[10:11] <rogpeppe> dimitern: which gives us freedom to change file formats in the future if we want (for example to move away from YAML)
[10:12]  * rogpeppe has just got his laptop back through the post
[10:12] <rogpeppe> and they've cleaned it all up - it doesn't look like my scruffy laptop any more :-)
[10:13] <rogpeppe> let's see if it works...
[10:13] <rogpeppe> ha, they replaced the keyboard!
[10:17] <jam> rogpeppe: I'm glad you got it back in time, congrats
[10:18] <dimitern> rogpeppe, \o/
[10:18] <dimitern> rogpeppe, ok, that sgtm
[10:20] <rogpeppe1> jam: yay! back on the thinkpad!
[10:46] <jam> rogpeppe: fwereade, dimitern: standup?
[10:50] <jam> fwereade: poke ?
[10:51] <fwereade> jam, sorry, couple of mins
[10:58] <jam> mgz: poke ?
[10:59] <mgz> jam: ta
[11:08] <jam> fwereade: one more quick standup ping?
[11:48] <rogpeppe> fwereade: https://codereview.appspot.com/68650044
[11:51] <jam> rogpeppe: https://bugs.launchpad.net/juju-core/+bug/1254577 is still marked Critical and not Fix Committed. I thought you landed code related to that?
[11:52] <rogpeppe> jam: marked as "fix committed"
[11:52] <jam> rogpeppe: do you know if that got released in 1.17.3
[11:52] <jam> ?
[11:53] <rogpeppe> jam: i certainly hope so. let me check.
[11:55] <rogpeppe> jam: well, the fix was merged 3 weeks ago, so i should certainly hope so
[11:57] <jam> does anyone have the link to the current CI runs? I seem to have an old IP address that is no longer valid
[11:57] <jam> sinzui: ^^
[12:13] <natefinch> jam: FYI I have an old IP too, not sure what happened.  Sinzui is likely still asleep, but when he responds, I'll email out the new IP.
[12:21] <fwereade> frankban, dimitern: does charm get handle symlinks at all?
[12:22] <dimitern> fwereade, because it uses a zip reader internally, i guess it should
[12:22] <fwereade> frankban, dimitern: it looks like it's just sending the target path and I'm not convinced that's useful
[12:23] <frankban> fwereade: I guess it depends on how they are handled by zip.ReadCloser
[12:24] <dimitern> frankban, fwereade, but a test with a zip + symlinks is definitely useful
[12:24] <fwereade> frankban, dimitern: ok, what do you think we should be doing? sending the actual content of the target?
[12:25] <frankban> fwereade: makes sense
[12:25] <dimitern> fwereade, frankban, that sounds reasonable
[12:25] <frankban> fwereade, dimitern: trying with a symlink
[12:25] <fwereade> dimitern, frankban: ok, cheers, I'll see what I can do
[12:28] <fwereade> dimitern, frankban: also, would it be *really* annoying if I changed the filelist stuff to return directories as well? I freely admit this is more rooted in convenience than any solid design principles
[12:29] <fwereade> dimitern, frankban: hmm, I think we may need special handling for the revision file too
[12:29] <frankban> fwereade: not annoying for me
[12:30] <fwereade> frankban, cool, basically I'd like to just return the result of the imminently-available Bundle.Manifest method
[12:30] <frankban> fwereade: re: revision file, is it special?
[12:31] <fwereade> frankban, its presence is not guaranteed in the zip file, but it is always returned by Manifest because we do always write one out
[12:31] <frankban> fwereade: oh, so you'll instantiate a bundle and it will have a Manifest returning the file list?
[12:31] <fwereade> frankban, it'll *almost* certainly always be there, but it's that "almost" that's the issue ;)
[12:31] <fwereade> frankban, yeah, I think so -- is a ReadBundle unreasonable at that point?
[12:32] <frankban> fwereade: OIC, if it's not there there is no problem from our perspective, AFAICT we are not interested in the revision file for that API. but I agree, if it's in the list, we must also return its contents
[12:34] <frankban> fwereade: in my previous impl (before requirements changes) I used ReadBundle to and ExpandTo to extract the files, so, it makes sense. I wonder if at that point a bundle.GetFile would be reasonable too.
[12:36]  * fwereade starts wondering about a Content(path) method
[12:37] <fwereade> frankban, yeah, I'm just having trouble integrating the symlink-resolution stuff in my current model
[12:41] <fwereade> frankban, how do we currently behave if you ask for a path to a dir?
[12:41] <fwereade> frankban, ah 403 cool
[12:41] <frankban> fwereade: forbidden
[12:41] <frankban> yeah
[12:41] <fwereade> frankban, ok, I think that works for me
[12:42] <fwereade> frankban, dimitern: can we do a really quick hangout?
[12:43] <frankban> fwereade: sure
[12:43] <dimitern> fwereade, frankban, sure
[12:43] <fwereade> dimitern, frankban: https://plus.google.com/hangouts/_/7ecpjumv8629dqrig0jdegier8?hl=en
[13:19] <rogpeppe> fwereade: you've got a review: https://codereview.appspot.com/69110043/
[13:21] <sinzui> jam, natefinch http://162.213.35.54:8080/ and it appears ill (and we stood it up 2 days ago too)
[13:21] <sinzui> oh, no route to host
[13:21] <jam> sinzui: k, so that I can't get to it is probably because it isn't there :)
[13:22] <natefinch> heh
[14:12] <rogpeppe> dimitern: i've responded to your review
[14:13] <rogpeppe> dimitern: i'd appreciate the rest, if you have some time
[14:14] <dimitern> rogpeppe, thanks, i'll look into it a bit later
[14:14] <rogpeppe> dimitern: ta
[14:14] <rogpeppe> natefinch, fwereade: your reviews appreciated too
[14:51] <niemeyer> rogpeppe: Hey, just a ping to let you know your branch got merged, and the tests that were failing due to the panic formatting changes in recent Go versions have also been fixed
[14:52] <rogpeppe> niemeyer: great, thanks. i was planning to get around to merging it, but my laptop died which was a distraction
[14:52] <rogpeppe> niemeyer: i'll update the juju-core deps file
[14:52] <niemeyer> rogpeppe: Thanks
[14:59] <dimitern> rogpeppe, what are these cryptic 0v 1p in member definitions
[14:59] <rogpeppe> dimitern: see the definition of mkMembers and mkStatuses
[15:00] <dimitern> rogpeppe, right, thanks
[15:00] <niemeyer> mramm, fwereade: Are we having that call today?
[15:01] <mramm> I'm in the hangout
[15:01] <mramm> if you want to have it
[15:01] <mramm> but I don't have any items for today's agenda
[15:02] <mramm> so I am also fine with skipping today
[15:03] <niemeyer> mramm: I'm joining
[15:21] <natefinch> rogpeppe: resuming the review now
[15:21] <rogpeppe> natefinch: thanks!
[15:33] <rogpeppe> lunch
[15:46] <sinzui> natefinch, rogpeppe , is someone adding support to install juju-mongodb when it is available?
[15:46] <rogpeppe> sinzui: i think that's the plan, but i don't know its current status
[15:47] <sinzui> rogpeppe, thank you
[15:50] <dimitern> rogpeppe, reviewed
[15:50] <rogpeppe> dimitern: ta!
[15:50] <natefinch> sinzui: it is planned but I don't think anyone is assigned. I did the other part, but someone else should probably do this part, since I am way behind on HA stuff.
[15:51] <sinzui> natefinch, fab. I think I will work to release juju 1.17.4 as it is for people working on trusty and other archs
[16:03] <dimitern> rogpeppe, fwereade, so with the introduction of agent conf format 1.18 we should drop 1.12 format support, right?
[16:03] <fwereade> rogpeppe, would you explain the windows 022 thing a bit more?
[16:03] <rogpeppe> fwereade: i think so
[16:03] <rogpeppe> dimitern: i think so
[16:03] <dimitern> ok :)
[16:03] <fwereade> dimitern, hmm, I have a nasty feeling that 1.12 might try to upgrade arbitrarily far
[16:04] <rogpeppe> fwereade: so, i'm not convinced that we'll get sane-looking perms from windows-generated zip files
[16:04] <dimitern> fwereade, so?
[16:04] <dimitern> fwereade, it will fail
[16:04] <rogpeppe> fwereade: from previous experience with unix-like perms on windows
[16:04] <rogpeppe> fwereade: natefinch may know more of the expected behaviour
[16:04] <fwereade> dimitern, so I'm not sure that we can guarantee that 1.18 won't start up with a 1.12 conf
[16:05] <fwereade> dimitern, it may just be a matter of shouting about it in the release notes though
[16:06] <fwereade> rogpeppe, natefinch: in particular I don't quite get what `&=022` would do, maybe because I'm not sure where you mean me to apply it
[16:06] <dimitern> fwereade, well, we can't guarantee compatibility 16 releases back anyway, so it should just fail in some sensible way
[16:07] <rogpeppe> fwereade: it would clear group and other write permissions from all files and directories
[16:08] <rogpeppe> fwereade: sorry, it should have been &^022
[16:09] <rogpeppe> fwereade: another possibility is to use ((p&7) | (p&7)<<3 | (p&7)<<6)) & ^022
[16:10] <rogpeppe> fwereade: i.e. ignore group and other modes, don't allow any group/user write perms, and use r and x bits from user perms for group and other
[16:10] <rogpeppe> fwereade: but that means it's not possible to make a non-group or other -readable file
[16:26] <natefinch> fwereade, rogpeppe:  catching up....   perms on windows are way different.  Not 100% sure on how Go translates permission bits to windows
[16:26] <rogpeppe> natefinch: yeah.
[16:26] <rogpeppe> natefinch: what do you think windows-created zip files will report for permissions?
[16:27] <rogpeppe> natefinch: perhaps you could create a zip file under windows, with a variety of permissions, and we could find out
[16:28] <natefinch> rogpeppe: yeah, that';s what I was thinking.  I don't know what linux defaults to when it sees a windows file that doesn't have permissions like that set.  I'll try it out, easy enough
[16:28] <rogpeppe> fwereade: one thought is that if we're unpacking the charm under unix, it's pretty unlikely that the charm was zipped under windows
[16:28] <rogpeppe> natefinch: i did some of the go zip perms code, ages ago, but i can't remember much about it and it's probably changed since i did it
[16:28] <rogpeppe> natefinch: i think the trauma of reading the zip spec must've blanked my memory :-]
[16:29] <natefinch> rogpeppe: hahah
[16:34] <fwereade> natefinch, rogpeppe: sorry, multitasking fail
[16:36] <natefinch> rogpeppe: by default it's 0664
[16:36] <rogpeppe> natefinch: which default?
[16:36] <natefinch> -rw-rw-r--  for those of us less binarily inclined
[16:36] <natefinch> rogpeppe: if I just create a zip without specifying permissions
[16:36] <rogpeppe> natefinch: is that Go's behaviour or windows' ?
[16:37] <natefinch> rogpeppe: windows, sorry
[16:37] <rogpeppe> natefinch: have you tried unpacking that using Go, to make sure
[16:37] <natefinch> rogpeppe: not yet, I'll do that
[16:38] <natefinch> rogpeppe: unpacking on linux, I presume?
[16:39] <rogpeppe> natefinch: it shouldn't make any difference
[16:39] <rogpeppe> natefinch: you don't actually need to create the file
[16:39] <fwereade> rogpeppe, natefinch: fwiw we *do* make sure that hooks are executable when we unpack *anyway* and I suspect this hits most of the cases -- 644/744 should be enough for anyone, right?
[16:39] <rogpeppe> natefinch: just see what perms are reported
[16:39] <fwereade> rogpeppe, natefinch: indeed assuming that *is* what's reported
[16:40] <rogpeppe> fwereade: i'd go for 755 rather than 744
[16:40] <rogpeppe> fwereade: but yeah, i don't think there's a huge issue here
[16:40] <rogpeppe> fwereade: it's worth going into it with our eyes open though
[16:40] <rogpeppe> fwereade: (i have definitely hit problems in this area in a previous lifetime)
[16:41] <fwereade> rogpeppe, natefinch: I'm not *really* expecting we'll get a lot of people writing charms on windows anyway tbh
[16:42] <fwereade> rogpeppe, natefinch: drag a charm archive into a browser on windows? plausible
[16:42] <fwereade> rogpeppe, natefinch: zip up a subtly wrong dir and drag it into a browser on linux? also plausible
[16:43] <fwereade> rogpeppe, natefinch: "develop" a charm sight unseen on windows, and deploy it to a real ubuntu cloud straight off? seems less likely
[16:43] <rogpeppe> fwereade: it's possible but i think that the resulting issues probably won't be *too* bad
[16:43] <rogpeppe> fwereade: exactly
[16:45] <rogpeppe> fwereade:  one other thing occurs to me: the perms you'll get when creating a file with os.OpenFile may well be different from the perms you get when doing a chmod
[16:45] <rogpeppe> fwereade: because of umask
[16:46] <rogpeppe> fwereade: to be consistent, perhaps we should AND all the perms with the current umask before doing anything
[16:48] <fwereade> &^umask, right?
[16:50] <natefinch> rogpeppe, fwereade: btw the unzipped files w/ go are created with 0664, too.
[16:51] <rogpeppe> fwereade: yeah
[16:51] <rogpeppe> natefinch: that's not a great default, but umask should sort it out
[16:54] <fwereade> natefinch, ok, that seems probably good enough to me?
[16:54] <fwereade> rogpeppe, added v brief notes on https://codereview.appspot.com/68650044/ -- I'll be looking at it some more
[16:55] <fwereade> rogpeppe, but it is explicitly *not* nlgtmed, so please do not take my need to convince myself further as a roadblock
[16:59] <rogpeppe> fwereade: i'd be interested to know what kind of thing you're thinking about when you suggest a "simpler and dumber model"
[17:02] <rogpeppe> fwereade: i agree that the current mocking setup is somewhat experimental, but i *think* it beats trying to get the real State to jump through all those hoops
[17:03] <fwereade> rogpeppe, yeah, definitely agreed
[17:06] <rogpeppe> fwereade: the IsNotFound cases are the only place in the code we don't have 100% coverage. that's mainly because i haven't yet thought of a decent way to "wait for nothing to happen"
[17:07] <rogpeppe> fwereade: i'd also be interested to know where you found it difficult to follow the code, so i can add an appropriate comment or two
[17:23] <fwereade> rogpeppe, I'll hopefully have some better comments later today
[17:24] <rogpeppe> fwereade: i've just approved the MP BTW, but i'll take on board any further comments and integrate them into the next branch
[17:24] <fwereade> rogpeppe, I do find myself wondering whether we actually kinda want to unpack charms with the permissions in the zip file, umask be damned
[17:24] <fwereade> rogpeppe, thanks
[17:24] <rogpeppe> fwereade: i'm not sure
[17:24] <rogpeppe> fwereade: an easy way to do that is to set umask to 0
[17:25] <rogpeppe> fwereade: umask is kinda dumb anyway
[17:25] <rogpeppe> fwereade: i preferred the plan 9 way of doing things, where the default perms were taken from the parent dir
[17:25] <fwereade> rogpeppe, heh, but then we do want to keep using the default umask for hook execution I think
[17:25]  * fwereade rather agrees tere
[17:26] <rogpeppe> fwereade: i don't know. what do you think the expectation of umask is for charm authors?
[17:27] <fwereade> rogpeppe, there were bugs about it in the past
[17:27] <fwereade> rogpeppe, iirc the expectation is "execute hooks with the system umask"
[17:28] <rogpeppe> fwereade: the other thing that i didn't remark on in the review, is what happens if you have a directory with non-writable permissions, but it contains some files?
[17:28] <rogpeppe> fwereade: i *think* that in general it's a moot point because zip files don't usually mention directories explicitly
[17:28] <rogpeppe> fwereade: but it can be an issue
[17:32] <fwereade> rogpeppe, yeah, my thinking was mainly that unwritable things are unlikely to come up in practice, and when they do we have ErrConflict
[17:32] <fwereade> rogpeppe, because I certainly don't know what the point of having such things would be
[17:32] <rogpeppe> fwereade: alternatively, make sure that all directories are at least 700
[17:33] <rogpeppe> fwereade: me neither, but it's difficult to pre-guess
[17:33] <fwereade> rogpeppe, and thus am unqualified to impose expectations
[17:35] <ev> hiya. Is ssh forwarding broken? http://paste.ubuntu.com/7000920/
[17:35] <ev> that's on 1.17.3-saucy-amd64
[17:37] <rogpeppe> ev: hmm, it would be interesting to find out what actual command line is being executed there
[17:37] <ev> rogpeppe: hm? Isn't that in the pastebin?
[17:37] <mgz> is that just bug 1281577
[17:37] <_mup_> Bug #1281577: juju 1.17.2 doesn't pass command line options to ssh <docs> <landscape> <regression> <ui> <juju-core:Fix Committed by dimitern> <https://launchpad.net/bugs/1281577>
[17:37] <ev> ah, that's the badger
[17:37] <ev> thanks guys
[17:37] <rogpeppe> ev: no, sorry, i mean the ssh comment
[17:38] <rogpeppe> mgz: thanks
[17:38] <mgz> ev: sinzui is doing 11.17.4 today which has the fix
[17:38] <mgz> -1
[17:41] <ev> whoop!
[17:42] <natefinch> rogpeppe, fwereade: btw, it looks like zip files don't actually include the directory information, just implicitly through paths on files (at least the ones I created on windows 7).
[17:43] <fwereade> natefinch, would you mail me one please?
[17:43] <rogpeppe> natefinch: that's what i meant by "zip files don't usually mention directories explicitly"
[17:43] <rogpeppe> natefinch: i think it's possible for them to do so though
[17:44] <rogpeppe> natefinch: i *think* it's possible to have empty dirs in a zip file
[17:45] <natefinch> rogpeppe: windows won't let you do it : [Window Title]
[17:45] <natefinch> Compressed (zipped) Folders
[17:45] <natefinch> [Content]
[17:45] <natefinch> Windows was unable to add one or more empty directories to the Compressed (zipped) Folder.
[17:45] <natefinch> [OK]
[17:45] <rogpeppe> natefinch: ha ha
[17:45] <rogpeppe> natefinch: no one likes those poor empty directories
[17:45] <natefinch> rogpeppe: I'd just been testing that
[17:45] <rogpeppe> natefinch: apart from bzr, which is being phased out
[17:45] <natefinch> rogpeppe: yeah, it's kinda sad, because they can have value.
[17:46] <rogpeppe> natefinch: they're really important sometimes
[17:46] <natefinch> rogpeppe: if for nothing else than "here's where you should put X stuff"
[17:47] <mgz> natefinch: certainly tools *exist* on windows that let you add empty dirs to zips...
[17:47] <mgz> whether they're what people use is another matter
[17:47] <natefinch> mgz: yeah, probably 7zip etc would allow it.  Certainly we should support it if it's possible.
[17:47] <mgz> 7zip does, just tested
[17:50] <natefinch> mgz: good to know.
[17:54] <natefinch> rogpeppe: we should probably talk HA next steps before your EOD, or jam will have my head for not putting up some tasks on kanban
[17:55] <rogpeppe> natefinch: i'm just working on that, but let's have a chat about it
[17:55] <rogpeppe> natefinch: in fact, give me 10 mins to finish my thoughts here
[17:55] <natefinch> rogpeppe: sure thing'
[18:06] <sinzui> mgz, ev : I hope to do a 1.17.4 release tomorrow. nova/canonistack lost the ci machine abotu 12 hours. We had to stand up another one as our first priority
[18:07] <mgz> sinzui: eck... we need a less overcommitted region probably :0
[18:08] <sinzui> mgz, It happened last week too. We will move to another region or cloud
[18:12] <ev> sinzui: *nods* I've just sent instructions to my team on using juju from trunk for this
[18:12] <rogpeppe> natefinch: https://plus.google.com/hangouts/_/calendar/am9obi5tZWluZWxAY2Fub25pY2FsLmNvbQ.mf0d8r5pfb44m16v9b2n5i29ig?authuser=1
[18:12] <ev> HP has hilariously set really low limits on not only security groups, but security group rules
[18:12] <ev> so wooo tunnels
[18:13] <ev> I don't suppose I could convince someone to update the simplestreams stuff to use the new US/West HP Cloud region?
[18:13] <ev> we've uploaded the right thing to a public bucket on one of our HPCloud accounts for now
[18:14] <sinzui> ev, Juju-CI just built UNRELASED debs for trusty, saucy, and precise. This is the release candidate we are testing: http://162.213.35.54:8080/job/publish-revision/
[18:14] <sinzui> if ev, this is the actual release tarball we will use on success: http://162.213.35.54:8080/job/build-revision/
[18:15] <ev> ( https://region-a.geo-1.objects.hpcloudsvc.com/v1/11289530460295/images and https://region-a.geo-1.objects.hpcloudsvc.com/v1/11289530460295/tools )
[18:15] <ev> sinzui: *nods* thanks!
[19:20]  * rogpeppe is done for the day
[19:20] <rogpeppe> g'night all
[19:21] <rogpeppe> fwereade: there are now some kanban cards for HA, BTW
[19:51] <thumper> o/
[21:59] <thumper> waigani: https://bugs.launchpad.net/juju-core/+bug/1281394
[21:59] <_mup_> Bug #1281394: uniter failed to run non-existant config-changed hook <regression> <juju-core:Triaged by thumper> <https://launchpad.net/bugs/1281394>
[22:10] <thumper> wallyworld: just for you: http://pastebin.ubuntu.com/7002116/
[22:10] <wallyworld> looking
[22:11] <wallyworld> is this trunk?
[22:11] <thumper> aye
[22:11] <thumper> pulled trunk, started a local provider
[22:11] <wallyworld> hmmm. worked for me before :-(
[22:11] <wallyworld> and CI
[22:12] <wallyworld> ok, i'll have to look
[22:12] <thumper> and also deployed ubuntu charm
[22:12] <thumper> that is all
[22:12] <thumper> well, it is up and running
[22:12] <thumper> but the worker is bouncing
[22:12] <wallyworld> sigh, yeah will look
[22:12] <wallyworld> but i'm in a good mood - got support for IDE based debugging :-)
[22:13] <wallyworld> niiiiiice
[22:13] <wallyworld> no more fmt.Printf() to see wtf is going on
[22:21] <thumper> haha
[22:21] <thumper> nice
[22:21] <waigani> Tim just shot me
[22:22] <thumper> nerf
[22:34] <wallyworld> thumper: what juju version were you upgrading local provider env from?
[22:34] <thumper> I wasn't upgrading
[22:34] <thumper> I was just starting it
[22:35] <wallyworld> hmmm. ok
[22:38] <wallyworld> thumper: since you're ocr :-) could you +1 this one roger looked at - i've responded to changes but he didn't get to +1 yesterday. there's also https://codereview.appspot.com/68990043/ :-D
[22:38] <thumper> i'm ocr?
[22:38] <wallyworld> it says so on the calendar :-)
[22:38]  * thumper sighs
[22:38] <thumper> suppose I am then...
[22:38] <thumper> yes, I'll look soonish
[22:39] <wallyworld> yep :-)
[22:39] <wallyworld> no hurry
[22:39] <wallyworld> i have 4 branches stacked up i need to land
[22:39] <wallyworld> so just keen to clear the queue sometime today or whenever
[22:40] <thumper> yeah yeah
[22:41]  * thumper puts wallyworld on the TODO soonish stack
[22:45] <wallyworld> no hurry