| === vladk is now known as vladk|offline | ||
| hazmat` | no caps letters in services names. | 00:12 |
|---|---|---|
| * hazmat` wonders why | 00:12 | |
| rick_h_ | url-able? | 00:12 |
| hazmat` | rick_h_, urls can include caps letters. lwn.net/Articles/587373/#Comments | 00:14 |
| rick_h_ | hazmat`: sure, but it's generally nice to make Comments and comments not do different things | 00:15 |
| hazmat` | humbug ;-) | 00:15 |
| wallyworld_ | axw: hiya, when you have a minute, can we have a hangout? | 00:59 |
| axw | wallyworld_: heya, sure just a moment | 01:00 |
| wallyworld_ | ok, i'll set one up for when you are ready | 01:01 |
| wallyworld_ | https://plus.google.com/hangouts/_/7acpj2ql7v7hcjv3aea5s03kog | 01:01 |
| axw | wallyworld_: ready... it says "the party is over", did you close it? | 01:02 |
| wallyworld_ | no | 01:03 |
| wallyworld_ | hmm, let me try again | 01:03 |
| wallyworld_ | i sent an invite | 01:03 |
| axw | wallyworld_: I think I lost you | 01:07 |
| axw | nope | 01:07 |
| * thumper digs out the ice pack | 01:26 | |
| rick_h_ | thumper: stop hitting yourself | 01:28 |
| thumper | I was even wearing my head gear | 01:29 |
| thumper | menn0: are you reusing branches? | 01:40 |
| menn0 | i was just writing to you about that :) | 01:40 |
| menn0 | i'm using the same branch because it's a continuation of the same work | 01:40 |
| menn0 | not the right approach? | 01:41 |
| menn0 | (or could I have used lbox propose --new-bug?) | 01:41 |
| menn0 | thumper: ? | 01:43 |
| thumper | --new-bug is something different | 01:43 |
| thumper | I tend to use new branches, based of the old ones, for continuation of work | 01:43 |
| thumper | this way, branches linked to bugs, merge proposals are simpler, and lbox doesn't get confused | 01:44 |
| thumper | the code review there now shows it as already approved | 01:44 |
| menn0 | yeah i saw that :( | 01:44 |
| thumper | more a function of our tools and workflow | 01:44 |
| menn0 | so to recover... delete the review and try again from a new branch | 01:44 |
| menn0 | ? | 01:44 |
| thumper | nah, don't worry for this one | 01:44 |
| thumper | just try to remember for the next | 01:45 |
| menn0 | ok | 01:45 |
| thumper | and we should write that in the developer documentation :-) | 01:45 |
| menn0 | writing that down now ... | 01:46 |
| menn0 | lunch time ... | 01:47 |
| thumper | wallyworld_: are you still wanting to catch up weekly? | 01:53 |
| wallyworld_ | sure, why not | 01:53 |
| thumper | ok, I'll just go make some lunch | 01:54 |
| axw | wallyworld_: seems this is P1 -- https://bugs.launchpad.net/juju-core/+bug/1316869 | 01:58 |
| _mup_ | Bug #1316869: juju sync-tools destroys the environment when given an invalid source <juju-core:New> <https://launchpad.net/bugs/1316869> | 01:58 |
| axw | wallyworld_: do you want me to look at this, or keep looking at the LXC thing? | 01:58 |
| wallyworld_ | axw: i thought at first glance that env one was a non issue? | 01:58 |
| wallyworld_ | but maybe they want to keep the newly created env | 01:58 |
| axw | wallyworld_: no I don't think so. after looking at the log more closely, it shouldn't be destroying | 01:59 |
| wallyworld_ | in that case fix that one first | 01:59 |
| wallyworld_ | we'll need to get a release done with that, both 1.18 and 1.19 i expect | 01:59 |
| wallyworld_ | axw: before you start looking at the fast lxc stuff again, can you please ping me? | 02:32 |
| axw | wallyworld_: will do | 02:42 |
| wallyworld_ | ta, we need to tweak the implementation | 02:43 |
| === hatch__ is now known as hatch | ||
| thumper | anyone interested in reading over my developer doc on writing tests? https://codereview.appspot.com/96110043/ | 03:46 |
| jcw4 | thumper: this document looks very useful... thanks | 03:56 |
| thumper | np | 03:57 |
| menn0 | thumper: review just submitted. very useful! | 04:40 |
| thumper | menn0: ta | 04:49 |
| fwereade | thumper, morning/evening | 05:20 |
| thumper | fwereade: just being called away.. bbs | 05:20 |
| fwereade | thumper, ok :) | 05:20 |
| thumper | fwereade: back | 05:30 |
| thumper | kitchen/cooking emergency | 05:30 |
| fwereade | thumper, no worries | 05:30 |
| fwereade | thumper, thanks for the test docs, just writing some comments | 05:30 |
| thumper | fwereade: did you want a quick hangout? | 05:30 |
| thumper | fwereade: I'm just adding a section on checkers, and will refer to the other checkers package | 05:31 |
| fwereade | thumper, cool; and yes I do, in say 5-10 mins? | 05:31 |
| thumper | sure | 05:32 |
| jam1 | fwereade: morning, I'd like to run something by you that I discovered while doing the type introspection. | 05:55 |
| fwereade | jam1, just in with thumper at the moment, will let you know when I'm out | 05:56 |
| jam1 | fwereade: yeah, no prob | 05:56 |
| axw | if anyone has 1.18 locally, can you please try running BootstrapSuite.TestTest in cmd/juju? | 06:01 |
| jam1 | axw: you know you can always switch to 1.18, right? | 06:04 |
| axw | jam1: I possibly don't | 06:05 |
| axw | :) | 06:05 |
| jam1 | axw: you want the tip of the 1.18 branch? | 06:05 |
| axw | jam1: sorry, maybe I misunderstood. I know I can clone lp:juju-core/1.18 | 06:06 |
| axw | is there a way to switch to 1.18 within the same repo? | 06:06 |
| axw | I guess just switch... it's just a branch isn't it | 06:06 |
| jam1 | axw: I'm not sure how your files on disk are layed out, but if you are using a lightweight checkout or colocated branches, you can. | 06:06 |
| jam1 | axw: but also the 1.18 branch is merged into trunk | 06:06 |
| jam1 | so you can "bzr update -r juju-1.18.2" | 06:06 |
| axw | jam1: cool, thanks | 06:07 |
| jam1 | axw: you probably need to run "godeps -u dependencies.tsv" because of differences | 06:07 |
| axw | jam1: I was actually interested in someone reproducing an error I was getting on the 1.18 branch, but this is useful info anyway | 06:07 |
| axw | I think I've tracked down the error in the mean tim | 06:07 |
| axw | time* | 06:07 |
| jam1 | axw: hmm.. tags are missing, I'll get them put in, just a sec | 06:07 |
| jam1 | looks like people have been backporting and not keeping trunk up to date with 1.18, I'll spend some cycles to bring them in sync again. | 06:20 |
| fwereade | jam1, https://plus.google.com/hangouts/_/gux2ehqneizflyei3np3mfnyzya?hl=en | 06:21 |
| jam1 | fwereade: so if I *just* do my one line change to unwrap interfaces, there is an error, because it builds up methods using the reflect method Index, and the concrete type's method indexes don't match the interfaces interfaces (for obvious reasons). but I think with the other changes, it will build up that method mapping later so it won't be a problem | 06:42 |
| jam1 | investigation still neede | 06:43 |
| axw | critical bug fix up for review, if someone has a moment: https://codereview.appspot.com/92140043 | 06:47 |
| wallyworld | axw: i'd look but i'm off to soccer. i'll look when i get back if not reviewd by then. bigger than i thought it would be | 07:04 |
| axw | wallyworld: yeah, unfortunately touches lots of little bits | 07:05 |
| axw | thanks | 07:05 |
| axw | wallyworld: I will take a look at the lxc stuff now | 07:05 |
| wallyworld | axw: ok. i talked to tim today and he mentioned that you don't *need* the btrfs stuff. a straight file copy of the template will do. i think the current code may do that if clone is enabled but btrfs is not used but i haven't had a chance to check. so we may be able to (for now) leave out the btrfs stuff | 07:08 |
| axw | wallyworld: ok. I will test out the bare minimum, and make any changes required for that. then we can see what else is needed | 07:09 |
| wallyworld | yep ok. thanks very much. i think the main thing missing is with add-machine. in which case, i think not using btrfs is the right way to go | 07:09 |
| * wallyworld -> soccer now | 07:10 | |
| jam1 | fwereade: confirmed. with the rest of my patch there isn't a failing test that we end up "exposing" more than we intended... | 07:10 |
| jam1 | so I guess that means I'm allowed to do whatever I want, right? | 07:10 |
| fwereade | jam1, oops, missed you: yes, sgtm | 07:44 |
| jam1 | fwereade: your embedding of an interface into a concrete type did work as expected (reflect.Value(value.Interface()) doesn't give you the fully underlying type) | 07:45 |
| fwereade | jam1, cool, the universe works how my brain thought it did, this is reassuring ;) | 07:45 |
| fwereade | axw, commnted on https://codereview.appspot.com/92140043/ | 07:48 |
| axw | ta | 07:49 |
| fgz | oo, ferry is moving | 08:04 |
| jam1 | fgz: ferry gz ? that's new | 08:05 |
| fgz | or france gz... in like 5 hours | 08:06 |
| jam1 | fgz: premature naming, if you ask me... :) | 08:06 |
| === fgz_ is now known as fgz | ||
| jam1 | fwereade: we have CodeNotImplemented for when you try to call an API that doesn't exist (Client.Foo is not available) | 08:19 |
| jam1 | fwereade: should I reuse that code for when Client(2) doesn't exist at all? | 08:19 |
| jam1 | I guess today everything returns "params.ErrBadId" | 08:21 |
| fgz | jam1: what happens currently if you try to... | 08:21 |
| jam1 | fgz: ^^ | 08:21 |
| jam1 | fgz: only because each implementation does it directly | 08:21 |
| fgz | I guess you can just accept both that and a new more apt code if desired | 08:21 |
| jam1 | it isn't part of the RPC spec, whereas CodeNotImplemented is used | 08:21 |
| jam1 | fgz: well on the APIServer itself it has a mapping that ErrBadId ==> params.CodeNotFound | 08:22 |
| fwereade | jam1, I don't think I have a coherent position there. I can't see a real distinction between BadId and NotImplemented in practice, but I would prefer not to wantonly change behaviour as we progress | 08:24 |
| jam1 | fgz: so today you probably actually get CodeNotFound if you pass an unknown version, and you get CodeNotImplemented if you pass a valid version but to a Method that doesn't exist | 08:24 |
| jam1 | fwereade: digging deeper shows it to be CodeNotFound | 08:24 |
| fwereade | jam1, however I think the latter is weaker than the former because AFAIK nobody is depending on BadId | 08:24 |
| jam1 | fwereade: I believe client side we translate both into NotFound, checking | 08:25 |
| fwereade | jam1, NotFound does not strike me as coherent, but I suppose that doesn't help | 08:25 |
| jam1 | fwereade: well, we didn't find the Facade you asked for :) | 08:25 |
| jam1 | fwereade: I'm not sure about top level missing the entire facade either | 08:26 |
| fwereade | jam1, yeah, but the broader the domain of NotFound the less meaningful it is | 08:26 |
| jam1 | fwereade: you get CallNotImplementedError if the Facade isn't there | 08:26 |
| fwereade | jam1, time was you could depend on NotFound meaning that some entity referenced by your request -- implicitly or explicitly -- was missing | 08:26 |
| jam1 | same as if the Method is not there | 08:26 |
| jam1 | fwereade: right | 08:27 |
| jam1 | CodeNotFound ==> data in the DB isn't there | 08:27 |
| fwereade | jam1, if we can make some baby steps back in that direction I would be happy | 08:27 |
| jam1 | CodeNotImplemented => API isn't there | 08:27 |
| fwereade | jam1, +1 | 08:27 |
| jam1 | fwereade: should we just continue to enforce CodeNotImplemented for missing Id, or should we have an CodeAPIVersionNotImplemented | 08:27 |
| jam1 | I think I prefer just using CodeNotImplemented | 08:28 |
| jam1 | with enough context you have a chance to figure it out | 08:28 |
| fwereade | jam1, I think not -- "not implemented in this version" does not imply "implemented elsewhere" | 08:28 |
| fwereade | jam1, well, it kinda *does*, but that doesn't map onto reality | 08:28 |
| fwereade | jam1, stick with CodeNotImplemented | 08:28 |
| * fwereade bbs | 08:29 | |
| jam1 | fwereade: sgtm. Unfortunately the actual error we get across the pipe isn't typed, just a message string and a Code | 08:29 |
| jam1 | but I can live with that. | 08:29 |
| jam1 | and for Compat purposes, ErrBadId => CodeNotImplemented | 08:29 |
| jam1 | we've never needed to deal with it before | 08:29 |
| jam1 | but we can put a compatibility shim in the client side for mapping {Message: ErrBadId, Code: CodeNotFound} => CodeNotImplemented if we need to (I think) | 08:30 |
| fgz | sounds reasonable to me | 08:31 |
| fwereade | jam1, +1 | 08:42 |
| jam1 | fwereade: so... can we break the API and start returning CodeNotImplemented for all ErrBadId 's ? | 08:46 |
| jam1 | Nothing (today) should be sending anything but "" for Id | 08:46 |
| jam1 | as all currently exposed APIs return ErrBadId in that case | 08:46 |
| jam1 | I'm reasonably ok with saying that until now passing Id != "" was undefined behavior, so we get to define it. | 08:47 |
| axw | wallyworld: I have created a new branch that picks out just the fast-lxc-clone bit from yours, but I've done it a little differently. I've created a new provisioner API, ContainerManagerConfig, which returns a map[string]string that configures the container manager | 08:47 |
| === vladk|offline is now known as vladk | ||
| axw | wallyworld: also I called it use-lxc-clone (maybe change to lxc-use-clone), otherwise people will just see "fast" and stop thinking | 08:48 |
| jam1 | But it is true that when we update clients with versioning they're going to sometimes get ErrBadId, CodeNotFound (old server) and sometimes CodeNotImplementedError, CodeNotImplemented, but I think that is ok | 08:48 |
| axw | wallyworld: seems to be working in MAAS, but I need to do a bit more work to handle upgrades | 08:48 |
| fwereade | jam1, sorry, I keep not seeing notifications, that's the trouble with trying to write, 80% of my tie is spent staring into the middle distance | 09:14 |
| jam1 | fwereade: np | 09:14 |
| jam1 | I do have another Q for you as well. | 09:14 |
| fwereade | jam1, I think we just have to put up with the variation for now, and just be consistent as we progress | 09:14 |
| jam1 | If you have a function that returns an interface you end up with a reflect.Type that describes just that interface. | 09:14 |
| jam1 | I'm trying to figure out if I can come up with an object | 09:15 |
| jam1 | such that reflect.TypeOf will return that same Type | 09:15 |
| jam1 | fwereade: what I mean is, we *could* continue to return ErrBadId | 09:15 |
| jam1 | fwereade: since that is maintaining the existing API | 09:16 |
| jam1 | but I think that is actually a bad API and nobody depends on it, so we can sanely change it out for returning CallNotImplementedError | 09:16 |
| jam1 | and teach the client code to accept either one | 09:16 |
| jam1 | but have the server code start returning the better values | 09:16 |
| fwereade | jam1, +1 to that, but I'm still furrowing my brow re the reflect stuff | 09:16 |
| jam1 | fwereade: did what I say make sense and you don't know how to do it? | 09:17 |
| jam1 | The way the existing code got the reflect.Type was doing: | 09:17 |
| jam1 | reflect.TypeOf((*InterfaceMethods)(nil)).Elem() | 09:17 |
| fwereade | jam1, I *think* so, yes | 09:17 |
| jam1 | I was hoping I could get rid of all the reflect.TypeOf calls and put them in one place | 09:17 |
| jam1 | but var interfaceValue InterfaceMethods = &SimpleMethods{}; reflect.TypeOf(interfaceValue) == SimpleMethonds | 09:18 |
| fwereade | jam1, yeah, I'm not sure how to do that | 09:18 |
| jam1 | fwereade: fwiw I never figured it out either | 09:19 |
| jam1 | I was originally trying to do something like it for "interface{}" | 09:19 |
| jam1 | but my attempts there just led me to get "nil" | 09:19 |
| jam1 | fwereade: https://codereview.appspot.com/98090043 when you get the chance | 09:40 |
| natefinch | jam1, fwereade: what's the current story about gcc-go? are we planning to use that for all our builds, or just for power, since it's required there? I wasn't sure where that discussion landed.. | 09:43 |
| jam1 | natefinch: for trusty we went with golang-go where we can and gcc-go where we can't | 09:43 |
| fwereade | natefinch, while the performance differential is as significant as it is, best toolchain for the platform | 09:43 |
| jam1 | I'm not sure where the status quo ends up | 09:43 |
| jam1 | certainly distro is pushing for gcc-go everywhere | 09:43 |
| fwereade | natefinch, ideally I'd have a single toolchain across the board, but I'm not interested in making things suckier than they have to be as a point of principle | 09:44 |
| natefinch | fwereade: I hear you. In an ideal world, gcc-go would be good enough for everyone, but yeah... it's not. | 09:44 |
| wallyworld_ | axw: that's great, thanks. for the demos, I don't think we need to worry about upgrades as such | 09:57 |
| axw | wallyworld_: yeah I've just added some code to ignore API-not-implemented errors | 09:58 |
| axw | just about to push | 09:58 |
| wallyworld_ | ok, i'll take a look and let the maas folks know | 09:58 |
| perrito666 | good morning everyone | 09:59 |
| axw | hey perrito666 | 10:01 |
| axw | wallyworld_: https://codereview.appspot.com/96140044 | 10:03 |
| wallyworld_ | great thanks, looking | 10:03 |
| natefinch | voidspace, menn0: meeting? | 10:07 |
| perrito666 | wwitzel3: ping | 10:08 |
| wallyworld_ | axw: so you tested with add-machine of a kvm container and then deploy to lxc inside that? | 10:08 |
| wwitzel3 | perrito666: pong | 10:09 |
| perrito666 | I privmsgd you | 10:10 |
| axw | wallyworld_: I created a vmaas, and add-machine'd in one of the machines | 10:10 |
| wallyworld_ | cool | 10:10 |
| axw | wallyworld_: the top-level machines are on kvm, but not using the kvm provisioner | 10:11 |
| wallyworld_ | yep | 10:11 |
| wallyworld_ | i'll have a comment or two about adding a doc comment to exported methods, but if it works it's good enough for the maas folks to try from source | 10:11 |
| voidspace | gah | 10:22 |
| voidspace | coming | 10:22 |
| wwitzel3 | jam1: "Be careful that you use different queue file names for the second action, else you will mess up your system." | 10:29 |
| wwitzel3 | jam1: I was not doing that ^ | 10:29 |
| jam1 | natefinch: so are you intending to continue attending the UTC 10 meeting next week ? Or are you going to split off ? | 10:34 |
| wwitzel3 | perrito666: join the moonstone hangout re: replicaset stuff | 10:35 |
| natefinch | jam1: is that the daily? I was going to split off the daily one. | 10:35 |
| jam | yes | 10:35 |
| natefinch | I wonder if for cross pollination, it would work to send one person each day to another team's standup. | 10:37 |
| natefinch | so like monday, someone from my team would go to the onyx standup, tuesday, someone else would go to the sapphire standup, etc | 10:39 |
| wwitzel3 | what is a good way to generate some logging on a pre-existing mysql node? .. | 10:42 |
| perrito666 | wwitzel3: oops sorry missed the message, going | 10:42 |
| jam1 | wwitzel3: you want Juju logging, or mysql loggign? | 10:48 |
| jam1 | because you can "restart jujud-unit-2" or whatever the agent name is | 10:48 |
| wwitzel3 | jam1: I want to test this rsyslog change before putting it in to the code, so I want to trigger some unit mysql logging. | 10:49 |
| jam1 | wwitzel3: right, I think if you just bounce the running agent, you'll get "I restarted" logging | 10:49 |
| jam1 | wwitzel3: or you can do "juju set" to change some conf item | 10:50 |
| wwitzel3 | jam1: thanks | 10:50 |
| jam1 | hi alexlist`, really sorry to hear about what happened. I hope you're doing well. | 10:54 |
| wwitzel3 | jam1: that worked, thanks, and it seems to be reliably logging to all the state machines now. | 10:55 |
| jam1 | wwitzel3: yay | 10:55 |
| jam1 | rsyslog is *magic* :) | 10:55 |
| wwitzel3 | "..else you will mess up your system" | 10:55 |
| voidspace | wwitzel3: did you do a "standard" maas install - or us virtual maas? (or both?) | 11:01 |
| === perrito6` is now known as perrito666 | ||
| wallyworld_ | jam1: natefinch: both you guys have in progress bugs against 1.18.3. are you able to get them completed so that we can merge the fix for the critical P1 issue when done and get a 1.18.3 release out? | 11:06 |
| jam1 | wallyworld_: I think mine is the bug you actually fixed | 11:07 |
| jam1 | https://bugs.launchpad.net/juju-core/+bug/1306537 | 11:07 |
| _mup_ | Bug #1306537: LXC local provider fails to provision precise instances from a trusty host <deploy> <local-provider> <lxc> <juju-core:Fix Released by wallyworld> <juju-core 1.18:In Progress by jameinel> <juju-quickstart:Fix Released by frankban> <juju-quickstart (Ubuntu):New> <juju-quickstart (Ubuntu Trusty):New> <https://launchpad.net/bugs/1306537> | 11:07 |
| wwitzel3 | voidspace: I just used a standard trusty image and choose the maas option, for my provider | 11:07 |
| jam1 | has your branch associated with it | 11:07 |
| jam1 | "bootstrap supported series" | 11:08 |
| jam1 | wallyworld_: is it just that you intended to backport to 1.18 but didn't get it? | 11:08 |
| wallyworld_ | ah could be | 11:08 |
| jam1 | wallyworld_: I'll reassign it to you | 11:08 |
| wallyworld_ | sure thanks. i should have looked close than just the miletone page | 11:08 |
| natefinch | wallyworld_: mine was released in 1.19.1, possibly just needs backporting | 11:09 |
| wallyworld_ | ok | 11:09 |
| wallyworld_ | i'll backport tomorrow | 11:09 |
| wwitzel3 | voidspace: also my latest push to 008-ha-rsyslog has node logging to all state machines working | 11:15 |
| voidspace | wwitzel3: cool, thanks | 11:18 |
| wwitzel3 | https://codereview.appspot.com/100270043/ .. his is for the nodes logging to any state servers that exist when the node is created. | 11:19 |
| wwitzel3 | tested in non-HA as well | 11:19 |
| wwitzel3 | now I'm going to look at refactoring the watcher for rsyslog for re-writing the config file when state servers are added/removed. | 11:20 |
| voidspace | great | 11:21 |
| wwitzel3 | jam1: I have your notes from yesterday about using an API call to get the environ config bits needed, instead of using it directly | 11:21 |
| jam1 | wwitzel3: do you need more detail about it? | 11:24 |
| wwitzel3 | jam1: don't think so, though I'm just starting to dig in | 11:26 |
| jam1 | wwitzel3: sounds good | 11:26 |
| voidspace | wwitzel3: so you specify a queue filename per state server | 11:28 |
| wallyworld_ | wwitzel3: do you have an eta on your vmaas setup notes? | 11:28 |
| voidspace | wwitzel3: interesting | 11:28 |
| wwitzel3 | voidspace: yeah, you have to, else you will mess up your system. | 11:28 |
| voidspace | wwitzel3: ah, that was the discussion earlier | 11:28 |
| voidspace | lovely... | 11:29 |
| wwitzel3 | wallyworld_: I will flesh them out today | 11:29 |
| wallyworld_ | \o/ thanks. but of course don't put them ahead of real work :-) | 11:30 |
| wwitzel3 | wallyworld_: I've been meaning to do it, I've just got a pile of notes tossed in to a doc now, so I'll turn them in to something real | 11:32 |
| wallyworld_ | great, looking forward to it | 11:32 |
| hazmat` | axw, where was that destroy env logic in sync tools.. it was source diving for it through the sync code yesterday... and it was really non obvious where it was. | 11:38 |
| hazmat` | s/it/i was source | 11:39 |
| jam1 | axw, hazmat`: environFromName | 11:54 |
| jam1 | has a cleanup func it returns | 11:54 |
| jam1 | which is supposed to only delete it if the env can't be looked up, but there was a bug WRT EnvName being an empty string | 11:54 |
| jam1 | so one function couldn't find it, but the next function could | 11:55 |
| fwereade | wwitzel3, voidspace: reviewed https://codereview.appspot.com/100270043/ | 11:57 |
| fwereade | jam1, you have a bunch of LGTMs | 11:58 |
| jam1 | fwereade: did you see rog's comment on that CL ? | 12:03 |
| voidspace | wwitzel3: do you have a link to the docs warning about the ActionQueueFileName stuff? | 12:05 |
| fwereade | jam1, sorry, which? | 12:07 |
| jam1 | fwereade: on https://code.launchpad.net/~jameinel/juju-core/reflect-only-facades/+merge/218764 | 12:13 |
| jam1 | comment: https://code.launchpad.net/~jameinel/juju-core/reflect-only-facades/+merge/218764/comments/521422 | 12:14 |
| jam1 | I did reply that I intend to do runtime introspection, instead of static introspection | 12:14 |
| jam1 | fwereade: also, that specific branch can't land just yet because we *do* static introspection of srvRoot in the state/apiserver code to make sure types are registered with no Discarded Methods. | 12:15 |
| jam1 | so I was going to push forward on getting a registry so that we can do the lookups | 12:16 |
| jam1 | fwereade: also, should I push forward on making "Facade" a name that gets used in code and errors strings, etc. Right now the RPC package thinks in terms of: "unknown object type %q" when you ask for something that isn't accessible. | 12:17 |
| voidspace | what's the cause of "WARNING failed to find 1.19.2 tools, will attempt to use 1.19.1"? | 12:21 |
| voidspace | I had this during the sprint, but I can't remember how I solved it | 12:21 |
| jam1 | voidspace: "bzr bootstrap --upload-tools" as 1.19.2 isn't actually released yet IIRC | 12:21 |
| voidspace | jam1: it's simpler than that | 12:22 |
| voidspace | jam1: I didn't bootstrap with --upload-tools | 12:22 |
| voidspace | jam1: thanks :-) | 12:22 |
| voidspace | and I need to - the whole point of this exercise is to test something in the dev version... | 12:23 |
| === vladk is now known as vladk|offline | ||
| * voidspace lunches | 12:41 | |
| === vladk|offline is now known as vladk | ||
| === vladk is now known as vladk|offline | ||
| === vladk|offline is now known as vladk | ||
| === vladk is now known as vladk|offline | ||
| === rvba` is now known as rvba | ||
| axw | fwereade: not sure I grok your comment; I have added lxc-use-clone to the immutable config attributes list | 14:00 |
| axw | fwereade: if/when we want to make it dynamic, I will take it out and add code to react to changes | 14:00 |
| axw | but for now it's set-at-bootstrap and that's it | 14:00 |
| fwereade | axw, then I must just be an idiot and have misread where it was | 14:00 |
| fwereade | axw, sorry | 14:00 |
| axw | fwereade: nps | 14:01 |
| axw | fwereade: also, I totally agree regarding inversion of EnvCommandBase | 14:02 |
| jam1 | fwereade: so any thoughts on runtime self-description vs static self-description? I still feel that having the name separate from the version is better for us, though arguably the final type we are going to be returning is going to have the type in its name. | 14:02 |
| jam1 | sorry, have the version in its name | 14:02 |
| jam1 | (ClientAPIv2 or somesuch) | 14:02 |
| === Ursinha is now known as Ursinha-afk | ||
| natefinch | jam1: separate seems like it's almost universally better than combined. Combining things is trivial, splitting them is usually more difficult. | 14:05 |
| === alexlist` is now known as alexlist | ||
| fwereade | jam1, yeah, I just saw that comment in mail -- I do not consider munging the version number into the method name to be "reasonable", and I'm pretty sure we can do all the API description generation dynamically just fine | 14:07 |
| jam | natefinch: isn't that what regex is for :) | 14:14 |
| natefinch | jam: now you're just yanking my chain :) | 14:15 |
| jam | natefinch: well, I prefer the split form, and since 3 out of 4 devs polled agree, I'll push forward with it | 14:19 |
| fwereade | jam, dammit, I borked my voip and forgot about it -- can you make the cross-team while I rush to figure out how to fix it up again? | 14:34 |
| stokachu | axw: wallyworld_ any of you guys around now? | 14:35 |
| fwereade | or natefinch, since jam's not meant to be working now | 14:35 |
| natefinch | fwereade: I can do that | 14:35 |
| natefinch | fwereade: can you give me a link? | 14:35 |
| jam | natefi | 14:41 |
| jam | natefinch: it is the canonical Conference call | 14:41 |
| jam | since there are like 30 people | 14:41 |
| natefinch | jam: fwereade gave me the info | 14:41 |
| natefinch | jam: it was still in "waiting for the leader" mode, so we figured it wasn't happening | 14:42 |
| natefinch | sometimes I really wish we were better about being more specific with our wording. | 14:51 |
| natefinch | fwereade: I have a task: Agent conf needs to store all addresses (hostports), not just private addresses. I presume this means API hostports? | 14:52 |
| wwitzel3 | heh, the only thing the rsyslog worker grabs from the EnvironConfig is the SyslogPort | 14:52 |
| fwereade | natefinch, yeah -- it's to prevent the suicide-in-manual-environments problem | 14:52 |
| wwitzel3 | oh and the CAcert | 14:52 |
| fwereade | natefinch, although, if state hostports are kept there too, fix them as well | 14:53 |
| natefinch | fwereade: fair enough, will do | 14:53 |
| fwereade | natefinch, otherwise we *will* get complaints about suiciding manual HA environments | 14:53 |
| === Ursinha-afk is now known as Ursinha | ||
| wwitzel3 | jam: so were you saying that in the actual SetUp of the rsyslog worker, it shouldn't use WatchForEnvironConfigChanges? Or just in Handle, it should no longer use EnvironConfig()? Or both? | 14:54 |
| jam | wwitzel3: both | 14:54 |
| bac | jcastro: your issue with deployed bundles not being placed correctly has now been fixed an deployed. enjoy. | 14:54 |
| jam | It should have an API for Watching the actual RSyslog changes (which might be backed by the EnvironConfig watcher) | 14:54 |
| jcastro | you mean placed as in the boxes? | 14:54 |
| jam | but the Agent side should have a proper "this is what I care about" API | 14:55 |
| wwitzel3 | jam: I see, got it. Thank you. | 14:55 |
| jam | wwitzel3: as an example you can look at WatchAPIVersion on the Upgrader interface | 14:57 |
| jam | the API is WatchAPIVersion(), but the internal watcher is actually WatchForEnvironConfigChanges. | 14:57 |
| jam | that gives us the ability to say "we're generating too many notifications when API hasn't actually changed" and fix it in the future | 14:58 |
| jam | rather than breaking the contract | 14:58 |
| wwitzel3 | jam: yep, looking at it now. Then we can later tune it | 14:58 |
| wwitzel3 | right | 14:58 |
| fwereade | wwitzel3, and in general *only* state servers should get to see environ config | 14:58 |
| fwereade | wwitzel3, it's (usually) got cloud account keys in it | 14:58 |
| wwitzel3 | fwereade: seems sane :) | 14:58 |
| jam | wwitzel3: fwereade: right. Also in the case of rsyslog you actually care about 2 things, because you want the config for the ports, etc, but you also want the list of addresses. | 14:59 |
| fwereade | wwitzel3, we can't rationally stop the state servers from seeing them, but we shouldn't let anyone else ;) | 14:59 |
| jam | And I *think* we could sanely hide that with 2 watchers inside the APIServer and merge any notification events to 1 watcher in the client | 14:59 |
| fwereade | jam, sounds sane to me | 14:59 |
| wwitzel3 | jam: sounds good | 15:00 |
| wwitzel3 | fwereade, jam: thanks | 15:00 |
| jam | fwereade: fwiw we explicitly blank them for any agent that doesn't have JobManageEnviron, but it is still too much a "giant back of unrelated data" when we want the API to be around just what we actually want for rsyslog | 15:00 |
| fwereade | jam, yeah, but the blanking sucks imo | 15:01 |
| jam | fwereade: I agree, just that it isn't an *actual* security hole ATM | 15:01 |
| fwereade | jam, and it forces secrets to be strings, and it doesn't stop people from hacking up not-quite-working Environ objects, and, eww | 15:01 |
| fwereade | jam, true | 15:02 |
| * fwereade needs to visit shops, bbiab | 15:02 | |
| perrito666 | is there anything in place to update mongo machines entry for machine 0 if machine-0 ip changes? | 15:03 |
| natefinch | perrito666: I believe so, yes. I would have to go back through it, but I think that's the peer grouper's responsibility | 15:05 |
| jcw4_ | are there feature toggles/flags in juju-core? | 15:07 |
| natefinch | jcw4_: not really | 15:07 |
| perrito666 | natefinch: mm peergrouper is the one making my life hard, apparently it sets my replicaset to old ip values instead of the new ones, I believe it is getting wrong info from machines bc the machine-0 entry has old address data, so I wanted to update that so peergrouper stops messing with me | 15:07 |
| natefinch | jcw4_: what specifically are you thinking of? | 15:08 |
| jcw4_ | natefinch: tx. Just trying to think of the best way to combine regular small commits with introducing a whole new feature (i.e. actions) | 15:08 |
| natefinch | jcw4_: the easiest way to do it is to simply not expose the CLI command until it's ready. That's our usual practice. "in but not on" | 15:09 |
| jcw4_ | natefinch: bodie_ and I have made a number of changes but we're not anywhere close to a full feature. | 15:09 |
| jcw4_ | natefinch: yeah, maybe we'll just have to do an MR with what we have soon... no cli, but state server changes | 15:10 |
| jam | jcw4_: generally that is ok, as long as a compatible client won't corrupt things | 15:13 |
| jam | jcw4_: there is stuff like environ config which can be used for feature flags | 15:13 |
| jcw4_ | jam: interesting. | 15:13 |
| jam | but there isn't something like "go build -WITH_SUPPORT_FOR_FOO" | 15:13 |
| jcw4_ | jam: rick_h_ gave bodie_ and I a bit of a demo of their process, which includes feature flags. | 15:14 |
| jam | jcw4_: It sort of depends how invasive the changes are, if you are in your own collections it should be fine, if you have to change existing docs then we have to be careful with how we'll end up doing an upgrade from previous stable to new code. | 15:14 |
| jcw4_ | yeah, we have one collection (actions) that's new, but we're also adding actionids to units... possibly an issue | 15:15 |
| jam | jcw4_: sure, but they aren't quite as concerned about multiple client versions making requests. or at least they are but at a different level (FF vs IE vs Safari, etc) | 15:15 |
| jcw4_ | jam: good point | 15:15 |
| jam | jcw4_: the main problem there is that we need an upgrade path | 15:15 |
| jam | so if you start with a 1.18 environment, we need a way to get to the new code with action ids | 15:16 |
| jam | natefinch: is currently tasked with sorting out db schema migrations | 15:16 |
| jam | during upgrade | 15:16 |
| jam | because we have most clients behind the API | 15:16 |
| jam | except the API servers themselves | 15:16 |
| jam | and HA complicates a migration procedure a bit | 15:16 |
| jcw4_ | jam: backward compatibilty and upgrade path seem a little tricky. Are there any tests or scenarios that are commonly used to test upgrades? | 15:16 |
| jam | jcw4_: CI does upgrade testing, bootstraps with 1.18 and then does an upgrade to dev tip | 15:17 |
| jcw4_ | jam: I see, and that is just when a change gets landed right? | 15:17 |
| jam | jcw4_: it isn't something we do well internally yet. | 15:17 |
| jcw4_ | no CI before landing in trunk? | 15:17 |
| jcw4_ | (a bit obvious I guess) | 15:17 |
| jam | jcw4_: we run the unit test suite before landing trunk (go test), but the CI suite is run async on lots of platforms and clouds | 15:17 |
| jcw4_ | jam: I see. | 15:18 |
| jam | jcw4_: so we won't do an official release unless CI says everything is green | 15:18 |
| jam | but we might break upgrade/etc for a short while. | 15:18 |
| jam | jcw4_: for a schema change, ideally we'd have the code written such that it can handle either schema | 15:19 |
| jam | and then once we know all the agents are upgraded to know how to handle either schema | 15:19 |
| jam | we can update the DB to the new schema | 15:19 |
| jam | I *think* the current migration is to actually take the system offline, upgrade the agents, see that they are upgraded, then stop the db, copy the data to a safe backup, and then rewrite in place. | 15:20 |
| jam | but natefinch and wallyworld's teams are the ones task with actually doing that work | 15:20 |
| jcw4_ | jam: so forgiving if collections or keys are missing and not changing by removing stuff? Interesting about migration path | 15:20 |
| jam | jcw4_: it is a common way to leap-frog update your API servers and DB backend, though we might not need to go through quite as much effort | 15:21 |
| jam | often you would do "upgrade => Servers have compat, upgrade => actually roll out schema changes" but that doesn't quite work with how juju upgrades itself. | 15:21 |
| jcw4_ | hmmm | 15:22 |
| jcw4_ | does it make sense to add actionIds to Unit to represent pending actions that the Unit must execute? Or should Unit 'look up' actions that are assigned to it. | 15:24 |
| jcw4_ | I am a little cautious about adding a collection of ids to the Unit. At some point the delegation of Actions won't be explicit to a certain Unit | 15:25 |
| jcw4_ | probably need more context... sorry. | 15:25 |
| jam | jcw4_: I think I have enough context | 15:26 |
| jam | jcw4_: in general we've gone with smaller docs | 15:26 |
| jam | because our Watch level of granularity is a whole doc | 15:26 |
| jam | which means that things that watch the lifecycle of a Unit | 15:26 |
| jam | would also get woken up | 15:26 |
| jam | when you add an action to be performed | 15:26 |
| jcw4_ | I see | 15:26 |
| jcw4_ | does that mean maybe not adding the actionid to the unit? | 15:27 |
| jam | jcw4_: so you would have a unit-actions collection indexed by unit-id | 15:27 |
| jam | jcw4_: and *that* doc would have the list of action-ids | 15:27 |
| jcw4_ | jam: good. makes sense ok | 15:27 |
| jcw4_ | then watchers would only respond if they care about unit-actions | 15:28 |
| jam | jcw4_: exactly | 15:28 |
| jcw4_ | cool | 15:28 |
| jam | it isn't that different from a many-to-many table in SQL design | 15:28 |
| jam | just that one side is still 1-to-many | 15:28 |
| jcw4_ | yeah, makes sense | 15:28 |
| jcw4_ | (no problem in CS that can't be solved by one more level of indirection) | 15:28 |
| jcw4_ | :) | 15:29 |
| * perrito666 managed to make a machine terminate itself.... | 15:31 | |
| wwitzel3 | I'm managing to make juju terminate itself .. less desirable. | 15:32 |
| perrito666 | wwitzel3: ouch | 15:33 |
| perrito666 | I just updated by hand the machine-0 addresses and restarted jujud-machine-0 and it decided to terminate itself :) | 15:33 |
| wwitzel3 | perrito666: it is ok, I know why, and it is my fault | 15:34 |
| jam | wwitzel3: this is on MaaS? | 15:34 |
| jam | wwitzel3: I believe MaaS uses the IP address as the handle for an instance | 15:34 |
| jam | rather than say the Amazon's InstanceId | 15:35 |
| jam | since they don't have a separate handle | 15:35 |
| jam | the MaaS provider sees "some random machine that I don't know about running in this environment" and stops it | 15:35 |
| jam | wwitzel3: there is a bug about "safe mode by default" | 15:35 |
| wwitzel3 | jam: ahh ok | 15:35 |
| jam | which is about not killing machines we don't recognized | 15:35 |
| jam | recognize | 15:35 |
| jam | I believe you can "juju set-env safe-mode=true" | 15:35 |
| jam | and we've talked about making that the default (it is needed during restore) | 15:36 |
| jam | wwitzel3: I also seem to remember that MaaS was talking about abstracting nodes to Ids that aren't their IP address | 15:36 |
| jam | wwitzel3: and I would be ~ happy if the Provisioner that decides to kill machines could notice that it is running on the machine it is wanting to kill | 15:37 |
| natefinch | Isn't there a bug about running precise lxc containers on trusty? juju deploy wordpress on my local machine is bringing up a precise container that fails while running the install hook for wordpress | 15:37 |
| jam | natefinch: bug #1306537 ? | 15:37 |
| perrito666 | wwitzel3: your fault? you mean my issue or yours? | 15:38 |
| wwitzel3 | perrito666: I meant mine, but you can blame me for yours as well :) | 15:38 |
| jam | wwitzel3: you can even name the patch "refuse-seppuku" :) | 15:39 |
| wwitzel3 | jam: hah :) | 15:39 |
| jam | wwitzel3: we've had some spectacular bugs around that area, so a bit of extra caution would be just fine | 15:39 |
| natefinch | jam: that bug says fix released, though | 15:40 |
| jam | natefinch: not released in 1.18 | 15:41 |
| jam | "fails while running the install hook" isn't that failure | 15:41 |
| jam | natefinch: that failure was "failing to start at all" | 15:41 |
| jam | natefinch: if it was failing for mysql, I would say it is the "mysql charm wants 80% of all your RAM for shared memory" which breaks fairly often. | 15:42 |
| jam | I haven't seen specific problems with the wordpress charm | 15:42 |
| fwereade | jcw4_, fwiw, I might be inclined to go one further -- one document per action per unit. that's not absolutely mandated, but it's certainly easier to enqueue/dequeue by adding/removing whole documents | 15:45 |
| jam | jcw4: fwereade I was thinking about that, but it seemed to be a bit hard to lookup if there are any docs you need, since mongo 2.4 doesn't do multi column indexes ... | 15:46 |
| jam | ? | 15:46 |
| jam | jcw4: fwereade I was thinking about that, but it seemed to be a bit hard to lookup if there are any docs you need, since mongo 2.4 doesn't do multi column indexes ... | 15:46 |
| jam | 19:46 | 15:46 |
| jam | ? | 15:46 |
| fwereade | jcw4, and also: our watcher granularity is only per-document (so I'm definitely -1 on adding action ids to the unit doc); and that causes me to tend towards having one per, because it leads to smaller docs and therefore better watch granularity | 15:47 |
| jcw4 | fwereade: yeah, you had mentioned that before, but the application here was forgotten. | 15:47 |
| jcw4 | I like the separate action-unit doc better anyway | 15:47 |
| fwereade | jcw4, depends exactly how we store them, I think -- what's the concern? in particular, if completed actions move out of the actions collection and into an actionresults collection, it's just get-all-docs-with-particular-unit-key | 15:48 |
| fwereade | jcw4, *however*, given the way watching currently works, it is potentially useful to encode the unit key in the action's _id field | 15:49 |
| fwereade | jcw4, it's not necessarily ideal, from many standpoints | 15:49 |
| jcw4 | fwereade: hmm my concern was lookups but encoding it in the id might address that? | 15:50 |
| fwereade | jcw4, but it does mean we can watch changes to that collection and deliver notifications to the right units *without* db hits | 15:50 |
| jam | fwereade: don't you need 1 doc to actually reference them, so the Unit agent can watch for that changing so it knows to go fire off the actions?= | 15:50 |
| jam | (that might be exactly what you are describing, though :) | 15:51 |
| jcw4 | fwereade: so no unit-actions doc... watcher watches the actions doc... when a new action appears the watcher greps the unit id from the action id and notifies the unit? | 15:51 |
| fwereade | jam, I think it can just as easily be a collection watch -- that might not be absolutely best for performance, but it's probably not bad -- the relation scope watches use that mechanism, and you've hit those pretty hard with the explode charm in scale testing | 15:52 |
| jcw4 | jam: part of the problem is my fuzzy understanding of watchers and how the units would respond | 15:52 |
| fwereade | jcw4, jam: watcher watches the actions collection, and skips events on docs with the wrong prefix | 15:52 |
| fwereade | jcw4, jam: yeah, once I've done the arch overview doc an explanation of how the watchers currently work is called for I think | 15:53 |
| jcw4 | fwereade: I see. does that mean units each have their own watcher running? makes sense now that I think about it | 15:53 |
| natefinch | is it not possible to remove a broken service? juju destroy-service wordpress puts the unit in the dying state, but it stays in dying forever. | 15:54 |
| jam | jcw4: right each Unit asks for a Watcher to be run in the API server | 15:54 |
| jcw4 | bingo | 15:54 |
| fwereade | jcw4, well, it *does* suck a bit in some cases -- N service watchers for N units of that service -- but having a single watcher for a single unit's events is ok I think | 15:54 |
| jam | natefinch: IIRC you have to "juju destroy-machine —force" to teardown the machine that has the bad unit on it | 15:54 |
| jcw4 | (excuse my johnny come lately eureka moments) | 15:55 |
| fwereade | natefinch, is the unit broken? | 15:55 |
| fwereade | natefinch, ie running but not actually functioning properly? | 15:55 |
| natefinch | fwereade: install hook failed | 15:55 |
| fwereade | natefinch, you can juju debug-hooks, and juju resolved, to your heart's content | 15:55 |
| fwereade | natefinch, but, yeah, destroy-machine --force is the quickest way to clear it up | 15:56 |
| jam | fwereade: ah yes, the infamous "resolved until it breaks on every possible hook and then finally decides to dy" | 15:56 |
| fwereade | natefinch, the issue with resolved is that you'll have to resolve a few times, probably, because the subsequent hooks will likely themselves fail | 15:56 |
| jam | die | 15:56 |
| fwereade | natefinch, yeah, what jam said | 15:56 |
| natefinch | fwereade: I suppose I should probably try to figure out why it died before killing it anyway | 15:57 |
| jam | fwereade: not that unlike our current "ensure-availability" until it actually decides the machine is dead | 15:57 |
| fwereade | natefinch, jam, there is *no* good reason not to insta-die when waiting on a failed install hook | 15:57 |
| jam | fwereade: same thing for "insta die" when we never got to started for an agent, right? | 15:57 |
| jam | fwereade: though the machine should probably still be considered dirty | 15:57 |
| jam | since it might have installed something | 15:58 |
| fwereade | jam, yeah, I has a pretty serious grumpy about that -- I thought that "don't make HA depend on the presence package" had been clear, but I guess it got lost in the cracks somewhere | 15:58 |
| fwereade | jam, the machine's marked dirty immediately the unit is assigned, but if you catch the unit before the machine's deployer does it should get cleaned up without trying to install at all | 15:58 |
| jam | fwereade: well, we don't really have another way to actually recover from something being dead | 15:58 |
| jam | fwereade: sure | 15:59 |
| jam | though once you've started the install hook it should stay dirty | 15:59 |
| fwereade | jam, yeah, we do mark dirty too early | 15:59 |
| fwereade | jam, you mean we don't have a better way to detect deadness? | 16:00 |
| fwereade | jam, my contention was always that we need a much better way to detect deadness ;) | 16:00 |
| voidspace | wwitzel3: did you find some action you could perform on a unit that would reliably cause logging on the state server? | 16:02 |
| voidspace | wwitzel3: deploying wordpress, mysql and exposing wordpress doesn't seem to have done it for me | 16:02 |
| voidspace | that's in HA, going to try with a single state server | 16:04 |
| perrito666 | wow :| I made it | 16:08 |
| jcw4 | OT: golint seems to think that Id should always be ID.... thoughts? | 16:08 |
| fwereade | voidspace, juju set-env logging-config="<root>=DEBUG" will give you all the logging you could possibly desire | 16:11 |
| fwereade | voidspace, and much, much more | 16:11 |
| voidspace | fwereade: hah, thanks | 16:14 |
| voidspace | fwereade: now sshuttle is flaking out on me - so wrestling with that | 16:14 |
| jcw4 | golint also seems to think that Url should be URL | 16:19 |
| jcw4 | 1) do we care about golint, and 2) do we want to ignore this naming convention (capitalize ID and URL) | 16:20 |
| fwereade | jcw4, I don't care much about those *particular* golint complaints, at least | 16:23 |
| fwereade | jcw4, I'm not willing to go so far as to say I don;t care about golint, though ;) | 16:23 |
| jcw4 | fwereade: yeah, it finds other things that seem valuable (missing docs, malformed docs, incorrect error messages, etc.) | 16:24 |
| fwereade | jcw4, indeed | 16:26 |
| natefinch | jcw4: yeah, I agree with fwereade, those particular ones I wouldn't worry about. Personally, I prefer Url to URL, because it's easier to read, and it's such a common acronym that it's not likely to be confused for anything else. | 16:36 |
| jcw4 | natefinch: agreed. It appears that golint has no intention of providing flags to suppress warnings so I'll just learn to ignore those ones :) | 16:36 |
| wwitzel3 | voidspace: restarting worked, login to the unit machine and do a restart juju-unit-name | 16:37 |
| voidspace | wwitzel3: cool, thanks | 16:37 |
| natefinch | jcw4: yeah.... might be worth writing a wrapper for it to suppress what you want to ignore | 16:38 |
| jcw4 | natefinch: interesting... maybe | 16:39 |
| voidspace | rebooting | 16:39 |
| natefinch | jcw4: I'll probably whip something up at some point... golint is only valuable if you can separate the signal from the noise | 16:39 |
| * fwereade will probably be back later, got some things to finish off, but done for now | 16:40 | |
| natefinch | fwereade: quick question? | 16:40 |
| natefinch | fwereade: are debug-hooks supposed to run normally on local? because it doesn't appear to be doing the right thing | 16:40 |
| fwereade | natefinch, grar -- they probably should, yeah | 17:11 |
| natefinch | fwereade: I get a prompt like this: root@nate-local-machine-2:~# | 17:12 |
| natefinch | fwereade: after doing juju debug-hooks wordpress/0 install | 17:12 |
| dimitern | natefinch, fwereade, i'd appreciate a review on the following goamz branch: https://codereview.appspot.com/99030044 | 17:32 |
| * dimitern goes to lunch | 17:32 | |
| fwereade | natefinch, ah -- that's not *necessarily* not working | 17:57 |
| fwereade | natefinch, you'd need to resolved --retry before it'd trigger again | 17:57 |
| natefinch | fwereade: I figured it out.... talked with Marco about it. Just me not understanding the docs | 17:57 |
| fwereade | natefinch, that's likely an indication of a doc problem more than a you problem though | 17:58 |
| fwereade | natefinch, if you have suggestions for clarification they would be much appreciated | 17:58 |
| natefinch | fwereade: I will suggest some changes. I also will suggest some changes to juju help resolve and juju help debug-hooks, since both have only a single line of help in them :/ | 17:59 |
| === bodie_ is now known as Guest66499 | ||
| dimitern | hey natefinch | 18:37 |
| dimitern | natefinch, regarding the short urls - i followed the same pattern as for the rest of goamz, i think the reason is AWS API urls are really really long (>200 chars) | 18:38 |
| natefinch | dimitern: Personally, I'd rather see a 200 character line that gets wrapped than a shortened URL, but since the rest of goamz does it that way, I guess I'll have to live with it. | 18:41 |
| dimitern | natefinch, thanks | 18:41 |
| natefinch | dimitern: btw, are you still in the US, or was that just a really really late lunch? | 18:41 |
| dimitern | natefinch, still in austin, departing tomorrow afternoon | 18:42 |
| natefinch | dimitern: ahh, cool | 18:42 |
| dimitern | natefinch, have you seen gustavo today? | 18:42 |
| natefinch | dimitern: nope | 18:44 |
| dimitern | 10x | 18:44 |
| voidspace | relocating | 19:01 |
| stokachu | wallyworld_: axw you guys around yet? | 19:11 |
| stokachu | also could someone increase the priority of bug https://bugs.launchpad.net/juju-core/+bug/1307434 | 19:13 |
| stokachu | its happening more and more as we continue testing | 19:13 |
| stokachu | landscape team is hitting it as well | 19:13 |
| natefinch | stokachu: your comment on the bug says it happens when deploying 4 charms.... is this just 1 unit of each? | 19:15 |
| stokachu | natefinch: yea 1 unit of each | 19:15 |
| natefinch | stokachu: ouch | 19:15 |
| stokachu | natefinch: thats been the smallest workload | 19:16 |
| stokachu | but all with 1 unit of each | 19:16 |
| natefinch | stokachu: did you have to restart the server to get it to work, or did it eventually sort itself out? | 19:17 |
| stokachu | natefinch: destroy the units and restart the state server | 19:17 |
| stokachu | so we destroyed 2 units, and then re-deployed after state server is up | 19:18 |
| natefinch | stokachu: ok | 19:18 |
| natefinch | sinzui: ^^ https://bugs.launchpad.net/juju-core/+bug/1307434 seems like this bug can occur with even small numbers of units. We may need to address this for 1.20. What do you think? | 19:21 |
| sinzui | thank you natefinch I targeted it to next stable. I am going to empty 1.20 this week with Ian's help | 19:27 |
| natefinch | sinzui: cool | 19:27 |
| natefinch | stokachu: ^^ I changed the priority to High, too. | 19:28 |
| stokachu | natefinch: thanks man | 19:31 |
| stokachu | do you guys know when wallyworld_ or axw come online? | 19:31 |
| natefinch | stokachu: they're in australia, and it's still the middle of the night there, so probably in like 3+ hours | 19:34 |
| stokachu | natefinch: ok cool thanks | 19:35 |
| wallyworld_ | stokachu: hi, how can i help? | 20:51 |
| stokachu | wallyworld_: hey there, im having trouble getting new tools packaged with your changes to test | 20:52 |
| wallyworld_ | ok. so you are using bootstrap --upload-tools? | 20:52 |
| stokachu | sinzui pointed me towards a script to package the tools | 20:52 |
| wallyworld_ | you shouldn't need that | 20:52 |
| wallyworld_ | if you have go installed, you just need bootstrap --upload-tools | 20:53 |
| stokachu | wallyworld_: how does it know to use the tools from your branch? | 20:53 |
| wallyworld_ | it should look at the GOPATH env variable from memory | 20:53 |
| wallyworld_ | but you will need al the deps checked out also | 20:54 |
| wallyworld_ | if you like, i can build you some tools | 20:54 |
| stokachu | wallyworld_: i guess im confused on how i need to setup my gopath | 20:54 |
| stokachu | wallyworld_: sure if youve got the time | 20:54 |
| wallyworld_ | stokachu: ok, i have to pop and take my son to school. i'll be back in 25 mins or so | 20:56 |
| wallyworld_ | i i can either help you get stuff set up or build tools and give you a tarball, whatever is easiest for you | 20:56 |
| stokachu | wallyworld_: cool ill be around | 20:56 |
| stokachu | wallyworld_: thanks man | 20:56 |
| wallyworld_ | np, we'll get this working for sure real soon now :-) | 20:57 |
| stokachu | haha awesome, ive got a lot of "eyes" on this | 20:57 |
| natefinch | stokachu: gopath is just whatever directory you want to use to store your go code | 20:57 |
| stokachu | natefinch: so if ive got the godeps checked out in my $GOPATH do i just cd into wallyworlds branch to do the bootstrap --upload-tools? | 20:58 |
| stokachu | or does it matter what directory im in | 20:58 |
| natefinch | stokachu: 2 things - you'll need to install juju first. To do that, go to $GOPATH/src/launchpad.net/juju-core (make sure it's pointing at the correct branch) and do go install ./... that'll build the juju binaries and copy them to $GOPATH/bin | 20:59 |
| stokachu | ok | 21:00 |
| natefinch | stokachu: make sure that $GOPATH/bin is in your path, and then you can do juju bootstrap --upload-tools, and it'll use the jujud that is next to the juju binary as the thing to upload | 21:00 |
| menn0 | Morning | 21:00 |
| stokachu | ahhh | 21:00 |
| stokachu | natefinch: now it makes sense | 21:00 |
| natefinch | stokachu: make sure which juju returns the one in your gopath, though... if you have juju installed from elsewhere, it'll be running that version instead of the one in your gopath | 21:01 |
| sinzui | stokachu, if you need a tarball then | 21:01 |
| sinzui | make-release-tarball.bash -1 lp:~wallyworld/juju-core/fast-lxc-everywhere | 21:01 |
| stokachu | sinzui: ah nice | 21:02 |
| sinzui | stokachu, I then make a package with | 21:04 |
| sinzui | make-package-with-tarball.bash testing juju-core_*.tar.gz 'Curtis C. Hovey <curtis.hovey@canonical.com>' | 21:04 |
| stokachu | ok running go get -u launchpad.net/juju-core/... to pull the latest down | 21:04 |
| sinzui | stokachu, The package will be UNRELEASED, but excellent for testing | 21:04 |
| stokachu | sinzui: awesome writing this stuff down | 21:05 |
| sinzui | stokachu, I think it is in the README.md | 21:05 |
| sinzui | if not I borked it when I split the scripts form testing | 21:05 |
| natefinch | I gotta run. good luck! | 21:05 |
| stokachu | sinzui: i didnt see that in the README in the toplevel dir | 21:07 |
| stokachu | is it in another directory? | 21:07 |
| sinzui | stokachu, http://bazaar.launchpad.net/~juju-qa/juju-release-tools/trunk/view/head:/README.md | 21:07 |
| stokachu | ah | 21:07 |
| sinzui | stokachu, did I point your to lp:juju-release-tools ? I created that last week from the older scripts | 21:08 |
| sinzui | stokachu, Those are the actual scripts we test and run. I hope that one day the publish script will work for any private cloud | 21:09 |
| thumper | waigani, menn0: I'm in and out this morning taking Jessie to the dentist | 21:09 |
| menn0 | thumper: no problems. I've got plenty to work on. | 21:09 |
| waigani | thumper: dido | 21:11 |
| thumper | waigani: as in the singer? | 21:11 |
| waigani | lol, typo | 21:11 |
| waigani | fwereade: can I book in a time to talk about test isolation? | 21:17 |
| wallyworld_ | stokachu: i'm back now, ping me when you have an update. i'm keen to know when it works :-) | 21:20 |
| dimitern | niemeyer, hey | 21:24 |
| niemeyer | dimitern: Heya | 21:24 |
| dimitern | niemeyer, can you take a look at this please: https://codereview.appspot.com/99030044/ | 21:25 |
| stokachu | wallyworld_: so i think i got the gopath setup for the upload tools | 21:28 |
| stokachu | wallyworld_: testing now | 21:28 |
| wallyworld_ | great :-) | 21:28 |
| stokachu | wallyworld_: im not confident my go expertise its correct ill let you know im about 15 minutes | 21:29 |
| wallyworld_ | ok, once we are happy, we should be able to get you a new 1.19.2 release by monday for ODS | 21:29 |
| wallyworld_ | then it will just work out of the box | 21:29 |
| niemeyer | dimitern: Checking it out | 21:30 |
| stokachu | wallyworld_: that would be sweet, i think we'd want it for 1.18 as well if thats possible | 21:35 |
| stokachu | at least management will push for it | 21:35 |
| wallyworld_ | sure, we can do that | 21:36 |
| stokachu | thats awesome | 21:36 |
| wallyworld_ | we're here to help :-) | 21:36 |
| stokachu | running my cloud installer now so shouldnt be to much longer | 21:36 |
| wallyworld_ | i'm hopeful...... | 21:36 |
| dimitern | niemeyer, thanks! | 21:41 |
| stokachu | wallyworld_: so i tried to do the go get -v juju.. but only jujud is going in $GOPATH/bin | 21:48 |
| wallyworld_ | go install ./... should be what you need to create the binaries | 21:49 |
| wallyworld_ | run from the juju-core directory | 21:49 |
| stokachu | ok running that now | 21:50 |
| wallyworld_ | or just go install launchpad.net/juju-core/... from outside | 21:50 |
| stokachu | http://paste.ubuntu.com/7418425/ | 21:51 |
| stokachu | my $GOPATH is set to /home/ubuntu/src | 21:52 |
| wallyworld_ | lhmmm | 21:54 |
| wallyworld_ | ah | 21:55 |
| stokachu | wallyworld_: fater i run go get -v launchpad.net/juju-core/... do i just rsync your branch over? | 21:55 |
| stokachu | after* | 21:55 |
| wallyworld_ | GOPATH needs to be /home/ubuntu | 21:55 |
| stokachu | ah | 21:55 |
| wallyworld_ | under GOPATH tere will be src pg and bin directories | 21:56 |
| wallyworld_ | pkg | 21:56 |
| stokachu | ah ok | 21:56 |
| stokachu | reset gopath and re-getting juju-core | 21:56 |
| wallyworld_ | and under src will be various launchpad.net amd github.com dirs will all the source for the dependencies | 21:56 |
| stokachu | ive written a go plugin against juju-core before you'd think i know this by now | 21:56 |
| wallyworld_ | easy to get mixed up | 21:57 |
| dimitern | niemeyer, do you think it's good to land? | 22:04 |
| niemeyer | dimitern: Sorry, I got a call meanwhile | 22:04 |
| niemeyer | dimitern: No, but it's close | 22:04 |
| dimitern | niemeyer, ah, ok | 22:04 |
| stokachu | wallyworld_: ok go tthe binaries now | 22:05 |
| wallyworld_ | great | 22:05 |
| stokachu | wallyworld_: do i rsync over your branch into juju-core and re-run go get? | 22:05 |
| niemeyer | dimitern: Done | 22:05 |
| stokachu | in src/launchpad.net/juju-core | 22:05 |
| dimitern | niemeyer, thank you! | 22:05 |
| wallyworld_ | you can just bzr pull from launchpad | 22:05 |
| stokachu | ok | 22:05 |
| wallyworld_ | bzr pull lp:~axwalk/juju-core/lp1315216-lxc-use-clone | 22:06 |
| wallyworld_ | stokachu: ^^^^^ | 22:06 |
| wallyworld_ | do the above in the juju-core dir | 22:06 |
| wallyworld_ | actually | 22:06 |
| wallyworld_ | bzr merge | 22:06 |
| stokachu | so not lp:~wallyworld/juju-core/fast-lxc-everywhere? | 22:06 |
| wallyworld_ | stokachu: no - i sent another email, do you see it? | 22:07 |
| wallyworld_ | did | 22:07 |
| stokachu | ah nah didnt see that | 22:07 |
| wallyworld_ | ok, np. just use the branch above | 22:07 |
| wallyworld_ | lp:~axwalk/juju-core/lp1315216-lxc-use-clone | 22:07 |
| wallyworld_ | bzr merge lp:~axwalk/juju-core/lp1315216-lxc-use-clone | 22:07 |
| stokachu | ok done, do i re-run go get now? | 22:08 |
| stokachu | or go install ./... | 22:08 |
| wallyworld_ | no, just install | 22:08 |
| stokachu | ok | 22:08 |
| wallyworld_ | go get grabs the source code but we have that already | 22:08 |
| stokachu | gotcha | 22:08 |
| stokachu | so i did the go install ./... , then tried juju status and it says "WARNING unknown config field "use-lxc-clone" | 22:11 |
| stokachu | ran juju bootstrap --upload-tools with same error sorry | 22:11 |
| wallyworld_ | that's the wrong config - see the email | 22:12 |
| wallyworld_ | it should be " lxc-use-clone" | 22:12 |
| stokachu | doh | 22:12 |
| wallyworld_ | :-) | 22:12 |
| wallyworld_ | typo :-) | 22:12 |
| wallyworld_ | the number of times i've done stuff like that i've lost count of | 22:13 |
| stokachu | wallyworld_: so lxc-use-clone is unknown config field as well | 22:13 |
| stokachu | wallyworld_: haha yea been a long day | 22:13 |
| wallyworld_ | so, i think that may be a bad warning - i think that may be a bug | 22:14 |
| wallyworld_ | i think the setting is actually ok | 22:14 |
| stokachu | so maybe after bootstrap then the config field is known | 22:14 |
| wallyworld_ | yes, what you can do after bootstrap is... | 22:14 |
| wallyworld_ | juju get-env lxc-use-clone | 22:14 |
| wallyworld_ | that should print true | 22:14 |
| stokachu | ah ok | 22:14 |
| wallyworld_ | if that warning is indeed a bug, we'll fix it as part of this so it doesn't create confusion | 22:15 |
| stokachu | ok cool, its currently bootstrapping | 22:15 |
| wallyworld_ | just to check, you ran juju "bootstrap --upload-tools" | 22:16 |
| stokachu | wallyworld_: yea | 22:16 |
| wallyworld_ | then i assume you will great a kvm machine and then use juju add-machine to register it with juju | 22:17 |
| wallyworld_ | and then use a --to placement directive to deploy a charm | 22:17 |
| stokachu | yea | 22:17 |
| wallyworld_ | ok | 22:17 |
| wallyworld_ | i have to pop out again to drop the dog to the vet - she is being desexed, i'll be back real soon | 22:18 |
| stokachu | so basically when i deploy to lxc ill see if the template is created right? | 22:18 |
| thumper | wallyworld_: o/ | 22:18 |
| wallyworld_ | yes | 22:18 |
| stokachu | ok cool | 22:18 |
| wallyworld_ | check the /var/lib/lxc dir | 22:18 |
| wallyworld_ | and also deploys to subsequent containers should be quick | 22:19 |
| wallyworld_ | hi thumper | 22:19 |
| stokachu | sweet, have fun at the vet | 22:19 |
| stokachu | ill let you know how it goes | 22:19 |
| wallyworld_ | gotta run, back soon | 22:19 |
| wallyworld_ | ok | 22:19 |
| === cory_fu is now known as cory_fu|away | ||
| stokachu | so deploying with latest code is running on juju 1.19.2 and after deploying mysql to lxc:1 it is still in pending, but no lxc has been installed on machine 1 yet | 22:48 |
| stokachu | this is KVM -> nested lxcs | 22:48 |
| stokachu | not sure if this is a problem with just 1.19 codebase and nested lxc's within a kvm machine | 22:49 |
| stokachu | ok made it run with 1.18.1.1 and juju get-env lxc-use-clone is reporting True | 22:57 |
| wallyworld_ | stokachu: so you merged the branch into a checkout of 1.18? | 23:01 |
| stokachu | wallyworld_: i merged that branch after doing a go get -v | 23:01 |
| wallyworld_ | what did you go get? the 1.18 series trunk? | 23:02 |
| stokachu | go get -v launchpad.net/juju-core/... which shouldve pulled 1.19.2 | 23:03 |
| stokachu | which juju is pointing to $HOME/bin/juju so that seems correct | 23:03 |
| wallyworld_ | ok, but you said above you are running 1.18.1.1? | 23:04 |
| stokachu | yea sorry that was on a previous juju env, just re-bootstrapped and its 1.19.2 | 23:04 |
| wallyworld_ | ok | 23:04 |
| stokachu | get-env lxc-use-clone is returning true | 23:04 |
| stokachu | once machine 1 comes up ill try to deploy a lxc container | 23:05 |
| stokachu | http://paste.ubuntu.com/7418668/ | 23:06 |
| stokachu | thats where im at now | 23:06 |
| stokachu | wallyworld_: doesnt look like lxc is getting installed on kvm machine 1 | 23:06 |
| wallyworld_ | stokachu: the first one takes a long time | 23:07 |
| wallyworld_ | since it has to download the ubuntu image | 23:07 |
| wallyworld_ | but once that is done, the second one should be fast | 23:07 |
| wallyworld_ | you could ssh into the kvm instance and check out the /var/lib/lxc directory | 23:07 |
| wallyworld_ | or run sudo lxc-ls --fancy | 23:08 |
| stokachu | wallyworld_: weird thing is the kvm instance doesn't have lxc installed | 23:08 |
| wallyworld_ | ah | 23:08 |
| wallyworld_ | then that's a problem | 23:08 |
| wallyworld_ | you need to ensure the kvm instance has all required dependencies install | 23:09 |
| stokachu | so in 1.18.1 lxc was installed (maybe by default?) | 23:09 |
| wallyworld_ | i think that's the case | 23:09 |
| wallyworld_ | perhaps | 23:09 |
| wallyworld_ | let me check something | 23:09 |
| stokachu | oh one sec | 23:09 |
| stokachu | wallyworld_: https://github.com/Ubuntu-Solutions-Engineering/cloud-installer/blob/master/cloudinstall/gui.py#L229-L245 | 23:09 |
| stokachu | so thats where we re-configure the lxcbr0 to bridge host-only | 23:10 |
| stokachu | i thought we installed lxc there but we dont | 23:10 |
| wallyworld_ | ok | 23:10 |
| wallyworld_ | so if you are sure lxc is not installed, you'll need to do that. you'll also want to destroy the machine you added (juju destroy-machine) | 23:11 |
| wallyworld_ | then re-add it once lxc is installed | 23:12 |
| stokachu | wallyworld_: ah im hitting that other bug with juju blindly copying over apt-http-proxy | 23:12 |
| wallyworld_ | i recall something bout that but m not familiar with the detail | 23:12 |
| stokachu | yea ive got squid-deb-proxy running on host and when i add a kvm machine it attempts to query the proxy at http://localhost:8000 | 23:13 |
| stokachu | which doesn't exist in the kvm | 23:13 |
| stokachu | i think thats the issue with lxc not being installed | 23:13 |
| stokachu | lemme work around that one sec | 23:14 |
| wallyworld_ | ok | 23:14 |
| wallyworld_ | thumper: i thought we had a fix for the above apt-hhtp_proxy bug already? | 23:14 |
| * thumper looks up | 23:14 | |
| thumper | wat> | 23:14 |
| wallyworld_ | ignore or something? | 23:14 |
| wallyworld_ | see the last few lines of backscroll | 23:15 |
| stokachu | so i just set apt-http-proxy to the host IP | 23:15 |
| stokachu | rather than localhost | 23:15 |
| wallyworld_ | ok. i did seem to recall we allowed a config to let juju ignore it but could be wrong | 23:16 |
| thumper | I'm not aware of any copying over apt-http-proxy | 23:16 |
| stokachu | https://bugs.launchpad.net/juju-core/+bug/1309207 | 23:17 |
| _mup_ | Bug #1309207: juju should not blindly create an apt proxy config file in deployed nodes <apt-http-proxy> <cloud-installer> <local-provider> <juju-core:Triaged> <https://launchpad.net/bugs/1309207> | 23:17 |
| stokachu | so ive just done the workaround fo rnow | 23:17 |
| stokachu | wallyworld_: ok lxc installed after deploy to lxc:1 | 23:19 |
| stokachu | so lets see how fast this goes after the first one | 23:19 |
| wallyworld_ | ok | 23:19 |
| stokachu | template file is there | 23:19 |
| stokachu | still downloading the initial cloudimg | 23:23 |
| wallyworld_ | yeah, could take a few minutes | 23:23 |
| stokachu | wallyworld_: ok awesome, this is way faster | 23:31 |
| wallyworld_ | great :-) | 23:31 |
| stokachu | the downloading took awhile but could just be th enetwork here at the sprint | 23:31 |
| stokachu | but once that was done the only real wait is from the package installation from the charms | 23:32 |
| wallyworld_ | yes, would be a shared bandwidth | 23:32 |
| stokachu | the machines are up and running almost instantly | 23:32 |
| stokachu | machines == lxc containers | 23:32 |
| wallyworld_ | good news, so you happy then | 23:32 |
| stokachu | wallyworld_: yea man this is amazing | 23:32 |
| wallyworld_ | we'll release a 1.19.2 over the weekend and back port to 1.18 | 23:32 |
| wallyworld_ | so you'll be set up well for ODS next week | 23:33 |
| stokachu | awesome i really appreciate your help with this | 23:33 |
| wallyworld_ | np, anytime. been a combined effort. ask if you need anything else | 23:33 |
| stokachu | wallyworld_: will do, thanks again! | 23:33 |
| wallyworld_ | welcome | 23:33 |
| wallyworld_ | stokachu: what would your preference be? a 1.19 release or a 1.18 release with the lxc clone support? | 23:40 |
| wallyworld_ | i'm thinking 1.18 would be safer | 23:41 |
| wallyworld_ | but i'm not sure what we're looking to demo for ODS | 23:41 |
| wallyworld_ | thumper: so we having a juju-core standup now? | 23:47 |
| stokachu | wallyworld_: 1.18 for us definitely | 23:48 |
| wallyworld_ | stokachu: ok, we'll backport the fix to 1.18 and do a 1.18.3 release for next week | 23:49 |
| stokachu | wallyworld_: for our stuff it would be 1.18 for demos | 23:49 |
| waigani | thumper: I can't see any docs on identity or resources in drive? | 23:49 |
| stokachu | thats what we've developed against anyway | 23:49 |
| wallyworld_ | yep, 1.18 it is | 23:49 |
| waigani | menn0: do you have the link to thumper's charm? | 23:55 |
| menn0 | waigani: the github ones? | 23:56 |
| waigani | menn0: yep | 23:56 |
| waigani | I thought I might give writing a charm a go | 23:56 |
| menn0 | that's what I'm doing right now too | 23:56 |
| waigani | menn0: how is it going? | 23:56 |
| menn0 | here they are: lp:~thumper/+junk/github-watcher | 23:56 |
| menn0 | lp:~thumper/+junk/github-readme | 23:57 |
| menn0 | the readme one is a demo consumer of github-watcher | 23:57 |
| waigani | menn0: cheers, are you following a tut? | 23:57 |
| waigani | menn0: ah I was looking on his github account for them | 23:57 |
| menn0 | Mainly the Charm Authors section at https://juju.ubuntu.com/docs/ | 23:58 |
| menn0 | but also looking at other charms and various blog posts for further guidance | 23:58 |
| waigani | menn0: any good finds? | 23:58 |
| menn0 | thumper's charm is hacky and incomplete (I'm sure he'd agree!) and not a good place to start if you want to see how a charm works | 23:59 |
| waigani | menn0: I think I'll follow this: https://juju.ubuntu.com/docs/authors-charm-writing.html | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!