| niemeyer | davecheney: :-) | 00:19 |
|---|---|---|
| niemeyer | davecheney: Are you using cobzr? | 00:19 |
| niemeyer | davecheney: It may help | 00:19 |
| niemeyer | davecheney: It's really boring to use GOPATH without it | 00:20 |
| niemeyer | Alright, calling a day I am | 00:33 |
| niemeyer | Have a good night/day all | 00:33 |
| davecheney | niemeyer: yes, alias bzr=cobzr | 00:34 |
| davecheney | will cobzr close (ie, remove from my local branch list) branches that have been submitted ? | 00:35 |
| TheMue | morning | 06:38 |
| * davecheney waves | 06:38 | |
| * TheMue waves back | 06:38 | |
| davecheney | i heard tell there is a pastebin for canonical | 06:38 |
| davecheney | the public one | 06:38 |
| TheMue | davArrived in the right timezone? ;) | 06:38 |
| davecheney | yesterday was not pretty | 06:39 |
| TheMue | davecheney: Yes | 06:39 |
| davecheney | walked around like a zombie til 5pm | 06:39 |
| davecheney | then gave in to the inevitable | 06:39 |
| TheMue | http://paste.ubuntu.com/ | 06:39 |
| davecheney | TheMue: http://paste.ubuntu.com/988455/ | 06:40 |
| TheMue | davecheney: Funnily this time I had almost no problems. But I slept a lot during flight. | 06:40 |
| davecheney | what do you think of that? | 06:40 |
| davecheney | the logic is, watch /environment | 06:40 |
| davecheney | get the *ConfigNode, pass config.Map() to this function, receive Environ | 06:41 |
| TheMue | davecheney: Loks straight. | 06:42 |
| TheMue | Looks | 06:43 |
| * davecheney shakes his fist at the interface{}'s being passed around everywhere | 07:18 | |
| davecheney | well, mainly inside environs/config.go | 07:19 |
| TheMue | davecheney: Hehe, indeed, anonymous interfaces are always some kind of double-edged. | 07:22 |
| davecheney | dummy.Open expect a schema.MapType, but ec2,Open expects a *providerConfig | 07:23 |
| davecheney | I can't see a way to reconcile the two | 07:24 |
| davecheney | apart from changing environProvider.ConfigCheck() to coerce everything to a map[string]interface{} | 07:24 |
| davecheney | ohh, it's actually worse than that | 07:26 |
| TheMue | davecheney: I hope Roger is around soon. This is his playground. | 07:31 |
| davecheney | OK: 6 passed | 07:37 |
| davecheney | i got it to pass, but it is really ugly | 07:37 |
| TheMue | davecheney: Now that it's working it's time to make it elegant. ;) | 07:47 |
| davecheney | in the face of interface{}, little can be done | 07:50 |
| davecheney | but I think I pushed some of the nastyness out of sight | 07:52 |
| davecheney | TheMue: https://codereview.appspot.com/6215045 | 07:54 |
| davecheney | just checking it over before i send it out | 07:55 |
| davecheney | halo rog | 08:07 |
| davecheney | i'm just finishing up | 08:07 |
| davecheney | check out https://codereview.appspot.com/6215045 | 08:07 |
| rog | davecheney: hi there | 08:07 |
| rog | davecheney: am very bleary! | 08:07 |
| davecheney | took far too long (read most the day) | 08:07 |
| davecheney | to produce that | 08:07 |
| * rog looks | 08:07 | |
| davecheney | but hopefully it's a faithful representation of what we discussed last week | 08:07 |
| rog | davecheney: cool. | 08:08 |
| rog | davecheney: what time of day is it for you? | 08:08 |
| davecheney | 18:06 | 08:08 |
| davecheney | so i'd better go and make the dinner | 08:08 |
| davecheney | and tackle the mountain of washing up that sam left for me | 08:08 |
| TheMue | rog: Heya | 08:09 |
| rog | davecheney: ok :-) | 08:09 |
| rog | TheMue: mornin' | 08:09 |
| TheMue | davecheney: You got my comment. Mostly looks good. | 08:09 |
| rog | davecheney: i thought we were going to use Setter/Getter or something like that | 08:10 |
| davecheney | Open can't take a getter, the value of attributes is provider specific | 08:12 |
| davecheney | it spent most the day bashing my head on that | 08:12 |
| davecheney | ok, going afk for a few hours at least | 08:12 |
| rog | davecheney: ok, have fun. | 08:12 |
| rog | davecheney: washing up, yeah! | 08:12 |
| rog | davecheney: BTW i was suggesting to pass a Getter to Check, not Open. | 08:13 |
| TheMue | rog: Too late. (lol) | 08:17 |
| TheMue | rog: Seen on the log that you yesterday asked for running Ubuntu in a VM. | 08:17 |
| rog | TheMue: yeah | 08:17 |
| rog | TheMue: was just wondering if my crash scenario was specific to me only... | 08:18 |
| TheMue | rog: Oh, tell me more. | 08:18 |
| rog | TheMue: ok, if you don't mind your VM crashing, try this: echo /dev/*/tun* | 08:19 |
| TheMue | rog: Maybe later on a copy. ;) So you play around with the tunneling? | 08:20 |
| rog | TheMue: yeah, but i couldn't get it working, and i don't know why. | 08:20 |
| rog | TheMue: that was on the plane. | 08:20 |
| TheMue | rog: That can't work. | 08:21 |
| rog | TheMue: what can't work? | 08:21 |
| TheMue | rog: Tunnels are below earth, not 10.000 feet above. (scnr) | 08:21 |
| rog | :-) | 08:21 |
| TheMue | rog: But what did you expect by echoing directly on the devices? | 08:22 |
| rog | TheMue: i expected it to tell me what files were in /dev | 08:22 |
| rog | TheMue: i ended up posting a stackoverflow question: http://stackoverflow.com/questions/10583601/how-should-the-tunattachfilter-ioctl-be-called | 08:23 |
| TheMue | rog: Never used echo for it, only ls. | 08:23 |
| rog | TheMue: you'd get the same behaviour if you passed the same argument to ls | 08:24 |
| rog | TheMue: echo is nice because it prints all the names on one line | 08:24 |
| TheMue | rog: attributes in config are always a map[string]interface{}? I already wondered about the usage of interface{} here. | 09:07 |
| rog | TheMue: they only happen to be a map[string]interface{} if the yaml is written correctly. | 09:08 |
| TheMue | rog: So I would define a type Attributes map[string]interface{} with setter/getter and Check(*EnvironChecker) (or something like that). | 09:08 |
| rog | actually.... | 09:08 |
| rog | i think they're usually map[interface{} | 09:08 |
| rog | ] interface{} | 09:09 |
| rog | TheMue: don't you like my Getter/Setter idea? | 09:09 |
| TheMue | rog: Could live with that too, even if it's very generic. | 09:09 |
| TheMue | rog: Get and Set on Checker? | 09:09 |
| rog | TheMue: the idea is that you should be able to pass a *ConfigNode to EnvironProvider.Check | 09:10 |
| rog | TheMue: you saw my comment, right? | 09:10 |
| TheMue | rog: Only a quick look so far. | 09:10 |
| rog | TheMue: https://codereview.appspot.com/6215045/diff/13/environs/open.go#newcode36 | 09:10 |
| TheMue | rog: So your idea is to pass anything where you can "get" a value by key from as an input to the checker? Am I right? | 09:13 |
| rog | TheMue: yes | 09:13 |
| TheMue | rog: Sounds good. | 09:13 |
| rog | TheMue: and it also works the other way around | 09:14 |
| TheMue | rog: Yes | 09:14 |
| rog | TheMue: an environ config can be saved directly to a config node | 09:14 |
| TheMue | rog: So if it later will be something else and not the config node it's no problem. | 09:14 |
| rog | TheMue: yes | 09:14 |
| TheMue | +1 | 09:14 |
| rog | cool | 09:15 |
| TheMue | rog: Got this one http://shop.canonical.com/product_info.php?products_id=708 at UDS. Now here in the cold and wet Germany it's really useful. | 09:17 |
| rog | TheMue: doesn't look like it'll keep out the rain much :-) | 09:18 |
| TheMue | rog: No, but it keeps warm. Thankfully there's no rain inside my house. ;) And it's dry enough for the way to the car. | 09:19 |
| rog | :-) | 09:19 |
| fwereade | TheMue, rog: I *did* sleep well last night but I'm feeling the aggregate effect of too many weird days... taking a swap day today | 09:58 |
| rog | fwereade: ok, good plan | 09:58 |
| rog | fwereade: enjoy the day! | 09:58 |
| TheMue | fwereade: OK, enjoy it. | 09:58 |
| fwereade | rog, cheers :) | 09:58 |
| fwereade | TheMue, cheers also :) | 09:58 |
| TheMue | ;) | 09:58 |
| === TheMue_ is now known as TheMue | ||
| === rog is now known as Guest16956 | ||
| === Guest16956 is now known as rogpeppe | ||
| niemeyer | Heya! | 13:51 |
| TheMue | niemeyer: Heya. | 13:59 |
| niemeyer | TheMue: How're things? | 14:15 |
| TheMue | niemeyer: Fine, just working on relations. And you? | 14:16 |
| rogpeppe | niemeyer: yo! | 14:17 |
| niemeyer | TheMue: I'm waking up after a rough night where the jetlag ruled out, and getting on some reviewing | 14:18 |
| niemeyer | rogpeppe: Heya! | 14:18 |
| TheMue | niemeyer: Yeah, adjusting the inner clock back is hard. And you've been there almost two weeks. | 14:19 |
| Aram | I have a 26 hour biological clock, it's terrible. | 14:20 |
| rogpeppe | niemeyer: https://codereview.appspot.com/6145043/ is feeling a bit neglected :-) | 14:20 |
| niemeyer | rogpeppe: The whole queue is feeling neglected | 14:21 |
| rogpeppe | niemeyer: i think that might be one of the older items... | 14:21 |
| niemeyer | rogpeppe: I'm sure some of them are older than the others :) | 14:22 |
| niemeyer | rogpeppe: My day will be pretty much just reviews today | 14:22 |
| niemeyer | Except for lunch and a meeting I have in about 1h | 14:23 |
| niemeyer | rogpeppe: Will do a quick pass on this one now.. hopefully we can get it in now | 14:24 |
| rogpeppe | niemeyer: thanks! | 14:24 |
| niemeyer | rogpeppe: version.ToolsPath makes no sense to me | 14:26 |
| rogpeppe | niemeyer: where do you think it should go? | 14:26 |
| rogpeppe | niemeyer: i was duplicating it all over the place | 14:26 |
| niemeyer | rogpeppe: If anywhere, this should live within environs.ToolsPath | 14:27 |
| rogpeppe | niemeyer: that could make sense. let me check. | 14:27 |
| niemeyer | rogpeppe: Although, maybe it should be a function instead, and let the implementation details off | 14:27 |
| niemeyer | rogpeppe: environs.GetTools(env) | 14:28 |
| niemeyer | Aram: Ouch :) | 14:30 |
| rogpeppe | niemeyer: i'm not sure that's right | 14:30 |
| rogpeppe | niemeyer: the tools path is independent of the provider | 14:30 |
| rogpeppe | niemeyer: i think | 14:30 |
| rogpeppe | niemeyer: otherwise we've documented the interface to PutFile wrong. | 14:31 |
| niemeyer | rogpeppe: Not sure I see what you mean.. environs is not environment-specific either | 14:31 |
| rogpeppe | niemeyer: ah, so you'd have environs.PutTools too? | 14:31 |
| Aram | niemeyer: yeah, basically only once every 13 days I wake up when I should. All the other days I feel jet lagged. I compensate with caffeine, heh. | 14:32 |
| Aram | maybe that makes it worse. | 14:32 |
| niemeyer | rogpeppe: Don't we have that already? | 14:32 |
| rogpeppe | niemeyer: UploadTools, yeah. | 14:33 |
| rogpeppe | niemeyer: but without ToolsPath, it's difficult to test that the correct file has been written, because we don't know its name. | 14:33 |
| niemeyer | Aram: I bet it does indeed :) | 14:33 |
| niemeyer | rogpeppe: We only have to know its name once, in a single test | 14:34 |
| niemeyer | rogpeppe: If UploadTools works as it should, everything is else may rely on that | 14:34 |
| niemeyer | rogpeppe: We can test that DownloadTools (?) gets the same content that UploadTools supposedly uploaded, for example | 14:35 |
| niemeyer | rogpeppe: We don't have to test the path for that | 14:35 |
| rogpeppe | niemeyer: i'm still not happy about cmd_test.go knowing about the underlying path name. | 14:35 |
| niemeyer | rogpeppe: I just pointed out that it doesn't have to..? | 14:36 |
| niemeyer | rogpeppe: I'm happy with PutTools and GetTools as well, btw | 14:36 |
| niemeyer | rogpeppe: Probably more sensible for GetFile/PutFile | 14:36 |
| rogpeppe | niemeyer: yeah, i tend to agree | 14:37 |
| rogpeppe | niemeyer: even though the flag is called --upload-tools | 14:37 |
| rogpeppe | maybe it might be better named --put-tools in fact | 14:37 |
| niemeyer | rogpeppe: Yeah, that's fine.. the language on the command line has to be more sensible for the user instead | 14:37 |
| niemeyer | rogpeppe: --upload-tools feels more clear in that sense | 14:37 |
| rogpeppe | niemeyer: ok | 14:37 |
| rogpeppe | niemeyer: ok, i'll see how it goes without ToolsPath | 14:38 |
| niemeyer | rogpeppe: Thanks.. I'll be here for about 20 mins more before lunch | 14:38 |
| rogpeppe | niemeyer: one thought: nothing is ever going to use GetTools except tests. | 14:41 |
| rogpeppe | niemeyer: hmm, update will, i suppose. | 14:42 |
| niemeyer | rogpeppe: Curious.. I wonder what's the purpose of uploading a file we never download :-) | 14:42 |
| rogpeppe | niemeyer: we use wget and tar... | 14:42 |
| niemeyer | rogpeppe: That's done for bootstrap only | 14:42 |
| rogpeppe | niemeyer: when else do we download tools? | 14:42 |
| rogpeppe | niemeyer: update will, i think, so i think it seems ok to me. | 14:43 |
| niemeyer | rogpeppe: Yep | 14:43 |
| niemeyer | rogpeppe: Whenever we have Go code running that wants to download tools | 14:43 |
| niemeyer | rogpeppe: Updating has to do that | 14:44 |
| rogpeppe | niemeyer: yeah | 14:44 |
| rogpeppe | niemeyer: i'll still need to verify against tar xz though | 14:44 |
| niemeyer | rogpeppe: Yeah, once, though | 14:44 |
| rogpeppe | oh darn | 14:48 |
| rogpeppe | niemeyer: GetTools won't work without support for ListFiles in Environ | 14:48 |
| rogpeppe | niemeyer: and even that's not quite there, as we've got a two-tier system. | 14:48 |
| niemeyer | rogpeppe: I don't understand how we can have ToolsPath in version and can't have a function instead | 14:50 |
| rogpeppe | niemeyer: because GetTools doesn't get a particular version - it searches for the latest appropriate version. | 14:50 |
| niemeyer | rogpeppe: So ToolsPath is equally bogus | 14:50 |
| rogpeppe | niemeyer: ToolsPath gives the path for the *current* tools. that's why i put it in version. | 14:50 |
| niemeyer | rogpeppe: Ugh.. that's not great | 14:51 |
| niemeyer | rogpeppe: Let's have ListFiles in the environment then, and have GetTools | 14:51 |
| rogpeppe | niemeyer: we'll need two ListFiles-type functions (or one with a bool arg) because we need to be able to look in private storage first before failing over to public storage. | 14:52 |
| rogpeppe | niemeyer: perhaps ListFiles(private bool) ([]string, error) | 14:53 |
| niemeyer | rogpeppe: That sounds like yet another great reason to have GetTools.. this is unrelated to ListFiles in the environment | 14:53 |
| rogpeppe | niemeyer: really? | 14:53 |
| rogpeppe | niemeyer: which bucket would ListFiles list? | 14:53 |
| niemeyer | rogpeppe: Well, maybe it could be.. thinking | 14:53 |
| niemeyer | rogpeppe: ListFiles should list the files in the environment | 14:54 |
| niemeyer | rogpeppe: That has a very well defined meaning | 14:54 |
| rogpeppe | niemeyer: so how do we list the files in the public bucket so we can use publicly uploaded tools? | 14:54 |
| niemeyer | rogpeppe: Which is in theory unrelated to anything about how-do-I-get-public-tools | 14:54 |
| niemeyer | rogpeppe: That's a good question for which we need a good answer.. it doesn't invalidate the former point, though | 14:55 |
| rogpeppe | niemeyer: the environment knows about both, so i'd put that logic into the environment. if it's not in the environment, then we need some way of extracting info about the public bucket from it | 14:55 |
| rogpeppe | s/i'd/i/ | 14:56 |
| niemeyer | rogpeppe: Please explain "the environment knows about both" | 14:56 |
| rogpeppe | niemeyer: the names for both the private and public buckets are stored in environments.yaml | 14:56 |
| rogpeppe | niemeyer: and they're environment-specific | 14:57 |
| niemeyer | rogpeppe: You're putting statements as if they were true as you go, but it feels to me like the implementation of these details is actually still undefined | 14:57 |
| rogpeppe | niemeyer: ok. i'm happy to refactor. | 14:58 |
| niemeyer | rogpeppe: It is not true that the public files are environment-specific, for instance | 14:58 |
| rogpeppe | niemeyer: i'm not sure how we'd specify mutable storage in a provider-independent way though. | 14:58 |
| niemeyer | rogpeppe: All the environments for a given provider, or even for multiple providers, may share files | 14:59 |
| rogpeppe | niemeyer: oh, is the list-bucket functionality provider-independent? | 14:59 |
| niemeyer | rogpeppe: It is also not necessarily true that they are stored in environments.yaml either | 14:59 |
| niemeyer | rogpeppe: Since we'll have defaults | 14:59 |
| niemeyer | rogpeppe: It may be.. and it doesn't even have to be a bucket, for example | 15:00 |
| rogpeppe | niemeyer: what we need is some generic "container-like" functionality, i think | 15:00 |
| rogpeppe | niemeyer: if we want to go in this direction | 15:01 |
| niemeyer | rogpeppe: I think we can actually have an interface that defines a public-files thingy (name to be defined), and have a HTTP(S) consumer implementation for that | 15:01 |
| niemeyer | rogpeppe: I *suspect* we can use that single implementation with every provider we know about so far | 15:02 |
| * rogpeppe doesn't know about anything other than s3 | 15:02 | |
| niemeyer | rogpeppe: Then, we can have a env.PublicFilesThingy() or similar | 15:02 |
| niemeyer | rogpeppe: Which in pretty much all cases does | 15:03 |
| rogpeppe | niemeyer: and PrivateFilesThing() ? | 15:03 |
| niemeyer | rogpeppe: I suspect the env itself is a PrivateFilesThing | 15:03 |
| rogpeppe | ew | 15:03 |
| rogpeppe | niemeyer: that seems a little icky | 15:04 |
| rogpeppe | niemeyer: i'm not sure why PublicFiles and PrivateFiles wouldn't be symmetrical | 15:05 |
| niemeyer | rogpeppe: env.PublicFilesThingy() will return TheBasicHTTPPublicFilesThingy(defaultURL or configURL) for pretty much all providers | 15:05 |
| niemeyer | rogpeppe: Because they are not in real life.. the environment manages storage of its own files.. the public files is managed by someone else | 15:05 |
| niemeyer | rogpeppe: There's nothing icky about that to me | 15:05 |
| niemeyer | rogpeppe: Although, I'm fine to have PrivateFilesThingy if you prefer that | 15:06 |
| rogpeppe | niemeyer: i'll think about it. | 15:06 |
| niemeyer | rogpeppe: It sounds sane to me as well | 15:06 |
| rogpeppe | Environ.Files vs Environ.PublicFiles ? | 15:06 |
| rogpeppe | niemeyer: then the file interface can be simply be: interface {Put(...) error; Get(...) error; List( ...) ([]string, error)} | 15:07 |
| rogpeppe | niemeyer: because we won't need to disambiguate | 15:07 |
| niemeyer | rogpeppe: I'm happy with that.. feels very clean | 15:08 |
| rogpeppe | niemeyer: i'll see how it looks | 15:08 |
| niemeyer | rogpeppe: Happy with PrivateFilesThing too | 15:08 |
| niemeyer | rogpeppe: Btw, we need a name :) | 15:08 |
| niemeyer | rogpeppe: I'll have lunch, and try to come up with some suggestions | 15:08 |
| rogpeppe | niemeyer: Storage? | 15:08 |
| rogpeppe | niemeyer: ok, enjoy | 15:08 |
| rogpeppe | ! | 15:08 |
| niemeyer | rogpeppe: Sounds great | 15:09 |
| * niemeyer => lunch | 15:09 | |
| * niemeyer_ is back | 16:13 | |
| niemeyer_ | rogpeppe: How does it feel? | 16:13 |
| rogpeppe | niemeyer_: it's looking quite nice | 16:14 |
| rogpeppe | niemeyer_: http://paste.ubuntu.com/989159/ | 16:14 |
| rogpeppe | niemeyer_: it feels like another piece of the puzzle has dropped into place | 16:14 |
| rogpeppe | niemeyer_: what do you think? | 16:16 |
| * niemeyer_ reads | 16:18 | |
| niemeyer_ | rogpeppe: Looks very good indeed | 16:19 |
| niemeyer_ | rogpeppe: A couple of suggestions: | 16:19 |
| rogpeppe | niemeyer_: cool. | 16:19 |
| niemeyer_ | rogpeppe: Let's not get into the S3 prefix madness | 16:19 |
| niemeyer_ | rogpeppe: Let's call it a dir | 16:19 |
| rogpeppe | niemeyer_: ok. i started with that. | 16:20 |
| rogpeppe | niemeyer_: but it's hard to do proper dirs with s3 | 16:20 |
| niemeyer_ | rogpeppe: I thougth it was trivial? | 16:20 |
| rogpeppe | niemeyer_: List(prefix="e", separator="/") will return "elephant" AFAIR | 16:20 |
| rogpeppe | (if "elephant" exists, of course) | 16:21 |
| niemeyer_ | rogpeppe: What will "e/" return? | 16:21 |
| rogpeppe | niemeyer_: good point - just always append a / | 16:21 |
| niemeyer_ | rogpeppe: The only reason to not do that would be efficiency I guess | 16:22 |
| niemeyer_ | rogpeppe: In the sense we could list precisely what we want, if possible | 16:22 |
| niemeyer_ | rogpeppe: This might be enough of a reason to implement the prefix-based stuff | 16:22 |
| rogpeppe | niemeyer_: if we know precisely what we want, then why are we doing a LIST? | 16:22 |
| niemeyer_ | rogpeppe: "foo-* | 16:22 |
| rogpeppe | niemeyer_: i don't think we should worry. | 16:23 |
| rogpeppe | niemeyer_: we're not going to have *that* many versions. | 16:23 |
| rogpeppe | niemeyer_: and if we do, we can partition the dirs | 16:23 |
| niemeyer_ | rogpeppe: It may be useful to avoid returning 100s of tools from the public storage, actually | 16:23 |
| niemeyer_ | rogpeppe: tools-<major>.* | 16:23 |
| rogpeppe | niemeyer_: in which case, why not make tools-<major> a directory? | 16:24 |
| rogpeppe | niemeyer_: as you said, the S3 prefix stuff is madness | 16:24 |
| niemeyer_ | rogpeppe: Well, we can make it saner.. we'd not support varied separators, or distinguish common prefixes in separate lists | 16:25 |
| rogpeppe | niemeyer_: not quite whether to go for "/" or "" as the root directory. | 16:25 |
| rogpeppe | niemeyer_: i don't see the need for the abstraction - you've persuaded me. prefix might not be as easy to implement in other providers | 16:25 |
| rogpeppe | niemeyer_: directories are sufficient | 16:25 |
| niemeyer_ | rogpeppe: I can't see how that would possibly be the case | 16:25 |
| rogpeppe | niemeyer_: if the provider actually uses a directory-like structure, prefix matching will be harder to do efficiently. | 16:26 |
| rogpeppe | niemeyer_: (we'd need to do it client-side) | 16:26 |
| niemeyer_ | rogpeppe: Anywhere we can list a directory, we can filter it out with three lines (for+if+append) | 16:27 |
| rogpeppe | niemeyer_: exactly. but then we'll be getting the inefficiency we're trying to remove by using the prefix abstraction. | 16:27 |
| rogpeppe | niemeyer_: and using a directory will be the same efficiency in both cases. | 16:27 |
| niemeyer_ | rogpeppe: We'll be getting the inefficiency you're suggesting we'd have all the time | 16:27 |
| niemeyer_ | rogpeppe: Yes, the same *inefficiency* in both cases.. | 16:28 |
| rogpeppe | niemeyer_: not if we store tools as tools-$MAJOR/$MINOR-$PATCH.tgz | 16:28 |
| niemeyer_ | rogpeppe: Which means filtering it out by hand, client side, in both cases.. | 16:28 |
| niemeyer_ | rogpeppe: Not sure about what you're arguing for, to be honest | 16:28 |
| rogpeppe | the above | 16:28 |
| rogpeppe | niemeyer_: note the "/" between major and minor versions | 16:29 |
| rogpeppe | niemeyer_: then we can just List("tools-$MAJOR") | 16:29 |
| niemeyer_ | rogpeppe: Ok, but this naming isn't great | 16:29 |
| rogpeppe | niemeyer_: no? | 16:30 |
| niemeyer_ | rogpeppe: "tools/$MAJOR/tools-$MAJOR.$MINOR.$PATCH.tar.gz" then | 16:30 |
| rogpeppe | niemeyer_: why does it need to have the same pattern on the provider as on disk? | 16:30 |
| niemeyer_ | rogpeppe: Because I don't want to wget 1.2.tar.gz | 16:30 |
| rogpeppe | wget tools/2/1.2.tgz seems ok to me. | 16:31 |
| niemeyer_ | rogpeppe: Sorry, 1.2.tar.gz isn't a proper file name | 16:31 |
| rogpeppe | niemeyer_: but anyway, all this is premature optimisation - we can change it all later trivially. | 16:32 |
| rogpeppe | niemeyer_: i think we've shown that we don't need prefix matching to do this efficiently | 16:32 |
| rogpeppe | niemeyer_: and i'm ok with the redundant major version too | 16:32 |
| rogpeppe | niemeyer_: by the time we've got hundreds of versions, we'll have upgrade and we can change the schema on the fly :-) | 16:33 |
| niemeyer_ | rogpeppe: No, let's do it now please.. the need is obvious, the implementation trivial | 16:33 |
| niemeyer_ | rogpeppe: You can pick either.. tools/tools-$MAJOR.$MINOR.PATCH.tar.gz + prefix <OR> tools/$MAJOR/tools-$MAJOR.$MINOR.$PATCH.tar.gz + dir | 16:34 |
| rogpeppe | niemeyer_: ok. | 16:34 |
| rogpeppe | niemeyer_: i vote for the latter. | 16:34 |
| niemeyer_ | rogpeppe: Cool, let's go with it then | 16:35 |
| rogpeppe | niemeyer_: any other suggestions? | 16:37 |
| === niemeyer__ is now known as niemeyer | ||
| rogpeppe | right, off for the day. see y'all tomorrow. | 17:01 |
| niemeyer | What the heck | 17:05 |
| niemeyer | Google+ Hangout has f* up my connection permanently.. | 17:06 |
| niemeyer | I had to reboot and reconnect the router.. | 17:06 |
| niemeyer | I wonder if the Hangout servers are DoSing me somehow | 17:07 |
| Daviey | I wonder if he had the 'DoS me' option enabled in Advance pref's? | 17:10 |
| ahasenack | hi guys, niemeyer tells me his internet is down for good | 17:20 |
| ahasenack | hazmat, jimbaker, others: ^^^ | 17:21 |
| hazmat | ahasenack, thanks for relaying | 17:22 |
| ahasenack | hazmat: 3g is also down, not just adsl, so it must be something more serious in that region | 17:22 |
| hazmat | indeed, that's uncommon | 17:23 |
| jimbaker | interesting | 17:23 |
| niemeyer | Okay | 17:24 |
| niemeyer | Something funky is happening with the local ISPs | 17:24 |
| niemeyer | Managed to get in via 3G now | 17:24 |
| ahasenack | maybe everybody is playing diablo 3 ;) | 17:25 |
| niemeyer | ahasenack: That might explain it | 17:25 |
| TheMue | niemeyer: Who may be interested in a possible bug in relation.py in the current implementation? | 17:27 |
| niemeyer | TheMue: Ben, Jim, or Kapil | 17:27 |
| niemeyer | TheMue: Everybody would be *interested* though, but one of them will have to look at the code | 17:27 |
| TheMue | niemeyer: I'm not sure if it's a bug, but I think it's worth a look. | 17:28 |
| TheMue | jimbaker: Still around? | 17:28 |
| hazmat | TheMue, what's up? | 17:31 |
| TheMue | hazmat: Ah, heya. | 17:32 |
| TheMue | hazmat: Please take a look at relation.py at line 91. | 17:32 |
| hazmat | TheMue, yeah.. thats suspect its only checking one endpoint | 17:34 |
| TheMue | hazmat: I think service_id has to be service_relation.internal_service_id(). | 17:34 |
| TheMue | hazmat: Yep, that's what I thought. Especially inside the loop. | 17:34 |
| hazmat | TheMue, it should be service_relation.service_id | 17:35 |
| hazmat | er. internal_service_id | 17:35 |
| TheMue | hazmat: The service id is stored in _service_id. So you have to use the accessor. | 17:35 |
| TheMue | hazmat: Yeah | 17:35 |
| jimbaker | TheMue, still around, but looks like hazmat has got you covered | 17:36 |
| TheMue | jimbaker: Heya. Yes, hes has. ;) Thx. | 17:36 |
| hazmat | bzr blame suggests otherwise ;-) | 17:37 |
| hazmat | jimbaker, trivial http://paste.ubuntu.com/989322/ | 17:38 |
| jimbaker | hazmat, looks like a check to ensure we are not seeing inconsistent topology. iirc this was a bug fix to fix looping tests | 17:40 |
| hazmat | jimbaker, it looks it was part of the initial impl | 17:40 |
| hazmat | jimbaker, updated trivial w/ test http://paste.ubuntu.com/989333/ | 17:41 |
| hazmat | jimbaker, okay.. given lack of objections.. adding to trunk.. the failure without the change is InternalTopo..Error instead of StateChanged | 17:44 |
| jimbaker | hazmat, ok, got context - it just looked like all the other checks we have added to avoid InternalTopologyError, so along the same lines | 17:44 |
| jimbaker | hazmat, +1 | 17:44 |
| hazmat | thanks TheMue | 17:46 |
| niemeyer | rogpeppe: ping | 17:47 |
| TheMue | hazmat: np, happy to help | 17:48 |
| niemeyer | mthaddon: ping | 18:08 |
| TheMue | So, I'm off. Good night. | 19:03 |
| * hazmat meanders off for food | 19:06 | |
| flaviamissi | do you guys have any intention of implementing an api for juju? | 20:39 |
| hazmat | flaviamissi, definitely | 20:58 |
| hazmat | flaviamissi, there's a very rough draft extant in http://bazaar.launchpad.net/~hazmat/juju/rest-api-spec/files/head:/source/drafts/ | 21:12 |
| flaviamissi | hazmat: great! it would be very useful, I'll take a look at it, maybe I can help on that | 21:33 |
| hazmat | flaviamissi, great, comments welcome, its basically in three parts, a REST api, an HTTP command api corresponding to the CLI, and websocket notification mechanism. | 21:34 |
| flaviamissi | hazmat: yeah, I'm reading the spec now, is anyone working on that? | 21:37 |
| hazmat | flaviamissi, there's an experimental branch that someone through together, but its probably not going in as is. there's some drive to have this done for 12.10 to support other activities though. | 21:39 |
| hazmat | flaviamissi, the experiment is attached to https://bugs.launchpad.net/juju/+bug/804284 | 21:40 |
| flaviamissi | hazmat: great, thank you | 21:41 |
| hazmat | flaviamissi, that's a client side rest api though.. | 21:41 |
| hazmat | ie. its not deployed as part of juju | 21:42 |
| flaviamissi | hazmat: hmm... but this is the intention? I mean, the api won't be deployed as part of juju? | 21:43 |
| hazmat | flaviamissi, yes that's the goal.. like i said that branch is experimental.. its not clear its the basis for an official rest api yet | 21:43 |
| flaviamissi | hazmat: ok | 21:43 |
| flaviamissi | hazmat: that's for the python version, right? | 21:44 |
| hazmat | flaviamissi, it is | 21:44 |
| hazmat | flaviamissi, at this point feedback on the spec would be the most helpful, ie. making sure we're covering appropriate use cases and functionality | 21:45 |
| flaviamissi | hazmat: I can do that | 21:45 |
| hazmat | negronjl, where would you want to take jrapi? | 21:45 |
| davecheney | 'sup 'sup | 21:48 |
| negronjl | hazmat: what do you mean ? | 21:52 |
| negronjl | hazmat: If it serves a purpose, let's use it. If anyone comes up with something better, we can use that ... | 21:54 |
| negronjl | hazmat: but, until something better shows up, I am playing with jrapi | 21:54 |
| hazmat | negronjl, sure, but trying to figure out where it goes from here.. ie do we evolve it add tests, match it to spec and try to merge it, or do we end up with a separate official project that gets merged. | 21:56 |
| flaviamissi | hazmat: the spec looks really good, looks like all cases are covered, but I'll take another look later | 21:57 |
| === niemeyer__ is now known as niemeyer | ||
| niemeyer | flaviamissi: There was some mixup there.. | 22:01 |
| niemeyer | <flaviamissi> hazmat: hmm... but this is the intention? I mean, the api won't be deployed as part of juju? | 22:02 |
| niemeyer | <hazmat> flaviamissi, yes that's the goal.. like i said that branch is experimental.. its not clear its the basis for an official rest api yet | 22:02 |
| niemeyer | flaviamissi: hazmat intended to say that, yes the goal is to have the API deployed as part of juju | 22:02 |
| flaviamissi | niemeyer: hmmm | 22:03 |
| flaviamissi | niemeyer: that makes more sense to me :) | 22:03 |
| niemeyer | flaviamissi: It's one of the next major features that will come | 22:03 |
| niemeyer | flaviamissi: After the port is done | 22:03 |
| flaviamissi | niemeyer: so, the plan is not have the api for the python version? | 22:04 |
| niemeyer | flaviamissi: Yes, Python is in maintenance mode, and we're working on getting the port done in time for 12.10 | 22:05 |
| flaviamissi | niemeyer: great | 22:05 |
| flaviamissi | I'm leaving, we chat more later | 22:06 |
| * niemeyer => dinner too | 22:07 | |
| hazmat | niemeyer, doh.. yeah.. totally it should be deployed as part of juju | 22:11 |
| hazmat | that was unclear | 22:11 |
| hazmat | async response communication fail | 22:11 |
| negronjl | hazmat: Can you make the spec available to me? | 22:26 |
| negronjl | hazmat: I'm up for using this API of course but, the final decision on that I believe it to be yours | 22:26 |
| hazmat | negronjl, its publicly pushed to docs and editable by charmers | 22:27 |
| hazmat | negronjl, http://bazaar.launchpad.net/~hazmat/juju/rest-api-spec/files/head:/source/drafts/ | 22:27 |
| negronjl | hazmat: I'm up for modifying/merging jrapi | 22:27 |
| hazmat | negronjl, testing would be key | 22:27 |
| negronjl | hazmat: I agree on testing... I can start adding some testing to the project as well... Let me take a moment to read the spec in full... | 22:28 |
| hazmat | negronjl, i am as well.. realistically this month i don't have much spare time, i'd like to get the spec approved and rolling though before then. | 22:28 |
| negronjl | hazmat: ok. Not sure what the next step on this is .... Has the spec been approved by the powers that be ? | 22:29 |
| hazmat | negronjl, no.. its in decent shape, but needs some polish | 22:30 |
| hazmat | and some parts need to be flushed out a lot more | 22:30 |
| hazmat | like auth | 22:30 |
| negronjl | hazmat: I see. Well. I want to take some time to read the specs. This will give me more information to come up with more intelligent questions. | 22:31 |
| negronjl | hazmat: I can get back to you with some feedback tomorrow. Does that work for you ? | 22:31 |
| hazmat | negronjl, sounds good | 22:31 |
| SpamapS | jimbaker: can you please reference bug numbers on all commits to trunk! | 23:29 |
| SpamapS | jimbaker: I need a bug report for every change or we cannot SRU to 12.04.1 | 23:30 |
| SpamapS | jimbaker: trivials included, though r536 actually doesn't look trivial *at all* | 23:31 |
| hazmat | SpamapS, its like 5 lines | 23:52 |
| SpamapS | its not about the size | 23:52 |
| SpamapS | I need to understand why its ok to update the stable release with it. | 23:52 |
| hazmat | SpamapS, its nothing something thats needed in practice, it still raises an error in either csae | 23:52 |
| hazmat | just cleans up the error to something intended for the user instead of an internal error | 23:52 |
| SpamapS | we have to justify every change | 23:52 |
| SpamapS | so, Low priority change, that was not on the galapagos list | 23:53 |
| SpamapS | I think I need to fork a 12.04.1 branch and only pull in High bug fixes | 23:53 |
| hazmat | SpamapS, indeed it came out of of a porting comment | 23:53 |
| hazmat | from frank while looking at the relation code | 23:53 |
| SpamapS | I'm going to be pushing 535 into precise-proposed tomorrow | 23:53 |
| hazmat | SpamapS, i can back it out.. if need be | 23:53 |
| hazmat | just put it on the unfettered branch | 23:54 |
| SpamapS | Then we have to verify all 4 bugs fixed then it goes to precise-updates. | 23:54 |
| SpamapS | I plan to keep trickling in the galapagos bugs as they're comitted | 23:54 |
| SpamapS | hazmat: if it has a reasonable test case, impact statement, and regression potential is Low, then we can leave it | 23:54 |
| SpamapS | just document it with a bug | 23:54 |
| hazmat | all those things are true | 23:54 |
| * hazmat adds a bugs | 23:55 | |
| SpamapS | yeah I figure as much. Just have no way of knowing that w/o a bug # | 23:55 |
| SpamapS | We can go nuts w/ commits again after June 6, but for just this month.. lets fix bugs. :) | 23:55 |
| SpamapS | hazmat: I want to get acls in. Can we do that without breaking the world? | 23:55 |
| SpamapS | crap its 45 minutes later than I wanted to EOD today.. :-P | 23:56 |
| hazmat | SpamapS, define breaking the world ;-) | 23:56 |
| hazmat | hmmm | 23:56 |
| hazmat | SpamapS, actually we could | 23:56 |
| hazmat | SpamapS, its done at the connection level, so we can detect support and activate it without too much trouble. | 23:57 |
| hazmat | just switch the security policy from acl to the noop | 23:57 |
| SpamapS | hazmat: I think all we need to do is make the secret arg to the agents optional | 23:57 |
| hazmat | ah... mixed mode envs | 23:57 |
| SpamapS | hazmat: existing bootstrapped envs will just work w/o acls | 23:57 |
| hazmat | newer client with older env isn't too bad | 23:58 |
| hazmat | newer agent with older env could work | 23:58 |
| SpamapS | and we'll make a note that if you upgrade the provisioning agent, you have to re-bootstrap or something | 23:58 |
| hazmat | it would apply generically to all of them | 23:58 |
| hazmat | er... all agents | 23:58 |
| SpamapS | I don't want to support mixed mode | 23:59 |
| SpamapS | I just want to make sure existing bootstrapped envs with juju-origin: distro can continue to add-unit and deploy | 23:59 |
| hazmat | well then we need the upgrade/consistent version stuff that rog is doing on the go version | 23:59 |
| hazmat | SpamapS, that is mixed mode | 23:59 |
| SpamapS | um, ok | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!