wwitzel3ericsnow: ping00:20
ericsnowwwitzel3: hey00: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 it00:24
* fwereade_ bed00:25
davecheney mwhudson i have an email from the go pm who's asking for contact details for the go packaging maintainers01:02
davecheneyi'm tempted to just give him your name01:02
davecheneythat is, unless you can find someone else for me to foist this on01:02
=== kadams54 is now known as kadams54-away
mwhudsondavecheney: in ubuntu?  me and doko i guess would be a good start01:44
davecheneymwhudson: i guess that is my first question01:45
davecheneydon't ubuntu follow debian01:45
davecheneyi wonder if I should send him to the debian folks first01:45
mwhudsonthe debain folks are paultag and tianon01:45
davecheneyi think I know him/them01:45
mwhudsonas usual when being asked a question the first response is "what are you trying to achieve"01:46
davecheneyjason is a pm01:46
davecheneyhe's used to not getting a straight answer01:46
mwhudsonah, i think ian cc:ed him on the mail he sent me earlier today01:48
davecheneyjason b01:48
davecheneyyeah, all roads lead back to product managment01:48
=== anthonyf is now known as Guest33778
wallyworldthumper: 5 min chat?01:58
thumperwallyworld: sure01:59
davecheneythumper: https://github.com/juju/testing/pull/7102:22
davecheneythumper: i have a problem02:55
davecheneylucky(~/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
davecheneyjuju depends ont he charmstore02:55
davecheneythe charmstore depends on gopkg.in/check.v102:55
davecheneyand I believe rog will block any landing into that repo02:55
thumperbut since we aren't running tests against it, why is it a problem?02:56
davecheneyi *think* this will be ok02:56
davecheneyyes, that02:56
davecheneybut it might also be a blocker02:56
davecheneyi need to point this out02:56
thumperin theory, gocheck should end up being in any non test dependencies right?02:57
thumperare we using any *testing packages from the charm package?02:57
davecheneyso if that package provides checkers that we're using02:57
* thumper grunts02:57
davecheneywe're boned02:57
davecheneyif it's just using the types02:58
davecheneywe're probably ok02:58
thumperlet me know02:58
* thumper goes to make coffee02:58
davecheneywe might still be ok, i think gocheck uses an interface02:59
davecheneyor reflection to figure out which of the arguments are checkers02:59
davecheneyand there is no requirement that a cheker implemetns an interface02:59
davecheneyor embeds a checker base type03:00
davecheneyso this might be ok03:00
davecheneyif a bit ropey03:00
davecheneyworker/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".CheckerInfo03:00
davecheney                want Info() *"github.com/juju/check".CheckerInfo03:00
davecheneyopps, spoke too soon03:00
natefinch...and that's why you avoid using custom types in interfaces03:02
davecheneythumper: nope03:03
davecheneyi'm screwed03:03
davecheneywe have a gordian knot between juju/juju, juju/testing and check.v1 and charm.v503:03
davecheneyi cannot complete this change unless the charmstore owners agree to also switch to our fork03:04
natefinchluckily they work for us, so that should not be that hard?  Maybe?03:04
davecheneythumper: i'm shelving this card, I cannot complete it at thsi time03:10
thumperdavecheney: ack03:24
thumperthat seems screwed up03:26
=== kadams54 is now known as kadams54-away
davecheneythumper: what do you want to do ?04:06
thumperdavecheney: I'm unclear as to why the checker is using gopkg.in checker...04:07
davecheneyits a suite04:08
davecheneycheck/v.5 uses suites from juju/testing04:08
davecheneyjuju/testing expects a "github.com/juju/check".Checker, this is a gc.C04:09
davecheneycheck.v5 suites expects a "gopkg.in/check.v1".Checker gc.c04:09
davecheneycheck.v5 suites expects a "gopkg.in/check.v1".Checker gc.04:09
davecheneyhmm, that wasn't quite right04:11
davecheneysome of the names of the gocheck types aren't right in that explanation04:11
davecheneybut the effect is the same04:11
natefinchbecause 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
wallyworldwaigani: do you gave time for a chat about simplestreams branch?04:14
waiganiwallyworld: yep sure04:14
thumperdavecheney: ah poo04:16
thumperdavecheney, natefinch: can we change juju/check to not expect package specific types?04:17
davecheneynatefinch: is gc.C a type or an internface04:17
thumperthat'll only work for checkers04:17
davecheneythumper: the problem is suites04:17
thumpernot the C04:17
* thumper gets it04:17
davecheneywell, there are several problems04:18
thumperas frustrating as it is04:18
thumpereven if we could fix juju/check04:18
davecheneycharm.v5 is using check.v1 as it's definition of gc.C passed to suites04:18
davecheneyand juiju/testing is using our fork04:18
thumperwith the charms.v5 using gopkg.in, it means it can't use us04:18
* thumper nods04:18
thumperdouble poo04:18
davecheneyTL;DR, everyone has to upgrade04:18
thumperthis is go types done wrong IMO04:19
thumperdavecheney: I think the fastest way to progress would be to provide the upstream gocheck with the exact patch we want04:19
thumperand apply pressure to get it in04:20
davecheneyi agree04:20
thumperdid that other Chris fella respond to the PR comment?04:20
thumperan aside should be for us to learn from this when designing bits of code04:22
davecheneythumper: i agree04:22
davecheneybut there is no value in having that conversation on IRC04:23
davecheneyit will be lost04:23
davecheneyplease take it to the juju-dev mailing list04:23
thumpercan you propose a PR to gocheck upstream that has the fix we need, based on the work Chris did?04:24
thumperdavecheney: ?04:24
davecheneyyes, on it04:24
waiganianastasiamac: 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
davecheneythumper: oh, THATS's right05:01
davecheneythe gocheck tests dont pass05:01
davecheneyi forgot that05:01
davecheneyoh well05:01
davecheneyfuck it05:01
thumperWT actual F?05:01
davecheneyyeah, i logged that bug a year or so ago05:01
davecheneyalst time I made a fix to a checker05:02
davecheneywell, maybe i logged a bug05:02
thumperwallyworld: http://reviews.vapour.ws/r/1948/05:05
thumperwallyworld: sorry05:05
thumperwas after waigani05:05
thumperbut he isn't here05:06
thumperwallyworld: I can get someone else that is more familar with the code if you like05:06
wallyworldthumper: maybe that's better?05:06
wallyworldi 'm about to go do school pickup05:07
thumperwallyworld: sure, np05:07
davecheneygit push --set-upstream origin fix-data-race-on-status05:17
davecheneyfatal: https://gopkg.in/check.v1/info/refs not valid: is this a git repository?05:17
davecheneyreason 2^63 why I don't like gopkg.in05:18
davecheney"oh,you downloaded this repo, but I'm not going to tell you where origin _really_ is"05:18
davecheneythumper: https://github.com/go-check/check/pull/4405:19
thumperdavecheney: thanks05:19
davecheneyconfirmed the race in worker/provisioner is fixed05:19
thumperlaters peeps05:49
wallyworldaxw: 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
axwwallyworld: looking07:09
axwwallyworld: when is a unit in "maintenance"? that's when the machine is being provisioned?07:14
wallyworldaxw: Unknown during allocation07:15
wallyworldmaintenance during install hook07:15
wallyworlddoor, be back in a sec07:15
dimiternwallyworld, hey07:16
dimiternwallyworld, re bug 1464616 we talked about yesterday07:16
mupBug #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
wallyworlddimitern: http://reviews.vapour.ws/r/1947/07:17
dimiternwallyworld, I couldn't figure out what might be the issue without logs, but it seems you've got it07:17
wallyworldaxw is looking07:17
wallyworldyeah :-)07:17
dimiternwallyworld, awesome :)07:17
wallyworldaxw: 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 status07:20
* axw nods07:20
dimiternwallyworld, reviewed07:22
wallyworldaxw: 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 / tools07:25
axwwallyworld: it could also be in error unrelated to installing07:25
axwwallyworld: so not really07:26
wallyworldcould be but the other checks imit it to installing07:26
wallyworldi'll change the name07:26
axwwallyworld: the other asserts do, but that means you have to know about the asserts together in context07:26
wallyworldthat is true07:26
axwwallyworld: 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 dependents07:27
axwso the worker no longer has to track dependencies07:28
wallyworldsimplicity is nice07:28
wallyworldsounds better07:28
dimiternwallyworld, axw, can a subordinate have actions of its own?07:29
dimiternfwereade_, ^^07:30
wallyworldnot sure tbh07:30
dimiternI'm thinking of creating a simple subordinate charm that has actions returning various networking settings - iptables, routes, etc.07:30
axwdimitern: sorry no idea07:32
dimiternno worries, will rtfm :)07:33
wallyworlddimitern: i don't understand the code review comment about "ErrAborted handling below"07:34
dimiternwallyworld, well, any txn.Op with an Assert can trigger ErrAborted07:34
wallyworldsure. which one are you referring to?07:35
dimiternthe unitAgentAllocatingOrInstalling07:35
wallyworldthat's the Assert, sorry i mean which ErrAborted handler?07:35
* dimitern actually looks at the full source of that method07:36
wallyworldit's all takne care of AFAIK. the txn will just be retried as normal07:36
wallyworldeither the unit was not installed or it was when the txn was started07:36
wallyworldit's called from line 289 func (u *Unit) Destroy() (err error)07:37
dimiternwallyworld, yeah, I can't see anything wrong with it off hand, but I'd recommend fwereade_ having a look07:38
* dimitern now really likes the idea of multi-series charms in the face of cross-series CI tests07:44
dimiternjw4, are you around by any chance?07:48
wallyworldjam: 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 start07:57
=== mgz is now known as mgz_
dimiternvoidspace, jam, fwereade_, standup?09:01
voidspacedimitern: omw09:01
mupBug #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).obliterateUnit09:59
dooferladvoidspace: success?10:01
lazyPoweromg 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
voidspacedooferlad: nope10:03
fwereade_lazyPower, owww :(10:03
voidspacedooferlad: using dhcp seems to overwrite the dns-nameservers option10:03
voidspacedooferlad: using static (with the correct values) just plain doesn't work10:03
lazyPowerfwereade_: that awkward moment i wish we were still git based so i could have recovered10:04
voidspacedooferlad: I suspect it's a bad interaction with the bridging config for br010: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 original10:04
dooferladvoidspace: do you actually need br0?10:05
lazyPowerfwereade_: my changes were remote, not local. so i had no backup and forgot i sent the upgrade-charm like an hour prior.10:05
lazyPowerexited the hook thinking "Yes, now i can sync back"10:05
fwereade_lazyPower, bad luck :(10:05
voidspacedooferlad: I'll try getting rid of it and see what breaks :-)10:05
dooferladvoidspace: ahh, fun with networking :-)10:05
lazyPowerit was too late, by the time upgrade_charm was trapped in tmux, i knew i was taking a stroll through "trololol" land10:06
voidspacedooferlad: apparently I do need it10:17
voidspacedooferlad: without it, no network10:17
voidspacedooferlad: I'll dig into where it comes from10:17
voidspacedooferlad: statically configuring br0 doesn't work - it has a bunch of bridge options set10:18
voidspacedooferlad: http://pastebin.ubuntu.com/11729739/10:18
voidspacedooferlad: it's to do with kvm (br0)10:20
voidspacedooferlad: docs here imply I ought to be able to statically configure10:20
voidspacedooferlad: I was missing gateway before which is why I think statically configuring br0 didn't work10:24
dooferladvoidspace: oh, yes, you will need that!10:26
dimiterndooferlad, you've got a review; btw add an Overhead card for it please10:31
voidspacedooferlad: but dns-nameservers seems to be ignored now10:31
dooferladdimitern: thanks, already acting on it10:32
dooferladdimitern: overhead card?10:32
dimiterndooferlad, for that PR10:33
dooferladdimitern: don't all PRs go through review though?10:34
dimiterndooferlad, i'd like to track all PRs that land with cards10:34
dimiterndooferlad, yes, indeed10:34
dimiterndooferlad, we're doing a lot of overhead tasks and a few actually planned, so I'd like to keep track of this10:35
voidspacedooferlad: it seems like I need to have the dns-nameservers section in eth0 not in br010:40
dooferladvoidspace: oh, interesting!10:40
voidspacedig now reports the correct nameserver10:40
voidspacedoesn't *seem* to have improved connection speed10:41
voidspaceI'll try running the tests though10:41
dooferladif you "dig nanosheep.org" or some other server you haven't looked at recently, does it take long?10:41
dooferladvoidspace: ^^10:41
voidspacedooferlad: that returned quickly enough10:42
voidspaceI think this means that dns isn't the issue10:42
dooferladvoidspace: is quickly sub 200ms? From If so, yea, that looks fine.10:43
voidspacedooferlad: hmm... 599ms10:43
voidspacecmd/juju tests are no quicker10:44
dooferladvoidspace: http://paste.ubuntu.com/11729870/10:44
dooferladvoidspace: ping response time from an upstream DNS server?10:45
voidspacedooferlad: for lots of other sites I'm getting really quick responses10:46
dooferladvoidspace: it has to be a site you haven't looked up or you will get a cached response10:47
voidspacedooferlad: cached ones return in 0ms :-)10:47
dooferladvoidspace: I get 1ms cached responses10:47
voidspacedooferlad: response times for other domains really vary10:47
dooferladvoidspace: could just be a one-off slow response10:47
dooferladOK, other stuff. Do other machines on your network have the same slow browsing problem?10:48
dooferladanything unusual about that machines network connection? Could you try another cable/10:49
voidspacethe connection speed is fine10:49
voidspaceand that wouldn't affect locally running tests10:50
voidspaceit's not slow browsing, it's slow initial connection10:50
voidspace(which really sounds like dns but I'm fairly sure isn't now)10:50
voidspaceand that particular problem started after we changed iptables10:50
voidspaceI might try removing those rules to see if it changes again10:50
dooferladsounds like a plan10:50
voidspaceI don't *know* that cmd/juju got slow then, it may just be a coincidence10:51
voidspaceso removing them and trying again will let me know10:51
voidspaceI might go back to some real work for a bit first10:51
dooferladremoving those iptables rules is kind of trivial though - just comment them out of the saved rules file and restore the rules from it10:51
dooferladdimitern: review responded to.10:54
dimiterndooferlad, cheers, looking10:54
dimiterndooferlad, let's drop the second failing StopsInstances() call from that test then10:55
dooferladdimitern: 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
dimiterndooferlad, 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
dooferladdimitern: that is because the first thing it does is try to delete some files and directories, then it calls lxc-destroy10:56
dooferladdimitern: so the first error it returns it just what comes back from those delete calls10:57
dimiterndooferlad, right, that's seems wrong10:57
dooferladdimitern: calling lxc-destroy first would seem sane to me, then tidying up.10:57
dimiterndooferlad, yeah, let's go back to this at some point10:58
dooferladdimitern: on the 1.24 branch, I was using AssertFileContains rather than AssertFileContains because I figured having both functions was probably overkill.10:58
dooferladdimitern: was going to ask about removing AssertFileContains10:58
dooferladdimitern: 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
dimiterndooferlad, 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 nice11: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 mins12:00
jamfwereade_: k12:01
jamalexisb isn't here yet either12:01
waiganifwereade_: actually I don't think it would be that bad12:01
waiganifwereade_: menno and I worked on it originally when we migrated the collections to multi envs12:02
waiganimenno wrote the original collections.go and would be most familiar with it12:02
fwereade_waigani, yeah, I ask because you're online ;p12:05
waiganibut 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 fine12:06
waiganifwereade_: 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 etc12:07
jw4dimitern: probably too late, but you pinged?12:47
=== anthonyf is now known as Guest64410
dimiternjw4, no worries; I had some questions re actions, but I figured it out from the docs :)12:48
jw4dimitern: cool12:48
TheMuedimitern: 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
TheMuedimitern: even if it's a nice component for entities it's more code than the direct implementation12:53
dimiternTheMue, that's a good question12:54
TheMuedimitern: or alternatively make the IPAddress to a valid entity too (with adding an according kind to juju/names).12:54
dimiternTheMue, which reminds me we don't have tags for addresses12:54
TheMuedimitern: reading a bit of remover code and how it works on entities it's really a nice mixin12:55
TheMuedimitern: exactly12:55
dimiternTheMue, let's do this - propose a juju/names PR that introduces IPAddressTag12:56
dimiternTheMue, this should be a separate, overhead card btw12:56
dimiternTheMue, tags need a kind (used as prefix), let's use "ip-<value>"12:57
TheMuedimitern: 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
TheMuedimitern: OK, will add the tag as quick one and add it with a second PR to the remover12:58
dimiternTheMue, 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
dimiternTheMue, yeah, it's easy to do the juju/names PR first12:59
TheMuedimitern: it's more an effect of visibility12:59
=== kadams54-away is now known as kadams54
* TheMue loves DVCSes for simple switching between branches13:00
dimiternTheMue, hmm.. but I can see a problem with address tags13:00
dimiternTheMue, 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
dimiternfwereade_, ping13:01
fwereade_dimitern, pong13:01
TheMuedimitern: ic13:02
dimiternfwereade_, hey, so it's high time to introduce tags for ip addresses13:02
TheMuedimitern: could we by this way find a better name than just "value"?13:02
dimiternfwereade_, but since it's a struct, just using the Value is not loseless wrt transforming from tag to address13:02
TheMuedimitern: could we by this way find a better name than just "value"?13:03
TheMueouch, twice13:03
dimiternTheMue, yeah, I'm thinking of "ip-<type>-<scope>-<network>-<value>"13:03
dimiternfwereade_, ^^ ? or perhaps "<type-kind>-<scope>-<network>-<value>" e.g. ipv4-public-juju-private-
TheMuedimitern: value is the address itself in standard notation, isn't it?13:04
dimiternTheMue, yeah, but it also holds extra metadata about its scope, type, and network13:05
dimiternit can even be a hostname13:05
fwereade_dimitern, that feels wrong13:06
fwereade_dimitern, having all that jammed into a tag13:06
dimiternfwereade_, the unique _id for ipaddressesC is DocID, which can be used in a tag, but it'll contain the envuuid13:06
TheMuedimitern: 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, metadata13:07
dooferladdimitern: 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
dimiternfwereade_, we *could* go only with the value in the tab, *but* this won't work if you're trying to serialize e.g. "public:" as "ip-", as on the reverse path with network.NewAddress(tag.Id()) the scope will be "guessed" as local-cloud not public13:09
fwereade_dimitern, right13:09
dimiterndooferlad, looking13:09
dimiternfwereade_, or "ip-localhost" for that matter looks weird13:09
fwereade_dimitern, so the reason to jam all that into the tag is for uniqueness?13:10
dimiternfwereade_, use a single tag type and multiple sub-kinds? "ip<kind>-<value>" ? e.g. "iphostname-localhost" or (iphost-?) "ipv4-", "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
TheMuethat feels strange13:11
dimiternfwereade_, not for uniqueness, as the value + envuuid is the _id, so it's unique, but for better carrying out the original intent13:11
dimiternfwereade_, hmm we need to know what to hash back on FindEntity though13:12
jamdimitern: 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 tag13:12
jamwhat 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, indeed13:13
* jam disappears to go shopping13:13
dimiternfwereade_, 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 field13:13
TheMueso we could take a meaningless but unique uuid too13:14
dimiternfwereade_, hmm13:14
fwereade_TheMue, indeed, equally13:14
fwereade_dimitern, opaque identifiers are good things13:14
dimiternfwereade_, I'd rather hash the DocID and use that - it's already in the doc and can be found13:14
fwereade_dimitern, sure, that sounds fine too13:14
dimiternfwereade_, address-<sha256(_id)>13:15
waiganiwallyworld: ignoring unknown tools metadata: http://reviews.vapour.ws/r/1955/13:15
TheMuedimitern: address-<docID>13:15
fwereade_dimitern, that sgtm, you'll still have to store the hashed docid to look it up :)13:15
mupBug #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
TheMueor 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 document13:17
dimiternfwereade_, yeah, or perhaps Find all for the current env and iterate? :)13:17
TheMueand docID is unique13:18
dimiternTheMue, it's not just an ip address, as it can be a hostname13:18
dimiternfwereade_, why not use the docId unhashed indeed?13:18
TheMuedimitern: we talk about a tag identifying a type, and the typename is IPAddress. otherwise we should rename the type too *iiirks*13:19
dimiterndooferlad, ship it :)13:19
dooferladdimitern: click!13:19
TheMuedimitern: that's why I would take ipaddress-<docID>13:19
dimiternTheMue, I agree the name can be better, but let's not change everything at once :)13:20
TheMuedimitern: and other address types later, mac addresses, addresses for bills, whatever, can use their type as part of the tag13:20
TheMuedimitern: no no, I don't want to change it, only want to have it in the tag13:20
TheMuedimitern: so it's 1:113:20
dimiternfwereade_, with the "address-<docID>" format we'll have tags like "address-fedcba98-7654-4321-ba98-76543210beef:"13:22
TheMuedimitern: you surely wanted to write "ipaddress-<docID>" *scnr*13:23
dimiternfwereade_, 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
dimiternTheMue, I don't mind *that* much13: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 environment13:25
dimiternwe don't need to care for tag-to-ip conversion based on the format of the tag at all13:25
mupBug #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
dimiternfwereade_, yes, but none of the tags (except the environment tags obviously) carry the envuuid prefix that make them unique13: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 state13:26
fwereade_dimitern, I think it's fine for a tag to be unique only within the scope of a given environment13:27
dimiternfwereade_, yeah, they report local ids13:27
dimiternnot docIDs13:27
dimiternTheMue, 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
TheMuedimitern: so in our case it would be "ipaddress-<value>"?13:27
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 tingle13:29
TheMuehmm, 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 overlap13:29
dimiternfwereade_, yes we can as you can only use such tags once you've logged into a given environment13:30
fwereade_TheMue, dimitern: I just feel like that's an unreasonable restriction in a complex network environment13:30
dimiternfwereade_, we're only talking about how to access ipaddress entities we already have in the db for the current env13:31
fwereade_TheMue, dimitern: why can't isolated subnets use overlapping ranges?13:31
TheMuefwereade_: but can an environment have multiple disjunct subnets, having the same address range13:31
dimiternfwereade_, isolated like in a separate space?13:31
fwereade_dimitern, yes13:32
dimiternfwereade_, TheMue, subnet CIDRs for a given space should NOT overlap13:32
fwereade_dimitern, I know that juju will refuse to allow it13:32
dooferladas soon as you get >1 network associated with a machine you can get up to all sorts of fun.13:32
TheMuedimitern: should or must?13:32
dimiternfwereade_, TheMue, that's the whole point of the subnets being equal within a space13:32
fwereade_dimitern, within a single space, yes, you don't want subnets to overlap13:33
dimiternTheMue, fair enough - it must not overlap13:33
TheMuedimitern: ok, so we ensure that we can have multiple subnets but even then each IP is only used once13:34
dimiternfwereade_, the case you're describing sounds like having a machine in two separate, disjoint spaces13:34
fwereade_dimitern, but if you're modelling two spaces, that are completely distinct, and happen to use overlapping ranges, juju will fail13:34
mupBug #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
TheMuedimitern: so in this case using the address value as part of the tag seems to be fine13:35
mupBug #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
dimiternfwereade_, now it won't as that's not yet enforced, but I think it should anyway13:35
fwereade_dimitern, you're saying that any organisation that has more than one network using 10.0. is Doing It Wrong? ;p13:36
dimiternfwereade_, the problem is with a given machine's single routing table overlapping ranges will lead to issues with routing13:36
fwereade_dimitern, I don't care about machines13:36
fwereade_dimitern, I care about tags being unique13:36
dimiternfwereade_, 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
mupBug #1466087 changed: TestAllInstances fails <ci> <test-failure> <juju-core:Incomplete> <juju-core devices-api-maas:Triaged> <https://launchpad.net/bugs/1466087>13:38
dimiternfwereade_, right, what I'm proposing is not worse that what we have already in the face of multiple envs in the same state db13:38
TheMuedimitern: 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
dimiternfwereade_, machine tags (or others) are only unique within their env13:38
fwereade_dimitern, I know13:38
fwereade_dimitern, I'm saying address tags should too13: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 format13:39
dimiternI don't believe we should model all possible cases like this13:39
dimiternwhat's the use of having enclaves of machines like that in the same env?13:40
dooferladdimitern, fwereade_, TheMue: https://docs.google.com/a/canonical.com/drawings/d/1UAZEYOi1LcBgDyokAdlJAFQuDxpOL98DeHpFT-q1HbU/edit?usp=sharing13:40
dooferladI think this is easier with diagrams!13:40
fwereade_dooferlad, good diagram, thank you13:41
TheMuedimitern: 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
dimiterndooferlad, great, thanks13:41
fwereade_dimitern, I reject the notion that we should bake the impossibility of encoding that topology into juju forever13:41
fwereade_dimitern, not doig it today is one thinng13:41
* dimitern needs to think about this13:41
fwereade_dimitern, picking a tag format that renders it really damn hard to fix is another13:41
TheMuedooferlad: yeah, good one13:42
dimiternfwereade_, I totally get your point and agree the described scenario is not well modeled with what i'm suggesting13:42
fwereade_dimitern, "address-<space>-<value>" might address my concerns but I'm still a bit iffy there too13:42
dimiternfwereade_, but I seem to recall in the model somewhere we said we won't allow that13:42
fwereade_dimitern, yeah13:43
fwereade_dimitern, I agree that it's fine not to do that yet13:43
TheMuefwereade_: 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
TheMuefwereade_: to the ID of an IP address simply should be a UUID, the tag "ipaddress-<id>"13:45
dimiternfwereade_, agreed13:45
fwereade_TheMue, yeah, I'm totally comfortable with (not to mention keen on) opaque primary keys13:45
TheMuefwereade_: dimitern: so it doesn't care how we model networks and it is still identifyable13:45
dimiternfwereade_, TheMue, let's go with "ipaddress-<space>-<value>" the "space" part can be safely hardcoded to "default" I think13:46
dimiternat least initially13:46
mupBug #1466087 opened: TestAllInstances fails <ci> <test-failure> <juju-core:Incomplete> <juju-core devices-api-maas:Triaged> <https://launchpad.net/bugs/1466087>13:47
natefinchI don't know what we're talking about, but I'm always +1 on UUID for primary IDs over some concatenated mess.13:48
dimiterndooferlad, 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 too13: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
dimiternfwereade_, 1) a lot easier to implement, 2) more readable, 3) just as unique .. come to mind13:49
TheMuefwereade_: IMHO only better human readable, but that's all13:49
TheMuedimitern: why easier to implement?13:50
dimiternTheMue, also much easier to follow in the logs when debugging13:50
natefinchif you have to read IDs, you're doing something wrong13:50
fwereade_natefinch, +113:50
TheMuedimitern: I would log myAddress.String() giving a good readable string representation of my address13:51
dimiternTheMue, 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 ipaddressDocs13:51
dimiternI'm very good at following logs like that and figuring out what happened :P13:52
TheMuedimitern: sure, we act on existing data.13:52
dimiternand almost forgot - 4) a lot shorted in 90% of the cases for both IPv4  and IPv6 values13:53
* dimitern really needs to go now, might be back later13:54
* TheMue has to think about it too, but still feels a bit better with UUIDs13:55
fwereade_dimitern, you don't *have* to use a uuid, remember13:56
fwereade_dimitern, other formats can be both unique and opaque13:56
mupBug #1466100 opened: TestManageEnvironServesAPI fails <ci> <intermittent-failure> <test-failure> <juju-core:Incomplete> <juju-core db-log:Triaged> <https://launchpad.net/bugs/1466100>13:59
TheMuefwereade_: 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, bbiab14:05
fwereade_TheMue, indeed, "uuids are too big" is not generally an argument that impresses me much :)14:05
alexisbdooferlad, I will be a few minutes late14:26
alexisbbut I will be there14:26
natefinchdpb1: we can't repro your bug https://bugs.launchpad.net/juju-core/+bug/1465307 have you found a way to reproduce it?14:29
mupBug #1465307: 1.24.0: Lots of "agent is lost, sorry!" messages <blocker> <landscape> <regression> <juju-core:Incomplete> <https://launchpad.net/bugs/1465307>14:29
dpb1natefinch: 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
natefinchdpb1: cool, just wanted to make sure we were on the same page.14:36
natefinchericsnow: I was wrong about that rsyslog bug, I do understand why it happened, though not precisely the best way to fix it14:37
ericsnownatefinch: k14:37
natefinchericsnow: it was my fault - I changed where the rsysog certificate is (as stated by Menno in the comments of the bug).14:37
ericsnownatefinch: is it the way menn0 described it14:37
ericsnownatefinch: k14:37
ericsnownatefinch: I'll look into the fix14:37
katconatefinch: moving card for bug 1465307 to "DONE"14:38
mupBug #1465307: 1.24.0: Lots of "agent is lost, sorry!" messages <blocker> <landscape> <regression> <juju-core:Incomplete> <https://launchpad.net/bugs/1465307>14:38
natefinchkatco: huzzah14:38
katconatefinch: ty for following up14:38
natefinchkatco: 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
katconatefinch: sure thing14:43
natefinchkatco: thanks14:43
katcogsamfira: hey, were you looking at bug 1464470?14:47
mupBug #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-core14:47
mup1.24:Triaged> <https://launchpad.net/bugs/1464470>14:47
ericsnownatefinch: do you have the revision of the change you made for the location of the certificate?14:48
natefinchericsnow: I can find it14:57
ericsnownatefinch: thanks14:58
natefinchericsnow: https://github.com/juju/juju/commit/3a6ebe0b6a24a8c5f80a7dbcb78937755540839e14:58
jw4ericsnow: were you thinking github PR or reviewboard link?15:13
ericsnowjw4: either is fine, though I think putting the RB link also more clearly sends the message that the patch was reviewed :)15:14
jw4ericsnow: cool :)15:14
natefinchericsnow: got a minute to talk about the plugin package?15:17
ericsnownatefinch: sure15:17
ericsnownatefinch: moonstone?15:17
natefinchericsnow: ya15:17
voidspacedimitern: ping15:19
voidspacedimitern: currently, the network interface information returned by PrepareContainerInterfaceInfo populates MACAddress with the NIC of the interface it allocated the address on15:19
voidspacedimitern: i.e. the host NIC MAC15:19
voidspacedimitern: so my change is a semantic change here.15:19
voidspacedimitern: as the method is documented to return "information for configuring networking on a container" I think that's ok15:20
voidspacedimitern: we always overwrite the MAC address anyway15:20
voidspacedimitern: but it might be slightly surprising to someone reading the code15:20
dooferladTheMue/voidspace: could you take a quick look at this fix: https://github.com/dooferlad/juju/commit/aeb9acf964cbdb04abd957f49e2303a65cc5d24015:21
dooferladThe rest of the change (http://reviews.vapour.ws/r/1941) has got a ship-it, but this caused the test bot to fail15:21
voidspacedooferlad: looking15:21
voidspacedooferlad: what was the failure?15:21
dooferladThe 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
voidspacedooferlad: is this because the code is running in a goroutine and you don't want to use an assert?15:22
dooferladno, an assert would be fine15:22
voidspaceah ok15:23
voidspacedooferlad: but you need to repeat the read on cfgObserver15:23
voidspacedooferlad: looks good to me15:23
dooferladvoidspace: yea, just need to keep reading cfgObserver until the expected change arrives, or time out.15:24
voidspaceyep, LGTM15:24
dooferladvoidspace: thanks. Will push the go button again.15:24
dooferladvoidspace: and port to trunk.15:24
dooferladvoidspace: 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
dooferladTheMue: since voidspace is offline, could you take a look ^^15:50
voidspacedooferlad: LGTM15:50
dooferladvoidspace: how I love IRC clients. You are apparently both offline and online.15:51
dooferladvoidspace: once that lands you probably want the changes in devices-api-maas. Hopefully it will result in less $$stupidtests$$15:54
dooferladvoidspace: yell if you want a hand15:54
voidspacedooferlad: cool, thanks15:59
voidspacedooferlad: heh, my IP address changed just at that instance16:00
voidspacedooferlad: so I was briefly offline and reconnected16:00
=== natefinch_ is now known as natefinch
=== liam_ is now known as Guest13658
mupBug #1466152 opened: [RFE] log locks and other relevant information when jujud receives SIGUSR1 <juju-core:New> <https://launchpad.net/bugs/1466152>16:47
rogpeppe1natefinch: just took a look at deputy. nice idea. you should probably document that Timeout isn't compatible with StdoutPipe or StdinPipe17:26
natefinchrogpeppe1: ahh yeah good point17:27
natefinchrogpeppe1: 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
rogpeppe1natefinch: yeah, i think it's a reasonable idea17:29
natefinchrogpeppe1: I'm sure it needs some work, it's just an initial draft.17:30
rogpeppe1natefinch: tbh i'm not that keen on the Option thing. it's cute, but i'd actually prefer to see an explicit options struct17:32
rogpeppe1natefinch: also, i think you've got a potential race condition17:34
rogpeppe1natefinch: not sure of a decent way to work around it though17:35
rogpeppe1natefinch: i think you probably need to allow only one of either stderr or stdout as error17:36
natefinchrogpeppe1: I'd thought about what happens if you use both stderr and stdout as errors.... allowing only one is probably better17:40
natefinchrogpeppe1: and you may be right about the option thing.17:40
mupBug #1466167 opened: debug-hooks no longer works with 1.24-beta6 <juju-core:New> <https://launchpad.net/bugs/1466167>17:47
katcowwitzel3: ericsnow: natefinch: do you guys need anything?18:36
ericsnowkatco: I'm good for now18:37
natefinchericsnow: nope, I'm good18:42
wwitzel3katco: a new nasal passage18:49
katcowwitzel3: hm.18:50
katcowwitzel3: i have a hammer, a phillips screw driver, and a lawyer's phone number.18:50
wwitzel3katco: no duct tape? sounds sketchy18:51
katcowwitzel3: i assure you, the screw driver is the highest quality stainless steel18:52
katcowwitzel3: it shouldn't stain my screwdriver at all18:52
wwitzel3well in that case ...18:54
perrito666wwitzel3: 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
katcoanastasiamac: ping21:46
* perrito666 wonders what he did this time to have reviewboard ignore him22:31
anastasiamackatco: pong?22:39
katcoanastasiamac: hey got time for a chat?22:39
anastasiamackatco: sure. tanzanite?22:40
katcoanastasiamac: https://plus.google.com/hangouts/_/canonical.com/moonstone?authuser=122:40
katcoanastasiamac: don't have the link for tanzanite anymore =/22:40
perrito666katco: that is cruel22:40
alexisbkatco, word on the street is anastasiamac and wallyworld will be looking for tanzanite when they are next in Capetown SA22:48
alexisbkatco, you will have to one up them by getting moonstone in Missouri22:48
perrito666alexisb: 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=022:50
katcoalexisb: lol i'll have to do that :)22:52
katcoalexisb: all jokes aside, i find moonstones to be prettier than tanzanite :)22:52
anastasiamacalexisb: wallyworld will be looking for tanzanite in SA. anastasiamac will twidlling her thumbs in Aus :D22:53
anastasiamackatco: combine the two and u'll get an even better value :D22:53
katcoanastasiamac: haha :D22:54
wallyworldebay? you'll end up buying purple glass22:54
wallyworlda jeweller friend of mine has so many customers who bring in rings bought off ebay that are just straight out fakes22:54
perrito666wallyworld: better? http://www.amazon.com/s?ie=UTF8&field-keywords=tanzanite&index=blended&link_code=qs&tag=wwwcanoniccom-2022:55
wallyworldyes :-)22:55
perrito666ow, interesting, I had not noticed the tag= part22:56
wallyworlddid you use a scope?22:57
perrito666wallyworld: nope, my browser amaz<tab>22:57
perrito666my browser being chrome22:58
perrito666that quick search might be rigged ot do the same22:59
=== kadams54 is now known as kadams54-away
anastasiamacalexisb: running a bit late...will ping after standup..23:30
alexisbanastasiamac, ack23:30
anastasiamacalexisb: m grabbing a drink (& coffeeeee) and will b there! tyvm for waiting :D23:33
thumperwallyworld: do you have a few minutes to talk about leases?23:55
thumperaxw: you around?23:57
wallyworldthumper: give me 5?23:59

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!