[00:20] ericsnow: ping [00:20] wwitzel3: hey [00:24] 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:25] * fwereade_ bed [01:02] mwhudson i have an email from the go pm who's asking for contact details for the go packaging maintainers [01:02] i'm tempted to just give him your name [01:02] that is, unless you can find someone else for me to foist this on === kadams54 is now known as kadams54-away [01:44] davecheney: in ubuntu? me and doko i guess would be a good start [01:45] mwhudson: i guess that is my first question [01:45] don't ubuntu follow debian [01:45] i wonder if I should send him to the debian folks first [01:45] the debain folks are paultag and tianon [01:45] tainon [01:45] i think I know him/them [01:46] as usual when being asked a question the first response is "what are you trying to achieve" [01:46] jason is a pm [01:46] he's used to not getting a straight answer [01:48] ah, i think ian cc:ed him on the mail he sent me earlier today [01:48] jason b [01:48] yeah, all roads lead back to product managment [01:50] yeah === anthonyf is now known as Guest33778 [01:58] thumper: 5 min chat? [01:59] wallyworld: sure [02:22] thumper: https://github.com/juju/testing/pull/71 [02:55] thumper: i have a problem [02:55] lucky(~/src/github.com/juju/juju) % go install -v ./... [02:55] ../../../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] juju depends ont he charmstore [02:55] the charmstore depends on gopkg.in/check.v1 [02:55] and I believe rog will block any landing into that repo [02:55] sure... [02:56] but since we aren't running tests against it, why is it a problem? [02:56] i *think* this will be ok [02:56] yes, that [02:56] but it might also be a blocker [02:56] i need to point this out [02:57] in theory, gocheck should end up being in any non test dependencies right? [02:57] are we using any *testing packages from the charm package? [02:57] ... [02:57] mockstore? [02:57] yes [02:57] so if that package provides checkers that we're using [02:57] * thumper grunts [02:57] we're boned [02:58] if it's just using the types [02:58] we're probably ok [02:58] ok [02:58] let me know [02:58] * thumper goes to make coffee [02:59] we might still be ok, i think gocheck uses an interface [02:59] or reflection to figure out which of the arguments are checkers [02:59] and there is no requirement that a cheker implemetns an interface [03:00] or embeds a checker base type [03:00] so this might be ok [03:00] if a bit ropey [03:00] 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] "gopkg.in/check.v1".Checker does not implement "github.com/juju/check".Checker (wrong type for Info method) [03:00] have Info() *"gopkg.in/check.v1".CheckerInfo [03:00] want Info() *"github.com/juju/check".CheckerInfo [03:00] opps, spoke too soon [03:02] ...and that's why you avoid using custom types in interfaces [03:02] yup [03:03] thumper: nope [03:03] i'm screwed [03:03] we have a gordian knot between juju/juju, juju/testing and check.v1 and charm.v5 [03:04] i cannot complete this change unless the charmstore owners agree to also switch to our fork [03:04] luckily they work for us, so that should not be that hard? Maybe? [03:10] thumper: i'm shelving this card, I cannot complete it at thsi time [03:24] davecheney: ack [03:26] man... [03:26] that seems screwed up === kadams54 is now known as kadams54-away [04:06] thumper: what do you want to do ? [04:07] davecheney: I'm unclear as to why the checker is using gopkg.in checker... [04:08] its a suite [04:08] check/v.5 uses suites from juju/testing [04:09] juju/testing expects a "github.com/juju/check".Checker, this is a gc.C [04:09] check.v5 suites expects a "gopkg.in/check.v1".Checker gc.c [04:09] check.v5 suites expects a "gopkg.in/check.v1".Checker gc. [04:09] C [04:11] hmm, that wasn't quite right [04:11] some of the names of the gocheck types aren't right in that explanation [04:11] but the effect is the same [04:13] 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:14] waigani: do you gave time for a chat about simplestreams branch? [04:14] wallyworld: yep sure [04:14] https://plus.google.com/hangouts/_/canonical.com/tanzanite-stand [04:16] davecheney: ah poo [04:17] davecheney, natefinch: can we change juju/check to not expect package specific types? [04:17] however [04:17] natefinch: is gc.C a type or an internface [04:17] that'll only work for checkers [04:17] thumper: the problem is suites [04:17] not the C [04:17] right? [04:17] yeah [04:17] * thumper gets it [04:18] well, there are several problems [04:18] as frustrating as it is [04:18] even if we could fix juju/check [04:18] charm.v5 is using check.v1 as it's definition of gc.C passed to suites [04:18] and juiju/testing is using our fork [04:18] with the charms.v5 using gopkg.in, it means it can't use us [04:18] * thumper nods [04:18] double poo [04:18] TL;DR, everyone has to upgrade [04:19] this is go types done wrong IMO [04:19] davecheney: I think the fastest way to progress would be to provide the upstream gocheck with the exact patch we want [04:20] and apply pressure to get it in [04:20] i agree [04:20] did that other Chris fella respond to the PR comment? [04:22] an aside should be for us to learn from this when designing bits of code [04:22] nope [04:22] thumper: i agree [04:23] but there is no value in having that conversation on IRC [04:23] it will be lost [04:23] please take it to the juju-dev mailing list [04:24] can you propose a PR to gocheck upstream that has the fix we need, based on the work Chris did? [04:24] davecheney: ? [04:24] yes, on it [04:26] cheers [04:41] 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. [05:01] thumper: oh, THATS's right [05:01] the gocheck tests dont pass [05:01] i forgot that [05:01] oh well [05:01] fuck it [05:01] WT actual F? [05:01] yeah, i logged that bug a year or so ago [05:02] alst time I made a fix to a checker [05:02] well, maybe i logged a bug [05:05] wallyworld: http://reviews.vapour.ws/r/1948/ [05:05] wallyworld: sorry [05:05] looking [05:05] was after waigani [05:06] but he isn't here [05:06] w-TAB [05:06] fail [05:06] wallyworld: I can get someone else that is more familar with the code if you like [05:06] thumper: maybe that's better? [05:07] i 'm about to go do school pickup [05:07] wallyworld: sure, np [05:17] git push --set-upstream origin fix-data-race-on-status [05:17] fatal: https://gopkg.in/check.v1/info/refs not valid: is this a git repository? [05:18] reason 2^63 why I don't like gopkg.in [05:18] "oh,you downloaded this repo, but I'm not going to tell you where origin _really_ is" [05:19] thumper: https://github.com/go-check/check/pull/44 [05:19] davecheney: thanks [05:19] confirmed the race in worker/provisioner is fixed [05:19] awesome [05:49] laters peeps [07:04] 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:09] wallyworld: looking [07:09] ty [07:14] wallyworld: when is a unit in "maintenance"? that's when the machine is being provisioned? [07:15] axw: Unknown during allocation [07:15] maintenance during install hook [07:15] door, be back in a sec [07:16] wallyworld, hey [07:16] wallyworld, re bug 1464616 we talked about yesterday [07:16] Bug #1464616: destroy-machine --force no longer forceably destroys machine

