| davecheney | var m = make(map[string]int) | 00:00 |
|---|---|---|
| davecheney | type T struct { name string } | 00:01 |
| * thumper is beginning to want proper inheritance in go... | 01:26 | |
| * thumper sighs | 01:26 | |
| * thumper has another thought... | 01:28 | |
| thumper | gah, must finish something before starting another | 01:28 |
| * thumper puts head down again | 01:28 | |
| thumper | davecheney: by splitting out the SetFlags from the Init, a bunch of tests are failing... | 02:22 |
| thumper | davecheney: as they are testing Init | 02:22 |
| thumper | davecheney: is there a place where we put helper test functions? | 02:22 |
| thumper | davecheney: for example, jujud/agent_test.go has a method called initCmd | 02:23 |
| thumper | which creates some flags, and calls init | 02:23 |
| thumper | I added the setflags to it, and I'd like to make the function more generally useful in other tests | 02:23 |
| * thumper guesses davecheney is at lunch | 02:27 | |
| davecheney | thumper: generally suite_test.go is a good start | 02:43 |
| davecheney | but i think you have to leiway to create your own tradition | 02:43 |
| thumper | whoever thought that "c *C" were good params for tests should be given a very stern look | 04:00 |
| * thumper jumps through hoops | 04:16 | |
| * thumper wonders if 1000 lines of diff are enough for first change to juju | 04:21 | |
| davecheney | thumper: i'd say most things are up for grabs if you are prepared to argue your case | 04:27 |
| thumper | hmm... | 04:27 |
| thumper | davecheney: are there dependencies between the juju-core packages that I have to make sure I don't screw up? | 04:28 |
| davecheney | thumper: not sure i parsed that correctly | 04:31 |
| thumper | davecheney: there are tests lying around... | 04:31 |
| thumper | davecheney: and I want to put some common command test helper methods into juju-core/testing | 04:31 |
| davecheney | kk | 04:32 |
| thumper | which would add a depencency on juju-core/cmd | 04:32 |
| thumper | which I don't think is there yet | 04:32 |
| thumper | likely to be fine? | 04:32 |
| davecheney | sure | 04:32 |
| thumper | kk | 04:32 |
| davecheney | I'm sure there is alreayd a dep between cmd/juju and cmd | 04:32 |
| davecheney | thumper: go list -f '{{ .Imports }}' launchpad.net/juju-core/cmd/juju | 04:33 |
| davecheney | ^ direct imports of cmd/juju | 04:33 |
| davecheney | go list -f '{{ .Deps }}' launchpad.net/juju-core/cmd/juj | 04:33 |
| davecheney | ^ all transitive deps | 04:33 |
| thumper | ah... | 04:33 |
| thumper | handy | 04:33 |
| thumper | I may try that shortly | 04:33 |
| thumper | holy shit | 04:50 |
| wallyworld_ | thumper: you got your rietveld account all set up for your mp? | 04:50 |
| thumper | realised that my tollerance for duplication in tests is way below some others | 04:50 |
| thumper | wallyworld_: no | 04:50 |
| wallyworld_ | thumper: it's not just tests - i'm finding Go to be very verbose | 04:51 |
| thumper | wallyworld_: this isn't go | 04:51 |
| thumper | it is just code | 04:51 |
| wallyworld_ | yeah agreed, it's also elsewhere | 04:51 |
| thumper | davecheney: umm... if I Ctrl-C the tests while running, have I left things behind that might cause further tests to hang? | 05:08 |
| davecheney | thumper: in theory no | 05:10 |
| davecheney | in practice | 05:10 |
| davecheney | yes, you'll eventyualy leak enough mongo processes to run out of swap | 05:10 |
| davecheney | if you put /tmpfs on swap, then you ahve to be doubly careful | 05:11 |
| davecheney | as each mongo will write 200mb of journal files on startup | 05:11 |
| thumper | hmm... | 05:22 |
| thumper | ok, something to watch for then :) | 05:22 |
| thumper | I'm almost at the state of making all these tests pass again... | 05:22 |
| davecheney | neat | 05:22 |
| thumper | hmm... | 05:22 |
| thumper | $ bzr diff | wc -l | 05:22 |
| thumper | 1467 | 05:22 |
| thumper | although, not quite that bad: 58 files changed, 223 insertions(+), 188 deletions(-) | 05:23 |
| thumper | and much of that is duplicated | 05:23 |
| thumper | ok, I hear the kids home | 05:24 |
| thumper | tests are running, pretty confident | 05:24 |
| thumper | tomorrow lets get this reviewed and landed | 05:24 |
| thumper | night all | 05:24 |
| davecheney | night | 05:25 |
| davecheney | got a branch ? | 05:26 |
| thumper | work up at lp:~thumper/juju-core/command-set-flags if you are curious | 05:26 |
| * thumper signs off | 05:26 | |
| davecheney | kk | 05:26 |
| thumper | and all tests passed \o/ | 05:26 |
| wallyworld_ | davecheney: hi, thanks for finding that data race. what tool did you use? | 06:52 |
| TheMue | Morning | 08:13 |
| dimitern | TheMue: morning! | 08:14 |
| fwereade | dimitern, TheMue, heyhey | 08:25 |
| dimitern | fwereade: hiya | 08:25 |
| TheMue | fwereade, dimitern: Hi | 08:25 |
| fwereade | dimitern, TheMue: fwiw I have a few constraints branches from last night up | 08:25 |
| dimitern | fwereade: yeah, already on these | 08:25 |
| fwereade | dimitern, you rock | 08:26 |
| fwereade | TheMue, you have a trivial LGTM on the deletes branch | 08:26 |
| TheMue | fwereade: Yep, thx, just doing the final merging and test. | 08:26 |
| rogpeppe | mornin' all | 08:28 |
| TheMue | rogpeppe: Hiya | 08:28 |
| rogpeppe | TheMue: yo! | 08:28 |
| dimitern | rogpeppe: morning | 08:28 |
| rogpeppe | dimitern: hi! | 08:28 |
| dimitern | fwereade: you've got 2 reviews | 10:23 |
| fwereade | dimitern, tyvm | 10:23 |
| fwereade | rogpeppe, ping | 10:35 |
| rogpeppe | fwereade: pong | 10:35 |
| fwereade | rogpeppe, last weekend, I had a thought related to the api | 10:35 |
| rogpeppe | fwereade: ok | 10:36 |
| fwereade | rogpeppe, would you agree that the following is a valid perspective: a machine agent can be defined to be trusted, or not, dependent on whether it has a state.Info and can hence connect directly to mongo | 10:36 |
| fwereade | rogpeppe, and that we thus always require that at least one trusted machine exists | 10:37 |
| rogpeppe | fwereade: given that the state.Info contains a valid password, yeah | 10:37 |
| fwereade | rogpeppe, because we need it to run the API server, through which untrusted machine/unit agents will connect | 10:37 |
| rogpeppe | fwereade: yup | 10:37 |
| rogpeppe | fwereade: there must always be at least one API server running | 10:38 |
| fwereade | rogpeppe, ok, so, if we keep the Provisioner and Firewaller just as they are, and only allow them to run on trusted machines -- against a state.Conn, I think you get to cut down the API surface quite pleasingly (and not need to even *touch* the code for the pro/fw) | 10:39 |
| rogpeppe | fwereade: hmm, i'm not sure | 10:40 |
| fwereade | rogpeppe, that way we don't even expose an EnvironConfig API call that returns the user's credentials | 10:40 |
| rogpeppe | fwereade: how does a trusted machine get the credentials in the first place? | 10:40 |
| fwereade | rogpeppe, however it does as it is? sorry, I'm not sure of the impact, can you expand? | 10:41 |
| fwereade | rogpeppe, machine 0 would have it magically; subsequent machine agents that need to run trusted tasks would, I presume, get the state info published to them | 10:41 |
| rogpeppe | fwereade: i'd envisaged that we'd be able to repurpose an existing machine to run any job | 10:41 |
| fwereade | rogpeppe, I had a vague feeling that was in line with the approx plans? | 10:41 |
| fwereade | rogpeppe, yeah, I think we still can | 10:42 |
| rogpeppe | fwereade: so how do we publish the state info to an existing machine? | 10:42 |
| fwereade | rogpeppe, you had the plans for a Publisher of API info, right? why not analogously for state info, but with more restrictions in the API? | 10:43 |
| rogpeppe | fwereade: sure. but surely the place to publish it is in the state, no? | 10:43 |
| fwereade | rogpeppe, yeah, via the API... right? | 10:43 |
| rogpeppe | fwereade: bingo | 10:44 |
| rogpeppe | [10:40:12] <fwereade> rogpeppe, that way we don't even expose an EnvironConfig API call that returns the user's credentials | 10:44 |
| fwereade | rogpeppe, ok, but the attack surface is limited to that one call... much like Login | 10:44 |
| rogpeppe | fwereade: ah, no i see | 10:45 |
| fwereade | rogpeppe, and I *think* the savings form not having to implement the API bits that are only used by trusted workers will be handy | 10:45 |
| rogpeppe | fwereade: yeah, i think that certainly for an interim period, your suggestion is good | 10:45 |
| fwereade | rogpeppe, yeah, we can evaluate how well it works :) | 10:46 |
| rogpeppe | fwereade: rather than having an EnvironConfig call, we have a MongoStateInfo call (or something) which gives untrammelled access to the underlying state | 10:46 |
| fwereade | rogpeppe, btw, ISTM that the tools param to Environ.StartInstance is used very rarely indeed | 10:46 |
| fwereade | rogpeppe, yeah, exactly | 10:46 |
| fwereade | rogpeppe, that information feels like the stuff we also have to give to a machine running another Stater to connect them all up | 10:47 |
| rogpeppe | fwereade: i'm not sure long term though | 10:47 |
| rogpeppe | fwereade: having direct access to the state feels a bit like granting root access | 10:47 |
| fwereade | rogpeppe, don't worry, I'm not laying down cathedral plans ;) | 10:47 |
| fwereade | rogpeppe, sure, agreed | 10:47 |
| rogpeppe | fwereade: and actually neither provisioner or firewaller need that level of access | 10:48 |
| rogpeppe | fwereade: only the API server does | 10:48 |
| fwereade | rogpeppe, agreed -- I am not laying down cathedral plans | 10:48 |
| rogpeppe | fwereade: ok | 10:48 |
| fwereade | rogpeppe, I'm suggesting that it's a good interim goal because it looks like the quickest way to get all our code running with *a* security boundary in place | 10:49 |
| rogpeppe | fwereade: the only difficulty is that the logic in the machiner becomes more complex | 10:51 |
| rogpeppe | fwereade: but that's probably a reasonable tradeoff | 10:52 |
| fwereade | rogpeppe, it feels tolerable, yeah | 10:52 |
| rogpeppe | fwereade: yeah, it looks like we could get rid of the tools arg to StartInstance without losing anything significant | 10:57 |
| rogpeppe | fwereade: trivial CL: https://codereview.appspot.com/7317050 | 11:04 |
| fwereade | rogpeppe, well, I think the tools interact very closely, I'm still trying to figure out the right way to go | 11:07 |
| rogpeppe | fwereade: i managed to reproduce that mongodb "--format provided but not defined error" BTW. i'm not entirely sure which command is drawing that error, hence my trivial CL above. | 11:08 |
| rogpeppe | fwereade: that's the bug i found w.r.t. the mongodb charm, BTW | 11:08 |
| fwereade | rogpeppe, LGTM trivial | 11:09 |
| rogpeppe | fwereade: thank | 11:09 |
| fwereade | rogpeppe, but it's not reliably reproducible? | 11:09 |
| rogpeppe | s | 11:09 |
| rogpeppe | fwereade: yeah, it is | 11:09 |
| fwereade | rogpeppe, ah, fantastic | 11:10 |
| rogpeppe | fwereade: it just takes a while to do it | 11:10 |
| fwereade | rogpeppe, heh | 11:10 |
| fwereade | rogpeppe, I'm thinking of --upload-tools, which I think at the moment just uses version.Current, which is probably right (given an absence of cross-compiling) | 11:12 |
| rogpeppe | fwereade: it can't do anything else, yeah | 11:13 |
| fwereade | rogpeppe, in which case we have to check that the series and arch of the image/instance we start actually match what we're uploading | 11:13 |
| rogpeppe | fwereade: hmm, i have to think about that a bit | 11:14 |
| rogpeppe | fwereade: currently upload-tools is just an argument to bootstrap | 11:14 |
| rogpeppe | fwereade: and there's nothing stopping you from provisioning more instances that don't use the originally uploaded tools | 11:14 |
| fwereade | rogpeppe, yeah, and vice versa | 11:14 |
| fwereade | rogpeppe, ok then, cool | 11:15 |
| rogpeppe | fwereade: i'm not sure what you mean by "vice versa" there actually. | 11:15 |
| rogpeppe | fwereade: you can't upload tools later | 11:15 |
| fwereade | rogpeppe, we *just* upload the tools we can, and the user is responsible for starting instances on which they will actually run | 11:15 |
| fwereade | rogpeppe, oh, I thought upgrade-juju could do that? | 11:16 |
| rogpeppe | fwereade: oh yeah, so it does! | 11:16 |
| fwereade | rogpeppe, :D | 11:16 |
| rogpeppe | [11:16:00] <fwereade> rogpeppe, we *just* upload the tools we can, and the user is responsible for starting instances on which they will actually run | 11:17 |
| rogpeppe | +1 | 11:17 |
| fwereade | rogpeppe, ok, sweet | 11:17 |
| fwereade | rogpeppe, I am also eyeing environs.FindTools | 11:17 |
| fwereade | rogpeppe, I am suspecting that it should somehow give me a list of available tools matching certain criteria (filter on series and arches, I think) | 11:18 |
| rogpeppe | fwereade: yeah. the significant issue around this is that currently we choose what tools an instance will run before we actually ask the provider to start the instance | 11:19 |
| fwereade | rogpeppe, that is I think ok | 11:19 |
| rogpeppe | fwereade: but if the provider itself can decide on an architecture, for example, then that might be a problem | 11:19 |
| rogpeppe | fwereade: perhaps FindTools should take a Constraints as an argument? | 11:20 |
| rogpeppe | [11:20:10] <rogpeppe> fwereade: perhaps FindTools should take a Constraints as an argument? | 11:20 |
| rogpeppe | although series isn't really a constraint | 11:20 |
| fwereade | rogpeppe, perhaps -- yeah, I'm eyeing (series string, cons Constraints) args | 11:21 |
| fwereade | rogpeppe, that said... it would be *really* convenient if Series was a constraint | 11:21 |
| rogpeppe | fwereade: yeah, and... why shouldn't it be? | 11:21 |
| fwereade | rogpeppe, because it's not something amenable to direct control like the others | 11:22 |
| fwereade | rogpeppe, the series is determined by the service's charm, which itself may be determined by the environ's default-series | 11:22 |
| rogpeppe | fwereade: isn't it actually in a way *more* amenable to direct control (we can start different series on a given piece of hardware) | 11:22 |
| fwereade | rogpeppe, from the juju level, it is -- juju deploy cs:precise/foobar -- bam, there's precise | 11:23 |
| fwereade | rogpeppe, and there's the distinct setting of constraints, in which series does not play a part | 11:23 |
| rogpeppe | fwereade: i'm not intrinsicaly opposed to the idea that a charm might influence the constraints of the machine that's started to deploy it | 11:23 |
| fwereade | rogpeppe, it *must* | 11:23 |
| fwereade | rogpeppe, precise charms run on precise | 11:23 |
| fwereade | rogpeppe, quantal charms run on quantal | 11:24 |
| fwereade | rogpeppe, etc | 11:24 |
| rogpeppe | fwereade: ok, so how can the series *not* be part of the constraints? | 11:24 |
| rogpeppe | fwereade: BTW how does getting a list of available tools from FindTools help you? | 11:25 |
| fwereade | rogpeppe, it is not entirely clear that the internal representation of a Constraints should *necessarily* carry with it the series information which is specified in a different way and could I think be inferred where necessary | 11:25 |
| rogpeppe | fwereade: all constraints are optional, no? so there's no "necessary" there. | 11:26 |
| fwereade | rogpeppe, series is not optional | 11:26 |
| fwereade | rogpeppe, which is another way in which it is different to the other constraints | 11:27 |
| rogpeppe | fwereade: no constraint is optional when the machine is actually instantiated :-) | 11:27 |
| fwereade | rogpeppe, that's information about a running instance, which we do want to match against constraints in future; but they are not themselves constraints | 11:28 |
| fwereade | rogpeppe, they represent a solution to the constraints, if you like | 11:28 |
| rogpeppe | fwereade: yeah, and the form of the solution might look exactly like a Constraint :-) | 11:28 |
| fwereade | rogpeppe, they do indeed look very similar | 11:29 |
| fwereade | rogpeppe, but actually not exactly the same :) | 11:29 |
| rogpeppe | fwereade: anyway, i'm not sure i see the advantage to passing the series around as an extra parameter to the constraints. | 11:29 |
| rogpeppe | rather, a parameter extra to the constraints | 11:30 |
| rogpeppe | fwereade: and i definitely see simplicity advantages to including it with the constraints | 11:30 |
| fwereade | rogpeppe, I'm not sure the case is overwhelming either way, is all; it could easily be stored on state.Machine when a unit is assigned -- you always have a series, because the unit has a service has a charm -- as well as the service having constraints | 11:31 |
| rogpeppe | fwereade: in fact, if series was part of the constraints, we perhaps wouldn't need default-series | 11:31 |
| fwereade | rogpeppe, I don't think it's the same thing, quite | 11:32 |
| rogpeppe | fwereade: because it could be specified by the environment's series constraint. | 11:32 |
| fwereade | rogpeppe, that's where the default would come from -- but then you override that constraint in a different and magical way when you deploy, and you can't even set it from the UI | 11:33 |
| rogpeppe | fwereade: i'm not sure it's "magical" - every charm comes with an implied series constraint. | 11:34 |
| rogpeppe | fwereade: maybe you would want some special case code to prevent you setting a service's series constraint to something other than the charm's series though. | 11:35 |
| fwereade | rogpeppe, I am weighing up the costs and benefits of that special casing | 11:35 |
| fwereade | rogpeppe, I don;t feel entirely in favour of it: I think that doing that in the python was a bit of a mistake | 11:35 |
| rogpeppe | fwereade: but tbh, "series" doesn't seem like something that should be so special. it's special now because everything's ubuntu-only. | 11:36 |
| fwereade | rogpeppe, I don;t suppose you know if there's a wiki page for the sprint yet? | 11:36 |
| rogpeppe | fwereade: not afaik | 11:36 |
| * rogpeppe must book flights | 11:36 | |
| fwereade | rogpeppe, it's gonna be very special one day, I just hope it can bear the load that's put on its shoulders | 11:36 |
| fwereade | rogpeppe, it's in charms, it's in juju, and it's our one way of specifying a target os | 11:36 |
| rogpeppe | fwereade: i could see it becoming a (os, os-version) tuple | 11:37 |
| fwereade | rogpeppe, indeed it might | 11:37 |
| rogpeppe | fwereade: but maybe that's just a compound name | 11:37 |
| fwereade | rogpeppe, plausibly | 11:37 |
| dimitern | anyone seen mramm ? | 11:37 |
| rogpeppe | fwereade: i'd prefer it to be two attributes as part of the constraints though, | 11:37 |
| fwereade | dimitern, we can all dogpile him when he gets on :) | 11:38 |
| dimitern | fwereade: :D sure | 11:38 |
| rogpeppe | fwereade: to put it another way, what *wouldn't* work well (or be more complex) if series was part of the constraints? | 11:38 |
| fwereade | rogpeppe, environ-level series constraints would be weird -- they'd work a bit like default-series and a bit like the other constraints | 11:40 |
| rogpeppe | fwereade: say we took default-series to be just the seed for setting the environ-level series constraint? would that cause problems? | 11:42 |
| rogpeppe | fwereade: (we've already got to segregate default series from the other environment config params) | 11:42 |
| rogpeppe | fwereade: (mind you, that's true of the agent version field too, and probably others) | 11:43 |
| fwereade | rogpeppe, yeah -- I think that it is tempting to put lots of stuff into constraints but I want to grow it prudently | 11:44 |
| rogpeppe | fwereade: i would *not* put the agent version into constraints | 11:44 |
| fwereade | rogpeppe, quite so | 11:44 |
| rogpeppe | fwereade: but i think series does work well as a constraint | 11:45 |
| fwereade | rogpeppe, a constraint that can't be set like the other constraints, can't be changed like the other constraints, and affects parts of the codebase that no other constraints impact? | 11:45 |
| fwereade | rogpeppe, it *may* indeed be a good place for it | 11:46 |
| fwereade | rogpeppe, but it will take some pretty seriously ugliness on the other side to balance that out | 11:46 |
| fwereade | rogpeppe, so, anyway, as I solve the constraints I will eliminate various images and instance-types from consideration, but I will still probably end up with multiple candidates | 11:49 |
| fwereade | rogpeppe, of those that the provider offers, there may not be tools available | 11:49 |
| fwereade | rogpeppe, gaah, sorry | 11:51 |
| rogpeppe | fwereade: np | 11:51 |
| fwereade | rogpeppe, what was the last thing you saw? | 11:51 |
| rogpeppe | [11:49:26] <fwereade> rogpeppe, of those that the provider offers, there may not be tools available | 11:51 |
| fwereade | rogpeppe, cool, that was all I'd said | 11:51 |
| rogpeppe | fwereade: yeah, i see where you're coming from | 11:52 |
| fwereade | rogpeppe, but still I will end up with a bunch of possible instance/image pairs, and appropriate tools for each, and then have to try to pick the "best" according to whatever soft constraints we have | 11:52 |
| fwereade | rogpeppe, that's a separate problem though | 11:53 |
| rogpeppe | fwereade: the thing to be careful of is that you always want to pick from Storage over PublicStorage where possible. | 11:53 |
| fwereade | rogpeppe, hmm, if you want to use your own storage you're surely using it for higher-than-public versions..? | 11:54 |
| rogpeppe | fwereade: "where possible" might just mean "where the difference is just in version number" | 11:54 |
| rogpeppe | fwereade: no, not necessarily | 11:54 |
| rogpeppe | fwereade: it's important that you be able to upload lower-than-public versions too | 11:55 |
| rogpeppe | fwereade: and have them used | 11:55 |
| rogpeppe | fwereade: that was a significant part of the current design | 11:55 |
| fwereade | rogpeppe, ok, sgtm, thank you for pointing that out | 11:57 |
| rogpeppe | fwereade: it means that if you use upload-tools, you rely on the fact that you're going to run the uploaded tools (assuming that you deploy to the same architecture) | 11:57 |
| fwereade | rogpeppe, but wait | 11:57 |
| * rogpeppe waits with baited breath | 11:57 | |
| rogpeppe | or is it "bated bread"? | 11:57 |
| rogpeppe | breath | 11:57 |
| rogpeppe | ah, it is | 11:58 |
| fwereade | rogpeppe, the latter -- and fwereade is not sure | 11:58 |
| * fwereade has just been reminded that he has to visit the shops for cath's lunch; bbiab | 11:58 | |
| rogpeppe | fwereade: ok | 11:58 |
| fwereade | rogpeppe, heyhey | 12:27 |
| rogpeppe | fwereade: hihi | 12:28 |
| fwereade | rogpeppe, can we explore the public/private use cases a little more? I think I need a little refresher | 12:29 |
| rogpeppe | fwereade: ok | 12:29 |
| rogpeppe | fwereade: motivating example #1: we want to be able to run the local dev version of the tools without worrying about what might be in a public bucket | 12:30 |
| rogpeppe | fwereade: what in particular are you interested in finding out? | 12:33 |
| fwereade | rogpeppe, hum, ok, so: does FindTools currently return the latest compatible tools in private, or if that's not there the latest compatible tools in public? | 12:35 |
| rogpeppe | fwereade: yup | 12:35 |
| fwereade | rogpeppe, ok, so, I think the FindTools variant wants to return all latest matching private toolses, followed by all latest matching public toolses? | 12:37 |
| * rogpeppe likes "toolses" | 12:37 | |
| fwereade | :) | 12:37 |
| rogpeppe | fwereade: i'd like to see a sketch of your algorithm for constraints solving before i commit to whether that's the right approach or not | 12:38 |
| fwereade | rogpeppe, 1) eliminate non-matching instance types | 12:39 |
| fwereade | rogpeppe, 2) eliminate non-matching images | 12:39 |
| fwereade | rogpeppe, discard bad combinations in (1) x (2) | 12:39 |
| fwereade | rogpeppe, (that may not come exactly there, but will be somewhere) | 12:40 |
| fwereade | rogpeppe, 3) eliminate images for which no tools can be found | 12:40 |
| fwereade | rogpeppe, 4) discard bad combinations | 12:41 |
| fwereade | 5) magic happens here to nail down exactly which one we pick | 12:41 |
| rogpeppe | fwereade: i've been wondering about the possibility of *starting* with the available tools | 12:42 |
| rogpeppe | fwereade: but i'm not quite sure how that would look, or whether it would be better or worse. i suppose anything that eliminates more possibilities earlier is to be preferred. | 12:43 |
| fwereade | rogpeppe, yeah, it shouldn't be too hard to reorder stages if we need to | 12:43 |
| rogpeppe | fwereade: that depends if each stage is dealing with a list of the same things | 12:46 |
| fwereade | rogpeppe, well, yes: we were I think talking about two stages of image-filtering | 12:46 |
| rogpeppe | fwereade: {instance-type} -> {(instance-type, image)} -> {(instance-type, image, tools)} | 12:47 |
| rogpeppe | fwereade: is that a reasonable summary of what the data types might look like through each stage? | 12:48 |
| rogpeppe | fwereade: where {a} represents a set of a, and (a, b) represents a tuple of a and b. | 12:48 |
| fwereade | rogpeppe, yeah, roughly like that | 12:48 |
| rogpeppe | fwereade: got lunch. back in a short while. | 12:51 |
| * dimitern lunch | 12:58 | |
| rogpeppe | niemeyer: yo! | 13:05 |
| fwereade | niemeyer, heyhey | 13:22 |
| niemeyer | Heya | 13:23 |
| * fwereade goes to eat the other half of lunch that he neglected before | 13:23 | |
| rogpeppe | fwereade: from the mongodb charm uniter log: http://paste.ubuntu.com/1676994/ | 13:43 |
| fwereade | rogpeppe, what's --format json meant to do for relation-set? | 14:05 |
| rogpeppe | fwereade: ha, good question, i'd missed that | 14:06 |
| rogpeppe | fwereade: i'm surprised the python version allows it | 14:06 |
| fwereade | rogpeppe, (that is to say: grar, I guess to match python we need to implement the --format stuff on every hook tool, whether or not it makes sense | 14:06 |
| fwereade | ) | 14:06 |
| rogpeppe | fwereade: we can just ignore it i suppose, mostly | 14:07 |
| fwereade | rogpeppe, yeah, I think so | 14:07 |
| fwereade | rogpeppe, but tyvm, good catch | 14:07 |
| rogpeppe | fwereade: np | 14:07 |
| fwereade | rogpeppe, do yu have the bug number handy? I can jot in an explanation | 14:08 |
| rogpeppe | fwereade: sorry, i hadn't yet made a bug - i wanted to replicate it first | 14:09 |
| fwereade | rogpeppe, np -- then just note that we should add it for everything | 14:09 |
| rogpeppe | fwereade: yea | 14:09 |
| rogpeppe | h | 14:09 |
| fwereade | rogpeppe, (every hook tool that is) | 14:09 |
| rogpeppe | fwereade: https://bugs.launchpad.net/juju-core/+bug/1129130 | 14:11 |
| _mup_ | Bug #1129130: all hook tools should support --format <juju-core:New> < https://launchpad.net/bugs/1129130 > | 14:11 |
| fwereade | rogpeppe, cool, tyvm | 14:11 |
| hazmat | bigjools, thanks for that mongo ppa, btw. | 14:55 |
| dimitern | fwereade: ping | 15:10 |
| mgz | thanks for the review hazmat | 15:11 |
| hazmat | mgz, np | 15:13 |
| mgz | hazmat: also, missed the review on the last change landed on lp:juju, have left a comment there now | 15:17 |
| hazmat | ack | 15:18 |
| mgz | the design for that changed too many times, and ended up in a confused state... | 15:19 |
| hazmat | mgz, r597 was pure breakage it appears | 15:20 |
| hazmat | mgz, the value returned by constraints convert is used for comparison and validation, the tests weren't previously getting to a real comparison because the constraints lacked series | 15:21 |
| mgz | the issue is maas needs the original string, not something that juju constraints have mangled | 15:21 |
| hazmat | mgz, folks using it in practice would hit the issue that the string was being returned but the compare method was issubset | 15:21 |
| mgz | the previous bug was from passing str(set(['tag-a', 'tag-b'])) which maas didn't understand because it doesn't parse python sets | 15:22 |
| mgz | so, that's fixable(ish) elsewhere, I just wonder if we've regressed the other bug... | 15:22 |
| hazmat | mgz, hmm.. the original string is preserved and serialized, noted thoug | 15:22 |
| hazmat | mgz, yeah.. not having a maas instance to test against makes this a bit of wackamole | 15:22 |
| mgz | provided the convert method is only used for juju, and not in the api call, I think we're fine | 15:23 |
| mgz | but I can't remember what exactly is the case there... | 15:23 |
| hazmat | mgz, the convert call is also used against __getitem__ implicitly so the constraint acquisition for sending to maas may indeed have issue | 15:24 |
| hazmat | checking | 15:24 |
| mgz | uses constraints.get... which I have a nasty feeling does convert | 15:24 |
| mgz | argh, and the maas client tests use dicts not real constraint objects because those are a pain to construst outside of a provider context | 15:26 |
| hazmat | not clear that it does | 15:26 |
| hazmat | yeah.. | 15:26 |
| hazmat | mgz, i'll have a look and try to do a proper constraints test with that api | 15:27 |
| hazmat | mgz, thanks | 15:38 |
| hazmat | mgz, digging through the tags stuff last week, i did run into a concern of tags that where valid at the time of service definition that are no longer valid cause issues | 16:11 |
| mgz | yeah, it's troublesome | 16:12 |
| mgz | this is generally true for non-trivial constraints, just because it once resolved to something sane, doesn't mean it always will | 16:14 |
| mgz | so the provisioner needs to handle having a constraint that fails | 16:14 |
| mgz | rather than just going into a retry loop as it does at present... | 16:14 |
| rogpeppe | fwereade: you'll like this one. noisy but trivial: https://codereview.appspot.com/7327050 | 16:38 |
| fwereade | rogpeppe, w00t! | 16:45 |
| rogpeppe | fwereade: :-) | 16:45 |
| rogpeppe | fwereade: i'm going to unexport state.NotFoundError and export state.NotFoundf | 16:46 |
| rogpeppe | fwereade: because i want to be able to create a not-found error for testing purposes | 16:46 |
| rogpeppe | fwereade: and there's no point really in exporting the type when we've got IsNotFound | 16:46 |
| fwereade | rogpeppe, yeah, as long as we have api.IsNotFound I'm not bothered by the precise gubbins | 16:47 |
| TheRealMue | fwereade: Just for info, I put the backend branch into work in progress again. I discovered a missing capability during the storage testing. | 16:47 |
| rogpeppe | fwereade: cool | 16:47 |
| fwereade | TheRealMue, ah, thanks | 16:47 |
| === TheRealMue is now known as TheMue | ||
| rogpeppe | fwereade: i'm leaning towards something a bit more general actually: api.ErrCode(err) == api.CodeNotFound | 16:48 |
| rogpeppe | fwereade: although we could have IsNotFound as a short cut for that | 16:48 |
| fwereade | rogpeppe, sgtm | 16:48 |
| fwereade | rogpeppe, clear and close enough ;) | 16:48 |
| === deryck is now known as deryck[lunch] | ||
| rogpeppe | hmm, typing this was not a good idea: | 17:15 |
| rogpeppe | bzr switch lp:~rogpeppe/juju-core/221-instanceid-bool | 17:15 |
| rogpeppe | now: how to get myself out of it! | 17:16 |
| mgz | heh | 17:23 |
| mgz | what was the location before? just a plain branch, or something fancier? | 17:23 |
| mgz | rogpeppe: what do `bzr info` and `bzr branches` say? | 17:25 |
| rogpeppe | mgz: it's ok, i've fixed it | 17:25 |
| rogpeppe | mgz: i just edited the "location" file | 17:25 |
| rogpeppe | mgz: i was using cobzr, so the location before was a file: branch | 17:26 |
| mgz | ..that's okay for checkouts, if you also have sane tree state, switching back to the previous location is safer | 17:26 |
| rogpeppe | mgz: i couldn't use "cobzr switch" because it complained at me | 17:27 |
| mgz | plain bzr switch, with the magic cobzr location, would work (with --force at least), but that does mean you need to know how cobzr maps names | 17:28 |
| rogpeppe | mgz: ah, i didn't know that plain bzr had a "switch" command | 17:28 |
| === imbrando1 is now known as imbrandon | ||
| === deryck[lunch] is now known as deryck | ||
| rogpeppe | here's a dilemma: is it ethical to ask the company to pay 400 quid more for a flight so that i can get 4 hours sleep rather than none... ? | 18:37 |
| rogpeppe | right, time to stop, see y'all tomorrow | 19:03 |
| thumper | poos | 22:29 |
| thumper | davecheney: ping | 22:29 |
| davecheney | thumper: ack | 22:30 |
| thumper | davecheney: I have a slight problem | 22:30 |
| davecheney | shoot | 22:30 |
| thumper | I've managed to cut out a lot of code duplication | 22:30 |
| thumper | with one small problem | 22:30 |
| thumper | in all cases we want to parse the command line flags with "allowIntersperse=true" | 22:31 |
| thumper | except for the case of a supercommand | 22:31 |
| thumper | the code is cmd.Main | 22:31 |
| * davecheney looks | 22:31 | |
| thumper | and I want to say "if this Command is a SuperCommand, then use false, otherwise use true" | 22:31 |
| thumper | Command is an interface and SuperCommand just a struct | 22:32 |
| thumper | what is the best way to ask | 22:32 |
| thumper | davecheney: the parsing used to be in the Init methods of *every* command | 22:32 |
| thumper | I'm wanting to remove that duplication | 22:32 |
| davecheney | +1 to that | 22:32 |
| davecheney | thumper: try a type switch | 22:32 |
| thumper | the code is nice and simple | 22:32 |
| thumper | davecheney: got an example? | 22:32 |
| davecheney | c is of type cmd.Command | 22:33 |
| davecheney | switch c := c.(type) { | 22:33 |
| davecheney | case *cmd.SuperCommand: // guess | 22:33 |
| davecheney | // do something | 22:33 |
| davecheney | default: | 22:33 |
| thumper | hmm... lemmie test | 22:33 |
| davecheney | // you are something else that conforms to cmd.Command | 22:33 |
| davecheney | } | 22:33 |
| thumper | sweet | 22:35 |
| thumper | works in my small test prog | 22:35 |
| thumper | will test in main code | 22:35 |
| thumper | davecheney: I think I have it now, but I have to go collect daughter for lunch | 22:43 |
| thumper | back online after lunch | 22:43 |
| davecheney | thumper: no worries, i have to pop to the shops for breakfast stuffs | 22:46 |
| bigjools | hazmat: the pleasure was all mine, believe me :) | 23:13 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!