| === tasdomas_afk is now known as tasdomas | ||
| jam | wallyworld: I ended up getting back at a reasonable time if you still want to 1:1 | 06:13 |
|---|---|---|
| wallyworld | ok, i'll fire up mumble | 06:14 |
| jam | wallyworld: we can hangout instead | 06:14 |
| jam | https://plus.google.com/hangouts/_/30081079f3ae053b9ac5eba3f343941780b57763 | 06:14 |
| jam | wallyworld: ^ I know how much you just adore mumble | 06:14 |
| dimitern | wallyworld: client-side api stays as in state, as agreed on the last call - we cannot change that now | 06:18 |
| dimitern | wallyworld: it'll require rewritting everything | 06:18 |
| dimitern | wallyworld: but it's a transitional state towards having bulk support on the server | 06:19 |
| dimitern | wallyworld: and eventually the agents can benefit from that (one at a time) when refactored | 06:19 |
| wallyworld | dimitern: we need to discuss. i'm on a call right now. perhaps after standup. the way it is now is fundamentally broken because it is 1. stateful, 2. not connectionless, 3. not service oriented | 06:22 |
| dimitern | wallyworld: none of these 3 things can change in a single CL | 06:22 |
| dimitern | wallyworld: as i said, changing the client-side api needs to happen once the state api itself is changed accordingly | 06:23 |
| dimitern | wallyworld: what's important is to have the api server-side right first, which is what the cl does | 06:23 |
| dimitern | wallyworld: but by all means, another discussion is in order with me, you, fwereade and rogpeppe | 06:24 |
| TheMue | morning | 07:19 |
| === tasdomas is now known as tasdomas_afk | ||
| === tasdomas_afk is now known as tasdomas | ||
| fwereade | morning gents, I think my irc client may have swallowed it last time I tried to greet you all | 07:44 |
| dimitern | fwereade, TheMue: morning | 07:52 |
| === racedo` is now known as racedo | ||
| TheMue | fwereade, dimitern: heya | 07:55 |
| fwereade | dimitern, TheMue, heyhey | 07:57 |
| fwereade | dimitern, wallyworld, we should all talk sometime soon | 07:57 |
| dimitern | fwereade: yep, sgtm | 07:57 |
| dimitern | fwereade: i have 1-1 with jam at 11, maybe after that, before the standup? | 07:57 |
| fwereade | dimitern, sure, if that works for wallyworld -- or if right now wors for you both that might be even better | 08:05 |
| dimitern | wallyworld: you're good for a call now? | 08:05 |
| dimitern | fwereade: what was you wanted to talk about the api btw? | 08:10 |
| === TheRealMue is now known as TheMue | ||
| fwereade | dimitern, I was just a bit confused about the authorization testing for unit access given a machine connection | 08:11 |
| fwereade | dimitern, it seemed like an unrelated machine was happily getting units it shouldn't really have access to? | 08:11 |
| dimitern | fwereade: oh? | 08:11 |
| fwereade | dimitern, and if that's just because it's a straight port of existing functionality that's ok but I wanted to check what the story was there | 08:12 |
| dimitern | fwereade: only the environ manager machine and the machine agent for a specific machine has access to most methods on machines | 08:12 |
| dimitern | fwereade: re units, the auth is based on 3 things: entity itself (u.Tag() == authUser.Tag()); or its deployer (principal unit or machine) | 08:13 |
| fwereade | dimitern, https://codereview.appspot.com/9797046/patch/21001/22008 seems to log in as a machine but to get units not assigned to that machine | 08:13 |
| fwereade | dimitern, possibly I just misread something? | 08:14 |
| dimitern | fwereade: can you point me to a specific test? | 08:14 |
| fwereade | dimitern, TestUnitsGet | 08:14 |
| dimitern | fwereade: so the suite is written so that the authuser is machine 0 | 08:15 |
| dimitern | fwereade: which (i know this must be wicked, but) is both JobHostUnits and JobManageEnviron | 08:15 |
| fwereade | dimitern, s.machine, err = s.State.AddMachine("series", state.JobHostUnits) ? | 08:16 |
| dimitern | fwereade: and in general reading operations are less restrictive than write | 08:16 |
| fwereade | dimitern, is there something else set up in JujuConnSuite? | 08:16 |
| dimitern | fwereade: ah, that's the first CL - yes in there it's just JobHostUnits | 08:17 |
| fwereade | dimitern, ah, ok, I'm still readin that one I'm afraid | 08:17 |
| dimitern | fwereade: Units.Get does not impose any additional authorization, beyond the requireAgent stuff which happens at srvRoot.Units() | 08:18 |
| fwereade | dimitern, anyway that's a side issue really -- the really important thing is to nail down agreement with wallyworld, I think | 08:18 |
| dimitern | fwereade: agreed | 08:18 |
| fwereade | dimitern, hmm, I think that's probably wrong -- I'd prefer to be as restrictive as possible by default, really | 08:19 |
| fwereade | dimitern, nobody gets any information we can't be sure they need ;p | 08:19 |
| dimitern | fwereade: well, you cannot really do anything even once you get a unit - any other call which is mutating *has* auth | 08:19 |
| dimitern | fwereade: but ok, I can change that to be more restrictive - like the check in Units.SetPassword perhaps? | 08:20 |
| dimitern | fwereade: if !u.root.authOwner(unit) && !u.root.authDeployer(unit) | 08:20 |
| fwereade | dimitern, yeah, that sgtm, I think... I'm just wondering whether it's ok to tell unauthorized clients the difference between a missing entity and one they're just not allowed access to | 08:21 |
| fwereade | dimitern, it might not matter, but there's a definite parallel with common practice logging into, say, a website | 08:22 |
| dimitern | fwereade: as it is right now, they'll get not found before they get unauthorized | 08:22 |
| dimitern | fwereade: cf. tests with foo/42 | 08:22 |
| fwereade | dimitern, you don't say "wrong password" and thereby leak the existence of an account with a given email address | 08:22 |
| fwereade | dimitern, you just say "email/password didn't match" (and thereby, ofc, frustrate users who can't remember which email account they signed up with ;p) | 08:23 |
| dimitern | fwereade: i see your point, but what's the action? :) | 08:24 |
| dimitern | fwereade: should we postpone CodeNotFound until we checked the user is actually authorized? | 08:24 |
| fwereade | dimitern, report not-found for anything you try to access but aren't allowed to | 08:24 |
| fwereade | dimitern, the trouble is I'm not certain that this is a good idea | 08:24 |
| fwereade | dimitern, but nor am I certain it isn't | 08:24 |
| dimitern | fwereade: so why is CodeUnauthorized there for at all? | 08:25 |
| fwereade | dimitern, there's definitely a use case for it -- trying to modify an entity in an unacceptable way | 08:25 |
| dimitern | fwereade: remember, if you got as far as to call that method you're at least an authorized agent | 08:25 |
| fwereade | dimitern, eg the deploying machine should be able to get some access to a unit it's responsible for, but it shouldn't be able to set it to Dying | 08:26 |
| dimitern | fwereade: i think i might be a good idea not to lie about things like that and make debugging much harder | 08:26 |
| fwereade | dimitern, yeah, there's always a tension between security and transparency ;) | 08:26 |
| jam | fwereade: I don't think we've actually had a discussion of the privacy model for Juju. | 08:27 |
| jam | I'd like to at least bring up the 'helpful hints when you make a mistake' vs the 'dont leak secrets' | 08:27 |
| fwereade | jam, quite so | 08:27 |
| jam | fwereade: I think it would be reasonable to code Juju more along the lines of "if you have at least authorized with an account, we will give you more helpful errors". Though I guess | 08:28 |
| jam | we run some untrusted code | 08:28 |
| jam | in the Charm hooks, right? | 08:28 |
| jam | so maybe we should be more defensive. | 08:28 |
| jam | I'm not entirely sure what would leak if you knew that there was a specific service running. | 08:28 |
| jam | fwereade: and then there is multitenancy | 08:28 |
| fwereade | jam, remember that this is the agent context, though -- I would prefer that we be defensive in that context to guard against agent compromise (both by malicious actors, and by our own mistakes) | 08:28 |
| jam | fwereade: well given the existing model of everyone-has-root-everywhere, it is good to get away from them. Finding a decent happy point is good. | 08:29 |
| fwereade | jam, yeah, but not-being-sure-what-would-leak is kinda my problem -- being as restrictive as possible, at least for the private API, seems like a sensible default position | 08:29 |
| jam | fwereade: also, what about readonly mode? | 08:30 |
| jam | is that just again for the public apis? | 08:30 |
| fwereade | jam, readonly mode is a Client thing, not an agent thing, I think | 08:30 |
| fwereade | jam, I don't think there's a use case for an agent that can connect but not actually fulfil its duties | 08:30 |
| fwereade | jam, and I don't *think* there's much confusion about an agent's duties | 08:31 |
| jam | fwereade: at that point Client looks like a really wide API, rather than "some client-level requests about Units". | 08:31 |
| jam | Which I think is why there is occasional confusion. | 08:32 |
| jam | I think I understand that each Process that talks to the API should generally be talking to one of the top level endpoints? | 08:32 |
| fwereade | jam, hmm -- a user will be talking to Client | 08:32 |
| fwereade | jam, at the moment an agent will potentially want to talk to several of the root objects | 08:33 |
| fwereade | jam, but not to client | 08:33 |
| jam | fwereade: yep, that is 1 process (juju FOO) talking to 1 top level API (Client) | 08:33 |
| jam | But Machine agents might want to talk to Unit? | 08:33 |
| fwereade | jam, quite so | 08:33 |
| fwereade | jam, I would be happiest if they were to be *very* heavily restricted | 08:34 |
| fwereade | jam, but the set of relevant information, and allowable operations, is a bit messy | 08:34 |
| jam | fwereade: so is it possible to say that Machine can only talk about Units that are on that machine? Is that reasonably structured internally that it can be queried easily? | 08:34 |
| jam | The only specific logic I've seen so far is "Are you an Agent" | 08:35 |
| fwereade | jam, yeah, should be | 08:35 |
| jam | vs Are you the Agent for Machine X when requesting actions on X | 08:35 |
| fwereade | jam, yeah, "are you an agent" is IMO of limited value | 08:35 |
| fwereade | jam, "are you agent X" is a more suitable model in general, I think | 08:36 |
| fwereade | jam, I'm not 100% sure, but I think that in the vast majority of cases it is simple to tell what entity has responsibility for what operations on what entities | 08:37 |
| dimitern | jam: not quite right | 08:38 |
| dimitern | jam: there are both "are you an agent" (requireAgent) when connecting | 08:38 |
| dimitern | jam: and "are you the machine agent for machine X" authOwner(machine) | 08:38 |
| fwereade | dimitern, jam: it crosses my mind that it *might* be good to partition the APIs by client-task | 08:43 |
| fwereade | dimitern, jam: this would perhaps satisfy wallyworld's concerns | 08:44 |
| dimitern | fwereade: by client-task? | 08:44 |
| fwereade | dimitern, the provisioner service, for example, provides all functionality required by the provisioner task | 08:44 |
| fwereade | dimitern, downside is that there will be some overlap of responsibility | 08:45 |
| dimitern | fwereade: hmm.. that's not a bad idea | 08:45 |
| dimitern | fwereade: but are we deciding to break state api compatibility completely then? | 08:45 |
| fwereade | dimitern, ie a Machiner is allowed to set its machine to Dead; and so is a Provisioner | 08:45 |
| fwereade | dimitern, yeah, it might be hard to do without having some impact on the client code, that is also a valid concern | 08:46 |
| dimitern | fwereade: *some* impact? :) | 08:46 |
| fwereade | dimitern, ;) | 08:46 |
| fwereade | dimitern, I don't like to overstate things, it makes people jumpy ;p | 08:47 |
| dimitern | fwereade: :) yeah, I know what you mean | 08:47 |
| jam | dimitern: If the actual API call takes the same args and has the same net effect, then the client impact is just renaming what method you are calling. Which is an effect, but it isn't massive. | 08:48 |
| dimitern | fwereade: then maybe we should decide should we throw away what's already there in the workers and rewrite them one by one to use the api, while keeping the others using state | 08:48 |
| dimitern | fwereade: if we do that, everything goes for the client-side agents api | 08:49 |
| fwereade | dimitern, that's what we're doing already, really, it's just we've been trying to minimize the difference between the two versions | 08:50 |
| fwereade | dimitern, and we still should -- but we shouldn't take the original form to be sacrosanct | 08:50 |
| fwereade | dimitern, the difference between having a global api.Machine and a provisioner.Machine, for example, is actually quite minimal | 08:51 |
| fwereade | dimitern, (vs machiner.Machine) | 08:51 |
| dimitern | fwereade: true | 08:52 |
| dimitern | fwereade: i'm beginning to like it more and more | 08:52 |
| fwereade | dimitern, and it has benefits in that we make it much harder to screw up auth on methods that are relevant for two very different clients in very different contexts | 08:53 |
| dimitern | fwereade: there'll be some duplication (machiner.Machine and provisioner.Machine will basically be the same, but this can be fixed by helpers) | 08:53 |
| fwereade | dimitern, however, I'm not necessarily sure that task-graining is quite right -- job-graining *might* be better | 08:53 |
| fwereade | dimitern, thoughts? | 08:53 |
| dimitern | fwereade: it actually simplifies the authorization a lot - we can do it on the top-level - "are you a provisioner?" ok - get the api.Provisioner end point, and no more checks inside the calls themselves | 08:54 |
| fwereade | dimitern, yeah | 08:54 |
| fwereade | dimitern, I'm considering the distinction between the Provisioning endpoint and the EnvironManagement endpoint | 08:55 |
| dimitern | fwereade: i can see more benefits as well - it isolates us nicely from the exact state api | 08:55 |
| fwereade | dimitern, yeah | 08:55 |
| dimitern | fwereade: so job vs. agent? | 08:55 |
| fwereade | dimitern, yeah: I can't tell which is right though :) | 08:56 |
| dimitern | fwereade: the jobs (tasks/workers) are the ones actually doing stuff, while the agent has little to do with state anyway | 08:56 |
| fwereade | dimitern, a job is a group of tasks/workers | 08:56 |
| dimitern | fwereade: (it shouldn't deal with state at all I think, or if it should, it can use the worker api instead perhaps?) | 08:56 |
| dimitern | fwereade: yeah, correct | 08:57 |
| fwereade | dimitern, I'm concerned right now with whether job granularity is better, or task granularity | 08:57 |
| dimitern | fwereade: if we choose tasks, authz gets easier (at end point only) | 08:58 |
| fwereade | dimitern, maybe auth should be grouped by job, but actual service endpoints should be split by task? | 08:58 |
| dimitern | fwereade: if we choose jobs, there has to be more authz inside methods as well | 08:58 |
| fwereade | dimitern, it does act to fossilize the jobs | 08:58 |
| fwereade | dimitern, but maybe that's a worthwhile proce, because the original idea of making them flexible will be kinda hard to carry off regardless | 08:59 |
| fwereade | dimitern, and maybe it's not even any worse than it will be *whatever* we do | 08:59 |
| fwereade | dimitern, this plausibly lets us split the whole damn api up into sensible packages though | 09:00 |
| fwereade | dimitern, and that idea makes me very happy | 09:00 |
| fwereade | dimitern, state is a monster | 09:00 |
| === davecheney is now known as Jibbers_McGee | ||
| fwereade | dimitern, and it'll be hard to ever unmonster that, because it's responsible for cross-entity consistency, sanity, etc | 09:01 |
| dimitern | fwereade: bbiab, sorry - 1-1 | 09:01 |
| fwereade | dimitern, no worries, ttyl | 09:01 |
| fwereade | dimitern, (fwiw, I think the job/task granularity question can be decided a little way down the line: pick one by gut, keep an eye on it, fix it before we release if it seems to be crazy in short-term hindsight) | 09:05 |
| fwereade | dimitern, (by-job is probably easier, fwiw) | 09:06 |
| fwereade | dimitern, (no response necessary while you're busy ;p) | 09:06 |
| === Jibbers_McGee is now known as davecheney | ||
| dimitern | fwereade_: back\ | 09:31 |
| dimitern | fwereade_: fwiw, task-based interface seems better to me | 09:33 |
| TheMue | dimitern: rogers new task runner isn't yet merged, isn#t it? | 09:36 |
| dimitern | TheMue: it is, but it's not used yet | 09:36 |
| TheMue | dimitern: hmm, seems i'm looking at the wrong places :) | 09:36 |
| dimitern | TheMue: worker/runner.go | 09:37 |
| TheMue | dimitern: thx | 09:37 |
| === alexlist` is now known as alexlist | ||
| fwereade_ | dimitern, let's go with per-task then | 09:39 |
| fwereade_ | dimitern, definitely makes it easier to shift tasks between jobs, which I expect we'llneed at some point | 09:39 |
| dimitern | fwereade_: cool, I can throw together a proposal of the interface | 09:39 |
| fwereade_ | dimitern, great | 09:39 |
| dimitern | fwereade_: should I start with the provisioner? | 09:40 |
| fwereade_ | dimitern, best not, frank is up to the elbows in that at the moment | 09:41 |
| fwereade_ | dimitern, let's go with machiner to start with | 09:41 |
| dimitern | fwereade_: ok | 09:41 |
| fwereade_ | dimitern, which I *think* is an absolutely minimal set of data and methods | 09:41 |
| TheMue | fwereade_, dimitern: +1 | 09:41 |
| fwereade_ | dimitern, no need to include pinger | 09:41 |
| TheMue | ;) | 09:41 |
| dimitern | fwereade_: sure | 09:42 |
| fwereade_ | dimitern, I'm not sure how we address wallyworld's concerns re statefulness and connectionlessness | 09:44 |
| fwereade_ | dimitern, the latter is a necessity given routing issues, and the former is a consequence thereof AFAICT | 09:45 |
| fwereade_ | dimitern, I agree that we're more stateful than we need or want to be long-term, but I don't think it should be addressed today | 09:45 |
| fwereade_ | dimitern, does that roughly align with your understanding? | 09:45 |
| dimitern | fwereade_: exactly | 09:46 |
| fwereade_ | dimitern, cool | 09:46 |
| fwereade_ | TheMue, btw, I noted a comment of yours in the loggo CL: "TODO for whom?" | 09:48 |
| fwereade_ | TheMue, AIUI the badging by name is not "who should do this", it's "who should I talk to about this when I hit it" | 09:48 |
| fwereade_ | TheMue, if person X is refactoring package Y and sees TODO(Z), and doesn't immediately understand all relevant context, X should talk to Z and take the resulting discussion into account when changing Y | 09:50 |
| fwereade_ | s/refactoring/working in/ | 09:51 |
| TheMue | fwereade_: ok | 09:51 |
| TheMue | fwereade_: i only know lonely todos as those which never will be done | 09:52 |
| fwereade_ | TheMue, so I'm not convinced that TODOs *always* require a badge -- it's just a pointer that is expected to persist better than `bzr annotate` | 09:53 |
| fwereade_ | TheMue, I hadn't seen a badged TODO as a commitment to actually DO :) | 09:53 |
| TheMue | fwereade_: it's just short than // HASTOBEDONEONCEWHENANYBODYHASTIME ;) | 09:54 |
| fwereade_ | TheMue, yeah :) | 09:55 |
| TheMue | fwereade_: I take them typically as hints for me that I have to do further work here in a second or third step | 09:55 |
| fwereade_ | TheMue, sure, it's *great* when someone adds a badged TODO and fixes it 3 days later | 09:56 |
| TheMue | fwereade_: *rofl* | 09:56 |
| fwereade_ | TheMue, but I still feel the badge serves the purpose I suggested: to warn others to chat to X before diving in (and thereby discover, hey, it's being done :)) | 09:57 |
| TheMue | fwereade_: btw, just a question. it seems to me my "anybody" has been wrong and "somebody" would be the correct term. am i right? | 09:57 |
| fwereade_ | TheMue, either reads ok in that context, I think, but maybe "somebody" wins on a technicality | 09:58 |
| TheMue | fwereade_: fine, thanks, still learning | 09:58 |
| dimitern | fwereade_: there it is -> https://docs.google.com/a/canonical.com/document/d/1Yd2Nil43AemnBq8qv003OkWLptiPzuhWGESBcwlI7Nc/edit?usp=sharing | 10:16 |
| dimitern | wallyworld, jam: ^^ | 10:19 |
| fwereade_ | dimitern, cheers | 10:19 |
| fwereade_ | dimitern, hmm, all of those things STM to be better expressed client-side as methods on a *Machine, as before | 10:25 |
| dimitern | fwereade_: i was trying to avoid this | 10:26 |
| dimitern | fwereade_: and make wallyworld happy as a side-effect :) | 10:26 |
| fwereade_ | dimitern, yeah, we should talk to wallyworld about what his objections to the agreed (I thought) client-side API are | 10:27 |
| fwereade_ | dimitern, the client side should be fixed if it's stupid, sure | 10:27 |
| fwereade_ | dimitern, but we don't have to write the client-side code as a perfect clone of the API we use to implement it | 10:28 |
| dimitern | fwereade_: not sure i understand the last statement.. | 10:29 |
| fwereade_ | dimitern, Machine.SetStatus(foo, bar) can call MachinerService.SetStatus([]MachineStatus{{id, foo, bar}}), and then we get both a helpful long-term API, and a helpful form of code on the client side | 10:30 |
| dimitern | fwereade_: there's not MachinerService - at server-side we still use Machines.SetStatus, etc. | 10:32 |
| * TheMue is at lunch, bbiab | 10:32 | |
| dimitern | fwereade_: the Machiner facade is client-side only | 10:32 |
| dimitern | fwereade_: at least that's what I understood | 10:33 |
| fwereade_ | dimitern, hmm, it seemed to me that we'd get the best of it from doing it server-side -- doing it client-side kinda misses the SOA point I think? | 10:33 |
| fwereade_ | dimitern, that's where we need the auth etc after all | 10:34 |
| dimitern | fwereade_: hmm.. good point | 10:34 |
| fwereade_ | dimitern, MachinerService (or whatever) thus maps approximately to the *State we pass into workers today | 10:34 |
| dimitern | fwereade_: so then the client-side API is just a 1-1 mapping to the server-side | 10:34 |
| dimitern | fwereade_: how about bulk operations then? | 10:35 |
| fwereade_ | dimitern, well, the client-side API can look much as it currently does, but expressed in task-specific terms over the wire | 10:35 |
| fwereade_ | dimitern, I *think* we still want bulk ops, on the basis that they're forward-sensible even if we never use them, and boxing/unboxing is little hassle | 10:36 |
| dimitern | fwereade_: that's exactly what wallyworld was agains aiui | 10:36 |
| fwereade_ | dimitern, he was against bulk ops? | 10:36 |
| fwereade_ | dimitern, ah sorry, against keeping the existing client-side API? | 10:36 |
| dimitern | fwereade_: no, against client-side objects even when they are proxying to server-side services | 10:36 |
| dimitern | fwereade_: yeah | 10:36 |
| dimitern | fwereade_: how about a hybrid approach? | 10:37 |
| fwereade_ | dimitern, changing that is IMO busywork with no benefit, and it obscures the actual logic of the machiner | 10:37 |
| fwereade_ | dimitern, a machiner's about messing around with a single machine | 10:38 |
| dimitern | fwereade_: still have Machines at server-side, with bulk ops, as now, but in addition have the Machiner facade as well | 10:38 |
| dimitern | fwereade_: which will use the machines service but for a single machine | 10:39 |
| fwereade_ | dimitern, IMO the per-task facades make sense server-side, and let us drop the Machines, Units, etc service-alikes he';s not keen on | 10:39 |
| fwereade_ | dimitern, the issue with "Machines" is that it's a weird division and not very servicey | 10:39 |
| dimitern | fwereade_: not really - the "service" deals with machines | 10:39 |
| dimitern | fwereade_: that's like openstack api for servers | 10:40 |
| fwereade_ | dimitern, yeah, but lots of things deal with machines -- splitting by entity kind seems weaker than splitting by groups of business-logic ops that fit well together | 10:40 |
| dimitern | fwereade_: ok, if we do that, then i cannot see where the bulk ops come into play | 10:41 |
| dimitern | fwereade_: if the api is task-oriented (which is still SOA imho), then we don't really need bulk ops at all | 10:41 |
| dimitern | fwereade_: we'll need them only for client-facing apis like for the gui/cli | 10:42 |
| fwereade_ | dimitern, consider the provisioner -- where long-term we'll want Lifes, InstanceIds, etc | 10:42 |
| fwereade_ | dimitern, the machiner doesn't need them now and perhaps never will | 10:43 |
| fwereade_ | dimitern, but habitually expressing things as bulk ops means we never need to make that decision, and hence never run the risk of getting it wrong | 10:43 |
| dimitern | fwereade_: fair enough, then we'll introduce bulk ops on methods of the task facades, as needed | 10:43 |
| fwereade_ | dimitern, I agre that in the narrow machiner context we probably never will | 10:43 |
| dimitern | fwereade_: but not *everywhere by default* | 10:43 |
| fwereade_ | dimitern, I'm advocating everywhere by default, because the cost of doing so is low and it inculcates good habits | 10:44 |
| dimitern | fwereade_: the cost is not low at all in the case of the machiner | 10:44 |
| fwereade_ | dimitern, expand please | 10:44 |
| dimitern | fwereade_: if the facade operates on a single machine, why do we need to pretend is works on multiple machines? | 10:45 |
| fwereade_ | dimitern, because, say, getting machine life *is* an op we will need in bulk | 10:45 |
| dimitern | fwereade_: on the other hand, for the provisioner - most ops will be bulk, but still they're on the facade as methods | 10:45 |
| fwereade_ | dimitern, the machiner only wants one at a time, but the provisioners will want N | 10:45 |
| dimitern | fwereade_: if we're talking about eventually changing the underlying state API to default to bulk ops, i agree | 10:46 |
| fwereade_ | dimitern, we can then make the auth the responsibility for the facades, and implement the machine-life-getting separately, as called by both | 10:46 |
| dimitern | fwereade_: but for the case of the machiner single ops suffice | 10:46 |
| dimitern | fwereade_: so you're talking about a hybrid approach after all - having both Machines (w/ bulk ops by default), and facades, using Machines as well - in case of machiner single ops, with the provisioner - bulk ops? | 10:47 |
| fwereade_ | dimitern, no... Machines should never be exposed | 10:48 |
| dimitern | fwereade_: i'm not saying it should be | 10:48 |
| fwereade_ | dimitern, but an apiserver-internal Machines might actually fit very nicely | 10:48 |
| dimitern | fwereade_: it can be an internal "service" | 10:48 |
| dimitern | fwereade_: exactly | 10:48 |
| fwereade_ | dimitern, and having the various services expressed with a consistent vocabulary is IMO an end in itself | 10:48 |
| dimitern | fwereade_: ok, it gets clearer now | 10:49 |
| dimitern | fwereade_: apiserver.machines, units, etc. are there | 10:49 |
| dimitern | fwereade_: and the exposed facades apiserver.Machiner, etc. use them internally | 10:50 |
| dimitern | fwereade_: this simplifies the srvmachines implementation, because it doesn't have to care about authz at all | 10:50 |
| dimitern | fwereade_: it'll be done on the facades only | 10:50 |
| dimitern | fwereade_: does it make sense? | 10:51 |
| fwereade_ | dimitern, yes, with the caveat that the thing I want to prescribe is that the data on the wire be expressed as (1) bulk ops on (2) business-logic-level services; the internal services are a possible implementation detail that seems ATM like a good idea, but which doesn't lock us into anything going forward | 10:51 |
| fwereade_ | dimitern, yeah | 10:51 |
| fwereade_ | dimitern, the rason I'm quibbling about the internal machines is that we'll actually want that stuff to migrate into the *state* package long-term, I think | 10:52 |
| dimitern | fwereade_: see, now I'm not following you | 10:52 |
| fwereade_ | dimitern, so we can do bulk *db* ops to get, say, life for 10k machines in one go | 10:52 |
| dimitern | fwereade_: bulk ops *on-the-wire* applies only to the exposed facades' methods | 10:52 |
| fwereade_ | dimitern, without having to suck up 10k lists of assigned units as well | 10:53 |
| fwereade_ | dimitern, yeah, that is my primary focus | 10:53 |
| dimitern | fwereade_: ok, then we're on the same page | 10:53 |
| fwereade_ | dimitern, but it supports, in the long term, smarter and more efficient usage of the underlying db | 10:53 |
| fwereade_ | dimitern, and so while a Machines service is probably a good idea today, it's not a prerequisite for what I'm after | 10:54 |
| dimitern | fwereade_: agreed - once we're free to develop the state api w/o having to worry about breaking the agents, we can improve the actual calls to be bulk | 10:54 |
| fwereade_ | dimitern, and as soon as we've isolated state from everything except the API server, we start to be able to slice and dice the interface of the *state* package such that things like the Machines service become redundant | 10:55 |
| fwereade_ | dimitern, exactly | 10:55 |
| dimitern | fwereade_: i'll change the proposal to reflect what we just discussed then | 10:55 |
| fwereade_ | dimitern, <3 | 10:55 |
| fwereade_ | dimitern, is your standup about to start? | 10:57 |
| dimitern | fwereade_: in 30m | 10:57 |
| fwereade_ | dimitern, ok, cheers -- if I'm afk when wallyworld's ready for a chat, text me please, I'd like to make sure we're all on the same page asap rather than waste your time again :) | 10:59 |
| dimitern | fwereade_: sure, np :) | 11:00 |
| wallyworld | fwereade_: dimitern: hi, i just got back from soccer, did you guys want a chat? | 11:02 |
| dimitern | wallyworld: now or after standup? jam said he won't be around until standup time | 11:04 |
| wallyworld | now is fine | 11:04 |
| dimitern | fwereade_: you as well can chat now? | 11:05 |
| dimitern | wallyworld: just a sec, texting fwereade_ | 11:08 |
| fwereade_ | wallyworld, dimitern, sgtm | 11:08 |
| dimitern | fwereade_, wallyworld: ok https://plus.google.com/hangouts/_/7964c6d4ac01386655b7ddf69dbc9cd43365a91a?authuser=0&hl=en | 11:08 |
| danilos | jam, dimitern, hi, are we having a stand-up? | 11:35 |
| jam | yep! | 11:38 |
| fwereade_ | wallyworld, look at it like this: by delivering an API, we create real value right now wrt things the business needs *soon*; by refactoring all the client code on top of that, we just increase risk. Maintaining the domain-object style of the pre-existing client code is cheap and easy, and does *not* make it any harder to fix later; but trying to fix the programming model right now across the board *does* impact our ability to deliver real value | 11:40 |
| * fwereade_ lunch | 11:40 | |
| dimitern | fwereade_: ping me when you're back please | 12:02 |
| fwereade_ | dimitern, ping | 12:03 |
| dimitern | fwereade_: i'll start a hangout | 12:04 |
| dimitern | fwereade_, wallyworld, jam: https://plus.google.com/hangouts/_/609bce415113fdec03001e8ade27f75c41945d7e?authuser=0&hl=en | 12:04 |
| === wedgwood_away is now known as wedgwood | ||
| === wedgwood is now known as Guest21017 | ||
| === wedgwood_ is now known as wedgwood | ||
| === tasdomas is now known as tasdomas_afk | ||
| fwereade_ | someone else please review https://codereview.appspot.com/9641044/ for frankban | 15:19 |
| fwereade_ | ttfn guys, I'll be around again later tonight | 15:26 |
| FunnyLookinHat | Anyone here know why I'd be getting a 411 Length Required error when trying to bootstrap? Is the client request class not sending proper headers for some reason? | 15:37 |
| FunnyLookinHat | I can't determine if the headers are being attached or not because I haven't found a way to dump the requests being sent :-( | 15:37 |
| === hatch_ is now known as hatch | ||
| arosales | ran into this juju core bug this weekend | 17:11 |
| arosales | https://bugs.launchpad.net/juju-core/+bug/1187062 | 17:11 |
| arosales | is anyone else running into this on HP's cloud? | 17:11 |
| fwereade_ | arosales, `juju image-metadata -i 81078` will generate a pair of files somewhere inside $JUJU_HOME that you need to upload to your public-bucket | 17:33 |
| fwereade_ | arosales, I thought wallyworld sent a mail about it, but I could be wrong | 17:34 |
| arosales | fwereade_, to juju list or juju-dev | 17:34 |
| fwereade_ | arosales, I can't seem to find it so that may just have been a fever dream | 17:34 |
| arosales | I very well could have missed it too | 17:34 |
| * arosales running behind on list email | 17:35 | |
| fwereade_ | arosales, I'm pretty sure that if you run that command, though, it tells you what to do next | 17:35 |
| fwereade_ | arosales, sorry drive-by, I'm not really at work any more | 17:35 |
| arosales | fwereade_, do I get 'juju image-metadata" with the ppa juju-core? | 17:35 |
| arosales | or do I need to do that from source? | 17:35 |
| fwereade_ | arosales, hmm, I will be upset if we released simplestreams-only without including the workaround | 17:36 |
| fwereade_ | arosales, run that command and rage at me if it doesn't help you :) | 17:36 |
| arosales | fwereade_, will do | 17:37 |
| arosales | I had to remove juju core | 17:37 |
| arosales | and had to fall back to juju for my demo this weekend | 17:37 |
| fwereade_ | arosales, dammit, sorry about that :( | 18:10 |
| fwereade_ | arosales, I'm often around at antisocial hours but was ill last w/e | 18:10 |
| fwereade_ | arosales, was that the problem? | 18:10 |
| arosales | fwereade_, no worries | 18:10 |
| arosales | had a demo at texas linux fest I had to fall back to .7 for | 18:11 |
| jcastro | arosales: did the demo go well overall? | 18:26 |
| arosales | jcastro, ya .7 went well | 18:27 |
| arosales | had good interest and questions. | 18:28 |
| arosales | fwereade_, do you know what the valid inputs are for series? | 19:14 |
| arosales | http://pastebin.ubuntu.com/5730353/ ? | 19:14 |
| fwereade_ | arosales, you don't want the "="s in there | 20:51 |
| fwereade_ | arosales, `juju image-metadata -s precise ...` | 20:52 |
| wallyworld | fwereade_: arosales: just saw the backscroll - i did send emails and it's in the release notes how to use image-metadata to generate local simplestreams data | 20:52 |
| fwereade_ | wallyworld, yeah, I *thought* you had, I must just be stupider than I look | 20:53 |
| wallyworld | i tested with canonistack | 20:53 |
| wallyworld | you do not look *that* stupid :-) | 20:54 |
| arosales | still getting http://pastebin.ubuntu.com/5730651/ | 20:54 |
| arosales | fwereade_, thanks or the response btw, I know it is late for you. | 20:54 |
| fwereade_ | arosales, no worries :) | 20:55 |
| wallyworld | arosales: did you copy those files to your public bucket? | 20:55 |
| fwereade_ | arosales, I don't think you want any of those "="s at all, fwiw | 20:55 |
| arosales | wallyworld, no I didn't. | 20:56 |
| arosales | I suspect I should find the release notes and follow the instructions . . . | 20:56 |
| wallyworld | arosales: it's in the instructions - perhaps i need to make it clearer | 20:56 |
| arosales | fwereade_, noted on the "=" | 20:56 |
| wallyworld | it's also on the command line after you run the command | 20:56 |
| wallyworld | arosales: i haven't come across a meeting invite - you said you scheduled one for tomorrow? i only just woke up so may be not have found it in my inbox | 20:59 |
| thumper | morning | 21:00 |
| thumper | hi wallyworld | 21:01 |
| thumper | wallyworld: early for you | 21:01 |
| wallyworld | thumper: hi, how's the dog | 21:01 |
| thumper | bouncy | 21:01 |
| wallyworld | yeah | 21:01 |
| wallyworld | i bet | 21:01 |
| wallyworld | the girls like him? | 21:01 |
| thumper | oh yes | 21:02 |
| thumper | and her | 21:02 |
| thumper | pepper is a girl | 21:02 |
| thumper | I think I'll call her pepper pots | 21:02 |
| wallyworld | ah, i forgot | 21:02 |
| wallyworld | dogs are great. we love ours | 21:02 |
| thumper | she has settled down now | 21:02 |
| wallyworld | yeah, takes a day or two | 21:03 |
| thumper | I've moved into the lounge so I can close it off and watch her | 21:03 |
| thumper | well everyone else has left | 21:03 |
| thumper | kids at school | 21:03 |
| thumper | and rachel at work | 21:03 |
| wallyworld | i gotta go do school drop off now. back after breakfast etc | 21:03 |
| arosales | wallyworld, ah I forgot to add you to the invite | 21:04 |
| arosales | wallyworld, sorry | 21:04 |
| arosales | which makes the scheduling tuff | 21:05 |
| arosales | wallyworld, fwereade_ regarding simple streams. As this is a fundamental change to the way users expect Juju to work do you plan on making this backwards compatible or optional? | 21:06 |
| arosales | ie the use of simple streams? | 21:06 |
| fwereade_ | arosales, simplestreams is intended to be the One True Way going forward; but we hope that for most public clouds we wil be publishing everything needed via cloud-images.ubuntu.com | 21:07 |
| arosales | wallyworld, perhaps I can follow up with you and dave later in the evening regarding simple streams | 21:09 |
| arosales | fwereade_, gotcha. Now we just need to be sure we are publishing everything to cloud-image.ubuntu.com | 21:09 |
| fwereade_ | arosales, yeah; there has an issue with us publishing unsigned simplestreams data to the HP bucket, misrepresenting the images as being Official Ubuntu Images -- I think there's a thread you're in somewhere..? | 21:11 |
| * fwereade_ looks at his mail again | 21:11 | |
| arosales | ya, I think I saw ben howard raise that concern | 21:12 |
| fwereade_ | arosales, I've just accepted the invite for tomorrow, thanks | 21:12 |
| arosales | fwereade_, thanks. I"ll follow up with wallyworld and dave later in the US day to get their input/feedback too. | 21:13 |
| wallyworld | arosales: sorry, was doing school drop off | 21:51 |
| arosales | wallyworld, no worries | 22:08 |
| * thumper takes the dog for a walk... | 22:11 | |
| wallyworld | arosales: ping me today if you have any immediate questions, or otherwise we can ensure everyone is on the same page tomorrow at the meeting | 22:42 |
| arosales | wallyworld, will do. I am seeing a few interesting stack traces in go-juju | 22:48 |
| arosales | but perhaps that is just my environment. | 22:48 |
| arosales | if it is repeatable I will open up a bug for triage | 22:48 |
| wallyworld | yeah, we would love to get all these things fixed | 22:49 |
| wallyworld | we're not seeing them as devs but end users have all sorts of different set ups | 22:49 |
| wallyworld | and we know that if there are issues (with env or whatever), we need to, in places, improve the error reporting etc | 22:50 |
| wallyworld | thumper: back from the walk? | 23:09 |
| thumper | wallyworld: yeah, have been for ages | 23:09 |
| thumper | the dog doesn't take long walks | 23:09 |
| thumper | yet | 23:09 |
| thumper | and it is cold outside | 23:09 |
| thumper | I had to coax her out | 23:09 |
| wallyworld | i bet | 23:09 |
| wallyworld | quick chat? | 23:09 |
| thumper | sure | 23:09 |
| wallyworld | https://plus.google.com/hangouts/_/d3f48db1cccf0d24b0573a02f3a46f709af109a6 | 23:10 |
| mramm | thumper: you around? | 23:12 |
| thumper | mramm: yep, chatting with wallyworld now | 23:12 |
| mramm | thumper: cool! | 23:12 |
| mramm | thumper: got time to chat for a few in like 15 min? | 23:13 |
| thumper | mramm: wallyworld said to talk to you first | 23:13 |
| mramm | hahaha | 23:13 |
| mramm | ok | 23:13 |
| thumper | he said it like "mramm is in a worse timezone and needs sleep, so talk to him first" | 23:13 |
| mramm | hahaha | 23:13 |
| mramm | I guess I was at a meeting with him 12 hours ago | 23:14 |
| thumper | mramm: are you starting a hangout/ | 23:14 |
| thumper | ? | 23:14 |
| mramm | yep | 23:14 |
| mramm | one sec | 23:14 |
| thumper | wallyworld: I'm off with mramm now | 23:38 |
| wallyworld | ok | 23:38 |
| wallyworld | same url as before | 23:38 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!