[07:17] dimitern: http://reviews.vapour.ws/r/1947/ [07:17] wallyworld, I couldn't figure out what might be the issue without logs, but it seems you've got it [07:17] axw is looking [07:17] yeah :-) [07:17] wallyworld, awesome :) [07:20] 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:22] wallyworld, reviewed [07:22] ty [07:25] 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] wallyworld: it could also be in error unrelated to installing [07:26] wallyworld: so not really [07:26] could be but the other checks imit it to installing [07:26] i'll change the name [07:26] wallyworld: the other asserts do, but that means you have to know about the asserts together in context [07:26] that is true [07:27] 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:28] so the worker no longer has to track dependencies [07:28] simplicity is nice [07:28] sounds better [07:29] wallyworld, axw, can a subordinate have actions of its own? [07:30] fwereade_, ^^ [07:30] not sure tbh [07:30] I'm thinking of creating a simple subordinate charm that has actions returning various networking settings - iptables, routes, etc. [07:32] dimitern: sorry no idea [07:33] no worries, will rtfm :) [07:34] dimitern: i don't understand the code review comment about "ErrAborted handling below" [07:34] wallyworld, well, any txn.Op with an Assert can trigger ErrAborted [07:35] sure. which one are you referring to? [07:35] the unitAgentAllocatingOrInstalling [07:35] that's the Assert, sorry i mean which ErrAborted handler? [07:36] * dimitern actually looks at the full source of that method [07:36] it's all takne care of AFAIK. the txn will just be retried as normal [07:36] either the unit was not installed or it was when the txn was started [07:37] it's called from line 289 func (u *Unit) Destroy() (err error) [07:38] wallyworld, yeah, I can't see anything wrong with it off hand, but I'd recommend fwereade_ having a look [07:38] ta [07:44] * dimitern now really likes the idea of multi-series charms in the face of cross-series CI tests [07:48] jw4, are you around by any chance? [07:57] 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 === mgz is now known as mgz_ [09:01] voidspace, jam, fwereade_, standup? [09:01] dimitern: omw [09:40] Bug #1466011 opened: apiserver tests fail on windows

