[02:04] How goes? [05:32] morning wallyworld_, I hope your weekend went well. [05:35] jam: hello, very busy but good [06:29] Anybody about that can give me a quick update on openstack progress, subordinates, or TLS? I'm putting together a status update for internal folks, but also thinking about sending out e-mail with some status info to the list. [06:30] I seem to have found a time where all the core guys are not online... Bully for me! [06:46] ok, signing out for a bit, back later this evening when EU folks are up ;) [07:13] Morning. [08:29] morning all [08:29] fwereade: have a nice holiday? [08:30] rogpeppe, thank you, yes :) [08:30] rogpeppe, fwereade: Hiya. [08:30] fwereade: i got TLS working live BTW [08:30] rogpeppe, ate in cafes, went to beach, the usual late-november things :) [08:30] rogpeppe, awesome! [08:30] TheMue, morning [08:31] fwereade: the late november thing here currently is sheltering from the rain and squelching through mud [08:31] fwereade: Walking to the beach is definitely a benefit of your home town. Here it is too windy and cold. [08:31] rogpeppe: +1 [08:31] rogpeppe, TheMue: :) [08:32] * TheMue had some nice malts on Friday, warming from inside. [08:39] whoops, need to pop out a mo [08:39] (I *think* I just wrote something nice...) [09:08] yay! all live tests pass with TLS enabled... [09:09] rogpeppe: Cheers. [09:20] rogpeppe, cool! [09:21] fwereade: of course, it'll probably take weeks to get the CLs through :-| [09:21] fwereade: there's one little thing i encountered that i'm not sure of the best way to fix [09:21] rogpeppe, quite, but this is a significant milestone nonetheless [09:21] rogpeppe, oh yes? [09:22] fwereade: when you first make the connection to the state, you might succeed in connecting before the initialisation process has set up the initial password [09:22] fwereade: so you can get an "unauthorized" error [09:23] rogpeppe, ha, but usually unauthorized means that something's really wrong [09:23] fwereade: there's only a very short time window for it to happen [09:23] fwereade: yeah [09:23] rogpeppe, grar [09:23] fwereade: so i'm wondering if we should only open the mgo port after bootstrap-state has completed [09:23] rogpeppe, +1 [09:24] fwereade: that involves a few icky special-case hacks though [09:24] fwereade: for instance, i think we'd need a new entry point in Environ [09:25] fwereade: and... oh bugger, we can't do it [09:25] rogpeppe, what if we were to bunch all the mgo setup stuff up as a Stater task? [09:25] fwereade: we can't change ports [09:25] fwereade: before the first client connection [09:25] rogpeppe, oh ok [09:25] fwereade: because we haven't got the enviroment credentials yet [09:26] fwereade: there's another possibility actually [09:26] fwereade: and maybe it's not a bad one, as we're going to be doing something similar later with the API [09:26] fwereade: we could start a proxy process [09:26] fwereade: that just port-forwards [09:27] fwereade: and start *that* after bootstrap-state has completed. [09:27] rogpeppe, sounds very sane to me [09:28] fwereade: i think i'll leave it as a possibility for the moment - the retry logic is sufficient for the time being. [09:28] rogpeppe, cool [09:28] Greetings from the opposite side of the world from my normal life [09:29] mramm: yo! [09:29] I'm exactly 12 hours off normal schedule [09:29] mramm: where are you? [09:29] so, instead of 1, 2, and 4 pm meetings [09:29] I have midnight through four in the morning meetings :) [09:29] Thailand [09:29] mramm: for work or play? [09:29] visiting friends of my mom, and hanging out on the beach [09:29] mramm: very nice! [09:30] mramm: temperature? [09:30] I also bought a suit or two for work [09:30] hot [09:30] ;) [09:30] * rogpeppe is jealous [09:30] * rogpeppe as he hears the rain drumming outside [09:30] mramm: you might be interested to know i got all the TLS stuff working. [09:31] about 32 degrees [09:31] and that's because it has cooled off a bit since yesterday [09:32] mramm: nice. not *too* ridiculous [09:32] right [09:32] it has rained every day [09:32] but not for too long [09:32] and warm rain [09:32] mramm: i hope you've been taking full advantage of the local cuising [09:32] cuisine [09:32] so, today I'm working so that I can be ready for all those late night meetings [09:32] yea, I love me some thai food [09:33] got some basil thai fried rice from a street vendor for lunch [09:33] 40 baht ($1.20) [09:33] and it was delicious [09:34] anyway I'll be updating a few of the existing briefs, and adding a new one for API stuff [09:35] and I also created a new status report doc, so that I can pull from it to give big Mark updates on a regular basis [09:40] davecheney: yo! [09:40] rogpeppe: hey [09:40] davecheney: since i'm telling everyone... i got TLS working. [09:43] rogpeppe: congratulations!! [09:47] davecheney: interesting test failure you saw last night [09:48] davecheney: i think we should probably never rely on error messages from go [10:19] *: https://codereview.appspot.com/6853075/ likes another review. [10:21] fwereade: I somehow have a problem changing the original LXC configuration for testing. A possible solution may be a kind of chroot() and have an own /etc directory. But I'm not sure. Any other good idea is welcome. [10:22] TheMue, hum: is it possible to just make the path configurable and settable for the tests? [10:22] TheMue, much like the charm stor url in juju-core/charm IIRC [10:23] fwereade: Yeah, should be possible. Good idea. [10:31] dimitern, etc: how are things going on the provider front? [10:32] mramm: we're into refactoring the POC client code and writing test services (doubles of openstack api subset we're implementing) [10:33] cool [10:33] mramm: we have identity auth service + client code mostly done, and the nova and swift packages taking shape [10:33] nice [10:33] mramm: we also have a complete stub openstack provider ready in juju-core [10:33] awesome [10:34] only needs its actual "meat" over the bones [10:35] dimitern, also known as the code that actually does stuff :) [10:35] morning dimitern [10:37] jam, mgz: morning [10:54] jam, mgz: Morning [10:54] jam, mgz: what's the story with goose? is it going to start with merges from scratch again, or are we moving on from its current state? [10:55] jam, mgz, dimitern: morning, BTW! [10:56] rogpeppe: morning! well done for the TLS! :) [10:56] dimitern: thanks. we'll see how long it takes to land :-) [10:56] dimitern: at least i can see the light at the end of the tunnel... [10:58] rogpeppe: moving on from the current state [10:58] jam: ok, there are a few comments i'd like to make at some point, if that's ok [10:58] rogpeppe: silence! the code is perfect as is, and I will hear no dissent. [10:59] * rogpeppe mumbles [10:59] rogpeppe: I would be happy to get feedback. [10:59] * rogpeppe feels the lack of a codereview CL to click on :-) [11:00] rogpeppe: can you propose the code against a blank tree? [11:00] I think reitveld just works from a patch anyway. [11:00] (diff) [11:00] bzr diff -r 0..-1 would give it to you [11:00] jam: yeah, i'll give that a go [11:02] the puns! the puns! [11:04] fwereade: Done, thanks for the good hint. [11:04] alrght everybody I'll be back in a few hours. Going to get some food and rest up for tonight's marathon of meetings starting at midnight. [11:06] Good morning jujuers [11:07] niemeyer: yo! [11:07] rogpeppe: Hey man, how was the weekend? [11:08] niemeyer: morning :-) [11:08] niemeyer: great. i did a fun gig in St Andrews, and spent the train journey up there getting TLS working [11:08] niemeyer: which it now does, all live tests pass [11:08] rogpeppe: Ohhh, sweet [11:09] fss: Heya [11:09] niemeyer: yesterday I tried go version [11:10] niemeyer: good morning! [11:10] mramm: Heya, how were holidays? [11:10] fss: Nice, how was it? [11:11] niemeyer: looks neat :-) I'm glad most of proxy stuff worked because go's http client supports http_proxy and https_proxy [11:11] niemeyer: good. I have another week here on the beach. [11:11] niemeyer: Hiya [11:12] niemeyer: but am working a bit, just to stay on top of meetings and whatnot [11:12] mramm: Oh, so you're still mostly off this week? [11:12] yea [11:12] TheMue: Heya [11:12] mramm: Cool [11:12] today I'm working all day [11:12] fss: So did it all work? [11:13] early lunch, bbiab [11:13] mramm: How was the 6AM meeting? :-) [11:13] heya niemeyer [11:13] fwereade: Heya [11:13] niemeyer: almost [11:13] niemeyer: it doesn't work in the agent, because it would need to be exported in the upstart config file (using env) [11:14] niemeyer: I don't know if there is another way [11:14] niemeyer: (regarding http_proxy and https_proxy env vars) [11:14] fss: Ah, I see [11:14] jam: https://codereview.appspot.com/6844087 [11:15] niemeyer: which one? I'm on UTC/GMT +7 hours [11:15] mramm: The one 3h ago [11:15] rogpeppe: so that looks like it worked, but did it announce itself to anyone to actually follow it? [11:15] jam: nope [11:15] niemeyer: interesting, that wasn't on my calendar [11:15] jam: or... i dunno [11:15] I do have one for midnight tonight, and then another at 1am ;) [11:15] jam: probably not [11:16] jam: but we can advertise it if we like [11:16] rogpeppe: well, the big thing is that when you actually make comments, I would like to see them. [11:16] mramm: Hmm.. I think I'm on crack.. I see it's now scheduled to 17 UTC [11:17] niemeyer: we'd like to help getting it to work on sa-east-1, terminate-machine, destroy-service, vpc and proxy (our scenario) [11:17] niemeyer: no worries we all hit the crack a little bit too hard sometimes ;) [11:18] mramm: 1AM? Ugh [11:18] jam: if you comment on the CL, you'll see any further comments [11:18] fss: The proposal of a sprint is still up [11:18] rogpeppe: which is... a bit non-ideal, but what I just did. [11:21] niemeyer: nice, next friday is our deadline for getting tsuru working in vpc, so I will keep working in the python fork today and tomorrow, and them I will start helping out go version [11:21] niemeyer: That's what I get for going to vacation 12 hours removed from my normal tz! [11:23] mramm: Yeah, a bit intense :) [11:23] mramm: Well, to be honest though, that's what you get for *working* during vacation :-) [11:24] fss: The proposal won't be up for much longer, though.. if you're actually interested, we have to sort that out today or tomorrow [11:24] fss: Otherwise we'll be doing it remotely, which is no big deal, but will take a bit longer [11:26] niemeyer: hmm, I don't think we will be able to sort it out today or tomorrow, we will probably work remotely. I'll let you know [11:28] niemeyer: yea, but if I *didn't* work during vacation, what would I do ;) [11:39] Btw, I've upgraded my network connection to amazing 10Mbps on Friday, which means my video should suck a bit less now.. it took some troublesome cabling effort, but it worked out in the end. [11:40] "amazing" because I didn't quite trust it to work for real here, but apparently it's quite reasonable [12:10] fwereade: Please ping me when you're back [12:10] fwereade: I'd like to sort out the machine id situation somehow [12:10] niemeyer, heyhey [12:11] niemeyer, ok, I have a pair of branches that I am just about to push on the strength of which you may find it helpful to judge [12:11] fwereade: Okay [12:11] fwereade: I have an idea I'd like to talk as well.. [12:11] fwereade: Can we have a quick call? [12:11] niemeyer, ofc [12:12] niemeyer, will you invite or shall I? [12:12] fwereade: Sending [12:31] kunchtime [12:33] is that a special german custom? :) === niemeyer_ is now known as niemeyer [12:43] niemeyer: just confirmed, it's not possible to arrange that sprint [12:43] fss: Cool [12:44] fss: Thanks [12:46] =/ [12:51] jam: i've made some comments. https://codereview.appspot.com/6844087/ [12:52] jam: it seems a pity that you can't push changes to that CL though. [12:53] jam: as another possibility (too late!) i was wondering if it might be better to make a minor change to each file (e.g. a comment "// pending review") and propose that as a CL to the existing trunk. then people could comment on any file, and changes would be targetted to trunk. [12:56] rogpeppe, must I remind you: (2:58:50 PM) jam: rogpeppe: silence! the code is perfect as is, and I will hear no dissent. :) [12:56] too many camels [12:56] thanks for the comments, the inline comments is an interesting idea [12:56] jam: oops [12:56] I'll look over your comments and see if it is something that can be addressed quickly, or not. [12:56] jam: there are many small issues [12:57] the top few I generally agree with and a few have been mentioned/are being fixed [12:57] jam: it would have been nicer if we could have commented as the branch was being built up [12:57] so, less redundant naming of things in packages, constants where just using the string would do, and so on [12:57] rogpeppe: you were sitting right next to us :D [12:57] mgz: i saw no proposals :-) [12:58] mgz: yeah, just lots of go-idiomatic things, mostly [12:59] fss: What was the issue, out of curiosity? [13:00] rogpeppe: okay, on the json error to go error thing, this is what I want to get sorted [13:01] mgz: that was probably the most substantive comment, yeah [13:01] but, discussing it this morning, I still don't really get the go conventions for rich error instances [13:01] mgz: basically you can document that a function may return a particular error type [13:02] mgz: then the caller can dynamically check (if it wants to) whether such an error type was actually returned [13:02] TheMue, hmm, my understanding of something is fatally flawed: why is firewaller using a MachinePrincipalUnitsWatcher? [13:02] mgz: there are actually three conventions [13:02] but you can't have a type, and then a subtype of that, as I understand is, so no `except EnvironmentError:` kind of thing [13:02] TheMue, I thought the whole point of the MachineUnitsWatcher was to do exactly what the fw needed? [13:03] mgz: you can return several different possible types [13:03] so, having a general OpenstackInteractionError then specific types that derive from that is no go [13:03] niemeyer: I don't know. We all should pray for transparency :-( There was an excuse, but I'm not sure that was the reason [13:03] mgz: e.g. EnvironmentError, HttpError, JsonError, etc [13:04] mgz: then the caller can do: if e, ok := err.(*EnvironmentError); ok { ... we got an environment error } [13:04] the point of EnvironmentError in python is it catches OSError (and subclasses) and IOError (and subclasses) [13:05] mgz: well, we don't do subclasses. you'd need to decide which errors come within which category. [13:05] mgz: (errors can of course contain other errors) [13:05] mgz: sorry, i'm not very familiar with python or its class hierarchy [13:06] the other question... [13:06] in python I'd make an exception class with several attributes [13:06] and a __str__ method that took those attributes and presented something pretty [13:07] so, you could do `err.code == 404` but when propogates you still get the nice stringification [13:07] mgz: that sounds very similar to a struct type with an Error method [13:07] where's a good go example for that? [13:07] mgz: egrep for ' Error\(' [13:07] mgz: well... [13:08] mgz: i'll fine you an example [13:08] find [13:08] mgz: basically, if you define an "Error() string" method on a type, it can be used as an error. [13:09] mgz: so if you've got a struct type describing your error, you can write an Error method that produces a pretty string version of the error [13:09] okay, thanks. [13:09] I'll do such after lunch. [13:10] rogpeppe: the OpenStackHTTPClient stuff is already in a branch to land, for some of the naming tihngs. [13:10] mgz: example at random: look in go/scanner/errors.go in the go source tree [13:10] jam: ok. [13:11] rogpeppe: so what is the difference between fmt.Errorf and errors.New() ? It would seem New() won't let you ever put in custom formatting, while Errorf() is pretty obvious for that. [13:12] jam: that's the only difference. errors.New is a teeny bit more efficient as it doesn't need to scan the string. [13:12] It seems a bit odd to use both in the codebase (having to import errors just to get New, when most of the time you use fmt.Errorf() because you want extra context) [13:12] jam: i suggested using errors.New because the errors package was already imported [13:13] jam: it's not a significant issue though [13:14] fss: What was the excuse? [13:15] fss: If that's publc [13:15] public [13:15] fwereade: I can't help you here. I used machine.WatchUnits() in my latest version before I added the global mode. At this time the change to the principal unit watcher has been introduced. [13:16] fwereade: I think it may be a temporary change due to the work on the unit watcher. [13:18] TheMue, ah, ok, I shall examine it further [13:18] TheMue, cheers [13:19] jam: Do you have a moment before you go? [13:19] rogpeppe: I'll read through your suggestions a bit more tomorrow. My son is indicating in no uncertain terms that its my EOD. [13:19] niemeyer: I might have 30s or so [13:20] jam: okeydokey [13:20] niemeyer: msg :-) [13:20] jam: Cool, that won't be enough.. let's catch up tomorrow then [13:21] niemeyer: works for me. [13:21] jam: Have a pleasant evening there [14:04] niemeyer, re depart hooks, the pinger presence expiration won't trigger them? [14:04] hazmat: Nope [14:07] anyone fancy having a look at some of my outstanding reviews? i'm sure a couple of them could be submitted if i had two LGTMs. [14:09] rogpeppe: the ones I reviewed I don't think I said lgtm but did mean it [14:09] mgz: thanks. yeah, you're the first LGTM! [14:29] mgz: just wondering: why do you define an interface type for each of the various clients (e.g. swift.Swift, swift.Nova, etc) ? [14:29] s/swift.Nova/nova.Nova/ of course [14:30] which part of that question is surprising for you? I think the bit that's novel for me might not be what you mean... [14:30] needing an interface seems to be a neat way in go of providing a real implementation and a testing backend that support the same stuff. [14:30] but I suspect you mean why not just one interface for everything? [14:32] openstack exposes various seperate services, with different endpoints, so, for instance, you could have a deployment that had nova for compute, but no swift (as canonistack did for a long time) [14:34] so, we might for instance want a ceph object-store client as well, which we could then perhaps factor a common interface out of [14:36] rogpeppe: Which CL do you want to be reviewed? [14:37] mgz: sorry, only just saw your reply. (i generally don't notice things on irc unless directly addressed) [14:37] TheMue: any of the ones in https://code.launchpad.net/juju-core/+activereviews with no prereqs would be a good start [14:37] mgz: i mean both actually [14:38] mgz: i don't see that defining an interface that provides exactly the same things as the type you're also defining is useful. [14:38] rogpeppe: right, it's only really useful when you have another type as well [14:38] mgz: it just means that you have to do more work when changing type sigs, because you need to keep the interface type in sync too [14:39] mgz: in general, in Go we define interfaces when we need them. [14:39] which I think is what the plan was over providing test versions, but there's still some debate over what we're trying to do there exactly [14:40] mgz: it's not that usual to use interfaces in Go just to enable mocking. [14:40] fair enough, and we may do that all at the http level anyway [14:40] mgz: that's the approach we took for ec2, and it seems to have worked ok [14:41] you seem to rely a lot on testing edge cases just against ec2 itself [14:41] that's less tractable with the myriad possible openstack deployments [14:41] mgz: for example? [14:41] * niemeyer => lunch [14:41] but there are also other ways to address that with a faked out server [14:41] mgz: we run the "live" tests against the fake server too [14:43] dave cheney just fixed an issue where you get an odd error back from ec2 when in a different region and trying to access the public bucket [14:44] really, for that kind of thing with openstack, we want to test the specific error back from swift gets propogated to the client as something understandable so the user can fix their region [14:45] if you just have a well behaved pretend swift server, testing particular error cases means either adding params to it and spinning up a new one each test, or poking a running one to do something special next response [14:46] or I guess here, hardcoding some maic region value that both the test and the server expect to behave in a particular way [14:47] that starts to add a lot of complexity after the 50th quirk you want to test [14:47] rogpeppe: ^example :) [14:49] mgz: we should definitely test that kind of thing locally. we happened to find the error when testing live, but there's no reason we can't use the local test server to check those kinds of issue. [14:49] mgz: i'd provide a way to configure the test server so that it emulates one (or a set) of the possibilities [14:49] rogpeppe: I'm not seeing that being done in several merge proposals that have gone past, generally just the client code has been fixed [14:50] mgz: i agree, that's a problem. [14:51] mgz: but that doesn't mean the general approach is wrong [14:54] mgz: what do you think of the idea of defining a common-subset interface across the various provider types? [14:55] rogpeppe: don't think it's practical [14:55] mgz: there's no common functionality at all? [14:56] mgz: from my brief glance, it looks as if there's at least some [14:56] might work for some bits like storage, which tends to be a thin wrapper around the underlying apis anyway, [14:57] which a few added frustrations in the design from s3isms [14:57] mgz: it's entirely possible to have a common-subset API which still provides access to extended features [14:57] rogpeppe, it's a question of convenience in a particular setting, though [14:57] openstack and ec2 should be able to share a fair bit, but maas doesn't look much like them outside of having somewhere to poke files [14:57] mgz: oh sorry [14:58] mgz: i wasn't talking about between openstack and ec2 [14:58] mgz: i was talking about the various clients within openstack [14:58] mgz: e.g. nova, swift [14:59] ahem [14:59] rogpeppe: so, there's not much direct overlap at present, potential for s3-compat/swift/ceph aside [14:59] perhaps i should google a bit before talking about something i don't know anything about :-) [15:00] but certainly services that provide roughly similar apis like that should be exposed through a common interface for usage that doesn't care about which one you're using for object-store [15:00] rogpeppe: One LGTM with a small hint. [15:00] mgz: it does look like there are potential types in common though. Entity, for example, is the same in each, no? [15:01] TheMue: append(certPEM, keyPEM...) *can* touch certPEM [15:01] rogpeppe: the other thing along those lines is some compat stuff where apis used to be in nova but have been split out in newer versions, clients ideally shouldn't care where the volume management bits are, just that a volume management interface is available [15:02] rogpeppe: some apis take uuids that refer to the same objects, I'm not sure what other things apart from auth are shared [15:02] mgz: it seems to me like that's something that can be managed at a later stage. [15:02] mgz: Link ? [15:02] for example, booting a server requires knowing what image to use [15:03] rogpeppe: OK. Is it platform dependend? Can't reproduce it. [15:03] mgz: oh yeah, another thing i noticed (can't remember quite where now) - if you want to unmarshal a possibly null string using JSON, you can use *string rather than interface. [15:03] this is just given as a uuid, and at present will need to manually configured as we haven't got a neat cloudwotsit that tells you what the latest precise image on hp is, for instance [15:04] TheMue: try: x := []int{1,2,3}; y = append(x[0:1], 4); fmt.Println(x) [15:04] but you don't need a rich image object, which is what you'd expect back when looking up images using glance (seperate project farmed out from nova a few releases back) [15:05] mgz: i'm talking about shared concepts, not just shared things. can't we use a common Link type across each package? [15:06] probably, what specifically does that get us? [15:06] rogpeppe: OK, that's the trick, IC. Thx. [15:06] rogpeppe: Tested it without indexing. [15:06] mgz: it reduces the number of overall entities. [15:06] richer basic types would be good. [15:07] sure, but what would Link be exactly? [15:07] mgz: what is it now? (i don't see any docs :-]) [15:08] ...I think this is all stuff for unmarshalling/marshalling specific json [15:08] which is likely not very sharable, at least if we want to be well behaved [15:08] mgz: IMHO it's nice to factor out common elements when appropriate. then it becomes easy to use common code across those elements. [15:09] mgz: but ListFlavors, for example, returns a []Entity [15:09] rogpeppe: one issue I have is optional params [15:09] mgz: so it's *not* just about marshalling/unmarshalling [15:09] as I understand it, unmarshalling lacking some json keys is fine, the value for that key is then just nil [15:09] mgz: yeah [15:10] but the reverse is a little suspect [15:10] if you're meant to provide key A or key B, you don't really want {... A: "", B: "something"} [15:10] mgz: you can have omitempty for that [15:10] ah, that sounds good. [15:11] mgz: it doesn't work for structs though, i think [15:11] mgz: just atoms [15:11] mgz: but i may be wrong there [15:11] mgz: anyway, it's not necessary to use the same types for unmarshalling as you're returning from the functions. [15:13] sure, but it is pretty handy, and we'd need even more structs to make that distinction [15:14] the Link/Entity thing is pretty mysterious... [15:15] does seem they're meant to be a common interface many objects use [15:17] mgz: do they have a common json representation too? [15:17] nope, but share some keys [15:18] many things have an id:UUID, name:string, links:{} as well as the rest of their details [15:19] so, having that up one level might make sense (not for swift though) [15:20] the nova derived parts are more homogenous [15:20] mgz: you *might* be able to use an embedded Entity struct to make that work [15:21] mgz: is there an API reference for these things BTW? i just found java docs. [15:21] api.openstack.org [15:22] ah, i was looking at docs.openstack.org [15:23] * rogpeppe loves the way a single example is considered sufficient documentation [15:23] hey, at least there's an example these days [15:25] :-) [15:25] I did quite a bit of coding to the implementation... [15:26] which when bouncing through and external api then the internal rpc was often quite fun to work out exactly what some param did [15:26] mgz: i'm sure [15:28] reminds me, I still want to see if I can do away with the need for private storage via cunning compute api usage [15:28] the main problem is the habit of stuffing charms in there... which I think we can just do with an auto-generated local-public bucket [15:29] mgz, +1 [15:30] the current hack of just making the whole bucket public-readable is... not something I'm happy with [15:33] mgz: we also use the private storage for pushing development versions of tools to [15:34] mgz: but in general it's an idea we're working towards [15:47] fwereade: will we be able to use your new UnitsWatcher for watching service units too? [15:48] niemeyer: regarding proxy support, there's another issue, we would need to specify it to cloud init too, so it is used when apt-getting [15:49] niemeyer: our current approach is to set the proxy in /etc/apt/apt.conf.d in a customized AMI [15:49] fss: We probably need an env setting for that [15:51] niemeyer: makes sense [15:55] niemeyer: thanks [15:55] fss: Do you need https proxy as well, or just http? [15:57] rogpeppe, nope, there will be too many service units for that approach [15:58] fwereade: any chance of a review of this trivial branch? https://codereview.appspot.com/6847091/ [16:00] * fwereade looks [16:02] niemeyer: yep. We use the HTTP proxy for tunneling HTTPS connections. Unfortunately, twisted does not support that. We're using HTTP AWS endpoints, but we don't plan to keep using this [16:03] TheMue: ultra-trivial review for you (and also fixes trunk when compiling against go tip): https://codereview.appspot.com/6849101 [16:05] rogpeppe: Indeed ultra-trivial. ;) [16:05] rogpeppe: https://codereview.appspot.com/6847091/diff/4001/environs/bootstrap.go#newcode77 [16:05] rogpeppe: Please please please don't commit that [16:05]