#juju-dev 2012-10-22
<davecheney> hola!
<davecheney> who is in demark ?
<davecheney> joy, my airplane to frankfurt is 22 ... http://www.aussieairliners.org/b-747/vh-oji/vhoji.html
<davecheney> it gets better
<davecheney> http://www.atsb.gov.au/publications/investigation_reports/2003/aair/aair200304815.aspx
<fwereade> TheMue, morning
<TheMue> fwereade: heya
<TheMue> hmm, online checkin doesn't work
<niemeyer> Hello there
<fwereade> niemeyer, heyhey
<fwereade> niemeyer, I presume you're already in a nearby timezone :)
<niemeyer> fwereade: Indeed :)_
<fwereade> niemeyer, tolerable travel?
<niemeyer> fwereade: It was pretty good all things considered.. uneventful long trip
<fwereade> niemeyer, good-o
<TheMue> niemeyer: meya
<TheMue> s/meya/heya/
<niemeyer> TheMue: Yo
<niemeyer> When are you all coming over?
<TheMue> niemeyer: I'm flying on Wednesday very early. We have a local airline providing a direct flight of about 1h.
<niemeyer> TheMue: Ah, nice
<TheMue> niemeyer: Indeed. But we'll see where the January sprint will be. ;)
<niemeyer> TheMue: I came through Frankfurt coincidently
<TheMue> niemeyer: Ah, the most important airport for international flights in Germany.
<TheMue> niemeyer: Haven't been there for a longer time. Last flights have been via Munich or Amsterdam.
<fwereade> niemeyer, this should be trivial: https://codereview.appspot.com/6736058
<niemeyer> fwereade: Looking
<niemeyer> fwereade: A couple of comments containing the content we're trying to match might be useful
<fwereade> niemeyer, good point, thanks
<niemeyer> fwereade: Not sure about what this matches, for example: ([0-9a-
<niemeyer>       z-/ ]+)
<niemeyer> fwereade: (a space?)
<fwereade> niemeyer, yeah, it's the relation ID if present
<fwereade> niemeyer, I shall bulk up the explanations
<niemeyer> fwereade: Thanks.. I felt like I wouldn't know what the intention there really is if I had to fix/change it somehow
<fwereade> niemeyer, (oh, sorry, wrong bit: *that* is the remote unit if present)
 * fwereade remakes niemeyer's point
<TheMue> niemeyer: I think I now have the right firewaller approach but not yet a clue how to test it best (todays unit tests work). I would like to propose it so you can take a look. OK?
<niemeyer> TheMue: I'd prefer if you could actually figure testing out first.. we'll have to talk about it anyway, and it's not clear yet what slot size I'll find here
<TheMue> niemeyer: ok
<niemeyer> TheMue: Think about the use cases you're exercising.. the things I've mention would break your previous implementations are good use cases to encode in the test
<niemeyer> TheMue: To start with..
<niemeyer> s/mention/&ed/
<TheMue> niemeyer: Yeah, I have the use case in mind. Have to see how I simulate it best.
<niemeyer> TheMue: A as-small-as-possible test case that exercises exactly the problems described sounds like a good start
<niemeyer> TheMue: Should watch out to avoid copying test logic that is not really relevant for the specific use case being exercised
<TheMue> niemeyer: Yes, will keep it small.
<wrtp> fwereade: ping
<wrtp> TheMue: ping
<TheMue> wrtp: pong
<wrtp> TheMue: you don't happen to know anything about TLS and x509 do you? :-)
<TheMue> wrtp: sorry, almost nothing, yes
<TheMue> ;)
<wrtp> TheMue: thanks. i had to ask :-)
<wrtp> TheMue: i've got a bit further with my example, but it's still failing
<TheMue> wrtp: the one from G+?
<wrtp> TheMue: yes
<wrtp> TheMue: it does actually run in the playground now: http://play.golang.org/p/arjFhqvpWU
<TheMue> wrtp: I'll look deeper in a few moments, my wife needs me.
<wrtp> TheMue: it's no problem. i'm already quite deep into it!
<mreed> Can anyone shed any insight as why I may be getting a zookeeper.Session.Expired Error?  I am deploying a stress test, but I typically cannot see the completion of the test via juju debug-log before the timeout.
<wrtp> TheMue: got it working, finally (with a little help from agl): http://play.golang.org/p/Z5Jn4Qykk4
<TheMue> wrtp: Great. The list of imports reads weird. ;)
<wrtp> TheMue: why so?
<TheMue> wrtp: The large number.
<wrtp> TheMue: this bit of go crypto is a bit of a nightmare tbh
<TheMue> wrtp: Seldom seen it in one package or program..
<TheMue> wrtp: I so far only used the Rand()
<wrtp> TheMue: i imagine it's one of the more complex programs that's run in the playground...
<TheMue> wrtp: +1 yes
<wrtp> TheMue: rand is fine. crypto/cipher is nice too. but the legacy stuff (x509, tls, etc) is horrible
<wrtp> TheMue: so many special cases
<wrtp> TheMue: so many half-general (half-assed!) things
<TheMue> wrtp: *rofl*
<wrtp> right, i'm off
<wrtp> see y'all tomorrow! yay!
#juju-dev 2012-10-23
<TheMue> morning
<fwereade> TheMue, heyhey
<fwereade> TheMue, http://ec2-23-20-89-179.compute-1.amazonaws.com/?page_id=2
<TheMue> fwereade: whow, great
<TheMue> fwereade: hello btw ;)
<TheMue> fwereade: typical two nodes running wp and mysql?
<fwereade> TheMue, yes indeed :D
<TheMue> fwereade: fantastic
<fwereade> TheMue, first live test and it appears to actually *work*
<TheMue> fwereade: yes, already clicking around
<fwereade> TheMue, it's admin/blah if you want to play around some more
<fwereade> TheMue, I need to go and actually prepare for my trip ;)
<TheMue> fwereade: when does your flight start?
<fwereade> TheMue, er, 4ish
<TheMue> fwereade: ok, mine is tomorrow morning from 7:15 to 8:30, Copenhagen is pretty near ;)
<fwereade> TheMue, nice :)
<TheMue> fwereade: yes
<fwereade_> and, holy crap, wordpress has a peer relation and that appears to work too
<fwereade_> right, really not on any more, take care all
<davecheney> wow!
<davecheney> these rooms are ... um ... personal
<TheMue> davecheney: heya
<TheMue> davecheney: nice rooms?
<davecheney> TheMue: they are, well, swedish is the only word I can describe
<davecheney> they are very nice
<davecheney> the whole place is brand new
<davecheney> but, i hope you chose your roomie wisely
<davecheney> 'cos you'll be seeing an aweful lot of them
<TheMue> davecheney: I've seen the website, looks â¦ hmmm â¦ special
<TheMue> davecheney: you see a lot of your roomie?
<davecheney> TheMue: you'll understand when you get here :)
<davecheney> speaking of which
<davecheney> WHY AREN"T YO UHEAR NOW
<davecheney> do I have to drink mojithos by myself ?
<TheMue> davecheney: it's a short flight of 1:15h, so asked Mark to fly tomorrow morning. touch-down is 8:30
<davecheney> ok
<davecheney> yeha, it would be trivial for you
<TheMue> davecheney: but I think there will be time enough for good drinks. and niemeyer is already there and fwereade_ starts at about 4pm
<davecheney> it was only 70 mins from frankfurt
<davecheney> right, well, i'll see if I can find them
<TheMue> davecheney: we have a local airline with a direct flight here, the drive to the airport and the check-in last longer than the flight
<fwereade_> TheMue, davecheney, I get in lateish, I forget exactly when
<davecheney> fwereade_: crap
<davecheney> drinks start at 7pm tonight
<davecheney> TheMue: tell me about it
<fwereade_> davecheney, I land at 2145 :(
<davecheney> the taxi'ing in frankfurt was as long as the flight
<davecheney> anyhoo
<davecheney> i'm off to check out the conference facility
<davecheney> i will see you guys around
<TheMue> davecheney: enjoy
<wrtp> TheMue: yo!
<TheMue> wrtp: Hi, already there?
<wrtp> TheMue: no, unfortunately we're sitting on the runway
<TheMue> wrtp: Just had lunch and now stepping out to fetch some DEK and SEK from the bank.
<wrtp> TheMue: looks like i'm probably going to miss my next flight
<TheMue> wrtp: Sitting on the runway? How shall any plane start then?
<TheMue> wrtp: Oh, shit.
<wrtp> TheMue: :-) alright, we're sitting *next* to the runway!
<wrtp> TheMue: bad weather in Heathrow means everything is delayed
<wrtp> TheMue: it's quite foggy here too
<wrtp> TheMue: they said there *should* be another later flight, but we will see
<TheMue> wrtp: And afterwards? Amsterdam or Frankfurt?
<wrtp> TheMue: copenhagen
<TheMue> wrtp: Yesterday Warsaw had chaos in the air due to fog.
<wrtp> TheMue: i think there's a lot around currently. various flights were cancelled here yesterday i heard
<wrtp> TheMue: still at least there's good data connectivity through my mobile phone!
<TheMue> wrtp: Huh? You talked about your next flight. It is Heathrow - Copenhagen directly?
<wrtp> TheMue: yes
<TheMue> wrtp: Ah, ic. Mine is BRE - CPH tomorrow morning too. Airtime ist 1:15h ;)
<wrtp> TheMue: did you see william's email to juju-dev? exciting news!
<wrtp> TheMue: what time do you arrive?
<TheMue> wrtp: Already played with his wordwpress. Great!
<TheMue> wrtp: At 8:30.
<davecheney> wrtp: yeah, gustavo told me at lunch
<davecheney> deploy all the things
<wrtp> davecheney: you're already there?
<TheMue> So, I'm back later. Otherwise no money :(
<wrtp> TheMue: i have no money yet...
<wrtp> TheMue: am relying on a cashpoint machine, hopefully
<wrtp> TheMue: woo, slot's come forward it seems, we set off in 5 minutes. only an hour and 10 minutes late. still don't think i'll make the next flight though.
<wrtp> see y'all there
<wrtp> hopefully before tomorrow
<davecheney> wrtp: yeah, got in about 11am
<davecheney> wrtp: you
<davecheney> you are shitting me, you sat on the tarmac for 70 mins 'cos the tower wouldn't let your plane take off ?
<davecheney> wow
<Aram> yo.
<Aram> mramm: what's up.
<mramm> not much
<mramm> Aram: I'm about to head down to the "meet and greet" meeting at the sprint
<wrtp> Aram: ping
<Aram> wrtp: yo
<wrtp> Aram: i'm not going to make it tonight, sadly
<Aram> ah, I wondered where you were :-).
<wrtp> Aram: you're there already, presumably?
<Aram> delayed plane?
<Aram> yes
<wrtp> Aram: yeah, my flight down was 1.5h late, and they couldn't get me a seat on either of the later flights
<wrtp> Aram: so i'm in a hotel near heathrow, a bit annoyed
<Aram> bummer
<wrtp> Aram: it's not even got free wifi...
<Aram> well this one doesn't have that stupid password :))
<Aram> it's all open wifi
<wrtp> Aram: yay!
<wrtp> Aram: upstairs as well?
<Aram> yes
<wrtp> Aram: cool, a hotel with sense
<Aram> now I'm trying to find a schedule or something on that dreaded wiki of ours.
<wrtp> Aram: please could you pass on my apologies to gustavo and the others
<Aram> sure.
<wrtp> Aram: now i think i'll go to the bar!
<Aram> cheers!
<wrtp> Aram: see ya tomorrow. i've got a 0650 flight - should arrive 10am ish.
<Aram> have fun
<wrtp> Aram: so will miss the first meeting, but hopefully make it for something or other
<wrtp> Aram: how long does it take from airport to hotel?
<Aram> wrtp: the train itself 15 minutes, probably 30 minutes with all ticketing and whatever overhead
<wrtp> Aram: cool, thanks
<wrtp> Aram: ttfn
#juju-dev 2012-10-24
<davecheney> mramm: yo
<davecheney> where you at ?
<Aram> hi davecheney, mramm
<Aram> any idea where breakfast is?
<davecheney> Aram: breakfast is on level 1
<davecheney> the in tower two
<Aram> thanks
<davecheney> up the stairs from the lobby
<Aram> davecheney: and where do we go after that?
<davecheney> Aram: walk out of the doors in the lobby
<davecheney> turn left, cross the road and follow the line of the building til you find the door to the conference center
<davecheney> there are a few signs that say 'canonical'
<Aram> thanks
<Aram> fwereade: http://paste.ubuntu.com/1302012/
<fwereade> Aram, thanks
<fss> hi everyone :-)
<fss> who could help me reviewing a goamz CL while niemeyer is out?
#juju-dev 2012-10-25
<davecheney> wrtp: where are you ?
<davecheney> come to the big cloud room
<wrtp> in the cloud room with the others
<wrtp> davecheney: ok
<wrtp> davecheney: what's up?
<davecheney> reviewing hte hundreds of bugs in py juju
<wrtp> will be over in a mo, if i can work out which is the "big cloud room" :-)
<niemeyer> fwereade:
<niemeyer> """
<niemeyer> When jujud has already opened the log file, and then panics, we just
<niemeyer> lose the panic output. So I think we do need this...
<niemeyer> """
<niemeyer> fwereade: Why would we lose?  That's not what append does, AFAIK
<fwereade> niemeyer, I just checked, and the output is nowhere to be seen -- and that fits with my intuition, that 2 things should probably not open the same file for writing
<fwereade> niemeyer, am I being stupid?
<niemeyer> fwereade: AFAIK, the reason for O_APPEND in *nix is precisely to handle that
<fwereade> niemeyer, hum, ok
<fwereade> niemeyer, I will try to figure out what I got wrong, and get back to you
<niemeyer> fwereade: If it's going to take too long, we can just move forward.. I expected it to be straightforward, though, and it's very handy to not have two files with the same name in the same directory.. we'll always have to type the extension otherwise
<fwereade> niemeyer, well, I did submit already, but I will see if I can figure out what I did wrong all the same :)
<fwereade> niemeyer, (ok, I can't figure out what I did wrong, but I clearly did -- using the same file works perfectly... sorry)
<davecheney> agent_test.go:294: c.Assert(string(data), Not(Equals), "spurious")
<davecheney> ... obtained string = "spurious"
<davecheney> ... expected string = "spurious"
<davecheney> o_O!
<niemeyer> davecheney: Type
<niemeyer> davecheney: Hmm.. whhaaa
<niemeyer> davecheney: Oh,
<niemeyer> davecheney: Not(Equals)
<davecheney> fair enough
<davecheney> that is a bit unhelpful
<davecheney> i'll fix it
<davecheney> wrtp: GOMAXPROCS=81 go test .../cmd/jujud will fail with an auth error very reliably for me
<davecheney> bootstrap_test.go:129: c.Assert(err, Equals, expectErr)
<davecheney> ... obtained = nil
<davecheney> ... expected *errors.errorString = &errors.errorString{s:"unauthorized access"} ("unauthorized access")
<davecheney> wrtp: http://paste.ubuntu.com/1304534/
<davecheney> wrtp: https://codereview.appspot.com/6767053
<davecheney> looking good in stress testing
<wrtp> cool
<davecheney> wrtp: now looking at https://bugs.launchpad.net/juju-core/+bug/1064142
<fwereade> davecheney, thank you, I've peered at that a couple of times and been totally unable to figure out what was actually happening in the ackground
<davecheney> fwereade: np, i'll come an nag you if I am confused
<fwereade> mramm, s/Availability/Available/
<fwereade> mramm, s/principle/principal/
<TheMue> fwereade: +1
<fwereade> mramm, I don't appear to have edit rights, that's the only reason I'm hassling you
<Aram> fwereade: please share the link to the google doc.
<fwereade> Aram, https://docs.google.com/a/canonical.com/document/d/1cm_JDMmk-uA15nSUf5Wz8icbBb4AmCOB-hoJZUfcgsE/edit#
<Aram> thanks
<fwereade> davecheney, where did you guys go, and should I be there?
<davecheney> most people went to carbo load
<davecheney> fwereade: https://bugs.launchpad.net/juju-core/+bug/1071320
<davecheney> ^ has been happening for a while
<davecheney> i am investigating now
<davecheney> (manly as I have no idea how to fix the previous issue)
<fwereade> davecheney, that aaaaaaaaaaaaaaaaaaa one? I hopefully assigned it to rogpeppe this morning
<fwereade> davecheney, interesting to see the panic on reset though
<davecheney> yeah, that is common for most of our tear down tests
<davecheney> it's not a concern
<fwereade> davecheney, ah, ok
<fwereade> davecheney, so the panics come after the failures in aram's problem? and are therefore not a cause of it?
<davecheney> yes
<fwereade> davecheney, ty, that is good to know
<davecheney> fwereade: https://codereview.appspot.com/6781043
<davecheney> ^ possible fix for aaa race
<fwereade> davecheney, I don't understand how https://codereview.appspot.com/6781043 works... but then I don't think I understood the original failure either :/
<fwereade> davecheney, rogpeppe may be a better reviewer...
<davecheney> fwereade: i belive that the hook is exiting before we even start the logger
<davecheney> but I am trying to understand that bad fd error better
<davecheney> logically thre is a chance logger.stop could be called before logger.run is scheduled
<davecheney> or the process could complete and exit before logger.run is scheduled
<fwereade> davecheney, ah, ok
<davecheney> the key in that proposal is it mitigates the problem
<davecheney> doesn't fix it
<davecheney> but mititgates it to a point that I was only able to reproduce the issue very infreqently
<davecheney> at which case other failures are taking precidence
#juju-dev 2012-10-26
<hazmat> console-output -> http://paste.ubuntu.com/1306529/
<rogpeppe> fwereade: trivial? https://codereview.appspot.com/6776051
 * fwereade looks
<Aram> rogpeppe: "The Elements of Style" uses quotation marks in the same way we use them for quoting subjects in error messages.
<Aram> it's elementary english usage.
<Aram> the use of quotes for expressing irony is unusual and more rare.
<rogpeppe> Aram: can you link to an example?
<fwereade> rogpeppe, yeah, I think it is trivial
<fwereade> https://codereview.appspot.com/6781043/
<davecheney> jynx!
<rogpeppe> http://www.informatics.sussex.ac.uk/users/adrianth/TEC99/paper.ps
<rogpeppe> davecheney: http://codereview.appspot.com/6789043
<davecheney> rogpeppe: yes, i saw
<davecheney> thank you
<rogpeppe> davecheney: try this: https://codereview.appspot.com/6774050
<fwereade> davecheney, is there some distinction between https://bugs.launchpad.net/juju-core/+bug/1071320 and https://bugs.launchpad.net/juju-core/+bug/1052836 of which I am unaware?
<davecheney> fwereade: no, just that it is hard to search for things in LP
<davecheney> even when I use the test name as the key
<davecheney> http://codereview.appspot.com/6734043/
<fwereade> niemeyer, would like a chat about Relation.Destroy shortly -- are you likely to be free in <5 mins, or can I slope off for a ciggie?
 * fwereade slopes off
<davecheney> PSA: appengine is totes broken
<davecheney> so reitveld is down
<niemeyer> mthaddon: http://pastebin.ubuntu.com/1307365/
<niemeyer> http://pastebin.ubuntu.com/1307377/
#juju-dev 2012-10-28
<rog> davecheney: what's up?
<davecheney> rog: gustavo and I are hackin' in the main conference area
<rog> davecheney: i was gonna do upload-tools soon if noone else got there first
<davecheney> rog: go for it, you sound like you have a plan for it
#juju-dev 2013-10-21
<dimitern> hazmat, ping
<hazmat> dimitern, pong
<dimitern> hazmat, we just finished the constraints in production usage
<dimitern> hazmat, we couldn't find you
#juju-dev 2013-10-22
<garyposter> whois gary_poster
<Makyo> A question we all ask ourselves, sometimes...
<davecheney> who has the link ?
<davecheney> thumper: link pleaes
<thumper> davecheney: https://docs.google.com/a/canonical.com/document/d/1Xo905HSVWwX4lVMfRQUzH-y2QwWLU4MLZOfsHHoOBNg/edit#heading=h.qo9grsysujqc
#juju-dev 2013-10-23
<mgz> wallyworld: https://codereview.appspot.com/14930049
<davecheney> dimitern: https://github.com/davecheney/socksie
<rogpeppe1> mgz: test failure
<mgz> smoser: https://codereview.appspot.com/15060051
<mgz> this does need some actual live testing, as I can't really unit test that the key is correct I think...
#juju-dev 2013-10-24
<mgz> dimitern: any luck?
<dimitern> mgz, bitesize juju 14.04 spreadsheet https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0At5cjYKYHu9odDJTenFhOGE2OE16SERZajE5XzZlRVE#gid=1
<mgz> sinzui: https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0At5cjYKYHu9odDJTenFhOGE2OE16SERZajE5XzZlRVE#gid=1
<dimitern> mgz, https://docs.google.com/a/canonical.com/document/d/1Gu422BMAJDohIXqm6Vq4WTrtBV8hoFTTdXvXDQCs0Gs/edit#heading=h.k0og9vg5z38e
<mgz> dimitern: thanks!
<davecheney> https://bugs.launchpad.net/juju-core/+bug/1244382
<_mup_> Bug #1244382: cmd/juju: destroying an environment twice returns no error <juju-core:New> <https://launchpad.net/bugs/1244382>
<sinzui> https://bugs.launchpad.net/juju-core/+bugs?field.tag=canonical-webops+charmers+cloud-installer+cts-cloud-escalation+cts-cloud-review+juju-gui+landscape+maas+ubuntu-openstack
#juju-dev 2013-10-25
<mgz> wallyworld: https://codereview.appspot.com/16930043
<jamespage> hazmat, https://bugs.launchpad.net/juju-core/+bug/1244761
<_mup_> Bug #1244761: reboot hook command for deferred reboot <juju-core:New> <https://launchpad.net/bugs/1244761>
<hazmat> jamespage, thanks
<hazmat> jamespage, does shutdown -r +10 work for that?
<dimitern> rogpeppe, ping
<dimitern> rogpeppe, take a look at http://askubuntu.com/questions/365807/whats-the-correct-way-to-share-a-juju-environment
<jamespage> hazmat, well it would as long as another hook is not doing something by then
<hazmat> jamespage, gothca
<wallyworld> smoser: hey, i can't find william for the 13:30 simplestreams session. i'll keep looking for him, but we may need to reschedule
<davecheney> jam: ping
<Guest10189> davecheney: time scp -C ec2-54-205-193-51.compute-1.amazonaws.com:/var/log/juju/machine-0.log  .
<Guest10189> rogpeppe: ^^
<dimitern> wallyworld, https://docs.google.com/a/canonical.com/document/d/1xiuJ_RLVm7TuwZUURALZaqPjyPEPE85_ESyohSWRm08/edit#
<adam_g> mgz, https://bugs.launchpad.net/juju-core/+bug/1244807
<_mup_> Bug #1244807: juju-deployer teardown fails due to hook errors <juju-core:New> <https://launchpad.net/bugs/1244807>
#juju-dev 2014-10-20
<thumper> wallyworld: ping
<wallyworld> yo
<thumper> wallyworld: got a minute for a question?
<thumper> hangout?
<wallyworld> sure
<thumper> wallyworld: just use or 1:1 hangout
<wallyworld> ok
<wallyworld> thumper: i'm here, in our 1:1
<thumper> hmm... so am I
 * thumper tries again
<axw> wallyworld: that review seems to lack a diff
<axw> looks like the hook got part way through and then died
<wallyworld> axw: hmmm, i didn't check if there were any diff, i just noticed the review showed up after i created the PR
<wallyworld> seems like there's an issue with the new hook
<wallyworld> i'll ask eric
<wallyworld_> anastasiamac: http://streams.canonical.com
<wallyworld_> anastasiamac: https://bugs.launchpad.net/juju-core/+bug/1309207
<mup> Bug #1309207: bad apt proxy config file in deployed nodes <apt-http-proxy> <cloud-installer> <local-provider> <juju-core:Triaged> <https://launchpad.net/bugs/1309207>
<axw> wallyworld_: FYI, I've added a new section to the storage doc about provider requirements for implementation
<axw> mainly of interest for MAAS
<wallyworld_> axw: ok, thanks, will look a little later
<anastasiamac> axw: thnx for review comments. did u c my corrections/comments? :-)
<axw> anastasiamac: sorry laptop froze
<axw> last time I looked there was no new diff to review
<axw> I guess the integration hook
<axw> isn't quite working properly
<axw> anastasiamac: reviewed on github
<anastasiamac> axw: brilliant! thnx :-)
<voidspace> morning all
<mattyw> morning everyone
<TheMue> jam: ping
<jam> hey TheMue, be there in a couple mins, sorry Im late
<TheMue> jam: no problem
<jam> TheMue: I'm here now
<voidspace> dimitern: ping
<dimitern> voidspace, pong
<voidspace> jam: http://bazaar.launchpad.net/~virtual-maasers/charms/precise/virtual-maas/trunk/view/head:/README-nojuju.txt
<voidspace> jam: https://insights.ubuntu.com/2013/11/15/interested-in-maas-and-juju-heres-how-to-try-it-in-a-vm/
<voidspace> are we still manually closing review board reviews once a branch is merged?
<voidspace> jam: "static-ipaddresses" is in the capabilities api - just not listed in the documentation
<voidspace> jam: I'll file an issue
<voidspace> ah, already fixed apparently
<voidspace> https://bugs.launchpad.net/maas/+bug/1375647
<mup> Bug #1375647: 'static-ipaddresses' capability in 1.6 not documented. <doc> <trivial> <MAAS:Fix Committed by julian-edwards> <https://launchpad.net/bugs/1375647>
<dimitern> voidspace, TheMue, jam, guys, I just got notified I'll be without power for some time while they fix some issue, so I'll be back when it's on again
<jcastro> Can I do `instance-type: m3.xlarge` in environments.yaml and have that dtrt?
<w7z> jcastro: nope
<jcw4> ericsnow: any idea why http://reviews.vapour.ws/r/201/ (super trivial PR) doesn't include a diff on reviewboard?
<jcw4> ericsnow: I did an rbt post -u and the diff appeared (and added the whole juju-team as reviewers)
* ChanServ changed the topic of #juju-dev to: https://juju.ubuntu.com | On-call reviewer: see calendar | Open critical bugs: 1383310
<sinzui> Ladies and Gentleman. This might be a bad day. No version of Juju we try can bootstrap with azure: https://bugs.launchpad.net/juju-core/+bug/1383310
<mup> Bug #1383310: Juju stable and devel cannot bootstrap Azure <azure-provider> <bootstrap> <juju-core:Triaged> <juju-core 1.20:Triaged> <https://launchpad.net/bugs/1383310>
<jcw4> sinzui: sounds like azure changed their configuration offerings to make them incompatible with our default constraints?
<sinzui> informative, thank you jcastro
<sinzui> jcw4, ^
<jcw4> lol :)
<jcastro> it's ok, I'm on ec2 today anyway. :)
<jcw4> hehe
<perrito666> ericsnow: natefinch: Hey I have some people working at home around me, Ill have to skip this one sorry :(
<ericsnow> jcw4: I'll take a look
<jcw4> ericsnow: ta
<jcw4> sinzui: did the CI build machine run out of space? ("write /mnt/tmp/juju-tgz519656690: no space left on device")
<jcw4> http://juju-ci.vapour.ws:8080/job/github-merge-juju/947/console
<w7z> jcw4: that's generally a symptom of aws in general being unhappy, I'll investigate
<jcw4> w7z: thanks
<sinzui> jcw4, If it did, it was cleaned up There is space now
<jcw4> w7z: are you mgz?
<w7z> yup, sorry
<jcw4> lol
<jcw4> sinzui: hmm; okay maybe I'll try again
<jcw4> wwitzel3, w7z : pre-push hook improvement PR http://reviews.vapour.ws/r/197/
<fwereade> dimitern, ping
<sinzui> jcw4, both / and /mnt are fine and /tmp was cleaned.
<jcw4> sinzui: weird
<dimitern> fwereade, pong
<fwereade> dimitern, in HookContext, when getting public/private address
<fwereade> dimitern, we have a check for IsCodeNoAddressSet
<fwereade> dimitern, do you remember why?
<sinzui> jcw4, The test script running will cleanup, so disk really could have been used up. The machine currently as 24G and 122G available on both partitions
<fwereade> dimitern, (git blames you for those lines ;p)
<dimitern> fwereade, because it might be unavailable yet?
<fwereade> dimitern, I'm assuming it's because moving addresses t the machine introduced a race
<fwereade> dimitern, yeah
<jcw4> sinzui: hopefully my second try will work
<fwereade> dimitern, can you think of any reason not to delay hook execution until there is an address?
<fwereade> dimitern, ISTM that the current behaviour is still buggy, it just means the uniter doesn't fall over
<fwereade> dimitern, but it pushes the bugginess into the charm's lap
<fwereade> dimitern, I guess the question is for how long we might be without an address
<dimitern> fwereade, delaying the hook sgtm
<fwereade> dimitern, are there any cases we might be left without an address for arbitrarily long time?
<dimitern> fwereade, how long? well.. hard to tell, but it shouldn't be long in the usual case - as soon as the instance poller runs and gets an address
<fwereade> dimitern, and we'll get both public and private still?
<dimitern> fwereade, iirc that haven't changed
<fwereade> dimitern, even if there's no public address (ie we return the private one?)
<fwereade> dimitern, cool
 * perrito666 runs the whole test suite before pring and has time to brew tea
<w7z> jcw4: I'm not mad about that script still being bash with that much added logic
<jcw4> w7z: whew
<jcw4> :)
<dimitern> axw, are your still around by any chance?
<katco> dimitern: it's pretty late for him i think... ~11pm
<dimitern> katco, yep, just checking :)
<sinzui> natefinch, can you organise an effort to understand bug 1383310? I fear azure cloud changed and we need new stable and devel juju's to work with it
<mup> Bug #1383310: Juju stable and devel cannot bootstrap Azure <azure-provider> <bootstrap> <juju-core:Triaged> <juju-core 1.20:Triaged> <https://launchpad.net/bugs/1383310>
<blackboxsw> in
<natefinch> sinzui: ok
<jcw4> w7z: any preference for the extracted verification script name? verify.bash seems a little generic
<dimitern> any reviewers wanna have a look at a trivial branch http://reviews.vapour.ws/r/202/ ?
<jcw4> w7z: (and any other reviewers) pre-push hook update: http://reviews.vapour.ws/r/197/
<dimitern> voidspace, if still around ^^
<voidspace> dimitern: sure
<voidspace> dimitern: hah, nice and easy :-)
<voidspace> dimitern: in the whitebox test, why  did you add the extra config to the NewNetwork calls?
<dimitern> voidspace, it is :)
<jcw4> dimitern: fwiw, I just did an rbt post -u and my diff appeared along with the juju-team reviewer being added
<dimitern> jcw4, ha, good to know, thanks! :)
<dimitern> voidspace, because of the gomaasapi changes
<dimitern> voidspace, now "ip" and "netmask" are required attributes for a network inside the MAAS test server
<voidspace> dimitern: ok
<voidspace> dimitern: so for maas there's no test of the false or error cases?
<voidspace> dimitern: only the true case
<dimitern> voidspace, it's a bit shitty, but the reason is "/ipaddresses/?op=reserve&network=1.2.3.4/5" expects network= to be a CIDR of an existing network, while *everywhere* else a network can be referred to by name or other things (i.e. "ip:1.2.3.4", etc)
<dimitern> voidspace, yes, because as agreed in brussels, we'll be dropping support for maas pre 1.6 and 1.7 will be SRU-ed into trusty
<voidspace> dimitern: but there's still an untested code path - even if it's an "unsupported" code path
<voidspace> dimitern: I mean, it's trivial code - so maybe it's alright
<dimitern> voidspace, expand a bit please?
<dimitern> voidspace, you mean testing "IsFalse" case?
<voidspace> dimitern: you could hard code the maas implementation of SupportAddressAllocation to return true
<voidspace> dimitern: and no tests would fail
<dimitern> voidspace, that's true
<voidspace> dimitern: yes, the IsFalse case
<dimitern> voidspace, the maas test server is really not easy to tweak, so it can return the capability or not
<voidspace> right
<dimitern> voidspace, but it will work in the real world - returning false against an older maas
<voidspace> dimitern: the code certainly *looks* correct ;-)
<voidspace> dimitern: anyway, LGTM
<dimitern> voidspace, cheers!
<voidspace> dimitern: I assigned that card to you as it was previously assigned to me
<dimitern> voidspace, yeah, thanks - I realized this PR actually implements the SAA() cap, so I'll move both to merged once the PR lands
<voidspace> dimitern: new private  method for checking default vpc is on ec2/ec2.go:environ right?
<voidspace> or on ec2Instance
<dimitern> voidspace, yeah, it should return (VpcId, bool)
<dimitern> voidspace, on environ
<voidspace> dimitern: coolio, thanks
<bodie_> anyone have a thought briefly about whether batch calls on the api client should be exported?
<bodie_> for example, I can imagine a use case where the client wants to find the action schemas for multiple services
<sinzui> natefinch, could this be relevant to the azure failures: http://azure.microsoft.com/blog/2014/10/17/azure-service-bus-namespacetype-default-value-change/
<sinzui> ah, that doesn't say the change will be enforced until the 26th
<natefinch> sinzui: yeah, I don;t think that would be the problem . Sorry, I haven't been able to dive into the azure problem just yet, but will in just a little bit.  I know it's obviously very critical
<mattyw> ericsnow, ping?
<ericsnow> mattyw: ping
<mattyw> ericsnow, just a quick question about the review board integration (thanks very much by the way)
<mattyw> ericsnow, if I push updates to a pr. Does the review board branch need to have the changes published or is it automatic?
<ericsnow> mattyw: it is automatic
<mattyw> ericsnow, me again, there doesn't seem to have been a diff generated: http://reviews.vapour.ws/r/203/
<ericsnow> mattyw: yeah, no reviewers are getting set which ultimately causes no diff to get attached
<ericsnow> mattyw: I'm working on fixing it :(
<mattyw> ericsnow, I set juju-team as the group
<ericsnow> mattyw: perfect
<mattyw> ericsnow, I did that before publishing - but there still seems to be no diff
<mattyw> ericsnow, is there something I should/ can do or can you sort it?
<ericsnow> mattyw: until I get this fixed you'll have to use rbt -u
<mattyw> ericsnow, I don't mind using rbt
<mattyw> ericsnow, cool
<voidspace> g'night all
<thumper> ericsnow: hey
<ericsnow> thumper: hey
<thumper> ericsnow: with the new github integration stuff
<thumper> I have a review that was pushed last week
<thumper> if I just push to github
<thumper> will it pick up the new diff?
<thumper> or do I still need to use rbt for that?
<ericsnow> thumper: sorry, no (keep using rbt for that)
<thumper> ok
<ericsnow> thumper: also FYI the integration is currently broken (I'm working on a fix)
<perrito666> ericsnow: ah gtk, so I should hold my pr then?
<ericsnow> perrito666: I support you could
<perrito666> ericsnow: seems your english integration just broke too
<ericsnow> perrito666: or just do it, and then publish the auto-generated review request and use rbt -u to push the diff
<ericsnow> perrito666: haha
<perrito666> ericsnow: oh, I can just go ad do the publish by hand?
<ericsnow> perrito666: muscle memory
<ericsnow> basically yeah
<perrito666> I thought broken means nothing works at all
<katco> is anyone familiar with machine/container id formats as they're stored in mongo?
<ericsnow> perrito666: no, the review request gets created, but without any reviewers set
<perrito666> ericsnow: works for me I know how to finish that by han
<perrito666> d
<ericsnow> perrito666: cool
<natefinch> sinzui: what's up with azure?
<sinzui> natefinch, I think West US is bad
<sinzui> natefinch, We have not been able to use it for 3 days. I set East US and juju works
<sinzui> natefinch, ...I find it hard to believe that West US has been over saturated for 3 days that we have had no successful bootstraps
<sinzui> natefinch, abentley jog. We have a passing cloud-health check and revision tests because I setup CI for East US.
<natefinch> sinzui: that does seem unlikely, but I also don't know why US west would fail while East passes
<sinzui> natefinch, abentley purges our account of all resources. We didn't have much beyond a storage account and a network
<sinzui> natefinch, mayeb azure has rules at a higher level. Canonical as a company may have reached a limit for the West region?
<natefinch> sinzui: could be.  Do you know if we have contacts over there?
<sinzui> Antonio has contacts.
<sinzui> My own report of usage shows were are using less that 5% of any one resource
<sinzui> natefinch, I think this bug is implicitly fixed with the release of 1.21.0 because users wont need to specify storage: https://bugs.launchpad.net/juju-core/+bug/1236136
<mup> Bug #1236136: Azure bootstrap fails when 'location' and 'storage-account-name' are not in the same region <azure-provider> <bootstrap> <juju-core:Triaged> <https://launchpad.net/bugs/1236136>
<thumper> o/ davecheney
<davecheney> thumper: sorry, still a bit jetlagged
<thumper> davecheney: that's ok
 * thumper has just been hacking
 * davecheney heads for the hangout
<natefinch> sinzui: we should talk to Microsoft about Azure and why we might be getting that error on West.  It sounds like it's an azure problem, honestly.  If they can't give us an instance with 2 GB of RAM.... that seems like a pretty severe problem on their side.
<sinzui> natefinch, funny you should mention 2G ram. Azure can give us 4G or 1.75G. Maybe I find constraints that will select a machine in the region
<natefinch> sinzui: I thought i saw a constraint given that said 2GB.... juju just treats that as a minimum and will pick the cheapest instance with at least that much TAM
<natefinch> RAM
<sinzui> yes, RAM
<natefinch> sinzui: hrm, creating a machine manually from the azure website in US West seems to work ok
<sinzui> yep
<sinzui> natefinch, setting constraints to 2G, 4G and 8G fails.
<natefinch> sinzui: there was a big microsoft azure presentation today
<natefinch> sinzui: in SF.... maybe a lot of people are poking at Azure US West today
<natefinch> though you said it's been a few days
<sinzui> natefinch, azure west died on the 17th, as we were EOD
<davecheney> thumper: https://bitbucket.org/goarm64/go/commits/all
<davecheney> so you can see what is going on
<davecheney> i added 'howbazaar'
<thumper> davecheney: cheers
<alexisb> thumper, on and ready when you are
#juju-dev 2014-10-21
<perrito666> ericsnow: the auto thingisnot workingright?
<wallyworld_> sinzui: hey, remind me, did we agree that the simplestream content id for tools should be "com.ubuntu.juju:released:tools" always? even for devel/proposed? the devel/proposed tools like at a different url of course, but are we going to lie in the content ids inside the json?
<wallyworld_> the current code in master generates ids like com.ubuntu.juju:proposed:tools or com.ubuntu.juju:devel:tools which don't match what's in the json
<sinzui> wallyworld_, I don't like the lie, but we never agreed to remove it
<wallyworld_> sinzui: ok. in that case, i'm not sure how 1.21-alpha1 is finding tools
<wallyworld_> because the code is generating the wrong ids
<sinzui> wallyworld_, right. I think a real change requires a longer transition.
<wallyworld_> sinzui: we can make a fix for alpha2 which generates the expected content ids
<wallyworld_> sinzui: just to confirm, proposed will live at http://streams.canonical.com/juju/proposed/tools/
<sinzui> yes
<wallyworld_> devel will live at http://streams.canonical.com/juju/devel/tools/
<sinzui> yep
<wallyworld_> ok, that's what the code assumes, bt with the wronf content id
<wallyworld_> so we'll do a fix
<sinzui> wallyworld_, I think we need to teach 1.21 that it will change, but probably not change until 1.22
<wallyworld_> sinzui: yeah, i guess it could look for the correct id and fall back to the incorrect one
<sinzui> wallyworld_, We never say you can upgrade from devel to devel though. alpha1 might be able to upgrade to alpha2, but we never say it is so
<wallyworld_> messy but doable
<wallyworld_> i would prefer just to fix the ids for alpha2
<wallyworld_> ie have the json generated with com.ubuntu.juju:proposed:tools etc
<wallyworld_> but if that's not doable, we will have to code the fallback option
<wallyworld_> which will be very messy
<wallyworld_> sinzui: let me know your thoughts and we can code the solution to work with what's possible for you
<sinzui> wallyworld_, I think we can fix the values in the json, and announce that upgrades from a1 to a3 are not supported...unless sync-tool from alpha2 clients will work
<wallyworld_> sinzui: sync-tool should write the correct json, so it *should* work. but +1 to making it all correct now during the alpha release stage before it's too late to fix
 * thumper takes a deep breath, and continues with deep refactoring dive
<wallyworld_> axw: standup?
<axw> oops
<axw> brt
<davecheney> mercurial hates me
<davecheney> $ hg pull -u
<davecheney> abort: error: _ssl.c:510: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
<davecheney> i know _why_ this stopped working
<davecheney> but I don't know _how_ to fix it
<perrito666> davecheney: doesn't hg allow you to ignore the cert somehow?
<davecheney> perrito666: maybe
<davecheney> make: Warning: File `../../Make.dist' has modification time 1.4e+09 s in the future
<davecheney> dfc@bauer:~/go/src/cmd/7a$ date
<davecheney> Thu Jan  1 01:29:47 EST 1970
<davecheney> oh wow
<davecheney> i guess that is why https wasn't working
<wallyworld_> axw: hi, review baord and 1.20 aren't playing nicely, could you take a look at this for me? https://github.com/juju/juju/pull/929
<axw> wallyworld_: will do
<wallyworld_> ty
<axw> wallyworld_: what part bind-mounts the storage dir?
<wallyworld_> axw: container/lxc/lxc.go
<wallyworld_> mountHostToolsDir()
<axw> why is it doing that? :/
<wallyworld_> so the container doesn't have to go to http storage to get tools cause there's a race condition on startup
<wallyworld_> containers would sometimes fail to download tools in cloud init
<wallyworld_> because the http storage wasn't available
<axw> yeah, so we put in retries right?
<wallyworld_> i think that was after this fix
<axw> the agent will rm -fr /var/lib/juju on destruction, so mounting anything in there is going to be bad
<wallyworld_> yes
<axw> I guess it's too late for 1.20
<wallyworld_> hence this fix
<axw> what I mean is, this is working around it - it would be better not to mount it
<wallyworld_> the fix mounts it to /tmp instead but i guess now that retries are there the mount is no longer needed
<wallyworld_> at lease that assumes the retires will fix the original issue
<wallyworld_> i'dhave to re-read the orignal bug
<axw> wallyworld_: reviewed
<wallyworld_> ty
<wallyworld_> axw: ah, i think i remember - some hosts had port 8040 closed
<wallyworld_> hence the curl to the http provider failed
<wallyworld_> so retries won't help
<axw> wallyworld_: ah yeah. anyway, shouldn't be a problem in trunk at least
<wallyworld_> yup
<wallyworld_> axw: i'm wondering if we should randomise the choice of availability zone when none is explicitly specified and we just iterate over the available zones till we find one where startinstance works
<axw> for openstack?
<wallyworld_> yeah, but also for ec2
<wallyworld_> i'm implementing the choice for openstack
<axw> wallyworld_: we could randomise at each level of population
<wallyworld_> since it currently always uses the first zone
<axw> otherwise it would defeat the algorithm
<axw> wallyworld_: it uses the first of the ones with the least population from the group
<axw> under the assumption that it wouldn't fail, which obviously was wrong
<wallyworld_> ah, right, in that case i might not do any extra
<axw> I suggest we just iterate through in ascending order of population
<axw> like in ec2
<wallyworld_> yup, ok
<axw> we could always change the underlying code in provider/common later to randomise if it's valuable
<wallyworld_> axw: so in openstack, we do this: zoneInstances, err := availabilityZoneAllocations(e, group)    and then zone-to-use = zoneInstances[0].ZoneName
<wallyworld_> i'm just going to iterate over the slice and try start instance on each zone till it succeeds
<wallyworld_> like in ec2
<wallyworld_> the code in there now matches the bug symptom
<wallyworld_> where it always tries just the same zone each tome
<axw> wallyworld_: right, I agree with that approach
<wallyworld_> coolio
<axw> wallyworld_: in ec2 we check for a specific error code, and bail on others
<axw> not sure if there's an equivalent on openstack
<wallyworld_> axw: yep, openstack returns just a 500 sadly
<wallyworld_> so i gotta check the message :-(
<axw> wallyworld_: I meant error-code-string in the body
<axw> same as aws then
<wallyworld_> our goose library will return an UnspecifiedErrorCode I think. the underlying openstack message is "No valid host was found"
<wallyworld_> goose gets a http 500 response code
<wallyworld_> jam: bug 1383260 is related to scalability - do you have any comments based on your previous work in this area. i fear it will not be something we can easily fix
<mup> Bug #1383260: 1.20.10/MAAS 1.5 relations not being 'started' in a large environment <deploy> <maas-provider> <scale-test> <juju-core:Triaged> <juju-core 1.20:Triaged> <https://launchpad.net/bugs/1383260>
<jam> wallyworld_: well he did say "it did eventually complete" but was slow and high CPU/memory. I don't have any specific notes on what we could do to fix that, we just need testing and profiling.
<jam> wallyworld_: He had ~300+ items and then added a subordinate, which creates 300 new units right away
<wallyworld_> jam: yep, i wasn't sure if you had any previous profiling which may have showed that issue
<jam> wallyworld_: I was aware that adding a subordinate is painful, but when I did it with 1k nodes, it pretty much just died. And I haven't done it for a long time. I had actually forgotten about it.
<wallyworld_> ok, np
<wallyworld_> i think the bug shoud be moved off 1.20
<wallyworld_> as we won't get to fix it for that release
 * fwereade will be off in a few mins, back when I'm in a hotel on the next island, not far but might be a bit of a wait for the boat
<voidspace> morning all
<wallyworld_> axw: thanks for review. i did
<wallyworld_> .
<wallyworld_> add a test for that eror path i think
<wallyworld_> TestStartInstanceWithUnknownAZError
<axw> wallyworld_: yeah I saw it later... sort of tests it indirectly, but that's good enough
<wallyworld_> yeah, i thought it would be sufficient
<axw> what I meant specifically was in that test, do we get az3 after failing to get az2, or did we go straight to az3
<axw> but anyway, don't worry about it
<wallyworld_> ah, i see your point
<wallyworld_> the other tests sort of prove that we would  hit az2 first
<wallyworld_> but yeah, not 100% sufficient
<voidspace> wallyworld_: axw: can one of you run this code and tell me what it outputs please
<voidspace> http://pastebin.ubuntu.com/8612039/
<voidspace> I'm seeing "none", which surprises me
<axw> voidspace: hey. sure, one moment
<voidspace> it should print the id of the default-vpc for the account
<voidspace> axw: thanks
<voidspace> no hurry, I'm grabbing coffee
<axw> voidspace: I also get "none"
<wallyworld_> voidspace: none for me too
<voidspace> so either we have no default-vpc for that region, or goamz is buggy, or the amazon api is buggy
<voidspace> I tried a couple of different regions and got none for the ones I tried
<voidspace> wallyworld_: thanks
<voidspace> not just my credentials then
<axw> voidspace: "ec2-describe-account-attributes default-vpc" gives me something other than none
<axw> so it's not the first case
<voidspace> ah, cool
<voidspace> well, distinctly uncool
<voidspace> but thanks
<voidspace> and dimiter is off today of course :-)
<axw> voidspace: sorry
<axw> I was wrong
<axw> I forgot, I changed my default region in my dot file
<axw> so ec2-describe-account-attributes was describing ap-southeast-2
<axw> voidspace: us-east-1 does return "none" when using that too
<voidspace> axw: ah
<voidspace> axw: I get "Client.Unauthorized: Not Authorized"
<axw> using ec2-describe-account-attributes?
<voidspace> yep
<voidspace> and the ec2-describe-regions
<axw> you sourced your creds?
<voidspace> yep :-)
<voidspace> if you don't do that then you get a traceback instead
<voidspace> and naturally it uses different environment variables to the ones we (and goamz) uses
<axw> dunno then - just works for me
<voidspace> axw: I'm reading the docs
<voidspace> but I'll try ap-southeast from goamz
<axw> ah yeah, I should've tried that. yep, works fine
<voidspace> axw: for me too
<voidspace> code is probably correct
<voidspace> I wonder why my command line tools don't work
<voidspace> Hmmm... my reviewboard review didn't have a reviewer set
<voidspace> Nor does it appear to have a diff
<voidspace> http://reviews.vapour.ws/r/211/
<voidspace> I'll have to harass ericsnow
<voidspace> Ah, known issue but thought fixed...
<fwereade> wwitzel3, ping
<voidspace> jam: are you around?
<jam> voidspace: clicking on the link now
<voidspace> jam: http://reviews.vapour.ws/r/211/diff/1/#1
<fwereade> if anyone's familiar with the details of what the uniter's trying to do with proxy settings, please let me know
<wallyworld_> fwereade: i know a little, what did you want to know?
<fwereade> wallyworld_, so, we rewrite the environment with new proxy settings
<wallyworld_> it basically allows the user to update the http/ftp/apt proxy settings via an environment config change, and have the hook context reflect those settings when a hook is run
<fwereade> wallyworld_, what about the impact on the http package?
<fwereade> wallyworld_, is there any? if so, do we depend on it? if so, how do we deal with the implicit races?
<wallyworld_> fwereade: well, it sets the HTTP_PROXY env var, so that will affect the http package too
<fwereade> wallyworld_, quite so
<wallyworld_> if hook tools invoke http calls
<fwereade> wallyworld_, that's the source of my concern
<fwereade> wallyworld_, it's not just the hooks that invoke http calls
<fwereade> wallyworld_, the uniter downloads charms itself
<fwereade> wallyworld_, and... hmm, the upgrader doesn't any more, does it?
<wallyworld_> sure, but the uniter downloading charms would need to use any http proxy setting the user deemed necessary
<fwereade> wallyworld_, that is, it doesn't because the machine agent's upgrader is guaranteed to have coincidentally downloaded everything already
<wallyworld_> yes
<fwereade> wallyworld_, ok, but what happens when the env setting change races with the charm download?
<wallyworld_> how do you mean?
<fwereade> wallyworld_, well, we rewrite the env -- and the http package reads the env -- what happens when they collide? can they collide? I may be worrying about nothing
<fwereade> wallyworld_, can we get nonsense in the proxy settings if we kick off a charm download at just the wrong time?
<fwereade> wallyworld_, are we maybe safe explicitly downloading charms with no proxy? given that they should always come from the local state server
<fwereade> wallyworld_, wait scratch that we're not
<fwereade> wallyworld_, manual env :/
<wallyworld_> i must admit i don't see an issue. when an env i bootstrapped, the user chooses if they want to set the http proxy in their env.yaml. then later, they can change it using a set-env call, which sends the change to the uniters
<fwereade> wallyworld_, it's purely about the details of what's happening in-memory
<fwereade> wallyworld_, is a change of env vars atomic?
<fwereade> wallyworld_, even if it is, does the http package read them atomically, or could it get non-matching HTTP_PROXY and NO_PROXY values?
<wallyworld_> not sure. but the seq from a system perspective is: cange hits db -> watcher invoked -> uniter notices -> uniter calls os.SetEnv()
<wallyworld_> oh i see what you are asking
<fwereade> wallyworld_, yeah, I'm fine with what's going on at a high level
<wallyworld_> if the user changes 2 env settings via single set-env call, will that translate into a single EnvironConfig changed event
<wallyworld_> i would hope so
<fwereade> wallyworld_, even lower level
<fwereade> wallyworld_, how does a call to os.SetEnv affect a concurrent http.Get
<wallyworld_> no idea
<wallyworld_> i would expect that the tcp connection already made will stick
<fwereade> wallyworld_, I guess we have the same problem, if it is one, in the machine agent anyway
<fwereade> wallyworld_, that's doing the same stuff essentially
<wallyworld_> yeah
<fwereade> wallyworld_, ok, I will pretend it's not an issue for now
<wallyworld_> i can't see a very common use case of http proxy changing after bootstrap
<wallyworld_> but i guess it's something to be considered
<fwereade> wallyworld_, yeah, my suspicion is that it's a bug but not one anyone will actually hit in practice
<wallyworld_> i agree
<wallyworld_> but, knowing our luck, someone important will be unlucky
<wallyworld_> i hadn't thought about it too much, didn't write that code
<fwereade> wallyworld_, so what I should really do is scrap the yucky uniter code, parameterise machineenvironmentworker, and run one of those in the unit agent (that doesn't write to the global location and just hits the os.Env)
<fwereade> wallyworld_, no worries
<fwereade> hmm
<fwereade> I wonder, what's the worst that could happen if I just scrap the code in the uniter, and grab proxy settings for each hook context individually?
<fwereade> charm downloads won't use the proxy... but they're (1) almost certainly local and (2) ha, it looks like they're not guaranteed to anyway
<fwereade> ffs
<wallyworld_> fwereade: charm dowsnloads will soon be via the charn store
<wallyworld_> the local charm store
<wallyworld_> so it won't matter anyway
<fwereade> wallyworld_, yeah
 * fwereade just saw a check on provider type inside a worker and experienced a brief moment of apoplectic rage
 * fwereade better now
<wallyworld_> oh no, which worker?
<wwitzel3> fwereade: pong
<fwereade> wwitzel3, what's the status of the juju-run-in-relation-context work?
<fwereade> dammit I have to break for a moment
<fwereade> wwitzel3, would you let me know when I'm back on? hopefully just a few mins
<wwitzel3> fwereade: it just needs to be reviewed
 * perrito666 just learned what apopletic rage is
<fwereade> wwitzel3, back, sorry
<wwitzel3> fwereade: np
<jcw4> w7z: did you get a chance to review http://reviews.vapour.ws/r/197/ ?
<sinzui> natefinch, do you expect golang 1.2 win-amd64 to "just work" when I build 386 juju.exe with goarch=386?
<w7z> jcw4: yes, I think we should land, but we also need to coordinate when it happens, as I need to change the landing script at the same time
<w7z> jcw4: lets do that
<w7z> jcw4: oh yeah, my one question was have you checked calling to the other script still works when the pre-push one is symlinked into .git/blah ?
<natefinch> sinzui: yes
<sinzui> thank you natefinch
<voidspace> TheMue: I updated by PR by the way
<voidspace> TheMue: added a const for "none"
<TheMue> voidspace: hehe, thanks
<TheMue> voidspace: just found in my PR that we always use strings for the provider types, which is convenient but error prone
<ericsnow> natefinch: we basically had a 1-on-1 yesterday, but we can go today if you want to
<voidspace> TheMue: :-)
<sinzui> natefinch, sorry, I am confused by go building. Do I need to run make.bat each time I switch the target architecture?
<natefinch> sinzui: just once per architecture... it'll put the binaries in a separate directory, and it'll use the right ones when crosscompiling
<natefinch> sinzui: er once per arch/OS
<sinzui> natefinch, that is what I hoped. this make.bat seems to think I want gcc :(
<natefinch> sinzui: to be honest, I just use Dave Cheney's scripts, it makes it trivial: http://dave.cheney.net/2013/07/09/an-introduction-to-cross-compilation-with-go-1-1
<natefinch> ericsnow: let's have a quick 1 on 1 anyway
<ericsnow> natefinch: k
<sinzui> natefinch, Me too, but in the case of windows, I cannot verify immediately what was built passes a smoke test. We build on windows just like we build our ubuntu packages on the real arch
<jcw4> w7z: yeah, sorry did test that - yep.
<jcw4> w7z: will wait to push til you're ready
<w7z> jcw4: will give you the okay in a sec
<jcw4> ta
<ericsnow> natefinch: sorry, hangouts died
<natefinch> ericsnow: haha ok
<natefinch> ericsnow: I was talking and talking and then noticed you weren't moving anymore
<w7z> jcw4: okay, go
<jcw4> kk
<jcw4> sorry.. added x bit
<natefinch> I sort of wish the local provider didn't exist.... it confuses people into thinking they should use juju the way they use other deployment systems - i.e. SSH into the machine where you want to deploy stuff and start running juju there.
<sinzui> natefinch, me too :(
<sinzui> arosales, can you try a bootstrap in azure West US? I can only bootstrap in East US.
<arosales> sinzui: sure. I am in a few meetings atm, but should be able to try at the top of the hour.
<voidspace> ok all, g'night
<w7z> I'm out for a bit, ping me if the landing bot is unhappy should anyone try it later and have issues
<natefinch> ericsnow: btw, I made a review and it didn't give me a diff, so I closed the PR, made a new PR and now reviewboard isn't picking up the PR at all.  This is probably an edge case, but wanted you to be aware.
<ericsnow> natefinch: this is actually an issue of RB having a unique constraint on the repo revision on each  review request and how discarded review requests hold on to that
<natefinch> ericsnow: figured it was something like that.   What's the workaround?  poke my PR with a new commit?
<ericsnow> natefinch: that should do it or you could use rbt -u
<ericsnow> natefinch: and make sure that old review request is open
<natefinch> gah, stupid "File was not found in the repository"
<natefinch> probably why there was no diff in the first place
<natefinch> this is from a clean master and only fixing a typo (no new files or anything)
<ericsnow> it's amazing what happens to your terminal when you run "cat /dev/urandom" :(
<ericsnow> natefinch: yeah, I'm looking into several of those right now
<perrito666> aghghh import cycle with dummy provider
<natefinch> the dummy provider imports stuff?  That seems bad
<perrito666> natefinch: import apiserver
<natefinch> perrito666: so much for being a dummy :/
<perrito666> lol
<perrito666> uff, more than 30C outside and I live in a country where drinking individually is seen with bad eyes
<perrito666> what a torture
<jcw4> perrito666: you need to get a cutout of a drinking buddy
<perrito666> jcw4: on the good side, beer is way easier to get in 1l bottles than in individuals
<jcw4> perrito666: lol
<jcw4> I think they call that a tallboy here
<perrito666> anyone knows exactly what is the purpose of the apiServer member of environState struct?
<perrito666> seems to be barely used
<natefinch> nope
<natefinch> perrito666: seems to only get stopped when environState is closed.  that's the only use I see
<natefinch> perrito666: it boggles my mind that the dummy provider starts a real apiserver
<perrito666> natefinch: I am not sure if its there for some obscure use we dont know of
<perrito666> natefinch: yes, beats a bit the dumminess
<natefinch> perrito666: so, apiserver.NewServer() has a side effect of running a tls listener
<natefinch> perrito666: likely some tests are expecting to be able to actually connect to an API
<natefinch> perrito666: but it's probably worth seeing what happens if you just comment it out
<perrito666> well the test is killed by sigquit
<thumper> morning folks
<natefinch> morning thumper
<perrito666> thumper: morning
 * perrito666 ponders how to fix this without writing a dummy apiserver
<natefinch> perrito666: what's the import cycle?
 * natefinch thinks that sounds like a bad song from the 90's
<perrito666> http://pastebin.ubuntu.com/8618809/
<perrito666> natefinch: sounds something you would ask in a star trek episode during an engineering crisis
<natefinch> ug
<thumper> hmm...
<thumper> ericsnow: getting errors with rbt
<bodie_> howbazaar = howbazaar on IRC, right?
<thumper> error uploading diff
<thumper> bodie_: wat?
<natefinch> bodie_: howbazaar = thumper you mean
<bodie_> oooh
<ericsnow> what's the error?
<bodie_> okay :)
<natefinch> bodie_: and yes
<thumper> twitter?
<thumper> bodie_: unfortunately thumper was taken
<bodie_> thumper, just looking for a ping back on reviewboard 178 when you have a spare minute
<natefinch> probably anyone named howbazaar anywhere is thumper :)
<thumper> probably
<bodie_> sorry -- I'm not too savvy with IRL handles
<thumper> surprisingly I'm neither howbazaar nor thumper IRL
<natefinch> lol
<bodie_> that's Thumper H. Bazaar to you
<natefinch> great psuedonym
<ericsnow> thumper: what error are you getting?
<katco> is there an example of how to stub a machine with a given id for a test anywhere?
<natefinch> ericsnow: you took out that "screw you, thumper" easter egg, right?
<ericsnow> natefinch: oh, shoot!
<thumper> ericsnow: error uploading diff
<ericsnow> thumper: no other info?
<natefinch> perrito666: so, you're changing peergrouper tests to do something that requires the testing package?
<thumper> ericsnow: The file was not found in the repository. (HTTP 400, API Error 207)
<thumper> Your review request still exists, but the diff is not attached.
<natefinch> thumper: yeah, a bunch of us are getting that
<thumper> hmm...
<thumper> natefinch: any suggestions?
<natefinch> thumper: ericsnow's been looking at it today, but I don't think he's figured it out.  Manual upload of the diff is probably the only workaround right now.
<thumper> oh? how do we do that?
 * thumper found a link
<thumper> got an error uploading diff: The file "api/client.go" (revision b373c16) was not found in the repository
<thumper> which is bollocks
<natefinch> yeah, I got the same thing for my PR, which was just a 2 character change
<thumper> so... anyone up for a 4k review?
<thumper> Showing ï¿¼ 36 changed files  with 1,924 additions and 1,237 deletions.
 * thumper feels hopeful
<natefinch> zoikes
 * natefinch is OCR
<thumper> natefinch: hey there buddy
<natefinch> :D
<thumper> natefinch: was reviewed by menno, katco, axw and william already
<thumper> I was just following up, tweaking
<thumper> lots of new docstrings
<natefinch> well shit, I can just rubberstamp, right?
<thumper> but now rb is all in a fuss
<katco> thumper: sorry about the dupes. menno and i overlapped a bit
<thumper> katco: that's fine
<thumper> made them easy to address
<natefinch> doh, guess it'll have to wait until tomorrow when someone else is OCR...
<katco> thumper: we didn't know we were reviewing the same thing. on the plus side, you got a new high score :)
 * thumper is winning!
<katco> haha
<natefinch> thumper: so is there a diff?
<natefinch> sinzui: https://bugs.launchpad.net/juju-core/+bug/1370149  is not reproducible for me on trunk.
<mup> Bug #1370149: No defined 'state-servers' on environment file after bootstrap, works after run 'juju status' <bootstrap> <cloud-installer> <cts> <juju-core:Triaged> <https://launchpad.net/bugs/1370149>
<thumper> natefinch: https://github.com/juju/juju/pull/905/files, or http://paste.ubuntu.com/8618992/
<thumper> natefinch: http://reviews.vapour.ws/r/169
<davechen1y> thumper: hang on i have to reboot before the hangout
<thumper> kk
<sinzui> natefinch, Shall we mark it fix committed in 1.21-alpha2?
<natefinch> sinzui: seems to be true
<sinzui> okay, thank you very much natefinch
<perrito666> natefinch: I am not, I actually added restore, which is part of backups which is registered as a facade by apiserver and since dummy env imports apiserver that creates the cycle
<natefinch> dang
<perrito666> and well dummyserver is used by testing which is used by the peergrouper tests
<natefinch> I wonder if we can break the cycle at testing -> dummy
<natefinch> unless the peergrouper tests need dummy server, which is possible I guess
<natefinch> er dummy provider
<perrito666> they dont seem to directly but I have not checked if seccond hand they do, I am guessing they do since when I tweak a bit dummy server to remove apiserver they end up being killed for too much wait
 * perrito666 drinks a mate and says ugly things in spanish
<natefinch> ericsnow: it looks like the diff upload problem is trickling into existing reviews: http://reviews.vapour.ws/r/212/diff/#
<ericsnow> natefinch: k
 * perrito666 sees ericsnow twitching
<thumper> ericsnow: there also seems to be a big difference in my branch where I've moved some files around
<thumper> ericsnow: on github they show as moves with minor edits
<thumper> ericsnow: oh rb, it shows as deletes and adds
<perrito666> thumper: ouch sorry me commenting on something you where reviewing might have caused you an issue
<ericsnow> thumper: yeah, something is out of sync with the base revisions
<ericsnow> thumper: I'm looking into the caching the reviewboard does
<wallyworld_> sinzui: question - given that 1.21 looks for streams content ids like "com.ubuntu.juju:<stream>:tools", we will either need to teach 1.20 to look for such content ids, or publish metadata using both "release" and <stream> in the proposed and devel streams
<wallyworld_> we current use tools-metadata-url to tell 1.20 how to find devel and proposed tools, but once/if we change the content ids, 1.20 won't be able to find any metadata
<wallyworld_> and right now, 1.21 can't find proposed/devel metadata due to the different content ids
<perrito666> hey wallyworld_ IRQ when you have a sec
<wallyworld_> IRQ?
<perrito666> I am obviously asking for processor time on you :p
<wallyworld_> lol
<wallyworld_> is that non maskable
<perrito666> I certainly hope so :p I dont feel like being idle waiting
<perrito666> I know your time you are completely unfair scheduling :p
<perrito666> always handling to those that dont bring problems
 * wallyworld_ saves registers and current stack frame
 * wallyworld_ processes interrupt
<ericsnow> FYI: reviewboard is happier now; rbt works again and I'm fixing the github integration part right now
<ericsnow> sorry for the headaches
<jcw4> thanks ericsnow :)
#juju-dev 2014-10-22
<thumper> ericsnow: $ rbt post -r 169 -p
<thumper> ERROR: Error updating review request draft: HTTP 500
<ericsnow> thumper: what's the unicode table-flipping URL again?
<thumper> http://emojicons.com/table-flipping
<ericsnow> thanks
<ericsnow> thumper: (â¯'â¡')â¯ï¸µ â»ââ»
<ericsnow> thumper: is there an existing review request?
<ericsnow> thumper: perhaps a draft?
<thumper> yep
<ericsnow> oh, right (rbt -r)
<thumper> yes...
<thumper> it looks like previous attempts to upload diffs half worked
<ericsnow> which review request?
 * thumper tries again
<thumper> same error
<thumper> looks like it is ok...
<thumper> although
<thumper> only some of the file moves were identified as moves
<ericsnow> what's the review request number?
<thumper> but it didn't publish
<thumper> http://reviews.vapour.ws/r/169
<thumper> see the "-r 169"
<thumper> if I try to click publish
<thumper> I get: 500, internal server error
<thumper> at least the current review looks ok
 * thumper will leave it there
 * thumper looks around for ax2
 * thumper looks around for axw
<thumper> oh hai axw
<axw> thumper: hey, otp
<thumper> axw: yeah, standup time, can you ping me when you're done?
<axw> thumper: finished
<thumper> axw: quick hangout?
<axw> sure
<thumper> axw: https://plus.google.com/hangouts/_/g4kiddxgksppcg5jevrhyid5xqa?hl=en
<thumper> axw: re http://reviews.vapour.ws/r/169/diff
<thumper> wallyworld_: can I get a +1 from you here: https://github.com/juju/errors/pull/10
<wallyworld_> looking
<thumper> axw: has that branch got you wanting to slash your wrists?
<axw> thumper: a little bit :)
<axw> I'm on page 2
<thumper> \o/
<thumper> not too many changes needed I hope
<axw> no, but I haven't been particularly thorough and I'm not completely au fait with this user/auth stuff
 * thumper is happy with cursory
<axw> thumper: done
<thumper> axw: thanks
 * thumper looks
 * thumper hopes he didn't say thanks too soon...
<axw> thanks... FOR NOTHING
<axw> bbl, tea
<thumper> axw: thank you for the review. I know it was massive.  Tweaks made and pushing.
<thumper> I do wonder how we can fix the command API usage in a better way
<thumper> axw: we could inject from the outside in the tests, and have nil for the api normally
<thumper> axw: so if it is nil, we get the api calls from the appropriate api client
<thumper> axw: is that what you meant?
 * thumper thinks on this
<thumper> axw: I may look at changing it for my 'user list' command to see how it looks
<thumper> BOO YEAH!!!
<thumper> mega user manager branch merged first time
<wallyworld_> you sounds surprised?
<thumper> of course not, I checked it here first
<thumper> just happy that CI agrees with me
<thumper> wallyworld_: and related juju branch https://github.com/juju/juju/pull/937
<davechen1y> thumper: "Update to the latest juju/errors.
<davechen1y> Old Contextf and Maskf replaced by DeferredAnnotatef."
<davechen1y> how much of this is up for debate ?
<wallyworld_> ok
<thumper> wallyworld_: hey... isn't review board going to do this...
<davechen1y> zero, can be an answer
<wallyworld_> thumper: supposedly :-)
<thumper> davechen1y: zero at this stage...
<davechen1y> then LGTM
<thumper> davechen1y: but I'm open to listening
<davechen1y> didn't even read it
<davechen1y> DeferredAnnotatef means jack shit to me
<davechen1y> it's 0% improvement over the old, also unknowable methods
<thumper> well... I'm open to a better name, but couldn't think of one
<davechen1y> ok, so when you said zero is up for debate
<davechen1y> that was incorrect ?
<thumper> effectively it allows someone to say `defer <somename>(&err, "some text")`
<wallyworld_> thumper: just checked, github->reviewboard worked this time :-)
<thumper> so it can annotate the error response if it is non-nil
<thumper> davechen1y: can you think of a better name?
<davechen1y> After ?
<davechen1y> Possibly ?
<davechen1y> putting Deferred at the front is as bad as
<thumper> davechen1y: errors.MaybeAnnotate?
<davechen1y> type IInterface interface
<thumper> davechen1y: I don't particularly like the name
<thumper> davechen1y: but I couldn't think of a better one
<davechen1y> defer eerrors.Maybe
<thumper> so suggest away
<thumper> davechen1y: sounds like we aren't sure :)
<wallyworld_> what's wrong with IFoo interface? :-P
<davechen1y> sssstuttering
 * thumper stabs wallyworld_quitely
<davechen1y> wallyworld_: we're not all hungarian
<wallyworld_> i don't like hungrian, but don't mind IFoo
 * thumper doesn't like IFoo
<thumper> I prefer "Foo" for the interface
<thumper> and a concrete implementation
<wallyworld_> and FooImpl
<wallyworld_> i've used both
<thumper> or namespaced
<thumper> wallyworld_: got any ideas on a better name?
<thumper> I'm not sure about maybe
<wallyworld_> me either, .... maybe
 * thumper invites bikeshed colours
<thumper> davechen1y: any other ideas?
<wallyworld_> thumper: i don't mind Annotate
<thumper> wallyworld_: but it isn't Annotate
<wallyworld_> it should be obvious it will pass nil through
<thumper> it is currently 'DeferredAnnotatef'
<davechen1y> thumper: honestly, you';ve done the work now
<davechen1y> the work to change this now or change it later is the same
<davechen1y> so leave it
 * wallyworld_ is bad at names
<thumper> davechen1y: how about we paint it later?
<thumper> davechen1y: agreed
 * thumper merges for now
<thumper> davechen1y: magic words needed here: http://reviews.vapour.ws/r/232/
<davechen1y> "I ain't even mad, bro" ?
<thumper> ta
<thumper> bugger...
 * thumper waits for the bot to fail
<thumper> at least it should fail fast
 * thumper takes a deep breath and resolves a shed load of conflicts in his user list branch
 * thumper rages against the machine
<thumper> WTF...
<thumper> missing }
<axw> thumper: I meant it would be good if the cmd/juju package passed an API client into the cmd/juju/user command constructor (if it had one)
<axw> and the tests could do their own mock API client
<thumper> I don't think it knows at that time, but I have an idea...
<axw> IOW, make cmd/juju/user unaware of the API client code
 * thumper is trying it out
 * thumper promises to do documentation and email reading tomorrow
<thumper> long day...
<thumper> perhaps I'll exercise more tomorrow
<thumper> night folks
<fwereade> jam, do you have a few minutes? I need someone to talk to gsamfira about reboots
<fwereade> jam, I'm completely failing to multitask today and I don't want to drop the code I'm writing
<fwereade> alternatively, dimitern or voidspace, perhaps? ^^
<voidspace> fwereade: I'm happy to listen - not a topic I know about :-) Is that sufficient?
<dimitern> fwereade, hey, I'm sprinting in bluefin with mattyw and the cts guys for the rest of this week
<fwereade> voidspace, looks like it's you then :)
<fwereade> voidspace, you don'yt need to know anything going in
<voidspace> fwereade: sure
<voidspace> fwereade: do gsamfira sort this out between ourselves from here?
<fwereade> ok, gsamfira, voidspace -- please hang out and introduce yourselves at your convenience :)
<voidspace> cool
<voidspace> gsamfira: hi, do you want to start a hangout or shall I?
<gsamfira> voidspace: If you prefer a 10 minute hangout to bring you up to speed, we could do that now :)
<gsamfira> either way is fine :P)
<gsamfira> :)
<voidspace> gsamfira: that's fine - go ahead and start a hangout and send me the link
<gsamfira> link sent :)
<TheMue> morning
<TheMue> voidspace: now my power adapter broke and I had to organize a new one *sigh*
<voidspace> TheMue: my laptop is cursed
<voidspace> TheMue: it even broke your power!
<TheMue> voidspace: *rofl*
 * fwereade lunch, would love a review of https://github.com/juju/juju/pull/939
<jam> TheMue: voidspace: would you guys want to move the meeting up by 45min? It works better for me and means we won't run into this as much. (we'll need to move our 1:1 though voidspace)
<voidspace> jam: that's fine with me - I would prefer to move the 1:1 forward rather than back though :-)
<voidspace> jam: if possible
<voidspace> jam: 9:15am on a monday morning I tend to be a bit blurrier than usual...
<TheMue> jam: just done calculations due to change of CEST to CET this weekend. so if I'm right the meeting would be 15 mins earlier for me then from Monday on. ;) so change is ok.
<voidspace> gsamfira: ping
<gsamfira> voidspace: pong
<voidspace> gsamfira: how does jujud on the parent know to clear the reboot flag?
<voidspace> gsamfira: is it just on restart, if it sees the flag it clears it
<gsamfira> the lock is created on all machines. Parent and container. It gets cleared when the reboot worker starts
<gsamfira> both the local lock and the flag
<gsamfira> on the state machine
<gsamfira> https://github.com/juju/juju/pull/782/files#diff-127c383eb8a738c5f51ef175dfee5734R80
<voidspace> gsamfira: if jujud crashes (and is restarted by upstart) in between setting the flag and actually rebooting, what happens
<voidspace> (jujud on the parent machine - not the state machine)
<voidspace> gsamfira: or are you saying that it's the reboot worker on the state machine that knows when the parent machine has rebooted and clears the flag?
<gsamfira> right now, the flag gets set by the hook when the tool is called: https://github.com/juju/juju/pull/831/files#diff-8ff4032006e797fd3c81d33149202160R541 . When that happens, the worker notices the flag, grabs the locks and exits with worker.ErrMachineReboot. The machine agent then sees the error,  and issues a reboot
<gsamfira> so if the agent gets killed before the reboot is actually executed, when it comes back up, it simply clears the flag
<voidspace> and reboot doesn't happen
<gsamfira> problem is, that the containers might do the right thing anyway and shutdown
<gsamfira> yeah
<voidspace> what about if the flag was cleared *immediately* prior to the actual reboot command being executed
<voidspace> so there's only microseconds of race condition between the flag being cleared and the reboot for a crash to interfere
<gsamfira> I would actually prefer this, but that means reconnecting to state after the fatal error is returned
<gsamfira> if that is fine with everyone, I could revert to a previous version that did this
<voidspace> but william didn't like this approach?
<gsamfira> not that much. To be fair, it was a bit ugly.
<voidspace> it seems we just traded one race condition (jujud dies after clearing flag) for another (jujud dies after flag is set)
<voidspace> and clearing the flag before reboot saves having to have the uuid
<voidspace> I guess it depends on *how* ugly
<gsamfira> I can give it a shot and make it pretty
<gsamfira> :)
<voidspace> gsamfira: cool
<mattyw> voidspace, ping - when you have a spare moment - not urgent
<jam> voidspace: TheMue: I moved the time, just confirm that it matches what you were thinking it would be
<jam> TheMue: would you like to join the hangout again to quickly go over what you're working on?
<voidspace> jam: looks good
<voidspace> mattyw: pong
<mattyw> voidspace, cancel that ping actually
<mattyw> voidspace, but thanks anyway
<jam> voidspace: and then for our 1:1 how about just after the standup?
<voidspace> mattyw: unpong
<voidspace> jam: great
<mattyw> voidspace, ack
<voidspace> :-)
<jam> hmmm.. TheMue is probably out for lunch. I'm going to go help with homework and be back in a bit. Ping me when you're back around so we can coordinate again.
<TheMue> jam: back again
<TheMue> jam: short status is, that the test matrix and the tests are defined, in there is a setup for each scenario and here I'm currently working on (some manipulations in state, thankfully nowhere else)
<TheMue> jam: and new standup time is confirmed
<jam> TheMue: sounds good, I'm in and out a bit while I help with homework (we also had to discuss an incident at school today).
<TheMue> jam: oh, I know these discussions. I hope nothing too bad.
<jam> TheMue: just some pushing, etc. But wanting to make sure he learns well at 7 so it isn't a bigger problem at 17 :)
<TheMue> jam: hehe, good way, yes
<anastasiamac> ericsnow: Eric, I've committed some changes to github but did not get review automatically created... was I meant to have are view or do I need to do rbt stuff? I think it's meant to be 940 (number appended on PR)
<anastasiamac> ericsnow: did rbt meanwhile..
<jam> anastasiamac: http://reviews.vapour.ws/r/235/ "this review is not yet public"
<jam> anastasiamac: so is there an "anastasialinux" user ? :)
<anastasiamac> jam: i created 235 manually by running rbt post
<jam> anastasiamac: sure, but if you create one, you do still need to make it public when you're done
<anastasiamac> jam: i have ;-)
<jam> anastasiamac: anyway, it definitely looks like we need to check on why you didn't get an automatic review post
<jam> but the rbt thing seems to have worked
<anastasiamac> jam: mac is start of my family name and not an affiliation :-)
<anastasiamac> jam: thnx for checking. i really appreciate
<jam> anastasiamac: I realized that, but when I first read it I thought it was because you had multiple active accounts and this was you connecting from your mac (given the recent discussions we've been having of trying to get you set up.)
<jam> I realized when I saw your github name was the same
<jam> anastasiamac: fwiw, you should also be added to the github.com/juju/ "hackers" team, so you can vote on merge proposals, etc. I'll do that now
<jam> hmm.. .says you are part of the team, what is the sorting on this page
<jam> I see you there now
<jam> anastasiamac: I thought that might be part of the reviewboard issue, but obviously not related
<anastasiamac> jam, ericsnow: my push had 2 commits with 25 files overall... maybe that caused an issue?
<jam> anastasiamac: it shouldn't
<jam> we've certainly had much bigger
<anastasiamac> jam: oh well, I'll put it down to beginner's luck and will call it a nite :-) thnx for feedback!
<natefinch> ahh
<natefinch> yes, that's a good fix for the import cycle.  Or at least, an expedient fix
<natefinch> this is a good place to use the export_test pattern
<natefinch> i.e. make an export_test.go file, which by definition is only compiled when peergrouper tests are running - it can export the private functions that the tests need
<natefinch> so like
<natefinch> var PrivateFunction = privateFunction
<natefinch> will make privateFunction available for use in tests, just have to rename the calls to use PrivateFunction instead
 * fwereade needs a walk, bbiab
<perrito666> natefinch: I was making that but dind find a way for the types
<perrito666> so I guess a solution there is to always export the types and since members are private make accessors for those in export_test
<perrito666> man, its so hard to get anniversary gifts when you share credit cards with your wife :p
<natefinch> haha
<natefinch> perrito666: yeah, not sure what to do about types
<perrito666> I googled a bit and I dont see a much cleaner solution for types
<perrito666> I mean I do, but I dont know if the cost of re-writing half peergrouper is worth it
<voidspace> computer having "issues"
<voidspace> rebooting
<natefinch> ug, so I had the stupid idea to try out vim today.... I can't even finish making my .vimrc without hitting what seems like a ridiculous bug
<natefinch> Wanted to set up the right tabstops, so google, find this: http://stackoverflow.com/questions/1878974/redefine-tab-as-4-spaces/1878984#1878984
<natefinch> right, so copy and paste into my vimrc, right?  WRONG
<perrito666> that works
<perrito666> that is what is on my vimrc
<rick_h_> natefinch: heh, it hates you
<natefinch> it's not that the content is wrong... it's that copy and paste is fubared.  What actually gets pasted is this: http://pastebin.ubuntu.com/8628514/
<rick_h_> natefinch: heh, :set paste
<rick_h_> natefinch: I've mapped it to F11
<rick_h_> natefinch: but yea, that happens, not a bug.
<rick_h_> natefinch: it's other vim settings kicking in for you
<rick_h_> and then :set nopaste to turn back
<perrito666> natefinch: for vim every input is input, so if you dont set paste as rick_h_ says it will try to autocomplete your text
<rick_h_> and do things like carry on your comment block from one line to the next/etc
<rick_h_> which is darn handy writing a comment block, but sucks for pasting text
<perrito666> natefinch: if you think that sucks try pasting html :p
<natefinch> this is the problem with using a terminal as software - vim can't tell the difference between a paste and me typing really fast.  Which is epically dumb
<perrito666> natefinch: there is no, you are not using a paste feature of the editor
<natefinch> I was even ok with having to put vim into edit mode, but now I need to put it into paste mode too?  Do people not copy and paste all the time in vim?
<perrito666> natefinch: but if it makes you feel better you can use gvim
<rick_h_> natefinch: not large blocks of text with mixed comments/etc no
<perrito666> which is perhaps the most esthetically offensive piece of software ever
<rick_h_> natefinch: didn't they teach you copy/paste is bad :P
<natefinch> perrito666: I did run gvim for just long enough to have it burn my eyes before I closed it down
<rick_h_> esthetically? it's an editor. Give me a blinking cursor and a keyboard baby :)
<rick_h_> ah, right you have to turn off all the menu/tec
<rick_h_> etc
<rick_h_> toolbars
<perrito666> rick_h_: I like my editor to be surrounded by not so much uglyness
<perrito666> :p
<rick_h_> perrito666: I prefer it to be surrounded by nothing :)
<perrito666> hehe
<rick_h_> perrito666: natefinch pics sent with gvim running :)
<perrito666> rick_h_: you use gvim set up exactly like vim :p
<perrito666> you dont use the ugly graphical things that come in gvim
<rick_h_> perrito666: except I get better mouse integration and such :)
<rick_h_> perrito666: but yea
<perrito666> rick_h_: ah true, interesting indea, I might try it, although I have picked the habit of bg/fg mi vim after peer programming with mgz
<rick_h_> perrito666: ah, I just us tiling and flip active windows vs fg/bg
<mgz> eheh, evil ways
<perrito666> aghh why ubuntu keeps setting my apt with local mirrors
<natefinch> vim tutorials need to be written by people who *haven't* been using vim for 30 years
<perrito666> natefinch: they need to be written by both, the new people write "to do this use <placeholder>" and then the old guys fill placeholder
<natefinch> they're all like 10 pages of different ways to edit and delete shit, and you have to do a full text search to find all the basic stuff.  Like, how do I make a new tab?  How to I switch tabs?  How do I open a friggin' file from inside vim?  How do I undo?
<perrito666> natefinch: just create your own config, itll be faster, I dont think anyone uses the defaults for thos
<perrito666> those
<perrito666> they suck
<natefinch> ok, so .... how do I open a file once I'm in vim?  it seems like :o is the right thing, except vim doesn't seem to like anything I type after that as a filename
<perrito666> natefinch: :edit file
<perrito666> for the current buffer
<perrito666> :tabnew blah
<perrito666> for a new tab
<perrito666> and if you have a decent sized screen you can :vsplit your screen
<natefinch> ok
<natefinch> how do I switch to the other buffer?
<mfoord> TheMue: after I made the change to use a const for "none", are you happy with my ec2 SupportAddressAllocation mp?
<perrito666> natefinch: :buffer numbe
<perrito666> to know which is which :buffers
<perrito666> natefinch: you could use nerdtree which is that fs tree that you can see on rick_h_ gvim, but it sucks
<natefinch> no but really, how do you actually do it, because I'm not typing 14 characters every time I want to switch back and forth
<perrito666> there is only so much you can do with a terminal
<perrito666> natefinch: lol, I dont use buffers I use tabs
<mfoord> TheMue: http://reviews.vapour.ws/r/211/
<perrito666> but I actually have a shortcut around there for changing buffers
<TheMue> mfoord: sure, mom
<natefinch> perrito666: I have a 30" screen, not using a split screen would be terrible
<perrito666> natefinch: noone really types these things, you figure the ones you use and shortcut them
 * natefinch goes back to sublime text
<perrito666> natefinch: lol
<perrito666> vim is a way of life, you cannot have one day stands with it
<perrito666> btw, good luck exiting vim
<TheMue> natefinch: hehe, I moved back from ST to my good old vim.
<natefinch> haha.... I know how to exit vim :)  I learned to edit with vim a long time ago because ssh...
<natefinch> you know what I can do with sublime text? Grab a tab, pull it into a different window on a different screen.  It takes a half a second with this new fangled thing they call a mouse :)
<TheMue> what is a mouse?
<mfoord> I'm pleased that are still options for those afraid of GUIs
<TheMue> those animals our cat fetches from time to time?
<mfoord> ;-)
<perrito666> natefinch: I like sublime, I just dont feel like paying 70 bucks for it :p
<natefinch> perrito666: I found it to be worth the $70 after using it in nag-mode for a year or so
<TheMue> or you can reserve one of your cores and run Atom
<natefinch> lol
<natefinch> I did eventually install Atom, but after running it for about 30 seconds I didn't really see a point if I was already used to ST
<natefinch> and ST is like 1000 times faster
<perrito666> I actually wrote my own IDE with a friend, but we are both too lazy to add go support
<TheMue> natefinch: but hey, you can develop plugins in this fantastic language they call JavaScript
 * TheMue has to say he likes JS like he likes having a flu
<perrito666> TheMue: I dont really mind writing it, as long as I dont have to read it
<TheMue> perrito666: oh, so now I know how you are. you abuse maintainers. WORN (write-once, read-never) coder.
<TheMue> :D
<perrito666> TheMue: only in javascript, and perhaps php if I really have to
<TheMue> perrito666: ouch, ok, reasonable ;)
<perrito666> TheMue: the last time I had to write JS my job description was senior python dev, so I only wrote the JS with the "father helping child to do homework" disclaimer "Ill write this, but you will have to understand it and explain it later" :p
<TheMue> perrito666: hehe, reminds me of an old colleague and perl fan. first comment in his code: "don't read any further if you don't understand this statement: ..." with something I never understood.
<perrito666> lol
<rick_h_> natefinch: https://www.youtube.com/watch?v=XXJO_Swmdnw and https://www.youtube.com/watch?v=KVAeelM-0QI
<rick_h_> natefinch: and https://www.youtube.com/watch?v=SzrcMilnre8
<natefinch> rick_h_: thanks... those looks cool, but I think I'll stick with ST.  I'm not sure I'd really get much from vim, other than hacker cred
<rick_h_> natefinch: cool, use what works for you. If you think on vim again let me know. it takes some time but I can't move back
<rick_h_> natefinch: have the same keybindings in my shell as I do in my editor and such, <3
<perrito666> mm, private methods on interfaces behave funny :p
<sinzui> natefinch, is there a plan for win images in os streams, possibly at cloud-images.ubuntu.com
<bodie_> hello all, I'm trying to call a subpackage API client (api/actions/client.go) from cmd/juju; however, there's no NewAPIClient method for that subpackage client type on cmd.Context
<natefinch> sinzui: we're trying to figure out what to do with win images...
<perrito666> rick_h_: the videos suggested from your links are fun "how to become ultra productive writing code with vim" I am sure that if the difference on the speed of your programming is significant depending on how fast you write you re not putting enough though into your logic
<perrito666> rick_h_: but the video tutorial is nice
<rick_h_> perrito666: they're my videos :)
<rick_h_> perrito666: did them a few years ago trying to help convert some folks
<perrito666> rick_h_: the bar with the keys+mouse is a nice touch
<rick_h_> perrito666: and true enough, but there are times when you've given tasks that knowing the editor better help make a lot smoother, TDD, csv/test data editing/etc
<perrito666> rick_h_: true, the thing is I actually clicked on some of those suggestions :p
<rick_h_> being better able to flow from MVC files of code and such are really helpful keeping the brain on track
<perrito666> rick_h_: I see you really make something of the mouse integration Ill try gvim again
<bodie_> let me grab a quick review on https://github.com/juju/names/pull/30
<bodie_> miniscule change to export a struct member for using tags over the wire, blocking an api PR
<perrito666> sometimes godeps reminds me too much of ensure availability
<bodie_> I noticed there's a Go mode for LightTable
<bodie_> kinda curious about that
<natefinch> someone review this trivial change?  It's just a typo: http://reviews.vapour.ws/r/214/
<mfoord> g'night all
<perrito666> natefinch: done
<natefinch> perrito666: thanks
<perrito666> np, running tests, not like I can do much else at some parts
<perrito666> mm can anyone run the full test suite?
<perrito666> I got provisioner failing when I do a full run but not on isolation
<natefinch> quick review to fix a critical bug?  http://reviews.vapour.ws/r/237/
<natefinch> perrito666: I'll run the full test suite if you review that fix :)
<perrito666> heh
<perrito666> btw, the review board thing is empty Ill use github
<natefinch> dammit
<natefinch>  mongod --version
<natefinch> TokuMX mongod server v2.0.0-mongodb-2.4.10, using TokuKV rev 668f1118593ba0976b6ec68768062f64d418ec83
<ericsnow> natefinch: is it still not posting the diff?
<natefinch> ericsnow: dunno, didn't notice
<natefinch> ericsnow: guess not
<natefinch> perrito666: I uploaded the diff
<natefinch> ericsnow: at least rbt post -u is working now
<ericsnow> natefinch: looks like RB was fussing about the diff that github gave it
<ericsnow> natefinch:  only one other auto review request  has had any issues (unicode related)
<perrito666> natefinch: I can think of a couple of nicer fixes
<natefinch> perrito666: oh yeah?
<perrito666> like making updateDistroInfo take a Reader and making something else wrap it and you can test updateDistroInfo and ignore the wrapping function that only opens a file
<perrito666> natefinch: and I am pretty sure that there is a way to use PatchValue :p but I have not looked that much into it
<perrito666> "oh yeah?" from your manager usually means that I will end up doing the programming equivalent of cleaning toilets right?
<natefinch> perrito666: I was trying to go as neutral as possible :)
<natefinch> perrito666: it's a good point about avoiding reading from disk
<perrito666> natefinch: also I feel that SetDistroInfo breaks isolation a bit
<natefinch> perrito666: it's in export_test so it only is exposed to tests in that package
<perrito666> natefinch: breaks isolation between tests
<perrito666> there are no other tests, so its a bit irrelevant
<perrito666> but you never know
<natefinch> perrito666: oh, I see what you mean
<perrito666> there, nice and tidy in the right lines in the reviewboard
<perrito666> I am not that clear explaining it on the air
<bodie_> hm
<katco> ok this is driving me slightly batty... i have 2 testing suites, A embeds B. A has a TearDownTest and if i reset a context in this method, i get a panic saying it's already been reset. if i don't, it's not reset. is anyone familiar with gocheck and suites?
<perrito666> ericsnow: I believe the name resolution of reviewboard is not going so well in mails
<perrito666> http://ec2-54-165-123-2.compute-1.amazonaws.com/r/238/
<perrito666> :p
<ericsnow> perrito666: yeah, I saw that
<bodie_> my godeps -t $(go list github.com/juju/juju/...) > dependencies.tsv.new is significantly different than the old one.  is anyone else having this issue?
<ericsnow> perrito666: it's on my list of low-priority bugs :)
<perrito666> ericsnow: completely agree
<natefinch> perrito666: I fixed the isolation thing.  I don't think I'll bother to fix writing to disk... it's not a huge deal, and it keeps the production code more obvious
<perrito666> I couldnt care less what is before /r/###
<perrito666> katco: that sounds odd
<perrito666> its the only difference?
<bodie_> this is the case even if I do godeps -t *in master immediately after running godeps -u*
<katco> perrito666: meaning only difference between tip and my branch?
<perrito666> katco: the only difference between your two suite runs is commenting the context reset?
<katco> perrito666: ah, yes. if i toggle commenting out the resetContext(...) i get different classes of failures
<katco> perrito666: commented out, i get a complaint that i'm adding a machine trying to be a state server when it's the 3rd machine to be added (context not being reset)
<katco> perrito666: uncommented, i get the panic saying it's already been reset
<katco> perrito666: and i'm fairly sure it's something to do with order of operations b/t the embedded suite and how i'm calling TearDownTest et. al. but i'm not able to pin it down as of yet
<perrito666> katco: I was unde the impression that if you want to call TearDownTest on a "parent" type you need to do it explicitly
<perrito666> so I am a bit puzzled
<katco> perrito666: me too... i mean please work under the assumption that i'm just doing something wrong. i just don't know what.
<perrito666> natefinch: I am not savvy enough to know if that solves the issue of concurrency
<katco> perrito666: http://reviews.vapour.ws/r/87/diff/#3
<katco> perrito666: you can see on L2602 i commented out the reset because my tests were panicing, but now the StatusSuite has a failure
<perrito666> katco: this might sound idiotic, have you tried swaping the calls?
<katco> perrito666: i believe when i first ran into it, but let me try again
<perrito666> katco: have you tried turning it off and on again?
<perrito666> :p
<katco> perrito666: wait a second... have i wandered into a tiere-1 call-center!?
<perrito666> Well, I am south american :p
<katco> i'm not using windows dammit! there is no start button!
<perrito666> and I worked on a call center for 6 hs
<katco> (tests running now)
<bodie_> so I guess nobody else is having that problem? lol
<perrito666> bodie_: sorry I have not tried, but I actually did not add a dependency in ages
<perrito666> bodie_: natefinch is the resident godeps guru :p
<bodie_> yeah, it's something different, a whitespace thing I think
<katco> perrito666: oh btw, what is even stranger is i'm doing -gocheck.f to filter down to just a StatusSuite test, yet this is still having an effect
<thumper> waigani: are you really around?
<thumper> waigani: notice the new standup time?
<natefinch> bodie_: you know you can just do godeps -t ./...
<katco> perrito666: test failed with a panic still =/
<perrito666> morning thumper
<waigani> thumper: yes and no
<thumper> o/ perrito666
<katco> hiyo thumper
<natefinch> bodie_: from the juju root dir of cours
<thumper> waigani: it is now
<waigani> ah
<bodie_> natefinch, aye
<perrito666> katco: at that point I believe its worth seeing what is going on in the parent TearDown
<bodie_> natefinch, http://paste.ubuntu.com/8631657/ is the diff against master immediately after godep -u
<natefinch> bodie_: so, yes, I see some differences... but it's mostly BS
<bodie_> right
<katco> perrito666: tons of stuff... it hooks into JujuConnSuite
<bodie_> I've just bumped into this before and I'm not sure what's happening or why -_-
<bodie_> very irritating to fix manually
<bodie_> just wondering if it's something someone else has seen before I assume PEBKAC
<perrito666> bodie_: wrong version of godeps?
<bodie_> just updated godeps to make sure
<natefinch> bodie_: so, the bitbucket ones are because they're windows only, and godeps currently only shows the dependencies for things that are compiled for your current OS.  This is fixable in our code if we're careful
<katco> niemeyer: ping
<perrito666> bodie_: we are programming the thing, its always PEBKAC
<natefinch> for example I did this with my npipe code... you just import it without using it
<niemeyer> katco: Hey
<bodie_> weeeell, there's pebkac and then there's pebkak::ID-10T
<katco> niemeyer: howdy :) i have a gocheck question. i'm seeing some behavior i don't understand
<katco> niemeyer: do you have time to review the backlog b/t me and perrito666?
<niemeyer> katco: Not right now, but I can do it soon
<natefinch> bodie_: the syslog difference is just an ordering difference, someone didn't put it in the right spot
<niemeyer> katco: I can answer a specific question now, though
<katco> niemeyer: not a problem, whenever you can get to it. thank you :)
<bodie_> natefinch, okay, I just want to make sure I'm not that person before I go opening a PR with content that messes it up for others
<natefinch> bodie_: and errgo... I don't have a difference for errgo in mine... I can't tell what the actual difference is in your pastebin
<katco> niemeyer: i'm not sure i can pin it down to 1 question... it's a dependency issue b/t testing suites and TearDownTest
<katco> niemeyer: trying to reset a context, but if i do that it panics b/c calling TearDownTest on parent suite also does that
<katco> niemeyer: however if i don't, it appears as though the context doesn't reset
<niemeyer> katco: Okay, there are no "parent" suites, strictly speaking
<natefinch> bodie_: I tried to get people to let me put in a test that ensures godeps -t outputs the same contents as are in dependencies.tsv but I got shot down
<katco> niemeyer: sorry, a suite i've chosen to embed within another suite
<niemeyer> katco: Got it.. still doesn't make much sense to me.. will need more context indeed
<katco> niemeyer: i'm almost absolutely doing something wrong and stupid. just trying to figure out what :)
<natefinch> bodie_: ahh, I see... someone removed the use of errgo but didn't remove the godeps entry
<bodie_> there we go
<bodie_> okay
<bodie_> cool
<bodie_> and I'll just leave the windows deps in there
<natefinch> bodie_: yep
<perrito666> it would be awesome if godeps would support creating dependencies with the same type of filter as go _windows _linux and such
<natefinch> bodie_: I blame thumper
<natefinch> or rather, git blame does :)
<thumper> wat?
<natefinch> perrito666: yeah, roger wants to add that, but hasn't gotten around to it
<perrito666> mmmpf on my way back from brussells I watched the lego movie and now every time I read/say/hear awesome this obnoxious song pops into my head
<natefinch> thumper: dependencies.tsv still included github.com/juju/errors
<natefinch> er errgo
<thumper> davecheney: http://reviews.vapour.ws/r/233/
<thumper> netyes...
<thumper> natefinch: yes
<thumper> natefinch: errgo has slipped into juju/charms and juju/utils
<thumper> so until that is unpicked, still needed
<natefinch> thumper: godeps doesn't think it's used anymore
<natefinch> thumper: maybe that's been fixed
<thumper> maybe...
<natefinch> apologies... not your fault, then
<natefinch> thumper: yeah, quick grep says it's not used anymore.  That's good.
<thumper> natefinch: feel free to submit a branch that removes it
<bodie_> hrm
<bodie_> thumper, it'll be in reviewboard 178 in about 1 minute -- should I just include that change there?
<bodie_> thumper, the godeps tweak to remove errgo, that is
<bodie_> thumper, also, I could really use a confirmation on your query there
<bodie_> http://reviews.vapour.ws/r/178/#comment1225
<natefinch> http://reviews.vapour.ws/r/239/
<natefinch> thumper: ^
<natefinch> removes errgo and fixes the ordering and fixes the windows-only imports problem so godeps -t ./... > dependencies.tsv produces the right output
<niemeyer> katco: Okay, here
<katco> niemeyer: can you review the backlog, or would you like me to go over it again?
<natefinch> thanks for the review davecheney
<niemeyer> katco: Reading
<katco> ty
<niemeyer> katco: What does it mean to "reset a context"?
<katco> http://reviews.vapour.ws/r/87/diff/#3 L2602
<katco> it is in JujuConnSuite; looks like it kills pingers and then calls JujuConnSuite.Reset
<thumper> bodie_: so, re http://reviews.vapour.ws/r/178/#comment1225, I don't think that ServicesCharmActions is a good client call.
<thumper> bodie_: it exposes the wire protocol objects unnecessarily
<thumper> bodie_: and it isn't going to be called by the juju command line client
<thumper> bodie_: perhaps just don't export the method?
<thumper> menn0: hangout?
<menn0> thumper: yep. the standup one?
<thumper> sure
<niemeyer> katco: Have you noticed there are two different suites being setup there?
<niemeyer> katco: StatusSuite and JujuConnSuite?
<niemeyer> katco: While there's only a single anonymous type in the struct
<bodie_> thumper, sounds good to me
<katco> niemeyer: in filteringFeature's SetUpSuite?
<niemeyer> katco: In the suite
<niemeyer> katco: filteringFeature is manipulating sub-fields on an embedded suite
<niemeyer> katco: and in the TearDownTest, the commented out method I suppose is a method of the anonymous field as well
<niemeyer> katco: So there are at least three different ways in which the embedded suite is being used:
<niemeyer> 1. An explicit method of the embedded type
<niemeyer> 2. A method of a field from the embedded type which is a suite
<niemeyer> 3. A suite method from the embedded type
<niemeyer> katco: I'm not surprised the behavior is unclear
<niemeyer> katco: Unfortunately I cannot tell you what is wrong, but I bet that cleaning up that situation would reveal the problem
<katco> niemeyer: so, i believe i'm only utilizing methods on my embedded type (StatusSuite) which may be forwarding calls onto its embedded suite(s)
<niemeyer> f.JujuConnSuite.SetUpTest(c)
<niemeyer> katco: That's not a method of the embeded type
<niemeyer> katco: It' s a method of a field of the embedded type
<katco> niemeyer: ah i missed that... i think that's in error, let me correct it
<niemeyer> katco: and then there are both
<niemeyer> f.StatusSuite.TearDownTest(c)
<niemeyer> and the suggestion of
<niemeyer> f.resetContext(c, <-f.ctx)
<niemeyer> Which is the problematic piece
<katco> niemeyer: except the ctx i pass in is a member of filteringFeature... but perhaps resetContext relies on some member variables of statusSuite?
<niemeyer> katco: I don't really know
<katco> niemeyer: also puzzling is how 2 different instances of suites could affect one another
<niemeyer> katco: I would try to make the interface of StatusSuite more clear
<niemeyer> katco: and would probably not have it as a suite in the first place, if it's supposed to be a helper
<katco> niemeyer: i think you're on the right track... i'll start teasing things apart
<katco> niemeyer: thank you :)
<niemeyer> katco: Code that calls one another can affect one another.. :)
<niemeyer> katco: Which is why a cleaner interface would help out
<niemeyer> katco: np
<katco> niemeyer: hrm, but if they're separate instances, i don't know how that works haha
<katco> niemeyer: at any rate, thanks for taking the time
<niemeyer> katco: I have avoided using that sort of SetUpSuite/TearDownSuite "forwarding" in recent projects
<niemeyer> katco: It's much better to have a helper with a clear interface that is called out by the suites
<niemeyer> katco: So there's only one SetUpSuite/TearDownSuite
<katco> niemeyer: it does cause complexity, but it appears to be the way juju does things at the moment
<niemeyer> katco: and the tasks inside it are clear
<katco> niemeyer: i like your idea better
<niemeyer> katco: Well, it doesn't have to be
<waigani> thumper: inserting a new instanceData doc, what fields need to be populated? _id, instanceid ...
<thumper> waigani: pretty much
<waigani> ok
<thumper> waigani: what file is it in again?
<waigani> thumper: state/upgrades.go
<thumper> waigani: I was meaning the instance data struct
 * thumper has found it
<waigani> oh sorry
<thumper> waigani: you'd need a status too
<waigani> where do we get the status from?
<waigani> ah machine.Status()
<thumper> waigani: hmm...
<thumper> waigani: no, that appears to be a different status...
<thumper> waigani: just don't worry about the instance status, that is provider specific
<thumper> and can be empty
<thumper> should be fine
<waigani> thumper: sgtm
<bodie_> thumper, tweaked what you asked for on RB 178
<thumper> davecheney: would be good if you could look at http://reviews.vapour.ws/r/233/ earlyish so I can address issues to land today
 * thumper goes to walk the dog while the weather is still good
<waigani> davecheney: wont the 9am stand-ups be very early for you?
<davecheney> waigani: meh
<thumper> ericsnow: are you still on http://reviews.vapour.ws/r/237/ ??
<thumper> ericsnow: it is critical and blocking landing
<ericsnow> thumper: I took a cursory look at it but perrito666 was already giving it a more thorough review
<thumper> ericsnow: I thought it was your branch
<ericsnow> thumper: I'm not sure where Nate left it
<thumper> who owns it?
<ericsnow> thumper: Nate (at least he did)
<thumper> it shouldn't just be left...
<thumper> it is a critical bug
<thumper> grr
<ericsnow> thumper: I can pick it up
<thumper> ericsnow: I'll take it
<thumper> it is your EOD
<ericsnow> perrito666: do you know where Nate left that distro info patch?  was he still addressing any of your comments
<ericsnow> ?
<ericsnow> thumper: k, thanks
<ericsnow> thumper: FYI Nate and Horacio were having a lengthy discussion here about the patch
<thumper> ericsnow: yeah I commented too
<ericsnow> thumper: ah
<davecheney> ericsnow: why does reviews.vapour.ws now direct us to the ec2 machine directly ?
<davecheney> http://ec2-54-165-123-2.compute-1.amazonaws.com/r/233/
<ericsnow> davecheney: you mean in the emails?
<davecheney> yup
<ericsnow> davecheney: yeah, I noticed that earlier today too; haven't had a chance to look into it
<ericsnow> davecheney: looks like a setting got flipped
<ericsnow> davecheney: I've set it back to reviews.vapour.ws so it should be squared away now
<davecheney> ta
<ericsnow> see you all in a few hours
<thumper> davecheney: I've taken nate's branch for the critical blocking bug
<thumper> davecheney: should have a review for you shortly
<thumper> just running the tests
<davecheney> kk
<davecheney> thumper: did ou see my followup to 233 ?
<thumper> davecheney: yeah, I'll test the constants
<thumper> when I had vars it complained
<thumper> I then assumed it would also complain with the const
<davecheney> thumper: take your c++ hat off
<davecheney> and put your feet up
<thumper> ha
<thumper> davecheney: https://github.com/juju/juju/pull/947
<thumper> davecheney: expecting rbt to pick it up
<thumper> davecheney: http://reviews.vapour.ws/r/244/
#juju-dev 2014-10-23
<waigani> thumper: http://reviews.vapour.ws/r/177/
<anastasiamac> davecheney: could u please review http://reviews.vapour.ws/r/235/ - it'd b gr8 to land it :-)
<davecheney> anastasiamac: sure
<anastasiamac> davecheney: thnx!
<davecheney> anastasiamac: not lgtm
<davecheney> sorry
<davecheney> config.AgentMetadataURLKey: "
<davecheney> i don't think this payus for itself
<davecheney> are we really going to be changing the definition of this so frequently that we need to move it's definition to a shared location ?
<davecheney> the reason I say this is
<davecheney> all the test fixtures still assert it's a constant
<anastasiamac> davecheney: u mean using variables instead of string?
<davecheney> yup
<menn0> thumper: https://github.com/mjs/juju/commit/b7f48aa500f6aba285320c6a4aa184736d287b1a
<davecheney> anastasiamac: all the fixtures still encode the string directly
<davecheney> so does the documentation and the examples
<davecheney> i don't feel this pays for itself
<menn0> thumper: this is the commit that adds various hacks to allow the machine agent to start so that it can run the machine env UUID upgrades
 * thumper wonders how horrible it is
<menn0> thumper: it's actually mostly done, except for some unit test changes
<thumper> ok, it doesn't look TOO long
<anastasiamac> davecheney: m not big fan of retyping the same string. if a string is used more thn once, it should b a variable...
<menn0> thumper: it's a bit horrible but the horribleness is fairly localised
<davecheney> anastasiamac: but you ended up typing a slightly longer variable ...
<menn0> thumper: instead of storing and using a DB version, the code checks for evidence of the upgrade being in place
<menn0> thumper: this is safer IMHO
<menn0> thumper: because otherwise you end up with points in time where the DB has been changed but the version hasn't
<davecheney> thumper: i will be late for the team meeting
<davecheney> have 1:1 with robbiew
<thumper> kk
<davecheney> ericsnow: reviews.ws has gone back to reporting it's ec2 url again
<davecheney> just got another email from the wrong address
<anastasiamac> davecheney: :-) what length would u consider k for a variable? also should the name be descriptive? eg. here would AgentURL be k?
<ericsnow> davecheney: (â¯Â°â¡Â°)â¯ï¸µ â»ââ»
<menn0> thumper: does this approach look ok to you?
 * thumper looks in detail
<thumper> anastasiamac: I like descriptive names
<thumper> please don't be sucked in to thinking shorter is better
 * thumper is opinionated on this
<anastasiamac> thumper: i agree. shorter is not always practical..
<anastasiamac> thumper: by the same token, metadata is 8 chars... ;-(
<davecheney> anastasiamac: i'm not arguging about the length
<davecheney> its the fact that this change doesn't pay for itself
<davecheney> you can't turn all the test fixtures into variables as well
<davecheney> or the examples
<davecheney> or the documentation
<davecheney> or the yaml keys
<davecheney> etc
<thumper> menn0: mostly looks ok
<thumper> not gone through in exceptional detail yet
<davecheney> seriously, i missed the meeting ?
<thumper> davecheney: yeah...
<thumper> davecheney: we were done in 15 minutes
<thumper> davecheney: it seems that rb doesn't pick up juju/cmd
<thumper> https://github.com/juju/cmd/pull/8
<thumper> wallyworld_: or you maybe? ^^^
<thumper> or axw...
<wallyworld_> wot
<thumper> simple change
<wallyworld_> ok
<thumper> juju/cmd update
<wallyworld_> thumper: are other sub command affected besides juju user?
<thumper> wallyworld_: it only impacted nested subcommands
<thumper> and only if you didn't say anything else
<wallyworld_> ok
<thumper> so 'juju user' would miss out the 'juju' prefix in the help output
<thumper> juju user --help was fine
<thumper> juju user help add was fine
<thumper> juju user add --help was fine
<thumper> juju user was not
<wallyworld_> ack
<wallyworld_> sadly you still need to hit the merge button manually for this sub repo i think
<thumper> will do
<thumper> wallyworld_: I also noticed that all the licences were wrong
<thumper> wallyworld_: I'll submit another quick one to fix that
<wallyworld_> for cmd/juju?
<wallyworld_> i thought robbie had audited everything
<thumper> it still shows AGPL
<thumper> instead of LGPL with exception
<thumper> OH FFS
<thumper> should the file be LICENCE or LICENSE?
<thumper> we have a mix
<thumper> LICENSE
<thumper> according to the world
<anastasiamac> thumper: one is noun, on is verb..
<thumper> WTF?...
<anastasiamac> thumper: ~ce (from French/Latin), ~se (from Mid English)...
 * thumper found a weird file...
<thumper> wallyworld_: https://github.com/juju/cmd/pull/9
<wallyworld_> ceis noun
<wallyworld_> se is verb
<wallyworld_> like practice and practise
<wallyworld_> and advise and advice
<thumper> I always get that shit wrong
<thumper> wallyworld_: so in that PR, you'll notice I also remove names.go
<wallyworld_> easy to remember - ice is a noun'
<thumper> which should never have been there in the first place
<wallyworld_> ok
<wallyworld_> why are we changing LICEENCE to be incorrectly spelt?
<wallyworld_> oh the irony. LICENCE
<thumper> because this is what the world has
<thumper> oh it also appears to be an americanism
<wallyworld_> yes :-(
<wallyworld_> americans cannot spell for shit
<thumper> http://oss-watch.ac.uk/resources/opensourceyourcode#applying-the-licence
<thumper> says to have LICENSE
<wallyworld_> we are an englidh company
<thumper> not LICENCE
<wallyworld_> english
<thumper> that is a .uk site
<wallyworld_> but the farking url says licence
<thumper> notice the header: Applying The Licence
<wallyworld_> sigh
<thumper> GNU LESSER GENERAL PUBLIC LICENSE
<thumper> notice the SE
<wallyworld_> but but but
<wallyworld_> sigh
<thumper> don't shoot me
<thumper> I'm just trying to be consistent
<wallyworld_> they know it's wrong or else why have licence in their url
<wallyworld_> sigh
<anastasiamac> thumper: be original and say it in german
<thumper> :P
<wallyworld_> "es"
<wallyworld_> or "der" or "sie" depending on gender
<wallyworld_> did I pass?
<davecheney> thumper: it's spelt COPYING
<thumper> ha
<menn0> thumper: PTAL http://reviews.vapour.ws/r/175/
<thumper> menn0: kk, need to look at waigani's first
<menn0> thumper: np
<thumper> wallyworld_: wouldn't ya know it, juju was depending on that names package in juju/cmd
 * thumper will fix with the branch that increments the dependency
<thumper> wallyworld_: and the backups command test checks for a wrong usage :-)
<wallyworld_> \o/
<anastasiamac> ericsnow: rbt problem.. probably related to the issue of creating my request yesterday... update did not occur automatically either. I had to manually update it...
<wallyworld_> fwereade_: i have to go to soccer - do you have a little time to pop into #juju on canonical and offer some insight into some relation departed issues they are having in oil? some relations are behaving, others aren't, and i'm a little unclear on what to tell them
<fwereade_> wallyworld_, I'll see what Ican do, thanks
<wallyworld_> you rock
<mattyw> morning everyone
<fwereade_> mattyw, updated http://reviews.vapour.ws/r/234/diff/
<fwereade_> mattyw, fwiw, it's almost all just moves
<fwereade_> mattyw, the only things that should really be worth paying attention to are the code that's moved from uniter into context.factory; and the proxy junk that I deleted from uniter (which kinda comes under the same heading anyway)
<mattyw> fwereade_, ok great, I'll take a look this afternoon
<voidspace> dimitern: ping
<dimitern> voidspace, pong, give me 20m please, doing a test now
<voidspace> sure
<fwereade_> does anyone know why we use an abstract socket for the jujuc server, but a filepath socket for the juju-run listener?
<fwereade_> wallyworld_, when you return, ^^ -- on the basis that you're sort of near thumper and might know why he did it
<fwereade_> gsamfira, does juju-run work on windows?
<fwereade_> gsamfira, the tests have linux stuff hardcoded, I don't see how they can run
<gsamfira> fwereade_: juju-run should work on windows, unless someone changed that code :). Instead of a unix socket, juju-run uses named pipes on windows
<fwereade_> gsamfira, if the tests don't pass, I don't really consider it working ;p
<gsamfira> those tests have yet to be fixed on windows
<fwereade_> gsamfira, what's the progress there?
<gsamfira> yeah, a little more then half the tests pass on windows
<fwereade_> gsamfira, because, you know, code without tests *is* fundamentally broken
<gsamfira> fwereade_: my colleagues are working on the tests
<fwereade_> gsamfira, in the same way that data without offsite backups only happens to exist by coincidence
<fwereade_> gsamfira, I know, and I'm glad that they are, I'm just stressing about it a bit
<fwereade_> gsamfira, do you have an ETA?
<gsamfira> fwereade_: understood. There are some issues that are giving us a bit of a headache. For example, colon delimited files are not possible on windows
<gsamfira> so com.ubuntu.juju:series:foo
<fwereade_> gsamfira, tedious -- which files are those?
<gsamfira> cannot be written on windows
<fwereade_> gsamfira, where would they come up? simplestreams?
<gsamfira> for those files some normalization needs to happen (the juju-metadata plugin fails for the same reasons)
<gsamfira> yep
<gsamfira> simplestreams
<gsamfira> and a ton of tests rely on those
<gsamfira> let me ping bogdanteleaga to get the status of that
<fwereade_> gsamfira, I strongly recommend you talk to wallyworld about that
<fwereade_> gsamfira, gut feeling says there should be a simple way around that, and we shouldn't depend on those FS paths
<gsamfira> I think bogdan has been in touch with wallyworld
<fwereade_> gsamfira, ok, fantastic
<gsamfira> most likely after the Paris ODS, I'll be joining in to work on the tests.
<gsamfira> fwereade_: right now we are in crunch mode for the summit in openstack
<fwereade_> gsamfira, fantastic -- just bear in mind that it's hard to legitimately claim windows support while the unit tests are still far from green
<gsamfira> fwereade_: understood
<fwereade_> gsamfira, would it be worth syncing up with (say) mgz to get proto-CI in place for windows? that way at least we can catch regressions in tests that had been passing
<gsamfira> fwereade_: I would suggest we disable all tests that fail on windows ATM, and enable them as they get fixed
<gsamfira> fwereade_: so yes. it is worth doing :)
<fwereade_> gsamfira, mgz: ok, I'd be fine with a SkipWindows() func we jam into the failing tests, or something
<wallyworld_> gsamfira: fwereade_ : there's a bug nate is aware of to change the file paths to be windows compatible
<fwereade_> gsamfira, mgz: can I leave you guys to coordinate getting that done somehow?
<fwereade_> wallyworld_, so we're reading dirs with tools in that format?
<wallyworld_> fwereade_: thanks for helping with the relation stuff - i was not across those older bugs in previous versions
<fwereade_> wallyworld_, ok, good to know
<fwereade_> wallyworld_, yw :)
<wallyworld_> fwereade_: we're reading dirs with file names containing :
<wallyworld_> which is fine for linux
<fwereade_> wallyworld_, yeah
<fwereade_> wallyworld_, gsamfira: I guess I'm a bit surprised that the :s are problematic for a large proportion of the tests, though
<fwereade_> wallyworld_, I can understand how they'd mess up the metadata ones
<wallyworld_> fwereade_: so skimming the back scroll in #juju, their issues were caused by bugs in 1.16.5?
<fwereade_> wallyworld_, I *think* so, yeah
<fwereade_> wallyworld_, the units were coming up and believing they weren't in the relations they actually were
<wallyworld_> fwereade_: gsamfira: many tests set up fake metadata, writing files with :, hence they fail
<fwereade_> wallyworld_, which could happen pre 1.18.1, because we weren't recording what relations we'd joined locally until we saw a remote unit in them
<gsamfira> fwereade_, wallyworld_ : bogdanteleaga proposed a fix for the : files
<gsamfira> https://github.com/juju/juju/pull/908
<fwereade_> wallyworld_, oh ok -- can we get around that by not writing the metadata to the filesystem?
<fwereade_> wallyworld_, or just fixing the FS storage to map : paths to something else?
<fwereade_> wallyworld_, hell just urlencide all paths?
<wallyworld_> fwereade_: yes i think so, but there's a lot of tests to fix, and we need to change the file names anyway for the generate metadata plugin
<wallyworld_> fwereade_: we originally used : because that's what the simplestreams folks did onthe public web server
<gsamfira> fwereade_, wallyworld_  : https://github.com/juju/juju/pull/908 <-- I think this should do
<wallyworld_> easy enough just to change the : to -
<wallyworld_> gsamfira: ok, will look soon, gotta have dinner after coming hie from soccer
<wallyworld_> home
<gsamfira> wallyworld_: cool. If those 2 patches are fine, we can fix a large portion of the tests that try to write simplestreams files
<fwereade_> gsamfira, wallyworld_: that CL scares the life out of me tbh
<fwereade_> gsamfira, wallyworld_: way too many arbitrary-lookin changes in arbitrary-looking places
<fwereade_> gsamfira, wallyworld_: why wouldn't just encoding internal paths work?
<fwereade_> gsamfira, wallyworld_: the metadata fixes would be different but they feel like they really *are* different
<wallyworld_> or just notusing filenames with : in them
<fwereade_> gsamfira, wallyworld_: they're about parsing a particular FS structure
<wallyworld_> the metadata is fine on either os - it's the filenames that need changing unless i am missing something
<fwereade_> gsamfira, wallyworld_: why wouldn't we just make :s work in Storage paths?
<fwereade_> gsamfira, wallyworld_: the solution to a leaky abstraction is to fix the leak
<wallyworld_> fwereade_: the json files are written to disk
<fwereade_> gsamfira, wallyworld_: not to add duct tape in 10 other files
<wallyworld_> fwereade_: i've had no input to the CL, not seen it yet
<wallyworld_> nor
<fwereade_> wallyworld_, and? the Storage names can have :s just fine, we just need to encode them differently for the FS, surely?
<wallyworld_> sure, but why do that? the file names are totally arbitrary
<wallyworld_> just make file names compatible with all os's
<fwereade_> wallyworld_, yes
<fwereade_> wallyworld_, that shoudl be completely hidden behind the Storage interface
<wallyworld_> yep
<wallyworld_> but don't forget
<fwereade_> wallyworld_, not splattered across the codebase everywhere we *happen* to have noticed a problem today
<wallyworld_> we generate files on disk also
<wallyworld_> we just need to change *1* method
<fwereade_> wallyworld_, I understand that the metadata plugin is a separate issue
<gsamfira> aside from index.json, i *think* the rest can be named whatever we want. As long as we use the same path inside index.json
<fwereade_> gsamfira, that is true as well
<gsamfira> fwereade_: the metadata plugin uses the same filenames/constants. if we fix the metadata plugin, we fix most tests
<fwereade_> gsamfira, wallyworld_: but the proportion of tests in which we depend on FS simplestreams data (as opposed to Storage-based simplestreams data) should be minimalk
<wallyworld_> changing this const should work
<wallyworld_> ProductMetadataPath = "streams/v1/com.ubuntu.cloud:released:imagemetadata.json
<wallyworld_> fwereade_: agreed, i'm not sure of the current mix of tests which use storage vs fs metadata
<wallyworld_> but regardless, changing a const should fix everything
<fwereade_> sorry guys, my lunch is getting cold
<fwereade_> wallyworld_, it wil *not*
<fwereade_> wallyworld_, it will fix *one symptom* of the underlying problem
<fwereade_> wallyworld_, which is that our FS storage abstraction is leaky and fails on windows
<wallyworld_> ok, we can talk after your lunch
<fwereade_> wallyworld_, cheers :)
<gsamfira> wallyworld_, there is also this: https://github.com/juju/juju/blob/master/environs/tools/marshal.go#L21
<gsamfira> and the one immediately bellow that
<wallyworld_> gsamfira: yes, i knew that was there but didn;t find the method in time to type it in
<wallyworld_> there's a couple of places where we generate the filename
<gsamfira> wallyworld_: if we can create a constant with those names, that would be great
<gsamfira> bogdanteleaga: can you try changing the filenames and see if that works on both windows and linux ?
<wallyworld_> gsamfira: the content id doesn't need to change
<wallyworld_> just the file name
<bogdanteleaga> there's quite a lot of places where there are :'s, mostly are sptrintf'd
<bogdanteleaga> and we have some tests where they are hardcoded
<wallyworld_> it's only the file names isn't it?
<bogdanteleaga> but it's pretty doable
<bogdanteleaga> yes
<wallyworld_> the content ids should be fine
<gsamfira> content ids are fine, yes
<wallyworld_> so there should be a small number of places where filenames are generated, these just need to have the : replaced
<gsamfira> only paths inside index.json (and of course the names on disk) need to change
<bogdanteleaga> and what about files online?
<bogdanteleaga> there's no difference between the offline and offline paths, they're generated from the same string
<gsamfira> bogdanteleaga: those can be replaced. the index.json is the only one of consequence, and we don't touch that
<gsamfira> so the path to the file containing information about tools in in the index.json file
<wallyworld_> the online ones are url paths
<gsamfira> http://paste.ubuntu.com/8639101/
<wallyworld_> it's just windows fs that is broken :-(
<gsamfira> the "path" inside this file tells you where to find the tools information.
<gsamfira> wallyworld_: yeah...unfortunately...windows uses ":" for drive letters....
<wallyworld_> stupid windows, stupid drive letters
<gsamfira> wallyworld_: ....amen
<gsamfira> wallyworld_: its funny because windows also has UNC paths, which would be nicer to use in general...
<wallyworld_> yeah, go figure
<perrito666> morning
<TheMue> perrito666: morning
<perrito666> natefinch: https://github.com/juju/juju/pull/928 care to take a second look?
<jcw4> fwereade: question about timestamps in action docs
<jcw4> fwereade: creation time and completion time are straightforward
<jcw4> fwereade: capturing start time (i.e. when the action is picked up and started) is a little tricky.
<jcw4> fwereade: we chose to only write actionDoc once when enqueing it, and then writing a new actionResultDoc when done
<jcw4> fwereade: so that the watchers can be efficient about detecting new actions, and not fire when we *update* the actionDoc
<jcw4> fwereade: I'm just bringing this up 'cause you'd mentioned capturing start time, and I'm looking for your preference on how to capture that
<fwereade> jcw4, can we plausibly write the beginnings of the actionResultDoc when we start?
<jcw4> fwereade: that's the only thing that makes sense to me
<fwereade> jcw4, the big trouble is that we still don't seem to have proper handling for units that die halfway through an action
<fwereade> bodie_, was there any progress there?
<jcw4> fwereade: I think we'd have to rework how we write actionResultDoc though, since I think the code expects it only to be written once too, on completion.
<jcw4> it actually might be cleaner, if we begin actionResult right away and remove actionDoc as soon as it's picked up, but we'd have to decide what happens when units die halfway through.
<jcw4> at least this way it'd be clear from the actionResultDoc that a unit tried to start working on it
<fwereade> jcw4, yeah, I think that would be handy
<fwereade> jcw4, the uniter has responsibilities if it goes down mid-action
<fwereade> jcw4, but if it goes down forever, we should also have the state-server-side cleanup for a dead unit explicitly mark all those actions failed
<fwereade> jcw4, the uniter responsibilities are one of my major concerns, though
<fwereade> bodie_, ^^
<jcw4> fwereade: do we already have mechanisms in place for uniter cleanup ?
<jcw4> before the big hammer of state-server-side cleanup
<fwereade> jcw4, we're *meant* to
<fwereade> jcw4, everything the uniter does can pick itself up and recover if it's kill -9'd at any time
<fwereade> jcw4, *except* actions
<jcw4> ooh
<fwereade> jcw4, to be fair, it's pretty easy
<fwereade> jcw4, it just needs to detect and handle it in ModeContinue
<jcw4> fwereade: that's partially because we don't have a way right now to know that actions have been started... which an initial record of actionResult may help.
<fwereade> jcw4, I'm inclined to make it local, actually
<jcw4> hmm; interesting
<fwereade> jcw4, we do already record that fact locally
<jcw4> i see
<fwereade> jcw4, just got factored out into uniter/operation package
<jcw4> fwereade: I saw your emails about that refactor, but haven't looked at the diff
<jcw4> fwereade: I'll check it out too
<fwereade> jcw4, the reason we no longer run actions in error states is because the current implementation smashes op-error state
<fwereade> jcw4, this does need to be fixed :)
<jcw4> fwereade: the current implementation of action handling in uniter you mean?
<fwereade> jcw4, yeah, it's just writing out hook state
<fwereade> jcw4, which smashes pre-existing hook-pending state
<jcw4> fwereade: ah; I see.
<fwereade> jcw4, which is how the uniter can tell it was interrupted running one, and hence should be in error mode
<fwereade> jcw4, I did agree that it's not *top* priority -- "can't run actions in error state" is a bug, but it's not unreasonable in the first cut, while "running actions in error state messes everything up" is unreasonable at any time
<jcw4> fwereade: +1
<jcw4> fwereade: also; slight side topic:  I'm *really* uncomfortable embedding time.Now() in the bowels of any state code.. I'd want to inject the concept of current time somehow to make chronology more predictable, and more testable.
<fwereade> jcw4, that sounds good to me
<fwereade> jcw4, take a look at the metrics stuff
<fwereade> jcw4, I can't remember how they do that
<fwereade> jcw4, if it's good, do the same
<jcw4> fwereade: okay - I did see some code there
<fwereade> jcw4, if it's not, please fix both ;p
<fwereade> jcw4, and maybe sling thumper a mail? I suspect he is, or soon will be, doing something like that re user stuff
<jcw4> fwereade: what I saw there looked like 1/2 a solution of at least capturing current time in a function that could be monkey patched
<jcw4> It seems like a TimeProvider interface or something would be good
<fwereade> jcw4, +1 to that
<fwereade> axw, ping
<mattyw> dimitern, are you able to do a trivial review? http://reviews.vapour.ws/r/248/
<dimitern> mattyw, sure, looking
<jcw4> mgz, sinzui any idea why CI keeps failing on Does not match ['fixes-1384175'] ?
<jcw4> that bug doesn't show up in the critical bugs on lp
<jcw4> 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=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&field.importance%3Alist=CRITICAL&assignee_option=any&field.assignee=&field.bug_reporter=&field.bug_commenter=&field.subscriber=&field.structural_sub
<jcw4> or
<jcw4> https://api.launchpad.net/devel/juju-core?ws.op=searchTasks&status%3Alist=Triaged&status%3Alist=In+Progress&importance%3Alist=Critical&tags%3Alist=regression&tags%3Alist=ci&tags_combinator=All
<jcw4> mgz, sinzui bug 1384175 shows as fixed in LP
<mup> Bug #1384175: Utopic test failures due to addition of vivid series <ci> <regression> <test-failure> <vivid> <juju-core:Fix Committed by thumper> <juju-core 1.20:Triaged by anastasia-macmood> <https://launchpad.net/bugs/1384175>
<mgz> jcw4: it's only fix committed atm
<mgz> it requires fix released
<mgz> which I will mark now, as the utopic unit tests are blue
<mgz> jcw4: go wild
<jcw4> mgz: I see; I need to update my bookmark for checking blockers :)
<jcw4> woo hoo
<sinzui> mgz, jcw4 : We are finishing of the test run and we can see the test will be declared a pass. I will mark the bug as fix released
<jcw4> sinzui: ta (mgz beat you to marking the bug as fix released though)
* ChanServ changed the topic of #juju-dev to: https://juju.ubuntu.com | On-call reviewer: see calendar | Open critical bugs: None
<sinzui> natefinch, is anyone working on a backport of the vivid and ppc64el test fixes to 1.20?
<natefinch> sinzui: yeah, me or someone to whom I delegate
 * perrito666 ducks
<sinzui> natefinch, :) I never assume it is you when I ask, I just hope you know the answer
<natefinch> sinzui: probably a good assumption ;)
<ericsnow> natefinch, perrito666: standup?
<perrito666> ericsnow: natefinch just moved it
<perrito666> you should have a new invite
<natefinch> ericsnow: sorry... there's a tosca meeting today that always conflicts, I should have moved today's meeting like 2 months ago
<gsamfira> fwereade, bodganteleaga: so there are essentially 2 major aspects that need to get fixed to have all tests that require to generate/upload tools to work (and also fix the metadata plugin). First one is the obvious problem of having colons in filenames written to disk. The other is the file:// handler the http module uses to fetch local files.
<ericsnow> natefinch: forgot to refresh my calendar
<gsamfira> fwereade, bodganteleaga: changing the filename that gets written to disk should not impact functionality. We can do this for bith windows and linux. What is a bit wonky is the file:// handler
<fwereade> gsamfira, ah, so file:// urls won't work right on windows?
<natefinch> file:// works fine on windows actually
<gsamfira> they do work, but not the way juju uses them
<natefinch> heh
<fwereade> gsamfira, I'd be entirely happy to have FileStorage run an http server and just happen to use an FS backend
<gsamfira> fwereade: on linux we register '/' as the root for file://
<fwereade> gsamfira, I think we already have an HTTPStorage like that anyway?
<natefinch> fwereade: do we really want to change the whole way filestorage works just to avoid using colons?  I think getting this done sooner rather than later is more important than making it perfect.
<gsamfira> for that bit, it would be ok to use a small http server for tests only
<gsamfira> BUT, there comes the need to generate simpolestreams files using the client
<gsamfira> fwereade: for example, the juju-metadata plugin
<fwereade> gsamfira, sure, understood
<gsamfira> that plugin uses file:// iirc
<fwereade> gsamfira, my position there is that we have a *huge* number of tests not passing thanks to FileStorage
<fwereade> gsamfira, which equates to a huge proportion of juju not working, or at best working by coincidence
<gsamfira> huge is right :)
<fwereade> gsamfira, so fixing filestorage is the important thing
<fwereade> gsamfira, because we believe that's just a test problem
<gsamfira> fwereade  : *local* file storage
<fwereade> gsamfira, metadata doesn't work anyway
<fwereade> gsamfira, and IMO it strictly comes behind fixing the tests that we believe are spurious failures
<fwereade> gsamfira, certainty on the bits that do work comes first
<gsamfira> fwereade: there is another option. The way file:// is mapped now, assumes that we have a root folder. On linux using "/" is fine, because any volume is mounted under that. On windows we have drive letters (unfortunately). So A possible solution would be to implement a version of http.NewFilesystemHandler() that does not chroot all requests inside a folder
<gsamfira> and simply does a os.Stat()
<gsamfira> if the file is local, just serve it
<gsamfira> instead of doing filepath.Join(rootDir, filename)
<gsamfira> and then serving it
<gsamfira> then we would be able to have file://C:/my awesome/file
<katco> can i get a quick lgtm on a 2-line change? http://reviews.vapour.ws/r/236/diff/#
<gsamfira> kind of the same way every other browser on the planed does it
<gsamfira> :)
<fwereade> gsamfira, bogdanteleaga: do we need the full path there anyway? since we register the handler anyway, can we not just have file:// defined as relative to rootDir?
<gsamfira> we can, but then we need to strip the drive letteer every time. Juju generates full paths most times
<gsamfira> so juju will most times pass: "C:/path/to/file"
<gsamfira> fwereade: so paths would become file://C:/path/to/file
<fwereade> gsamfira, why would we need to strip the drive letter other than inside FileStorage?
<gsamfira> if we chroot NewFilesystemHandler to C:/
<gsamfira> and pass in C:/path
<gsamfira> file would look for C:/C:/path
<fwereade> gsamfira, why would we be passing in C:/anything?
<gsamfira> fwereade: because that's how juju generates all paths :)
<fwereade> gsamfira, all I care about is that URL() returns something that's a valid url, that we can write a handler for that goes back to the right place
<fwereade> gsamfira, er, what?
<fwereade> gsamfira, the Storage interface has complete control
<fwereade> gsamfira, the fullPath thing looks like the problem here
<fwereade> gsamfira, that's how FileStorage works now
<fwereade> gsamfira, but it evidently doesn't work right on windows
<fwereade> gsamfira, so lng as we end up with (1) FileStorage working on windows and (2) none of the client code having to dick around with windows-isms to use FileStorage, I'm happy
<gsamfira> cool
<fwereade> gsamfira, in fact, (2) beats out (1)
<fwereade> gsamfira, if we can't eliminate the windows-isms, I'd be perfectly happyto see HTTPStorage used instead
<fwereade> gsamfira, tedious that it'd need cleanup
<fwereade> gsamfira, but really, whatever minimal-friction Storage interface we can get is what we need
<gsamfira> fwereade: so then what needs to happen now is: 1) have fullPath return a correct path on windows 2) chroot in C:/ on windows (for now) 3) filenames need to contain valid characters on both OS
<fwereade> gsamfira, I think I'm suggesting that we should drop the notion of fullPath entirely
<bogdanteleaga> fwereade: are you talking about the URL functions in environs on (2)?
<fwereade> gsamfira, register the stupidTestFile:// handler if we have to
<fwereade> gsamfira, nobody should be using file:// urls in anything other than a test context anyway afaics
<fwereade> gsamfira, except for wget in that special cloudinit case, which I don';t think is underconsideration here
<fwereade> gsamfira, is it?
<gsamfira> nope
<katco> jam: hey i see you're ocr, do you have time to give a quick look at a 2-line change? http://reviews.vapour.ws/r/236/diff/#
<fwereade> katco, not 100% sure about that -- I think we want to prioritise speed in the local provider, and for thumper to finish his local provider plugin that will give us better handling of image updates
<fwereade> katco, am I misunderstanding?
<katco> fwereade: i am definitely getting mixed messages on this
<katco> fwereade: originally that was what we were going for
<sinzui> natefinch, https://bugs.launchpad.net/juju-core/+bug/1370149
<mup> Bug #1370149: No defined 'state-servers' on environment file after bootstrap, works after run 'juju status' <bootstrap> <cloud-installer> <cts-cloud-review> <juju-core:Triaged> <https://launchpad.net/bugs/1370149>
<katco> fwereade: but wallyworld_ asked me to make this change, and i think there are a few others who would like to see this behavior
<fwereade> katco, dammit
<fwereade> katco, do you know where the requirement came from upstream of wallyworld_?
<katco> fwereade: it can sit there a bit longer until there's some consensus. i'm only trying to finish it on wallyworld_'s behest before the eow
<katco> fwereade: let me do some digging rq
<fwereade> katco, cool, thanks
<fwereade> katco, the code looks fine fwiw
<wwitzel3> fwereade: ping, and I good to start on the juju-run side of things?
<wwitzel3> s/and/am
<fwereade> wwitzel3, I've been hoping for a review of http://reviews.vapour.ws/r/234/
<fwereade> wwitzel3, if I can hassle you for a review of that, and maybe 1 followup, you should be good to go
<fwereade> wwitzel3, they're both a lot simpler than they look, they're really just moves...
<voidspace> TheMue: so you point out in your review that the test doesn't use the constant for "none"
<voidspace> TheMue: this is because the constant is not available in the test namespace
<voidspace> TheMue: but it isn't a potential source of error
<voidspace> TheMue: if the string literal is wrong then the test will fail
<voidspace> TheMue: the same applies for the "default-vpc"
<voidspace> TheMue: so I don't think there's much value in defining constants just for those test uses
<voidspace> TheMue: as they provide no actual value
<voidspace> (s/namespace/package/)
<TheMue> voidspace: ok, can live with it. only always get a bit scary of typos when seeing repeating strings
<voidspace> TheMue: I understand
<voidspace> TheMue: but for a single use string literal (the test "none") the const is just as likely to have the typo... and it's now non-locally to the test
<voidspace> TheMue: so you're even less likely to see it!
<voidspace> TheMue: more importantly though, for these literals, a typo will cause an actual failure
<voidspace> so I don't think there's a danger in *these* cases
<TheMue> voidspace: yep, in your case it's ok.
<voidspace> TheMue: thanks, can I have a "ShipIt"?
<TheMue> voidspace: didn't I already gave you one?
 * TheMue -> looking
<voidspace> TheMue: I didn't think so
<voidspace> I may just have not seen it :-)
<TheMue> voidspace: it has been a fix it, then ship it. now it's only a ship it. :)
<voidspace> Haha, ok thanks
 * fwereade has frightened wwitzel3 away :(
<voidspace> that's an achievement
<voidspace> he's pretty hard to frighten
<fwereade> ok, cath will be justifiably upset with me if I don't go and see the blue lagoon before the sun sets
<fwereade> I hope I will make it back on tonight
<fwereade> but then I meant to do that yesterday, and ended up sleeping 12 hours or something
<voidspace> fwereade: o/ night
<voidspace> fwereade: enjoy the lagoon :-)
<fwereade> voidspace, cheers
<voidspace> PANIC: machine_test.go:70: MachineSuite.TestSetRebootFlagDeadMachineRace
<fwereade> natefinch, I appoint you answerer of questions while I'm out ;p
<voidspace> ... value *errors.Err = &errors.Err{message:"", cause:(*net.OpError)(0xc210362380), previous:(*errors.Err)(0xc21041f690), file:"github.com/juju/juju/state/open.go", line:68} ("cannot create log collection: local error: bad record MAC: local error: bad record MAC")
<voidspace> ^^^ familiar anyone?
<natefinch> voidspace: wacky...
<voidspace> natefinch: that was a buildbot failure for my merge
<voidspace> didn't fail locally
<voidspace> will retry
<natefinch> voidspace: that's a tls error... almost certainly not a code problem
<perrito666> voidspace: saw it then when I tried to reproduce it it was gone
<voidspace> natefinch: perrito666: thanks
<mgz> gsamfira: do you have a mo, I'm trying to understand some kardianos/service dep weirdness
<gsamfira> mgz: sure. I will gladly help if I can
<natefinch> mgz: doh, is it causing a problem?  I just changed the deps yesterday so godeps -t ./... would produce the right output
<mgz> natefinch: maybe? I didn't see your change *doing* anything to the windows deps though
<mgz> it just seems like kardianos/service/service_windows.go needs code.google.com/p/winsvc - which we don't have as a dep
<mgz> but this *did* build before, and I can't see what has changed
<mgz> gsamfira: so, do we need to build that file, and is it actually a dep?
<gsamfira> mgz: the kardianos/service is actually a wrapper for winsvc (on windows)
<gsamfira> so yeah
<natefinch> weird that godeps isn't picking that up
<natefinch> ahh... I see, it's only included in an _windows.go file
<natefinch> I'm surprised it built before if we weren't including that package.  Do we build the windows code differently?
<mgz> natefinch: not deliberately, but perhaps
<mgz> so, I'll just file a bug, and we add the dep now I guess
<natefinch> yeah
 * natefinch grumbles about not using go get
<mgz> it does, but we try and make our tarball make sense, mostly for ubuntu's benefit (they have to document all the licences of all the deps and such like)
<mgz> so, this is a bit of an edge case in that they don't really need to care about windows-only dependencies, but life is still somewhat easier if we actually know what our code needs to build
<jamespage> dimitern, hey - just noticed that juju 1.21 started accessing the bootstrap node via its IPv6 address ;-)
<dimitern> jamespage, hey, yeah - esp. if you set prefer-ipv6: true in env.yaml :)
<jamespage> dimitern, ooooooo
<dimitern> but apart from that, prefer-ipv6 does not do much
<dimitern> (yet)
<mgz> gsamfira: filed bug 1384818
<mup> Bug #1384818: Windows service dependency missing <windows> <juju-core:Triaged> <https://launchpad.net/bugs/1384818>
<mgz> we probably also want to change the 1.20 branch
<sinzui> natefinch, mgz, do either of you have a minute to review https://github.com/juju/juju/pull/955
<natefinch> sinzui: LGTMd
<sinzui> thank you natefinch
<voidspace> g'night all
<natefinch> this is why I never write bash scripts.... because stuff that looks like it should absolutely work, just doesn't
<natefinch> wtf is wrong with this: #!/bin/bash
<natefinch> export GOPATH=$HOME
<natefinch> go get gopkg.in/yaml.v1
<natefinch> ^^^ says GOPATH is not set
<natefinch> how is that possible?
<perrito666> natefinch: its most likely your fault :p
<perrito666> natefinch: pastebin the whole thing
<natefinch> http://pastebin.ubuntu.com/8644139/
<natefinch> it's an install hook where I tried to do the "right thing" by using go run.  But seriously... this is why I never write bash scripts
<perrito666> natefinch: I noticed
<perrito666> natefinch: you can ditch the export
<natefinch> ok
<natefinch> is that what's screwing me?
<perrito666> nope
<natefinch> lol
<perrito666> although you are assuming that $HOME actually has something
<perrito666> since its bash you can safely use ~
<natefinch> yeah, I thought of that
<perrito666> mm, re thinking keep the export I am not sure what go get does inside
<thumper> morning folks
<perrito666> morning t
<perrito666> meh, too many t people
<TheMue> thumper: morning
<thumper> hmm...
<thumper> both the on call reviewers for Friday still think it is Thursday
<thumper> :-(
<thumper> that wasn't well planned
<perrito666> thumper: well I also think there is some thursdayness in the day
<perrito666> the fun part is that both thursday reviewers think its friay
<perrito666> friday*
<thumper> anyone? http://reviews.vapour.ws/r/254/diff/
<ashipika> http://reviews.vapour.ws/r/247/
<perrito666> thumper: done
<thumper> perrito666: ta
<menn0> thumper: I've just responded to your review comments for 175
<menn0> thumper: one thing though, can you explain why it's preferable to use a non-LTS series for machines in tests?
<thumper> menn0: histerical raisins
<thumper> I'm sure there was a rational reason at some stage
<thumper> but I don't recall what it was
<menn0> thumper: ok np
<menn0> thumper: gah! I've just noticed that envUserDoc uses "envuuid" instead of "env-uuid"
<thumper> :-(
<menn0> thumper: we've been using env-uuid for the migrated collections
<thumper> which is good
<menn0> thumper: should we fix now while it's new?
<thumper> I think the dashes make it more readable
<menn0> thumper: I noticed because I was thinking about machineid vs machine-id
<menn0> thumper: I think we should settle on machine-id and make the pre-existing fields consistent
<thumper> +1
<menn0> thumper: what about envUserDoc? that's just been released hasn't it?
<thumper> we should migrate it, not just assume
<menn0> thumper: ok
<menn0> thumper: I'll do that as a separate branch
<menn0> thumper: onyx standup hangout?
<thumper> sure, there in 2 m
<wallyworld_> thumper: hey
<thumper> o/
<wallyworld_> a question when you were offline
<wallyworld_> <fwereade_> does anyone know why we use an abstract socket for the jujuc server, but a filepath socket for the juju-run listener?
<wallyworld_> answer?
<thumper> if there was a reason, I don't recall it now
<wallyworld_> ok :-)
<thumper> I do think there may have been a reason
<thumper> actually I think I do know
<wallyworld_> next time you "see" william, maybe touch base with him about it
<thumper> jujuc used to use a filepath one too
<thumper> perhpas this was changed for the windows work
<wallyworld_> ah ok
<thumper> without them realisign about the juju-run one
<wallyworld_> makes sense
<thumper> menn0: have you updated the rb diff with the latest stuff?
<thumper> menn0: although I have noticed that when you push to github, it gets the diff updated
<thumper> menn0: I'm still seeing "machineid" and I thought you were changing
<menn0> thumper: nope. just finishing off the bit to move the upgrade steps to 1.21alpha3
<thumper> ok...
<thumper> I'll go to exercise before reviewing then
<thumper> wallyworld_: can we chat this afternoon about the local charmstore integration?
<menn0> thumper: the tests in the upgrades package were lacking so I'm fixing them too
<menn0> thumper: give me 10 mins
<thumper> np
<thumper> menn0: take an hour :)
<menn0> thumper: I have to take my son swimming soon so it'll be much less than that
<menn0> thumper: done
<wallyworld_> thumper: sure, just ping when you want to talk
#juju-dev 2014-10-24
<wallyworld_> sinzui: i'll have code using the new stream based tarball directories ready today - are you able upload tarballs to "juju/tools/released" so that sync-tools will work? no urgency, just letting you know
<sinzui> wallyworld_, I cannot upload anything to Jerff
<sinzui> wallyworld_, I control a script that can get assets from Lp
<sinzui> We have limited powers, but we will be changing this because Lp wont be providing win-agents that we make. We need a new delivery mechanism to Jerff or a better pickup mechanism
<wallyworld_> ok, no worries. i can still commit the code - it will still find tools using the existing index files; i doubt people will care if sync-tools on trunk is broken for a few days
<sinzui> wallyworld_, I misunderstood. we can NEVER replace an agent. We can remove if it is malign. That is why I keep hammer the point about controlling the archives. Alarms will sound and trees will be reverted if a checksum ever changes.
<sinzui> wallyworld_, Until juju agent version can state their origin or build or packaging version, we will never be able to fix an agent
<wallyworld_> true. that's somewhat orthogonal to the current changes though isn't it?
<sinzui> wallyworld_, it is. sync-tools cannot be fixed by steal, we require a release
<sinzui> stealth
<sinzui> nor ca we fix a broken ppc64el witha  rebuild
<wallyworld_> sure. it's just that now sync-tools needs to be taught that it needs to look in a different place to find the tarballs
<wallyworld_> it currently looks in a "releases" dir
<wallyworld_> it needs to look in a dir named after the stream
<sinzui> right
<wallyworld_> that's the change i'm making and which means sync-tools will be broken until tarballs are placed in "released" on streams.canonical.com
<wallyworld_> everything else about the changes i'm doing doesn
<wallyworld_> 't affect any thing
<wallyworld_> since it's just teaching generate-tools to write the correct metadata
<thumper> wallyworld_: around?
<wallyworld_> thumper: hiya, just finished standup
<thumper> wallyworld_: hangout chat?
<wallyworld_> sure, use our 1:1
<thumper> kk
<niedbalski> wallyworld_, could you check https://github.com/juju/juju/pull/689? I think is not a definitive fix but at least address a potential issue (http://osdir.com/ml/general/2014-06/msg03723.html)
<menn0> thumper: I'm having second thoughts about the machine-id vs machineid thing
<menn0> thumper: there's lots of places where machineid is already in use
<thumper> like where?
<menn0> networkinterfaces
<thumper> ugh
<menn0> unit
<thumper> ok, I'll suffer though with machineid
<menn0> :)
<wallyworld_> niedbalski: looking now, sorry just finished meeting
<menn0> thumper: the machines env uuid branch has merged \o/
<thumper> w00t
 * thumper calls it an early day
<thumper> lots of extra hours Wed and Thu
<thumper> have a good weekend everyone
<thumper> it is a long weekend here in NZ, so see folks on Tuesday
<thumper> davecheney: no standup monday
<thumper> davecheney: or 1:1 as it is Labour day here
 * thumper goes to delete items from the calendar
<davecheney> thumper: ack
<davecheney> no problem
<davecheney> nothing really to report anyhow
<davecheney> enjoy your 8 hour work day celebration
<thumper> \o/
<menn0> davecheney: howdy. I wanted to chat to you about the state / apiserver dependency unpicking you're working on. hangout?
<davecheney> menn0: sure
<menn0> davecheney: standup hangout?
<davecheney> kk
<menn0> davecheney: i'm there now
<davecheney> https://lists.ubuntu.com/archives/juju/2014-October/004434.html
<mattyw> morning everyone
<TheMue> axw: done
<TheMue> mattyw: morning
<mattyw> TheMue, good morning
<axw> TheMue: thanks
<TheMue> axw: yw
<dimitern> morning all
<fwereade> so, it turns out small boats can be quite stressful in 50 km/h winds
<fwereade> dimitern, hey dude
<Spads> swallows and amazons forever
<TheMue> dimitern: morning
<dimitern> fwereade, TheMue, hey guys
<voidspace> dimitern: morning
<voidspace> TheMue: morning
<voidspace> fwereade: yow, you made it back safely though...
<fwereade> voidspace, yeah, it was really a very short crossing
<fwereade> voidspace, still a bit much tbh
<voidspace> fwereade: are you away from home - or just taking perilous sea crossings in Malta?
<dimitern> morning voidspace
<fwereade> voidspace, it's laura's half term, we had a couple of days on comino
<fwereade> voidspace, tiny island between malta and gozo
<voidspace> fwereade: ah, but you've been working from there?
<voidspace> At least you've been online...
<fwereade> voidspace, yeah
<dimitern> we had a great 14.10 release lunch yesterday, worthy of the 10y anniversary :)
<fwereade> voidspace, nice to have a change of scene
<fwereade> dimitern, nice :D
<voidspace> fwereade: heh, cool - although you should have taken a proper break :-)
<fwereade> voidspace, ehh, I've actualy been programming this week
<voidspace> fwereade: looking it up on wikipedia, looks lovely
<fwereade> voidspace, it's tremendously enjoyable and healing and all that :)
<voidspace> fwereade: :-)
<voidspace> dimitern: USEast region is now reporting a default vpc
<voidspace> dimitern: did we request the change?
<voidspace> anyway, it's good - makes testing this code less of a pain
<dimitern> voidspace, which account is this?
<voidspace> dimitern: "our" account
<dimitern> voidspace, ah :) ok, I'm using my own actually
<voidspace> ah
<dimitern> voidspace, but it's good nonetheless
<dimitern> voidspace, I probably should try to use "ours" as well :)
<voidspace> yeah, although I was using APSoutheast2 before USEast is easier to type ;-)
<voidspace> dimitern: yeah, saves making expense claims
<voidspace> dimitern: balls, I was running the wrong file
<voidspace> dimitern: the default-vpc is still for APSoutheast2
<dimitern> voidspace, ah, I've done that yeah
<fwereade> wallyworld_, if you're around, do you have an opinion on https://github.com/juju/juju/pull/908/files ?
<wallyworld_> looking
<fwereade> wallyworld_, I still don't think I'm happy -- strikes me as a scattergun fix-windows-paths-here-and-there approach
<fwereade> wallyworld_, but much of it is simplestreams related, so maybe you can set my mind at rest?
<wallyworld_> fwereade: sure, give me a few minutes and i'll look
<fwereade> wallyworld_, cheers
<fwereade> wallyworld_, at your leisure
<wallyworld_> fwereade: so there are 2 issues. 1. the folks who created the simplestreams metadata files on streams.canonical.com chose to use ":" in the file names. juju provides a mechanism to generate metadata  files (used to upload or import metadata) and also uses ":", 2. simplestreams  uses file:// and http:// urls. the file:// urls are easy to create in linux but harder in windows due to drive letters. to solve issue #1, it is essentially a
<wallyworld_>  change to the filename generation; the file name is arbitrary so use "-" instead of ":", doesn't matter. for issue #2, the various places where file:// urls are generated need to account for windows. most of the places are in tests. regardless, we should be deferring any windows conversion to the system boundaries, at the places where the urls are actually used. and this is only one place i think, in the actual Fetch()  method
<fwereade> wallyworld_, so I'm a bit concerned about having a Storage implementation that (1) doesn't allow : in paths and (2) doesn't produce sane urls
<wallyworld_> fwereade: blame windows
<wallyworld_> it's windows that doesn't allow ":" in urls
<wallyworld_> un paths
<wallyworld_> in
<wallyworld_> we only write out simplestreams metadata in one place
<wallyworld_> in the generation utility
<fwereade> wallyworld_, so ISTM that it's simply that FileStorage is (1) failing to properly encode paths such that they can be stored on windows and (2) failing to generate urls that can be used on windows
<wallyworld_> we read simplestream metadata off disk in only one place - at bootstrap when the user can supply their own (and also in tests)
<fwereade> wallyworld_, IMO simplestreams issues are completely secondary
<fwereade> wallyworld_, we can make a point of generating simplestreams dirs that don't have :s in
<fwereade> wallyworld_, but this is completely separate from the fact that FileStorage doesn't work on windows
<fwereade> wallyworld_, and we need FileStorage to be able to be a Storage, so we can use it as a reasonablereplacement for the real simplestreams sources
<fwereade> wallyworld_, but for now there are plenty of simplestreams sources that do include :s
<wallyworld_> fwereade: yes, that's what i was referring to when i talked about doing the conversion at system boundaries
<fwereade> wallyworld_, yeah
<wallyworld_> fwereade: the sources that include ":" don't matter
<wallyworld_> these are urls
<wallyworld_> they are fine
<fwereade> wallyworld_, yeah, exactly
<fwereade> wallyworld_, the problem is the FileStorage is shite on windows
<wallyworld_> it is *only* the generation utility
<fwereade> wallyworld_, and we need to fix that
<wallyworld_> and the tests
<fwereade> wallyworld_, and then *separately* we can fix the metadata plugin
<wallyworld_> there are lots of tests that write out simplestreams files
<wallyworld_> and then substitute a file:// url for the real http:// url
<fwereade> wallyworld_, but what we're seeing right now is a broken test framework, because FileStorage doesn't work on win
<wallyworld_> yes
<fwereade> wallyworld_, so IMO the only reasonable thing to do is to fix the test framework
<wallyworld_> i'd look to file the FileStorage abstraction
<fwereade> wallyworld_, ok, cool, I think we are aligned here
<wallyworld_> so that we deal with ":" etc internally
<wallyworld_> fwAH HANG ON A SEC
<wallyworld_> sorry capslock fail
<wallyworld_> fwereade: the issue is, that we use http.Get()
<wallyworld_> and file:// urls
<wallyworld_> so there's no real file storage abstraction as such. it is an abstraction based on getting froma url
<wallyworld_> trouble is, on windows, the file:// urls are broken
<wallyworld_> and so http.Get fails
<wallyworld_> so we would want to use a helper for the url getter
<wallyworld_> that converts the file:// urls on windows
<wallyworld_> the uniform use of http.Get makes the fetching of file content agnostic to file and http urls
<fwereade> wallyworld_, if FileStorage can't generate URLs that work, it needs to start doing so
<fwereade> wallyworld_, if that means running an http server, it should do that
<fwereade> wallyworld_, and then we can drop the foul file://-handler haclk entirely
<fwereade> wallyworld_, AIUI, it's only agnostic because we register a handler for file:// urls
<fwereade> wallyworld_, so, yeah, hacking up the file:// handler in windows would be another way to do it
<fwereade> wallyworld_, but AFAICS it's still all down to FileStorage
<fwereade> wallyworld_, it doesn't Put properly
<fwereade> wallyworld_, and it doesn't URL properly
<fwereade> wallyworld_, and so it's not a Storage
<fwereade> wallyworld_, and so it needs to be fixed
<wallyworld_> the Fetch mechanism uses http.Get, that's why file:// urls were introduced, so the simplestream.Fetch() could deal with a url based abstraction
<wallyworld_> file:// is a valid url schema
<wallyworld_> but yeah, what follows differs on wndows vs linux
<fwereade> wallyworld_, sure -- but if we're not capable of generating file:// urls that work, we can't reasonably use them, can we?
<wallyworld_> we can use a helper - MakeFileURL(path)
<wallyworld_> different implementaion on windows vs linux
<fwereade> wallyworld_, that's fine by me, because it stays inside FileStorage
<wallyworld_> instead of "file://" + path
<wallyworld_> which is used now
<fwereade> wallyworld_, what I care about is that FileStorage keeps working like an actual Storage
<fwereade> wallyworld_, although
<fwereade> wallyworld_, honestly
<fwereade> wallyworld_, simplestreams and Storage have an impedance mismatch *anyway*
<wallyworld_> the file storage part in tests is file, so long as the file names use "-"
<fwereade> wallyworld_, there's no guarantee that Storage.URL() results have any relationship to the underlyingpaths
<fwereade> wallyworld_, URLs that are just opaque hashes are perfectly valid
<wallyworld_> well, for disk based Storage() implementtions the URls do have that correspondence
<fwereade> wallyworld_, right, but that's not part of the Storage interface
<fwereade> wallyworld_, it's an invalid assumption made by the simplestreams machinery
<wallyworld_> sure, but i don't think we use Storage() for simplestreams
<fwereade> wallyworld_, hmm, I thought the two were more than a little entangled
<fwereade> wallyworld_, if we don't, why is that CL hitting both storage code and simplestreams code?
<wallyworld_> we use a simplestreams.DataSource abstraction
<fwereade> gsamfira, conversation relevant to your interests for about the last 50 mins ^^
<wallyworld_> and there are file based and http based  implementations
<wallyworld_> fwereade: so, in effect, the comments still apply - what what we do internally, and convert the urls are the system boundaries
<fwereade> wallyworld_, which I would say doesn't fit with Storage, but was welded on for convenience's sake, for understandable and defensible but ultimately unhelpful reasons
<wallyworld_> fwereade: simplestreams doesn't use storage
<wallyworld_> it uses a different abstraction
<wallyworld_> 99% of it is about streaming data from a url
<wallyworld_> the other 1% is a utility which can write data
<fwereade> wallyworld_, that's frequently backed by Storage-based urls
<wallyworld_> no, mostly by htto urls
<wallyworld_> only storage based for tests
<fwereade> wallyworld_, that don't necessarily have the properties required by simplestreams
<fwereade> wallyworld_, well, when did that change? because for a long time we *were* uploading ss data to Storages, and depending on the properties of the URLs returned by storage
<fwereade> wallyworld_, my understanding was that we were getting closer to breaking the link, but had not yet done so
<fwereade> wallyworld_, I haven't seen the state-based catalogues of tools and images...
<wallyworld_> all we need to do is fix storageSimpleStreamsDataSource
<wallyworld_> they are there
<wallyworld_> tools are no longer store in the cloud storage
<wallyworld_> tools and image metadata go into catalogs in state
<wallyworld_> the other thing is that the simplestreams.DataSource interface is read only
<wallyworld_> it streams data from urls
<wallyworld_> but for tests, and the generation utility, we need to write data
<wallyworld_> write data to a location on disk that the DataSource can read back
<wallyworld_> the simlplestreams.Datasource interface uses urls
<fwereade> wallyworld_, ok, I see, the apiserver/common.Tools stuff is just falling back to simplestreams sometimes?
<wallyworld_> fwereade: it does if the tools don't exist in the sate database
<wallyworld_> from memory
<fwereade> wallyworld_, in that case... shoudl we not be using state-based tool/image catalogues across the board in the tests?
<fwereade> wallyworld_, this'll leave some bootstrap tests broken, I imagine
<fwereade> wallyworld_, and ofc the metadata plugin ones
<wallyworld_> yes, we should i guess. there are lots of tests to fix
<fwereade> wallyworld_, but they feel like they're real problems that should require code changes
<wallyworld_> we still need to read and write metadata to/from disk
<wallyworld_> for the generate plugin and bootstrap
<fwereade> wallyworld_, understood
<wallyworld_> bootstrap - read files off disk, store in state server
<wallyworld_> (if --metadata-source is specified)
<fwereade> wallyworld_, but what I am fulminating over is that this Storage-based hackery is being proposed as a way to get all the other tests passing
<wallyworld_> generate - read files off disk, see what's there, merge new metadata, write back out
<fwereade> wallyworld_, when it's not actually fixing anything
<fwereade> wallyworld_, it's just torturing the test framework to the point where, yes, the tests kinda pass, but there's basically no connection between reality and the test fixture
<wallyworld_> in 1.21 yes, in 1.20 no
<fwereade> wallyworld_, well, 1.21 is what we're currently working on...
<wallyworld_> yes, agreed
<wallyworld_> if we didn't want to fix all the tests in one go, we should be able to tweak the urls in the storage data source before they are used i think
<wallyworld_> and generate filenames with "-", not ":"
<wallyworld_> the last bit is trivial
<fwereade> wallyworld_, is it even about fixing all the tests in one go, though?
<fwereade> wallyworld_, can this not be done piecemeal?
<wallyworld_> um, don't think so, could be wrong. there are a lot of tests though that fail on windows aren't there?
<fwereade> wallyworld_, AIUI, yes, there are loads
<fwereade> wallyworld_, and many of them are failing because FileStorage doesn't work on windows
<wallyworld_> yes, so we tweak the helper method which writes the files
<wallyworld_> to fix the storage path on windows
<fwereade> wallyworld_, but any that aren't bootstrapping, or aren't using the metadata plugin, shouldn't need it anyway, because we now have tool/image catalogues in state anyway
<wallyworld_> yes, but there are still tests that exercise the simplestreams fetch/filer code
<wallyworld_> using file based metadata
<fwereade> wallyworld_, understood -- but aren;t they going to be an absoluteminority?
<wallyworld_> we still need those tests
<fwereade> wallyworld_, sure
<fwereade> wallyworld_, and they're exercising functionality that is currently broken
<fwereade> wallyworld_, I'm saying that it is moreimportant that we get the tests for working functionality to themselves start working
<wallyworld_> there are several of them. and bootstrap tests also need the url based data sources
<wallyworld_> and there are lots of those
<wallyworld_> so there are 3 types of test 1. simplestreams infrastructre, 2. bootstrap, 3. general juju
<wallyworld_> the first 2 still need al lthe crap we have now
<fwereade> wallyworld_, gsamfira: my understanding is that less than 50% of the test suite is passing on windows -- I don't believe that 50% of the test suite needs to depend on bootstrapping or simplestreams
<wallyworld_> agree (waves arms in air)
<fwereade> wallyworld_, gsamfira: I want to get the bits that don't depend on those two peiecs working reliably
<wallyworld_> 50% seems way low
<wallyworld_> i thought it was only several
<wallyworld_> maybe a package or two plus some other misc tests
<fwereade> wallyworld_: gsamfira should be able to confirm, but I thought that was what he said the other day
<fwereade> wallyworld_, I hadn't realised it was that bad myself
<wallyworld_> doesn't seem right
<fwereade> wallyworld_, this is a large part of why I am freaking out somewhat indiscriminately
<wallyworld_> i am surprised myself
<wallyworld_> i honesty thought a MakeFileURL() or similar at the system boundary would work
<fwereade> wallyworld_, correct me if I'm wrong
<fwereade> wallyworld_, actually, no, this is just a pure question
<fwereade> wallyworld_, in simplestreams, when adding a compenent to a path, does it always pass through the underlying storage's URL() method again?
<fwereade> wallyworld_, if it doesn't, I don't think there's any expectation that it will work
<wallyworld_> fwereade: not sure ottomh. i know we use path.Join() to glue together the bits
<fwereade> wallyworld_, because relative paths in storage are not guaranteed to map to relative storage urls in the first place
<wallyworld_> there's always a base url
<wallyworld_> and simplstreams works off relatives paths under that
<fwereade> wallyworld_, so if there's a path component including a : that gets tacked on
<fwereade> wallyworld_, that will *never* work as a file url on windows
<wallyworld_> yes
<fwereade> wallyworld_, whereas if the path had a : tacked on
<wallyworld_> that's the issue
<fwereade> wallyworld_, and that passed through the URL method
<fwereade> wallyworld_, we'd get a new URL that should work everywhere
<wallyworld_> but we don't need the ":"
<wallyworld_> and we also need to strip drive letters
<wallyworld_> but regardless, we can store internally what we want, and only when it is used, which is via the URL()_ method, do we convert it
<fwereade> wallyworld_, I am still deeply reluctant to use different filenames in the tests on windows, when we're writing code that needs to work against filenames with :s on remote systems
<fwereade> wallyworld_, especially when this apparently hits so much of the test suite
<wallyworld_> fwereade: but on remote systems they are not filenames
<wallyworld_> they are http urls
<wallyworld_> and that bit works fine on windows
<fwereade> wallyworld_, then can we have FileStorage run an http server, and return http urls? for the purpose of the tests, at least, allowing us to isolate the bits that need work in the real code?
<wallyworld_> http://cloud-images.ubuntu.com/releases/streams/v1/com.ubuntu.cloud:released:aws.json
<wallyworld_> that wil work fine on windows
<fwereade> wallyworld_, agreed
<fwereade> wallyworld_, but I would like our test data to reflect that reality, and not just sub out certain characters because they're inconvenient
<wallyworld_> we could run an http server, or, we could just 1. not use ":", use "-" instea
<wallyworld_> the ":" are *totally* arbitrary
<wallyworld_> the filenames don't matter
<fwereade> wallyworld_, agreed, but they're also in the live data
<wallyworld_> we just used ":" because the streams folks did
<wallyworld_> the image metadata folks have their own utilities for generate image json
<fwereade> wallyworld_, I agree that we can do that in the metadata plugin, and I think that's fine and great
<wallyworld_> our QA folks generate the tools metadata, and if we switch to "-", that won't affect anything
<fwereade> wallyworld_, my concern is all about the unrelated tests, that should be working against data that maps as closely as possible to the stuff in the wild
<fwereade> wallyworld_, we can generate other data for local usage, and that's all fine
<wallyworld_> the data *content* is important, not the filenaes
<wallyworld_> the filenames just don;t matter one iota
<wallyworld_> there is only one file accessed directly - the index file
<wallyworld_> the index file contains paths to the product files
<wallyworld_> we can make those whatever we want
<wallyworld_> to me that's easier than setting up a http server for storage
<fwereade> wallyworld_, I see this in the code:
<fwereade>     ProductMetadataPath = "streams/v1/com.ubuntu.cloud:released:imagemetadata.json"
<fwereade> wallyworld_, is it unused?
<fwereade> wallyworld_, or ill changing it suddenly cause us to stop working against the live data?
<wallyworld_> fwereade: that is *only* for the generate utility
<wallyworld_> not live data
<wallyworld_> live data reads the index file, looks in there, and follows the path therein
<wallyworld_> our generate plugin  makes index files also
<wallyworld_> and uses what you reference about for the product file path
<wallyworld_> but we can totally chaneg that
<wallyworld_> fwereade:  look inside this http://cloud-images.ubuntu.com/releases/streams/v1/index.json
<wallyworld_> that is live data
<wallyworld_> and the paths are what they are, we don't care
<wallyworld_> we just make a url from them
<wallyworld_> all that has nothing to do with the above const
<fwereade> wallyworld_, I understand that
<fwereade> wallyworld_, I am still not convinced that it's sane to arbitrarily change the format of our test data to be different to the live data -- *even if it's just a convention they use* -- for the convenience of the tests on windows
<fwereade> wallyworld_, am I making sense?
<wallyworld_> i guess that's where we differ - i see it as an arbitary internal implemenation detail
<wallyworld_> so long as the external behaviour is correct
<wallyworld_> ie Fetch works, the datasources work
<wallyworld_> who cares what the files are called under the covers
<fwereade> wallyworld_, I don't care what the files on disk are called, but I do care that the urls we create map to the ones used live
<fwereade> wallyworld_, and using file:// urls causes that correspondence to be important
<wallyworld_> i disagree :-)
<wallyworld_> the url content is also totally arbitrary
<wallyworld_> so long as we can 1. load an index file, 2. parse the data, 3. file and load the correct product file,
<wallyworld_> it doesn;t matter what the urls are
<wallyworld_> simplestreams doesn't care
<wallyworld_> simplestreams doesn;t even parse the urls
<wallyworld_> it just hands them off to http.Get
<fwereade> wallyworld_, I think it does matter, because it guards against inappropriate messing around with :s or drive letters in places where we shouldn't have to worry about them
<wallyworld_> we get rid of ":", problem solved there
<fwereade> wallyworld_, every time we tweak our test data to be less like the real data, we go another step away from a real test
<fwereade> wallyworld_, and that's great for the plugin/bootstrap cases
<wallyworld_> we use a helper MakeFileURL(path) function instead of "file://" + path, problem solved there
<fwereade> wallyworld_, except that simplestreams will try to create a url by tacking on a filename with a : in it
<wallyworld_> fwereade: disagree about another step away from real test
<fwereade> wallyworld_, and that won't work everywhere
<wallyworld_> you mean for the streams.canonical.com case?
<wallyworld_> those aren't filenames
<wallyworld_> they are url paths
<fwereade> wallyworld_, I know -- but we're apparently using FileStorage all over the shop as our mock for streams.c.c
<wallyworld_> sure, but simplestreams doesn't know thar
<wallyworld_> so long as we give it a url which http.Get can use, job done
<wallyworld_> it doesn't care what the url is
<fwereade> wallyworld_, so we have simplestreams code that mucks about with :s, and streams.c.c data that contains :s, and we're explicitly avoiding triggering the : cases
<wallyworld_> it won't muck around with ":" is we use "-" in our file names for the generate plugin
<wallyworld_> if
<wallyworld_> the streams.c.c data contains ":" but we don't cares, it's just urls we are dealing with
<fwereade> wallyworld_, agreed, AFAICS the generate plugin is easy to fix, but IMO it needs to be fixed *after* we get the working code reliably tested
<wallyworld_> the troube there is the tests and generate plugin use shared code to write out metadata
<wallyworld_> so it still comes down to those 2 issues. 1. use windows compatible file names "-" instead of ":"
<wallyworld_> and 2. the way we generate file:// urls
<fwereade> wallyworld_, ok, circling back, and leaving aside the question of how much work it is:
<fwereade> wallyworld_, would you agree that it's generally more appropriate to use state-based tool/image catalogues for all tests that are not about bootstrapping and/or the metadata plugin?
<wallyworld_> yes
<wallyworld_> but those are in the minority (hand waves)
<fwereade> wallyworld_, I find that hard to believe (waves hands vigorously and intimidatingly)
<fwereade> wallyworld_, I guess we'll need input from someone who's actually got a windows to run the tests against here :)
 * fwereade waves hands at gsamfira
<wallyworld_> fwereade: under environs/tools environs/simplestreams, environs/imagemetadata there are mainly pure simplestreams tests
<wallyworld_> then there are tests in cmd/juju/bootstrap (lots)
<wallyworld_> then there are the plugins tests
<fwereade> wallyworld_, anyway, even if they are in the minority, I contend that it's important to fix those first, because they're potentially obscuring other real failures
<wallyworld_> sure
<fwereade> wallyworld_, or alternatively eroding confidence in bits that really do work
<wallyworld_> no issue fixing tests which should be using tools from state but which aren't
<wallyworld_> but i have my doubts how many there are
<fwereade> wallyworld_, not to mention obscuring regressions in the bits that should work, that might get introduced by tangentially-related work
<fwereade> wallyworld_, just a mo
<fwereade> wallyworld_, WriteMetadata uses the Storage interface anyway
<fwereade> wallyworld_, it ought to be working with paths not URLs anyway, right?
<wallyworld_> let me check
<fwereade> wallyworld_, yeah, stor.Put(filePath, ...)
 * fwereade brb
<wallyworld_> fwereade: that Storage is a file system stor, not an provider cloud stor
<wallyworld_> it was done to allow metadata to be written to cloud storage as well as file system
<wallyworld_> but of course, cloud storage not needed anymore
<fwereade> wallyworld_, well, it's the Storage interface ;p
<wallyworld_> true, but doesn't need to be now
<wallyworld_> but yes, WriteMetadata works with paths
<wallyworld_> not urls
<bogdanteleaga> fwereade, wallyworld_: have you reached some agreement? I disconnected right after I've seen you've started to discuss my pr :)
<fwereade> bogdanteleaga, well, I remain adamant that we need to get the non-simplestreams and non-bootstrap tests working against state catalogues -- so we can have faith in the parts of the system that do work -- before we start changing up the bits that don't work
<fwereade> bogdanteleaga, can you estimate the proportions in play?
<wallyworld_> i agree with that
<fwereade> bogdanteleaga, my understanding is that there are a *lot* of tests failing, and I find it hard to believe that they're all about simplestreams and botstrap
<fwereade> bogdanteleaga, do you know what the failing proportion is offhand?
<bogdanteleaga> well right now we're looking at about 100 tests I think
<bogdanteleaga> without counting worker
<fwereade> bogdanteleaga, hmm, most of juju is in worker, isn't it?
<bogdanteleaga> the problem with getting non-simplestreams and non-bootstrap things up
<bogdanteleaga> is that some of the stuff depends on it
<bogdanteleaga> there's not really much else going on
<fwereade> bogdanteleaga, btw, can you send me the test output on windows?
<bogdanteleaga> there's some separate package derps
<bogdanteleaga> and some ssh/charms problems
<bogdanteleaga> sure
<marcoceppi> what is metrics.yaml
<mgz> marcoceppi: it's for metering, charms can define what kind of ticks they care about
<mgz> mattyw/cmars talked a bit about it at the sprint
<TheMue> mgz: ping
<voidspace> so, to assign a new private IP address to a network (amazon ec2), *and* know what ip address is, we have to make 3 calls
<voidspace> fetch all ips for that network, add a new ip address (which doesn't tell you the new one), fetch the ips for the network again and work out which is the new one
<voidspace> at least as far as I can tell
<mgz> voidspace: ick
<voidspace> mgz: yeah, I'm just spelunking the api docs to see if it's really that bad
<mgz> I guess what you actually care about is if there's any as-yet-unused private ip?
<voidspace> mgz: this is specifically for adding a new ip address for a new container in an instance
<voidspace> mgz: so really we do want "the one we just created"
<mgz> so it's really while True: ip = get_free_addr_from_pool() if addr: break; allocate_new_private_ip()
<voidspace> mgz: hmmm....
<mgz> which wpuld be maybe one call, but generally the three you mentioned :)
<mgz> also, ip==addr, go variable naming
<voidspace> mgz: there's an api call in goamz AssignPrivateIPAddresses
<voidspace> mgz: I'm not following you
<voidspace> mgz: we're not maintaining a pool here, and the abstraction you suggest doesn't really map to what we're doing
<voidspace> as far as I can tell :-)
<mgz> voidspace: well, I guess my assumption about just having any private ip is wrong, so rest makes no sense
<voidspace> mgz: hehe
<voidspace> mgz: yeah, we get ec2 to allocate the address for us
<voidspace> mgz: but when they allocate it, they don't tell you what they allocated...
<mgz> but you don't have to get ec2 to assign it, you can also supply one
<voidspace> mgz: that's possibly true, and then we'd need to maintain the pool (or similar)
<mgz> which is back to what I was assuming - not sure which is actually better in practice
<voidspace> at least for ec2
<voidspace> for maas I think we really do want maas to allocate it
<voidspace> but we don't have to use the same approach for both - so long as we have a consistent abstraction for getting the address
<TheMue> mgz: could you please drop the actions sync calendar entry? I'll add a new one I've got to change when daylight saving times are over
<mgz> drop?
<TheMue> mgz: remove, delete
<TheMue> mgz: just took the first word that came into my mind. ;)
<mgz> I can just make you all have edit rights?
<TheMue> mgz: that's ok too
<mgz> done
<TheMue> thanks
<TheMue> we're changing this weekend, the US next weekend
<marcoceppi> so, where are the windows charms?
 * fwereade has evidently done something dumb with git, anyone free to tell me what I did exactly and how to undo it? can be seen in reviews.vapour.ws/r/258/diff/ and https://github.com/juju/juju/pull/961 which claims to contain changes I already merged in the previous branch
<jcw4> fwereade: did you update your fork's master branch before making the PR?
<jcw4> fwereade: dunno if it still applies, but rbt previously required your master branch on your fork to be up to date
<TheMue> fwereade: had it once too. switch to the false changed branch, do an rbt post -u, then switch back to the correct changed branch and do an rbt post -u there too (afair, will take a look again)
<natefinch> fwereade: that can happen if you create a new branch from your old branch, without switching back to master first.  I did that yesterday.  The way I fixed it was to just make a new branch off master and cherry-pick the commit.  There's probably a better way to fix the current branch, but I don't know it offhand.
<fwereade> cheers guys, I'll hack at it a bit and see if it gets better :)
<fwereade> ah, looks happier now after merging master (again) and pushing (again)
<voidspace> fwereade: Jonathan is looking for work and we have an open position...
<voidspace> fwereade: I've emailed him...
<fwereade> voidspace, awesome, the collection grows...
<voidspace> fwereade: hopefully
<voidspace> fwereade: although I suspect it's a juju-gui position from the description
<voidspace> right, have a happy weekend everyone
<voidspace> g'night all
<jcw4> happy weekend voidspace
<voidspace> o/
<jog> mgz, or natefinch, could I get a quick review here: https://github.com/juju/juju/pull/963
<natefinch> sure
<mgz> jog: lgtm
<natefinch> laziness pays off again
<jcw4> :)
<jcw4> fwereade: do you happen to be online at 9:30 pm on a Friday evening?
<fwereade> jcw4, kinda, for a bit :)
<fwereade> jcw4, what can I do for you?
<jcw4> I'm feeling like the watcher mechanism for handling actions is creaking at the seams
<jcw4> fwereade: per niemeyer 's comments I think it's a fairly sizeable refactor to enforce ordering of action execution
<jcw4> fwereade: right now the watcher uses set.Strings to collect the id's in the watcher, which is a set without any ordering mechanism (afaik)
<fwereade> jcw4, so, that was not the idea, they were meant to produce ordered events
<fwereade> jcw4, but that's not that hard to enforce, is it?
<jcw4> fwereade: I think you're right
<fwereade> jcw4, worst case I can see is that two people sending actions at *almost* the same time might not get them in the db in quite the order they sent them
<jcw4> fwereade: I just get nervous relying on the watcher for ordering; but I suppose it's as good a queuing mechanism as any
<jcw4> fwereade: also, when the watcher is first created it gets a list of the id's already enqueued in the actions collection
<jcw4> fwereade: and in that query we're depending on the order that mongo gives them back to us in
<fwereade> jcw4, hmm, I thought we were sorting them
<jcw4> fwereade: I guess I'm beginning to prevaricate about the sequence id's -- they may not be a guarantee of ordering between two different clients, but I can't imagine them not being ordered for one client
<fwereade> jcw4, that was one of the reasons to have the sequence number in the id
<jcw4> fwereade: yeah - I can make sure we sort
<jcw4> fwereade: but niemeyer 's point was that the sequence mechanism isn't reliable for two different clients
<jcw4> fwereade: although if we allow that ordering between two clients is undetermined then the only issue left is if action-3 from client 1 runs before action-2 from client 2
<niemeyer> jcw4: That wans't the point, actually
<jcw4> I misunderstood then... :(
<niemeyer> jcw4: If two people send actions concurrently, there's no pre-defined order between them by definition
<jcw4> niemeyer: yes, that makes sense
<fwereade> niemeyer, o/
<niemeyer> jcw4: My point is that you should not allow that to be observable as order 103 goes before 102 if it comes from different clients
<niemeyer> fwereade: Yo
<jcw4> niemeyer: I thought that the problem was advertising sequence number that may not reflect reality
<niemeyer> jcw4: Isn't that what I just said?
<jcw4> niemeyer: yes exactly
<jcw4> I was just still typing
<niemeyer> jcw4: Okay
<niemeyer> jcw4: and my other point is that if one client sends two actions, the order should be respected
<jcw4> niemeyer: okay - which we can do using the sequence numbers right?
<niemeyer> jcw4: Can you? I don't know
<niemeyer> jcw4: You implied that sequence numbers were being generated out of the transaction
<jcw4> niemeyer: ah, I tried to clarify that it was in a separate transaction before the action was created
<jcw4> niemeyer: but you indicated that was even worse
<jcw4> :)
<niemeyer> jcw4: No, I just said it was a proof that you cannot trust the numbers alone if you are using a queue
<niemeyer> jcw4: Because client 1 might get action 103 committed before client 2 gets action 102 committed
<niemeyer> jcw4: and that's confusing
<jcw4> niemeyer: okay so far everything is consistent with my understanding from the emails
<fwereade> niemeyer, IIRC it's the sequence() thing we've had in state since forever -- downside is very rare out-of-order effects, upside is less unnecessary overlap in the txns
<niemeyer> fwereade: I don't see how that's relevant in this case
<niemeyer> fwereade: It doesn't matter how it's been used before, does it?
<niemeyer> fwereade: Actions are queued.. having a queue with out-of-order sequence numbers feels obviously bogus
<fwereade> niemeyer, yeah, wouldn't be hard to tweak -- the tradeoff in play is having lots of subtly-different code paths for doing almost identical things
<jcw4> niemeyer: is there a better queueing mechanism?  I don't know how to order actions other than by some generated sequence
<niemeyer> fwereade: I don't quite understand why this is not a trivial problem, with zero code duplication
<niemeyer> fwereade: If the sequence numbers are not sequential, use anything else, such as a random id
<jcw4> niemeyer: that implies to me that we can't use mongo collections as the queue because we have no way of sorting the items in the collection without a sequence?
<niemeyer> jcw4: a timestamp, a list field, a sequence number that is not exposed to the user, etc
<jcw4> niemeyer: okay - so timestamp is fine with me
<niemeyer> jcw4: That's a surreal statement :)
<jcw4> niemeyer: :)
<niemeyer> jcw4: You can order any data at all.. even a pair of random bytes
<jcw4> niemeyer: in my surreal statement a timestamp is a suitable sequence so I'm happy
<jcw4> niemeyer: sure - it's finding meaningful sorting that seems to be the trick here
<niemeyer> jcw4: Not even that.. the only thing I pointed out is that you should not have bogus sequence numbers exposed to the user
<jcw4> niemeyer: I keep coming back to the fundamental point that this is just an issue of representation to the end user right?
<jcw4> niemeyer: what you just said
<niemeyer> jcw4: The ordering was not the problem
<niemeyer> jcw4: Unless, of course, you use the actions completely unsorted, as you suggested in the email thread
<jcw4> niemeyer: so internally I'll fix the bug and sort actions by timestamp
<jcw4> niemeyer: and externally we'll represent action id's without implied ordering
<niemeyer> jcw4: Watch out for timestamp issues
<niemeyer> (clocks changing, machines in a cluster with unmatching clocks, etc)
<jcw4> fwereade: and sorting by timestamp, I think, introduces pulling the entire document instead of just the _id
<jcw4> niemeyer: is that mitigated by having the queuing done on the state server (i.e. only one machine)
<jcw4> niemeyer: esp. if we use UTC rather than some local representation of time
<niemeyer> jcw4: In principle the id with a sequence was fine for ordering
<jcw4> niemeyer: just not representing to the user?
<niemeyer> jcw4: As long as you're not exposing it to the user as means for defining the order in which events took place
<fwereade> jcw4, I'd be more inclined to pull the sequence generation into the txn if you want to expose the internal sequence
<niemeyer> fwereade: Hah, yep.. the txn-revno has a sequence
<niemeyer> Either way, I need to step out
<niemeyer> Back later
<jcw4> thanks niemeyer
<jcw4> fwereade: so use txn-revno instead of sequence() ?
<jcw4> fwereade: right now state.sequence() encapsulates its own transaction.
<fwereade> jcw4, hmm, that would work for ordering, and we have it available in the watcher
<jcw4> yeah
<jcw4> fwereade: does txn-revno guarantee uniqueness though?
<fwereade> jcw4, so long as we guarantee a single write to the doc inquestion, yes, I think so
<jcw4> fwereade: i.e. will dozens of new actions across different clients produce a steadily increasing txn-revno?  Yeah only one write.
<fwereade> well, so long as there's some document touched by all those transaction, yes
<fwereade> jcw4, so in practice, without changes, actually... no
<fwereade> jcw4, so
<jcw4> fwereade: so include a write to a master doc?
<fwereade> jcw4, well
<fwereade> jcw4, just putting the sequence-getting inside the txn might be the easiest way?
<jcw4> fwereade: duplicating the existing sequence() code?
<jcw4> fwereade: or factoring lines 19-24 of state/sequence.go into a re-usable block?
<fwereade> jcw4, I would need to look at it, but I would favour the latter on general principles
<jcw4> fwereade: +1
<fwereade> jcw4, would you take an hour or so to figure out the actual impact of pulling all sequence-generation into txns?
<jcw4> fwereade: sure... you mean every use of sequence() not just actions right?
<fwereade> jcw4, yeah, please figure out the larger picture
<jcw4> fwereade: +1
<fwereade> jcw<3
<jcw4> haha
<fwereade> wwitzel3, are you still working?
<fwereade> or katco maybe?
<jcw4> fwereade: 0 for 2
<fwereade> jcw4, seems that way
<jcw4> fwereade: gotta look for us west coast dudes
<jcw4> :)
<fwereade> jcw4, don't suppose I can induce you to review http://reviews.vapour.ws/r/258/ can I?
<jcw4> or whatever the gender neutral version of dude is
<jcw4> sure sure
<fwereade> jcw4, be harsh
<jcw4> hehe
<fwereade> jcw4, but bear in mind that I think it's a *bit* less bad than the current state
 * jcw4 rubs his hands evilly
<fwereade> don'tforget to twirl your mustachios
<fwereade> jcw4, http://www.themarysue.com/ibm-black-team/
<jcw4> amost exactly what I pictured when you said mustacios
<wwitzel3> fwereade: yep
<fwereade> wwitzel3, so, I landed most of that stuff that'll mess with you, I'm afraid
<wwitzel3> fwereade: ok, great
<fwereade> wwitzel3, jcw4 is currently looking at the next one that'll hurt
<fwereade> wwitzel3, but the more reviews I get on that one the better
<fwereade> wwitzel3, http://reviews.vapour.ws/r/258/
<jcw4> wwitzel3, fwereade hehehe
<wwitzel3> fwereade: ok, I will take a pass of it in a bit? or you trying to land it before the weekend?
<wwitzel3> fwereade: I'm right in the middle of a completely different thought :)
<fwereade> wwitzel3, I'd *love* to land it
<fwereade> wwitzel3, but just put it on the stack
<fwereade> wwitzel3, I am going to either finish the next refactoring or pass out
<fwereade> wwitzel3, which is to say "finish"
<wwitzel3> right :)
<fwereade> wwitzel3, in that it'll need a sober pass before I even try to propose it
<fwereade> wwitzel3, but I don't have the courage to start it unfortified
<fwereade> wwitzel3, and hey it's friday, I'm already fortified, and everyone else is asleep
<wwitzel3> fwereade: no one should be subjected to starting a refactor sober
<jcw4> *thats* my problem
<wwitzel3> fwereade: how else will you get the courage to start?
<fwereade> wwitzel3, I've been putting this one off for almost two years now :/
 * jcw4 yells "honey: where's my petit syrah!?"
<wwitzel3> fwereade: I'm glad it is happening :) .. I am sure it is doubtful, but it any of it can be worked on async, let me know.
<wwitzel3> fwereade: refactoring is always one of those things where I wish there was five of me with the same overall vision at the same time
<wwitzel3> under most conditions five of me would be a horrible thing
<fwereade> wwitzel3, yeah, I worry that I'd just argue with myself even more than usual
 * fwereade wishes he hadn't started by renaming a package, it's really not helping
<wwitzel3> :)
<fwereade> nah, actually, that's *nothing* compared to the errors I'm suddenly seeing in totally unrelated packages :/
 * fwereade runs godeps and hopes
 * fwereade feels unjustifiably smug
<wwitzel3> fwereade: I played a game of Dominion where I won doing nothing but stacking my buys and getting as many actions, coppers, and vineyards (+1 VP per 3 action points)
<wwitzel3> fwereade: I thought of you
<fwereade> wwitzel3, lol, nice :)
<fwereade> wwitzel3, don't think I've ever played with vineyards
<fwereade> wwitzel3, is that cornucopia?
<wwitzel3> http://wiki.dominionstrategy.com/index.php/Vineyard
<wwitzel3> Alchemy
<fwereade> wwitzel3, very nice
<fwereade> fuck, knew I should have done that other step first :/
<fwereade> ...and didn't even realise that *other* step I should also have done first
<fwereade> bah
<jcw4> I thought you said you were fortified fwereade
<fwereade> jcw4, I didn't say I'm not pressing on, did I :)
<jcw4> hehe
<fwereade> jcw4, just means I've got to split it up more before I can land it ;p
<jcw4> fwereade: LGTM, plus minor comments
 * fwereade cheers heartily at jcw4
<jcw4> :)
 * fwereade wishes jc<tab> autocompleted
<jcw4> well three tabs means you might as well just type it out
<jcw4> I need a longer nick to justify the multiple tabs
<jw4> fwereade: there... jw<tab> ?
<fwereade> jw4, man, now I need to rewire my muscle memory ;p
<jw4> haha
<fwereade> jw4, but it *is* nice all the same
<fwereade> jw4, you wouldn't think that "jc" would be such a common prefix
<fwereade> omfg uniter tests passing
<jw4> haha
<fwereade> this might have actually worked
 * fwereade is coder, hear me roar
<wwitzel3> it either worked, or we have no coverage for what you just changed .. but really, they might as well be the same thing ;)
#juju-dev 2014-10-26
<fwereade> gsamfira, ping
<fwereade> gsamfira, actually don't worry
#juju-dev 2015-10-19
<mup> Bug #1494542 opened: config-changed error does not cause error state <hooks> <juju-core:In Progress by axwalk> <juju-core 1.24:Fix Released by thumper> <juju-core 1.25:Fix Released by thumper> <https://launchpad.net/bugs/1494542>
<dimitern> jam, ping - 1:1 ?
<jam> dimitern: sorry I missed you, maybe chat after standup?
<dimitern> jam, ok, sure
<dimitern> jam, frobware, TheMue, standup?
<TheMue> sorry, phone call, will join in a moment
<mattyw> fwereade, ping?
<fwereade> mattyw, pong
<mattyw> fwereade, hey hey, would you have 10 minutes for a little chat about http://reviews.vapour.ws/r/2746/
<fwereade> mattyw, in 10-20 mins? meeting atm
<mattyw> fwereade, ping me when you're around
<dimitern> frobware, TheMue, I've suggested to skip the planning today and instead do it as scheduled on friday, with a "double retro" for this and the last iteration
<frobware> dimitern, dooferlad: I'm back... I also scheduled a planning session in 30 mins.
<dooferlad> frobware: ack
<dimitern> frobware, I guess you didn't get my earlier message
<frobware> dimitern, nope
<dimitern> frobware, TheMue, I've suggested to skip the planning today and instead do it as scheduled on friday, with a "double retro" for this and the last iteration
<frobware> dimitern, fair enough and as long as we have enough scheduled until then.
<dimitern> frobware, I think we do
<dimitern> jam, do you think "storage.fast" needs to be part of the constraints accepted syntax for maas?
<dimitern> jam, I was thinking the constraints should be generic and the bindings define the specific parts, like fabric class
<dimitern> jam, so in order to get to the arguments we need to pass to acquire node, we combine constraints and bindings (the latter overriding the more generic former)
<jam> dimitern: i would have actually expected the constraints to match the binding syntax
<jam> dimitern: from the model of "constraints are just about placement"
<jam> and if we want to deploy 2 services on a machine, then that machine needs to be somewhere that can match these constraints
<jam> which are what bindings will be used for services deployed to that machine
<jam> (or containers on that machine)
<dimitern> jam, are you saying we should support [<plug>@|^]<space>[.<class>] in constraints?
<dimitern> I think this unnecessarily complicates things
<jam> dimitern: I'm not suggesting "plug" in constraints
<jam> but you need a way to say "I'm about to create a machine, for which I'm going to deploy services on it"
<jam> you need a way to "add-machine" that is in the right spaces and fabrics to be able to "deploy plug@"
<dimitern> jam, right, then constraints like spaces=foo.bar are passed literally to maas
<jam> right
<dimitern> jam, ok, we're in agreement then :)
<dimitern> jam, I'll update the docs to reflect this
<dooferlad> dimitern: python is there in the default Ubuntu image that MAAS installs.
<dooferlad> dimitern: i.e. images/ubuntu/amd64/generic/trusty/release/root-tgz so I guess that is a default cloud image
<jam> dooferlad: traditionally ubuntu used upstart which is python based so it *had* to have python, I'm not sure if it could be removed now, but IIRC python is still part of a bunch of core bits
<dimitern> dooferlad, awesome!
<dooferlad> jam: good to know. I thought it had to be there, but I just wanted to check
<dimitern> dooferlad, when you have some time, I'd appreciate if you can independently test my juju-br0 script changes on your maas(es?) with 1.25: https://github.com/juju/juju/pull/3539
<dooferlad> dimitern: will do
<dimitern> dooferlad, cheers
<frobware> dimitern, published some comments. Given the size of the script you could also run it through http://www.shellcheck.net/about.html
<dimitern> frobware, I didn't know that checker, will do - thanks for the review!
<mup> Bug #1506866 opened: Juju delays ~15min to update the unit public address with a Nova floating IP <juju-core:New> <https://launchpad.net/bugs/1506866>
<dooferlad> dimitern: how exactly do you want me to test that branch?
<dimitern> dooferlad, you have your maas working right?
<dimitern> dooferlad, 1.9
<dooferlad> dimitern: I am on 1.8
<dimitern> dooferlad, ah, I see
<dooferlad> dimitern: do you want me to upgrade?
<dimitern> dooferlad, well, it should work on 1.8 (haven't tested)
<dimitern> dooferlad, how about this: bootstrap --upload-tools --to somenode.maas on 1.8 and then add-machine/deploy+add-unit --to lxc:0
<dooferlad> dimitern: I was more asking about the juju changes. Is it a case of turning off the addressable containers flag and deploying a machine?
<dimitern> dooferlad, it applies only without the feature flag
<dooferlad> dimitern: OK, will do.
<dooferlad> dimitern: I don't like that we have juju-br0, but that is for another time!
<dimitern> dooferlad, basically, I've tested: 1)bootstrap --to (with various network setups on a NUC with 2 NICs - second one usb2eth adapter); 2) add-machine/add-unit --to lxc and kvm
<dimitern> and made sure all machines come up (eventually, I'm experiencing slow downs due to c-i waiting 120+ secs before yielding the node to juju after provisioning) with the proper IPs
<dimitern> dooferlad, use your CI script - it should be easy to test with the feature flag and without on 1.8 (to ensure no regressions)
<dimitern> dooferlad, but it's a good idea to upgrade to 1.9 soon :)
<mup> Bug #1507601 opened: TestStartTerminationWorker fails on gccgo <ci> <gccgo> <ppc64> <regression> <test-failure> <juju-core:Triaged> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1507601>
<mup> Bug #1507637 opened: Bootstrap and provisioning fail with internal error tagging instance <bootstrap> <ci> <ec2-provider> <intermittent-failure> <juju-core:Incomplete> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1507637>
<mup> Bug #1507644 opened: backup i/o timeout <backup-restore> <ci> <intermittent-failure> <juju-core:New> <https://launchpad.net/bugs/1507644>
<mup> Bug #1507644 changed: backup i/o timeout <backup-restore> <ci> <intermittent-failure> <juju-core:New> <https://launchpad.net/bugs/1507644>
<mup> Bug #1507644 opened: backup i/o timeout <backup-restore> <ci> <intermittent-failure> <juju-core:New> <https://launchpad.net/bugs/1507644>
<perrito666> what could provoke for juju agent to uninstall itself?
<mgz> perrito666: bug 1464304
<mup> Bug #1464304: Sending a SIGABRT to jujud process causes jujud to uninstall (wiping /var/lib/juju) <sts> <juju-core:Fix Committed by axwalk> <juju-core 1.25:Fix Committed by axwalk> <https://launchpad.net/bugs/1464304>
<frobware> mgz, regarding https://bugs.launchpad.net/juju-core/+bug/1491592 - the bug has already been fixed in 1.25. Is it best to set the state for that to "Invalid", or something else?
<mup> Bug #1491592: local provider uses the wrong interface <charmers> <customer-support> <kvm> <local-provider> <networking> <juju-core:In Progress by frobware> <juju-core 1.24:Triaged> <https://launchpad.net/bugs/1491592>
<frobware> mgz, and is also fixed in 1.24.7
<mgz> frobware: just fix committed if it'll be in the next 1.25
<mgz> frobware: were there particular commits that got landed?
<mgz> I can retroactively add it to the 1.24.7 milestone if needed
<mgz> if it's just we fixed this at some point and don't really know when, just mark fix released and remove milestone
<frobware> mgz, not sure; might have been this fix https://bugs.launchpad.net/juju-core/+bug/1435283
<mup> Bug #1435283: juju occasionally switches a units public-address if an additional interface is added post-deployment <addressability> <bug-squad> <network> <openstack-provider>
<mup> <juju-core:Fix Released by mfoord> <juju-core 1.24:Fix Released by mfoord> <juju-core 1.25:Fix Released by mfoord> <https://launchpad.net/bugs/1435283>
<mgz> that seems likely
<mgz> I'm tempted to just dupe into that bug
<frobware> mgz, your call. was just trying to close it out now I know where we stand.
<mgz> frobware: I'll poke things
<frobware> mgz, gracias
<perrito666> mgz: I was not aware that was still standing
<mgz> perrito666: as of today, it's not :)
<perrito666> mgz: am I lucky
<mgz> or you're just fashionably late :9)
<mup> Bug #1491592 changed: local provider uses the wrong interface <charmers> <customer-support> <kvm> <local-provider> <networking> <juju-core:Fix Released> <juju-core 1.24:Fix Released> <https://launchpad.net/bugs/1491592>
<mup> Bug #1491592 opened: local provider uses the wrong interface <charmers> <customer-support> <kvm> <local-provider> <networking> <juju-core:Fix Released> <juju-core 1.24:Fix Released> <https://launchpad.net/bugs/1491592>
<mup> Bug #1491592 changed: local provider uses the wrong interface <charmers> <customer-support> <kvm> <local-provider> <networking> <juju-core:Fix Released> <juju-core 1.24:Fix Released> <https://launchpad.net/bugs/1491592>
<perrito666> meh, no dimitern
<thumper> morning
<rick_h_> thumper: morning, early?
<thumper> not really
<thumper> clocks went forward some weeks back
<thumper> almost 9am here now
<rick_h_> wow ok
<mup> Bug #1507771 opened: Juju deploy fails when template container cannot be started <cdo-qa> <juju-core:New> <https://launchpad.net/bugs/1507771>
<mup> Bug #1507771 changed: Juju deploy fails when template container cannot be started <cdo-qa> <juju-core:Triaged> <https://launchpad.net/bugs/1507771>
<mup> Bug #1507771 opened: Juju deploy fails when template container cannot be started <cdo-qa> <juju-core:Triaged> <https://launchpad.net/bugs/1507771>
<mgz> sinzui: will uploading the revising juju packaging with deps interfer with your 1.24.7 efforts in any way?
<sinzui> mgz: No, 1.25 is a separate effort
<sinzui> mgz:  and I now know We need a wily machine to make source packages. I will get something to test, then solve future building needs
<sinzui> cherylj: I just targted this: you can choose to remove it from 1.25 if it isn't a goal https://bugs.launchpad.net/juju-core/+bug/1506680
<mup> Bug #1506680: `juju environments` fails due to missing ~/.juju/current-environment <juju-core:Triaged> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1506680>
<cherylj> thanks, sinzui.  I'm thinking it should be targeted to 1.25.1, since I don't think we're going to be removing the JES feature flag until 1.26
<sinzui> wallyworld: the many commits to master, 1.25, and feature-payloads prevent your two branches from being tested.
<sinzui> cherylj: +1
<wallyworld> :-(
<sinzui> wallyworld: 1.25 and master were tested 20 times, payloads 4 times and chicago-cubs 2 times. Your branches are not more important than master
<wallyworld> no they are not
<wallyworld> but
<wallyworld> i really am looking forward to not having feature branches wither on the vine
<axw> mgz: thanks for fixing the gccgo build failure
<mgz> axw: no worries
<axw> wallyworld: my camera decided to stop working, trying to fix now
<wallyworld> ok
#juju-dev 2015-10-20
<davecheney> thumper: i figured out the final test failure on my branch
<davecheney> here is a hint
<davecheney> lucky(~/src/github.com/juju/juju) % jujud version
<davecheney> 1.26-alpha1
<davecheney> cherylj: thumper do you know if we have a test for "juju version"
<davecheney> or "jujud version"
<davecheney> i suspect that we do not
<thumper> um... wat?
<thumper> oh
<thumper> I see that both juju version and jujud version are fully qualified with series and arch
<davechen1y> thumper: https://github.com/juju/cmd/pull/24
<davechen1y> little one for you
 * thumper looks
<thumper> LGTM
<davechen1y> thumper: ta
<davechen1y> thumper: https://github.com/juju/juju/pull/3545
<davechen1y> complimentary change in juju/juju
<thumper> shipit
<davechen1y> thumper: do you know if the version subcommand is sahred between cmd/juju and cmd/jujud
<davechen1y> tryign to figure out where it is registered is a bugger
<davechen1y> i'm trying to figure out if i need to add more tests
<davechen1y> or if there is only one place version is created
<thumper> the version is passed in when the primary super command is created
 * thumper double checks
 * thumper gets a bad feeling
<davechen1y> do tell
 * thumper cries 
 * thumper adds another item to the shit list
<thumper> davechen1y: I'm actually tring to find out where the version is hooked into the juju cmd
<thumper> and it isn't obvious
<davechen1y> it is not
<davechen1y> this is the bug blocking landing the versin.Current branch
<davechen1y> a lot of code relies on the output of 'jujud version'
<davechen1y> being specific form
<davechen1y> please assign me the tech debt card
<davechen1y> i'l fix it
<thumper> the tech debt card is a different one, cmd/juju/commands badrun func needs to die
<thumper> ah ha
<thumper> cmd/supercommand.go
<thumper> that is where the version string is added
<thumper> davechen1y: and that file has the run notifier too
<thumper> davechen1y: if I have a select block where some of the values are channels and others are functions that return channels, will all the functions get executed?
<thumper> or does it depend?
<thumper> davechen1y: your stress.sh helper seems to indicate that it will always be called
<davechen1y> selection happens in two phases
<davechen1y> 1. all expressions are evaluated, returning channels that may be selectable
<davechen1y> 2. the other stuff
<davechen1y> so if you ahve
<davechen1y> case <- c:
<davechen1y> case <- f():
<davechen1y> then f() will be evaluated
<davechen1y> that phase happens in order, from top to bottom
<davechen1y> so case <- a():
<davechen1y> case <- b():
<davechen1y> a() will be evalusted, then b()
<thumper> ok
<thumper> my test adds a marker when the func is called, and returns a channel
<thumper> just making sure that the func is always called before channels checked
<thumper> this is good
<thumper> makes for a stable test :)
<davechen1y> always called, and always in the same order
<thumper> coolio
<davechen1y> thanks for the supercmd tip
<davechen1y> i'll make sure we're testing the expected output there
<thumper> the juju/juju/cmd/supercommand.go just passes in the string
<thumper> to use as the version
<thumper> this is just echoed from the juju/cmd package
<thumper> when someone uses the version command
<axw> wallyworld: is there a bug for tests failing on wily?
<axw> wallyworld: (I can look if you don't know off the top of your head ...)
<thumper> axw: not sure if there is a bug, but there are two causes that leap to mind
<thumper> 1. errors changing text and our tests are too strict
<thumper> 2. scheduling changes bringout out timing related errors
<thumper> bringing
<axw> thumper: ok, thanks
<axw> running a wily container now to run the tests
 * thumper thinks
<thumper> in the past, I think there were other problems attempting to run the unit tests in containers
<thumper> not sure what it was though
<thumper> nor sure if they are still there
<axw> thumper: AFAIK they were all timing related
<axw> will find out shortly :)
<thumper> :)
<davechen1y> ... mismatch at ["services"]["mysql"]: length mismatch, 4 vs 5; obtained map[interface {}]interface {}{"charm":"local:quantal/mysql-1", "exposed":false, "relations":map[
<davechen1y> interface {}]interface {}{"server":[]interface {}{"wordpress"}}, "units":map[interface {}]interface {}{"mysql/0":map[interface {}]interface {}{"agent-state":"allocating"
<davechen1y> , "machine":"1"}}}; expected map[interface {}]interface {}{"relations":map[interface {}]interface {}{"server":[]interface {}{"wordpress"}}, "service-status":map[interfac
<davechen1y> e {}]interface {}{}, "units":map[interface {}]interface {}{"mysql/0":map[interface {}]interface {}{"agent-state":"allocating", "agent-status":map[interface {}]interface
<davechen1y> {}{}, "machine":"1", "workload-status":map[interface {}]interface {}{}}}, "charm":"local:quantal/mysql-1", "exposed":false}
<davechen1y> any ideas ?
<davechen1y> for some reason updaing github.com/juju/cmd causes this test to fail because there is an additional status element
<davechen1y> OH FUCKING FUCK
<davechen1y> https://github.com/juju/cmd/commit/2933b3ffd9116713d6da61494cdc789889100cb7
<davechen1y> yaml.v1 and yaml.v2 treat these structs differently
<davechen1y> thumper: https://github.com/juju/cmd/pull/25
<thumper> :(
<axw> thumper: I dunno if someone already fixed the issues, but tests run fine on master with wily in an LXC container
<thumper> axw: well that is good
<axw> wallyworld_: ^^
<thumper> I still get failures running locally on trusty with 1.5
<wallyworld_> hmmm
<axw> thumper: FWIW I was using go 1.5 from the golang-go package
<davechen1y> thumper: tests do not pass under Go 1.5
<davechen1y> peergrouper is still a shitshow
<thumper> axw: you may want to retry the peergrouper tests
<axw> davechen1y: does for me - perhaps more frequent failures though?
<wallyworld_> axw: i was only going by what curtis told me
<thumper> sometimes they pass, sometimes not
<davechen1y> axw: 100% failure rate across amd64, ppc64 and arm64
<davechen1y> thumper: http://reviews.vapour.ws/r/2945/
<davechen1y> please, it's quite urgent as it is blocking me
<axw> davechen1y: definitely not 100% for me. I'm using 1.5 and it passes.
<thumper> davechen1y: :-( what is so different between v2 and v1?
<davechen1y> thumper: they handle empty fields differently
<thumper> ugh
<wallyworld_> axw: could you look at the jenkins job and see what failures there are there compared with your test run?
<davechen1y> http://juju-ci.vapour.ws:8080/job/github-merge-juju/5150/console
<davechen1y> we can try again later
<axw> wallyworld_: sure
<wallyworld_> ty
<davechen1y> i'll put it on my list to take over the transition from mgz
<davechen1y> thumper: http://juju-ci.vapour.ws:8080/job/github-merge-juju/5150/console
<thumper> davechen1y: ack, back to v1, when we move juju/juju to v2, we can fix the tests
<davechen1y> thumper: ta
<davechen1y> thumper: how's that tech debt backlog ?
<thumper> growing
<thumper> davechen1y: https://canonical.leankit.com/Boards/View/116651667#workflow-view
<davechen1y> lotta red
<thumper> :)
<davechen1y> https://github.com/juju/cmd/pull/25
<davechen1y> can someone submit this for me
<davechen1y> bot has gone awol
 * thumper explodes
<davechen1y> landing bot has borke
<davechen1y> http://juju-ci.vapour.ws:8080/job/github-merge-juju-cmd/5/console
<davechen1y> wallyworld: can you kick the bot please
<davechen1y> it's not picking up jobs anymore
<wallyworld> all jobs or just yours?
<wallyworld> it looks for a Build failed: message
<wallyworld> otherwise it will ignore resubmits
<davechen1y> wallyworld: it won't get that message
<davechen1y> 'cos it died
<davechen1y> wallyworld: http://juju-ci.vapour.ws:8080/job/github-merge-juju-cmd/5/console
<wallyworld> so manually type in "Build failed: foo" into gh comment on the pr
<davechen1y> \o/
<davechen1y> thanks for the tip
<wallyworld> and then a subsequent $$merge$$ will trigger
<wallyworld> i know it's sucky
<davechen1y> meh
<davechen1y> that works
<wallyworld> yay
<davechen1y> at least I can fix it myself
<davechen1y> without having to nag you
<wallyworld> sure :-)
 * thumper is done
<axw> wallyworld: so it's possible for the peergrouper tests to error if the set of state server machines is non-empty... nfi how that would be the case. doesn't appear to be wily-specific, and I haven't been able to repro in my container
<axw> wallyworld: I'll keep poking
<mup> Bug #1507867 opened: juju upgrade failures <canonical-bootstack> <upgrade-juju> <juju-core:Triaged> <https://launchpad.net/bugs/1507867>
<wallyworld> axw: thanks for looking into it - those peer grouper tests are horrid
<axw> wallyworld: there's only one test that's using a real mongo connection in a meaningful way. I'm going to move that one to featuretests, and remove the remnants of JujuConnSuite from the others
<wallyworld> dimitern: could you add any notes / progress to that bug so other folks can stay in the loop? maybe add in a sentence or 2 the solution with cidr that is being looked at?
<dimitern> wallyworld, sure
<wallyworld> ty, you rock
<dimitern> wallyworld, well it's my own mess to begin with ;/
<wallyworld> our mess, we all own juju :-)
<dimitern> :D that's better, yeah
<dooferlad> frobware: hangout?
<frobware> omw
<wwitzel3> ericsnow, katco`, natefinch: where did we fall on allowing you to pass register just the workload class name and ID, because as I write out these notes again, it feels really odd to be defining it in the metadata AND then passing all of that in on the command line
<ericsnow> wwitzel3: I thought we were dropping the redundant CLI arg
<wwitzel3> ericsnow: ok, current register doesn't do that it seems
<ericsnow> wwitzel3: I may be wrong :)
<katco`> wwitzel3: yeah we agreed on dropping it, but probably got lost in translation as the team was scrambling. it's fine for v1
<katco`> wwitzel3: we can change in v2 if necessary
<katco`> wwitzel3: remember, mvp
<TheMue> dimitern: thx
<cherylj> dimitern: did you see my question about bug 1483879?
<mup> Bug #1483879: MAAS provider: terminate-machine --force or destroy-environment don't DHCP release container IPs <destroy-machine> <landscape> <maas-provider> <juju-core:Triaged> <juju-core 1.24:Triaged> <https://launchpad.net/bugs/1483879>
<dimitern> cherylj, looking now
<dimitern> oh ffs
<dimitern> this doesn't seem to be going anywhere
<dimitern> cherylj, where's you comment?
<dimitern> your
<cherylj> i had sent you an email about it.  there was speculation that this had already been fixed
<cherylj> We'd like to target it for 1.25.0
<dimitern> cherylj, I believe it is indeed fixed
<dimitern> cherylj, but there seems to be a communication breakdown somewhere between us and them :)
<cherylj> Do you happen to know which commit(s) fixed it?
<mup> Bug #1508089 opened: `juju set keystone ...` caused `hook "config-changed" failed` <juju-core:New> <https://launchpad.net/bugs/1508089>
<dimitern> cherylj, the linked PR - https://github.com/juju/juju/pull/2548
<cherylj> dimitern: Thanks!
<katco> ericsnow: if master uses charm.v6-unstable, why don't we just forward-port the payload stuff from v5? why move it out?
<katco> ericsnow: is that by design?
<ericsnow> katco: because workloads.go really doesn't belong in the charm repo
<katco> ericsnow: gotcha
<katco> ericsnow: are we doing the cleanup in the feature-payloads branch?
<ericsnow> katco: that's not quite clear to me
<ericsnow> katco: was going to tackle that as we got closer depending on where we stood on master
<katco> ericsnow: the question or it's not clear what the answer is?
<ericsnow> katco: what the answer is :)
<katco> ericsnow: i think it's fine since it's landed in 1.25. if we need to change anything there we can just branch off of 1.25
<katco> ericsnow: maybe the only thing that gives me pause is how hard will it be to rebase the changes on top of master
<katco> ericsnow: i'll try that first and see what we're looking at
<ericsnow> katco: I'd say wait on the rebase until after you take care of the charm/workloads.go thing
<ericsnow> katco: otherwise you won't be able to test the rebase
<katco> ericsnow: how difficult it is to rebase determines where we do a new feature branch
<ericsnow> katco: k
<katco> ericsnow: i.e. it's the difference between "start from master, pull in workload feature" or "start from 1.25 and rebase to master"
<lazypower> wwitzel3, ubuntu@xps13:~$ juju --version
<lazypower> 1.26-alpha1-trusty-amd64 - the 1.25 branch reports version as if it were trunk, is this intended behavior?
<wwitzel3> lp|lunch: not sure, does the same for me, so it is ok for what we are doing
<katco> wwitzel3: lp|lunch don't think that is intentional
<mup> Bug #1508089 changed: `juju set keystone ...` caused `hook "config-changed" failed` <juju-core:Invalid> <keystone (Juju Charms Collection):New> <https://launchpad.net/bugs/1508089>
<lazyPower> ack
<lazyPower> just making sure its consistent. I went to verify that i had the proper docker bin built and i saw the 1.26 alpha - its not terribly alarming, just thought i'd ping about it
<lazyPower> er
<lazyPower> juju bin
 * lazyPower has that other container thing on the brain
<alexisb> thumper, I am going to steal some time w/ cherylj before we meet
<thumper> k
<cherylj> hey wallyworld, I'm going through the 1.25 bugs and came across this one which I'm not sure if we should bump the priority of to get into 1.25.0:  bug 1469193
<mup> Bug #1469193: juju selects wrong address for API <kvm> <local-provider> <lxc> <network> <sts> <juju-core:Triaged> <https://launchpad.net/bugs/1469193>
<cherylj> wallyworld: what do you think?
<wallyworld> cherylj: give me 5 to look, just in standup
<cherylj> wallyworld: np, I might be on kid duty in a few, but I'll check scrollback if I miss it
<wallyworld> cherylj: that bug is symptomatic of a class of problem that is bad and that juju has had trouble with in the past. sapphire is looking at an issue now that was fallout from attempting to deal with this sort of thing.
<wallyworld> bug 1507867
<mup> Bug #1507867: juju upgrade failures <canonical-bootstack> <upgrade-juju> <juju-core:Triaged> <https://launchpad.net/bugs/1507867>
<wallyworld> cherylj: so i'd personally like that bug you mentioned to be a 1.25 fix, if not 1.24. maybe it will be covered by the work sapphire is doing now to fix the 2nd bug above
#juju-dev 2015-10-21
<cherylj> thanks, wallyworld.  Given that we want 1.25.0 asap, do you think it could reasonably be done soon?  or should we aim for it in 1.25.1?
<wallyworld> cherylj: it can go in 1.25.1 - it's been broken for a while AFAIK. so let's not hold up 1.25 for it, but i'd like to think 1.25.1 will appear not too long after
<cherylj> wallyworld: sounds good, thanks!
<lazyPower> :O
<lazyPower> update-status hook isn't a myth!
<perrito666> lazyPower: it better not
<perrito666> we should settle for one of the englishes in the code
<lazyPower> perrito666, i heard about it in seattle, but called schenanigans
<lazyPower> i'm on a build of 1.25-beta2 and its in here
<perrito666> grep -ri authorized | wc -l
<perrito666> 997
<perrito666> grep -ri authorised | wc -l
<perrito666> 200
<perrito666> lazyPower: it better be, I put it there
<thumper> perrito666: english vs american
<perrito666> thumper: they both sound foreign to me :p
<thumper> :)
<natefinch> pretty sure America invented English
<perrito666> My brain reads juju comments and code with the BBC narrator voice so I presume it is uk version :p
<natefinch> lol
<perrito666> ok brain coredumped, see some of you tomorrow
<axw> dpb1: don't suppose you still have the env for https://bugs.launchpad.net/juju-core/+bug/1491688? and can I get access? I haven't had any luck reproducing it, and the logs aren't very illuminating
<mup> Bug #1491688: all-machine logging stopped, x509: certificate signed by unknown authority <landscape> <logging> <rsyslog> <sts> <juju-core:Triaged> <juju-core 1.24:In Progress by axwalk> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1491688>
<thumper> axw: I have that locally with 1.24.6
<axw> thumper: orly? did you have to do something special?
<thumper> start two local providers
<thumper> it fucks up all the logs
<thumper> it used to work
<axw> interesting
<axw> I'll try that
<thumper> the lxd provider will fix this...
 * thumper can't wait
<natefinch> we should just warn people about the problems of running more than zero local providers
<axw> thumper: pretty sure LS is using MAAS though...
<thumper> yeah...
<natefinch> and yes, the lxd provider is amazing
<thumper> I'm guessing that this isn't necessarily the same problem
<axw> I want it nowwwww
<natefinch> a little slow, though
<thumper> natefinch: plz make tools work properly with local streams
<thumper> slow
<thumper> ?
<axw> natefinch: the OpenStack on LXD demo wayne did was pretty sweet
<thumper> agreed
<natefinch> bootstrapping takes like twice as long as the local provider
<natefinch> axw: yeah, that demo was pretty killer
<natefinch> honestly, just bootstrapping without it asking for a sudo password kind of rocks my world... not to mention the fact it doesn't crap all over my local machine
<thumper> natefinch: hah...
<thumper> well that isn't really surprising
<thumper> local bootstrap isn't starting a machine
<natefinch> right
<thumper> it is just shitting on our local machine
<natefinch> what amazed me the most was how easy it was to write the provider.  They really did well with lxd
<dpb1> axw: I don't, and it wasn't seen with doing anything funky (like two local providers).  But, if you all can't repro, I totally understand (I certainly can't at will).  I've seen it a total of twice.
<axw> dpb1: ok, no worries. I'll keep looking anyway
<natefinch> what's the right way to convert from a unit ID to a unit tag?  I'm getting unit ids back from a strings watcher and I've been told I have to pass Tags through the API.
<natefinch> names.NewUnitTag looks likely, but it panics if I pass it an invalid id (which is gobsmackingly horrible, btw)
 * thumper looks
<thumper> natefinch: what do you have?
<thumper> service/3 ?
<natefinch> yeah
<thumper> names.NewUnitTag should work
 * thumper looks at the tests
<natefinch> but it panics... which means I have to check the ids before I pass it into the function, and then that function itself rechecks the ids, which is dumb
<thumper> natefinch: 	c.Assert(names.NewUnitTag("wordpress/2").String(), gc.Equals, "unit-wordpress-2")
<thumper> yes, you have to check
<thumper> names.IsValidUnit
<thumper> all the New*Tag methods panic on invalid input
<natefinch> that's horrible
<thumper> because they are generally used where checking errors is a PITA
<thumper> no... it is a valid pattern
<thumper> most places, you know you are dealing with valid names
<thumper> sometimes, like user input, you need to validate
<natefinch> it's a house of cards waiting for someone to feed the wrong string into the wrong function at some point and the whole thing blows up in production because someone didn't want to check an error.
<thumper> I disagree
<thumper> but I can see your point of view
<natefinch> ditto :)
<thumper> so...
<thumper> given that you have a valid unit name, why is it failing?
<thumper> perhaps you don't have what you think you have
<natefinch> I'mwriting an api client.  It takes a list of strings it hopes are ids. It shouldn't assume someone's not going to do the wrong thing
 * thumper looks at unit id
<thumper> agreed, the client (and the server) need to validate
<natefinch> for example, my test passed in an invalid id, and the code panicked.  Sure, I could not do that, but that seems silly
<thumper> right, so validate
<natefinch> right
<thumper> IIRC the general use case for creating tags using the New*Tag methods was tests
<thumper> at the time they were written
<thumper> and panicing in tests is fine
<thumper> perhaps we should create a new class of functions
<thumper> that validate and return (tag, error)
<thumper> however, the line count will be approx the same as currently
<natefinch> it just irks me to call IsValidUnit twice
<thumper> it is my expectation that if I'm calling a function that doesn't return an error, I should check theinput
<thumper> you don't
<thumper> do you?
<natefinch> I assume a function that doesn't return an error can't fail
<thumper> well...
<thumper> or it panics
<thumper> because Go
<natefinch> well... except that in general you never panic unless THE WORLD HAS COME TO AN END.  Not because johhnny passed in "foo"
<natefinch> so, I don't call IsValidUnit twice, but I call it once and then NewUnitTag calls it once
<thumper> / NewUnitTag returns the tag for the unit with the given name.
<thumper> / It will panic if the given unit name is not valid.
<natefinch> trivia - the panic was added on the day I joined canonical (though not by me)
<thumper> :)
<thumper> magic
<natefinch> And yes, I am glad that the comment states it panics. That's at least better than blindsiding someone.
<thumper> boo yeah - have a panic
<thumper> not as nice as a picnic
<thumper> but close enough
<natefinch> ha
<axw> wallyworld: I really don't know what's up with the rsyslog bug. I can't reproduce it, and injecting errors into the rsyslog worker shows that it does recover from errors writing certs to state
<axw> wallyworld: rsyslog looks unhealthy in the env, because it's repeating machine-0's logs in all-machines.log
<wallyworld> axw: hmmm. mark as incomplete and ask for steps to repro? or access to an env with the problem so it can be investigated
<axw> wallyworld: ok
<wallyworld> ty for looking
<axw> menn0: what ever happened to the logging-in-state feature branch? is that still happening?
<menn0> axw: it's been merged for a long time
<menn0> axw: but it's still behind a feature flag
<axw> menn0: ah
<axw> menn0: any particular reason why it's not enabled by default?
<menn0> axw: it also gets activated if the "jes" feature flag is turned on
<axw> I see
<axw> menn0: so it will be soon then I guess?
<menn0> axw: to be honest, I don't know when
<axw> (on by default)
<axw> mk
<menn0> axw: some people had concerns about logging to mongodb
<menn0> axw: performance related mainly
<menn0> axw: let me bring it up on the list
<thumper> menn0: I don't think it is in 1.24 is it?
<wallyworld> axw: small corner case fix please http://reviews.vapour.ws/r/2955/
 * menn0 checks
<menn0> thumper, axw: it's in 1.25 but not 1.24
<menn0> there's bits of it there in 1.24 but it wasn't complete nor wired in at that stage
<axw> menn0: ok. was mainly just curious what the plan was for enabling it
<axw> thanks
<menn0> axw: I'll email the list about getting it turned on by default for 1.26
<natefinch> menn0: do we need the EnvUUID field in new mongo docs?  William said in a review that he thought we didn't, but to check with you.
<menn0> natefinch: no they're not necessary any more
<menn0> the multi-env DB layer will automatically add them
<menn0> I have a personal tech debt item to go and remove them from all our structs (and all the place they're set)
<menn0> even if a document struct has an EnvUUID field you can just leave out setting it in the code that creates them
<menn0> it'll still get added
<menn0>  /populated
<natefinch> menn0: thanks
<menn0> natefinch: np
<menn0> natefinch: let me know if you find that any aspect of this doesn't work how I've just described
<natefinch> menn0: will do
<wallyworld> axw: with the test it would be either a big cut and paste or a bit of refactoring all for a corner case where the method being used is tested extensively elsewhere. i can do it if you insist :-)
<wallyworld> axw: another small one sorry http://reviews.vapour.ws/r/2956/
<frobware> dimitern, running 10 mins late...
<dimitern> frobware, that's ok, I'm finishing my HW list here, will join ~5m
<dooferlad> dimitern: hangout?
<dimitern> omw
<voidspace> dimitern: frobware: I see that AWS "space discovery" is still listed as a deliverable, even after our conversation with William last week when we said it shouldn't be done
<dimitern> voidspace, that depends on "shared spaces by default" or not
<voidspace> dimitern: yes, and the agreement in discussion with fwreade was that we should *not* do shared spaces by default
<voidspace> dimitern: because of the unnecessary pain that it brings
<dimitern> voidspace, I know, but that's not approved yet by jam or rick
<dimitern> voidspace, I'd like it if we don't share by default, but mark seemed keen on the idea
<voidspace> dimitern: listing it as a deliverable seems like a bad idea (very)
<voidspace> you're boxing us into a corner
<dimitern> voidspace, even if we go with "not shared by default", there is still value in having discover + filters
<voidspace> dimitern: how is discover different from list then?
<dimitern> voidspace, discover lists spaces which are pre-existing on the cloud, but not yet known to (or usable by) juju
<voidspace> dimitern: but if you don't have shared spaces then there won't be pre-existing spaces
<dimitern> voidspace, i.e. you can import these (idempotently)
<voidspace> because as soon as you can share spaces (import them) then the can of worms is open
<voidspace> and you can't delete / rename them or move subnets
<dimitern> voidspace, well, "not sharing by default" does not exclude "being able to share spaces at all"
<voidspace> which is why we agreed not to do it
<dimitern> voidspace, how about openstack, azure?
<dimitern> voidspace, for maas "shared by default" and "no creation" is clear
<voidspace> dimitern: I'm talking about AWSD
<voidspace> *AWS
<mup> Bug #1508392 opened: Clearer error message when servicename instead of unitname <juju-core:New> <https://launchpad.net/bugs/1508392>
<voidspace> you have listed space discovery as a 16.04 deliverable for AWS, despite discussion with fwreade saying we shouldn't do it
<dimitern> voidspace, we have to do auto-discovery at bootstrap to figure out where to put the apiserver, and to allow bootstrapping into a space
<voidspace> dimitern: not if we don't have shared spaces
<voidspace> dimitern: because there won't be a pre-existing space, so we'll create the necessary infrastructure at bootstrap
<voidspace> dimitern: it *does* mean we don't have feature parity between AWS / MAAS for spaces
<dimitern> voidspace, that's one of the options
<dimitern> voidspace, let's have a call with jam about this, ideally also with rick
<dimitern> frobware, ^^ ?
<dimitern> we need to clarify this ASAP
<voidspace> heh
<jam> dimitern: voidspace: if the user has to set up the spaces in order for anything to work at all (which they do today), then it seems to make sense to discover them without having to have a bunch of steps. I don't think it is a prereq for January, though.
<dimitern> jam, not for jan, we're discussing later, until 16.04
<voidspace> jam: they set them up through juju
<voidspace> jam: so they don't have to set them up in EC2 as a pre-requisite
<voidspace> jam: they only configure them through juju
<voidspace> jam: having spaces discoverable (i.e. potentially shareable between environments) means that you can't safely delete or rename a space (can't fix typos) and you can't delete subnets or move them between spaces (so you have to assign a subnet to a space at subnet creation)
<voidspace> jam: all of which is a horrible UX
<voidspace> jam: not to mention that if you have different teams sharing a substrate (amazon account) with different environments they will see each others spaces
<jam> voidspace: if you have different teams sharing an amazon account you see everyone's stuff anyway
<jam> hence the *shared account*
<voidspace> jam: and old spaces/subnets from old environments will hang around for ever
<voidspace> jam: not with juju - you just see your environment
<voidspace> jam: a much better model, both for implementation and for UX, is private (to the environment) spaces by default, with explicitly global spaces for sharing
<voidspace> jam: with the added benefit that "explicitly global" doesn't need to be done initially (yay scope reduction) and can be added later
<jam> voidspace: so I wouldn't focus too much on things beyond January at this point, but I'd also note that if we aren't handling routing between subnets, etc, then the user still has to go to the console to do anything.
<jam> I do agree with some of your points about shared-on-request
<voidspace> jam: dimitern: the strongest argument for not promising it is that if we don't do it we can always add it - but as soon as we add it we have to support it for ever
<voidspace> jam: dimitern: so really, let's not promise it or do it until we're clear about the implications
<voidspace> jam: (it's currently listed as a 16.04 deliverable in the draft doc - which is why I'm bringing it up now)
<dimitern> frobware, voidspace, jam, I agree to drop it, but it should be replaced with an entry about modeling the shared (global/local) aspect of spaces/subnet and how does it affect the CLI commands
<dimitern> (i.e. make sure we can do it later properly)
<voidspace> well yes we should document what we do...
<TheMue> dimitern: backported latest doc changes to 1.25, mind a quick look at http://reviews.vapour.ws/r/2961/ ? thx
<dimitern> TheMue, sure, will do shortly
<TheMue> dimitern: great
<mup> Bug #1508498 opened: JUJU bootstrap fails first time every time <juju-core:New> <https://launchpad.net/bugs/1508498>
<mup> Bug #1508498 changed: JUJU bootstrap fails first time every time <juju-core:New> <https://launchpad.net/bugs/1508498>
<dimitern> TheMue, reviewed
<dimitern> sorry it took so long
<TheMue> dimitern: thx
<mup> Bug #1508498 opened: JUJU bootstrap fails first time every time <juju-core:New> <https://launchpad.net/bugs/1508498>
<alexisb> wwitzel3, can you refresh my memory on what is happening the first week of feb w/ the eco team
<alexisb> I see your travel request
<rick_h_> alexisb: fosdem charmers summit party time!
<katco> alexisb: the 1st rule of charmers summit is you talk about charmers summit ALL THE TIME.
<marcoceppi> ALL THE TIME EVERYWHERE
<wwitzel3> lol
<katco> woo woo
<mgz> fosdem fosdem
<katco> hypetrain
<wwitzel3> do I even need to say anything at this point?
<alexisb> :)
<marcoceppi> fosdem, cfgmgmtcamp, and http://summit.juju.solutions
<rick_h_> wwitzel3: jsut 'pretty please'? :P
<wwitzel3> rick_h_: :)
<alexisb> wwitzel3, seems I am a good spot to ask for bribes ;)
<wwitzel3> alexisb: haha
<voidspace> frobware: so I've done a 1.22 -> 1.24 upgrade with ignore-machine-addresses=true and failed to reproduce that issue
<voidspace> frobware: trying some other configurations
<katco> ericsnow: natefinch: wwitzel3: http://reviews.vapour.ws/r/2963/
<natefinch> katco: are those first two tests going to compile?
<katco> natefinch: tests run
<natefinch> katco: workload.Info doesn't ahve a Workload field anymore, does it?
<wwitzel3> katco: looking
<katco> natefinch: hm. no it does not
<katco> natefinch: doh... didn't run those tests
<natefinch> katco: oh good, I was hoping this wasn't some wacky like embedding thing where it works both ways
<sinzui> cherylj: bug 1465317 just came up in #ubuntu-devel. Ubuntu just learned about series X and the dep8 tests failed. They have fixed a test to avoid the panic, but they are nontheless concerned about Juju's insistence on knowing every version of every OS.
<mup> Bug #1465317: Wily osx win: panic: osVersion reported an error: Could not determine series <osx> <packaging> <wily> <windows> <juju-core:In Progress by dave-cheney> <juju-core 1.24:Triaged> <juju-core 1.25:Triaged> <juju-release-tools:Fix Released by sinzui> <https://launchpad.net/bugs/1465317>
<cherylj> sinzui: I was just looking at that bug.  I see that it's in progress, but I'm not convinced that dave is actually working it.
<cherylj> I asked for an update, but I'll also talk with him directly in the onyx standup today
<katco> ericsnow: natefinch: wwitzel3: updatedf
<sinzui> cherylj: I saw. I think we really need the issue to be fixed in 1.26. I think 1.25.1 is nice to have, I think all the next OS upgrades will involve 1.26 being the new stable
<cherylj> sinzui: sounds reasonable.
<mup> Bug #1508498 changed: JUJU bootstrap fails first time every time <adoption> <charmers> <cpp> <juju-core:New> <https://launchpad.net/bugs/1508498>
<katco> yeeeeesssss: https://github.com/rmuslimov/jenkins.el
<mup> Bug #1508498 opened: JUJU bootstrap fails first time every time <adoption> <charmers> <cpp> <juju-core:New> <https://launchpad.net/bugs/1508498>
<mup> Bug #1508498 changed: JUJU bootstrap fails first time every time <adoption> <charmers> <cpp> <juju-core:New> <https://launchpad.net/bugs/1508498>
<mup> Bug #1508498 opened: JUJU bootstrap fails first time every time <adoption> <charmers> <cpp> <juju-core:New> <https://launchpad.net/bugs/1508498>
<mup> Bug #1508498 changed: JUJU bootstrap fails first time every time <adoption> <charmers> <cpp> <juju-core:New> <https://launchpad.net/bugs/1508498>
<marcoceppi> mup: calm down
<mup> marcoceppi: Excuse moi, parlez vous anglais?
<marcoceppi> okay who made mup sassy
<wwitzel3> katco: lol .. isn't there a bootloader for emacs? just switch already
<katco> wwitzel3: lol i think there is
<wwitzel3> there are instructions for making it pid 1
<wwitzel3> good enough
<katco> wwitzel3: i know you can make it your wm
<lazypower> the day fun died and emacs won
<wwitzel3> katco: heh, for an editor no one uses there sure are a lot of plugins and extensions for it
<cherylj> sinzui: I was just about to ask you if that juju-local packaging bug should be sent to lxc.  You're too quick!
<katco> wwitzel3: maybe more people use it than people think :)
<cherylj> :)
<katco> wwitzel3: semi-complete list: https://melpa.org/#/
<sinzui> cherylj: :) I was helping the user in another channel
<cherylj> ah!
<wwitzel3> all those packages just for katco
<katco> haha
<katco> wwitzel3: 70k+ downloads... you should try it out (whistles) https://melpa.org/#/evil
<natefinch> katco: http://reviews.vapour.ws/r/2814/  all tests passing
<katco> natefinch: tal
<jamesmillerio>   wwitzel3: Kind of random, but I think I just realized I actually know you based on your handle, hah
<jamesmillerio> kind of crazy
<sinzui> cherylj: I just reported bug 1508585 which is the cause the failure of the current test of 1.25
<mup> Bug #1508585: TestUploadedToolsMetadata fails on windows and centos <blocker> <centos> <ci> <regression> <test-failure> <unit-tests> <windows> <juju-core:Incomplete> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1508585>
<mup> Bug #1508585 opened: TestUploadedToolsMetadata fails on windows and centos <blocker> <centos> <ci> <regression> <test-failure> <unit-tests> <windows> <juju-core:Incomplete> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1508585>
<cherylj> thanks for the heads up, sinzui
<mup> Bug #1508585 changed: TestUploadedToolsMetadata fails on windows and centos <blocker> <centos> <ci> <regression> <test-failure> <unit-tests> <windows> <juju-core:Incomplete> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1508585>
<mup> Bug #1508585 opened: TestUploadedToolsMetadata fails on windows and centos <blocker> <centos> <ci> <regression> <test-failure> <unit-tests> <windows> <juju-core:Incomplete> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1508585>
<wwitzel3> jamesmillerio: yeah?
<jamesmillerio> wwitzel3: yeah, you're Laura Tripletts friend and Jessa's husband, right?
<wwitzel3> jamesmillerio: ahh, yeah, I know you and your wife :)
<jamesmillerio> Niceeee, yep. I saw your wedding pictures go over my FB feed a few days ago so your name was fresh in my head. Saw you in here and there are only so many witzel's out there, haha.
<katco> i am fairly certain that wwitzel3 is actually a golden retriever who has no idea what he's doing.
<katco> like 20% sure.
<wwitzel3> 20% seems low
<katco> well. i'm also unsure of what i'm doing.
<wwitzel3> I'm 100% sure that I'm unsure
<wwitzel3> ;)
<katco> i... uh... i... yeah.
<katco> maybe.
<mup> Bug #1508595 opened: revisit use of networks in AddService code <tech-debt> <juju-core:New> <https://launchpad.net/bugs/1508595>
<natefinch> katco: so.... now what?
<natefinch> katco: what can I do to help with our demos, now that we've finally reached a more or less stopping point for this bug?
<katco> natefinch: wwitzel3: ping, you need help with lxd?
<thumper> can I add any surity?
<thumper> but I know I don't know what you are doing
<katco> thumper: surity?
<thumper> sureity?
<natefinch> sureitude
<thumper> damn english
<katco> thumper: lol
<thumper> sureness
<katco> thumper: no i don't think so, just trying to find the next best thing for nate to work on
<katco> natefinch: you could start working on feature tests for payloads
<natefinch> katco: I can do that.
<natefinch> katco: I'll start working on that tonight.
<katco> natefinch: kk
<natefinch> gotta run, back in a while
<cherylj> can I get a review for the 1.25 blocker?  http://reviews.vapour.ws/r/2965/
<katco> cherylj: lgtm
<cherylj> katco: thanks!
<wwitzel3> katco: you got a shipit
<katco> wwitzel3: ty. 1.25 is blocked atm
<perrito666> can anyone thing a way to check the size of all collections on a mongo db?
<perrito666> thumper: seems that you are not the only one thinking the way you do about english http://img-9gag-fun.9cache.com/photo/aDmPrnO_700b.jpg
<alexisb> anastasiamac, cherylj I will be late
<anastasiamac> alexisb: k :) we r there
<menn0> wallyworld: ping
<wallyworld> menn0: sorry, in standup, give me 5
<menn0> wallyworld: no rush
#juju-dev 2015-10-22
<wallyworld> menn0: sorry, free now
<menn0> wallyworld_: sorry, I didn't see you
<wallyworld_> np
<menn0> wallyworld_: I was wanting to know about how tools are stored in the controller
<wallyworld_> sure, maybe a hangout
<menn0> wallyworld_: ok cool
<wallyworld_> https://plus.google.com/hangouts/_/canonical.com/tanzanite-stand
<menn0> wallyworld_: i'm there now
<wallyworld_> me too
<wallyworld_> hmmm
<thumper> here is a personal itch being scratched: http://reviews.vapour.ws/r/2970/
<thumper> menn0 ^^
<menn0> thumper: i'm looking
<thumper> menn0: and the related juju branch http://reviews.vapour.ws/r/2971/
<menn0> thumper: looks cool. so in the case of Juju there would be a single well known location for the aliases file that people could monkey with?
<thumper> menn0: and it works surprisingly well :)
<thumper> menn0: see the second one :)
<thumper> menn0: my testing file: http://paste.ubuntu.com/12891561/
<thumper> well, not testing, but the one I started hacking up
<menn0> thumper: it's cool! I guess we can acheive almost the same thing with shell aliases but the level of integration is better with your PR
<thumper> menn0: I expect to create an aliases command at some stage...
<thumper> like I did with 'bzr alias'
<thumper> to add and remove aliases from the file through the CLI
<thumper> the command could be automagically added by the supercommand if it has been registered with an alias file location
<menn0> thumper: yep that would be nice
<thumper> the interesting bit would be attempting to keep some stability in the file structure
<thumper> so we don't lose user comments or whitespace
<thumper> that'd be easy enough :)
<thumper> but later
<rick_h_> menn0: ping, got time to chat on these comments?
<menn0> rick_h_: sure. I wanted to set up a call to get the spec sorted more quickly. now is good too though
<rick_h_> menn0: cool
<rick_h_> menn0: https://plus.google.com/hangouts/_/canonical.com/rick?authuser=1 *adjust authuser*
 * thumper is done
<thumper> laters
<wallyworld> axw: small one if you have a moment http://reviews.vapour.ws/r/2972/
<axw> wallyworld: sure, soon as bootstrap stops flooding my connection
<wallyworld> no rush
<axw> wallyworld: why not just log it in APIHostPortsSetter.SetAPIHostPorts? rather than sending the results all the way back up only to be logged
<wallyworld> yeah, probably should have
<wallyworld> was logging where the original was done
<wallyworld> i'll change it
<axw> wallyworld: thanks
<wallyworld> axw: well that's much simpler. sigh. so stupid
<axw> wallyworld: cool :)
<axw> looking
<axw> wallyworld: LGTM
<wallyworld> ta
<fwereade> waigani, ping
<fwereade> (and menn0 if you're around as well)
<menn0> fwereade: i happen to be around
<fwereade> waigani, menn0: I think it comes down to "why can't we destroy a system when it's hosting environments?"
<waigani> fwereade: beacuse we have a txn assert that doesn't allow this
<waigani> fwereade: are you asiking why don't we remove the assert?
<menn0> fwereade: because if the system goes the API server goes and we don't want the API server to go before the other envs are gone
<fwereade> waigani, or at least make it conditional?
<fwereade> menn0, that's the purpose of dying/dead
<fwereade> menn0, you stay dying while you clean up
<menn0> fwereade: i was guessing somewhat
<fwereade> menn0, waigani: once the things that depend on you have gone away, you can become dead, and get cleaned up
<waigani> fwereade: what if one of the environs fails to be cleaned up?
<waigani> how do we back out?
<fwereade> waigani, then the system stays dying, that env stays dying, and hopefully we report what's happpening
<fwereade> waigani, we don't
<waigani> okay
<waigani> fwereade: when you say make it conditional...
<fwereade> waigani, (am I missing something? what can/should we back out if one env won't die?)
<menn0> fwereade: FTR i'm going to need some kind of environment mode for environment migration
<menn0> fwereade: I was thinking we could use the same mode
<menn0> field
<menn0> (the field is currently called migration-mode in the spec though)
<fwereade> waigani, re conditional, I mean that we have two use cases -- destroy-if-empty and destroy-with-contents, if you like
<fwereade> waigani, it doesn't particularly phase me to have those two cases differ by one assert
<fwereade> menn0, it feels to me like they're very different
<fwereade> menn0, no argument against migration-mode
<waigani> right so we have two destroy paths, one asserting no envs, the other without the assert
<waigani> fwereade: ^?
<menn0> fwereade: agreed. although some of the modes will also need to block the same kinds of transactions.
<fwereade> waigani, yeah, I think one of them is set-dying-if-refcount-0 and the other is just set-dying
<waigani> okay. That will also solve the problem for me.
<waigani> as to backing out, as long as we can handle the situation of several envs in different states of life with a dying system that's fine
<fwereade> menn0, expand a bit please?
<waigani> oh no wait
<menn0> fwereade: one example is when an environment is being migrated out of an environment we want to block provisioning of resources for it
<menn0> fwereade: I guess that could/will also be done at the API server level
<fwereade> menn0, I almost think it has to be?
<waigani> sorry, typing out loud. So my original consern was the same as menno's above. That if we set the system to dying first, we could get zombie resources.
<fwereade> waigani, IMO not if we do it properly?
<fwereade> waigani, from my perspective "dying" literally means "the user asked us to destroy this"
<waigani> fwereade: right, so a dying system should be considered just as reliable as an alive one, you just can't provision new resources?
<menn0> fwereade: i'm definitely planning to lock down the API for the environment during migration.
<menn0> fwereade: I had it in my head that we'd also do it at the txn level
<fwereade> waigani, yeah, certain changes to dying entities are no longer appropriate, but generally they should continue to function
<menn0> fwereade: but that's probably overkill
<fwereade> menn0, I *think* that if we've got a solid apiserver-level block then nothing else will be touching state and we're safe
<fwereade> menn0, so long as we do a resume-all
<menn0> fwereade: there's also the added protection migrations aborting early if anything is provisioning when the migration is initiated
<fwereade> menn0, right, I'm not strongly against some txn-level mechanism to protect migrations
<waigani> fwereade: so just to be clear, we then don't care about the race in the case where we're destroying the system and any environs. I.e. someone adds an env as I destroy everything - that env also gets a bullet?
<menn0> fwereade: by resume-all you mean a mgo/txn Runner.ResumeAll?
<fwereade> menn0, yeah
<fwereade> waigani, I think so, yes
<fwereade> waigani, races where someone wins aren't such a worry, it's races that leave us inconsistent that keep me up at night
<waigani> hmm.. right I see
<fwereade> waigani, eg an alive system that's quietly nuking all its tenants, or a dying system accepting new ones
<waigani> lol, fair enough, I see the difference
<waigani> okay I'm happy, I can move forward with this. What should we do with the environ mode branch? Still useful for migration?
<menn0> fwereade: just to be clear, you're suggesting a ResumeAll just after the API gets locked down?
<fwereade> menn0, yes, I think we need that -- right?
<fwereade> waigani, might well be, menn0 will be able  to answer more clearly there
<menn0> waigani: yep, please keep it. we can use much of it when adding the migration-mode field
<waigani> okay cool, will do
<menn0> fwereade: yes I think so. just making sure we're on the same page.
<fwereade> menn0, I *think* we'd want the ResumeAll, wouldn't we? migration is going to write some docs, and we don't want it picking up incomplete transactions from before
<fwereade> cool
<menn0> yep that makes sense
<menn0> I hadn't consider that yet but it makes sense
<menn0> otherwise something could start changing the env when we thought it was stable
<menn0> wallyworld: re the API address logging change
<menn0> wallyworld: I noticed you did exactly the same thing which I thought of during dinner :)
<menn0> wallyworld: just log the addresses inside SetAPIHostPorts
<menn0> much simpler
<dooferlad> dimitern, jam, fwereade, TheMue, voidspace: hangout time!
<TheMue> dooferlad: ouch, thx, omw
<dimitern> dooferlad, omw
<jam> omw
<voidspace> dooferlad: omw
<dooferlad> dimitern, frobware, voidspace: hangout time!
<fwereade> jam, also ^
<dimitern> ooh.. forgot about that one, omw
<voidspace> frobware: actually I might be able to reproduce the "machine agent never upgrades" problem - going from 1.20 to 1.24.6
<voidspace> frobware: going to see if it really is reproducable (but with debug logging on)
<voidspace> and if it happens with 1.24.7
<frobware> voidspace, did you use deploy different charms this time?
<voidspace> frobware: nope, not sure what was different
<frobware> voidspace, timing related? <shrug>?
<voidspace> frobware: in the last deploy (currently bootstrapping again) I saw machine-0 flatline at 100% CPU constant
<voidspace> frobware: and machine-1 never upgraded the agent
<voidspace> frobware: possibly
<voidspace> (possibly timing related I mean)
<voidspace> frobware: lots of errors in the logs, but nothing *useful*
<voidspace> frobware: so will repeat with debug logging on
<frobware> voidspace, dmesg - anything interesting in there? oom killer, et al?
<voidspace> frobware: ParseError
<voidspace> ah no
<voidspace> dmesg
<voidspace> I read that as "debug"
<voidspace> frobware: didn't look, will check next time
<voidspace> frobware: if they have lots of units there will be more load on the API server, so some symptoms maybe different
<frobware> right
<voidspace> frobware: ah, so this time the mysql/0 unit reports the newer version - but the *machine agent* is still reporting the older version
<voidspace> frobware: no 100% CPU usage this time
<voidspace> frobware: maybe it did happen before and I just missed it (seeing the unit agent with the upgraded version)
<voidspace> frobware: I'll spelunk the logs and see what I can work out
<alexisb> dimitern, frobware pint
<alexisb> pin
<alexisb> ping
<frobware> alexisb, I'll take your first offer. :)
<alexisb> lol
<alexisb> 6am and look where my mind goes, scary
<alexisb> frobware, can you and dimiter jump on a hangout?
<frobware> alexisb, sure
<alexisb> I want to chat about hardware so we can get things rolling
<frobware> alexisb, ah I just started a doc on that
<alexisb> https://plus.google.com/hangouts/_/canonical.com/andy-alexis
<dimitern> alexisb, hey, in a call, bbiab
<mup> Bug #1508923 opened: Support for Azure Resource Groups <juju-core:New> <https://launchpad.net/bugs/1508923>
<alexisb> dimitern, frobware and I chatted you are all good he has it handled
<dimitern> alexisb, awesome!
<frobware> dooferlad, ping - can we HO for a bit regarding your current h/w
<dooferlad> frobware: sure
<frobware> dooferlad, let's use the standup HO
<mup> Bug #1500760 changed: all juju subcommands need to respect -e env-name flag <network> <usability> <juju-core:Triaged> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1500760>
<frobware> voidspace, dimitern: see my recent doc invite regarding h/w - would appreciate if you could fill out your sections so that we can complete today and send to rick, et al.
<voidspace> frobware: ok
<frobware> voidspace, thx
<natefinch> fwereade: (or anyone else) anyone know why my worker would be dying with permission denied constantly?  Looks like it's the watcher returning an error on Next
<natefinch> - http://pastebin.ubuntu.com/12894707/
<rogpeppe> jam: ping
<rogpeppe> natefinch: do you know what the status is re: merging feature branches?
<natefinch> rogpeppe: no idea
<rogpeppe> natefinch: any idea who might know?
<frobware> voidspace, do you have additional h/w requirements - I noticed you left that section empty, so just double-checking...
<voidspace> frobware: well, we don't know yet do we - we haven't specced what we'll need for a sufficient dev environment
<frobware> voidspace, james and dimitern are basing it on 4 machines, per the bundle spec
<voidspace> "The openstack-base bundle indicates that 4 machines are required, each with two NICs and 2 disks however it is questionable whether developers will initially need to deploy the full bundle"
<voidspace> frobware: if we need the full spec, I'll need two NIC cards, 2 more disks, plus two more machines
<natefinch> katco: what's the process for merging feature branches?  rogpeppe is asking
<frobware> voidspace, OK, maybe that needs more explanation. For networking I don't think we would need 2 disks.
<katco> natefinch: $$merge$$
<voidspace> frobware: but we'll need the four machines?
<rogpeppe> katco: so it's ok to merge a feature branch at any time, assuming it's blessed?
<voidspace> frobware: my requirements are basically identical to dooferlad
<katco> rogpeppe: yes, as long as tip of branch is blessed
<voidspace> frobware: as my existing hardware is very similar in spec
<frobware> voidspace, I say yes.
<rogpeppe> katco: great!
<frobware> voidspace, beware that is NUCs are not AMT, so you would need some kind of PDU to power on/off.
<frobware> s/is/his
<voidspace> frobware: I have a PDU
<frobware> voidspace, viola!
<voidspace> frobware: but the existing hardware table only had space for machines... :-)
<voidspace> frobware: so that's cool
<frobware> voidspace, bleh
<voidspace> frobware: I assumed it was on purpose :-)
<frobware> voidspace, feel free to add more characters :)
<frobware> voidspace, spec and buy what we believe we will need to deliver
<frobware> voidspace, thx for the update; this is a strawman proposal anyway - just wanted to get the ball rolling today
<voidspace> frobware: so far - one in three upgrades to 1.24.6 have succeeded
<voidspace> frobware: one in one upgrades to 1.24.7 have succeeded
<voidspace> trying again with 1.24.7
<frobware> voidspace, interesting
<voidspace> I also have debug logs from a failed one
<voidspace> (by failed I mean that machine agent stayed on 1.20 - everything still *appeared* to work.)
<voidspace> yeah, weird
<voidspace> frobware: and will be tricky if it's actually a bug in 1.20
<frobware> voidspace, ian mentioned that they had tried 1.24.7 in the RT ticket but I didn't see any mention of that explicitly in the bug
<voidspace> frobware: not in that original report definitely
<frobware> voidspace, he mentioned it in passing, but again, worth confirming.
<voidspace> frobware: looking at the rt now
<voidspace> Ah, Peter has tried 1.24.7
<voidspace> he has logs
<voidspace> perrito666: ping
<perrito666> voidspace: pong
<voidspace> perrito666: are you still looking at bug 1507867
<mup> Bug #1507867: juju upgrade failures <canonical-bootstack> <upgrade-juju> <juju-core:Triaged> <https://launchpad.net/bugs/1507867>
<voidspace> perrito666: the failed upgrade rt?
<perrito666> voidspace: I am, I did forget to own it this am
<perrito666> voidspace: do you have anything to add to it?
<voidspace> perrito666: cool
<voidspace> perrito666: not really, I can reproduce an issue - when I upgrade from 1.20 to 1.24 *most* of the time (but not always) the machine agent fails to upgrade version
<voidspace> perrito666: the unit agent reports the correct new version, but not the machine agent
<voidspace> perrito666: however, I can't reproduce the bug as described (missing address or corrupted db)
<voidspace> perrito666: this is with a deployed mongo unit and ignore-machine-addresses on
<perrito666> voidspace: maybe you can help me a bit, from reading at the logs, It seems to me that the juju binary in use is in fact the old one
<voidspace> perrito666: it would be weird for the machine agent and unit agent to be from different binaries
<voidspace> but that's what status is reporting
<perrito666> errors in the logs correspond to older versions than the one supposedly running
<perrito666> voidspace: do you have that env running?
<voidspace> perrito666: no, my *current* env succeeded
<voidspace> perrito666: I'll redo it (takes about 15 - 20 mins) and *usually* fails
<voidspace> perrito666: I'll report back shortly
<perrito666> voidspace: appreciated
<perrito666> a ps faux will shed some light
<ericsnow> katco, natefinch, wwitzel3: ptal http://reviews.vapour.ws/r/2930/
<wwitzel3> ericsnow: looking
<ericsnow> wwitzel3: ta
<cherylj> sinzui, mgz, have we done long jump upgrade tests from 1.18.* to 1.24.7?
<sinzui> cherylj: no, it isn't possible, go to 1.20, then to 1.24.
<cherylj> sinzui: is 1.18->1.22->1.24 ok?
<sinzui> cherylj: I don't have my table about, but I don't think 1.18 will accept anything but 1.20.x
<sinzui> cherylj: if I wasn't busy I would just reply the upgrade tests
<sinzui> upgrade steps
<cherylj> sinzui: np, I can get with you a bit later on it
<perrito666> voidspace: any news?
<perrito666> sinzui: I am a bit confused on why this bug https://bugs.launchpad.net/juju-core/+bug/1497301 is in the top list of 1.25 http://reports.vapour.ws/releases/top-issues?_charset_=UTF-8&__formid__=deform&previous_days=7&issue_count=20&update=update#1.25
<mup> Bug #1497301: mongodb3  SASL authentication failure <ci> <mongodb> <regression> <unit-tests> <juju-core:Triaged> <https://launchpad.net/bugs/1497301>
<sinzui> perrito666: the bug happens so often in the single test we run that it dominates the count of bug frequency
<perrito666> sinzui: but mongodb3?
<perrito666> I have this sensation that I missed something
<sinzui> perrito666: http://reports.vapour.ws/releases/issue/55fc1a67749a5674698af639 shows every occurrence. It just happens all the for run-unit-tests-mongodb3 job, which core asked us to test
<perrito666> this is on our feature branch?
<sinzui> perrito666:
<sinzui> perrito666: no. this test is run for every revision in every branch. The host we run the unit tests on has mongodb 3
<perrito666> ok, didn't know that :)
<sinzui> cherylj: bad news. Juju doesn't support 1.25.0 I think tests were written to keep juju version in devel. I will report the bug in a few minutes
<sinzui> cherylj: https://bugs.launchpad.net/juju-core/+bug/1509032 is super important for 1.25.0
<mup> Bug #1509032: Juju doesn't support is own version of 1.25.0 <ci> <test-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1509032>
<perrito666> voidspace: I need to relocate, if you get to reproduce the error please get me more info :)
<mup> Bug #1509032 opened: Juju doesn't support is own version of 1.25.0 <ci> <test-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1509032>
<cherylj> sinzui: looking
<cherylj> oh god, this is just a horribly wrong test
<cherylj> sinzui:  was that the only failing test?
<mup> Bug #1509032 changed: Juju doesn't support is own version of 1.25.0 <ci> <test-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1509032>
<sinzui> cherylj: The bug points to 2 other status tests that failed in my three tries. I don't see a 1.25.0 connection to the failures
<mgz> cherylj: see 5191 on jenkins github-merge-juju job
<cherylj> k
<sinzui> cherylj: mgz: http://ci-master.vapour.ws:8080/view/Juju%20Ecosystem/job/github-merge-juju/5192/consoleText is better because it isn't a victim of bad record mac
<cherylj> ah, thanks
<mgz> anywa, looks like three dreal failures, the one in the bug and two status tests with ahrd to read mismatches :)
<cherylj> okay, I'm going to handle the case of the state test failing.
<mup> Bug #1509032 opened: Juju doesn't support is own version of 1.25.0 <ci> <test-failure> <juju-core:Triaged by cherylj> <https://launchpad.net/bugs/1509032>
<cherylj> cmars, katco, can you volunteer someone to look at the status failures here:  http://ci-master.vapour.ws:8080/view/Juju%20Ecosystem/job/github-merge-juju/5192/consoleText
<mup> Bug #1509032 changed: Juju doesn't support is own version of 1.25.0 <ci> <test-failure> <juju-core:Triaged by cherylj> <https://launchpad.net/bugs/1509032>
<cherylj> wwitzel3, ericsnow, natefinch can one of you guys look at these failures?
<natefinch> cherylj: I can look
<cherylj> thanks, natefinch.  It's the status failures in this run:  http://ci-master.vapour.ws:8080/view/Juju%20Ecosystem/job/github-merge-juju/5192/consoleText
<mup> Bug #1509032 opened: Juju doesn't support is own version of 1.25.0 <ci> <test-failure> <juju-core:Triaged by cherylj> <https://launchpad.net/bugs/1509032>
<voidspace> perrito666: last couple of attempts to repro *failed* (i.e. the upgrade worked - failed to fail)
<voidspace> perrito666: and now I'm EOD and off out to Northants Geeks
<voidspace> perrito666: when I come back in I may try again as I can do it in front of the TV
<natefinch> who the hell writes tests that check 21 lines of textual output?
<natefinch> obtained: <wall of text>  expected: <wall of text>
<natefinch> thanks
<natefinch> cherylj: forgot I have to watch the kids while my wife takes my daughter to a doctor's appointment, so I'll be mostly afk for an hour and a half or so.
<cherylj> natefinch: ok, had you found anything yet to hand off?
<cherylj> omfg, it's a whitespace problem
<natefinch> cherylj: sounds like you found more than I did
<natefinch> cherylj: I was about to just diff the before and after on those statuses
<marcoceppi> hello
<marcoceppi> I ran juju ensure-availablility on AWS and now I can't connect to the api from the CLI
<natefinch> cherylj: ahh yeah I see it... the number of spaces after 1.25.1 in the status.  amazing.
<natefinch> cherylj: (still not really here ;)
<marcoceppi> http://paste.ubuntu.com/12896313/
<cherylj> natefinch-afk: no worries, I'm going to fix the status failures in the same patch.
<marcoceppi> db, jujud-machine-0 are both running on machine 0
<marcoceppi> I'll just ask on the list.
<cherylj> I need a review so we can move to 1.25.0:  http://reviews.vapour.ws/r/2977/
<cherylj> cmars, katco natefinch-afk wwitzel3 mgz ^^
<katco> cherylj: lgtm
<sinzui> cherylj: spaces broke the status test? ouch
<cherylj> sinzui: yeah, awesome.
<cherylj> sinzui: I sort of hacked it so that it won't break if the length of the current version changes again
<cherylj> but ideally, we'd fix that test.
<cherylj> perrito666: ping?
<perrito666> cherylj: pong
<cherylj> perrito666: good afternoon :)  Wanted to see if this was on your radar yet?  bug 1497301
<mup> Bug #1497301: mongodb3  SASL authentication failure <ci> <mongodb> <regression> <unit-tests> <juju-core:Triaged> <https://launchpad.net/bugs/1497301>
<perrito666> cherylj: it sort of is, I kind of just learned that we are testing that
<perrito666> I am not yet sure I understand what this is about
<cherylj> perrito666: have you run into it yourself?
<perrito666> sinzui: my branch still did not go trough? :(
<sinzui> cherylj: you got a bad record mac
<mgz> I resubmitted
<cherylj> I know :(
<mgz> and chery was faster anyway
<cherylj> I win!
<mgz> that particular flavour seems more common in the gating job of late
<sinzui> perrito666: I see your merge. https://github.com/juju/juju/commits/restore-fix we are waiting for 1.25.0 to exist We stopped CI so we could test is as soon as it existed
<mgz> cherylj: we presumably do want to target that bug against master as well, as the dodgy tests want fixing there too?
<cherylj> mgz: yes, I'm working on that now
<cherylj> but it wouldn't hit us until we move to 1.26.0
<sinzui> cherylj: Ci has started testing your revision
<cherylj> sinzui: yay!
<cherylj> sinzui: Is there any ballpark of when we can expect 1.25.0 in the ppa?
<sinzui> Tomorrow cherylj
 * cherylj sad panda
<cherylj> but so it goes...
<sinzui> cherylj: 3+ hours to test (and make release artifacts like real agents), then 3+ jourss to get the base debs created in the secret PPA., then 1.5 hours to publish to the CPCs, then 1.5+ hours to publish to streams.canonical.com, then 1h to copy to the public PPA.
<cherylj> sinzui: Oh I'm sure there's a lot that goes into it, it's just a shame that these bugs added to the delay
<sinzui> cherylj: we have no control over Lp or Jerff, so we can only hope we get immediate service
<cherylj> sinzui: what do you need from Jerff?  I can ask my office mate to help
<sinzui> cherylj: We queue the job that makes the agents for streams.canonical.com. We expect it to deliver betweek 15 and 45 minutes past the hour. Sometimes it is many hours because the machine is nusy
<cherylj> sinzui: I can have Rob manually trigger the job, rather than waiting the hour to pick it up
<cherylj> not that it helps a *whole* lot
<sinzui> cherylj: that is nice, I can ask in #cloudware too when it needs to happen quickly. Since the release process is a queue of steps building on eachother. there is nothing to ask for now
<cherylj> yeah
<mup> Bug #1509099 opened: juju does not error or warn when agent-stream is ignored <ci> <upgrade-juju> <juju-core:Triaged> <https://launchpad.net/bugs/1509099>
<perrito666> wallyworld: ping me when you are here
<mup> Bug #1509097 opened: Juju 1.24.6 -> 1.24.7, upgrade never finishes <kanban-cross-team> <landscape> <juju-core:New> <https://launchpad.net/bugs/1509097>
<alexisb> wallyworld, ping
<wallyworld> hey, just talking to horatio, give be 10?
<alexisb> wallyworld, np, when you are free
<alexisb> no rush
<cherylj> menn0: I got the syslog for that replicaset / EMPTYCONFIG bug if you want to take a look:  bug 1412621
<mup> Bug #1412621: replica set EMPTYCONFIG MAAS bootstrap <adoption> <bootstrap> <charmers> <cpec> <cpp> <maas-provider> <mongodb> <oil> <juju-core:Triaged> <juju-core 1.24:Triaged> <https://launchpad.net/bugs/1412621>
<menn0> cherylj: i've got a few errands to run right now but i'll take a look today
<wallyworld> alexisb: just finished but about to do standup, can you wait another 10 minutes or so?
<alexisb> geeze wallyworld
<alexisb> just keep pushing me off ;)
<alexisb> yes I will still be here in 10 minutes
<alexisb> but my info may be useful for your standup
<wallyworld> alexisb: oh, ok let's talk quikly now then
#juju-dev 2015-10-23
<wwitzel3> ericsnow: ping, you still around?
<ericsnow> wwitzel3: more or less ;)
<wwitzel3> ericsnow: our cat got bit by a dog so I had to run off to the vet for most of the day, but I'm back now if you want to hand off
<ericsnow> wwitzel3: sorry to hear that
<ericsnow> wwitzel3: cat okay?
<wwitzel3> ericsnow: she is well, yeah, couple set of stiches and a cone of shame
<ericsnow> wwitzel3: if you like, you can give my cleanup patch a once over: http://reviews.vapour.ws/r/2927/
<ericsnow> wwitzel3: ha, cone of shame
<wwitzel3> ericsnow: that diff seems to have a lot of stuff in it, is all of this part of the cleanup?
<ericsnow> wwitzel3: I have some comments for your LXD provider code, but that can wait until tomorrow :)
<ericsnow> wwitzel3: well, it was smaller before fwereade made a number of (reasonable) suggestions :)
<ericsnow> wwitzel3: but yeah, it really is that big
<ericsnow> wwitzel3: sorry
<ericsnow> wwitzel3: a *lot* of extra test coverage
<wwitzel3> ericsnow: what about all the stuff in apiserver/common/errors?
 * ericsnow checks
<ericsnow> wwitzel3: alas, yes
<mup> Bug #1507601 changed: TestStartTerminationWorker fails on gccgo <ci> <gccgo> <ppc64> <regression> <test-failure> <juju-core:Fix Released by gz> <juju-core 1.25:Fix Released by gz> <https://launchpad.net/bugs/1507601>
<mup> Bug #1507601 opened: TestStartTerminationWorker fails on gccgo <ci> <gccgo> <ppc64> <regression> <test-failure> <juju-core:Fix Released by gz> <juju-core 1.25:Fix Released by gz> <https://launchpad.net/bugs/1507601>
<mup> Bug #1507601 changed: TestStartTerminationWorker fails on gccgo <ci> <gccgo> <ppc64> <regression> <test-failure> <juju-core:Fix Released by gz> <juju-core 1.25:Fix Released by gz> <https://launchpad.net/bugs/1507601>
<sinzui> thumper: menn0 waigani wallyworld do either of you have a minute to review this for the release http://reviews.vapour.ws/r/2980/
<wallyworld> sinzui: lgtmandt
<sinzui> thank you wallyworld
<wallyworld> axw: be there in 1 minute
<axw> wallyworld: me too
<natefinch> lololol  -  juju-core's complimentary commercial subscription expires on 2015-11-22. Proprietary projects can use Launchpad by purchasing a commercial-use subscription which costs US$250/year/project.
<natefinch> somebody just broke something in launchpad
<thumper> davechen1y: ping
<cherylj> Can I get a review for http://reviews.vapour.ws/r/2981/ ?
 * thumper looks
 * thumper sighs
<thumper> clicked the wrong button again
 * thumper wanted the fix it and ship it button
<cherylj> oh blargh
<thumper> kids calling
<thumper> laters folks
<thumper> see y'all Tuesday (public holiday monday here)
<cherylj> wallyworld, axw could I get a sanity check on this revision:  http://reviews.vapour.ws/r/2981/
<cherylj> It's late and I don't want to mess things up again :)
<wallyworld> sure
<axw> cherylj: seems fine, although I'd probably just use a regex to match the whitespace
<wallyworld> cherylj: sorry, just got off the phone, what was the issue?
<wallyworld> oh, i see - version string length
<cherylj> axw: would you be willing to implement just using a regex?
<cherylj> it's midnight here and I really want to go to bed
<axw> cherylj: sure
<cherylj> thank you, axw.  This is for bug 1509032
<mup> Bug #1509032: Juju doesn't support is own version of 1.25.0 <ci> <test-failure> <juju-core:In Progress by cherylj> <juju-core 1.25:In Progress by cherylj> <https://launchpad.net/bugs/1509032>
<wallyworld> or even just strip the trailing spaces
<axw> cherylj: not clear how I trigger the failure?
<cherylj> set juju/juju/version/version.go, const version = "1.25.1"
<cherylj> you have to be on 1.25 and get my latest commits from today
<axw> cherylj: I see, thanks
<axw> wallyworld: if you have a moment, http://reviews.vapour.ws/r/2982/
<wallyworld> sure
<wallyworld> axw: yup, +1
<rogpeppe> dimitern: ping
<rogpeppe> anyone around to do a very quick (and urgently needed) review?
<rogpeppe> http://reviews.vapour.ws/r/2983/
<dimitern> rogpeppe, sure, looking
<rogpeppe> dimitern: thanks!
<rogpeppe> dimitern: (FWIW it follows the exact same pattern used in the other providers)
<dimitern> rogpeppe, ship it! :)
<dimitern> cherylj, any chance you're still around?
<wallyworld> dimitern: hey there, do you have time for a chat?
<dimitern> wallyworld, I do
<wallyworld> https://plus.google.com/hangouts/_/canonical.com/tanzanite-stand
<dimitern> wallyworld, omw
<voidspace> dimitern: standup?
<dimitern> omw
<dimitern> fwereade, joining standup?
<voidspace> wallyworld: ping
<voidspace> axw: ping
<wallyworld> hey
<voidspace> wallyworld: hey
<voidspace> wallyworld: the broken upgrade issue
<wallyworld> that old thing
<voidspace> wallyworld: we've worked out that *part* of the problem is that "ignore-machine-addresses" is broken for lxc containers
<voidspace> wallyworld: and there's an easy fix (we think)
<voidspace> wallyworld: so I'll create a new bug for that specifically and work on it
<wallyworld> ok
<voidspace> lxc containers *only* have machine addresses, so ignoring them is bad...
<wallyworld> yeah, containers don't have provider addresses
<voidspace> I've added a note to the main launchpad bug about this
<voidspace> just keeping you up to date
<wallyworld> yay for easy fix - get 1.24 and 1.25 working and fix 1.26 "properly"
<wallyworld> thanks for update, much appreciated
<voidspace> I'll add a reply to the rt too
<wallyworld> ty
<mup> Bug #1509292 opened: "ignore-machine-addresses" broken for containers <juju-core:In Progress by mfoord> <juju-core 1.24:In Progress by mfoord> <juju-core 1.25:In Progress by mfoord> <https://launchpad.net/bugs/1509292>
<mup> Bug #1509292 changed: "ignore-machine-addresses" broken for containers <juju-core:In Progress by mfoord> <juju-core 1.24:In Progress by mfoord> <juju-core 1.25:In Progress by mfoord> <https://launchpad.net/bugs/1509292>
<mup> Bug #1509292 opened: "ignore-machine-addresses" broken for containers <juju-core:In Progress by mfoord> <juju-core 1.24:In Progress by mfoord> <juju-core 1.25:In Progress by mfoord> <https://launchpad.net/bugs/1509292>
<dimitern> frobware, I think jam's comment on deploy time bindings just made my day :)
<voidspace> dimitern: how do I get "juju upgrade-juju --upload-tools" to work?
<voidspace> dimitern: http://pastebin.ubuntu.com/12901704/
<frobware> dimitern, need to work out why I don't get any doc notifications
<voidspace> dimitern: client is my new version, server is 1.20.14
<dimitern> frobware, not actually implementing (but speccing properly) the "connects" side of the metadata, will save good 2 to 3 weeks of work before jan
<dimitern> voidspace, so this is coming from the apiserver I guess? try with --debug?
<dimitern> voidspace, if that's the case, try $ juju upgrade-juju --upload-tools --series trusty
<voidspace> dimitern: http://pastebin.ubuntu.com/12901718/
<dimitern> this tells me you're on wily
<voidspace> dimitern: tried that already, --series is ignored
<voidspace> I'm really not
<dimitern> oh ffs..
<voidspace> 15.04
<dimitern> voidspace, juju status | grep agent-version ?
<voidspace> we need to solve this so peter can try the new binaries (let alone actually testing it ourselves)
<dimitern> agreed
<voidspace> 1.20.14.1
<dimitern> hmm
<dimitern> so where's wily coming from then
<voidspace> presumably simplestreams
<voidspace> where else could it come from
<dimitern> it could be hardcoded
<dimitern> in the client
<voidspace> ah right
<dimitern> most likely, as 1.20 was pre-vivid, right? and it's not complaining about it
<voidspace> indeed, if I set the tools-url to something invalid I still get the same error
<voidspace> so it must come from the client
<voidspace> well, no - if I grep our codebase for wily it doesn't appear
<voidspace> we must have a series list that the server checks
<dimitern> we have indeed - version/supportedseries.gho
<voidspace> yeah, just found it
<voidspace> dimitern: and wily isn't in seriesVersions
<dimitern> just try adding "wily" to ubuntuSeries map rebuild and retry
<voidspace> dimitern: let me try adding it there
<dimitern> :)
<dimitern> voidspace, and if that works we should give both juju and jujud in the tarball for peter
<voidspace> dimitern: kk
<voidspace> hmm... still the same error
<dimitern> voidspace, hmm I suspect you need to do apt-get upgrade and make sure distro-info is up-to-date
<dimitern> voidspace, looking at the comment on seriesVersions, check: $ cat /usr/share/distro-info/ubuntu.csv
<dimitern> mine does show wili
<dimitern> wily
<voidspace> dimitern: on machine-0
<dimitern> on your machine
<voidspace> mine does too
<dimitern> (well, try first on yours, then try on machine-0 I guess :)
<voidspace> this error looks like it's coming from the server
<dimitern> yeah - the "400" is a http status I guess
<voidspace> that directory doesn't exist on machine-0
<voidspace> doing an upgrade anyway
<voidspace> nothing to upgrade
<dimitern> voidspace, try dist-upgrade as well
<voidspace> did
<dimitern> voidspace, well, juju set-env logging-config '<root>=TRACE' && retry and paste the machine-0.log for the deploy call?
<voidspace> dimitern: I'm going to see if 1.22 has the same issue
<voidspace> dimitern: if I can upgrade from 1.22 that will suffice for testing
<voidspace> dimitern: and they do report failed upgrades from 1.22 - so they can test that scenario too
<voidspace> (if upgrading from 1.22 with upload-tools works)
<dimitern> voidspace, +1
<voidspace> dimitern: seemed to work
<voidspace> at least the upload worked I mean...
<voidspace> we'll see if the issue is fixed
<dimitern> nice!
<dimitern> 1.20 is too old anyway
<voidspace> yep
 * dimitern steps out for a while
<voidspace> dimitern: nope, still the same error - just reported in a slightly different way
<voidspace> dimitern: in fact, I can't even upgrade from 1.22 to 1.24 due to this error
<voidspace> dimitern: must be due to the already uploaded tools
<voidspace> I'll reset
<voidspace> dimitern: as wily is imminent I wonder if it's just recently been added to a stream / version list somewhere which is only *now* causing this problem to show
<voidspace> dimitern: I bet I can still test this fix anyway ("ignore-machine-addresses" with containers is probably broken even without an upgrade)
<voidspace> dimitern: and treat the upgrade problem as a separate issue
<frobware> voidspace, seems like it it would be a good step along the way
<voidspace> frobware: yeah
<mup> Bug #1509353 opened: local provider service cannot be enabled after disabling <local-provider> <systemd> <juju-core:Triaged> <https://launchpad.net/bugs/1509353>
<fwereade> grrrrrrrrrrrrrrrrr RB apparently just ate a long reply
<natefinch> fwereade: that has happened to me a few times.  Seemsl ike if you click on a link to look at the code, your replies go away
<fwereade> natefinch, dammit, thanks, hopefully I will learn from it
<natefinch> fwereade: but you don't really need a long reply. You can just click the ship it button on my review.  I'll know what you mean
<perrito666> lol
<natefinch> fwereade: but seriously... I always open the code links in new tabs now, that seems to be the only safe way to do it
<fwereade> natefinch, so what happened there, I think, was that I had two concurrent replies to previous reviews open, and then remembered I also had a review, and that would be a good place to put the topp-level comments, so I pressed the "edit review" button; when I returned only one of the replies was there
<lazypower> :\
<lazypower> thats never fun when you're working and the software is actively trolling you
<fwereade> still better than lp or github for reviews :)
<lazypower> debateable
<natefinch> it's amazing no one's made a significantly better review system... they all kind of suck in their own special ways.
<natefinch> which one you like best is mostly dependent on which suckiness you find least annoying
<fwereade> natefinch, ha, yeah
<lazypower> i feel this way about most software natefinch
<natefinch> lazypower: lol yep
<fwereade> natefinch, btw, we should talk more about tests -- I *think* that our differences on BaseSuite and in/out-package tests come from a common source
<natefinch> fwereade: I definitely think we both want the same thing in the end, we are just approaching it from different directions :)
<fwereade> natefinch, which could reasonably be summarised as "fwereade is unreasoningly paranoid and grumpy about all developers, including himself"
<natefinch> fwereade: ditto for me :)
<fwereade> natefinch, so in all cases, what you are doing is fine in isolation, but presses my buttons because it feels very easy for other people to break them unintentionally
<fwereade> natefinch, BaseSuite doesnn't protect against anything in your code
<fwereade> natefinch, but it (or maybe better, here, I think, IsolationSuite) *does* protect against the stuff other people might do in the future
<fwereade> natefinch, network access, writing env vars, etc etc
<fwereade> natefinch, and I have approximately zero faith in our collective ability to avoid doing stuff like that
<fwereade> natefinch, because it seems to keep cropping up
<katco`> natefinch: planning time
<fwereade> natefinch, and log-capture-by-default STM to be cheap compared to the monstrous hassles of trying to repro an intermittent failure that doesn't capture logs
<natefinch> katco`: oops, coming
<fwereade> natefinch, and so BaseSuite/IsolationSuite feel to me like just Good Habits because they're a tiny cost for a low-probability large benefit, that still IMO has a positive expected value
<fwereade> natefinch, I guess now is not the best time
<fwereade> natefinch, read at your leisure
<fwereade> natefinch, similarly, testing in-package is fine if you're disciplined and don't fossilise the code around the implementation details; but in practice, over time, the tests and the code leak into one another
<fwereade> natefinch, and then, when you're testing out-package and you get the urge to use export_test, you can actually use that as a smoke detector for higher-level problems with your design -- very very often, an implicit dependency that you "only want to change for tests" and therefore don't make an explicit dependency
<fwereade> natefinch, and the urge is understandable but IMO wrong
<fwereade> natefinch, almost anything you need to export_test you could instead represent as explicit config
<fwereade> natefinch, which may appear to broaden the interface
<fwereade> natefinch, but I contend that it actually just shows you a truer picture of the breadth, which was always there, but some of it was hidden
<fwereade> natefinch, and it's only by dragging the whole set of connections into the light that we can start to make good decisions about severing them
<frobware> dooferlad, you about? Can we have a quick chat about your NUCs?
<marcoceppi_> I need help with actions and the jsonschema, can anyone help me out?
<marcoceppi_> Mostly, what are the valid "types" in actions?
<marcoceppi_> I get string, int, boolean, but what else is there? mainly, is there enum
<natefinch> marcoceppi_: last I checked, they're all strings
<rick_h__> marcoceppi_: hmm, it's in the schema but not sure what they implemented in the go library for it.
<voidspace> frobware: dimitern: I can confirm that deploying a container with "ignore-machine-addresses" on fails with 1.24 (no need for an upgrade to demonstrate the bug)
<voidspace> frobware: dimitern: testing the fix now
<marcoceppi_> natefinch: well, no, there are definitely ints and booleans
<rick_h__> marcoceppi_: https://github.com/juju/gojsonschema/blob/master/json_schema_test_suite/enum/schema_1.json
<rick_h__> natefinch: ^
<frobware> voidspace, and that is just this bug -  https://launchpad.net/bugs/1509292 - or something else?
<mup> Bug #1509292: "ignore-machine-addresses" broken for containers <juju-core:In Progress by mfoord> <juju-core 1.24:In Progress by mfoord> <juju-core 1.25:In Progress by mfoord> <https://launchpad.net/bugs/1509292>
<marcoceppi_> \o/
<marcoceppi_> rick_h__: thanks!
<dimitern> voidspace, great! then we can confirm the fix works, and prepare a tarball with patched binaries for peter to try on the actual HW
<rick_h__> marcoceppi_: so the library should support it, not sure how it's exposed/used through actions
<rick_h__> marcoceppi_: but that's the tool used so hopefully helps a bit more at least
<natefinch> marcoceppi_, rick_h__:  https://bugs.launchpad.net/juju-core/+bug/1456703
<mup> Bug #1456703: action-set converts everything to strings <actions> <juju-core:Triaged> <https://launchpad.net/bugs/1456703>
<marcoceppi_> rick_h__: that's cool, turns out I don't need enums atm, but good to know
<marcoceppi_> natefinch: ah, I care slightly less about that, I was talking instead about the actions.yaml file format
<rick_h__> natefinch: hmm, but can you do a enum of strings then?
<natefinch> rick_h__: not sure
<natefinch> marcoceppi_: probably just needs some testing to see how it actually works... but I was getting numbers as strings, which was screwing things up, but maybe display in the GUI wouldn't be affected.
<natefinch> jw4: ^
<voidspace> frobware: correct
<voidspace> dimitern: well, he can try it - but I don't think he can upgrade to it
<voidspace> until there's a released one
<dimitern> voidspace, hmm.. that might be true, but I'm *sure* there's a way to fix that "invalid series "wily"" error
<voidspace> dimitern: you would hope so
<voidspace> I haven't found it yet
<voidspace> dimitern: frobware: the fix works
<voidspace> I'll add a test
<dimitern> voidspace, \o/
<dimitern> voidspace, before you leave today, please update the original bug with links to the separate bug we filed and your proposed fix
<voidspace> dimitern: done the first bit already
<voidspace> will add a link to the branch
<voidspace> dimitern: doesn't look to me like IgnoreMachineAddresses is tested...
<voidspace> it's not called from any tests anyway
<voidspace> dimitern: ah, found the tests
<dimitern> voidspace, yeah, it's tested for newMachiner
<dimitern> ok, I'm starting to celebrate the weekend and the productive week ;)
<voidspace> dimitern: enjoy
<dimitern> voidspace, thanks ;)
<katco`> ericsnow: wwitzel3: natefinch: not sure what's going on. looks like i have connectivity, but having trouble with hangouts
<natefinch> katco`: maybe log out and back in to google?
<frobware> voidspace, please could you point me at your fix
<frobware> voidspace, forget it, found it in the /other/ bug
<voidspace> frobware: just pushed a test
<voidspace> frobware: test needs improving - but the test passes with the fix and fails without it
<frobware> anybody see general gmail connectivity issues - seem to be plagued with chrome failures most of this afternoon
<voidspace> frobware: hmm... not that I've noticed
<voidspace> I'm using FF though
<frobware> voidspace, I spent at least one hour earlier in the day where things just went "aw, snap"
<rogpeppe2> anyone fancy a ridiculous review? this merges a feature branch. it has no commits in that have not already been reviewed. https://github.com/juju/juju/pull/3590
<rogpeppe2> it would make my week if i could get this merged today
<voidspace> rogpeppe2: if they're all already reviewed we've done the merge without further review...
<rogpeppe2> voidspace: awesome! $$merge$$ coming up!
<katco`> fwereade: hey are you still around?
<voidspace> rogpeppe2: if you want to return the favour, here's a really short review
<voidspace> http://reviews.vapour.ws/r/2992/
<rogpeppe2> voidspace: i have 4 more minutes until i have to go...
<voidspace> rogpeppe2: if you can't do it no problem :-)
<voidspace> rogpeppe2: it's *possible* to do that one in four minutes, but you might want to spend a bit more time on the test
<voidspace> rogpeppe2: the code change is like 3 lines...
<voidspace> frobware: http://reviews.vapour.ws/r/2992/
<frobware> voidspace, I made one comment but need to change browsers... as it keeps going snap!
<rogpeppe2> voidspace: sorry, small review but i'd need a while to understand the context
<voidspace> rogpeppe2: k, thanks
<voidspace> rogpeppe2: you wouldn't default to true, you'd default to the environment value and then override with false for a container
<voidspace> rogpeppe2: you think that would be better?
<voidspace> maybe
<voidspace> rogpeppe2: I've switched to that with a comment
<voidspace> rogpeppe2: oops, those comments should have gone to frob
<frobware> voidspace, much better
<voidspace> frobware: ^^
<mup> Bug #1509419 opened: 1.25-beta1 no matching tools error message spam <landscape> <juju-core:New> <https://launchpad.net/bugs/1509419>
<frobware> voidspace, I think you need somebody with additional +1 on the test
<voidspace> frobware: ok
<voidspace> TheMue: I think you're OCR today, if you're still around
<rogpeppe2> voidspace: np
<rogpeppe2> voidspace: have a good w/e
<voidspace> rogpeppe2: o/
<voidspace> you too
<voidspace> TheMue: http://reviews.vapour.ws/r/2992/
<bogdanteleaga> can I somehow export a struct only for testing?
<mup> Bug #1509419 changed: 1.25-beta1 no matching tools error message spam <landscape> <juju-core:New> <https://launchpad.net/bugs/1509419>
<mup> Bug #1509419 opened: 1.25-beta1 no matching tools error message spam <landscape> <juju-core:New> <https://launchpad.net/bugs/1509419>
<voidspace> bogdanteleaga: the usual pattern is to export an alias to the struct in export_test.go
<bogdanteleaga> voidspace: yeah, but I'm getting "<struct> is not an expression"
<bogdanteleaga> it does work for functions
<voidspace> ah
<voidspace> bogdanteleaga: export a function that returns a struct instance?
<voidspace> NewStruct
<mgz_> bogdanteleaga: with `type SomeStruct someStruct`?
<voidspace> or that...
<mgz_> that doesn't work depending on what exactly you're doing with the struct
<mgz_> if it's being passed in places that accept an interface it's fine
<voidspace> if you're testing the struct itself it should be fine
<voidspace> mgz_: if you have time a quick review would be appreciated, would be nice to land it today
<voidspace> mgz_: http://reviews.vapour.ws/r/2992/
<mgz_> voidspace: looking
<bogdanteleaga> mgz_: yup, that seems to do it
<mgz_> voidspace: I'm still mystified as to why 2992 is special
<voidspace> mgz_: special?
<mgz_> there's a little banner at the top of the page
<voidspace> mgz_: oh yeah
<voidspace> how odd
<voidspace> just because I'm special I guess
<mgz_> classic off-by-eight error?
<voidspace> a palindromic number?
<voidspace> mgz_: 2002 has a banner too
<mgz_> aha
<voidspace> and 2112
<natefinch> do we support local provider on Centos?
<mup> Bug #1509419 changed: 1.25-beta1 no matching tools error message spam <landscape> <juju-core:New> <https://launchpad.net/bugs/1509419>
<mgz_> natefinch: nope
<natefinch> mgz_: ok, I thought as much, but wanted  to know for sure
<mgz_> voidspace: code changes look good to me, need to look at the original ignoremachineaddresses branch to work out the actual logic
<mgz_> bogdanteleaga: what are the plans over centos and containers?
<bogdanteleaga> I'm pretty out of the loop concerning that one
<bogdanteleaga> I know there were some talks around templates and whatnot
<bogdanteleaga> you'd be better off asking gabriel or alexis about that
<mgz_> gotcha
<mup> Bug #1509419 opened: 1.25-beta1 no matching tools error message spam <landscape> <juju-core:New> <https://launchpad.net/bugs/1509419>
<bogdanteleaga> wow, juju/testing seems to depend on juju/utils
<mgz_> bug 1463480
<mup> Bug #1463480: Failed upgrade, mixed up HA addresses <blocker> <canonical-bootstack> <ha> <upgrade-juju> <juju-core:Fix Released by wallyworld> <juju-core
<mup> 1.22:Fix Committed by thumper> <juju-core 1.24:Fix Released by wallyworld> <hacluster (Juju Charms Collection):New> <https://launchpad.net/bugs/1463480>
<mgz_> voidspace: okay, your change seems fine, but we really need to kill this config option
<mgz_> the logic around address setting is getting ridiculous
<frobware> mgz_, choice leads to madness! :)
<voidspace> mgz_: thanks
<voidspace> mgz_: I know nothing about the origins of the hack
<mgz_> voidspace: the bug is fun reading
<voidspace> mgz_: ah, right
<voidspace> will try and dig it out
<voidspace> mgz_: I'll port this to 1.25 and on monday discuss with dimiter what to do about master
<mgz_> voidspace: sounds like a good plan
<voidspace> mgz_: at the moment if you use ignore-machine-addresses then containers are broken - so we can't leave it like this for long
<natefinch> anyone know why we've never written code to replace downed units?  Seems like a pretty basic need - to keep your service at the capacity you told Juju you wanted
<natefinch> (automatically replace, that is)
<voidspace> EOW
<wwitzel3> ericsnow: ping
<ericsnow> wwitzel3: hey
<ericsnow> wwitzel3: otp
<wwitzel3> ericsnow: ok, let me know when you have a second
<fwereade> natefinch, fwiw, the minunitsworker does that, but the functionality never got exposed via the CLI iirc
<natefinch> fwereade: so like, you just need a flag to enable it or something?
<fwereade> natefinch, the api accepts minunits, it just never made it into the cli
<fwereade> natefinch, it happened a looong time ago
<natefinch> fwereade: that's crazy
<fwereade> natefinch, also worth remembering that our direction has been explicitly focused on providing the primitives rather than building in too much hard-to-observe cleverness
<natefinch> fwereade: with all the talk of schedulers from other orchestration tools, seems like people want at least some basic cleverness
<fwereade> natefinch, I have a notion that we were expecting to pick it up alongside --scale-with and similar things that we didn't do for those reasons
<fwereade> natefinch, I'm not disagreeing, but I think there are valid arguments against building them in too deep
<fwereade> natefinch, built-in strategies *are* confining, and tend towards pressure to add more for every scenario out there
<fwereade> natefinch, that said, we could do a better job of exposing attachment points for external strategies
<fwereade> natefinch, although... machine placement and unit placement *do* give you quite a lot of control
<natefinch> fwereade: seems like if we give some default behavior and allow it to be overridden, we get the best of both worlds
<natefinch> fwereade: for people that want it to just work, they can use the default, and for people that want to do something else, they can use something else (or just do it manually like they have to now)
<fwereade> natefinch, zoom out enough and that's what we do, I think -- the intention is that just spamming commands with the fewest possible args *will* get you reasonably sane/predictable results
<fwereade> natefinch, you can certainly make a case that there's room for in between the two extremes
<natefinch> fwereade: the whole point is not to require a human at a keyboard to both notice and fix problems
<natefinch> fwereade: especially when the most reasonable thing to do is blindingly obvious
<fwereade> natefinch, fwiw, in machine/unit scenarios, the trouble is that the problem is rarely that blindingly obvious
<fwereade> natefinch, just because juju's lost track of a unit does not *necessarily* imply that that unit has gone away
<fwereade> natefinch, and when we can't be sure about the nature of a problem -- which is the general case -- automated responses are risky
<natefinch> fwereade: that's why you let the admin decide whether or not to automatically create a new one or not.  They get to decide which is worse - having one too many units/machines or one too few
<natefinch> fwereade: I'm guessing most admins would rather have one too many than one too few.
<fwereade> natefinch, for instance, the instance-replacement code that we used to have got dropped after it emerged that nobody was using it on purpose, and only consciously experienced negative effects (eg stopping an instance to do something out of band, whoops, juju started a new one)
<natefinch> fwereade: might require some tools - a juju pause-unit or something.... but mostly I'm looking for feature parity to our competitors... and one of the first things people always ask is "will you bring up a new unit if one goes down?"  And I think we lose a lot of people when we say no.
<fwereade> natefinch, so, yes, given a clear definition of "down", you can at least come up with predictable rules there
<mup> Bug #1496972 opened: juju bootstrap fails to successfully configure the bridge juju-br0 when deploying with wily 4.2 kernel <hs-arm64> <kernel-da-key> <network> <juju-core:New for frobware> <Ubuntu:Invalid by jsalisbury> <Ubuntu Wily:Invalid by jsalisbury> <https://launchpad.net/bugs/1496972>
<natefinch> fwereade: might also be a case for better introspection into our providers... juju should be able to ask EC2 if an instance is down, for example.
<fwereade> natefinch, but I would reiterate that when we tried it, people actively disliked it
<fwereade> natefinch, yeah, I can't remember how much instancepoller keeps track of offhand
<fwereade> natefinch, but, honestly, it's also annoyingly tricky to do usefully for any stateful workload
<fwereade> natefinch, storage possibly makes that better, for some forms of storage at least
<natefinch> fwereade: right, that's definitely the hardest bit
<fwereade> natefinch, and even then... I think I'm quite comfortable focusing on the atoms -- i.e. if I had to divide effort between "migration" and "deciding when to migrate" I think I'd be pretty happy putting all my eggs in the first basket
<natefinch> fwereade: that's true
<fwereade> natefinch, still, though, your point about what people are asking for remains unanswered
<fwereade> natefinch, if it is turning people off we should be addressing it
<natefinch> fwereade: I wouldn't say I have my finger on the pulse of the devops community, but I've definitely seen people ask for having the number of units maintained, at least.  And if it's low-hanging fruit because the backend stuff already exists....
<fwereade> natefinch, I don't think I've actually looked at the code for, uh, 30-odd months, so I can't really vouch for much -- in particular, I'm not sure it's working at the level we actually want it to
<fwereade> natefinch, it might mesh well with a machine-reaper for dead instances... but that is its own can of worms
<natefinch> fwereade: ahh, didn't realize it was quite that old :)
<fwereade> natefinch, something like that, yeah, round about the atlanta sprint
<fwereade> natefinch, it was a time of many decisions, not all of which have turned out optimal in the long run
<fwereade> natefinch, ...and fwiw, the machine-replacer code was gone before even then, so I suspect our audience today has little in common with our audience then
<lazypower> just pulled in -proposed juju, and so far so good team :thumbsup: nice work so far!
<cherylj> lazypower: yay!  thank you :)
<lazypower> :D
<alexisb> lazypower, thanks!
#juju-dev 2015-10-24
<mup> Bug #1509419 changed: 1.25-beta1 no matching tools error message spam <landscape> <juju-core:New> <https://launchpad.net/bugs/1509419>
<mup> Bug #1509635 opened: error destroying environments on OpenStack cloud with no block storage services <juju-core:New> <https://launchpad.net/bugs/1509635>
#juju-dev 2015-10-25
<mup> Bug #1509747 opened: Intermittent lxc failures on wily <lxc> <wily> <juju-core:New> <https://launchpad.net/bugs/1509747>
<axw> wallyworld_: need to get kids ready, take charlotte to school. I'll review in ~90 mins or so
<wallyworld_> no hurry
#juju-dev 2016-10-24
<mgz> morning all
<hoenir> any more thoughts on this review? https://github.com/juju/juju/pull/6414
<hoenir> morning mgz
<mgz> hoenir: I'd be happy to look over as well, but seems you have addressed reviews from axw and katco already?
<axw> hoenir mgz: I will take another pass, but nearly EOD so not until tomorrow
<hoenir> axw, ok thanks !
<jamespage> mgz, hey - we're hitting a juju ssh problem in a charm school at the openstack summit
<jamespage> aware of any issues? basically the terminal is foobar'ed when you ssh to a ubuntu machine from a windows command prompt.
<mgz> jamespage: hm, there have been some issues, let me see what I can find
<mgz> jamespage: bug 1468752
<mup> Bug #1468752: "juju ssh" adds an additional strings to all commands when used on Windows, in interactive mode <ssh> <windows> <juju:Triaged> <juju-core:Won't Fix> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1468752>
<anastasiamac_> mgz: jamespage: there is this on.. https://bugs.launchpad.net/bugs/1635622
<mup> Bug #1635622: 'juju ssh <unit> ...' fails with Permission denied (publickey), for only one or two machines in a deployment <juju:Triaged> <https://launchpad.net/bugs/1635622>
<mgz> ...bug doesn't document a workaround as such, but does suggest spaces before and after the command
<jamespage> anastasiamac_, ssh key is working ok - but shell is non-functional
<mgz> jamespage: is terminal completely borked of does ` echo test ` actually output 'test' as well as errors?
<mgz> -of+or
<mgz> may also be work considering using `juju run` instead, if possible?
<voidspace> finally online, one monitor still not working
<voidspace> ah well
<SimonKLB> whats the best way to include a local version of charmhelpers in the wheelhouse? right now i manually put it there and remove the one that gets downloaded in the build process
<voidspace> SimonKLB: you're better off asking in #juju - there should be people there who can answer your questions (although maybe a bit later in the day when the Americans arise!)
<SimonKLB> voidspace: whats the difference between #juju and this channel? i thought this was for the people developing juju / juju charms while #juju was for juju users
<voidspace> SimonKLB: this channel is used by those developing juju itself. #juju is for those writing charms and using juju.
<voidspace> SimonKLB: that's how it works in practise. I'm sorry that I don't know the answer to your question. There *maybe* someone here who can answer your question, but not at the moment it seems.
<SimonKLB> voidspace: gotcha, so youre not involved with the charmhelpers and/or charm layers?
<voidspace> SimonKLB: I don't have much experience with them myself, no.
<SimonKLB> do you know of anyone awake at this hour that do? id like to have a quick discussion regarding an issue
<voidspace> rick_h_: do you know who would be a good person to answer SimonKLB's question?
<SimonKLB> that, but even more someone to discuss this: https://github.com/juju-solutions/layer-basic/issues/79
<voidspace> SimonKLB: when more people are around I will ask again. It might be wise to ask on the mailing list as that gives people time to respond.
<voidspace> SimonKLB: let me find you a link.
<dimitern> SimonKLB: one of these people should be able to help: marcoceppi, lazyPower, arosales, jcastro
<voidspace> SimonKLB: https://lists.ubuntu.com/archives/juju/
<mgz> dimitern: do you have some time to help me with debugging today?
<dimitern> mgz: sure - what's up?
<SimonKLB> dimitern: yea, the only problem is the timezone difference with those guys.. :)
<mgz> dimitern: hangout? maas/network fun mostly
<dimitern> mgz: joining core now
<perrito666> morning all
<mgz> morning perrito666
<dimitern> mgz: you got kicked out?
<rick_h_> SimonKLB: https://pythonhosted.org/charmhelpers/getting-started.html#updating-charmhelpers-packages
<SimonKLB> rick_h_: thanks!
<SimonKLB> rick_h_: do you know if there is going to be any problems using this while also building the charm normally where the wheelhouse is getting populated?
<SimonKLB> isnt the upstream version of the charmhelpers going to be installed as well in that case?
<rick_h_> SimonKLB: sorry not sure. Will have to try it out.
<dooferlad> rick_h_: 1:1 time
<rick_h_> dooferlad: omw
<mup> Bug #1589680 changed: Upgrading to cloud-archive:mitaka breaks lxc creation <canonical-bootstack> <juju-core:Incomplete> <juju-core 1.25:Incomplete by dimitern> <https://launchpad.net/bugs/1589680>
<rick_h_> dimitern: so on that bug, you're doing an upgrade on the system so doing that install before bootstrap doesn't help?
<rick_h_> dimitern: if you install post-bootstrap is there anything that could be done to get it to that working state?
<dimitern> rick_h_: it's not an upgrade per se
<dimitern> rick_h_: it won't work with xenial containers to begin with, without upgrading
<rick_h_> dimitern: let's chat after the standup on it please
<dimitern> rick_h_: ok
<mup> Bug #1560487 opened: local provider fails to create lxc container from template <canonical-is> <local-provider> <juju-core:Triaged> <juju-core 1.25:Invalid> <OPNFV:Invalid> <juju-core (Ubuntu):Confirmed> <https://launchpad.net/bugs/1560487>
<rick_h_> kadams54: voidspace ping for standup
<rick_h_> oops, not kadams54, katco who, isn't here so tab complete fail
<kadams54> lOl
<kadams54> I was really befuddled
<rick_h_> kadams54: :P you know you want to join us
<kadams54> Guilty as charged
<voidspace> rick_h_: omw
<arosales> rick_h_: get SimonKLB all set?
<SimonKLB> arosales: yea talked to lazyPower :)
<arosales> SimonKLB: great, that lazyPower rocks
<perrito666> well look at that, this code had a ton of nilptr derefs waiting to happen
<natefinch> perrito666: obviously the answer is not to use pointers
<perrito666> natefinch: wish it was so easy
<natefinch> what, you just delete the little *, right?
 * rick_h_ lunches
<alexisb> babbageclunk, ping
<perrito666> hi all, I desperately need a review on https://github.com/juju/juju/pull/6490 its a bit tricky sorry
<natefinch> perrito666: oh man, dropping the need for our copied dependencies is awesome
<perrito666> natefinch: heh sadly that is the last tag that will support juju until we move to 1.7
<natefinch> perrito666: wow, they require 1.7?
<perrito666> natefinch: next tag uses Context
<perrito666> from context
<natefinch> ahh, crappage
<perrito666> We could revert it back to golang.org/x/context but maintaining such parallel code is very unwise
<natefinch> you could file an issue and maybe they'd put it back to using that one
<alexisb> perrito666, if we  are updating a dep we need a +1 from the tech board
<perrito666> alexisb: technically we had that dep already
<alexisb> the juju version was special because?
<perrito666> alexisb: compatible with go 1.2
<alexisb> o yuk, yeah ok I remember that
<alexisb> ok we are good then thank you
<perrito666> np, sorry for making the assumption there without asking
<babbageclunk> alexisb: pong, sorry - missed your message!
<alexisb> babbageclunk, no worries, was just going to touch base with you, otp atm
<babbageclunk> alexisb: ok, give me a yell when you're free
<perrito666> brb errand
<babbageclunk> alexisb: actually, pausing for lunch - will ping when back.
<alexisb> k
<katco> i will probably miss the mobility, but for now: wow it is so nice to be back on a desktop with 8 fast cores and 16GB ram
<rick_h_> katco: heh yea somtimes forget what real hardware can do
<katco> i definitely did
<katco> i did not know the pain i was in
<katco> at least i did the experiment :) now i know better
<babbageclunk> alexisb: back!
<alexisb> babbageclunk, still otp
<alexisb> :)
<babbageclunk> alexisb: ok cool
<perrito666> a lte modem is working better than my isp, this is so sad
<alexisb> babbageclunk, I am free when you are
<babbageclunk> alexisb: ok, jumping into the hangout
<alexisb> meet you there
<natefinch> man, recursive code screws with my head
 * rick_h_ goes to get the boy from school
<natefinch> rick_h_: aww... POC for openstack: http://pastebin.ubuntu.com/23375669/
<lazyPower> super cool to juju update-clouds today and see the new AWS region show up
<lazyPower> <3
<natefinch> \m/
<natefinch> lazyPower: while you're here, would love to get your impression of this working example of an interactive add-cloud for juju: http://pastebin.ubuntu.com/23375669/
<lazyPower> interesting, can this be scripted wtihout the use of `expect`?
<lazyPower> i assume it can with a config.yaml
<natefinch> lazyPower: nope,  but if you want to script you can just pass in a yaml file like we do now
<lazyPower> yep, sgm
 * lazyPower +1's it
<lazyPower> ship it
<natefinch> cool
<lazyPower> natefinch - i'm probably missing most of the context, the last time i setup an openstack controller was for OIL onboarding. but this looks straight forward.
<lazyPower> and i'm +1 to straight forward data entry forms :)
<natefinch> lazyPower: before this, the only way to add an openstack or maas or manual provider is to give juju a yaml file you had hand-written that you somehow mangically knew the correct format for
<perrito666> natefinch: what, you dont?
<lazyPower> natefinch - i recall, and it annoyed me
<lazyPower> <3
<babbageclunk> Anyone have an idea why this detects an error by looking for an error message in the header rather than for an error code? https://github.com/juju/juju/blob/staging/rpc/client.go#L103
<babbageclunk> perrito666, natefinch: ^
<natefinch> babbageclunk: I presume both are always set at the same time, not 100% sure though
<babbageclunk> natefinch: Well, they weren't in some code I just wrote! :) Took me a while to track down.
<katco> menn0: ping
<menn0> katco: hi
<katco> menn0: hey, hope your 3-day was good :)
<katco> menn0: or 4-day? did you take friday off?
<menn0> katco: 4 day!
<katco> menn0: nice :D
<katco> menn0: this is ready for review: https://github.com/juju/juju/pull/6469
<menn0> katco: mostly spent doing hard labour in the garden mind you
<katco> menn0: it always works out that way doesn't it?
<katco> menn0: do you write about your garden anywhere? considering starting one
<menn0> katco: yes, but it was kind of rewarding
<menn0> katco: looking at that PR now
<menn0> katco: github says there's a conflict
<katco> menn0: ta. no rush on that other than i'd like to get it merged before it conflicts :)
<katco> menn0: it's a very simple conflict at the top-level... not substantive
<menn0> katco: ok
<katco> menn0: cmd/juju/commands/main.go
<katco> menn0: the review doesn't have to be now; i'm not blocked or anything. just when you have time. before i wake up tomorrow would be nice :)
<menn0> katco: ok will do
<katco> menn0: ta!
<katco> menn0: so do you blog about your garden at all? what do you grow?
<menn0> katco: no, not at all. I am a complete beginner. this weekend was a lesson in how much I suck at gardening.
<katco> menn0: lol! any words of advice?
<natefinch> katco: my wife and I have gardened a lot.  Our gardening blog is evidently down, which I should fix.  But I'll try to get it back up again.
<menn0> katco: be careful when using a spade - there can be pipes where you don't expect them :)
<natefinch> lol
<menn0> I cut through an irrigation hose
<katco> natefinch: awesome, thx!
<katco> menn0: rofl
<katco> menn0: what are you starting off with?
<katco> natefinch: and what do you grow?
<natefinch> katco: if you're going to be in this location through next july, plant garlic, it's super easy
<katco> natefinch: with any luck we will not be. this is a future-looking thing :)
<natefinch> katco: ok :)
<katco> natefinch: maybe i could do some potted garlic
<natefinch> katco: garlic grows like a flower bulb - plant in the fall, harvest next july-ish
<katco> natefinch: that's perennial isn't it?
<natefinch> not really, you uproot the whole plant when you harvest
<katco> natefinch: oh. must have read that wrong... looked into that a month or so ago
<natefinch> katco: my best piece of advice us to mulch mulch mulch.  Makes the garden look nice, keeps soil moister, and keeps the weeds down.
<katco> natefinch: is mulch the same as compost?
<natefinch> katco: nope.  Mulch is the stuff you put on top of the ground to keep weeds from growing.
<katco> natefinch: oh didn't know mulch did that
 * katco is going to challenge menn0 for garden newb status
<natefinch> katco: for flower beds it's often bark, for garden beds my favorite is salt marsh hay... it's like regular straw, but straw has grass seeds in it, which are obviously not something you want in your garden
<menn0> katco: what, like regular updates? :)
<katco> natefinch: do you have to reapply? or once?
<natefinch> katco: basically just once a season
<katco> natefinch: what do you do with the old mulch?
<natefinch> katco: it tends to start to break down.. if it hasn't broken down too much, you can reuse it, but often times I just till it back into the dirt.
<katco> natefinch: ah ok. so you don't have to like rake it up or anything
<natefinch> nah.  It's just plant matter... it's actually good for the soil after it breaks down
<katco> cool
<katco> menn0: natefinch: have you seen this? https://farmbot.io/
<natefinch> oh oh oh.... if you're planting near a structure - get your soil tested for lead (among other things).  Sometimes lead paint can contaminate the ground near buildings.  you can get your local state extension office to test your soil - just grab a bag and mail it off.  It's like $15.  Totally worth it.
<katco> natefinch: wow, does that end up in edibles?
<natefinch> katco: it definitely can, especially if they're root vegetables.
<katco> wow
<menn0> katco: that's pretty awesome
<natefinch> yeah, haven't seen that machine before.  That's amazing
<menn0> katco: although this is almost certainly how the matrix begins... the robots start with plants but then move onto people
<katco> natefinch: menn0: it's completely open too. plans, cad, etc.
<katco> menn0: rofl
<katco> menn0: i couldn't have a perfectly fine hobby that gets me away from computers to keep me away from computers.
<menn0> haha
 * menn0 counts Github reviews vs reviewboard votes
<thumper> morning
<katco> morning thumper, wb
 * thumper is feeling a little sore
<thumper> about 15 hours of BJJ over Thursday/Friday/Saturday
<thumper> very good though
<katco> thumper: what is BJJ?
<thumper> brazillian jiu jitzu
<katco> ahh
<menn0> thumper: wow, that's a lot of walloping :)
<perrito666> mm, so, if the test run fails it marks the PR as failed, if it doesn't will it mark it as success in some form?
<thumper> why is our develop branch so screwed? and failing CI?
<perrito666> katco: menn0 natefinch thumper  does any of you know the answer to my question??
<katco> perrito666: i believe it will
<thumper> perrito666: it gets a tick
<perrito666> I see no tick, Ill try a build by hand
<menn0> thumper: i've just been going through some of the recent failures
<thumper> and?
<menn0> thumper: i'll take this one since I've worked on this recently: https://bugs.launchpad.net/juju/+bug/1632485
<mup> Bug #1632485: TestAgentConnectionDelaysShutdownWithPing fails <ci> <intermittent-failure> <unit-tests> <juju:Triaged by menno.smits> <https://launchpad.net/bugs/1632485>
<menn0> thumper: some of the windows fails are the usual mongodb failing to come up
<menn0> thumper: this looks quite strange and needs attention: http://reports.vapour.ws/releases/4522/job/run-unit-tests-race/attempt/2007
<thumper> menn0: I'm pretty sure I have mentioned more than once that 40 minutes isn't good enough on a small VM
<thumper> a success is ~36 minutes
<thumper> a 10% variation can cause it to fail
<thumper> ish
<menn0> thumper: well there's that, but all the ssh unit test failures are interesting as well
<thumper> ah
<thumper> yeah
<thumper> didn't scroll to that
<menn0> thumper: this is a new failure that started happening on the 22nd: http://reports.vapour.ws/releases/issue/580bc1a0749a566f2d9176bf
<thumper> heh
<thumper> yes, using space constraints is dependent on the underlying maas configuration
<menn0> thumper: any idea what we need to change to fix the failures? who owns this?
<mup> Bug #1630737 changed: juju should use internal vpc network address space when connected to vpc  via vpn <juju:Triaged> <https://launchpad.net/bugs/1630737>
<rick_h_> menn0: so that's something we need to work on the bigger "spaces on aws" picture
<rick_h_> menn0: I just triaged it and we'll make it part of that work we're planning for 17.04
<menn0> rick_h_: but what about the CI failures that are contributing to cursed develop tests now?
<rick_h_> menn0: oh, not sure.
<menn0> rick_h_: something spaces related was committed on the 22nd which started breaking a bunch of CI tests: http://reports.vapour.ws/releases/issue/580bc1a0749a566f2d9176bf
<rick_h_> menn0: hmm, but that was on the 22nd and no code landed over the weekend I'm aware of
<rick_h_> menn0: this smells like something else up?
<menn0> rick_h_: not sure - maybe whatever it was landed on the 21st, or maybe there's something else going on. i'm just trying to raise visibility.
<rick_h_> menn0: hmm, I wonder if this is related to mgz's new maas related tests he's been working to get going
<mgz> menn0: I broke a bunch of things, and should now have fixed them
<rick_h_> menn0: rgr, so that bug isn't related. It's something with aws and a vpn that's going on there.
<rick_h_> mgz: k, if you get a sec can you check with menno on what he's seeing vs expectations?
 * rick_h_ has to get the boy ready for violin lessons and then to join the release call
<mgz> menn0: can do hangout quickly if you like?
<menn0> mgz: sure
<mgz> menn0: I'm in the hangout named core
 * redir goes for late lunch and to run an errand
<redir> bbiab
<menn0> thumper: so those spaces failures are all in hand. mgz was making some changes to maas+networking related tests and the failures were teething problems. they shouldn't happen on the next run.
<thumper> cool
<mup> Bug #1636307 opened: cannot deploy to network space <juju-core:New> <https://launchpad.net/bugs/1636307>
<babbageclunk> menn0: Hey, are you busy? Can I pick your brains about some more migration stuff?
<alexisb> thumper, fyi this bug is still preventing blesses on CI: https://bugs.launchpad.net/juju/+bug/1625768
<mup> Bug #1625768: github.com/juju/juju/state go test timeout <ci> <intermittent-failure> <regression> <unit-tests> <juju:Triaged by alexis-bruemmer> <https://launchpad.net/bugs/1625768>
<thumper> yes
<thumper> I know
<thumper> and there isn't really much we can do to fix it
<thumper> the state tests just take a long time
<thumper> I have pointed this out many times
<thumper> until we replace the DB
<thumper> or move all the logic out into separate packages
<thumper> this will continue to fail
<thumper> there is no quick fix for this issue
<alexisb> thumper, I am on bluejeans
<thumper> ack
<mgz> bdx: can you poke around in your machine-0.log and see what juju thinks it knows about spaces when it's deploying machines to the wrong places?
<menn0> babbageclunk: hi, sorry was AFK
<menn0> babbageclunk: can chat now
<bdx> mgz: yeah omp
<mgz> bdx: thanks!
<mup> Bug #1560487 changed: local provider fails to create lxc container from template <canonical-is> <local-provider> <juju-core:Invalid> <juju-core 1.25:Invalid> <OPNFV:Invalid> <juju-core (Ubuntu):Confirmed> <https://launchpad.net/bugs/1560487>
<babbageclunk> menn0: Sorry - now I'm AFK - organising burger order but back in 5?
<menn0> babbageclunk: np, i'll be here.
<babbageclunk> menn0: ok, jump into a-team hangout?
<menn0> babbageclunk: ok
<babbageclunk> menn0: oh, hang on, that's bluejeans now - core?
<menn0> babbageclunk: yep :)
<alexisb> wallyworld, we are on bluejeans
<alexisb> I wil be right back
<wallyworld> alexisb: oh, i was in the hangout from the meeting invite
<babbageclunk> Oops, burgers just arrived - not going to make it to the standup, sorry! See you next week!
<alexisb> anastasiamac, ping
<alexisb> babbageclunk, ping
<alexisb> veebers, ping
<veebers> alexisb: pong o/
<alexisb> are you joining the hangout
<alexisb> standup
<veebers> alexisb: ah right, yes I can join, but might need to leave early
<axw> veebers: any idea what the deal is with http://juju-ci.vapour.ws:8080/job/github-merge-goose/17/console ?
<axw> veebers: failing because of a missing dep... do they have to be added to the bot machine manually?
<veebers> axw: hmm, wallyworld asked balloons the same thing. Let me have a look in a short moment
<axw> veebers: ok, thanks
<wallyworld> axw: veebers: i don't want the branch to land yet as I am pretty sure there's still a launchpad.net/gnuflag dep in there which needs to be culled
<wallyworld> but we can still fix the other dep issue in preparation
<axw> wallyworld: ok. yeah, i did see the bit just above where it grabbed launchpad.net/gnuflag
<axw> sounds good
<wallyworld> secgreoup-delete-all/main.go
<veebers> wallyworld: the jenkins job has launchpad.net/gnuflag declared as a dep, that needs to change?
<wallyworld> yes. to the github version
<wallyworld> the job error shows the missing repo
<veebers> ack
<veebers> wallyworld: when you say you don't want it to land yet, do you want it crippled in some way?
<wallyworld> no, just don't hit $$merge$$ once job is fixed
<wallyworld> once launchpad.net/gnuflag is removed, it won't land anyway :-)
<veebers> wallyworld: ack, I'll get the dep updated and you can merge whenever you wish
<wallyworld> awesome, tyvm
<veebers> wallyworld: nw, re-building now
<wallyworld> noooo!
<wallyworld> that's what  i didn't want :-)
<wallyworld> but it should fail
<veebers> wallyworld: carp, I can kill if needed
<wallyworld> hopefully
<wallyworld> we need to update to make consistent use of gnuflags dep
<wallyworld> before landing again
<veebers> wallyworld: rats, sorry about that :-\
<wallyworld> no worries :-)
<veebers> wallyworld: it succeeded :-\
<wallyworld> ah, ok, we'll do another fix up branch
<redir> thumper: when do you usually start?
#juju-dev 2016-10-25
<thumper> redir: around 9am
<wallyworld> veebers: i am blind. i pulled goose master and the change i wanted was there after all. i just missed seeing it in the diff it appears
<veebers> wallyworld: sweet, well in that case I accidentally re-built that job on purpose :-)
<wallyworld> yes :-)
<wallyworld> i need to go get glasses
<perrito666> hey, this is a strange question, did any of you went to disney?
<anastasiamac> perrito666: no
<redir> OK, thumper I'll hit you up around 10 tomorrow.
<anastasiamac> perrito666: wallyworld: as the most amazingly persistent ppl that worked on "backup" featurette, do u know if we have fixed this on Juju 2? https://bugs.launchpad.net/juju-core/+bug/1636080
<mup> Bug #1636080: Machine unit 0 dies after "juju backup" <canonical-bootstack> <juju:New> <juju-core:Won't Fix> <https://launchpad.net/bugs/1636080>
<wallyworld> lol
<wallyworld> i don't know that bug
<anastasiamac> it's new
<anastasiamac> agaisnt 1.25.6
<anastasiamac> i just want to know if we've fixed on 2..
<perrito666> anastasiamac: I have no clue, but last time I checked backup "just works" in 2.0
<anastasiamac> (which part "lol" - most persistent or featurette?)
<anastasiamac> awesome \o/
<anastasiamac> wallyworld: so as a conclusion of heated discussion.. spaces are only supported on MAAS in JUju2?
<anastasiamac> wallyworld: not ec2 or any other provider?
<wallyworld> and aws i believe
<anastasiamac> k ;)
<anastasiamac> then i have a bug \o/
<wallyworld> not 100% sure about others
<wallyworld> rick is across it all
<wallyworld> not sure if a bug is required, there is probably one already
<anastasiamac> wallyworld: that's what i mean - i have  abug: m not planing on creating more ;-P
<mup> Bug #1636307 changed: cannot deploy to network space <juju:Triaged by rharding> <https://launchpad.net/bugs/1636307>
<thumper> veebers: what CI testing do we have around migrations?
<veebers> thumper: http://juju-ci.vapour.ws:8080/job/functional-model-migration/
<thumper> how can I see what it does?
<veebers> thumper: that's the jenkins job for the model migrations that I worked on with menn0
<veebers> thumper: you could read the log, or the source or I could take a quick look to refresh my memory and give you a quick summary
<veebers> thumper: the test is "assess_model_migration.py" in juju-ci-tools
 * thumper looks at console output
<thumper> veebers: just wondering, because I have found a failure case, and wondering whether we should add it to the CI
<thumper> or at least I think I have a failing case
<veebers> thumper: what's the suspected failure case?
<thumper> veebers: juju upgrade-charm after a migration
<thumper> I'm pretty sure it will fail
 * veebers checks test code
<veebers> thumper: right, the current CI test does not attempt that, it does add units to the migrated models
 * thumper nods
<thumper> how easy is it to add?
<veebers> thumper: should be straight forward I think
<mgz> morning all
<frankban> dimitern: could you please take a look at https://github.com/juju/juju/pull/6482 ? it's trivial
<dimitern> frankban: sure, I'll get to it shortly
<frankban> ty
<dimitern> frankban: it is trivial indeed - I'll QA it locally, but I'd appreciate a review on this equally trivial https://github.com/juju/juju/pull/6495
<frankban> dimitern: since *state.State is embedded, why defining that method at all?
<dimitern> frankban: not sure - I guess so it can be stubbed for testing
<mgz> I like just deleting the method
<frankban> dimitern: ok, then lgtm
<dimitern> frankban: cheers! I'm almost done with yours..
<frankban> dimitern: what's vmaas-21?
<dimitern> frankban: virtual maas 2.1
<frankban> dimitern: cool, so that spins up a virtual maas? where? lxd?
<dimitern> frankban: nope, just uses one of my vmaas-es - all in lxd
<frankban> dimitern: ah, ok
<perrito666> Morning all
<dimitern> perrito666: morning :)
<perrito666> Dimitern i added a comment to your pr about something that worries me
<dimitern> perrito666: yeah, I've just seen it
<dimitern> perrito666: I'm open to suggestions how to test this actually :)
<perrito666> If you can convince of the comtrary ill stamp it
<dimitern> perrito666: it's just badly written code, that's not well tested - and that's because it's only really works on maas - with some assumptions
<perrito666> Are there plans to change the state of things?
<dimitern> frankban: I'm having trouble with `juju gui` - it seems to return Juju GUI is not available: Juju GUI not found on LXD (always that I can see..)
<dimitern> frankban: however I can see with your fix it's dialing "wss://10.40.149.73:17070/api", and without it - "wss://10.40.41.252:17070/model/9b6daa80-d635-43d8-893d-8e5fcaec583d/api", so I can confirm it's using the controller root
<dimitern> frankban: ok, I've run `juju upgrade-gui` first and now it works! \o/
<frankban> dimitern: cool, so current GUI in simplestreams does not work with juju tip?
<frankban> dimitern: or did you bootstrap with --no-gui?
<dimitern> frankban: it seems so - I've seen issues around getting the gui commonly
<dimitern> frankban: nope, I'm not using --no-gui
<frankban> dimitern: I wonder why the GUI was not available on your controller then...
<frankban> any errors in the bootstrap output?
<dimitern> frankban: yeah - usually `Unable to fetch Juju GUI info: error fetching simplestreams metadata: invalid URL "https://streams.canonical.com/juju/gui/streams/v1/index.sjson" not found`
<dimitern> frankban: LGTM
<frankban> dimitern: dimitern oh ok then, you have a firewall or similar?
<frankban> dimitern: ty
<dimitern> frankban: I have a bunch of iptables rules, but I don't think it should interfere with streams.c.c (I've seen intermittent connection errors hitting streams.c.c occasionally though)
<dimitern> perrito666: there are always plans :)
<dimitern> perrito666: but that code is not yet used for what it's supposed to be used
<dimitern> perrito666: it will be fixed in the near future when we have greater spaces support in the providers (LXD at least)
<frankban> dimitern: thanks to your fantastic QA instructions a set up a quick and dirty juju-db juju plugin: http://pastebin.ubuntu.com/23378478/
<dimitern> frankban: awesome! I'll give it a try :)
<frankban> cool
<dimitern> frankban: works great, and only needs support for --help and --description I think to become an official plugin :)
<frankban> dimitern: http://pastebin.ubuntu.com/23378596/
<dimitern> frankban: sweet thanks! btw noticed a typo on 17 (conect)
<frankban> dimitern: good catch thanks
<dooferlad> dimitern, voidspace, macgreagoir: https://github.com/juju/juju/pull/6496 needs eyes
<dimitern> dooferlad: will have a look shortly
<dooferlad> thanks dimitern!
<natefinch> rick_h_, voidspace: http://pastebin.ubuntu.com/23378736/
<natefinch> I was thinking it would be useful to just print out the yaml at the end anyway, so you can see the end result easier.
<rick_h_> natefinch: sorry, -1 from my pov on that. I think just finishing with a "Added cloud 'osl' would be about it
<rick_h_> natefinch: maybe a sample bootstrap ", can be bootstrapped with juju bootstrap osl"
<dimitern> dooferlad: can you clean that diff a bit, so it's easier to follow? It looks like you've moved some things around for no good reason
<rick_h_> natefinch: much like add-credential, the goal is to get to where the files don't exist to the end user and having this go so far from that seems not the best direction.
<natefinch> rick_h_: well, maybe the output of show-cloud os1?
<natefinch> basically the same thing... I just find it nice after all the prompts and stuff to see that I didn't typo anything
<rick_h_> natefinch: is it really worth a > 1 line output that you added an entry?
<rick_h_> natefinch: but you see what you typed in your terminal above the final line?
<natefinch> yes, but it can be hard to see the forest for the trees.  The prompts and stuff make it so it's not a consolidated view
<rick_h_> natefinch: nothing else we have dumps out that kind of data that I can think of.
<dooferlad> dimitern: code was moved for the very good reason of it being difficult to follow and debug
<natefinch> rick_h_: most of our things aren't long complicated interactive commands either
<dooferlad> dimitern: like it says in the PR, getBootstrapConfigs contains the only material changes.
<dooferlad> + tests
<rick_h_> natefinch: I understand, but going to go -1 on starting that here unless there's real user feedback. Start minimal and add only when pushed imo.
<natefinch> ok
<rick_h_> always easy to add, harder to take away kind of thing
<dimitern> <grumble/>..
<dooferlad> dimitern: unfortunately the github diff viewer sucks
<dooferlad> dimitern: the one I was using locally make it much clearer :-|
<dimitern> dooferlad: *ok*, I'll try to follow it, but since it's >500 lines, somebody else should have a look as well
<rick_h_> dimitern: dooferlad +1 on 2 reviews for a large diff
<natefinch> rick_h_: so, I added manual yesterday too (which is really trivial, but worth having to keep the UX consistent).  So now I just need tests... but at least it's working, and it should be pretty extensible if neeed
<dimitern> dooferlad: re QA: what do you mean by 'check that it is honored' ? whether it's set on get-model-config after bootstrap with --config use-floating-ips=true ?
<rick_h_> natefinch: so is this still a PoC or have you gone beyond that?
<rick_h_> natefinch: the original goal was a single PoC we could try out and get some review that the code was heading in the right path.
<natefinch> rick_h_: it's basically production code that has zero tests
<dooferlad> dimitern: if I were you, I would just open https://github.com/dooferlad/juju/blob/9577e379651a6c45d3b4b3050f11ebda2516fbad/cmd/juju/commands/bootstrap.go and look at Run (line 314+) that used to be insanely big and make sure that it reads well. The only logical change is in getBootstrapConfigs (line 729+) where the old code was wrong.
<rick_h_> natefinch: heh, ok
<rick_h_> natefinch: let's not use the word production yet then :P
<natefinch> rick_h_: heh
<natefinch> indeed
<natefinch> I can build a binary and let people poke at it
<dooferlad> dimitern: the other new functions are just moved code so Run is even vaguely readable.
<rick_h_> natefinch: +1, shoot me a branch or a binary and I'll tinker with it
<dimitern> dooferlad: ok, I'll do that
 * dimitern wtf?! bootstrapCmd.Run is more than 500 lines itself!
<dooferlad> dimitern: Just clarified the CI steps in response to your question - the bug was in parsing clouds.yaml, so you need to set the config there, not on the CLI
<dimitern> that's *insane*
<dooferlad> dimitern: it used to be *much* bigger
<dimitern> dooferlad: I'm looking at the source before your changes :)
<dooferlad> dimitern: oh, yea
<dooferlad> dimitern: that is why I changed it!
 * dimitern approves :)
<dimitern> of the refactoring
<natefinch> rick_h_: https://docs.google.com/uc?export=download&confirm=leR2&id=0B-r4AW1RoHJNRFRsZ1U4d1diaHc
<natefinch> rick_h_: or use hub checkout https://github.com/juju/juju/pull/6498
<rick_h_> natefinch: cool ty
 * dimitern tries to remember how to use canonistack
<macgreagoir> dimitern: I can give it a test in canonistack, if you get stuck.
<dooferlad> macgreagoir: if you could take a look at that https://github.com/juju/juju/pull/6496 too that would be great
<macgreagoir> dooferlad: I am, aye. Only 498 lines to go :-)
<perrito666> dooferlad: looking
<dimitern> macgreagoir: that would be great actually :) thanks!
<macgreagoir> dimitern: nw
<rick_h_> kadams54: natefinch dimitern ping for standup
<rick_h_> bah, katco that is
<kadams54> :-(
<kadams54> ;-)
<dimitern> omw
<dimitern> dooferlad: reviewed
<dooferlad> dimitern: thanks!
<dooferlad> dimitern: my favourite types of changes - minor cosmetic
<dimitern> dooferlad: well, the code seems OK AFAICS
<dooferlad> dimitern: :-D
<rick_h_> dooferlad: picking up our intermittent issue for week #2 and since your work is in review sending your way please.
<dooferlad> rick_h_: ack
<perrito666> dooferlad: dimitern I am reviewing the pr, it might take me a couple of minutes but I will most likely catch similar stuff than dimitern
<perrito666> dooferlad: reviewed
<dimitern> rick_h_: good news :) I can't reproduce the bash completion traceback - probably was due to stale cache file or something
<rick_h_> dimitern: hmm, I had that in my testing right up to GA
<rick_h_> dimitern: /me will try to reproduce I guess
<dimitern> rick_h_: however, I found a couple of issues with it and I'd like to propose a small fix so completions will work for source builds and the version check will be properly installed
<mgz> yeah, I'm sorry but the completion stuff is still super-heisen
<mgz> there is almost certainly a bug or two
<mgz> but may depend on specifics of which packages were installed in the past and so on
<dimitern> mgz: can you give this a try? https://github.com/juju/juju/pull/6499/ (also a review would be nice :)
<dimitern> rick_h_: ^^
<mgz> dimitern: taking a look
<mgz> dimitern: I don't think try:/except: pass can be what we want
<dimitern> mgz: why?
<mgz> means there's no record at all if things are borked
<dimitern> true, but would you prefer a broken bash env instead? :)
<mgz> the style seems to be print something out mid-tab if things are totally screwed
<mgz> I agree that normal operation shouldn't do that
<dimitern> I don't mind dropping the try/excepts
<dimitern> but I really like the block 345-348, which finally made the completions usable for source builds
<mgz> yeah, I agree that change seems good
<dimitern> a possible workaround will be `sudo ln -s "$GOPATH/bin/juju" /usr/bin/juju-2.0", but that won't work if you *also* have the juju-2.0 package installed
<dooferlad> dimitern, perrito666: WRT https://github.com/juju/juju/pull/649 I could just return/fill in structs for the functions that currently return lots of variables but the diff would be bigger. Happy to make the change either now or in a followup. Thoughts?
<dooferlad> leave comments on the PR if you want but would like to know my next step soon.
<dimitern> dooferlad: that's even better - I meant to suggest it, but forgot
<dooferlad> dimitern: OK, I won't squash that commit so you can see what changed.
<dooferlad> dimitern: thanks
<dimitern> mgz: updated https://github.com/juju/juju/pull/6499
<perrito666> dooferlad: sorry was hunting for lunch, please do as a follow up
<dooferlad> perrito666: just pushed changes to ^^. Dimiter seemed to want them on the same branch so that was where I was working. https://github.com/juju/juju/pull/6496/commits/5890aa96b97e4db8b945894ce2a8415fdfaab077 is the changes from what you have seen before.
<perrito666> dooferlad: checking
<deanman> Hello, I'm facing a very wierd behavior of juju2 on xenial guest VM using localhost as a cloud provider. In particular, i can bootstrap the controller just fine and see its LXD in running state but when deploying a charm it complains about not being able to download the image. Guys from #juju were helpful enough and suggested that maybe it is a bug and could get some more triage assistance here?
<kwmonroe> to add to deanman's case, this looked fishy to me:  http://paste.ubuntu.com/23379874/.  where does 'stream "devel"' come from, and why is his agent version 2.0.0.1?  he's got the juju/devel ppa, but so do i, and my agent version/stream is 2.0.0/released.
<deanman> kwmonroe: You meant juju/stable ppa right? At least i have used 'sudo add-apt-repository ppa:juju/stable' before downloading juju
<kwmonroe> deanman: even when i install from the devel ppa, i still get a model-config with 2.0.0/released.
<deanman> ah ok!
<deanman> kwmonroe: xenial-backports repo is uncomment on source.list, does it make any difference?
<kwmonroe> i don't think so deanman.  mine is uncommented as well
<kwmonroe> one other fishy thing between deanman's model config (http://pastebin.com/YM9GHtrC) and mine is his says: development / model / true.  mine says:  development / default / false.
<kwmonroe> deanman: is it possible you bootstrapped with --config development=true?
<deanman> kwmonroe: well i did set it to true myself during bootstraping.
<kwmonroe> and you were just all like "this probably isn't important to mention to kwmonroe"?
<deanman> "Set whether the model is in development mode", i was in development mode :-)
<kwmonroe> :)
<kwmonroe> well try turning that sucker off
<rogpeppe1> anyone know of a testing utility func in juju that destroys a model and all its applications too?
<rogpeppe1> or do i have to write it?
<rogpeppe1> i'm talking about testing when i've got a *state.State instance here
<rogpeppe1> natefinch: ^ ?
<natefinch> rogpeppe1: buh.... no idea.  Look on juju conn suite maybe?
<rogpeppe1> i *think* what i have to do is Destroy the model, then go through each of the model's applications and destroy them, then go through each unit and destroy that. or maybe the other way around.
<natefinch> I can't tell if juju destroy-model kills applications too (sorta looks like it, but it's not explicit).  Might look to see how it does that
<rogpeppe1> natefinch: it doesn't seem to
<rogpeppe1> natefinch: i think it waits for everything to tear itself down
<natefinch> ahh
<katco> rogpeppe1: is this a feature test?
<natefinch> rogpeppe1: kill-controller does a forced destruction after it's timeout expires
<rogpeppe1> katco: this isn't a test in juju-core
<katco> rogpeppe1: ah ok, sorry to bother
<rogpeppe1> katco: np
<natefinch> do we have a checker that does regex matches across newlines, or do I have to do the strings.replace(s, "\n", "", -1) thing?
<natefinch> gah, whoever made checkers in github.com/juju/testing/checkers without godoc deserves a flogging
 * rogpeppe1 checks it's not him
<perrito666> yeah, foto log that b*****d
<perrito666> natefinch: fun fact flog in spanish applies to users of foto logs :p
<natefinch> heh, it was tim
<natefinch> or at least... hmm
<natefinch> I think he must have moved the code
<natefinch> because I know I wrote SameContents, but it's flagged as him too
<natefinch> I guess we'll never know
<natefinch> perrito666: heh
<katco> natefinch: if only there was a tool to review the complete history of code =|
<perrito666> natefinch: great now my brain has snaps of tim dressed as a emo/dark
<natefinch> katco: I don't know how to dig further in the history of that line, and running more than one command requires more effort than I really care to spend :)
<perrito666> yeah, if we where all in the same office you could use the more simple method of printting the code, write in red marker "you know who you are, beg that I never do" and put it with a knife in the pin board
<perrito666> which I am sure there is a git command for
<perrito666> and certainly an emacs shortcut
<rogpeppe1> so far i've got this and the last call to RemoveAllModelDocs still fails with a "model not dead" error: http://paste.ubuntu.com/23380364/
<rogpeppe1> i wonder what other things i need to kill
 * rogpeppe1 delves into the code
<rogpeppe1> how i love mgo/txn
<natefinch> it's um... something special, for sure
<rogpeppe1> perrito666: any idea how i can remove a model, by any chance?
<perrito666> rogpeppe1: destroy-model ?
<rogpeppe1> perrito666: sorry, i've got a *state.State
<perrito666> rogpeppe1: ah, It escapes my memory now, but State.Destroy() isnt a thing?
<rogpeppe1> perrito666: no, that would be too obvious :)
<perrito666> rogpeppe1: god forbid we do that
<rogpeppe1> perrito666: i think Model.DestroyAllModelDocs is the thing
<rogpeppe1> perrito666: but it doesn't work if the model isn't dead
<rogpeppe1> perrito666: and i can't work out how to make it dead
<rogpeppe1> perrito666: there's no EnsureDead or Remove method on Model
<perrito666> rogpeppe1: state.Model() then thatModel.Destroy()
<rogpeppe1> perrito666: this is what i'm doing currently: http://paste.ubuntu.com/23380415/
<perrito666> rogpeppe1: check state/model.go
<rogpeppe1> perrito666: but it doesn't work
<rogpeppe1> perrito666: i've checked that there are no apps and no machines left
<rogpeppe1> perrito666: which is what the code seems to be checking for
<perrito666> rogpeppe1: odd, destroy is quite straight forward
<rogpeppe1> perrito666: the model life remains at dying
<perrito666> I recall there being aworker for this but not much more
<rogpeppe1> perrito666: the worker will be outside of state tho'
<perrito666> rogpeppe1: most likely running on the controller? not sure
<rogpeppe1> perrito666: it shouldn't matter AFAICS - i'm accessing the state directly
<rogpeppe1> perrito666: ha, it looks like you can't remove a model if you've called Destroy on it
<perrito666> rogpeppe1: even if life advanced to dead?
<rogpeppe1> perrito666: the only way of advancing life to dead is by calling Destroy
<rogpeppe1> perrito666: (i think)
<perrito666> rogpeppe1: afaik destroy will advance it to dying
<rogpeppe1> perrito666: but if there are units around and you call Destroy it goes into dying mode
<perrito666> then you do something and it gets dead :p
<rogpeppe1> perrito666: yeah
<rogpeppe1> perrito666: but there's this code in Destroy:
<rogpeppe1> 	if m.Life() != Alive {
<rogpeppe1> 		return nil, errModelNotAlive
<rogpeppe1> 	}
<rogpeppe1> perrito666: which looks wrong to me
<perrito666> right in this moment I miss fwereade :p
<rogpeppe1> perrito666: indeed
<rogpeppe1> perrito666: i don't think anyone else understood this stuff
<rogpeppe1> perrito666: if i change that line to "m.Life() == Dead", then I get "failed to destroy model: state changing too quickly; try again soon"
<rogpeppe1> i can't think how many times i've seen that error and it's never ever been because state was changing underfoot
<rogpeppe1> katco: BTW i got bored and landed gopkg.in/retry.v1
<katco> rogpeppe1: cheers
<katco> rogpeppe1: i was going to try and review that in more depth today before the tech board meeting
<rogpeppe1> katco: i dunno what the juju board decision will be, but at least snappy can use it now
<katco> rogpeppe1: :)
<perrito666> rogpeppe1: with some luck menn0 might understand it better or thumper they both must have been around for multi model work
<rogpeppe1> perrito666: it would be nice to have someone with whom i shared some working hours :)
<perrito666> rogpeppe1: ah I sort of forgot t hat detail
<rogpeppe1> katco: review comments still welcome on the retry PR BTW
<katco> rogpeppe1: is that pr now in sync with gopkg.in/retry.v1?
<rogpeppe1> katco: pretty much. the only changes are the import paths and that i removed the dependency on juju/utils/clock
<katco> rogpeppe1: ok cool. i will go there when/if i can review
<rogpeppe1> katco: ta
<katco> rogpeppe1: ty!
<katco> redir: hey i'm sorry i'm afraid i've been a horrible pairing partner. do you need anything?
<rogpeppe1> perrito666: BTW that code does work if you haven't already called Destroy on the model first
<perrito666> rogpeppe1: odd
<perrito666> rogpeppe1: btw, thumper is there, so technically you are now sharing tz
<thumper> FSVO sharing
<rogpeppe1> thumper: yo!
<thumper> morning
<rogpeppe1> thumper: evening :)
<thumper> pretty sure if it was evening, I'd be drinking
<rogpeppe1> thumper: do you have any idea about model lifecycle states?
<katco> rogpeppe1: thumper: it's afternoon you fools!
<rogpeppe1> thumper: i drank enough last week to cover this week
<thumper> rogpeppe1: what do you mean by that?
<rogpeppe1> thumper: so, i'm operating directly on *state.State
<thumper> alive, dying, dead?
<rogpeppe1> thumper: i have a model with some units
<thumper> uh ha
<rogpeppe1> thumper: i call Destroy on it
<rogpeppe1> thumper: it goes into dying state
<rogpeppe1> thumper: (as expected)
 * thumper nods
<rogpeppe1> thumper: then i destroy/remove all the units, apps and machines
<thumper> why?
<rogpeppe1> thumper: because i want to remove the model
<thumper> destrying a model starts a cascade of cleanup jobs
<rogpeppe1> thumper: this is without any workers running
<rogpeppe1> thumper: just raw *state.State
<thumper> um... ok
<thumper> why not call the remove all model docs method?
<rogpeppe1> thumper: you can't call it until the model is dead
<rogpeppe1> thumper: but it seems that once a model is dying it can never be made dead
<thumper> what is the use case for this?
<rogpeppe1> thumper: a test
<rogpeppe1> thumper: but i kinda hope that state works on its own terms
<thumper> it can be made dead
<thumper> but a lot of this changed with the tear down of multi model
<thumper> i'd have to go and read the code
<rogpeppe1> thumper: how can it be made dead?
 * thumper goes to look
<rogpeppe1> thumper: this code looks suspicious to me:
<rogpeppe1> func (m *Model) destroyOps(ensureNoHostedModels, ensureEmpty bool) ([]txn.Op, error) {
<rogpeppe1> 	if m.Life() != Alive {
<rogpeppe1> 		return nil, errModelNotAlive
<rogpeppe1> 	}
<rogpeppe1> thumper: I *think* that implies that if the model is dying, then it won't do anything
<rogpeppe1> thumper: and that certainly *seems* to be the case in practice
<thumper> look at state/model_test.go:111
<thumper> although that method is is export_test.go
<thumper> is this a state package test or from further out?
<rogpeppe1> thumper: further out. in an external project that's integration-testing watcher behaviour
<thumper> ProcessDyingModel
<thumper> rogpeppe1: moves a model from dying to dead if all the machines are gone
<rogpeppe1> thumper: ha
<rogpeppe1> thumper: that's... unusual
<thumper> part of the undertaker worker
<rogpeppe1> thumper: perhaps that should be renamed to EnsureDead
<rogpeppe1> thumper: to fit with the other types
<thumper> all about the controller making sure the models are cleaned up nicely
<thumper> except it doesn't EnsureDead
<thumper> ish
<rogpeppe1> thumper: or at least Destroy could mention that method
<thumper> not entirely sure
<thumper> true
<thumper> it should
<thumper> there should be docs about model lifecycle that mention the states, and how to progress through them
<thumper> you are not wrong
<rogpeppe1> thumper: thanks anyway. i've spent hours on this :)
<thumper> :(
<thumper> it is one of those sad cases where everyone wants better docs
<thumper> and no one writes them
<thumper> or
<thumper> we have a tendency to think everything is obvious
<thumper> and doesn't need writing down
<thumper> until we come back to it in 3 - 6 months
<thumper> when we have forgotten the context
<thumper> I've done that a lot
<rogpeppe1> thumper: yeah, it is easy to do
<rogpeppe1> thumper: BTW this is what you need to do do destroy a model in the state from first principles AFAICS: http://paste.ubuntu.com/23380624/
<thumper> hmm...
<rogpeppe1> thumper: FWIW i think i'd found ProcessDyingModel if it had been a method on Model not State
<thumper> good thing we have cleanups that do most of that
<rogpeppe1> s/i'd/i'd've/
 * rogpeppe1 's test finally passes
<thumper> \o/
<thumper> hmm...
<thumper> seems like if bootstrap can't access public streams, it'll fail, even if it has local tools
<thumper> how will this work in secure separate networks?
<natefinch> thumper: sounds like a question for Ian.  it should upload tools automatically, but that doesn't help with images
<thumper> yeah
<thumper> I have intermittent DNS issues
<thumper> which makes bootstrap sometimes fail
<thumper> and also GUI downloading fail
 * thumper thinks there should be a retry in there somewhere
<natefinch> the network isn't always reliable?
<thumper> nope
<thumper> no idea why
<thumper> kinda shit
<natefinch> well, maybe it's because you're on an island off the coast of an island off the coast of southeast asia
<thumper> hmm...
<thumper> how do you upgrade a local charm now?
<rick_h_> thumper: juju upgrade-charm ./localcharm
<thumper> that isn't what the help says...
<rick_h_> thumper: sorry, missed the application name in there
<thumper> nope
<thumper> $ juju upgrade-charm ~/canonical/juju-2.0-beta7/charm-ubuntu ubuntu
<thumper> error: unrecognized args: ["ubuntu"]
<rick_h_> thumper: hmm, katco reworked that per a bug on that
<thumper> help says to specify --path to point to local charm location
<thumper> but that fails too
<rick_h_> katco: does it remember the same path on disk and need a --switch to take a ne wone?
<thumper> $ juju upgrade-charm --path=~/canonical/juju-2.0-beta7/charm-ubuntu ubuntu
<thumper> ERROR charm or bundle URL has invalid form: "~/canonical/juju-2.0-beta7/charm-ubuntu"
<rick_h_> thumper: right, you need the ./
<thumper> that isn't obvious at all
<rick_h_> thumper: try --path=./home/thumper/canonical/juju-2.0-beta7/charm-ubuntu or cd there and go
<thumper> ./home is just wrong
<katco> thumper: rick_h_: right, you have to specify --path in addition to the application name
<rick_h_> thumper: except all local charm references across all of juju2 require the ./ as the local indicator?
<thumper> is it a path or relative?
<katco> thumper: i believe it's any resolvable path... let me check
<thumper> $ juju upgrade-charm --path=./../canonical/juju-2.0-beta7/charm-ubuntu ubuntu
<thumper> ERROR charm or bundle URL has invalid form: "./../canonical/juju-2.0-beta7/charm-ubuntu"
<thumper> ugh from wrong dir
<thumper> juju upgrade-charm --path=./canonical/juju-2.0-beta7/charm-ubuntu ubuntu
<thumper> Added charm "local:xenial/ubuntu-1" to the model.
<thumper> worked when given a relative path
<thumper> that points to it
<thumper> but if the path is wrong, the error is confusing
<thumper> redir: did you want to chat kvm?
<redir> thumper: sure if your free
<redir> you're even
<thumper> rick_h_: funnily enough `juju deploy ~/canonical/juju-2.0-beta7/charm-ubuntu/ ubuntu` works
<thumper> rick_h_: but you can't use the same path to upgrade-charm
<thumper> we should probably fix that
<rick_h_> thumper: right, there was a bug around that. I thought they were made consistent.
<katco> thumper: this is the thing that resolves it: https://github.com/juju/charmrepo/blob/v2-unstable/charmpath.go#L51
<katco> rick_h_: thumper: https://github.com/juju/juju/commit/51d6437d31b154604d011be146f7d0a231e6e186#diff-aec7c600a6f94b7c3646bb9d9b124854
<katco> rick_h_: thumper: "There is commonality between `deploy` and `upgrade-charm` in resolving arguments and doing something useful with them. There is an opportunity to create a component and to pass it into both commands."
<katco> rick_h_: i would relish the opportunity to address that :)
<rick_h_> katco: yea, sorry. We spent a lot of time there. More to move onto atm.
<rick_h_> katco: would be good to get a bug though with the direction and mark it up for 2.2 suggestions
<katco> rick_h_: actually did not; you're thinking of deploy
<rick_h_> katco: true enough
<mup> Bug #1614633 changed: A unit with a failed storage-detaching hook cannot be destroyed <juju:Fix Released by axwalk> <juju-core:Won't Fix> <juju-core 1.25:Won't Fix> <https://launchpad.net/bugs/1614633>
<alexisb> anastasiamac, we can meet now if you like
<anastasiamac> k :)
<anastasiamac> alexisb: m in our 1:1
#juju-dev 2016-10-26
<menn0> wallyworld: review done
<wallyworld> thanks menno, will look soon
<axw> wallyworld: I was planning to do a small fix for cinder in goose today, but won't be able to if we can't use the version changes in juju
<axw> wallyworld: you think it's too close to be doing that?
<natefinch> rick_h_: thanks for all the feedback
<thumper> wallyworld: ffs
<thumper> wallyworld: I'm trying to get controller details for a non-responsive controller
<thumper> but show-controller makes an api call
<thumper> so doesn't return
<natefinch> <sad trombone>
<natefinch> ..aww, I miss Dave
<menn0> axw: prometheus review done. good stuff.
<axw> menn0: thanks!
<axw> menn0: develop seems buggered, I got a test failure to do with SCP commands which I went nowhere near
<menn0> axw: yep, that's failing each run in CI too
<axw> I'll dig a bit later
<menn0> axw: I worked in that area a few months ago so I can try and take a look too.
<menn0> axw: i'm bringing up the issue of develop being permanently cursed in the tech board meeting
<axw> menn0: dimiter made some changes last week to do with connecting to multiple addresses, most likely introduced then
<menn0> axw: ah right. that seems likely.
<axw> menn0: ok, sounds good. it's been a week since it merged :/
<menn0> axw: actually, I'll take a look now unless you really want it
<axw> menn0: nope, knock yourself out
 * thumper sighs
<thumper> menn0: got things to panic
<thumper> not sure if this is moving in the right direction
<menn0> thumper: this is the cloud credentials handling?
<thumper> yeah
<thumper> oh ffs
 * thumper wants to slap whoever did the core/description part of cloud-credentials
<thumper> menn0: the cloud credentials are never set on the outgoing model
<thumper> now that I'm passing them in
<thumper> it panics with "" not valid
<wallyworld> thumper: show-controller does make an api call as it needs that info. list-controller doesn't. juju controllers --format yaml is what you want
<thumper> thanks
<natefinch> that is uh... not very intuitive
<axw> wallyworld: just want to check I understand your email to heather. are we not updating dependencies.tsv now, because we're too close to 2.0.1?
<axw> wallyworld: I was hoping to get https://github.com/go-goose/goose/pull/26 in and updated in juju, but can't do it without the api version changes
<wallyworld> axw: i was refering to pull 25 which is the base work to support multi version endpoints. i didn't see the point in landing that just before 2.0.1 if there was no functional change
<wallyworld> but if you have a 26 which actually fixes something....
<axw> wallyworld: yes, this will fix https://bugs.launchpad.net/juju/+bug/1636648
<mup> Bug #1636648: cinder fails with badRequest... "Invalid input for field/attribute device" <openstack-provider> <storage> <juju:In Progress by axwalk> <https://launchpad.net/bugs/1636648>
<wallyworld> then that changes my thnking
<wallyworld> do you see where i was coming from?
<axw> wallyworld: yes
<axw> wallyworld: but I thought this was meant to go through OIL before we cut 2.0.1
<axw> so not sure on the timing
<wallyworld> yeah, we will need to ensure that
<axw> ok
<wallyworld> let's land yours and we can track progress through OIL
<axw> wallyworld: ok, sounds good. if you have a momen to review that, please do - it's pretty trivial
 * axw lunches
<wallyworld> looking now in fact :-)
<axw> wallyworld: thanks
<wallyworld> np
<wallyworld> axw: oops (one liner) https://github.com/juju/juju/pull/6500
<axw> wallyworld: LGTM
<wallyworld> ta
<axw> wallyworld: OK for me to land https://github.com/juju/juju/pull/6428 now then?
<axw> then I'll base my update on top
<wallyworld> yep
<wallyworld> if you are happy with it
<axw> looked fine, I'll take another look over
<axw> wallyworld: actually hrm, looks like we're never assigning s.Openstack, so we'll leak HTTP servers
<axw> wallyworld: I'll cherry-pick and fix that, and include in my PR
<wallyworld> sgtm, ta
<axw> wallyworld: bugger, seems there's an issue with keystone metadata source not working on heather's branch
<wallyworld> oh, for the simple streams data
<wallyworld> hmmm
<wallyworld> yo think the issue is on the goose side?
<wallyworld> or in that juju pr
<axw> wallyworld: dunno, looking into it now
<wallyworld> ok
<axw> wallyworld: it looks like the object-store check is not quite sufficient for product-streams
<axw> wallyworld: what do you think about disabling the API version check if the user passes in "" for the version?
<axw> (and just use whatever's in the service URL)
<axw> service catalogue
<wallyworld> i *think* that's ok testing notwithstanding
<axw> wallyworld: https://github.com/go-goose/goose/pull/27 please
<axw> running a test in Juju now, so far so good
<axw> it found the image metadata
<wallyworld> axw: sorry, quassel has stopped beeping at me, missed ping
<wallyworld> axw: lgtm with a suggestion. glad it was a simple fix
<axw> wallyworld: last one I promise: https://github.com/juju/juju/pull/6501
<wallyworld> no worries
<axw> wallyworld: first commit is heather's, unchanged
<wallyworld> ok
<wallyworld> axw: lgtm, suggested a test for the no device case
<menn0> wallyworld or axw: here's the fix for the issue that's causing lots of failures in develop: https://github.com/juju/juju/pull/6502
<axw> menn0: looking
<axw> and thank you
<menn0> just writing up QA steps
<wallyworld> yay
<axw> menn0: LGTM, thanks
<menn0> axw: cheers
<menn0> wallyworld, axw: there's still other tests that are failing intermittently and need attention, but this gives us a better chance of a bless
<wallyworld> yes, ty menno
 * wallyworld off to soccer, bbiab
<dimitern> macgreagoir: hey there
<macgreagoir> dimitern: \o
<dimitern> macgreagoir: rick_h_ suggested we should pair on the ipv6 setup / stuff
<dimitern> :)
<dimitern> macgreagoir: unless you are busy otherwise atm, ofc :)
<macgreagoir> dimitern: Can I get back you about that? I'm just trying to finish part of it now.
<Mmike> hi, lads. Where do I find wishlist for juju2 on launchpad?
<Mmike> And ladies, hello!
<mgz> hm, you mean as in features?
<deanman> Is ftp used as a protocol in any operation of juju ?
<mgz> nope
<deanman> I have enabled TRACE logging to see why controller running inside LXD fails to download image to deploy a charm on a seperate LXD. I get the following http://paste.ubuntu.com/23382970/. Information there doesn't help. What could i further look into? pcap?
<mgz> deanman: do you actually have routing to streams.canonical.com from that machine?
<deanman> The key differentiator is proxy, if not using proxy my setup works just fine, if using proxy the guest Xenial machine is able to download image and boot LXD container but not when deploying a charm.
<deanman> mgz: You mean whether this URL is resolvable?
<mgz> yeah, in this case with the same proxy settings I guess
<mgz> you probably do need some lower level inspection to see whether the correct requests are being sent out
<deanman> mgz: I can manually curl that address and see content returned, i guess juju would have nagged anyway if it couldn't reach that URL, could it be that somehow proxy messes with content returned?
<mgz> it's possible, but that log does look like juju nagging (at info level only)
<deanman> I can deduce from https://github.com/juju/juju/blob/juju-2.0.0/tools/lxdclient/client_image.go that it should have failed earlier if it was a network problem.
<perrito666> hey I suddenly have to run to the bank, bbl
<mgz> voidspace: do you have a mo to help me work out if the bug I have is in juju or maas?
<voidspace> mgz: yes
<voidspace> mgz: hangout or PM?
<mgz> voidspace: hangout?
<voidspace> mgz: cool - I have 5 mins before 1:1 with rick_h_ though.
<mgz> lets be fast
<voidspace> kk
<voidspace> mgz: see you in core
<voidspace> mgz: right, 15 minutes until hangout - I'm digging out the maas docs
 * mgz hopes back in core
<mgz> hops
<mgz> not hopes
<voidspace> mgz: hopes is better
<natefinch> odd, somehow my calendar got set to tuesday as the first day of the week
<natefinch> oh, no, it was on 7 days.. wacky
<rick_h_> katco: voidspace dimitern dooferlad ping for standup
<dimitern> omw
<dimitern> mgz: it will be useful to dump the NIC params here e.g.: 2016-10-26 11:31:50 INFO Changed existing interface: node-71f20964-71e9-11e5-8007-525400c43ce5 eth0
<dimitern>  
<mgz> dimitern: yeah, that could do with some more details
<dimitern> mgz: I'm not sure maas can satisfy *both* a placement with --to and bootstrap spaces constraints
<dimitern> mgz: if it happens some times but not others, the issue is probably hidden behind the log I pasted above
<mgz> I expect --to overrides
<mgz> anyway, the --to on bootstrap is fine
<mgz> it's the bundle deploy which just uses constraints where things get interesting
 * rick_h_ heads home from coffee shop
<katco> rick_h_: are you in the 2.0 retro?
<katco> balloons: hey i can't chat in bluejeans, but please don't hold back!
<balloons> katco, I think the feedback is most useful in the context of how to make it work at Canonical. I am +1 for doing it -- have been for some time
<katco> dooferlad: +1 to all of that
<dooferlad> katco: thanks
<katco> balloons: yes, i agree: it's paramount to confine the discussion to how it should work at canonical. that's a very agile concept anyhow :)
<alexisb> rick_h_, ping
<rick_h_> alexisb: pong
<alexisb> heya rick_h_redir has a request
<katco> rick_h_: re. your request: what priority is this? should i stop working on everything else?
<rick_h_> katco: yes please to unblock release
<katco> rick_h_: ok, starting on this
<perrito666> k, new isp about to connect me expect me to be unresponsive, apologies
<katco> rick_h_: so wait... we want develop -> 2.0? we're skipping staging?
<rick_h_> katco: yes, staging is a subset of develop at the moment. We need the updates in develop.
<katco> rick_h_: can you hangout rq?
<rick_h_> katco: sure thing, meet you in ?core
<thumper> rogpeppe, katco: morning, I've been thinking more about the retry thing, and I'm starting to get your viewpoint around the error handling. As my wife knows, I can be very stubborn but hopefully teachable
<rogpeppe> thumper: hiya
<katco> thumper: lol "strongly held beliefs loosely held" (thanks fwereade) is not a fault in my book
<thumper> I just wanted to say so "in person"
<rogpeppe> thumper: thanks for continuing to think it through :)
<thumper> rather than just email
<rogpeppe> thumper: that's appreciated
<thumper> there is a wonderful saying
<katco> thumper: rogpeppe: and thank you to both of you for putting so much effort into getting this right
<thumper> you shouldn't hold on to a wrong idea just because you spent a long time making it
<katco> thumper: yeah i immediately stole that one. not sure where he got it from
 * katco has a moment of silence to miss fwereade's contribution here
<rogpeppe> thumper: i like that - that is a good motto. apposite on many occasions i think.
 * thumper nods
<rogpeppe> thumper: shall we just go with gopkg.in/retry.v1 then? ISTM that it's something that deserves a larger scope than juju/
<rogpeppe> thumper: (i removed the dependency on utils/clock, so it should be usable by external projects that want to keep their dependencies tight)
<thumper> I'd like to bring things together first, then think about where
<thumper> I also think that we shouldn't depend on utils/clock
<thumper> we have always said that github.com/juju libraries aren't just for juju
<rogpeppe> thumper: i agree that those libraries aren't just for juju, but i think the name does imply some juju relatedness to people.
<thumper> yeah...
<thumper> there is some squatter on the canonical name
<rogpeppe> thumper: and some parts are definitely juju-centric - the way that an import of juju/utils mucks with gobal variables in net/http means I'd never recommend that to anyone external, for example.
<thumper> what in juju/utils mucks?
<rogpeppe> thumper: FWIW i think that snappy is already using the above import.
<rogpeppe> thumper: http.go:20
<thumper> ugh
<thumper> that seems like a wrong place
<rogpeppe> thumper: yes
<thumper> libraries that modify globabls of other packages is very antisocial
<rogpeppe> thumper: at least it doesn't make all HTTP connections drop after a single request like it did for years
<thumper> pfft
<rogpeppe> thumper: https://bugs.launchpad.net/juju/+bug/1491608
<mup> Bug #1491608: importing juju/utils should not side-effect http.DefaultTransport <tech-debt> <juju:Triaged> <juju-core:Won't Fix> <https://launchpad.net/bugs/1491608>
<mup> Bug #1636960 opened: Manual provider that spawns LXD containers <juju-core:New> <https://launchpad.net/bugs/1636960>
<natefinch> rogpeppe: wow, that's bad
<katco> balloons: ping, can you sanity check? https://github.com/juju/juju/pull/6504
<natefinch> It is surprisingly hard to get url.parse to actually reject things
<katco> so i'm on a new machine and having trouble building gh.com/lxc/lxd
<katco> i can't remember if i ever had to set anything up... it looks from the README.md that a go get github.com/lxc/lxd isn't expected to work?
<katco> there's additional libs required? can anyone confirm?
<natefinch> katco: from the makefile:
<natefinch> 	# Must a few times due to go get race
<natefinch> 	-go get -t -v -d ./...
<natefinch> 	-go get -t -v -d ./...
<natefinch> 	-go get -t -v -d ./...
<katco> natefinch: i'm getting errors on includes of .h files
<katco> natefinch: i highly suspect my setup, but i wanted some confirmation
<katco> natefinch: you're able to just do a go get?
<natefinch> katco: I think I've built it before... possibly did some work to get there, I don't remember.  I presume you followed the steps in the readme?
<katco> natefinch: nope, trying to avoid it
<natefinch> ha
<katco> natefinch: i don't want bleeding-edge lxd on my system, and the ppa doesn't seem to separate out that from the build-deps?
<natefinch> I dunno.... tych0?
<tych0> i htink the ppa bundles everything, and the archive version uses the archive's deps
<tych0> what's the problem, exactly?
<katco> tych0: is it possible to use the ppa for building but not for installing a binary?
<tych0> katco: sure, just build the binary but don't copy it to /usr/bin
<tych0> or did i misunderstand?
<katco> tych0: if i add the ppa, and do apt install lxc, won't it install the binary from the ppa?
<katco> tych0: or upgrade for that matter
<tych0> the `lxc` binary comes from lxd-client
<katco> tych0: ah ok different ppa? ppa:ubuntu-lxc/lxd-git-master is safe for building?
<tych0> katco: i don't even think you need the PPA to build
<tych0> i think the archive versions of golang should be okay for every release
<katco> tych0: you are correct, it was indeed the way i had things set up. thanks for confirmation! and ty natefinch
<tych0> katco: sure, np
<katco> balloons: ping? ut?
<balloons> katco, yes
<balloons> katco, sure let me take a quick look
<katco> balloons: ta
<balloons> katco, the buildbot is going to ignore this -- personally I think if we're happy we can just merge it
<balloons> it's been tested once, and we'll give it a full run once it's merged
<balloons> (it ignores pr's not going into develop)
<katco> balloons: ah ok
<katco> balloons: so i'll just merge and we can start a test run?
<balloons> yea
<balloons> looks like you have the proper commit
<katco> balloons: cool, merged.
<wallyworld> katco: sent you an email about 2.0.1
<katco> wallyworld: ok tal
<wallyworld> thanks in advance :-)
<katco> wallyworld: hth, shouldn't take long (WITH THE POWER OF EMACS!)
<wallyworld> lol
<wallyworld> katco: emacs, making development great again
<katco> wallyworld: lol
 * wallyworld prefers vi :-)
<katco> wallyworld: no one is perfect
<wallyworld> funny, funny
<katco> wallyworld: i thought you liked ides?
<wallyworld> yeah i do, but when i need to do quick editing, vi is it
<katco> wallyworld: for me it's emacs -nw -q
<wallyworld> of course it is :-)
<katco> which i have aliased to qmacs for "quick emacs" ;p
<katco> wallyworld: so you can't cherry-pick merge-commits, so i'll have to try and CP all the commits for that merge
<wallyworld> katco: oh joy. i had a thought - just after that PR was another (test only fixes) to solve bad intermittent juju scp test fixes. might be worth taking that one so we get a good/better CI run
<katco> wallyworld: was that the PR from menn0?
<wallyworld> yeah
<wallyworld> next commited PR after the goose one
<katco> wallyworld: the next commit i see is bebd627 which is from dooferlad
<katco> wallyworld: i don't see anything from menn0
<menn0> katco: https://github.com/juju/juju/pull/6502
<katco> menn0: ta... weird wonder why my local log is displaying something different
<katco> menn0: dang it, last fetch didn't go through
<katco> menn0: i see it now, ty
<menn0> katco: cool. sorry was on a call.
<katco> wallyworld: i lied earlier, i can cherry merge commits
<wallyworld> awesome, i'm sure i have done it before so i was a bit confused but in a meeting so didn't really think too hard
<wallyworld> katco: so think you are cherry pick 2 commits right?
<katco> wallyworld: cherry-pick -m 1 <commit>
<wallyworld> yep
<wallyworld> that's what i use
<wallyworld> so you are taking the goose commit and menno's
<katco> wallyworld: correcy
<katco> wallyworld: correct
<wallyworld> tyvm
<katco> wallyworld: menn0: sanity check please: https://github.com/juju/juju/pull/6505
<wallyworld> looking
<menn0> katco: looking
<alexisb> anastasiamac, https://hangouts.google.com/hangouts/_/canonical.com/alexis-bruemmer
<wallyworld> katco: looks good ty
<alexisb> when you ar eready
<katco> menn0: hit merge conflicts on yours
<katco> menn0: i think i did the correct thing
<menn0> katco: LGTM
<katco> balloons: are you up on all this?
<katco> wallyworld: menn0: tyvm
<wallyworld> yes he is :-)
<wallyworld> i raised it inthe release call
<wallyworld> so it's my fault you needed to do this :-D
<katco> wallyworld: ok :) will need a new test run balloons
<katco> just merged
<wallyworld> will will let the current run finish
<wallyworld> and then look to the new one
<katco> wallyworld: it was a hooge deal. terrible. and some commits i assume were good. but i make the best commits, everyone says so.
<wallyworld> indeed :-)
<katco> that was my attempt at trump-speak if that wasn't evident =|
<perrito666> axw: already up? I have a vsphere thing to ping pong with you
<axw> perrito666: I'm here now
<perrito666> axw: are you on bluejeans?
<mup> Bug #1636960 changed: Manual provider that spawns LXD containers <juju:Triaged> <https://launchpad.net/bugs/1636960>
<axw> perrito666: I am now
<alexisb> thumper, menn0, wallyworld ping
<mup> Bug #1636960 opened: Manual provider that spawns LXD containers <juju:Triaged> <https://launchpad.net/bugs/1636960>
<mup> Bug #1636960 changed: Manual provider that spawns LXD containers <juju:Triaged> <https://launchpad.net/bugs/1636960>
<wallyworld> axw: ping after your breakfast etc and we can talk to thumper about cred migrations?
<thumper> I'm looking to head up the road to a cafe for a bit
<thumper> which isn't good for calls or irc
<wallyworld> ok, can do it later
<thumper> or now?
<thumper> I really don't think there is a huge amount to talk about
<wallyworld> i think axw needs to do school drop off etc
<axw> thumper: now's fine for me. I just resent an email from june if you want to read that first
<axw> nah, michelle's on leave so she'll take charlotte to school
<thumper> what menn0 and I talked about yesterday was pack up the creds with the model, and error out if there are some that are on the controller already but differ
<wallyworld> should we join the standup hangout again?
<thumper> ok
#juju-dev 2016-10-27
<wallyworld> axw: review done
<axw> wallyworld: thanks
<menn0> thumper: could you take another look at this please? https://github.com/juju/juju/pull/6492
<thumper> yep
<thumper> menn0: just one thing
<menn0> thumper: ok thanks
<menn0> thumper: good suggestion. I even looked for an existing file to put that func in but missed this one.
 * thumper nods
<blahdeblah> Anyone able to tell me what this means?  Google has no hits.
<blahdeblah> Unable to get the model status from the API: no such request - method ModelManager(2).ModelStatus is not implemented (not implemented).
<blahdeblah> Seeing this using 2.0.0 client against a 2.0 rc3 controller
<blahdeblah> wondering if it's an API incompatibility between the two
<blahdeblah> If I downgrade to the 2.0-rc3 client, I get this instead: "ERROR cannot update account information: unqualified user name "admin" not valid"
<menn0> blahdeblah: that does indeed appear to be an API incompatibility
<menn0> blahdeblah: the error means that the client is trying to call ModelStatus on the ModelManager facade but the API server doesn't have it
<menn0> blahdeblah: I've done some digging and it looks like this was changed just before 2.0 final
<menn0> blahdeblah: it was done as part of the fix for bug 1611111
<mup> Bug #1611111: destroy-model is not blocking and should be <ateam> <oil> <oil-2.0> <uosci> <juju:Fix Released by wallyworld> <https://launchpad.net/bugs/1611111>
<menn0> blahdeblah: your best bet would be to use a 2.0-rc3 client to do what you're trying to do
<menn0> blahdeblah: and get that controller upgraded to 2.0 final
<blahdeblah> menn0: the 2.0-rc3 client had that unqualified user name problem, so I upgraded the controller to 2.0.0 (thanks wallyworld)
<menn0> blahdeblah: ok great
<menn0> glad you got it sorted
<menn0> sorry for the trouble
<mgz> hmph hmph, bug battle
<lazyPower> is there a way to tune the timeout of an action?
<lazyPower> i have a long running command that can reasonably take up to 6 hours to complete. I'm noticing the action seems to be timed out after just an hour and nukes the process thread
<natefinch> lazyPower: probably not
<lazyPower> natefinch this is unfortunate news indeed :/
<natefinch> lazyPower: I'll double check the code to see
<lazyPower> natefinch - for context, we built a layer to run the kubernetes e2e suite so we cna just relate itto the cluster and kick off an action to validate it conforms to what both we and google expect from a deployed k8s cluster
<lazyPower> natefinch - the full gambit of tests can take nearly 24h in some cases, in our use-case the test runs take a few hours.  So any way we configure this we're headed for a tire fire it sounds like
<natefinch> lazyPower: try using a numeric param called timeout and set it to the correct timeout in nanoseconds  (why the hell it's nanoseconds, I don't know).  I think that might work.  It looks like the timeout for juju run is specified that way, and it might work for actions, which use a lot of the same code
<lazyPower> ok
<lazyPower> i'll give that a go and let you know if it yields diferent results in ~ 40 minutes
<lazyPower> seems like the timeout is closer to 30 minutes than my original estimated 1 hr
<natefinch> lazyPower: worth trying a very short timeout on a long action first, to see if it does anything
<lazyPower> https://bugs.launchpad.net/juju/+bug/1637191  -- i filed this to track
<mup> Bug #1637191: [Feature Req] Make action timeout values tuneable via model-config <juju:New> <https://launchpad.net/bugs/1637191>
<natefinch> lazyPower: like, try to get it to timeout after 30 seconds.... easier to test that it works that way, than try for a 40 minute run ;)
<lazyPower> hokay ;)
<rick_h_> lazyPower: try a --timeout flag to the command?
<rick_h_> https://github.com/juju/juju/blob/6cf1bc9d917a4c56d0034fd6e0d6f394d6eddb6e/cmd/juju/commands/run_test.go#L128 has me wondering
<rick_h_> lazyPower: but I don't see where there's a hard coded timeout in juju for this in looking
<lazyPower> i added the timeout param to the action, building and upgrading charm
<rick_h_> oh heh, natefinch got you the same info it looks like
<lazyPower> :D I'm in good hands
<rick_h_> natefinch: chat?
<lazyPower> That doesn't appear to have changed the actual timeout.   http://paste.ubuntu.com/23388262/  -- is what i have in my actions.yaml
<natefinch> rick_h_: yep.
<lazyPower> i would have expected this to terminate context nearly immediately
<rick_h_> lazyPower: can you file a bug for the timeout exposure on actions please?
<lazyPower> rick_h_ i filed this: https://bugs.launchpad.net/juju/+bug/1637191
<mup> Bug #1637191: [Feature Req] Make action timeout values tuneable via model-config <juju:New> <https://launchpad.net/bugs/1637191>
<lazyPower> are we looking for a different bug context on having specific actions take timeout values instead of blanket config in model-config?
<katco> rick_h_: hey i just read your email, i'm double-checking
<rick_h_> katco: k, I was looking at the github list of commits for each branch and got freaked
<rick_h_> katco: balloons says I'm ok and to calm down :)
<katco> rick_h_: i pulled from commit 5890aa9, not HEAD... maybe that's why you're seeing a difference?
<balloons> ohh katco, you are around early. I reverted wallyworld's changes in your PR that you landed.
<rick_h_> katco: sorry, been otp and not looked at the 'why' yet.
<balloons> katco, is there a reason you landed them without the bot?
<katco> balloons: you said the bot didn't watch the 2.0 branch?
<balloons> katco, I hope I didn't lead you astray by saying to manually do the merge to create the branch
<balloons> katco, $$merge$$ still works
<katco> balloons: oh... ok. why didn't we use that for merging the first set of commits?
<katco> balloons: sorry about that. i thought the bot didn't work on that branch
<balloons> katco, I didn't want to hold out waiting for a run as that exact code had already been through a full CI run
<katco> balloons: oh i see. ok, sorry for the misunderstanding
<balloons> and my expectation moving forward is we would just create the branch; not through a PR as it's already "landed" code we would be branching
<katco> balloons: well the branch was already there, i just merged code into it. moving forward all of these changes would have been done directly off the 2.0 branch
<balloons> katco, no worries. I would rather have already sorted this out but we're doing a release now with this mantra before finalizing the changes Alexis brought up
<balloons> katco, true. I was thinking there wasn't a brancg
<katco> balloons: we'll get it right eventually. so are wallyworld and axw's cherried commits in there? do i need to re-propose?
<balloons> katco, I just reverted them. They broke the build and maybe could have been fixed and merged, but you didn't get to see that before merging last night :-(
<katco> balloons: doh... ok. so i'll repropose? or is it too late now?
<balloons> I don't think you need to re-propose now as they will come naturally in the next release.
<katco> balloons: ok. sorry wallyworld, axw
<balloons> I'm sorry if I led you astray. But please do use the bot to land code, and test it yourself as well before proposing :-)
<rick_h_> natefinch: ping for standup
<katco> balloons: hey i think rick_h_ may have been right
<katco> balloons: the commit alexisb_ suggested was for a branch prior to the commit to merge into develop
<katco> balloons: so i think i only brought in the commits from that work, not everything up to when that work was merged
<katco> balloons: i.e. 5890aa9 not bebd627
<balloons> katco, ahh. I verfied that what you brought in and the commit mentioned where exactly the same
<balloons> so if the commit you wanted wasn't the right commit, well ;-)
<katco> balloons: yep, kind of how i was operating
<katco> balloons: yep lol
<katco> balloons: so what can we do here?
<balloons> katco, well it sounds like rick_h_ is going to ask for 2.0.1 to have everything in it
<balloons> ?
<katco> balloons: yeah already has
<balloons> you may as well re-do the cherrypick then
<katco> balloons: ok, i'm going to --force the correct merge in if that's ok?
<balloons> so you are going to merge bebd627?
<katco> balloons: yes, and then cherry the two commits?
<katco> balloons: and overwrite history
<balloons> ok
<katco> balloons: with --force
<perrito666> fun fact, Air Conditioning installers do not do the electrical wiring to the device....
<balloons> katco, can you do it so we get a pre-check run
<balloons> so we know the basics are sound -- otherwise we'll end up in the same place, since this isn't a straight pull anymore
<katco> balloons: sorry, can you restate? what do you mean "do it so we get a pre-check run"? how do i do that?
<balloons> katco, sorry. I was asking if you were going to propose it as a PR or not
<katco> balloons: oh, yes i am
<balloons> katco, ok, fire away
<balloons> :-)
<katco> balloons: do you know what sha i should begin from? d25720a?
<balloons> katco, I don't know offhand. Let me see
<balloons> katco, to be far you could just grab the additional commits since the branch is up to 5890aa9
<balloons> *fair
<katco> balloons: i'd rather not have the messy history, plus we now have changes on top of that. not sure what git will do
<balloons> katco, then nuke the branch and redo it I think
<balloons> katco, use the 2.0.0 tag and re-make from that, then propose what you wish
<balloons> how's that?
<balloons> it's at 6cf1bc9
<katco> balloons: sounds good to me
<katco> balloons: do you prefer i merge the pre-checked commits first and then $$merge$$ the cherries, or do you want them together?
<balloons> katco, I don't think I care. I don't think merging them all at once will cause issues in the future with merging to the branch. That would probably be my only concern
<balloons> all at once will make it easier from a test perspective
<balloons> so I guess that's my vote ;-)
<katco> balloons: ok, so all at once and then use $$merge$$
<katco> balloons: sounds good to me
<katco> balloons: rick_h_: sanity check: https://github.com/juju/juju/pull/6510
<katco> i am a little confused because i'm seeing commits from nov. 2015, but i'm assuming this is from some kind of long-lived branch that landed
<alexisb_> katco, are they the CMR commits?
<katco> alexisb_: trying to figure out what they are
<katco> alexisb_: yeah, looks like that's it
<rick_h_> katco: cool that looks more like two weeks work from the team ty
<katco> rick_h_: yep, sorry for the trouble
<rick_h_> katco: all good, just glad we caught it before release ty for working on it
<katco> rick_h_: yeah thanks for checking for me
<rick_h_> katco: I'm getting back to the changelog. Where did you end up with the commit line?
<katco> rick_h_: what do you mean commit line?
<rick_h_> katco: what commit was the end of the line?
<rick_h_> katco: if I were to look at develop and judge where to stop for the changelog notes
<katco> rick_h_: oh, one sec
<katco> rick_h_: bebd627
<rick_h_> katco: you've not pushed to 2.0 on upstream yet right?
<rick_h_> katco: cool ty
<katco> rick_h_: no, i need to $$merge$$ looks like prechecks were successful
<rick_h_> katco: cool thanks
<katco> rick_h_: https://github.com/juju/juju/pull/6510 if you're curious
<rick_h_> cool, that might be easier to go through
<katco> balloons: rick_h_: looks like it's all merged
<rick_h_> katco: <3
<mup> Bug #1637267 opened: Juju fails to restore state-server on xenial <ci> <juju-core:New> <https://launchpad.net/bugs/1637267>
<balloons> rick_h_, alexisb I'm bumping develop to 2.1-beta1. We comfortable with that as the "next" version
<alexisb> balloons, I am
<rick_h_> balloons: yes, wfm
<balloons> natefinch, can you review? https://github.com/juju/juju/pull/6511
<balloons> natefinch, this one too :-) https://github.com/juju/juju/pull/6512
<natefinch> yep
<natefinch> LGTM
<natefinch> rick_h_: too much?  Just right? http://i.imgur.com/FAB5rSS.png
<rick_h_> natefinch: yea, would drop the X
<natefinch> aww... I like the X.  damn ascii purists ;)
<rick_h_> :)
<natefinch> seriously, I think the X is nice because it gives a visual indication that doesn't rely on color support for your terminal or your eyes.  But I know that's kind of pushing the envelope in the linux world
<rick_h_> natefinch: right, but it's not something in our "visual language" to date
<rick_h_> natefinch: so I'm hesitate to start adding new ways to indicate "error"
<rick_h_> natefinch: without thinking/doing it thruogh the whole codebase in a clear way
<natefinch> well, we only have a couple interactive commands... but that's ok, it's easy enough to add and remove as needed.
<rick_h_> redir: ping, I hear you have ipv6 on your network?
<rick_h_> redir: e.g. you could in theory ping a public ipv6 address?
<redir> rick_h_: whois me
<rick_h_> whois redir
<redir> Prolly says I'm connected from an ip6 addresws
<rick_h_> redir: can you ping6 2001:4800:7818:104:be76:4eff:fe04:78a6
<redir> yes
<rick_h_> redir: k, ty
<rick_h_> redir: can y6ou also try 2001:4800:7818:104:be76:4eff:fe04:c448 please?
<redir> affirmative
<rick_h_> interesting, every node in rackspace gets a public ipv4 and ipv6 address
<rick_h_> ty redir
<redir> np
<redir> rick_h_: I've had ip6 for ~3years
<redir> in NY and here
<rick_h_> redir: cool
<rick_h_> redir: yea, I think I can get my comcast setup to do dual but not bothered yet. Might be time to investigate that I guess.
<redir> for a while it broke android phones. They stopped reaching the net if they received an ip6 DNS server
<rick_h_> heh, oops
<redir> I didn't do anything.
<redir> just got it one day in NY
<redir> and it is on here'
<rick_h_> oic
<redir> obviously ip4 still works
<redir> and I've been on the same ip4 address for a year, but my ip6 address changes regularly.
<redir> go figure
<rick_h_> heh, that's crazy. You'd think you'd just get one
<mgz> it's probably a feature?
<mgz> like he does actually have a big range, but day to day moves around so people can't find him :)
<mgz> rick_h_: I have a proposed fix for ssh from windows, am going to mail juju-dev with summary
<rick_h_> mgz: ty
<mgz> food first :P
<redir> apparently there's some ipv6 privacy stuff that let's you have multiple addresses, and they change regularly.
<redir> But I've disabled that on my host, because it causes chrom[e|ium] to show network changed errors when it happens
<balloons> wallyworld, if you are said, you should be happy to hear your cherrypicks came in the end
<rick_h_> balloons: <3
<katco> balloons: they were actually part of the correct merge commit all along
<katco> balloons: no picking of cherries required :D
<balloons> lol. nice
<redir> do we already have some simplestreams parsing code somewhere?
<redir> utils or anywhere?
<rick_h_> natefinch: or katco can you help redir please? ^
<redir> I see somethign in environs/
<katco> redir: i saw your question, but i don't know :(
<redir> environs/imagedata
<katco> redir: i would be surprised if we didn't
<katco> redir: wallyworld would probably know
<redir> comparing to uvtool now
<redir> do we actually sync/mirror images in juju anywhere?
<rick_h_> redir: what are you up to?
<rick_h_> redir: I wonder if the context of what you're up to will help with a better answer
<redir> removing dependency on uvtool
<redir> which mirrors cloud server images for creating kvm instances from
<redir> loosely is what I am looking at right now.
<redir> if we already have code to mirror/sync images I'd use it
<redir> lxd does something like that
 * redir goes to look for lxd codee
<redir> layers I imaging
<rick_h_> redir: lxd doesn't do any caching
<redir> whoops
<rick_h_> redir: at this time, it's a feature we want to add
<redir> tx rick_h_ alexisb
<alexisb> perrito666, ping
<perrito666> alexisb: pong
<alexisb> heya perrito666, seems the vsphere updates are causing ci to fail
<alexisb> can you please take a look
<perrito666> sure I can
<alexisb> http://reports.vapour.ws/releases/4535/job/vsphere-deploy-trusty-amd64/attempt/245
<perrito666> alexisb: from the rather unclear output of that test it would seem that it is just taking too long
<balloons> rick_h_, alexisb, are we confident that we'll land something else for 2.0.1?
<perrito666> sinzui: abentley mgz  care to give me a hint?
<balloons> I ask only because https://github.com/juju/juju/pull/6512 landed, and will need reverted. I tried to be as quick as possible
<balloons> but it would mean a little rework in this case if so :-)
<alexisb> balloons, I think perrito666 needs to investigate
<alexisb> balloons, can you help with his inquiry
<balloons> ok, just please note that the version has to be revved back to 2.0.1 if you land something. ok perrito666?
<sinzui> perrito666: that looks like the open connection bug. Juju has exhaused the vsphere resources are repeated tests. we kas larry to restart vshere to relaim the 1000s of connections
<perrito666> balloons: ack
<perrito666> sinzui: can you confirm that using the vsphere dashboard thing?
<sinzui> perrito666: no, because I cannot see it
<perrito666> sinzui: I have seen this work without the failure
<balloons> sinzui, we need larry?
<perrito666> we need something with access to the pannel
<sinzui> perrito666: indeed it does work until resoruce exhaustion. it happens about every 10 days
<perrito666> sinzui: let me rephrase, I have seen juju work without taking resources
<balloons> sinzui, we're trying to decide if this is a blocker
<balloons> sounds like cursed ;-(
<alexisb> perrito666, could we run the test steps manually and see if they pass
<perrito666> alexisb: I guess we could, that is a question for someone in CI though that has both the env setup and knowledge of the tests
<perrito666> alexisb: sinzui has been gracious enough to do these things for me :)
<alexisb> perrito666, sinzui ok, this is currently a blocker for a 2.0.1 release so we will want to make sure we are not blocking needlessly or if there is an issue we need to investigate as a top priority
<abentley> perrito666: Sorry, I'm EOD, but it sounds like you and Curtis have already figured out more than I knew.
<perrito666> abentley: sorry I included you in the initial talk to keep all of QA in the loop, apologies
<abentley> perrito666: np
<axw> balloons: still about? what did you revert? I can't see any revert commits on 2.0
<axw> alexisb: do you know? ^^
<balloons> axw, branch was remade
<balloons> axw, your stuff is in there
<axw> balloons: ok, ta
<balloons> good morning :-)
<axw> good evening :)
<alexisb> perrito666, menn0, ping
<alexisb> redir, ping
<redir> tx
#juju-dev 2016-10-28
<menn0> wallyworld: verbose test output https://github.com/juju/juju/pull/6514
<wallyworld> looking
<wallyworld> menn0: i would even love a make arg to add gocheck.vv
<wallyworld> so that we can diagnose better hung individual tests
<wallyworld> but the change as submitted looks good
<menn0> wallyworld: agreed but -check.vv makes things a bit hard to follow though
<wallyworld> menn0: yeah, i ws thinking of it as a maek arg so that it was off by default
<menn0> wallyworld: interestingly, we already have per package test timings
<menn0> wallyworld: it varies a lot. for run-unit-tests-xenial-amd64 I've seen the state package tests take anywhere from 11mins to 19.2 mins.
<menn0> wallyworld: maybe we just need to bump the timeout
<wallyworld> maybe yeah
<anastasiamac> bumping timeout is kind of like sweeping under the rag... is there really no way we can shorten the time the tests run?
<anastasiamac> rug*
<menn0> anastasiamac: thumper fixed a bunch of unnecessarily long running tests in state recently
<menn0> anastasiamac: I don't think there's much low hanging fruit left
<menn0> anastasiamac: we keep adding functionality and tests so the test time keeps increasing
<axw> menn0: FWIW, in the prometheus metrics I'm gathering from my azure env I can see the effects of periodic txnpruner in terms of deletion ops going up every 2 hours, but there's no corresponding spike in CPU in jujud
<menn0> anastasiamac: it also seems like the test run time is highly variable in the virtualized environments in which we run the tests
<anastasiamac> menn0: i c... so based on the times u've put ^^, what timeout r u thinking? 25min?
<axw> but then I'm not seeing CPU spikes in my env at all
<menn0> axw: ok, so it's probably not that
<axw> menn0: I'm going to try hammering the disk to see if it triggers
<menn0> axw: did you manage to have a look at the logs for the system that is seeing the problem? i.e. is the pruner running for long periods there?
<axw> menn0: I think the log level was set to WARNING, I'll have another look
<axw> menn0: yeah, set to the default of <root>=WARNING
<anastasiamac> menn0: i have a tiny question but it may need context, could u HO or prefer IRC?
<menn0> anastasiamac: i'm easy
<anastasiamac> in standup?
<menn0> anastasiamac: ok
<wallyworld> damn, roofing guys caused my power to drop out. hopefully back now for  bit
<wallyworld> anastasiamac: it's not necessarily sweeping under rug. if there are X tests and each test takes Y time, then the tests will take X*Y to run. there's not much we can do about mgo startup time etc. of couse we can tune tests, but there's only so much that can be done
<natefinch> IIRC, Gustavo said we were doing something stupid with mongo - restarting it for every test or something.  Probably unavoidable per package, but maybe worth looking into to make sure that we're not restarting it for every test?
<wallyworld> i *think* someone did look at that. not retarting has other issues, eg test isolation
<wallyworld> not sure of the final outcome there
<natefinch> heh, I'm running the tests serially to get nicely ordered output and whoo boy, they take a lot longer that way
<natefinch> 35 minutes so far.... 35 minutes so far, and usually it's like... I dunno, 15ish?
<natefinch> heh: 44m31.434s
<anastasiamac> menn0: wallyworld how relevant is this to us now, with new logging/rsyslog in 2.0? https://bugs.launchpad.net/juju/+bug/1562088
<mup> Bug #1562088: flexible /etc/rsyslogd.d/25-juju.conf configuration <canonical-bootstack> <juju:Triaged> <https://launchpad.net/bugs/1562088>
<menn0> anastasiamac: it's not. 1.25 only
<anastasiamac> natefinch: \(ËËË)/
<anastasiamac> natefinch: or even better ã½(Â´oï½ï¼
<anastasiamac> menn0: tyvm
<natefinch> PASS: bakerystorage_test.go:72: BakeryStorageSuite.TestExpiryTime	58.037s
<natefinch> that's one test
<natefinch> PASS: syslog_test.go:220: syslogSuite.TestConfigChange	31.715s
<natefinch> PASS: syslog_test.go:193: syslogSuite.TestLogRecordForwarded	31.731s
<natefinch> PASS: local_test.go:547: localServerSuite.TestStopInstanceSecurityGroupNotDeleted	29.046s
<menn0> natefinch: ouch
<menn0> natefinch: we should get that one fixed :)
 * menn0 is EOW
<dimitern> rick_h_: ping
<rick_h_> dimitern: pong
<dimitern> rick_h_: do you have a few minutes for a quick HO?
<rick_h_> dimitern: otp atm, will have time possiblly before standup or right after
<dimitern> rick_h_: sure
<abentley> balloons: So our candidate for 2.02 is  8fcc982d ?
<abentley> balloons: I mean 2.0.1
<rick_h_> dimitern: free if you want to chat
<dimitern> rick_h_: ok, joining standup HO
<rick_h_> dimitern: rgr omw
<voidspace> mgz: ping
<mgz> voidspace: yo
<rick_h_> dimitern: voidspace natefinch mgz dooferlad ping for standup
<mgz> omw
<voidspace> rick_h_: omw
<katco> natefinch: funny you should send that email out re. tests. i had a test fail bc "`exec /usr/bin/mongod` file not found". i was sad for a bit
<katco> and begrudgingly installed mongo =|
<natefinch> haha
<natefinch> so sad that our "unit" tests depend on installing mongo
<katco> natefinch: well beyond that... why are we trying to *start* mongo by just running the binary if it's not running? just fail and let the user maintain a semblance of control over their machine
<natefinch> katco: good point
<mgz> natefinch: basically, sent message to list just now about ssh from windows client
<mgz> atm my fix uses github.com/andybalholm/crlf to wrap stdin
<mgz> which is probably not enough code to be bothered importing (not even sure I want the golang.org/x/text dep)
<mgz> wondered if you'd come across a modern go idiomatic method of translating newlines
<natefinch> mgz: you can do it pretty easily with just a io.reader wrapper... the naive implementation might be slightly worse performance-wise than that implementation, but this isn't something we're using to read hundreds of megabytes either
<natefinch> I'll make an example, one sec
<mgz> natefinch: ta
<natefinch> mgz: https://play.golang.org/p/aS3IFXBgdl
<mgz> natefinch: thanks!
 * rick_h_ goes to family lunch
<redir> alexisb: ping
<alexisb> heya redir
<alexisb> I am going to go drop off kiddo
<alexisb> but will ping when I am back
<alexisb> redir, ping
<redir> pong
 * redir heads out for a bit.
#juju-dev 2016-10-29
<mup> Bug #1637695 opened: Charm-guide: Openstack on LXD directions do not work <juju-core:New> <https://launchpad.net/bugs/1637695>
#juju-dev 2016-10-30
<axw> wallyworld: are we using mongo 2.4 anywhere still?
<wallyworld> axw: on 1.25
<axw> okey dokey
<axw> menn0: would you mind taking a look at https://github.com/juju/txn/pull/20 when you can?
<menn0> axw: sure, will do after standup
#juju-dev 2017-10-23
<axw> thumper: sorry, didn't realise our 1:1 and moved forward. now conflicts with standup.. can we move it?
<axw> and=had
<blahdeblah> axw: Do you know where I can find more about the fix for https://bugs.launchpad.net/juju-ci-tools/+bug/1634556 ?  I'm seeing the same error trying to bootstrap in GCE on 2.2.5.
<mup> Bug #1634556: autoload credentials fails on google <gap> <juju-ci-tools:Fix Released by mskalka> <https://launchpad.net/bugs/1634556>
<blahdeblah> ^ Or anyone else who happens to be around ...
<axw> blahdeblah: afraid not, sorry
<axw> blahdeblah: based on the people involved on the bug, I'm guessing there weren't any code changes...
<blahdeblah> Hmmm...
<blahdeblah> axw: Any suggestions on how to debug this then?  https://pastebin.canonical.com/201303/
<blahdeblah> Connectivity to www.googleapis.com does not appear to be the problem
<axw> blahdeblah: the source location suggests that the project ID is invalid. are you using a downloaded JSON file for creds?
<blahdeblah> yup
<blahdeblah> Maybe they're expired or something
<axw> blahdeblah: I would've thought you'd get an auth error, but perhaps. can you share the JSON file (with the key redacted)?
<blahdeblah> sure - 1 sec
<blahdeblah> axw: https://pastebin.canonical.com/201304/
<axw> huh
<axw> blahdeblah: mine has a "project_id" field, yours doesn't. the code expects one
<blahdeblah> weird
<axw> ah this is from gcloud. I don't use the gcloud one
<blahdeblah> ?
<blahdeblah> I've pulled some more credentials and they have a project id, so I'll use that
<axw> blahdeblah: I created my creds file via the GCP console. I guess we need to handle those project_id-less creds differently somehow
<blahdeblah> The other JSON file I just downloaded looks very different: {"installed":{"client_id":"413983063871-35g0qo8jt7ea1ofovpj5bhajc9sijhhq.apps.googleusercontent.com","project_id":"ubuntu-os-mirrors-dev","auth_uri":"https://accounts.google.com/o/oauth2/auth","token_uri":"https://accounts.google.com/o/oauth2/token","auth_provider_x509_cert_url":"https://www.googleapis.com/oauth2/v1/certs"}}
<blahdeblah> blah
<blahdeblah> that doesn't seem like a secret
<blahdeblah> or is it?
<blahdeblah> If so, I'd better get it deleted...
<blahdeblah> Yeah - looks like that's the wrong JSON file, with no secrets
<blahdeblah> axw: Created a new service account, it has the project_id, along with the other expected fields, like private key.
<blahdeblah> And trying the bootstrap manually now works
<axw> blahdeblah: yeah not sure what that other one is for, doesn't look very secret at all
<blahdeblah> axw: This is very strange - now I'm getting the following: $ juju bootstrap google my-new-gce-controller
<blahdeblah> ERROR invalid character '/' looking for beginning of value
<blahdeblah> Any ideas?
<blahdeblah> Google searches seem to indicate it's coming from somewhere in the golang runtime
<blahdeblah> possibly the JSON parser: https://stackoverflow.com/a/37492750
<blahdeblah> Weird thing is, if I run the same thing from the command line, it works.  So something's rotten in the state of environment variables.
<blahdeblah> I might be doing something wrong here, but I don't think so, so I'm going to log a bug.
<blahdeblah> https://bugs.launchpad.net/juju/+bug/1726226
<mup> Bug #1726226: bootstrap fails: ERROR invalid character '/' looking for beginning of value <juju:New> <https://launchpad.net/bugs/1726226>
<axw> blahdeblah: sorry missed your message. no ideas sorry, can you please include the credential file (with key redacted)
<blahdeblah> axw: thanks - will add it to the bug
<axw> blahdeblah: is project_id really "project-id", or did you substitute?
<blahdeblah> I substituted
<blahdeblah> sorry - should have made that more obvious
<axw> any / in the real value?
<axw> blahdeblah: ^
<blahdeblah> nope
<blahdeblah> just alphas & dashes
<axw> ok, ta
<axw> wallyworld: might need to talk about these estimates, I don't actually know what all of the line items mean
<wallyworld> axw: i added some commnts to yours, see if they make sense
<axw> wallyworld: so, your estimate for space selection for agent/controller traffic... is that *including* the controller-as-app work?
<wallyworld> axw: yeah, so i think it's too low perhaps
<axw> wallyworld: I've put in some numbers where I think we need more time. the ones I've left out are either OK, or too vague/broad to give an estimate on
<wallyworld> ok, ty, i'll take a look
<wallyworld> it's all a bit habdwavy
<Mmike> Hi, lads - is there a (simple-ish) way to recreate juju environment once I 'juju ssh' into a unit? I can't use 'juju run' as relations are in error state and I need to verify some relation variables across the environment. So before I resort to peeking into the database I wonder can I run 'relation-ids, relation-list, ...' from the unit itself somehow?
<babbageclunk> wallyworld: ping?
<thumper> externalreality: https://github.com/juju/charm/blame/v6-unstable/config.go#L62 still shows the panic...
<thumper> externalreality: is that now what you fixed?
#juju-dev 2017-10-24
<wallyworld> axw: i'm missing somthing for sure - doesn't assigning time.Unix(0,0) to a globalEpoch var mean that the var's value will be stale when it comes to be used?
<axw> wallyworld: it's meant to be constant. it's a fixed point in time (jan 1, 1970)
<wallyworld> ah, doh, ok
<wallyworld> axw: if it is changed to a model where each controller has a clock update worker, is the recovery for the mgo session dying (for whatever reason) just to restart the worker and it picks up a new session?
<axw> wallyworld: that already happens, it'll continue to do that
<wallyworld> ta, just wanted to be sure
<babbageclunk> wallyworld: I'm still having trouble making a local datasource directory - it never seems to pick up the tarball I have under devel/
<wallyworld> i'll have to look at the code to see where it searches for the tarballs
<wallyworld> babbageclunk: it looks in the top level metadata dir
<wallyworld> line 167
<babbageclunk> file?
<wallyworld> toolsmetadata.go
<wallyworld> that's what you are running i assume
<wallyworld> that's my guess anyway without debugging
<babbageclunk> wallyworld: hmm, actually I think they need to be in tools/<stream>/.
<babbageclunk> Thanks!
<wallyworld> ah ok, i'll take your word for it
<wallyworld> been ages since i looked at this stuff
<babbageclunk> wallyworld: Ok, I think that worked - it says it found the file and I can see a new entry for it in com.ubuntu.juju-devel-tools.json
<babbageclunk> wallyworld: why does it have all the entries for other tarballs that I don't have, though?
 * babbageclunk goes for a run in the beautiful sunshine
<thumper> wallyworld: the invite is on jam's calendar, so you could tell him I'll be a little late :)
<jam> wallyworld: how late?
<wallyworld> axw: swap you reviews? https://github.com/juju/juju/pull/7955
<axw> wallyworld: yup, in a little while after lunch
<wallyworld> no worries
<wallyworld> axw: thanks for those pick ups, sad that i missed them first time
<axw> wallyworld: no worries, looking now
<axw> jam: if you're still looking at the lease PR, I've finished up the code and it's now at https://github.com/juju/juju/pull/7957
<axw> jam: wallyworld's already +1'd, but I'll wait till tomorrow before landing. need to do some more heavy testing anyway.
<jam> axw: k
<axw> jam: and thanks for your comments so far, I'm happier with how it turned out as a result
<mup> Bug #1680787 opened: openstack: add support for neutron networks where port security is disabled <serverstack> <sts> <OpenStack Charm Test Infra:Fix Released by 1chb1n> <juju:Fix Released by hmlanigan> <juju-core:New> <https://launchpad.net/bugs/1680787>
<balloons> jam, you are thinking 2.2.6 with force upgrade?
<mup> Bug #1726945 opened: [2.3] consume feature hard to manage <docteam> <juju-core:New> <https://launchpad.net/bugs/1726945>
<jam> balloons: I'm not sure that 2.2.6 would be needed for just this. More that it is trivial to do in a 2.2 so we might as well target it, in case there is something that *does* warrant 2.2.6
<jam> balloons: as for you're version question, i'm not positive, I'll try to give it a look. I thought what I saw was someone trying to go to 2.2.5 using a 2.2~rc2 binary, and there 2.2~rc2 is definitely older than 2.2.5
<balloons> jam, right. I seem to remember it was saying 2.2~rc2  was greater than 2.2.5.. probably useful just to include a unit test for beta and rc versions so we know it behaves properly
<balloons> not a big deal in the sense this will skip that check, heh
<jam> balloons: IIRC we had a bug in the past where the "greater than" was given the wrong way around
<jam> the check was correct, but the message was backward
<balloons> jam, lol, hah. Ok, that may have been all it was then. Either way, that stuff is easy to mix uop
<wallyworld_> balloons: thumper: release call?
<wallyworld_> babbageclunk: hey! at some time today, would appreciate a fairly simple review. a bit of boiler plate since a new facade method is added https://github.com/juju/juju/pull/7960
<babbageclunk> wallyworld_: sure!
<babbageclunk> wallyworld_: looking nwo
<babbageclunk> now
<wallyworld_> yay, ty
<babbageclunk> wallyworld_: looks good - kind of depressing how much boilerplate we need to expose one state method though.
<babbageclunk> (This is not a new observation, obvs)
<wallyworld_> babbageclunk: yeah, agreed
<babbageclunk> Browser's hung - I can hear you but not see or unmute to talk
<babbageclunk> wallyworld: anyway, I'll try to grab you in a bit.
<wallyworld> ok
#juju-dev 2017-10-25
<axw> wallyworld: can you please take a look at https://github.com/juju/juju/pull/7957/commits/54d403ce8feb2ef80b58aca4f05af2890769716b? does the upgrade for leases
<axw> jam: do you have time to look at that commit above? ^
<jam> looking
<axw> heh, looks like bionic has been added to the releases file, and now all the tests are failing in CI
<Mmike> is this a bug: http://paste.ubuntu.com/25815668/
<Mmike> that model remains in 'destroying' state after being destroyed?
<Mmike> hello, btw :)
<axw> Mmike: not a bug, the model will show up as "destroying" while it's being cleaned up. when cleanup is complete, it should be removed. it has 0 machines though... maybe there's some storage?
<axw> jam: tests/CI will fail until we fix utils/series so we stop selecting Bionic as the latest LTS. I've got a PR here: https://github.com/juju/utils/pull/288
<axw> jam: ideally we'd consider it LTS but notice that it's pre-release and don't use it as "LatestLts", but I don't think it matters in practice
<Mmike> axw, nope, none. It's against openstack provider - but, I just rechecked, and both of them are gone :)
 * axw has to go help with kids and have dinner
<axw> Mmike: ok, must've looked at just the right time :)
<axw> there's delays with workers doing cleanups
<Mmike> yup :)
<Mmike> all good, sorry for the noise!
<axw> no worries
<jam> axw: currently in a meetting, so hard to review, though I do want to get a patch in
<axw> jam: np. if you get to it later and it looks OK, please merge - I'm off to have dinner
<jam> axw: enjoy your evening
<axw> thanks
<renier> hey, looking for docs on adding support to juju for a new cloud platform. appreciate pointers.
<thumper> morning
<mup> Bug #1727507 opened: [2.3] rationalize offer commands <docteam> <juju-core:New> <https://launchpad.net/bugs/1727507>
<thumper> jam, balloons: is this now done? https://bugs.launchpad.net/juju/+bug/1727407
<mup> Bug #1727407: Bionic series support <cdo-qa-blocker> <sts> <uosci> <juju:New> <https://launchpad.net/bugs/1727407>
<balloons> thumper, https://github.com/juju/juju/pull/7964
<balloons> 2.2.6 will have bionic agents
<balloons> thumper, also, good morning, and welcome to the fun that is today
<mup> Bug #1680787 changed: openstack: add support for neutron networks where port security is disabled <serverstack> <sts> <OpenStack Charm Test Infra:Fix Released by 1chb1n> <juju:Fix Released by hmlanigan> <juju-core:Won't Fix> <https://launchpad.net/bugs/1680787>
<babbageclunk> wallyworld: ping?
<wallyworld> hey, in release call
<wallyworld> babbageclunk: free now
<babbageclunk> wallyworld: time for a hangout? 1:1?
<wallyworld> sure
<babbageclunk> I mean, do you have, not it's
 * thumper running cat down to the vet
<thumper> bbs
#juju-dev 2017-10-26
<axw> hml: woot :)
<hml> very happy!
<axw> wallyworld thumper: I've been through the sizings again. question mark on update-status, needs some spec to figure out what a decent approach is. other than that, I think wallyworld's numbers are fine, but I bumped a few up
<thumper> axw: thanks
<wallyworld> +1
<anastasiamac> axw: fwiw, we had put some details in our sizing with jam... did u see these?
<axw> anastasiamac: yes, thanks
<anastasiamac> \o/
<babbageclunk> wallyworld: ping?
<wallyworld> hey
<wallyworld> babbageclunk: pong
<babbageclunk> doh, didn't get a notification for some reason
<wallyworld> that happens to me too
<babbageclunk> wallyworld: sorry ^. I'm having to hack no-neutron support into the test doubles in goose.
<babbageclunk> wallyworld: is this worthwhile?
<wallyworld> hmmm. there's no easier way?
<babbageclunk> wallyworld: thought I'd check before I got too far down the rabbit hole.
<wallyworld> we can't use a monkey patch to simulate lack of neatron?
<babbageclunk> Hmm. Maybe by registering a control point for authorisation to chop it out?
<babbageclunk> I'll try that
<babbageclunk> hang on
<wallyworld> yeah that
<wallyworld> or return an error that triggers the switch to nova in juju
<wallyworld> via the control point mechanism
<wallyworld> jam: hey, i'd like to land that network-get PR. are you able to +1?
<jam> wallyworld: so the *big* point is that I don't think creating a "public" space is really going to do what you think it will in 2.3
<jam> now, whether its still the best compromise that we can think of. I was hoping wpk would give it a look, but it seems he was overloaded with other things yesterday.
<jam> I'll check in again with him in about 10 min
<jam> I'll give the code a look as well.
<wallyworld> ok. i'm not sure why you think creating a space containing subnets from which a public address may be selected won't work. bear in mind though that is optional - just don't bind to anything if you want juju to choose a public address if one is available
<wallyworld> you bind the endpoint to a space if you *don't* want a public address to be used
<wallyworld> so the user has control of how their offer is consumed
<jam> wallyworld: if you don't bind at all, then you can't select a subnet
<jam> You might have carved several subnets that don't have public access because you want them to be for your database
<jam> so you need other subnets that *do* have public access, and thus you want to *select* them so you don't accidentally provision in the ones that don't have public
<jam> that doesn't mean your patch can't land, but it is a discrepancy between what we want to have and what we currently have
<axw> wallyworld: FYI, I'm looking at https://bugs.launchpad.net/juju/+bug/1724673
<mup> Bug #1724673: unable to destroy-model with offer in it <cross-model> <juju:In Progress by axwalk> <https://launchpad.net/bugs/1724673>
<wallyworld> jam: if you don't bind, juju will try and select the machine public address to set as the ingress address. if you want to control what address juju uses, bind to a space
<wallyworld> ie you need to decide an an offerer if you want your offer to be public or not
<wallyworld> axw: awesome, thanks for picking up that bug
<jam> wallyworld: my point is, if I have created 2 subnets on AWS, one that has public internet and one that doesn't. if I don't bind *at all* then Juju randomly selects which subnet it will use
<jam> and *might* pick the one that has a public address, so that I can create a public offer
<jam> or might not
<wallyworld> jam: no it won't it will use the public address
<jam> wallyworld: if you deploy to subnet-b *it has not public address*
<wallyworld> it calls machine.PublicAddress()
<jam> wallyworld: AWS Subnets can have a "create public address" flag
<wallyworld> right but using spaces and hence subnets is your choice
<jam> wallyworld: so if you can't bind, then you can't say "Make sure to use these subnets that have public addresses"
<wallyworld> i'm missing something it seems - i thought in aws, gce etc - all machines got  apublic address
<wallyworld> and m.PublicAddress() would return that
<wallyworld> and that's what we use in the absense of a binding
<jam> wallyworld: see above. There is a flag on a subnet that says "should machines in this subnet get a public address"
<jam> you can set that to false
<jam> which is what you *want* for your Database
<jam> because PCI says that database machines can't have public ingress
<wallyworld> not if you are offering it for public consumption
<jam> wallyworld: and yes, I don't want to make my db public
<jam> but I want my website public
<jam> and I can't have it use the database subnet
<jam> so I want to select the subnet that has public addresses associated with it
<wallyworld> so you can do that just fine
<jam> wallyworld: how do I tell it not to use the database subnet without binding?
<wallyworld> bind the website endpoint to a space with public addresses and the website db endpoint to a different space
<wallyworld> or just bind the db endpoint
<jam> wallyworld: you just said that if I bind it to the space that includes the subnet that has public addresses it will get the locally bound subnet address
<jam> I have the interview in 10, so I have to go prep, but I'll chat with you about this after
<wallyworld> ok, sounds good, i think we are at cross purposes
<jam> wpk was oversleeping, so I'll try to get his attention later as well
<wallyworld> ok
<wallyworld> axw: i think ChangeIngressRules() in sshInstanceConfigurator is wrong? the param should be -A and not -I ?
<wallyworld> when i try with -I it fails, but -A works fine
<wpk> you mean iptables -I fails?
<axw> wallyworld: sorry gotta take charlotte to ballet, I can take a look when I get back. that thing is an abomination
<wallyworld> wpk: yeah, but -A works, eg sudo iptables -d 192.168.1.1 -A INPUT -p icmp --icmp-type 8 -j ACCEPT
<wallyworld> that works but -I doesn't
<wpk> whaaa?
<wpk> works for me
<wallyworld> hmmm
<wpk> how it fails?
<wallyworld> i sshed into an aws instance and confirmed there also
<wallyworld> wpk: wtf, i just tried it again and it worked
<wallyworld> last time i got an error message about chained rules or something
<wallyworld> nfi
<wpk> wallyworld: It got scared that I'll start to debug it. It's called respect.
<wallyworld> lol
<wallyworld> wpk: if you had time for a smallish review at some stage, https://github.com/juju/juju/pull/7969
<wpk> I'd call it icmp-ping
<wallyworld> the sec group calls it just icmp
<wallyworld> a single word is better IMO
<wallyworld> it's also icmp in iptables
<wallyworld> easier to type udp or tcp or icmp
<wpk> it's icmp type 8
<wpk> (in iptables)
<wallyworld> ACCEPT     icmp --  0.0.0.0/0            10.0.0.1     icmptype 8
<wallyworld> the prot column is icmp
<wpk> but there's icmptype 8
<wallyworld> but that's not in the prot column
<wpk> you're not accepting any icmp, just type 8 (echo)
<wallyworld> the type is not specified in the sec groiup is it?
<wallyworld> that example was just for iptables, when you open an ip rule in a sec group you just say icmp
<wallyworld> the iptables list has these headers: target     prot opt source               destination
<wallyworld> the prot values are "icmp" or "tcp" or "udp"
<wallyworld> and that's what we specify for IpPerm in aws for example also
<wallyworld> we don't specify the sub type
<wpk> But just like you're opening a port in tcp/udp here you're saying you're opening "icmp" and only opening one type of it(echo). I'm being pesky, I know....
<wpk> but LGTM
<wpk> (just there might be someone who'll say that he wanted to open ICMP and only got pings :)
<wallyworld> wpk: but we don't specify that we're just opening one type for clouds. the only place we do that is that stupid configurator. i guess i could remove the type from there
<wpk> I wonder how it works on AWS. Anyway, as above - LGTM as is.
<wallyworld> ok, ty
<babbageclunk> jam: could you take another look at https://github.com/juju/juju/pull/7962 plz?
<axw> wallyworld: my PR has a bug in it, but highlighted an issue with the relation counting in applicationOffers.Remove. it's possible for a relation to a non-remote application to be removed, and replaced with one to a remote application, and the offer would still be removed
<axw> would/could
<wallyworld> oh oops
<axw> wallyworld: I've just pushed, see state/applicationoffers.go for my TODO(axw)
<axw> I'll take a look at fixing that tomorrow
<wallyworld> ty, luckily we shouldn't have people hitting this yet
<wallyworld> jam: not sure if you saw my last comment on the pr. if we can accept the current behaviour, i'd like to land it tonight so it makes beta2
<wallyworld> without the pr, things are sub optimal in a different way - i believe the pr makes things better for more cases we care about
<wallyworld> you either want your db publiclly available as an offer or you don't - we support that scenario fine
<wpk> damn, I hate fixing tests in state/..
<wallyworld> don't we all :-)
<jam> so who wants to be a review buddy for mgopurge: https://github.com/juju/mgopurge/pull/22/files
<jam> that one is fairly straightforward, at least
<wallyworld> jam: lgtm
<wallyworld> jam: did you get to ask for a 2nd opinion on the network-get PR?
<wallyworld> running out of time to land for beta2
<jam> I did, though it seems he hasn't gotten to that, ran into other bugs.
<wpk> wallyworld: LGTM for now
<wallyworld> ty, we can iterate
<wallyworld> i do believe it's a step forward
<wallyworld> not perfect yet
<wallyworld> i did get the nagios stuff all working today though
<jam> wallyworld: is it possible to check if there is a public address corresponding to a given space, rather than just whether there is a binding, or we just don't have that information
<jam> we probably don't track a link anyway
<jam> anywhere
<wallyworld> jam: yeah, we don't model that IIANM
<jam> I, Ian, Man ? :)
<wpk> jam: Someone recently used 'OIC', I had to look it up in Acronym Finder. The first answer does not seem to be correct...
<jam> O I C, yeah
<wallyworld> If I Am Not Mistaken
<wallyworld> :-)
<jam> wallyworld: yeah, I figured it out, I just figured I'd play with it.
<jam> its not one I use regularly
<jam> IIRC is usually what I use there
<wallyworld> wpk: so you ok for me to merge?
<jam> looking over it now, myself
<wallyworld> ok, ta
<jam> wallyworld: I had one comment on it, where you took out a fallback to unit.PrivateAddress() if len(NetworkInfo) == 0
<jam> wallyworld: aside from the fallback issue, I think lgtm
<wallyworld> jam: ty, i'm rereading the code, but it was intentional as it wasn't needed in that place anymore
<jam> k
<wallyworld> jam: we now rely on the behaviour in GetNetworkInfoForSpaces(0 to "Do The Right Thing" with regard to populating the bind addresses.
<wallyworld> the ingress address still falls back to using private addressfor the default space if it's cross model
<wallyworld> and if not, we select the first bind address
<jam> babbageclunk: reviewed
<wallyworld> externalreality_: i have 10 mins now if you want to chat
#juju-dev 2017-10-27
<wallyworld> babbageclunk: were you looking at the sig file stuff for beta2 release?
<babbageclunk> yup, just finished it off - I'll put the PR up while I'm doing a manual test.
<wallyworld> yay, ty
<axw> wallyworld: small fix for offer removal: https://github.com/juju/juju/pull/7976
<wallyworld> ty, looking
<babbageclunk> wallyworld: https://github.com/juju/juju/pull/7977 as well
<wallyworld> babbageclunk: ty, looking after my 1:1 with andrew
<babbageclunk> cool cool
 * babbageclunk goes for a run
<wallyworld> babbageclunk: just a small test change
<babbageclunk> wallyworld: thanks, fixed - merging now.
<wallyworld> babbageclunk: no worries
<anastasiamac> thumper: wallyworld: axw: modelstatus fix - https://github.com/juju/juju/pull/7979... since it's kind of not-small and highly visible/usable, I think I'd need at least 2 reviews...
<axw> anastasiamac: looking after lunch
<anastasiamac> axw: tyvm
<wallyworld> anastasiamac: +631/-179 is but a babe in the woods compared to some lately :-)
<anastasiamac> wallyworld: m glad to hear that my PR does not scare u... m not sure how i feel about the fact that big PRs r becoming more frequent
<wallyworld> :-)
<jam> anastasiamac: revewed
<anastasiamac> jam: \o/ thnx
<jam> morning
<jam> doesn't seem like a PR that needs 2 reviews
<anastasiamac> jam: k, m happy(ier) to have just one review (ur definition of weekend is very different to mine)
<jam> anastasiamac: what, I woke up, like an hour later, went to the grocery store, will be going out for lunch
<jam> how is that not a weekend?
<anastasiamac> jam: bestversion check on cmd is needed for cases where u r using new client against an older controller (if it ever happens) as we'd come to result.Error and will panic/err since Error would not exist in returned results...
<jam> anastasiamac: no, because your api/* code forces a result.Error => result[i].Error, doesn't it?
<jam> so you've already made sure that every object has a .Error set
<wallyworld> jam: i'd like to discuss your +1 to the pr - i don't agree with the approach
<wallyworld> i can't see a reason to not have the api layer present the same interface for either a v3 or v4 backend
<wallyworld> we control the call sites for the api layer so we can make everything hang othether as it should
<wallyworld> anastasiamac: jam: axw: happy to discuss in a hangout to ensure we're all on the same page, maybe easier than irc
<anastasiamac> wallyworld: +1, gimme 10mins?
<wallyworld> sure
<jam> wallyworld: I thought she did have the api/ layer push the global error into the each object Error
<jam> did I misread that?
<wallyworld> maybe i did, left me check
<wallyworld> jam: see line 84 in processModelStatusResultsV3
<jam> line 61 of processModelStatusResults
<jam> the part where we were talking about Trace
<wallyworld> that's for the v4 facade
<wallyworld> not the old v3
<jam> wallyworld: ah k. in that case, update v3 to set the error, and I think we're happy
<wallyworld> modulo that we don't need a separate processv3 method perhaps
<wallyworld> since v3 will just return an overall error anyway
<wallyworld> and if we do get results we just process them with the one method
<wallyworld> and we need to check but i thought jimm calls this api also so we'll need to update that code as well, or organise for it to be updated
<jam> so I think we're roughly aligned, in that api/* should provide a consistent view of errors, and then all the client code doesn't need BestVersion.
<jam> wallyworld: as a Controller facade, it should have some sort of implementation for it
<wallyworld> right, so we'll break them if they compile against tip
<jam> wallyworld: though if they did it correctly, we just treat JIMM as an older controller
<anastasiamac> wallyworld: jam: axw: want to take it to team standup from this morning?
<wallyworld> or in any case, we'll need to get them to update
<wallyworld> sure, ok
<jam> https://hangouts.google.com/hangouts/_/canonical.com/juju-standup?authuser=1 ?
<anastasiamac> jam: yes
<anastasiamac> wallyworld: ?
<ryebot> What happened to the --upload-tools flag on the juju bootstrap command? What's the right way to replicate that functionality today?
<dvavili_> Not sure if it's the right channel, but can Juju be used to deploy P3 instances on AWS that was announced a couple of days back?
#juju-dev 2017-10-29
<wallyworld> ryebot: juju will automatically upload a local agent binary if there's no matching binaries found online at streams.canonical.com
<blahdeblah> wallyworld: mostly :-P
<wallyworld> that's the intended behaviour unless there are bugs
<wallyworld> it's always worked for me
<wallyworld> i've never seen it not upload a local binary if it can't find one
<wallyworld> incorrect streams data is not a jju bug btw