[09:58] wallyworld, I'm afraid http://reviews.vapour.ws/r/1947/ does not lgtm, does my comment make sense? [09:59] wallyworld, I think you probably want to look at (*State).obliterateUnit [10:01] voidspace: success? [10:02] 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:03] dooferlad: nope [10:03] lazyPower, owww :( [10:03] dooferlad: using dhcp seems to overwrite the dns-nameservers option [10:03] dooferlad: using static (with the correct values) just plain doesn't work [10:04] fwereade_: that awkward moment i wish we were still git based so i could have recovered [10:04] dooferlad: I suspect it's a bad interaction with the bridging config for br0 [10:04] lazyPower, haha :( [10:04] lazyPower, you *should* be able to stop a pending upgrade that hasn't started yet by upgrading back to the original [10:05] voidspace: do you actually need br0? [10:05] 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] exited the hook thinking "Yes, now i can sync back" [10:05] doh [10:05] lazyPower, bad luck :( [10:05] indeed [10:05] dooferlad: I'll try getting rid of it and see what breaks :-) [10:05] voidspace: ahh, fun with networking :-) [10:06] it was too late, by the time upgrade_charm was trapped in tmux, i knew i was taking a stroll through "trololol" land [10:17] dooferlad: apparently I do need it [10:17] dooferlad: without it, no network [10:17] dooferlad: I'll dig into where it comes from [10:18] dooferlad: statically configuring br0 doesn't work - it has a bunch of bridge options set [10:18] dooferlad: http://pastebin.ubuntu.com/11729739/ [10:20] dooferlad: it's to do with kvm (br0) [10:20] dooferlad: docs here imply I ought to be able to statically configure [10:20] https://help.ubuntu.com/community/KVM/Networking [10:24] dooferlad: I was missing gateway before which is why I think statically configuring br0 didn't work [10:26] voidspace: oh, yes, you will need that! [10:31] dooferlad, you've got a review; btw add an Overhead card for it please [10:31] dooferlad: but dns-nameservers seems to be ignored now [10:32] dimitern: thanks, already acting on it [10:32] dimitern: overhead card? [10:33] dooferlad, for that PR [10:34] dimitern: don't all PRs go through review though? [10:34] dooferlad, i'd like to track all PRs that land with cards [10:34] dooferlad, yes, indeed [10:35] dooferlad, we're doing a lot of overhead tasks and a few actually planned, so I'd like to keep track of this [10:40] dooferlad: it seems like I need to have the dns-nameservers section in eth0 not in br0 [10:40] voidspace: oh, interesting! [10:40] dig now reports the correct nameserver [10:41] doesn't *seem* to have improved connection speed [10:41] I'll try running the tests though [10:41] if you "dig nanosheep.org" or some other server you haven't looked at recently, does it take long? [10:41] voidspace: ^^ [10:42] dooferlad: that returned quickly enough [10:42] I think this means that dns isn't the issue [10:43] voidspace: is quickly sub 200ms? From 127.0.0.1? If so, yea, that looks fine. [10:43] dooferlad: hmm... 599ms [10:44] cmd/juju tests are no quicker [10:44] voidspace: http://paste.ubuntu.com/11729870/ [10:44] :-/ [10:45] voidspace: ping response time from an upstream DNS server? [10:46] dooferlad: for lots of other sites I'm getting really quick responses [10:47] voidspace: it has to be a site you haven't looked up or you will get a cached response [10:47] dooferlad: cached ones return in 0ms :-) [10:47] voidspace: I get 1ms cached responses [10:47] dooferlad: response times for other domains really vary [10:47] voidspace: could just be a one-off slow response [10:47] yeah [10:48] OK, other stuff. Do other machines on your network have the same slow browsing problem? [10:48] no [10:49] anything unusual about that machines network connection? Could you try another cable/ [10:49] ? [10:49] the connection speed is fine [10:50] and that wouldn't affect locally running tests [10:50] indeed [10:50] it's not slow browsing, it's slow initial connection [10:50] (which really sounds like dns but I'm fairly sure isn't now) [10:50] and that particular problem started after we changed iptables [10:50] I might try removing those rules to see if it changes again [10:50] sounds like a plan [10:51] I don't *know* that cmd/juju got slow then, it may just be a coincidence [10:51] so removing them and trying again will let me know [10:51] I might go back to some real work for a bit first [10:51] 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:54] dimitern: review responded to. [10:54] dooferlad, cheers, looking [10:55] dooferlad, let's drop the second failing StopsInstances() call from that test then [10:56] 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] 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] dimitern: that is because the first thing it does is try to delete some files and directories, then it calls lxc-destroy [10:57] dimitern: so the first error it returns it just what comes back from those delete calls [10:57] dooferlad, right, that's seems wrong [10:57] dimitern: calling lxc-destroy first would seem sane to me, then tidying up. [10:58] dooferlad, yeah, let's go back to this at some point [10:58] dimitern: on the 1.24 branch, I was using AssertFileContains rather than AssertFileContains because I figured having both functions was probably overkill. [10:58] dimitern: was going to ask about removing AssertFileContains [10:59] 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. [11:03] 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 === kadams54 is now known as kadams54-away [11:59] 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? [12:00] waigani, axw: my gut feeling is "difficult"? [12:00] jam, sorry, 5 mins [12:01] fwereade_: k [12:01] alexisb isn't here yet either [12:01] fwereade_: actually I don't think it would be that bad [12:02] fwereade_: menno and I worked on it originally when we migrated the collections to multi envs [12:02] menno wrote the original collections.go and would be most familiar with it [12:05] waigani, yeah, I ask because you're online ;p [12:06] 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:07] 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:47] dimitern: probably too late, but you pinged? === anthonyf is now known as Guest64410 [12:48] jw4, no worries; I had some questions re actions, but I figured it out from the docs :) [12:48] dimitern: cool [12:53] 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] dimitern: even if it's a nice component for entities it's more code than the direct implementation [12:54] TheMue, that's a good question [12:54] dimitern: or alternatively make the IPAddress to a valid entity too (with adding an according kind to juju/names). [12:54] TheMue, which reminds me we don't have tags for addresses [12:55] dimitern: reading a bit of remover code and how it works on entities it's really a nice mixin [12:55] dimitern: exactly [12:56] TheMue, let's do this - propose a juju/names PR that introduces IPAddressTag [12:56] TheMue, this should be a separate, overhead card btw [12:57] TheMue, tags need a kind (used as prefix), let's use "ip-" [12:57] 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:58] dimitern: OK, will add the tag as quick one and add it with a second PR to the remover [12:58] 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 :) === kadams54 is now known as kadams54-away [12:59] TheMue, yeah, it's easy to do the juju/names PR first [12:59] dimitern: it's more an effect of visibility === kadams54-away is now known as kadams54 [13:00] * TheMue loves DVCSes for simple switching between branches [13:00] TheMue, hmm.. but I can see a problem with address tags [13:01] 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] fwereade_, ping [13:01] dimitern, pong [13:02] dimitern: ic [13:02] fwereade_, hey, so it's high time to introduce tags for ip addresses [13:02] dimitern: could we by this way find a better name than just "value"? [13:02] fwereade_, but since it's a struct, just using the Value is not loseless wrt transforming from tag to address [13:03] dimitern: could we by this way find a better name than just "value"? [13:03] ouch, twice [13:03] TheMue, yeah, I'm thinking of "ip----" [13:04] fwereade_, ^^ ? or perhaps "---" e.g. ipv4-public-juju-private-10.3.2.1 [13:04] dimitern: value is the address itself in standard notation, isn't it? [13:05] TheMue, yeah, but it also holds extra metadata about its scope, type, and network [13:05] it can even be a hostname [13:06] dimitern, that feels wrong [13:06] dimitern, having all that jammed into a tag [13:06] fwereade_, the unique _id for ipaddressesC is DocID, which can be used in a tag, but it'll contain the envuuid [13:07] 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] dimitern, all that metadata is, well, metadata [13:09] 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] 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] dimitern, right [13:09] dooferlad, looking [13:09] fwereade_, or "ip-localhost" for that matter looks weird [13:10] dimitern, so the reason to jam all that into the tag is for uniqueness? [13:11] fwereade_, use a single tag type and multiple sub-kinds? "ip-" ? e.g. "iphostname-localhost" or (iphost-?) "ipv4-10.0.3.1", "ipv6-2001:db8::1" [13:11] dimitern, if those bits are all immutable per address (which I imagine they are), how about `address-`? [13:11] that feels strange [13:11] fwereade_, not for uniqueness, as the value + envuuid is the _id, so it's unique, but for better carrying out the original intent [13:12] fwereade_, hmm we need to know what to hash back on FindEntity though [13:12] 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] what about "ip-" and then that just gives you what doc you have? [13:12] dimitern, well, you store the hash in the doc and look up by that, right? [13:13] jam, indeed [13:13] * jam disappears to go shopping [13:13] fwereade_, just for the sake of having a sha256 hash in the tags? [13:13] dimitern, more for the sake of not jamming a whole struct into a field [13:14] so we could take a meaningless but unique uuid too [13:14] fwereade_, hmm [13:14] TheMue, indeed, equally [13:14] dimitern, opaque identifiers are good things [13:14] fwereade_, I'd rather hash the DocID and use that - it's already in the doc and can be found [13:14] dimitern, sure, that sounds fine too [13:15] +1 [13:15] fwereade_, address- [13:15] wallyworld: ignoring unknown tools metadata: http://reviews.vapour.ws/r/1955/ [13:15] dimitern: address- [13:15] dimitern, that sgtm, you'll still have to store the hashed docid to look it up :) [13:16] Bug #1465695 changed: StorageAddSuite setup fails

[13:17] or event better ipaddress-, ipaddress represents the real type (if we have other addresses in the future, like mac-address), docID is already in the document [13:17] fwereade_, yeah, or perhaps Find all for the current env and iterate? :) [13:18]