| davecheney | natefinch, thumper: https://bugs.launchpad.net/juju-core/+bug/1226840 | 00:57 |
|---|---|---|
| _mup_ | Bug #1226840: Windows client needs to make unix paths when working with the bootstrap node <juju-core:Fix Committed by natefinch> <https://launchpad.net/bugs/1226840> | 00:57 |
| davecheney | does this need to be backported to 1.15.0 (trunk series ?) | 00:57 |
| axw | davecheney: disregard my email. I just checked the PPA myself | 01:13 |
| axw | I would like to know where go gets picked up from though | 01:13 |
| davecheney | axw: ok | 01:18 |
| davecheney | axw: are you saying, when we biuld into juju:ppa/stable, which version of Go does it use ? | 01:18 |
| davecheney | /s/saying/asking | 01:19 |
| axw | aye | 01:19 |
| davecheney | ok, that is level 11 magic | 01:20 |
| davecheney | me finds link | 01:20 |
| axw | :) thanks | 01:20 |
| davecheney | https://launchpad.net/~juju/+archive/stable/+edit-dependencies | 01:20 |
| davecheney | this stable ppa has a dependencie on juju-golang | 01:21 |
| davecheney | in effect, juju-golang is inserted into the apt sources | 01:21 |
| davecheney | before apt-get install golang-go | 01:21 |
| davecheney | so that is how we build with a go that isn't in any of the series' | 01:21 |
| thumper | davecheney: yes | 01:21 |
| thumper | davecheney: I'll do it | 01:21 |
| thumper | davecheney: I tried proposing just that change to lp:juju-core, but it had heaps of conflicts, so I left it until after the gym | 01:22 |
| thumper | back now | 01:22 |
| davecheney | thumper: cool, thanks for keeping on top of it | 01:22 |
| davecheney | i love the smell of backports in the morning | 01:23 |
| axw | davecheney: thanks | 01:24 |
| davecheney | axw: so that is how it works, i'm not sure if that answers all the questions | 01:25 |
| axw | davecheney: yes, I was just curious how it works | 01:25 |
| axw | davecheney: I didn't realise the PPAs built with CGO_ENABLED=0 | 01:25 |
| davecheney | axw: if they are, it's a massive bug | 01:25 |
| axw | davecheney: well the dev PPA binaries are statically linked | 01:26 |
| davecheney | axw: say again | 01:26 |
| davecheney | that should not be the case | 01:26 |
| davecheney | the whole reason for this dependant ppa stuff was to accomodate the (now depricated) gwacl cgo dependency | 01:26 |
| axw | davecheney: I just downloaded the raring 1.13.3 dev build | 01:26 |
| axw | and "juju" is statically linked | 01:27 |
| axw | davecheney: I only care because net.LookupIP breaks if you feed it an IP in non-cgo | 01:28 |
| axw | htus I | 01:28 |
| axw | erk | 01:28 |
| davecheney | axw: sudo apt-add-respository ppa:juju/juju-golang | 01:28 |
| davecheney | sudo apt-get install golang-go | 01:28 |
| davecheney | please check | 01:28 |
| davecheney | and raise a bug | 01:28 |
| axw | ok | 01:28 |
| davecheney | there is so much shit breaking i cannot keep on top ofit | 01:28 |
| axw | davecheney: no worries :) | 01:28 |
| davecheney | lucky(~/go/src) % file /usr/lib/juju-1.14.0/bin/juju | 01:29 |
| davecheney | /usr/lib/juju-1.14.0/bin/juju: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), not stripped | 01:29 |
| davecheney | does not appear to be the case | 01:29 |
| davecheney | i am confused that you are seeing different results | 01:29 |
| axw | davecheney: https://launchpad.net/~juju/+archive/devel/+files/juju-core_1.13.3-1~1737~ubuntu13.04.1_amd64.deb | 01:29 |
| axw | get that | 01:29 |
| davecheney | quantal ? | 01:29 |
| axw | raring | 01:29 |
| davecheney | sorry | 01:29 |
| davecheney | axw: could you please raise an issue | 01:30 |
| davecheney | otherwise i'm likely to get ... SQUIRREL! | 01:30 |
| axw | davecheney: yep I will | 01:30 |
| axw | :) | 01:30 |
| axw | ooh look at the dog with the fluffy tail | 01:30 |
| davecheney | PONY! | 01:31 |
| axw | davecheney: https://bugs.launchpad.net/juju-core/+bug/1226902 | 01:36 |
| _mup_ | Bug #1226902: ppa builds are built without cgo <juju-core:New> <https://launchpad.net/bugs/1226902> | 01:36 |
| davecheney | ta | 01:37 |
| thumper | davecheney: https://codereview.appspot.com/13241053 | 01:39 |
| davecheney | thumper: LGTM, tahnks | 01:41 |
| axw | davecheney: golang-go has CGO_ENABLED=1, so nfi | 01:42 |
| davecheney | that is batshit crazy | 01:43 |
| davecheney | is it blocking you today ? | 01:43 |
| axw | davecheney: I can work around it for now | 01:43 |
| davecheney | ok | 01:43 |
| davecheney | thumper: when you close this one https://bugs.launchpad.net/juju-core/+bug/1226840 | 01:44 |
| _mup_ | Bug #1226840: Windows client needs to make unix paths when working with the bootstrap node <juju-core:In Progress by thumper> <https://launchpad.net/bugs/1226840> | 01:44 |
| davecheney | please mark it fixed agaist 1.14.1 and 1.15.0 | 01:44 |
| davecheney | or something | 01:44 |
| thumper | davecheney: cleaned up the bug showing 1.14 series target, with 1.14.1 milestone | 02:08 |
| thumper | taking main task as trunk | 02:08 |
| davecheney | thumper: thank you, you are a very impressive man | 02:08 |
| davecheney | how do you do that | 02:09 |
| davecheney | i usually say 'target to series, then choose trunk and 1.14' | 02:09 |
| davecheney | how do you do it ? | 02:09 |
| davecheney | axw: could I draw you attention to https://canonical.leankit.com/Boards/View/103148069/106844170 | 02:09 |
| thumper | I just said "target to series" and selected 1.14 | 02:09 |
| davecheney | and ask that if it won't happen, you retarget the issue | 02:09 |
| davecheney | and not trunk | 02:09 |
| davecheney | maybe that is where I was ging wrong | 02:09 |
| thumper | the set the milestone on that for 1.14.1 | 02:09 |
| thumper | no, didn't select trunk | 02:10 |
| thumper | that way the main bug task stays there and active | 02:10 |
| thumper | and set the milestone for the main task to be 1.15 | 02:10 |
| axw | davecheney: if I fix this issue in time, I'll get onto that | 02:10 |
| axw | good chance it won't happen, in which case I'll retarget | 02:10 |
| thumper | davecheney: probably either is fine | 02:10 |
| davecheney | axw: i don't think this is critical for 1.15.0 | 02:10 |
| * davecheney makes a 1.15.1 milestone | 02:10 | |
| davecheney | thumper: wallyworld___ could you please put your heads together and reply to https://lists.ubuntu.com/archives/juju-dev/2013-September/001591.html | 02:13 |
| wallyworld___ | ok | 02:14 |
| wallyworld___ | if i can get my next 2 branches landed, we'll be good from my perspective | 02:14 |
| wallyworld___ | i'll reply in a bit | 02:14 |
| davecheney | cool | 02:15 |
| thumper | davecheney: ack | 02:17 |
| thumper | davecheney: all my pending stuff is landed now | 02:17 |
| thumper | so a +1 from me, | 02:17 |
| thumper | just reviewing wallyworld___'s branch now | 02:17 |
| thumper | I think wallyworld___ is trying to go for a record of trailing underscores | 02:17 |
| wallyworld___ | i've had longer | 02:17 |
| wallyworld___ | that's what she said | 02:17 |
| davecheney | wallyworld___: the door is over >>>>> there | 02:18 |
| thumper | heh | 02:18 |
| wallyworld___ | i'm here till Wednesday | 02:18 |
| davecheney | wallyworld___: https://twitter.com/RikerTips/status/372018041787138049 | 02:19 |
| wallyworld___ | lol | 02:20 |
| wallyworld___ | even though i *hate* twitter | 02:20 |
| wallyworld___ | i hope the IPO fails | 02:20 |
| wallyworld___ | i also hate facebook and anything else vaguely related | 02:20 |
| bigjools | shall we get off your lawn? | 02:21 |
| wallyworld___ | yes! | 02:21 |
| wallyworld___ | or i will hose you | 02:21 |
| * bigjools tingles with excitement | 02:21 | |
| * wallyworld___ does too | 02:21 | |
| thumper | wallyworld___ is going to eschew all technology made after 1986 | 02:37 |
| wallyworld___ | noooo, just social media, which is pointless crap | 02:38 |
| davecheney | thumper: have you seen my 8 track player ? | 02:38 |
| wallyworld___ | who cares if so and so took a huge dump this morning and then brushed his teeth. seriously | 02:38 |
| wallyworld___ | mindless drivel | 02:38 |
| davecheney | https://launchpad.net/juju-core/trunk | 02:41 |
| davecheney | ^ is it possible to hide the old milestones | 02:41 |
| davecheney | this list is longer than wallyworld___ | 02:41 |
| === wallyworld___ is now known as wallyworld | ||
| thumper | davecheney: not sure, I'd ask SteveK or wgrant | 02:42 |
| thumper | hmm... | 02:43 |
| * thumper wonders what wallyworld is going to say about this review | 02:43 | |
| wallyworld | oh dear | 02:44 |
| thumper | wallyworld: done | 02:51 |
| wallyworld | thanks i think :-) | 02:51 |
| wallyworld | thumper: i *really* wanted to have a storage subpackage under environs, then we would say "storage.Get" etc | 02:52 |
| wallyworld | but it was not possible | 02:52 |
| thumper | because? | 02:52 |
| wallyworld | because someone thought it a great idea to dump all the interfaces in environs | 02:52 |
| wallyworld | -> import loops | 02:53 |
| wallyworld | i tried to explain that in the cvering letter | 02:53 |
| thumper | ok, as I see it you have two choices | 02:53 |
| wallyworld | i don't know if it's a Go thing or not | 02:53 |
| thumper | keep in environs but with more descriptive names | 02:53 |
| wallyworld | but it seems like people don't like packages | 02:53 |
| thumper | or make a package with the interface defined in storage | 02:53 |
| thumper | I talked with fwereade about this | 02:54 |
| wallyworld | i'll see what can be done | 02:54 |
| thumper | and we decided it would be better to move all the interfaces into a different package | 02:54 |
| thumper | to make it so we don't ahve loops | 02:54 |
| wallyworld | yes! | 02:54 |
| thumper | the alternative is to have potentially diverging interface copies | 02:54 |
| wallyworld | i reckonif some people had their way, we would just have a single juju package | 02:55 |
| thumper | haha | 02:55 |
| wallyworld | it's not funny | 02:55 |
| wallyworld | but sad | 02:55 |
| thumper | yeah it is | 02:55 |
| wallyworld | sad, sad, sad | 02:55 |
| thumper | school run | 02:56 |
| wallyworld | thanks for reviewing | 02:56 |
| thumper | np | 02:56 |
| axw | thumper, wallyworld: are we on for a package review in half an hour? | 02:59 |
| wallyworld | axw: thumper was supposed to reschedule - i have a school concert thing at the same time today | 03:00 |
| axw | ok | 03:00 |
| davecheney | https://codereview.appspot.com/13577044 | 03:18 |
| arosales_ | Anyone able/up for building the juju msft client per nate's instructions @ https://docs.google.com/document/d/1WMm6lcUTDA4wZnmA8YzfSXyLnQRz6Fqrr5g2lDtZZes/edit?pli=1#heading=h.haqccf144cr7 | 03:36 |
| arosales_ | or perhaps we should just wait for natefinch in the morning us time as he has the env set up. | 03:36 |
| thumper | axw: there are a few ways to link your branch https://code.launchpad.net/~axwalk/juju-core/lp1225825-netlookupip-ip/+merge/186229 to bug 1225825 | 03:42 |
| _mup_ | Bug #1225825: add-machine fails when using IP in ssh: target <juju-core:In Progress by axwalk> <https://launchpad.net/bugs/1225825> | 03:42 |
| axw | thumper: yeah sorry, just forgot | 03:42 |
| thumper | axw: when you are making a commit, you can go "--fixes lp:1225825" | 03:42 |
| thumper | and then the branch scanner will pick that up | 03:43 |
| thumper | or you can do it from the bug or branch page | 03:43 |
| axw | ah cool | 03:43 |
| axw | I usually -bug in lbox | 03:43 |
| * thumper hopes to stab lbox in the heart | 03:43 | |
| axw | :) | 03:43 |
| thumper | axw: if you do it from the branch page, and you have something that looks like a number in the branch name | 03:44 |
| thumper | lp takes a guess an suggests that for the bug number | 03:44 |
| axw | yup, quite handy | 03:44 |
| axw | linked now | 03:44 |
| axw | thanks | 03:44 |
| thumper | ta | 03:44 |
| thumper | axw: what do you most urgently need reviewed? | 03:45 |
| thumper | I'm on a roll | 03:45 |
| axw | thumper: that one would be good to get into 1.15.0 | 03:45 |
| thumper | ok | 03:45 |
| * thumper looks now | 03:45 | |
| axw | thumper: after that, everything is to do with null provider/manual bootstrap | 03:46 |
| thumper | axw: what about manual bootstrap ? | 03:46 |
| axw | probably best if all the storage stuff gets sorted first | 03:46 |
| axw | thumper: I mean, all my remaining MPs | 03:46 |
| axw | are to do with that | 03:46 |
| thumper | axw: give me a queue to work through | 03:46 |
| axw | sure, just a moment | 03:46 |
| axw | https://code.launchpad.net/~axwalk/juju-core/localstorage-to-httpstorage/+merge/185958 | 03:49 |
| axw | https://code.launchpad.net/~axwalk/juju-core/filestorage-write-tmpdir/+merge/185715 | 03:49 |
| axw | https://code.launchpad.net/~axwalk/juju-core/sshstorage-tmpdir/+merge/185717 | 03:49 |
| axw | https://code.launchpad.net/~axwalk/juju-core/sanity-check-constraints/+merge/185015 | 03:49 |
| axw | thumper ^^ | 03:49 |
| thumper | kk | 03:49 |
| axw | thank you | 03:49 |
| thumper | axw: wasn't there a branch that moved local/storage out to another location? | 03:53 |
| thumper | just double checking that this queue is the order they'd be landed | 03:54 |
| axw | thumper: https://code.launchpad.net/~axwalk/juju-core/manual-bootstrap/+merge/184714 | 03:55 |
| axw | that's LGTM'd, just waiting on the sshstorage changes | 03:55 |
| axw | it's not quite in order | 03:55 |
| axw | I'll have to do some merging | 03:55 |
| thumper | axw: for the local -> http storage branch | 03:56 |
| thumper | the first file imports provider/local/storage as httpstorage | 03:56 |
| thumper | but the very next file uses environs/httpstorage | 03:56 |
| thumper | why the difference? | 03:56 |
| axw | hang on, gotta refresh my memory | 03:56 |
| thumper | ah.. | 03:57 |
| thumper | local/storage is the worker | 03:57 |
| thumper | ffs, why did I do that | 03:57 |
| axw | thumper: yeah that one is changing in the manual-bootstrap MP | 03:57 |
| * thumper confused himself | 03:57 | |
| axw | it will become worker/localstorage | 03:57 |
| axw | wait... | 03:57 |
| axw | *looking* | 03:57 |
| axw | wtf | 03:58 |
| axw | that is an error :) | 03:58 |
| axw | I probably did an overzealous sed | 03:58 |
| axw | thumper: cmd/jujud/machine.go should not have changed in this MP | 03:59 |
| thumper | axw: how about you do a quick sanity check on that diff, and push any changes and repropose | 03:59 |
| thumper | I'll look at the next one | 03:59 |
| axw | yep will do | 03:59 |
| axw | sorry about that | 04:00 |
| axw | thumper: updated | 04:08 |
| * thumper looks | 04:09 | |
| thumper | axw: re fileStorageReader, my first cut at it used filepath.Walk :-) | 04:13 |
| thumper | was told to use Glob | 04:13 |
| * thumper prefers walk | 04:13 | |
| thumper | as reviewer, I approve | 04:13 |
| axw | thumper: Glob doesn't actually work properly there, that's the main reason for the change | 04:16 |
| axw | Glob only works for one level of the hierarchy | 04:16 |
| thumper | where does it fail? | 04:16 |
| thumper | I didn't see a test added that demontrates that | 04:17 |
| thumper | or is it later in the branch? | 04:17 |
| axw | /tmp/* matches /tmp/blah, but not /tmp/blah/blah | 04:17 |
| * axw looks | 04:17 | |
| axw | I think it's probably in httpstorage | 04:17 |
| * thumper wonders | 04:17 | |
| thumper | should /tmp/* match /tmp/blah/blah | 04:17 |
| axw | not in shell globbing | 04:17 |
| axw | or deos it... | 04:18 |
| thumper | should it with our one? | 04:18 |
| * axw doesn't understand the question | 04:18 | |
| axw | thumper: according to the docs for filepath: '*' matches any sequence of non-Separator characters | 04:19 |
| axw | filepath.Match even | 04:19 |
| axw | which is what Glob's syntax conforms to | 04:19 |
| thumper | I'm wondering what the expectation is with our interface | 04:20 |
| thumper | is the expectation that we recurse or not? | 04:20 |
| thumper | if not, then we don't really need to walk the entire structure | 04:20 |
| axw | thumper: oh yeah, List is meant to return everytrhin | 04:21 |
| === tasdomas_afk is now known as tasdomas | ||
| axw | everything | 04:21 |
| axw | it considers the namespace flat | 04:21 |
| axw | thumper: there's no test for this directly in filestorage, only in httpstorage (which uses filestorage in the test). I can add one. | 04:22 |
| thumper | that would be appreciated | 04:22 |
| thumper | don't repropose until I've finsihed the review though | 04:23 |
| thumper | nearly there | 04:23 |
| axw | okey dokey | 04:23 |
| thumper | review done | 04:26 |
| * thumper moves to the third | 04:26 | |
| axw | thumper: good call on the test, I found a bug in the existing code | 04:36 |
| axw | for instance.HostAddresses; an IPv4 net.IP may be represented as 16 bytes | 04:37 |
| axw | there's no check for that | 04:37 |
| thumper | :) | 04:40 |
| thumper | axw: https://code.launchpad.net/~axwalk/juju-core/sanity-check-constraints/+merge/185015 has conflicts | 04:42 |
| axw | ok | 04:44 |
| axw | I'll add the filestorage test and then get onto that | 04:44 |
| thumper | axw: I'm heading off shortly | 05:22 |
| thumper | axw: got anything you want a re-review on before I go? | 05:22 |
| wallyworld | thumper: i'll push some changes to my branch in a bit if you happen to be on later | 05:24 |
| thumper | I'm being taken out for a birthday dinner | 05:24 |
| thumper | so not really likely to be on later | 05:24 |
| thumper | but can do it tomorrow morning | 05:24 |
| wallyworld | ok. whose birthday? | 05:25 |
| thumper | probably around for another 20 min or so | 05:25 |
| axw | thumper: I'm about to repropose the local-to-httpstorage | 05:25 |
| thumper | wallyworld: mine | 05:25 |
| thumper | wallyworld: and Rachel's | 05:25 |
| wallyworld | thumper: oh? happy birthday old man :-) | 05:25 |
| wallyworld | and to rachel too | 05:25 |
| thumper | wallyworld: last week dude | 05:25 |
| thumper | geez | 05:25 |
| * wallyworld didn't know | 05:26 | |
| wallyworld | you never mentioned it :-) | 05:26 |
| thumper | wallyworld: it is why I was off for a long weekend with no kids | 05:27 |
| wallyworld | i thought that was wedding anniversary | 05:27 |
| thumper | it was | 05:28 |
| thumper | wedding anniversary 9th, my birthday 10th, Rachel's 11th | 05:29 |
| thumper | all together for ease of remembering | 05:29 |
| wallyworld | you sure do know how to organise things | 05:29 |
| * thumper bows | 05:29 | |
| wallyworld | thumper: i'm moving StorageReader and friends interfaces to environs.storage. a lot of places to change | 05:30 |
| * thumper nods | 05:30 | |
| thumper | ok | 05:30 |
| thumper | I still think you should have "Get" and "GetWithRetry" | 05:30 |
| thumper | or "GetWithStrategy" | 05:30 |
| thumper | instead of "DefaultGet" and "Get" | 05:30 |
| wallyworld | sure. separate issue which i'll also look at :-) | 05:30 |
| * thumper nods | 05:30 | |
| wallyworld | thumper: there will be controvery i'm sure with the interface move | 05:31 |
| wallyworld | but i just can't agree it is right as is | 05:31 |
| wallyworld | and this is a good excuse | 05:31 |
| thumper | how are you doing the interface? | 05:31 |
| wallyworld | same interface names - StorageReader, StorageWriter etc, but moved to environs.storage | 05:31 |
| thumper | seems fine to me | 05:32 |
| thumper | we may have an interface package later to remove the dependency loops | 05:32 |
| thumper | but that can happen later | 05:32 |
| wallyworld | me too. but i'm sure i recall people wanting *all* the interfaces lumped together | 05:32 |
| thumper | and I may suggest we get technical architect approval and review | 05:32 |
| axw | thumper: I've reproposed, but haven't done the test helper changes yet. will do that now. | 05:33 |
| * thumper nods | 05:33 | |
| thumper | axw: I see the comment but not a diff change | 05:35 |
| thumper | did the propose work? | 05:35 |
| axw | thumper: sorry, I think lbox was still working | 05:35 |
| axw | should be there now | 05:35 |
| thumper | kk | 05:38 |
| thumper | axw: that one is good to go (preferably after the test helper is added) | 05:43 |
| * thumper has to go clean for a bit | 05:43 | |
| thumper | ciao | 05:43 |
| axw | thanks thumper | 05:43 |
| jam | wallyworld: poke about DataSource stuff | 06:36 |
| wallyworld | yeees? | 06:36 |
| jam | I'm trying to figure out whether tools DataSources have '/tools' in them or not. | 06:36 |
| jam | I might just have an out-of-date goose, though. | 06:37 |
| jam | but the old keystone entry was just putting "" in the entry | 06:37 |
| jam | wallyworld: still true in goose trunk if I'm reading it correctly. | 06:37 |
| wallyworld | jam: the keystone entry has been updates to add the /tools | 06:38 |
| jam | "Service{"juju", "juju-tools", ... PublicURL: url") where that URL is the root of the Swift bucket | 06:38 |
| jam | wallyworld: not in testservices/openstack/New() if I'm reading it correctly. | 06:38 |
| wallyworld | i can;t quite recall if goose needed updating | 06:38 |
| wallyworld | ah, you mean the test doubl | 06:38 |
| jam | wallyworld: I'm testing that I can actually *fetch* something from each DataSource and some of them are failing | 06:38 |
| jam | and I'm trying to figure out whether it is a mistaken understanding of where the stuff needs to get uploaded to | 06:39 |
| wallyworld | hmmm. i know the real canonistack puts out a url with /tools are the end. goose may not. but i don't think it matters. but i could be wrong | 06:39 |
| wallyworld | i think it matters for the legacy fallback to work | 06:39 |
| wallyworld | so, if simplestreams it set up right, you don't need any /tools at the end | 06:40 |
| wallyworld | it's just a url | 06:40 |
| wallyworld | but, if you want the legacy fallback stuff to work, you need to stick stuck in /tools | 06:40 |
| wallyworld | let me take a quick look at the code | 06:41 |
| jam | wallyworld: GetToolsSources puts environs.BaseToolsPath into the NewStorageSimpleStreamsDataSource | 06:41 |
| jam | but uses 'juju-tools' output directly | 06:41 |
| jam | I think it uses "ToolsURL" from config directly | 06:41 |
| jam | and DefaultBaseURL directly | 06:42 |
| wallyworld | the base url can be anything | 06:42 |
| wallyworld | the default url is for getting stuff from the official repository | 06:42 |
| jam | wallyworld: I was a bit confused because of different places where you end up mangling the search path for tools | 06:42 |
| jam | but you don't touch all the possible paths | 06:42 |
| wallyworld | there's only one place - in tools/urls.go | 06:42 |
| jam | so I thought "tools" got tacked on after the fact | 06:42 |
| wallyworld | but each provider gets to add in some search places if it wants | 06:43 |
| jam | wallyworld: I'm quite aware of that, which are the bits I'm working on for Openstack. I'm trying to make sure that if you have data in all places "correctly" that you can fetch them. | 06:43 |
| jam | and I'm still just trying to sort of what "correctly" is. | 06:43 |
| jam | A couple of times now my expectations of consistency across them didn't quite match. | 06:44 |
| wallyworld | so - you need to have a base url, under which is 1) a releases dir with the tarballs, and 2) a streams/v1 dir with the metadata | 06:44 |
| wallyworld | no "tools" anywhere | 06:44 |
| wallyworld | but, it's convention/tradition that we tend to make the base url end in "tools" | 06:45 |
| jam | wallyworld: and clearly you haven't fetched from the "juju-tools" keystone entry, because you can't write data to the '/' container | 06:45 |
| jam | AFAICT | 06:45 |
| wallyworld | i have fetched them from there | 06:45 |
| wallyworld | i can write to juju-tools url/tools | 06:46 |
| wallyworld | the keystone entry points to blahblah/tools | 06:46 |
| jam | wallyworld: not in the goose double | 06:46 |
| jam | which is my point | 06:46 |
| jam | you can't have a test case that is actually doing this | 06:46 |
| jam | you might have tested on Canonistack | 06:46 |
| wallyworld | but it doesn't need to end in tools | 06:46 |
| wallyworld | i don't think | 06:47 |
| jam | wallyworld: I think you're missing *my* point. | 06:47 |
| wallyworld | sorry, this is hard ober irc | 06:47 |
| jam | wallyworld: the URL probably can be whatever it wants to be | 06:47 |
| jam | wallyworld: but you can't have tested that the keystone entry works with the double, because you can't write data to the location that goose's keystone entry points to | 06:47 |
| jam | thus you probably can't have a test case that the keystone entry works | 06:48 |
| jam | if you have one, point me to it, and I'll follow how it sets up the data | 06:48 |
| wallyworld | where does the goose test double keystone entry point to? | 06:48 |
| jam | wallyworld: you *do* have a test case that we see the base URL | 06:48 |
| jam | but no test that Fetch on that URL works | 06:48 |
| wallyworld | there's test cases that the urls are as expected | 06:48 |
| jam | wallyworld: it points directly to the Swift base URL | 06:48 |
| wallyworld | and can't we set up one of those http proxies to return data releative to that url? | 06:49 |
| jam | wallyworld: you're pointing at where Swift returns its data, and you can't upload data to swift without a container to put it in | 06:50 |
| jam | so I could create the container named "releases" and one named "streams" and put stuff in the subdirectories (probably) | 06:51 |
| wallyworld | so, there are tests to ensure the urls that are used to construct the data sources are correct. but there's no need to put data in each as that's done in different tests | 06:51 |
| jam | wallyworld: I'm testing that both URL() and Fetch() works for each of the datasources we see | 06:51 |
| jam | I currently can't set up Fetch in a sane way to ensure that it gets data back properly | 06:51 |
| wallyworld | well, you can using tools-url | 06:51 |
| jam | I can hack around it, but it feels like we missed some test coverage | 06:51 |
| jam | wallyworld: that is a *different* data source | 06:52 |
| wallyworld | sure, but it's just a http data source | 06:52 |
| jam | I'm testing tools-url, private storage, and the keystone entry | 06:52 |
| wallyworld | and we test http data sources work | 06:52 |
| wallyworld | and we test that the correct http data soruces are returned | 06:52 |
| wallyworld | i guess we can add extra tests but it seems over kill given we test all the moving parts | 06:53 |
| jam | wallyworld: so in what I'm working on each one needs to be properly configured for ssl/no-ssl, so they aren't "just simple URLs" | 06:53 |
| wallyworld | so get the data sources back and poke their config? | 06:53 |
| wallyworld | so instead of testing MxN, test M+N | 06:53 |
| jam | wallyworld: well I'm just testing that I can fetch any data | 06:54 |
| jam | so I don't have to test that simplestream layout works there. | 06:54 |
| wallyworld | you can test separately if you can fetch data using a data source set up as no ssl | 06:54 |
| wallyworld | and separately test that the data sources that come back from simplestreams all have no ssl activates | 06:54 |
| jam | wallyworld: except the one that points to the canonical location, etc. It isn't very hard to just do a "can i actually fetch data from this source". | 06:57 |
| jam | wallyworld: especially given the privacy layering means you can't "just check the bit is set" | 06:57 |
| wallyworld | sure, but you don't need to | 06:57 |
| wallyworld | you just need check that the url is correct and the ssl thing is correct | 06:57 |
| wallyworld | and there are separate tests for if url based data sources work | 06:57 |
| wallyworld | there's only 2 data sources - a url based one and a environs storage one | 06:58 |
| wallyworld | they can be tested separately with the ssl thng | 06:58 |
| wallyworld | so to me it's still a M+N vs MxN strategy | 06:58 |
| jam | wallyworld: it is the same number of asserts to test the SSL bits as to do an actual Fetch, it is slightly more setup to actually put a file in the location to test that you can fetch it back. | 07:02 |
| wallyworld | so if you want to do that then i guess the url returned by the goose test double needs to have a container at the end | 07:03 |
| wallyworld | that you can put stuff in | 07:04 |
| jam | wallyworld: well, I have to cheat elsewhere because we put 'tools' into the URL, so I can just try to fetch "acontainer/foo" from that URL | 07:04 |
| wallyworld | we put tools in there for legacy things - the tools file name is "releases/tools/juju-" for simplestreams | 07:04 |
| wallyworld | using the existing tools StorageName method | 07:05 |
| wallyworld | many tests set up the new simplestreams prefix and reset it after wards | 07:05 |
| wallyworld | and soon the legacy prefix will go away | 07:05 |
| dimitern_ | hey guys, william texted me he's expecting his internet connection at the new place to be fixed some time this morning | 07:32 |
| wallyworld_ | jam: i'm going to miss the stand up tonight. i have 2 branches in review. tim is doing the first. the second builds on that to add sensible retries to tools fetching | 07:43 |
| hazmat | umm.. just a found a serious security issue in 1.14 for openstack | 08:29 |
| hazmat | although it might extend longer | 08:30 |
| jam | hazmat: what's up? | 08:30 |
| hazmat | switch to canonical #juju pls | 08:30 |
| dimitern_ | rogpeppe, morning | 08:48 |
| rogpeppe | dimitern: hiysa | 08:48 |
| rogpeppe | dimitern_: hiya, even | 08:48 |
| dimitern_ | rogpeppe, updated https://codereview.appspot.com/13720045/ :) | 08:48 |
| rogpeppe | dimitern_: you didn't like my "lxc:34/kvm/5" idea? | 08:53 |
| rogpeppe | dimitern_: aw, i thought that was quite nice | 08:53 |
| dimitern_ | rogpeppe, that's non-standard | 08:55 |
| dimitern_ | rogpeppe, it's only used in add-machine and deploy | 08:55 |
| dimitern_ | rogpeppe, in all other cases it's just a type, no prefix | 08:55 |
| rogpeppe | dimitern_: i have a bit of a problem with the ContainerTypes argument to WatchContainers | 08:56 |
| dimitern_ | rogpeppe, yes? | 08:56 |
| rogpeppe | dimitern_: the problem is that the ContainerType type doesn't really represent a container type - it's really a kind of pattern for matching containers of a particular type within a given machine | 08:56 |
| rogpeppe | dimitern_: a container *type* is really just a string | 08:57 |
| dimitern_ | rogpeppe, the structure is right for args, but I'm open to suggestions about a better name | 08:57 |
| rogpeppe | dimitern_: yeah, it's just the name i'm not keen on | 08:57 |
| dimitern_ | rogpeppe, how about MachineContainerPairs ? | 08:58 |
| rogpeppe | dimitern_: one possibility might be to make the container type a separate (non bulk) arg | 08:58 |
| rogpeppe | dimitern_: so that a given WatchContainers call could watch many machines, but only one type of container | 08:58 |
| dimitern_ | rogpeppe, that's not good - we might need to create several different containers in a single bulk call | 08:58 |
| rogpeppe | dimitern_: s/create/watch/ ? | 08:59 |
| dimitern_ | rogpeppe, yep | 08:59 |
| rogpeppe | dimitern_: well, you never *need* to issue a single bulk call for something | 08:59 |
| dimitern_ | rogpeppe, so how about MachineContainerPairs{Pairs: []MachineContainerPair{Tag, ContainerType}} ? | 09:00 |
| rogpeppe | dimitern_: it's really Machine-ContainerType-Pair but that doesn't make for a great name | 09:03 |
| dimitern_ | rogpeppe, why doesn't it? | 09:03 |
| rogpeppe | dimitern_: because MachineContainerTypePair could read as "Machine-container type pair" | 09:04 |
| dimitern_ | rogpeppe, c'mon | 09:04 |
| dimitern_ | rogpeppe, that's what doc comments are for | 09:04 |
| rogpeppe | dimitern_: i think these names are actually quite important, and not easy to get right | 09:04 |
| dimitern_ | rogpeppe, I really want to start landing stuff so I can continue | 09:05 |
| dimitern_ | rogpeppe, we can always go with WatchContainersParams{Params: WatchContainersParam{MachineTag, ContainerType}}} | 09:06 |
| rogpeppe | dimitern_: i'm wondering about params.WatchContainers | 09:06 |
| rogpeppe | dimitern_: yeah | 09:06 |
| dimitern_ | rogpeppe, ok, will change it and repropose | 09:07 |
| rogpeppe | dimitern_: i think that perhaps makes more sense that trying to make it into some kind of generally applicable type | 09:07 |
| rogpeppe | dimitern_: params.WatchContainers and params.WatchContainer, i think | 09:08 |
| rogpeppe | dimitern_: thanks for bearing with me | 09:08 |
| dimitern_ | rogpeppe, ok, np | 09:08 |
| dimitern_ | rogpeppe, updated | 09:14 |
| rogpeppe | dimitern_: does a provisioner really need to be able to access its own machine? | 09:25 |
| rogpeppe | dimitern_: (other than for Watch, of course) | 09:26 |
| dimitern_ | rogpeppe, for WatchContainers yes | 09:26 |
| rogpeppe | dimitern_: but not for all the other methods, right? | 09:27 |
| dimitern_ | rogpeppe, Life() as well | 09:27 |
| dimitern_ | rogpeppe, that's how we do st.Machine(tag) | 09:27 |
| rogpeppe | dimitern_: so perhaps those two methods should use a slightly different auth function? | 09:29 |
| dimitern_ | rogpeppe, acutally all of the others need it as well | 09:29 |
| rogpeppe | dimitern_: really? | 09:29 |
| dimitern_ | rogpeppe, we need InstanceId(), EnsureDead() | 09:29 |
| dimitern_ | rogpeppe, Remove() | 09:29 |
| dimitern_ | rogpeppe, definitely SetStatus | 09:30 |
| dimitern_ | rogpeppe, and SetProvisioned | 09:30 |
| rogpeppe | dimitern_: um, aren't most of those operations done on the child machines? | 09:31 |
| rogpeppe | dimitern_: not the provisioner's machine itself? | 09:31 |
| dimitern_ | rogpeppe, well, I don't think this is a big issue anyway, because the machine agent, which runs the machiner and the provisioner have access to the same stuff on the same account | 09:31 |
| rogpeppe | dimitern_: i was thinking of it more as a way of catching errors in the provisioner code as anything else | 09:32 |
| rogpeppe | dimitern_: (and also possibly as a way of making the code more obvious) | 09:33 |
| dimitern_ | rogpeppe, and more complicated :) | 09:34 |
| dimitern_ | rogpeppe, but it makes sense yeah | 09:34 |
| rogpeppe | dimitern_: leave it for now; as you say it doesn't really matter | 09:34 |
| dimitern_ | rogpeppe, ok then | 09:36 |
| rogpeppe | dimitern_: reviewed | 09:37 |
| dimitern_ | rogpeppe, thanks | 09:38 |
| dimitern_ | rogpeppe, responded | 09:42 |
| rogpeppe | dimitern_: i'm not sure why you need to make sure that the machine exists in the auth method | 09:43 |
| dimitern_ | rogpeppe, to return ErrPerm if it doesn't | 09:43 |
| rogpeppe | dimitern_: istm that a lexical test should be just fine | 09:43 |
| rogpeppe | dimitern_: i really don't think it matters actually | 09:45 |
| rogpeppe | dimitern_: as it is, we're going to fetch the machine *three times* on every API call | 09:45 |
| dimitern_ | rogpeppe, it matters so long as we're keeping consistency with other api facades | 09:45 |
| dimitern_ | rogpeppe, not 3 times - just 2 times | 09:46 |
| rogpeppe | dimitern_: three times, i think | 09:46 |
| dimitern_ | rogpeppe, once in lifegetter, once in auth func, right? | 09:47 |
| dimitern_ | rogpeppe, the same applies to the other mixins | 09:47 |
| rogpeppe | dimitern_: ah, perhaps - i was thinking we did it when creating the API facade itself, but that will have been done at login time | 09:48 |
| dimitern_ | rogpeppe, and we're running on the same node as the state server, so shouldn't slow us down | 09:48 |
| rogpeppe | dimitern_: BTW lots of existing API calls might not return ErrPerm if the entity has been removed | 09:49 |
| dimitern_ | rogpeppe, only if you're authorized to see it | 09:50 |
| rogpeppe | dimitern_: sure - but we can test that lexically, right? | 09:50 |
| dimitern_ | rogpeppe, i.e. you're trying to access your own machine, which was removed | 09:50 |
| rogpeppe | dimitern_: e.g. if you're trying to access a child machine, which was removed | 09:50 |
| rogpeppe | dimitern_: i think it's reasonable that the environment-global provisioner can ask whether a top level machine exists or not | 09:51 |
| dimitern_ | rogpeppe, how do you know it was removed, without fetching it? | 09:51 |
| rogpeppe | dimitern_: it doesn't matter - you can get a NotFound error without any security problems ensuing | 09:51 |
| dimitern_ | rogpeppe, if it comes to that, I'll change the logic, but so far it seems it'll work just fine | 09:51 |
| rogpeppe | dimitern_: i think that it's fine that a provisioner is able to access all machines in its domain, whether they exist or not | 09:52 |
| rogpeppe | dimitern_: the ErrPerm thing is more about accessing one's *own* machine that's been removed, I think (and even then we don't check in most cases) | 09:53 |
| rogpeppe | dimitern_: are there any other examples where the auth func does a db lookup? | 09:55 |
| rogpeppe | dimitern_: (i'm also wary of the fact that we're potentially dropping mongo errors on the ground here) | 09:56 |
| dimitern_ | rogpeppe, deployer does it | 09:57 |
| rogpeppe | dimitern_: not afaics | 09:57 |
| rogpeppe | dimitern_: getAuthFunc does, but not the auth func itself | 09:57 |
| dimitern_ | rogpeppe, well, take a look at getAllUnits | 09:57 |
| dimitern_ | rogpeppe, ah, yes | 09:57 |
| rogpeppe | dimitern_: and note the fact that getAuthFunc returns an error, so we don't drop it on the floor there | 09:58 |
| dimitern_ | rogpeppe, well, we don't have the tag inside getAuthFunc yet | 09:59 |
| rogpeppe | dimitern_: that's true. honestly though - why is a lexical test bad here? if the name we're trying to access is logically ok for us to access, why not allow it, regardless of the status of the entity in question? | 10:00 |
| rogpeppe | dimitern_: is there a security issue here that i'm not seeing? | 10:01 |
| dimitern_ | rogpeppe, let me check something | 10:01 |
| dimitern_ | rogpeppe, ok, changed the getAuthFunc to use state.ParentId() instead | 10:10 |
| rogpeppe | dimitern_: cool, thanks | 10:10 |
| dimitern_ | rogpeppe, and did slightly differently the suggestion about simplifying it | 10:11 |
| dimitern_ | rogpeppe, reproposing | 10:12 |
| dimitern_ | rogpeppe, LGTM? | 10:14 |
| rogpeppe | dimitern_: just having a last look | 10:14 |
| rogpeppe | dimitern_: reviewed | 10:20 |
| dimitern_ | rogpeppe, thanks | 10:22 |
| jam | dimitern, mgz, rogpeppe, TheMue: standup ? https://plus.google.com/hangouts/_/7bee5998ed9eebebcff8169fb6394538499bdf74?authuser=2 | 10:45 |
| jam | well, leave off that last bit: https://plus.google.com/hangouts/_/7bee5998ed9eebebcff8169fb6394538499bdf74 | 10:45 |
| mgz | gslowload | 10:45 |
| mgz | jam, hm, you're not in the one from c.. right | 10:46 |
| jam | we lost you rogpeppe | 10:47 |
| rogpeppe | jam: yeah, just reconnecting | 10:48 |
| dimitern_ | bug 1227074 | 11:19 |
| _mup_ | Bug #1227074: runtime panic when running any juju command in a deleted directory <juju-core:Confirmed> <https://launchpad.net/bugs/1227074> | 11:19 |
| jamespage | hazmat, did 'peers before herd' get into juju-core? | 11:28 |
| jamespage | (where peer relations are formed prior to any other remote relations) | 11:28 |
| rogpeppe | review anyone? https://codereview.appspot.com/13251052 | 12:37 |
| rogpeppe | dimitern_, jam, TheMue, mgz, axw: ^ | 12:38 |
| mgz | looking | 12:38 |
| rogpeppe | mgz: thanks | 12:38 |
| dimitern_ | I have one as well https://codereview.appspot.com/13552046 | 12:40 |
| mgz | okay, so the var stuff is the idiom for bits that need overriding in tests, right? | 12:40 |
| mgz | xcept the logger, which is just a logger | 12:41 |
| dimitern_ | rogpeppe, will you take a look? | 12:41 |
| rogpeppe | mgz: yeah | 12:42 |
| dimitern_ | mgz, I haven't heard of such practice - if it's for the tests there's usually a comment | 12:42 |
| rogpeppe | mgz: maybe that's a reason to keep them separate i suppose | 12:42 |
| jam | mgz: the export_test stuff isn't because it is being overridden | 12:42 |
| jam | it is because it is being exposed | 12:42 |
| rogpeppe | jam: i think he was referring to the var block at the start of https://codereview.appspot.com/13251052/diff/1015/juju/api.go | 12:43 |
| mgz | jam: the main code has a few aliases at the top for some functions | 12:43 |
| mgz | right | 12:43 |
| TheMue | dimitern: LGTM | 12:44 |
| dimitern_ | TheMue, thanks | 12:45 |
| rogpeppe | just rebooting to try to speed up this sluggish machinre | 12:48 |
| mgz | okay, this basically makese sense to me rog, but is pretty complex | 12:55 |
| jam | rogpeppe: I do have to wonder why doing the "in parallel connect to the provider" is better (especially for maintenance purposes) than try to connect with a short timeout, and then fall back to something els | 13:04 |
| jam | mgz, rogpeppe: I guess the idea is that we have a 10min wait because we might be waiting for a node to start? I don't think we need to do that in the case that we have seen an endpoint | 13:05 |
| fwereade | evening all | 13:07 |
| jam | hey fwereade, good to see you online :) | 13:08 |
| mgz | hey fwereade | 13:08 |
| dimitern_ | fwereade, hey! you're online at last | 13:08 |
| fwereade | dimitern_, yeah, I strolled off and had a peaceful lunchand now it's actually here at last | 13:08 |
| fwereade | how have the last couple of days been? | 13:09 |
| dimitern_ | provisioner is half way done :) | 13:09 |
| fwereade | dimitern_,<3 | 13:09 |
| dimitern_ | well, i'm finishing the server-side at first | 13:09 |
| fwereade | any reviews I should be looking at in particular, anyone? | 13:09 |
| rogpeppe | fwereade: i'd appreciate a look at https://codereview.appspot.com/13251052 | 13:11 |
| fwereade | rogpeppe, ack | 13:11 |
| mgz | yeah, that's a good idea | 13:11 |
| TheMue | fwereade: heya, I would like you to take a look at https://codereview.appspot.com/13430044/ to see if the direction is right | 13:32 |
| fwereade | rogpeppe, looking at the format I'm very much unkeen on the nested fields in what we read in/write out | 13:33 |
| rogpeppe | fwereade: so you don't like the endpoint/creds separation? | 13:34 |
| fwereade | rogpeppe, was there some compelling consideration leading away from flatness? | 13:34 |
| fwereade | rogpeppe, in my mind, if we end up with enough top-level fields in there for the separation to help, the purpose of the file will have changed beyond belief | 13:35 |
| fwereade | TheMue, ack | 13:35 |
| rogpeppe | fwereade: the reason was mainly because i've come around to the idea that location and credentials are two separate concerns, and should be treated separately. | 13:36 |
| fwereade | rogpeppe, I am +100 on doing that internally | 13:36 |
| rogpeppe | fwereade: i don't really see a downside from nesting them | 13:36 |
| fwereade | rogpeppe, I don't think it's a benefit in the context of content you might paste into an email to someone :) | 13:37 |
| rogpeppe | fwereade: it means that the configstore code can be blissfully ignorant of the contents of APICredentials and APIEndpoint | 13:37 |
| rogpeppe | fwereade: i think it reads ok actually | 13:38 |
| rogpeppe | fwereade: insofar as yaml ever reads ok :-\ | 13:39 |
| fwereade | rogpeppe, isn't the purpose of the configstore code to be able to produce a creds and an endpoint on demand? | 13:40 |
| fwereade | rogpeppe, based on what's on disk? | 13:40 |
| fwereade | rogpeppe, it's not some super-generic data store | 13:40 |
| fwereade | rogpeppe, it is concerned precisely with their format on disk and in memory and it's its job to adapt between them ;) | 13:41 |
| rogpeppe | fwereade: it will also store other info | 13:42 |
| rogpeppe | fwereade: e.g. PushedSecrets | 13:42 |
| rogpeppe | fwereade: extra config attributes | 13:42 |
| fwereade | rogpeppe, extra config wants to be nested, sure | 13:42 |
| fwereade | rogpeppe, PushedSecrets has to be LacksSecrets, doesn't it? | 13:43 |
| rogpeppe | fwereade: so we can flatten creds and endpoint if you really feel it makes a difference, but we've got nesting going on anyway. this isn't a hard format for people to parse. | 13:43 |
| rogpeppe | fwereade: why so? | 13:43 |
| rogpeppe | fwereade: ha, yes, i think you're right | 13:44 |
| fwereade | rogpeppe, because otherwise it'll sit there clogging up every file forever, won't it? otherwise we'll read the missing field and go "oh, false" | 13:44 |
| rogpeppe | fwereade: yeah | 13:44 |
| rogpeppe | fwereade: good point | 13:44 |
| rogpeppe | fwereade: maybe NeedsSecrets | 13:44 |
| fwereade | rogpeppe, as you wish:) | 13:45 |
| fwereade | rogpeppe, but I haven't really heard anything that makes me think it's better to nest the format than not to nest, which is how it was originally specified | 13:45 |
| fwereade | rogpeppe, and I'm wondering what the deal is with the string for cacert? | 13:46 |
| rogpeppe | fwereade: it means it can just be serialised with no extra hassle | 13:46 |
| rogpeppe | fwereade: there's no point in double-base64 encoding | 13:46 |
| fwereade | rogpeppe, didn't we say base64-encoded []byte? | 13:46 |
| fwereade | rogpeppe, don't we always use CACerts as []byte? | 13:47 |
| rogpeppe | fwereade: well it can't be []byte if it's to be serialised as a yaml string | 13:47 |
| rogpeppe | fwereade: yeah, and i think that was a mistake on balance | 13:47 |
| fwereade | rogpeppe, do those []byte~s actually only hold bytes from the base64 set? ) | 13:47 |
| rogpeppe | fwereade: yes, they're all ASCII | 13:47 |
| rogpeppe | fwereade: perhaps not from base64 per se, but all ASCII anyway, which is fine for encoding as a yaml string | 13:48 |
| rogpeppe | fwereade: the only reason we use []byte is because the crypto package functions use []byte | 13:48 |
| rogpeppe | fwereade: but it's all PEM encoded | 13:48 |
| rogpeppe | fwereade: (and documented as such) | 13:49 |
| fwereade | rogpeppe, urrgh | 13:49 |
| rogpeppe | fwereade: it also means that the certificate is actually obviously a certificate when it's in the config file. | 13:49 |
| rogpeppe | fwereade: BTW the environ config code already stores and uses the certificates as string | 13:51 |
| fwereade | rogpeppe, ok, I'm convinced there, thanks :) | 13:53 |
| fwereade | rogpeppe, but I'd really appreciate it if we could remove the nesting | 13:53 |
| rogpeppe | fwereade: ok, will do | 13:53 |
| rogpeppe | fwereade: BTW i did start off trying to implement a "type YAMLBase64Bytes []byte" with a custom YAML encoding method to encode and decode as base64 | 13:54 |
| rogpeppe | fwereade: ... or maybe as string, anyway | 13:54 |
| fwereade | rogpeppe, cheers | 13:55 |
| fwereade | rogpeppe, ah, nice | 13:55 |
| rogpeppe | fwereade: there are goyaml bugs that meant it couldn't work, sadly | 13:55 |
| fwereade | rogpeppe, aww | 13:56 |
| fwereade | rogpeppe, well, moot now I guess :) | 13:57 |
| fwereade | TheMue, wondering what the motivation is for the []StatusValue conversion | 14:02 |
| fwereade | TheMue, StatusData seems nice and clear | 14:03 |
| fwereade | TheMue, but I don't see what problem the change to array solves | 14:04 |
| fwereade | brb | 14:04 |
| rogpeppe | fwereade: re-proposed with those on-disk changes as discussed | 14:07 |
| TheMue | fwereade: It's helping to keep the usage of SetStatus() the same (the values are optional) instead of always pass a third argument nil if not needed | 14:07 |
| TheMue | fwereade: but can change it if preferred | 14:07 |
| TheMue | fwereade: would only touch many places in code ;) | 14:07 |
| fwereade | TheMue, I do see the nastiness | 14:15 |
| TheMue | fwereade: just convenience | 14:16 |
| jcastro | mgz: have you seen this yet? https://bugs.launchpad.net/juju-core/+bug/1227145 | 14:18 |
| _mup_ | Bug #1227145: Juju isn't cleaning up destroyed LXC containers <juju-core:Confirmed> <https://launchpad.net/bugs/1227145> | 14:18 |
| fwereade | TheMue, I think I'd prefer to use the nilsexplicitly on balance | 14:18 |
| fwereade | TheMue, I don't think it'll clutter the diff much, and it'll make SetStatus calls similar across the board | 14:19 |
| TheMue | fwereade: that's the best argument for, that usage is not typical | 14:19 |
| TheMue | fwereade: I'll change it | 14:20 |
| mgz | jcastro: not yet, looking | 14:20 |
| fwereade | TheMue, tyvm | 14:20 |
| TheMue | fwereade: what I also need is a bridge to the AllWatcher. the megawatcher is getting the change, but I currently cannot see how this play together with the AllWatcher | 14:25 |
| fwereade | TheMue, find what's already being done with status | 14:27 |
| fwereade | TheMue, it's all in the same document, right? | 14:27 |
| TheMue | fwereade: pardon? | 14:28 |
| TheMue | fwereade: ah, you mean document == statusDoc | 14:28 |
| TheMue | fwereade: wondered about a document | 14:28 |
| fwereade | TheMue, the allwatcher already reports status changes per-entity anyway AIUI (rogpeppe, confirm?) | 14:29 |
| rogpeppe | fwereade: yeah | 14:29 |
| rogpeppe | TheMue: what's the issue exactly? | 14:29 |
| fwereade | TheMue, so wherever it is it's picking up those changes, you can bung an extra field in whereappropriate and you're good, Ithink | 14:29 |
| TheMue | fwereade: I added it to UnitInfo and MachineInfo already, which are delivered EntityInfos. so it should be done | 14:31 |
| fwereade | TheMue, sorry,meeting | 14:32 |
| TheMue | rogpeppe: just getting a better understanding how the megawatcher and AllWatcher work together | 14:32 |
| TheMue | rogpeppe: had been unsure | 14:32 |
| rogpeppe | TheMue: they're the same thing | 14:32 |
| rogpeppe | TheMue: or do you mean the multiwatcher? | 14:33 |
| TheMue | rogpeppe: simplifies it for me :) | 14:33 |
| TheMue | rogpeppe: no, the megawatcher | 14:33 |
| rogpeppe | TheMue: there's no code that mentions the term "megawatcher" | 14:34 |
| rogpeppe | TheMue: it's just the name of the file that the AllWatcher implementation sits in | 14:34 |
| rogpeppe | TheMue: which is really just left there as an in-joke tbh | 14:34 |
| TheMue | rogpeppe: yes, and I referred to that file not knowing that it is the AllWatcher impl. I found it checking where UnitInfo and MachineInfo changes are reported | 14:35 |
| TheMue | rogpeppe: that is very helpful information for me, thx | 14:36 |
| rogpeppe | TheMue: your best bet is to read the multiwatcher docs thoroughly | 14:39 |
| rogpeppe | TheMue: all the changes you need to make will be in the allWatcherStateBacking methods, which implement multiwatcher.Backing | 14:40 |
| TheMue | rogpeppe: I had only to change updated() in backingStatus | 14:43 |
| rogpeppe | TheMue: that sounds about right | 14:43 |
| TheMue | rogpeppe: here now only one information more has to be copied for units and machines | 14:43 |
| TheMue | rogpeppe: but as I said, I have been sure I had to change it there but I didn't know the direct connection to AllWatcher *sigh* some kind of blindness | 14:44 |
| TheMue | rogpeppe: solving by accident | 14:45 |
| rogpeppe | TheMue: the | 14:45 |
| rogpeppe | % grep -i allwatcher megawatcher.go | wc | 14:46 |
| rogpeppe | 17 91 992 | 14:46 |
| rogpeppe | :-) | 14:46 |
| rogpeppe | TheMue: bit of a clue there :-) | 14:46 |
| TheMue | rogpeppe: I'm used to used an old fashioned environment of the 80s: smalltalk, with absolute simple code navigation by clicking ;) | 14:47 |
| rogpeppe | TheMue: your editor doesn't do that? | 14:47 |
| TheMue | rogpeppe: not the command you've done above, but references and implementors | 14:48 |
| TheMue | rogpeppe: but still not as convenient and in a good visual way as smalltalk does it since more than 30 years | 14:48 |
| TheMue | rogpeppe: today i started pharo again, because i once developed a product descriptor similar to our reviewed version stuff | 14:49 |
| rogpeppe | TheMue: pharo? | 14:50 |
| TheMue | rogpeppe: has been fascinating how fast you can navigate in the code | 14:50 |
| TheMue | rogpeppe: pharo is an oss smalltalk | 14:50 |
| rogpeppe | TheMue: it's not hard to make it easy to navigate around go programs. there are plugins for vi and emacs that do that. | 14:51 |
| TheMue | rogpeppe: and for sublime too :) | 14:51 |
| TheMue | rogpeppe: but it is still not the same | 14:51 |
| rogpeppe | TheMue: the go oracle will raise that to whole other level too | 14:51 |
| TheMue | rogpeppe: go oracle? | 14:52 |
| rogpeppe | TheMue: does sublime do the "go to definition of identifier" thing? | 14:52 |
| TheMue | rogpeppe: yep | 14:52 |
| rogpeppe | TheMue: interesting. so you can click on the "X" in an expression like y.foo().bar.X and it'll work reliably? | 14:52 |
| TheMue | rogpeppe: also nice is "go to any symbol in your project" | 14:53 |
| rogpeppe | TheMue: (to take you to the definition of the symbol X) | 14:53 |
| rogpeppe | TheMue: that's much easier | 14:53 |
| rogpeppe | TheMue: because it doesn't need to do the type inference | 14:53 |
| rogpeppe | TheMue: https://docs.google.com/document/d/1WmMHBUjQiuy15JfEnT8YBROQmEv-7K6bV-Y_K53oi5Y/edit# | 14:53 |
| TheMue | rogpeppe: oh, that doc looks interesting, will read it later | 14:54 |
| TheMue | rogpeppe: have to check your question before | 14:55 |
| TheMue | rogpeppe: so you mean a y of type Y, having a method foo(), returning something with a field bar containing a field X? | 14:56 |
| TheMue | rogpeppe: never tried, will check | 14:56 |
| rogpeppe | TheMue: yes (including the fact that X might be embedded several levels deep in anonymous structs) | 14:56 |
| rogpeppe | TheMue: as may foo and bar | 14:57 |
| TheMue | rogpeppe: no, I don't think that this is possible with GoSublime (the name of the plugin) | 14:57 |
| rogpeppe | TheMue: and y itself might be a variable in a range expression over the result of a function return, etc etc | 14:57 |
| rogpeppe | TheMue: ah, so that's what i meant - that capability is incredibly useful | 14:57 |
| rogpeppe | TheMue: it means that any time i see a symbol, i can find out all about it | 14:58 |
| rogpeppe | TheMue: in 0.01s approx | 14:58 |
| TheMue | rogpeppe: that really would be great | 14:58 |
| rogpeppe | TheMue: you could maybe do a plugin for sublime to support that (assuming you can make arbitrary plugins in sublime) | 14:59 |
| TheMue | rogpeppe: what I can do is if I find something like x := xdef.X{} I can simply jump directly to the definition of X in xdef | 15:00 |
| rogpeppe | TheMue: you just need to find out the address in the current file, invoke an external program, and parse the resulting file address | 15:00 |
| rogpeppe | TheMue: only if xdef is a package identifier, right? | 15:00 |
| TheMue | rogpeppe: yes, will check if it discovers an alias too | 15:01 |
| rogpeppe | TheMue: it should do - that's really easy to do | 15:01 |
| TheMue | rogpeppe: it does | 15:03 |
| rogpeppe | fwereade: i'm still hoping for a review of https://codereview.appspot.com/13251052, if poss | 15:04 |
| fwereade | rogpeppe, sorry, just finishing meeting | 15:04 |
| rogpeppe | fwereade: ack, np | 15:04 |
| dimitern_ | fwereade, https://codereview.appspot.com/13501051/ | 15:10 |
| dimitern_ | fwereade, last bit of provisioner server-side api | 15:10 |
| TheMue | simple part done, eliminated status value. but now the consequences ... | 15:15 |
| yolanda | hi, i'm receiving this error after a juju bootstrap, when trying to deploy a service, or even with juju status: error: cannot log in to admin database: auth fails | 15:30 |
| fwereade | yolanda, can you ssh to the machine and see if there's anything in var/log/cloud-init-output.log (I think that's the one) | 15:34 |
| fwereade | yolanda, if it didn't manage to set up admin creds it will probably say why in there | 15:35 |
| fwereade | yolanda, sorry, what I mean is, please pastebin me the contents of that file and I'll take a look | 15:36 |
| fwereade | yolanda, is there any possibility that you've got mismatched tools? | 15:36 |
| yolanda | http://paste.ubuntu.com/6124396/ | 15:36 |
| yolanda | fwereade, i executed a juju sync-tools before bootstrap | 15:36 |
| fwereade | yolanda, that is an interesting thing to see though | 15:37 |
| fwereade | yolanda, is there any more context? and cloud-init.log mightalso be handy | 15:37 |
| yolanda | fwereade, and it happens repeateadly since this afternoon, i tried at least 3 times | 15:37 |
| fwereade | yolanda, sorry, I have been moving house, but... rogpeppe, did we release anything this afternoon..? | 15:38 |
| yolanda | let me paste a bit from cloud-init | 15:38 |
| rogpeppe | fwereade: not as far as i've seen | 15:38 |
| yolanda | http://paste.ubuntu.com/6124407/ | 15:39 |
| yolanda | fwereade, is that useful? | 15:42 |
| fwereade | yolanda, it may be, it's consistently surprising :) | 15:43 |
| fwereade | yolanda, is there anything in /var/log/juju at all? | 15:44 |
| yolanda | fwereade, only all-machines.log, and it's empty | 15:44 |
| fwereade | rogpeppe, is there anywhere else you can think of that might have some context there? | 15:49 |
| rogpeppe | fwereade: reading back | 15:49 |
| rogpeppe | yolanda: could you paste the contents of cloud-init-output.log ? | 15:51 |
| rogpeppe | yolanda: (there's also cloud-init.log, i think, but that's has different stuff in) | 15:52 |
| rogpeppe | s/that's/that/ | 15:52 |
| yolanda | rogpeppe, full log? | 15:52 |
| yolanda | a bit is on http://paste.ubuntu.com/6124396/ | 15:52 |
| rogpeppe | yolanda: yes please | 15:52 |
| yolanda | http://paste.ubuntu.com/6124464/ | 15:53 |
| rogpeppe | yolanda: thanks! | 15:54 |
| rogpeppe | yolanda: can you ssh to the machine that happened on? | 15:55 |
| yolanda | yes | 15:55 |
| rogpeppe | yolanda: what happens if you try to run /var/lib/juju/tools/1.14.0-precise-amd64/jujud on that machine?> | 15:56 |
| yolanda | rogpeppe, it runs ok, shows a help message | 15:57 |
| rogpeppe | yolanda: hmm | 15:57 |
| rogpeppe | yolanda: running as root? or ubuntu? | 15:57 |
| yolanda | ubuntu | 15:58 |
| rogpeppe | yolanda: what environment is this in? | 16:00 |
| rogpeppe | yolanda: it looks like a mmap syscall has failed when initialising the go runtime | 16:00 |
| yolanda | rogpeppe, i'm on canonistack | 16:01 |
| rogpeppe | yolanda: just to check: what does uname -a print on that machine? | 16:03 |
| yolanda | Linux juju-openstack-machine-0 3.2.0-53-virtual #81-Ubuntu SMP Thu Aug 22 21:21:26 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux | 16:03 |
| rogpeppe | yolanda: hrmph :) | 16:04 |
| rogpeppe | mgz, yolanda: do you know what kind of virtualisation canonistack uses? | 16:05 |
| rogpeppe | (if any) | 16:05 |
| mgz | kvm | 16:05 |
| rogpeppe | mgz: any idea why a mmap call may be failing sometimes? | 16:05 |
| mgz | flakey disk? | 16:06 |
| rogpeppe | mgz: there's nothing disk-related about this mmap call | 16:06 |
| mgz | I've not had issues with the instance disk on canonistack though, only attached volumes | 16:07 |
| rogpeppe | mgz: (the fd argument to mmap is -1 in this case) | 16:07 |
| mgz | er,,, bad overcommit on memory then perhaps? | 16:07 |
| mgz | or a juju bug that just looks like the syscall is failing :) | 16:08 |
| rogpeppe | mgz: i can't think how that could happen - the go runtime is printing out the messages i'd expect to see in that case | 16:08 |
| rogpeppe | mgz: and the juju binary works ok when called later, so it doesn't appear to be binary corruption | 16:09 |
| rogpeppe | s/in that case/if the syscall fails/ | 16:09 |
| yolanda | rogpeppe, mgz, problem is happening in every bootstrap, so it's not a random problem | 16:10 |
| rogpeppe | yolanda: yes, this is really weird! (but actually good that you can reproduce the problem) | 16:10 |
| yolanda | but bad because i cannot deploy my services :( | 16:11 |
| mgz | yolanda: have you tried both regions? | 16:11 |
| yolanda | mgz, no, only zone 1 | 16:11 |
| yolanda | it was working fine until this afternoon | 16:12 |
| mgz | maybe try lcy02 if that's not too much hassle | 16:12 |
| yolanda | ok, let me try | 16:12 |
| mgz | the other thing to elliminate would be by using 1.13 tools rather than the new 1.14 if you're not certain you had a working 1.14 run | 16:13 |
| yolanda | trying zone 2 | 16:18 |
| rogpeppe | yolanda: did you use --upload-tools? (i.e. did you build the binaries yourself, and if so, what version of Go are you running?) | 16:22 |
| yolanda | juju sync-tools | 16:22 |
| rogpeppe | yolanda: thanks | 16:22 |
| rogpeppe | mgz: do you know what Go version we're using to build the tools in the public bucket? | 16:23 |
| mgz | rogpeppe: whatever dave used, I'd expect what we have in saucy | 16:23 |
| rogpeppe | mgz: hmm, any way i can easily find out? i'm just putting together an email to the golang list | 16:24 |
| rogpeppe | mgz: in case someone there has a better clue | 16:24 |
| mgz | sec | 16:24 |
| mgz | oo, I'm not sure for 1.14, wasn't built out of his recipe | 16:25 |
| mgz | rogpeppe: pretty sure it's the saucy package, 1.1.2 | 16:28 |
| rogpeppe | mgz: ok, thanks | 16:29 |
| mgz | arosales_: any corrections? | 16:29 |
| TheMue | fwereade: have to step out, but updated proposal is in. any feedback is appreciated so that i can continue tomorrow morning | 16:32 |
| rogpeppe | mgz: what's the likelihood that yolanda is getting the same physical instance each time? | 16:33 |
| yolanda | rogpeppe, i'm getting same instance every time | 16:33 |
| mgz | the same underlying machine? high-ish within the same region, we have pretty limited hardware | 16:33 |
| rogpeppe | mgz, yolanda: i wonder if it might be something odd about that instance | 16:34 |
| arosales_ | mgz, sorry reading backscroll now .. . | 16:36 |
| mgz | arosales_: short recap, what version of golang did the 1.14 release get built with? | 16:36 |
| yolanda | mgz, bad news, same happens with zone 2 | 16:36 |
| arosales_ | mgz, not sure on the golang version | 16:37 |
| mgz | yolanda: good news probably, means it unlikely to be canonistack hardware related | 16:38 |
| mgz | so, much more tractable problem :) | 16:38 |
| yolanda | mgz, but i was hoping that zone 2 worked and i could deploy everything :) | 16:38 |
| arosales_ | fwereade, do you know what version of golang releases are currently being built with? | 16:38 |
| mgz | I think the short version is no one has any clue how we do the release... I understoon Dave's old procedure, but he did something different this time around | 16:39 |
| arosales_ | mgz, https://code.launchpad.net/~dave-cheney/+recipe/juju-core is the build recipe that was used. | 16:40 |
| mgz | arosales_: the buildlog for that ppa disagrees | 16:41 |
| arosales_ | mgz, ah but I see what you are saying | 16:41 |
| arosales_ | mgz, so davecheney built the tar ball and delivered that to jamespage | 16:41 |
| arosales_ | jamespage then updated the saucy packaging and uploaded to the saucy archive | 16:41 |
| arosales_ | which was built by the lp builders, I assume saucy based | 16:42 |
| arosales_ | davecheney, then dput the packages from saucy into the ppa | 16:42 |
| === arosales_ is now known as arosales | ||
| yolanda | is there anything i can do to help to catch the bug? | 16:43 |
| mgz | arosales: I'm wondering if we didn't use the saucy binaries direct for the past ubuntu versions, but instead rebuilt with their golang copies... but I'd expect things to break much more dramatically if that happened | 16:44 |
| arosales | mgz, so we have done initial testing on aws, hp, and azure with 1.14 | 16:44 |
| arosales | are were able to bootstrap there | 16:44 |
| arosales | 1.14.0 that is | 16:45 |
| mgz | and using precise images I presume | 16:46 |
| arosales | mgz, correct | 16:46 |
| arosales | precise on the server | 16:46 |
| arosales | mgz, saucy failing here? | 16:46 |
| mgz | nope, precise | 16:46 |
| arosales | ok | 16:46 |
| mgz | yolanda: give me your exact steps, in as miniaml form as possible, and I'll try to reproduce | 16:47 |
| * arosales not sure how simplestreams work in canonistack | 16:47 | |
| yolanda | mgz, let me pass you my environments file | 16:47 |
| yolanda | without keys, of course | 16:47 |
| arosales | There were some cloud-init issues but we thought there were specific to Azure | 16:49 |
| arosales | yolanda, may want to have smoser take a look at the cloud-init log | 16:49 |
| yolanda | arosales, smoser, link to logfile is pasted in this conversation | 16:50 |
| yolanda | mgz, environments file is like that: http://paste.ubuntu.com/6124684/ | 16:51 |
| yolanda | then i just do a juju sync-tools, juju bootstrap | 16:51 |
| mgz | yolanda: ta | 16:51 |
| mgz | hm, there's some pyjuju junk in there but I assume that should just get ignored | 16:53 |
| arosales | smoser, I think yolanda is referencing http://paste.ubuntu.com/6124464/ | 16:53 |
| mgz | yolanda: what's your local juju binary version? | 16:55 |
| yolanda | 1.12 | 16:55 |
| smoser | k. | 16:55 |
| smoser | reading. | 16:55 |
| yolanda | i can try updating juju | 16:58 |
| mgz | let my try here first | 16:58 |
| mgz | okay, so I can reproduce that | 17:20 |
| mgz | manifests as a hang in status, which is joyous | 17:20 |
| mgz | rogpeppe, yolanda: also fails with the old 1.12 binaries, so not 1.14 related | 17:32 |
| rogpeppe | mgz: v glad you can reproduce | 17:32 |
| yolanda | mgz, and do you have any clue on what happens? | 17:32 |
| rogpeppe | mgz: i wonder if you can reproduce it by getting the cloudinit to run some other non-juju executable | 17:33 |
| rogpeppe | mgz: (go executable) | 17:33 |
| rogpeppe | mgz: the weird thing is that the same binary works later. | 17:33 |
| mgz | yup, manually running the command that fails (and fixing up the --constraints arg), gets the machine in a usable state, and status works | 17:37 |
| mgz | so, something at that point during boot is borked | 17:38 |
| mgz | this is definately a poke-IS moment | 17:38 |
| mgz | yolanda: can you file a bug or rt? | 17:39 |
| yolanda | mgz, sure, maybe an RT can be faster? | 17:39 |
| rogpeppe | fwereade, mgz: PTAL | 17:39 |
| rogpeppe | fwereade: i've addressed your points, i think, except that i couldn't work out what the Default remark was about | 17:40 |
| mgz | okay, that acroymn has me stumped :) | 17:40 |
| rogpeppe | mgz: sorry, "please take another look" | 17:40 |
| rogpeppe | mgz: (common in golang core dev, not here, i guess) | 17:41 |
| rogpeppe | mgz: i added a test for the "abort stops without closing" logic, but it proved really hard to make it fail | 17:41 |
| rogpeppe | mgz: so i left it untested (it's just an optimisation after all) | 17:41 |
| rogpeppe | right, that's me for the day | 17:42 |
| rogpeppe | g'night all | 17:43 |
| mgz | changes lgmt | 17:43 |
| rogpeppe | mgz: thanks | 17:43 |
| yolanda | mgz, is that an issue of juju-core, cloud init? | 17:45 |
| mgz | really hard to tell, but I suspect not juju-core, as it only started today, and the 1.12 binaries from a while back are also failing | 17:46 |
| natefinch | jam, fwereade, mgz, rvba: any of you guys know how to connect to Garage Maas? These instructions no longer appear to work: https://wiki.canonical.com/CDO/UbuntuServer/IOM-Lab | 17:48 |
| jam | rvba: allenap, bigjools ^^ | 17:48 |
| yolanda | i just file an RT with the situation and logs then | 17:48 |
| mgz | yolanda: thanks! | 17:48 |
| sinzui | natefinch, are you satisfied with with windows client? Do you want to block the releases of 1.14.1? | 17:50 |
| natefinch | sinzui: the windows client is fine, though currently it is marked as 1.14.0. If we want one for 1.14.1 I'll need to rebuild the installer. | 17:52 |
| yolanda | mgz https://eu1.salesforce.com/500D000000Uksl4 | 17:53 |
| sinzui | natefinch, understood. I think we want to start the release of 1.14.1, though the building of it would happen tomorrow by jamespage. I think you build the client at the time we extract the tools? | 17:54 |
| natefinch | sinzui: I can build the client any time we decide that what is on the branch is what we want to release.... it's 100% orthogonal to the rest of the release process | 17:56 |
| sinzui | natefinch, fab. The lp:juju-core/1.14 branch is NOT ready, but I will start on it. | 17:57 |
| marcoceppi | wtf, why is juju putting .empty files in directories? | 18:34 |
| natefinch | marcoceppi: do you have more detail? | 18:52 |
| smoser | shoot. / me rememers | 19:05 |
| smoser | am istill needed here? | 19:05 |
| smoser | mgz, i suspect jugju core. | 19:07 |
| smoser | cloud-init ran juju's stuff happily. | 19:07 |
| smoser | i'm not really sure why jjuju decided to print 7000 numbers. | 19:07 |
| smoser | presumably each charater in cacert as ascii | 19:08 |
| natefinch | smoser: yeah, I've seen it do that | 19:11 |
| marcoceppi | natefinch: install hook creates a "volumes" directory in the charm, next hook fails because it checks that directories for files, and in it is a .empty file | 19:49 |
| marcoceppi | Wasn't created by the charm, shows up in all directories my charms create that are empty | 19:50 |
| natefinch | marcoceppi: the code says that has something to do with using git with the charms | 19:53 |
| marcoceppi | natefinch: ugh, this sucks and breaks a few charms in the store | 19:53 |
| natefinch | marcoceppi: I don't know that area of the code at all... but it looks like that's not new code... though it's certainly possible it's being used in a new way | 19:53 |
| marcoceppi | there are other ways to register empty directories in git other than putting a dang file in there | 19:54 |
| === BradCrittenden is now known as bac | ||
| natefinch | marcoceppi: yeah, not really the best way to do it. should be easy enough to fix so that we don't do that. | 19:55 |
| * marcoceppi files a bug | 19:55 | |
| ahasenack | guys, I just bootstrapped with juju trunk from earlier today, and I'm getting authorization errors in juju status | 19:56 |
| ahasenack | anything known about that? | 19:56 |
| ahasenack | lemme paste | 19:57 |
| natefinch | marcoceppi: actually, it looks like you can't add empty directories in git... though honestly, it doesn't seem very useful anyway | 19:57 |
| marcoceppi | natefinch: you can | 19:57 |
| ahasenack | http://pastebin.ubuntu.com/6125398/ | 19:58 |
| natefinch | marcoceppi: ok. I was just going off a quick google search. But if there's a way, then certainly it must be better than empty ugly files everywhere | 19:58 |
| marcoceppi | natefinch: but either way, theres no need to track an empty directory | 19:58 |
| marcoceppi | if it's empty, it's empty | 19:58 |
| ahasenack | r1834 | 19:58 |
| natefinch | marcoceppi: yeah, it seems like you could just ignore it | 19:59 |
| marcoceppi | natefinch: well, there was a way | 19:59 |
| natefinch | ahasenack: let me try it here | 20:01 |
| ahasenack | natefinch: I bootstrapped with --upload-tools | 20:01 |
| ahasenack | if that matters | 20:02 |
| natefinch | shouldn't... but you never know | 20:03 |
| ahasenack | natefinch: I see a traceback in cloud-init.log, digging | 20:07 |
| ahasenack | natefinch: | 20:07 |
| ahasenack | runtime: panic before malloc heap initialized | 20:07 |
| ahasenack | fatal error: runtime: cannot allocate heap metadata | 20:07 |
| natefinch | well that sounds bad | 20:08 |
| ahasenack | so the bootstrap node doesn't run on an instance with 512Mb of RAM anymore | 20:08 |
| natefinch | that is pretty tight, but I don't know... I wouldn't have expected that to change | 20:09 |
| ahasenack | can I set default constraints in environments.yaml? | 20:09 |
| ahasenack | canonistack's default is 512Mb | 20:09 |
| natefinch | hmm... I'm actually getting similar behavior on EC2 | 20:10 |
| natefinch | lemme check the cloud init log there | 20:10 |
| natefinch | definitely wouldn't be a ram issue if it happens on EC2 | 20:11 |
| ahasenack | correct | 20:11 |
| ahasenack | unless you are using a tiny instance, then maybe | 20:11 |
| natefinch | it defaults to a small | 20:12 |
| natefinch | which is what I used | 20:12 |
| natefinch | I'm getting a different error, but still an error from cloud init | 20:13 |
| ahasenack | cloud init backtraced, I had to check cloud-init-output.log | 20:13 |
| natefinch | Yeah, I looked at both... possibly the memory issue you hit was during error handling, I don't know | 20:14 |
| natefinch | I'll write up a bug. I don't know this part of the code, so there's not much I can do, but others who do know will be on soon | 20:14 |
| ahasenack | so bootstrap failed for you in the end? | 20:15 |
| natefinch | ahasenack: yeah | 20:15 |
| ahasenack | that sucks | 20:15 |
| natefinch | ahasenack: well, bootstrap appeared to complete, but then juju status got into the same loop yours got in | 20:16 |
| natefinch | 2013-09-18 20:09:33 INFO juju.state open.go:106 connection established | 20:16 |
| natefinch | 2013-09-18 20:09:33 INFO juju.state open.go:68 opening state; mongo addresses: ["ec2-54-221-155-244.compute-1.amazonaws.com:37017"]; entity "" | 20:16 |
| natefinch | over and over | 20:16 |
| ahasenack | no authorization errors? | 20:16 |
| natefinch | yeah, one at the beginning, like in your paste | 20:17 |
| ahasenack | natefinch: mine worked now | 20:17 |
| ahasenack | used a bigger instance | 20:17 |
| natefinch | hmm weird | 20:17 |
| natefinch | so why is mine failing? :/ | 20:17 |
| ahasenack | natefinch: did you wait long enough? Mine failed for a while with auth errors, but then worked, I'm guessing stuff was still happening over at the bootstrap node | 20:19 |
| natefinch | all this time and it's still not working. Weird. I'll kill it and retry | 20:22 |
| ahasenack | k | 20:22 |
| natefinch | ahasenack: same problem | 20:31 |
| ahasenack | natefinch: what's the error in both cloud-init log files? | 20:32 |
| natefinch | 2013-09-18 20:27:43 ERROR juju supercommand.go:235 command failed: state info or API info not found in configuration | 20:33 |
| ahasenack | natefinch: only that? | 20:36 |
| ahasenack | natefinch: what about mongo messages in /var/log/syslog? | 20:36 |
| natefinch | ahasenack: well, that's the meat of the error, the rest is the python traceback | 20:37 |
| natefinch | ahasenack: yeah, a bunch of these: | 20:40 |
| natefinch | Sep 18 20:28:20 ip-10-139-4-163 mongod.37017[6957]: Wed Sep 18 20:28:20 [initandlisten] connection accepted from 71.174.89.21:55993 #1 (1 connection now open) | 20:40 |
| natefinch | Sep 18 20:28:23 ip-10-139-4-163 mongod.37017[6957]: Wed Sep 18 20:28:23 [conn1] authenticate db: admin { authenticate: 1, nonce: "ec93b95260b929d0", user: "a | 20:40 |
| natefinch | dmin", key: "b386a7e0cf28af1a46eca891235e2cc2" } | 20:40 |
| natefinch | Sep 18 20:28:23 ip-10-139-4-163 mongod.37017[6957]: Wed Sep 18 20:28:23 [conn1] auth: couldn't find user admin, admin.system.users | 20:40 |
| ahasenack | that sounds like an interrupted cloud-init script | 20:40 |
| ahasenack | you can check in /var/lib/cloud/tabtab somewhere about the cloud-init files that juju gave this instance | 20:40 |
| natefinch | so, I see this in my cloud-init.log, which sounds suspicious - Sep 18 20:27:43 ip-10-139-4-163 [CLOUDINIT] cc_scripts_user.py[WARNING]: failed to run-parts in /var/lib/cloud/instance/scripts | 20:49 |
| thumper | morning | 20:58 |
| natefinch | afternoon | 20:58 |
| natefinch | thumper: windows installer is deployed to the website (again). This time with code that actually works. So, high five for that. | 20:59 |
| * thumper high fives natefinch | 20:59 | |
| natefinch | thumper: unrelated... I can't seem to bootstrap an ec2 instance using trunk. was just going to write an email about it | 20:59 |
| thumper | what error are you seeing? | 21:00 |
| natefinch | thumper: error during cloud init - 2013-09-18 20:27:43 ERROR juju supercommand.go:235 command failed: state info or API info not found in configuration | 21:01 |
| thumper | hmm... | 21:01 |
| natefinch | and some errors from mongo in syslog- Sep 18 20:30:30 ip-10-139-4-163 mongod.37017[6957]: Wed Sep 18 20:30:30 [conn350] auth: couldn't find user admin, admin.system.users | 21:01 |
| thumper | interesting | 21:02 |
| thumper | not sure what happened there | 21:02 |
| thumper | I disconnected myself | 21:02 |
| natefinch | heh | 21:02 |
| natefinch | thumper: you missed this - and some errors from mongo in syslog- Sep 18 20:30:30 ip-10-139-4-163 mongod.37017[6957]: Wed Sep 18 20:30:30 [conn350] auth: couldn't find user admin, admin.system.users | 21:03 |
| thumper | huh | 21:03 |
| * natefinch shrugs | 21:03 | |
| thumper | yes, send the email | 21:03 |
| ahasenack | natefinch: the run-parts bit, what are the scripts in /var/lib/cloud/instance/scripts ? I think it means one script in there failed | 21:06 |
| ahasenack | it's the bootstrap-state command that failed | 21:09 |
| thumper | natefinch: did you upload tools? | 21:12 |
| natefinch | thumper: yep | 21:12 |
| * thumper goes back to thinking | 21:12 | |
| === tasdomas is now known as tasdomas_afk | ||
| natefinch | thumper: http://pastebin.ubuntu.com/6125667/ | 21:15 |
| natefinch | output from bootstrap | 21:15 |
| thumper | natefinch: yeah, reading through the email | 21:16 |
| natefinch | thumper: it says it found existing jujud... sorta surprised it found jujud, actually | 21:16 |
| thumper | natefinch: ah, could be in issue with the jujud you have built locally | 21:17 |
| natefinch | thumper: yeah I was just thinking that | 21:17 |
| natefinch | thumper: if it's an old version | 21:17 |
| thumper | natefinch: can you do an install | 21:17 |
| natefinch | thumper: yep | 21:18 |
| natefinch | thumper: retrying, but I need to get going... stuff to do before dinner. I'll see if this works better. | 21:19 |
| thumper | ok | 21:19 |
| thumper | np | 21:19 |
| natefinch | thumper: worked fine with the correct jujud.... false alarm :) | 21:25 |
| thumper | ok, cool | 21:25 |
| natefinch | g'night | 21:26 |
| Beret | t | 21:29 |
| thumper | morning wallyworld | 23:14 |
| * thumper has been busy reviewing | 23:14 | |
| bigjools | hello | 23:20 |
| thumper | o/ | 23:22 |
| thumper | gym time | 23:48 |
| === thumper is now known as thumper-gym | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!