[00:00] <davecheney> var m = make(map[string]int)
[00:01] <davecheney> type T struct { name string }
[01:26]  * thumper is beginning to want proper inheritance in go...
[01:26]  * thumper sighs
[01:28]  * thumper has another thought...
[01:28] <thumper> gah, must finish something before starting another
[01:28]  * thumper puts head down again
[02:22] <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:23] <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:27]  * thumper guesses davecheney is at lunch
[02:43] <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
[04:00] <thumper> whoever thought that "c *C" were good params for tests should be given a very stern look
[04:16]  * thumper jumps through hoops
[04:21]  * thumper wonders if 1000 lines of diff are enough for first change to juju
[04:27] <davecheney> thumper: i'd say most things are up for grabs if you are prepared to argue your case
[04:27] <thumper> hmm...
[04:28] <thumper> davecheney: are there dependencies between the juju-core packages that I have to make sure I don't screw up?
[04:31] <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:32] <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:33] <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:50] <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:51] <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
[05:08] <thumper> davecheney: umm... if I Ctrl-C the tests while running, have I left things behind that might cause further tests to hang?
[05:10] <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:11] <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:22] <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:23] <thumper> although, not quite that bad:  58 files changed, 223 insertions(+), 188 deletions(-)
[05:23] <thumper> and much of that is duplicated
[05:24] <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:25] <davecheney> night
[05:26] <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/
[06:52] <wallyworld_> davecheney: hi, thanks for finding that data race. what tool did you use?
[08:13] <TheMue> Morning
[08:14] <dimitern> TheMue: morning!
[08:25] <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:26] <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:28] <rogpeppe> mornin' all
[08:28] <TheMue> rogpeppe: Hiya
[08:28] <rogpeppe> TheMue: yo!
[08:28] <dimitern> rogpeppe: morning
[08:28] <rogpeppe> dimitern: hi!
[10:23] <dimitern> fwereade: you've got 2 reviews
[10:23] <fwereade> dimitern, tyvm
[10:35] <fwereade> rogpeppe, ping
[10:35] <rogpeppe> fwereade: pong
[10:35] <fwereade> rogpeppe, last weekend, I had a thought related to the api
[10:36] <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:37] <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:38] <rogpeppe> fwereade: there must always be at least one API server running
[10:39] <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:40] <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:41] <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:42] <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:43] <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:44] <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:45] <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:46] <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:47] <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:48] <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:49] <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:51] <rogpeppe> fwereade: the only difficulty is that the logic in the machiner becomes more complex
[10:52] <rogpeppe> fwereade: but that's probably a reasonable tradeoff
[10:52] <fwereade> rogpeppe, it feels tolerable, yeah
[10:57] <rogpeppe> fwereade: yeah, it looks like we could get rid of the tools arg to StartInstance without losing anything significant
[11:04] <rogpeppe> fwereade: trivial CL: https://codereview.appspot.com/7317050
[11:07] <fwereade> rogpeppe, well, I think the tools interact very closely, I'm still trying to figure out the right way to go
[11:08] <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:09] <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:10] <fwereade> rogpeppe, ah, fantastic
[11:10] <rogpeppe> fwereade: it just takes a while to do it
[11:10] <fwereade> rogpeppe, heh
[11:12] <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:13] <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:14] <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:15] <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:16] <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:17] <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:18] <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:19] <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:20] <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:21] <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:22] <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:23] <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:24] <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:25] <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:26] <rogpeppe> fwereade: all constraints are optional, no? so there's no "necessary" there.
[11:26] <fwereade> rogpeppe, series is not optional
[11:27] <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:28] <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:29] <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:30] <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:31] <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:32] <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:33] <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:34] <rogpeppe> fwereade: i'm not sure it's "magical" - every charm comes with an implied series constraint.
[11:35] <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:36] <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:37] <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:38] <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:40] <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:42] <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:43] <rogpeppe> fwereade: (mind you, that's true of the agent version field too, and probably others)
[11:44] <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:45] <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:46] <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:49] <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:51] <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:52] <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:53] <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:54] <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:55] <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:57] <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:58] <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
[12:27] <fwereade> rogpeppe, heyhey
[12:28] <rogpeppe> fwereade: hihi
[12:29] <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:30] <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:33] <rogpeppe> fwereade: what in particular are you interested in finding out?
[12:35] <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:37] <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:38] <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:39] <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:40] <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:41] <fwereade> rogpeppe, 4) discard bad combinations
[12:41] <fwereade> 5) magic happens here to nail down exactly which one we pick
[12:42] <rogpeppe> fwereade: i've been wondering about the possibility of *starting* with the available tools
[12:43] <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:46] <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:47] <rogpeppe> fwereade: {instance-type} -> {(instance-type, image)} -> {(instance-type, image, tools)}
[12:48] <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:51] <rogpeppe> fwereade: got lunch. back in a short while.
[12:58]  * dimitern lunch
[13:05] <rogpeppe> niemeyer: yo!
[13:22] <fwereade> niemeyer, heyhey
[13:23] <niemeyer> Heya
[13:23]  * fwereade goes to eat the other half of lunch that he neglected before
[13:43] <rogpeppe> fwereade: from the mongodb charm uniter log: http://paste.ubuntu.com/1676994/
[14:05] <fwereade> rogpeppe, what's --format json meant to do for relation-set?
[14:06] <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:07] <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:08] <fwereade> rogpeppe, do yu have the bug number handy? I can jot in an explanation
[14:09] <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:11] <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:55] <hazmat> bigjools, thanks for that mongo ppa, btw.
[15:10] <dimitern> fwereade: ping
[15:11] <mgz> thanks for the review hazmat
[15:13] <hazmat> mgz, np
[15:17] <mgz> hazmat: also, missed the review on the last change landed on lp:juju, have left a comment there now
[15:18] <hazmat> ack
[15:19] <mgz> the design for that changed too many times, and ended up in a confused state...
[15:20] <hazmat> mgz, r597 was pure breakage it appears
[15:21] <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:22] <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:23] <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:24] <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:26] <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:27] <hazmat> mgz, i'll have a look and try to do a proper constraints test with that api
[15:38] <hazmat> mgz, thanks
[16:11] <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:12] <mgz> yeah, it's troublesome
[16:14] <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:38] <rogpeppe> fwereade: you'll like this one. noisy but trivial: https://codereview.appspot.com/7327050
[16:45] <fwereade> rogpeppe, w00t!
[16:45] <rogpeppe> fwereade: :-)
[16:46] <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:47] <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:48] <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 ;)
[17:15] <rogpeppe> hmm, typing this was not a good idea:
[17:15] <rogpeppe> bzr switch  lp:~rogpeppe/juju-core/221-instanceid-bool
[17:16] <rogpeppe> now: how to get myself out of it!
[17:23] <mgz> heh
[17:23] <mgz> what was the location before? just a plain branch, or something fancier?
[17:25] <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:26] <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:27] <rogpeppe> mgz: i couldn't use "cobzr switch" because it complained at me
[17:28] <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
[18:37] <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... ?
[19:03] <rogpeppe> right, time to stop, see y'all tomorrow
[22:29] <thumper> poos
[22:29] <thumper> davecheney: ping
[22:30] <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:31] <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:32] <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:33] <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:35] <thumper> sweet
[22:35] <thumper> works in my small test prog
[22:35] <thumper> will test in main code
[22:43] <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:46] <davecheney> thumper: no worries, i have to pop to the shops for breakfast stuffs
[23:13] <bigjools> hazmat: the pleasure was all mine, believe me :)