| wwitzel3 | ericsnow: ping | 00:20 |
|---|---|---|
| ericsnow | wwitzel3: hey | 00:20 |
| fwereade_ | right, I had intended to go to sleep rather earlier than this, but hey ho. http://reviews.vapour.ws/r/1934/ now has complete logic tests, and enough docs to be worth poking at; I'm now looking to land it if anyone has the bandwidth for it | 00:24 |
| * fwereade_ bed | 00:25 | |
| davecheney | mwhudson i have an email from the go pm who's asking for contact details for the go packaging maintainers | 01:02 |
| davecheney | i'm tempted to just give him your name | 01:02 |
| davecheney | that is, unless you can find someone else for me to foist this on | 01:02 |
| === kadams54 is now known as kadams54-away | ||
| mwhudson | davecheney: in ubuntu? me and doko i guess would be a good start | 01:44 |
| davecheney | mwhudson: i guess that is my first question | 01:45 |
| davecheney | don't ubuntu follow debian | 01:45 |
| davecheney | i wonder if I should send him to the debian folks first | 01:45 |
| mwhudson | the debain folks are paultag and tianon | 01:45 |
| davecheney | tainon | 01:45 |
| davecheney | i think I know him/them | 01:45 |
| mwhudson | as usual when being asked a question the first response is "what are you trying to achieve" | 01:46 |
| davecheney | jason is a pm | 01:46 |
| davecheney | he's used to not getting a straight answer | 01:46 |
| mwhudson | ah, i think ian cc:ed him on the mail he sent me earlier today | 01:48 |
| davecheney | jason b | 01:48 |
| davecheney | yeah, all roads lead back to product managment | 01:48 |
| mwhudson | yeah | 01:50 |
| === anthonyf is now known as Guest33778 | ||
| wallyworld | thumper: 5 min chat? | 01:58 |
| thumper | wallyworld: sure | 01:59 |
| davecheney | thumper: https://github.com/juju/testing/pull/71 | 02:22 |
| davecheney | thumper: i have a problem | 02:55 |
| davecheney | lucky(~/src/github.com/juju/juju) % go install -v ./... | 02:55 |
| davecheney | ../../../gopkg.in/juju/charm.v5/testing/mockstore.go:18:2: cannot find package "gopkg.in/check.v1" in any of: /home/dfc/go/src/gopkg.in/check.v1 (from $GOROOT) /home/dfc/src/gopkg.in/check.v1 (from $GOPATH) | 02:55 |
| davecheney | juju depends ont he charmstore | 02:55 |
| davecheney | the charmstore depends on gopkg.in/check.v1 | 02:55 |
| davecheney | and I believe rog will block any landing into that repo | 02:55 |
| thumper | sure... | 02:55 |
| thumper | but since we aren't running tests against it, why is it a problem? | 02:56 |
| davecheney | i *think* this will be ok | 02:56 |
| davecheney | yes, that | 02:56 |
| davecheney | but it might also be a blocker | 02:56 |
| davecheney | i need to point this out | 02:56 |
| thumper | in theory, gocheck should end up being in any non test dependencies right? | 02:57 |
| thumper | are we using any *testing packages from the charm package? | 02:57 |
| thumper | ... | 02:57 |
| thumper | mockstore? | 02:57 |
| davecheney | yes | 02:57 |
| davecheney | so if that package provides checkers that we're using | 02:57 |
| * thumper grunts | 02:57 | |
| davecheney | we're boned | 02:57 |
| davecheney | if it's just using the types | 02:58 |
| davecheney | we're probably ok | 02:58 |
| thumper | ok | 02:58 |
| thumper | let me know | 02:58 |
| * thumper goes to make coffee | 02:58 | |
| davecheney | we might still be ok, i think gocheck uses an interface | 02:59 |
| davecheney | or reflection to figure out which of the arguments are checkers | 02:59 |
| davecheney | and there is no requirement that a cheker implemetns an interface | 02:59 |
| davecheney | or embeds a checker base type | 03:00 |
| davecheney | so this might be ok | 03:00 |
| davecheney | if a bit ropey | 03:00 |
| davecheney | worker/uniter/runner/jujuc/testing/networking.go:23: cannot use checkers.DeepEquals (type "gopkg.in/check.v1".Checker) as type "github.com/juju/check".Checker in argument to c.Check: | 03:00 |
| davecheney | "gopkg.in/check.v1".Checker does not implement "github.com/juju/check".Checker (wrong type for Info method) | 03:00 |
| davecheney | have Info() *"gopkg.in/check.v1".CheckerInfo | 03:00 |
| davecheney | want Info() *"github.com/juju/check".CheckerInfo | 03:00 |
| davecheney | opps, spoke too soon | 03:00 |
| natefinch | ...and that's why you avoid using custom types in interfaces | 03:02 |
| davecheney | yup | 03:02 |
| davecheney | thumper: nope | 03:03 |
| davecheney | i'm screwed | 03:03 |
| davecheney | we have a gordian knot between juju/juju, juju/testing and check.v1 and charm.v5 | 03:03 |
| davecheney | i cannot complete this change unless the charmstore owners agree to also switch to our fork | 03:04 |
| natefinch | luckily they work for us, so that should not be that hard? Maybe? | 03:04 |
| davecheney | thumper: i'm shelving this card, I cannot complete it at thsi time | 03:10 |
| thumper | davecheney: ack | 03:24 |
| thumper | man... | 03:26 |
| thumper | that seems screwed up | 03:26 |
| === kadams54 is now known as kadams54-away | ||
| davecheney | thumper: what do you want to do ? | 04:06 |
| thumper | davecheney: I'm unclear as to why the checker is using gopkg.in checker... | 04:07 |
| davecheney | its a suite | 04:08 |
| davecheney | check/v.5 uses suites from juju/testing | 04:08 |
| davecheney | juju/testing expects a "github.com/juju/check".Checker, this is a gc.C | 04:09 |
| davecheney | check.v5 suites expects a "gopkg.in/check.v1".Checker gc.c | 04:09 |
| davecheney | check.v5 suites expects a "gopkg.in/check.v1".Checker gc. | 04:09 |
| davecheney | C | 04:09 |
| davecheney | hmm, that wasn't quite right | 04:11 |
| davecheney | some of the names of the gocheck types aren't right in that explanation | 04:11 |
| davecheney | but the effect is the same | 04:11 |
| natefinch | because charm.v5 uses gopkg.in/check.v1 and everything else uses github.com/juju/check ... .and the interfaces aren't compatible because they contain package-specific types. | 04:13 |
| wallyworld | waigani: do you gave time for a chat about simplestreams branch? | 04:14 |
| waigani | wallyworld: yep sure | 04:14 |
| wallyworld | https://plus.google.com/hangouts/_/canonical.com/tanzanite-stand | 04:14 |
| thumper | davecheney: ah poo | 04:16 |
| thumper | davecheney, natefinch: can we change juju/check to not expect package specific types? | 04:17 |
| thumper | however | 04:17 |
| davecheney | natefinch: is gc.C a type or an internface | 04:17 |
| thumper | that'll only work for checkers | 04:17 |
| davecheney | thumper: the problem is suites | 04:17 |
| thumper | not the C | 04:17 |
| thumper | right? | 04:17 |
| thumper | yeah | 04:17 |
| * thumper gets it | 04:17 | |
| davecheney | well, there are several problems | 04:18 |
| thumper | as frustrating as it is | 04:18 |
| thumper | even if we could fix juju/check | 04:18 |
| davecheney | charm.v5 is using check.v1 as it's definition of gc.C passed to suites | 04:18 |
| davecheney | and juiju/testing is using our fork | 04:18 |
| thumper | with the charms.v5 using gopkg.in, it means it can't use us | 04:18 |
| * thumper nods | 04:18 | |
| thumper | double poo | 04:18 |
| davecheney | TL;DR, everyone has to upgrade | 04:18 |
| thumper | this is go types done wrong IMO | 04:19 |
| thumper | davecheney: I think the fastest way to progress would be to provide the upstream gocheck with the exact patch we want | 04:19 |
| thumper | and apply pressure to get it in | 04:20 |
| davecheney | i agree | 04:20 |
| thumper | did that other Chris fella respond to the PR comment? | 04:20 |
| thumper | an aside should be for us to learn from this when designing bits of code | 04:22 |
| davecheney | nope | 04:22 |
| davecheney | thumper: i agree | 04:22 |
| davecheney | but there is no value in having that conversation on IRC | 04:23 |
| davecheney | it will be lost | 04:23 |
| davecheney | please take it to the juju-dev mailing list | 04:23 |
| thumper | can you propose a PR to gocheck upstream that has the fix we need, based on the work Chris did? | 04:24 |
| thumper | davecheney: ? | 04:24 |
| davecheney | yes, on it | 04:24 |
| thumper | cheers | 04:26 |
| waigani | anastasiamac: I started reviewing your branch but need to run sorry, I've added a few comments, will continue later if it's still up. | 04:41 |
| davecheney | thumper: oh, THATS's right | 05:01 |
| davecheney | the gocheck tests dont pass | 05:01 |
| davecheney | i forgot that | 05:01 |
| davecheney | oh well | 05:01 |
| davecheney | fuck it | 05:01 |
| thumper | WT actual F? | 05:01 |
| davecheney | yeah, i logged that bug a year or so ago | 05:01 |
| davecheney | alst time I made a fix to a checker | 05:02 |
| davecheney | well, maybe i logged a bug | 05:02 |
| thumper | wallyworld: http://reviews.vapour.ws/r/1948/ | 05:05 |
| thumper | wallyworld: sorry | 05:05 |
| wallyworld | looking | 05:05 |
| thumper | was after waigani | 05:05 |
| thumper | but he isn't here | 05:06 |
| thumper | w-TAB | 05:06 |
| thumper | fail | 05:06 |
| thumper | wallyworld: I can get someone else that is more familar with the code if you like | 05:06 |
| wallyworld | thumper: maybe that's better? | 05:06 |
| wallyworld | i 'm about to go do school pickup | 05:07 |
| thumper | wallyworld: sure, np | 05:07 |
| davecheney | git push --set-upstream origin fix-data-race-on-status | 05:17 |
| davecheney | fatal: https://gopkg.in/check.v1/info/refs not valid: is this a git repository? | 05:17 |
| davecheney | reason 2^63 why I don't like gopkg.in | 05:18 |
| davecheney | "oh,you downloaded this repo, but I'm not going to tell you where origin _really_ is" | 05:18 |
| davecheney | thumper: https://github.com/go-check/check/pull/44 | 05:19 |
| thumper | davecheney: thanks | 05:19 |
| davecheney | confirmed the race in worker/provisioner is fixed | 05:19 |
| thumper | awesome | 05:19 |
| thumper | laters peeps | 05:49 |
| wallyworld | axw: if you have 15 minutes, would love a small review for a 1.24.1 bug fix http://reviews.vapour.ws/r/1947/ | 07:04 |
| axw | wallyworld: looking | 07:09 |
| wallyworld | ty | 07:09 |
| axw | wallyworld: when is a unit in "maintenance"? that's when the machine is being provisioned? | 07:14 |
| wallyworld | axw: Unknown during allocation | 07:15 |
| wallyworld | maintenance during install hook | 07:15 |
| wallyworld | door, be back in a sec | 07:15 |
| dimitern | wallyworld, hey | 07:16 |
| dimitern | wallyworld, re bug 1464616 we talked about yesterday | 07:16 |
| mup | Bug #1464616: destroy-machine --force no longer forceably destroys machine <destroy-machine> <regression> <juju-core:Triaged> <juju-core 1.24:In Progress by wallyworld> <https://launchpad.net/bugs/1464616> | 07:16 |
| wallyworld | dimitern: http://reviews.vapour.ws/r/1947/ | 07:17 |
| dimitern | wallyworld, I couldn't figure out what might be the issue without logs, but it seems you've got it | 07:17 |
| wallyworld | axw is looking | 07:17 |
| wallyworld | yeah :-) | 07:17 |
| dimitern | wallyworld, awesome :) | 07:17 |
| wallyworld | axw: part of the complicating factor now is that we need to look at both agent and unit status to see what's going on. before it was all just unit status | 07:20 |
| * axw nods | 07:20 | |
| dimitern | wallyworld, reviewed | 07:22 |
| wallyworld | ty | 07:22 |
| wallyworld | axw: with the "...OrError" - it would be an error whn running the install hook, so you could argue it's still installing, hence i left it off the name. is that ok, or wuld you prefer the name change? | 07:25 |
| * dimitern is itching to write some usable docs around the various CI python classes / tools | 07:25 | |
| axw | wallyworld: it could also be in error unrelated to installing | 07:25 |
| axw | wallyworld: so not really | 07:26 |
| wallyworld | could be but the other checks imit it to installing | 07:26 |
| wallyworld | i'll change the name | 07:26 |
| axw | wallyworld: the other asserts do, but that means you have to know about the asserts together in context | 07:26 |
| wallyworld | that is true | 07:26 |
| axw | wallyworld: completely unrelated: I changed tack on volume destruction a bit. I undid what I was talking about in the standup, and have simplified the worker so it just destroys volumes/filesystems when they're Dead. then in state we'll mark a volume/filesystem as Dead when it has no more dependents | 07:27 |
| axw | so the worker no longer has to track dependencies | 07:28 |
| wallyworld | simplicity is nice | 07:28 |
| wallyworld | sounds better | 07:28 |
| dimitern | wallyworld, axw, can a subordinate have actions of its own? | 07:29 |
| dimitern | fwereade_, ^^ | 07:30 |
| wallyworld | not sure tbh | 07:30 |
| dimitern | I'm thinking of creating a simple subordinate charm that has actions returning various networking settings - iptables, routes, etc. | 07:30 |
| axw | dimitern: sorry no idea | 07:32 |
| dimitern | no worries, will rtfm :) | 07:33 |
| wallyworld | dimitern: i don't understand the code review comment about "ErrAborted handling below" | 07:34 |
| dimitern | wallyworld, well, any txn.Op with an Assert can trigger ErrAborted | 07:34 |
| wallyworld | sure. which one are you referring to? | 07:35 |
| dimitern | the unitAgentAllocatingOrInstalling | 07:35 |
| wallyworld | that's the Assert, sorry i mean which ErrAborted handler? | 07:35 |
| * dimitern actually looks at the full source of that method | 07:36 | |
| wallyworld | it's all takne care of AFAIK. the txn will just be retried as normal | 07:36 |
| wallyworld | either the unit was not installed or it was when the txn was started | 07:36 |
| wallyworld | it's called from line 289 func (u *Unit) Destroy() (err error) | 07:37 |
| dimitern | wallyworld, yeah, I can't see anything wrong with it off hand, but I'd recommend fwereade_ having a look | 07:38 |
| wallyworld | ta | 07:38 |
| * dimitern now really likes the idea of multi-series charms in the face of cross-series CI tests | 07:44 | |
| dimitern | jw4, are you around by any chance? | 07:48 |
| wallyworld | jam: i've reworked the resource document a fair bit. the resource-path is i think improved as is the CLI. rick is tied up fixing their production issue, but i've answered is questions and posed a few of my own in new comments. when we are satisfied that the doc is "good enough" to show more people i'll link into the main spec. note that it's not complete, but the aim is for a WIP with enough defined to allow development to start | 07:57 |
| === mgz is now known as mgz_ | ||
| dimitern | voidspace, jam, fwereade_, standup? | 09:01 |
| voidspace | dimitern: omw | 09:01 |
| mup | Bug #1466011 opened: apiserver tests fail on windows <ci> <regression> <test-failure> <windows> <juju-core:Triaged> <https://launchpad.net/bugs/1466011> | 09:40 |
| fwereade_ | wallyworld, I'm afraid http://reviews.vapour.ws/r/1947/ does not lgtm, does my comment make sense? | 09:58 |
| fwereade_ | wallyworld, I think you probably want to look at (*State).obliterateUnit | 09:59 |
| dooferlad | voidspace: success? | 10:01 |
| lazyPower | omg i think i'm going to cry... i had a trapped upgrade charm pending after i wrote an entire refactor of a hook (~ 250 lines) .. just to have it wiped out by upgrade-charm ;_; | 10:02 |
| voidspace | dooferlad: nope | 10:03 |
| fwereade_ | lazyPower, owww :( | 10:03 |
| voidspace | dooferlad: using dhcp seems to overwrite the dns-nameservers option | 10:03 |
| voidspace | dooferlad: using static (with the correct values) just plain doesn't work | 10:03 |
| lazyPower | fwereade_: that awkward moment i wish we were still git based so i could have recovered | 10:04 |
| voidspace | dooferlad: I suspect it's a bad interaction with the bridging config for br0 | 10:04 |
| fwereade_ | lazyPower, haha :( | 10:04 |
| fwereade_ | lazyPower, you *should* be able to stop a pending upgrade that hasn't started yet by upgrading back to the original | 10:04 |
| dooferlad | voidspace: do you actually need br0? | 10:05 |
| lazyPower | fwereade_: my changes were remote, not local. so i had no backup and forgot i sent the upgrade-charm like an hour prior. | 10:05 |
| lazyPower | exited the hook thinking "Yes, now i can sync back" | 10:05 |
| lazyPower | doh | 10:05 |
| fwereade_ | lazyPower, bad luck :( | 10:05 |
| lazyPower | indeed | 10:05 |
| voidspace | dooferlad: I'll try getting rid of it and see what breaks :-) | 10:05 |
| dooferlad | voidspace: ahh, fun with networking :-) | 10:05 |
| lazyPower | it was too late, by the time upgrade_charm was trapped in tmux, i knew i was taking a stroll through "trololol" land | 10:06 |
| voidspace | dooferlad: apparently I do need it | 10:17 |
| voidspace | dooferlad: without it, no network | 10:17 |
| voidspace | dooferlad: I'll dig into where it comes from | 10:17 |
| voidspace | dooferlad: statically configuring br0 doesn't work - it has a bunch of bridge options set | 10:18 |
| voidspace | dooferlad: http://pastebin.ubuntu.com/11729739/ | 10:18 |
| voidspace | dooferlad: it's to do with kvm (br0) | 10:20 |
| voidspace | dooferlad: docs here imply I ought to be able to statically configure | 10:20 |
| voidspace | https://help.ubuntu.com/community/KVM/Networking | 10:20 |
| voidspace | dooferlad: I was missing gateway before which is why I think statically configuring br0 didn't work | 10:24 |
| dooferlad | voidspace: oh, yes, you will need that! | 10:26 |
| dimitern | dooferlad, you've got a review; btw add an Overhead card for it please | 10:31 |
| voidspace | dooferlad: but dns-nameservers seems to be ignored now | 10:31 |
| dooferlad | dimitern: thanks, already acting on it | 10:32 |
| dooferlad | dimitern: overhead card? | 10:32 |
| dimitern | dooferlad, for that PR | 10:33 |
| dooferlad | dimitern: don't all PRs go through review though? | 10:34 |
| dimitern | dooferlad, i'd like to track all PRs that land with cards | 10:34 |
| dimitern | dooferlad, yes, indeed | 10:34 |
| dimitern | dooferlad, we're doing a lot of overhead tasks and a few actually planned, so I'd like to keep track of this | 10:35 |
| voidspace | dooferlad: it seems like I need to have the dns-nameservers section in eth0 not in br0 | 10:40 |
| dooferlad | voidspace: oh, interesting! | 10:40 |
| voidspace | dig now reports the correct nameserver | 10:40 |
| voidspace | doesn't *seem* to have improved connection speed | 10:41 |
| voidspace | I'll try running the tests though | 10:41 |
| dooferlad | if you "dig nanosheep.org" or some other server you haven't looked at recently, does it take long? | 10:41 |
| dooferlad | voidspace: ^^ | 10:41 |
| voidspace | dooferlad: that returned quickly enough | 10:42 |
| voidspace | I think this means that dns isn't the issue | 10:42 |
| dooferlad | voidspace: is quickly sub 200ms? From 127.0.0.1? If so, yea, that looks fine. | 10:43 |
| voidspace | dooferlad: hmm... 599ms | 10:43 |
| voidspace | cmd/juju tests are no quicker | 10:44 |
| dooferlad | voidspace: http://paste.ubuntu.com/11729870/ | 10:44 |
| voidspace | :-/ | 10:44 |
| dooferlad | voidspace: ping response time from an upstream DNS server? | 10:45 |
| voidspace | dooferlad: for lots of other sites I'm getting really quick responses | 10:46 |
| dooferlad | voidspace: it has to be a site you haven't looked up or you will get a cached response | 10:47 |
| voidspace | dooferlad: cached ones return in 0ms :-) | 10:47 |
| dooferlad | voidspace: I get 1ms cached responses | 10:47 |
| voidspace | dooferlad: response times for other domains really vary | 10:47 |
| dooferlad | voidspace: could just be a one-off slow response | 10:47 |
| voidspace | yeah | 10:47 |
| dooferlad | OK, other stuff. Do other machines on your network have the same slow browsing problem? | 10:48 |
| voidspace | no | 10:48 |
| dooferlad | anything unusual about that machines network connection? Could you try another cable/ | 10:49 |
| dooferlad | ? | 10:49 |
| voidspace | the connection speed is fine | 10:49 |
| voidspace | and that wouldn't affect locally running tests | 10:50 |
| dooferlad | indeed | 10:50 |
| voidspace | it's not slow browsing, it's slow initial connection | 10:50 |
| voidspace | (which really sounds like dns but I'm fairly sure isn't now) | 10:50 |
| voidspace | and that particular problem started after we changed iptables | 10:50 |
| voidspace | I might try removing those rules to see if it changes again | 10:50 |
| dooferlad | sounds like a plan | 10:50 |
| voidspace | I don't *know* that cmd/juju got slow then, it may just be a coincidence | 10:51 |
| voidspace | so removing them and trying again will let me know | 10:51 |
| voidspace | I might go back to some real work for a bit first | 10:51 |
| dooferlad | removing those iptables rules is kind of trivial though - just comment them out of the saved rules file and restore the rules from it | 10:51 |
| dooferlad | dimitern: review responded to. | 10:54 |
| dimitern | dooferlad, cheers, looking | 10:54 |
| dimitern | dooferlad, let's drop the second failing StopsInstances() call from that test then | 10:55 |
| dooferlad | dimitern: we already test StopInstances, I was just seeing if there was anything interesting that would come up around doing it twice. The entire test is pointless if we drop the second call. | 10:56 |
| dimitern | dooferlad, it would be good to figure out why it's reporting some PathError, when it should return something like "no such container" etc. | 10:56 |
| dooferlad | dimitern: that is because the first thing it does is try to delete some files and directories, then it calls lxc-destroy | 10:56 |
| dooferlad | dimitern: so the first error it returns it just what comes back from those delete calls | 10:57 |
| dimitern | dooferlad, right, that's seems wrong | 10:57 |
| dooferlad | dimitern: calling lxc-destroy first would seem sane to me, then tidying up. | 10:57 |
| dimitern | dooferlad, yeah, let's go back to this at some point | 10:58 |
| dooferlad | dimitern: on the 1.24 branch, I was using AssertFileContains rather than AssertFileContains because I figured having both functions was probably overkill. | 10:58 |
| dooferlad | dimitern: was going to ask about removing AssertFileContains | 10:58 |
| dooferlad | dimitern: happy to keep both and use them though. AssertFileContains does seem to be the most common use case, so having a convenience function seems OK. | 10:59 |
| dimitern | dooferlad, I like the more generic AssertFileContents, but since asserts with jc.Contains on files are fairly common, having a simple wrapper around the more generic assert is nice | 11:03 |
| === kadams54 is now known as kadams54-away | ||
| fwereade_ | waigani, axw: you're both online, and have contributed to state/collections.go; can either of you ballpark estimate the hassle of extracting it (and multiEnvRunner ...and whatever else has to come with it) into its own state subpackage, so I can make use of it from another state subpackage? | 11:59 |
| fwereade_ | waigani, axw: my gut feeling is "difficult"? | 12:00 |
| fwereade_ | jam, sorry, 5 mins | 12:00 |
| jam | fwereade_: k | 12:01 |
| jam | alexisb isn't here yet either | 12:01 |
| waigani | fwereade_: actually I don't think it would be that bad | 12:01 |
| waigani | fwereade_: menno and I worked on it originally when we migrated the collections to multi envs | 12:02 |
| waigani | menno wrote the original collections.go and would be most familiar with it | 12:02 |
| fwereade_ | waigani, yeah, I ask because you're online ;p | 12:05 |
| waigani | but off the top of my head, I can't think of any "got yas". state/txn.go would have to import the subpackage but that should be fine | 12:06 |
| waigani | fwereade_: I can bring it up in the standup - 9hrs from now. I'd be happy to look at extracting it - but it'll depend on tim and priorities etc | 12:07 |
| jw4 | dimitern: probably too late, but you pinged? | 12:47 |
| === anthonyf is now known as Guest64410 | ||
| dimitern | jw4, no worries; I had some questions re actions, but I figured it out from the docs :) | 12:48 |
| jw4 | dimitern: cool | 12:48 |
| TheMue | dimitern: could you paste a rough outline how you would use the remover with IP addresses? it's no entity, so would you implement an EntityFinder taking a tag but looking for the IPAddress by id? | 12:53 |
| TheMue | dimitern: even if it's a nice component for entities it's more code than the direct implementation | 12:53 |
| dimitern | TheMue, that's a good question | 12:54 |
| TheMue | dimitern: or alternatively make the IPAddress to a valid entity too (with adding an according kind to juju/names). | 12:54 |
| dimitern | TheMue, which reminds me we don't have tags for addresses | 12:54 |
| TheMue | dimitern: reading a bit of remover code and how it works on entities it's really a nice mixin | 12:55 |
| TheMue | dimitern: exactly | 12:55 |
| dimitern | TheMue, let's do this - propose a juju/names PR that introduces IPAddressTag | 12:56 |
| dimitern | TheMue, this should be a separate, overhead card btw | 12:56 |
| dimitern | TheMue, tags need a kind (used as prefix), let's use "ip-<value>" | 12:57 |
| TheMue | dimitern: btw, one little aspect of mixins is that you inherit fields and methods you don't directly aware of, a bit like OOP. here composition and explicit method passing Foo() { my.plug.Foo() } would be better (long term) | 12:57 |
| TheMue | dimitern: OK, will add the tag as quick one and add it with a second PR to the remover | 12:58 |
| dimitern | TheMue, that's true, but if the embeddable type is intended to be embedded, this shouldn't be a problem (fields/methods "creeping in" unobserved :) | 12:58 |
| === kadams54 is now known as kadams54-away | ||
| dimitern | TheMue, yeah, it's easy to do the juju/names PR first | 12:59 |
| TheMue | dimitern: it's more an effect of visibility | 12:59 |
| === kadams54-away is now known as kadams54 | ||
| * TheMue loves DVCSes for simple switching between branches | 13:00 | |
| dimitern | TheMue, hmm.. but I can see a problem with address tags | 13:00 |
| dimitern | TheMue, just the value won't be enough to make a transformation from network.Address to names.AddressTag and back (e.g. in the case Scope was set to something else, rather than "discovered" automatically from the value) | 13:01 |
| dimitern | fwereade_, ping | 13:01 |
| fwereade_ | dimitern, pong | 13:01 |
| TheMue | dimitern: ic | 13:02 |
| dimitern | fwereade_, hey, so it's high time to introduce tags for ip addresses | 13:02 |
| TheMue | dimitern: could we by this way find a better name than just "value"? | 13:02 |
| dimitern | fwereade_, but since it's a struct, just using the Value is not loseless wrt transforming from tag to address | 13:02 |
| TheMue | dimitern: could we by this way find a better name than just "value"? | 13:03 |
| TheMue | ouch, twice | 13:03 |
| dimitern | TheMue, yeah, I'm thinking of "ip-<type>-<scope>-<network>-<value>" | 13:03 |
| dimitern | fwereade_, ^^ ? or perhaps "<type-kind>-<scope>-<network>-<value>" e.g. ipv4-public-juju-private-10.3.2.1 | 13:04 |
| TheMue | dimitern: value is the address itself in standard notation, isn't it? | 13:04 |
| dimitern | TheMue, yeah, but it also holds extra metadata about its scope, type, and network | 13:05 |
| dimitern | it can even be a hostname | 13:05 |
| fwereade_ | dimitern, that feels wrong | 13:06 |
| fwereade_ | dimitern, having all that jammed into a tag | 13:06 |
| dimitern | fwereade_, the unique _id for ipaddressesC is DocID, which can be used in a tag, but it'll contain the envuuid | 13:06 |
| TheMue | dimitern: the field value, the rest has extra fields, is only the address/hostname. hmm, sadly don't have a better name than "value" :/ | 13:07 |
| fwereade_ | dimitern, all that metadata is, well, metadata | 13:07 |
| dooferlad | dimitern: I have a ship it on http://reviews.vapour.ws/r/1941/ but not the original code on trunk (http://reviews.vapour.ws/r/1936/). Could you press the magic button? | 13:09 |
| dimitern | fwereade_, we *could* go only with the value in the tab, *but* this won't work if you're trying to serialize e.g. "public:10.0.3.1" as "ip-10.0.3.1", as on the reverse path with network.NewAddress(tag.Id()) the scope will be "guessed" as local-cloud not public | 13:09 |
| fwereade_ | dimitern, right | 13:09 |
| dimitern | dooferlad, looking | 13:09 |
| dimitern | fwereade_, or "ip-localhost" for that matter looks weird | 13:09 |
| fwereade_ | dimitern, so the reason to jam all that into the tag is for uniqueness? | 13:10 |
| dimitern | fwereade_, use a single tag type and multiple sub-kinds? "ip<kind>-<value>" ? e.g. "iphostname-localhost" or (iphost-?) "ipv4-10.0.3.1", "ipv6-2001:db8::1" | 13:11 |
| fwereade_ | dimitern, if those bits are all immutable per address (which I imagine they are), how about `address-<sha256-of-immutable-attributes>`? | 13:11 |
| TheMue | that feels strange | 13:11 |
| dimitern | fwereade_, not for uniqueness, as the value + envuuid is the _id, so it's unique, but for better carrying out the original intent | 13:11 |
| dimitern | fwereade_, hmm we need to know what to hash back on FindEntity though | 13:12 |
| jam | dimitern: I think fwereade's idea is that what you really want is a document with a lot of data in it, and not have to shove all of that information into the tag | 13:12 |
| jam | what about "ip-<RANDOM>" and then that just gives you what doc you have? | 13:12 |
| fwereade_ | dimitern, well, you store the hash in the doc and look up by that, right? | 13:12 |
| fwereade_ | jam, indeed | 13:13 |
| * jam disappears to go shopping | 13:13 | |
| dimitern | fwereade_, just for the sake of having a sha256 hash in the tags? | 13:13 |
| fwereade_ | dimitern, more for the sake of not jamming a whole struct into a field | 13:13 |
| TheMue | so we could take a meaningless but unique uuid too | 13:14 |
| dimitern | fwereade_, hmm | 13:14 |
| fwereade_ | TheMue, indeed, equally | 13:14 |
| fwereade_ | dimitern, opaque identifiers are good things | 13:14 |
| dimitern | fwereade_, I'd rather hash the DocID and use that - it's already in the doc and can be found | 13:14 |
| fwereade_ | dimitern, sure, that sounds fine too | 13:14 |
| TheMue | +1 | 13:15 |
| dimitern | fwereade_, address-<sha256(_id)> | 13:15 |
| waigani | wallyworld: ignoring unknown tools metadata: http://reviews.vapour.ws/r/1955/ | 13:15 |
| TheMue | dimitern: address-<docID> | 13:15 |
| fwereade_ | dimitern, that sgtm, you'll still have to store the hashed docid to look it up :) | 13:15 |
| mup | Bug #1465695 changed: StorageAddSuite setup fails <ci> <intermittent-failure> <test-failure> <juju-core:Triaged> <juju-core db-log:Triaged> <https://launchpad.net/bugs/1465695> | 13:16 |
| TheMue | or event better ipaddress-<docID>, ipaddress represents the real type (if we have other addresses in the future, like mac-address), docID is already in the document | 13:17 |
| dimitern | fwereade_, yeah, or perhaps Find all for the current env and iterate? :) | 13:17 |
| TheMue | and docID is unique | 13:18 |
| dimitern | TheMue, it's not just an ip address, as it can be a hostname | 13:18 |
| dimitern | fwereade_, why not use the docId unhashed indeed? | 13:18 |
| TheMue | dimitern: we talk about a tag identifying a type, and the typename is IPAddress. otherwise we should rename the type too *iiirks* | 13:19 |
| dimitern | dooferlad, ship it :) | 13:19 |
| dooferlad | dimitern: click! | 13:19 |
| TheMue | dimitern: that's why I would take ipaddress-<docID> | 13:19 |
| dimitern | TheMue, I agree the name can be better, but let's not change everything at once :) | 13:20 |
| TheMue | dimitern: and other address types later, mac addresses, addresses for bills, whatever, can use their type as part of the tag | 13:20 |
| TheMue | dimitern: no no, I don't want to change it, only want to have it in the tag | 13:20 |
| TheMue | dimitern: so it's 1:1 | 13:20 |
| dimitern | fwereade_, with the "address-<docID>" format we'll have tags like "address-fedcba98-7654-4321-ba98-76543210beef:10.0.3.1" | 13:22 |
| TheMue | dimitern: you surely wanted to write "ipaddress-<docID>" *scnr* | 13:23 |
| dimitern | fwereade_, or, maybe even better to just use the value and rely on the magical append of "envuuid:" that happens in state/collections.go for a naked FindId() | 13:23 |
| dimitern | TheMue, I don't mind *that* much | 13:24 |
| dimitern | :) | 13:24 |
| TheMue | hehe | 13:24 |
| * dimitern reads back what he've written earlier *facepalm* | 13:25 | |
| fwereade_ | dimitern, the only *really* important thing about a tag is that it be unique within an environment | 13:25 |
| dimitern | we don't need to care for tag-to-ip conversion based on the format of the tag at all | 13:25 |
| mup | Bug #1465695 opened: StorageAddSuite setup fails <ci> <intermittent-failure> <test-failure> <juju-core:Triaged> <juju-core db-log:Triaged> <https://launchpad.net/bugs/1465695> | 13:25 |
| dimitern | fwereade_, yes, but none of the tags (except the environment tags obviously) carry the envuuid prefix that make them unique | 13:26 |
| fwereade_ | dimitern, yeah: sometimes that's a convenient feature, but I think the only thing that really really depends on info encoded in ids is the watcher logic in state | 13:26 |
| fwereade_ | dimitern, I think it's fine for a tag to be unique only within the scope of a given environment | 13:27 |
| dimitern | fwereade_, yeah, they report local ids | 13:27 |
| dimitern | not docIDs | 13:27 |
| dimitern | TheMue, fwereade_, ok, as I need to go out for a while, can we agree on "ipaddress-<value>" for the tag format and live with it? | 13:27 |
| TheMue | dimitern: so in our case it would be "ipaddress-<value>"? | 13:27 |
| TheMue | h5 | 13:27 |
| dimitern | yeah | 13:28 |
| fwereade_ | dimitern, can we really guarantee uniqueness per environment there? | 13:28 |
| fwereade_ | dimitern, it's causing my "changes stakeholders will ask for" spidey sense to tingle | 13:29 |
| TheMue | hmm, in an env with multiple subnets sharing the same addresses? possible? | 13:29 |
| fwereade_ | TheMue, I think it's *currently* specced that subnets can't overlap | 13:29 |
| dimitern | fwereade_, yes we can as you can only use such tags once you've logged into a given environment | 13:30 |
| fwereade_ | TheMue, dimitern: I just feel like that's an unreasonable restriction in a complex network environment | 13:30 |
| dimitern | fwereade_, we're only talking about how to access ipaddress entities we already have in the db for the current env | 13:31 |
| fwereade_ | TheMue, dimitern: why can't isolated subnets use overlapping ranges? | 13:31 |
| TheMue | fwereade_: but can an environment have multiple disjunct subnets, having the same address range | 13:31 |
| dimitern | fwereade_, isolated like in a separate space? | 13:31 |
| fwereade_ | dimitern, yes | 13:32 |
| dimitern | fwereade_, TheMue, subnet CIDRs for a given space should NOT overlap | 13:32 |
| fwereade_ | dimitern, I know that juju will refuse to allow it | 13:32 |
| dooferlad | as soon as you get >1 network associated with a machine you can get up to all sorts of fun. | 13:32 |
| TheMue | dimitern: should or must? | 13:32 |
| dimitern | fwereade_, TheMue, that's the whole point of the subnets being equal within a space | 13:32 |
| fwereade_ | dimitern, within a single space, yes, you don't want subnets to overlap | 13:33 |
| dimitern | TheMue, fair enough - it must not overlap | 13:33 |
| TheMue | dimitern: ok, so we ensure that we can have multiple subnets but even then each IP is only used once | 13:34 |
| dimitern | fwereade_, the case you're describing sounds like having a machine in two separate, disjoint spaces | 13:34 |
| fwereade_ | dimitern, but if you're modelling two spaces, that are completely distinct, and happen to use overlapping ranges, juju will fail | 13:34 |
| mup | Bug #1465695 changed: StorageAddSuite setup fails <ci> <intermittent-failure> <test-failure> <juju-core:Triaged> <juju-core db-log:Triaged> <https://launchpad.net/bugs/1465695> | 13:34 |
| TheMue | dimitern: so in this case using the address value as part of the tag seems to be fine | 13:35 |
| mup | Bug #1466087 opened: TestAllInstances fails <ci> <test-failure> <juju-core:Incomplete> <juju-core devices-api-maas:Triaged> <https://launchpad.net/bugs/1466087> | 13:35 |
| fwereade_ | dimitern, right? | 13:35 |
| dimitern | fwereade_, now it won't as that's not yet enforced, but I think it should anyway | 13:35 |
| fwereade_ | dimitern, you're saying that any organisation that has more than one network using 10.0. is Doing It Wrong? ;p | 13:36 |
| dimitern | fwereade_, the problem is with a given machine's single routing table overlapping ranges will lead to issues with routing | 13:36 |
| fwereade_ | dimitern, I don't care about machines | 13:36 |
| fwereade_ | dimitern, I care about tags being unique | 13:36 |
| TheMue | *lol* | 13:37 |
| dimitern | fwereade_, you can't have a machine with 2 NICs, each on the same overlapping (even not completely) rfc1918 subnets and expect it to work without extra care (static routes, metrics, etc.) | 13:37 |
| mup | Bug #1466087 changed: TestAllInstances fails <ci> <test-failure> <juju-core:Incomplete> <juju-core devices-api-maas:Triaged> <https://launchpad.net/bugs/1466087> | 13:38 |
| dimitern | fwereade_, right, what I'm proposing is not worse that what we have already in the face of multiple envs in the same state db | 13:38 |
| TheMue | dimitern: two machines, one nic each, one ip each, each in a different subnet in the same env, both having the same IP. possible? | 13:38 |
| fwereade_ | TheMue, thank you :) | 13:38 |
| dimitern | fwereade_, machine tags (or others) are only unique within their env | 13:38 |
| fwereade_ | dimitern, I know | 13:38 |
| fwereade_ | dimitern, I'm saying address tags should too | 13:39 |
| fwereade_ | dimitern, you seem to either be saying that they shouldn't, or that there are whole classes of networks we shoould refuse to model because it's a bit inconvenient re tag format | 13:39 |
| dimitern | I don't believe we should model all possible cases like this | 13:39 |
| dimitern | what's the use of having enclaves of machines like that in the same env? | 13:40 |
| dooferlad | dimitern, fwereade_, TheMue: https://docs.google.com/a/canonical.com/drawings/d/1UAZEYOi1LcBgDyokAdlJAFQuDxpOL98DeHpFT-q1HbU/edit?usp=sharing | 13:40 |
| dooferlad | I think this is easier with diagrams! | 13:40 |
| fwereade_ | dooferlad, good diagram, thank you | 13:41 |
| TheMue | dimitern: one enclave for one business service backend, one for another, and a public one as a frontend and routing between them (naive idea) | 13:41 |
| dimitern | dooferlad, great, thanks | 13:41 |
| fwereade_ | dimitern, I reject the notion that we should bake the impossibility of encoding that topology into juju forever | 13:41 |
| fwereade_ | dimitern, not doig it today is one thinng | 13:41 |
| * dimitern needs to think about this | 13:41 | |
| fwereade_ | dimitern, picking a tag format that renders it really damn hard to fix is another | 13:41 |
| TheMue | dooferlad: yeah, good one | 13:42 |
| dimitern | fwereade_, I totally get your point and agree the described scenario is not well modeled with what i'm suggesting | 13:42 |
| fwereade_ | dimitern, "address-<space>-<value>" might address my concerns but I'm still a bit iffy there too | 13:42 |
| dimitern | fwereade_, but I seem to recall in the model somewhere we said we won't allow that | 13:42 |
| fwereade_ | dimitern, yeah | 13:43 |
| fwereade_ | dimitern, I agree that it's fine not to do that yet | 13:43 |
| TheMue | fwereade_: dimitern: we always used meaningless IDs, like UUIDs, to make a record unique while the rest of the data can be double. if that's not wanted additional constraints help. | 13:44 |
| fwereade_ | dimitern, but picking a tag format that makes it harder to do in the future is a decision that's harder to undo than just "let's not do it this week/cycle/year" | 13:45 |
| TheMue | fwereade_: to the ID of an IP address simply should be a UUID, the tag "ipaddress-<id>" | 13:45 |
| dimitern | fwereade_, agreed | 13:45 |
| fwereade_ | TheMue, yeah, I'm totally comfortable with (not to mention keen on) opaque primary keys | 13:45 |
| TheMue | fwereade_: dimitern: so it doesn't care how we model networks and it is still identifyable | 13:45 |
| dimitern | fwereade_, TheMue, let's go with "ipaddress-<space>-<value>" the "space" part can be safely hardcoded to "default" I think | 13:46 |
| dimitern | at least initially | 13:46 |
| mup | Bug #1466087 opened: TestAllInstances fails <ci> <test-failure> <juju-core:Incomplete> <juju-core devices-api-maas:Triaged> <https://launchpad.net/bugs/1466087> | 13:47 |
| natefinch | I don't know what we're talking about, but I'm always +1 on UUID for primary IDs over some concatenated mess. | 13:48 |
| dimitern | dooferlad, have a look at http://reports.vapour.ws/releases/2784/job/run-unit-tests-precise-amd64/attempt/2970 btw - it seems devices-api-maas needs your fixes too | 13:48 |
| fwereade_ | dimitern, yeah, I think we do need a bit more justification for address-<space>-<value> | 13:48 |
| fwereade_ | dimitern, what are the advantages over address<opaque>? | 13:49 |
| dimitern | fwereade_, 1) a lot easier to implement, 2) more readable, 3) just as unique .. come to mind | 13:49 |
| TheMue | fwereade_: IMHO only better human readable, but that's all | 13:49 |
| TheMue | dimitern: why easier to implement? | 13:50 |
| dimitern | TheMue, also much easier to follow in the logs when debugging | 13:50 |
| natefinch | if you have to read IDs, you're doing something wrong | 13:50 |
| TheMue | hehe | 13:50 |
| fwereade_ | natefinch, +1 | 13:50 |
| TheMue | dimitern: I would log myAddress.String() giving a good readable string representation of my address | 13:51 |
| dimitern | TheMue, because what fwereade_ is suggesting means 1) add the hashed compound id to ipaddressesDoc, 2) make sure we set and update it as needed, 3) upgrade step to set it on existing ipaddressDocs | 13:51 |
| dimitern | I'm very good at following logs like that and figuring out what happened :P | 13:52 |
| TheMue | dimitern: sure, we act on existing data. | 13:52 |
| dimitern | and almost forgot - 4) a lot shorted in 90% of the cases for both IPv4 and IPv6 values | 13:53 |
| dimitern | shorter | 13:53 |
| * dimitern really needs to go now, might be back later | 13:54 | |
| * TheMue has to think about it too, but still feels a bit better with UUIDs | 13:55 | |
| fwereade_ | dimitern, you don't *have* to use a uuid, remember | 13:56 |
| fwereade_ | dimitern, other formats can be both unique and opaque | 13:56 |
| mup | Bug #1466100 opened: TestManageEnvironServesAPI fails <ci> <intermittent-failure> <test-failure> <juju-core:Incomplete> <juju-core db-log:Triaged> <https://launchpad.net/bugs/1466100> | 13:59 |
| TheMue | fwereade_: and even in full printed form (not as [16]byte) a UUID has 36 bytes. need a lot of addresses then to make a database sweat. | 14:03 |
| * TheMue is afk to swap location, bbiab | 14:05 | |
| fwereade_ | TheMue, indeed, "uuids are too big" is not generally an argument that impresses me much :) | 14:05 |
| alexisb | dooferlad, I will be a few minutes late | 14:26 |
| alexisb | but I will be there | 14:26 |
| natefinch | dpb1: we can't repro your bug https://bugs.launchpad.net/juju-core/+bug/1465307 have you found a way to reproduce it? | 14:29 |
| mup | Bug #1465307: 1.24.0: Lots of "agent is lost, sorry!" messages <blocker> <landscape> <regression> <juju-core:Incomplete> <https://launchpad.net/bugs/1465307> | 14:29 |
| dpb1 | natefinch: sorry, I worked on it in the afternoon that day and I got close but not there. I'm being pulled on something else. I'll circle back as soon as I can. For now, I totally understand the "incomplete" status on there. thanks. | 14:30 |
| natefinch | dpb1: cool, just wanted to make sure we were on the same page. | 14:36 |
| natefinch | ericsnow: I was wrong about that rsyslog bug, I do understand why it happened, though not precisely the best way to fix it | 14:37 |
| ericsnow | natefinch: k | 14:37 |
| natefinch | ericsnow: it was my fault - I changed where the rsysog certificate is (as stated by Menno in the comments of the bug). | 14:37 |
| ericsnow | natefinch: is it the way menn0 described it | 14:37 |
| natefinch | yep | 14:37 |
| ericsnow | natefinch: k | 14:37 |
| ericsnow | natefinch: I'll look into the fix | 14:37 |
| katco | natefinch: moving card for bug 1465307 to "DONE" | 14:38 |
| mup | Bug #1465307: 1.24.0: Lots of "agent is lost, sorry!" messages <blocker> <landscape> <regression> <juju-core:Incomplete> <https://launchpad.net/bugs/1465307> | 14:38 |
| natefinch | katco: huzzah | 14:38 |
| katco | natefinch: ty for following up | 14:38 |
| natefinch | katco: can you bring up the "process for proposing a new repo in github.com/juju/" in the leads meeting tonight? I'm hoping we can just post the process on a page on the wiki. | 14:42 |
| katco | natefinch: sure thing | 14:43 |
| natefinch | katco: thanks | 14:43 |
| katco | gsamfira: hey, were you looking at bug 1464470? | 14:47 |
| mup | Bug #1464470: A subordinate charm hook scheduled to run(but waiting for the principal charm hook to release the lock) goes to an error state after the principal charm hook triggers a reboot. <1.24> <1.25> <hooks> <juju> <reboot> <regression> <subordinate> <windows> <juju-core:Triaged> <juju-core | 14:47 |
| mup | 1.24:Triaged> <https://launchpad.net/bugs/1464470> | 14:47 |
| ericsnow | natefinch: do you have the revision of the change you made for the location of the certificate? | 14:48 |
| natefinch | ericsnow: I can find it | 14:57 |
| ericsnow | natefinch: thanks | 14:58 |
| natefinch | ericsnow: https://github.com/juju/juju/commit/3a6ebe0b6a24a8c5f80a7dbcb78937755540839e | 14:58 |
| jw4 | ericsnow: were you thinking github PR or reviewboard link? | 15:13 |
| ericsnow | jw4: either is fine, though I think putting the RB link also more clearly sends the message that the patch was reviewed :) | 15:14 |
| jw4 | ericsnow: cool :) | 15:14 |
| natefinch | ericsnow: got a minute to talk about the plugin package? | 15:17 |
| ericsnow | natefinch: sure | 15:17 |
| ericsnow | natefinch: moonstone? | 15:17 |
| natefinch | ericsnow: ya | 15:17 |
| voidspace | dimitern: ping | 15:19 |
| voidspace | dimitern: currently, the network interface information returned by PrepareContainerInterfaceInfo populates MACAddress with the NIC of the interface it allocated the address on | 15:19 |
| voidspace | dimitern: i.e. the host NIC MAC | 15:19 |
| voidspace | dimitern: so my change is a semantic change here. | 15:19 |
| voidspace | dimitern: as the method is documented to return "information for configuring networking on a container" I think that's ok | 15:20 |
| voidspace | dimitern: we always overwrite the MAC address anyway | 15:20 |
| voidspace | dimitern: but it might be slightly surprising to someone reading the code | 15:20 |
| dooferlad | TheMue/voidspace: could you take a quick look at this fix: https://github.com/dooferlad/juju/commit/aeb9acf964cbdb04abd957f49e2303a65cc5d240 | 15:21 |
| dooferlad | The rest of the change (http://reviews.vapour.ws/r/1941) has got a ship-it, but this caused the test bot to fail | 15:21 |
| voidspace | dooferlad: looking | 15:21 |
| voidspace | dooferlad: what was the failure? | 15:21 |
| dooferlad | The test is looking for a particular config change. The problem is the initial set up can generate a change on the channel it is watching. | 15:22 |
| voidspace | dooferlad: is this because the code is running in a goroutine and you don't want to use an assert? | 15:22 |
| dooferlad | no, an assert would be fine | 15:22 |
| voidspace | ah ok | 15:23 |
| voidspace | dooferlad: but you need to repeat the read on cfgObserver | 15:23 |
| voidspace | dooferlad: looks good to me | 15:23 |
| dooferlad | voidspace: yea, just need to keep reading cfgObserver until the expected change arrives, or time out. | 15:24 |
| voidspace | yep, LGTM | 15:24 |
| dooferlad | voidspace: thanks. Will push the go button again. | 15:24 |
| dooferlad | voidspace: and port to trunk. | 15:24 |
| dooferlad | voidspace: could you take a look at that same change, just this time is is a review for trunk. No changes vs the other branch. | 15:49 |
| dooferlad | http://reviews.vapour.ws/r/1958/ | 15:49 |
| dooferlad | TheMue: since voidspace is offline, could you take a look ^^ | 15:50 |
| voidspace | dooferlad: LGTM | 15:50 |
| dooferlad | voidspace: how I love IRC clients. You are apparently both offline and online. | 15:51 |
| dooferlad | voidspace: once that lands you probably want the changes in devices-api-maas. Hopefully it will result in less $$stupidtests$$ | 15:54 |
| dooferlad | voidspace: yell if you want a hand | 15:54 |
| voidspace | dooferlad: cool, thanks | 15:59 |
| voidspace | dooferlad: heh, my IP address changed just at that instance | 16:00 |
| voidspace | dooferlad: so I was briefly offline and reconnected | 16:00 |
| === natefinch_ is now known as natefinch | ||
| === liam_ is now known as Guest13658 | ||
| mup | Bug #1466152 opened: [RFE] log locks and other relevant information when jujud receives SIGUSR1 <juju-core:New> <https://launchpad.net/bugs/1466152> | 16:47 |
| rogpeppe1 | natefinch: just took a look at deputy. nice idea. you should probably document that Timeout isn't compatible with StdoutPipe or StdinPipe | 17:26 |
| natefinch | rogpeppe1: ahh yeah good point | 17:27 |
| natefinch | rogpeppe1: ironically, we're probably not going to be using it for what I wrote it for, but I figured we run enough executables, we might want a consistent way to give them a timeout.... and get better errors than we usually get running commands (exit code 1 or whatever it is) | 17:29 |
| rogpeppe1 | natefinch: yeah, i think it's a reasonable idea | 17:29 |
| natefinch | rogpeppe1: I'm sure it needs some work, it's just an initial draft. | 17:30 |
| rogpeppe1 | natefinch: tbh i'm not that keen on the Option thing. it's cute, but i'd actually prefer to see an explicit options struct | 17:32 |
| rogpeppe1 | natefinch: also, i think you've got a potential race condition | 17:34 |
| rogpeppe1 | natefinch: not sure of a decent way to work around it though | 17:35 |
| rogpeppe1 | natefinch: i think you probably need to allow only one of either stderr or stdout as error | 17:36 |
| natefinch | rogpeppe1: I'd thought about what happens if you use both stderr and stdout as errors.... allowing only one is probably better | 17:40 |
| natefinch | rogpeppe1: and you may be right about the option thing. | 17:40 |
| mup | Bug #1466167 opened: debug-hooks no longer works with 1.24-beta6 <juju-core:New> <https://launchpad.net/bugs/1466167> | 17:47 |
| katco | wwitzel3: ericsnow: natefinch: do you guys need anything? | 18:36 |
| ericsnow | katco: I'm good for now | 18:37 |
| natefinch | ericsnow: nope, I'm good | 18:42 |
| wwitzel3 | katco: a new nasal passage | 18:49 |
| katco | wwitzel3: hm. | 18:50 |
| katco | wwitzel3: i have a hammer, a phillips screw driver, and a lawyer's phone number. | 18:50 |
| wwitzel3 | katco: no duct tape? sounds sketchy | 18:51 |
| katco | wwitzel3: i assure you, the screw driver is the highest quality stainless steel | 18:52 |
| katco | wwitzel3: it shouldn't stain my screwdriver at all | 18:52 |
| wwitzel3 | well in that case ... | 18:54 |
| perrito666 | wwitzel3: runny nose? | 19:02 |
| === kadams54 is now known as kadams54-away | ||
| === kadams54-away is now known as kadams54 | ||
| === kadams54 is now known as kadams54-away | ||
| === kadams54-away is now known as kadams54 | ||
| === kadams54 is now known as kadams54-away | ||
| === kadams54-away is now known as kadams54 | ||
| === kadams54 is now known as kadams54-away | ||
| katco | anastasiamac: ping | 21:46 |
| * perrito666 wonders what he did this time to have reviewboard ignore him | 22:31 | |
| anastasiamac | katco: pong? | 22:39 |
| katco | anastasiamac: hey got time for a chat? | 22:39 |
| anastasiamac | katco: sure. tanzanite? | 22:40 |
| katco | anastasiamac: https://plus.google.com/hangouts/_/canonical.com/moonstone?authuser=1 | 22:40 |
| katco | anastasiamac: don't have the link for tanzanite anymore =/ | 22:40 |
| anastasiamac | omw | 22:40 |
| perrito666 | katco: that is cruel | 22:40 |
| alexisb | katco, word on the street is anastasiamac and wallyworld will be looking for tanzanite when they are next in Capetown SA | 22:48 |
| alexisb | katco, you will have to one up them by getting moonstone in Missouri | 22:48 |
| perrito666 | alexisb: you know, there are easier way to do things :p http://www.ebay.com/sch/i.html?_from=R40&_trksid=p2050601.m570.l1313.TR0.TRC0.H0.Xtanzanite.TRS0&_nkw=tanzanite&_sacat=0 | 22:50 |
| katco | alexisb: lol i'll have to do that :) | 22:52 |
| katco | alexisb: all jokes aside, i find moonstones to be prettier than tanzanite :) | 22:52 |
| anastasiamac | alexisb: wallyworld will be looking for tanzanite in SA. anastasiamac will twidlling her thumbs in Aus :D | 22:53 |
| anastasiamac | katco: combine the two and u'll get an even better value :D | 22:53 |
| katco | anastasiamac: haha :D | 22:54 |
| wallyworld | ebay? you'll end up buying purple glass | 22:54 |
| wallyworld | a jeweller friend of mine has so many customers who bring in rings bought off ebay that are just straight out fakes | 22:54 |
| perrito666 | wallyworld: better? http://www.amazon.com/s?ie=UTF8&field-keywords=tanzanite&index=blended&link_code=qs&tag=wwwcanoniccom-20 | 22:55 |
| wallyworld | yes :-) | 22:55 |
| perrito666 | ow, interesting, I had not noticed the tag= part | 22:56 |
| wallyworld | did you use a scope? | 22:57 |
| perrito666 | wallyworld: nope, my browser amaz<tab> | 22:57 |
| perrito666 | my browser being chrome | 22:58 |
| perrito666 | that quick search might be rigged ot do the same | 22:59 |
| === kadams54 is now known as kadams54-away | ||
| anastasiamac | alexisb: running a bit late...will ping after standup.. | 23:30 |
| alexisb | anastasiamac, ack | 23:30 |
| anastasiamac | alexisb: m grabbing a drink (& coffeeeee) and will b there! tyvm for waiting :D | 23:33 |
| thumper | wallyworld: do you have a few minutes to talk about leases? | 23:55 |
| thumper | axw: you around? | 23:57 |
| wallyworld | thumper: give me 5? | 23:59 |
| thumper | ack | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!