| waigani | wallyworld_: morning | 00:13 |
|---|---|---|
| wallyworld_ | hey | 00:13 |
| waigani | I have a problem for you: | 00:13 |
| waigani | pulled trunk, got "undefined: ratelimit.New", go get github.com/juju/ratelimit, still get error. What did I miss? | 00:13 |
| wallyworld_ | what error? | 00:14 |
| waigani | ratelimit is undefined | 00:14 |
| waigani | it can't find the package | 00:14 |
| wallyworld_ | go get -u | 00:14 |
| wallyworld_ | maybe | 00:14 |
| waigani | ah | 00:14 |
| davecheney | marcoceppi: thanks for fixing the charm-helper-sh problem | 00:15 |
| waigani | wallyworld_: no luck, strange.. | 00:15 |
| wallyworld_ | hmmm | 00:15 |
| wallyworld_ | i did hear that tip of ratelimit is not compatible with juju core | 00:16 |
| wallyworld_ | but for the whole package to be undefined doesn't fit with that | 00:16 |
| wallyworld_ | i just pulled ratelimit and it is there | 00:17 |
| waigani | it must be something with my setup, otherwise others would be hitting this | 00:17 |
| wallyworld_ | are you sure your GOPATH is correct? | 00:18 |
| waigani | I'll check go paths etc (again!) | 00:18 |
| waigani | hmm, GOPATH looks correct, ratelimit is in $GOPATH/src/github.com/juju/ratelimit, tried rebuilding pkg hmmm | 00:24 |
| === thumper-gym is now known as thumper | ||
| thumper | mwhudson: where are you off to? | 00:24 |
| mwhudson | thumper: uk | 00:24 |
| thumper | sprint? | 00:24 |
| thumper | or holiday? | 00:24 |
| davecheney | waigani: i'm concerned that the solution to your problems is 'rebuild' everything | 00:24 |
| mwhudson | holiday! | 00:24 |
| mwhudson | dad's 80th | 00:24 |
| thumper | nice | 00:25 |
| davecheney | that smells like something is wrong with your setup | 00:25 |
| thumper | have fun | 00:25 |
| thumper | waigani: you need to do this: | 00:25 |
| thumper | go get github.com/juju/ratelimit | 00:25 |
| thumper | then run | 00:25 |
| mwhudson | thumper: i have to keep reminding myself that the routing with 6 hours in sydney was over $1000 cheaper :-) | 00:25 |
| thumper | godeps -u dependencies.tsv | 00:25 |
| thumper | mwhudson: haha | 00:25 |
| davecheney | mwhudson: where you going ? neptune ? | 00:25 |
| thumper | mwhudson: emma and pheobie going too? | 00:25 |
| thumper | mwhudson: how do you spell that? | 00:26 |
| * thumper feels like it is wrong | 00:26 | |
| mwhudson | thumper: no, solo | 00:26 |
| mwhudson | thumper: phoebe | 00:26 |
| davecheney | o before e == long eee sound | 00:26 |
| waigani | thumper: thanks, davecheney: more of a desperate attempt than a solution | 00:26 |
| davecheney | waigani: lets fix the underlying problem | 00:27 |
| thumper | waigani: you have godeps built? | 00:27 |
| davecheney | please tell the doctor where it hurts | 00:27 |
| thumper | davecheney: the underlying problem is not having the deps right :) | 00:27 |
| hatch | hey I just updated to 1.17.5 on precise and now local machines give me this error "(error: container failed to start)" is this a known issue? | 00:27 |
| waigani | thumper: godeps -u dependencies.tsv | 00:27 |
| waigani | "/home/jesse/go/src/github.com/juju/ratelimit" now at 0025ab75db6c6eaa4ffff0240c2c9e617ad1a0eb | 00:27 |
| waigani | godeps: cannot update "/home/jesse/go/src/github.com/juju/testing": fatal: reference is not a tree: 9c0e0686136637876ae659e9056897575236e11f | 00:27 |
| davecheney | waigani: go version | 00:28 |
| thumper | waigani: cd ~/go/src/github.com/juju/testing | 00:28 |
| davecheney | go env | pastebinit | 00:28 |
| thumper | git pull | 00:28 |
| davecheney | thumper: yeah, if waigani is using go get | 00:29 |
| thumper | probably a way to do it without changing directory | 00:29 |
| waigani | davecheney: go version go1.2.1 linux/amd64 | 00:29 |
| davecheney | and a working copy already exists | 00:29 |
| davecheney | then it will not update | 00:29 |
| davecheney | go get -u github.com/juju/ratelimit | 00:29 |
| thumper | also, godeps doesn't pull | 00:29 |
| davecheney | is required | 00:29 |
| thumper | davecheney: ack | 00:29 |
| * thumper breaks his own rules and takes the laptop into the kitchen | 00:31 | |
| waigani | thumper: davecheney: wallyworld_: all working now, tests pass thanks | 00:32 |
| thumper | good | 00:33 |
| thumper | axw: all that thinking and we already have it in the Makefile :) | 01:27 |
| axw | doh :) | 01:28 |
| thumper | davecheney: any idea why I'd be getting link errors when trying to build the tests on power? | 01:45 |
| thumper | oh fark | 01:49 |
| thumper | stabby | 01:49 |
| thumper | stabby | 01:49 |
| thumper | stabby | 01:49 |
| rick_h_ | thumper: needs more stabby! | 01:53 |
| thumper | rick_h_: ✂ ☹ | 01:57 |
| thumper | rick_h_: ✂☹ ✂☹✂☹✂☹ | 01:57 |
| rick_h_ | lol | 01:59 |
| mwhudson | thumper: heh, you're being roped into the "make it work on funny arch" game? | 02:03 |
| thumper | mwhudson: yeah... | 02:03 |
| wallyworld_ | davecheney: hiya | 02:04 |
| === hatch__ is now known as hatch | ||
| thumper | davecheney: I need help | 02:06 |
| axw | waigani: shipit | 02:24 |
| axw | waigani: well, apparently there's a text conflict in state/initialize_test.go, so after you fix that :) | 02:24 |
| waigani | oh really? | 02:24 |
| waigani | okay, axw thanks for the massive review | 02:25 |
| axw | waigani: no worries :) | 02:25 |
| thumper | waigani: https://code.launchpad.net/~waigani/juju-core/remove-checkers-dir/+merge/210935 needs updating with trunk, someone added a test pointing to old checkers | 02:44 |
| waigani | thumper: on it | 02:44 |
| thumper | waigani: also the migrate testbase branch has conflicts with trunk | 02:48 |
| davecheney | hello | 02:51 |
| davecheney | i'm here to help | 02:51 |
| davecheney | thumper: sorry, was eating | 02:52 |
| thumper | davecheney: you aren't allowed to eat | 02:52 |
| thumper | my god man | 02:52 |
| davecheney | sorry sir | 02:52 |
| thumper | why is mongodb-server failing on power? | 02:52 |
| thumper | I'm guessing you've solved this already | 02:52 |
| davecheney | thumper: ahh | 02:52 |
| davecheney | this is a good question | 02:52 |
| davecheney | juju looks for /usr/bin/mongod | 02:53 |
| davecheney | and chides you if it's not there | 02:53 |
| davecheney | BUUUUUUUUUUUUUUUUT | 02:53 |
| davecheney | the actual path of juju-mongodb is somewhere else | 02:53 |
| davecheney | becuase this is our special versino of mongo | 02:53 |
| davecheney | so even if the package is installed, the check still fails | 02:53 |
| davecheney | or the upstart script points to the wrong location | 02:53 |
| thumper | are we installing that? | 02:54 |
| davecheney | well | 02:54 |
| thumper | I didn't think that that branch had landed | 02:54 |
| thumper | it did land and was reverted | 02:54 |
| davecheney | the install instructions say 'apt-get isntall mongo-server | 02:54 |
| davecheney | which isn't correct | 02:54 |
| thumper | so the default mongo-server on power is fucked | 02:55 |
| thumper | and we need to use our one? | 02:55 |
| === Ursinha-afk is now known as Ursinha | ||
| davecheney | thumper: not fucked | 02:55 |
| davecheney | not available | 02:55 |
| thumper | I installed it | 02:55 |
| davecheney | thumper: as I understood it | 02:55 |
| davecheney | we (juju) should always be recommeding juju-mongodb package | 02:56 |
| thumper | but it fails to start | 02:56 |
| davecheney | not just for trusty/ppc64el | 02:56 |
| davecheney | but for everyting back to precise | 02:56 |
| davecheney | thumper: it doesn't work 'cos v8 doesn't run on ppc | 02:56 |
| thumper | it should be juju-db package (according to our sabdfl) | 02:56 |
| davecheney | the juju-mongodb package does not have a javascript interpreter enabled | 02:56 |
| thumper | well... unless you have the v8 power thing from github | 02:56 |
| mwhudson | um | 02:56 |
| thumper | o/ mwhudson | 02:57 |
| mwhudson | i thought a v8 port was available for power? | 02:57 |
| mwhudson | probably not packaged though i guess | 02:57 |
| thumper | I don't think it is packaged | 02:57 |
| davecheney | thumper: sir, it's a little late to reopen this discussion | 02:57 |
| thumper | developed by not available | 02:57 |
| davecheney | we (juju) should always be recommeding juju-mongodb package | 02:57 |
| thumper | davecheney: I'll take it to the people I know... | 02:57 |
| davecheney | ^ am I mistaken | 02:57 |
| * thumper sighs | 02:57 | |
| mwhudson | i agree that davecheney is right about where things _should_ be | 02:57 |
| thumper | davecheney: you are correct with what we originally said | 02:57 |
| mwhudson | nfi what the current state is though | 02:58 |
| thumper | however we had been trumped along the way | 02:58 |
| thumper | but I'm not sure whether it has been actioned | 02:58 |
| * thumper will take to the email | 02:58 | |
| davecheney | who wants to get on a hangout and thrash this out ? | 02:58 |
| thumper | davecheney: so... your local on power had a hacked juju-db upstart? | 02:58 |
| davecheney | thumper: NO | 02:58 |
| davecheney | my hack is | 02:58 |
| davecheney | ubuntu@winton-02:~$ ls -l $(which mongod) | 02:59 |
| davecheney | lrwxrwxrwx 1 root root 24 Mar 14 00:55 /usr/bin/mongod -> /usr/lib/juju/bin/mongod | 02:59 |
| davecheney | IMO two things need to happen | 02:59 |
| mwhudson | i don't want to muddy the water tooooo much | 02:59 |
| davecheney | 1. juju stops recommending the mongodb-server package | 02:59 |
| mwhudson | but https://launchpad.net/ubuntu/+source/mongodb/1:2.4.9-1ubuntu1/+build/5664994 is a ppc build of mongo for trusty | 02:59 |
| davecheney | 2. upstart scripts are corrected to reflect the path is /usr/lib/juju/bin/mongod | 02:59 |
| davecheney | mwhudson: sorry | 03:00 |
| davecheney | please, this discussino is over | 03:00 |
| davecheney | james page made this package | 03:00 |
| mwhudson | ok | 03:00 |
| thumper | mwhudson: I did try it, it failed to start | 03:00 |
| davecheney | it's too late to try to re solve this problem | 03:00 |
| mwhudson | ah ok, so it builds but doesn't work, ok | 03:00 |
| davecheney | we have a solution | 03:00 |
| davecheney | it's a really good solution | 03:00 |
| mwhudson | davecheney: i'm not trying to change the solution | 03:00 |
| davecheney | because it *ALSO* solves the problem for precise | 03:00 |
| thumper | davecheney: AFAIK nate is working on changing to use the juju db package | 03:00 |
| davecheney | which we still have to support for another 3 years | 03:00 |
| thumper | davecheney: it is a different argument about the name 'juju-db' or 'juju-mongodb' | 03:00 |
| thumper | I want to see where we are with it | 03:01 |
| davecheney | thumper: cool | 03:01 |
| davecheney | the name of the replacement pacakge is unimportant | 03:01 |
| thumper | davecheney: so you just symlinked /usr/bin/mongod | 03:01 |
| davecheney | the key is that it does not live in /usr/bin/mongod | 03:01 |
| davecheney | and it isn't called mongodb-server | 03:01 |
| thumper | ack | 03:01 |
| davecheney | thumper: yes, that is my workaround | 03:01 |
| davecheney | to unblock myself | 03:02 |
| davecheney | it is not a soluton | 03:02 |
| thumper | right | 03:02 |
| * thumper is on to fix the solution | 03:02 | |
| davecheney | 1. juju stops recommending the mongodb-server package | 03:02 |
| davecheney | 2. upstart scripts are corrected to reflect the path is /usr/lib/juju/bin/mongod | 03:02 |
| davecheney | ^ i believe this is the correct sequence | 03:02 |
| thumper | sure... | 03:03 |
| thumper | davecheney: do you want to be CC'ed on the emails, or are you happy to be left off? | 03:03 |
| thumper | axw: due to the current aufs issues, I'm going to submit a branch to default aufs to off | 03:04 |
| axw | thumper: okey dokey | 03:04 |
| davecheney | thumper: sure | 03:06 |
| davecheney | email away | 03:06 |
| wallyworld_ | davecheney: i'm guessing i need to configure the ppc vms to be able to ssh out to an ec2 instance? | 03:06 |
| davecheney | thumper: re aufs: i agree | 03:06 |
| davecheney | i know mramm really really wants it | 03:06 |
| davecheney | but lets get *something* working | 03:06 |
| davecheney | before moving on to making it use all the super amazing optional features | 03:06 |
| davecheney | wallyworld_: oh, there is no external access | 03:07 |
| thumper | wallyworld_: if you have the http proxy | 03:07 |
| thumper | davecheney: none at all? | 03:07 |
| davecheney | goota go through the proxy | 03:07 |
| wallyworld_ | thumper: i used the squid proxy to get http | 03:07 |
| davecheney | and the proxy is whitelist only | 03:07 |
| wallyworld_ | the ip addresses didnt work | 03:07 |
| davecheney | wallyworld_: i'm really sorry | 03:07 |
| davecheney | you have to raise an RT | 03:07 |
| davecheney | please cc me on the RT | 03:07 |
| davecheney | i'm maintaining a list of open ones | 03:07 |
| davecheney | i'm tyring to get the PM to be more active in getting them actioned | 03:07 |
| thumper | wallyworld_: also, ask for all the vms | 03:08 |
| wallyworld_ | davecheney: so my ssh foo is crap - i can't just set up a config and use the proxies from the doc, they are only for http? | 03:08 |
| davecheney | wallyworld_: not quite sure what you are asking | 03:08 |
| thumper | wallyworld_: axw has good ssh-fu | 03:08 |
| davecheney | the doc talks about from bne -> your vm | 03:08 |
| davecheney | not the other way around | 03:08 |
| davecheney | incoming access is via batuan, the jump host | 03:08 |
| wallyworld_ | davecheney: yes, but the doc also gives proxies to use inside the vm | 03:08 |
| davecheney | outgoing access is via proxy | 03:08 |
| wallyworld_ | i have outgoing http access via http://squid.internal:3128/ | 03:09 |
| davecheney | correct | 03:09 |
| davecheney | but that is whitelisted | 03:09 |
| wallyworld_ | but you are saying an RT is needed to get outpoing ssh? | 03:09 |
| davecheney | wallyworld_: yes | 03:09 |
| davecheney | and also to have addtional sites whitelisted for the proxy | 03:10 |
| wallyworld_ | davecheney: ok, will raise rt. cause once that's done, i have a branch which would have been abl to bootstrap a workload on aws | 03:10 |
| davecheney | for example I had to ask rog to hold off on the launchpad.net/goyaml -> gopkg.in/goyaml change | 03:10 |
| davecheney | because that site was not whitelisted by the proxy | 03:10 |
| davecheney | OH FUCK | 03:10 |
| davecheney | i just realised that | 03:10 |
| davecheney | sync bootstrapo | 03:10 |
| wallyworld_ | yep | 03:11 |
| davecheney | we required ssh access from the client | 03:11 |
| davecheney | WE"RE FUCKED | 03:11 |
| wallyworld_ | yep | 03:11 |
| * davecheney cries | 03:11 | |
| wallyworld_ | oh? | 03:11 |
| wallyworld_ | we can't organise that? | 03:11 |
| davecheney | the chances or elmo allowing that are effectively zero | 03:11 |
| davecheney | can we disable sync bootstrap ? | 03:11 |
| axw | what's the problem? | 03:12 |
| wallyworld_ | no outgoing ssh | 03:12 |
| wallyworld_ | from ppc boxen | 03:12 |
| axw | you can't proxy it? | 03:12 |
| axw | what is outgoing? | 03:13 |
| wallyworld_ | bootstrap tries to ssh into aws instance and fails to connect | 03:13 |
| davecheney | axw: sync bootstrap | 03:13 |
| axw | if you can ssh, you can ssh out using a tunnel at the worst | 03:13 |
| axw | if you can ssh in* | 03:13 |
| davecheney | axw: a human can | 03:13 |
| davecheney | juju probably cant | 03:13 |
| axw | davecheney: do you have an HTTP proxy you can go out through? | 03:15 |
| axw | davecheney: if so, you can set up ssh to use HTTPS/CONNECT using ProxyCommand | 03:15 |
| axw | man ssh_config, look for ProxyCommand | 03:16 |
| axw | and set up your ~/.ssh/config accordingly | 03:16 |
| davecheney | axw: worth a shot | 03:17 |
| davecheney | i think some parts of aws are whitelisted | 03:17 |
| davecheney | but it might just be the api endpoiints | 03:17 |
| davecheney | axw: are you actively trying to use the proxy for outgoing ssh ? | 03:37 |
| axw | davecheney: I'm not doing ppc stuff, so no | 03:40 |
| davecheney | axw: thanks for confirming | 03:40 |
| axw | davecheney: I can help debug if you're having trouble though | 03:40 |
| davecheney | axw: i am also not trying | 03:41 |
| axw | ok | 03:41 |
| thumper | wallyworld_: are you trying? | 03:51 |
| wallyworld_ | no | 03:52 |
| wallyworld_ | am finish tests | 03:52 |
| wallyworld_ | finishing | 03:52 |
| wallyworld_ | i can try after that cause i want to get the branch proposed | 03:52 |
| wallyworld_ | and it's a bit of a rabbit hole with existing code cut and pasted around a bit | 03:53 |
| wallyworld_ | the branch i'm working on is not blocked by the ssh issue | 03:54 |
| thumper | wallyworld_: https://codereview.appspot.com/77220043 | 03:58 |
| thumper | wallyworld_: I changed lxc-clone and lxc-clone-aufs to bools | 03:59 |
| wallyworld_ | ok | 03:59 |
| thumper | wallyworld_: as I tried to use it locally and realised how fucked up strings were in their place | 03:59 |
| wallyworld_ | will look in 2 minutes | 03:59 |
| thumper | sure | 03:59 |
| thumper | no rush | 03:59 |
| thumper | I have to head out shortly | 03:59 |
| thumper | also has aufs defaulting to off for now | 03:59 |
| wallyworld_ | thumper: what's failing at the moment are tests which i don't think should have passed originally | 03:59 |
| thumper | haha | 03:59 |
| thumper | damn | 04:00 |
| wallyworld_ | ie upload tools should not upload for non dev versions | 04:00 |
| wallyworld_ | ie 1.2.x should not upload since it's not a dev release | 04:00 |
| thumper | right... and I take it that it is? | 04:00 |
| wallyworld_ | yep | 04:00 |
| wallyworld_ | so i'm having to change existing tests | 04:00 |
| thumper | but 1.2.x.1 should right? | 04:00 |
| wallyworld_ | yep | 04:00 |
| thumper | ok | 04:00 |
| wallyworld_ | those table driven tests are a pita | 04:01 |
| wallyworld_ | or at least that how it appears | 04:01 |
| wallyworld_ | i have to did though gobs of output | 04:01 |
| wallyworld_ | i might review your stuff to give my eyes a rest | 04:02 |
| davecheney | thumper: https://codereview.appspot.com/77220043/ LGTM | 04:04 |
| thumper | davecheney: ta | 04:07 |
| * thumper goes away for while... | 04:08 | |
| davecheney | wallyworld_: is there an MP for the tools/arch change you are working on ? | 04:08 |
| * davecheney is ready to review | 04:08 | |
| wallyworld_ | davecheney: it's still wip sadly. it was ready and i used it to test live but i added extra tests and they failed cause we have cut and paste code and broken tests which passed even though they should not have IMO | 04:09 |
| davecheney | le fuck | 04:09 |
| wallyworld_ | unless i am wrong, if version.Current is 1.2.x say, the --upload-tools should not work cause 1.2 is a release version | 04:10 |
| davecheney | wallyworld_: i think that you are correct | 04:10 |
| davecheney | but that restriction was never implemented in code | 04:10 |
| wallyworld_ | and yet tests set up such a version.Current and called bootstrap --upload-tools and expected tools to be uploaded | 04:10 |
| wallyworld_ | well, it was in some places | 04:11 |
| davecheney | so, the tests assume that restrictino is not in place | 04:11 |
| davecheney | remove the restriction ? | 04:11 |
| wallyworld_ | hmmm. i would like to keep it | 04:11 |
| wallyworld_ | cause relese tools should be available | 04:11 |
| wallyworld_ | i think it's reasonable to say that upload-tools should be for dev versions | 04:11 |
| davecheney | wallyworld_: sure, i have no position on this | 04:14 |
| davecheney | --upload-tools always produces, x.y.z.1 | 04:14 |
| wallyworld_ | yeah | 04:14 |
| davecheney | so there is no possibility of a conflict | 04:14 |
| wallyworld_ | there was 2 pices of almost identical code | 04:14 |
| wallyworld_ | one lot enforced it i think, and the other didn't | 04:15 |
| wallyworld_ | i've made changes so can't recall exactly | 04:15 |
| wallyworld_ | but the code is now shared, so we can change the policy in once place | 04:16 |
| wallyworld_ | davecheney: if you still feel like reviewing https://codereview.appspot.com/77270043 a lot of the diff is deleted/moved code and tests. i also retained upload release versions for explicit uploads | 05:21 |
| wallyworld_ | davecheney: you should be happy once this lands | 05:21 |
| wallyworld_ | tested on ppc box but failed due to ssh - the tools bit worked fine | 05:22 |
| davecheney | wallyworld_: /me looks | 05:26 |
| wallyworld_ | ta :-) | 05:26 |
| === vladk|offline is now known as vladk | ||
| === vladk is now known as vladk|away | ||
| === vladk|away is now known as vladk | ||
| vladk | jam, good morning | 08:06 |
| vladk | jam, https://juju.ubuntu.com/docs/config-LXC.html says that | 08:06 |
| vladk | "The usage of LXC Linux Containers enforces that bootstrapping and destroying of an environment are done as root. ... | 08:06 |
| vladk | ... sudo juju bootstrap" | 08:06 |
| vladk | but I have got | 08:06 |
| vladk | "ERROR bootstrapping a local environment must not be done as root" | 08:06 |
| vladk | where can I write about it? | 08:06 |
| dimitern | vladk, it is done by root, but sudo is called later in the bootstrap process | 08:23 |
| vladk | dimitern, morning | 08:24 |
| dimitern | vladk, morning! | 08:24 |
| vladk | dimitern: I see, but there is an error in documentation, if I follow it, I have got the above error. So I would like to know who can I write to fix the documentation | 08:25 |
| vladk | dimitern: how can I 'juju bootstrap' with trusty series? | 08:26 |
| dimitern | vladk, evilnickveitch is in charge of the documentation, and there are bugs filed for the docs separately | 08:26 |
| dimitern | vladk, https://bugs.launchpad.net/juju-core/docs | 08:27 |
| dimitern | vladk, so on trusty, you just need to do juju bootstrap --upload-tools | 08:27 |
| vladk | dimitern: how to understand upload-tools? | 08:28 |
| dimitern | vladk, ah, that's an instruction to bootstrap to package your existing binaries (from cmd/juju and cmd/jujud) into a tools.tar.gz package and set the version to version.Current.Number + 0.0.0.1 | 08:29 |
| dimitern | vladk, i.e. if version.Current is 1.17.6, with --upload-tools version 1.17.6.1 will be uploaded (and .2 next time you call --upload-tools and so on) | 08:30 |
| jam | vladk: morning | 08:30 |
| jam | vladk: the docs do need updating, they are correct for juju 1.16.6 (our last stable release), but not correct for trunk | 08:30 |
| jam | however, we won't update the docs until 1.18 is out, since otherwise they'd be wrong for everyone using stable | 08:30 |
| evilnickveitch | vladk, dimitern, feel free to file bugs anyhow on things you think are wrong, but mention you are running the dev version | 08:38 |
| evilnickveitch | someday we will have notes for the unstable releases too | 08:38 |
| dimitern | evilnickveitch, \o/ | 08:39 |
| rogpeppe | mornin' all | 08:48 |
| vladk | rogpeppe: morning | 08:52 |
| rogpeppe | vladk: hiya | 08:52 |
| dimitern | mgz, fwereade, maas vlan meeting? | 09:02 |
| jam | mgz: vladk, fwereade: care to join us to discuss MaaS ? | 09:02 |
| jam | https://plus.google.com/hangouts/_/canonical.com/discuss-vlan | 09:02 |
| mfoord | rejoining | 09:26 |
| jam | mgz: poke about MaaS vlan | 09:28 |
| jam | mgz: poke | 09:48 |
| perrito666 | good morning everyone | 09:55 |
| jam | morning perrito666 | 10:00 |
| jam | wwitzel3: let me know when you come online | 10:00 |
| wwitzel3 | jam: I'm here | 10:02 |
| jam | wwitzel3: hi. We're still doing some of the MaaS VLAN discussion, but I think we're winding down. | 10:02 |
| jam | wwitzel3: I'm in the hangout associated with the 1:1 calendar event I sent you | 10:03 |
| jam | mgz: poke for standup | 10:47 |
| dimitern | vladk, ^^ | 10:48 |
| mgz | gah, sorry guys | 11:00 |
| adeuring | could somebody have a llok here: https://codereview.appspot.com/77260044 (trivial fix( | 11:10 |
| voidspace | adeuring: LGTM | 11:11 |
| adeuring | voidspace: thanks | 11:11 |
| rogpeppe1 | voidspace: shall we make another hangout? | 11:34 |
| jam | natefinch: if you have known tests that fail, and we can fix them with runtime.GOMAXPROCS(1), we can certainly add them. | 11:35 |
| wwitzel3 | I'm interested in vlan stuff, but if I sit in on that, I will loose all the HA stuff jam and I talked about this morning | 11:35 |
| wwitzel3 | natefinch: I am going to take a look at the code changes you pushed up and run them through MaaS, ping me when you're back in the saddle. | 11:35 |
| rogpeppe1 | voidspace: https://plus.google.com/hangouts/_/7acpj0plqg71qcoie9g4705ddo?hl=en-GB | 11:36 |
| voidspace | rogpeppe1: coming | 11:40 |
| voidspace | just testing something - please ignore this message (or not at your pleasure) | 11:59 |
| rogpeppe1 | mgz, fwereade, dimitern, jam: we want to factor out the address-related stuff from the instance package. suggested package is juju-core/netaddr, with the same Address, etc types that are current in the instance package | 12:14 |
| rogpeppe1 | does that seem reasonable? | 12:14 |
| dimitern | rogpeppe1, +1 | 12:14 |
| mgz | why the factor out? | 12:16 |
| rogpeppe1 | mgz: because addresses need to be seen by clients, and it doesn't really make sense for clients to import instance | 12:18 |
| === rogpeppe1 is now known as rogpeppe | ||
| mgz | that surprises me a little, I thought everything imported instance | 12:18 |
| rogpeppe | mgz: there's a load of stuff in the instance package which is really not applicable to API clients | 12:20 |
| mgz | eg, lots of things use Instance.Id even if they don't use other bits | 12:21 |
| rogpeppe | mgz: factoring out the address-related stuff seems kind of reasonable to me | 12:21 |
| rogpeppe | mgz: instance.Id, yes | 12:21 |
| mgz | it seems reasonable to move it if it helps things | 12:21 |
| mgz | I just thought instance was pretty pervasive | 12:21 |
| rogpeppe | mgz: it is, but i guess to me the address stuff feels much less juju-specific than the other stuff in the instance package | 12:24 |
| rogpeppe | mgz: and dividing them up could make for two nicely coherent packages | 12:25 |
| rogpeppe | mgz: but if you don't think it's a good idea, i don't think it matters too much | 12:25 |
| mgz | it seems reasonable if it actually helps anything | 12:26 |
| mgz | as in, if there are places that don't ending up importing both anyway :) | 12:26 |
| TheMue | mgz, rogpeppe: could you tell me why juju-backup/juju-restore are no regular commands (e.g. juju backup/juju restore)? | 12:27 |
| TheMue | and why they are called plugins? | 12:27 |
| mgz | TheMue: they are, just magic plugin things | 12:27 |
| rogpeppe | TheMue: they're a bit hacky to be first-class citizens | 12:27 |
| rogpeppe | TheMue: but "juju backup" should work | 12:28 |
| TheMue | rogpeppe: hacky in the way they are implemented? sure, a bit different. ;) | 12:28 |
| rogpeppe | TheMue: as should "juju restore" | 12:28 |
| rogpeppe | TheMue: (the former requires the shell script to be installed tho) | 12:28 |
| TheMue | rogpeppe: hmm, where is the magic hidden that the script is called? didn't found a reference to the script in the code. maybe too blind. | 12:29 |
| rogpeppe | TheMue: it starts with "juju-" | 12:29 |
| TheMue | rogpeppe: ah, so if juju (the command) doesn't find a command (e.g. "foo") directly implemented it looks for a "juju-foo" file to execute it? | 12:30 |
| TheMue | rogpeppe: then also the naming as plugin makes sense | 12:30 |
| TheMue | rogpeppe: found the magic, thanks. important for the documentation I'm writing | 12:33 |
| natefinch | jam: want to meet now? | 12:39 |
| * jam whimpers | 12:39 | |
| jam | soo many meetings | 12:40 |
| jam | but actually yes | 12:40 |
| natefinch | jam: ok | 12:40 |
| jam | fwereade: are you back yet | 12:40 |
| natefinch | jam: maybe the new manager person will help take some of the meetings off your plate? She has a name that I have, of course, forgotten. | 12:40 |
| jam | natefinch: alexis is *my* manager, not a team lead | 12:40 |
| jam | so just another person to report to :) | 12:41 |
| natefinch | jam: heh... I just hoped she might be able to help with some of the managerial stuff, but sounds like that's not the problem :) | 12:41 |
| jam | natefinch: I'm in the channel from the earlier calendar event | 12:42 |
| natefinch | jam: oh, ok | 12:42 |
| === BradCrittenden is now known as bac | ||
| sinzui | jamespage, Did you unsubscribe me from ~juju-packaging/+archive/stable ? | 13:02 |
| jamespage | sinzui, nope | 13:03 |
| sinzui | oh dear. I don't know who could do it besides you and me | 13:03 |
| sinzui | jamespage, I will avert the 1.18.0 release catastrophe by resubscribing and updating cloud city with the new credentials | 13:03 |
| rogpeppe | x | 13:22 |
| rogpeppe | mgz: fancy a review of some instance package additions? https://codereview.appspot.com/77410043/ | 13:31 |
| voidspace | rogpeppe I can hear you | 13:39 |
| voidspace | rogpeppe: wow, that's about a ten second latency on audio | 13:39 |
| rogpeppe | voidspace: ok, let's try the IRC challenge | 13:40 |
| rogpeppe | voidspace: i'll type x and say it at the same time | 13:40 |
| voidspace | rogpeppe: ok | 13:40 |
| rogpeppe | x | 13:40 |
| rogpeppe | x | 13:40 |
| rogpeppe | y | 13:40 |
| voidspace | rogpeppe: the first one seemed instantaneous | 13:40 |
| rogpeppe | z | 13:40 |
| voidspace | rogpeppe: maybe a second or two | 13:40 |
| voidspace | rogpeppe: let me try | 13:40 |
| voidspace | rogpeppe: this | 13:41 |
| voidspace | rogpeppe: did you even get that? | 13:41 |
| voidspace | wow | 13:41 |
| voidspace | ouch | 13:41 |
| rogpeppe | about 11 seconds delay | 13:41 |
| voidspace | rogpeppe: wwitzel3: I have 1Mbit upstream | 13:41 |
| voidspace | rogpeppe: wwitzel3: maybe if I switch off my camera it will help | 13:42 |
| voidspace | reduce my upstream | 13:42 |
| voidspace | rogpeppe: lunch sounds *great* | 13:42 |
| voidspace | :-) | 13:42 |
| rogpeppe | awesome, let's do lunch :-) | 13:42 |
| voidspace | byeeee | 13:42 |
| natefinch | wwitzel3: ok, ready, finally | 13:44 |
| wwitzel3 | natefinch: ok :) | 13:51 |
| adeuring | another trivial MP: https://codereview.appspot.com/77430043 | 13:53 |
| mgz | rogpeppe: looking | 13:57 |
| axw | hazmat: you don't use the PublicAddress client API do you? | 14:00 |
| axw | hazmat: actually.. never mind, probably too late in 1.17 to remove it now. | 14:01 |
| mgz | rogpeppe: lgtm | 14:01 |
| rogpeppe | mgz: thanks | 14:02 |
| mgz | adeuring: lgtm. | 14:03 |
| adeuring | mgz: thanks | 14:03 |
| mgz | adeuring: did you also check the other providers just in case? :) | 14:03 |
| adeuring | mgz: let me look again ;) | 14:04 |
| adeuring | no looks good | 14:04 |
| === vladk is now known as vladk|away | ||
| bits3rpent | Any reason updated master wont replace juju binaries? | 14:13 |
| natefinch | are you doing juju install or juju build? Build doesn't install, it just compiles | 14:14 |
| natefinch | er sorry, go build bo install | 14:14 |
| natefinch | brains | 14:14 |
| bits3rpent | go install launchpad.net/juju-core/... | 14:14 |
| bits3rpent | haha, it's fine :) | 14:15 |
| hazmat | axw, i don't, there's a usage mode in deployer (-f) where people want that but i extract from status | 14:16 |
| hazmat | axw, iotw i was going to.. but no i don't use it atm | 14:17 |
| fwereade | bits3rpent, are you talking about replacing binaries in $GOBIN or those installed via apt? | 14:17 |
| natefinch | bits3rpent: that should work, unless there's no changes to the code. Do you have just a single path in your GOPATH? go install always installs to the first path in GOPATH, if you have multiple | 14:17 |
| natefinch | fwereade: ahh good question | 14:17 |
| bits3rpent | fwereade: $GOBIN | 14:18 |
| axw | hazmat: thanks, it'll likely stay in anyway | 14:18 |
| fwereade | bits3rpent, hmm, that's surprising -- does it install to that location if you move/delete what's already there? | 14:22 |
| axw | fwereade: I'm planning to make "juju ssh" connect to private addresses, proxying through the API server address. Any objections to this approach? | 14:26 |
| axw | it won't be azure-specific | 14:26 |
| fwereade | axw, I'm +1 on that in general, public ips are in short supply all over the place | 14:26 |
| axw | cool, I can work on that independent of the azure stuff | 14:27 |
| axw | fwereade: did you see my reply about PrincipalUnits vs. DistributionInstances? I can't really see away around it while also preventing add-machine at that point | 14:29 |
| fwereade | axw, sorry, I didn't get to that yet, just a sec | 14:30 |
| axw | add-machine can be prevented by a Prechecker, but that's not supposed to be reliable | 14:30 |
| fwereade | axw, remind me the forces that lead towards a callback ratherthan a plain slice | 14:32 |
| fwereade | axw, but DistributionInstances sounds like a tolerable name to me :) | 14:32 |
| axw | fwereade: purely for performance | 14:32 |
| fwereade | axw, so we don't bother calculating it for providers that can't handle it? fair enough | 14:33 |
| axw | fwereade: though it's on the state server already, so... *shrug* | 14:33 |
| fwereade | axw, I'm fine leaving it as a callback, I had a vague recollection there was another reason to prefer it, I just can't remember what | 14:34 |
| axw | fwereade: perhaps I'll think of it in the middle of the night, but I can't think of any other reason now | 14:35 |
| fwereade | axw, fwiw I wouldn't be opposed to a field that took a string that providers are free to use to try to helpfully tag nstances if possible | 14:36 |
| axw | fwereade: sure. that's not a blocker really. the thing blocking me now is that I can no longer prevent StartInstance with no assigned principals | 14:38 |
| mgz | axw: it *is* the middle of the night, isn't it? | 14:40 |
| axw | mgz: it's only 10:40pm :) | 14:40 |
| mgz | :) | 14:40 |
| fwereade | axw, I see -- it means there's no way to prevent add-machine? | 14:43 |
| axw | fwereade: yup | 14:43 |
| * fwereade makes a face and stares into space a bit | 14:43 | |
| axw | fwereade: I'm using the principals in two places for that: in PrecheckInstances, and in StartInstance | 14:43 |
| axw | PrecheckInstance* | 14:44 |
| fwereade | axw, how do prevent --to? | 14:44 |
| fwereade | s/do/do we/ | 14:44 |
| axw | fwereade: a new UnitAssigner state policy | 14:44 |
| * axw context switches a bit | 14:44 | |
| axw | fwereade: UnitAssigner.CheckUnitAssignment(*state.Unit, *state.Machine) error | 14:45 |
| fwereade | axw, yeah, just found it again | 14:45 |
| === hatch__ is now known as hatch | ||
| axw | fwereade: so Azure just returns an error all the time. It only gets called if a new machine isn't created | 14:45 |
| axw | err, if an existing machine is requested | 14:46 |
| fwereade | axw, so, one thing we had for a while that didn't end up sitting quite right was having the environ itself return the assignment policy | 14:47 |
| fwereade | axw, ie AssignLocal, AssignCleanEmpty, etc | 14:47 |
| fwereade | axw, I'm trying to figure out if there's some similar way of describing the allowable operations at that sort of level | 14:48 |
| axw | fwereade: --to effectively overrides the policy | 14:48 |
| axw | oh, I see what you mean | 14:49 |
| === vladk|away is now known as vladk | ||
| === hatch is now known as negatron | ||
| === negatron is now known as hatch | ||
| fwereade | axw, thinking a bit more: it's *kinda* a CanAssignUnits flag on an environ, that controls validity of both --to and add-machine | 15:10 |
| voidspace | rogpeppe: are you back? | 15:11 |
| rogpeppe | yup | 15:11 |
| axw | fwereade: sounds reasonable. I'm fine with blocking it at that level | 15:12 |
| voidspace | rogpeppe: want to try starting a new hangout | 15:12 |
| voidspace | rogpeppe: nearly typed hangup by mistake | 15:12 |
| rogpeppe | voidspace: https://plus.google.com/hangouts/_/76cpjgribubncq8d4f1s1nalr0?hl=en-GB | 15:12 |
| voidspace | I have enough hangups already without you starting more | 15:12 |
| voidspace | cool :-) | 15:12 |
| axw | fwereade: though, the UnitAssigner was meant to grow to handle filtering machines that can be assigned to for ec2 AZs | 15:13 |
| axw | fwereade: so you may support assignment, but you can't assign to any old machine | 15:13 |
| fwereade | axw, --to overrides that, right? this is just for auto-assignment to existing machines? | 15:14 |
| axw | fwereade: yup | 15:16 |
| axw | fwereade: supporting add-machine/--to could be a flag, independent of that | 15:17 |
| axw | just saying I had intended to put them both together in one interface | 15:17 |
| bits3rpent | Is there anyway to only display unassigned bugs on launchpad? | 15:19 |
| fwereade | axw, I'm wondering whether the assignment could be handled with an interface more like FurthestPossibleInstance(candidates, onesToAvoid []Instance) (Instance, error) | 15:19 |
| fwereade | bits3rpent, sorry: there's an Assignee field in https://bugs.launchpad.net/juju-core/?advanced=1 | 15:20 |
| fwereade | bits3rpent, with a "Nobody" radio button | 15:20 |
| bits3rpent | fwereade, thanks! | 15:20 |
| axw | fwereade: for ec2, yes, that sounds about right | 15:20 |
| fwereade | bits3rpent, if you click the "search" button at the top of the page it might ignore the stuff you specify below, though | 15:21 |
| fwereade | bits3rpent, use the one at the bottom :) | 15:21 |
| fwereade | axw, well, for azure in assignment-allowed mode we can just return any of them | 15:21 |
| bits3rpent | fwereade, will do :) | 15:21 |
| fwereade | axw, (and for ec2 we will also need an error meaning "you can start an instance that's even further than any of those" | 15:22 |
| fwereade | ) | 15:22 |
| axw | yeah that makes sense | 15:22 |
| axw | this is getting ahead of the immediate need though I think | 15:23 |
| axw | fwereade: did you have any thoughts on how to flag a StartInstance as being add-machine'd without PrincipalUnits? | 15:24 |
| axw | how that works actually has ramifications on API and maybe state | 15:24 |
| axw | the other stuff can be changed with refactoring | 15:24 |
| fwereade | axw, I was thinking we could actually get away with doing so at the API/state layer, if we just look up the flag on the environ | 15:24 |
| fwereade | axw, if we can guarantee only good data gets into state, we don't need to worry about checking it again later | 15:25 |
| fwereade | note: the obove is obviously not true | 15:25 |
| fwereade | but sometimes it's not unreasonable to pretend it is | 15:25 |
| axw | :) | 15:25 |
| axw | it's actually not the end of the world if we do start the instance, so I'm okay with that | 15:26 |
| axw | so basically some variation of the PrecheckInstance modification I did | 15:26 |
| marcoceppi | I've got a bone to pick with the destroy-environment command | 15:26 |
| fwereade | marcoceppi, oh yes? | 15:27 |
| marcoceppi | fwereade: I just watched someone type juju status <environment> and get annoyed that the output was something other than what the user expected | 15:27 |
| marcoceppi | We're mixing user expereinces with environments and destroy-environment started this | 15:27 |
| fwereade | marcoceppi, ha, so the destroy-environment change trained them wrong | 15:27 |
| fwereade | marcoceppi, bugger | 15:27 |
| natefinch | dang | 15:27 |
| marcoceppi | yeah, I feared this, but now I have evidence | 15:28 |
| fwereade | can anyone remember where that requirement originated? | 15:28 |
| axw | fwereade: better go to sleep before I fall asleep on the keyboard. I'll rework my stuff and repropose after the ssh proxy branch is up. Thanks for the chat again... | 15:29 |
| fwereade | axw, thank you | 15:29 |
| fwereade | axw, sleep well | 15:29 |
| natefinch | fwereade, marcoceppi: it was my change that made the environment name mandatory, with -e optional, because flags shouldn't be mandatory | 15:29 |
| natefinch | (for destroy-environment) | 15:29 |
| natefinch | fwereade, marcoceppi: the name was made mandatory due to feedback from several users at canonical that said destroy environment was scary, especially if you have several environments on the same machine. So forcing the user to type out the name of the environment is insurance against destroying the wrong one | 15:31 |
| marcoceppi | natefinch: I'd rather just make the -e flag manditory | 15:31 |
| fwereade | marcoceppi, natefinch: if it's causing active upset I think I'd come down on the side of consistency with other uses of -e there... did we do a stable release with that change in yet? | 15:32 |
| marcoceppi | fwereade: I don't think so | 15:32 |
| natefinch | marcoceppi, fwereade: yeah, in hindsight, the consistency with the rest of the commands is more important than the fact that it's weird to have a mandatory flag | 15:33 |
| fwereade | natefinch, I'm worried that people will have updated to use the no-e version | 15:35 |
| fwereade | natefinch, any serious drawback to just accepting both forms? | 15:35 |
| marcoceppi | fwereade: could add a depreciated warning | 15:35 |
| natefinch | fwereade: we accept both now | 15:35 |
| natefinch | fwereade: or at least, on tip we do | 15:35 |
| fwereade | marcoceppi, natefinch: just swap the deprecation warning :) | 15:35 |
| marcoceppi | fwereade natefinch should I file a bug wrt this? | 15:36 |
| sinzui | natefinch, Are you still working on Bug #1271937, I thought someone else was going to be assigned | 15:39 |
| _mup_ | Bug #1271937: Use juju-mongodb when the package is available <arm64> <ci> <mongodb> <ppc64el> <trusty> <juju-core:In Progress by natefinch> <https://launchpad.net/bugs/1271937> | 15:39 |
| mgz | fwereade: if I hurl up a mp of a first pass of state networks doc, can you look it over? | 15:42 |
| fwereade | mgz, soon, on a call atm | 15:42 |
| mgz | I currently lack tests, and want to know what a sane base level of testing is for new state documents | 15:42 |
| mgz | (my template, constraints, has no unit-testy bits for just the constraints doc) | 15:42 |
| dimitern | anyone willing to review my fix for bug 1291400 ? https://codereview.appspot.com/77340044/ | 15:47 |
| _mup_ | Bug #1291400: migrate 1.16 agent config to 1.18 properly (DataDir, Jobs, LogDir) <regression> <upgrade-juju> <juju-core:In Progress by dimitern> <https://launchpad.net/bugs/1291400> | 15:47 |
| dimitern | mgz, voidspace ^^ ? | 15:49 |
| dimitern | natefinch, wwitzel3 ^^ ?? | 15:51 |
| mgz | dimitern: can probably look in a sec | 15:51 |
| dimitern | mgz, ta! it's not huge | 15:52 |
| voidspace | dimitern: he beat me to it... | 15:54 |
| voidspace | xchat notifications are very subtle | 15:54 |
| mgz | fwereade: https://codereview.appspot.com/77270046 | 15:57 |
| vladk | dimitern: ping | 15:57 |
| natefinch | sinzui: about Bug #1271937, I have code that makes it work. it should be landing this week. I'm not sure what the timeline is for people that want it | 16:01 |
| _mup_ | Bug #1271937: Use juju-mongodb when the package is available <arm64> <ci> <mongodb> <ppc64el> <trusty> <juju-core:In Progress by natefinch> <https://launchpad.net/bugs/1271937> | 16:01 |
| dimitern | voidspace, :) thanks anyway | 16:01 |
| dimitern | vladk, pong | 16:01 |
| sinzui | natefinch, The landing will unblock several people. I will consider a 1.17.6 release when the fix is available. | 16:01 |
| fwereade | mgz, yeah, that's pretty much what I was looking for | 16:03 |
| natefinch | sinzui: there's basically two ways to make it work: one involves a fair amount of code, which is what I have, and one is a little hackier but much easier. currently we create the upstart script on the client and send it to the bootstrap node, so it doesn't know if the bootstrap node has juju-mongodb or not. | 16:03 |
| natefinch | sinzui: the fix is either to create the upstart script on the bootstrap node, or just create it with the command as "mongod" and let the PATH figure out which one to use | 16:04 |
| * sinzui nods | 16:04 | |
| natefinch | sinzui: my code does the former, but the latter would be trivial to get in. my code should be ready in a day or two, but historically I've been bad about estimating when this particular code will finish | 16:05 |
| * fwereade bbs | 16:06 | |
| wwitzel3 | rogpeppe: any idea where we might get a hold of the actual hostname of a machine (to use for mongo replicaset) during bootstrap. | 16:08 |
| rogpeppe | wwitzel3: ha ha | 16:08 |
| rogpeppe | wwitzel3: actually... | 16:08 |
| rogpeppe | wwitzel3: perhaps you can, these days | 16:08 |
| rogpeppe | wwitzel3: i'm not entirely sure whether bootstrap-state now has a valid environ config now or not | 16:09 |
| wwitzel3 | rogpeppe: ok, so the environ config is where it would be though | 16:10 |
| rogpeppe | wwitzel3: no, but the environ config lets you get an environs.Environ which allows you to get an instance.Instance which allows you to find out the address :-) | 16:11 |
| rogpeppe | wwitzel3: you'll also need the bootstrap machine's instance id | 16:11 |
| wwitzel3 | rogpeppe: obviously | 16:11 |
| rogpeppe | wwitzel3: from ... i can't quite remember where | 16:11 |
| wwitzel3 | rogpeppe: sounds straightfoward ... | 16:13 |
| dimitern | wwitzel3, rogpeppe, it's provider-state | 16:14 |
| rogpeppe | dimitern: ah yes | 16:14 |
| dimitern | bootstrap-state just says "storage is writable" | 16:15 |
| rogpeppe | dimitern: i guess now that bootstrap is synchronous, there's actually no need for the bootstrap instance to query the provider-state file | 16:15 |
| rogpeppe | dimitern: (assuming it still does) | 16:15 |
| wwitzel3 | rogpeppe, dimitern: what does that mean, it's provider-state? | 16:15 |
| rogpeppe | mgz: another instance package review for you: https://codereview.appspot.com/77470043 | 16:15 |
| rogpeppe | wwitzel3: there's a file in the environ's Storage that's conventionally used to store the bootstrap machine's instance id | 16:16 |
| dimitern | mgz, review poke ;) | 16:22 |
| mgz | dimitern: nearly have a gap :0 | 16:24 |
| dimitern | mgz, cheers :) | 16:25 |
| wwitzel3 | rogpeppe: so how do you retrieve an instance if you have a given id? | 16:26 |
| rogpeppe | wwitzel3: Environ.Instances([]instance.Id{id}) | 16:27 |
| rogpeppe | wwitzel3: godoc launchpad.net/juju-core/instance and launchpad.net/juju-core/environs for details | 16:27 |
| * dimitern is away for a while | 16:34 | |
| rogpeppe | any reviews of this would be appreciated: https://codereview.appspot.com/77470043 | 16:59 |
| === niemeyer_ is now known as niemeyer | ||
| rogpeppe | voidspace: away for a minute or two | 17:00 |
| === vladk is now known as vladk|offline | ||
| viperZ28_ | it looks like Juju does not have ability to enforce runtimes only startup | 17:21 |
| viperZ28_ | In my test I brought up a multi-node RabbitMQ cluster, I then took one of the machines out using `lxc-shutdown`, | 17:22 |
| viperZ28_ | Juju did not try to restart the machine or spin up another one | 17:22 |
| viperZ28_ | I was hoping Juju would sense the downed machine and make an attempt to restart it | 17:22 |
| viperZ28_ | I am also looking for plans to integrate with vSphere/ESX stack | 17:22 |
| perrito666 | hey fine people, please review this if you'v got the time https://codereview.appspot.com/77490043 | 17:28 |
| natefinch | viperZ28_: you're correct, it doesn't do that currently. At some point it probably will, we're just not there yet. | 17:29 |
| viperZ28_ | any plans for ESX/v* integration? | 17:29 |
| bodie_ | anyone familiar with wemux? | 17:29 |
| bodie_ | I'm trying to set up pairing for my team and it's not being friendly | 17:30 |
| natefinch | viperZ28_: as far as I know there's no plans for it, but plans can change and I'm not the leader of much. fwereade might have a better idea, but I think he's AFK for a while | 17:31 |
| fwereade | viperZ28_, oddly enough we've found that most people seem to get upset when we start up downed units/machines for them -- and the python version *did* do that, and nobody noticed for months, until they tried to shut down some unused machines out-of-band and got upset when juju replaced them :/ | 17:37 |
| viperZ28_ | perhaps this should be an option | 17:38 |
| voidspace | rogpeppe: grabbing a drink too | 17:38 |
| viperZ28_ | if I want a HA RabbitMQ cluster I could not use Juju for this use case | 17:38 |
| wwitzel3 | rogpeppe: can you invite me to your hangout? | 17:39 |
| fwereade | viperZ28_, I think I agree there, but I'm not sure I can promise it'd get scheduled any time soon -- to Do It Right in the general case we'd need to be able to assign the storage from the old nodes to the new ones | 17:39 |
| bits3rpent | is there still a bug in juju debug-log? | 17:39 |
| fwereade | viperZ28_, well, you'd need monitoring and human response, at least | 17:39 |
| fwereade | viperZ28_, automated response to *apparent* failure can itself be problematic | 17:40 |
| bodie_ | anyone know what's up with the bug that's like | 17:40 |
| bodie_ | # launchpad.net/juju-core/worker/instancepoller | 17:40 |
| bodie_ | go/src/launchpad.net/juju-core/worker/instancepoller/aggregate.go:67: undefined: ratelimit.New | 17:40 |
| bodie_ | ? | 17:40 |
| bodie_ | I'm getting this as output of go get on a fresh system | 17:40 |
| viperZ28_ | seems in a cloud model or IT as a service this is a requirement, of course with added alerting and throttling | 17:40 |
| natefinch | bodie_: that's a new package that recently got added | 17:41 |
| natefinch | bodie_: go get github.com/juju/ratelimit I believe | 17:42 |
| bodie_ | shouldn't that be pulled down automatically if it's needed? | 17:43 |
| bodie_ | bits3rpent check this out | 17:43 |
| fwereade | viperZ28_, it also enables a whole host of exciting problems -- consider a network partition in which a majority of nodes are lost to the state servers, and the state servers bring up replacements | 17:43 |
| natefinch | bodie_: go get -u launchpad.net/juju-core will get it, but it'll overwrite whatever branch you're working on in juju-core | 17:44 |
| viperZ28_ | I think this is manageable as long as a single master is controlling units running | 17:44 |
| natefinch | bodie_: do a go get launchpad.net/godeps and then you'll have the godeps program, which we use to track dependencies | 17:44 |
| natefinch | bodie_: then from the root of juju-core, you can do godeps -u dependencies.tsv and it'll tell you if any dependencies are missing or out of date | 17:45 |
| viperZ28_ | so is the Juju model more about orchestrating startup and less about operation? | 17:45 |
| viperZ28_ | or should I say maintaining state and operation | 17:46 |
| fwereade | viperZ28_, (also: re vsphere/esx: no current plans, but we love new substrates and would be keen to assist anyone who wanted towork on it) | 17:46 |
| natefinch | viperZ28_: for now, basically, yes. I mean, for operation, you can add or remove instances, add or remove services. | 17:46 |
| fwereade | viperZ28_, not necessarily -- but the correct responses at runtime are very application-spcific | 17:46 |
| fwereade | viperZ28_, and hence more within the individual charms' purview | 17:46 |
| viperZ28_ | this is true, I think this is why there is a gap in PaaS and IaaS when talking about services | 17:47 |
| bodie_ | natefinch, I got that bit. it looks OK now. | 17:47 |
| natefinch | bodie_: cool | 17:47 |
| rogpeppe | wwitzel3: https://plus.google.com/hangouts/_/76cpjgribubncq8d4f1s1nalr0?hl=en-GB | 17:49 |
| fwereade | viperZ28_, more detailed runtime orchestration is certainly possible via the API fwiw -- we're not currently focused on building more sophisticated external brains for juju, but we're definitely not opposed to them :) | 17:49 |
| * fwereade puts his own supper on, bbs | 17:50 | |
| viperZ28_ | Does Juju currently have REST API? | 17:50 |
| viperZ28_ | I saw this https://bugs.launchpad.net/juju/+bug/804284, but didn't see a resolution | 17:51 |
| _mup_ | Bug #804284: API for managing juju environments, aka expose cli as daemon <pyjuju:Triaged> <juju-core:Fix Released by jameinel> <https://launchpad.net/bugs/804284> | 17:51 |
| hatch | viperZ28_ that bug is resolved | 17:56 |
| viperZ28_ | is there any documentation for the API? | 17:57 |
| === vladk|offline is now known as vladk | ||
| hatch | I don't think so, the GUI communicates via a websocket | 18:00 |
| bodie_ | cool | 18:00 |
| bodie_ | that appeases me | 18:00 |
| natefinch | viperZ28_, hatch: right, there's an API, but it's through websocket (the CLI uses that too) | 18:02 |
| fwereade | viperZ28_, er, not really :( -- the juju-gui talks to it, but I'm not sure that bit is very well abstracted out; and then there's https://launchpad.net/python-jujuclient | 18:02 |
| fwereade | bbiab again | 18:02 |
| hatch | well, not abstracted out to the point you could put it into another project | 18:02 |
| hatch | there is a feature request to do that however | 18:03 |
| viperZ28_ | thanks all for the insight | 18:05 |
| hatch | viperZ28_ the GUI is open source so you could extract the commands from here https://github.com/juju/juju-gui/blob/develop/app/store/env/go.js | 18:09 |
| hatch | ex) https://github.com/juju/juju-gui/blob/develop/app/store/env/go.js#L454 | 18:10 |
| bits3rpent | Does the API server in fact currently log everything as debug? | 18:15 |
| bits3rpent | I am trying to replicate https://bugs.launchpad.net/juju-core/+bug/1173122 | 18:15 |
| _mup_ | Bug #1173122: API server should not log passwords <logging> <security> <tech-debt> <juju-core:Triaged> <https://launchpad.net/bugs/1173122> | 18:15 |
| bits3rpent | tail -f ~/.juju/local/log/unit-*.log shows no debug messages | 18:16 |
| bits3rpent | Has anyone replicated this bug? | 18:17 |
| natefinch | bits3rpent: if you bootstrap with --debug it'll output debug messages | 18:19 |
| bits3rpent | Thank you. | 18:19 |
| bodie_ | so many gotchas :( | 18:23 |
| natefinch | bodie_: is there something we can do to help? | 18:32 |
| bodie_ | we're just figuring out the collaborative side of things right now, I'm putting a vm together for us to share that hopefully will have working versions of the code and such | 18:33 |
| * rogpeppe is done for the day | 18:43 | |
| rogpeppe | g'night all | 18:44 |
| bodie_ | nite | 18:45 |
| perrito666 | hey, my local copy of juju-core, obtained using go get lacks a trunk, it does has a branch master, why is that? | 19:04 |
| natefinch | perrito666: go get doesn't actually check out the branch, it just gets the code. You can do a bzr branch lp:juju-core to get an actual branch | 19:08 |
| perrito666 | natefinch: just a branch and then I can switch to trunk? | 19:09 |
| natefinch | perrito666: there's no real reason to be on trunk per se. You can't commit directly to trunk anyway, and a branch of trunk is just as good as trunk as long as it's up to date | 19:09 |
| perrito666 | natefinch: indeed, but since I was just peer programming with gz and his local had trunk I was wondering if my own branch was not from the wrong place | 19:11 |
| natefinch | perrito666: oh, so, that's not a real thing. That's a branch called trunk that he keeps in sync with master | 19:12 |
| natefinch | perrito666: he's using cobzr, which is a way of keeping multiple branches in the same directory on disk. It's the way git works, and it's handy for working with go. | 19:13 |
| perrito666 | natefinch: I am cobzring too :) | 19:14 |
| natefinch | perrito666: the way you start it is to do bzr checkout lp:juju-core, which will grab trunk/master/tip whatever you want to call it from juju-core, then do brz switch -b trunk, and that'll make you a colocated branch called trunk that you can keep in sync with main | 19:14 |
| natefinch | perrito666: ahh good | 19:14 |
| perrito666 | altough the idea to have a trunk in place is nice | 19:14 |
| natefinch | perrito666: yeah, it's a lot easier to just have a cobzr branch called trunk, then you can always just bzr switch trunk; bzr pull; bzr switch -b <newbranch> | 19:15 |
| bodie_ | you guys need a bot to answer these questions :S | 19:15 |
| bodie_ | I had the same exact problems not two days | 19:15 |
| bodie_ | ago | 19:15 |
| natefinch | bodie_: how do you know I'm not a bot? :) | 19:16 |
| perrito666 | bodie_: we could also add it to CONTRIBUTING or README I guess | 19:16 |
| perrito666 | :p | 19:16 |
| bodie_ | now that's just crazy talk | 19:16 |
| bodie_ | READ the README? | 19:16 |
| perrito666 | bodie_: for what I have seen of natefinch he is a bot that has a tiny human controlling him in fron of him | 19:17 |
| perrito666 | s/fron/from | 19:17 |
| bodie_ | lol | 19:17 |
| bodie_ | pay no attention to the man behind the curtain... | 19:18 |
| bodie_ | or, maybe it's more like the men in black aliens that pilot a humanoid robot | 19:18 |
| natefinch | bodie_: he means my 9 month old daughter who sits on my lap for our morning standups because she always wakes up at 6am | 19:19 |
| natefinch | (or earlier) | 19:19 |
| bodie_ | I can so relate! | 19:20 |
| bodie_ | the tiny masters are powerful... | 19:20 |
| natefinch | yep | 19:21 |
| perrito666 | natefinch: tx, I have my repo up and running | 19:27 |
| perrito666 | out of the box tests explode right? | 19:35 |
| natefinch | perrito666: uh.... not if your environment is set up correctly. The main thing is that you need mongo with SSL installed in /usr/bin (note that apt-get does not install one with SSL capability) | 19:37 |
| natefinch | perrito666: also you currently need to *not* have mongod at /usr/lib/juju/bin/mongod | 19:37 |
| perrito666 | duh, I had run the install dependencies step on another vm | 19:39 |
| perrito666 | natefinch: thanks again | 19:39 |
| natefinch | perrito666: welcome | 19:41 |
| perrito666 | curiosity, tests also fail if bzr name is not set | 19:45 |
| natefinch | perrito666: yeah that should really be fixed, but since you'll almost certainly have one to work on juju, it's usually not a huge deal | 19:49 |
| thumper | morning | 19:56 |
| * thumper peruses the email for urgent items | 19:57 | |
| bodie_ | howdy | 19:58 |
| === vladk is now known as vladk|offline | ||
| perrito666 | one more, I am getting coding errors from lxc.go, something there that I am missing right? | 20:06 |
| * perrito666 runs updates for go lxc | 20:11 | |
| waigani | thumper: https://codereview.appspot.com/76670043/, https://codereview.appspot.com/73390043/ (added tests for auto-restart) (oh and good morning) | 20:13 |
| thumper | morning | 20:13 |
| thumper | perrito666: what sort of errors? | 20:13 |
| * thumper looks at his calendar | 20:16 | |
| thumper | natefinch: ping | 20:18 |
| natefinch | thumper: yo | 20:22 |
| thumper | hi natefinch | 20:22 |
| thumper | the juju-mongodb package work, is that progressing? | 20:22 |
| thumper | or shall I take it off you? | 20:22 |
| natefinch | wayne and I are finishing it up. Currently works except for the local provider for some reason | 20:23 |
| thumper | I'm also curious as to the actual other reasons it broke things | 20:23 |
| thumper | natefinch: want me to look at it? | 20:23 |
| natefinch | thumper: sure, help would be appreciated. the branch is lp:~natefinch/juju-core/030-MA-HA | 20:24 |
| * thumper grabs it | 20:24 | |
| natefinch | thumper: the reason it broke things is because we were creating the upstart script for mongo on the client, and using the existence of /usr/lib/juju/bin/mongod on the client to determine the path of mongod to specify in the upstart script that gets created on the server | 20:25 |
| thumper | ah | 20:25 |
| natefinch | how that came about was that I landed half the changes in a branch, and so it had the changes to figuring out mongod, but not the changes to creating the upstart script on the server | 20:26 |
| * thumper nods | 20:26 | |
| natefinch | s/creating/create/ | 20:26 |
| natefinch | thumper: also, destroy environment local isn't cleaning up the new upstart script yet, so you may need to do a stop juju-db-v2 between bootstraps, or it'll complain the mongo port is in use | 20:30 |
| thumper | any particular reason for changing the upstart script name? | 20:31 |
| natefinch | thumper: poor man's version control | 20:32 |
| natefinch | so we can know if we need to remove the old version and install the new version | 20:32 |
| thumper | natefinch: what is the purpose of all the agent config changes? | 20:35 |
| thumper | seems somewhat unrelated to just the mongo package | 20:35 |
| natefinch | thumper: so the branch is really for HA support, so that's code the machine agent runs to call EnsureMongoServer when it notices it's now supposed to be an EnvironManager | 20:36 |
| perrito666 | thumper: I had an outdated version of golxc | 20:36 |
| thumper | perrito666: ack | 20:36 |
| thumper | natefinch: hmm... | 20:36 |
| natefinch | thumper: we could probably factor out just the code that calls ensure mongo server during bootstrap, but it would kind of be a pain | 20:38 |
| natefinch | thumper: the other option is a temporary hack to change the upstart script to have the command it runs be "mongod" and then if /usr/lib/juju/mongod is the first mongod in your path, bam, it works. | 20:39 |
| thumper | I'm very concerned that we have tied a dependent piece for something I need right now into HA which is still coming | 20:39 |
| natefinch | thumper: there's not much actual HA stuff here. it can land on its own without the rest of HA. | 20:40 |
| natefinch | we didn't know we needed it right now until a few days ago, from my understanding, so we didn't worry too much about it as long as it wasn't breaking things. | 20:41 |
| thumper | yeah... I didn't know it was breaking things either | 20:43 |
| natefinch | Well, so it was breaking things, and then martin made a patch to revert it to the previous behavior, and then from what I hear, some people with a lot of money decided they wanted it to work sooner rather than later. | 20:43 |
| natefinch | though this is all third hand, so I may be misunderstanding various bits. | 20:44 |
| thumper | natefinch: how would you feel if I created a branch that pulled bits out of your branch and just did the package change thing? | 20:45 |
| natefinch | thumper: I'd be happy it was you and not me. | 20:45 |
| thumper | haha | 20:46 |
| thumper | natefinch: I'm pretty sure I know what I need to do... | 20:46 |
| thumper | ish | 20:46 |
| natefinch | I think all you really need to do is take the code from agent/bootstrap.go and have it call EnsureMongoServer. We've tweaked ensure mongo server to do some replicaset stuff, but that should be easy to see and ignore | 20:46 |
| thumper | I was thinking a bit simpler than that :-) | 20:47 |
| natefinch | what's your plan? | 20:48 |
| * thumper is still reading the diff | 20:48 | |
| natefinch | very little of the diff on that branch is applicable | 20:49 |
| natefinch | the only thing that really matters is the call to ensuremongoserver in agent/bootstrap.go and making sure agent/mongo/mongo.go is doing the right thing to figure out the mongo path | 20:49 |
| natefinch | come to think of it, that's not really hard at all to pull out | 20:50 |
| thumper | so... the key bit is that you are moving the creation of the mongo upstart script to the machine agent? | 20:50 |
| natefinch | so, yes and no. That part is actually only needed for HA. If you only have one bootstrap node, you can just toss EnsureMongoServer in agent/bootstrap.go | 20:50 |
| natefinch | and remove the code that creates the upstart script on the client | 20:50 |
| thumper | well... actually the bare minimum I need to do is to update cloudinit :-) | 20:52 |
| thumper | and fix the path of the import | 20:52 |
| natefinch | You mean before we send it to the server? Isn't that going to hit the same problem, where we don't know where mongod will exist on the server? | 20:53 |
| thumper | natefinch: oh... now I get it | 20:55 |
| thumper | natefinch: as the simplest thing that can work now, how about this: | 20:59 |
| thumper | natefinch: we update the mongo upstart script to add the location of the juju-mongodb mongodb exec to the path, and don't specify the full path for mongodb ? | 21:01 |
| thumper | that way if we have juju-mongodb installed, we pick up the right mongodb | 21:01 |
| natefinch | thumper: yeah, that was my hack to get it done ASAP in a way that's not awful | 21:01 |
| thumper | I think that is the best thing to get what we need *right now* | 21:01 |
| thumper | that way I'm not blocked on you | 21:02 |
| * thumper was surprised to see that the mongo upstart script location had moved in trunk | 21:02 | |
| thumper | hadn't noticed that move | 21:02 |
| * thumper hacks around a bit | 21:03 | |
| thumper | natefinch: your branch didn't install the juju-mongodb package | 21:04 |
| natefinch | thumper: nope | 21:04 |
| thumper | ok | 21:04 |
| natefinch | ok, I gotta run. Email me if you need anything, I'll keep an eye on it. | 21:05 |
| natefinch | btw, the mongo upstart script moving was part of my half-feature commit that broke things :/ | 21:05 |
| thumper | ah bollocks | 21:26 |
| jamespage | thumper, it does "juju-mongodb | mongodb-server" | 21:27 |
| thumper | ah | 21:27 |
| thumper | can we change that? | 21:27 |
| jamespage | we can | 21:27 |
| thumper | jamespage: I'm thinking that for the local provider on trusty, we always use mongodb-server | 21:27 |
| thumper | either that, or I need to check | 21:27 |
| jamespage | thumper, can't | 21:27 |
| jamespage | thumper, mongodb-server is not mir'able | 21:28 |
| jamespage | juju-mongodb is | 21:28 |
| thumper | sorry, typed the wrong thing... | 21:28 |
| jamespage | phew | 21:28 |
| thumper | what I meant to say was: | 21:28 |
| thumper | on trusty, I want to have the local provider use juju-mongodb | 21:28 |
| thumper | so we just have one mongo thing for trusty juju\ | 21:28 |
| thumper | so I don't have to see what you hvae installed | 21:29 |
| jamespage | thumper, so mongodb-server would not be supported | 21:29 |
| jamespage | that's fine | 21:29 |
| thumper | umm... | 21:29 |
| thumper | perhaps as of 1.17.6 we make the local provider use juju-mongodb | 21:29 |
| thumper | on trusty | 21:29 |
| thumper | does that sound reasonable? | 21:29 |
| thumper | jamespage: I'm trying to get a minimal patch in for juju so that it will work with power and not screw up the ha stuff too much | 21:30 |
| thumper | effectively I want to do a switch internally that says "if trusty use juju-mongodb, otherwise use mongodb-server" | 21:30 |
| thumper | and deal with other operating systems as we get them | 21:30 |
| jamespage | thumper, that would apply to all providers right? | 21:30 |
| thumper | right | 21:30 |
| jamespage | thumper, not just local | 21:30 |
| thumper | right | 21:30 |
| jamespage | OK - that's fine | 21:30 |
| jamespage | thumper, if >= trusty :-) | 21:31 |
| thumper | we have juju-mongodb for trusty everywhere right? | 21:31 |
| thumper | right | 21:31 |
| jamespage | thumper, yes | 21:31 |
| thumper | ok... that is my plan then | 21:31 |
| jamespage | +1 | 21:31 |
| jamespage | thumper, I'll line up the juju-mongodb change when 1.17.6 releases | 21:31 |
| thumper | awesome... | 21:32 |
| thumper | jamespage: also... | 21:32 |
| thumper | jamespage: I have a plugin coming 'juju-local' that we should include in the juju-local package | 21:32 |
| bodie_ | worth noting that trusty installs juju-mongodb to /usr/lib/juju/bin and juju looks for it in /usr/bin | 21:32 |
| thumper | but it has nothing in it yet | 21:32 |
| thumper | I'll keep you in the loop | 21:32 |
| jamespage | thumper, ok | 21:32 |
| thumper | bodie_: ack, this will be part of the change | 21:32 |
| bodie_ | hooray | 21:33 |
| bodie_ | does that mean I don't have to wipe my workstation and reinstall with 12.04? *sigh* | 21:33 |
| thumper | bodie_: you can if you like | 21:33 |
| bodie_ | I've just been setting up a remote dev box today in the hopes it'll get resolved soon on trusty | 21:33 |
| bodie_ | as much as i love reinstalling my pc... | 21:34 |
| * thumper dev machine is trusty | 21:34 | |
| thumper | it is also my day to day machine | 21:34 |
| bodie_ | same here | 21:34 |
| bodie_ | I just keep getting one thing after another | 21:34 |
| bodie_ | moved the mongod binary to /usr/bin, now some other thing is broken | 21:34 |
| thumper | don't do that | 21:35 |
| thumper | :) | 21:35 |
| bits3rpent | Hello all, I am working on the bug stating that juju in debug mode stores passwords of logins etc. | 21:45 |
| bits3rpent | I will be fixing the issue (most likely) a configurable switch | 21:45 |
| bits3rpent | i.e juju bootstrap --debug --show-passwords (Default is false) | 21:46 |
| jcw4 | this bug right? https://bugs.launchpad.net/juju-core/+bug/1202682 | 21:46 |
| bits3rpent | Would everyone prefer the whole log is dropped, or just that the password is parsed out. | 21:46 |
| _mup_ | Bug #1202682: debug-log doesn't work with lxc provider <cts-cloud-review> <debug-log> <local-provider> <papercut> <ssh> <ui> <juju-core:In Progress by dimitern> <https://launchpad.net/bugs/1202682> | 21:46 |
| bits3rpent | https://bugs.launchpad.net/juju-core/+bug/1173122 | 21:46 |
| _mup_ | Bug #1173122: API server should not log passwords <logging> <security> <tech-debt> <juju-core:Triaged> <https://launchpad.net/bugs/1173122> | 21:46 |
| jcw4 | oops thanks bits3rpent | 21:46 |
| bits3rpent | I wanted to keep it as a switch just in case someone wanted it, but do most of you not want any possibility of passwords being logged (via very specific switch)? | 21:48 |
| bits3rpent | jcw4 no problem | 21:48 |
| bits3rpent | Also I was wondering if all of you would rather have the whole log output dropped or just the password parsed out. | 21:48 |
| thumper | bits3rpent: how do you propose to parse the output? | 22:03 |
| bits3rpent | thumper: check for ,"Password":*", and replace with empty string | 22:06 |
| bits3rpent | check result of jsoncodec.DumpRequest(hdr,body) to be specific | 22:07 |
| thumper | wallyworld_: I have a few errands in town, back later | 22:28 |
| wallyworld_ | ok | 22:28 |
| thumper | wallyworld_: lbox is still working out the diff for my branch | 22:28 |
| wallyworld_ | of course it is | 22:28 |
| thumper | https://code.launchpad.net/~thumper/juju-core/juju-mongodb/+merge/211642 | 22:28 |
| wallyworld_ | will look | 22:28 |
| thumper | not tested on power yet, will check that later... | 22:28 |
| * thumper thinks | 22:28 | |
| wallyworld_ | hopefully rt will be done soon too | 22:28 |
| thumper | might have time now | 22:28 |
| * wallyworld_ reboots to apply updates | 22:29 | |
| thumper | wallyworld_: power still seems to have issues, will chase more later | 22:33 |
| wallyworld_ | ok, what issues? | 22:33 |
| thumper | not starting issues | 22:40 |
| === thumper is now known as thumper-afk | ||
| wallyworld_ | thumper: i think nate is doing some work in the area of EnsureMongoServer etc | 22:40 |
| thumper-afk | yes I know | 22:40 |
| thumper-afk | I've taken a minimal approach | 22:40 |
| thumper-afk | his work wasn't yet installing juju-mongodb | 22:40 |
| thumper-afk | and was tied up with HA stuff | 22:40 |
| wallyworld_ | ok, so no issues landing yours then | 22:41 |
| thumper-afk | nope | 22:41 |
| === Ursinha is now known as Ursinha-afk | ||
| === Ursinha-afk is now known as Ursinha | ||
| davecheney | sinzui: lost you | 23:11 |
| davecheney | i think we're done | 23:11 |
| davecheney | no need to reconnect | 23:11 |
| bodie_ | http://paste.ubuntu.com/7117018/ .... | 23:47 |
| bodie_ | this is on a totally clean 13.10 install... did make install-dependencies and go get -u dependencies.tsv | 23:48 |
| bodie_ | any input welcome | 23:48 |
| davecheney | i'd guess the ssh command exited early | 23:48 |
| bodie_ | so maybe just a fluke? | 23:56 |
| davecheney | bodie_: hope so | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!