[00:57] 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 [00:57] does this need to be backported to 1.15.0 (trunk series ?) [01:13] davecheney: disregard my email. I just checked the PPA myself [01:13] I would like to know where go gets picked up from though [01:18] axw: ok [01:18] axw: are you saying, when we biuld into juju:ppa/stable, which version of Go does it use ? [01:19] /s/saying/asking [01:19] aye [01:20] ok, that is level 11 magic [01:20] me finds link [01:20] :) thanks [01:20] https://launchpad.net/~juju/+archive/stable/+edit-dependencies [01:21] this stable ppa has a dependencie on juju-golang [01:21] in effect, juju-golang is inserted into the apt sources [01:21] before apt-get install golang-go [01:21] so that is how we build with a go that isn't in any of the series' [01:21] davecheney: yes [01:21] davecheney: I'll do it [01:22] 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] back now [01:22] thumper: cool, thanks for keeping on top of it [01:23] i love the smell of backports in the morning [01:24] davecheney: thanks [01:25] axw: so that is how it works, i'm not sure if that answers all the questions [01:25] davecheney: yes, I was just curious how it works [01:25] davecheney: I didn't realise the PPAs built with CGO_ENABLED=0 [01:25] axw: if they are, it's a massive bug [01:26] davecheney: well the dev PPA binaries are statically linked [01:26] axw: say again [01:26] that should not be the case [01:26] the whole reason for this dependant ppa stuff was to accomodate the (now depricated) gwacl cgo dependency [01:26] davecheney: I just downloaded the raring 1.13.3 dev build [01:27] and "juju" is statically linked [01:28] davecheney: I only care because net.LookupIP breaks if you feed it an IP in non-cgo [01:28] htus I [01:28] erk [01:28] axw: sudo apt-add-respository ppa:juju/juju-golang [01:28] sudo apt-get install golang-go [01:28] please check [01:28] and raise a bug [01:28] ok [01:28] there is so much shit breaking i cannot keep on top ofit [01:28] davecheney: no worries :) [01:29] lucky(~/go/src) % file /usr/lib/juju-1.14.0/bin/juju [01:29] /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] does not appear to be the case [01:29] i am confused that you are seeing different results [01:29] davecheney: https://launchpad.net/~juju/+archive/devel/+files/juju-core_1.13.3-1~1737~ubuntu13.04.1_amd64.deb [01:29] get that [01:29] quantal ? [01:29] raring [01:29] sorry [01:30] axw: could you please raise an issue [01:30] otherwise i'm likely to get ... SQUIRREL! [01:30] davecheney: yep I will [01:30] :) [01:30] ooh look at the dog with the fluffy tail [01:31] PONY! [01:36] davecheney: https://bugs.launchpad.net/juju-core/+bug/1226902 [01:36] <_mup_> Bug #1226902: ppa builds are built without cgo [01:37] ta [01:39] davecheney: https://codereview.appspot.com/13241053 [01:41] thumper: LGTM, tahnks [01:42] davecheney: golang-go has CGO_ENABLED=1, so nfi [01:43] that is batshit crazy [01:43] is it blocking you today ? [01:43] davecheney: I can work around it for now [01:43] ok [01:44] 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 [01:44] please mark it fixed agaist 1.14.1 and 1.15.0 [01:44] or something [02:08] davecheney: cleaned up the bug showing 1.14 series target, with 1.14.1 milestone [02:08] taking main task as trunk [02:08] thumper: thank you, you are a very impressive man [02:09] how do you do that [02:09] i usually say 'target to series, then choose trunk and 1.14' [02:09] how do you do it ? [02:09] axw: could I draw you attention to https://canonical.leankit.com/Boards/View/103148069/106844170 [02:09] I just said "target to series" and selected 1.14 [02:09] and ask that if it won't happen, you retarget the issue [02:09] and not trunk [02:09] maybe that is where I was ging wrong [02:09] the set the milestone on that for 1.14.1 [02:10] no, didn't select trunk [02:10] that way the main bug task stays there and active [02:10] and set the milestone for the main task to be 1.15 [02:10] davecheney: if I fix this issue in time, I'll get onto that [02:10] good chance it won't happen, in which case I'll retarget [02:10] davecheney: probably either is fine [02:10] axw: i don't think this is critical for 1.15.0 [02:10] * davecheney makes a 1.15.1 milestone [02:13] thumper: wallyworld___ could you please put your heads together and reply to https://lists.ubuntu.com/archives/juju-dev/2013-September/001591.html [02:14] ok [02:14] if i can get my next 2 branches landed, we'll be good from my perspective [02:14] i'll reply in a bit [02:15] cool [02:17] davecheney: ack [02:17] davecheney: all my pending stuff is landed now [02:17] so a +1 from me, [02:17] just reviewing wallyworld___'s branch now [02:17] I think wallyworld___ is trying to go for a record of trailing underscores [02:17] i've had longer [02:17] that's what she said [02:18] wallyworld___: the door is over >>>>> there [02:18] heh [02:18] i'm here till Wednesday [02:19] wallyworld___: https://twitter.com/RikerTips/status/372018041787138049 [02:20] lol [02:20] even though i *hate* twitter [02:20] i hope the IPO fails [02:20] i also hate facebook and anything else vaguely related [02:21] shall we get off your lawn? [02:21] yes! [02:21] or i will hose you [02:21] * bigjools tingles with excitement [02:21] * wallyworld___ does too [02:37] wallyworld___ is going to eschew all technology made after 1986 [02:38] noooo, just social media, which is pointless crap [02:38] thumper: have you seen my 8 track player ? [02:38] who cares if so and so took a huge dump this morning and then brushed his teeth. seriously [02:38] mindless drivel [02:41] https://launchpad.net/juju-core/trunk [02:41] ^ is it possible to hide the old milestones [02:41] this list is longer than wallyworld___ === wallyworld___ is now known as wallyworld [02:42] davecheney: not sure, I'd ask SteveK or wgrant [02:43] hmm... [02:43] * thumper wonders what wallyworld is going to say about this review [02:44] oh dear [02:51] wallyworld: done [02:51] thanks i think :-) [02:52] thumper: i *really* wanted to have a storage subpackage under environs, then we would say "storage.Get" etc [02:52] but it was not possible [02:52] because? [02:52] because someone thought it a great idea to dump all the interfaces in environs [02:53] -> import loops [02:53] i tried to explain that in the cvering letter [02:53] ok, as I see it you have two choices [02:53] i don't know if it's a Go thing or not [02:53] keep in environs but with more descriptive names [02:53] but it seems like people don't like packages [02:53] or make a package with the interface defined in storage [02:54] I talked with fwereade about this [02:54] i'll see what can be done [02:54] and we decided it would be better to move all the interfaces into a different package [02:54] to make it so we don't ahve loops [02:54] yes! [02:54] the alternative is to have potentially diverging interface copies [02:55] i reckonif some people had their way, we would just have a single juju package [02:55] haha [02:55] it's not funny [02:55] but sad [02:55] yeah it is [02:55] sad, sad, sad [02:56] school run [02:56] thanks for reviewing [02:56] np [02:59] thumper, wallyworld: are we on for a package review in half an hour? [03:00] axw: thumper was supposed to reschedule - i have a school concert thing at the same time today [03:00] ok [03:18] https://codereview.appspot.com/13577044 [03:36] 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] or perhaps we should just wait for natefinch in the morning us time as he has the env set up. [03:42] 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 [03:42] thumper: yeah sorry, just forgot [03:42] axw: when you are making a commit, you can go "--fixes lp:1225825" [03:43] and then the branch scanner will pick that up [03:43] or you can do it from the bug or branch page [03:43] ah cool [03:43] I usually -bug in lbox [03:43] * thumper hopes to stab lbox in the heart [03:43] :) [03:44] axw: if you do it from the branch page, and you have something that looks like a number in the branch name [03:44] lp takes a guess an suggests that for the bug number [03:44] yup, quite handy [03:44] linked now [03:44] thanks [03:44] ta [03:45] axw: what do you most urgently need reviewed? [03:45] I'm on a roll [03:45] thumper: that one would be good to get into 1.15.0 [03:45] ok [03:45] * thumper looks now [03:46] thumper: after that, everything is to do with null provider/manual bootstrap [03:46] axw: what about manual bootstrap ? [03:46] probably best if all the storage stuff gets sorted first [03:46] thumper: I mean, all my remaining MPs [03:46] are to do with that [03:46] axw: give me a queue to work through [03:46] sure, just a moment [03:49] https://code.launchpad.net/~axwalk/juju-core/localstorage-to-httpstorage/+merge/185958 [03:49] https://code.launchpad.net/~axwalk/juju-core/filestorage-write-tmpdir/+merge/185715 [03:49] https://code.launchpad.net/~axwalk/juju-core/sshstorage-tmpdir/+merge/185717 [03:49] https://code.launchpad.net/~axwalk/juju-core/sanity-check-constraints/+merge/185015 [03:49] thumper ^^ [03:49] kk [03:49] thank you [03:53] axw: wasn't there a branch that moved local/storage out to another location? [03:54] just double checking that this queue is the order they'd be landed [03:55] thumper: https://code.launchpad.net/~axwalk/juju-core/manual-bootstrap/+merge/184714 [03:55] that's LGTM'd, just waiting on the sshstorage changes [03:55] it's not quite in order [03:55] I'll have to do some merging [03:56] axw: for the local -> http storage branch [03:56] the first file imports provider/local/storage as httpstorage [03:56] but the very next file uses environs/httpstorage [03:56] why the difference? [03:56] hang on, gotta refresh my memory [03:57] ah.. [03:57] local/storage is the worker [03:57] ffs, why did I do that [03:57] thumper: yeah that one is changing in the manual-bootstrap MP [03:57] * thumper confused himself [03:57] it will become worker/localstorage [03:57] wait... [03:57] *looking* [03:58] wtf [03:58] that is an error :) [03:58] I probably did an overzealous sed [03:59] thumper: cmd/jujud/machine.go should not have changed in this MP [03:59] axw: how about you do a quick sanity check on that diff, and push any changes and repropose [03:59] I'll look at the next one [03:59] yep will do [04:00] sorry about that [04:08] thumper: updated [04:09] * thumper looks [04:13] axw: re fileStorageReader, my first cut at it used filepath.Walk :-) [04:13] was told to use Glob [04:13] * thumper prefers walk [04:13] as reviewer, I approve [04:16] thumper: Glob doesn't actually work properly there, that's the main reason for the change [04:16] Glob only works for one level of the hierarchy [04:16] where does it fail? [04:17] I didn't see a test added that demontrates that [04:17] or is it later in the branch? [04:17] /tmp/* matches /tmp/blah, but not /tmp/blah/blah [04:17] * axw looks [04:17] I think it's probably in httpstorage [04:17] * thumper wonders [04:17] should /tmp/* match /tmp/blah/blah [04:17] not in shell globbing [04:18] or deos it... [04:18] should it with our one? [04:18] * axw doesn't understand the question [04:19] thumper: according to the docs for filepath: '*' matches any sequence of non-Separator characters [04:19] filepath.Match even [04:19] which is what Glob's syntax conforms to [04:20] I'm wondering what the expectation is with our interface [04:20] is the expectation that we recurse or not? [04:20] if not, then we don't really need to walk the entire structure [04:21] thumper: oh yeah, List is meant to return everytrhin === tasdomas_afk is now known as tasdomas [04:21] everything [04:21] it considers the namespace flat [04:22] 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] that would be appreciated [04:23] don't repropose until I've finsihed the review though [04:23] nearly there [04:23] okey dokey [04:26] review done [04:26] * thumper moves to the third [04:36] thumper: good call on the test, I found a bug in the existing code [04:37] for instance.HostAddresses; an IPv4 net.IP may be represented as 16 bytes [04:37] there's no check for that [04:40] :) [04:42] axw: https://code.launchpad.net/~axwalk/juju-core/sanity-check-constraints/+merge/185015 has conflicts [04:44] ok [04:44] I'll add the filestorage test and then get onto that [05:22] axw: I'm heading off shortly [05:22] axw: got anything you want a re-review on before I go? [05:24] thumper: i'll push some changes to my branch in a bit if you happen to be on later [05:24] I'm being taken out for a birthday dinner [05:24] so not really likely to be on later [05:24] but can do it tomorrow morning [05:25] ok. whose birthday? [05:25] probably around for another 20 min or so [05:25] thumper: I'm about to repropose the local-to-httpstorage [05:25] wallyworld: mine [05:25] wallyworld: and Rachel's [05:25] thumper: oh? happy birthday old man :-) [05:25] and to rachel too [05:25] wallyworld: last week dude [05:25] geez [05:26] * wallyworld didn't know [05:26] you never mentioned it :-) [05:27] wallyworld: it is why I was off for a long weekend with no kids [05:27] i thought that was wedding anniversary [05:28] it was [05:29] wedding anniversary 9th, my birthday 10th, Rachel's 11th [05:29] all together for ease of remembering [05:29] you sure do know how to organise things [05:29] * thumper bows [05:30] thumper: i'm moving StorageReader and friends interfaces to environs.storage. a lot of places to change [05:30] * thumper nods [05:30] ok [05:30] I still think you should have "Get" and "GetWithRetry" [05:30] or "GetWithStrategy" [05:30] instead of "DefaultGet" and "Get" [05:30] sure. separate issue which i'll also look at :-) [05:30] * thumper nods [05:31] thumper: there will be controvery i'm sure with the interface move [05:31] but i just can't agree it is right as is [05:31] and this is a good excuse [05:31] how are you doing the interface? [05:31] same interface names - StorageReader, StorageWriter etc, but moved to environs.storage [05:32] seems fine to me [05:32] we may have an interface package later to remove the dependency loops [05:32] but that can happen later [05:32] me too. but i'm sure i recall people wanting *all* the interfaces lumped together [05:32] and I may suggest we get technical architect approval and review [05:33] thumper: I've reproposed, but haven't done the test helper changes yet. will do that now. [05:33] * thumper nods [05:35] axw: I see the comment but not a diff change [05:35] did the propose work? [05:35] thumper: sorry, I think lbox was still working [05:35] should be there now [05:38] kk [05:43] 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] ciao [05:43] thanks thumper [06:36] wallyworld: poke about DataSource stuff [06:36] yeees? [06:36] I'm trying to figure out whether tools DataSources have '/tools' in them or not. [06:37] I might just have an out-of-date goose, though. [06:37] but the old keystone entry was just putting "" in the entry [06:37] wallyworld: still true in goose trunk if I'm reading it correctly. [06:38] jam: the keystone entry has been updates to add the /tools [06:38] "Service{"juju", "juju-tools", ... PublicURL: url") where that URL is the root of the Swift bucket [06:38] wallyworld: not in testservices/openstack/New() if I'm reading it correctly. [06:38] i can;t quite recall if goose needed updating [06:38] ah, you mean the test doubl [06:38] wallyworld: I'm testing that I can actually *fetch* something from each DataSource and some of them are failing [06:39] and I'm trying to figure out whether it is a mistaken understanding of where the stuff needs to get uploaded to [06:39] 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] i think it matters for the legacy fallback to work [06:40] so, if simplestreams it set up right, you don't need any /tools at the end [06:40] it's just a url [06:40] but, if you want the legacy fallback stuff to work, you need to stick stuck in /tools [06:41] let me take a quick look at the code [06:41] wallyworld: GetToolsSources puts environs.BaseToolsPath into the NewStorageSimpleStreamsDataSource [06:41] but uses 'juju-tools' output directly [06:41] I think it uses "ToolsURL" from config directly [06:42] and DefaultBaseURL directly [06:42] the base url can be anything [06:42] the default url is for getting stuff from the official repository [06:42] wallyworld: I was a bit confused because of different places where you end up mangling the search path for tools [06:42] but you don't touch all the possible paths [06:42] there's only one place - in tools/urls.go [06:42] so I thought "tools" got tacked on after the fact [06:43] but each provider gets to add in some search places if it wants [06:43] 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] and I'm still just trying to sort of what "correctly" is. [06:44] A couple of times now my expectations of consistency across them didn't quite match. [06:44] 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] no "tools" anywhere [06:45] but, it's convention/tradition that we tend to make the base url end in "tools" [06:45] wallyworld: and clearly you haven't fetched from the "juju-tools" keystone entry, because you can't write data to the '/' container [06:45] AFAICT [06:45] i have fetched them from there [06:46] i can write to juju-tools url/tools [06:46] the keystone entry points to blahblah/tools [06:46] wallyworld: not in the goose double [06:46] which is my point [06:46] you can't have a test case that is actually doing this [06:46] you might have tested on Canonistack [06:46] but it doesn't need to end in tools [06:47] i don't think [06:47] wallyworld: I think you're missing *my* point. [06:47] sorry, this is hard ober irc [06:47] wallyworld: the URL probably can be whatever it wants to be [06:47] 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:48] thus you probably can't have a test case that the keystone entry works [06:48] if you have one, point me to it, and I'll follow how it sets up the data [06:48] where does the goose test double keystone entry point to? [06:48] wallyworld: you *do* have a test case that we see the base URL [06:48] but no test that Fetch on that URL works [06:48] there's test cases that the urls are as expected [06:48] wallyworld: it points directly to the Swift base URL [06:49] and can't we set up one of those http proxies to return data releative to that url? [06:50] 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:51] so I could create the container named "releases" and one named "streams" and put stuff in the subdirectories (probably) [06:51] 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] wallyworld: I'm testing that both URL() and Fetch() works for each of the datasources we see [06:51] I currently can't set up Fetch in a sane way to ensure that it gets data back properly [06:51] well, you can using tools-url [06:51] I can hack around it, but it feels like we missed some test coverage [06:52] wallyworld: that is a *different* data source [06:52] sure, but it's just a http data source [06:52] I'm testing tools-url, private storage, and the keystone entry [06:52] and we test http data sources work [06:52] and we test that the correct http data soruces are returned [06:53] i guess we can add extra tests but it seems over kill given we test all the moving parts [06:53] 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] so get the data sources back and poke their config? [06:53] so instead of testing MxN, test M+N [06:54] wallyworld: well I'm just testing that I can fetch any data [06:54] so I don't have to test that simplestream layout works there. [06:54] you can test separately if you can fetch data using a data source set up as no ssl [06:54] and separately test that the data sources that come back from simplestreams all have no ssl activates [06:57] 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] wallyworld: especially given the privacy layering means you can't "just check the bit is set" [06:57] sure, but you don't need to [06:57] you just need check that the url is correct and the ssl thing is correct [06:57] and there are separate tests for if url based data sources work [06:58] there's only 2 data sources - a url based one and a environs storage one [06:58] they can be tested separately with the ssl thng [06:58] so to me it's still a M+N vs MxN strategy [07:02] 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:03] 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:04] that you can put stuff in [07:04] 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] we put tools in there for legacy things - the tools file name is "releases/tools/juju-" for simplestreams [07:05] using the existing tools StorageName method [07:05]