davecheneythumper: nagging nag, did you talk to smoser about power64 ?00:00
ericsnowwallyworld_: it's left over from the original backup script00:00
ericsnowwallyworld_: I'm in the process of sorting out all those hard-coded paths00:00
wallyworld_we must have been lucky this hasn't failed then00:01
wallyworld_in an HA environment00:01
katcowallyworld_: for your perusal: http://reviews.vapour.ws/r/519/00:06
ericsnowwallyworld_: right00:07
thumperdavecheney: yes, been escelated00:11
thumperfor some spelling of that00:11
axwwallyworld_: seen the Azure bug?00:16
wallyworld_axw: yeah, otp, but i was going to ask you to pick it up. i trusted kapil to have tested it but obviously not :-(00:17
axwwill do00:17
thumperdavecheney: I noticed that the juju/utils package tests panic with gccgo00:24
thumperdavecheney: but no idea why00:24
thumperI couldn't grok the panic00:24
thumpersubpackages are fine, just the main one00:25
thumperwallyworld_: do you know which juju projects have the autolander?00:28
menn0ericsnow: it's pretty awful that everything is hardcoded to be able machine-0 but if that's going to get resolved soon then I guess that's ok00:31
davecheneythumper: thanks00:31
davecheneythumper: paste.ubuntu ?00:31
* thumper looks for it again00:32
ericsnowmenn0: agreed00:32
thumperdavecheney: http://paste.ubuntu.com/9351357/00:33
thumperericsnow: do you know which juju projects are auto-landed?00:34
ericsnowthumper: you talking about the bot or for reviewboard?00:35
thumperericsnow: bot00:35
thumperericsnow: although knowing about reviewboard would also help00:36
ericsnowthumper: RB is currently just core and utils00:36
thumperericsnow: it seemed that juju/cmd didn't have the rb hookup00:36
davecheneythumper: sorry, my internets shat themselves00:36
thumperericsnow: ah...00:36
davecheneyyou were saying ?00:36
thumperdavecheney: http://paste.ubuntu.com/9351357/00:36
thumperI think I'll just use the github magic merge button for juju/utils00:37
davecheneythumper: first thougth is you have the wrong gccgo00:37
=== kadams54 is now known as kadams54-away
thumperdavecheney: I've not changed it...00:37
davecheneyprety much everyone has the wrong gccgo00:37
ericsnowthumper: for the bot I think it's just core00:37
davecheneythumper: do this00:37
davecheneygo test -c $PKG00:37
davecheneygdb --args ./$PKG.test00:37
thumperdavecheney: can I use '.' for $PKG?00:38
davecheneyso if your in juju/cmd00:38
davecheneythe bin will be called00:38
thumperdavecheney: but also need to specify the compiler right?00:38
ericsnowwallyworld_, menn0: fix landed for 139844800:38
davecheney-c basically says "don't throw away the test binary afterwads, and give it a predictable name"00:39
menn0ericsnow: awesome00:39
thumperdavecheney: all passed with gdb00:39
menn0ericsnow: it'll take a while to filter down to the relevant CI jobs00:39
ericsnowmenn0: for that "unable to get DB names" issue, looks like the mgo session dropped or something (hence EOF)00:40
davecheneythumper: so here is a fun thing00:40
davecheneygccgo development has moved on since 4.9.200:40
ericsnowmenn0: I'm working on making it at least a little more robust00:41
davecheneywhat are out changes of getting gccgo 5.0 backported to trusty ?00:41
davecheneys/out changes/our chances/00:41
thumpernfi, but we can ask00:41
davecheneybasically we're going to have to stick with the trunk of gccgo if we want to have any support from uupstream00:42
menn0ericsnow: sounds good00:43
davecheneythumper: this is on a branch ?00:44
davecheneyi'll try to repro00:44
thumperdavecheney: master00:44
davecheneyok, that makes it easy00:44
davecheneygithub.com/juju/cmd ?00:44
=== kadams54-away is now known as kadams54
thumperdavecheney: no, utils00:46
=== kadams54 is now known as kadams54-away
* davecheney smacks forhead00:47
davecheneythumper: ummm00:48
davecheneywhat happened here00:48
davecheneyoh, wait00:48
davecheneysorry, local problem00:48
wallyworld_ericsnow: ty, sorry just got out of meeting00:51
ericsnowwallyworld_: no worried00:51
wallyworld_thumper: no, many are supposed to, you mean on github or lp?00:52
wallyworld_i think the tarmac bot has died00:52
thumperwallyworld_: I just don't know which ones00:52
thumperwallyworld_: my general approach is to try $$merge$$ and if nothing happens for a few minutes, do it manually00:52
wallyworld_we need to follow up there, it's fallen into a hole00:53
davecheneythumper: ok, repro pretty easy00:53
thumperwallyworld_: github lander not lp00:53
davecheney% env GOMAXPROCS=42 ./utils.test00:54
davecheneySegmentation fault (core dumped)00:54
thumperdavecheney: is the fix as obvious?00:55
=== kadams54-away is now known as kadams54
davecheneynow I should be able to get it to shit itself under gdb00:56
davecheneyurgh, looks like a gc bug00:57
davecheneyor a crash in libunwind00:57
davecheneythumper: what release are you running ?01:01
* thumper afk for a bit01:02
mwhudsondavecheney: oh, i've seen that one01:07
mwhudsondavecheney: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=6400101:08
davecheneymwhudson: do you want me to work on a repro ?01:10
davecheneyit's related to the http -> tls -> asn code path01:10
mwhudsondavecheney: a small-ish repro would be great, yes01:10
mwhudsondavecheney: yeah, but the crash seems dementedly unrelated to that01:10
davecheneyyou're right about the stack split01:10
davecheneythat paste above is pretty clear where it's happening01:11
mwhudsonyeah, but not why01:11
davecheneysomethign it makeing libunwind shit itself01:11
mwhudsonwell no01:11
mwhudsonat least not in my case01:11
mwhudsonit's in the __morestack splitting code01:12
mwhudsonand $rsp is bogus01:12
mwhudsonsometimes unaligned, sometimes unmapped01:12
mwhudsoni guess if you're really lucky it's valid but pointing at some random part of the heap so you get random corruption01:12
davecheneymwhudson can you do this01:13
mwhudsoni saw at least three distinct failure modes fwiw01:13
davecheneyenv GOGC=1 gdb --args go get github.com/lxc/lxd01:13
mwhudsonthat was one of them01:13
davecheneyyeah, i've seen some others01:13
davecheneyi think the https one is the easiest to make a repro01:13
mwhudsonit worked once...01:15
mwhudsonbut then01:15
mwhudsonProgram received signal SIGBUS, Bus error.01:15
mwhudson__morestack () at ../../../src/libgcc/config/i386/morestack.S:52901:15
mwhudson(gdb) p $rsp01:15
mwhudson$1 = (void *) 0xffffedf4536001:15
davecheneymwhudson: ok, i'll try to make a stand alone repro that blows up01:16
davecheneyhopefully ian can figure out what is failing01:16
davecheney'cos it's way above my ken01:16
mwhudsoni spent an hour or so poking at it when i was in austin and got ~nowhere01:17
wallyworld_katco: standup?01:19
davecheneymwhudson: do you know if 4.9.2 is available in a trusty-backports ?01:19
katcowallyworld_: shoot sorry brt01:19
mwhudsondavecheney: i do not know01:19
=== kadams54 is now known as kadams54-away
davecheneymwhudson: http://paste.ubuntu.com/9351595/01:27
davecheneyworlds smallest repro01:27
davecheneymwhudson: will you be my mule and put this stuff on the gcc bugzilla ?01:27
thumpermenn0: updated https://github.com/juju/cmd/pull/10/files01:34
thumperdavecheney: that is pretty small01:34
* thumper rushes to get the cmd branch in before anastasiamac01:36
mwhudsondavecheney: !01:42
axwwallyworld_: sorry I was wrong, D1 fails for me too. I put in a rubbish name and saw "D1", but that's hard-coded in D101:42
axwerr hard coded in Juju01:43
mwhudsondavecheney: sure, will en-bugzilla01:44
wallyworld_axw: no worries, glad it's reproduceable01:47
menn0thumper: looking01:50
davecheneymwhudson: so that one liner can blow up simply01:50
davecheneyi'm trying to disect it down to the bit that confuses the gc01:50
davecheneyi know what it could be01:51
davecheneyasn1 probably looks like a random field of pointers to the gc01:51
mwhudsonit fails with GOGC=off though?01:54
davecheneyshould do01:55
davecheneyrepro is super fiddly01:55
davecheneyoh, interestingly01:56
davecheneythat aspolodes as well01:56
davecheneywhich means you were right about the stack split01:56
anastasiamacthumper: u r making me cry but it's k - whoever has the last laugh and all.... :-P02:00
menn0thumper: done. there's a few doc issues but otherwise LGTM.02:00
menn0thumper: note that some of the comments are directly against the last commit which Github makes a little tricky to get to.02:01
thumpermenn0: ta02:06
thumperah... didn't fix the docstrings on those alias methods02:07
davecheneyanastasiamac: i like your attitude to code review02:09
davecheneydon't get mad, get even02:09
anastasiamacdavecheney: i get made at drivers not coders ;-)02:10
anastasiamacdavecheney: plus thumper is scary02:10
anastasiamacdavecheney: wouldn't want to get mad at him...02:10
davecheneyyeah, he's fluffy02:11
davecheneylike a kitten02:11
thumperfluffy now with the facial fuzz02:11
axwwallyworld_: https://code.launchpad.net/~axwalk/gwacl/rolesizes-fix-dg-names/+merge/243478 please02:16
wallyworld_axw: where are the Aliases used?02:20
axwwallyworld_: nowhere yet, they'll be used in Juju02:20
axwwallyworld_: I'll extend environs/instances/InstanceType to have an "Aliases []string" field02:20
wallyworld_axw: ok, do we have the ExtraLarge etc ones the right way around?02:21
axwwallyworld_: yes02:21
axwwallyworld_: from Azure:02:21
axw2014-12-02 11:37:29 ERROR juju.cmd supercommand.go:323 failed to bootstrap environment: cannot start bootstrap instance: POST request failed: BadRequest - Value 'D1' specified for parameter 'RoleSize' is invalid. Allowed values are 'ExtraSmall,Small,Medium,Large,ExtraLarge,A5,A6,A7,A8,A9,Basic_A0,Basic_A1,Basic_A2,Basic_A3,Basic_A4,Standard_D1,Standard_D2,Standard_D3,Standard_D4,Standard_D11,Standard_D12,Standard_D13,Standard_D14'. (http code02:21
axw 400: Bad Request)02:21
wallyworld_ok, and the same for the G ones I guess02:21
wallyworld_those names look like a dog's breakfast02:22
thumperwaigani_: very complex review ... not!  http://reviews.vapour.ws/r/575/02:23
=== kadams54 is now known as kadams54-away
=== kadams54-away is now known as kadams54
thumperwallyworld_: is the landing bot unblocked?02:24
wallyworld_should be02:24
wallyworld_for master?02:24
wallyworld_i landed a fix last night02:24
thumperjw4: FAIL: action_test.go:144: actionSuite.TestFindActionTagsByPrefix02:25
thumperjw4: intermittent?02:25
mwhudsondavecheney: __morestack is called a _lot_02:29
mwhudsonit turns out02:29
thumperthat action test fails for me all the time...02:34
axwwallyworld_: I always forget. the bot does gwacl?02:36
wallyworld_axw: i merged by hand, i think tarmac is dead02:36
* thumper throws his hands up and leaves the office02:38
thumperhow the fuck did this test land?02:40
thumpermenn0: state/action.go:27802:41
thumpermenn0: and apiserver/action/action_test.go:14402:42
davecheneymwhudson: yeah, which is odd02:42
davecheney'cos there is no escape analysis in gccgo02:42
davecheneyso there should be _less_ stack pressure02:42
* thumper heads to the 'uper duper market02:43
mwhudsondavecheney: so i was wrong in my initial bug comment, __generic_morestack is returning junk02:44
mwhudsondavecheney: also, it really doesn't fail with my random gccgo tip build02:44
axwwallyworld_: D1 fails to provision still, but it's a different error now (Compute.OverconstrainedAllocationRequest)02:56
axwthis may take a little while...02:57
wallyworld_sure that's not just a transient azure snaffu02:58
axwwallyworld_: I get the same error on West US and Southeast Asia, for both D1 and D2 multiple times02:58
axwtrying through the management console now02:58
=== kadams54 is now known as kadams54-away
thumpermenn0: ping03:35
thumperjw4: ping03:40
thumperwallyworld_: can I get you to test something for me please?03:41
thumperwallyworld_: on master, run the tests in apiserver/actions plz?03:41
thumperI get a fail that I can't see how it landed03:41
thumperit is me03:43
thumperfuckity fuck fuck03:43
thumperI'm bringing in jw4's utils change...03:43
wallyworld_ok, just gotta shelve, sec03:44
wallyworld_OK: 8 passed03:44
wallyworld_ok      github.com/juju/juju/apiserver/action   5.622s03:44
wallyworld_thumper: ^^^^03:44
wallyworld_let me check that y master is up to date, i think it ia03:45
thumperit is03:45
thumperI know what it is03:45
menn0thumper: sorry, I was out giving programming lessons03:55
thumpermenn0: to?03:55
menn0thumper: still need me to do something?03:56
menn0thumper: a friend's son (he's 11 but very keen)03:56
* thumper nods03:56
menn0doing an hour a week with him03:56
thumpermenn0: got a minute to hangout?03:56
menn0thumper: yep03:56
thumpermenn0: standup hangout03:56
menn0thumper: there now03:57
anastasiamac4421 lines in one file :-(04:25
=== kadams54 is now known as kadams54-away
wallyworld_jam1: ping05:33
bradmdavecheney: hey05:41
davecheneybradm: hey05:42
bradmdavecheney: this might be easier than going back and forth via RT :)05:42
davecheneybradm: yeah05:43
bradmdavecheney: so I checked the squid config on batuan, you did not have github on it.05:43
bradmdavecheney: but you do now. :)05:43
davecheneyi'll try now05:43
bradmdavecheney: give it a go, all those things you listed should be working.05:43
davecheneybradm: what do I do abour getting mercurial on rubgy ?05:43
bradmdavecheney: is the packaged version ok?05:43
davecheneyfor <reasons> juju uses all three of git, bzr and hg05:44
bradmdavecheney: do you need it in a chroot?  or just in the base OS?05:44
davecheneybase os05:44
davecheneydon't care about that chroot stuff05:44
davecheneyin this case i'm just a luser05:44
bradmyou put your hg in your bzr in your git?  then you should cvs it, and then rcs that.05:44
bradmyou'd never lose anything then.05:44
davecheneythanks for the tip05:45
davecheneydid i mention we also use more than one code review system05:45
* davecheney stabs self in face05:45
bradmdavecheney: mercurial package is installed.05:46
bradmdavecheney: how's that look?  need anything else to get you going?05:48
davecheneysquid.internal gives some public ip05:50
davecheneycan I check the proxy settings with you ?05:50
bradmwhat are you using?05:51
davecheneyexport http_proxy https_proxy05:51
bradmtry http_proxy=http://batuan.canonical.com:312805:52
bradmand the https_proxy bit too05:52
bradmsquid.internal is mostly used by UK hosts, I only mentioned it because I wasn't sure what you had05:53
davecheneybradm: thanks05:53
davecheneyall working now05:53
bradmdavecheney:  perfect!  let us know if you have any further issues05:53
davecheneybradm: dfc@rugby:~$ gcc05:54
davecheneyThe program 'gcc' is currently not installed. To run 'gcc' please ask your administrator to install the package 'gcc'05:54
davecheneysorry, i didn't even think to check this05:55
davecheneycould I get build-essential and gdb pls05:55
bradmdavecheney: running05:55
bradmdavecheney: done.05:57
* axw pulls hair out06:05
axwwallyworld_: now I'm finding that some locations don't have some role sizes. gotta filter that out too...06:05
axwle sigh06:05
wallyworld_fwereade_: if you did have time, here's the work to generate the server cert on each state server. i've removed the cert from state entirely. http://reviews.vapour.ws/r/552/06:48
axwwallyworld_: https://code.launchpad.net/~axwalk/gwacl/listlocations/+merge/243495 - another small one, please07:39
TheMuejam1: a few seconds, missed to install the plugin09:00
TheMuejam1: dimitern: so, in the hangout09:01
dimiternTheMue, what hangout?09:03
TheMuedimitern: I thought you would be part of the 1:1:1 ;)09:04
dimiternTheMue, ah, I though yours was yesterday09:04
TheMuedimitern: jam1 moved it due to his holiday09:05
dimiternTheMue, I don't have the link - can you add me to the guests?09:05
TheMuedimitern: yep09:05
TheMuedimitern: just invited you09:06
dimiternTheMue,yeah, thanks - hmm.. it came to my phone though09:07
TheMuedimitern: *lol* that's the magic of the google cloud09:07
voidspacedimitern: when you get a chance old boy09:14
voidspacedimitern: http://reviews.vapour.ws/r/564/09:14
dimiternvoidspace, sure, will have a look shortly09:17
voidspacedimitern: "PickNewAddress" (or whatever we call it). Subnet method or State method?09:33
voidspacedimitern: I think Subnet method. State has a big enough API already.09:34
voidspacecoffee - brb09:34
jam1dimitern: TheMue: standup ?10:02
dimiternjam1, omw10:02
TheMuejam1: coming, just finished 1:110:02
rogpeppevoidspace: ping10:09
perrito666good morning10:12
wallyworld_jam1: after your standup, can you ping me back? i need to ask about bug 139737610:13
mupBug #1397376: maas provider: 1.21b3 removes ip from api-endpoints <api> <cloud-installer> <fallout> <landscape> <maas-provider> <juju-core:Triaged> <juju-core 1.21:Triaged> <https://launchpad.net/bugs/1397376>10:13
jam1wallyworld_: we'll want to make sure dimitern is in that conversation, as there seems to be some strong disagreement about whether things should be talking DNS names or IP addresses.10:14
wallyworld_customers want ip addresses i think10:14
wallyworld_and there are claims only returning one address is a regression10:15
wallyworld_since it used to return multiple10:15
jam1wallyworld_: IIRC from the maas discussion, the IP address can change while the DNS name would stay consistent10:15
wallyworld_and the api is called api-endpoints after all10:15
jam1so the MaaS guys asked us to talk in terms of DNS names10:15
wallyworld_oh, i see10:15
axwrogpeppe: hey. would there be any reason for charm.Meta to have bson tags, if we duplicate the structure in state and put bson tags there?10:16
jam1wallyworld_: api-endpoints did return only 1, then it started returning 2, then we reverted back to 110:16
perrito666davecheney: did you mean http://golang.org/pkg/os/#Create ? in your email about chmod?10:16
dimiternwallyworld_, jam1, I can bring this up at today's maas cross team call10:16
rogpeppeaxw: yeah, i think we're storing it directly in mongo in the charm store10:17
wallyworld_dimitern: that would be good. i fear (perhaps unnecessarily) that other providers would work better with ip addresses10:17
wallyworld_eg openstack autopilot10:18
wallyworld_see comment #810:18
wallyworld_so it seems we want one behaviour for maas, and another for openstack10:18
wallyworld_but if the provider gives us the correct info for machine addresses, it all should just work10:19
dimiternwallyworld_, afaik maas did not return dns names before due to a bug - it was supposed to10:19
wallyworld_and we need the prefered address a 010:19
wallyworld_as per comment #910:19
wallyworld_dimitern: so it seems then that with a mass that works correctly, the bug becomes a matter of ensuring that we ensure that the preferred ip address is in Addresses[0] so that's te one printed10:20
dimiternwallyworld_, or we can just try to resolve dns names before saving10:22
wallyworld_for maas10:22
jam1dimitern: wallyworld_: so I believe the bug *here* is that MaaS guys are saying "use the DNS name" but the Autopilot guys are saying "but I don't want to have to add MaaS as my DNS source"10:22
jam1It makes some sense fo inside the MaaS cloud as everything is run by MaaS, but for client machines10:22
jam1they are fairly likely to just know the MaaS endpoint, and not be configured to talk to "foo.maas"10:22
wallyworld_client machines would want ip address i think10:23
jam1wallyworld_: AIUI, api-info is intended to supersede api-endpoints10:23
jam1as it can give information on stuff like CA Cert10:24
wallyworld_that could well be true, i'm not across the detail on this bit of the system, hence asking you guys :-)10:24
wallyworld_we do need to consider backwards compatibility, no?10:24
wallyworld_dimitern: jam1: so can i leave this bug in your guys' capable hands? :-)10:26
dimiternwallyworld_, sure thing :)10:26
wallyworld_ty :-) \o/10:27
wallyworld_dimitern: andrew is working the azure bug - it got complicated, so he has to add in extra apis to query location as not all locations support all the role sizes :-(10:28
dimiternwallyworld_, sweet! I underestimated that one badly10:28
jam1dimitern: I'm just makign coffee, but I'll be at the next meeting.10:28
wallyworld_dimitern: me too. i thought that the gwacl changes made by kapil were all good to go, bad assumption :-)10:29
wallyworld_as it turned out10:29
wallyworld_azure is complicated10:29
dimiternyeah, and often broken as well10:30
wallyworld_yep, through no fault of ours it seems many times10:30
dimiternfwereade_, jamespage, gnuoy, networking call?10:30
jamespagedimitern, yes - sorry - still in stockholm10:31
bachi axw, you still around?10:34
axwbac: heya, yes I am10:36
bacaxw: good, i know it is late for you.  i saw a problem with azure yesterday that i wanted to tell you about.10:37
axwbac: is it this one? https://bugs.launchpad.net/juju-core/1.21/+bug/139840610:37
mupBug #1398406: Azure provider attempts to deploy with unsupported "D1" RoleSize <azure-provider> <bootstrap> <ci> <regression> <juju-core 1.21:In Progress by axwalk> <https://launchpad.net/bugs/1398406>10:37
bacaxw: no.10:37
axwokey dokey10:37
voidspacerogpeppe: pong10:38
voidspacerogpeppe: sorry, only just seen your ping10:38
rogpeppevoidspace: np10:38
bacaxw: it involved having two environments up with the same credentials but different storage for the state servers.  i used destroy-environment on one and it took down both.10:38
rogpeppevoidspace: how much do you know about USSO?10:38
voidspacerogpeppe: well, I've never heard of the acronym10:38
bacaxw: i have the remnants on azure but have not been able to create a minimal reproduction of the problem10:38
voidspacerogpeppe: so not a good start...10:39
rogpeppevoidspace: just saw your name on the identityprovider source code and thought you might be able to help us...10:39
bacaxw: i was using 1.20.12-utopic-amd64.10:39
axwbac: I suspect azure is not using the env UUID to separate things... I will see if I can figure it out. did you raise a bug already?10:39
voidspacerogpeppe: heh, I worked a lot on identityprovider - but not actually on the identity protocols in the end10:39
bacaxw: i did not since i could not reproduce10:39
voidspacerogpeppe: and I don't recall ever hearing USSO, so it might have been added after I left10:39
axwfair enough10:39
rogpeppevoidspace: ubuntu single sign on10:39
axwbac: thanks, I'll take a look at the code to see if I can think up a repro10:40
bacaxw: the problem was quite costly as it destroyed our CI environment10:40
voidspacerogpeppe: ah...10:40
bacaxw: if you'd like to look at the jenv files or azure storage i've kept them10:40
voidspacerogpeppe: oh, it depends on the question then10:40
voidspacerogpeppe: it's been a while though...10:40
axwbac: that would be good to have10:40
bacaxw: and i'm happy to file a bug10:40
rogpeppevoidspace: perhaps you could join us in a hangout for a few moments?10:40
voidspacerogpeppe: sure10:41
bacaxw: do you have access to chinstrap? i'd like to not sanitize the jenv files so i don't want to attach them to the bug report10:41
axwbac: yes I do10:41
bacaxw: cool, i'll put it there and reference it.10:41
bacaxw: thanks and good night10:42
axwbac: thanks10:42
axw(and sorry about your CI env :()10:43
axwPTAL, I tweaked the isLimitedRoleSize code a bit10:58
axwwallyworld_: ^^10:58
wallyworld_axw: just a typo, might be good for one more live test before landing, just to be sure with the tweaks11:01
axwwallyworld_: thanks. sure11:02
* axw dinners first11:03
wallyworld_np, ty11:03
dimiternvoidspace, whew.. no meetings for a while, so back to your review11:12
=== ashipika1 is now known as ashipika
voidspacedimitern: cool, thanks11:16
=== ashipika1 is now known as ashipika
dimiternvoidspace, reviewed, please ping me if something is unclear11:34
=== ashipika1 is now known as ashipika
voidspacedimitern: sure, thanks12:05
perrito666Is there a create version tat supports permissions?12:22
perrito666what exactly will _posix tag match?12:43
perrito666build* tag12:43
wallyworld_fwereade_: if you did get a chance or the inclination to look at http://reviews.vapour.ws/r/552/ that would be great, but you're busy so i'll bother someone else tomorrow if needed12:56
fwereade_wallyworld_, thanks, I'll try12:57
wallyworld_sure, no hassle if not12:57
axwwallyworld_: the Azure fixes still need backporting to 1.21, I'll do that tomorrow13:28
wallyworld_axw: sure, np13:28
wallyworld_thanks for fixing13:28
bacaxw: i filed bug 1398820, not sure if you saw it13:30
mupBug #1398820: destroying Azure environment took down other environment <juju-core:New> <https://launchpad.net/bugs/1398820>13:30
=== kadams54 is now known as kadams54-away
=== kadams54-away is now known as kadams54
mbruzek1wallyworld_ ping14:35
bacsinzui: thanks for the insight on that bug.  i'm trying to reproduce with azure and azure-1 now.14:36
anastasiamacmbruzek1: it's 00.35am where wallyworld is :)14:36
wallyworld_but sadly he is here14:37
mbruzek1ping retracted go to sleep Ian14:37
wallyworld_mbruzek1: how can i help?14:37
anastasiamacwallyworld_: OMG!!14:37
wallyworld_like you can talk :-)14:37
sinzuibac: abentley and I are trying to remember the issue we found about a year ago.14:37
wallyworld_same time for you14:37
anastasiamacwallyworld_: I had 89 comments on my tiny PR... how can I sleep?14:37
wallyworld_all/mostly trivial14:38
anastasiamacwallyworld_: true. in fact, I was hoping u could review tomorrow in hopes of landing before ur holiday :)14:38
abentleysinzui, bac: https://bugs.launchpad.net/juju-core/+bug/125748114:38
mupBug #1257481: juju destroy-environment destroys other environments <ci> <destroy-environment> <juju-core:Fix Released by jameinel> <juju-core 1.16:Fix Released by jameinel> <juju-core (Ubuntu):Fix Released> <juju-core (Ubuntu Saucy):New> <https://launchpad.net/bugs/1257481>14:38
wallyworld_anastasiamac: sure14:39
anastasiamacwallyworld_: thnx ;-) m EOD-ing now14:40
wallyworld_as well you should14:40
bacthanks abentley.14:40
anastasiamacwallyworld_: u214:40
mattywsinzui, landing is blocked on 1398448 - but it looks like a fix has landed for it?14:40
* sinzui checks test14:42
sinzuimattyw, ha ha, that bug is indeed fix released, but is replaced by another bug 139883714:44
mupBug #1398837: cannot extract configuration from backup file: "var/lib/juju/agents/machine-0/agent.conf <backup-restore> <ci> <regression> <juju-core:Triaged> <https://launchpad.net/bugs/1398837>14:44
mattywsinzui, so still blocked - but for a different reason?14:45
sinzuimattyw, yes, sorry.14:45
mattywsinzui, no problem - is someone working on that bug?14:48
sinzuimattyw, not yet, it was reported when abentley was checking on the other blocking bug. I am sending out an email about the many hot bugs targeted to 3 milestones14:49
mattywsinzui, ok - I'm not vounteering as I'm going to be out for a few days - but just wanted to make sure they weren't being ignored14:50
mattywsinzui, so I'm not being helpful - but I'm being supportive ;)14:50
sinzuiunderstood Makyo14:50
sinzuiunderstood mattyw14:50
natefinchooh ooh, can I be unhelpful but supportive, too? ;)14:53
mattywnatefinch, I've taken that job, you'll have to be helpful but unsupportive14:56
mattywor you can be unhelpful and unsupportive14:57
natefinchI can't believe you fools!  here's the fix.14:57
perrito666natefinch: /ignore sinzui ?14:57
natefinchI didn't even know /ignore was a thing...14:58
* natefinch is an IRC n00b14:58
perrito666odd, you seem to have the age to have been young when IRC was a thing14:58
* perrito666 hides14:58
natefinchthou dost injure me, perrito66614:59
natefinchI used IRC back in the late 90's, and figured everyone had moved on since then.  But, you know, linux people seem to pine for 1999 for some reason.15:00
perrito666natefinch: you do realize that if I did not spent so much time watching tv and movies that joke would have been completely lost on non english native speakers15:00
dimiternwallyworld_, jam1, the dns issue with api-endpoints for maas is not maas-related, it stems most likely from the changes in address selection logic (i.e. prefer hostnames to public/cloud-local IPs - the latter being most common with maas)15:08
katcosinzui: ping15:17
sinzuihi katco15:17
katcosinzui: good morning :)15:17
katcosinzui: i'd like to provide andreas with some binaries for tip of 1.2115:17
katcosinzui: what's the best-practice for doing so? i want to make sure he's testing what will eventually be b415:18
=== kadams54 is now known as kadams54-away
sinzuikatco, http://juju-ci.vapour.ws:8080/job/publish-revision/1254/ lists the binaries we built and tested15:19
sinzuikatco, , but there are no streams for these15:19
katcosinzui: that's probably _perfect_15:19
katcosinzui: i haven't wrapped my head around simple streams yet, but i suspect he could use these binaries to update his existing testing environment?15:20
ericsnowperrito666: FYI, that blocker is due to the hard-coded "machine-0" in the old restore :P15:21
sinzuikatco, --upload-tools is the only option.15:21
katcosinzui: hm. he can probably build a local environment if pressed.15:22
sinzuikatco, our testing streams are volatile, they are master at the moment. there were 1.21-beta4 for about 3 hours when those packges were made15:22
sinzuikatco, yes, the local env will be fine he just needs the state-server and two services15:23
katcosinzui: i'm pretty confident in that use-case. but i want to make sure it works for his more complex example15:23
perrito666ericsnow: well, i told you that there was no guaranteeof compatibility with thenew backup15:23
ericsnowperrito666: I'm expecting that the new restore will break in the same way (under HA)15:24
bacsinzui: i am able to reproduce bug 1398820 and have added more information.15:24
mupBug #1398820: destroying Azure environment took down other environment <azure-provider> <destroy-environment> <juju-core:Triaged> <https://launchpad.net/bugs/1398820>15:24
perrito666ericsnow: most likely, but it is waaaay easier to fix15:24
ericsnowperrito666: easier to test at least :)15:25
bacsinzui: due to documented loss of user data (the blunder cost us 10 engineer hours and denied 12 engineers the use of our landing automation for five hours) i'd suggest it be marked critical.  a work-around after-the-fact is not very useful.15:26
perrito666ericsnow: inded15:26
sinzuithank you bac15:26
voidspacedimitern: one of your suggestions15:31
voidspacedimitern: adding the following to the comment for the State.IPAddress method "with the given value."15:31
voidspacedimitern: you don't think it's entirely obvious that one returned will represent the value you pass in?15:31
dimiternvoidspace, yeah, I really meant to say "missing full-stop"15:32
voidspacedimitern: heh, you got me on that one.15:32
voidspacedimitern: cool15:32
dimiternvoidspace, in general doc comments should be proper sentences when possible I think15:33
voidspacedimitern: ok, I've never been quite sure.15:33
voidspacedimitern: I'll stick to that from now on. Easy enough.15:33
dimiternvoidspace, cheers15:33
alexisbdimitern, ping15:39
dimiternalexisb, hey15:40
dimiternalexisb, just replying to your mail btw15:40
alexisbhey there dimitern15:40
alexisbnws, no rush on that15:40
alexisbI saw some of your irc chatter earlier; are you working this bug:15:41
mupBug #1397376: maas provider: 1.21b3 removes ip from api-endpoints <api> <cloud-installer> <fallout> <landscape> <maas-provider> <juju-core:Triaged> <juju-core 1.21:Triaged> <https://launchpad.net/bugs/1397376>15:41
dimiternalexisb, I did investigate the issue - it seems like a juju-specific regression (if you can call it that, since it was never documented nor claimed anywhere api-endpoints should return IPs instead of hostnames)15:42
alexisbdimitern, given it is currently marked as critical and blocking the 1,21 release we need to decide on a path forward and get it resolved15:43
dimiternalexisb, there are several possible solutions15:44
dimiternalexisb, and I prefer to have the same one across all providers, i.e. always return a usable IP as first endpoint (if we only have a hostname try resolving it first)15:45
dimiternalexisb, I'll add a comment to the bug15:45
alexisbdimitern, thank you15:45
dimiternalexisb, and propose a fix + backports15:46
alexisbmake sure to make it clear if you are looking for a response from the bug commiter, etc15:46
=== jog_ is now known as jog
voidspacedimitern: instead of enforcing that InterfaceId or MachineId can only be set once15:49
voidspacedimitern: how about we only do it once?15:50
voidspacedimitern: if we do that then the check is unnecessary. If we *need* to do it more than once then the code is actually a hindrance.15:50
voidspacedimitern: so at *best* the code is useless... IMO15:50
* fwereade_ swears at the jujud tests and kicks things for a bit15:51
dimiternvoidspace, how can you guarantee it's only once15:51
voidspacedimitern: by only doing it in one place15:51
voidspacedimitern: by understanding the code15:51
voidspacedimitern: if we attempt to do it more than once and it fails juju will have problems due to a code path that stops15:51
voidspacedimitern: so we need to do that *anyway*15:51
voidspacedimitern: I can add an assert, it's easy enough15:52
voidspacedimitern: I'm just not convinced it's very useful, and may actually be the opposite of useful (at which point we just take it out again)15:52
alexisbfwereade_, I see you are having a good evening ;)15:52
fwereade_alexisb, a delight, as always :)15:52
=== kadams54-away is now known as kadams54
dimiternvoidspace, ok, let's think about it for a bit15:58
dimiternvoidspace, the reason we have similar "hard states", e.g. once a machine is provisioned it can't be "unprovisioned", is because these steps happen at different times and more importantly in different workers16:00
voidspacedimitern: right16:01
voidspacedimitern: in our case an IP address will be requested *for* a machine16:01
voidspacedimitern: so nothing else will attempt to use it16:01
voidspacedimitern: and once allocated the MachineId will be set16:01
voidspacedimitern: so there's no use case for changing it, but nor is it possible that something will try16:02
dimiternvoidspace, yeah, it seems reasonable to bind setting state to allocated with setting the machine id16:02
dimiternvoidspace,  how about having a AllocateTo(machineId, interfaceId) method ?16:03
voidspacedimitern: instead of individual setters - ok.16:04
voidspacedimitern: to add the asserts I need to get rid of omitempty it would seem16:04
voidspaceI *would* need to get rid of omitempty16:04
dimiternvoidspace, it asserts the state is unknown and machine / interface ids are empty before setting state to allocated + mid +iid16:04
dimiternvoidspace, yeah - omitempty should go on both ids16:05
voidspacedimitern: so you still want the asserts...16:05
voidspaceto protect us against something that can never happen... :-p16:05
voidspaceI should sprinkle anti-polar-bear dust around the code as well just in case16:06
dimiternvoidspace, imagine multiple workers trying AllocateTo() in parallel16:06
voidspacedimitern: but they'll be given different ip addresses16:06
dimiternvoidspace, true16:06
voidspacetechnically there's a race between fetching the full set of existing addresses and generating a new one16:07
dimiternvoidspace, ok, at least let's have an error when it's already allocated16:07
voidspaceok :-)16:07
dimiternvoidspace, indeed, that's why we need to assert the txn-revno of ipaddressesC haven't changed since we fetched them :) - good point16:08
voidspacea fair compromise and that will protect against the race16:08
voidspacewe should do that in the code that generates the ip address16:08
dimiternvoidspace, but that's relevant to the picking algorithm16:08
dimiternvoidspace, yep16:08
katcovoidspace, dimitern: not sure if this is how fwereade_ intended this to be used, but the new leasing stuff will provide a sort of "environment mutex"16:09
katcowhere you could say, "i'm mucking in the ip addresses, give me that lease"16:10
dimiternvoidspace, so AllocateTo() returns nil on success or - say ErrAlreadyAllocated with message "IP "" is already allocated to machine "1""16:10
katcoand then when others would like to know about ip addresses they could grab that lease16:10
dimiternkatco, oh GIL ? :)16:10
dimiternor we can call it JIL instead :D16:10
katconot familiar with that term16:10
dimiternkatco, good to know16:10
fwereade_katco, I suspect that will not be a very happy pairing of components16:10
dimiternkatco, that's python's global interpreter lock16:11
katcoahh ok16:11
=== tvan-afk is now known as tvansteenburgh
katcofwereade_: thanks for chiming in :) i retract my suggestion! :p16:11
fwereade_katco, no worries :)16:11
fwereade_dimitern, voidspace: I'm not really up to date with what you're dicussing, btw16:12
fwereade_dimitern, voidspace: but txn-revno is a very big hammer to be using in general16:13
dimiternvoidspace, and the other method can be SetUnavailable(value) - returning some (doesn't have to be typed) error when the address is already unavailable16:13
dimiternfwereade_, we're discussing how to do the address allocation algorithm for containers16:14
dimiternfwereade_, creating a new placeholder doc in the ipaddresses collection with state "unknown" (similarly to local charm uploads), then allocating it (or failing) and changing the state to "allocated" or "unavailable" depending on the result16:15
perrito666natefinch: stand up?16:16
voidspacedimitern: using txn-revno would also prevent *another* address being allocated16:16
natefinchperrito666: momentarily16:16
dimiternvoidspace, correct16:17
fwereade_voidspace, dimitern: I'm probably being dense, but txn-revno on what doc exactly?16:17
voidspacefwereade_: ipaddresses - a new one16:17
dimiternfwereade_, voidspace, on the new ipaddresses collection Michael is doing now16:17
fwereade_voidspace, so the documents in that collection will be one-to-one with machines?16:18
dimiternfwereade_, it will contain all machine addresses juju knows about16:18
fwereade_dimitern, not just one doc with all addresses, surely?16:18
dimiternfwereade_, yes - machines and network interfaces16:18
fwereade_dimitern, that will be a hell of a bottleneck16:19
dimiternfwereade_, wow, that haven't occurred to me *lol*16:19
fwereade_dimitern, even without txn-revno, all writes will be serialized16:19
dimiternfwereade_, right, so txn-revno is no good then16:20
dimiternfwereade_, we can't just fetch all addresses, pick a random in the same range, not yet existing, then create it asserting the collection hasn't changed16:21
katcofwereade_: forgive my ignorance, but doesn't this really sound like an environmental mutex would be helpful? what am i missing?16:22
dimiternkatco, how is that mutex supposed to work?16:22
fwereade_dimitern, voidspace: I am most likely misunderstanding the problem -- but I'm not following who needs to allocate these addresses?16:23
fwereade_dimitern, voidspace: surely in the general case we are asking the provider for new addresses, aren't we?16:23
voidspacefwereade_: no16:23
katcodimitern: well, the lease service is a fifo stack; 1 exists per state machine, and only 1 person can own a lease for a namespace at a time16:23
voidspacefwereade_: for "reasons"16:24
voidspacefwereade_: let me remember specifically16:24
dimiternfwereade_, no, we're asking for a specific address16:24
voidspacefwereade_: with ec2 we can request they give us a new address - but they don't tell us what it is16:24
voidspacefwereade_: so we then have to look on the network interface and find "the new address"16:24
voidspacefwereade_: and if we do that in parallel (adding several machines to an interface) we have race conditions working out which one is for which machine16:25
dimiternfwereade_, yeah - ec2 is quite unhelpful and most providers allow you to request a specific address to allocate16:25
voidspacefwereade_: but both ec2 and maas (and openstack but we only initially care about ec2 and maas)16:25
fwereade_voidspace, dimitern: oh, what fun16:25
voidspacefwereade_: will allow us to pick an address and request that specific one16:25
voidspacefwereade_: so we're generating and storing allocated addresses16:25
dimiternfwereade_, and keeping track which machine uses them, or marking them as unavailable (i.e. something else uses it, we'll try another but remember this)16:26
fwereade_voidspace, dimitern: ok, so, to try to restate in my own words16:26
fwereade_voidspace, dimitern: an example would be: you have machine N, with a bunch of containers N/lxc/A,B,C16:27
fwereade_voidspace, dimitern: something running in the agent for machine N observes that there are 3 new addresses available, and needs to assign them to the appropriate containers?16:28
fwereade_voidspace, dimitern: or have I completely misunderstood the context?16:28
* fwereade_ suspects he completely has16:29
voidspacefwereade_: it's more that we notice there are three new containers, we need to create three new addresses16:30
voidspacefwereade_: more likely we will try to create one address three times16:30
dimiternfwereade_, yeah - that thing will be the container provisioner most likely, but it won't notice the new addresses, it will request them and allocate them to each container, so that the address updater (after this happens) can see the machine has 4 IPs (as seen via the cloud api) but only 1 IP is for the machine (already allocated) the rest are for the containers16:30
voidspacefwereade_: if we arean't picking the addresses ourself, but we have a worker that requests an address and then has to work out what the new one is16:30
voidspacefwereade_: if that happens three time in parallel - when the worker checks the network interface and sees three new addresses, how does it know which is the "new one"16:31
fwereade_dimitern, that cannot be the container provisioner, can it?16:31
fwereade_dimitern, we don't want to give it the cloud credentials necessary to ask for the addresses16:31
dimiternfwereade_, it won't talk to the cloud directly, obviously the api will be used16:32
fwereade_dimitern, ok cool :)16:32
fwereade_dimitern, not 100% sure it's the container provisioner then? but, ehh, that's an irrelevant detail at this point I guess16:33
dimiternvoidspace, fwereade_, so effectively: the apiserver will be creating ipaddresses docs, calling the cloud to allocate them and assigning them to their machineid16:33
dimiternvoidspace, fwereade_, that's a detail yes, we'll get there16:33
fwereade_dimitern, so, what we have at the moment is that the machiner calls SetMachineAddresses with all the addresses it knows about -- and presumably we'll keep on doing roughly the same thing? just doing so more often, and not in the machiner?16:37
marcoceppibac: building amulet now16:38
marcoceppiwill be released in about 20 mins16:38
bacthanks marcoceppi16:38
dimiternfwereade_, IIRC SetMachineAddresses discovers what's on the machine, not via the cloud api16:39
fwereade_dimitern, yes16:39
dimiternfwereade_, so it will be the same16:39
dimiternfwereade_, the address updater is problematic and has to be fixed carefully to separate container addresses from host addresses when refreshing the instance info from the cloud16:41
fwereade_dimitern, and we also get a stream of SetAddresses~s coming from the instanceupdater as well16:41
fwereade_dimitern, how *can* we separate them? what's the difference between a provider address that was allocated for a container, and one that was allocated for the host machine?16:42
dimiternfwereade_, yeah - which in turn also calls SetAddresses at the end via the apiserver16:43
katcosinzui: we have confirmation that 1397995 is fixed in v1.21. discussions are ongoing about expected behavior, but that's just a spec thing, not a bug.16:43
dimiternfwereade_, ha! there's the beauty of it :)16:43
sinzuikatco, \o/16:43
katcosinzui: tyvm for your efforts and assistance. you did a great job! :)16:43
dimiternfwereade_, because we pre-allocate the address we know what it is and for which machine id (or container) it's allocated before the container starts16:44
fwereade_dimitern, ok, so we (could) have a provider id for each address that comes in via the instanceupdater?16:44
dimiternfwereade_, I think the least painful way to resolve all these is to change state.Machine.SetAddresses() internally to do the separation considering what's in ipaddressesC16:45
dimiternfwereade_, by provider id you mean instance id in this case?16:45
fwereade_dimitern, no? I think I mean a provider id for the address16:46
dimiternfwereade_, there's no specific id - the IP itself is the key - at least in maas, openstack and ec216:46
fwereade_dimitern, instance id is not a problem, is it? we know which *host* machine already because it's 1:1 with instances16:46
fwereade_dimitern, I am suspicious that there is an implicit assumption that those addresses won't change16:47
fwereade_dimitern, which does not gel with what I understand ec2 in particular is likely to do to you if you suspend your instances for a bit16:48
dimiternfwereade_, it depends on how the instance was started (i.e. the termination behavior) - we don't do suspend/resume ourselves16:51
fwereade_dimitern, ok, I am still questioning the assumption that addresses won't change16:52
fwereade_dimitern, eg when an AZ falls over for a bit I would like it if we were able to absorb that when everything was running again16:53
voidspaceevilnickveitch: ping16:59
evilnickveitchvoidspace, hey17:00
voidspaceevilnickveitch: hey17:00
voidspaceevilnickveitch: you just sent me an email about juju docs17:00
voidspaceevilnickveitch: I suspect it was intended for someone else...17:00
evilnickveitchvoidspace, oops - sorry! I am blaming gmail autocomplete17:01
voidspaceevilnickveitch: :-)17:01
dimiternfwereade_, the address won't change *at will*17:03
dimiternfwereade_, it will happen due to some specific user action - i.e. stopping an instance and restarting it perhaps - juju should be able to detect this and know how to handle it17:04
dimiternfwereade_, an address that was allocated (reserved, in-use, whatever) cannot be reused by any other node on the same subnet (except for some weird clustering/balancing/etc. on L2)17:06
dimiternfwereade_, a machine can get a new (allocated) address and become unreachable under the old one, but the old one won't just appear on some machine (as long as the machine is up)17:07
fwereade_dimitern, no arguments there... the problem STM to be that i-abc123 can reasonably return 2 non-overlapping sets of IPs in two consecutive requests to the provider17:08
fwereade_dimitern, and if we don't have some notion of what the underlying provider id of a given IP is, we can't cleanly map the first set onto the second17:08
fwereade_dimitern, (that said, I believe that the underlying provider ids do not necessarily exist -- I'm not saying you should find them, but I am fixating on the nasty edge cases that I think I can see)17:09
fwereade_dimitern, in general it's not outside the bounds of probability that we might see, for a single machine17:10
dimiternfwereade_, I understand the problem and appreciate you bringing it up - I'll make sure we do have tests for such cases17:10
fwereade_dimitern, SA: a; SMA: b; SA: c, d; SMA: e,f17:11
fwereade_dimitern, cool17:11
fwereade_dimitern, have I just been massively derailing you then? :(17:11
dimiternfwereade_, shouldn't we prefer addresses discovered on the machine rather than the ones coming via the cloud api?17:12
fwereade_dimitern, it still sort of feels like the problem you're talking about is "how do we reconcile these streams of addresses from two different sources"17:12
fwereade_dimitern, hmm17:12
fwereade_dimitern, I *think* the cloud api is more likely to give us usable addresses, isn't it?17:12
fwereade_dimitern, like how in address-get we want to return the advertise address rather than the bind address?17:13
dimiternfwereade_, no, it's very useful as I did have much time to think in detail about how to solve the 2 address sources problem17:13
fwereade_dimitern, I assert <wave hands vigorously> that what the cloud tells us is more likely to correspond to the addresses which will cause the traffic to be delivered to the right place17:13
dimiternfwereade_, well, if the cloud *thinks* node A uses IP1, but eth0 on A says IP2, the latter will be usable (all other things equal - i.e. no restrictive firewalling/routing for IP1 vs IP2)17:14
dimiternfwereade_, yeah17:14
fwereade_dimitern, my concern is exactly that all other things will not be equal17:15
dimiternfwereade_, at some point we'll need a way to actually *verify* a given node's IP is usable (inbound and out)17:16
fwereade_dimitern, eg when you expose something to the public internet, you need to advertise the public address that will get the packets to the right place, which is not necessarily the one you're binding to at all17:16
fwereade_dimitern, that's a nice-to-have where it's practical17:16
dimiternfwereade_, until then I guess trusting the cloud makes more sense17:16
fwereade_dimitern, but I'm not sure it's something we can depend on in all cases17:17
fwereade_dimitern, in particular17:17
fwereade_dimitern, these thorny sorts of questions17:17
fwereade_dimitern, are why I'm keen that we continue to record the stuff that gets set via SA/SMA unchanged17:17
dimiternfwereade_, the "just-in-" case :)17:18
fwereade_dimitern, and we recalculate our best guess at reality, taking *both* of those things into account, in response to a change in either17:18
voidspacedimitern: when you have a minute (shouldn't take any longer) can you check the implementation of AllocateTo17:19
voidspacedimitern: http://reviews.vapour.ws/r/564/17:19
voidspacedimitern: all issues resolved17:19
dimiternfwereade_, right, but the ips known to be allocated should be used when needed, while the SA/SMA ones only when they change17:19
dimiternvoidspace, sure, will look shortly17:19
dimiternfwereade_, (the IPs in ipaddressesC I mean)17:20
fwereade_dimitern, true -- the providers that *do* tell us what IPs they've allocated should probably be trusted over and above the SA/SMA ones17:20
dimiternfwereade_, what if the cloud says node A's IP is now b (used to be a)? Should we also ensure SMA reports b as well? (I mean reconfigure the interface on the machine)17:22
fwereade_dimitern, I have literally no idea, I'm afraid :(17:23
fwereade_dimitern, I suspect "it depends" but I don't really know what on17:24
dimiternfwereade_, and also how often/when this is possible17:24
dimiternvoidspace, reviewed17:38
dimiternvoidspace, I'm ok with moving subnet method tests from state_test.go into a new subnets_test.go as a follow-up17:38
alexisbdimitern, you joining the networking call?18:01
voidspacedimitern: ok18:06
voidspacedimitern: thanks, still a few things to fix18:07
voidspacedimitern: do we *need* DeepEquals for comparing structs?18:08
voidspacedimitern: I wasn't sure18:08
natefinchequals will work for simple structs that don't have, for example, maps or slices in them18:09
voidspacenatefinch: and if it doesn't work it should complain, right?18:10
voidspacenatefinch: as it worked I didn't feel the need to use DeepEquals18:10
voidspacenatefinch: so no reason to prefer jc.DeepEquals over gc.Equals if it's not required?18:11
natefinchvoidspace: there's probably no reason not to use DeepEquals, the difference in speed is going to be negligible..... trying to think if there might be a reason why Equals would be preferred...18:15
voidspacenatefinch: heh, your answer is the opposite of what I asked :-)18:18
natefinchvoidspace: my point is, jc.DeepEquals should always work, so there may be no reason to ever use gc.Equals unless you're doing a very large number of comparisons.  If one way always works, and one way usually works... why not just always use the way that always works?18:23
voidspacenatefinch: because I already have a way that works and I need a reason to swap...18:24
voidspacenatefinch: I understand what you're saying though18:25
natefinchvoidspace: if it works, it works, don't muck with it ;)18:26
voidspacemy thoughts exactly :-p18:26
voidspaceI'll start using jc.DeepEquals just to not have to ever have this conversation again...18:26
dimiternvoidspace, it's good to use DeepEquals for structs, otherwise you might end up comparing .String() or .GoString() values18:27
voidspacedimitern: ah, so there is a reason18:27
voidspacedimitern: when would that happen?18:27
dimiternvoidspace, it depends on how the Equals checker is implemented I guess18:32
dimiternvoidspace, can't really say without experimenting a bit18:32
dimiternvoidspace, I tend to use DeepEquals (the jc version, not the gc one as it prints more comprehensive error messages with deeply nested structs / long maps, etc.)18:34
dimiternvoidspace, ..for anything than a simple type18:34
voidspacedimitern: better failure messages is a good reason to prefer it18:34
dimiternvoidspace, but maybe it's just me being paranoid :)18:35
voidspacedimitern: when adding a new test file is there anything else I need to do?18:35
voidspacedimitern: it doesn't look like my tests are being run18:35
voidspaceas in, I inject a failure and nothing fails18:35
dimiternvoidspace, yeah :)18:35
dimiternvoidspace, register the suite18:35
voidspaceor something elsse?18:36
dimiternvar _ = gc.Suite(&machineSuite{})18:36
voidspacethat's there18:36
=== kadams54 is now known as kadams54-away
dimiternvoidspace, and no tests run still?18:37
voidspacedoesn't look like it18:37
voidspacepackage is state_test, file is state/subnet_test.go18:37
=== kadams54-away is now known as kadams54
voidspacehmmm... maybe it should be subnets_test.go18:38
voidspacedimitern: does each test file need to match a source file?18:38
dimiternvoidspace, yeah, but that shouldn't matter18:39
voidspacedimitern: you're on late18:39
dimiternvoidspace, btw - see this http://paste.ubuntu.com/9356541/18:39
voidspacedimitern: fair enough :-)18:39
voidspacehmmm... but the ipaddresses_test is definitely being run18:40
dimiternvoidspace, even though I added a .GoString() method on network.HostPort to shorten the output considerably (from network.HostPort{Value:, Port:42, ...} to
dimiternvoidspace, hmm.. let me see if something else was needed18:40
dimiternvoidspace, I'm on since 7am :)18:41
dimiternreally need to stop soon18:41
dimiternvoidspace, can you paste your complete subnets_test.go ?18:42
voidspacedimitern: http://pastebin.ubuntu.com/9356566/18:42
voidspacedimitern: there's a deliberate error in assertSubnet inside TestAddSubnet (first test)18:43
voidspacethat should fail18:43
dimiternvoidspace, you don't need to embed ConnSuite, do you?\18:44
voidspacedimitern: StateSuite does, which is what I copied for this and IPAddressSuite18:44
voidspaceif we can get rid of it then cool18:44
dimiternvoidspace, hmm.. no sorry - you need it18:44
voidspacewe need s.State18:44
dimiternvoidspace, yeah18:45
voidspaceI've renamed to subnets_test.go18:45
voidspacethat didn't help18:45
dimiternvoidspace, why do you have that s.policy.GetConstraintsValidator in SetUpTest?18:45
dimiternvoidspace, HA!  found it18:46
dimiternvoidspace, a single character is needed :)18:46
voidspacego on18:47
dimiternvoidspace, var _ = gc.Suite(&SubnetSuite{}) - instead of var _ = gc.Suite(SubnetSuite{}) - all methods have pointer receivers18:47
voidspaceof course18:47
voidspaceit registers an empty one18:47
dimiternno worries18:47
dimiterni'll be off then :)18:47
voidspacedimitern: g'night18:48
dimiternvoidspace, g'night18:48
voidspaceI'm off too18:58
voidspaceg'night all18:58
ericsnownatefinch: could you take a look at http://reviews.vapour.ws/r/577/19:50
ericsnownatefinch: (and http://reviews.vapour.ws/r/573/ too) :)19:50
ericsnownatefinch: that first one fixes the blocker19:50
natefinchericsnow: cool, looking19:50
thumperjw4: ping19:57
thumperjw4: I actually have a branch that fixes one of the actions bits https://github.com/juju/juju/pull/1261/files19:57
thumperjw4: may clash with your dependency update too19:57
thumperjw4: interesting that both our solutions were identical - completely identical :-)20:01
natefinchericsnow: a couple small concerns, but nothing too hard to fix.20:12
ericsnownatefinch: k20:12
=== kadams54 is now known as kadams54-away
ericsnownatefinch: I've addressed your comments20:35
natefinchericsnow: looking20:38
ericsnownatefinch: keep in mind that cmd/plugins/juju-restore/restore.go is going away, so it probably isn't worth nitpicking there :)  For that file I just want to be sure I have the logic right since there isn't any simple way to test it20:40
thumperericsnow: I did a review too, nothing to add20:41
thumperericsnow: I'd wait for natefinch's LGTM before landing though20:41
ericsnowthumper: thanks :)20:41
ericsnowthumper: will do20:41
natefinchericsnow: I just gave it a shipit :)20:41
ericsnownatefinch: thanks20:42
* thumper awaits an unblocked laner20:42
natefinchthumper: while you're waiting, do you have some time to talk about provider configuration?   I'm porting fwereade_'s skeleton provider from 10-months-ago juju to today-juju, and some of the internals bug me.  He thought you might have some insight.20:43
thumpernatefinch: make a hangout20:43
natefinch thumper: https://plus.google.com/hangouts/_/canonical.com/moonstone?authuser=120:45
ericsnowdavecheney: I was just reading through your functional options talk (very interesting)21:00
ericsnowdavecheney: do you think there are any spots that could stand to benefit from functional options in juju?21:00
ericsnowdavecheney: would it be a good approach for pulling in the different paths that need to be backed up (I think mattyw was hinting at this a while back)21:02
davecheneyericsnow: sure21:02
davecheneyi think there are a few places we could use it21:02
jw4thumper: thanks!21:09
davecheneyok, time for breakfast21:11
davecheneythen, REVIEWING!21:11
thumperericsnow: did you see that your branch failed early?21:21
ericsnowthumper: yeah, fixing it now21:21
* thumper wants to land stuff21:21
thumperanastasiamac: I'm reviewing your mega branch21:52
thumperanastasiamac: done21:58
ericsnowanyone know how to force a CI test to run (functional-ha-backup-restore, specifically)?22:02
ericsnowthumper: my fix landed but I hesitate to mark the bug as committed until the CI test (functional-ha-backup-restore) runs22:02
thumperericsnow: I think they happen automatically22:03
jw4fix committed won't clear CI til it's marked as fix released22:03
thumperericsnow: and marking the bug fix committed doesn't release the bot22:03
ericsnowthumper: right22:03
ericsnowthumper, jw4: thanks for clarifying22:03
perrito666interesting, windows does not run update as an atomic process22:42
* perrito666 has an install running in a machine next to him that installed 170 packages, failed on the 171 and just rolled back the whole thing... this all thing took 4 hs22:43
jw4thumper: https://bugs.launchpad.net/juju-core/+bugs?field.searchtext=&orderby=-importance&field.status%3Alist=NEW&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&field.status%3Alist=FIXCOMMITTED&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&field.importance%3Alist=CRITICAL&field.tag=ci+regression+&field.tags_combinator=ALL22:44
jw4thumper: when that list is empty CI will be unblocked22:44
* thumper sighs22:44
* thumper waits22:44
jw4thumper: I personally use https://api.launchpad.net/devel/juju-core?ws.op=searchTasks&status%3Alist=Triaged&status%3Alist=In+Progress&status%3Alist=Fix+Committed&importance%3Alist=Critical&tags%3Alist=regression&tags%3Alist=ci&tags_combinator=All22:44
thumperhandy link22:45
* jw4 has had code to land for a week now22:45
perrito666davecheney: do you feel answered by my email? I was not sure if you answered the review with an email or added a review and then deleted it23:16
perrito666natefinch: fwereade_ ericsnow you should all have a mail with the shared draft for b&r specs23:17
=== kadams54-away is now known as kadams54
=== kadams54 is now known as kadams54-away
anastasiamacthumper: thnx for the review!!!23:31
wallyworld_davecheney: i think you're ocr? you able to take a look at http://reviews.vapour.ws/r/552/ for me?23:31
=== kadams54-away is now known as kadams54
davecheneywallyworld_: looking23:54
davecheneyperrito666: could you summarise the state of play for me23:55
davecheneyi'm unclear what or if there is a problem23:56
davecheneywallyworld_: on a scale of 1 to "don't be picky dave", is the importance of this PR ?23:58
wallyworld_davecheney: i would like to land but if there are issues, record them23:58
davecheneywallyworld_: URGH params.StateServingInfo23:59
davecheneythat fucking type23:59
davecheneysuch a mess23:59

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