[07:27] <TheMue> morning
[07:29] <fwereade> heya TheMue
[07:30] <TheMue> fwereade: just went outside on our veranda to work there. the nice side of home office.
[07:35] <rogpeppe> fwereade, TheMue: mornin'
[07:35] <TheMue> rogpeppe: heya
[07:44] <fwereade> heya rogpeppe
[07:45] <fwereade> TheMue, sounds lovely :)
[07:45] <fwereade> TheMue, I find my balcony is just too damn hot/bright at the times I'd generally want to work out there, but hey ho
[07:46] <rogpeppe> ah, sun, i have vague memories of that.
[07:48]  * rogpeppe looks out at yet another grey wet day
[07:55] <TheMue> Hope that the weather next week is fine.
[07:55] <rogpeppe> me too
[07:56] <rogpeppe> fwereade: niemeyer is suggesting that UploadTools becomes part of PutFile's functionality. i'm not quite sure how that'll work though, as there are two possible places to put and get things.
[07:56] <rogpeppe> fwereade: i'm wondering what you thing
[07:56] <rogpeppe> think
[07:56] <fwereade> rogpeppe, sorry, which are the places? I saw that suggestion, looked sane at first glance
[07:57] <rogpeppe> fwereade: if you're a user, you get the tools from a public place, but you get bootstrap info from a private place
[07:58] <fwereade> rogpeppe, ah, I'd had a vague assumption that the "local" version of the tools would always be stored in filestorage, and that would be the canonical location for that particular deployment, regardless of original source
[07:58] <fwereade> rogpeppe, like charms (right?)
[07:59] <rogpeppe> fwereade: i don't think every user should be charged with 5MB+ of uploads every bootstrap
[07:59] <rogpeppe> fwereade: it slows it down apart from anything else.
[07:59] <fwereade> rogpeppe, well, it wouldn't *necessarily* have to go through the user's machine (although not doing so would be somewhat fiddlier)
[08:00] <rogpeppe> fwereade: it would using that API
[08:01] <rogpeppe> fwereade: and in fact i'm not sure it's possible to initiate S3->S3 transfers without involving either a new machine in the cloud or shuttling the data through the local machine
[08:01] <rogpeppe> but there might be i guess
[08:03] <rogpeppe> interesting: http://docs.amazonwebservices.com/AmazonS3/latest/API/RESTObjectCOPY.html
[08:03] <fwereade> rogpeppe, I'd been thinking that in the local case, we upload somewhere and somehow communicate "there" to the bootstrap machine; which would always copy the juju files to the canonical location, regardless of source (but yeah, that could maybe shortcut it)
[08:04] <fwereade> rogpeppe, (it actually feels like things could be a bit annoying if we upload to the canonical location directly from the client)
[08:04] <rogpeppe> fwereade: by "the canonical location" are you thinking of a file path or a URL?
[08:04] <fwereade> rogpeppe, URL
[08:05] <rogpeppe> fwereade: so in the local case you're suggesting we store the binaries at two URLs?
[08:06] <rogpeppe> fwereade: one for the initial upload and one "canonical" place?
[08:06] <fwereade> rogpeppe, I'm not sure it's *actually* necessary to do so, and I think it's an implementation detail
[08:06] <rogpeppe> fwereade: i'm not sure i see the advantage in doing so
[08:07] <fwereade> rogpeppe, I'm really just saying that I don't think a deployment-local copy of the source code necessarily involves copying publicly available stuff through the user's machine
[08:08] <rogpeppe> fwereade: we've got to copy things *from* the user's machine, right?
[08:08] <fwereade> rogpeppe, only in dev mode, surely?
[08:08] <rogpeppe> fwereade: yeah, sorry i thought that's what you meant by "deployment-local'
[08:08] <rogpeppe> "
[08:09] <fwereade> rogpeppe, ha, sorry
[08:09] <rogpeppe> fwereade: why would non-devs need a deployment-local copy of the source code?
[08:09] <fwereade> rogpeppe, I'm just having a quick look at the python to remind myself of something
[08:09] <rogpeppe> or the binaries, come to that?
[08:13] <fwereade> rogpeppe, I'm not privy to the details of the original discussions; my only non-waffly/hedged argument is "because we decided to do that for charms", and I'm not convinced the two cases are different enough to warrant inconsistency ;)
[08:14] <fwereade> rogpeppe, it doesn't feel to me like an intrinsically bad thing for a deployment to pull in all its dependencies as they become apparent, though
[08:15] <fwereade> rogpeppe, it should I think just make things a little less dependent on the vagaries of the wider internets ;)
[08:15] <fwereade> brb
[08:18] <rogpeppe> fwereade: yes, i agree with that. and it seems like the storage cost of storing the tools once per deployment is small.
[08:18] <rogpeppe> fwereade: however...
[08:19] <rogpeppe> fwereade: what about multiple architectures/OS versions etc?
[08:26] <fwereade> rogpeppe, sorry, not sure: what about them? won't we potentially need copies for each, whatever we do, independent of anything else?
[08:27] <rogpeppe> fwereade: so you're suggesting that every time we add a unit, we potentially copy toos to the local provider storage
[08:27] <rogpeppe> ?
[08:27] <rogpeppe> s/toos/tools/
[08:28] <fwereade> rogpeppe, I think so; just like we do on deploy, right?
[08:28] <rogpeppe> fwereade: this wasn't the plan i'd understood. but maybe it's a good thing to do.
[08:29] <fwereade> rogpeppe, hm, I don't think it's necessarily intrinsically incompatible with what we'd discussed
[08:29] <rogpeppe> fwereade: i'd thought that upload-client was an explicit flag that we would give
[08:30] <fwereade> rogpeppe, I think we have a bit of freedom to do dev/real slightly differently
[08:31] <rogpeppe> fwereade: how would dev and real be different?
[08:31] <fwereade> rogpeppe, I'd seen the upload-client flag as an explicit I'm-in-dev-mode thing
[08:32] <rogpeppe> fwereade: me too. but i think you're suggesting that real deployments do something similar?
[08:33] <fwereade> rogpeppe, I'm suggesting that deployments should internally take responsibility for distributing juju binaries just as they do with charms
[08:33] <fwereade> rogpeppe, and that the dev mode stuff simply give devs an opportunity to hook into that mechanism at a useful point
[08:34] <fwereade> rogpeppe, it may ofc be that the charm-distribution strategy is a historical accident and I'm entirely on crack
[08:35] <rogpeppe> fwereade: how do we deal with different charm versions for different platforms?
[08:35] <fwereade> rogpeppe, I don't think we do
[08:35] <rogpeppe> fwereade: 'cos that's something we need to deal with for juju tools
[08:35] <fwereade> rogpeppe, I think that's up to the charm authors
[08:36] <rogpeppe> fwereade: i thought so
[08:36] <fwereade> rogpeppe, and yes, I see that they're not 100% the same situation
[08:36] <fwereade> rogpeppe, (well, in a sense we do, in that we have separate oneiric and precise versions of some charms, and that means they carry a different identifier)
[08:37] <rogpeppe> fwereade: but not, say, 386 vs amd64 vs arm?
[08:37] <fwereade> rogpeppe, there's nothing stopping me running wordpress on precise and oneiric in the same deployment, although I'm not sure why I'd want to
[08:37] <fwereade> rogpeppe, no; I think the core idea of variation is still in there
[08:39] <rogpeppe> fwereade: so... if we go this direction, how does the initial bootstrap happen?
[08:39] <rogpeppe> fwereade: bootstrap init pulls from a URL and pushes to local provider storage?
[08:39] <fwereade> rogpeppe, I think so, yes
[08:42] <rogpeppe> fwereade: maybe that only needs to happen when the first unit is deployed.
[08:42] <fwereade> rogpeppe, yeah, I think so; it feels sensible to me to keep using the same versions everywhere until we're told to upgrade
[08:43] <fwereade> rogpeppe, (but then I also think it makes sense to be lazy about grabbing (say) the 2.4.2 ARM binaries until we actually dpeloy to ARM
[08:43] <fwereade> )
[08:44] <rogpeppe> fwereade: yeah. that's where i was coming from.
[08:44] <fwereade> rogpeppe, I'm just not quite sure where that fits in with dev mode
[08:45] <rogpeppe> fwereade: indeed. i'm all a bit confused about how things would work exactly now.
[08:45] <fwereade> rogpeppe, but a build-absolutely-everything script, and a dev-mode bootstrap that pushes everything, sounds, well, plausible at least
[08:46] <fwereade> rogpeppe, I'm definitely drawing heavy inspiration from how charm publishing works atm
[08:46] <fwereade> rogpeppe, er, in python, not in the store
[08:47] <fwereade> rogpeppe, that's something that appears to "just work" pretty well
[08:48] <fwereade> rogpeppe, but I am suddenly starting to worry that there are enough subtle differences that I've led myself astray
[08:48] <rogpeppe> fwereade: so... is this about right: when you want to deploy a service, an agent (the machine agent?) pulls the charm from a URL and pushes to the local provider storage. then when a unit starts, the unit agent pulls the charm from local provider storage and runs it?
[08:49] <fwereade> rogpeppe, unless I've really missed something, the charms even from the store round-trip through your local machine
[08:49] <rogpeppe> fwereade: i don't know. the main significant difference AFAICS is that there are no bootstrapping issues with charms.
[08:49] <fwereade> rogpeppe, I consider this to be sucky *but* an implementation detail
[08:49] <rogpeppe> fwereade: really?
[08:49] <fwereade> rogpeppe, pretty sure
[08:50] <rogpeppe> fwereade: i'd prefer that not to be true for the tools. they're 10MB already and will be larger.
[08:50] <fwereade> rogpeppe, "charm = yield repo.find(charm_url)"
[08:50] <fwereade> rogpeppe, hence my talking about it being an implementation detail
[08:50] <fwereade> rogpeppe, hm wait a mo
[08:51] <fwereade> rogpeppe, no, I'm right, repo.find downloads
[08:51] <fwereade> rogpeppe, I'd prefer also that it not be true for the charms
[08:51] <rogpeppe> fwereade: agreed.
[08:52] <fwereade> rogpeppe, but I think that in neither case is it actually *necessary* that the publicly available stuff be downloaded
[08:52] <fwereade> rogpeppe, I'm suggesting the philosophy is worth copying not the implementation
[08:57] <rogpeppe> fwereade: i think i agree. i'm just trying to work out what it means.
[08:59] <rogpeppe> fwereade: how's this for a sketch: http://paste.ubuntu.com/956991/
[09:00] <rogpeppe> fwereade: actually, one slight mod: http://paste.ubuntu.com/956997/
[09:00] <fwereade> rogpeppe, in essence yes; I think there are maybe some arch-related subtleties around the "version" there, but I think-hope they're impishdetails rather than fully devilish ones
[09:01] <rogpeppe> fwereade: what kind of things are you thinking of there?
[09:01] <fwereade> rogpeppe, I *think* it'll only be an issue in dev mode
[09:02] <fwereade> rogpeppe, and I think as a dev I can put up with building everything I plan to need for my env before bootstrapping and just splurging them all up there at bootstrap time
[09:03] <rogpeppe> fwereade: yeah. i think you have to.
[09:03] <fwereade> rogpeppe, with that assumption in place it feels like it'd work
[09:03] <rogpeppe> fwereade: and you *can't* deploy to a version with a different arch if you want to use your local version
[09:04] <rogpeppe> s/deploy to a version/deploy to a machine/
[09:06] <fwereade> rogpeppe, hmm, can't we cross-compile?
[09:07] <rogpeppe> fwereade: not if we want to use DNS.
[09:07] <rogpeppe> (DNS uses cgo, which means that we need the dynamic libraries available when we compile)
[09:08] <fwereade> rogpeppe, ty
[09:08] <fwereade> rogpeppe, but this means we are actually not able to cross-compile at all?
[09:08] <rogpeppe> (i might be wrong about some of the details there)
[09:08] <rogpeppe> fwereade: pretty much, yeah.
[09:09] <fwereade> rogpeppe, I'm comfortable avoiding a deep-dive on the subject, that sounds like the critical issue
[09:09] <rogpeppe> fwereade: well... no, you can, and it's dead easy
[09:09] <fwereade> rogpeppe, ah ok...
[09:09] <rogpeppe> fwereade: but you don't get certain packages
[09:09] <fwereade> rogpeppe, ah, got it; so DNS really did mean DNS :)
[09:09] <rogpeppe> fwereade: the go compiler is always a cross compiler too
[09:09] <fwereade> rogpeppe, so I had thought :)
[09:09] <rogpeppe> fwereade: yeah.
[09:10] <rogpeppe> fwereade: the problem is that on some platforms you just can't do everything by invoking syscalls
[09:10] <rogpeppe> fwereade: there's magic in the local libraries too, so you need to call them.
[09:10] <fwereade> rogpeppe, that said I think we touchedon it in the thread and niemeyer agreed that no-foreign-dev-builds was an acceptable tradeoff for now anyway
[09:11] <fwereade> rogpeppe, ha, ok
[12:34] <fwereade> rogpeppe, TheMue: https://codereview.appspot.com/6129053
[12:34] <fwereade> ...and lunch
[12:35] <TheMue> fwereade: enjoy
[13:16] <rogpeppe> fwereade: reviewed
[13:17] <fwereade> rogpeppe, tyvm
[14:47] <rogpeppe> fwereade: i've updated the uploadtools proposal in the light of gustavo's comments, which i think are compatible with the result of our discussion earlier. https://codereview.appspot.com/6128046/
[14:48] <fwereade> rog, cheers
[14:48] <rogpeppe> (it's a pity that codereview/lbox doesn't deal with file moves well)
[15:15]  * rogpeppe just deleted >70 lines of slightly dubious code. oh, the pleasure!
[15:16] <rogpeppe> make that >100
[15:31] <niemeyer> Hello!
[15:32] <niemeyer> fwereade, rogpeppe, TheMue: Anyone around still?
[15:32] <rogpeppe> niemeyer: yo!
[15:33] <rogpeppe> niemeyer: i think we all are, probably
[15:33] <rogpeppe> niemeyer: we could even have our start-the-week meeting maybe
[15:33] <rogpeppe> niemeyer: how's things in californeye-ay?
[15:33] <TheMue> niemeyer: Heya.
[15:34] <niemeyer> rogpeppe: Probably not today, at least.. we're about to have the kick off talk by Mark
[15:34] <rogpeppe> niemeyer: k
[15:34] <TheMue> rogpeppe: BBQ is already hot here.
[15:34] <niemeyer> rogpeppe: I could wake up earlier tomorrow so we can do it, though
[15:34] <niemeyer> TheMue: Nice :)
[15:34] <rogpeppe> TheMue: sounds like you've got nice weather. jealous!
[15:34] <rogpeppe> niemeyer: that sounds good
[15:34] <TheMue> niemeyer: Yes, indeed, traditional party starting into May.
[15:35] <TheMue> rogpeppe: 20°C, sun is shining.
[15:35] <rogpeppe> niemeyer: i wonder if i could run something past you briefly that i discussed with fwereade this morning
[15:35] <niemeyer> rogpeppe: Sure, what's up?
[15:35] <rogpeppe> niemeyer: it's to do with how we do the bootstrap stuff
[15:36] <rogpeppe> niemeyer: here's a sketch of how i *think* it might work
[15:36] <rogpeppe> niemeyer: http://paste.ubuntu.com/957728/
[15:36] <rogpeppe> niemeyer: the difficulty being that unlike Put/GetFile, upload tools has two places to go to
[15:37]  * niemeyer reading through
[15:37] <rogpeppe> niemeyer: there should be a blank line before "on bootstrap machine init" BTW
[15:38] <niemeyer> rogpeppe:It all sounds good until the provisioning agent bits
[15:38] <rogpeppe> niemeyer: go on
[15:39] <niemeyer> rogpeppe: I'm wondering why it has to recompute
[15:39] <niemeyer> rogpeppe: I guess it makes sense, since there are different circumstances depending on what's being run
[15:39] <rogpeppe> niemeyer: exactly
[15:39] <fwereade> niemeyer, heyhey; sorry, landlady cam round early
[15:40] <niemeyer> fwereade: Heya!
[15:40] <rogpeppe> niemeyer: different versions might be appropriate for different os/arch combinations
[15:40] <niemeyer> rogpeppe: That scheme looks reasonable
[15:40] <rogpeppe> niemeyer: the only really new bit is that the binaries are usually copied to private storage
[15:41] <rogpeppe> niemeyer: that doesn't happen with the bootstrap machine, unless you force it with --upload-client
[15:41] <niemeyer> rogpeppe: Hmm
[15:41] <niemeyer> rogpeppe: private doesn't have to be private.. that might make things simpler
[15:41] <rogpeppe> niemeyer: fwereade's suggestion, based around what we do with charms
[15:42] <rogpeppe> niemeyer: how do you mean?
[15:43] <niemeyer> rogpeppe: Private might be a bit misleading, in the sense that this is the environment storage to which the client has write access
[15:43] <niemeyer> rogpeppe: There's no intrinsic reason why *those* files, specifically, have to be private
[15:43] <rogpeppe> niemeyer: it's also the same storage name space that's used for storing the environment zookeeper addresses
[15:44] <niemeyer> rogpeppe: Hmmm.. on S3, though, we can do even better
[15:44] <niemeyer> rogpeppe: We can make $u a signed URL, that has read access from the bucket even though it is private
[15:45] <rogpeppe> niemeyer: i'm not sure i see how that helps
[15:45] <niemeyer> rogpeppe: Hold on, sorry.. why is $u being copied?
[15:45] <niemeyer> rogpeppe: i've missed that in the scheme
[15:46] <rogpeppe> niemeyer: the idea is that an environent gets a stable, local copy of the juju tools, even if the originals have come from a remote, potentially unstable source.
[15:47] <niemeyer> rogpeppe: We shouldn't worry about that now IMO.. $PUBLIC is going to be configurable
[15:47] <niemeyer> rogpeppe: and right now both private and public are equally trustable, being in S3
[15:48] <rogpeppe> niemeyer: the difficulty i'm having is that we've subsumed UploadTools into PutFile, but there are now *two* name spaces not one
[15:48] <rogpeppe> niemeyer: we've got the place that the tools are stored and the place that the environment settings (zookeeper addresses currently) are stored
[15:48] <niemeyer> rogpeppe: We've always had two.. that's not related to UploadTools vs. PutFile
[15:49] <rogpeppe> niemeyer: we didn't use PutFile for the other storage space though, right?
[15:49] <niemeyer> rogpeppe: Which other storage space?
[15:49] <rogpeppe> niemeyer: the storage space for the executable files
[15:50] <niemeyer> rogpeppe: Sorry, let's get a bit more specific
[15:50] <niemeyer> rogpeppe: PutFile should be used by the client to upload the tools to the environment storage
[15:50] <niemeyer> rogpeppe: PutFile is not used to upload to the public storage because it's not maintained by the juju client
[15:52] <niemeyer> rogpeppe: Does that make sense?
[15:52] <niemeyer> rogpeppe: If it does, I'm not sure about what you mean
[15:53] <rogpeppe> niemeyer: yes it does. and i think my confusion has gone. if i delete the lines that copy $u, it all looks fine.
[15:53] <niemeyer> rogpeppe: Sweet
[15:55] <rogpeppe> niemeyer: one other reservation was that the prefix "tools/" becomes rather special, but i think that's fine - i've documented it on Environ.PutFile: http://paste.ubuntu.com/957764/
[15:55] <niemeyer> rogpeppe: Agreed
[15:55] <rogpeppe> niemeyer: and that makes it reasonable for an Environ implementation to know about files of that form when searching for tools
[15:55] <niemeyer> rogpeppe: We'll have another special prefix too: charms/
[15:56] <rogpeppe> niemeyer: cool.
[15:56] <niemeyer> rogpeppe: That's how it was originally designed, but the ancient "nova object store" couldn't deal with slashes (!)
[15:56] <niemeyer> rogpeppe: We don't care about that anymore, so can do the right thing
[15:56] <rogpeppe> niemeyer: great.
[15:57] <rogpeppe> niemeyer: i've just been deleting the "juju-origin" code BTW and it feels marvellous
[15:58] <niemeyer> rogpeppe: +1000 :)
[15:58] <rogpeppe> niemeyer: >100 lines of code gone, just like that (and that's not even including the tests!)
[16:00]  * fwereade approves :)
[16:01] <niemeyer> rogpeppe: re. this:
[16:01] <niemeyer> """
[16:01] <niemeyer> rogpeppe: Well, I did suggest
[16:01] <niemeyer> Arm
[16:01] <niemeyer> Thanks copy & paste
[16:01] <niemeyer> i don't think so. "t" is for "test" here - i'm not sure that there's a
[16:01] <niemeyer> single set of arguments that will result in characteristic for all
[16:01] <niemeyer> commands, so we use the test table above.
[16:01] <niemeyer> """
[16:02] <niemeyer> rogpeppe: The only difference in that table is the "juju" vs "jujud" string
[16:02] <niemeyer> rogpeppe: It's really not worth a table in that case..
[16:03] <rogpeppe> niemeyer: i guess, if we can force a similar-looking usage message out of all juju commands by passing them the same arguments
[16:03] <rogpeppe> niemeyer: it's probably true of jujuc too, and perhaps that's all we'll ever have
[16:03] <rogpeppe> niemeyer: ok, will remove the table
[16:03] <niemeyer> rogpeppe: That's my guess, and we can always change back when it does make sense to have it
[16:04] <niemeyer> rogpeppe: Mostly a "doesn't look like it's necessary", rather than "we can't do this"
[16:04] <rogpeppe> niemeyer: k
[16:05] <TheMue> So, just came back to wish you a happy labour day tomorrow and you a good time in IAK, niemeyer.
[16:06] <TheMue> niemeyer: I've done the watcher test refactoring, it's proposed.
[16:06] <niemeyer> TheMue: Thanks a lot, have a good time too!
[16:06] <niemeyer> TheMue: Cheers.. I'll do a review pass tonight
[16:07] <TheMue> niemeyer: Thank you, will have. And looking forward to next week. But we'll meet here on Wednesday again.
[16:07] <TheMue> Bye
[16:10] <rogpeppe> niemeyer: i've made that change BTW
[16:11] <niemeyer> rogpeppe: Thanks!
[16:22] <niemeyer> rogpeppe: Looking, tentatively :)
[16:29] <niemeyer> Have to move
[16:29] <niemeyer> biab
[16:43] <rogpeppe> fwereade: ping
[16:43] <fwereade> rogpeppe, pong
[16:44] <rogpeppe> fwereade: here's a thought: rather than having a --upload-client flag, we have an upload-client command
[16:44] <fwereade> rogpeppe, hmm, that sounds like a good idea to me
[16:44] <fwereade> rogpeppe, although it makes me less certain that that's precisely the right name
[16:45] <rogpeppe> fwereade: 'cos i was just looking at looking as it as a flag and it's not really appropriate on quite a few commands, but seems like it might work well as a command in its own right
[16:45] <rogpeppe> fwereade: upload-tools? upload?
[16:45] <fwereade> rogpeppe, upload-tools sounds pretty good
[16:46] <rogpeppe> fwereade: the idea is you can execute it *before* bootstrap if you want
[16:46] <fwereade> rogpeppe, yes, very nice
[16:46] <rogpeppe> fwereade: good, thanks.
[16:47] <rogpeppe> fwereade: ok, i'll give that a go
[16:47] <rogpeppe> fwereade: unless you wanna
[16:48] <fwereade> rogpeppe, I'm very happily fiddling with the hook commands atm
[16:48] <rogpeppe> fwereade: ok great
[17:00] <rogpeppe> right, i'm off for the evening. see y'all tomorrow
[17:01] <fwereade> likewise
[17:01] <fwereade> take care all