| davecheney | http://play.golang.org/p/0jeSRlVe8B | 00:00 |
|---|---|---|
| davecheney | ^ maybe that makes a little more sense | 00:00 |
| davecheney | thumper: can you show me the hole in the code where this function would fit | 00:01 |
| davecheney | maybe that would help me suggest a better implementation | 00:01 |
| rick_h_ | davecheney: via the api we want to colocate a service with another on an existing machine. If I create a service with 0 units, and then add a unit with the machine id of an existing machine any chance of it working? | 00:02 |
| rick_h_ | I cna't test it out via the cli becaus I can't deploy a service with --num-units=0 | 00:03 |
| davecheney | rick_h_: deploy --to | 00:03 |
| davecheney | ^ that is what you are trying to do, right ? | 00:03 |
| rick_h_ | yea, that's cli, but I need api for the gui | 00:03 |
| rick_h_ | davecheney: yes, basically | 00:03 |
| davecheney | ok, let me figure out how the cli does it | 00:03 |
| rick_h_ | but doing it with manual placement | 00:04 |
| rick_h_ | davecheney: thanks | 00:04 |
| rick_h_ | davecheney: sorry, we're getting the demo rules changed on us and trying to get back to a working demo | 00:04 |
| rick_h_ | appreciate the help | 00:04 |
| davecheney | rick_h_: ok, i dont know what that means | 00:06 |
| davecheney | oh yes i dio | 00:06 |
| davecheney | ODS is here isn't it | 00:06 |
| rick_h_ | davecheney: yep :) | 00:06 |
| rick_h_ | davecheney: and our demo of lxc container on a running machine isn't happy with openstack running on openstack | 00:07 |
| rick_h_ | so we're trying to change it on the fly to colocated on bare metal vs in lxc | 00:07 |
| davecheney | err = client.ServiceDeployWithNetworks( | 00:07 |
| davecheney | curl.String(), | 00:07 |
| davecheney | serviceName, | 00:07 |
| davecheney | numUnits, | 00:07 |
| davecheney | string(configYAML), | 00:07 |
| davecheney | c.Constraints, | 00:07 |
| davecheney | c.ToMachineSpec, | 00:07 |
| davecheney | includeNetworks, | 00:07 |
| davecheney | excludeNetworks, | 00:07 |
| davecheney | ) | 00:07 |
| davecheney | this is the api (i guess call), there is a numunits on ther | 00:07 |
| rick_h_ | ok, so it's coming in with the service | 00:08 |
| rick_h_ | we need to break the steps up, but will see how we do | 00:08 |
| davecheney | hang on , still checking | 00:08 |
| davecheney | http://paste.ubuntu.com/7455044/ | 00:10 |
| rick_h_ | thanks looking | 00:10 |
| davecheney | so num units 1 | 00:10 |
| davecheney | tomachinespec <- the machine you want to pin the service to | 00:10 |
| rick_h_ | yea, we're deploying the service with 0 units and then making individual add unit calls. | 00:11 |
| davecheney | that won't work | 00:11 |
| davecheney | --to is a dirty hack | 00:11 |
| davecheney | its internal name is 'hulk smash' | 00:11 |
| rick_h_ | ugh | 00:12 |
| rick_h_ | ok | 00:12 |
| davecheney | so you'll have to deply one unit with --to, then make additional calls to add-unit --to | 00:12 |
| rick_h_ | yea, that breaks more stuff for us then. thanks for looking | 00:12 |
| davecheney | the reason its like this is --to skips the normal machine selection logic, and just spats the unit on that machine | 00:13 |
| davecheney | that splatting isn't recorded in mongo at all | 00:13 |
| rick_h_ | understood | 00:13 |
| axw | wallyworld_: that issue curtis reported is fixed by the tools CL you just did? | 01:18 |
| wallyworld_ | axw: yes | 01:19 |
| axw | cool | 01:19 |
| wallyworld_ | axw: did you have time for a quick standup? | 01:39 |
| axw | wallyworld_: sure | 01:39 |
| thumper | davecheney: around? | 02:13 |
| davecheney | thumper: ack | 02:14 |
| thumper | davecheney: got time for a hangout? | 02:15 |
| davecheney | thumper: sure | 02:15 |
| thumper | let me just let the dog in | 02:15 |
| thumper | davecheney: https://plus.google.com/hangouts/_/g4gj3fe657m4xgcesqioprs6vqa?hl=en | 02:17 |
| davecheney | joining ... | 02:18 |
| thumper | davecheney: play.golang.org/p/3LV_d5HJb3 | 02:29 |
| waigani | axw: ping | 02:36 |
| axw | waigani: pong | 02:36 |
| waigani | axw can I pick your brain? hangout? | 02:37 |
| axw | sure | 02:37 |
| axw | waigani: sorry was a bit hard to hear you, didn't realise you were logging off. cya ;) | 02:47 |
| waigani | oh whoops, didn't mean to hang up on you :/ | 02:48 |
| axw | waigani: nps | 02:48 |
| axw | you got everything you needed right? | 02:48 |
| waigani | yep, all good now, thanks :) | 02:48 |
| axw | nps | 02:48 |
| waigani | I was going to ask how harding was going, but you seem to be in the thick of it | 02:49 |
| axw | waigani: just picking off bugs one at a time, not that different from before | 02:50 |
| waigani | axw: you're looking very productive! Thunderbird keeps popping up with merge proposals from you an wallyworld_ every 5min! | 02:51 |
| axw | I don't really feel very productive doing bitsy things, but it's still useful | 02:52 |
| wallyworld_ | getting the test suite to pass reliably is very productive :-) | 02:53 |
| axw | wallyworld_: do you really want me to look at the LXC defaults thing, or was that just an idea? I've got a good idea about how to fix #1316272 | 02:57 |
| _mup_ | Bug #1316272: juju destroy-environment >=256 nodes fails <amd64> <apport-bug> <destroy-environment> <maas-provider> <sm15k> <third-party-packages> <trusty> <juju-core:Triaged> <MAAS:Invalid> <juju-core (Ubuntu):New> <maas (Ubuntu):Invalid> <https://launchpad.net/bugs/1316272> | 02:57 |
| wallyworld_ | go for it, it was just an idea | 02:58 |
| wallyworld_ | that maas one is more important | 02:58 |
| axw | cool | 02:59 |
| === ppetraki_ is now known as ppetraki | ||
| jam | thumper: gocheck provides a gc.FitsTypeOf checker that takes two objects and tells you if the first one matches the type of the second one | 04:00 |
| thumper | jam: I don't want the type, but object identity | 04:08 |
| jam | thumper: so it isn't "unsafe" to grab a uintptr object | 04:08 |
| jam | AIUI | 04:08 |
| jam | it is only "unsafe" to cast that back into a type | 04:08 |
| thumper | jam: however the interface is a tuple of two pointers | 04:09 |
| jam | thumper: reflect.Value(obj).Pointer() == reflect.Value(obj2).Pointer() | 04:09 |
| thumper | jam: doesn't work if the type isn't a pointer | 04:09 |
| jam | I don't have the scrollback on this terminal for your non-comparable types | 04:09 |
| thumper | it panics | 04:09 |
| jam | thumper: &obj is still a pointer | 04:09 |
| jam | well, would always be a pointer | 04:09 |
| thumper | no | 04:09 |
| thumper | no it isn't | 04:10 |
| thumper | a value type can implement an interface | 04:10 |
| thumper | and in fact we have an example in juju-core | 04:10 |
| jam | sure, but &obj is still a pointer | 04:10 |
| thumper | where a value type is an error and uncomparable | 04:10 |
| jam | thumper: if it is a value type, then they *are not* the same obj.ect. | 04:10 |
| jam | object | 04:10 |
| thumper | jam: but you don't know | 04:10 |
| thumper | jam: look, I have examples in test code | 04:10 |
| thumper | which expected behaviour | 04:11 |
| thumper | if it can be done a different way | 04:11 |
| thumper | I'm happy, but AFAIK, it cannot | 04:11 |
| jam | thumper, so to start with, I'm not sure that comparing errors by identity is actually what we want to be doing, rather than checking if this error is part of this type of errors. | 04:16 |
| jam | I realize our code is a bit mixed on this point | 04:16 |
| jam | where we have some concrete errors | 04:16 |
| jam | and we have other variable ones | 04:16 |
| jam | and we get some unhashable/uncomparable ones from various libs | 04:16 |
| thumper | it isn't helpful to discuss this here without examples | 04:16 |
| jam | I've run into it elsewhere in our code where I wanted to put error types into a map | 04:16 |
| jam | but it fails to lookup because we get an unhashable error type. | 04:17 |
| jam | In that case, we just swallowed the panic | 04:17 |
| jam | that was the Serve code, IIRC | 04:17 |
| jam | which wants to map known errors into error codes | 04:17 |
| jam | thumper: state/apiserver/common/errors.go func singletonCode(err error) (string, bool) | 04:20 |
| jam | // All error types may not be hashable; deal with | 04:20 |
| jam | // that by catching the panic if we try to look up | 04:20 |
| jam | // a non-hashable type. | 04:20 |
| jam | thumper: if your error is a value type, then it pretty much *cannot* be the same object as some other object, because as soon as it is passed on the stack, it is a new object. | 04:20 |
| jam | as such, you can just say "if this isn't a Pointer() then it isn't the same object" | 04:21 |
| jam | and force the equivalence to false in that case. | 04:21 |
| thumper | jam: play.golang.org/p/dnd98Gl1O4 | 04:24 |
| jam | thumper: http://play.golang.org/p/IjRIj8SaWk | 04:27 |
| jam | without unboxing the internal implementation | 04:27 |
| jam | of interface | 04:28 |
| thumper | but catching panic is just as horrible | 04:28 |
| thumper | jam: I'm going to take this to the list anyway | 04:28 |
| thumper | jam: so we can discuss it there | 04:28 |
| thumper | personally I wish that golang made this easier for me, but it doesn't | 04:29 |
| thumper | we will have one icky thing or the other | 04:29 |
| thumper | both are horrible IMO | 04:29 |
| thumper | but which is more horrible? | 04:29 |
| * thumper shrugs | 04:29 | |
| jam | thumper: they give different results, too: http://play.golang.org/p/JQ5Ga8k-xd | 04:33 |
| jam | since if you have an 'error' it is pointing at a concrete value, so while you can't pass that value around without it changing to a new value, you *can* pass around the error interface to it | 04:33 |
| jam | which gives you a new interface at each step, but the underlying object is the same. | 04:34 |
| thumper | jam: well that is problematic | 04:34 |
| jam | thumper: though is the actual error you care about comparing to a value type ? | 04:34 |
| thumper | it may be | 04:34 |
| thumper | and that is one horrible bit | 04:34 |
| thumper | it may be a value type | 04:34 |
| thumper | and it *may* be uncomparable | 04:34 |
| thumper | and since it might happen | 04:35 |
| thumper | we need to handle it | 04:35 |
| jam | thumper: well, we do have some control on the system and can say things like "if you want your errors to be compared to be the same, they must be comparable types" | 04:35 |
| jam | I'm not sure what the use case is for being able to compare all possible error implementations | 04:36 |
| thumper | um... because you are writing an error handling library? | 04:36 |
| jam | thumper: its still your code | 04:36 |
| jam | you can give parameters of what is supported | 04:36 |
| thumper | not all of it | 04:36 |
| thumper | ugh | 04:37 |
| jam | Value type errors that are uncomparable aren't *nice* errors in go world | 04:37 |
| thumper | agreed | 04:38 |
| === vladk|offline is now known as vladk | ||
| davecheney | waigani: ping | 07:01 |
| waigani | davecheney: pong | 07:01 |
| davecheney | waigani: do you remember the issue that we had before vegas related to juju blowing up on 64k kernels ? | 07:03 |
| waigani | davecheney: going offline soon | 07:03 |
| davecheney | there was one test package that would always blow up | 07:03 |
| davecheney | waigani: if you don't remember, that is fine | 07:04 |
| waigani | davecheney: just trying to think ... | 07:04 |
| waigani | everything stopped working for me before vegas | 07:04 |
| waigani | yeah sorry, I'll have a look over the issues/emails in the morning and see if I can remember | 07:05 |
| davecheney | waigani: np | 07:05 |
| davecheney | i'll figure it out | 07:05 |
| davecheney | 2014-05-13 07:06:58 INFO juju.worker runner.go:260 start "peergrouper" | 07:07 |
| davecheney | 2014-05-13 07:06:58 DEBUG juju.worker.peergrouper worker.go:421 found new machine "0" | 07:07 |
| davecheney | 2014-05-13 07:06:58 ERROR juju.worker.peergrouper worker.go:137 peergrouper loop terminated: cannot get replica set status: cannot get replica set status: not running with --replSet | 07:07 |
| davecheney | 2014-05-13 07:06:58 ERROR juju.worker runner.go:218 exited "peergrouper": cannot get replica set status: cannot get replica set status: not running with --replSet | 07:07 |
| davecheney | 2014-05-13 07:06:58 INFO juju.worker runner.go:252 restarting "peergrouper" in 3s | 07:07 |
| davecheney | local provider shits itself in a loop | 07:07 |
| davecheney | bugs raised today: 3 | 07:17 |
| davecheney | bugs fixed today: 0 | 07:17 |
| davecheney | if I do | 08:09 |
| davecheney | juju deploy X | 08:10 |
| davecheney | X is resolved by the charm store, yes ? | 08:10 |
| davecheney | is it resolved by the client, or by the api server ? | 08:10 |
| davecheney | (having proxy issues) | 08:10 |
| davecheney | ubuntu@winton-02:~/src/launchpad.net/juju-core$ juju deploy --debug cs:trusty/mysql 2014-05-13 07:54:41 INFO juju.cmd supercommand.go:301 running juju-1.19.3-trusty-ppc64 [gccgo] | 08:10 |
| davecheney | 2014-05-13 07:54:41 DEBUG juju.conn api.go:185 trying cached API connection settings | 08:10 |
| davecheney | 2014-05-13 07:54:41 INFO juju.conn api.go:268 connecting to API addresses: [10.245.67.6:17070] | 08:10 |
| davecheney | 2014-05-13 07:54:41 INFO juju.state.api apiclient.go:198 dialing "wss://10.245.67.6:17070/" | 08:10 |
| davecheney | 2014-05-13 07:54:41 INFO juju.state.api apiclient.go:144 connection established to "wss://10.245.67.6:17070/" | 08:10 |
| davecheney | 2014-05-13 07:56:49 ERROR juju.cmd supercommand.go:304 cannot download charm "cs:trusty/mysql-0": Cannot access the charm store. Are you connected to the internet? Error details: Get https://store.juju.ubuntu.com/charm-info?charms=cs%3Atrusty%2Fmysql-0: dial tcp 91.189.95.67:443: connection timed out | 08:10 |
| === vladk is now known as vladk|offline | ||
| voidspace | morning all | 08:37 |
| axw | morning voidspace | 08:38 |
| axw | can someone please review a change to gomaasapi? https://code.launchpad.net/~axwalk/gomaasapi/testservice-nodes-release/+merge/219309 | 08:39 |
| axw | (I'm updating the MAAS provider's StopInstances to do bulk release) | 08:40 |
| wwitzel3 | voidspace: ping | 08:43 |
| voidspace | wwitzel3: morning :-) | 08:44 |
| voidspace | axw: morning | 08:44 |
| voidspace | wwitzel3: give me a few minutes and I'll join you in the hangout? | 08:44 |
| wwitzel3 | voidspace: sounds good | 08:45 |
| fwereade | axw, lbox? I really like line-by-line comments :) | 08:49 |
| fwereade | axw, (this is not really a case where it's super-important, 'tis true) | 08:50 |
| fwereade | axw, basically LGTM but a few comments | 08:53 |
| fwereade | jam, axw, voidspace, wwitzel3, et al: I'm approving https://codereview.appspot.com/91390043/ but I'd still appreciate comments | 08:58 |
| === vladk|offline is now known as vladk | ||
| axw | fwereade: sorry, does gomaasapi have lbox set up? | 09:00 |
| axw | does not appear to | 09:01 |
| fwereade | axw, good point -- but is it more than a .lbox file in the source tree? | 09:01 |
| axw | fwereade: making dinner, will take a look at your doc later | 09:01 |
| axw | fwereade: I have no idea | 09:01 |
| jam1 | fwereade: I've come up with a possible problem with just putting Version into another attribute of the request header. | 09:05 |
| fwereade | jam1, oh yes? | 09:06 |
| jam1 | In that old servers will just happily ignore the field and return the wrong thing | 09:06 |
| jam1 | fwereade: it just means we have to be more careful in not allowing the client-side code to accidentally try a new version request | 09:06 |
| voidspace | fwereade: will read | 09:07 |
| voidspace | fwereade: thanks | 09:07 |
| jam1 | fwereade: if we were to re-use the "id" field, then we would have gotten back ErrBadId, and we could have mapped that into "oh, that actually means NotImplemented" | 09:07 |
| jam1 | now we just get "ok" | 09:07 |
| fwereade | jam1, ie only send versioned requests to server that have already stated they support versions? that does sound reasonable to me | 09:07 |
| jam1 | I *think* we're ok, because we detect what the server supports at Login time. | 09:07 |
| jam1 | fwereade: it is just one of those things where we have to be "extra careful" because we can do it wrong and things will still seem to be working, but might be subtly broken. | 09:09 |
| jam1 | Like when we want to change the Set() api so that blank strings are accepted and don't mean "set to default". | 09:09 |
| jam1 | if the client code had a bug that it just always used 2,Set() it would "just work" except when you tried to set to an empty string on an old server and it would set it to the default value. | 09:10 |
| jam1 | fwereade: anyway, I have a model for how the client side code might work, and since we probe for available versions at Login time we should be able to do client side filtering appropriately | 09:10 |
| fwereade | jam1, yeah, I see your point, my personal instinct still slightly leads toward not reusing the field but I'm having a hard time justifying it -- at least a single layer of id-munging to support old clients using watcher ids is much more localised | 09:10 |
| jam1 | Its just one of those "I'd like it to break noisily when we make a mistake" | 09:11 |
| jam1 | fwereade: yeah, I like having it as an explicit Version. I was mostly just bringing up an issue that we should at least be aware of. | 09:11 |
| fwereade | jam1, cheers | 09:11 |
| jam1 | fwereade: I guess partially I was also hoping that I wouldn't have to do as much changes to the RPC package because I had a new field and could do magic there, but it turns out everything was only nice and orderly because of all the other changes I've done along the way. | 09:12 |
| jam1 | like handling Id early rather than late, etc. | 09:12 |
| * fwereade cheers | 09:12 | |
| jam | fwereade: I'm about halfway through your arch overview, and I'm trying to get a feel for how much we need the "here be dragons" side comments vs the "this is how it is laid out". I like letting people know that what we have is not perfect yet, I just wonder if they distract from getting an understanding first. | 09:23 |
| jam | IF we had footnotes, I think they'd make excellent footnotes | 09:24 |
| fwereade | jam1, I go back and forth -- "how it is" and "how it should be" *are* separate, but I find that focusing only on the former ends up giving it a misleading air of the latter | 09:24 |
| fwereade | jam1, yeah, footnotes would be the answer, wouldn'tthey | 09:25 |
| jam | sidebars, something :) | 09:25 |
| jam | fwereade: yeah, I certainly appreciate the "it is this way because it has been this way, and we don't quite understand why the alternatives weren't chosen" | 09:25 |
| jam | which seems like something an overview could at least hint at. | 09:25 |
| jam | "eponymous" a word I've probably only ever read, I'm not actually sure how it is pronounced :) | 09:26 |
| fwereade | jam, I like that word so I probably shouldn't use it ;) | 09:27 |
| fwereade | jam, I thought I remembered deleting it actually, maybe some part of my brain rebelled and inserted it somewhere else | 09:27 |
| jam | fwereade: for example, `Provisioner`, `Upgrader`, and `Uniter`, each used by the eponymous +worker types | 09:28 |
| jam | I'm fine with it, fwiw | 09:28 |
| jam | I was just reading it over and realized, I know exactly what he means, but I don't actually know how to pronounce that word. | 09:28 |
| fwereade | jam, I can say what I think it should sound like in the standup, but I'm not *certain* that I haven't just made that up | 09:29 |
| jam | fwereade: https://www.google.com/search?client=ubuntu&channel=fs&q=eponymous&ie=utf-8&oe=utf-8 has a "pronounce it" button | 09:29 |
| fwereade | jam, well, google agrees with me | 09:30 |
| fwereade | jam, not sure that's enough to pronounce myself "right" but I'll go with it ;) | 09:30 |
| jam | fwereade: :) | 09:31 |
| jam | fwereade: LGTM with some trivials | 09:33 |
| jam | for your arch doc | 09:33 |
| jam | https://codereview.appspot.com/91390043/ | 09:33 |
| fwereade | jam, thanks, I'll work those into the next CL | 09:38 |
| jam1 | fwereade: so API versioning again. I like the idea that changing the Version argument can change the type of the thing being returned, but changing the Id should *not* be allowed to do so. | 09:39 |
| jam1 | However, with us just registering a "give me an object" function | 09:39 |
| jam1 | we can't quite tell the type without actually getting a concrete one. | 09:40 |
| jam1 | the existing code used static introspection of functions to do some of this | 09:40 |
| jam1 | what I'd *like* is to be able to have | 09:40 |
| jam1 | instead of Register(func(State, Resources, Authorizer) (interface{}, error)) | 09:41 |
| jam1 | instead have | 09:41 |
| jam1 | Register(func(State, Resources, Authorizer) (FixedType, error)) | 09:41 |
| jam1 | but I'm not sure if you can actually get away with that. | 09:41 |
| jam1 | just because you need to be able to cast the function pointer you get to *something* to be able to call it (I think) | 09:42 |
| wwitzel3 | jam1, fwereade: you guys have time to chat about rsyslog API stuff real quick? voidspace and I are in a hangout | 09:42 |
| fwereade | wwitzel3, sure | 09:42 |
| jam1 | wwitzel3: can you link the hangout? | 09:42 |
| wwitzel3 | https://plus.google.com/hangouts/_/canonical.com/moonstone | 09:43 |
| fwereade | jam1, sorry, don't wait for me re standup | 10:39 |
| jam1 | fwereade: np | 10:39 |
| fwereade | jam1, just 1 main thing: you have work items, but do you also have people writing proto-docs and handing over to evilnickveitch? | 10:39 |
| jam1 | fwereade: I believe the intent is to have Frank focus on some of that as he comes over to core | 10:40 |
| jam1 | or you're talking more about proto-docs before implementation of current feature? | 10:40 |
| jam1 | fwereade: for what I'm working on, I still haven't actually gotten enough implementation to know how its going to hang together, but when I get a bit further I would be happy to write how to use API versioning doc | 10:41 |
| voidspace | jam1: as you suspected, bringing up new state servers doesn't rewrite the rsyslog conf on units | 11:02 |
| voidspace | jam1: so we *definitely* need the additional notification | 11:03 |
| jam | voidspace: so my guess is, that if you then bounce unit-wordpress-0 it will rewrite syslog.conf because it will read the new addresses from agent.conf | 11:03 |
| jam | but I think we want to do it right away | 11:03 |
| voidspace | right | 11:03 |
| voidspace | we're working on doing it the right way | 11:03 |
| jam | voidspace: I think ideally we would be writing rsyslog data from information we get directly from the API server, rather than punning the apiaddresses data | 11:04 |
| jam | agent.conf (pie-in-the-sky) would be only enough information to get your real truth from the API server. | 11:04 |
| voidspace | jam: we're going to add an RsyslogHostPorts endpoint (or similar) that effectively (currently) wraps APIHostPorts | 11:09 |
| voidspace | I think :-) | 11:09 |
| axw | jam: is there a way to merge an MP to trunk via LP? | 11:09 |
| jam | voidspace: so thats good, we just need to change the ports as the data goes through. | 11:09 |
| voidspace | right | 11:09 |
| axw | jam: or do I need to branch/merge/push | 11:09 |
| jam | axw: what trunk? | 11:09 |
| voidspace | we'll currently just add the global port to each address | 11:09 |
| axw | jam: gomaasapi | 11:09 |
| voidspace | but that's easy to then change if we *actually* have different ports | 11:10 |
| jam | axw: branch and push | 11:10 |
| axw | ok, ta | 11:10 |
| jam | axw: gwacl is controlled by our bot, but gomaas is manual | 11:10 |
| jam | IIRC | 11:10 |
| axw | yep, seems so. thanks | 11:10 |
| wwitzel3 | voidspace: https://code.launchpad.net/~wwitzel3/juju-core/009-ha-rsyslog-api | 12:08 |
| perrito666 | could someone please tal https://codereview.appspot.com/92320043/ ? | 12:34 |
| perrito666 | and yes, that is awk that I am using, I am from the past | 12:35 |
| natefinch | perrito666: looking | 12:43 |
| perrito666 | natefinch: turns out it was a bit less trivial than originally thought :p | 12:44 |
| natefinch | perrito666: heh, I never thought it would be trivial ;) | 12:45 |
| perrito666 | I am an optimistic guy | 12:45 |
| natefinch | sleep 60 ... well that inspires confidence | 12:45 |
| natefinch | (not a judgement of the programmer) | 12:45 |
| perrito666 | mm, did I push that? | 12:47 |
| natefinch | it's there, yeah | 12:47 |
| perrito666 | tx god for restores, bugs in bash in go are a pain to spot | 12:47 |
| perrito666 | s/restores/reviews | 12:48 |
| natefinch | honestly, the problem is that we're just passing huge strings to bash. That's not really the way we should be running terminal commands | 12:48 |
| natefinch | the single { for mongo and the double {{ for go templates is particularly gnarly | 12:49 |
| perrito666 | natefinch: you should see how that outputs to the shell | 12:50 |
| perrito666 | '\"'\"' <-- that is ' | 12:50 |
| natefinch | heh | 12:50 |
| natefinch | reminds me of "\\\\" for a literal \ in a regex | 12:51 |
| natefinch | "http:\\\\\\\\" | 12:52 |
| jam | perrito666: I'm ~ sure that you can change the agent.conf on machine-0 to just read "localhost:17070" and it would be happy | 12:52 |
| perrito666 | I can try | 12:54 |
| jam | perrito666: that can potentially simplify your logic a lot | 12:55 |
| perrito666 | jam: true | 12:56 |
| jam | perrito666: also, is it possible to use the values for "state-port" and "api-port" instead of assuming they are 37017 and 17017 respectively? | 12:57 |
| jam | If it is hard to do, don't worry too much about it, as I don't think anyone has *actually* run with a non-standard port, but the configuration *is* ther. | 12:57 |
| perrito666 | jam: it is not that much effort to add it, I have been avoiding additions beyond necessity because restore is quite fragile and I did not want to make future/present bug hunting even harder | 12:59 |
| natefinch | I wish we could just remove the port configuration, it would make our code significantly simpler. | 13:02 |
| === BradCrittenden is now known as bac | ||
| perrito666 | brb | 13:24 |
| natefinch | jam: how do I figure out what revision a branch is on, say if the code were copied to a github, for example? .bzr/branch/last-revision has a revision number, but the diffs look off | 13:28 |
| jam | natefinch: every branch has its own revision numbering but the revision-id is unique. You can do "bzr revno" or "bzr revision-info" to get details | 13:29 |
| jam | natefinch: and you can't exactly push a bzr branch to github | 13:29 |
| jam | but otherwise you can pass "-d" to revision-info to select a different location | 13:29 |
| jam | bzr revision-info -d lp:juju-core | 13:29 |
| jam | for example | 13:30 |
| natefinch | bzr revno worked. | 13:30 |
| jam | natefinch: sure I just wanted to be clear that having the same revno doesn't mean it has the same contents, because if we are both at 2250 and we both commit, we'll both be at 2251 but have different revision-ids | 13:31 |
| natefinch | the code was copied into git, but I wasan't sure if that would throw off bzr, but it seems the .bzr stuff was left intact | 13:32 |
| natefinch | jam: ahh I see | 13:32 |
| jam | natefinch: so if you're using bzr-git, we might be magic enough to map into git and then back into bzr again. | 13:32 |
| jam | otherwise you wouldn't be able to do "bzr revno $GITLOCATION" | 13:33 |
| natefinch | I presume revnos are at least unique per branch, right? so trunk 2200 is a definitive revision | 13:34 |
| jam | natefinch: it is, but pull/push can change the order of history and 2200 *can* become something different. | 13:34 |
| jam | there are ways to enforce it (set append-revisions-only will refuse a push that would change revnos) | 13:35 |
| natefinch | ew.... so, why even bother with revision numbers if they don't mean anything static? | 13:38 |
| jam | natefinch: because most of the time (and the tool can help enforce it) they are static within a branch | 13:40 |
| jam | and they are *far* more meaningful and understandable than hashes | 13:40 |
| jam | if I tell you I changed it at rev 2500 in trunk, you can tell really quickly if your copy of trunk has the change I proposed | 13:41 |
| jam | things like trunk branches should always have append_revisions_only set (I believe I did that for juju-core) | 13:42 |
| jam | so push can't change the old numbers. | 13:42 |
| natefinch | interesting | 13:44 |
| natefinch | I do like numbers I can understand rather than just giant hashes that have no intrinsic meaning | 13:45 |
| bodie_ | mornin fellas | 13:45 |
| natefinch | morning bodie_ | 13:45 |
| perrito666 | sinzui: you can try turning on the restore test again | 13:48 |
| sinzui | perrito666, I saw the change and queued the test | 13:48 |
| perrito666 | great, not that I dont have faith but Ill be expectant | 13:50 |
| fwereade | guys, I'm feeling somewhat sick, I'm going to go and lie down for a while, probably back later | 14:11 |
| perrito666 | ok, get better | 14:12 |
| wwitzel3 | natefinch: you want to assit with this code structuring? | 14:19 |
| wwitzel3 | assist | 14:20 |
| natefinch | wwitzel3: oh yeah, sorry, one second, I'll get back in the hangout | 14:25 |
| jam | sinzui: is there a new URL for reports.vapor.ws ? or is it intended to be private | 14:47 |
| sinzui | jam, oh! | 14:48 |
| sinzui | jam, I think abentley put it behind apache in the last 12 hours | 14:48 |
| sinzui | http://reports.vapour.ws/ | 14:48 |
| jam | sinzui: ah, just directly not at the random port | 14:48 |
| perrito666 | hey, does anyone have the link to the doc from the sprint, it is not showing in my docs as shared with me | 14:49 |
| perrito666 | natefinch: well, apparently we where very consistent on not writing details regardin WAL | 14:53 |
| perrito666 | :p | 14:53 |
| natefinch | perrito666: https://docs.google.com/a/canonical.com/document/d/1XZN2Wnqlag9je73mGqk-Qs9tx1gvOH0-wxMwrlDrQU4/edit#heading=h.hpeo5xue46ue | 14:56 |
| natefinch | perrito666: if you go to google docs for canonical, it should be in the list of recent documents, which is where I ususally go to find stuff | 14:56 |
| perrito666 | ah, recent, didnt think of that | 14:57 |
| * perrito666 facepalms | 14:57 | |
| natefinch | perrito666: it's ok, it took me like 6 months at canonical to start using recent :) | 14:58 |
| perrito666 | the fact that the listing of files for google docs looks like a teenagers windows desktop in the 90s does not help at all :p | 14:59 |
| === jcw4_ is now known as jcw4 | ||
| sinzui | perrito666, your revision is building now in CI. I hope to see a pass in the next 80 minutes http://juju-ci.vapour.ws:8080/ | 15:24 |
| perrito666 | sinzui: oh the suspense | 15:33 |
| perrito666 | hey anyone around here was present at the HA talks, most precisely when you talked about WAL? I think I am on track but would love to double check | 15:37 |
| perrito666 | sinzui: yay, a dns humanly readable name cool | 15:37 |
| sinzui | perrito666, PASS http://juju-ci.vapour.ws:8080/job/functional-backup-restore-devel/806/console | 16:24 |
| perrito666 | \o/ | 16:25 |
| Sebas_ | hi folks :) | 16:51 |
| voidspace | fwereade: ping | 16:56 |
| fwereade | voidspace, pong | 16:56 |
| voidspace | fwereade: you gave my branch an LGTM today | 16:56 |
| fwereade | voidspace, that was nice of me :) | 16:57 |
| voidspace | fwereade: it turned out I'd missed some of our copy-pasta config tests | 16:57 |
| voidspace | fwereade: haha, it was premature of you ;-) | 16:57 |
| voidspace | but yes, nice | 16:57 |
| voidspace | fwereade: so I've fixed those tests to use the new format, including the ruleset for a single state server | 16:57 |
| voidspace | fwereade: plus a test that if we have multiple state servers that we get entries for both (for the case of two) in the generated template | 16:57 |
| fwereade | voidspace, <3 | 16:58 |
| voidspace | fwereade: essential testing the logic in the template | 16:58 |
| voidspace | fwereade: should I ask for another look at the branch, or as it's *essentially* test fixes should I just reapprove? | 16:58 |
| bodie_ | fwereade: should we think about merging the action yaml parsing stuff into our code before dressing it for MR? | 16:59 |
| fwereade | voidspace, the general answer is "use your judgment" -- if you're confident in it, and the approach has been LGTMed, don't feel you *have* to get *everything* rereviewed | 17:00 |
| bodie_ | or make those two separate mr's (we'd assumed the previous work was a discard) | 17:00 |
| voidspace | fwereade: it's just fixing tests, and they all pass this time (*coff*) so I'm inclined to just re-approve | 17:00 |
| voidspace | thanks | 17:00 |
| fwereade | voidspace, go for it | 17:00 |
| fwereade | voidspace, we have the landing bot after all, so all you *really* risk there is looking stupid if they keep on failing ;p | 17:01 |
| fwereade | bodie_, keep them separate | 17:01 |
| fwereade | bodie_, that CL is basically fine, I don't want it to grow and grow and incorporate more and more, that's painful for everybody | 17:01 |
| voidspace | fwereade: if I was afraid of looking stupid I wouldn't get much done... | 17:01 |
| bodie_ | was that a dumb enough question? ;) | 17:02 |
| bodie_ | yes | 17:02 |
| fwereade | bodie_, until it's exposed in the UX, and until it's doing things that affect actual DB integrity/sanity, small incremental steps are great | 17:02 |
| fwereade | bodie_, keep trying ;p | 17:02 |
| fwereade | bodie_, I'm sure you can ask much dumber questions if you put your mind to it ;p | 17:02 |
| bodie_ | fwereade, I suppose the worst of them are the ones that remain unasked and instead are expressed as dumb code ;) | 17:05 |
| fwereade | bodie_, exactly :) | 17:06 |
| wwitzel3 | anyone have a second to look at a screenshare and tell my why my tests are getting a state server not found error? fwereade, natefinch ? | 17:09 |
| fwereade | wwitzel3, not much more than a second tbh, but I can try :) | 17:11 |
| wwitzel3 | https://plus.google.com/hangouts/_/canonical.com/moonstone | 17:11 |
| natefinch | wwitzel3: ug. I can look, though the tests that try to set up an environment always give me like 3 days of trouble | 17:11 |
| voidspace | natefinch: we have 20 minutes ;-) | 17:11 |
| natefinch | voidspace: luckily fwereade offered assistance for a second, which is almost certainly worth more than my 20 minutes :) | 17:12 |
| Sebas_ | hey there! I'm recently having an issue with lxc containers created by the juju-local in an ubuntu trusty | 17:17 |
| Sebas_ | I installed a new fresh ubuntu each time (3 times by now) | 17:17 |
| Sebas_ | the lxcbr0 is missing | 17:18 |
| Sebas_ | so everything is failing apart :( | 17:18 |
| Sebas_ | someone have's a clue of what can be or where to look? | 17:18 |
| natefinch | Sebas_: can you pastebin your /etc/lxc/lxc.conf /etc/default/lxc and /etc/default/lxc-net ? | 17:21 |
| Sebas_ | natefinch: of course! | 17:22 |
| Sebas_ | natefinch: just a minute | 17:22 |
| natefinch | Sebas_: I'm not an lxc expert, but it sounds like maybe your lxc is configured to use a different bridge, which is a known problem with juju local | 17:22 |
| Sebas_ | natefinch: there's no /etc/lxc/lxc.conf | 17:23 |
| natefinch | Sebas_: that's ok, there isn't for me either, I think that's the default | 17:23 |
| Sebas_ | hmmm but in the local machine exist properly | 17:23 |
| Sebas_ | like lxcbr0 | 17:23 |
| natefinch | Sebas_: check /etc/default/lxc-net - that's where mine is configured to use lxcbr0, perhaps yours is configured differently for some reason | 17:25 |
| Sebas_ | natefinch: take a look http://pastebin.com/KN4XxqrD | 17:26 |
| Sebas_ | i'm comparing with a local virtualbox machine that is working | 17:27 |
| natefinch | looks just like mine | 17:27 |
| natefinch | Sebas_: Specifically what error are you seeing? | 17:28 |
| Sebas_ | natefinch: the bridge is just missing :( | 17:28 |
| Sebas_ | in the container | 17:28 |
| Sebas_ | its really wired | 17:29 |
| natefinch | Sebas_: can you copy and paste the actual text? It'll help me find it in the code and maybe figure out what it's trying to do and why it's failing | 17:29 |
| Sebas_ | natefinch: the problem is that there isn't an error | 17:30 |
| Sebas_ | its just missing so, the from it can't access internet from the container | 17:30 |
| voidspace | EOD folks | 17:32 |
| voidspace | g'night all | 17:32 |
| voidspace | see you tomorrow | 17:32 |
| natefinch | night voidspace | 17:32 |
| Sebas_ | voidspace g'night | 17:32 |
| Sebas_ | natefinch: whats your kernel? mine is 3.13.0-24-generic | 17:34 |
| Sebas_ | seems ok | 17:35 |
| natefinch | Sebas_: I'm on 3.13.1, but I doubt that's the difference | 17:36 |
| Sebas_ | yep :( | 17:37 |
| Sebas_ | natefinch: i dump some dmesg | 17:37 |
| Sebas_ | http://pastebin.com/ZHjDkhHE | 17:37 |
| Sebas_ | just wat I thought is relevant | 17:37 |
| wwitzel3 | EOD for me | 17:40 |
| perrito666 | wwitzel3: bye | 17:40 |
| natefinch | Sebas_: brb, I need to reboot | 17:43 |
| === vladk is now known as vladk|offline | ||
| perrito666 | fwereade: still on the clock? | 17:50 |
| natefinch | perrito666: he's salary, that means he's always on the clock ;) | 17:50 |
| perrito666 | natefinch: I have no clue what that means | 17:51 |
| perrito666 | :p | 17:51 |
| natefinch | perrito666: salaried vs. hourly wages. he gets paid the same amount whether he works 20 hours a week or 120. In theory, "on the clock" applies to people who have to clock in and out because they're paid by the hour (wage). | 17:52 |
| perrito666 | ahh I see no such linguistic distinction in spanish | 17:53 |
| perrito666 | salary person means you get paid :p and then you need to specify by/the X | 17:54 |
| natefinch | yeah, we say salaried vs. hourly to differentiate | 17:54 |
| perrito666 | anyway, I just wanted to know what percentage of his attention was still on the screen, which apparently amounts to 0 :p | 17:54 |
| natefinch | haha well, it is rather late there | 17:55 |
| perrito666 | If I understood correctly the adding wal to mongo was only to add --journal to the mongo-db invocation, and perhaps find a way to test that | 17:55 |
| perrito666 | I was just hunting for someone that actually took part on that conversation | 17:56 |
| natefinch | perrito666: if --journal is defined by the mongo docs as turning on WAL, then all you need to test is that we call --journal. No need to test that mongodb does what it says it'll do | 17:56 |
| natefinch | and maybe contemplate what happens when someone upgrades from a previous juju that didn't specify --journal | 17:57 |
| perrito666 | natefinch: so it says :) http://docs.mongodb.org/manual/tutorial/manage-journaling/ | 17:57 |
| Sebas__ | natefinch: thoughts ? :P | 17:58 |
| natefinch | Sebas__: sorry, got distracted. Is the problem then just that the containers can't contact the internet? | 17:58 |
| Sebas__ | natefinch: btw thanks for your help :) | 17:58 |
| natefinch | Sebas__: doing my best, but you've unfortunately encountered the Juju dev with the least amount of Linux experience :) | 17:59 |
| Sebas__ | yep, because of the missing lxcbr0 bridge | 17:59 |
| natefinch | Sebas__: you said you had lxcbr0 on your local machine, right? | 17:59 |
| Sebas__ | yes | 17:59 |
| Sebas__ | but not into the container | 18:00 |
| Sebas__ | which is wired hehe | 18:00 |
| natefinch | Sebas__: so, the container doesn't need lxcbr0.... mine don't have that, and they can contact the internet just fine | 18:00 |
| Sebas__ | hmmm | 18:00 |
| Sebas__ | natefinch: you are right! | 18:01 |
| Sebas__ | so now i more lost | 18:01 |
| Sebas__ | hehe | 18:01 |
| natefinch | perrito666: do you know anything about lxc containers and their networking? | 18:01 |
| perrito666 | natefinch: very little you want to ask to vladk|offline or dimitern | 18:05 |
| Sebas__ | the thing is that, it isn't a random error | 18:06 |
| Sebas__ | is with fresh installed ubuntu trusty | 18:06 |
| perrito666 | lxbr0 iirc is the virt interface for bridging lxc containers, the containers themselves should have "regular" ifaces | 18:06 |
| Sebas__ | perrito666: yeah, and it seems it haves, i checked now | 18:08 |
| Sebas__ | and the eth0 is there like it should | 18:08 |
| natefinch | Sebas__: so, all juju does is make LXC containers using the usual methods. It's not really doing anything magical to the containers. I don't know why your containers are broken, but it's likely an environmental issue rather than a juju issue, per se. I know that doesn't help you much, though. You might try getting on #ubuntu and seeing if someone there can help debug your lxc issues. | 18:09 |
| Sebas__ | ooh ohh! i think i know what is it | 18:10 |
| Sebas__ | natefinch: you are correct | 18:10 |
| Sebas__ | till now I didn't know what was it | 18:10 |
| Sebas__ | but | 18:10 |
| Sebas__ | i ping just the ip to see if wasn't an resolve problem | 18:11 |
| Sebas__ | of geteway | 18:11 |
| Sebas__ | and it pings!! | 18:11 |
| Sebas__ | im going to try to route by hand | 18:12 |
| natefinch | cool :) | 18:12 |
| natefinch | brb, gotta water the carrots | 18:12 |
| Sebas__ | natefinch: yeah but the route already exist :( | 18:14 |
| Sebas__ | damn it ! | 18:15 |
| Sebas__ | hehe | 18:15 |
| fwereade | perrito666, passing by briefly: http://docs.mongodb.org/manual/tutorial/manage-journaling/ seems to imply it's on by default (at least on 64-bit) -- might we be thinking about the writeconcern, which I think needs fixing too? | 18:22 |
| natefinch | fwereade: I have writeconcern in a different branch. Possibly this is a noop then | 18:23 |
| fwereade | perrito666, cool -- it's still worth doing for 32-bit systems though | 18:23 |
| perrito666 | fwereade: indeed, for what I see we even have tests that check for journaling stuff happening, we seem to be assuming it on by default | 18:29 |
| === BradCrittenden is now known as bac | ||
| === vladk|offline is now known as vladk | ||
| perrito666 | ok, eod for me | 19:27 |
| perrito666 | bye guys | 19:27 |
| natefinch | perrito666: see ya | 19:28 |
| thumper | cmars: morning | 20:09 |
| cmars | hi thumper | 20:10 |
| thumper | cmars: when I organised our chat in about an hour I had forgotten about a physio appt I have | 20:10 |
| thumper | cmars: can we push it back an hour? | 20:10 |
| thumper | so in 1:50? | 20:10 |
| cmars | sure | 20:11 |
| thumper | thanks | 20:12 |
| thumper | I'll put in the calendar this time | 20:12 |
| fwereade | thumper, btw, my eyes glazed over a little looking at that CL, but progress seems sane -- was there anything in particular you wanted to talk about? | 20:39 |
| thumper | fwereade: agreement on direction mainly | 20:40 |
| fwereade | cmars, not sure if you saw my review; I'm mainly just unsure what forces prompted it. separate certs for state vs api seems perfectly sane to me, I just haven't thought through the upgrade process and wanted to be reassured that someone had | 20:40 |
| === Ursinha is now known as Ursinha-afk | ||
| sinzui | hello rocket scientists. Does anyone have a strategy for using a newly built tool for an arch not in the streams. I want to add-machine a ppc instance. Ubuntu never published an official juju-core 1.18.2, but I tested a tool that I want juju to use when provisioning | 20:53 |
| * sinzui ponders creating a private stream with extra tools. | 20:54 | |
| sinzui | natefinch, ^ have you ever pondered this | 20:55 |
| fwereade | sinzui, that would be my advice -- wallyworld's `juju metadata` stuff should make it doable? | 20:55 |
| * fwereade waves his hands enthusiastically | 20:55 | |
| sinzui | fwereade, yes, I can do that making a new stream. I can change juju-metadata-tools exactly once because of a bug in juju | 20:55 |
| fwereade | sinzui, hmm, is that failed mutability or failed immutability? | 20:56 |
| wallyworld | you should be able to create metadata for just the one tarball, and put that plus the tarball in cloud storage. it will look there and fallback to streams.c.c for other arches | 20:57 |
| sinzui | fwereade, we cannot change *-metadata-url once set, but we can bootstrap with out it (use streams.canonical.com), then change it once later | 20:57 |
| fwereade | wallyworld, I still get nervous about the falling back :) | 20:57 |
| fwereade | sinzui, heh, failed immutability then | 20:57 |
| sinzui | I reported the tools version of the bug, other users reported the image- version of the bug | 20:57 |
| fwereade | wallyworld, do you recall why we made those immutable? I can see how it *could* be a can of worms, but there's a clear use case there as well | 20:58 |
| wallyworld | fwereade: can't recall now sorry :-( i'm sure it was a good idea at the time | 20:58 |
| wallyworld | also, it never used to fallback, but we made it so | 20:58 |
| sinzui | fwereade, Once juju-1.18.2-trusty-ppc64el.tgz is know to the juju-ci-3 env, I am 30 minutes from have two slaves in two different networks to prove trans-cloud envs rock | 20:59 |
| sinzui | wallyworld, It might have made sense to not let you change the values before we added mirrors | 20:59 |
| fwereade | wallyworld, yeah, I think the falling back was a bit of an act of desperation... if it's *possible* to find *some* tools, please do :) | 20:59 |
| fwereade | sinzui, awesome | 21:00 |
| === Ursinha-afk is now known as Ursinha | ||
| wallyworld | fwereade: don't quite grok the last tools comment. the fallback thing was to allow some tools to be found in cloud storage, say, and the rest from streams | 21:02 |
| fwereade | wallyworld, yeah, it's precisely that that makes me nervous -- 2 different locations for tools raises an unholy spectre of two different versions of juju that think they're the same | 21:03 |
| fwereade | wallyworld, it's something that scares me, but probably not something I ought to get too stressed about | 21:03 |
| fwereade | wallyworld, and the happy path is evidently happy | 21:03 |
| wallyworld | i sorta agree but users complained and it was not usable the other way | 21:03 |
| bodie_ | famous last words | 21:03 |
| fwereade | wallyworld, I'm just whining, you know how I love to do that | 21:04 |
| wallyworld | you are english :-) | 21:04 |
| fwereade | bodie_, I've had 6 months since I first said them ;p | 21:04 |
| wallyworld | sinzui: do you have all you need to try out the jenkins github lander with my test core repo? is there anything i can do? | 21:05 |
| sinzui | fwereade, wallyworld . I think the scenario here is ops may want to choose new source for images and tools. They certainly want just one source. they may want to change the source to get special images or tools. private clouds need to do this if they move things. envs in public clouds may want to get special streams | 21:07 |
| waigani | morning all, back again :) | 21:07 |
| === BradCrittenden is now known as bac | ||
| sinzui | wallyworld, I need time. I don't think I can start the tests until monday. | 21:07 |
| wallyworld | no worries, just ensuring i didn't need to do anything else to help | 21:08 |
| wallyworld | not urgent :-) | 21:08 |
| fwereade | sinzui, that was sorta my perspective; definitely +1 on making them mutable; *also* +1 on mandating a single source, but my nightmares re allowing multiple have not yet come to pass, so your job right now should be easier even if not for my favourite reaons | 21:08 |
| wallyworld | sinzui: if that url bug is not already high, we can add it to the high pool | 21:09 |
| bodie_ | fwereade -- I'm getting a strong spidey sense about the way we're trying to do Actions. can you help me understand why it's necessary for the hook to trust the action info? | 21:10 |
| bodie_ | if I were writing an Action hook, I'd be parsing args myself | 21:10 |
| bodie_ | unless I'm misunderstanding the purpose of this | 21:10 |
| fwereade | bodie_, one somewhat-significant reason is so that we can provide a nice gui for it, but that probably shouldn't be (the* overriding reason within core | 21:13 |
| fwereade | bodie_, declaring what an action accepts in a standard format STM to be a Good Thing on general principles, too, fwiw | 21:14 |
| fwereade | bodie_, and if we *do* guarantee that the data we deliver will match the declared interface, we should be able to save charm authors quite a lot of boilerplate checking | 21:14 |
| fwereade | bodie_, if we don't, I think we add quite a lot to the burden of implementing an action | 21:15 |
| fwereade | bodie_, imagine how bad it would suck if every single method just took (args ...interface{}) | 21:15 |
| fwereade | bodie_, spidey-sense rising or fading? ;) | 21:17 |
| cmars | does anyone else see intermittent failures in cmd/jujud when running all the tests? they usually disappear if I 'go test ./cmd/jujud' by itself | 21:27 |
| thumper | yes | 21:29 |
| bodie_ | fwereade, I see regarding reducing Action boilerplate | 21:33 |
| bodie_ | should've mentioned I was stepping away | 21:34 |
| bodie_ | yes, it seems like everything using interface{} would somewhat defeat the utility of Go ;) | 21:35 |
| bodie_ | yet if we're using json-schema on the charm, why is it OK to define in a yaml file? | 21:39 |
| wallyworld | cmars: we're working on fixing the test suite but there's a lot to work through | 21:59 |
| wallyworld | fingers crossed we'll get it sorted real soon now | 21:59 |
| cmars | wallyworld, thanks. I was mostly wondering if it was just my dev env | 21:59 |
| wallyworld | nah, the bot is sad too | 22:00 |
| wallyworld | cmars: feel free to file a bug tagged test-failure and we can look to ensure it's not a new issue | 22:00 |
| wallyworld | thumper: if you are interested or have a spare moment, i'd love a look at https://codereview.appspot.com/94410043 it consolidates the lxc clone settings | 22:02 |
| thumper | will look later | 22:02 |
| wallyworld | no hurry | 22:03 |
| === vladk is now known as vladk|offline | ||
| === vladk|offline is now known as vladk | ||
| sinzui | wallyworld, any insights? http://pastebin.ubuntu.com/7459884/ | 22:39 |
| wallyworld | looking | 22:46 |
| === vladk is now known as vladk|offline | ||
| wallyworld | sinzui: can you also paste the index file? | 22:51 |
| sinzui | wallyworld, http://pastebin.ubuntu.com/7459905/ | 22:52 |
| wallyworld | sinzui: sadly there's a lack of logging in the code around where i suspect it's failing, i'm still looking | 23:02 |
| waigani | menn0: standup :) | 23:03 |
| wallyworld | can we get the all-machines.log? | 23:03 |
| sinzui | wallyworld, thank you. I have a fallback plan of bootstrapping the machine as a separate env. | 23:03 |
| wallyworld | sinzui: before you do, grab the all-machines.log for me and i'll look at that | 23:04 |
| wallyworld | i think it's failing creating the manual provisioning script | 23:04 |
| * sinzui does | 23:04 | |
| sinzui | wallyworld, oh, 403. damn, when I recreated this container it lost the public permissions | 23:37 |
| sinzui | wallyworld, I see a ppc64 machine on a different cloud being provisioned | 23:38 |
| perrito666 | sinzui: still around? | 23:38 |
| * sinzui is so excited | 23:38 | |
| sinzui | perrito666, I am | 23:38 |
| perrito666 | sinzui: I have a patch proposed for HA restore, I was wondering if I should push it once its reviewed or if there is a CI test for that story in the foreseeable future | 23:40 |
| perrito666 | no pressure | 23:40 |
| sinzui | perrito666, I will have a test running tomorrow morning or even tonight. I sketched it out last week. | 23:41 |
| perrito666 | wow you are fast :) there is a comment asking this on the bug, if you couuld add the info as an answer there once the test is there I will be very thankful | 23:42 |
| perrito666 | (also I will be happy not to do that by hand again :p) | 23:42 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!