[01:05] niemeyer: http://paste.ubuntu.com/1002200/ [01:05] as an example API [01:17] i will have to add mutexs around all of the variables touched by SetConfig to ensure their visibility [01:26] davecheney: Might make sense to have one or more internal helper methods.. e.g.: func (e) credentials() (accessKey, secretKey string) [01:26] davecheney: So the locking is constrained [01:27] yeah, each providor is different [01:27] davecheney: yeah, that's for internal use only [01:27] in ec2, config is used to construct an ec2 and s3 at open time [01:28] so those will need to be reconstructed [01:28] davecheney: Same idea.. rather than credentials, func (e) s3() *S3 then.. [01:28] yup [01:29] davecheney: So locking is only necessary within the method itself [01:29] i will try to make it as fine grained as possible [01:30] davecheney: I was more worried about convenience than granularity in this case [01:30] davecheney: THis is a very rare event [01:30] yup [01:31] ... value *net.OpError = &net.OpError{Op:"remote error", Net:"", Addr:net.Addr(nil), Err:0x28} ("remote error: handshake failure") [01:31] Com'on Amazon [02:26] Woohay [02:26] Signed URL works [02:46] and proposed [02:48] niemeyer: just go though a first cut of Environ.SetConfig [02:50] davecheney: Nice [02:50] davecheney: How does it feel? [02:50] not too bad [02:50] had to use _variables [02:50] which feel icky [02:50] but adding accessors for the configuration items wasn't too bad [02:51] just running off lbox propose [02:54] davecheney: Feels icky indeed [02:55] https://code.launchpad.net/~dave-cheney/juju/go-environs-setconfig/+merge/106930 [02:55] davecheney: Will let you know if I can think of something else tomorrow [02:55] davecheney: Right now it's past bed time here [02:56] niemeyer: at the risk of reactivating the discussion from earlier [02:57] the proxy environ was cleaner [02:57] as in the case of ec2, we replace everything when we call SetConfig [02:57] the end result is very similar [02:57] but we can continue that discussion tomorrow [02:58] davecheney: It's actually not, for the reasons I explained.. doing e.Foo(); e.Bar() and being completely unable to tell whether e is a completely different value is a no no. [02:58] fair enough, i'm happy the discussino is closed [02:58] davecheney: I'm happy to discuss other possibilities, but something that has that property won't fly [02:58] niemeyer: understood [02:59] davecheney: The locking you did, even if it feels like overhead, is putting you in control [03:09] why does lp treat me so badly ? [03:09] % lbox propose -wip -edit [03:09] error: Failed to load data for project "juju": Get https://api.launchpad.net/devel/juju: unexpected EOF [03:09] it's totally random [03:10] davecheney: Good question.. I haven't seen that level of weirdness [03:11] davecheney: and I'm not specially close to it either [03:11] Anyway, bed for reals now :) [03:11] davecheney: Have a good EOD [03:11] kk [06:58] rogpeppe: around today ? [07:01] davecheney: Heya [07:01] hey frank [07:01] how are you going ? [07:02] davecheney: Fine, pretty wither today here in Germany. And you? [07:03] pretty cold in sydney [07:03] still grinding on the provisining agent [07:03] still rewriting the environs interface :)\ [07:06] davecheney: I'm still working on the relations, currently three depending branches in the queue. [07:12] davecheney: just up [07:12] davecheney, TheMue: morning! [07:12] rogpeppe: Heya [07:29] morning. [07:39] Aram: hiya [07:55] Aram: Moin [09:25] fwereade: yo! [09:25] rogpeppe, heyhey === Guest__ is now known as smaddock [09:26] rogpeppe, I just saw yu had anothe CL in that same sort of area perhaps? [09:26] rogpeppe, if my comments are redundant, sorry [09:26] fwereade: i'm moving it all forward bit by bit... [09:27] rogpeppe, cool -- I'm just not sure about fixing the name without fixing the type ;p [09:27] fwereade: you think that InstanceSpec is ill-conceived? what should we have there? [09:27] rogpeppe, the type itself is not so bad, but half the fields are misleading/useless [09:27] fwereade: Moin [09:27] fwereade: "a type that is moderately ill-conceived in the first place." :-) [09:27] rogpeppe, we have no interest in daily, desktop, or instance-store images [09:28] fwereade: ok, i'll take out that param [09:28] rogpeppe, when fully 50% of a type's fields are irrelevant, I think a little of the ill-conceivedness leaks out into the type itself :p [09:28] fwereade: naah [09:29] rogpeppe, ok, "obscures any essential rightness the type may be in posession of" [09:29] fwereade: it's a place-holder for things to come IMHO [09:29] fwereade: the important change is that the i want the type to represent the constraints on an instance, not just an machine image. [09:30] rogpeppe, sure, a type can be incomplete, but it's carrying baggage that's just unhelpful, and that's all I'm complaining about [09:30] s/the i/i/ [09:30] TheMue, heyhey [09:30] fwereade: sure. maybe this is a good CL to change some of those in. [09:30] fwereade: or perhaps i could do that in another CL [09:30] fwereade: i'm trying hard to keep CL sizes down. [09:31] fwereade: i.e. move things forward in small increments. [09:31] rogpeppe, I'm easy [09:31] fwereade: my next branch is too big and i'm going to need to split it up, which is a right pain [09:32] rogpeppe, yeah, I seem to spend rather too much of my time doing that sort of thing [09:32] fwereade: i was thinking last night that i want some way of saying "factor *these* changes into a new branch" - in about one line of shell. [09:33] so you want git? :D. [09:33] * Aram hides. [09:33] * rogpeppe has never used git [09:33] it does that thing. [09:33] probably the only thing it does well. [09:33] that was kinda my first thought too :) [09:34] Aram: out of interest, what git command would you use to do that? [09:36] if you want to do it at commit time, you just git add your changes (my understanding is that you can git add parts of the file as well, not whole files). [09:36] basically in git you don't commit everything by default, but have to chose what to commit every time. [09:36] there's also cherry picking. [09:36] that makes it easy to move only some changes between branches, but not every change. [09:38] cherry picking is literally picking commits from one place and applies them somewhere else, so you don't have to do any manual merging step or whatever. really handy. [09:38] as much as I dislike git and I complain about it all the time, it does some things well. [09:44] fwereade: hope you've had a good few days off, BTW [09:46] fwereade: for PersistentStorage/Daily/Desktop, are you saying that we will *never* want to use anything but PersistentStorage=true, Daily=false, Desktop=false ? [09:47] fwereade: because that logic is in the python version, so i copied it across [09:47] fwereade: but if we know the settings for all time, i'm always happy to delete code! [09:52] rogpeppe, yeah: all that stuff is gone from the python [09:53] fwereade: sigh [09:53] rogpeppe, and niemeyer appears to be -1 on handling instance-store stuff [09:53] fwereade: ok, i'll remove the settings in an upcoming branch [09:53] rogpeppe, which I can get behind tbh, even though it would be trivial to implement [09:53] rogpeppe, cool, thanks [09:54] updates, restarting [10:29] test [10:31] rogpeppe: success [10:31] TheMue: thanks. my web browser seems to be playing up. [10:32] fwereade: Thx for review. Requirer as noun exists? Sounds strange. But ok. ;) [10:33] cool google logo today [10:33] TheMue, it's not one I'd use in conversation, but it's definitely closer to legitimate english than, say, "ReadCloser" :p [10:33] rogpeppe: Already played a song? [10:34] fwereade: Hehe, yeah. [10:44] fwereade: So, name change done. No merge it again into the follow-up. [10:45] TheMue, cool, thanks [11:18] rogpeppe: in testing charm repos, would you agree it makes most sense to run them against an actual store.Server? [11:19] fwereade: it depends how much interaction with the server it has, i guess [11:19] fwereade: if it's just a simple GET, then maybe there's no point. [11:19] fwereade: we don't necessarily want to fire up mongodb for every test. [11:20] fwereade: but that's a *totally* off-the-cuff response! [11:20] rogpeppe, that's the thing... it does feel a little bit heavyweight [11:20] rogpeppe, but a canned-response tet server feels a little lightweight :/ [11:21] fwereade: does it actually do anything other than a simple GET? [11:21] rogpeppe, I'll think on it some more; early lunch today, maybe somewhat extended; will be back for the rest of my "morning" in a bit [11:21] rogpeppe, (taking half-days this week) [11:21] fwereade: cool [11:21] fwereade: still in the UK presumably? [11:22] fwereade: hope you've got the same lovely weather we have. perfect for half days... [12:53] rogpeppe: Could it be that the watcher problems are since about one week? [12:54] TheMue: it's possible. [12:54] TheMue: i couldn't say for sure i'm afraid [12:55] TheMue: have you got a possible candidate for the source of the problems? [12:55] rogpeppe: Just found the change introducing the "initialValue" flag in the content watcher. [12:55] TheMue: it's entirely possible that's the problem! [12:55] rogpeppe: And the problem I've got here in my test belong to the content watcher. [12:55] TheMue: it may easily all be my fault. [12:56] TheMue: if that's true, we need better tests in the watcher package :-) [12:56] rogpeppe: *lol* [12:56] rogpeppe: What's the intention behind this flag? [12:56] TheMue: it's so that the initial value is always sent, regardless of what it is [12:57] TheMue: perhaps your tests are assuming otherwise... [12:57] TheMue: s/tests are/code is/ [12:57] rogpeppe: That's possible, the old behavior has been different. [12:58] TheMue: i think maybe the old behaviour didn't send something if the initial contents were blank [12:58] TheMue: that might actually be the behaviour we want, i guess. [12:58] TheMue: one question: why doesn't the test fail all the time? [12:59] rogpeppe: It might or it is? [12:59] TheMue: i dunno. depends what we're after. [12:59] rogpeppe: Yes, that's an interesting question. [12:59] TheMue: i think it's probably because it depends whether the content watcher sees the initial blank value before the test changes it. [13:00] rogpeppe: So we're back to the race condition. [13:01] TheMue: yeah, but we know what the problem is, and it's easy to solve - just put a sleep before the initial contents set. [13:01] rogpeppe: Yip [13:01] TheMue: woof === asavu_ is now known as asavu [13:31] Hello all [13:32] hi. [13:34] yo. [13:34] Aram: Monday is the day then? [13:34] yes. [13:34] nice. [13:35] that's. [13:35] awesome. [13:35] :-) [13:35] yes :). [13:35] rogpeppe, TheMue, fwereade: Aram is joining us officially on Monday [13:36] niemeyer: cool. i heard from robbiew yesterday. [13:36] Aram: welcome! [13:36] niemeyer: Moin. Great news! [13:36] thanks, hi all! [13:36] Aram: Welcome. [13:40] fwereade: thanks for your review :D [13:51] andrewsmedina, a pleasure :) [13:52] Aram, welcome! [13:52] niemeyer, heyhey [13:52] thanks/. [13:53] andrewsmedina: Heya [13:54] andrewsmedina: Aram is joining the team on Monday, btw [13:54] fwereade: Heya [13:56] rogpeppe: Wanna have another look at SignedURL? [13:56] niemeyer: looking already [13:57] rogpeppe: Cool, thanks for the review, looks even better now :) [14:00] niemeyer: " [14:00] Corrupting the returned URL is testing the behavior of something that is not [14:01] what the method produces. [14:01] " [14:01] i was suggesting, i think, that we test that the unsigned URL would fail where the signed URL would succeed [14:01] i'm not sure that the tests verify that currently - we're just assuming that Get of the unsigned URL will fail because the object is private [14:02] rogpeppe: And I'm suggesting that this is not testing SignedURL [14:02] rogpeppe: Because you're testing something that is *not* the signed URL [14:02] Aram: welcome :D [14:02] niemeyer: the assumption of those tests is that the signed URL is giving us something that the unsigned URL does not, right? [14:02] rogpeppe: There are positive and negative tests in place already, and both of them verify the real URL. [14:02] rogpeppe: No [14:02] rogpeppe: The unsigned URL is completely irrelevant [14:03] rogpeppe: The behavior of a signed URL stands on its own.. if you corrupt the URL, you're not testing the method anymore [14:04] andrewsmedina: thanks. [14:04] niemeyer: if the server is letting everything through anyway, then the signing is irrelevant and the test isn't testing anything. [14:04] niemeyer: my suggestion makes sure that the test *is* actually testing something. [14:04] rogpeppe: If the server is letting everything through, the tests will fail, and they *did fail*! [14:05] rogpeppe: They are testing something.. please take the code and set authIsBroken to 1 [14:05] Aram: were are you from? [14:05] rogpeppe: or 0 [14:05] rogpeppe: It will break, because the auth is letting everything through in the fake server [14:05] robbiew: Hi. I'm ready. [14:05] niemeyer: for instance, i think the test would succeed ok if the server verified expiration time without testing the signature [14:05] andrewsmedina: I am from romania but I currently live in austria. [14:06] Aram: Austria? Ah, so you now may be the nearest to me. Been twice in Vienna, a wonderful town. [14:07] rogpeppe: Heh.. the server may be broken in all kinds of ways, yes [14:07] Aram: I'm from Brazil [14:07] * TheMue should measure, Roger still has good chances to be nearer. [14:07] TheMue: where are you from? [14:07] Aram: Oldenburg in North Germany [14:07] niemeyer: it's ok, i don't mind if we don't do the check. it was just a suggestion. [14:08] andrewsmedina: same place as niemeyer? [14:08] rogpeppe: If it allowed you to see a *private* object, just because you provided a URL with an expire time, what is broken is not the SignedURL method, though. [14:08] rogpeppe: Thanks for the suggestion. I've read it, understood it, and replied. [14:08] TheMue: g+ invite on the way [14:09] robbiew: ack [14:09] niemeyer: true. but it does mean we haven't verified SignedURL. i don't mind much. [14:10] rogpeppe: No, it doesn't mean that. I don't mind much that you don't agree either, though. [14:10] Aram: no, I live in Rio de JAneiro [14:10] rogpeppe: Because we tend to get in those interminable arguments very frequently. [14:10] niemeyer: sorry about that [14:11] rogpeppe: The test not only worked, but it detected the fact that the auth in the server was broken. There's a positive and a negative test, both verifying access to a private object. [14:12] rogpeppe: Your argument is that you wanted to see that a plain URL, *without signature*, works. [14:12] rogpeppe: It's beyond me how you're willing to argue that to death. [14:12] [14:12] niemeyer: i'm not. i've stopped. i'm fine with what you've got. [14:13] rogpeppe: You've stopped with "it does mean we haven't verified SignedURL". Thanks, but that sucks. [14:14] rogpeppe: Enjoy the method, though. Happy to help. [14:14] niemeyer: oh sorry. i meant that only in the case that the server is broken so it checks the expiry time only. [14:16] TheMue: by air you seem to be the same distance from me and rogpeppe, by land I'm closer because there's no water to cross. [14:17] niemeyer: "// URL returns a non-signed URL that allows retriving the object at path". [14:17] s/retriving/retrieving/ [14:17] :-) [14:18] and i'd s/a non-signed/an unsigned/ too [14:18] but i'm too late ... [14:25] rogpeppe: Fixed. [14:29] Aram: Yes, it's funny how near the UK is, only the North Sea between us. [15:06] Heading to lunch [15:18] hey all: despite the very long lunch, I'm pretty sure I've done my half day now [15:18] fwereade: np. you might want to have a brief look at this, if you have any time at all: https://codereview.appspot.com/6209094 [15:19] fwereade: it adds a "public-bucket" field to the ec2 config [15:20] fwereade: i'm not entirely sure that's the best name for it, but gotta start somewhere... [15:20] i have to have some lunch too [15:21] what's your setup guys, do you use a stable or unstable ubuntu release for development? [15:21] (so the hidden question really is if a stable version is good enough). [15:22] rogpeppe, it suddenly seems to me as if we're going to a lot of trouble to accommodate something in juju (tool upload) that could be entirely replaced with (1) the public-bucket and (2) a tiny separate script that just nukes the bucket and repaves with fresh local builds [15:23] rogpeppe, maybe my problem is derived from the name though... but surely the public source will always be the same for everybody? so, not necessarily a bucket, just a url prefix [15:24] rogpeppe, and the only reason (that I can see) to make it configurable is for testing [15:24] rogpeppe, have I just gone off into the weeds? [15:25] Aram, stable, fwiw [15:30] rogpeppe, I do need t be off now; I've left a tab open, it'll be the first thing I see when I come back :) [15:30] later :) [15:42] Aram: i use vanilla 12.04 [15:43] Aram: I'm using stable (so now 12.04) as "production environment" in a VM and test unstable releases in another VM. [15:43] I see. [16:13] fwereade: i don't know. maybe you're right and we should just strip all that stuff out. [16:13] niemeyer: what do you think? [16:15] fwereade: You mean implementing the exact same logic as tool upload, but outside of juju? [16:19] rogpeppe: If that's what fwereade means, I'm not sure.. feels like we'll have the exact same trouble on both sides.. we're just delegating it to a second class citizen that is not as well integrated. [16:20] niemeyer: i guess it would mean that we could do a simple uploader for each provider type without having to have all the --upload-tools flags and args to Bootstrap etc [16:20] rogpeppe: All? You mean two? :) [16:21] niemeyer: :-) [16:21] niemeyer: the logic for finding tools would be a little simpler too. only one Storage per environ. [16:22] rogpeppe: I don't have a strong feeling about it, but I'm not convinced it's getting us much. Having convenient mechanisms for people to develop juju itself feels like a valuable goal. [16:22] rogpeppe: How so? public-bucket is a storage [16:22] rogpeppe: And it has to exist for every single storage, despite uploading tools [16:23] rogpeppe: Because the real tool deployments uses the public storage too [16:24] rogpeppe: The only difference is that FindTools would look in a single storage, rather than in two. So 3 or 4 lines rather than 6 or 7 [16:24] niemeyer: yeah, that's true. we need both regardless. [16:24] niemeyer: did you take a look at the public-bucket branch, BTW? [16:25] niemeyer: (i'm quite happy with the direction we're going actually. it's always good to try and take a step back and think "is this really the right way to do it?" though.) [16:25] rogpeppe: No, I had a look at a nice lunch just now :) [16:25] niemeyer: cool. hope your weather is as nice as ours ... [16:26] rogpeppe: What's the public-bucket setting about? [16:26] rogpeppe: It's surprisingly good [16:26] rogpeppe: Feels like we're going back onto summer, even though it's quite the opposite [16:26] niemeyer: public-bucket is where the provider looks for public storage. [16:26] niemeyer: i.e. to get the publicly accessible tools downloads from [16:27] rogpeppe: Ah, nice [16:27] niemeyer: perhaps in the future we might want to support a simple URL, so we don't have to host the binaries in EC2, but i think that a bucket should be ok for now. and it makes it easy to write to for testing purposes :-) [16:27] rogpeppe: Btw, are you seeing my messages in that thread with William? [16:28] rogpeppe: Or just William's? [16:28] niemeyer: the "serve metadata and config" thread? [16:28] rogpeppe: Yeah [16:29] niemeyer: yeah, i'm seeing them. although i haven't read it in a couple of hours [16:29] rogpeppe: Ok.. np [16:29] rogpeppe: negronjl seems to missing my messages that go to the list for some reason [16:29] negronjl: Apparently they're reaching the list, at least [16:29] niemeyer: well, i *might* be missing some of your messages... :-) [16:30] niemeyer: oh yeah, just seen negronjl's email. perhaps you count as spam :-) [16:31] rogpeppe: It might be half-right.. :-) [16:31] niemeyer, rogpeppe: lol ... [16:31] niemeyer: I am checking my spam folder just to be sure ... [16:31] niemeyer: while i remember... are we going to try to have monday meetings as planned? [16:33] rogpeppe: Yeah, we should [16:33] rogpeppe: This one might be a tricky one as I'll be in London, but let's make an effort at least [16:34] niemeyer: does that mean three of us will all be in the UK at once? woo! [16:34] nothing on my spam from niemeyer .... [16:41] rogpeppe: Unfortunately not.. William is back to Malta next week [16:42] negronjl: I really can't tell then.. maybe we should ask IS [16:42] niemeyer: I'll ask [16:46] negronjl: Thanks, please let me know.. curious about what could be going on as well [16:47] rt.admin.canonical.com #53190 [16:47] niemeyer: ^^ [17:01] negronjl: Don't have access to it, but thanks.. let's see what they find [17:10] i'm off to enjoy the sunshine [17:10] see y'all tomorrow [17:15] rogpeppe: Enjoy [21:15] hi davecheney. [21:15] howdy === meetingology` is now known as meetingology [22:53] davecheney: Morning [23:05] morning [23:18] davecheney: 181 » » panic(fmt.Sprintf("configuration was %T, expected %T", cfg, new( [23:18] providerConfig))) [23:19] davecheney: That's not necessary [23:19] davecheney: c, ok := cfg.(*providerConfig) => s/, ok// [23:19] davecheney: The compiler can do that for us [23:27] davecheney: Re-reviewed the branch, mentioned a couple of details, and LGTM [23:54] niemeyer: thanks, i'll finalise and submit later today [23:54] if you have time coudl you also take a look a the NewConfig banch [23:54] branch