[02:21] axw: hey [02:22] axw: fwereade was considering staying up to chat to you but when he realized what time you started he decided not to :) [02:22] thumper: yo [02:22] hehe [02:22] axw: probably about the precheck branch [02:22] I've not read is response other than to realize that he made one [02:22] thumper: I think about the null provider actually [02:22] * thumper is busy with kvm [02:22] ah [02:22] but yes, precheck needs work too [02:22] expect a ping from him when he wakes [02:23] yup, will do [02:23] thanks [02:23] np [02:26] axw: when a manually provided machine is added, the agents still run as root, right? [02:26] thumper: yes [02:26] cool [02:26] just checking [05:53] axw, heyhey [05:53] fwereade: heya [05:54] axw, so, sorry I got confused about the time -- I hope I didn't leave you hanging too badly [05:54] fwereade: nope, not at all. thumper let me know you realised later about the time :) [05:55] I would feel quite guilty if you got up in the middle of the night to talk to me ;) [05:55] axw: you get over that :) [05:55] heh [05:55] axw, haha [05:55] I guess it's inevitable [05:56] axw, ok, just catching up on your responses [05:56] axw, I *think* that series is maybe still a useful thing to have [05:57] axw, because it's the environ that's more or less in charge of making tools, images, etc available to juju [05:57] also... for future container checks [05:57] we probably want the instance id [05:57] so we can get the machine [05:58] and see if it said kvm was ok [05:58] fyi, on ec2, no kvm [05:58] axw, and at least a check for "do we have an image available" depends on seriess + type [05:58] thumper: ah yes, I forgot you mentioned kvm-ok [05:58] fwereade: fair enough [05:58] I plan to have the machine agent run it on start up [05:58] thumper, AFAIK Prechecker will be somehow used inside state [05:58] thumper, so we'll already know the machine [05:58] and if kvm-ok fails, then we should record in state that the host machine can't do kvm [05:59] thumper, definitely [05:59] fwereade: but is it passed through? [05:59] we probably should [05:59] thumper, not yet [05:59] thumper: passing through is in a followup [05:59] thumper, we need tofigure out how to get this code where we need it without making baby jesus cry [05:59] that's fine [05:59] hehe [06:00] fwereade: I'm struggling getting the damn kvm code to actually run [06:00] constantly fails for me [06:00] :( [06:00] I'm writing the interfaces and mocks [06:00] and broker [06:00] and stuff [06:00] hoping that we can plug working bits in later [06:00] thumper, cool, but if the stuff you'remocking seem flaky... [06:00] thumper, yeah [06:00] it is what it is [06:01] we can work with it for now [06:01] quite so [06:01] we know basicly what it will take [06:01] so can mock out that [06:01] it won't be perfect [06:01] until the utility code actually works [06:01] so I'm mocking out what I think we'll need [06:01] as far as params go [06:01] the function calls are known though [06:01] start/stop/list [06:01] and that's about it [06:01] except for the initialize [06:02] go get me an image type code [06:02] thumper, ok, great [06:02] fwereade, thumper: so I'll put instance.Id in since it'll be used for kvm-ok, and I'll put series in for checking image availability [06:02] (into PrecheckContainer params) [06:03] axw, ah, ok, clearly I'm missing something -- why's the instance id needed there? [06:04] axw, thumper: surely what will happen is the machine agent will run and check, and record in state whether kvm is a viable option [06:04] axw, eliminating the need to ask the env? [06:04] axw, or am I ignorant about something? [06:04] ah yes of course [06:04] (I am surely ignorant about many things ofc) [06:05] sorry, I'm still getting my head around what's known in state etc. [06:05] that makes sense [06:05] axw, no worries [06:05] nope, I'm ignorant :) [06:05] ok. just series then [06:05] axw, that's not known yet anyway [06:05] axw, cool, thanks [06:05] fwereade: what's not known? [06:06] axw, sorry -- the can-we-run-kvm code doe not *yet* write anything into state to record the results [06:06] right [06:06] axw, but it should/will, so we're good with series + contianer kind [06:07] fwereade: thanks, I'll update it after proposing my httpstorage auth branch [06:07] axw, brilliant, thanks [06:07] axw, bah, it looks like I may be off shortly... the power company has scheduled maintenance, apparently [06:08] axw, so it I disappear that's where I'll be [06:08] fwereade: no worries, thanks for coming on early to chat. [06:10] axw, and thanks for addressing all those things, those CLs look solid, I'll give them a closer look in a bit [06:10] cool [06:11] * fwereade is always a bit worried about searching for his power company [06:11] bad reviews? :) [06:11] * fwereade fears the consequence of a fat-fingered search for, yes, "enemalta" [06:11] haha [06:12] it's particularly alarming seeing branded fuel tankers driving around the airport [06:12] aaanyway [06:13] speaking of alarming branding, I saw this in a parenting magazine yesterday: http://www.juju.com.au/ [06:16] haha [06:26] oh dear [07:04] mornin' all [07:06] fwereade: hiya [07:06] rogpeppe, heyhey [07:06] fwereade: martin reviewed this, but suggested another look might be good, so i wondered if you could take a glance before i approve it. https://codereview.appspot.com/13778046/ [07:06] rogpeppe, ah, sure [07:07] rogpeppe, btw I will disappear for an unknown period at some point today, power company doing some maintenance [07:07] fwereade: ok, thanks for the heads up [07:35] morning [08:13] TheMue: yo! [08:14] rogpeppe: btw, the chrome plugin you twittered is nice - but i dropped chrome [08:15] TheMue: what do you use now? [08:15] rogpeppe: to much memory and cpu consumption [08:15] rogpeppe: now back to the good old ff [08:16] TheMue, I have exactly the opposite experience with ff and chrome - the latter works faster and its more lightweight on my machine :) [08:16] rogpeppe: imho chrome becomes more and more an own os, only missing a go and a dart ide integrated ;) [08:16] rogpeppe: funny [08:16] rogpeppe: some of my friends switched too and feel better now [08:17] rogpeppe: may depend on the exact plugins one is using === ChanServ changed the topic of #juju-dev to: https://juju.ubuntu.com | On-call reviewer: TheMue | Bugs: 12 Critical, 135 High - https://bugs.launchpad.net/juju-core/ [08:18] hmm, the number of bugs is only increasing. we need a feature freeze to simply handle those bugs [08:40] wallyworld_: I'm looking at the fetch code right now, and I see it failing to find sjson in 3 places before it even tries to look for .json: http://paste.ubuntu.com/6149206/ [08:40] that looks like private-bucket, then ? then tools-url [08:40] wallyworld_: I thought the goal was to search for sjson then json in private, then fallback to site-tools, then user config? [08:42] wallyworld_: the issue is that the signed/unsigned flag is being done at a higher level [08:42] with "requireSigned" [08:43] environs/tools/simplestreams.go always calls "GetMaybeSignedMetadata(...,requireSigned=true)"before calling it with something else if it hasn't found anything [08:43] doesn't that mean when we have juju.canonical.com or even just signed mirror data, it *won't* ever use user-specified unsigned metadata ? [08:56] jamespage, ping [08:56] wallyworld_: I'm also surprised you decided to take our "implicit" URLs before user-explicit URLs (you check the custom urls before "tools-url") [08:56] how would a user override an explicit setting in the env? Only by using their private bucket? [09:12] jam: i had no choice for the 1.15 release, because for in HP Cloud (for example), the tools url was set automatically and this hid the uploaded tools when using a dev release [09:13] wallyworld_: how is tools-url set automatically ? [09:14] jam: see certifiedclouds.go [09:14] it sets up the tools url in config validation [09:15] we won't need this once the repository comes online [09:15] wallyworld_: so... that indicates to me that our layering is probably wrong. Can't we put it into the CustomSources instead of overriding user-config ? [09:16] wallyworld_: we could call GetCertified... in openstack/provider.go GetToolsSources, couldn't we ? [09:16] maybe. it was done later friday night because i was smoke testing for the release and found the issue. but we didn't release 1.15 so it was for nought [09:17] i was just trying to get something done so the release would be ok [09:17] it's on my list to revisit [09:17] sure, did you see my point about always searching for DefaultBaseURL+ .sjson *before* searching the private-bucket for .json ? [09:17] that will also cause problems when we have "official" locations online [09:18] i'm reading it now [09:19] the thinking way back when was that signed metadata should take precedence but this could cause issues as you say [09:22] jam: the hp cloud url was done in config because i needed to convert the deprecated public-bucket-url into a tools url and that deprecation code lives in config, but i think it can be split out into custom sources [09:23] i was initially looking to keep the code dealing with deprecated config values together [09:23] wallyworld_: sure. It just feels like it should be "user-config" then "private" then "default tools-for-cloud" then "juju.canonical.com" [09:24] *maybe* private then user-config [09:24] but right now we have "default-tools-for-cloud" before user-config [09:24] sure. but a few short hours before when i thought the release was being done i needed a quick fix [09:24] np [09:25] tomorrow i should get to do mirrors and hence was making tomorrow my "deal with simplestreams" stuff day [09:25] stuff = where to find things [09:25] np [09:26] wallyworld_: I only noticed because I had to touch those bits, and it caused conflicts when merging turnk [09:26] trunk [09:26] np. i hadn't appreciated/property though about the sjon vs json thing so i'm glad you asked [09:48] jam, mgz, dimitern, TheMue, axw, natefinch: a small cleanup to the environs.Environ interface: https://codereview.appspot.com/13587046 [09:49] rogpeppe: looking [09:49] TheMue: thanks [09:55] rogpeppe: reviewed [09:55] TheMue: ta! [10:17] rogpeppe, hey he provisioner is ready for review :) https://codereview.appspot.com/13720051/ [10:19] dimitern: cool. i'll take a look soon. [10:45] raywang, hello [10:46] Hi jamespage, just want to check with you that after deploy ceph-radosgw, anything extra works need to be done for testing s3 or swift compatibility? === teknico1 is now known as teknico [10:47] standup time [10:47] mgz: dimitern https://plus.google.com/hangouts/_/239d0ac12a07a73dd5a83cc2b9d8bb4047ce20b4 [10:50] raywang, #juju [10:50] jamespage, ok [11:08] here's my CL for review: https://codereview.appspot.com/13430044/ [11:18] * TheMue => lunch [11:22] jam - one thing I forgot to mention is that once the maas tags bugs are fixed, I'll need another project to work on, if you have ideas. [11:22] natefinch: I would look closely at supporting the work from the weekly agenda https://docs.google.com/a/canonical.com/document/d/1eeHzbtyt_4dlKQMof-vRfplMWMrClBx32k6BFI-77MI/edit# [11:22] whether that is doing code reviews [11:23] or working with Martin on Amazon + VPC stuff [11:23] natefinch: also, if you have MaaS up and running [11:23] there is something I'm concerned about with our container strategy [11:23] in that we fire up a container and it grabs an address from the DHCP server. [11:24] I'm concerned that the MaaS infrastructure itself thinks that these are new machines that it is going to want to PXE boot. [11:24] ahh yeah, I remember you mentioned that [11:24] jam I can do some testing on that [11:25] natefinch: essentially I think "juju deploy --constraints container=lxc" and then see what changes on the MaaS master node [11:26] jam: I can do that. So that'll deploy a service to a container on one of the nodes, and we just want to make sure maas doesn't think you've added a new node for it to manage, right? [11:26] natefinch: right. [11:26] or at least document what happens so we can open bugs about how we want to fix it [11:28] jam: cool. I'll test that out once I get my maas in working order again. [11:29] smoser: you around? [11:34] wallyworld_: i've got a few remarks on https://codereview.appspot.com/13842044 if you can hold off approval for a few minutes [11:35] ok === Guest47103 is now known as ehw [11:48] wallyworld_: you have a review [11:48] thanks, looking [11:51] sorry for missing standup, had to step out [11:52] rogpeppe: thanks for the Go tips, will implement those tomorrow before landing [11:54] fwereade, hey [11:54] dimitern, hey dude [11:54] fwereade, provisioner review? https://codereview.appspot.com/13720051/ [11:54] dimitern, that took longer than expected [11:54] dimitern, twould be a pleasure [11:54] fwereade, I was wondering where are you [11:55] dimitern, power cut [11:55] dimitern, was apparently scheduled, I found out just today, wasn't expecting it to be like 4 hours though [11:56] fwereade, aw.. well at least it's just 4 hours :) [11:57] fwereade: welcome back [12:05] dimitern: quick question: why do non-global provisioners need the environ config at all? [12:12] rogpeppe, afaik they need to know the environ config is saved to state already [12:12] dimitern: why so? just asking, because in future we won't want them to be able to get access to the env config, so it'll save us work if we can avoid them accessing it now. [12:13] rogpeppe: so today the code is structured just that we wait for environ config changes and instantiate an "Environ" object [12:14] which needs an EnvironConfig [12:14] they then later on do stuff with that Environ [12:14] but the two parts of the code are pretty far apart [12:14] jam: what does the local provisioner do with an Environ? [12:15] rogpeppe: I'm not 100% sure how it all hangs together.From what I can tell it uses "getBroker" which returns either the Environ itself, or an LXCBrokecr [12:15] Broker [12:16] rogpeppe: and the Config stuff ends up getting handed off to a lot of places [12:16] rogpeppe, so in short, it seems the lxc one does not need it at all, but that's how the code is written [12:17] dimitern: I'd much prefer it if the local provisioner never called WatchEnvironConfig [12:17] so what comes to mind is having an API that returns a minimialistic EnvironConfig, which we later ask another API for the credentials needed for the environment broker [12:18] dimitern: (i mean WatchForEnvironConfigChanges of course) [12:18] dimitern: couldn't you only set p.environ if p.pt == ENVIRON ? [12:18] looking at the code, it does feel like we have a bunch of switch statements that might look better overall if we just had 2 types [12:18] an LXCProvisioner [12:18] vs an EnvironProvisioner [12:20] dimitern, ha, I was just coming to start the above conversation [12:21] dimitern, rogpeppe: so, yeah, the environ stuff is tied in too tightly there [12:21] ah, i see why [12:21] fwereade: so I think landing what we have to guarantee API-based provisioner in 13.10 and *then* trying to split things up would be our best way forward [12:21] i don't think the change would be difficult at all, at first glance anyway [12:21] dimitern, rogpeppe: in particular, it look like an lxc provisioner is waiting for a valid environ config [12:21] dimitern, rogpeppe: else how can it set p.environ [12:22] dimitern, rogpeppe: and that mean we're pooing secrets onto every machine again [12:23] dimitern, rogpeppe, jam: in the name of expediency I could put up with a hack-for-landing that had a p.environ field that was always nil for non-environ provisioners, for example [12:23] dimitern, rogpeppe, jam: but it'd really have to be addressed very soon afterwards [12:24] the problem is that ContainerManager.StartContainer wants a config.Config [12:25] ahhh [12:25] so we actually do want a significant portion of the environment config there [12:25] just not the secret bits [12:25] rogpeppe, ha, yes, anotherslice through environ config with its own special idiosyncracies [12:25] because we need to call FinishMachineConfig, which needs things like authorized keys, [12:26] rogpeppe, what does FinishMachineConfig use for non-managers aside from the auth-keys? [12:26] rogpeppe, AIUI it is in fact *only* the authkeys we need [12:27] fwereade: provider type [12:28] rogpeppe, aw, ffs [12:28] fwereade: and it uses cfg.AdminSecret, which seems wrong [12:28] fwereade: and StatePort and APIPort [12:29] rogpeppe, nah, that's all after "if !mcfg.StateServer{ return nil}" [12:29] fwereade: ah! missed that, thanks. [12:30] rogpeppe, I guess provider type i not so bad [12:30] fwereade: we *are* putting environ creds onto every machine, but we know that, and while it lets you start and stop instances, it isn't the same as giving you root on all the machines. [12:30] fwereade: for lxc, i presume it's always lxc [12:30] For example, you can't actually add ssh keys to machines just with provider creds (only startup ssh keys, etc) [12:31] rogpeppe, but I think there's a pretty good case for a narrower FinishBasicConfig which is called by FinishBootstrapConfig [12:31] yeah, after reflection, i think i'm with jam that we should land this now and work towards eliminating environ config later [12:31] jam, it lets an attacker spend a user's money [12:31] jam, keeping those particular credential secret i one of the major points of this [12:32] fwereade: I agree 100% that we want to get away from this. But I think getting to the point where "root on machine-a doesn't give root on all other machines" is a very useful step forward. [12:32] jam: +1 [12:32] fwereade: i think that this CL is progress [12:32] fwereade: and it's nice to see it when not too much logic has changed [12:33] fwereade: the main problem is that we have a "config.Config" and we honestly don't know without a lot of deep inspection what we need out of that. [12:33] rogpeppe, jam, dimitern: I don't care if the provisioner API does something ludicrously dirty like look up SecretAttrs and crap in NO-NOT-YOURS values over what they return [12:33] so I think incremental steps. But having an EnvironProvider and an LXCProvider will actually clean up the code a bit as well as make it clearer what bits we actually need. [12:33] rogpeppe, jam, dimitern: but we really must not put provider cred on every machine [12:33] fwereade: agreed [12:33] fwereade: but that doesn't have to happen in this CL [12:34] exactly [12:34] fwereade: we don't have to do it all at once [12:34] fwereade: "progress not perfection" [12:34] rogpeppe: sorry, but this is one of the main point of this work [12:34] fwereade: sure [12:34] fwereade: but it doesn't have to happen in *this* CL [12:34] fwereade: which is already big enough [12:35] fwereade: and gives us behaviour that's better than we had before [12:35] fwereade, dimitern: so something like line 158 of state/apiserver/provisioner/provisioner.go after we grab Config.AllAttrs() we could do a "JobHostsStateServer" check and if that isn't part of the unit making the request, we nuke whatever secrets we can ? [12:36] fwereade: aren't those specific to the provider itself (openstack has different secrets than ec2 than azure) [12:36] or can we just nuke all secret attrs ? [12:36] jam, yes they are, but we don't need to construct an actual environ to get secrets, that' on EnvironProvider [12:37] jam: yeah, we can do that (only if the provisioner isn't the global one though, of course) [12:37] jam, but we will probably need to dick around and figure out the types of the secret attrs so we can overwrite them usefully,and in the general case overwriting them usefully may not even be possible [12:37] so do we need an Environ (and its config) in a lxc provisioner at all? [12:37] dimitern, we *need* two values out of the config [12:38] fwereade, which ones? === natefinch is now known as natefinch-afk [12:38] dimitern, provider type and authorized keys [12:38] fwereade, why? [12:38] dimitern, they're the ones actually used by FinishMachineConfig for a non-state-server [12:38] fwereade: so the Environ.SecretAttrs seems to be the only place that knows what the private attributes are [12:38] dimitern, but IIRC we agreed that authorized-keys should come from the machine anyway? [12:39] state.EnvironConfig doesn't combine sections or anything [12:39] jam, yeah [12:39] jam, afraid not [12:39] fwereade, how about provider type? [12:39] fwereade: so I would be fine with a quick hack, but I think if we can have LXCProvisioner than it doesn't need anything like EnvironConfig, it can just do "GetMyProvisionerConfig" sort of call. [12:40] dimitern: I would guess that we don't actually need environ for LXC provisioner [12:40] dimitern: but the current code layering [12:40] jam, yeah [12:40] means a lot of line-by-line auditing of "can I get here in an LXC provisioner" [12:41] personally I think we should move towards having known attributes in the state in a well known form separate from environ config. [12:41] rogpeppe, yeah, I'm definitely keen on migrating stuff into sensible buckets [12:41] dimitern, I'm trying to figure out why we need provider type [12:41] fwereade, we can do ProviderType() (string, error) api call, like we did with the uniter [12:41] fwereade: we'd have to be careful around juju set-environment [12:42] dimitern, yeah, indeed [12:42] dimitern: moving towards that also gets us away from "NewSimpleAuthenticator" running on the LXCProvisioner, which makes it easier to say "this does not actually directly touch Mongo" [12:42] rogpeppe, yeah, definitely [12:42] jam, we don't have to change that - we can change the api not to set mongo passwords [12:42] rogpeppe, but, eh, that stuff's all fatally broken anyway,it only works by luck [12:43] dimitern: this is more about auditability [12:43] by sharing the code [12:43] you have to look at switches, etc [12:44] oh, this isn't enabled in this configuration [12:44] if we split them apart [12:44] then there just isn't a state connection object anywhere in the LXCProvisioner [12:44] fwereade, so how about a follow-up that introduces ProviderType() and apiprovisioner.Machine.GetAuthorizedKeys() API calls, and uses that in the lxc provisioner? [12:44] dimitern: I don't tihnk we need the api to get the ProvisionerType, as cmd/jujud/machine.go is the only place where we ever call NewProvisioner [12:45] and if we *want*, we can make Provisioner just an interface{} [12:45] and then implement 2 of them [12:45] fwereade, GetAuthorizedKeys() needs to read the env config internally and return a slice of what? [12:45] and NewProvisioner returns one or the other based on the flag you passed in. [12:45] jam, it currently does that [12:45] dimitern, GetAuthorizedKeys I think takes an []tag, and retur an []string [12:46] jam, but not as an interface [12:46] fwereade, machine tag ok, and which env config keys should it return? [12:47] dimitern: no, it currently returns a Provisioner that has an internal flag set. vs a separate type/struct/whatever [12:47] dimitern: I guess my point is, we shared a bunch of the code because they look "similar" but honestly there are a *lot* of different bits, and I'd like to split them further apart. [12:47] dimitern, it just returns the valueof authorized-keysin config [12:47] jam, yeah, they should unquestionably be split [12:47] fwereade, ok, one per machine [12:48] jam, that was always the original plan [12:48] and have 2 implementations that share an interface, rather than 1 concrete type that has a bunch of switch statements. [12:48] jam, but the authkeys-in-config scotched it [12:48] fwereade, and then a follow-up that splits the 2 provisioners into separate types implementing an interface [12:48] dimitern, do you know offhand why there's an environ on p? [12:48] fwereade: GetAuthorizedKeys returns a []{tag: Name, keys []string} doesn't it? [12:49] fwereade, and a third CL, which binds the previous 2 together [12:49] well, []{tag: Name, keys []string, Error} [12:49] fwereade, it's an instance broker [12:49] jam, authkey is just a string in the format one would expect in .ssh [12:49] jam: we current represent a set of authorized keys as a single string [12:49] dimitern, wtf, why's it called environ then? [12:49] fwereade: []{tag: Name, keys string, Error} ? [12:49] jam, not really - we can co with just StringsResults - no name neede [12:49] dimitern, +1 [12:50] dimitern, ok, I need to think and read more code a little [12:50] fwereade, because it implements what InstanceBroker's interface was extracted from [12:50] dimitern: I personally *really* like APIs that return "result + context you requested it" [12:50] jam: too late :-) [12:50] jam, we need to unnecessary change all calls [12:51] jam, and it's working well already [12:51] jam: also, it's really not necessary - adds more network traffic and more error conditions to check [12:51] rogpeppe: slightly more traffic vs being able to actually look at a response and instantly understand it.... [12:52] xml/json are reasonably self documenting over ASN.1 for a reason [12:52] jam, you can look at the request and understand the response [12:52] dimitern: still takes 2 bits of information, when it could be all together [12:52] dimitern: +1. without the request, you're pretty much out of luck anyway [12:52] jam, i really don't see this as a drawback [12:53] dimitern: so if you take this array of things, and sort of squint at it enough, you can line it up with that array of things. [12:53] jam: i could potentially change the rpc package so it always included all the request data with the response [12:53] *or* you could write it down as an array of tuples [12:53] and immediately see the pairirng [12:53] jam: we never pass more than one thing anyway - the whole point is moot [12:54] jam, and send twice as much over the wire [12:54] jam: we might possibly one day have two uses for bulk calls [12:54] dimitern: one is a tag that is 5-10 bytes, one is an authorized-keys string that is 1000bytes, that is not 2x over the wire [12:54] dimitern, ok, so, that environConfig goes on a loong adventure between the getBroker call and the final FinishMachineConfig, but that's the only place it happens [12:55] jam, rogpeppe: if anything, logging api requests and responses can be improved - like print the request data in the response log [12:55] dimitern, so resolving that in this CL is indeed definitely not an option [12:55] fwereade: +1 [12:55] dimitern, however I remain unrepentantly opposed to putting secrets,via the API, anywhere that is not known to be authorized to read those [12:56] fwereade: me too [12:56] rogpeppe, and we need to get rid of these discard * call signature debug logs from the rpc [12:56] dimitern: they're gone [12:56] rogpeppe, sweet! [12:56] fwereade, ok, it's just a temporary state [12:56] dimitern: https://codereview.appspot.com/13249054/ [12:56] fwereade, it'll be fixed in the next 3 cls [12:57] dimitern, fwereade: i'd still like a second review of this (martin's request) BTW: https://codereview.appspot.com/13778046/ [12:57] rogpeppe, bugger, I thought I texted you -- I'd just finished reading it when the power went out [12:58] rogpeppe, I said "LGTM" :) [12:58] fwereade: ah, you did! my phone was muted [12:58] fwereade: i sent you an email, expecting your "from-the-future toy" response... [12:59] fwereade: thanks [12:59] dimitern, can we have a quick g+ in 5 please? [12:59] fwereade: ha, looks like a merged it anyway! [13:00] s/a merged/i merged/ [13:00] fwereade, sure, let me start one [13:01] fwereade, https://plus.google.com/hangouts/_/96f599fd9a86362a79be136169847367eaaf5539 [13:02] dimitern: http://paste.ubuntu.com/6150016 [13:02] fwereade: ^^ [13:03] that is in EnvironConfig [13:03] we already have the AuthEnvironManager [13:03] to handle stuff like WatchEnvironMachines [13:03] so we can just use it here to hide all secrets if we aren't an environ manager [13:03] jam, and we need to restrict WatchForEnvironConfigChanges to the environ manager as well as EnvironConfig() [13:04] jam, then we won't need to delete any attrs [13:04] fwereade, i'm waiting [13:04] dimitern: so I think we need an entirely new structure for non environ provisioners, but if we just want "don't leak secrets to those machines" that should be enough, I think. [13:05]