#juju-dev 2012-11-05
<mcclurmc> rogpeppe: hey, i just finished that intro to go and juju blog we talked about
<mcclurmc> rogpeppe: http://mcclurmc.wordpress.com/2012/11/05/go-lang-and-juju/
<rogpeppe> mcclurmc: i'm just reading it!
<mcclurmc> awesome
<rogpeppe> mcclurmc: looks good
<mcclurmc> should i spam the juju list about it?
<rogpeppe> mcclurmc: i think you should explain the ... wildcard feature of the go command, as you use it quite a bit
<rogpeppe> mcclurmc: in fact the "go doc launchpad.net/.../ec2" example should perhaps be "go doc launchpad.net/goamz/ec2" to avoid confusion
<rogpeppe> mcclurmc: BTW version pinning is often done by importing code locally and renaming the package path. another alternative is to put the version into the package path (e.g. labix.org/v2/mgo)
<rogpeppe> mcclurmc: other than the above minor comments, this looks great - i'd post to both the juju list and the juju-dev list
<mcclurmc> rogpeppe: my irc proxy lost the minor comments you had. could you repeat them?
<rogpeppe> 10:56:56] <rogpeppe> mcclurmc: i think you should explain the ... wildcard feature of the go command, as you use it quite a bit
<rogpeppe> [10:58:29] <rogpeppe> mcclurmc: in fact the "go doc launchpad.net/.../ec2" example should perhaps be "go doc launchpad.net/goamz/ec2" to avoid confusion
<rogpeppe> [11:00:11] <rogpeppe> mcclurmc: BTW version pinning is often done by importing code locally and renaming the package path. another alternative is to put the version into the package path (e.g. labix.org/v2/mgo)
<rogpeppe> [11:00:48] *** mcclurmc is now known as mcclurmc_away.
<rogpeppe> [11:00:58] <rogpeppe> mcclurmc: other than the above minor comments, this looks great - i'd post to both the juju list and the juju-dev list
<mcclurmc> rogpeppe: cool, i'll make the changes and post to the lists. thanks!
<rogpeppe> mcclurmc: one other thing - you could also mention something about the changes required to environments.yaml
<rogpeppe> mcclurmc: and perhaps you could end by bootstrapping a juju instance...
<rogpeppe> mcclurmc: assuming that succeeds, of course :-)
<mcclurmc> rogpeppe: yes, that would be a good idea. i need to create an ec2 account since the local lxc doesn't work
<rogpeppe> mcclurmc: yes, that's true - an unfortunate current limitation
<rogpeppe> davecheney: yo!
<mcclurmc> rogpeppe: i just made those changes. instead of giving a juju bootstrap howto, i linked to https://juju.ubuntu.com/docs/getting-started.html
<rogpeppe> mcclurmc: cool
<SpamapS> does juju-core just log everything to syslog?
<SpamapS> oh please oh please tell me it does
<rogpeppe> SpamapS: i wish it did
<rogpeppe> SpamapS: but it doesn't
<rogpeppe> SpamapS: it writes to /var/log/juju/*
#juju-dev 2012-11-06
<davecheney> le sign
<davecheney> sigh
<davecheney> us-east-1 is 260ms from me
<davecheney> ap-southeast-1 is 160-180
<davecheney> hardly rocking
<rogpeppe> fwereade: mornin'
<fwereade> heya rogpeppe
<fwereade> morning TheMue
<TheMue> heya fwereade
<Aram> moin.
<TheMue> Moin Aram
<rogpeppe> Aram, TheMue, mramm: hiya
<mramm> rogpeppe: hiya
<TheMue> hi rogpeppe
<mramm> rogpeppe: early morning for me (5:40 here)
<TheMue> mramm: where are you now? lost between copenhagen and you home town?
<rogpeppe> mramm: can't sleep? or inconvenient meeting time?
<TheMue> mramm: ah, home town
<mramm> TheMue: home town now
<mramm> rogpeppe: yea, still on copenhagen time
<rogpeppe> lunch
 * Aram curses in anger
 * fwereade makes vague but soothing and conciliatory noises
<Aram> is this known?
<Aram> firewaller_test.go:712:
<Aram>     s.assertEnvironPorts(c, []state.Port{{"tcp", 80}})
<Aram> firewaller_test.go:71:
<Aram>     c.Fatalf("timed out: expected %q; got %q", expected, got)
<Aram> ... Error: timed out: expected ["tcp:80"]; got ["tcp:80" "tcp:8080"]
<Aram> meeh
<Aram> of course the "simple" watcher niemeyer "fixed" because mine was too complex and submitted even when I said it wasn't good doesn't work correctly.
<fwereade> Aram, sorry, I haven't seen that one
<TheMue> Aram: Interesting, I'm just looking. So far it worked.
<TheMue> Aram: Here it passes, just took a fresh branch of the current trunk.
<Aram> yeah, it passes with trunk, it doesn
<Aram> 't pass with the machine units watcher instead of the old machine principals units watcher
<TheMue> Aram: Strange ...
<Aram> fwereade: around?
<fwereade> Aram, for a few moments, what can I do for you?
<Aram> fwereade: the firewaller assumes the machine units watcher will report changes in unit port settings.
<fwereade> Aram, ha, interesting
<Aram> it seems sensible to me to allow the machine units watcher to return any change in any attribute rather than only changes in lifecycle.
<Aram> and the client can filter things out.
<fwereade> Aram, that seems like a sane alternative to one-watcher-per-unit
<fwereade> Aram, I think I'm +1 on that
<Aram> cool.
<fwereade> Aram, I am well used to assuming that changes may not be relevant
<fwereade> Aram, the main thing is having everyone agree on what changes should be reported
<Aram> yeah.
<fwereade> Aram, and honestly the "right" thing is irritatinglysituational
<fwereade> Aram, eg I *think* the uniter would work OK given extra service relations events but it was written against the current implementation
 * rogpeppe has just emerged from an irritatingly long dive into the openssl source, just so i can work around the fact that mongod can't read an unencrypted PEM file.
 * rogpeppe is off for the night. see y'all tomorrow
#juju-dev 2012-11-07
<fwereade> davecheney, heyhey
<rogpeppe> fwereade, davecheney: morning'
<fwereade> and rogpeppe, also heyhey
<fwereade> and TheMue :)
<TheMue> fwereade: morning, and who else? ;)
<fwereade> TheMue, dave and rogpeppe
<TheMue> fwereade: ah
<rogpeppe> i have only just opened up the computer, to be fair :-)
<TheMue> davecheney: hello and rogpeppe: heya
<rogpeppe> TheMue: yo@
<rogpeppe> !
 * TheMue too
<rogpeppe> my fingers still aren't working too well
<davecheney> hello
<fwereade> davecheney, and possibly rogpeppe, I was meaning to ask
<fwereade> davecheney, rogpeppe: is it just a tools problem that's blocking non-precise deploys?
<rogpeppe> fwereade: yes
<rogpeppe> fwereade: AFAIK
<davecheney> fwereade: i have a proposal for that
<fwereade> davecheney, rogpeppe: in that case ISTM that davecheney's approach is sane
<rogpeppe> fwereade: we just need to compile mongodb for quantal
<rogpeppe> fwereade: at least, that was the blocker i saw
<davecheney> rogpeppe: i'm only considering deploying from quantal -> LTS
<fwereade> rogpeppe, ah, ok, makes sense
<davecheney> we can consider the other permutations another day
<rogpeppe> davecheney: we want to be able to do LTS -> quantal too
<davecheney> but making a quantal/raring mongo will enable that
<davecheney> rogpeppe: we *might*
<davecheney> i haven't seen a request for that yet
<rogpeppe> davecheney: so that we can run the builddb charm for quantal from precise
<davecheney> rogpeppe: what is the story with mongo
<fwereade> davecheney, we want to be able to deploy to and from anything basically
<davecheney> fwereade: sure, i agree, but i'm only focusing on things we *need* this week
<davecheney> wants can come later :)
<rogpeppe> davecheney: we just need to build a quantal version
<davecheney> rogpeppe: i thought we were screwed on licencing
<fwereade> davecheney, that's fine indeed :)
<rogpeppe> davecheney: i haven't heard that - what's the story?
<davecheney> rogpeppe: mark saied we aren't allowed to distribute that binary
<rogpeppe> davecheney: the mongo binary?
<davecheney> ja
<rogpeppe> davecheney: well we're fucked then
<davecheney> yes
<davecheney> is mark working this week ?
<davecheney> rogpeppe: ideally if we could get a 2.2 backport into the archive
<davecheney> that would solve our problem
<rogpeppe> davecheney: how would that help?
<rogpeppe> davecheney: and how come we're allowed to distribute the binary via apt-get ?
<davecheney> rogpeppe: as I understand it the current mongo in precise has TLS enabled
<davecheney> is that correct
<davecheney> ?
<rogpeppe> davecheney: i dunno. i don't think so, but i'll check
<davecheney> rogpeppe: if so, the licencing issue becomes someone elses' problem
<davecheney> we just ride on the archives' coat tails
<rogpeppe> davecheney: no the default version does not have tls enabled
<davecheney> rogpeppe: right, back to being screwed then
<rogpeppe> davecheney: i thought AGPL allowed distribution in binary form
<davecheney> openssl is not AGPL :(
<davecheney> and by linking statically to it
<davecheney> we polute the binary
<davecheney> but, we might get lucky as the source of the program that builds the binary is available
 * davecheney IANAL
<rogpeppe> davecheney: we weren't planning to link to openssl, were we?
<rogpeppe> davecheney: ah, of course
<rogpeppe> davecheney: mongo itself
<rogpeppe> doh!
<davecheney> welcome to open sores licencing shitfighting
<rogpeppe> davecheney: openssl is so shit internally too. not worth fighting for.
<rogpeppe> davecheney: the license doesn't seem too onerous actually: http://www.openssl.org/source/license.html
<rogpeppe> davecheney: (either of them)
<rogpeppe> davecheney: "
<rogpeppe> Actually both licenses are BSD-style
<rogpeppe>   Open Source licenses.
<rogpeppe> "
<davecheney> rogpeppe: I need mark to respond
<davecheney> but for the moment lets assume we're in the clear
<rogpeppe> davecheney: it looks like we should be. those licenses don't seem to disallow anything other than redistributing without the license
<rogpeppe> davecheney: oh, here's the issue: http://people.gnome.org/~markmc/openssl-and-the-gpl.html
<davecheney> right, openssl is bsd 3 clause
<davecheney> am i correct ?
<rogpeppe> davecheney: yeah
<rogpeppe> davecheney: so it imposes some restrictions (you must distribute acknowledgements) that GPL doesn't allow you
<rogpeppe> davecheney: what a mess
<davecheney> sounds like the Apache Harmony vs the Java TCK nonsense
<rogpeppe> davecheney: i don't know about that
 * rogpeppe googles
<davecheney> rogpeppe: http://en.wikipedia.org/wiki/Apache_Harmony#Difficulties_to_obtain_a_TCK_license_from_Sun
<davecheney> almost identical story to the one above
<davecheney> to do X, we need Y, but using Y implys we can't be X
<davecheney> error: Failed to load data for project "juju-core": Get https://api.launchpad.net/devel/juju-core: EOF
 * davecheney shakes fist at LP
<rogpeppe> davecheney: if either mongodb or openssl were reasonable pieces of code, it should not be hard to do a GPL-compatible replacement for the way that mongo uses it
<rogpeppe> davecheney: sadly both are convoluted to hell
<davecheney> so i have heard
<rogpeppe> davecheney: i spent a significant proportion of yesterday delving deeply into the openssl code
<rogpeppe> davecheney: so i could find a particular constant
<rogpeppe> davecheney: to implement x509.Encrypt
<rogpeppe> oops
<rogpeppe> davecheney: to implement x509.EncryptPEMBlock
<rogpeppe> davecheney: because mongo does not support reading unencrypted PEM blocks
<rogpeppe> davecheney: it epitomises everything that's wrong with C-as-it-has-turned-out
 * davecheney pats rogpeppe on the shoulder
<davecheney> i bet it's a rats nest of macros and #ifdefs
<rogpeppe> davecheney: yup
<rogpeppe> davecheney: and unnecessary layers of abstraction
<rogpeppe> davecheney: so this issue means that none of the Go source code is GPL-compatible AFAICS
<rogpeppe> davecheney: and i always thought the BSD license was the less restrictive one
<davecheney> rogpeppe: it is a modified 2 arg, right ?
<rogpeppe> davecheney: well, i guess it is, but just an incompatible set of restrictions
<rogpeppe> davecheney: "Redistributions in binary form must reproduce ..."
 * davecheney checks
<davecheney> i don't know enough about this stuff
<davecheney> i'm not sure i want to ,either
<rogpeppe> GPL should allow components to add copyright notice distributions
<rogpeppe> i'm sure that this incompatibility is against its original aims
<davecheney> rogpeppe: i think go is ok in this respect
<davecheney> the wording in the 2nd clause in
<davecheney> http://golang.org/LICENSE
<davecheney> differs from the complaint in http://people.gnome.org/~markmc/openssl-and-the-gpl.html
<rogpeppe> "
<rogpeppe> You may not impose any further
<rogpeppe>   restrictions on the recipients' exercise of the rights granted herein.
<rogpeppe> "
<davecheney> oh for fucks sake
<rogpeppe> the 2nd clause in the go license seems like it does that
<rogpeppe> yeah
<davecheney> maybe this is an ordering issue
<davecheney> the order in which you stack licences would allow for some interesting permutations
<rogpeppe> davecheney: so you can't distribute a Go program that links against a GPL program, but you can distribute a Go program as GPL
<rogpeppe> davecheney: that kinda makes sense
<davecheney> sounds like witchcraft
<rogpeppe> davecheney: i see now how 10gen make money
<davecheney> you can't sell wisky with water in it, but you can pour wisky over ice
<davecheney> or something
<davecheney> rogpeppe: for 10gen i imagine it is more about indemity
<davecheney> or providing indemnity to their customers
<davecheney> which is a massive issue for the more regulated companies in our industry
<rogpeppe> davecheney: i doubt it - why else would they sell the OpenSSL version separately?
<rogpeppe> davecheney: well, i'm sure indemnity is part of it too
<davecheney> you are probably right, heinoius money grabbing
<rogpeppe> davecheney: actually, this just might be a good thing
<davecheney> mmm
<rogpeppe> davecheney: actually.... i think we're all ok
<rogpeppe> davecheney: AGPL != GPL
<rogpeppe> davecheney: see http://www.gnu.org/licenses/agpl-3.0.html section 7
<rogpeppe> davecheney: "you may [...] supplement the terms of this License with terms: [...] requiring preservation of specified reasonable legal notices or author attributions in that material or in the Appropriate Legal Notices displayed by works containing it; "
<davecheney> the source of Juju is AGPL, i dunno if that applies to a file we reference in binary form
<rogpeppe> davecheney: mongo license is AGPL
<davecheney> orly
<rogpeppe> davecheney: which i'd always thought of as more restrictive than GPL, funnily
<davecheney> it's more free, which depends on your POV
<rogpeppe> davecheney: anyway, by my reading of it, we *can* distribute mongodb binaries :-)
<rogpeppe> davecheney: IANALBASOTI
<davecheney> sounds good enough for now
<davecheney> yes, everyone in the chan who is a lawyer, raise your hand
<davecheney> rogpeppe: so, where does that leave us
<davecheney> mongo == good
<rogpeppe> davecheney: yeah
<rogpeppe> davecheney: AGPL == good
<davecheney> but you're getting screwed over by certs
<rogpeppe> davecheney: that's fine, go needs EncryptPEMBlock anyway
<rogpeppe> davecheney: although it is annoying
<Aram> hello.
<TheMue> Aram: hi
<hazmat> rogpeppe, we do have lawyers avail
<hazmat> mramm, was looking into it afaicr
<rogpeppe> hazmat: i just wanted to assure myself that all was not lost :-)
<mramm> hazmat: rogpeppe: well we can move to encrypted channels in the rest API
<rogpeppe> mramm: what about the channels from the API servers to the mongodb servers?
<mramm> the thing there is that you could snoop data if you can snoop the network
<mramm> right
<mramm> you wouldn't have control, just access to data, which is not great, but probably not catastrophic
<rogpeppe> mramm: if you can change network packets, you have control
<mramm> true
<rogpeppe> mramm: from my extremely crude reading of the AGPL, i don't *think* there should be a problem with us distributing the mongodb/openssl binaries.
<rogpeppe> mramm: but as hazmat says, we have lawyers. i'd like to know what they think.
<mramm> yes
<mramm> I think we might be able to get away with distributing under a modified AGPL that allows advertising
<mramm> but we might need to talk 10gen into doing the same
<mramm> and elliot at 10gen seems to think he has a solution to the problem coming
<mramm> but I'm not in the loop on what that is
<mramm> and we can also just setup VPN of some sort to handle transport level security
<mramm> so it's definitely true that "all is not lost"
<mramm> we will be able to route around the problem if we need to
<fwereade> Aram, ping
<Aram> yes
<Aram> fwereade: ^
<fwereade> Aram, I'm thinking about subordinates
<Aram> what about them.
<fwereade> Aram, and ISTM that what I need is basically precisely a machiner, but watching a slightly different set of units
<fwereade> Aram, but I wanted you input on the current MachinePrincipalUnitsWatcher
<fwereade> Aram, and whether or not you anticipate changes to API or semantics at any point
<Aram> fwereade: so what set of units you want to watch?
<fwereade> Aram, the subordinates of one specific unit
<Aram> I see.
<Aram> well.
<Aram> hmm.
<Aram> there will be changes in the implementation that will make this easier, hopefully this week.
<Aram> but in semantics or API, I don't think so.
<fwereade> Aram, so it remains just Added/Removed with all other changes swallowed?
<Aram> (actually the MachinePrincipalUnitsWatcher and the MachineUnitWatcher use a diferent API in my latest branches than in trunk).
<Aram> personally I would change it to return more events.
<Aram> but I don't think niemeyer would approve.
<Aram> for the time being I suspect it's a safe bet that this behavior won't change.
<fwereade> Aram, always a fine line to walk ;)
<Aram> although it has disadvantages IMO.
<fwereade> Aram, I'll go with the current behaviour for now then, see where it takes me; cheers
<Aram> fwereade: it kind of bugs me that each collection watcher starts N individual watchers, but in some client of the collection watcher, like the firewaller or whatever, you start N individual watchers yourself anyway.
<fwereade> Aram, yeah, I feel that it's undergone somewhat forced/accelerated evolution and it needs to settle a bit
<Aram> fwereade: I'
<Aram> fwereade: I'd either make collection watchers return everything (no filtering) OR make them report only new objects as they become alive and no other event.
<Aram> fwereade: I did an experiment yesterday making the machine units watcher return everything with no filtering. the "problem" was that you got an event for the principal when you added a subordinate, because the principal is also modified in the process, but maybe that's ok.
<fwereade> Aram, yeah, I don't see that as a major problem myself
<Aram> fwereade: well, one issue might be that it essentially returns implementation details, right now the principal is modified in the process of adding a subordinate, but in the future it need not be.
<fwereade> Aram, I guess it all comes back down to agreement on what changes it is guaranteed for and which it isn't
<Aram> TheMue: have any idea why a firewaller will pick a close port event, but it will not pick the same close port event if the firewaller was stopped, and then restarted?
<Aram> I have a mental idea of what kind of race is going on, but it's somewhat hard for me to debug it, probably because of the unfamiliarity of the code.
<Aram> TheMue_: have any idea why a firewaller will pick a close port event, but it will not pick the same close port event if the firewaller was stopped, and then restarted?
<Aram> I have a mental idea of what kind of race is going on, but it's somewhat hard for me to debug it, probably because of the unfamiliarity of the code.
<TheMue_> Aaarg, disconnected just after the answer.
<TheMue_> Aram: I will take a deeper look.
<TheMue_> Aram: The last part that has been changed has been the adding of the global mode.
<TheMue> Aram: Here the initial open ports are retrieved not by the watchers but by traversing the state.
<Aram> hmm
<Aram> TheMue: basically this works, but if you uncomment those lines it will fail: http://paste.ubuntu.com/1339904/
<TheMue> Aram: Where exactly does it fail? Line?
<Aram> TheMue: http://paste.ubuntu.com/1339921/
<Aram> TheMue: you say that initial ports are retrieved from the environment, not from the watchers, then how can the firewaller determine if a close port on a unit should have any effect globally, since it doesn't know which units might use that port?
<Aram> TheMue: from what you are telling me, the failure seems expected, so how did it work before?
<TheMue> Aram: Just going through the code.
<TheMue> Aram: It worked.
<TheMue> Aram: The initial ports only in global mode are retrieved from the env.
<Aram> yeah
<TheMue> Aram: But the watchers still work.
<Aram> of course.
<TheMue> Aram: And this is collated with the already known global ports.
<Aram> but when you get a close port event from a unit, how do you know if you should close the port globally?
<TheMue> Aram: One moment, will tell you the line number.
<TheMue> Aram: Line 228 and the function flushGlobalPorts()
<TheMue> Aram: Here is also the fw.globalPortRef[port] to cound the usage
<rogpeppe> lunch
<Aram> TheMue: who initializes fw.globalPortRef?
<TheMue> Aram: It's created in initGlobalMode() and the counters will be increased by flushGlobalPorts() (based on the watchers).
<TheMue> Aram: If they would already be counted in initGlobalMode() they would be counted twice.
<fwereade> TheMue, on a related note, if you have a mo: how do we handle units which are removed with opened ports? ISTM that they will keep those ports open, but I am also unfamiliar with the code
<TheMue> fwereade: In global mode ports will be closed after the final unit using this port.
<TheMue> fwereade: Otherwise directly.
<Aram> fwereade: I think it's fine, removal of a unit event makes fw call flush machine which calls flushGLobalPorts and does the refcound decrement
<TheMue> fwereade: If you change it to dying the firewaller gets notified by the watcher.
<fwereade> Aram, ah! forgetUnit
<fwereade> TheMue, thanks
<TheMue> fwereade: yw
<fwereade> TheMue, wait, when what becomes Dying?
<fwereade> TheMue, do we do something when the unit becomes Dying?
<Aram> TheMue: take a look at this, maybe you see an obvious flaw with it: https://codereview.appspot.com/6820112
<TheMue> fwereade: I would have to look more exactly.
<Aram> I'm not sure that the failure I see is due to my code, but rather to just enabling a race, but maybe my code sucks.
<TheMue> fwereade: Will look at Arams review before.
<fwereade> TheMue, I just didn't unerstand what you meant by:
<fwereade> <TheMue> fwereade: If you change it to dying...
<TheMue> fwereade: Please later, I'm not working concurrent
<fwereade> TheMue, ok, I would appreciate a clarification when you have a mo :)
<TheMue> fwereade: Yep, will do afterwards.
<fwereade> TheMue, cheers
<TheMue> fwereade: Have to look the exact flow in the code
<fwereade> TheMue, I just want to know what you meant by "it" in "setit to dying" above... I don't think you need to look at the code...
<TheMue> fwereade: Has just been a quick rememberance. The important part is that the watchers notify the fw and the fw combines these changes to get aware which ports it has to open/close.
<TheMue> Aram: Hmm, so far it looks good. The loops over the removed and added units are almost the same, only that you now have a list with names and a list with units. But I'll again check the part above.
<TheMue> Aram: The retrieval of the lifecycle state is now somewhat strange. Shall it be changed this way everywhere? I liked the fact that the watchers emit changes according to the state.
<Aram> TheMue: could you be more specific or rephrased that? I don't understand what you mean.
<TheMue> Aram: Sure, so far the change itself contained Added and Removed. Now you get all changes and have to check the state on you own. That looks strange.
<Aram> TheMue: well that's how the new style watchers are now.
<TheMue> Aram: I liked the old way, or a return of Alive, Dying, Dead to be more close to the states.
<Aram> eventually, all old style watcher will be like this.
<Aram> we took the decision of doing it this way at Lisbon.
<TheMue> Aram: OK, then I think it's well discussed. Forget my question.
<fwereade> TheMue, I'm looking at the firewaller again
<TheMue> fwereade: Feel free
<fwereade> TheMue, in the watch loops for unitData and serviceData, you defer watcher.Stop()
<fwereade> TheMue, is that intentional
<fwereade> ?
<fwereade> TheMue, ie, doing so swallows errors, but I can see a fuzzy justification for why we might want to
<Aram> TheMue: so you don't see anything egregious about my code?
<fwereade> TheMue, but I need help clarifying what it is and whetherit exists ;)
<TheMue> Aram: So far not, it looks fine to me.
<Aram> hmm.
<TheMue> fwereade: Sorry, here I have to go into history when they wen in. Since the earliest steps the fw has had several changes.
<fwereade> TheMue, sure, this is pretty tightly focused though
<Aram> I think that there's a race in the firwaller, and my code helped bring it to the surface, but the actual fault is in the firewaller, not my code.
<fwereade> TheMue, why do we ignore errors in sd.watcher and ud.watcher?
<Aram> TheMue: btw, if I change the MachineUnitsWatcher to report everything, not only lifecycle changes, this test passes.
<TheMue> fwereade: Please one after the other.
<fwereade> TheMue, I asked the same question in two different ways, I thought
<TheMue> And btw, lunchtime. Today later, daughter came just back.
<fwereade> TheMue, ok, I'll see what happens if I get stricter :0
<fwereade> rogpeppe, Aram, TheMue: I have to go early today, but before I do... I just proposed https://codereview.appspot.com/6811091 ...
<fwereade> which makes service and unit watchers just return ids instead of entities
<fwereade> but I now want to go a step further, and cause machine/unit/service watchers to just send `struct {}{}`
<Aram> fwereade: heh, I already did that as well.
<fwereade> rationale is that whoever started the watch should damn well know what enitity they mean
<Aram> I might have even proposed it about two weeks ago.
<Aram> but gustavo didn't like a prereq
<fwereade> Aram, crap, sorry, I never saw that
<Aram> so he didn't even look over it
<fwereade> Aram, ah hell
<Aram> and never went in
<Aram> anyway
<rogpeppe> fwereade: i totally agree, but i've said that a few times to gustavo and had no agreement
<TheMue> back
<fwereade> rogpeppe, hum, ok -- the issue is that it lets me dodge the damn-stupid-in-hindsight difference in type between unit and machine
<fwereade> sorry, unit and machine *ids*
<rogpeppe> fwereade: i agree
<Aram> fwereade: rogpeppe: one benefit of returning id is that a collection watcher can literally be constructed from N individual watchers muzed together on the same channel.
<Aram> s/muzed/muxed/
<Aram> not that we do that, just saying.
<rogpeppe> Aram: that would be an issue if you passed a channel into a watcher
<rogpeppe> Aram: as it is, it's not AFAICS
<rogpeppe> fwereade: if you can demonstrate a nice use case for struct{}, i think it would probably be fine
<Aram> TheMue: I think I know what the race is.
 * TheMue listens
<Aram> TheMue: individual machine and unit watchers are started as soon as possible, rather than waiting for the fw to finish reading the environment.
<fwereade> rogpeppe, I think the putative deployer makes a nice one
<rogpeppe> fwereade: agreed
<fwereade> rogpeppe, but maybe for now I'll ponder less-controversial prereqs for doing so -- I should at least fix up MachinePrincipalUnitsWatcher
<Aram> rogpeppe: yeah, we don't currently make use of that feature, and the benefit of having watchers return the same type outweighs the potential benefit of muxing watchers in the future.
<fwereade> Aram, +1
<Aram> fwereade: I have a fix for that as well
<Aram> I'm just blocked on debugging this stupid thing
<Aram> that's why is not up for review again
<fwereade> Aram, ah ok! sorry, would you link me your branch for MPUW so I can see what I'll need to work with?
<TheMue> Aram: IMHO not. loop() starts with initGlobalMode() before entering the watchers. But let me have a deeper look.
<Aram> fwereade: well, this one: https://codereview.appspot.com/6718052/ but I'll have to work on it some more to use more of the machine units watcher that has changed in the meantime and the prereq is bad as well.
<TheMue> Aram: Ah, no, WatchMachines() starts earlier, indeed.
<Aram> TheMue: yes, you're right, the environment is read before, but the behavior suggests otherwise. I've put debug prints inside the unit watcher loop, and globalPortRef is not good
<Aram> basically empty
<Aram> meh
<Aram> for whatever reason the unit loop doesn't run enought times.
<TheMue> Aram: Maybe the separation in added and removed should be done inside the unitd to avoid receiving from the watcher the next time. The slices of added and removed can then be sent to the main loop as before.
<Aram> TheMue: what do you mean?
<TheMue> Aram: I'm jist thinking loud, but I'm thinking it will show no effect. :|
<TheMue> Aram: It's the new new loop where you initially check if a units is added or removed before you later iterate over those slices to process the units like before.
<Aram> TheMue: you want to do it in a single loop?
<Aram> why do you think it should make a difference?
<TheMue> Aram: No. During this "pre-processing" the unitd can receive the next change, maybe here's the race. So a solution can be to move the pre-processing into the unitd and then send the separated slices to the main loop.
<TheMue> Aram: But that's only guessing.
<Aram> TheMue: I don't know whay you mean by 'unitd'?
<Aram> s/whay/what/
<Aram> what is unitd?
<TheMue> unitData
<TheMue> They are managed as fw.unitds[]
<Aram> but unitDatas are created inside the for _, unit := range added { by newUnitData, aren't they?
<Aram> so they don't even exist in the preprocessing step\
<TheMue> Aram: Yes, those both loops (removed, added) can stay in the fw.loop(), as before. Only the first loop that's new now..
<Aram> TheMue: I don't understand what difference that makes, but maybe I am missing something basic.
<Aram> oh
<Aram> hmm
<Aram> no
<Aram> I don't see it :).
<Aram> I mean that function is called synchronously, as if the code was pasted there.
<TheMue> Aram: Yes, you're right. *sigh*
<Aram> TheMue: on the other hand you might be right about the race, when that function is executing, more events could be queued for the watcher, and the fw would call that function again with the same units.
<Aram> not sure what difference that makes though.
<TheMue> Aram: Could be worth a test.
<Aram> TheMue: inlining that and doing it all in a single loop, without a preprocessing step, made no difference.
<TheMue> Aram: Sh...
<Aram> TheMue: I'm out of ideas to try.
<Aram> TheMue: the fact that it works if you don't restart the watcher suggests there's something wrong with watcher initialization.
<TheMue> Aram: Don't know. It worked so far. So the change seems to effect a different behavior inside the fw.
<Aram> TheMue: what about var ports []state.Port inside func (ud *unitData) watchLoop() {?
<Aram> this wil start fresh, from nil when watcher is restarted
<Aram> but that function compares the new ports with old ports each run
<Aram> so it will compare with nil when a watcher is started
<Aram> so it won't ever close ports
<Aram> yeah
<Aram> that's it.
<Aram> it compares nil to 80, and can't realize it needs to close 8080
<Aram> TheMue: does that make sense?
<TheMue> Aram: Sounds good, I'm only wondering why it worked before.
<TheMue> Aram: I'll go into the history there tomorrow to get  a feeling.
<Aram> TheMue: because the watcher delivered units as they were at that point, so you'd get one even with 80, 8080 and one with 80, but now you have to load the unit manually, and when you load it it's already only 80
 * TheMue leaves now, I've got a cold and almost had no sleep last night.
<TheMue> Aram: Ah, that sounds reasonable.
<Aram> TheMue: have a nice evening
<TheMue> Aram: Thx, cu tomorrow
<TheMue> Aram: And have a nice evening too
#juju-dev 2012-11-08
<TheMue> Morning
<TheMue> Today is the worst day of my cold. So I'll work later a bit from the couch and with lots of peppermint tea.
<TheMue> So cu later.
<Aram> hello.
<Aram> hmm, anyone seen frank?
<fwereade> Aram, he's got a cold and may or may not be available at any given time
<rogpeppe> two CLs to review, if anyone cares to:  https://codereview.appspot.com/6811095/ https://codereview.appspot.com/6819115
<rogpeppe> i'm off for the evening, see y'all tomorrow
#juju-dev 2012-11-09
<davecheney> hey hey
<davecheney> the good news, juju can now bootstrap from quantal to precise
<davecheney> the bad news, do-release-upgrade on my precise system totally hosed it :(
<fwereade> davecheney, heyhey
<davecheney> fwereade: hey
<fwereade> davecheney, reviewed one, with unhelpful whining about tests, I'm afraid
<davecheney> understood
<davecheney> it is a non trivial amount of work to add 409 response behavior to s3test
<davecheney> i'll man up and do it
<fwereade> davecheney, on the other, trying to figure out what the deal is with the arch change in cloudinit_test
<fwereade> davecheney, thanks very much :)
<fwereade> davecheney, I expect it makes sense somehow, but I just cannot figure out where that i386 came from
<davecheney> fwereade: i386 is just to double check that cloudinit isn't amd64 only
<fwereade> davecheney, I just can't see what change caused it to use i386 where once it used amd64
<davecheney> fwereade: i can remove the i386 thing if it is confusing
<davecheney> it isn't testing anything important
<fwereade> davecheney, sorry, I have just come to realise I am being stupid
<fwereade> davecheney, so that one basically LGTM -- but the description should be fixed if it is now actually intended for submission ;)
<davecheney> fwereade: cool
<davecheney> that is the one i really care about
<davecheney> as i upgraded to quantal today (twice)
<fwereade> davecheney, ah, cool
<fwereade> davecheney, you have an LGTM with one nitpick
<fwereade> bbiab
<rogpeppe> fwereade: hiya
<fwereade> rogpeppe, heyhey
<TheMue> morning
<rogpeppe> TheMue: hi
<TheMue> rogpeppe: hiya
<rogpeppe> fwereade: what's our current position on watchers returning updates for any changes, not just lifecycle? (i'm looking at MachinePrincipalUnitsWatcher here)
<rogpeppe> fwereade: it seems a bit silly that when we're told about a unit changing, we fetch its unit doc twice. ISTM that hardly any logic in the client (worker/machiner) would have to change, and we could get rid of a big chink of logic in the watcher
<TheMue> rogpeppe: I like the idea of getting notified on any change, but I then like to get the watched entitiy (not only the id) and a useful information what has changed (e.g. the lifecycle state)
<fwereade> rogpeppe, I am still undecided tbh
<rogpeppe> TheMue: from what i see of the clients, they don't make that much use of that info.
<fwereade> rogpeppe, the trouble is that different use cases are different and I think that both behaviours are wanted in different places
<TheMue> rogpeppe: The old added/removed separation has been more helpful than today iterating over ids, retrieve the state and compare it.
<rogpeppe> fwereade: if we're just sending ids, then i think it makes sense that the client is responsible for doing the refresh and doing the diffs itself
<rogpeppe> TheMue: i agree, but since we've moved away from that, i think it makes sense to take advantage of that
<fwereade> rogpeppe, this is true, up to a point -- let me read some code a mo
<rogpeppe> TheMue: there's no need for both the watcher *and* the client to be independently fetching the doc
<TheMue> rogpeppe: That's true
<fwereade> rogpeppe, I consider it to be a good thing, though, that the ServiceRelationsWatcher filters out irrelevant changes and only tells me about life changes
<rogpeppe> fwereade: how much would your logic need to change if it told you about other changes too?
<fwereade> rogpeppe, it could be more efficient -- it only needs to grab 2 fields to do the comparison -- but I think we need to consider the HTTP API here
<rogpeppe> fwereade: after all, you need to fetch the doc to find out exactly *what* has changed
<fwereade> rogpeppe, I think it *is* worth getting the document twice, because once the watcher is implemented behind the API, right next to the state, it is cheap for it to get a document
<fwereade> rogpeppe, and by doing so it can send fewer updates to remote clients on the other side of the API
<fwereade> rogpeppe, and those clients, for whom getting a document is expensive, don't have to repeatedly get and inspect the documents to do their own filtering
<fwereade> rogpeppe, sane?
<rogpeppe> fwereade: hmm
<rogpeppe> fwereade: that's a reasonable point
<rogpeppe> fwereade: o
<rogpeppe> fwereade: darn, i thought we could get rid of large chunks of code
<fwereade> rogpeppe, annoying, innit ;)
 * rogpeppe grumbles
<fwereade> rogpeppe, TheMue: so, given that, I think the answer really is annoyingly situational
<fwereade> rogpeppe, TheMue: for the firewaller, it's perfect to get life and ports changes only
<fwereade> rogpeppe, service relations we want life only
<fwereade> rogpeppe, TheMue: again, for the (?)deployer and/or machiner, life changes only
<rogpeppe> fwereade: i'm happy with that now.
<fwereade> rogpeppe, cool, sorry :)
<TheMue> :D
<Aram> morning.
<TheMue> Aram: hi
<rogpeppe> Aram: you've got a couple of reviews
<rogpeppe> Aram, fwereade: what's the story regarding https://codereview.appspot.com/6811091 vs https://codereview.appspot.com/6820112 ?
<rogpeppe> looks like there are quite a few conflicts there
<Aram> rogpeppe: unfortunate duplication of effort
<rogpeppe> Aram: well, yours does more, as it uses WatchUnits rather than WatchPrincipalUnits. maybe fwereade's should go in first.
<rogpeppe> hmm, looks like my gmail account has been hacked
<TheMue> rogpeppe: Yesterday there also has been a strange twitter message by you.
<rogpeppe> TheMue: yeah, that was hacked too. seems a bit strange - they both had different passwords
<rogpeppe> TheMue: although, to be fair, both passwords were terribly weak
<TheMue> rogpeppe: OK, so maybe just brute force.
<rogpeppe> TheMue: i think so
<TheMue> rogpeppe: I like the xkcd, where long curious sentences are better than "P4ssw0rd". ;)
<rogpeppe> TheMue: yeah, that's the approach i'm using
<rogpeppe> TheMue: with a couple of weird chars thrown in for good measure
<TheMue> rogpeppe: I've changed it and now have stupid sentences.
<TheMue> rogpeppe: But today I had to set one with 8 to 15 chars and no specia characters. Why those constraints? *sigh*
<rogpeppe> TheMue: yeah, that's outrageous. don't they know that you can run sha1 in javascript? :-)
<TheMue> rogpeppe: Yep ;)
<rogpeppe> interesting to see the spam machine in action
<rogpeppe> none of the sent messages addressed more than 5 recipients
<rogpeppe> and they all sent a different link
<TheMue> rogpeppe: Yeah, they do their best to not being catched by spamassassin or postgrey.
<rogpeppe> they got as far as "j" in my address book
<rogpeppe> 65 spam messages sent in total
<rogpeppe> fwereade: ping
<Aram> rogpeppe: I want acme integration with codereview.
<rogpeppe> Aram: how would you want it to work?
<Aram> rogpeppe: somewhat like mail.
<Aram> in fact even using that with the email you get now from codereview is almost usable, aparte from the fact that you can't reply.
<rogpeppe> Aram: do you still use acme mail?
<Aram> no.
<rogpeppe> Aram: i used it for years actually, but the lack of threading finally got to me
<rogpeppe> Aram: and the benefits aren't so great if you're not running under plan 9
<Aram> yeah...
<fwereade> rogpeppe, deferred pong
<fwereade> rogpeppe, I have to pop out for a while and will be somewhat spottily around this afternoon and evening
<Aram> acme mail is not so useful at this point anymore, but I think for specialized things, an acme mail thing would be useful.
<fwereade> rogpeppe, I will grab you this pm though
<rogpeppe> fwereade: ok. sometime i'd like a chat about some new attributes in config
<rogpeppe> fwereade: but i think i've decided on a reasonable approach actually
<fwereade> rogpeppe, cool -- I look forward to seeing it :)
<fwereade> tytyl
<rogpeppe> fwereade: have fun
<rogpeppe> Aram: go for it; i'd like to see what you come up with.
<rogpeppe> fwereade: i'll just run the config stuff by you to check for crackfullness, if that's ok
<fwereade> rogpeppe, sgtm
<rogpeppe> fwereade: so, we want to be able to specify a root CA when bootstrapping and when connecting to an environment
<fwereade> rogpeppe, ok
<rogpeppe> fwereade: when bootstrapping we'll need the private key too, so we can sign a new key/cert pair and hand it off to the first instance
<rogpeppe> fwereade: so my thought is to add three new attributes to config
<rogpeppe> fwereade: root-cert-path, root-cert and root-private-key
<rogpeppe> fwereade: root-cert-path acts a little like authorized-keys-path
<rogpeppe> fwereade: that is, if it's set, the cert/key pair is read from that file; otherwise if root-cert isn't set in config, we'll try to read from ~/.juju/rootcert.pem
<fwereade> rogpeppe, yep, that makes sense
<rogpeppe> fwereade: we verify that the cert parses and that, if given, the key matches the cert.
<rogpeppe> fwereade: which prevents going a long way down the road with a bogus cert/key pair
<fwereade> rogpeppe, ok, yep
<rogpeppe> fwereade: i think that's it, for the time being
<rogpeppe> fwereade: i'm just doing the tests
<rogpeppe> fwereade: it's a pity that it's yet one more step to getting a juju up and running
<rogpeppe> fwereade: i wonder if we might have a juju helper that prompts for the necessary information and does everything else necessary (e.g. generating the key, generating an admin secret, etc) and writes an environments.yaml file.
<fwereade> rogpeppe, just one of many, really, we'll get there :)
<fwereade> rogpeppe, yeah, new-user experience would be very much helped by that
<rogpeppe> fwereade: juju new-environment ?
<rogpeppe> fwereade: i'm not sure that we can rewrite environments.yaml losslessly though, sadly
<fwereade> rogpeppe, I'm pretty sure we can't
<rogpeppe> fwereade: me too. +1 to json :-)
<rogpeppe> fwereade: actually, maybe it could just spit out an environments.yaml to stdout
<rogpeppe> fwereade: anyway, that's way down the line.
<rogpeppe> fwereade: if all that SGTY, i'll carry on
<fwereade> rogpeppe, I *think* it does
<fwereade> rogpeppe, I am not sure how to handle changing the root cert
<fwereade> rogpeppe, or in general how to (or whether we should) change any of those new fields
<fwereade> rogpeppe, (I guess root-cert-path is not really a setting, at least, just a sort of input filter)
<rogpeppe> fwereade: yeah, changing the root cert is hard
<rogpeppe> fwereade: and what about certificate revocation
<rogpeppe> ?
<fwereade> rogpeppe, quite so
<fwereade> rogpeppe, I guess it would be worth trying to think a little way through those questions to ensure we're not closing any future doors, even if we don't support anything like that at this stage
<rogpeppe> fwereade: tbh, i think that both with changing the root cert and revocation, what we're building now is a necessary prerequisite. we are always going to need to pass at least one certificate into the cloud.
<fwereade> rogpeppe, that does sound solid to me
<rogpeppe> fwereade: revocation, i think happens automatically, as long as clients are checking revocation lists appropriately.
<rogpeppe> fwereade: changing the root cert we'd probably do by leveraging the existing root cert to produce another cert. you'd probably do it by using a level of indirection and revoking the original certificate but not the original *root* certificate (he says, hand-waving wildly)
<fwereade> rogpeppe, I think that's outside the realm of things I can claim to have a reasoned opinion on ;)
<fwereade> rogpeppe, incidentally, I was wondering something related... ISTM that the user is already adequately identified with the authorized key, and I'm suddenly unsure what we get out of admin-secret... what am I missing?
<Aram> rogpeppe: significantly refined version https://codereview.appspot.com/6820112/ , when you have time
<rogpeppe> fwereade: that may well be true in the future. for the time being, i don't know of a way to get mongodb do client authentication
<fwereade> rogpeppe, ok, cool, so it's purely for admin auth with mongo?
<rogpeppe> fwereade: yes, i *think* so
<rogpeppe> Aram: looking
<Aram> rogpeppe: also https://codereview.appspot.com/6814108/
<rogpeppe> Aram: sorry, i got some way through, then realised i really wanted to propose my CL by the end of the day...
<Aram> rogpeppe: don't worry, I'm only pinging you, I don't expect reviews right away.
<rogpeppe> Aram: that's find. just letting you know in case you expected one after my "looking"
<rogpeppe> s/find/fine/
<rogpeppe> fwereade: ping
<fwereade> rogpeppe, pong
<rogpeppe> fwereade: i've just realised, i think, that i'm slightly askew in my assumptions
<fwereade> rogpeppe, oh yes?
<rogpeppe> fwereade: i've been assuming that it's mandatory to have a root certificate
<rogpeppe> fwereade: but actually, i think we perhaps want the capability to connect to a server without checking
<fwereade> rogpeppe, expand please
<fwereade> rogpeppe, naively it seems like a good idea
<rogpeppe> fwereade: well, say we have a juju environment but we've lost the root cert key
<rogpeppe> fwereade: the checking that juju does is, i think, something that should be a choice (the default choice)
<rogpeppe> fwereade: 'cos otherwise we can't connect
<rogpeppe> fwereade: a bit like the way ssh automatically adds a key if you ask for it
<fwereade> rogpeppe, I kinda favour just advising people that "keys are important; don't lose them"
<rogpeppe> fwereade: i was just wondering if i really want the root cert to be mandatory in config
<rogpeppe> fwereade: (i've just spent the last while putting it everywhere...)
<fwereade> rogpeppe, ha, yeah, it is usually at such junctures that I start to question things
<fwereade> rogpeppe, hmm
<fwereade> rogpeppe, honestly I don;t know what is really meant by "everywhere" so it is hard for me to follow intuitively
<rogpeppe> fwereade: i got to environs/ec2, and realised that it uses your actual authorized keys, so i'm wondering whether we want to the same approach for root cert, or if we should generate one on the fly
<rogpeppe> fwereade: everywhere we've got a set of attributes for a config
<rogpeppe> fwereade: pretty much everywhere we've got an authorized-keys attribute now
<rogpeppe> fwereade: i'm thinking that it might be fine just to hard-code a root cert for testing.
<rogpeppe> fwereade: there's another thing which is a source of discomfort currently
<rogpeppe> fwereade: which is that the cert and key are specified in a single file, but they get two attributes in the config.
<fwereade> rogpeppe, yeah, that definitely seems wrong
<fwereade> rogpeppe, except hmm
<fwereade> rogpeppe, maybe not
<rogpeppe> fwereade: there are +s and -s
<fwereade> rogpeppe, but, yeah, it doesn't sit quite right
<rogpeppe> fwereade: i was trying to avoid having *two* more path attributes in the config.
<fwereade> rogpeppe, hmm, just a mo
<rogpeppe> fwereade: but perhaps that makes more sense in fact; keep them separate at all times.
<fwereade> rogpeppe, if that is as convenient that sgtm
<rogpeppe> fwereade: it's not convenient at the moment - i'd have to rewrite some code and lots of tests :-)
<fwereade> rogpeppe, ha, indeed
<rogpeppe> fwereade: but on balance, i think it's probably a better approach
<rogpeppe> fwereade: bugger
 * fwereade sympathises
<fwereade> rogpeppe, a strawmanny thought
 * rogpeppe gets out the wooden axe
<fwereade> rogpeppe, how would it be if the administrator who created the environment were to have keys and certificates automatically generated and stored in ~/.juju/environments/<name>?
<fwereade> rogpeppe, they could of course be overridden by config settings
<rogpeppe> fwereade: i think that's a reasonable thought, and i've thought about something similar myself
<rogpeppe> fwereade: but i think it's orthogonal to what i'm doing currently
<rogpeppe> fwereade: which enables that, trivially
<fwereade> rogpeppe, agreed... maybe a suggestion for the lists, see if it draws popular support, if it does it should indeed be easy to build on top
<rogpeppe> fwereade: yeah. actually, i don't think there needs to be a key per environment
<rogpeppe> fwereade: i think one root key for all environments is just fine
<rogpeppe> fwereade: so the command line tool could generate ~/.juju/rootcert.pem if it doesn't already exist
<fwereade> rogpeppe, I dunno, I think one per environment is saner in a multi-admin situation
<fwereade> rogpeppe, but I don't feel very strongly about it, haven't really thought it through
<rogpeppe> fwereade: if you want one per environment, that's easy to do. but a single name space also makes sense, i think.
<rogpeppe> fwereade: it means there's only one public key to distribute, for one
<fwereade> rogpeppe, yeah, also sounds reasonable :)
<rogpeppe> right, i can't launch into changing all this now; time to stop for the night, i think.
<rogpeppe> a pint beckons
<rogpeppe> fwereade: have a great weekend, see ya monday
<rogpeppe> night all
<fwereade> rogpeppe, have fun :)
#juju-dev 2013-11-04
<thumper> axw, wallyworld_: I'm prepared to trade review for review... mine is trivial
<wallyworld_> ok
<thumper> axw: and I'm replying to the maas-allocated one
<axw> thumper: okey dokey
<thumper> enfixorating it took longer than expected
<axw> thumper: sorry, couldn't remember if we were doing a bug or blueprint for the API stuff.. thanks for fixing
<thumper> np
<thumper> gives me something to do and feel important :)
<axw> thumper: did you mean to repropose the maas MP?
<axw> there's a bunch of unrelated stuff in there now
<thumper> no...
<thumper> yes I know
<thumper> I'll fixit
<axw> k
<thumper> dammit
<thumper> axw: I'm trying to work out wtf happened
<thumper> I had branched from 1.16
<thumper> ugh
<thumper> I know
 * thumper goes to uncommit several
<axw> thumper: when you're not busy, can you please take a look at https://codereview.appspot.com/14775044/
<axw> a fix for one of the manual provisioning bugs
<thumper> bigjools: can I get you to cast a quick eye over https://code.launchpad.net/~thumper/juju-core/maas-allocated/+merge/191090
<thumper> bigjools: just to make sure I'm not doing something dumb?
<thumper> axw: ack
<bigjools> thumper: out of interest,  why the change to name the returned values?
<bigjools> line 38 on diff
<thumper> I was assigning to them before
<thumper> but refactoring took it out
<thumper> again
<thumper> sometimes it is easier to have the named params
<thumper> than to have empty declarations in the code
<thumper> they are effectively function local variables
<bigjools> yeah
<bigjools> sheesh, I don't remember enough Go already to see what this is doing without looking stuff up
<bigjools> did my best to banish it from my mind
<thumper> axw: var allSeries = [...]string{"precise", "quantal", "raring", "saucy"} <- why the dots in [...] ?
 * axw reminds himself
<thumper> bigjools: it was more just the filter I cared about
<thumper> bigjools: the rest of it I understand
<bigjools> filter is fine
<axw> thumper: why I did that instead of a slice... *shrug*, it's a little less overhead
<bigjools> thumper: having said that
<axw> [...]{...} is syntax for an array literal with the size taken from the number of elements
<bigjools> thumper: it would be better to have the filtering done in gomaasapi
<bigjools> as an optional state param
<thumper> bigjools: agreed, but I felt that it was more work, and I think gomaasapi should give juju-core higher level objects to work with
<thumper> rather than thin wrappers on a ReST api
<thumper> axw: I just wasn't familiar with the syntax
<thumper> bigjools: why exactly do we filter out unallocated ones?
<bigjools> lol
<thumper> I'll update the comment if you give me the reason
<bigjools> thumper: nodes can be owned by the same user but not necessarily in use by juju
<bigjools> juju just assumes it owns the world
<bigjools> this change is not actually strictly necessary after the other work we did
<thumper> by not strictly necessary...
<thumper> do you mean it isn't needed at all?
<bigjools> well, no :)
<thumper> if it isn't, then we could flag it
<bigjools> the agent_name work marks nodes that juju allocated
<thumper> although I wish I knew that before I spent a day trying to massage it into shape
<bigjools> I didn't know you were working on it, sorry
 * thumper sighs
<thumper> I'll strip the filter, but commit the changes because it makes the code more "correct"
<thumper> and tweaks the tests
<bigjools> ok
<axw> wallyworld_, thumper : bot sez "no space left on device"
<axw> do either of yo uhave access?
<wallyworld_> i do
<wallyworld_> which device?
<axw> wallyworld_: /tmp
<wallyworld_> ok
<axw> thanks
<wallyworld_> axw: try now
<axw> fixed, ta
<axw> wallyworld_: do you have any thoughts on this thread, before I land my change? https://lists.ubuntu.com/archives/juju-dev/2013-October/001651.html
<wallyworld_> axw: just a sec, otp
<wallyworld_> axw: i'm in 2 minds - i can see the need to keep the current behaviour. but seems like there's enough support to land it. especially now there are validation tools so they can verify the image id they will be getting.
<axw> wallyworld_: how do the validation tools help? you mean, people can just set the image id explicitly to prevent unexpected images from being provisioned?
<axw> ah never mind, I get it
<wallyworld_> one source of confusion in changing the behaviour is: people will set up metadata to use precise image 1234 (to override the stock abcd)
<wallyworld_> and if we fall back to abcd cause they stuffed up, that's bad
<axw> yep
<axw> and validation tools can help prevent that
<wallyworld_> yeah, if people use them :-)
<axw> heh :)
<wallyworld_> so i'm sorta -0 on it
<axw> we can add an option on datasources to prevent fallback
<wallyworld_> yes. let's land this first as is i guess and do more work later if it comes up as an issue
<axw> ok, sounds like a plan
<wallyworld_> i still get a bit nervous about doing it, but oh well
<wallyworld_> so long as it's documented and in the release notes
<axw> good point, I don't think there's a card for it.. will create one
<wallyworld_> main issue is it's a change in behaviour. and i'm not sure how upstream is set up to handle such things; ideally we'd be consistent but if not, double the need for doco
<wallyworld_> jam: https://codereview.appspot.com/20730043/
<jam> morning all
<axw> morning jam
<rogpeppe> mornin' all
<axw> morning rogpeppe
<rogpeppe> axw: hiya
<mgz> mornin' all
<dimitern> mgz, morning
<rogpeppe> mgz, dimitern: yo!
<rogpeppe> jam: i just posted a review of this: https://codereview.appspot.com/21000044/
<dimitern> rogpeppe, hiya
<rogpeppe> fwereade_: ping
<fwereade_> rogpeppe, pong, sorry
<rogpeppe> fwereade_: just wanted to point you at the HA doc that nate and i put together on friday. i imagine you'll have some comments to make: https://docs.google.com/a/canonical.com/document/d/1hGa2PNz6JyGFc7FjA-gX2_UnXRUGAZbS8O9TiS51bl8/edit
<fwereade_> rogpeppe, sweet, tyvm
<jam> rogpeppe: fwereade_: standup?
<jam> https://plus.google.com/hangouts/_/calendar/am9obi5tZWluZWxAY2Fub25pY2FsLmNvbQ.mf0d8r5pfb44m16v9b2n5i29ig
<jam> natefinch: ^^
<jam> mgz: https://plus.google.com/hangouts/_/72cpj1004s1il9ggm12bsqttpg
<mattyw> fwereade_, you remember a few weeks ago I was working on the mp for adding the owner to the addservice function? It just occured to me I never submitted it for review, I'm just doing it now, I have a feeling there's still lots to be done on it, but thought I'd submit it as a way of getting it moving again
<natefinch> jam: ahh crap, daylight savings time. Sorry.
<fwereade_> mattyw, ah, great, thanks, about to lunch but I'll take a look this pm
<jam> natefinch: I expected as much
<jam> I knew it was extra early for you, and wasn't sure if you'd be there. We should sort something out for you
<natefinch> jam: I expected better of myself :)
<mattyw> fwereade_, thanks. no hurry - I have plenty to keep me busy  (as I'm sure you do as well)
<rogpeppe1> natefinch: ping
<abentley> marcoceppi: Is it considered bad style to do apt-get upgrade in a charm?
<marcoceppi> abentley: not nessisarily
<abentley> marcoceppi: It seems to me that upgrading all the packages on your system should be an admin decision, not one that your charms make.
<marcoceppi> abentley: charms are extremely opinionated encapsulation
<marcoceppi> abentley: if the author thinks that's the best course of action, then so be it
<abentley> marcoceppi: So the situation is that wordpress does apt-get upgrade.  This attempts to install cgroups-lite.  But I am running the local provides, so installing cgroups-lite fails (I assume because nested lxcs aren't permitted).  So the charm can't install.
<abentley> s/provides/provider.
<marcoceppi> what in the chain of deps requires cgroups-lite?
<abentley> marcoceppi: None.  It's part of the base install.
<natefinch> rogpeppe1: hey, sorry, kids got up late today.  What's up?
<marcoceppi> well, that seems like a bigger problem tbh
<abentley> marcoceppi: What's the bigger problem?  That the Ubuntu base install has cgroups-lite in it?
<marcoceppi> abentley: yeah, that cgroups-lite isn't installing properly on lxc
<abentley> marcoceppi: Yes, that's certainly a bug.  I just wondered whether it's also a bug that wordpress is trying to upgrade cgroups-lite.
<abentley> marcoceppi: It's clearly irrelevant.  I was able to remove it, and the charm installed fine after that.
<marcoceppi> abentley: there's an argument to make that it shouldn't as package versions could become mismatched between units, but the same can happen for long running deployments and updates to the simplestream data for images
<abentley> marcoceppi: right.
<abentley> marcoceppi: I figure charms are cannot by themselves ensure packages are in sync, and if juju changes to be able to ensure packages are in sync, it probably won't be necessary to do it in the charm.
<rogpeppe1> natefinch: we should have another chat about the HA stuff
<natefinch> rogpeppe1: cool, whenever is good for you
<rogpeppe1> natefinch: https://plus.google.com/hangouts/_/calendar/am9obi5tZWluZWxAY2Fub25pY2FsLmNvbQ.mf0d8r5pfb44m16v9b2n5i29ig?authuser=1
<rogpeppe1> fwereade_: ping
<rogpeppe1> natefinch: i've added some notes to the end of the HA document with some thoughts about HA failover and liveness
<natefinch> rogpeppe1: cool
<natefinch> rogpeppe2: you around?
<thumper-afk> morning
<thumper> hi natefinch
<abentley> thumper: morning.  Can we chat about local provider when you're free?
<thumper> abentley: sure, I need to kick the kids out shortly
<thumper> after that?
<natefinch> thumper: hi
<abentley> thumper: great.
<natefinch> thumper: finally had daylight savings over here... nice to have an extra hour of overlap with you.  Makes my afternoons less lonely :)
<thumper> :)
<thumper> I noticed that too
<thumper> now if we could just hire someone on the west coast too
<natefinch> Last I saw we had an opening for someone that they specifically wanted to have near San Fransisco for some reason.
<natefinch> niemeyer: you around?
<thumper> abentley: did you want irc or hangout?
<abentley> thumper: Let's hang out.
 * thumper waits
<abentley> thumper: https://plus.google.com/hangouts/_/72cpiquo8sjrmfhcnqpq31pdi0?authuser=1&hl=en
<thumper> abentley: that fixed the install problem
<thumper> abentley: just testing something else
<abentley> thumper: Cool.
<thumper> natefinch: https://codereview.appspot.com/21740043
<natefinch> thumper: looking
<thumper> natefinch: I initially wanted to move in the direction of nested lxc support
<thumper> but I couldn't get lxc-start to work with the apparmor profile
<thumper> so I gave up and went with the simple solution
<thumper> abentley: no sinzui today?
<abentley> thumper: No, he's taking the day off.
<thumper> hmm...
<thumper> we may want to release 1.16.3
<thumper> to fix the local provider
<natefinch> thumper: yeah, just disabling nested LXC seems like the best idea.  I doubt it'll be a big problem
<thumper> abentley: can you do your CI dance with the trunk branch again once I get the fix landed?
<abentley> thumper: Sure, but I need to leave in ~30 minutes.
<thumper> ack
<thumper> it may have to wait then...
<thumper> natefinch: and if you can, the same for 1.16 https://codereview.appspot.com/21420045
<natefinch> thumper: done
<thumper> ta
<natefinch> thumper: welcome.  If you get a chance, I'd like to get the code I wrote for specifying EC2 instance types as constraints in... since the code is slowly bitrotting.   https://codereview.appspot.com/14523052/
<thumper> I looked at it at the end of last week, but I couldn't remember what we decided about landing the instance type from our burlingame conversations
<thumper> do you recall?
<natefinch> thumper: we decided to land it.  I asked specifically at the time
<thumper> ok, I vote for landing and cleaning up the mess :)
 * thumper goes to do a proper review
<natefinch> :)
<thumper> natefinch: why type and not instance-type?
<thumper> I guess it doesn't matter
<thumper> just wondering
<natefinch> thumper: I thought instance type was too specific to EC2, but if it's more common than that, that's fine
<thumper> I think that type should be fine
<thumper> abentley: trunk now has lxc fix
<abentley> thumper: okay.
<natefinch> thumper: once nice bonus that code gives is that you see the type of the machine in juju status, instead of having to try to infer it.  So you'll see like "hardware: arch=amd64 cpu-cores=1 cpu-power=100 mem=1740M root-disk=8192M type=m1.small"
<abentley> thumper: build started at http://162.213.35.28/job/juju-core-ci/97/console
<thumper> natefinch: yep, noticed that
<thumper> abentley: ta
<natefinch> thumper: actually tempted to put type first in the printout, since it sorta defines the rest of the line
<thumper> natefinch: well, line is alphabetical no?
<thumper> eye naturally tracks to the end
<natefinch> thumper: I think it's in the order we define, which happens to be alphabetical
<thumper> natefinch: what happens with the mongo doc
<thumper> and output
<thumper> for environments that exist already?
<natefinch> thumper: it should just default to empty.  admittedly I haven't tried it
 * thumper nods
<thumper> noticed the bson serialization code
<thumper> omitempty *should* be fine
<natefinch> thumper: yeah
 * natefinch also said *should* ;)
 * natefinch covers his ass
<natefinch> Cool.   I'll do an upgrade test in the morning to double check,  and then merge it in.
 * natefinch has reached end of day.
<thumper> natefinch: ack
<natefinch> thumper: thanks for the review
<abentley> thumper: It errored.  Sorry, I don't have time to look at whether it's the same error as before.
<thumper> abentley: kk
<bigjools> good moaning
<thumper> o/
<marcoceppi> Can someone in here help out in #juju with a botched upgrade from 1.14 -> 1.16.2j
#juju-dev 2013-11-05
<axw> wallyworld: in case you're wondering why I didn't land the simplestreams changes yet, I found a bunch of tests I forgot to update :)
<wallyworld> ah np :-)
 * thumper -> school run
<thumper> wallyworld: please don't remove the names when done
<wallyworld> thumper: ok, i saw some names had already been removed for things besides mine so i thought i'd tidy it up
<wallyworld> looks neater :-)
 * thumper fixes
<thumper> it isn't how its doen
<wallyworld> do we care about the names?
<thumper> done
<wallyworld> once done
<axw> jam: I had it as two tests, but changed it because I keep getting told to ;)   I agree - will change it back to two
<jam> axw: having worked through the Uniter tests, I find them very hard to debug when things go wrong
<jam> because the Nth item in the test is failing
<jam> and the log is 1000 lines long
<axw> yeah, I find this problematic too
<jam> wallyworld: poke
<jam> for https://code.launchpad.net/~jameinel/juju-core/faster-passwords/+merge/193667 I realized that if an agent logs in with the "slow" hash, we can just rewrite it there to the fast one
<jam> (or if we want something with salt, etc, etc)
<wallyworld> jam: hi
<jam> hey wallyworld
<wallyworld> you want me to look at that review again?
<wallyworld> jam: so did you need me to do anything re: the above poke?
<jam> wallyworld: Sorry, I haven't finished responding to all the feedback, but I wanted to ask if a change seemed reasonable.
<jam> Namely
<jam> when running entity.PasswordValid
<jam> if we see that the PasswordHash in the DB is the old form
<jam> just rewrite the DB to the new form
<jam> we can trivially compute the hash
<jam> because the agents always just pass in the full password
<wallyworld> right, i thought you were looking to do that. seems reasonable to me, since cost is trivial and it will incrementally upgrade the db
<jam> wallyworld: what about "salt" for UserPasswords
<jam> sounds like fwereade would like to see that added
<jam> doesn't seem hard, though it means adding another field to the DB
<wallyworld> that makes sense to me too - o'd personally feel better with it
<wallyworld> i'd
<jam> wallyworld: is it worth doing for agent passwords?
<wallyworld> that's a harder question
<jam> also, is it worth doing something like a len(password) >= 18 for the fast version?
<jam> wallyworld: so "worth it" is just in the "so the code paths are similar"
<jam> I'm 99% sure it isn't worth it from an actual increased security
<wallyworld> i'd like that since were relying on long enough password = hard enough to brute force
<jam> (len(password) maybe)
<wallyworld> does the salt for agent passwords add any tangible benefit?
<wallyworld> cf the extra complexity
<wallyworld> i guess if the code is the same anyways....
<jam> wallyworld: no
<jam> salt is a "prevent someone from precomputing 1B password hashes"
<jam> of known user-likely passwords
<jam> the whole point is we don't have known user-passwords for agents
<wallyworld> yeah
<wallyworld> so i wouldn't do it
<wallyworld> we could still use same code
<wallyworld> ie look up salt and use it if there
<wallyworld> i think mongo returns empty for non existent fields
<jam> wallyworld: I'm sure we can tell and be compatible
<wallyworld> so then, add salt for user passwords, check length of agent passwords, rewrite out of date hashes
<wallyworld> do we pass password over the wire in plain text?
<wallyworld> i guess we do?
<jam> wallyworld: yes. though we have a TLS connection by that point
<wallyworld> ok
<jam> wallyworld: I know fwereade also talked about using CA signed client certs for agents
<jam> because that also helps in the case of "recovery" mod.
<jam> mode
<wallyworld> ok
<jam> but you'll still want *some* sort of user identity token/password/thingy
<wallyworld> yeah
<jam> because you don't want machine-1 agent pretending to be machine-0
<jam> since machine-0 gets all the passwords
<wallyworld> yep :-)
<wallyworld> or machine-N
<jam> right
<wallyworld> where N is a HA state server
<jam> wallyworld: yeah, I think recovery will need some thought about security
<wallyworld> indeed
<jam> one can argue the attack surface is minimized by requiring a user to engage the mode
<jam> and it could even require Admin registration sort of thing
<jam> I don't know how much we want to automate all of recovery
<jam> so EOUTOFSCOPE for now :)
<wallyworld> yep
<wallyworld> there's lots of prior art for this sort of thing too i think
<wallyworld> let's not reinvent the wheel
<jam> wallyworld: oh, the other bit about requiring min length of Agent passwords
<jam> is it is going to disrupt the test suite a lot
<jam> because we have tests that set the password for machine to "test-password"
<jam> which is a lot less than the 24 bytes we normally have
<wallyworld> s/test-password/test-password1234567890 :-)
<jam> wallyworld: well that, and it *might* bite us in backwards compatibility mode
<jam> since we can't change the actual password
<jam> we can change what we *store*
<jam> but we don't have a "that Login is valid, but you need to create a new Password now"
<wallyworld> true
<jam> utils.RandomPassword has generated 24-byte passwords for a long time now, though
<wallyworld> i reckon it's worth trying
<rogpeppe> mornin' all
<rogpeppe> fwereade: ping
<axw> morning rogpeppe
<rogpeppe> axw: yo!
<axw> rogpeppe: should everything prefer to use state.Machine.Addresses() rather than go to environs.Environ.WaitDNSName()?
<axw> I'm updating juju ssh to use the API; it uses WaitDNSName currently
<rogpeppe> axw: yes, it should definitely use state.Machine.Addresses
<axw> ok
<rogpeppe> axw: or Unit.Address(es?) when appropriate
<axw> yup
<axw> cool
<axw> rogpeppe: main problem now is that NewAPIConn doesn't pass secrets... I guess I'll do that now
<rogpeppe> axw: ah yes, that definitely needs to happen
<rogpeppe> axw: you mean, it doesn't push secrets if it's the first connection, right?
<axw> rogpeppe: yup
<axw> there's a TODO
<rogpeppe> axw: ha, the TODO just above it is very stale...
<rogpeppe> axw: i'm just wondering if there's a nicer way to do secret pushing that doesn't incur an extra round trip
<axw> rogpeppe: the API server could return an error that says "I haven't got my secrets yet"? and then we push and retry?
<rogpeppe> axw: something a little like that, yes
<TheMue> morning
<axw> morning TheMue
 * TheMue fights with a mail backlog of one week :)
<rogpeppe> TheMue: hiya
<TheMue> hiya axw and rogpeppe
<rogpeppe> axw: one alternative i'm considering is that the Login response, rather than failing, returns a "lacking secrets" status
<rogpeppe> axw: that can be cached locally in the api.State and queried.
<axw> rogpeppe: ah ok. I don't know the internals well to know how separated they are...
<axw> sounds sensible
<axw> so instead of a GetEnvironment/SetEnvironment, it'd just push secrets during login
<rogpeppe> axw: yes
<rogpeppe> axw: so we might add an environ config argument to api.Open
<rogpeppe> axw: which is allowed to be nil, but if it is, then the connection will fail if it's the first API connection
<rogpeppe> axw: in that case in fact it might work well to have Login fail
<rogpeppe> axw: hmm, not sure though
<rogpeppe> axw: depends whether we want the login message to contain the environ config
<axw> rogpeppe: if it's just the first connection, why not just have the login proceed, and then have the server request the secrets (via a special error)?
<axw> then a second message
<axw> it's only once
<rogpeppe> axw: so the error implies "login has actually succeeded (despite the error) but secrets are needed" ?
<axw> rogpeppe: yeah. perhaps confusing, but that's one option anyway :)
<rogpeppe> axw: i definitely don't mind a second message to push the secrets
<rogpeppe> axw: one question that arises from this: is there ever a case where we want to allow some request to the API server *without* pushing the admin secrets?
<rogpeppe> axw: because if we push environ config with Login, that will be ruled out
<rogpeppe> axw: but that might well be a good thing
<rogpeppe> axw: because then there's no way that any client can do anything at all with an environment with no secrets
<axw> hmm
<rogpeppe> axw: the other thing that i'm thinking about is how does the server know when secrets have been pushed
<rogpeppe> axw: the most straightforward approach is simply to get the environment config and see if there are any secrets in it
<rogpeppe> axw: but perhaps there might be an environment that has no secrets
<rogpeppe> axw: ha, that's actually not a problem, i realise
<axw> rogpeppe: I thought the idea was an environ's config must be invalid if it doesn't have its secrets
<rogpeppe> axw: yeah, it is
<rogpeppe> axw: but we don't even need to create the Environ
<axw> rogpeppe: as for allowing no secrets... sounds preferable to require them always, but I don't know if there's a case or not
<rogpeppe> axw: because we've got EnvironProvider.SecretAttrs
<rogpeppe> axw: so if that returns nothing, we know that we don't require secrets to be pushed
<axw> ah yeah, I see. then we can distinguish an invalid env from one with no secrets
<rogpeppe> axw: yeah
<rogpeppe> axw: although...
<rogpeppe> axw: perhaps it might be a good plan to actually validate the environ
<rogpeppe> axw: something we can't do currently
<axw> can't?
<axw> rogpeppe: why can't we?
<rogpeppe> axw: because clients talk directly to mongo
<rogpeppe> axw: so there's nothing stopping a dodgy client pushing a bad environ config
<axw> ah ok, I see
<axw> there's no good time to do it currently
<rogpeppe> axw: the other thing that occurs to me is that we could cache "secrets pushed" in the apiserver.Server (because it can only go from false to true), meaning that any api server would only need to check once
<rogpeppe> axw: but that's just an optimisation (but one that's not possible if the secrets checking is done client-side)
<axw> rogpeppe: is all of this going to break the GUI horribly?
<rogpeppe> axw: i don't think so
<rogpeppe> axw: because AFAIK the GUI can't currently make the first connection anyway
<rogpeppe> axw: and the Login call can be changed in a totally backwardly compatible way
<axw> cool
<rogpeppe> axw: so to summarise, how does this sound? http://paste.ubuntu.com/6363731/
<axw> rogpeppe: sounds great.
<axw> rogpeppe: are you planning to do this yourself, or are you working on other things?
<rogpeppe> axw: i'm currently oriented more towards the HA stuff - if you feel like doing this, it would be great.
<axw> sure, I will look into it (probably in the morning)
<jam> axw: just to let you know, I'm currently poking a lot of stuff underneath login (PasswordHash) stuff
<jam> it probably won't conflict, but you might want to wait a sec on it
<axw> jam: ok no worries
<rogpeppe> jam, fwereade: how does the above plan look to you?
<axw> thanks
<jam> rogpeppe: I *think* it is all unnecessary. thumper was quite keen on changing "juju bootstrap" to wait until it can connect to the API server
<jam> in which case
<jam> bootstrap does all the work
<jam> and then we don't have to do it for every API connection.
<rogpeppe> jam: i don't think that's viable
<jam> rogpeppe: because ?
<rogpeppe> jam: what happens if someone interrupts "juju bootstrap" ?
<jam> rogpeppe: they have to start over
<jam> they don't have more than 1 machine at that point
<jam> so we aren't destroying an environment that is well set up anyway
<jam> Or we allow "juju bootstrap" to start where it left off
<fwereade> rogpeppe, jam: the plan was to catch interrupts and takes the machine down if it's interrupted
<rogpeppe> fwereade: i'm not sure that's great actually - what if the network is down? does that mean you can't interrupt bootstrap?
<fwereade> rogpeppe, jam: blocking bootstrap actually has a lot of advantages -- no silly secrets dance, ability to create storage in the environment instead of the provider
<fwereade> rogpeppe, it just fails
<jam> fwereade: I'm a big fan, plus the fact you can give the user feedback about how far it gets
<fwereade> rogpeppe, don't think it's any worse than the network going down during a normal bootstrap
<fwereade> jam, rogpeppe: indeed, useful feedback during bootstrap is also awesome
<jam> rather than trying to do that at every "juju status" or "juju deploy" or ... etc
<fwereade> jam, in a sense that's just an extension of the secrets dance, but yeah, would be good to drop it entirely, no argument
<rogpeppe> fwereade: FWIW i think we can create storage in the environment instead of the provider anyway, can't we?
<fwereade> jam, rogpeppe: the question is *when* thumper is likely to do this, because we need some solution for the cli-api work
<jam> fwereade, rogpeppe: going back to another discussion, I'm going back to the PasswordHash stuff, and splitting it into a UserPasswordHash(password, salt) and AgentPasswordHash(password)
<jam> where we allow CompatPasswordHash, but if that succeeds, we then change the DB to set it to the new methods
<jam> fwereade: well, 'juju status' and 'juju deploy' are going to be some of the last steps we actually finish :)
<fwereade> rogpeppe, well, we do, for the manual provider -- but that's a blocking bootstrap ;)
<jam> we can set someone on it, even if it isn't thumper
<rogpeppe> jam: i don't think you can salt user passwords until the entire CLI is API, can you?
<fwereade> jam, heh, axw springs to mind given that he did the manual stuff -- it's just "make everything else work like manual bootstrap" :)
<axw> heh
<fwereade> jam, axw: modulo *also* needing provider storage -- or some alternative mechanism -- to store the bootstrap info
<jam> rogpeppe: so we don't salt the Mongo password, so I don't think that actually changes, it is just when someone *does* connect via the API, we look up the hash + salt.
<axw> jam, fwereade: per my email before, lack of secrets via API kinda blocks work I'm doing
<axw> I can move onto destroy-environment maybe
<axw> but otherwise, I could look at the secrets/bootstrap business
<rogpeppe> jam: currently we do hash the mongo password, but i guess we could use a known salt for that
<rogpeppe> jam: (in fact that's what we do currently)
<jam> rogpeppe: CompatPasswordHash() uses the same UserPasswordHash(password, FIXEDSALT)
<rogpeppe> jam: seems reasonable
<rogpeppe> jam: while we're about it, can we increase the password strength?
<jam> rogpeppe: 18-bytes of entropy is about 2^53 or so. We could easily go up to 24 (and get 32-byte base64 passwords). which gets us up into 2**72.
<jam> I may be wrong on the exact values
<jam> but < 2^64 today, and >2^64 with a size bump.
<jam> rogpeppe: the code itself says "we stick to 18-bytes because mongo uses md5sum anyway"
<rogpeppe> jam: i'm thinking we could usually use 256-bit random passwords and hashes
<rogpeppe> s/usually/usefully/
<jam> rogpeppe: I honestly don't think that improves our actual security, but yes, we could make it really big.
<jam> #1 mongo is still the most critical part
<jam> as getting *that* password gives you everything
<rogpeppe> jam: yeah, but cracking the user password might give you access to other environments
<jam> rogpeppe: doesn't matter, we don't set the user password
<jam> and these passwords that we are generating are only good for a given agent
<jam> so no leakage
<jam> we're using sha512 as our hash, so we have room internally
<jam> if mongo is using md5sum
<jam> then that would be 128 bits
<jam> but 18 bytes of entropy = 2^144 (i was doing the math wrong before)
<jam> so we're already better than md5
<rogpeppe> yeah, i thought your numbers looked weird (i thought you perhaps meant 10^53)
<jam> rogpeppe: I was doing 8 bytes == 8^8 rather than 256^8
<rogpeppe> jam: or 2^(8 * 8)
<rogpeppe> jam: (easier just to work in bits, i reckon)
<jam> rogpeppe: so because we take the raw bits and put it into base64 encoding, the useful bits are 18 bytes, 24 bytes and 30 bytes
<jam> since those leave us with a base64 password that doesn't have '=' padding.
<rogpeppe> jam: tbh a 144 bit random password is probably ample
<jam> rogpeppe: for our attack surface I think it is more than ample myself
<rogpeppe> jam: that's not gonna be the way that someone breaks into our system
<jam> rogpeppe: yeah, I was considering it when my math was bad, because 2^64 isn't great security. but 2^144 is perfectly fine
<rogpeppe> jam: yeah
<rogpeppe> fwereade: are you around for a chat about the HA stuff?
<rogpeppe> fwereade: ah, it's standup in a mo actually
<dimitern> rogpeppe, mgz, fwereade: standup
<mgz> ta
<jam> fwereade: standup?
<jam> fwereade: https://plus.google.com/hangouts/_/calendar/am9obi5tZWluZWxAY2Fub25pY2FsLmNvbQ.mf0d8r5pfb44m16v9b2n5i29ig
 * TheMue => lunch
<tasdomas> does juju support tokens in config.yaml? I.e. in cases where one value is dependant on another one (like base path and subfolders)?
<mgz> tasdomas: nope
<tasdomas> mgz, right, thanks
<abentley> sinzui: did thumper fill you in on the lxc/local-provider developments?
<sinzui> No, but I saw the branch merge
<abentley> sinzui: I did a test run after the branch merged and the local provider still failed, but I did not have time to check whether it was the same issue as before.
<sinzui> abentley, are you using mysql in the test?
<abentley> sinzui: Yes.
<jam> rogpeppe1: fwereade: https://code.launchpad.net/~jameinel/juju-core/faster-passwords/+merge/193667 has been updated. It now sets a Salt for User passwords and uses clearly denoted AgentPasswordHash vs UserPasswordHash vs CompatPasswordHash
<rogpeppe1> jam: looking
<jam> I haven't had a chance to test live upgrades, but I have every belief things will JustWork
<rogpeppe1> jam: one thing that occurs to me as *potentially* useful in the future, if we have many "users" that are actually agents, is that if we've generated the admin secret automatically (i.e. it's got lots of entropy) we could eschew the salting.
<rogpeppe1> jam: something to think about for the future, perhaps
<jam> rogpeppe1: well, eventually we'll get real users
<jam> we do often generate admin-secret today
<rogpeppe1> jam: indeed.
<jam> but, meh, salting is cheap, I'm only looking to change this stuff for the AgentPasswordHash changes
<rogpeppe1> jam: salting is cheap, but UserPasswordHash is not. at some point in the future, we *might* come to a situtation where we've got many agents (the GUI is one example) that reconnect when an API server goes down, and hence use lots of CPU resources when doing so
<rogpeppe1> jam: so, i guess i'm not really talking about the salting per se
<rogpeppe1> jam: anyway, it was just a thought that occurred to me; ignore me :-)
<abentley> sinzui: my test was invalid, because it started with 1.16.x, which isn't expected to have a fix yet.
<sinzui> ah
<sinzui> abentley, we could add stable branches to the test? juju/1.16 will build a 1.16.3 client and server
<abentley> sinzui: Certainly.  Did that temporarily for thumper yesterday.
<abentley> sinzui: Are you in the stand-up?  I switched my urls around.
<rogpeppe1> jam: why is environs/cloudinit.go using CompatPasswordHash ?
<jam> rogpeppe1: that is the old "use the hashed password until we can use the real one"
<sinzui> abentley g+ is asking me to juggle three identities
<abentley> sinzui: Fun.
<rogpeppe1> jam: why can't we use a salted password there too?
<jam> rogpeppe1: that would require changing what we pass to cloud-init, I think
<rogpeppe1> jam: (after all, it's actually one of the most insecure places that the admin password is kept)
<rogpeppe1> jam: yes, it would.
<rogpeppe1> jam: is that a problem?
<jam> which is something I wasn't as comfortable with because it isn't hidden behind the api
<rogpeppe1> jam: i'm not that comfortable seeing "Compat"PasswordHash being used in a place where it looks like it will not be deprecated.
<jam> rogpeppe1: regardless, the data we write to cloud init gets rewritten anyway,
<rogpeppe1> jam: how do you mean?
<jam> rogpeppe1: I'm fine changing the name back, or having multiple names for the same thing.
<jam> rogpeppe1: once an agent is up, it resets its password
<jam> so it won't match what is in cloud-init
<jam> and bootstrap changes the admin password back to the real password rather than the hashed password
<rogpeppe1> jam: but the admin password is still hashed in cloud-init, no?
<rogpeppe1> jam: so someone that gets access to the cloud-init data (probably not too hard) can still brute-force the non-salted admin password AFAICS
<rogpeppe1> jam: if we *are* going to salt user passwords, i think that's probably one of the most important places to do it
<natefinch> rogpeppe1, jam:  any place we *can* salt passwords, we  should.  It's not computationally expensive, and even if we're not too worried about that vector of attack, it certainly can't hurt.
<jam> rogpeppe1: so I dont think anything I've done precludes us adding salt there, and I think bootstrap is particularly a place where it is easy to break compatibility accidentally
<rogpeppe1> jam: yeah, it *would* mean you couldn't use a new juju to bootstrap with old tools
<rogpeppe1> jam: but perhaps you could change the occurrences of CompatPasswordHash to call UserPasswordHash with the known constant salt - then it's more obvious what's going on, perhaps. And a TODO in the code would be nice too.
<rogpeppe1> jam: you have a review
<abentley> sinzui: As we move to have more sets tests running, we'll want to have multiple versions of juju running concurrently.  Which makes me think we need to chroot (not lxc because that would break local provider).
<sinzui> abentley, I understand
<tasdomas> I am getting a strange panic when running go test on juju-core/worker/uniter
<tasdomas> http://pastebin.com/ER6GUuza
<tasdomas> (this is juju-core trunk)
<jcsackett> sinzui: just realized what time it is. are we 1x1ing?
<sinzui> jcsackett, sorry, had another meeting
<abentley> sinzui: AFAICT, it's impossible to run "make clean", because "go list -e -f '{{.Dir}}' launchpad.net/juju-core" doesn't find anything.  I could do "bzr clean-tree --unknown --ignored"
<sinzui> abentley, the make-recipe-and-package script creates a new directory with the revision in the name, so I don't understand how we could be reusing a built tree.
<abentley> sinzui: Yesterday, I was testing 1.16 in the tree normally used for trunk.  With bad luck, a 1.16 revno could match a trunk revno.
<sinzui> ah@
<sinzui> abentley, I have experienced that just after I created the 1.16 branch
<abentley> sinzui: I also trigger the tests manually, without waiting for the revno to update, but that's probably less of an issue.
<bac> jcsackett: are you around?  can we talk in a bit?
<abentley> sinzui: I'm adding the clean-tree anyway to reclaim disk space.
<sinzui> Yay
<jcsackett> bac: sorry, i missed your message earlier. i can chat now, if you like.
<bac> hi jcsackett
<bac> now is good
<jcsackett>   bac: g+?
<bac> jcsackett: https://plus.google.com/hangouts/_/72cpjm0fnhduq36l7pim15v0mk?hl=en
<jcsackett> sinzui: can you join in on the above g+? ^
<jcsackett> sinzui: nm.
 * rogpeppe1 is done for the day.
<rogpeppe1> g'night all
<bac> sinzui: would you have a moment to review my one-line migration script?  i'll get someone else to look at the rest.  https://codereview.appspot.com/21790045
<jcsackett> sinzui: can you look at https://code.launchpad.net/~jcsackett/charmworld/rollback-422/+merge/193999 today?
<sinzui> bac, jcsackett I can start the reviews now
<jcsackett> sinzui: awesome, thanks.
<bac> sinzui: please do jc's first
<sinzui> jcsackett, r=me
<jcsackett> sinzui: thanks.
<jcsackett> bac: i'll ping you when i've qa'ed it on staging.
<thumper> sinzui: morning
<thumper> sinzui: thoughts on 1.16.3?
<sinzui> bac: LGTM. Thank you for updating the migration template
<bac> cool.  thanks for looking at the migration stuff sinzui.
<bac> jcsackett: any problem with me landing my branch now or do you want me to wait?  i can walk the dog now and do it later
<sinzui> bac: I am just happy we remember that es-update is automatically run for us
<jcsackett> bac: i don't think our branches collide, so it should be fine.
<sinzui> thumper, These bugs are fix releases in stable. they are fixed in trunk. I think I can mark these as fix released because everyone has the fix https://bugs.launchpad.net/juju-core/+bugs?search=Search&field.importance=Critical&field.status=New&field.status=Incomplete&field.status=Confirmed&field.status=Triaged&field.status=In+Progress&field.status=Fix+Committed
<thumper> sinzui: well, kinda, are we going to roll out 1.17?
<thumper> should we make them fix released when we release them?
<sinzui> I was think of doing it this week, but doing 1.16.3 might exhaust me
<thumper> well, bug 1246556 is in 1.16.2
<_mup_> Bug #1246556: lxc containers broken with maas <api> <maas-provider> <juju-core:Fix Committed by thumper> <juju-core 1.16:Fix Released by thumper> <juju-core (Ubuntu):Fix Released> <juju-core (Ubuntu Saucy):New> <juju-core (Ubuntu Trusty):Fix Released> <https://launchpad.net/bugs/1246556>
<thumper> so I think that should be fix released
<thumper> hmm, I see the 1.16 task is released
<thumper> personally I'd rather not have them marked fix released until we have a release with the fix
<thumper> fix committed is enough to say they are in trunk
<sinzui> thumper, I think only your addition last night is unreleased as well as the complicated maas bug
<thumper> sinzui: I was concerned that we'd break people in a charm school at ODS
<thumper> as the local provider is broken for everyone
<thumper> due to an old mistake and a precise update
<jcsackett> bac: qa-ok.
<jcsackett> bac: how did you cleanup the bad old review jobs last time? my terminal-fu is weak, and we have processes that won't die.
<sinzui> thumper, yes, but not every charm is affected. I wont push back on the releases, but each releases of stable delays other work. It took days to get 1.16.2 to every place it had to be
<thumper> sinzui: hmm, not every charm, but the local provider is broken now
<thumper> for everyone except those compiling trunk
<thumper> no install hooks complete
<thumper> because apt is left in an incomplete state
<sinzui> look at https://bugs.launchpad.net/juju-core/+bug/1240709. I think this is fix released for everyone because the juju-core maintains stable and devel trees.
<_mup_> Bug #1240709: local provider fails to start <local-provider> <juju-core:Fix Committed by thumper> <juju-core 1.16:Fix Released by thumper> <juju-core (Ubuntu):Fix Released> <juju-core (Ubuntu Saucy):New> <juju-core (Ubuntu Trusty):Fix Released> <https://launchpad.net/bugs/1240709>
<bac> jcsackett: it was in such a sad state i just rebooted the charmworld instance
<sinzui> thumper, I typed into the to wrong channel 30 minutes ago: thumper I can do it. I was hoping that that CI would be up today. but abentley and I have had to rethink the branch + revno tactics used with jenkins
 * thumper nods
<thumper> Normally I wouldn't be too concerned, but with ODS and charm school...
<thumper> could look real bad
<sinzui> thumper, remember that the release takes between 8 hours and many days
<thumper> :(
<sinzui> I don't want to be rushed it it has to be rushed because we don't control the builders and the copy step just adds more hours to the release
<sinzui> thumper, If I had off a package in a few hours, I can hope that I have something to republish to end users in the first hours of my morning
<sinzui> s/had/hand/
<thumper> sinzui: I think we wouldn't need to push new tools
<thumper> sinzui: as 1.16.3 should get 1.16.2 tools
<thumper> which would work fine
<thumper> the only change is in the local provider cloud-init config
<sinzui> because juju-core (client and server) are deployed by the client on the same machine?
<thumper> yeah
<thumper> the local provider always pushes local tools
<thumper> it is horrible
<thumper> and we should fix it to be nicer
<thumper> but it works for now
<sinzui> thumper, this is an awkward position to take because we have gone out of our way to ensure the jujuds are published before users get the clients
<thumper> :)
<sinzui> The number mismatches are scary
<thumper> I understand
<thumper> was just trying to make things easier
<thumper> but I can understand that it isn't working
<sinzui> thumper, jamespage makes the stable packages...
<sinzui> but I could go crazy and upload my own package to the builders. My packaging does not yet support dpkg alternatives, which would be a nasty regression for IS
<sinzui> and I haven't fix packaging because I personally spent 2.5 days releasing 1.16.2
<thumper> wow, why so long?
<sinzui> CI does not test stable yet. I do all the testing, send the tarball for building. While it builds I write release notes and steal natefinch's time to get a window's installer, and setup all the upgrade tests again. When I see all packages are build, I spend an hour assembling the tools and publishing them. Then a few hours testing that everything works still. Then I do the release annoucements, Then I work on windows and mac
<sinzui> distribution with upstreams
<sinzui> If Hp loses authentication like last time, I can spend 90 minutes flailing to get jujuds in the cloud
<sinzui> thumper, how many hours until charm school?
<thumper> sinzui: no idea, best asking jcastro or marcoceppi
<thumper> I don't know that there is one
 * sinzui is calculating risk and time
<thumper> but they normally do something
<wallyworld> fwereade: hey, any update on bug 1233457?
<_mup_> Bug #1233457: service with no units stuck in lifecycle dying  <cts-cloud-review> <destroy-service> <juju-core:Triaged> <https://launchpad.net/bugs/1233457>
<thumper> sinzui: news isn't good, cts is doing the charm school
<sinzui> when?
<thumper> don't know
<sinzui> thumper, I have a release plan nonetheless https://docs.google.com/a/canonical.com/document/d/1J0xf_G1ZRU5timhVBnPsrDbQmZmW3iuw02ReCpO9cMk/edit#
<thumper> sinzui: weird
<thumper> sinzui: I paste that in to the browser and get nothing
<thumper> not an error, just nothing
<sinzui> thumper, I think you are not logged in as your canonical id
<abentley> thumper: I could see it.
<sinzui> thumper, I can go through the steps to the tarball phase. At that point I could return to fixing the devel packaging rules. When the rules are compatible, I can safely place packages into any archive. OR we appandone recipe...just ignore that is who we build test packages and fall back to tarball + packaging + bzr
<thumper> sinzui: do you have 1.16 installed locally?
<thumper> abentley: do you have 1.16 and not trunk?
<sinzui> If I have the right rules, I am unblocked from loading the package to any archive
<sinzui> thumper, I do, the current packaging rules do not support dpkg switch...IS cannot use pyjuju in production
<abentley> thumper: I have 1.16.0 on my local machine.
<thumper> abentley: 1.16.0 or 1.16.2?
<abentley> thumper: It claims to be 1.16.0.
<thumper> hmm...
<thumper> abentley: does it start the local provider?
<abentley> thumper: At the sprint, it worked sometimes.
<sinzui> oh, thumper , abentley you might be referring to my quickly put together notes. stable is 1.16.2 now. that is what we test
<thumper> funny, but my system one says 1.16.0 too
<sinzui> thumper, depending on your mirrors and update checks you can be a few weeks behind
 * thumper nods
<thumper> sinzui: my ppa's were probably disabled when I moved to saucy
<thumper> and I've not enabled them
<thumper> yet
<sinzui> thumper, The only way for me to get the 1.16.3 to complete the release is to install the deb I pulled locally, or bleed. I am running trusty (bleed)
<thumper> :)
<thumper> I'm not that trusty of trusty
<sinzui> I still think of her are tarty
<thumper> sinzui: what is the doc called? going through the listing
<thumper> link still doesn't work, and I am logged in with the right creds
<fwereade> wallyworld, heyhey
<sinzui> thumper, 1.16.3 Release Log
<wallyworld> hi
<wallyworld> fwereade: just thought i'd check in in case i could help at all
<thumper> sinzui: can't find it
<thumper> sinzui: can I get you to check the sharing on it?
<sinzui> thumper, try again
<sinzui> I think I have ensured the entire folder is searchable
<thumper> sinzui: nope...
<thumper> what is the folder?
<sinzui> thumper, "Juju QA" and I just shared the doc directly with you.
<thumper> restarting chromium seemed to help
<wallyworld> fwereade: also, save me some search time - is there currently a way to get an environs.Environ instance using an apiclient made from a call to NewAPIClientFromName? I can't see a way
 * sinzui starts blessing and cursing
<thumper> sinzui: expose on the local provider does precisely nothing
<thumper> sinzui: also, why test installing apache not mysql?
<sinzui> thumper, That was copied from the 1.16.3 release. I am going to do the mysql + wordpress stack. The apache charm was an example of a charm not affected by the apparmor/cgroups issue
<thumper> sinzui: wow, that is quite a list
<sinzui> This is half the size of the 1.16.2 that has canonistack, hp, azure, and ec2
<davechen1y> linkage
<sinzui> If I die, someone can check off the boxes I didn't get too
<davechen1y> sorry, i missed the discussion
<abentley> thumper, sinzui: I just tested 1.16r1982, and mysql was unhappy: http://162.213.35.28/job/test-no-upgrade-stable/3/console
 * sinzui looks
<thumper> abentley: this isn't the local provider
<abentley> thumper: Yeah, I don't know whether it was caused by the local provider or just happened on the local provider.
<thumper> abentley: looked like it was happening on the hp test
<thumper> isn't it?
<sinzui> yep
<sinzui> that is the very risk I am taking with my plan. The change only affected the local-provider
<abentley> thumper: No, we set them up in parallel to reduce lag.
<abentley> thumper: So exposing on test-release-hp is the last thing we did before we turned our attention back to the local provider.
<thumper> abentley: do you have access to logs?
<thumper> I don't entirely believe this
<abentley> sure, what do you want?
<thumper> /var/lib/juju/containers/*/console.log
<thumper> from the machine running the local provider
<sinzui> abentley, thumper I commonly see start-errors with local. I did *not* get errors starting mysql+wordpress with 1.16.2 just now. I am setup for an upgrade test
<thumper> sinzui: really? WTF?
<thumper> I guess it is good...
<thumper> but kinda shit
<thumper> sinzui: doing mysql+wordpress with the local provider?
<sinzui> I have noted in the past that mysql seems to work between the hours of UTC 0 and 6
<sinzui> yep
<sinzui> thumper, remember when you helped my last week with local provider...that is the thing I deployed 3 times to convince myself all was good...
<davechen1y> 09:40 < sinzui> I have noted in the past that mysql seems to work between the hours of UTC 0 and 6
<davechen1y> o_O!
<sinzui> then the next morning mysql told me to go fuck myself
<davechen1y> sinzui: are you running through squid-apt-proxy ?
<thumper> sinzui: it worked last week, but I didn't expect it to work today...
<sinzui> davechen1y, not in this test
<davechen1y> if N, maybe that would make things more reliable^h^h^h^h^h reproducable
<sinzui> I have a package. I will do the upgrade
<abentley> thumper: mailed to you.
<thumper> ta
<sinzui> thumper, abentley local 1.16.2 to 1.16.3 worked.
<thumper> abentley: the error seems to be unrelated to apt or lxc, but a networking glitch
<thumper> near the end of the first machine log file
<abentley> thumper: it appears that mysql is on the second machine.
<abentley> thumper: And that the problem is with mysql itself not coming up.
<thumper> abentley: unit log file for it?
<abentley> thumper: something different from local-machine-2/console.log?
<thumper> abentley: yeah...
<thumper> is the environment still "live"?
<abentley> thumper: No, it's down.
<thumper> bugger
<thumper> that means the internal log files are gone too
<sinzui> 1.16.3 deployment of mysql+wordpress == PASS
<abentley> thumper: It might just be ENOMEM.
<sinzui> tarball is building
<sinzui> thumper, I have a tarball that I am willing to (and have) signed. I could send this to be packaged. I would prefer to fix my packaging branch. If I cannot solve its dep problems by my bedtime, I can send off the tarball.
 * wallyworld off to accountant, bbiab
<sinzui> thumper, do you have any insight into why this upgrade did not complete? http://pastebin.com/QuLFM3hq
<sinzui> oops, thumper, I think this has the log that shows a failed upgrade http://pastebin.com/3dTCS9W1
#juju-dev 2013-11-06
 * thumper looks
<thumper> sinzui: no. sorry
<thumper> sinzui: but I have felt that our upgrade story is too flakey
<thumper> I have plans (in my head)
<thumper> and half written down
<sinzui> yeah. Sometimes I need to wait forever for it to happen. I cannot predict if it is slow or will fail
<sinzui> but I think the 14 -> 16 upgrades are better than 12 -> 14
<thumper> :)
<axw> thumper: I'm updating the API to support pushing secrets now. I was chatting with rogpeppe yesterday, and we discussed having a negotiation thing during login. Then fwereade and jam reminded us that you were keen on making bootstrap blocking, and secrets-pushing can go there
<axw> so... I'm just going to add an API call to push secrets. sound ok?
<axw> we'll unconditionally call it when making an API connection for now, and later just during bootstrap
<thumper> sure
<thumper> and yes we want bootstrap synchronous
<thumper> it would solve all manner of bootstrap issues
<thumper> sure
<thumper> wallyworld: FYI -  https://codereview.appspot.com/22320043
<wallyworld> thumper: looing
<wallyworld> looking even
 * thumper goes to help with dinner, then swim
<thumper> I'll be back later this evening
<wallyworld> +1000 to synchronous bootstrap. a lot of us have been wanting that for ever
<wallyworld> so long as there's feedback as it executes
<davecheney> WHOOOOOOOOOOOOT!
<axw> ooh
<axw> yay for output :)
<sodre> ping ?
<sodre> what is the standard way of including charmhelpers in a charm ?
<sodre> i.e. should I branch charmhelpers and check it in together with the rest of my charm?
<bradm> sodre: thats what I've done in my charms, but I don't know if its considered best practice
<sodre> bradm: thanks.
<jam> sodre: from everything I've seen you copy charmhelpers into your code
<sodre> jam: alright :) That's how I'll do it then.
<jam> axw: I don't think we want to call it uncondionally during api.Open
<axw> jam: why not?
<jam> axw: we only need to pass secrets 1 time, rather than the 100 times you ever call status/etc8
<axw> jam: sure, but detecting that requires feedback from the server - seems like a lot of work for something that's going to go away soon
<axw> we currently go to state each time we connect to see if we need to do it
<axw> oops, race dector'd my machine
<axw> detector'd even
<jam> race decor'd sounds more interesting
<axw> jam: if you replied, I missed it. last message I have is "we currently..."
<jam> no, I didn't say anything
<axw> ok
<axw> jam: I realise doing it every connection sucks, so if there's a non sucky way, I'm open to suggestions
<jam> axw: is it that hard to add an extra field to Login that says now that you've logged in, can you send the credentials
<jam> ?
<axw> jam: the Login code knows nothing about environments or secrets. It's probably not hard, just felt a bit wrong. I don't know that area of the code well, though
<axw> well, it knows the state object of course
<jam> axw: so I think we need a state/api/client level interface that supports passing secrets in, no doubt about that.
<axw> jam: ah, you're suggesting a result from Login that says the next call should be PushSecrets?
<jam> axw: looking at Login today, all it can return is an err
<jam> and if we changed *that* behavior
<jam> it would break things like the GUI
<axw> yup
<jam> I suppose that might be ok, since the GUI can't ever send secrets?
<axw> one idea that came up was returning a special error
<axw> right
<jam> so you have to always connect via another means 1st time anyway
<jam> I'd really like to run it by gary_poster|away or someone else on his team
<jam> I think they're all mostly US time based
<axw> ok
<jam> axw: so the Client api for pushing up secrets is needed regardless, we'll likely use it in bootstrap, etc
<jam> axw: do you know about "directory.canonical.com" ?
<axw> jam: yeah, I was thinking you were talking about the idea of adding secrets into the Login call itself, which I think is too much work
<axw> jam: sure do
<jam> so frankban is the only one in EU timezone. Huw is in AU, but he's more Web/UI focused.
<jam> axw: so I wouldn't put the secrets *into* Login, because I would avoid putting them on the wire as much as possible
<jam> I was hoping Login had a nice way of telling you something after you login
<jam> rather than only returning an err
<jam> and that would give us a way to extend it with "please upload secrets" without telling clients to shove off
<jam> err => most clients will probably just disconnect right away
<axw> jam: yeah. I think GUI requires it to be there already, but I can check with gary_poster|away
<jam> axw: I actually don't think it strictly does, though to install the GUI you would have had to pass the secrets
<jam> because, you have to "juju deploy" the gui
<jam> so actually, I think we're ok there
<axw> well, sorry, that's what I meant
<axw> implicitly requires :)
<jam> sorry I'm mostly catching up to something that you've probably thought more about
<jam> so I think short term putting the err return in Login is ok
<axw> that's cool
<jam> because we don't have much juju client stuff that connects via the api in older versions
<jam> just add-unit and get
<jam> and you are very unlikely to call either of those
<jam> until you've run some other command
<jam> which is why we could get away with it :)
<axw> hehe
<jam> axw: it *was* why I picked those. That and they were pretty straightforward.
<jam> axw: if you don't mind investigating a bitd
<jam> bit
<jam> can you see if we can add a return parameter to Login that isn't an err?
<jam> and see if old clients complain about it
<axw> jam: sure, will do
<jam> axw: because if we can do that compatibly, I can see a use case for doing other things at Login time
<jam> giving hints about compatibility, etc
<axw> I'll get the new API call working first, then go onto the Login stuff and look at that first
<jam> so adding a struct to the return will be generally beneficial
<jam> but if we need to go the err route, I think that's ok
<axw> sounds good
<jam> axw: I would even go as far as propose the API call so that we can land it
<jam> so you don't have to have that pending in a branch
<jam> unless you think it might need tweaking based on your other results
<axw> we'll see, tho I expect the only thing that'll change is where it's called
<jam> (one thought, bootstrap doesn't ever connect as a Client today, so it might just push the secrets direct into the DB, though the fact that we want bootstrap to hang around until the API is up, maybe it is sane to have it do the Client login as well...)
<jam> axw: in which case, it would just be the first thing that logged in
<jam> axw: I don't really like it being an err as a general quality thing
<axw> yeah that did occur to me - we could just leave that bit alone once it's implemented for the general case
<jam> but I could live with it
<axw> yup, fair enough
<axw> it's not an error, after all
<jam> axw: so looking at state/api/Login today, it just passes "nil" for the response struct
<axw> jam: yeah, but does adding one after the fact break the clients? that's what you're asking me to investigate, right?
<jam> axw: right. I'm poking around right now :). If resp == nil ; resp = &struct{}{} and then we still call conn.codec.ReadBody(resp, isRequest)
<jam> so it looks like
<jam> current clients will still consume a body response, and just throw it away
<jam> which is fine
<axw> cool
<jam> axw: but we should probably test that in practice :)
<axw> and clients ignore extraneous fields, right?
<jam> axw: generally, yes
<jam> JSON.Unmarshal loves throwing away unrecognized things
<axw> heh
<jam> axw: AFAICT there's no way to pass it a Strict flag
 * jam => away for lunch and groceries
<axw> later
<jam> axw: to summarize before I go. It looks like putting it as an extra parameter is going to be just as much work and just as compatible with the existing clients, rather than changing the Err, so I'd rather do that.
<jam> but, as always, testing with 1.16 against a running patched 1.17 is probably worthwhile
<axw> jam: agreed, I will go with that.
<axw> (and test)
<dimitern> morning all
<thumper> fwereade, jam: do you guys have time for a catch up hangout?
<fwereade> thumper, sure
<thumper> fwereade, jam: https://plus.google.com/hangouts/_/76cpjgbfmbsvbg46v349h6l5ug?hl=en
<wallyworld> dimitern: hi there. how close are you to finishing the get-environment migration to the api?
<dimitern> wallyworld, get-env is done, finishing set-env now and proposing both
<wallyworld> dimitern: great :-) cause i need the ability to get environ config via api and i figure your work will include that
<dimitern> wallyworld, yeah
<dimitern> wallyworld, basically, you can use client.api.state.EnvironConfig to get it, where client is the "c" receiver of the method
<wallyworld> ok, thanks
<wallyworld> i need EnvironConfig() exposed in state/api/client
<axw> wallyworld: is that for add-machine?
<wallyworld> yeah
<wallyworld> the manual provisioning
<axw> ah
 * wallyworld -> dinner, bbiab
<jam> fwereade: I take it you and tim already finished up?
<jam> wallyworld, dimitern: I think we need to think reasonably carefully about exposing all of EnvironConfig via the Client API. Because it ends up having environ credentials which we don't want to expose to something like the GUI (I think).
<wallyworld> jam: i need it to create an environs.Environ instance. we could audit the usage of that to see what's really needed. it will be messy
<jam> wallyworld: what do you need for Environ given you are doing manual provisioning?
<jam> (I have the feeling it is accidentally using something it shouldn't)
<jam> just so it can do something like get AuthorizedKeys
<wallyworld> jam:  it's used in the manual provisioning code in a few places
<jam> which we ran into for the Provisioner
<wallyworld> setting up auth is one such usage i think
<wallyworld> finding tools is another
<wallyworld> i can't recall the third offhand
<jam> wallyworld: given what you've been saying about avoiding provider storage at all, is that something we are trying to get away from?
<jam> anyway, I can see it being necessary today, though I'd like us to understand what we really need, because we've run into several cases where we really didn't want it
<wallyworld> possibly. i'm initially looking to just do a straight port
<wallyworld> agreed about seeing what we really need
<wallyworld> will get messy, so looking to do it in stages
<jam> wallyworld: right, the main problem with just the straight port is that we can expose secrets that we don't want to commit to supporting
<wallyworld> well, we use State now to get a full env in the current code
<wallyworld> so the cmd has secrets today doesn't it?
<jam> wallyworld: yes, but it has straight DB access today. The issue is that this isn't the only point that uses Client
<jam> GUI uses it directly, for example
<rogpeppe1> mornin' all
<jam> and we are trying to support juju -the-commandline that doesn't have raw access to EC2 creds
<wallyworld> jam: ok, and you are saying as soon as we add that to the api the gui could misuse it
<jam> so that you can share your env in a limited fashion
<jam> wallyworld: I'm not saying the GUI would, because i trust Gary et al, but it is *an* api that is leaking security in a place where we weren't before
<rogpeppe1> jam: what about the case where a GUI client actually needs to change cloud credentials?
<jam> EnvironConfig specifically
<wallyworld> jam: yes, that's what i meant
<jam> is something we've been really careful about sharing
<rogpeppe1> jam: or in fact, and client
<jam> when it came to the agents
<rogpeppe1> s/and/any/
<jam> wallyworld: I think the specific security hole is some *other* code running in the same machine where the GUI (etc) are running and getting access to secrets.
<jam> certainly that was the Uniter issue
 * wallyworld nods
<jam> we didn't want any charm to be able to get access to EnvironConfig
<wallyworld> jam: ok, so we may need to avoid the EnvironConfig via the api and stick to current method and refactor
<wallyworld> jam: but get-environment uses it afaik
<jam> rogpeppe1: that may be a use case that we need to support. *My* point is that we need to actually discuss it and decide from a security perspective rather than just saying "oh just expose this, no problem"
<dimitern> jam, wallyworld, we already have a way to mask out secret attributes in environ config - take a look at the provisioner api's EnvironConfig
<rogpeppe1> jam, wallyworld: i think that for the time being at any rate (pending user roles/permissions) we should not take away the ability for a client to see and change the environ configuration
<rogpeppe1> jam: if we don't, we're breaking backwards compatibility
<jam> wallyworld: from what I've understood from fwereade, get-environment and set-environment do far too much.
<wallyworld> i can believe that
<jam> and that is partially because we've sort of just shoved everything in EnvironConfig
<rogpeppe1> jam: i guess it's possible we want to do that, but we should at least audit current users to check how much they rely on get-environment
<wallyworld> let's discuss after standup with dimitern et al
<fwereade> jam, wallyworld: well, set-environment is terribly flaky by nature, but I think that's separate
<jam> wallyworld: like you can trigger an upgrade via set-environment
<fwereade> jam, wallyworld: yeah, that's something I would like to be very careful to avoid
<fwereade> jam, wallyworld: we may or may not have code that tries to prevent that
<jam> rogpeppe1, wallyworld: I would *guess* the #1 use case for it is to handle setting constraints, because we don't expose another way to set whole-environment values
<rogpeppe1> i totally agree that there are somethings in the environ config that really should not be
<jam> and you set whole-env values at bootstarp time
<fwereade> jam, wallyworld: but the state method does basically depend on people calling it "right"
<wallyworld> yeah
<fwereade> jam, there are no constraints in environ config actually
<rogpeppe1> jam: you can set constraints with it?
<jam> fwereade: isn't that set in "juju set-environment" ?
<fwereade> jam, nope, set-constraints
<jam> it may not be EnvironConfig but part of that command?
<jam> ah, k
<rogpeppe1> jam: if your environment credentials have been compromised and you need to change them, set-environment would seem like the right thing to use
<dimitern> fwereade, wallyworld, jam, rogpeppe1: https://codereview.appspot.com/22210044/ set/get-environment
<rogpeppe1> jam: and for debugging, i've certainly relied on get-environment before, for sanity checking (otherwise there's no way of actually finding out what environ config the agents are really using)
<rogpeppe1> jam: but we should certainly consider (at least) erasing secrets from the return of get-environment
<wallyworld> dimitern: tests?
<fwereade> rogpeppe1, jam: I *think* that's dependent on user roles/permissions, isn't it?
<rogpeppe1> fwereade: yeah, that's my thought
<rogpeppe1> fwereade: and currently we treat the client as admin, so they get everything
<jam> fwereade: so I don't have a particular stake in the matter, I just wanted to make sure it got discussed
<jam> fwereade: it would seem a strong end-run around sharing a .jenv that didn't have env creds
<jam> if the first thing you could do
<jam> is run "juju get-env"
<jam> and have access to them
<rogpeppe1> fwereade: given they can deploy to machine 0 and read the database, there's not really any security hole that we're avoiding by making the environ config available
<rogpeppe1> jam: i think that having less privileged users is something we are aiming for, but we're not there yet
<fwereade> rogpeppe1, jam: true, but I long-term expect people to create relatively restricted users and share .jenvs authing those users as themselves, rather than having anyone actually share their jenv files directly
<jam> rogpeppe1: so I think with your work about api.Open we could actually support it for many commands very soon
<dimitern> wallyworld, there are tests already that pass without change
<jam> fwereade: sure, but if we don't actually think about security at get-environment, then it is a pretty clear whole
<jam> hol
<jam> hole
<jam> anyway, meh. as I said, I wanted us to be aware of it more than anything
<wallyworld> dimitern: for the new apis? EnvironmentGet/Set?
<dimitern> wallyworld, oh, right
<jam> add-machine sounds like something that should explicitly *not* have an Environ since we aren't provisioning from the environ
<dimitern> wallyworld, will add, thanks
<wallyworld> dimitern: we've been adding new tests for those new things we add
<wallyworld> np
<jam> but I can see where it just used it so far, so we can keep doing so
<wallyworld> jam: right, so we need to understand how env is used in manual provisioning, cause that's why add-machine needs it
<wallyworld> add-machine per se doesn't need it
<wallyworld> but add machine calls into the manual provisioning api
<jam> wallyworld: right, LXC Provisioner was asking for it too, and the *only* thing it pulled out of it was authorized keys
<jam> which thumper had to work to fix
<wallyworld> manual does that too
<wallyworld> plus some other stuff
<jam> because the MaaS environ can't be created if you strip secrets out of it
<jam> so we'll run into this again with not being able to manually provision with MaaS if we just did the same thing.
<wallyworld> sounds so
<wallyworld> i've just read the manual provisioning code today for the firt time
<axw> wallyworld, jam: a couple of things spring to mind: state/api.Info (could be gotten another way), and finding tools
<jam> wallyworld: sure. So I would encourage you to see if you can do add-machine without a full EnvironConfig because it shouldn't really be using it. If it isn't worth the time, then we can hack it in
<jam> wallyworld: so we do already have a Tools api for agents, I wonder how hard it would be to expose that for an "I want a machine over here".
<davecheney> is it call the null provider
<davecheney> the manual provider
<axw> jam, wallyworld: don't we need the full env config for the provisioned machine's machine config though...?
<davecheney> or the ssh provider
<davecheney> please help
<jam> davecheney: I'm *pretty* sure we settled on Manual provisioner. However, this is still about manually registering a machine to an env that could have a regular provider.
<jam> axw: I'm pretty sure we don't
<davecheney> jam: what is SABDFL decided to call it ?
<davecheney> i understand there was a ruling
<jam> axw: Uniter and Provisioner today don't have access to all of EnvironConfig
<jam> davecheney: he liked the phrase "manual registration"
<davecheney> well, that isn't helpful
<jam> and not having the word "Provider" in there
<jam> because nothing is *providing* machines
<davecheney> +1 for semantic correctness
<jam> davecheney: so the last bit I remember was "not having provider: in the environ config and using the term manually register new machines"
<davecheney> -1,000 for usefullness :)
<fwereade> axw, we should in general never need any of the stuff in environ config
<fwereade> axw, authorized-keys is the only generally useful bit of it that springs to mind
<axw> fwereade, jam: yeah I was just revising, that's only used for manual bootstrap
<fwereade> axw, and *that* is pretty dumb and broken regardless :(
<jam> axw: right. manual bootstrap is pretty different
<fwereade> axw, because *surely* the *useful* concept is "authorized users"
<fwereade> dimitern, commented
<dimitern> fwereade, thanks
<dimitern> fwereade, not sure I get your comment about Key/Keys - it's what the command is supposed to do, no?
<fwereade> dimitern, yeah, but I'm not sure it's actually very useful at an API level
<fwereade> dimitern, I would prefer to keep the api small and orthogonal as much as possible
<fwereade> dimitern, baking into it "and this is a use case that's sometimes helpful for the CLI doesn't seem like much of a win, when the cli can filter just fine"
<fwereade> dimitern, it's kinda like `juju get` which I have a horrible feeling returns the crazy nonsense that the command outputs
<fwereade> dimitern, the api for `juju get`
<fwereade> dimitern, which is no use to man nor beast, and even if it is it should be constructed for the specific context it's used in, out of clear sensible atoms, rather than forcing that interpretation on every api user
<fwereade> dimitern, anyway I could be convinced that Keys was sensible
<fwereade> dimitern, not so much Key
<dimitern> fwereade, but there's no need for Keys
<dimitern> fwereade, it's either one key or all of them
<dimitern> fwereade, are you saying to have Keys and use only one or zero keys when calling the command and have the rest of the logic moved to the command itself (key == "" -> all keys, else just that key) ?
<dimitern> fwereade, I thought we want to make the client API as close as possible to the CLI, logic included, so the GUI can provide the same features?
<fwereade> dimitern, at the moment there's no need for keys because we have a set-env that was hacked together without much thought and it only uses one
<jam> dimitern: so I would guess the point is to think about what is actually useful in an API. Today the CLI is actually deficient in that area. If I want 3 settings, I have to do 3 round trips, when you can easily implement the API to support multiple in one pass.
<dimitern> fwereade, set-env accepts multiple key=value args
<fwereade> dimitern, then all the more reason to allow us to ask for multiple values in get, surely?
<fwereade> jam, exactly
<dimitern> fwereade, ok, I'll change EnvironmentGet to accept zero or more keys
<fwereade> jam, dimitern: we're trying to write a sane api that happens to allow for the CLI functionality
<fwereade> jam, dimitern: rather than just writing an API for the CLI
<dimitern> fwereade, and the CLI get-env will use it like that, except there'll be the bit that if key == "" -> return the map, otherwise, return just the value of the given key
<fwereade> dimitern, sgtm, I'm not *that* much against Keys ;)
<dimitern> fwereade, ok, because frankly I can't see the alternative
<fwereade> dimitern, just ask for the whole env config?
<dimitern> fwereade, always?
<dimitern> fwereade, it seems unnecessary trafficwise
<jam> dimitern: as a general guide, if it is less than 64kB it isn't worth filtering
<fwereade> dimitern, gut feeling says that's simplest and always adequate, but maybe all those extra bytes add up to an annoying degree
<jam> as the bandwidth cost == latency of a round tirp
<jam> if its big, then we can do somethnig
<dimitern> ok, I'll get rid of Key/Keys and return the whole lot always then
<fwereade> dimitern, cheers
<jam> that's at least the numbers I've found in the past
<jam> 100ms at 1M/s = 100
<jam> 100kb I guess is 12kB
<jam> though I've got 16MB and I've seen 300ms ping
<rogpeppe> jam: just saw your conversation with axw about client secret-pushing. this is what i suggested yesterday - it seems to me that this is more-or-less where you ended up, is that right? http://paste.ubuntu.com/6363731/
<axw> rogpeppe: except not putting it into Login
<axw> I started down that path this morning, it got a bit messy
<axw> Login will (after my next CL) respond with a flag saying that secrets need to be pushed
<axw> but it won't require it there and then
<rogpeppe> axw: ah, ok
<rogpeppe> axw: where did the messiness come from?
<axw> rogpeppe: possibly just my misunderstanding of the API stuff, but it seemed wrong to add knowledge of environments in there. Now that I think of it though, it's going to have to anyway...
<rogpeppe> axw: yeah, that's what i was thinking
<axw> well, either approach will not be much of a change from what I've got now anyway
<rogpeppe> axw: cool
<axw> rogpeppe: the other thing I wondered was about validating config that soon
<jam> axw: I'm wondering if we want it in api.Open or if we could do it one layer higher
<jam> NewAPIConn is what the current CLI code ends up using, and it has the ENviron there
<axw> is it possible the config is wrong at that point? then how do we fix it without being able to login?
<jam> axw: my gut instinct at https://code.launchpad.net/~axwalk/juju-core/api-push-env-secrets/+merge/194083 was that it looks like the wrong level
<rogpeppe> axw: if the config is wrong, you shouldn't be able to push it into the environment
<axw> jam: I originally had it higher, in fact. It seemed better to me to keep the Login-results-stuff inside api.Open
<rogpeppe> axw: you can fix it by pushing a correct config
<axw> rogpeppe: true, unless the correctness changes over time :p
<jam> axw: but having state/api know anything about environs secrets is ... dissapointing
<axw> rogpeppe: ah, so I was just planning to push the secrets, not the entire config
<rogpeppe> axw: well, having a bad config doesn't make the environment inaccessible
<axw> jam: true, but the apiserver is going to have to anyway, right?
<axw> rogpeppe: I'm saying if we require login to successfully Validate config before letting the API client through
<axw> (back to our discussion yesterday)
<rogpeppe> jam: i think that the api will need to know about environ secrets even when bootstrap is synchronous
<rogpeppe> axw: is that problematic?
<jam> rogpeppe: axw: so it feels very strange to push "people connecting to the API should have environ and secrets" when we *really* want to get the environ state from the api
<axw> rogpeppe: only if it's feasible that the first time you connect, config is bad. I think it's probably not, like you said.
<jam> and it is only because of the handoff that we need it for the *very first* login.
<rogpeppe> jam: only the first client connecting needs environ and secrets
<jam> rogpeppe: needs, but everything else looking at the function will go "where do I get these bits"
<rogpeppe> jam: we allow nil to be passed
<jam> rogpeppe: "allow nil to be passed" is not very good API design.
<rogpeppe> jam: and when bootstrap is synchronous, we can have a separate API call
<rogpeppe> jam: rather, a separate entry point in juju
<rogpeppe> jam: sometimes i think it's ok
<rogpeppe> jam: when the thing really is optional
<rogpeppe> jam: so we'd provide it as an argument only if we find a BootstrapConfig in the .jenv.
<rogpeppe> jam: hmm, actually there's perhaps another possibility
<rogpeppe> jam: we can actually know if we're the first to connect, because the .jenv file has no cached API address (well - that will be the case when we do actually cache API addresses...)
<rogpeppe> jam: what's your suggestion for the (juju) package API?
<jam> rogpeppe: so we could just do a "Do you need secrets" call in NewAPIConn, and if it returns true, then call Client.SetSecrets()
<jam> though even there, NewAPIConn is used by agents
<jam> I think
<axw> jam: the agents use api.Open directly
<jam> axw: k, that would be pretty clear that the 99% case is not wanting to pass in the extra data, so we probably don't want to put it there.
<jam> axw: AFAICT the only thing we gain is 1 round trip which we are going to get rid of with doing it at bootstrap
<rogpeppe> jam: it looks to me as if NewAPIConn isn't used by anything except NewAPIClientFromName
<jam> rogpeppe: it is a point where we already have the data we need, and it is called by NewAPIConnFromName which most (all?) CLI cmds will be using to connect.
<axw> jam: sorry, confused. are you suggesting that I go back to doing the unconditional API call for the client?
<jam> axw: a thought, api.Open() could cache some status onto the api object itself, so that a follow up "api.DoIneedSecrets" doesn't have to do a round trip
<jam> but we don't expose it directly in the return of api.Open
<jam> axw: well it was a "CheckIfWeNeedSecrets" unconditionally.
<jam> though the putting it in a result from Login and then caching that on the api.State object.
<rogpeppe> if it's going to go away, i don't really mind an extra round trip for every API connection
<axw> jam: what's the big difference between unconditionally calling "PushEnvironmentSecrets" instead of "CheckIfWeNeedSecrets" and t hen "PushEnvironmentSecrets"
<axw> the former does nothing if it's not needed
<jam> rogpeppe: well today we get to remove about 5 round trips by caching the API address :)
<jam> but after that it shows up more
<jam> axw: passing secrets over the wire when they aren't neededx
<rogpeppe> jam: we're talking about something which we're going to fix anyway, right?
<jam> rogpeppe: right, I'm saying we add 1 round trip here, but then we take away 5 over there pretty soon, and eventually get back to this 1
<rogpeppe> jam: so cluttering the API as little as possible seems like a reasonable approach
<dimitern> rogpeppe, should DeepEquals work and return 2 for 2 identical map[string]interface{} values?
<axw> sorry guys, gotta go help get my daughter ready for bed. I may be on a bit later
<rogpeppe> jam: we can probably use exactly the same logic that the mongo connection uses currently - no need to change the API at all
<rogpeppe> dimitern: yes
<dimitern> rogpeppe, s/return 2/return true/
<dimitern> rogpeppe, well it doesn't for some reason
<jam> dimitern: are you sure about int types
<jam> int 2 != int64 2
<rogpeppe> dimitern: they're not identical then :-)
<jam> interface{} is really bad about this
<jam> and the output in the log looks like
<jam> {a: b} != {a: b} which is very WTF
<dimitern> rogpeppe, I checked them key by key http://paste.ubuntu.com/6369724/
<rogpeppe> dimitern: ah, there's one other thing: it won't return true if some values are not comparable ISTR
<dimitern> rogpeppe, perhaps like ca-cert?
<rogpeppe> dimitern: gospew is useful for diagnosing stuff like this
<jam> dimitern: I would bet api-port is an 'int' on one side and something like 'int32' or 'int64' somewhere else
<jam> or if this is data you got out of JSON, even float74
<rogpeppe> dimitern: i bet it's a JSON issue
<jam> float64
<jam> which writes out as int if it doesn't have a decimal
<rogpeppe> dimitern: remember that any numbers in json arrive as float64, as jam says
<dimitern> both ports look like ints
<jam> I've hit that in the past
<jam> printf(float64(1)) == 1
<jam> not 1.0
<dimitern> damn!
<jam> which is sort of a shame
<jam> I've *definitely* been bit by that in the past
<dimitern> so passing anything through the api which returns interface{} having possibly ints is doomed
<jam> well, "doomed" to get cast into a float
<jam> :)
<jam> unless you put it into a struct
<jam> we had that for "juju get" as well
<rogpeppe> jam: well printf("%v %v %v", int8(1), int16(1), int(1)) prints 1 1 1
<jam> rogpeppe: http://play.golang.org/p/Spp9lwRovO
<jam> right, the issue is
<rogpeppe> dimitern: i've considered the possibility of doing UseNumber for all json stuff we send on the wire
<jam> Printf("%v", float64(1.0))
<jam> also returns just
<jam> 1
<jam> so you can't tell it is a float
<jam> vs returning 1.0
<dimitern> rogpeppe, what's UseNumber
<rogpeppe> jam: yeah - i'm just pointing out there are *lots* of possible types there too. just fixing it for floats wouldn't fix it for those too
<rogpeppe> dimitern: http://golang.org/pkg/encoding/json/#Decoder.UseNumber
<rogpeppe> dimitern: BTW gospew reference: github.com/davecgh/go-spew/spew
<rogpeppe> dimitern: spew.Dump(someVal) is useful for seeing everything (recursively and with types) inside a value
<jam> dimitern: see rev 1722 of juju-core where I mention that cmd.Get also suffers from auto-cast to float64
<dimitern> ok, thanks rogpeppe
<jam> dimitern: note that the discussion from juju get is that clients just shouldn't count on it being an Int object
<jam> so you could also go that way
<jam> otherwise you need to run the type decoding on the client side
<jam> after getting the map
<jam> even UseNumber
<jam> just gives you stuff that you can then chose what you cast it to
<rogpeppe> jam: i *think* i'm marginally in favour of using UseNumber throughout
<rogpeppe> jam: it means that we can transmit int64 losslessly too
<jam> rogpeppe: UseNumber means we just have strings so you still don't have an actual int or float
<rogpeppe> jam: indeed, but at least it's explicitly something else
<jam> rogpeppe: as I said before, you then *still* need to run the "interpret everything as an explicit type" code on the client
<rogpeppe> jam: and we can make the schema package work with json.Number
<jam> so the decision 2 months ago was, don't worry about it.
<jam> it doesn't change the cli
<jam> as we are printing it out into JSON anyway
<jam> or possibly YAML
<jam> so the only thing that might care is someone calling the API directly, and they're already screwed
<rogpeppe> jam: how so?
<rogpeppe> jam: or do you mean calling the api package directly?
<jam> rogpeppe: they just have a string on the wire that is a float, So all the code we have to try and cast thing into appropriate types, but on the wire its just a string
<rogpeppe> jam: it doesn't look like a string on the wire
<jam> rogpeppe: anyway, quite a bit of effort for almost 0 gain
<rogpeppe> jam: it looks like a normal json number
<jam> rogpeppe: it doesn't look like an int or a float on the wire. it looks like a sequence of bytes
<jam> aka "string"
<rogpeppe> jam: it fits exactly the usual json syntax for a number
<jam> rogpeppe: sure, but it *isn't* a float or an int
<rogpeppe> jam: no? i'm not sure i see the difference.
<rogpeppe> jam: json only has one number type
<jam> the fact that an object is an int or a float needs to be transmitted separately
<jam> which means we have to re-implement the code to interpret what the value of this field should be
<jam> and it was determined in the last discussion
<jam> that it wasn't actually worth doing that
<jam> I don't quite see how that's changed
<jam> UseNumber doesn't actually help until we have a way to cast it
<rogpeppe> jam: ah, i see what you mean
<jam> so yes, *if* we implement client-side casting, then we can UseNumber at that point
<rogpeppe> jam: yeah, i think i agree that we can transmit all numbers as exactly the same type
<rogpeppe> jam: and we can define that to be float64
<jam> rogpeppe: so in the config structure, it does define what the actual type of that number is
<jam> and we have code to do the work, and it runs behind the API, but then all that info gets discarded on the wire, so we have to do it again on the client
<rogpeppe> jam: standup?
<jam> yep, sorry
<dimitern> fwereade, added tests https://codereview.appspot.com/22210044/
<fwereade> dimitern, cheers
 * TheMue => lunch
<rogpeppe> natefinch: ping
<natefinch> rogpeppe: hey
<rogpeppe> natefinch: hangout?
<natefinch> sure
<rogpeppe> natefinch: https://plus.google.com/hangouts/_/calendar/am9obi5tZWluZWxAY2Fub25pY2FsLmNvbQ.mf0d8r5pfb44m16v9b2n5i29ig?authuser=1
<dimitern> fwereade, thanks for pointing out agent-version - it was totally possible to change it with EnvironmentSet - now it's not and I added a specific test about it
<dimitern> fwereade, updated https://codereview.appspot.com/22210044/
<fwereade> dimitern, sweet, tyvm
<rogpeppe> jam: do you fancy a quick chat about the charm streaming stuff? i was just about to write yet another reply, but thought perhaps a higher bandwidth connection might be useful
<mattyw> fwereade, thanks for looking at my mps - hope it's not wasting too much of your time, I'll take another look at them tomorrow
<fwereade> mattyw, dude, it's my job :)
<fwereade> mattyw, not a waste at all
<mattyw> fwereade, sweet! did you see my reply, what do you mean by dirty? the commit history??
<fwereade> mattyw, it just looked like the proposed branch hadn't had history merged in
<fwereade> mattyw, so I can't (easily) tell which are your changes and which just happened in the interim
<fwereade> mattyw, just merge trunk through the pipeline and propose again
<mattyw> fwereade, oh ok, I hadn't noticed that, I'll take another look
<mattyw> who's a good person to talk to about the charm store?
<rogpeppe> mattyw: what do you want to talk about?
<sodre> smoser: is example-sync still working ?
<TheMue> strange, shut eth0 on a ec2 machine, but status still reports it as running
<mgz> TheMue: that's from the instance existing, not the state reporting though, no?
<TheMue> mgz: no, status reporting
<TheMue> mgz: from the perspective of ec2 it is still running, which is ok
<TheMue> mgz: juju ssh fails as expected
<TheMue> mgz: pinging the machine fails too, so I would expect that also machine 0 would fail to reach the machine :/
<mgz> TheMue: 'running' is an ec2 instance state, not a juju machine status
<mgz> one thing `juju status` does is call DescribeInstances and report the instance state of all instances juju is managing
<TheMue> mgz: yep, ok, wrong wording, agent-state is still started, not down
<TheMue> mgz: the instance state is correct with running
<mgz> TheMue: try for instance, euca-stop-instances on that, then see what it reports
<mgz> "for instance"? too many instances.
<TheMue> mgz: :)
<TheMue> mgz: I tried to simulate a netsplit. stoping or terminating a machine is fine for the status reporting.
<jcsackett> :q!
<jcsackett> exit
<jcsackett> ...i hate when i get windows mixed up.
<mgz> :D
<fwereade> bbiab
<TheMue> yeah, bootstrap node has no connection to the agents on that machine anymore. and status reports still that everything is fine.
<benji> :w plan-to-use-jcsackett's-window-management-skills-against-him.txt
<benji> oops
<mgz> ehehe
<jcsackett> truthfully it's less window management and more "what has focus" issues. :-P
<benji> sloppy focus is the only way
<natefinch> Man, I really want to be able to use juju to deploy juju's mongodb in HA :/
<mgz> natefinch: you are not the first to have this thought
<natefinch> mgz: chickens and their stupid eggs
<natefinch> ok, so what we do, is use the manual provider to bootstrap the bootstrap for a real provider...
 * natefinch checks out the mongodb charm to see if there's anything he can crib
<sinzui> jamespage, I just released https://launchpad.net/juju-core/+milestone/1.16.3 to address the cgroup-lite bug that affects lxc
 * sinzui doesn't want to do any more 1.16 releases
<mgz> sinzui: jamespage is at the openstack summit, so I think he's probably not online right now
<sinzui> :)
<bac> hi sinzui
<sinzui> Hi bac
<bac> sinzui: can you join us in #juju-gui?
 * rogpeppe is done for the day
<rogpeppe> g'night all
<natefinch-afk> morning thumper
<thumper> morning
<natefinch-afk> what color do *you* want the bike shed to be? :)
<thumper> which shed are we talking about?
<thumper> if it is the ensure-ha chat
<thumper> I'm likely to dive in :)
<thumper> but firstly
<natefinch> yeah ,ha
<thumper> *STOP CROSS POSTING EVERYONE!!!!*
<natefinch> wow, I missed that roger had posted to juju, not just juju-dev
<thumper> since I don't use gmail, I get everything showing twice
<natefinch> well, you have no one but yourself to blame for that one ;)
<bac> hi marcoceppi
<marcoceppi> o/ bac
<bac> hey marcoceppi, we need a change to charmtools proof to make the endpoint an option to the proof call.  i've got a branch that seems to work that i'd like to propose
<marcoceppi> bac: couldn't you guys just call proof with --offline and then call your endpoint seperately?
<bac> marcoceppi: long term that's probably a good solution
<bac> marcoceppi: please have a look at https://code.launchpad.net/~bac/charm-tools/proof-endpoint/+merge/194227 and see what you think.
<marcoceppi> :\ I don't like it, but it's nothing to do with the code, it's just exactly the reason I put the offline flag within proof in the first place
<marcoceppi> Once this is in, it's pretty much there until a 2.0
<bac> marcoceppi: we're not offline.  we just need to configure the address of the server.
<marcoceppi> well
<marcoceppi> bac: the idea behind offline was for charmworld. Since charmworld knows it's own api it won't need charm-tools to do it since it can invoke it itself
<bac> marcoceppi: i don't know the history but i don't understand how offline has anything to do with charmworld.  i thought it was to allow people to use your tool when offline.  the two seem orthogonal.
<marcoceppi> bac: offline was just the way the feature was named, as it turns off remote checking
<rick_h_> marcoceppi: the thing with offline is we still need to run proof and then run our own checks
<rick_h_> marcoceppi: so we need to double the calls, build a combined list of issues, etc
<rick_h_> marcoceppi: the hope was that using proof in 'online always' mode would make sure we're all seeing the same messages/list of issues
<rick_h_> marcoceppi: but we can break it apart.
<rick_h_> marcoceppi: we'll work on that path.
<marcoceppi> OTP, rick_h_ if the URL is different then it should be run outside of that
<rick_h_> marcoceppi: rgr
<marcoceppi> rick_h_ bac: I don't mean to be disagreeable, however, I don't have time to cut this as a 1.1.3 before I start traveling given my current workload
<rick_h_> marcoceppi: understand
<bac> marcoceppi: i've retracted my MP.  i understand your concerns.
<marcoceppi> bac: thanks, sorry again. I really want to accomodate you guys as much as possible - let me know if there's anything else I can help with o/
 * thumper -> gym
<davecheney> all: which pocket is Juju going to ship in 14.04 ?
<davecheney> mramm:  which pocket is Juju going to ship in 14.04 ?
<wallyworld_> thumper: since you are ocr,  https://codereview.appspot.com/22580043 plus i wouldn't mind a quick hangout if you are free
#juju-dev 2013-11-07
<thumper> wallyworld_: ack, lemmie get something to eat
<wallyworld_> ok, no rush
<davecheney> thumper: which pocket is Juju going to ship in 14.04 ?
<davecheney> thumper: was there any resoltuion on that discussion in SF that juju core developers should be using P
<thumper> davecheney: well, there was the plan that the devs came up with, but that was overruled
<thumper> davecheney: I hear that we will be in main with a dependency on juju-db not mongodb-server
<davecheney> thumper: so, devs will not be fixed to a certain series ?
<davecheney> thumper: wrt juju-core in main
<davecheney> if we need to use gccgo to compile for arm (for example) that would also need to be in main ?
 * thumper shrugs
<thumper> probably
<thumper> wallyworld_: https://plus.google.com/hangouts/_/72cpi4lte1uucmppj5b94beve4?hl=en
<davecheney> thumper: right, thanks for confirming
<axw> hey thumper, was the 14.04 planning/schedule doc finalised and sent out? I can't find it on drive
<thumper> probably not :-)
<thumper> axw: hangout?
<axw> okey dokey
<axw> thumper: sure
<thumper> axw: https://plus.google.com/hangouts/_/72cpi4lte1uucmppj5b94beve4?hl=en
<thumper> wallyworld_: for this machine call to the api to give supported containers, we should also report ip addresses
<thumper> just a FYI
<wallyworld_> ok
<bigjools> thumper: I need to talk to you (or someone in core) about expectations around vlans in maas
<thumper> hmm
<thumper> how soon?
<thumper> I'm going to have to run children to sports very shortly
<bigjools> thumper: can do it tomorrow
<bigjools> just wanted to register this in your head
<thumper> ack
<thumper> kids rescued by wife
<thumper> but I've had a day of calls already
<thumper> and would like to do some work
<davecheney> bloody hell
<davecheney> http://paste.ubuntu.com/6374105/
<davecheney> ^ what happened here
<davecheney> the provisioner isn't starting machine 1
<bigjools> thumper: calls != work.  ACK :)
<thumper> bigjools: if I wanted work calls I'd go back to engineering manager
<davecheney> axw: http://paste.ubuntu.com/6374105/
<davecheney> any idea what happened ehre ?
<axw> looking
<davecheney> machine 1 is not goundf
<davecheney> because I just deployed the first service
<axw> sorry, no idea davecheney
<axw> davecheney: what's going wrong exactly?
<davecheney> juju deploy
<davecheney> machine never comes up
<davecheney> also, 2013-11-07 02:45:15 INFO juju password.go:94 setting password for "unit-gccgo1-0"
<davecheney> 2013-11-07 02:45:16 INFO juju password.go:94 setting password for "unit-gccgo1-0"
<davecheney> ^ why does it set the password twice ?
<axw> I haven't looked at most of the provisioner code I'm afraid
<davecheney> fair enough
<davecheney> (not) awesome
<davecheney> restarting the provisioner picked up the missing machine
<davecheney> and provisioned it
<davecheney> yay timing issues !
<axw> I'm guessing the machine status isn't added in the same transaction
<davecheney> my god the agents query tools a lot
<davecheney> https://bugs.launchpad.net/juju-core/+bug/1248800
<_mup_> Bug #1248800: worker/provisioner missed signal to start new machine <juju-core:New> <https://launchpad.net/bugs/1248800>
<sinzui> davecheney, surely you can take a guess at the importance. I think we want to commit to fix that bug in the next 6 months....High
<sinzui> davecheney, I think we have a bug already about the redundant queries
<davecheney> sinzui: i was told not to triage bugs anymore
<davecheney> well, not to screw with their priority
<sinzui> oh lovely. I get to guess at all the importances
<wallyworld_> axw: with the api design and errors, here's another example that uses the pattern - apiserver/provisioner/provisioner.go func (p *ProvisionerAPI) Status() . In this case, the Status() method can return an error preparing to execute the bulk operations, but the bulk calls themselves do not return an error, but instead record it in the result object
<axw> wallyworld_: hmm yeah fair enough. it allows you to distinguish an error relating to the individual calls from initial setup
<wallyworld_> yeah
<axw> just throws me a little, because if I see no error returned, I expect that everything is fine
<wallyworld_> i can understand that
<wallyworld_> i depends how the api defines "fine"
<axw> true :)
<axw> wallyworld_: is it intentional that you can't delete environ-config attrs from state? (I guess not, but before I go changing it...)
<axw> SetEnvironConfig updates keys that are there, but never deletes things you remove from the config
<wallyworld_> axw: i'm not sure tbh
<axw> ok. I'll create a bug and let someone shoot it down if needed
<wallyworld_> axw: be warned, the config stuff has been a source of way too much bikshedding
<axw> ok :)
<wallyworld_> the scars run deep from what i've been told
<axw> wallyworld_: I wouldn't care, but it actually is preventing me from testing something
<wallyworld_> william is probably the best person to ask
<axw> thanks, I'll run it by him later
<axw> fwereade: when you're awake, please take a look at https://bugs.launchpad.net/juju-core/+bug/1248809
<_mup_> Bug #1248809: state.State.SetEnvironConfig never forgets <juju-core:Triaged> <https://launchpad.net/bugs/1248809>
<davecheney> wallyworld_: oh yes
<davecheney> lets not start a second land war in asia
 * thumper going to make dinner, back later tonight for the meeting
<fwereade> axw, got to go out to the bank -- but, yes, SetEnvironConfig hardly works at all
<fwereade> axw, saying it was "designed" is very charitable
<axw> fwereade: hah :)
<axw> ok
<axw> I saw in a comment to dimitern a bug regarding passing old/new to SetEnvironConfig
<axw> probably they could be tackled at the same time
<axw> fwereade: however... the new EnvironmentSet API call assumes a config subset
<axw> so, either that would need to change, or a new API would be needed for deleting, or the current behaviour remains
<axw> anyway, ttyl
<axw> jam: I implemented an alternative to PushEnvironmentSecrets: https://codereview.appspot.com/22720043/
<axw> does the same as what we do now, under the assumption the code is going to be deleted
<jam> axw: where are you calling updateSecrets? In NewAPIConn ?
<axw> yup
<jam> axw: lgtm
<axw> cool. the other way would make sense if it were to stick around, but I don't think we'll need it at all
<axw> we should be able to start the agent up with full environment config initially with synchronous bootstrap
<jamespage_ods> sinzui: when you start I've pushed juju-core 1.16.3 to trusty and all of the backport packages have built in the packaging PPA's
<rogpeppe> mornin' all
<TheMue> rogpeppe: morning
<rogpeppe> TheMue: hiya
<axw> fwereade: when you're back- since you started reviewing the other one, could you take a look here before I land: https://codereview.appspot.com/22720043/
 * fwereade is backand looking at axw's branch
<axw> ta
<axw> sorry rogpeppe, I meant to ask about that comment - already merged
<axw> will delete it when I touch the file next
<rogpeppe> axw: np
<axw> jam: I don't know the upstart config off hand, but env vars were being pushed thru there before for provider type, and I think LXC bridge type
<axw> we moved *away* from setting env vars to simplify upgrading
<thumper> jam, mgz: meeting time
<thumper> fwereade: meeting
<rogpeppe> fwereade: meeting?
<rogpeppe> mgz: meeting?
<thumper> night all
<jpds> Guys, is it 'juju sync-tools --source=. --debug' to sync locally from tools/releases ?
<jpds> Because neither --source=. or --source=tools/releases/ is working here.
<rogpeppe> fwereade: i've just updated https://bugs.launchpad.net/juju-core/+bug/1246343
<_mup_> Bug #1246343: destroy-environment no longer removes .jenv <charmers> <destroy-environment> <landscape> <juju-core:Triaged by axwalk> <https://launchpad.net/bugs/1246343>
<rogpeppe> jam: wow, 34810 running goroutines; that's quite something.
<jam> rogpeppe: well the go claims that there you can cheaply spawn 100,000s of them, right? :)
<rogpeppe> jam: indeed - it's just more than i expected
<jam> rogpeppe: yeah, with 7k agents that means almost 5 per agent
<rogpeppe> jam: you might be interested in this - it's a characterisation of all the stack traces by set of called functions; the count is the number of goroutines with that stack trace: http://paste.ubuntu.com/6376480/
<rogpeppe> jam: looks like everything's blocked on mongo
<jam> rogpeppe: could be, though mongo itself was at 0% cpu during this time
<rogpeppe> jam: goroutine 216906 seems to be the one with the lock (the write lock at any rate)
<jcsackett> sinzui: after standup, can you look at https://code.launchpad.net/~jcsackett/charmworld/multiple-appflowers/+merge/194241 for me?
<rogpeppe> jam: wonder if it would be useful to instrument mgo with some stats (github.com/GaryBoone/GoStats might provide an easy way to get some more useful stats without making enormous log files)
<rogpeppe> jam: actually i may have been thinking of github.com/rcrowley/go-metrics
<rogpeppe> natefinch: ping
<natefinch> rogpeppe: yo
<rogpeppe> natefinch: i've been trying to think through the failover stuff, and hit a tricky issue
<rogpeppe> natefinch: i wondered if you wouldn't mind a chat about it to try to get my thoughts straight
<rogpeppe> natefinch: np if inconvenient
<natefinch> rogpeppe: sure thing
<rogpeppe> natefinch: usual hangout?
<natefinch> sure
<rogpeppe> https://plus.google.com/hangouts/_/calendar/am9obi5tZWluZWxAY2Fub25pY2FsLmNvbQ.mf0d8r5pfb44m16v9b2n5i29ig?authuser=1
<rogpeppe> fwereade: any chance you could join us?
<jcastro> hey sinzui, is bug #1238934 something we can backport to saucy/precise?
<_mup_> Bug #1238934: manual provider doesn't install mongo from the cloud archive <cloud-archive> <ssh-provider> <juju-core:Fix Committed by axwalk> <https://launchpad.net/bugs/1238934>
<jcastro> or should we just have it in 1.18 as a whole and tell people to use the PPA for manual provisioning?
<sinzui> sigh
<sinzui> jcastro, we can, but we can do one release a week. so if it do, we delay 17 and 18
<jcastro> sorry I didn't mean to depress you!
<sinzui> I would like 17 next week and 18 the following week
<jcastro> are there plans to bring 18 to precise/saucy?
<sinzui> jcastro, all stable releases go to all supported series
<jcastro> oh ok
<sinzui> We always do that
<jcastro> so waiting 2 weeks is the smart thing to do
<sinzui> 1.16.3 will be in the archives in a few hours BTW
<jcastro> ok I wasn't aware of the backport treadmill -- that works out for me!
<sinzui> jcastro, I hope that with more automation, we can entertain a stable and devel release in the same week
<jcastro> yeah I'm just trying to sync the manual provisioning docs with 1.18, but I have two weeks to figure that out, heh
<rogpeppe> interesting: http://www.packer.io/intro
<natefinch> rogpeppe: I saw that packer thing. Kinda neat, but not sure the real-world utility.  Sure you can take a machine and make an image for EC2 or virtualbox or whatever. You still have to make the original correctly, though, and that seems like the more interesting challenge (and the one we're tackling).
<rogpeppe> natefinch: yeah, i haven't read it properly - just thought it looked interesting
<natefinch> rogpeppe: yep
<rogpeppe> natefinch: trying to work out what's going on with jam's enormous stack trace, i quickly hacked up this: http://paste.ubuntu.com/6377995/
<rogpeppe> natefinch: it analyses a stack trace and produces an SVG call graph summary
<rogpeppe> natefinch: if you get his stack trace with: curl http://ubuntuone.com/6vKrM07H7BTHUa9Xqvy16V | ungz > /tmp/stacktrace
<natefinch> rogpeppe: damn, roger.  Quickly hacked up.... I hope we're paying you enough :)
<rogpeppe> natefinch: and then run the above program on it: go run stacktrace.go < /tmp/stacktrace > /tmp/x.svg
<rogpeppe> natefinch: and open your browser on file:///tmp/x.svg
<rogpeppe> natefinch: i stole all the interesting bits from the pprof perl script
<rogpeppe> natefinch: (first time i've ever translated perl to Go!)
<rogpeppe> natefinch: (first time i've ever read any perl actually :-])
 * natefinch shudders
<rogpeppe> natefinch: it's not too bad in that particular case
<rogpeppe> ha!
<rogpeppe> natefinch: i've got the arrows all backwards!
<natefinch> heh
<natefinch> rogpeppe: tar -xz is saying it's not in gzip format
<rogpeppe> natefinch: sorry, i said ungz; i meant unxz
<rogpeppe> natefinch: it's not a tar file
<natefinch> rogpeppe: ahh right, because it's just one file. Stupid linux and it's stupid 10 different ways to pack files :/
<rogpeppe> natefinch: this version puts the arrows in the right direction: http://paste.ubuntu.com/6378028/
<natefinch> back in my day we only had .zip and we liked it :/
<rogpeppe> natefinch: back in my day we only have .Z and we liked it :-)
<rogpeppe> s/have/had/
 * thumper is going to be taking daughter to the dentist, so not really around until later
<natefinch> rogpeppe: took me a while, but I got there.  Pretty cool
<rogpeppe> natefinch: cool
<rogpeppe> right, that's me done and dusted
<rogpeppe> natefinch: g'night
<natefinch> rogpeppe: g'night
<sinzui> natefinch, do you have time to build a win installer for 1.16.3 and request a signing?
<natefinch> sinzui: sure
<sinzui> thank natefinch
<sinzui> ^ yoy
<sinzui> ^ you
<sinzui> I give up. My head hurts, I two ways of packing perfect packages, yet neither method is perfect in itself
 * sinzui ponders the consequences to drinking and retrieving children from school
<natefinch> sinzui: I think it's funny we're releasing a new windows client that includes a fix for the local provider.... that can't run on windows anyway :)
<sinzui> ha ha
<sinzui> I know
<sinzui> natefinch, I am happy for you to say no, it is just busy work
<natefinch> sinzui: it's super quick, no problem.  Just amusing is all.
<sinzui> we did an ubuntu release for 1.14.1 that had no changes for ubuntu. It was just to acknowledge that windows got a different version
<sinzui> sorry juju-gui, you got spam from me
<sinzui> you don't want to use my devel packages
 * thumper goes to hack on kvm stuff
<thumper> and will effectively disconnect
<rick_h_> thumper-hacking: yay for my lxc environment being back to being useful. Tested the updated gui with bundle super powers in it and so much nicer/faster than ec2
#juju-dev 2013-11-08
<ehw> hey, stokes, you awake?
<ehw> doh
<mramm> anybody about?
<wallyworld_> mramm: hi
<mramm> I wanted to bounce some HA ideas off of folks
<axw> I'm here.. haven't been looking at HA tho
<mramm> that mailing list thread seems to like a lot of heat
<mramm> I'm just trying to think about how we spell it for users
<mramm> not about how we implement it ;)
<wallyworld_> i think there's 2 common ideas - the ensure-has thing and the concept of juju services - db, api etc
<wallyworld_> seems the juju add-unit juju:db thing is popular
<wallyworld_> and fits with how people like to think about it
<TheMue> imho an important part of the story is to tell the user, that we talk about juju ha, not of ha for their services
<TheMue> those are two different stories
<mramm> wallyworld_: I think that is sort of complicate to call these things units
<TheMue> morning btw
<mramm> they will be special units
<mramm> there aren't charms for them
<mramm> they can't have subordinates
<mramm> they don't have hooks
<mramm> removing them kills everything
<TheMue> mramm: exact. they may share the same base technology, but the semantics is a different one
<wallyworld_> true. i think folks liked to think of the juju:services in terms of units that could be added to
 * TheMue prefers a number of ha-... commands
<axw> sorry mramm missed your hangout thing - want to take it there, or keep chatting here?
<wallyworld_> so the add-unit paradigm could be used
<mramm> I'm all for spelling it add-unit juju:db someday -- but starting out that way is crazy
<mramm> wallyworld_: I like that idea too
<mramm> though I think we have a good way to go before we get there
<wallyworld_> yeah
<wallyworld_> i also like the ensure-ha idea to set up a ha scenario
<mramm> so what do we do in the short term that still makes sense in the long term?
<TheMue> wallyworld_: +1
<wallyworld_> and then use add-unit <service> to maintain it
<TheMue> mramm: the underlying logic and the command interface to the user are different things
<wallyworld_> my opinion is do ensure-ha N where N >=3 to set up a workale ha scenario
<mramm> TheMue: right
<TheMue> mramm: imho the enable-ha still can use the idea of core units
<wallyworld_> then add stuff to allow users to add to the initial set up
<TheMue> eh, services
<mramm> we don't have "units"
<mramm> and making state server stuff into units is complicated
<mramm> and by that I mean enabling them to act like units to users
<mramm> anyway, if anybody wants to chat about this via voice: https://plus.google.com/hangouts/_/76cpimd6r4dqrb52sh0b8h3jg0?hl=en
<rogpeppe> mornin' all
<noodles775> Anyone around able to look at a charm-helpers MP (some ansible support): https://code.launchpad.net/~michael.nelson/charm-helpers/ansible-tags/+merge/194324
<mramm> so the result of the google hangout was that I sent an e-mail, and while I'm not 100% sure we've got the exact spelling of everything worked out we agreed on a proposed command line syntax for HA
<mramm> (those in the meeting already know, and those not in the meeting can see the results in the juju-dev mailing list)
<wallyworld_> mgz: wallyword + friday evening  + alcohol = no standup
<wallyworld_> + 2 women also
<dimitern> :) \o/
<dimitern> mgz, rogpeppe, TheMue: standup?
<dimitern> mgz, ping
<TheMue> tschakka, first try already looks better
 * TheMue => lunch
<rogpeppe> lunch
<rogpeppe> i'm done. happy weekends all.
<ahasenack> hi, does someone know of the top of his/her head how juju gets the private-address value?
<ahasenack> is it something like "hostname -f"?
<natefinch> ahasenack: it's different per provider, but mostly it comes from provider metadata
<ahasenack> natefinch: in the case of maas, do you know? I'm going over the code, but kind of getting lost
<ahasenack> I found this
<ahasenack> func (info *machineInfo) load() error {
<ahasenack>     return utils.ReadYaml(_MAASInstanceFilename, info)
<ahasenack> }
<ahasenack> and now I'm chasing down that that instance filename is
<natefinch> ahasenack: you're a few "go to definition" clicks ahead of me, looks like
<ahasenack> there is provider/maas/environprovider.go
<ahasenack> where I found func (maasEnvironProvider) hostname() (string, error) {
<ahasenack>     info := machineInfo{}
<ahasenack>     return info.Hostname, nil
<ahasenack> looks like I want that info.Hostname bit
<natefinch> ahasenack: yeah, I  got there.  I see this:
<natefinch> var _MAASInstanceFilename = environs.DataDir + "/MAASmachine.txt"
<natefinch> so, /var/lib/juju/MAASmachine.txt
<ahasenack> where, on the unit?
<ahasenack> presto!
<ahasenack> root@k8q9m:/var/lib/juju# cat MAASmachine.txt
<ahasenack> hostname: k8q9m.maaslocal
<ahasenack> natefinch: thanks :)
<ahasenack> now, what populates that, the provider?
<natefinch> ahasenack: trying to figure that out
<natefinch> ahasenack: yeah, it looks like it gets it during StartInstance
<natefinch> ahasenack:  mi.maasObject.GetField("hostname")
#juju-dev 2014-11-03
<wallyworld> menn0: only took 3 attempts, but fix has landed, will take a bit to wash through CI, but critical regression fix committed
<menn0> wallyworld: glad it's in
<wallyworld> must. not. comment.
<wallyworld> sadly we still have work to do to make out test suite reliable
<bodie_> rick_h_, simply that a change to the charm repo in master is causing juju core tests written against the bit that was removed, to fail
<bodie_> it's not really critical to what I'm trying to do right now, but I want to land some changes to charm, and if v4 master isn't working perhaps I shouldn't rebase my changes on master
<bodie_> I'll try to get ahold of rogpeppe / uros (who's that?)
<menn0> hmmm, although LP shows no critical regressions the buildbot is still blocking merges due to bug 1388493']
<mup> Bug #1388493: generate-tools --streams loses content of other streams <ci> <metadata> <regression> <juju-core:Fix Committed by wallyworld> <https://launchpad.net/bugs/1388493>
<menn0> and bug 1388073
<mup> Bug #1388073: set-env no longer accepts empty values <ci> <compatibility> <regression> <set-env> <juju-core:Fix Committed by tasdomas> <https://launchpad.net/bugs/1388073>
<rick_h_> bodie_: urulama sorry
<rick_h_> bodie_: roger's lead, the two have been working with charm for some charmstore stuff/etc and are up on the charm package info these days.
<bodie_> ah, okay.  thanks rick_h_ :)
<menn0> wallyworld_: do we officially support concurrent local provider environments on the one host machine?
<wallyworld_> um, no
<wallyworld_> not to my knowledge
<wallyworld_> i'm not sure it would even work
<davecheney> menn0: it works
<davecheney> but you'd be bonkers to try
<davecheney> we did it in japan
<davecheney> 27 local providers
<wallyworld_> \o/
<davecheney> * footnote: that was in versino 1.14
<davecheney> gawdknows what's changed since then
<menn0> wallyworld_, davecheney: the reason I ask is that i've just figured out why the rsyslog worker works for all but 1 environ
<stokachu> im going to try it
<menn0> wallyworld_, davecheney: it writes out configuration files using different certs but all listening on the same rsyslog port
<menn0> wallyworld_, davecheney: so only one environment has working logging
<davecheney> menn0: rump-row
<wallyworld_> menn0: ah, i'm currently wondering why juju debug-log is broken
<menn0> and even if you go back to one env
<wallyworld_> nodes are failing to send stuff to machine 0 due to certificate issues
<menn0> the old rsyslog config doesn't appear to get removed
<menn0> so logging is broken from then on
<menn0> you need to clean up /etc/rsyslog.d manually
<menn0> it's taken me quite some time to figure that out :)
<wallyworld_> menn0: i'm seeing this
<wallyworld_> 2014-11-03 02:56:34 ERROR juju.worker runner.go:219 exited "rsyslog": x509: certificate is valid for ip-10-46-174-79.ec2.internal, not juju-rsyslog
<menn0> wallyworld_: that's the one
<wallyworld_> menn0: this is a critical regression for alpha3
<wallyworld_> as debug log is just broken
<menn0> wallyworld_: it's only for the local provider though
<wallyworld_> menn0: nope, also aws
<wallyworld_> and probably evrything else too :-(
<menn0> wallyworld_: sorry
<wallyworld_> that line i just pasted was from an aws deploy
<menn0> wallyworld_: I just re-read that error.
<menn0> wallyworld_: I was seeing something different
<wallyworld_> ah, ok
<menn0> x509: certificate signed by unknown authority (possibly because of "crypto/rsa: verification error" while trying to verify candidate authority certificate "juju-generated CA for environment \"rsyslog\"")
<wallyworld_> it may well be the same root cause, not sure
<menn0> wallyworld_: don't think so
<wallyworld_> regardless rsyslog and hence debug log is stuffed
<menn0> wallyworld_: the thing i've been investigating is definitely local provider specific when you have multiple environments set up
<menn0> sure
<wallyworld_> :-(
<menn0> wallyworld_: the client side of the connection sets the expected server name to a hardcoded value of "juju-rsyslog"
<menn0> wallyworld_: see composeTLS() in worker/rsyslog/worker.go
<wallyworld_> menn0: yeah, i'm backing out that change to see if it works
<wallyworld_> was changed 10th october
<wallyworld_> so recently
 * wallyworld_ waits imatiently for aws to start up an instance or two
<davecheney> %  git push --set-upstream origin 100-fix-issue-69
<davecheney> fatal: https://gopkg.in/juju/charm.v4/info/refs not valid: is this a git repository?
<davecheney> I hate gopkg.in
<davecheney> https://github.com/juju/charm/pull/70
<davecheney> anyone ?
<davecheney> wallyworld_: thanks for the review
<davecheney> i'm going to wait for rog
<davecheney> this is his baby
<davecheney> and I have just slapped it, soundly
<wallyworld_> sure, looked ok to me.... but im not 100% familiar with it
<davecheney> wallyworld_: i'm changing the semantics of the method from what it promised, but didn't deliver
<davecheney> to what it does
<wallyworld_> right :-)
<davecheney> i tried to do it the other way, ie make the methods return a *copy* of the receiver
<davecheney> but of course all the tests expect the current behavioru
<davecheney> so all broke
<davecheney> so, this change renames the method to _say_ what they _do_
<davecheney> as well as making them thread safe
 * wallyworld_ nods
<wallyworld_> davecheney: do you know anything about unit tags gaining a suffix? eg unit-flannel-2[2016]
<wallyworld_> menn0: that one line change to remove "juju-rsyslog" worked
<wallyworld_> but i'm not sure of the implications of just removing it
<menn0> wallyworld_: good.
<wallyworld_> the commit message says
<wallyworld_> tls.Config clients should use a meaningful ServerName This also fixes an issue with the rsyslog tls.Config not using a ServerName at all.
<wallyworld_> well, trouble is, if the rsyslog tls.Config uses a service name, it breaks
<menn0> wallyworld_: the docstring for composeTLS (added in that rev) says that setting ServerName is required to support pre-1.20.9 certs
<menn0> wallyworld_: so I suspect taking that line out is going to bring back the problem of rsyslog cert issues when upgrading from 1.20 to 1.21
<menn0> wallyworld_: better check with wayne i guess
<wallyworld_> yeah
<menn0> i have to run some errands
<wallyworld_> i'm not an expert on this stuff
<menn0> neither am i
 * wallyworld_ raiss a criitical bug
<menn0> sigh
<menn0> back in a bit
<davecheney> wallyworld_: tag ? nope
<davecheney> 'fraid I wasn't watching
<davecheney> smells like an actions thing
<wallyworld_> davecheney: np. unit agent logs now have tags like "unit-mysql-0[15930]"
<wallyworld_> could be actions related i guess, not sure
<wallyworld_> davecheney: a quick look at the names package doesn't seem to reveal any related changes
<davecheney> yup
<davecheney> doesn't look like that is whyere they are coming from
<davecheney> it is rsyslog ?
<davecheney> putting the PID on the end ?
<wallyworld_> yeah, i just came to the same conclusion ook at the code, so it must be a logging artifact
<davecheney> [$PID] is the smell
<wallyworld_> the whle rsyslog thing has been radically changed recently
<wallyworld_> davecheney: what's the official way to construct a name from a tag? eg if I have "unit-mysql-1", I want to get "mysql/1"
<wallyworld_> jam: connection dropped, sorry if this comes twice, how's your TLS knowledge? i'm not sure what to do with bug 1388688 - 1.21 is broken, but apparently the change was made so that 1.20.9 could be connected to
<mup> Bug #1388688: juju debug-log is broken <debug-log> <regression> <rsyslog> <juju-core:Triaged> <https://launchpad.net/bugs/1388688>
<jam> wallyworld_: it didn't, looking
<jam> wallyworld_: is this a fresh bootstrap, an upgrade, an ... ?
<wallyworld_> jam: fresh bootstrap
<wallyworld_> 1.21 tip
<davecheney> wallyworld_: names.NewUnitTag(string).String()
<davecheney> wallyworld_: it depends
<davecheney> if you have "unit-mysql-1"
<davecheney> where did you get it from ?
<jam> wallyworld_: I worked with wwitzel a bit on trying to figure out what the right fix was for this.
<wallyworld_> davecheney: it's the prefix of a log file entry
<jam> specifically we have a variety of issues around TLS and cert names
<jam> they want you to either put a hostname in the field
<jam> or put IP addresses in another field
<jam> but if we do IP addresses we have to create a new certificate anytime any IP addresses change
<wallyworld_> for juju < 1.20.9 only?
<jam> we *were* putting the phrase "anything" as the server hostname for API connections, but nothing for stuff like rsyslog
<jam> and then generating certs with "Hostname: *"
<jam> which matches "anything"
<jam> at one point, someone switched us to start using IP addresses
<jam> but then upgrade breaks
<wallyworld_> oh :-(
<jam> because it uses one cert that doesn't have IP addresses
<jam> and when we discussed it
<jam> it felt a lot better to use
<jam> Hostname: *
<jam> and meaningful "ServerName" fields
<jam> and then maybe we could eventually migrate to Hostname: juju-meaningfulname instead of *
<jam> now, it looks like the cert that existed actually put a DNSName into the Hostname field
<jam> instead of Hostname: *
<wallyworld_> and we generate the cert?
<jam> but (a) not all clouds give you DNS names, and (b) the DNS name is specific to a machine, and not to all of the API servers in HA mode
<jam> wallyworld_: yeah, we generate the cert and how we connect to it
<jam> but it looks like we're having trouble because we changed it, and now we need to support all the possible ways it could have been generated.
<jam> I thought the IP address stuff was only in the 1.21-alpha stuff
<jam> I'd have to dig deep to know what was done when and whereb
<jam> because we seem to have changed these things in *micro* releases, which isn't a very good practice
<jam> wallyworld_: is it possible to wait for wwitzel, or do you need it asap ?
<wallyworld_> jam: i've marked it as a critical regression and in my view, we cannot release alpha3 till it's fixed. we can talk to wayne when he comes online
<wallyworld_> cause debug log is broken
<jam> wallyworld_: to be clear, the issue you are seeing is that 1.21-alpha3 agents are unable to talk to a 1.21-alpha3 API server's rsyslog daemon, correct ?
<wallyworld_> jam: yes, a fresh bootstrap with upload tools
<davecheney> wallyworld_: you can use names.ParseTag(...)
<wallyworld_> on local provider and AWS
<wallyworld_> davecheney: thanks, will look into that
<dimitern> morning
<TheMue> morning
<voidspace> morning all
<mattyw> morning everyone
<fwereade> tasdomas, ping
 * fwereade waves at everybody
<voidspace> fwereade: hah, when I started reviewing wayne's branch there were no reviews for it
<voidspace> fwereade: when I publish my review some have appeared...
<fwereade> voidspace, extra reviews are not in any way a problem
<voidspace> heh :-)
<jam> hi fwereade
<fwereade> jam, heyhey
<voidspace> jam: I'm there
<mattyw> fwereade, just noticed you pinging tasdomas  - I think he's off today
<fwereade> mattyw, cheers
<mattyw> fwereade, do we have a way to enabling client logging to a file?
<fwereade> mattyw, I *think* we do but I don't recall offhand
<mattyw> fwereade, --log-file thing.log
<fwereade> mattyw, heh, thanks
<fwereade> bah, so, the bot's complaining about 1388073 and 1388493 -- both of which STM to be fix committed
<fwereade> anyone?
<jam> fwereade: bot only lets go once it is Fix Released for a while now
<jam> fwereade: which IIRC, is Curtis seeing the actual CI test runs pass
<fwereade> jam, ah, ok, makes sense
<wallyworld_> fwereade: one remaining critical bug open on 1.21 is bug 1388688
<mup> Bug #1388688: juju debug-log is broken <debug-log> <regression> <rsyslog> <juju-core:Triaged> <https://launchpad.net/bugs/1388688>
<wallyworld_> sorta need to ask wayne about it
 * fwereade sees `tls.Config` in the first few lines and grumbles expressively to himself
<wallyworld_> if not for that, we could release 1.21 alpha i think/hope according to the dashboard
<fwereade> wallyworld_, ok, does he have a mail waiting for when he wakes up?
<wallyworld_> no, i was waiting for him to show up
<wallyworld_> i talked to jam a little also
<fwereade> wallyworld_, that's very good of you, but isn't it late?
<wallyworld_> well, kinda
<wallyworld_> i also want to talk to curtis
<wallyworld_> to make sure everything else is ok for the release
 * fwereade points wwitzel3 and wallyworld_ in each other's direction
<wallyworld_> wwitzel3: bug 1388688 is a critical regression because debug log is broken, i'm not sure how to fix to make both 1.21 and 1.20 happy
<mup> Bug #1388688: juju debug-log is broken <debug-log> <regression> <rsyslog> <juju-core:Triaged> <https://launchpad.net/bugs/1388688>
<wwitzel3> wallyworld_: ok, taking a look
<wallyworld_> ty
<wallyworld_> wwitzel3: here's some discussion from earlier http://pastebin.ubuntu.com/8803081/
<wwitzel3> wallyworld_: thank you
<wallyworld_> np, thanks for looking
<wwitzel3> I should of never upgraded, ugh
<wwitzel3> my xmonand broke, my graphics is no longer using hardware rendering, my system python installation broke, I get weird kernel errors randomly, oh and the whole machine freezes up every 2-4 hours
* ChanServ changed the topic of #juju-dev to: https://juju.ubuntu.com | On-call reviewer: see calendar | Open critical bugs:  1388853
<sinzui> jam, alexisb can you arrange for someone to address bug 1388853. We still haven't had a single blessed revision for alpha3
<mup> Bug #1388853: ppc64el unittests consistently fails <ci> <ppc64el> <regression> <test-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1388853>
<wwitzel3> wallyworld_: ok, well I have a "fix" for it based on what jam was saying.
<wwitzel3> wallyworld_: keeps both the clients happy
<wwitzel3> natefinch, perrito666: ping
<natefinch> wwitzel3: coming
<natefinch> wwitzel3: perrito666 is at ods
<wwitzel3> thumper and me are on-call reviewers today, so will need someone to take a look at http://reviews.vapour.ws/r/324/, it fixes bug #1388688
<mup> Bug #1388688: juju debug-log is broken <debug-log> <regression> <rsyslog> <juju-core:Triaged by wwitzel3> <https://launchpad.net/bugs/1388688>
<wwitzel3> ping fwereade, wallyworld_, voidspace ^
<fwereade> wwitzel3, tests?
<fwereade> wwitzel3, (and are you sure it'll work across all the versions in play?)
<wwitzel3> fwereade: yes, I confirmed it works for both versions
<fwereade> wwitzel3, awesome
<fwereade> wwitzel3, needs a unit test too, would lgtm with that
<wwitzel3> fwereade: as for tests, no idea how we would test it
<voidspace> wwitzel3: are you appending * inside the body of the loop?
<fwereade> wwitzel3, and that's a good point too
<wwitzel3> voidspace: oops, I was, need to push the updated diff, I noticed it after I initially pushed :)
<voidspace> cool :-)
<fwereade> wwitzel3, it looks like we're writing that stuff out somewhere
<fwereade> wwitzel3, can the tests not read the certs back in and check their properties?
<wwitzel3> fwereade: yep, we can do that
<wwitzel3> fwereade: you're right, that is better than nothing
<fwereade> wwitzel3, cool, thanks
<alexisb> sinzui, looking
<alexisb> sinzui, I am not seeing the attachment on that bug
<sinzui> alexisb, :( I will try again
<sinzui> alexisb, I added the log this time
<alexisb> awesome, thanks sinzui
<wwitzel3> fwereade, voidspace: added tests that check the issuer, subject, and dnsnames for the cert.
<voidspace> wwitzel3: did you push the tests?
<voidspace> wwitzel3: don't think they're showing on RB yet
<voidspace> checking github
<alexisb> all, please consider  bug 1388853 top priority
<mup> Bug #1388853: ppc64el unittests consistently fails <ci> <ppc64el> <regression> <test-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1388853>
<wwitzel3> voidspace: weird, yeah, they aren't showing in RB
<alexisb> as 1.21 is still blocked and release was targeted for last weds
<voidspace> wwitzel3: yeah, I'm looking at it on github
<voidspace> wwitzel3: github sometimes throttles (drops) API calls
<mgz> alexisb: I have a plan of sorts of that bug
<alexisb> mgz, please share
<mgz> I'm going to change the compiler version that runs the tests
<mgz> we fixed the juju parts of the bug on friday,
<mgz> it's just the current version of gccgo on trusty blows up with these tests - that's a change since brussels
<alexisb> mgz ack, how can the core team help at this stage?
<voidspace> wwitzel3: looks good to me
<voidspace> wwitzel3: the code adds a * after any HostPorts
<voidspace> wwitzel3: worth having a hostport in the test, so that code is exercised?
<mgz> alexisb: will yell if I need it
<alexisb> mgz, ack, thanks
<voidspace> dimitern: ping
<dimitern> voidspace, pong
<voidspace> dimitern: I have ec2-api-tools installed
<voidspace> dimitern: and the right AWC environment variables set
<dimitern> voidspace, yeah?
<voidspace> dimitern: and I can access the account using those credentials from code (goamz)
<voidspace> dimitern: the command line client always reports
<voidspace> Client.Unauthorized: Not Authorized
<voidspace> dimitern: do you have any idea why that might be?
<voidspace> the intarwebz are not helping on this
<voidspace> the only references I can find are to Java exceptions
<bodie_> who should I discuss changes to charm with? rogpeppe?
<rogpeppe> bodie_: if you like :)
<dimitern> voidspace, not sure if this can be the cause, but I had to set a couple of additional env vars for aws:
<voidspace> dimitern: ah
<voidspace> maybe
<voidspace> dimitern: you remember which ones?
<bodie_> rogpeppe, there is a change in charm v4 that breaks juju core state/charm_test TestTestingCharm, which tests against the "metered-custom" dummy charm that was removed from charm in 190b3a5d
<bodie_> rogpeppe, I want to make some additions to charm but I wasn't sure what to base them on since it seems like v4 is now not compatible (the commit in godeps is fine)
<dimitern> voidspace, try these - http://paste.ubuntu.com/8804761/
<bodie_> rogpeppe, should I just open a PR to replace the missing piece?  I think we might want to move to v5 anyway since I have some Actions related changes I want to make charm more correct.  I don't want deprecated bad bits to build up, but they are not serious... just irritating
<rogpeppe> bodie_: are you saying that there have been some backwardly incompatible changes made to v4, or that you want to make some backwardly incompatible changes in the charm package?
<voidspace> dimitern: that worked!
<voidspace> dimitern: it might be worth updating the container addressability doc, which only mentions the key pair
<voidspace> dimitern: I can do that
<voidspace> dimitern: I think it was the EC2_KEYPAIR one which did it
<voidspace> but I'll verify
<bodie_> rogpeppe, both.  but the backwards incompatibility that was added to v4, can easily be reversed.  and my changes don't have to be backwardly incompatible, but I would ideally like to remove the pieces they deprecate.
<voidspace> dimitern: nope, that on its own wasn't enough
<bodie_> rogpeppe, does that clarify?
<voidspace> dimitern: it was EC2_URL
<rogpeppe> bodie_: in a call currently, will get back to you in 15 mins or so
<bodie_> sure thing :)
<dimitern> voidspace, I think it was one of the key vars
<dimitern> voidspace, one name is deprecated, but accepted the other is the "new" one you're supposed to use
<dimitern> voidspace, I have some connection issues - did you see what I sent last?
<dimitern> voidspace, ah, ok
<dimitern> voidspace, please update the doc then :)
<voidspace> dimitern: no, I have the key vars in my env already - just adding EC2_URL is sufficient to make it work
<voidspace> dimitern: done
<dimitern> voidspace, cheers!
<wwitzel3> voidspace: yeah, probably, it is funny .. we have NewRsyslogConfigHandler = newRsyslogConfigHandler in export_test.go, but then we never actually override or test it :P
<voidspace> wwitzel3: hah
<wwitzel3> voidspace: I was hoping that wasn't the case, guess I'll have to write a suite for it
<bodie_> rogpeppe, fwiw, I think it would be good to roll forward to v5 since there are some old half-baked Actions definitions in a dummy charm in v4, that I want to remove, not deprecate.  but as long as it is clear that they are old and smelly, it doesn't change the actual behavior of charm.  it's testing-related only.
<bodie_> same goes for the breaking commit in v4.
<rogpeppe> bodie_: i'm not sure we need to hold to quite such a stringent backwards compatibility policy for testing-related code
<bodie_> rogpeppe, I think TheMue had a good point: tests shouldn't be written against implementation details (dummy charms) of v4 anyway :)
<bodie_> but, maybe that's a little bit of a funky point (dummy charms) which I'm not sure how to approach
<bodie_> anyway, I will make my changes compatible, but there is some cruft building up and I'd like the charmers to have a proper example of what Actions should look like in a charm
<rogpeppe> bodie_: out of the call now
<rogpeppe> bodie_: i'm generally in agreement with TheMue's point, and i've been pondering a good direction for a while now.
<bodie_> yeah, it is a pretty subtle and maybe small pothole
<rogpeppe> bodie_: i recently made a backwardly incompatible change to one of the testing repo charms too
<rogpeppe> bodie_: i don't think we need to count the testing-related packages as part of the v4 contract.
<rogpeppe> bodie_: although it's good to keep backwardly compatible when we can, obviously
<bodie_> my only concern is that if I want to make changes, I can't work on top of charm master if it's breaking juju master
<voidspace> dimitern: the task breakdown and estimates in the Juju Container Addressability document are based
<voidspace> dimitern: on AllocateAddress picking an address for us, and not on us managing addresses (and picking one from the right subnet)
<voidspace> dimitern: I'm not sure that changes a lot regarding estimates - except it means more work in the container provisioner
<voidspace> dimitern: unless I'm reading it wrong
<dimitern> voidspace, that's correct, we might need to inflate the estimate there
<voidspace> dimitern: right
<voidspace> dimitern: there is a "Track the IP addresses we have allocated for each subnet" which could cover it
<dimitern> voidspace, does the estimate there seem sane to you?
<voidspace> dimitern: 2-3wks probably has enough wiggle room to cover it :-)
<voidspace> dimitern: the other estimates seem ok to me
<voidspace> in a hand-wavy kind of way...
<dimitern> voidspace, :) cheers!
<rogpeppe> bodie_: sure you can - juju master is only broken when the juju-core deps are updated, no?
<rogpeppe> bodie_: the most important thing about compatibility is keeping go get working
<bodie_> gotya :)
<rogpeppe> bodie_: with the testing deps, the broken deps are usually only one level, between tests and testing package
<rogpeppe> bodie_: so, just to summarise, your backwardly incompatible changes only involved changes to the testing charms repo?
<bodie_> that's right, but they don't have to be backwardly incompatible.  I would just like them to be :)
<rogpeppe> bodie_: i think you should go for it
<rogpeppe> bodie_: for bonus points, check that the charmstore repo passes its tests with the new package
<rogpeppe> bodie_: and we should perhaps think about moving toward entirely removing testing/repo
<rogpeppe> bodie_: there will be places where it's still useful, but i think a better way would be to have charm testing repos inside the packages/repos that *use* the charm package
<bodie_> rogpeppe, perhaps a good approach would be for charm to expose some methods for generating mock charms for core tests that need to integrate with charm
<bodie_> (looking forward)
<rogpeppe> bodie_: that's another decent approach that might be good
<rogpeppe> bodie_: the only down side is that if every test is doing that, it can lead to a lot of disk churn
<rogpeppe> bodie_: a lot of tests don't really care about the details of the charms - they just need *some* example charm to reploy
<rogpeppe> deploy
<bodie_> heh, was still mid comprehending your thoughts
 * bodie_ scribbles "listen better" note with all the others
<bodie_> I'm not really seeing how that solves the problem since it's like turning the deps inside out, where clients must define the interactions they expect with charm.  but I don't really have an opinion either way yet -- I was thinking of generating in-memory fake charms though, but I didn't think about how much file interaction there is with charm
<rogpeppe> bodie_: another thing it might be interesting to do is make it easier to have an all in-memory charm
<rogpeppe> bodie_: ha
<bodie_> +1!  brb, meeting
<rogpeppe> bodie_: i think it depends how one thinks of the testing charms
<rogpeppe> bodie_: i think of them like they're testing data - a test wants to see what will happen when we do something with a given charm. it could specify that charm in the testing code, or as external data.
<rogpeppe> bodie_: the external-data approach is arguably more readable, as the charm's in the form that it is usually specified
<bodie_> rogpeppe, maybe it's as simple as having a function that cranks out a memory representation of the charm files, and then loads them as if they were a "real" charm file
<rogpeppe> bodie_: but the in-testing-code is more flexible
<bodie_> it's dumb, but it could be an easy out
<rogpeppe> bodie_: it's easy enough to do
<rogpeppe> bodie_: apart from the 100s of tests that would need changing in juju-core
<rogpeppe> bodie_: and it's the thought of that that leads me to suggest a half-way house, where juju-core has its own charm testing repo
<rogpeppe> bodie_: so then we don't need to change all those tests
<rogpeppe> bodie_: (assuming we get juju-core to prime the charm package on the location of the juju-core charm repo)
<wwitzel3> voidspace: updated the test to exercise the rsyslogHosts conditional logic
<voidspace> wwitzel3: looking
<voidspace> wwitzel3: LGTM
<wwitzel3> voidspace: thanks
<mgz> update on ppc blocker, bug 1388853
<mup> Bug #1388853: ppc64el unittests consistently fails <ci> <ppc64el> <regression> <test-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1388853>
<mgz> the crash stuff is dealt with by having a newer compiler than is available in trusty, our test machine has this
<mgz> if needed, ppa:ubuntu-toolchain-r/ppa can get you one as well
<mgz> the remaining failures documented in that bug seem like ppc-specific test issues which just need fixing, naming of arch/tools issues and such like
<alexisb> natefinch, can someone in the appropriate timezone take a look? ^^^
<mgz> I can tell anyone who wants to take it up how to get on our actual ppc machine if needed
<alexisb> mgz, can you make sure there is an updateint he bug
<mgz> alexisb: yeah, I'm also going to close the previous bug as that just got very confused
<natefinch> alexisb: yep
<natefinch> mgz: writing up how to get on our PPC machine in a place we can easily find it would be very useful
<mgz> natefinch: we don't have a general machine for playing on, just the one we use as the jenkins slave
<mgz> alexisb, natefinch: added details to the bug
<natefinch> mgz: thanks
<voidspace> g;night all
<katco> ericsnow: i may be looking at this wrong, but it looks like my review request didn't have a diff generated? http://reviews.vapour.ws/r/327/
<ericsnow> katco: yeah, look like it :(
<ericsnow> katco: that still happens infrequently
<katco> ericsnow: did i do something wrong/different, or is that a known issue?
<ericsnow> katco: it happens infrequently enough that I haven't looked into it
<ericsnow> katco: not your fault
<katco> ericsnow: k, ty sir :)
<ericsnow> katco: you can still use rbt to post the patch
<katco> ericsnow: righty-o
<menn0> waigani: morning
<waigani> menn0: morning
<katco> am i correct in assuming landings are blocked?
<menn0> yes they are
<menn0> due to bug 1388853
<mup> Bug #1388853: ppc64el unittests consistently fails <ci> <ppc64el> <regression> <test-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1388853>
<katco> ok, thanks menn0
<katco> yeah, figured, but wanted to ask just to be sure
<menn0> martin has done a good analysis. the problems looks pretty simple to fix so i'm going to have a go.
<katco> good luck, menn0. may the source be with you.
<mwhudson> good morning
<menn0> mwhudson: howdy
<mwhudson> someone put "dummy-admin dummy-admin just now just now" in the expected output of a test?
<menn0> mwhudson: someone has
<mwhudson> oh dear
<mwhudson> (well, unless the test uses a synthetic time source, which it apparently doesn't...)
<menn0> mwhudson: and it could even be thumper ...
<menn0> mwhudson: although I think I might have reviewed that one
<mwhudson> in a way that's good because i have no problems with telling thumper that he's done something stupid :)
<menn0> LOL
<mwhudson> whereas i might be a bit more circumspect with someone i didn't know so well :)
<menn0> i'll fix that and have a look at the other problem too
<menn0> although I can't get that to happen on my machine
<menn0> I suspect you actually need to be on a ppc64 host
<mgz> menn0: I can tell you how to access the jenkins build slave if that would help
<menn0> mgz: i have a few ideas to try first but could you send me the details anyway
<mwhudson> menn0, waigani, davecheney: email standup i guess?
<menn0> mwhudson: unless you would prefer otherwise?
<waigani> I'm easy either way
<mwhudson> i am currently in a cafe on extremely slow 3g so email sounds good :)
<waigani> email it i
<waigani> s
<menn0> cool
<mgz> menn0: https://pastebin.canonical.com/119817
<menn0> mgz: cheers
<waigani> menn0: I may have hit a chicken and egg
<menn0> waigani: in what way
<menn0> ?
<waigani> menn0: there is a settings doc which uses a global env key as it's key
<waigani> menn0: it holds the configuration for the environment
<waigani> menn0: the key is now perpended with the env-uuid
<waigani> menn0: and the doc exists, with a docID _id, before the upgrade step is run
<waigani> menn0: so during the upgrade step, it gets perpended with the env-uuid again
<waigani> menn0: and the test also fails as len(oldDocs) != len(newDocs) - that one I can fix easy enough
<katco> wallyworld_: noooot sure what happened, rejoining
<menn0> waigani: give me a sec
<menn0> waigani: ok
<waigani> menn0: yep, went you get a sec - does it jog anything from the workarounds you had to do?
<menn0> waigani: sounds like you might need to add another little hack
<menn0> waigani: but i'm not clear on why the env-uuid gets added twice
<menn0> waigani: can you explain that?
<waigani> menn0: good question, give me a sec I'll see...
<waigani> menn0: because I used the global env key in one of the dummy docs to migrate.
<waigani> menn0: so if I remove that and make the test expect len(oldDocs) + 1, the test should pass
<waigani>  or remove the envion doc from the newIDs returned...
<waigani> ah no, okay I'll stop thinking out loud and sort this
<menn0> waigani: ok. let me know if you need a sounding board again :)
<waigani> menn0: thanks :)
<menn0> This is one half of fixing the CI blocker. can someone PTAL? http://reviews.vapour.ws/r/329/
<davecheney> menn0: can you just delete the check fo rthe duration
<davecheney> it's unknowable
<natefinch> +1
<menn0> davecheney, natefinch: but I've made the test accept any possible duration. is that not ok?
<menn0> at least then the test ensure that we're getting the right shaped output
<davecheney> menn0: fells like solving the wrong problem
<davecheney> now that test will fail when tim changes the printing of an _arbitrary_ duration
<menn0> but if I do that there's nothing testing that the duration emitted by "user list" is sanely formatted at all!
<menn0> davecheney: ^
<menn0> davecheney: or put another way, there's nothing test that the duration formatting function is in use
<menn0> testing even
<natefinch> this is why I like internal tests ;)
<menn0> davecheney, natefinch: as this is becoming yet another testing debate and I just want to get this CI blocker sorted so that I can get back to useful work I will just do as you ask
<natefinch> menn0: for the record, I'm ok with either fix
<davecheney> menn0: natefinch same
<menn0> natefinch, davecheney: so what, leave the branch as it is?
<menn0> I just started relaxing the regex further
<natefinch> menn0: I put a ship it on it
<menn0> ok
<davecheney> menn0: do the absolute minimum required to get the test passing
<davecheney> as you say
<davecheney> this is a pointless testing debate
<davecheney> one of N
<menn0> thanks. i've sent that off for merging.
<menn0> now for the other half of the ticket.
<wallyworld_> menn0: i can pick up the ppc64 test failure
<katco> wallyworld_: fwiw i had to clear out my cookies... looks like time-changes mess with something w/ google apps
<wallyworld_> \o/
<katco> wallyworld_: the time changes from brussels probably triggered it on my laptop, daylight savings time for my main comp
 * katco shrugs
 * wallyworld_ shrugs too
<katco> software!
<menn0> wallyworld_: ok. it looks related to your changes from yesterday.
<wallyworld_> menn0: yep - i had to add extra metadata to account for 1.20 being wrong but clearly when run on non amd64, the expected list of metadata entries is different
<menn0> wallyworld_: the fix for the other part of the ticket (TestUserList) just landed
<wallyworld_> menn0: awesome, ty
<lazyPower> Ran into an interesting AWS issue with a customer that I've not seen before - if anyone has a moment to take a look - https://launchpad.net/bugs/1389014
<mup> Bug #1389014: juju AWS EC2 "unit-get public-address" gives private address  <juju-core:New> <https://launchpad.net/bugs/1389014>
<davecheney> lazyPower: is the custoemr using vpc
<davecheney> ?
<davecheney> themonk@redqueen:~$ juju run -e amazon --service my-charm1 "unit-get public-address"
<davecheney> 172.31.4.32
<davecheney> ^ how did this work
<lazyPower> davecheney: no idea its themonk in #juju though
<lazyPower> exactly!
<lazyPower> a) how do you get an IP, b) how do you get the *same* ip
<davecheney> how was their server able to contact 172.31.4.32 ?
<davecheney> that is a private ip
<lazyPower> and c) how do you get a private ip
<davecheney> lazyPower: juju just returns whatever the aws metadata services tells it
<davecheney> so if aws says you'r ip address is 1.1.1.1
<davecheney> that's why juju knows as well
<lazyPower> davecheney: <themonk> lazyPower, what is 'provisioned in a VPC' ?
<lazyPower> i'm going to say the answer is probably no...
<lazyPower> davecheney: do you have a minute to pop in #juju and interface with themonk over his AWS issue? If not no biggie - he's got an open bug that he can track.
<davecheney> curl http://169.254.169.254/latest/public-ipv4
<davecheney> this is what juju does
<davecheney> join #juju
<davecheney> urgh
<davecheney> sorry, i thought I was in that channel
<davecheney> i have so many called #juju
<lazyPower> all good davecheney :) I have the same issue between canonirc and freenode. so i know the feeling.
#juju-dev 2014-11-04
<axw> wallyworld_: does health/qos cover surfacing status messages from charms? e.g. "waiting for storage X"?
<wallyworld_> axw: yep
<axw> cool
<wallyworld_> there will be a juju-status hook tool
<wwitzel31> wallyworld_: thanks for merging that fix
<wallyworld_> np, thanks for fixing
<wallyworld_> turned out to be a simpl eone
<wallyworld_> fwereade: around?
<wallyworld_> fwereade: ping
<fwereade> wallyworld_, oops, sorry
<fwereade> wallyworld_, how's it going?
<wallyworld_> fwereade: hi, am late for dinner, got a few things to discuss, can i ping ypu later?
<fwereade> wallyworld_, ofc
<wallyworld_> np, gotta run
<wallyworld_> ttyl
<fwereade> wallyworld_, oh crap I forgot we had one scheduled this morning
<fwereade> wallyworld_, went out for coffee with cath
<mattyw> morning folks
<dimitern> TheMue, standup?
<fwereade> rogpeppe1, do you know: what's the current state of the art on making real charm directories to test with?
<fwereade> rogpeppe1, offhand I can think of a disturbingly large number of places with roughly connected functionality
<rogpeppe1> fwereade: i was chatting about this with menno yesterday
<rogpeppe1> fwereade: we had a couple of thoughts
<rogpeppe1> fwereade: 1) having lots of things depending on the one single testing charm repo is Bad
<fwereade> rogpeppe1, +1
<rogpeppe1> fwereade: 2) quite a few places would probably be better off just making in-memory charms rather than relying on a charm repo on disk
<fwereade> rogpeppe1, agreed up to a point, but I'm currently thinking about needing actual charms on disk -- those cases do exist
<rogpeppe1> fwereade: i think that a reasonable solution to that is to make it easy to create an in-memory charm that's also straightforward to expand to disk if needed
<rogpeppe1> fwereade: the most straightforward thing is just to provide a straightforward way to make a *charm.CharmArchive
<rogpeppe1> too many "straightforwards" :)
<fwereade> rogpeppe1, (oh yeah, I was meaning to ask, why the stuttering?)
<fwereade> rogpeppe1, (vs *charm.Archive?)
<fwereade> rogpeppe1, (not that that's anything but a derail)
<rogpeppe1> fwereade: because its symmetric with charm.BundleArchive
<rogpeppe1> fwereade: we could probably have gone with charm.Archive and charm.BundleArchive actually
<rogpeppe1> fwereade: but the shed has already been painted
<fwereade> rogpeppe1, yeah, I assumed there was a reason, just wanted to know what it was
<mjs0> rogpeppe1: I don't think you were talking to me about this... davecheney maybe?
<fwereade> rogpeppe1, fwiw, reading back, I'm not so much thinking of a charm archive on disk, I'm thinking of custom-built charms for particular test cases
<fwereade> rogpeppe1, and I feel like I've seen/written related code several times over in the past
<rogpeppe1> mjs0: oops, it was bodie, sorry
<fwereade> rogpeppe1, and weighing up the cost/benefit of writing yet more vs consolidating it a bit and what I can actually afford to spend to get those benefits
<mjs0> rogpeppe1: no worries
<mjs0> :)
<rogpeppe1> fwereade: i'm also thinking of that. but you said that we needed actual charms on disk
<fwereade> rogpeppe1, well, I need stuff on the filesystem to run the tests against, that doesn't automatically imply a repo
<fwereade> rogpeppe1, and a *general* in-memory charm representation makes me a bit nervous
<fwereade> rogpeppe1, will get very big/complex to handle all the cases wecurrently worry about
<rogpeppe1> fwereade: we already have one
<rogpeppe1> fwereade: it's called CharmArchive :)
<fwereade> rogpeppe1, heh, indeed
<fwereade> rogpeppe1, but charm archive creation is not exactly optimised for testing usage
<rogpeppe1> fwereade: definitely not
<rogpeppe1> fwereade: which is why i was thinking of a testing helper function to do that
<rogpeppe1> fwereade: it wouldn't need to touch disk
<fwereade> rogpeppe1, yeah, and that's what I worry will get super-complex, and will take me a couple of days to survey the field well enough to even get a handle on the true size of the task
<rogpeppe1> fwereade: well, if you don't need any actual working hook contents, it would be very easy
<fwereade> rogpeppe1, is there much reason to create an archive when it won't need to ever hit the disk?
<rogpeppe1> fwereade: so we can just use *charm.CharmArchive...
<fwereade> rogpeppe1, yeah, I'm all involved with the uniter again, so I care more about what lands on disk than anything else
<fwereade> rogpeppe1, but an archive is frequently a step too far
<fwereade> rogpeppe1, all I need is the dir
<rogpeppe1> fwereade: an archive is a good first step - if you've got an archive, you can trivially call ExpandTo
<rogpeppe1> fwereade: but there are many cases (most cases) where we don't need or want anything on disk
<fwereade> rogpeppe1, granted
<rogpeppe1> fwereade: and creating a bundle of files and directories is almost certainly going to be more expensive than creating a zip archive (which doesn't even need to do compression if we don't want)
<fwereade> rogpeppe1, the way I see it there are 3 cases
<rogpeppe1> fwereade: re: my first point, i'm considering deleting the testing.Charms variable
<fwereade> rogpeppe1, one, we just need to implement the interface, definitely no need to put it on disk
<rogpeppe1> fwereade: and replacing it with:
<rogpeppe1> // NewRepo returns a new testing charm repository
<rogpeppe1> // rooted at the given path, relative to the package directory of
<rogpeppe1> // the calling package.
<rogpeppe1> func NewRepo(path, defaultSeries string) *Repo {
<fwereade> rogpeppe1, stopping talking, listening to you instead
<rogpeppe1> fwereade: the interface is not enough
<rogpeppe1> fwereade: because it doesn't cover anything other than metadata and config (and actions)
<fwereade> rogpeppe1, it's enough for state tests, surely?
<fwereade> rogpeppe1, and metrics
<rogpeppe1> fwereade: indeed
<rogpeppe1> fwereade: i'm... not sure
<fwereade> rogpeppe1, but those are all we need in certain situations, aren't they?
<rogpeppe1> fwereade: probably
<fwereade> rogpeppe1, I accept it's useless for most of what you need to do
<fwereade> rogpeppe1, where you care about content
<rogpeppe1> fwereade: it depends whether it's worth having two parallel mechanisms, one without files and one with
<fwereade> rogpeppe1, but have no reason to risk the involvement of spinning rust in your tests
<rogpeppe1> fwereade: i agree
<rogpeppe1> fwereade: but there's no reason why creating an archive needs to involve spinning rust
<fwereade> rogpeppe1, agreed
<fwereade> rogpeppe1, but I don't see *that* many more cases of ArchiveTo(f) than ArchiveTo(buf)
<fwereade> rogpeppe1, although
 * rogpeppe1 goes to look at the state tests
<fwereade> rogpeppe1, yes, it's only Dirs that have that
<fwereade> bah
<fwereade> ignore me
<rogpeppe> fwereade: yeah, look for CharmDir
<wallyworld_> fwereade: free?
<fwereade> wallyworld_, sure
<fwereade> rogpeppe, thanks, will think more
<fwereade> rogpeppe, and probably talk to bodie when he comes on
<fwereade> wallyworld_, joining our 1:1
<wallyworld_> fwereade: the hamster died :-)
<fwereade> wallyworld_, I can hear yu, guess you can't me?>
<wallyworld_> no:-( let me check my end
<fwereade> wallyworld_, ha, tab actually  crashed
<fwereade> wallyworld_, ffs think I'm gone again, brb
<wallyworld_> fwereade: cooome baaaack, i didn't mean it
 * fwereade waits for sound to start...
 * fwereade sighs, grumbles
 * wallyworld_ taps fingers waiting for hamster to start running
<voidspace> dimitern: ping
<dimitern> voidspace, pong
<voidspace> dimitern: this is how goamz configures the response for the test server for calls to AssignPrivateIPAddresses
<voidspace> dimitern: http://pastebin.ubuntu.com/8817898/
<voidspace> dimitern: is it ok to do the same or do we have a different abstraction?
<voidspace> dimitern: it configures the xml response directly
<dimitern> voidspace, looking
<dimitern> voidspace, that's it yes - I suppose it was made like this to allow greater flexibility while testing
<voidspace> dimitern: we have some tests like this in cmd/juju/publish_test.go
<voidspace> and a couple more
<voidspace> but not many that directly configure responses
<voidspace> dimitern: I'll do this :-)
<voidspace> dimitern: if someone objects they can suggest a better way in review
<dimitern> voidspace, the publish tests are not ec2-specific
<voidspace> dimitern: I'm fine with it, it's a bit "low level"
<voidspace> ah, interesting
<dimitern> voidspace, it's another testing server afaics
<voidspace> what is gitjujutesting.Server then
<voidspace> checking
<dimitern> voidspace, well, hide it in a helper :)
<voidspace> well, indeed
<dimitern> voidspace, I think it's a simple http server
<voidspace> just reusing the same api
<voidspace> dimitern: it is
<voidspace> dimitern: NewHTTPServer
<voidspace> dimitern: that's probably what is under the hood for the goamz test server
<dimitern> voidspace, possibly quite similar, but the goamz one has a few ec2-specific helpers I think
<voidspace> right
<voidspace> dimitern: anyway, I'll procede in this direction...
<voidspace> ah dammit
<voidspace> I need to configure a call to "Instances" first to return the network interface
<voidspace> we need the network interface id before we can ask for the ip address
<voidspace> never mind, it's only more xml
<voidspace> maybe I can add a network interface to the instance via goamz instead
<dimitern> voidspace, yes, you can
<voidspace> dimitern: it's a call to CreateNetworkInterface then AttachNetworkInterface and I need an ec2 instance
<voidspace> dimitern: probably still less opaque than the xml
<dimitern> voidspace, in fact I did modify the goamz test server to create a network interface when you run an instance
<voidspace> dimitern: but it didn't get merged yet?
<voidspace> dimitern: that would be helpful as it matches the default behaviour
<dimitern> voidspace, check out TestRunInstancesVPCCreatesDefaultNICWithoutSubnetIdOrNICs
<voidspace> dimitern: thanks
<dimitern> voidspace, look also at ec2test.Server.addDefaultNIC and how it's used
<voidspace> dimitern: private method though
<voidspace> and needs a subnet
<voidspace> so I'll still have to do it somewhat manually
<voidspace> but these examples show how
<dimitern> voidspace, I didn't mean to call it directly, it'll get called if you specify a SubnetID in RunInstanceParams
<voidspace> ah right
<voidspace> maybe we can just add that to our testcase setup
<dimitern> voidspace, it's meant to simulate what the real ec2 api does
<voidspace> as the other tests shouldn't care about a subnet
<voidspace> dimitern: cool, thanks for your help
<dimitern> voidspace, np, it's a bit messy to test, but ping me if you run into something else
<rogpeppe> trivial update anyone - this fixes juju-dev so that the tests can work under the upcoming Go 1.4: https://github.com/juju/juju/pull/1034
<rogpeppe> dimitern, voidspace: ^
<voidspace> dimitern: so the trouble with having goamz create the network interface is that I need an EC2 instance, so I need the auth credentials
<voidspace> rogpeppe: that revision of testing has already been reviewed?
<rogpeppe> voidspace: yes
<rogpeppe> voidspace: (otherwise it wouldn't have been landed)
<dimitern> voidspace, I'm not sure I follow..
<dimitern> rogpeppe, looking
<rogpeppe> voidspace: currently if you use jc.DeepEquals under Go1.4, it will panic
<voidspace> dimitern: to call RunInstance or anyother ec2 api directly from goamz (which I'll need to do to setup the network interface)
<voidspace> dimitern: I need an ec2.EC2 instance
<voidspace> dimitern: and creating one of those requires auth credentials
<voidspace> rogpeppe: LGTM
<voidspace> rogpeppe: :-)
<rogpeppe> voidspace: ta
<rogpeppe> voidspace: where are you doing this from?
<dimitern> rogpeppe, it would've been nicer to add a comment to the change in juju/testing :)
<voidspace> rogpeppe: provider/ec2/local_test.go
<rogpeppe> voidspace: you're calling ec2 apis from the tests?
<voidspace> rogpeppe: a new method finds the network interface from the ec2 instance and then uses the id of that to provide a new static ip address
<voidspace> rogpeppe: into the test server...
<dimitern> voidspace, just a sec
<rogpeppe> voidspace: the tests have auth creds
<voidspace> rogpeppe: I need to configure the response to Instances to have a network interface
<voidspace> rogpeppe: where?
<rogpeppe> voidspace: see the EnvironEC2 function
<rogpeppe> dimitern: i'm not sure what you mean. i did add a relevant comment in github.com/juju/testing/checkers
<voidspace> rogpeppe: ah, cool
<voidspace> rogpeppe: he meant as a comment on the PR linking to the change
<dimitern> rogpeppe, no I meant to add a comment on the #1034 PR with a link to the other PR in juju/testing, which introduced the change
<dimitern> voidspace, sorry, so you can do that, but you need to modify how runInstances is called in provider/ec2/
<rogpeppe> dimitern: ah, ok
<rogpeppe> dimitern: will do
<voidspace> dimitern: so modify runInstances to provide the subnet id?
<voidspace> dimitern: so that the goamz test server will do the right thing?
<dimitern> voidspace, if you call it and set SubnetID in ec2.RunInstances struct, it will use the VPC-aware version and create a NIC (both the real ec2 and the test server)
<dimitern> voidspace, exactly :)
<rogpeppe> dimitern: i've added a link
<rogpeppe> dimitern: LGTY now?
<voidspace> dimitern: that sounds dangerous....
<dimitern> voidspace, but, please be aware the subnets are linked to AZs and this has to be done carefully, so not to break axw's AZ distribution code
<voidspace> dimitern: exactly...
<voidspace> dimitern: so then I have to test that change - which is a deeper rat-hole to get into
<dimitern> rogpeppe, LGTM, thanks!
<voidspace> dimitern: maybe I'll try the XML in a helper first...
<voidspace> dimitern: or I can move the test to be in ec2_test.go (white box) and have access to Environ.EnvironEC2 function (exported in export_test)
<dimitern> voidspace, maybe you can propose a pre-req that just tests setting an AZ (or picking one automatically with the distribution code) also sets SubnetID in RunInstances?
<dimitern> voidspace, that works for me, but please add a comment
<voidspace> dimitern: moving out of localServerSuite loses me a lot of setup though, so that's not ideal either :-)
<voidspace> the black box test is a bare Suite
<dimitern> voidspace, hmm.. that's a bit unfortunate
<voidspace> dimitern: messing with the way we create ec2 instances just for testability sounds more dangerous than I'd like to venture into
<voidspace> dimitern: so I'll check the XML route - it's easy enough to try it
<dimitern> voidspace, how about using ec2.InstanceEC2(inst *instance.Instance) to get access to the underlying instance struct?
<voidspace> dimitern: that might work
<dimitern> voidspace, or t.srv.ec2srv.Instance(strId) - there seem to be a few useful examples in provider/ec2/local_test.go
<voidspace> yeah
<voidspace> dimitern: if adding a network interface to that struct works then that could be it
<voidspace> it has the NetworkInterfaces slot
<voidspace> thanks
<voidspace> lunch first
<dimitern> voidspace, that'll also work, but it's not the same path we'd take eventually (i.e. we'll rely on the automatic NIC creation); but I'm fine with it as a workaround for testing (+please add a comment if you do this)
<voidspace> dimitern: ok
<voidspace> dimitern: if we go the route of setting SubnetID in RunInstances I'd rather pair on it
<voidspace> dimitern: I'd be very concerned about the intricacies of that
<dimitern> voidspace, sure, it's perhaps best
<voidspace> dimitern: and as we don't *need* it yet, it seems wiser to avoid it for now
<voidspace> dimitern: I'll add the comment that creating a default network interface for testing is a temporary measure
<dimitern> voidspace, +1
* ChanServ changed the topic of #juju-dev to: https://juju.ubuntu.com | On-call reviewer: see calendar | Open critical bugs:  None
<sinzui> natefinch, jam, mgz: Do you have a few minutes to review https://github.com/juju/juju/pull/1035
<mgz> sinzui: lgtm
<mgz> we also want to create the branch now?
<sinzui> mgz ...already done and...
<sinzui> mgz, https://github.com/juju/juju/pull/1036
<wwitzel3> natefinch: omw, having plugin issues
<mgz> sinzui: also lgtm. trying to remember if there's anything else that needs to be done for new branches... I think the landing bot just works?
<sinzui> mgz, abentley is adding the new branch to the ci-director cron job now
<sinzui> mgz, we will see if the lander sees my $$merge$$ in a few minutes
<abentley> sinzui, mgz: done.
<sinzui> bugger. I think I need to prepare a vivid source package too
 * sinzui polls mail to see vivid accepted
<katco> davechen1y: ty for the reviews
<sinzui> mgz, can you send an email to the juju-devel list explaining master is 1.22-alpha1 and we have a new stable branch 1.21 at 1.21-beta1...merges still in progress of course
<mgz> sinzui: sure thing
<mgz> what are we expecting people to want to land on 1.21?
<mgz> I guess I can just link the launchpad milestone pages?
<alexisb> he there mgz
<mgz> hey alexis
<alexisb> I see you but you are silent :)
<mgz> argh, ahngouts again
<alexisb> yes they can be fickle things
<mgz> sec, going chrome
<ericsnow> fwereade: ping
<fwereade> ericsnow, pong
<ericsnow> fwereade: do you have any reservations with making --download the default bahavior for "juju backups create"?
<fwereade> ericsnow, I'm heartily +1
<ericsnow> fwereade: cool
<fwereade> ericsnow, if the backup never makes it off the system being backed up, it ain't much of a backup
<ericsnow> fwereade: :)
<katco> fwereade: thank you for the review; i'll be revising after i land some PRs
<fwereade> katco, cool
<natefinch> ericsnow, fwereade: now the problem is, what do you call the flag to not download?
<ericsnow> natefinch: --no-download
<fwereade> natefinch, ericsnow: --eatmydata? ;p
<natefinch> haha
<ericsnow> :)
<natefinch> can you print out a big warning when someone uses whatever nodownload flag, that says something like "Your backup will be stored on the server.  This is NOT a long term solution and the backup should be downloaded as soon as possible."
<katco> do we have any util library to perform slice-item deletions?
<ericsnow> natefinch: yep
<natefinch> katco: meh... a := append(a[:i],a[i+1:]...)
<natefinch> er = not :=
<katco> natefinch: boundary edge cases =/
<katco> what if i is 0, or len(a)-1
<katco> clutters the clarity of the code =|
<katco> natefinch: bah, so i always forget this. after you reduce down all the code branches, you only really need 1 bounds check. so not so cluttered :)
<natefinch> :)
<natefinch> going to pick up my Lily from preschool and then off to vote.
<katco> voted this morning!
<katco> happy election day :)
<natefinch> katco: cool.  Happy election day :)
<voidspace> niemeyer: ping
<niemeyer> voidspace: Hey
<voidspace> niemeyer: hey, hi
<voidspace> niemeyer: I have code calling EC2.AssignPrivateIPAddresses
<voidspace> niemeyer: I'd like to be able to configure the response of the test server
<voidspace> niemeyer: I'd like it to fail with InvalidParameterValue and PrivateIPAddressLimitExceeded
<voidspace> niemeyer: as far as I can tell I can't hack the test server to return specific errors for calls, without the test server itself being coded to produce those responses
<voidspace> niemeyer: is that correct?
<voidspace> niemeyer: (goamz just in case that wasn't completely clear)
<niemeyer> voidspace: I'm not sure.. it's been a while since I looked at that code, but if there's no public API for doing that, it should be correct
<voidspace> ok
<voidspace> niemeyer: and to the best of your knowledge, if the test server implements an api (for example there's specific code for AssignPrivateIPAddresses)
<voidspace> niemeyer: the test server *should* modify the instances it holds to reflect the actions
<voidspace> I haven't dug into that code yet, I'm about to - but on my first cut I wasn't seeing the IP address added to the instance after a call to AssignPrivateIPAddresses
<niemeyer> voidspace: Yes, it should be realistic
<voidspace> cool, so it should be added and it's probably my fault that I can't see it yet
<niemeyer> voidspace: Erring on the side of the problematic behavior, when there's choice
<voidspace> cool
<voidspace> niemeyer: right
<niemeyer> voidspace: E.g. if a response may come without an IP address on the first try, it should force the requester to retry
<voidspace> ah right, interesting
<voidspace> in our case we're providing the IP address to assign
<voidspace> we're managing them ourselves
<voidspace> as the actual ec2 api doesn't tell you which one it assigns if it does succeed - so you have to work it out
<voidspace> and that's inherently racy if multiple addresses might be being assigned - so instead we'll manage them ourselves
<niemeyer> voidspace: Right, so the test server should mimic that problematic behavior
<niemeyer> voidspace: Forcing implementations to do the right thing
<rogpeppe> fwereade: https://github.com/juju/charm/pull/73 is a start on one of the points i mentioned earlier
<rogpeppe> bodie_: you might want to take a look too
<bodie_> rogpeppe, will do.  was just discussing some charm testing needs with fwereade a little while ago
<rogpeppe> bodie_: i have a plan to add some more stuff above this, to address custom charms that don't want to come from disk
<voidspace> g'night all
<mattyw> natefinch, ping?
<natefinch> mattyw: yo
<mattyw> natefinch, I picked your name at random - congratulations... Who's a good person to talk to about the manual provider?
<natefinch> I have some knowledge of it
<mattyw> folks, I'm calling it a day, see you all tomorrow
<ericsnow> natefinch: how's it looking for those 2 reviews?
<wwitzel3> ericsnow: I'm looking at the other one now, fyi
<ericsnow> wwitzel3: thanks!
<natefinch> ericsnow: sorry, busy day today with voting and stuff.  I'm working on it, honest :)
<ericsnow> natefinch: :)
<ericsnow> natefinch: FYI, I also have a patch up now for download-by-default
<natefinch> is it just me, or is it impossible to actually tell what fixes addressed what comments in a review?
<wwitzel3> natefinch: not just you
<fwereade> wwitzel3, hey, re http://reviews.vapour.ws/r/318/
<fwereade> wwitzel3, I'm suggesting that juju-run should accept the same syntax for relations as do the various hook tools
<natefinch> ericsnow: can you help me understand the reviews I'm re-reviewing?  If you can show me where to look, I can better understand what I'm looking at.
<fwereade> wwitzel3, it is interesting to note that we would accept `-r 21`, or `-r db:21` or, in fact, `-r lolwhatever:21` and all would be accepted and handled as "21"
<ericsnow> natefinch: sure
<wwitzel3> fwereade: right, but I but isn't that translastion going to be handled by "juju run"
<natefinch> ericsnow: like, basically, what comments were left that you addressed that need to be approved?
<natefinch> ericsnow: I assume the people who reviewed before did a good job, I just want to approve whatever hasn't been reviewed
<ericsnow> natefinch: I'm not exactly sure; they were pretty thorough
<fwereade> wwitzel3, well, as a charm author I'm likely to want to invoke juju-run in whatever way I'm used to invoking relation-get
<fwereade> wwitzel3, ie with "-r db:21"
<ericsnow> natefinch: I addressed everything that came up
<fwereade> wwitzel3, and not to support that syntax feels like we're missing a trick
<wwitzel3> fwereade: ok, I see what you mean now by "ignorebit:", I was really confused before.
<wwitzel3> fwereade: you mean .. -r ignoredbit:21
<wwitzel3> fwereade: yeah, we can just reuse the newRelationIdValue as you suggested
<fwereade> wwitzel3, cool
<katco> need to take my dog to the vet (UTI), bbiab
<natefinch> ericsnow: if you feel you addressed all the problems that were mentioned, and that there's unlikely to be anything outstanding, I can rubber stamp it for you.
<ericsnow> natefinch: fine with me :)
<wwitzel3> fwereade: also when you say, make jujuc accept --relation that's different from cmd/juju right?
<wwitzel3> fwereade: you mean uniter/jujuc right?
<ericsnow> natefinch: thanks
<fwereade> wwitzel3, yeah, exactly, I'm suggesting that if we're having --relation, or --relation-id in juju-run, it would equally be nice to accept the same spelling in the various uniter/jujuc commands
<wwitzel3> fwereade: .. where would they be needed in jujuc?
<natefinch> holy nested if clauses, batman!
<fwereade> wwitzel3, relation-list, relation-get, relation-set
<fwereade> wwitzel3, just search the tests for "-r" but I think that should be all
<wwitzel3> fwereade: wait, that doesn't make sense to me .. why would you pass in a relation to relation-list?
<fwereade> wwitzel3, relation-list is "tell me the units in some relation"
<fwereade> wwitzel3, relation-ids is "tell me what relations use this endpoint"
<fwereade> wwitzel3, which indeed returns relation ids ratherthan accepting them
<wwitzel3> fwereade: wait, so you are just saying make it accept -r / --relation (mapped to the same input)
<fwereade> wwitzel3, yeah, exactly
<wwitzel3> fwereade: no that it should accept another relation .. oh ok
<wwitzel3> fwereade: phew, I thought you'd gone mad, turns out it was just me ;)
<fwereade> wwitzel3, just make juju-run and juju consistent wrt how we specify relations
<fwereade> wwitzel3, jolly good ;p
<fwereade> s/ juju / jujuc /
<wwitzel3> fwereade: yep, that all makes sense, will get that taken care of now, thanks
<fwereade> wwitzel3, cool, thanks
<waigani> morning all
<alexisb> morning waigani
<waigani> alexisb: morning :)
<menn0> davechen1y, mwhudson, waigani: morning all
<natefinch> Anyone need a review?  It's sorta hard to understand what reviews still need attention
<menn0> natefinch: I normally start with anything that doesn't have a Ship it or issues against it (i.e. nothing in the 3rd column of the dashboard)
<ericsnow> natefinch: did you take a look at http://reviews.vapour.ws/r/268/?
<natefinch> ericsnow: no, I can look at it though. There were just already a lot of comments, which makes it really hard to review
<ericsnow> natefinch: yeah, sorry, feel free to pass--I'll hit up menn0 and axw :)
<davechen1y> natefinch: http://reviews.vapour.ws/r/331/ if you have a moment
<natefinch> davechen1y: looking
<natefinch> davechen1y: gah, the problem with multiple repos... the changes here reflect changes in some other repo I can't see in the review.  I presume the changes in SpecializeCharmRepo are the fix for the data race you're talking about?
<wallyworld_> menn0: as a background task, if you could look at bug 1389389 that would be awesome; it raises it's head semi regularly
<mup> Bug #1389389: TestUpgradeStepsFailure intermittent test failure <intermittent-failure> <test-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1389389>
<wallyworld_> natefinch: while i'm whining about tests - any progress on fixing the ^@#!@$!@$ replicaset ones?
<menn0> wallyworld_: will do
<wallyworld_> ty
<natefinch> wallyworld_: no, sorry.  I haven't spent time on it recently.  I'll try to find time to do so, I know it's long overdue.
<wallyworld_> natefinch: np, thank you. we still get many landing failures, and replicaset tests are one of the main causes. there are a few others as well, i'm on the case for those also :-)
<wallyworld_> katco: did you get the feedback and/or +1 you needed to unblock?
<katco> wallyworld_: i did... reviewing feedback now
<wallyworld_> great
<katco> wallyworld_: thank you :)
<wallyworld_> katco: np, i talked with wlliam last night, he said to shout at him if you didn't get the info, so i can now put away my megaphone
<katco> wallyworld_: haha
<katco> wallyworld_: good news is that there are no major disagreements, so i can start implementing while we iterate to an agreeable state.
<wallyworld_> whoohoo
<wallyworld_> the approach to do the remote api first was well received
<katco> cool, good idea
<katco> it will be the oprah of leadership services. "you get leadership! and you get leadership!"
<natefinch> that's one of my favorite memes lately.  Just so useful in so many situations.  You get ebola, and YOU get ebola!  etc :)
<katco> haha
<katco> https://www.youtube.com/watch?v=xAhuSDRIDHE
<natefinch> (NB: you won't really get ebola)
<ericsnow> perrito666: FWIW, I recognize how complex the restore process is :)
<perrito666> what is dbFixer?
<ericsnow> perrito666: just what I called a hypothetical type that hides away the state-dependent stuff going on there
 * perrito666 forbids himself to code because its late in the night here and he knows bugs are going to appear
<ericsnow> :)
<perrito666> ericsnow: you have a subscription to the abstraction of the month magazine :p
<perrito666> dont take this as an offense but sometimes you remind me of the zope code base :)
<ericsnow> perrito666: I'm a contributing writer ;)
<ericsnow> perrito666: those were the good old days...
 * perrito666 tries to make some sense of reiewboard separations
 * mwhudson finally reappears
<perrito666> ericsnow: so, I have an indecent proposition for you
<ericsnow> perrito666: I'm listening
<perrito666> mm, nevermind, I was going to propose something but then I decided I am not sure I want to code that :p
 * perrito666 rented a room for OpenStackSummit that has the particularity to have several powerplugs... none of them at powercord distance of the desk on the room
<perrito666> in the up side, the room was cheap
<perrito666> ericsnow: so, I believe I can get rid of client call for prepare
<ericsnow> perrito666: cool
<perrito666> I am pretty sure that Finish is there to stay, since it has to be called with a different client connection
<ericsnow> perrito666: yuck
<perrito666> ericsnow: well it is bound to be
<perrito666> ericsnow: I am actually destroying the api server and the state server
<perrito666> you would expect that connection to fall
<perrito666> I agree its less than ideal
<perrito666> but it is also a unique case
<ericsnow> perrito666: Can't client.Restore() create a new client and call Finish on it?
<ericsnow> perrito666: considering it's a unique case
<perrito666> ericsnow: mm, well client restore finishes with rpc.ErrShutDown
<perrito666> let me re-read this to make sure I can do it
<ericsnow> k
<perrito666> mmm, yes, it can, but we would have the methods in the facade
<ericsnow> perrito666: having them in the facade I think is unavoidable but okay
<perrito666> well if unavoidable, we better consider ok
<perrito666> or we will end up with an ulcera
<perrito666> :p
<ericsnow> perrito666: I meant "but not the end of the world" :)
<perrito666> I am too old for Airbnb rent a room
<perrito666> they actually require for me to be silent after a certain hour.. in a room with parquet floor and in a house with a toilet that has a grinder (something I never saw before)
<perrito666> and I am doing my best to avoid typing like a mad man as I usually do because I know I produce a noise similar to a typewriter :p
<perrito666> ericsnow: btw, so far you are one of the only reviewers that actually uses the multiline selection feature, this makes my life way easier when reading comments
<ericsnow> perrito666: I think people are catching on little by little
<perrito666> yeah, but every now and then I get acomment on a line that is if err != nil and I already changed that line
<perrito666> so get it requires some devination
<perrito666> ericsnow: question
<ericsnow> perrito666: yeah
<perrito666> backups.NewClient
<perrito666> how fake can httpApiCloser be?
 * perrito666 is blatantly breaking his no code promise
<ericsnow> perrito666: in the API client tests we only care that the low-level methods were called properly
<perrito666> ok, anyway reading at it, it seems to me that Ill need a restore root
<ericsnow> perrito666: so for unit-testing the API client we want to keep that low-level implementation as simple as possible
<ericsnow> perrito666: ah, yep
<perrito666> ericsnow: word of advice, even if they are not public, when you create an interface (which I actually believe are more cumbersome than useful when not public, at that volume of code) throw a couple of lines of comments
<perrito666> mostly for the purpose of the extending members
<ericsnow> perrito666: k
<ericsnow> perrito666: I wrote up a basic archive workspace type that should help clean up some of the state/backups.Backups.Restore code (https://github.com/ericsnowcurrently/juju/commit/50623a104438c7c61d6921b9db4873ae5c619522)
<ericsnow> perrito666: OpenFile() could be used to open the agent conf from the archive
<perrito666> ericsnow: it can actually but for now I care only to have this in a solid enough state to be merged, the rest is just an academic exercise, which I will most likely dedicate to once merged
<perrito666> nice method btw
<perrito666> and I agree, that could go in utils/tar
<ericsnow> perrito666: k
<ericsnow> perrito666: yeah, it was just a quick stab at it
<perrito666> sounds like a useful feature for utils/tar
<perrito666> ericsnow: question
<ericsnow> perrito666: yeah
<perrito666> cmd/juju/backups/backups.go:86 why?
<perrito666> not returning a concrete type is making very difficult to actually use this outside
<ericsnow> perrito666: you mean newAPIClient?  what makes it hard to use outside?  outside where?
<perrito666> ericsnow: well I wanted to pass NewAPIClient as a sort of closure but the fact that it returns an APIClient kind of defeats the purpose since I was declaring the function as returning a Client
<perrito666> I am trying to avoid circular imports here
<perrito666> still trying to figure out how to actually make client reconnect
<ericsnow> perrito666: what circular imports?
<perrito666> between cmdbackups and api backups restore, looking for a better solution worry not
 * wallyworld_ types MAAS to make jool's irc client go "bing"
<bigjools> wallyworld_: fuck off
<wallyworld_> lol
<wallyworld_> maas
<wallyworld_> maas
<wallyworld_> bigjools: seen this one? bug 1387262
<mup> Bug #1387262: bootstrap fails with failure to execute queries before end of atomic block <bootstrap> <maas-provider> <juju-core:Triaged> <MAAS:New> <https://launchpad.net/bugs/1387262>
<bigjools> make me a copffee and I'll look
<katco> wallyworld_: sorry, just wanted to confirm you said maas?
<wallyworld_> ok, you come over here and i will
<wallyworld_> lol lolo lol
<bigjools> might come over this arvo then
<katco> or does it have to be upper-case like this: MAAS?
<perrito666> wallyworld_: why are we supposed to say maas?
<bigjools>  /o\
<wallyworld_> perrito666: cause bigjools has an irc alert that goes "ping!" whenerver we say MAAS
<katco> perrito666: i think we're supposed to say maas because wallyworld_ is interested in maas or something
 * wallyworld_ can't stop laughing
<katco> either way, maas is a fun word, so (shrug)
<perrito666> wallyworld_: really just saying maas?
<bigjools> wallyworld is secretly wanting to work on maas
<wallyworld_> yep, just MAAS
<katco> bigjools is a maas -ster of irc
<wallyworld_> a maas-ter something or other, for sure
<bigjools> wallyworld_ is a maasturbator
<perrito666> what a pleasure test deployments to amazon while on a country with decent connections
<wallyworld_> perrito666: where are you?
<perrito666> wallyworld_: paris
<wallyworld_> lucky you!
<perrito666> my uploads fly
<wallyworld_> wish i were there
<perrito666> wallyworld_: I am here for a juju on windows sprint, think again
<anastasiamac> so do i
<wallyworld_> perrito666: ah, well, there's good and bad :-)
<bigjools> lol
<perrito666> heh yeah
<perrito666> the thing is, this old lady that rents me a room has a faster internet that my office :p
<perrito666> or at least is better positioned in terms of topology
#juju-dev 2014-11-05
<wallyworld_> perrito666: from argentina, the electrons have so much further to go, and they get tred and need at rest in miami
<perrito666> that must be it, or the fact that the country has only one freaking connection to the outside world
<perrito666> it is a shame that when I am in countries with good internet Is always countries where bittorrent is illegal
<wallyworld_> it's illegal here too, doesn't stop me
<perrito666> wallyworld_: its legal in argentina
<wallyworld_> and in holland, it's not illegal to download, only upload
<perrito666> wallyworld_: for what I heard in France is "we send you the police" illegal
<bigjools> bt is illegal???
<wallyworld_> perrito666: you serious??? wtf
<bigjools> it's illegal to download pirated stuff but not illegal to use
<perrito666> bigjools: yeah that is what I meant
<katco> these countries give bt a 1:1 with pirating? that is rediculous...
<perrito666> nono I meant bt for things like movies
<perrito666> the fun thing is, I actually have an account in a digital movies service :p I just dont know my creds
<perrito666> It comes with my internet+cable subscription
<bigjools> well there's better places to get this stuff than BT nowadays *cough*
 * perrito666 sms his wife to get the creds for his service
<katco> wallyworld_: does juju have a concept of in-memory services (overloaded term: not juju services, but a SoA service) i could reference?
<katco> wallyworld_: i want to have only 1 instance of the lease manager running
<wallyworld_> katco: we sorta do that using a worker
<wallyworld_> the state server starts named workers
<wallyworld_> each worker can host a service
<katco> wallyworld_: is that pattern worth repeating?
<wallyworld_> yes, it's what we use right at the moment
<katco> wallyworld_: cool, ty sir. maas
<wallyworld_> np. it fits with current practice, and works
<bigjools> katco: ping
<katco> bigjools: hey, how can i help you?
<bigjools> katco: unping
<wallyworld_> the service can be written indeoendent of the worker
<bigjools> oops :)
<katco> lol
<wallyworld_> the worker glues the service into the state server
<wallyworld_> katco: just say MAAS to get him back
<katco> bigjools: you have a very maas day :)
<wallyworld_> lol
<bigjools>  /ignore wallyworld_
<katco> wallyworld_: ah ok. b/c the apiserver instantiates a new object for every api call, i need to get a singleton of some sort at init time
<wallyworld_> katco: that's the remoting layer
<katco> wallyworld_: because i think we want the leasing service to handle synchronization in memory
<wallyworld_> and yes, i disagree with that implementation. but think of it like a session
<katco> wallyworld_: right, it's the remoting layer. but at the time the leadership remote layer gets instantiated, it has to know about the single lease service
<wallyworld_> the service should be stateless, so it could instantiate a new lease service fascade. or else rely on the fact that a lease service work (only one) has been run
<wallyworld_> maybe easier to discuss face-face
<katco> wallyworld_: since the ctor requires a specific signature, i'm going to use a closure to make it a bit more clear where the lease service reference is coming from
<katco> wallyworld_: yeah probably, maybe at the stand-up
<wallyworld_> ok
<katco> wallyworld_: or actually i have time now, daughter just being put to bed
<katco> wallyworld_: if you're free
<wallyworld_> sure, let's meet in standup hangout
<katco> okie doke
<katco> that sounds maas to me
<katco> i mean nice. nice to me.
<bigjools>  /ignore katco
<perrito666> ericsnow: ok, I got rid of finish restore :)
<perrito666> tomorrow preparerestore
<perrito666> but for now sleep
<ericsnow> perrito666: sweet!
<perrito666> its 2am here
<ericsnow> perrito666: sleep!
<ericsnow> menn0: could you take one more look at http://reviews.vapour.ws/r/268/?
<ericsnow> menn0: I've addressed all review feedback
<ericsnow> menn0: it should be good to go
<menn0> ericsnow: ok will do. but not for an hour or so.
<ericsnow> menn0: no worries
<ericsnow> menn0: I'm probably EOD pretty soon so no hurry
<menn0> ericsnow: kk
<wallyworld> fwereade: got a few minutes?
<fwereade> wallyworld, heyhey
<wallyworld> fwereade: hi, i would love to check a few things regarding the health status spec, but dinner is almost ready, can i ping you soon?
<fwereade> wallyworld, ofc
<wallyworld> ta, will get back to you
<wallyworld> fwereade: ok to talk now? 1:1 hangout
<fwereade> wallyworld, with you in a minute
<wallyworld> no hurry
<fwereade> wallyworld, can you hear me?
<fwereade> wallyworld, Iguess not
<fwereade> wallyworld, endpoint: --waiting-for=db
<wallyworld> no
<wallyworld> sound died
<fwereade> wallyworld, relation: --waiting-for=db:3
<fwereade> wallyworld, unit: --waiting-for=db:3:mysql/2
<fwereade> wallyworld, rejoining
<jam> fwereade: wallyworld: are you guys in a hangout about the "juju status" doc? (I see editing going on while I'm commenting)
<fwereade> jam, just finished
<wallyworld> jam: we were, but fwereade has a sucky connection
<fwereade> jam, my hangout keeps dying :/
<mattyw> morning all
<voidspace> hey guys, IS have a problem with juju in #is-outage
<voidspace> this is the error they have https://pastebin.canonical.com/119944/
<voidspace> do we still redirect (and throw away) mongo logging?
<rogpeppe> fwereade: fancy having a look at this, touching on some of what we chatted about yesterday? https://github.com/juju/charm/pull/73
<dimitern> anyone available for a review on http://reviews.vapour.ws/r/349/ ?
<voidspace> dimitern: jam: you ever seen this mongo error (or similar)?
<voidspace> Wed Nov  5 09:13:37.209 Error: DBClientBase::findN: transport error: 127.0.0.1:37017 ns: admin.$cmd query: { whatsmyuri: 1 } at src/mongo/shell/mongo.js:147
<fwereade> rogpeppe, based on the description I have no problem with that
<dimitern> voidspace, nope :/
<jam> voidspace: I have not
<fwereade> rogpeppe, gonna be a beast to integrate it with core though
<rogpeppe> fwereade: i don't think so
<voidspace> dimitern: jam: IS have lots of mongo timeouts on a production server
<rogpeppe> fwereade: i've actually already made the changes
<fwereade> rogpeppe, sweet
<rogpeppe> fwereade: the first step is just to copy the entire repo into juju code (inside github.com/juju/juju/testing/charm-repo
<rogpeppe> )
<fwereade> rogpeppe, heh, that makes it easier then ;p
<jam> fwereade: wallyworld: "what is the "mroe subt" in the title" ?
<rogpeppe> fwereade: then change all tests to use testing.Charms rather than charmtesting.Charms
<voidspace> dimitern: jam: restarting the  the jujud-machine-0 service seems to have helped a bit anyway
<jam> wallyworld: also, can we call the document something other than "Juju Status"? Since that is a thing that we have which is not this ?
<rogpeppe> fwereade: subsequent changes can trim down the repo and make extra repos where appropriate
<rogpeppe> fwereade: the salient changes in that PR are right at the end, BTW
<fwereade> jam, heh, I think it's some mistargeted typing
<dimitern> voidspace, hmm.. it looks like a heavy load issue
<fwereade> jam, maybe mine
<wallyworld> jam: yeah fixed, cursor fail
<jam> thanks
<jam> wallyworld: "Juju Charm Status" comes to mind
<voidspace> dimitern: thanks, they're happy (well, less unhappy) for the moment
<wallyworld> sure
<rogpeppe> fwereade: i haven't got all tests compiling yet though - the main obstacle is finding a decent pair of identifiers when importing both github.com/juju/juju/testing and github.com/juju/juju/juju/testing :)
 * fwereade twitches gently
<rogpeppe> perhaps coretesting and jujutesting, but i'm not that happy about that
<dimitern> jujujujutesting and jujutesting - what's wrong with these :D
<dimitern> coretesting and corejujutesting
<dimitern> even better :)
<rogpeppe> dimitern: "core" isn't really a thing any more
<dimitern> juE3testing ?
<rogpeppe> dimitern: it would've worked if it was github.com/juju/juju-core
<dimitern> rogpeppe, heh, sorry - I'm just happy all my tests pass finally :)
<rogpeppe> dimitern: cool
<rogpeppe> dimitern: are commits still blocked on critical bugs, BTW?
<dimitern> rogpeppe, according to my handy bookmarklet, no: https://bugs.launchpad.net/juju-core/+bugs?field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&field.importance%3Alist=CRITICAL&field.tag=ci+regression+&field.tags_combinator=ALL
 * rogpeppe thinks that when the critical bugs are fixed, the 'bot should go through all the PRs it denied because of that, and retry them
<rogpeppe> dimitern: thanks
<rogpeppe> dimitern: ha, i tried to bookmark that, and discovered that not only had i bookmarked it, it was on my bookmarks bar as "juju-core blocks"!
<dimitern> rogpeppe, hehe, I assume you'r using firefox then
<rogpeppe> dimitern: nope, chrome
<dimitern> rogpeppe, ah, sorry chrome has this now as well yeah
<jam> wallyworld: so I made a bunch of comments, but I hope they feel constructive rather than critical. The only thing I'm actually concerned about is that we poll to find the current status, when to be useful it needs to be more "lively" than that.
<jam> (my service is down, wtf is wrong, "juju status", nope everything is ok for 5 more minutes until we wake up to check)
<TheMue> morning
<jam> morning TheMue
<wallyworld> jam: i think they are constructive, thank you. i didn't interpret as critical. i'd rather answer many questions and make a better spec. the charm calls status-set in a hook, so i'm not sure of a way other than polling where a status can be communicated, once the charm is up and running
<jam> fwereade: wallyworld: I'd like william's input here, maybe "juju-run" is the escape hatch? But I do think we need a way that essentially a running application (postgres) can trigger data being sent to the Juju API server.
<wallyworld> bbiab, dessert time
<jam> wallyworld: sounds yummy
<voidspace> dimitern: so, my final conclusion was that testing AssignPrivateIPAddresses with the mock server is not possible (in any useful way)
<voidspace> dimitern: so I'm mocking it
<dimitern> voidspace, because of the needed changes to RunInstances ?
<voidspace> dimitern: no, I got past that
<voidspace> dimitern: setting a mock server default-vpc as an initial parameter adds a network interface
<voidspace> dimitern: but with the mock server you can't get it to simulate error conditions
<dimitern> voidspace, yeah?
<dimitern> voidspace, for IPLimitReached etc ?
<voidspace> dimitern: correct, or address already assigned
<voidspace> dimitern: I've looked through the code
<voidspace> dimitern: and when it does work, you can't test what it did - because I don't have access to the EC2 instance to fetch the network interface back
<voidspace> dimitern: and it doesn't show on the Instance which I can reach via the mock server
<dimitern> voidspace, ok, so for now mocking is fine, and later we can extend the test server in goamz to reply as needed to allow better testing
<voidspace> dimitern: right
<jam> voidspace: dimitern: is there a reason to start with mocking rather than start with extending?
<jam> It feels like if we want to do is have it in the goamz test server
<jam> then we're doing extra work by also doing it via mocking
<voidspace> jam: well, we can make the error conditions testable - but with a black box test it still seems hard to test the happy path
<voidspace> jam: although that maybe just that I haven't found the right "trick"
<voidspace> jam: what the call to ec2Inst.AssignPrivateIPAddresses should do is add the requested IP to the NIC
<voidspace> jam: to get the NIC back I need access from the test to an authenticated EC2 instance to fetch the network interface
<voidspace> jam: and the auth credentials are buried
<jam> voidspace: doesn't that just mean that it records it enough such that listing it shows the IP?
<dimitern> jam, voidspace, considering we don't really implement yet the subnet range tracking of IPs, mocking it for now and extending goamz later seems a good step
<voidspace> jam: "listing it" is the issue
<jam> voidspace: dimitern: standup
<jam> didn't mean that to sound quite so much like an order :)
<voidspace> :-)
<voidspace> but it is
<voidspace> ;-)
<jam> voidspace: would you like to join us in the standup hangout now ?
<jam> :)
<fwereade> jam, wallyworld: yeah, I see juju-run as the way the system can feed backinto itself
<wallyworld> fwereade: isn't juju-run being deprecated for actions?
<jam> fwereade: wallyworld: is it just that we add that as a discussion point in the spec? Should we try to encourage use of that instead of polling ?
<fwereade> wallyworld, jam: "juju run" may well be
<wallyworld> polling is a safety net so to speak
<fwereade> wallyworld, jam: "juju-run" is not going anywhere
<jam> wallyworld: sure, but it gives us a much better "what should the polling rate be?" its just a backstop, and the actual event based triggers is via a different mechanism that triggers immediately.
<jam> fwereade: and fwiw, I don't see "juju run" as an ad hoc do-some-stuff that I need right now, ever going away.
<fwereade> jam, indeed
<fwereade> jam, although I would still rather consider it to be a shortcut to invoking an implicit action
<fwereade> jam, but I know that's some way away
<fwereade> jam, wallyworld: far more important is how we actually execute juju-run stuff anyway
<wallyworld> jam: fwereade: given juju-run executes in a context (I think), would it be "juju run status-set busy" or something?
<fwereade> wallyworld, yeah, that should do it
<jam> wallyworld: well, to be clear "juju run" is the user/client command
<fwereade> jam, good point
<jam> "juju-run" is a binary on the machine that is invoked in response to "juju run" via the API server, etc.
<jam> that potentially processes on that machine can also use
<jam> wallyworld: the fact that it is confusing is partly why we should clearly document it :)
<wallyworld> yes, i've not got a handle on what the charms would do. is there a juju run charm helper? or woud the charm just shell out and run "juju run blah"?
<jam> wallyworld: there is no ".jenv" file on the machines for "juju" the CLI to use
<wallyworld> or should i say jujud somthing
<jam> so you have to use this other thing that is almost-the-same
<fwereade> wallyworld, "juju-run"
<fwereade> jam, wallyworld: and fwiw "juju-run" was always meant to be a purely charm-side tool
<fwereade> jam, wallyworld: "juju run" was an outgrowth of that, and not a *particularly* necessary or helpful one, given the existence of "juju ssh"
<wallyworld> jam: agree about documenting things from a charmer's perspective, but i see that as subtley different to this requirements doc
<fwereade> jam, wallyworld: but people seem to like it, however hard it fucks with reproducibility of deployments
<jam> wallyworld: so the thing is, I see "status" as needing an immediate mode, and part of the doc is describing how status is going to work
<jam> wallyworld: so if the way to do immediate mode is "use juju-run" then it should be part of the doc (IMO)
<jam> its not so much telling them how to write their code, but how they can get something done
<wallyworld> jam: sure, ok. i saw the doc as describing what work needed to be done, and user doc would also come too, but perhaps separately, but i'll add it
<wallyworld> if nothing else, will make everything unambiguously clear, and make user doc easy
<rogpeppe> fwereade: any chance of a LGTM on https://github.com/juju/charm/pull/73 ? (we need two reviews)
<fwereade> rogpeppe, done, sorry, saw the existing one and moved on
<rogpeppe> fwereade: thanks
<wallyworld> jam: fwereade: i've added some comments to the status spec, need to do some editing, will revisit tomorrow
<jam> thanks wallyworld
<wallyworld> np, thanks for detailed review
<rogpeppe> fwereade, anyone else: this is the logical follow-on from the charm package change above: https://github.com/juju/juju/pull/1048
<rogpeppe> large but mechanical
<rogpeppe> mattyw: this is relevant for you too
<mattyw> rogpeppe, thanks very much
<mattyw> rogpeppe, I'm also ocr today so I guess it's relevant twice :)
<rogpeppe> mattyw: cool
<dimitern> mattyw, hey, as OCR would you take a look at http://reviews.vapour.ws/r/349/ please?
<mattyw> rogpeppe, couple of things from me on https://github.com/juju/juju/pull/1048
<rogpeppe> mattyw: ta
<mattyw> dimitern, don't worry - that is on my list - I started looking but decided I'd need to wake up a bit more first ;)
<dimitern> mattyw, cheers :)
<rogpeppe> mattyw: the repo is an exact (cp -r) copy of the repo from the charm.v4 repo. i'd prefer to keep it like that, rather than randomly applying changes at this point, because it's good to keep such a large PR as mechanical as possible IMHO
<mattyw> rogpeppe, I understand that. If you think those changes are valid can you do them in a follow up - or at least add a bug/ task somewhere so someone else can pick them up
<rogpeppe> mattyw: hopefully a bunch of the testing charms can be deleted or moved into repos for specific packages
<rogpeppe> mattyw: are juju-core bugs still being tracked in launchpad?
<mattyw> rogpeppe, afaik yes
<natefinch> rogpeppe: yes
<voidspace> dimitern: http://reviews.vapour.ws/r/351/diff/#
<voidspace> dimitern: if you have time
<voidspace> dimitern: bike shedding on error names welcomed
<rogpeppe> mattyw: responded
<dimitern> voidspace, already looking :)
<natefinch> voidspace: I voted for my color
<rogpeppe> voidspace: FWIW, error values should always be prefixed with "Err"
<voidspace> rogpeppe: thanks
<natefinch> rogpeppe: that was the color I preferred as well ;)
<rogpeppe> voidspace: and aren't capitalised
<rogpeppe> voidspace: (the error text, that is)
<voidspace> rogpeppe: ok, cool
<voidspace> I thought you meant the names weren't capitalised, which seemed odd
<rogpeppe> voidspace: also, when specific errors are returned, they should be compared with == (or gc.Equals) not DeepEquals
<voidspace> rogpeppe: cool, I wasn't sure
<rogpeppe> voidspace: and it's worth comparing with c.Assert(errors.Cause(err), gc.Equals, ErrFoo) so that the errors can be wrapped if desired
<voidspace> rogpeppe: we won't wrap here as they'll be used by the next level up to construct a user facing error
<voidspace> rogpeppe: should I / can I use errors.Cause anyway?
<rogpeppe> voidspace: nonetheless, it's a good general policy - you might wrap inside the implementation itself
<rogpeppe> voidspace: yeah, i think so
<voidspace> kk
<voidspace> changes maded
<voidspace> *made
<voidspace> natefinch: I don't like your colour
<natefinch> voidspace: that's because you put a u in it ;)
<voidspace> natefinch: which only improves it
<natefinch> voidspace: but does it improuve it?
<voidspace> natefinch: only
<voidspace> natefinch: I mean, if you want consistency in your language it should be culor or even kulor
<natefinch> voidspace: sounds double plus good
<voidspace> :-)
<natefinch> voidspace: not to double up on the paint job, but is "address" really needed in those names?  Pretty sure we know we're not talking about intellectual property :)
<dimitern> voidspace, reviewed
<voidspace> natefinch: hmmm... I tend to talk about IP addresses and less so IPs
<voidspace> natefinch: but I don't care overly
<voidspace> dimitern: thanks
<voidspace> dimitern: why test with empty address?
<voidspace> dimitern: we're unlikely to call it with an empty address - and do you want parameter checking inside our implementation
<voidspace> dimitern: and if we'll rely on ec2 parameter checking, it isn't actually a different case
<dimitern> voidspace, 1) because it can happen, and the code doesn't seem to handle this; 2) as a reminder if we change the behavior later
<voidspace> dimitern: we'll get back InvalidParameterValue
<voidspace> dimitern: which we do handle
<voidspace> dimitern: which is why I say I don't think that's a different case
<dimitern> voidspace, hmm, that's true yeah - the test server doesn't handle this, but it will
<voidspace> dimitern: I can duplicate the test if you think it's important
<dimitern> voidspace, well, at least add a test case for empty address inside the test for ErrIPAddressUnavailable
<voidspace> ok
<dimitern> voidspace, thanks!
<voidspace> so I have a return nil erroneously in the code - meaning it can't work
<voidspace> but the tests checking it does work (exercising the unreachable return below) pass!
<voidspace> and those tests are definitely being run
<voidspace> ah no
<voidspace> it's a remnant of old code and the second return is unneeded
<voidspace> dimitern: rogpeppe: "in two sentence" error messages you wouldn't capitalise the second sentence?
<rogpeppe> voidspace: for example?
<voidspace> dimitern: rogpeppe: as in "unexpected AWS response. instance not found" rather than "... Instance not found."
<rogpeppe> voidspace: we wouldn't usually use a full stop, but a colon
<voidspace> rogpeppe: that avoids the problem
<rogpeppe> voidspace: unexpected AWS response: instance not found
<voidspace> you know your approach is basically sound when all the review comments are about the wording of your error messages ;-)
<voidspace> (not quite all to be fair)
<voidspace> natefinch: Errorf without formatting passes go vet fine
<voidspace> natefinch: I'm happy to switch to errors.New anyway
<voidspace> natefinch: go vet runs as a pre-push hook
<voidspace> dimitern: network.NewAddress is worse because I have to pass a Scope
<voidspace> dimitern: so I replace network.Address{Value:"foo"} with network.NewAddress("foo", network.ScopeUnknown)
<voidspace> dimitern: which I can do
<dimitern> voidspace, ah, fair point
<rogpeppe> mattyw: does PR #1048 look ok to you now?
<rogpeppe> mattyw: (i'd like to land it soon if possible, before it becomes conflicted)
<mattyw> rogpeppe, good call, looking again
<mattyw> rogpeppe, did you rebase it down to 1 commit?
<rogpeppe> mattyw: yes
<rogpeppe> mattyw: was that bad?
<voidspace> dimitern: so I've fixed everything from the reviews except your suggestion to add the ip address and instance id to the error  messages
<voidspace> dimitern: my reasoning was that this information is known to the caller, so they can annotate the error if needed
<voidspace> dimitern: I'm happy to add it there if you prefer
<mattyw> rogpeppe, not normally, but it means I have to look through the whole thing again to see what you changed :)
<mattyw> rogpeppe, seems like it was the package docs and that's it
<rogpeppe> mattyw: i changed just the comment
<rogpeppe> mattyw: yeah
<dimitern> voidspace, my reasoning was - this will end up in the log file at some point, so let's make it comprehensive
<voidspace> dimitern: ok, I'll add it
<dimitern> voidspace, thanks! I'll have another look
<mattyw> rogpeppe, and you raised lp:1389656
<rogpeppe> mattyw: yes
<mattyw> so instead of printing a nice message about my bug number mup decides to leave - trying not to take it personal
<voidspace> dimitern: done and pushed
<mattyw> rogpeppe, lgtm, land at your convenience
<rogpeppe> mattyw: ta!
<mattyw> ashipika, did you get your prs and reviews sorted?
<ashipika> mattyw: editing code.. will submit a bit later..
<ashipika> mattyw:  fwereade had some useful comments.. as always
<dimitern> voidspace, lgtm
<voidspace> dimitern: cool
<voidspace> dimitern: after lunch I'll look at goamz test server
<dimitern> voidspace, awesome!
<rogpeppe> i'm presuming that this juju-core test failure is just "one of those things" http://juju-ci.vapour.ws:8080/job/github-merge-juju/1192/console
<rogpeppe> natefinch: have you seen that failure mode?
<rogpeppe> fwereade: this is what i'm thinking of for the in-memory charm testing stuff: http://paste.ubuntu.com/8836186/
<rogpeppe> fwereade: that would be defined in charm.v4/testing
<rogpeppe> fwereade: there could be additional constructors if desired, to make charms with more easily specified relations or whatever
<rogpeppe> fwereade: or additional fields in the CharmSpec struct as desired
<rogpeppe> bodie_: ^
<rogpeppe> can someone please fix the landing 'bot please; i'm seeing "write error: No space left on device"
<rogpeppe> mgz: ^
<rogpeppe> http://juju-ci.vapour.ws:8080/job/github-merge-juju/1194/console
<natefinch> rogpeppe: sorry was away
<fwereade> rogpeppe, that works for me I think
<sinzui> natefinch, perrito666: I don't know how to verify that the win-agents in streams are good. I hoped I could use add-machine to manually provision a windows instance to verify the machine agent was installed and it called home
<TheMue> dimitern: thanks for explanations
<ericsnow> perrito666: FYI, I think I've covered your entire restore patch at a high level now :)
<wwitzel3> ericsnow: no tosca call today, so standup? :)
<perrito666> ericsnow: is findfile landed? I am already using it :p
<ericsnow> perrito666: working on it
<natefinch> sinzui: I would hope that add-machine would work
<sinzui> natefinch, consider that add-machine wants ssh. I happen to have an win image with ssh, but even that failed
<natefinch> sinzui: ahh hmm  yes
<rogpeppe> fwereade: cool
<rogpeppe> bodie_: here's what i ended up with: http://paste.ubuntu.com/8837430/
<natefinch> sinzui: can you ssh there w/o a password from your machine normally?
<sinzui> natefinch, yes
<sinzui> natefinch, the juju env and the win machine are using the same key too
<natefinch> sinzui: hmm weird
<rogpeppe> sinzui: the landing bot seems to be broken, if that's under your control
<bodie_> rogpeppe++
<rogpeppe> bodie_: cool, thanks
<katco> rick_h_: https://jujucharms.com/solutions, did we lose our count of # deploys?
<katco> those 0's make me sad :(
<rick_h_> katco: yes, it's a new store and we don't have any counts atm. we'll either try to backfill or start new or I'm not sure yet.
<katco> rick_h_: cool. looks great btw. nice work to you and your team :)
<rick_h_> katco: thanks, yea lots of kinks to work out but glad to get it out the door
<katco> it has that new software smell :)
<rick_h_> hah
<bodie_> rogpeppe, what I was imagining was CharmSpec as an interface implemented by a set of pre-baked testing charms, or the user can implement by composing requirement functions (must have Actions.yaml for X action, must have config with A and B parameters) that way the user never has to implement these things, they're a toolkit for generating fake charms
<bodie_> rogpeppe, but that's probably significantly more work without a lot more reward
<rogpeppe> bodie_: in a call, will get back to you
<sinzui> mgz, can you look into the landing bot?
<TheMue> alexisb: ping, I'm available
<ericsnow> jam: would you mind taking a look at a couple of mattyw's reviews?  http://reviews.vapour.ws/r/342/ and  http://reviews.vapour.ws/r/346/
<ericsnow> natefinch: I've addressed your comments on http://reviews.vapour.ws/r/343/
<mattyw> ericsnow, for the record you can get anyone else to review them as well I think.
<voidspace> someone refactored the test infrastructure so my build failed
<voidspace> goddamthem
<ericsnow> mattyw: yeah
<ericsnow> mattyw: I realized I had never followed up with a review mentor so I figured I would try it this time :)
<natefinch> ericsnow: looks good.... though the else in that if statement is spurious :)
<ericsnow> natefinch: it's visually innocuous while still conveying the right meaning :)
<ericsnow> natefinch: however, in this case I agree :)
<ericsnow> natefinch: I could use a switch <0.5 wink>
<mattyw> fwereade, ping?
<fwereade> mattyw, pong
<mattyw> folks - is anyone waiting for me to review code that I promised to do and haven't yet?
<rogpeppe> bodie_: i think that what i'm suggesting is still compatible with your thoughts there
<rogpeppe> bodie_: it's straightforward to add new constructors that make a testing.Charm, with whatever higher level specification we think might be useful
<bodie_> rogpeppe, agree but maybe the members of CharmSpec shouldn't be exported, is my thought
<rogpeppe> bodie_: why not?
<bodie_> probably a future change
<rogpeppe> bodie_: i don't see that that's limiting
<rogpeppe> bodie_: it's just one possible set of constructor arguments for creating a new testing Charm
<bodie_> I see, so that would give the package user the ability to use this form and write it by hand
<bodie_> then, move toward a more automatic version if needed
<rogpeppe> bodie_: yes
<rogpeppe> bodie_: the two forms aren't incompatible with one another
<rogpeppe> bodie_: the main problem i've just come across (again) is that we can't currently generate a YAML marshaled form of the metadata from a charm.Meta value
<rogpeppe> bodie_: so if we want to specify relations programmatically (for example) we have a bit of a problem.
<rogpeppe> bodie_: there are two ways forward here - either implement a proper GetYAML method on *charm.Metadata, or (the cheat's way) just use a different representation when generating charms, then marshal it before reading it
<rogpeppe> bodie_, fwereade, anyone else: https://github.com/juju/charm/pull/74
<bodie_> rogpeppe, lgtm
<rogpeppe> bodie_: ta!
<bodie_> :)
<bodie_> rogpeppe, why can't *charm.Meta be marshaled by yaml?
<rogpeppe> bodie_: it can, but it doesn't produce anything like a metadaya.yaml file
<bodie_> ah
<bodie_> maybe that's the problem
<bodie_> but I guess you can't just deprecate metadata.yaml
<bodie_> er, the current format, anyway
<rogpeppe> bodie_: indeed, it's about the oldest file format we have
<rogpeppe> bodie_: it predates the Go version of juju
<bodie_> even if you did, you'd still need to have a transformer for the unmarshaled form to the new format
<rogpeppe> bodie_: yup
<rogpeppe> bodie_: we actually do marshal the metadata directly into JSON in various places.
<bodie_> rogpeppe, so if you use the "cheat's way", then you are really laying the groundwork for that transformer ;)
<rogpeppe> bodie_: i'm not sure
<rogpeppe> bodie_: thing is, we'd probably not choose the current data format as a file format by choice, as it has redundancy in various places
<rogpeppe> bodie_: for instance, relations are keyed by name but the name of the relation is also in the value
<bodie_> heh
<voidspace> g'night all
<menn0> wallyworld: here's that PR to separate state-based upgrade steps from API-based upgrade steps. http://reviews.vapour.ws/r/355/
<wallyworld> ok, ta, will look soon
<menn0> wallyworld: there's still another PR to come which changes how upgrade targets are handled (as discussed in email)
<wallyworld> ok
<sinzui> wallyworld, Its been a bad day. I hope you or someone can give some answers to the speculation and testing I have done in https://bugs.launchpad.net/juju-core/+bug/1389807
<mup> Bug #1389807: stable juju cannot bootstrap because it selects the devel stanza in index.json <landscape> <metadata> <regression> <theme-oil> <juju-core:Triaged> <https://launchpad.net/bugs/1389807>
<wallyworld> sinzui: i'm trying to ramp up now
<wallyworld> what's the tl;dr?
<wallyworld> i'm reading the bug report
<sinzui> comment 4 https://bugs.launchpad.net/juju-core/+bug/1389807/comments/4
<wallyworld> sinzui: yes, released needs to be first
<wallyworld> since in 1.20 there was no discrimination on stream
<wallyworld> when parsing the index file and choosing a matching stanza
<sinzui> wallyworld, okay, I am glad you agree with my testing. I will prep for the validation and do you agree we can rewrite the content so that we don't need to wait for beta1?
<wallyworld> i am pretty sure, yes, 99.9%
<wallyworld> 1.20/1.18 looked for a matching stanza based on cloud details
<wallyworld> in there are devel, released,proposed etc - they will all have the same cloud details
<wallyworld> so released needs to go first
<wallyworld> it seems obvious now
<wallyworld> in hindsight
<wallyworld> i think it should be tested though to be 100% sure
<sinzui> wallyworld, well that pastebin is from a  reproduction of a test from Saturday...I failed to notice the switch in the details
<sinzui> oh...
<sinzui> wallyworld, actually, I can do something right now. I control the CPCs. I will fix the order and make the CPCs happy
<wallyworld> ok, i'll continue reading the bug etc to make sure my thoughts are correct, i've only just skimmed so far
<wallyworld> i need to understand why clouds without a mirror are the ones affected
<sinzui> wallyworld, yes, please, wait and be sure. My best idea was to stop the release last night and wait to update streams.canonical.com until moew qa team were about
<wallyworld> sinzui: the bug says private clouds - but private clouds will have their own metadata though, so i need to understand why they are reaching out to streams.canonical.com
<sinzui> wallyworld, no so. a lot of landscape and oil testing are open, using public streams
<sinzui> wallyworld, they cannot use the mirror, so the read the first item in index.json
<wallyworld> yeah, you are right, i was thinking of private clouds behind a firewall
<sinzui> wallyworld, and I was think that is how stakeholders were testing myself
<sinzui> s/think/thinking/
<wallyworld> sinzui: i fear that putting the released stanza first may not work on ppc
<wallyworld> that approach relies on json deserialisation and map ordering
<sinzui> wallyworld, :(
<wallyworld> it might work, needs to be tested
<wallyworld> with the compiled ppc binaries
<wallyworld> i'll keep digging, see if anything else comes to light
<wallyworld> sinzui: one nuclear option is to use a new name for the index file for 1.21 onwards, so we publish 2 index files
<sinzui> wallyworld, I like that option
<wallyworld> 1.21 would look for index2.json and fall back to index.json
<wallyworld> if index2.jsin wasn't there
<wallyworld> the nice bit would be that only that 1 extra file is needed
<sinzui> wallyworld, that would require beta1. I hope ppc testing will let me change the ordering to continue releasing alpha3
<wallyworld> yes, it would require a beta 1
<wallyworld> sinzui: we will need to do the index2 option anyway, because if as i suspect map ordering is an issue, it will break on amd64 if we ever compile 1.20 with go 1.3
<wallyworld> maybe we won't ever do that
<sinzui> wallyworld, json via js is officially ordered. I wrote the mirror generation with Pythons OrderedDicts to be certain I serialised exactly what I put in it
<sinzui> I hope go's json is ordered
<wallyworld> sinzui: I've learnt to never assume anything with Go
<sinzui> yeah, this issue comes up every other day
<wallyworld> sinzui: a quick ppc test would be to run validate-tools on ppc using the reordered index
 * sinzui added env to stilson-6
<menn0> wallyworld: can we chat about the upgrade steps review? I want to make sure I understand your comments.
<wallyworld> menn0: sure, but i need to keep an eye on irc
<wallyworld> https://plus.google.com/hangouts/_/canonical.com/tanzanite-stand
<sinzui> oops, I just tested aws which is mirrored.  ppc likes it BTW
<wallyworld> \o/
<wallyworld> i still fear ppc won't like the non mirrored case
<sinzui> wallyworld, we are about to find out. I am going to attempt an aws bootstrap first using the true aws location followed by the mirror
<wallyworld> ok
<sinzui> wallyworld, I would normally use my streams and mirrors on people.canonical.com, but stilsons cannot see it. It can see aws
<wallyworld> ah
<wallyworld> sinzui: regardless, if it works, it is still built on a fragile foundation and it people pull 1.20 source and recompile it may very well break, so i think index2.json will be needed for beta1; this will just buy time till then
<sinzui> wallyworld, we loose. I my first attempt setting the real location shows that devel was selected even though released is first in index.json
<wallyworld> yeah, not surprised
<davecheney> d sorts before r
<davecheney> :(
<wallyworld> :-(
<davecheney> so does alpa
<davecheney> and beta
<davecheney> ZEVELOPMENT!
<wallyworld> davecheney: well, it is json unmarshaling into a mao, then then we iterate the map, so no assumptions can be made at all
<davecheney> crap
<wallyworld> sinzui: i can add support for index2.(s)json files to be used, when were you thinking of releasing beta1?
<sinzui> wallyworld, officially tomorrow!
<wallyworld> sinzui: i can have a fix done today
<sinzui> wallyworld, but I can wait till Friday. Lets not rush.
<wallyworld> i can do a fix and it can be tested
<sinzui> wallyworld, davecheney this is the official proof that we ppc wont be happy http://pastebin.ubuntu.com/8842960/
 * sinzui adds link the bug
<davecheney> sinzui: poop
<sinzui> wallyworld, I wont release tomorrow because I need to change juju-release-tools. It needs to ensure index.json is preserved for historic juju.
<wallyworld> sinzui: sure, np. i want to get the fix done asap to give as much time as possible for testing etc
<sinzui> thank you very much wallyworld. I am going to drink now because it is dinner and I want to feel good that we have a plan
<wallyworld> sure, enjoy
#juju-dev 2014-11-06
<perrito666> ericsnow: before I go to sleep and forget about this (its like 2:30 AM here) please add a link to the patch to your last comment and an example of the Version output, I just made a change very similar to your suggestion to accomodate version and need to know how to know if we are above/below version N and since I am in it I can review your patch for archive data so it gets merged, or alternatively have a separate branch
<perrito666> with this fix for when you are merged
<perrito666> peace out
<ericsnow> perrito666: k
<ericsnow> perrito666: sleep well
<wallyworld> axw: hi, interrupt time. we've come up with a list of achievable bugs to burn down for 1.21. we want to get these fixed this week. bug 1388860 and bug 1389037 relate to ec2 availability zones. can i ask you to please take a look?
<mup> Bug #1388860: ec2 says     agent-state-info: 'cannot run instances: No default subnet for availability zone:       ''us-east-1e''. (InvalidInput)' <deploy> <ec2-provider> <network> <juju-core:Triaged> <https://launchpad.net/bugs/1388860>
<mup> Bug #1389037: provider/ec2: try alternative AZ on InsufficientInstanceCapacity error <ec2-provider> <juju-core:Triaged> <https://launchpad.net/bugs/1389037>
<wallyworld> the bugs against beta1 milestone are what we're going to fix
<axw> wallyworld: no worries
<wallyworld> thank you
<menn0> wallyworld: if you have a change could you look at this again? http://reviews.vapour.ws/r/355/diff/
<menn0> wallyworld: this takes in to account the things we discussed
<menn0> wallyworld: for the most part, things worker out simpler and clearer
<wallyworld> menn0: sorry, was otp, looking
<wallyworld> menn0: also, what's the status of bug 1382751
<mup> Bug #1382751: non subordinate container scoped relations broken  <regression> <relations> <subordinate> <juju-core:Triaged by menno.smits> <https://launchpad.net/bugs/1382751>
<wallyworld> we have this as needing to be fixed for 1.21
<wallyworld> and we'd like all fixes done by this week
<menn0> wallyworld: I haven't looked in to it
<menn0> wallyworld: it was going to be my next thing
<menn0> wallyworld: i'm about to EOD but I can make it my top priority tomorrow
<wallyworld> menn0: ok, thanks, see how you go with it.  we are aiming to get beta1 out end of week if possible
<wallyworld> sure, ty
<wallyworld> lmost done review, looks good
<menn0> wallyworld: regarding the upgrades PR, I've just had an idea.
<wallyworld> shoot
<menn0> wallyworld: instead of having Steps() and StateSteps() on Operation
<menn0> wallyworld: what about defining 2 separate lists of operations
<menn0> wallyworld: one for state based steps and one for the rest
<menn0> wallyworld: that could simplify things further
<menn0> wallyworld: and also i can see the state based stuff eventually happening in a separate worker
<menn0> wallyworld: so having a separate list seems cleaner if that happens
<menn0> wallyworld: I guess it doesn't matter too much at this stage
<wallyworld> yeah, main goal from first review was separate lists and contexts
<wallyworld> i think what's there works, but if it can be improved....
<menn0> wallyworld: I'll think about it. I won't land the current PR today anyway (and maybe not tomorrow depending how sorting out this bug goes)
<wallyworld> ok, sounds good
<menn0> wallyworld: thanks for the reviews
<menn0> wallyworld: i'm off now (local Python meetup)
<wallyworld> menn0: thanks, have fun, you got a +1
<jam> anastasiamac: ping
<wallyworld> jam: i talked to anastasiamac about the numactl stuff - the solution is being revised, so what's there is obsolete
<jam> sure
<anastasiamac> jam,wallyworld: thank u for ur time! u r  amazing :-0
<wallyworld> jam: tl;dr; original intent was to general the same script each time, and the script would use bash as per the bug to detect numa, no need for core to detect numactl. but the mingo doc seems to suggest that numactl can be used to start mongo all the time, even when not needed. so elmo will be asked to see if he's ok with that
<wallyworld> this will simply things greatly
<jam> wallyworld: yeah, I think we'd still want the "is numactl available" which is fine, but I feel like the bug is probably asking us to install it on numa architectures
<jam> which might just mean "always install it, and always call mongo with it"
<wallyworld> jam: your last line is the current thnking
<wallyworld> trivial to install
<wallyworld> and if no ill effects on non numa arches, then no harm
<wallyworld> we already apt intall mongo, just would be adding another small pkg to that
<wallyworld> axw: thanks for the fixes \o/
<axw> wallyworld: nps, gotta back port now right?
<wallyworld> yeah
<wallyworld> both
<wallyworld> axw: i'm off to soccer, back later, you can just self approve those backports
<axw> wallyworld: will do
<jam> dimitern: morning
<dimitern> morning jam
<jam> dimitern: I wanted to get your input on https://bugs.launchpad.net/juju-core/+bug/1388860
<mup> Bug #1388860: ec2 says     agent-state-info: 'cannot run instances: No default subnet for availability zone:       ''us-east-1e''. (InvalidInput)' <deploy> <ec2-provider> <network> <juju-core:In Progress by axwalk> <https://launchpad.net/bugs/1388860>
<jam> I sent an email earlier
<dimitern> jam, yeah, I saw that and replied a few minutes ago
<jam> dimitern: looks like axw is doing that already
<jam> dimitern: http://reviews.vapour.ws/r/359/
<axw> a fix has landed on master already, just skipping over them for now
<dimitern> jam, axw, awesome!
<dimitern> jam, I've managed to land the juju-br0 patch yesterday, but I still need to backport it for both 1.20 and 1.21
<dimitern> jam, and then I'll have a look at the "multiple networks" bug for maas
<jam> axw: will you be porting your fix to 1.21 ?
<axw> dimitern: nice work on maas, glad to see that network stuff working nicely
<axw> jam: yes, doing that right now
<dimitern> axw, cheers, yeah it's getting better
<jam> axw: I'm slightly worried about capitalization being an issue, that sort of thing really looks fragile
<jam> otherwise LGTM for 1.21
<axw> jam: I'm starting to wonder whether we should just try on all AZs regardless of the error
<axw> it's proven to be a little fragile in general
<jam> axw: as in, if we get an error just go to the next one ?
<axw> yep
<axw> perhaps we could pick certain errors to bail on, rather than the other way around
<jam> wallyworld: anastasiamac: still around ?
<anastasiamac> jam: wallyworld @ soccer, m about to go. why?
<jam> anastasiamac: I was thinking about the numactl stuff a bit more, and I think we need a flag
<jam> doing always everywhere is a pretty big cahnge
<jam> change
<jam> and we can easily be doing it wrong
<jam> with a flag, we can at least disable/enable it
<jam> I think I'd be happiest with "use it if its there and not disabled"
<jam> and maybe the first one is to not install the package by default
<jam> so people can go install it if they want it
<anastasiamac> jam: from my understanding of flags, they reflect a preference
<anastasiamac> the cmd numactl wrap is not - it's kind of needed based on hardware...
<jam> anastasiamac: "based on hardware" at the very least
<anastasiamac> jam: mayb completely off but most of this "feeling" is based on
<anastasiamac> jam: http://docs.mongodb.org/manual/administration/production-notes/#production-numa
<jam> anastasiamac: yeah, I'm on that page as well
<anastasiamac> jam: m happy not to run all the time
<anastasiamac> jam: my preference would be to run when needed: on NUMA
<anastasiamac> jam: irrespective of # of nodes
<jam> anastasiamac: so I certainly want us to DTRT according to our best understanding of what's going on
<jam> but if that is 100%, then we want to have a way for a user to tell us "you're doing it wrong"
<jam> s/is/is not 100%/
<anastasiamac> jam: :-) under what circumstance, if on NUMA, a user would not want to run with numctl wrap?
<anastasiamac> jam:
<jam> anastasiamac: reading here: http://blog.jcole.us/2010/09/28/mysql-swap-insanity-and-the-numa-architecture/
<jam> actually every juju installation
<jam> the reason you have numactl
<jam> is for cases where Mongo is consuming >50% of the memory
<jam> but *juju* mongodb doesn't get that big
<jam> the machine isn't "a dedicated mongodb machine"
<anastasiamac> jam: have to go to c kids, back soon-ish
<jam> anastasiamac: later
<mattyw> morning everyone
<anastasiamac> jam: no reason
<anastasiamac> jam: was not looking
<jam> :)
<jam> so digging into it, the reason Mongo wants the numa stuff is because it thinks it is going to use more memory than one node has access to, and their is a swapping bug on Linux associated with that case.
<jam> but if Mongo is using < 1 nodes worth of RAM, it will actually perform *better* if you don't use numactl --interlace=all
<jam> since it won't be trying to fetch from non-local memory.
<anastasiamac> jam:wow :-)
<anastasiamac> jam: so either my bug is not a bug
<anastasiamac> jam: or we just make it an option (flag) and let user set it (don't wrap by default)?
<anastasiamac> jam: bug 1350337
<mup> Bug #1350337: Juju DB should use numactl when running mongo on multi-socket nodes <hours> <maas> <mongodb> <juju-core:Triaged by anastasia-macmood> <https://launchpad.net/bugs/1350337>
<jam> yeah, I'm responding there
<anastasiamac> jam: excellent! thnx :-)
<jam> anastasiamac: can you dig into whether we have a way to get mongodb to be happy without numactl ?
<jam> Like are they directly touching libnuma ?
<anastasiamac> jam: k... in couple of hrs :-)
<jam> anastasiamac: https://github.com/mongodb/mongo/blob/master/src/mongo/db/startup_warnings_mongod.cpp
<jam> it just does a "does /sys/devices/system/node/node1" exist
<jam> and then tries to read /proc/self/numa_maps
<jam> and looks for a line that isn't "interleave"
<jam> axw: if you're around, does https://bugs.launchpad.net/juju-core/+bug/1388860 need to do anything on 1.20? Or did the round-robin behavior only land in 1.21 ?
<mup> Bug #1388860: ec2 says     agent-state-info: 'cannot run instances: No default subnet for availability zone:       ''us-east-1e''. (InvalidInput)' <deploy> <ec2-provider> <network> <juju-core:Fix Committed by axwalk> <https://launchpad.net/bugs/1388860>
<axw> jam: can't remember, I'll check
<jam> axw: thanks
<axw> jam: yeah we'll need to do it for 1.20 too
<jam> axw: it may be the 1.20 won't have any default-vpc support, but retrying on round-robin seems good to have there
<axw> jam: ah, because it's using an older version of the EC2 API? could be
<axw> agreed
<jam> axw: right, it is probably just using ec2-classic
<jam> dimitern: do you know if VPC (default-vpc) support landed in 1.20 ?
<jam> axw: I just got an EC2 instance on "54.171.140.0"
<jam> I didn't think you could use .0
<jam> heh, it works
<davecheney> jam: it'll work if the netmask isn't a /24
<axw> jam: I'll just test with 1.20 to make sure. I didn't think we were making any calls yet that triggered the VPC support, but I've probably missed something
<dimitern> jam, the support is there, but unused
<dimitern> axw, setting a SubnetID in the RunInstances params struct will trigger the VPC-aware API version to be run, otherwise we use (i.e. EC2 emulates) the classic mode
<axw> right and we're not setting SubnetID
<axw> so I should expect this to fail
<dimitern> axw, what error are you getting?
<axw> dimitern: I'm checking whether or not "No default subnet for availability zone" occurs in 1.20 too
<axw> (it does)
<TheMue> morning
<voidspace> morning all
<voidspace> dimitern: what's the region with a default vpc?
<jam> dimitern: voidspace: standup ?
<jam> voidspace: southeast ap 2 IIRC
<dimitern> jam, omw
<voidspace> jam: omw
<voidspace> jam: thanks
<jam> voidspace: ap-southeast-2
<dimitern> TheMue, voidspace, a quick review of the LXC/KVM bridge fixes for MAAS backported to 1.21? http://reviews.vapour.ws/r/362/diff/
<TheMue> *click*
<TheMue> dimitern: looks well known from the latest change. any special differences because it's a backport where I should take an extra look?
<wallyworld> appreciate a review of a critical 1.21 fix if some poor soul wants to share the pain http://reviews.vapour.ws/r/363/
<dimitern> TheMue, no new changes, in fact some code was not needed for 1.21
<dimitern> wallyworld, looking
<wallyworld> ty :-)
<TheMue> dimitern: ok, but it also does no harm.
<wallyworld> you'll be sorry you offered
<wallyworld> simplestreams
<dimitern> hehe
<dimitern> wallyworld, btw the diff on RB is somehow screwed
<wallyworld> oh
<wallyworld> ket me look
<dimitern> wallyworld, I got hit by this just minutes ago, because proposing PRs not against master, but 1.21 or 1.20, makes the RB automation pick the wrong parent/branch/tracking-branch apparently
<dimitern> ericsnow, ^^
<wallyworld> dimitern: diff looks ok
<wallyworld> i proposed against master, will backport
<wallyworld> the "errors" are due to files deleted
<wallyworld> if the whole file is deleted, it gets confused
<dimitern> wallyworld, if it was deleted it will display it ok, but I got the same error and traceback for existing files
<wallyworld> hmmm, i just hit View Diff and it looks fine for me
<wallyworld> http://reviews.vapour.ws/r/363/diff/#
<wallyworld> could always review in the pr if needed
<dimitern> wallyworld, hmm.. weird, now it shows less errors; anyhow, I'll go on with the review
<wallyworld> ty
<jam> voidspace: I'm back if you want to chat in juju-sapphire
<dimitern> wallyworld, reviewed
<wallyworld> dimitern: awesome, ty
<dimitern> TheMue, voidspace, ?
<wallyworld> dimitern: curious - is that formatting suggestion part of our guidelines, or more idiomatic go? i've tended to always use the style as written in the pr personally. i'll make the change, was just curious
<voidspace> jam: omw - sorry
<TheMue> coming, wife needed me
<voidspace> TheMue: the guide I'm following for maas
<voidspace> TheMue: https://insights.ubuntu.com/2013/11/15/interested-in-maas-and-juju-heres-how-to-try-it-in-a-vm/
<TheMue> voidspace: thx
<TheMue> voidspace: ah, a nice one
<dimitern> wallyworld, it helps me personally to read the code better
<wallyworld> np
<wallyworld> sadly you'll not like most of my other code :-)
<dimitern> wallyworld, i'll take what i can get :)
<wallyworld> so will I :-)
<dimitern> TheMue, last backport - for 1.20, if you can have a look? https://github.com/juju/juju/pull/1062 (RB is not configured for 1.20 apparently, so if you can review the PR please)
<TheMue> dimitern: just opened it a sec ago :)
<dimitern> TheMue, thanks! there are a few more changes, but not to the logic - just 1.20 stuff
<TheMue> dimitern: currently RB failed :( hmm, trying again
<dimitern> TheMue, automatic RB integration for 1.21 and 1.20 is broken
<TheMue> dimitern: argh, now I've seen you already mentioned it. ok
<dimitern> TheMue, :) np
 * dimitern needs to step out for 1/2h, bbl
<TheMue> dimitern: done
<mattyw> dimitern, can I ask you a question about charm urls and charm upgrades? specifically if you're on say ubuntu-0 and you upgrade to ubuntu-1. Will ubuntu-0 still exist in state?
<voidspace> yay, internet back
<voidspace> I was just about to give up - I'd got as far as maas running with a node that failed to commission due to lack of internet
<TheMue> voidspace: running your local maas?
<voidspace> TheMue: yep
<voidspace> TheMue: the guide I linked to earlier "just worked" for me
<voidspace> TheMue: although now I need to set the power options for the node so MAAS can boot it
<TheMue> voidspace: yes, seems to be the best solution
<TheMue> voidspace: most control
<voidspace> TheMue: my node just went from "Commissioning" to "Ready"
<voidspace> commissioning failed due to lack of internet before
<voidspace> TheMue: the one thing I had to do was configure the cluster
<TheMue> voidspace: which maas are you running?
<voidspace> My maas controller ip address is 172.16.0.2 - so I configured the "router" as 172.16.0.1 and the dynamic dhcp range 172.16.0.3-128 and the static range 129-255
<TheMue> voidspace: 1.7?
<voidspace> TheMue: yes - 1.7.0~rc1
<voidspace> TheMue: from the devel ppa
<TheMue> voidspace: good, will then spend some disk space for it ;)
<dimitern> mattyw, sorry, I'm back now
<dimitern> mattyw, I'll check the code, since it's been a while
<mattyw> dimitern, looking at the code it seems like they stay around
<mattyw> dimitern, but I'm not sure if that's by design or just luck
<dimitern> mattyw, you mean older versions of charms post-upgrade?
<mattyw> dimitern, correct
<dimitern> mattyw, it kinda depends whether they've come from the store or local repo
<voidspace> TheMue: bootstrapping juju to a MaaS node, pxe booted by MaaS
<voidspace> so far so good...
<TheMue> voidspace: great
<voidspace> TheMue: only took a month or so to get to this point...
<TheMue> voidspace: *lol*
<ericsnow> dimitern: re: reviewboard and 1.20, I only see one request from you for a PR that github reported as being based on 1.20: PR #1062
<ericsnow> dimitern: is that the one where RB set the branch to master?
<ericsnow> dimitern: (review request #365)
<voidspace> TheMue: http://pastebin.ubuntu.com/8853137/
<voidspace> bootstrap completed
<dimitern> ericsnow, that's the one
<ericsnow> dimitern: I was worried that the code was busted for the non-master branch case, but it should already be doing the right thing :(
<TheMue> voidspace: looks good
<dimitern> ericsnow, well, I had issues with 1.21 as well
<ericsnow> dimitern: I'll look into it when I get a chance
<ericsnow> dimitern: ah, okay
<ericsnow> dimitern: thanks for letting me know
<dimitern> ericsnow, the diff generated by the RB hook was missing every file; i'll send you a link
<dimitern> ericsnow, np, thanks; there's the link for the 1.21 PR http://reviews.vapour.ws/r/362/ (if you look at the first diff you'll see what happened; I had to manually run the following to update the diff: rbt post -u -r 362 --parent 1.21 --tracking-branch origin/1.21 --branch 1.21
<ericsnow> dimitern: ewww
<dimitern> ericsnow, and I tried the same for the 1.20 branch, but rbt reported an error: Unable to find a Review Board server for this source code tree.
<dimitern> (weird how it created #365 in the first place)
<ericsnow> dimitern: it's because the .reviewboardrc file doesn't exist in the 1.20 branch
<dimitern> ericsnow, ah, I thought this might be the issue
<TheMue> dimitern: review has btw been done
<ericsnow> dimitern: it would probably make sense to backport that file
<dimitern> TheMue, tyvm!
<TheMue> dimitern: yw
<dimitern> ericsnow, yes, especially if we're going to support 1.20 for some time and backport fixes
<TheMue> dimitern: has been simple as I know that change already
<ericsnow> dimitern: I'll put up a PR
<dimitern> ericsnow, cheers
<dimitern> TheMue, yeah, but I realized out of being in too much hurry I mis-pasted a few lines of doc comments for the previous 1.21 PR, so I'll propose a trivial fix for that
<TheMue> dimitern: ok, ping me then
<dimitern> TheMue, sure, it shouldn't take long
<ericsnow> dimitern: 1.21 has a related problem (the .reviewboardrc points to master)...I'll update that one too
<dimitern> ericsnow, hmm good catch! that's what probably caused the issue
<ericsnow> dimitern: it should not affect the github automation though
<lazyPower> Question - And i'm fairly certain I already know the answer - in a manually provisioned environment, when a HOST ip changes  does the agent do anything to discover its addressing and transmit that back to the state server?
<dimitern> ericsnow, yeah, but now I get it why I had to specify --branch, --parent, and --tracking-branch to rbt explicitly
<ericsnow> dimitern: ah, yep
<dimitern> lazyPower, I don't believe we expect the API server IP to change (on the same machine, not like when adding another HA slave) in any type of environment, manual included
<dimitern> lazyPower, but you might ask axw, as I might be missing something
<lazyPower> dimitern: thanks for the reply - I figured that was the case. We have a user in #juju that's got a manually provisioned environment and every machine IP changed out from under their deployment, and its causing headaches. I'm trying to come up with ways to triage this - i figure they can edit the jenv to address reachability from client => state server, however i'm not sure how you would repoint the agents @ the state server after an address change.
<fwereade> lazyPower, dimitern: bit of a driveby, but there *is* code in existence that goes into every machine and hacks the state server addresses in the agent configs, that was originally written for the frst attempts at backup/restore
<fwereade> ericsnow might know what we do now, rogpeppe would better remember what we did then ^^
<dimitern> TheMue, there it is - trivial https://github.com/juju/juju/pull/1063
<TheMue> dimitern: *click*
<ericsnow> fwereade: I'd ask perrito666 (he has worked on restore)
<ericsnow> lazyPower: ^^^
<dimitern> fwereade, that's true, but I think we only do that initially, before an api connection is available?
<fwereade> perrito666, hey, are you around? I'm somewhere near you Ithink
<TheMue> dimitern: hmm, thinking about rejecting it. no unit tests. *scnr*
<fwereade> dimitern, yeah, I'm just wondering whether it's easily repurposable
<fwereade> dimitern, I feel like it might be
<lazyPower> ericsnow: thanks for the heads up - perrito666: ping me when you have a minute
<ericsnow> fwereade, lazyPower: see http://reviews.vapour.ws/r/298/
<dimitern> lazyPower, you could go into each machine, change the /var/lib/juju/agents/machine-#/agent.conf (api and state IPs), then kill jujud and let upstart restart it
<dimitern> TheMue, *lol*
<fwereade> dimitern, IIRC the first version was just juju ssh in a loop
<dimitern> lazyPower, and the same for the unit agents conf
<dimitern> fwereade, I wasn't aware we have that code
<ericsnow> lazyPower: FYI, perrito666 is at ODS in Paris, so he *might* be busy for another couple hours
<lazyPower> Thats a respectable reason to be occupied :)
<mgz> and knowing ODS, 'busy' for many hours more after
<natefinch> wwitzel3: standup?
<ericsnow> lazyPower, mgz: I've mostly only seen him around after midnight (in Paris) :)
<wwitzel3> natefinch: oops, omw
<wwitzel3> fwereade: it is a bit verbose, but I was thinking --skip-remote-unit-check ? open to better ideas
<fwereade> wwitzel3, it's a lot clearer than --no-remote-unit though :)
<wwitzel3> fwereade: yes, I initially didn't consider how it read when they were both being used
<wwitzel3> fwereade: it was very silly in that context
<marcoceppi> fwereade, tvansteenburgh and I were wondering about how the events are managed internally in juju, is there a queue or a way to query the agents to see if they're processing an event or have events queued for processing?
<rogpeppe> fwereade: yeah, it just did an ssh to each machine and hacked the agent config files directly with sed AFAIR
<lazyPower> dimitern, ericsnow - solid answers. thanks for the follow up. Another happy customer - http://askubuntu.com/questions/540209/ip-domainname-of-juju-master-or-slaves-changes
<dimitern> lazyPower, sweet!
<fwereade> marcoceppi, the answer is close to "no", but the "juju.worker.uniter.filter" logger is likely to be relevant to your interests
<marcoceppi> fwereade: I mean, even a method not of the ways of the api, like say some terrible horrible hacky method?
<fwereade> marcoceppi, Iforget the precise syntax but something like env-set logging-config "<root>=WARNING;juju.worker.uniter.filter=DEBUG" should be pretty close
<fwereade> marcoceppi, we log ~all interesting events that come in at the debug level
<marcoceppi> fwereade: so this is in the pursuit of determining if an environment is idle, I can see how this would give us the stream of events being dispatched but not necessarily if the event is still occurring or if there are others waiting?
<marcoceppi> we're trying to find more efficient ways other than sshing to each machine and seeing if jujud is running a hook or not and if no units are running any hooks for X seconds the environment is idle
<marcoceppi> but it's not the most reliable or fast method
<fwereade> marcoceppi, ...and what I suggested will not help you re: relation conversations anyway
<marcoceppi> cool
<voidspace> right, I'm off to London
<voidspace> see you all tomorrow
<natefinch> anyone else coming to the team meeting
<natefinch> ?
<natefinch> katco: just saw the thing about the Missouri judge overturning the same sex marriage ban.  That's awesome.
<menn0> wallyworld_: I can reproduce bug 1382751
<mup> Bug #1382751: non subordinate container scoped relations broken  <regression> <relations> <subordinate> <juju-core:In Progress by menno.smits> <https://launchpad.net/bugs/1382751>
<wallyworld_> great, first step to fixing :-)
<menn0> my guy feel it's related to the recent uniter refactoring
<menn0> the uniter keeps dying saying "service is not a subordinate"
<menn0> still digging though
<wallyworld_> hmmm, maybe fwereade's fault :-)
<menn0> s/guy feel/gut feel/
<wallyworld_> lol
<menn0> a guy feel is a totally different thing :)
<wallyworld_> yes :-)
<wallyworld_> menn0: what did you deploy to reproduce?
<menn0> I used apache2 and a dummy charm I whipped up that establishes a container scoped relation to one of its interfaces
<wallyworld_> rightio
<menn0> to speed up testing I might create another dummy charm to replace apache2
<natefinch> wallyworld_: do we have a doc on how to write a provider?
<wallyworld_> natefinch: william wrote one i think, some time back
<wallyworld_> not sure where it got to
<wallyworld_> it will be a little out of date since we don't need storage
<natefinch> wallyworld_: any idea where that doc is?
<wallyworld_> ummm, no :-(
<wallyworld_> i know it was done, don't think i ever saw it
<natefinch> wallyworld_: it's unfortunate that the provider interface is actually called "Environ" :/
<wallyworld_> yes
<wallyworld_> one of many things :-)
<natefinch> ok gotta run
<menn0> wallyworld_: I can make this bug happen in 1.20 as well
<menn0> :(
<wallyworld_> menn0: some other stuff is being backported to 1.20 - i didn't think we'd need to with 1.21 almost out, but given others stuff is being backported, this fix should be too i think
<menn0> man 1.19 sucked compared to 1.21...
<menn0> wallyworld_: this bug exists in 1.19 as well
<menn0> wallyworld_: in fact, looking at "git blame" I think it probably existed in 1.18 too
<wallyworld_> menn0: so good it's being fixed :-)
<sinzui> wallyworld_, help
<sinzui> wallyworld_, I am testing beta1. I get an error generating devel streams http://pastebin.ubuntu.com/8857965/
<sinzui> wallyworld_, ^ I suspect it is because our policy is to delete the product file we are generating before calling generate-tools to ensure juju does checksums. This is also the only way we can retract a dangerous agent
<wallyworld_> looking
<sinzui> yep, juju now requires the product file to exist, which prevents retraction and checksums
<wallyworld_> sinzui: i am guessing that it would be looking in the existing index file, finding an stanza for devel, and then tries to load the product file
<wallyworld_> you can't delete product files ad hoc
<wallyworld_> because that means index file is then lying about what's there
<sinzui> The only hack I can think of is to move the index2.json, generate fresh json, then parse both files to merge
<wallyworld_> hmmm, i wasn't expecting both index and index2 to be generated in the same source tree
<wallyworld_> but i guess that was a bad assumption
<sinzui> wallyworld_, we are now generating index.json We have frozen it and we add it after we create.
<sinzui> hmm
<sinzui> so maybe we need to reset all index.json first.
 * sinzui reset everything and tries again
<wallyworld_> sinzui: i have to go run an important errand, will be back online in about 45 mins
<sinzui> wallyworld_, This is your plan, one tree. so we need to preserve everything, and remember that streams are generated by the version we are publishing...beta1 cannot be used to make 1.20.12 which we might release next week
<wallyworld_> sinzui: i think so, but i can modify things to better suit your workflow
<sinzui> wallyworld_, I will try changing my scripts first
<sinzui> wallyworld_, I haven't reported a bug, so lets try to keep it that way
<wallyworld_> the way it works is that you have a dir of tarballs, and run generate for each stream
<wallyworld_> each time generate is run, it adds to the metadata
<wallyworld_> so adds each new stream
<wallyworld_> but, before it adds, it reads what's there
<wallyworld_> so what's there needs to be valid
 * wallyworld_ runs away, back soon
<perrito666> lazyPower: pong?
<perrito666> like the most extremely belated pong
<rick_h_> lol TZs a pita :)
<perrito666> lazyPower: anyway for whenever you return I know your question, read the code from current masters cmd/plugins/juju-restore/restore.go line 451 and on, they are doing what you need you just need to call that for every client, if you want to call it from the server you need to ssh using identity file /var/lib/juju/system-identity from machine 0
#juju-dev 2014-11-07
<wallyworld_> sinzui: the first comment on that bug - i don't think juju needs to change since it already generates metadata for just one stream at a time, leaving the other stream metadata untouched
<sinzui> wallyworld_, does implementing option 3 risk releasing beta1 tomorrow?
<wallyworld_> sinzui: i'll have a fix asap
<sinzui> wallyworld_, As much as I don't want to write  hack, I can do it in a 3 hours
<wallyworld_> sinzui: the hack will be the backup plan?
<wallyworld_> but i will have juju changed today
<wallyworld_> promise :-)
<sinzui> wallyworld_, it allows my to release, then worry that juju will want to do something different next week
<sinzui> wallyworld_, I like your promises, but I don't want you to rush, stress, loose sleep
<wallyworld_> i'll be fine, we're almost there
<wallyworld_> i'll have it done b the time you SOD
<sinzui> okay, thank you, but if you discover  blocker, remember we have a backup plan
<wallyworld_> yep, good to know :-)
<wallyworld_> just finishing 1 other bug, will get straight on to it soon
<tvansteenburgh> is there something i can do to prevent this (see agent-state-info on machine 3)? http://pastebin.ubuntu.com/8859275/
<wallyworld_> tvansteenburgh: that will be fixed in 1.21 beta1
<tvansteenburgh> wallyworld_: \o/ thanks
<wallyworld_> we expect to release the beta by early next week
<tvansteenburgh> that's great news, i was about to ask :)
<wallyworld_> :-)
<wallyworld_> there's also a lot of other network fixes for maas
<wallyworld_> well juju/maas
<axw> tvansteenburgh: you can delete the default VPC in your region if you don't need it; you can't undo that (without AWS support's help)
<axw> that should stop the error from occurring
<wallyworld_> axw: when you have a moment :-) http://reviews.vapour.ws/r/369/
<wallyworld_> thanks :-)
<tvansteenburgh> axw: thanks for the tip, although i probably can't/shouldn't do that since these environments are owned by sinzui and co.
<axw> right, probably not then ;)
<wallyworld_> axw: i'm off to lunch, so no hurry, but review appreciated http://reviews.vapour.ws/r/370/
<axw> wallyworld_: sure, enjoy
<ericsnow> axw: when you have a minute could you take a look at http://reviews.vapour.ws/r/342/?  It's a little guy.
<axw> ericsnow: sure
<ericsnow> axw: thanks
<axw> ericsnow: done
<ericsnow> axw: with that backups is now completely switched over to gridfs :)
<axw> ericsnow: awesome :)
<wallyworld_> ericsnow: you backporting to 1.21?
<ericsnow> wallyworld_: planning on it
<wallyworld_> ericsnow: awesome. curtis will be doing a beta build tomorrow
<ericsnow> wallyworld_: I guess I'm planning on doing it tonight! :)
<wallyworld_> \o/
<wallyworld_> ericsnow: or we can
<wallyworld_> once it lands, we'll backport
<ericsnow> wallyworld_: well, there's more than one patch that needs backporting
<wallyworld_> ericsnow: in that case, don't worry, it can wait
<ericsnow> wallyworld_: k
<wallyworld_> it will be a bit of risk
<wallyworld_> ericsnow: just in case, can you email be the rev numbers that would need merging
<ericsnow> wallyworld_: will do (shouldn't be more than a handful
<wallyworld_> ok, ta
<ericsnow> wallyworld_: I've emailed you those rev numbers (3 of them)
<wallyworld_> thanks ericsnow :-)
<ericsnow> wallyworld_: plus the one I'm commiting right now (to master)
<wallyworld_> righto
<ericsnow> wallyworld_: you think I should hold off on backporting them?
<wallyworld_> ericsnow: well, it's really late for you isn't it
<ericsnow> wallyworld_: sort of :)
<wallyworld_> so, we'll backport if needed, you go get some sleep
<ericsnow> wallyworld_: k
<wallyworld_> have a good weekend
<ericsnow> wallyworld_: also, are we okay to land http://reviews.vapour.ws/r/371/? (add .reviewboardrc to the 1.20 branch)
<wallyworld_> can't see why not
<ericsnow> wallyworld_: k
<ericsnow> wallyworld_: FYI, we've yet to land the restore side of backups (and we're cutting it close)
<wallyworld_> ericsnow: i was hoping to be divorced from storage, but if it's not all there, we can wait
<ericsnow> wallyworld_: I meant the replacement for the juju restore CLI plugin (not storage)
<wallyworld_> ah, right, yeah that one will have to wait
<ericsnow> wallyworld_: wait for what?
<wallyworld_> 1.22
<wallyworld_> ideally we'll have a week to fully test 1.21 beta before release, which is next friday
<ericsnow> wallyworld_: so does that mean we should yank the new backups (at least the CLI for it)?
<ericsnow> wallyworld_: they kind of go together
<wallyworld_> yeah, i'm not across the state of play with that stuff
<ericsnow> wallyworld_: okay, I'll follow up with Nate tomorrow
<wallyworld_> ta, but i imagine we'd want to revert the cli
<wallyworld_> keep curtis in the loop also
<wallyworld_> as he will be pulling th trigger on the release
<ericsnow> wallyworld_: got it
<wallyworld_> ty
<ericsnow> wallyworld_: have a good weekend :)
<rogpeppe> does anyone know if the "format" field in metadata.yaml still has any relevance to anything?
<rogpeppe> fwereade: ^
<davecheney> rogpeppe: beware format 0 charms
<rogpeppe> davecheney: there are none
<rogpeppe> davecheney: AFAICS - i downloaded all the charms in the charm store
<rogpeppe> davecheney: hi, BTW!
<rogpeppe> davecheney: do you know the difference between format 1 and format 2 ?
<rogpeppe> davecheney: the only charms that i can find that explicitly mention format specify 2, which is different from our default. but we don't seem to have any logic (in the charm package anyway) that cares one way or another
<fwereade> rogpeppe, davecheney: the format stuff was a long long time ago, and I thought all references to it had been purged
<rogpeppe> fwereade: there are still remnants in the charm package
<fwereade> rogpeppe, davecheney: I can't remember exactly what it did -- some subtle change in hook tool behaviour
<fwereade> rogpeppe, I think it's safe to ignore them
<fwereade> rogpeppe, the code that would have been triggering on them does not exist
<rogpeppe> fwereade: i'm just writing a GetYAML method so we can marshal metadata as yaml (finally!) and i'm just making sure that I can always omit the format field.
 * fwereade cheers heartily at rogpeppe
<fwereade> rogpeppe, that sgtm
<rogpeppe> fwereade: cool
<rogpeppe> fwereade: this means that soon you'll be able to programmatically generate charms in tests and produce their yaml metadata, which i think you might find quite useful :)
<fwereade> rogpeppe, that is why I'm cheering :)
<rogpeppe> fwereade: :)
<davecheney> rogpeppe: i think we had this discussion in august 2012
<davecheney> and determined at the time we'd expunged them all
 * rogpeppe forgets most things
<davecheney> from memory, i think the charm format affected the default output format of charm hooks ?
<davecheney> and let me just say, "good riddence"
<fwereade> davecheney, that sounds pretty likely
<fwereade> davecheney, yeah :)
<mattyw> morning folks
<rogpeppe> anyone fancy a little review? https://github.com/juju/charm/pull/75
<TheMue> morning
<alexisb> morning TheMue
<TheMue> alexisb: hey, still in Europe?
<alexisb> I dont normally get to say that to you
<alexisb> yes I am in paris
<TheMue> alexisb: or is you inner clock not yet adjusted back to home? ;)
<TheMue> alexisb: ah, ok, I thought you were already on your flight back
<rogpeppe> fwereade:  https://github.com/juju/charm/pull/75
<mattyw> fwereade, are you around?
<rogpeppe> fwereade: i'm not sure what you mean by making the marshaling explicit
<rogpeppe> fwereade: do you mean the field names?
<fwereade> rogpeppe, yeah
<rogpeppe> fwereade: why is that better? we rely on the default lower casing everywhere else?
<rogpeppe> s/\?$//
<rogpeppe> fwereade: and the tests ensure that it's working correctly
<fwereade> rogpeppe, (1) we try not to everywhere else
<fwereade> rogpeppe, (2) it's hard to make those tests good
<fwereade> rogpeppe, unless we do explicit checks of what gets written out, which have their own problems
<rogpeppe> fwereade: the tests test round-tripping, which seems like a good-enough test to me
<fwereade> rogpeppe, roundtrip tests don't detect marshalling *changes* though
<rogpeppe> fwereade: yeah, i think they will
<rogpeppe> fwereade: we read in with the standard ReadMeta, and check that when marshaled, and read back, we get the same thing
<rogpeppe> fwereade: so if the marshaling semantics change (e.g. to not lower case the name) the test will fail
<rogpeppe> fwereade: for example, if i change the "Categories" tag so that the name is "Categories", the test fails
<fwereade> rogpeppe, doesn't that depend on a chain of inference across multiple tests and implementations? I'd rather just have it 100% obvious how something's going to marshal
<fwereade> rogpeppe, assuming readmeta works and the readmeta test works and this test uses readmeta...
<fwereade> rogpeppe, vs "that's how it marshals, done"
 * fwereade has to go again anyway
<rogpeppe> fwereade: ok, i'll add explicit names, no big deal
<rogpeppe> fwereade: though everything would break if yaml didn't lower-case as it marshaled (i actually don't like that behaviour, as it's doesn't fit with encoding/json, but i think it's reasonable to rely on)
<rogpeppe> fwereade: and the same testing issue applies whether i make the names explicit or not.
<fwereade> rogpeppe, thanks -- fwiw I've caught at least one proposed fieldname change that would have broken stuff subtly, I'd rather just make that mistake harder across the board
<fwereade> rogpeppe, granted, but it's that fieldname changes don't *always* trigger hey-changing-marshalling in people's brains
<fwereade> rogpeppe, this means that marshalling changes must be made explicitly, and will be seen to be explicit in review
<rogpeppe> fwereade: at some point, i plan to implement a backward-compatibility checker that can ensure this kind of stuff automatically
<fwereade> rogpeppe, that sounds awesome
<fwereade> rogpeppe, in the meantime, be so kind as to indulge my paranoia ;)
<rogpeppe> fwereade: will do
<rogpeppe> fwereade: the idea is that you run all the tests, check what gets marshaled/unmarshaled, and that gives you your list of stuff that needs to be maintained correctly.
<anastasiamac> jam, wallyworld_, axw: could u plz cast ur eyes over http://reviews.vapour.ws/r/357/ when u get a chance. this should cater for recomendations based on hardware and user preference
<menn0> this needs a review. it's a fix for one of the bugs that needs to be sorted for 1.21 beta1. Turns out it's a long-standing issue. http://reviews.vapour.ws/r/377/
<rogpeppe> here's a tiny PR in the charm package, if anyone wants to take a look: https://github.com/juju/charm/pull/76
<TheMue> rogpeppe: will do
<rogpeppe> TheMue: ta!
<TheMue> rogpeppe: lgtm
<rogpeppe> TheMue: ta!
<TheMue> yw
<wallyworld_> anyone know where fwreade is?
<alexisb> wallyworld_, I am looking at him
<wallyworld_> alexisb: ah, in that case i really need to talk to him
<wallyworld_> fwereade: !!
<wallyworld_> a couple of things, could you please look at http://reviews.vapour.ws/r/377/
<wallyworld_> we need to land this for 1.21
<fwereade> wallyworld_, ok, looking
<wallyworld_> it looks ok, but i have a coupleof concerns, bt may be ok
<fwereade> wallyworld_, I think that LGTM, but what are the concerns?
<wallyworld_> fwereade: what happens if someone changes the number of sub ords after a relation is added
<wallyworld_> then it could become invalid
<fwereade> wallyworld_, don't understand the question
<fwereade> wallyworld_, a service can't change its subordinacy
<wallyworld_> fwereade: i had a couple brief other questions, quick chat?
<wallyworld_> or you may be busy
<fwereade> wallyworld_, in a sprint room, private irc if you don't want to pollute here?
<fwereade> wallyworld_, happy to talk ofc
<fwereade> wallyworld_, just not convenient to do so out loud
<fwereade> wallyworld_, also my connection is rather spotty
<lazyPower> perrito666: thanks for the follow up, dimitern and ericsnow got me sorted. I should have sent un-ping ;)
<perrito666> np
<perrito666> you can thank fwereade that told me you where looking for me, he told it to me after 3 beers, but the information persisted nevertheless
<wallyworld_> perrito666: is nate around?
<perrito666> wallyworld_: there he is
<dimitern> anyone can review a trivial patch to fix bug 1307677? http://reviews.vapour.ws/r/380/diff/
<mup> Bug #1307677: juju tries to use lxcbr0 when local provider is configured with kvm containers <cloud-installer> <config> <kvm> <local-provider> <juju-core:In Progress by dimitern> <https://launchpad.net/bugs/1307677>
<wallyworld_> perrito666: tis ok, i was just going to ask for a branch to be backported, but i've just done it
<dimitern> cmars, TheMue, as OCR, can you have a look? ^^
<perrito666> wallyworld_: uh, I should postpone answering to you more often
<wallyworld_> indeed :-)
<lazyPower> fwereade: tap me next sprint and i'll get ya a beer
<lazyPower> perrito666: same to you *hattip*
<dimitern> thanks wallyworld_ !
<wallyworld_> dimitern: np, sorry about brief comments, beena long day
<wallyworld_> is this for 1.21 also?
<dimitern> wallyworld_, yeah
<TheMue> dimitern: *click*
<wallyworld_> great, really happy to see these network issues get fixed
<wallyworld_> natefinch: hey
<wallyworld_> or perrito666
<natefinch> yo
<wallyworld_> hey nate
<wallyworld_> for 1.21
<TheMue> dimitern: you've got a review
<dimitern> TheMue, thanks!
<wallyworld_> i landed menno's fix for bug 1382751
<TheMue> dimitern: yw
<mup> Bug #1382751: non subordinate container scoped relations broken  <regression> <relations> <subordinate> <juju-core:Fix Committed by menno.smits> <juju-core 1.20:In Progress by menno.smits> <juju-core 1.21:In Progress by menno.smits> <https://launchpad.net/bugs/1382751>
<wallyworld_> pr 1075
<wallyworld_> i backported to 1.21
<wallyworld_> and tried to land in pr 1077
<wallyworld_> but
<wallyworld_> there was test failure, due to a missing file http://juju-ci.vapour.ws:8080/job/github-merge-juju/1229/console
<wallyworld_> i'm totally buggered, after 12:30am here
<wallyworld_> could you possibly take a look and fix the issue and land?
<wallyworld_> it should be small and easy hopefully given it's anded in master already
<natefinch> wallyworld_: sure
<wallyworld_> tyvm
<wallyworld_> the goal is to get 1.21 beta blessed today
<natefinch> wallyworld_: seems likely something changed between 1.21's charm.v4 revision and master's charm.v4 revision
<wallyworld_> ah could be, charm.v4 has changed, yes
<wallyworld_> natefinch: maybe also poke wayne about bug 1361316
<mup> Bug #1361316: juju status panic if state conn is shutdown || closing. <cts-cloud-review> <panic> <status> <ui> <juju-core:Triaged by wwitzel3> <https://launchpad.net/bugs/1361316>
<wallyworld_> should be a one line fix
<natefinch> wallyworld_: yep, I'll ping him.  he was going to start looking at it yesterday, I'll make sure he's just doing the easy fix and not the hard fix :)
<natefinch> wwitzel3: ^
<wallyworld_> yeah, juju status is messed up
<wallyworld_> even with err != nil, you are expected to still print partial status
<wallyworld_> anyone know that state of bug 1381619
<mup> Bug #1381619: Failed to destroy-environment when node is in commissioning or new state <cloud-installer> <oil> <juju-core:Triaged by mfoord> <MAAS:Incomplete> <https://launchpad.net/bugs/1381619>
<wallyworld_> comments on the bug made me think that the fix was well understood
<dimitern> wallyworld_, voidspace started on that yesterday IIRC
<natefinch> rogpeppe: You just changed something in charm.v4 about testing and charm repos... we're trying to backport a change from master to 1.21 and it's getting this error: ... Panic: open /home/ubuntu/juju-core_1.21-beta1/src/gopkg.in/juju/charm.v4/testing/repo/quantal/logging-principal/metadata.yaml: no such file or directory (PC=0x4144D6)
<wallyworld_> hopefully will be done today as it's marked critical for 1.21 :-)
<wallyworld_> anyways, gotta sleep, good luck with final bug fixes
<rogpeppe> natefinch: looks like you've got the wrong dependencies
<perrito666> yay windows is fun
<rogpeppe> natefinch: or... do you need the new changes in the charm package?
<natefinch> rogpeppe: well, so 1.21 uses charm.v4 from before your latest change...
<natefinch> rogpeppe: that or we make the ported fix work with charm.v4 from before your change
<rogpeppe> natefinch: if that's the case, then how could my change in charm.v4 affect it?
<wwitzel3> natefinch: ok, I can add the status check and put up a review
<rogpeppe> natefinch: i think you'll have to do that
<natefinch> rogpeppe: the fix was made to master after your change
<rogpeppe> natefinch: that's part of the backport
<natefinch> rogpeppe: right, so my question is - what's different?
<natefinch> wwitzel3: cool
<rogpeppe> natefinch: we moved the testing charms repo from charm.v4 to juju-core
<rogpeppe> natefinch: but...
<rogpeppe> natefinch: that error message looks like you haven't updated the charm.v4 package
<natefinch> rogpeppe: right, I'm just concerned that if we update the charm.v4 revision that 1.21 uses, that it'll break a whole lot more stuff
<rogpeppe> natefinch: because charm.v4/testing/repo/quantal *should* exist in the old charm.v4 package
<rogpeppe> natefinch: yes, it will. don't do that.
<natefinch> oh hmm
<natefinch> ok, good, so that's what I assumed
<rogpeppe> natefinch: it's possible that the logging-principal test charm was added recently
<natefinch> https://github.com/juju/juju/pull/1077/files
<natefinch> it was added in this PR
<rogpeppe> natefinch: what version of charm.v4 is being used?
<natefinch> rogpeppe: f97c8d630e45651f7b39ce352dd7329082f134c4
<rogpeppe> natefinch: right, that's your problem
<natefinch> well, so, I'm not sure how to fix this.  If updating the charm.v4 revision will break a bunch of stuff... but this test won't work in 1.21 because charm.v4 at that revision expects the testcharm to be under its own testing/repo directory
<rogpeppe> natefinch: i see the issue
<natefinch> It seems like the only fix is to update 1.21's dependencies to use charm.v4 with your change
<rogpeppe> natefinch: and this is also a reason that the changes we've made in charm.v4 are good - it will prevent things like this from happening again
<natefinch> yes definitely
<rogpeppe> natefinch: yes
<natefinch> and then fix whatever else falls out of that
<rogpeppe> natefinch: those changes were sweeping but pretty much automatics
<rogpeppe> s/cs$/c/
<natefinch> k
<rogpeppe> natefinch: and the compiler will tell you if you've gotten it wrong
<rogpeppe> backporting is such fun
<natefinch> what's doubly aggravating is that this is just  for the test.  The actual production code is fine.
<natefinch> (in theory)
<natefinch> well, I'm glad we made the fix so it won't happen again... too bad we hit it one last time though
<ericsnow> natefinch: standup?
<ericsnow> sinzui: FYI, the restore side of backups has not landed for 1.21, which renders the rest of the new backups code kind of pointless for 1.21
<ericsnow> sinzui: I'm planning on getting a change into 1.21 that simply removes the new backups CLI but leaves the rest of the backups code intact (to lessen the risk of removing so much)
<ericsnow> sinzui: that patch should be up in a little bit
<wwitzel3> natefinch: http://reviews.vapour.ws/r/382/ fix for lp:1361316
<sinzui> ericsnow, thank you
<wwitzel3> also wallyworld_ if you're still around - http://reviews.vapour.ws/r/382/
<sinzui> natefinch, can you organise an effort to backport the fix for bug 1382751 to beta1 (1.21 branch)? It may be in progress already
<mup> Bug #1382751: non subordinate container scoped relations broken  <regression> <relations> <subordinate> <juju-core:Fix Committed by menno.smits> <juju-core 1.20:In Progress by menno.smits> <juju-core 1.21:In Progress by menno.smits> <https://launchpad.net/bugs/1382751>
<natefinch> sinzui: yeah, it's in progress by me ;)
<natefinch> sinzui: just updated the bug to reflect that
<sinzui> you rock natefinch
<natefinch> someday I'll tell the story of changing the keys on my keyboard so the bottom row spelled out "NATEROCKS" :)
<natefinch> ok, well, actually, that's the whole story
<sinzui> :)
<wwitzel3> thanks for the review TheMue
<TheMue> wwitzel3: yw
<wwitzel3> I just got an email from Amazon trying to get me to pay $99 to stick a device in my home that will listen to everyting in my house and send all that data to them ...
<wwitzel3> I feel like they should pay me for that
<voidspace> hah
<voidspace> wwitzel3: what's the device called?
<voidspace> I've not heard of that
<wwitzel3> Amazon Echo ..
<voidspace> wwitzel3: the NSA probably did that for you for free
<wwitzel3> if it was April .. I would of thought it was a joke
<voidspace> http://www.amazon.com/oc/echo
<voidspace> interesting
<natefinch> I saw a thing about that yesterday.  It seems interesting, but don't we all have something like that in our pockets already?  I guess not with a halfway decent speaker
<wwitzel3> see, the NSA did it wrong, all they needed to do was has a nice landing page and charge people for PRISM and it would of been a hit
<natefinch> haha
<natefinch> honestly, the main problem with this thing is that it's audio-only.  You now how many times I'm going to listen to it read out a wikipedia page?
<voidspace> :-)
<wwitzel3> natefinch: though it is probably more effective than when your friends read a wikipedia page off their phone, they always leave out the citation needed part :D
<voidspace> axw: ping
<natefinch> haha
<voidspace> axw: although I really doubt you're around
<wwitzel3> voidspace: it is like 5am saturday morning, who isn't up (still) then? ;)
<wwitzel3> voidspace: since you are OCR today, mind looking at http://reviews.vapour.ws/r/382/
<voidspace> ah, am I?
<wwitzel3> voidspace:  you and fwereade I believe
<ericsnow> sinzui, natefinch: 1.21 backups CLI removal patch: http://reviews.vapour.ws/r/383/
<voidspace> wwitzel3: you're looking at the wrong friday I think...
<wwitzel3> voidspace: probably
<wwitzel3> voidspace: will you look anyway *eyebat*
<voidspace> heh
<ericsnow> wwitzel3: cmars and TheMue are OCR
<voidspace> wwitzel3: seeing as I'm very unlikely to get this high priority bug completed anyway *sigh*
<voidspace> wwitzel3: I think I know where in the code to fix it at any rate
<natefinch> wwitzel3: you got a ship it from TheMue
<wwitzel3> voidspace: which are you working on?
<voidspace> wwitzel3: there's even a comment from axw predicting that there would be a problem with the code...
<wwitzel3> natefinch: don't we still need two?
<TheMue> yeah
<voidspace> wwitzel3: bug #1381619
<mup> Bug #1381619: Failed to destroy-environment when node is in commissioning or new state <cloud-installer> <oil> <juju-core:Triaged by mfoord> <MAAS:Incomplete> <https://launchpad.net/bugs/1381619>
<natefinch> wwitzel3: no?
<wwitzel3> oh, I was still under the impression we needed two LGTM/Ship It on reviews, ok :)
<voidspace> wwitzel3: have you seen how RB renders that diff?
<voidspace> ericsnow: ^^
<natefinch> wwitzel3:  I don't think we've needed 2 LGTMs since before we hired you :)
<voidspace> anyway LGTM *sigh*
<voidspace> wwitzel3: couldn't you just remove registering the command, whilst leaving the rest of the code in there?
<natefinch> ericsnow: yeah, that's what I was thinking ^
<wwitzel3> voidspace: huh?
<natefinch> wwitzel3: I think he keeps typing you instead of ericsnow
<voidspace> wwitzel3: basically, only do the change in cmd/juju/main.go
<perrito666> natefinch: when I entered whoever induced me, which I believe was mgz said that 1 for trivial changes 2 for anything importan
<perrito666> t
<voidspace> oh
<wwitzel3> voidspace: what?
<voidspace> is it ericsnow who asked for the review
<voidspace> wwitzel3: no, you asked for a review on 383
<wwitzel3> oops
<wwitzel3> wrong thing
<voidspace> wwitzel3: which removed backups
<natefinch> haha
<natefinch> 383 is eric's code
<voidspace> ah, ok
<wwitzel3> voidspace: http://reviews.vapour.ws/r/382/ sorry .. but I apparently don't need your review anyway :P
<voidspace> ericsnow: for 383... couldn't you just remove registering the command and leave everything else in place?
<voidspace> wwitzel3: hah ok :-)
<ericsnow> voidspace: too easy <wink>
<voidspace> ericsnow: :-)
<voidspace> ericsnow: if the code is good, and it's tested, why not leave it in place
<ericsnow> voidspace: good point; it hadn't crossed my mind
<mattyw> fwereade, you got 30 seconds?
<fwereade> mattyw, yeah, more or less :)
<ericsnow> voidspace: yeah, that makes for a much simpler change :)
<natefinch> ericsnow: +1
<ericsnow> natefinch: could you give me a ship-it?
<natefinch> ericsnow: done
<ericsnow> natefinch: thanks
<natefinch> ericsnow: just make sure all the tests still pass
<ericsnow> natefinch: they do
<natefinch> cool
<voidspace> gah, virsh can't use a storage pool on another physical drive due to strange permissions problems
<voidspace> but you can create a filesystem in a file and then mount that as if it's on the partition it wants it on
<voidspace> and it will use that happily
<voidspace> that took me nearly half a day to work out
<voidspace> but now I have two maas nodes
<voidspace> not using hard drive space on my boot disk
<voidspace> so now I can bootstrap *and* deploy a service - to try and reproduce the bug I'm meant to be working on
<wwitzel3> voidspace: progress :)
<voidspace> wwitzel3: yeah, slow and painful - but definite
<voidspace> although juju bootstrap hasn't started the node
<voidspace> "competent-bait" is resolutely off
<voidspace> but the power reporting works, so maas could boot the node if it wanted to
<voidspace> status is "Deploying" but power is off
<voidspace> INFO 0 minutes ago Node powered on
<voidspace> no it didn't...
<voidspace> and if I switch it on it shuts down again
<natefinch> voidspace: it's like one of those boxes that you turn on and a hand comes out and turns itself off.
<voidspace> natefinch: unfortunately so...
<voidspace> "useless box"
<voidspace> very qppropriate
<voidspace> nope, maas changes the node state to Deploying, they start and then shutdown almost immediately
<voidspace> the only record in the logs (libvirtd, maas and qemu) is that libvirtd kills the qemu process (shuts down the node)
<voidspace> commisioning works fine
<voidspace> and now it's working (after another manual kvm image start)
<voidspace> for no fathomable reason
<voidspace> looks like pxe booting isn't working, but manual starting is now working (didn't before)
<voidspace> that's good enough
<voidspace> heh, so I can't quite reproduce the bug
<voidspace> but if I manually release a maas node and then call destroy-environment, juju hangs
<voidspace> I don't know for how long...
<voidspace> ah...
<voidspace> that was releasing the bootstrap node
<voidspace> *state server node
<voidspace> not what I intended
<voidspace> no it wasn't
<voidspace> I released the right node
<natefinch> whoever is responsible for files in Juju that are over 2000 lines long should be flogged.  (really, anything over ~500 is too much)
 * natefinch goes to fix a test failure at line 2440 in apiserver/client/client_test.go
 * TheMue likes the good old Smalltalk. no files and methods seldom with more than 20 lines
<natefinch> That's one of the things I like about Go - you can subdivide into as many files as you want. They're all effectively just cat'ed together by the compiler
<natefinch> (per package)
<TheMue> natefinch: yes, no need to put everything in one file
<TheMue> natefinch: but otherwise, one file per unit of code and a rule of few lines leads to small units (classes, packages, modules, etc)
<natefinch> yep
<natefinch> big files aren't the end of the world, honestly, it's just a little annoying having to page through them in diffs and in the editor.  Big functions are the really killer... we have some 200 line functions in Juju that I've seen.  Biggest function I've seen in my career was a 1000 line behemoth, but that was a long time ago
<TheMue> ouch, that really hurts
<voidspace> happy weekend everyone
<voidspace> g'night all
<natefinch> see ya voidspace
<natefinch> sinzui: btw, backporting https://launchpad.net/bugs/1382751 is turning out to be a big mess.  It requires porting another change, and that then requires a third change....
<mup> Bug #1382751: non subordinate container scoped relations broken  <regression> <relations> <subordinate> <juju-core:Fix Committed by menno.smits> <juju-core 1.20:In Progress by menno.smits> <juju-core 1.21:In Progress by natefinch> <https://launchpad.net/bugs/1382751>
<sinzui> natefinch, :(
<sinzui> natefinch, is the chain for pain for 1.21 or both 1.21 and 1.20?
<natefinch> sinzui: I would imagine it's possibly even more difficult for 1.20, though I haven't even looked at 1.20 yet
<sinzui> natefinch, okay. I really appreciate you working on this. I am not sure we will release 1.20.12...well I need to work out how since 1.21 has permanently changes streams
<natefinch> sinzui: I think I have most of what needs doing done... just running the tests now, which is always its own adventure
<sinzui> fab
<natefinch> sinzui: so, I have  PR for the prerequisite code that needs to go in before I can backport the fix
<natefinch> sinzui: but it seems unwise to simply dump all this into 1.21 on Friday afternoon.  What do you think?
<sinzui> natefinch, if I see a pass tomorrow morning, I am happy to release. A failure may mean the antipodians have a regression to fix
<natefinch> sinzui: what i hear is "merge it and we'll see what happens" ... is that correct? :)
<sinzui> natefinch, yes, let's be hopeful
<natefinch> sinzui: does the merge bot work on the 1.21 branch?
<sinzui> natefinch, if it turns out bad, we are still are ahead of delaying until our monday
<natefinch> sinzui: yep
<sinzui> natefinch, yep, just works
<natefinch> ok
<cmars> natefinch, is reviewboard spewing lots of errors for you when you try to view this diff? http://reviews.vapour.ws/r/384/diff/#
<natefinch> typ
<natefinch> yup
<cmars> ericsnow, any ideas? ^^
 * ericsnow looks
<cmars> natefinch, ok, just wanted to confirm. i'll review in my dev env
<natefinch> sinzui: I'll hafve to finish up the second PR with the fix in the morning, I'm out of time today. It's just merging PR 1075 into 1.21 ... I've just run out of time trying to wrestle with git and github to get it to do that
<sinzui> natefinch, okay, Thank you for your time
<ericsnow> cmars: looks like a classic merge conflict (as the error messages imply)
<ericsnow> cmars: why?  I'm not immediately sure
<ericsnow> cmars: I'm guessing something didn't line up right when Nate initially made his pull request, which caused RB trouble and it hasn't been able to get back on its feet to try again
<cmars> ericsnow, could be the target branch is 1.21 instead of master? it doesn't look like it has a conflict
<ericsnow> cmars: 1.21 is definitely the trigger, but the cause of the problem is unclear
<ericsnow> cmars: FYI, other 1.21 PRs have generated proper review requests without incident
<ericsnow> cmars: I wonder if Nate used rbt to post the diff
#juju-dev 2014-11-08
<fwereade> gsamfira, http://reviews.vapour.ws/r/385/
<perrito666> hey any one knows what is revision file on a charm? it is in this structure https://juju.ubuntu.com/docs/tools-charm-tools.html but juju charm create does not add that file
<perrito666> gsamfira: what is the oldest version of windows we claim to support?
<fwereade> axw, ping?
#juju-dev 2014-11-09
<jw4> anyone around to give a quick review? http://reviews.vapour.ws/r/388/
 * thumper takes a deep breath and dives into the massive pile of work emails
<lazyPower> thumper: o/
<thumper> o/ lazyPower
<lazyPower> hows my favorite kiwi?
<jw4> davecheney: just responded to your review... thanks by the way.  I disagreed with both of your comments :)
<menn0> waigani: you still need a review of the settings stuff?
<waigani> menn0: yes please: http://reviews.vapour.ws/r/368/
<menn0> waigani: doing it now
<waigani> thanks
<menn0> waigani: done
<menn0> wallyworld_: morning
<waigani> menn0: thanks
<wallyworld_> hi
<wallyworld_> thanks for fixing that bug
<menn0> waigani: no problems
<menn0> thanks for merging it
<wallyworld_> np, was a bit of an experience to get it in 1.21
<menn0> wallyworld_, waigani: duh. The "no problems" was intended for wallyworld_
<wallyworld_> turns out other charm/repo stuff has to be backported too
<menn0> :)
<menn0> wallyworld_: yeah I saw that. there was another way around that. i initially had that test working without creating a new charm
<menn0> wallyworld_: by copying and monkeying the existing logging charm
<waigani> menn0: np, I take it as a given there will be problems with my review ;)
<wallyworld_> all good, at least 1.21 ans trunk are a little less diverged
<menn0> waigani: nothing major, except a potential pre-existiing bug
<menn0> wallyworld_: do you want me to backport to 1.20 as well?
<waigani> menn0: cool, thanks again, looking now
<wallyworld_> menn0: not sure, i was hoping we'd stop doing so much with 1.20 now that 1.21 is almost here
<menn0> wallyworld_: it's "fairly" unlikely that people will hit that bug but it's pretty bad when they do
<wallyworld_> yeah
<wallyworld_> i'll find out from curtis what our plans are
<menn0> wallyworld_: my inclination is to do the backport
<menn0> it shouldn't take long
<wallyworld_> ok, may as well then. i know dimiter has backported some network stuff too
<menn0> wallyworld_: k
<menn0> wallyworld_: I'll try and get it done today
<wallyworld_> no rush, not sure when 1.20 is getting a new release
<wallyworld_> 1.21 is the focus this week
<menn0> wallyworld_: ok
<waigani> menn0: when you have a moment: http://reviews.vapour.ws/r/368/
<menn0> waigani: looking
<menn0> waigani: so you think that was a bug?
<waigani> menn0: yes
<menn0> waigani: did you expand the unit tests to cover that scenario?
<waigani> menn0: I dumped the db, and the key used to get the doc
<waigani> menn0: you were right, good catch
<waigani> menn0: no, good point
<menn0> waigani: so what's with the checkAddEnvUUIDToCleanupsIdempotent comment? is it supposed to be there?
<waigani> menn0: no, i deleted it didn't I? It was just a reminder for me while working on the branch.
<menn0> waigani: nope it's still ther
<waigani> 0_O
<menn0> didn't hit save?
<waigani> ah right, ugh
<waigani> yeah I'll delete it
<waigani> AND save
<waigani> menn0: so the test. Should we check that the search key matches the settingsKey format with a regex?
<menn0> waigani: I don't think so. You want to engineer something where the first transaction attempt fails so that bit of code gets hit
<menn0> waigani: and then make sure the alive test works as expected
<waigani> menn0: right, got it
<menn0> perhaps make the fix and test changes in a separate PR if it's going to take a while?
<menn0> waigani: ^
<waigani> menn0: I'll have a poke around, considering it's nearly lunch, if my hunger wins out I'll do it in a followup PR
<menn0> waigani: not sure if you know but you can induce transaction failures using SetAfterHooks and SetBeforeHooks
<waigani> menn0: ah nice, thanks
<waigani> menn0: so code is currently called at bottom of TestSetCharm // SetCharm fails when the service is Dying.
<waigani> menn0: but it's not a positive test
#juju-dev 2015-11-02
<mup> Bug #1512191 opened: worker/uniter: update tests to use mock clock <tech-debt> <juju-core:Triaged> <https://launchpad.net/bugs/1512191>
<mup> Bug #1512191 changed: worker/uniter: update tests to use mock clock <tech-debt> <juju-core:Triaged> <https://launchpad.net/bugs/1512191>
<mup> Bug #1512191 opened: worker/uniter: update tests to use mock clock <tech-debt> <juju-core:Triaged> <https://launchpad.net/bugs/1512191>
<cherylj> anastasiamac: ping?
<anastasiamac> cherylj: pong?
<cherylj> hey :)
<cherylj> got a few minutes to chat?
<anastasiamac> cherylj: isn't it sunday for u?
<anastasiamac> of course
<cherylj> technically, yes
<cherylj> :)
<anastasiamac> tomorrow's meeting?
<cherylj> yes, let me get my headset
<davechen1y> mwhudson: so far joining the IBM partner network has granted me
<davechen1y> 1. zero access to the things I want
<davechen1y> 2. spam
<mwhudson> davechen1y: \o/
<mwhudson> davechen1y: i'm not sure i've gotten as far as getting spam
<jam> dimitern: did I miss you at our 1:1 ? I thought I was in the room a while
<dimitern> jam, sorry, I overslept :/
<jam> dimitern: k. no prob. I just was making sure we still had the right schedule with tz changes
<dimitern> jam, yeah, the schedule is correct
<voidspace> dimitern: ping
<dimitern> voidspace, pong
<voidspace> dimitern: hang on - trying something
<voidspace> dimitern: may still need your help, will re-ping if necessary :-)
<dimitern> voidspace, :) sure
<voidspace> dimitern: dooferlad: frobware: just grabbing coffee and taking a loo break, will be a couple of minutes late to standup
<voidspace> sorry!
<dimitern> voidspace, np
<dimitern> jam, standup?
<voidspace> dimitern: omw
<voidspace> wallyworld: ping
<frobware> jam: today is the day, my first bootstrap failed with the replica set failure; the day keeps getting better.... ??? :)
<voidspace> dimitern: are addressable containers in 1.24?
<dimitern> voidspace, there are some parts of it, but it's not working fully
<voidspace> dimitern: so there could be people using deployed environments with addressable containers
<dimitern> voidspace, in 1.24 ?
<voidspace> dimitern: yep
<dimitern> voidspace, that's possible of course, but I highly doubt it
<voidspace> dimitern: so making them "not work" on maas 1.8 would be a backwards compatibility issue...
<dimitern> voidspace, they won't work on maas without devices support, i.e. <1.8.2
<voidspace> dimitern: what do you mean by won't work?
<dimitern> voidspace, juju cannot guarantee container resources will be full released
<voidspace> dimitern: don't we support the older ways of requesting addresses - we used to
<voidspace> dimitern: so by "won't work" you mean "will work but there might be a temporary issue later under some circumstances"
<voidspace> dimitern: I really dislike the abuse of the phrase "won't work"
<dimitern> voidspace, the "temporary" issue is quite critical for some of our users
<voidspace> dimitern: specific users in specific cases
<voidspace> dimitern: that we can communicate with
<dimitern> voidspace, since maas 1.8.2 is in trusty, as a user you most likely won't even see that error
<voidspace> dimitern: we have many users with many use cases, breaking stuff that works for one use case - when we have fixed the problem for the other use case and can communicate with them - seems like a real backwards step to me
<voidspace> dimitern: we're [potentially] breaking things for some users - to avoid a problem that we've already fixed another way!
<dimitern> voidspace, all of that depends on the definition of "works"
<dimitern> voidspace, does it work if you can re-do the same deployment on the same maas only a certain number of times?
<voidspace> dimitern: well sort of but "the feature does what it says but under some circumstances might temporarily leak resources when you've *finished using it*"  is a funny definition of "doesn't work"
<voidspace> dimitern: using thousands of containers within a short space of time is a pretty specific use case - and one we *have addressed*
<voidspace> dimitern: we're not ignoring that use case, but to block *all other use cases* because of it is not good
<perrito666> morning
<dimitern> voidspace, sorry, but that's sounds to me like saying "leaving instances around after destroy-environment is not our problem, as it did work fine while the environment was running"
<voidspace> perrito666: morningg
<voidspace> dimitern: leaving instances around, that cost money, would be much worse and we should really avoid it
<voidspace> dimitern: temporarily leaking a dhcp lease is not the same
<dimitern> voidspace, it's the same, but it takes more retries for it to become a problem
<dimitern> voidspace, the same as with memory leaks really -  a small leak won't be a problem, unless you run your application for a long time
<dimitern> :)
<voidspace> dimitern: they're not at all the same
<voidspace> dimitern: resource leakage is not a good thing
<wallyworld> voidspace: hi
<voidspace> dimitern: having temporary leaks that don't cost money under specific known corner cases - addressed in a later release - is not the end of the world
<voidspace> dimitern: stopping *existing deployments* working, is much worse
<dimitern> voidspace, why you keep calling the leaks "temporary" ? it's not like they're going way by themselves after a while
<voidspace> dimitern: the dhcp lease expires, true?
<dimitern> voidspace, that depends on the dhcp server config
<voidspace> wallyworld: I would like to talk to you about bug 1403689
<mup> Bug #1403689: Server should handle tools of unknown or unsupported series <upgrade-juju> <upload-tools> <juju-core:Fix Released by wallyworld> <juju-core 1.24:Triaged> <juju-core 1.25:Fix Released by wallyworld> <https://launchpad.net/bugs/1403689>
<wallyworld> sure
<dimitern> voidspace, I think MAAS dhcpd uses rather long leases by default
<voidspace> wallyworld: did you fix it in the server or client?
<voidspace> wallyworld: server I assume
<wallyworld> voidspace: tim had already found and fixed most of the cases of mapping series -> version, but there was one place in simplestreams search that was not covered
<voidspace> dimitern: this is a specific use case for *experimentation*, real users aren't burning through all their dhcp leases! I'm not saying ignore the issue - we've fixed it! (Requiring maas 1.8).
<voidspace> dimitern: however blocking all other "normal uses" because of it, seems wrong / bad
<wallyworld> voidspace: so all the usages that i can see that would panic or return an error have been patched
<voidspace> wallyworld: where?
<voidspace> wallyworld: we have this problem on 1.20 / 1.22 servers...
<dimitern> voidspace, can you explain which "normal users" will be blocked?
<voidspace> wallyworld: which can't be upgraded with --upload-tools
<wallyworld> i fixed it in master
<wallyworld> and 1.25 i think
<voidspace> dimitern: anyone using addressable containers
<dimitern> voidspace, for existing environments, it will keep working as before
<wallyworld> upload-tools is bad
<dimitern> voidspace, for new environments, the new behavior is enforced by default
<wallyworld> we try not to encourage its use
<voidspace> wallyworld: however if you want to give users new binaries to test a fix it is what we have
<wallyworld> is there a use case for it?
<voidspace> wallyworld: unless you can suggest an alternative?
<voidspace> dimitern: upgrading a deployed environment
<dimitern> voidspace, the only affected users will be those using maas 1.7 or earlier
<wallyworld> our policy afaik is to get them to upgrade to latest stable relase
<wallyworld> aka 1.25
<wallyworld> uness that's changed
<voidspace> wallyworld: that upgrade doesn't work
<wallyworld> from 1.22 to 1.25?
<voidspace> wallyworld: we need to know if a proposed change has fixed the problem they have
<voidspace> wallyworld: yep
<voidspace> wallyworld: lots of horrible problems
<wallyworld> we haven't cuaght that in CI?
<voidspace> nope
<wallyworld> CI should have flagged those issues
<voidspace> wallyworld: https://bugs.launchpad.net/juju-core/+bug/1507867
<mup> Bug #1507867: juju upgrade failures <canonical-bootstack> <upgrade-juju> <juju-core:Triaged by hduran-8> <https://launchpad.net/bugs/1507867>
<voidspace> wallyworld: for a specific user
<wallyworld> looking
<wallyworld> voidspace: ah right ignore-machine-addresses
<voidspace> wallyworld: not just that though
<wallyworld> what else?
<wallyworld> there was a mongo corrution
<voidspace> yep
<wallyworld> but we were witing for logs
<wallyworld> mogo got corrupt before upgarde
<wallyworld> and could be fixed by running repairDatabase()
<voidspace> wallyworld: meanwhile, I've fixed the ignore-machine-addresses issue
<wallyworld> yay
<voidspace> wallyworld: but I can't get them to test that
<wallyworld> what about trying upload-tools with a 1.25 client?
<wallyworld> and having a custom jujud in the path
<wallyworld> unless w ebackport all the series versio fixes (and there were several, older clients will get stuck i expect)
<wallyworld> and we are not doing any new 1.20/1.22 releases
<dimitern> voidspace, so is the whole argument about displaying a warning if we detect no devices api instead of an error?
<voidspace> wallyworld: is the fix in the client then?
<voidspace> wallyworld: the 1.25 client won't attempt to upload a version that the 1.22 server rejects?
<voidspace> dimitern: a warning would be better, rather than refusing to create a new container (for deployed environment that may already have addressable containers created under 1.24)
<voidspace> wallyworld: sinzui said he *would* do new 1.22 release if required for this bug
<wallyworld> voidspace: --upload-tools will IIRC choose a jujud in the path - so you put the jujud that you want to test where the client can see it
<dimitern> voidspace, in this specific case, I agree
<voidspace> dimitern: \o/ :-)
<dimitern> voidspace, :)
<wallyworld> voidspace: and using a 1.25 client with all the series version fixes should work (that's my theory)
<voidspace> wallyworld: ok
<dimitern> voidspace, how about in other cases - new environment on older maas (<1.8)?
<wallyworld> voidspace: if we are to do a new 1.22, then all the series version fixes from tim and me would need backporting
<voidspace> wallyworld: right
<voidspace> dimitern: I care less I guess - but I don't think addressable containers are broken just because deploying thousands of them and using destroy-environment force causes an issue
<voidspace> dimitern: that's a very specific (and experimental) use case - that we have a fix for
<voidspace> dimitern: so even then, preventing addressable containers seems wrong to me
<voidspace> dimitern: not the world's worst wrong, only a minor wrong...
<voidspace> dimitern: so I would prefer a warning then too
<wallyworld> voidspace: we can do that backport if needed. but it would be intersting to try 1.25 client with custom 1.22 jujud push up via upload-tools
<voidspace> wallyworld: however, we are seeing --upload-tools *not work* on 1.22 (with a custom jujud in the path)
<voidspace> wallyworld: try it yourself, deploy 1.22 then try --upload-tools with only the new jujud in the path
<voidspace> wallyworld: you hit the wily bug
<wallyworld> voidspace: it would be intersting to see then error then so we can see where the issue is
<dimitern> voidspace, how about an extra flag - error by default, with the flag - warning and proceed?
<voidspace> dimitern: more flags! don't like it
<wallyworld> voidspace: ok, i'll try, but likely tomorrow
<wallyworld> need to finish ome other stuff tonight
<voidspace> wallyworld: I'll try again today and email you (currently working on a different environment)
<wallyworld> ok
<voidspace> wallyworld: and confirm that I can't upgrade from 1.22 to latest trunk
<voidspace> wallyworld: and you can believe me or not! :-)
<wallyworld> man, we need to fix our upgrades
<dimitern> voidspace, users are unlikely to see a mere warning in the case where juju is used as a tool (e.g. autopilot or a scripted deployer-based deployment)
<wallyworld> and figure out why CI didn't catch the issues
<voidspace> yeah
<wallyworld> voidspace:  i believe you but just don't have enough info yet
<voidspace> wallyworld: sure :-)
<wallyworld> :-P
<voidspace> wallyworld: I'll email you and you can tell me what more diagnostic information you need
<wallyworld> once i see the symptoms i can look at the code and see where the issue might be
<voidspace> dimitern: users are unlikely to hit the problem
<wallyworld> ok, and i'll try also
<voidspace> dimitern: and if they do we have a known fix for them
<voidspace> wallyworld: thanks
<dimitern> voidspace, which is?
<voidspace> dimitern: upgrade maas...
<dimitern> voidspace, and how are we communicating that to the users?
<voidspace> dimitern: all our available communication channels
<voidspace> dimitern: creating hundreds of containers and then destroying them is a pretty specific use case
<dimitern> voidspace, like the docs that suggest "oh, and by the way just in case set disable-network-management: true in your environments.yaml" ? :)
<voidspace> heh
<dimitern> voidspace, yeah, it's one of the cases we should support well - for density
<voidspace> dimitern: yep, I definitely agree we should make it work
<voidspace> we don't really have any choice in that matter
<voidspace> dimitern: new topic
<voidspace> dimitern: hopefully less contentious
<dimitern> voidspace, ok :)
<voidspace> dimitern: I'm trying to recreate the ignore-machine-addresses issue
<dimitern> voidspace, yeah?
<voidspace> dimitern: I have a deployed environment (current trunk) with a deployed unit of wordpress
<voidspace> dimitern: on that machine I've added a new nic
<voidspace> dimitern: this is my nic definition http://pastebin.ubuntu.com/13081446/
<voidspace> dimitern: I see "eth0:1" with that assigned (and spurious) 10.0 address when I do ifconfig
<voidspace> dimitern: but I don't see any issue with the machine from juju
<voidspace> dimitern: it isn't visibly picking up that new (wrong) address
<dimitern> voidspace, did you wait ~10m for the instance poller to try refreshing the machine addresses?
<voidspace> dimitern: no...
<voidspace> dimitern: :-)
<voidspace> dimitern: I'll go get coffee and see what happens
<dimitern> voidspace, :)
<voidspace> dimitern: thanks
<dimitern> voidspace, np, might not be the only thing, but I'd start there
<voidspace> dimitern: cool
<jam> dooferlad: frobware: I'm back around if you wanted to chat
<rogpeppe> i need a review of this please, towards fixing a juju critical bug: https://github.com/juju/persistent-cookiejar/pull/9
<rogpeppe> mgz_: ^
<rogpeppe> mgz_: i don't think that this will entirely fix CI problems with the cookies though
<jam> frobware, dooferlad, dimitern, voidspace: did any of you get a chance to play with the updated kvm_mass script?
<dooferlad> jam not I
<jam> k
<jam> dooferlad: did you have any other questions about bug #1510651?
<mup> Bug #1510651: Agents are "lost" after terminating a state server in an HA env <bug-squad> <ensure-availability> <juju-core:Triaged by dooferlad> <https://launchpad.net/bugs/1510651>
<dimitern> jam, not yet, I have to fix my vmaas first
<dooferlad> jam: I probably will have, just not yet.
<frobware> jam: not me either
<jam> k. I'm happy  to get feedback if there are thoughts about what could make it better
<jam> the next step I was considering was creating networks
<frobware> jam: I have 12+ nodes in various combos already.
<jam> say you could tell maas what networks and what spaces you wanted, and then it would make sure those existed in libvirt
<jam> frobware: hopefully a given node isn't in more than one maas, given each maas wants to control its subnet
<frobware> jam: no I have some half-baked naming scheme that mostly keeps me out of trouble.
<jam> frobware: heh. I was just using "m1-foo1" and was planning to go to "m2" if I set up another maas.
<voidspace> jam: not yet
<voidspace> dimitern: no dice
<voidspace> dimitern: it still reports imaginative-hose.maas as the dns name
<voidspace> dimitern: and I can still ssh to the machine via "juju ssh 1"
<voidspace> dimitern: I guess imaginative-hose still sorts earlier
<voidspace> dimitern: although 10.0 should sort before 172.16 - anything else I can do to trigger the bug
<dimitern> voidspace, but do you see the extra address you added?
<voidspace> dimitern: see it where?
<dimitern> voidspace, well, in the log - as part of the machine addresses
<voidspace> dimitern: I'll check
<voidspace> dimitern: not in all-machines.log
<voidspace> dimitern: I'll change the log level and check again
<voidspace> in 10 minutes...
<dimitern> voidspace, for the sake of the test, you could reduce the instance poller timeout
<voidspace> dimitern: yeah, adding better instrumentation would be a good idea too
<voidspace> dimitern: thanks
<dimitern> voidspace, looking at the network package's address sort order is: public IPs first, hostnames next (except "localhost"), cloud-local, machine-local, link-local
<voidspace> dimitern: I'll try and find the bug report and see if it has repro instructions
<dimitern> voidspace, there's also the piece of code in maas that *always* adds the hostname of the machine in the response of the provider addresses
<voidspace> dimitern: yeah, but the bug was a problem for maas users - so it is obviously possible to trigger it
<dimitern> voidspace, I think the difference is machines hosting units (and needing a preferred private address) and machines not hosting units (which only need the public address to display in status)
<dimitern> voidspace, so I'd try not add-machine + add extra IP, but deploy a unit and then add extra IP on that machine
<voidspace> dimitern: I did the latter anyway (used deploy and not add-machine)
<voidspace> I'll find the bug report
<rogpeppe> if you want master unblocked, could someone please review this? https://github.com/juju/persistent-cookiejar/pull/9
<dimitern> rogpeppe, reviewed
<rogpeppe> dimitern: ta!
<rick_h__> morning
<mup> Bug #1512371 opened: Using MAAS 1.9 as provider using DHCP  NIC will prevent juju bootstrap <juju-core:New> <https://launchpad.net/bugs/1512371>
<mup> Bug #1512371 changed: Using MAAS 1.9 as provider using DHCP  NIC will prevent juju bootstrap <juju-core:New> <https://launchpad.net/bugs/1512371>
<mup> Bug #1512371 opened: Using MAAS 1.9 as provider using DHCP  NIC will prevent juju bootstrap <juju-core:New> <https://launchpad.net/bugs/1512371>
<cmars> wwitzel3, can i get a review of http://reviews.vapour.ws/r/3040/ ? (fixes-1511717)
<cmars> wwitzel3, thanks!
<mgz_> cmars: if a user has both an old juju client installed, and a newer juju in ~/.local or something for testing a shiny new feature
<mgz_> do we break them?
<cmars> mgz_, hmm.. i guess such a user would need to use separate JUJU_HOME directories in that case, wouldn't they?
<mgz_> well, I know they don't in practice
<cmars> mgz_, but they'd have to, because the newer juju will have providers that the old juju doesn't understand
<mgz_> when I give someone a binary to test I don't say "only use this with JUJU_HOME=/tmp"
<mgz_> natefinch: I believe we are still on step #1: make the unit tests pass with go 1.5
<natefinch> mgz_: oh man.  is there a list of what needs to be fixed?  The LXD provider is dependent on go 1.3+ due to limitations with the LXD Go library
<mgz_> the remaining issues with run-unit-tests-wily-amd64 look like big environmental things rather than nice easy things like map ordering
<mgz_> bug 1494951 looks like one place to start
<mup> Bug #1494951: Panic "unexpected message" in vivid and wily tests <bug-squad> <ci> <intermittent-failure> <panic> <unit-tests> <wily> <juju-core:Triaged> <https://launchpad.net/bugs/1494951>
<natefinch> mgz_: do you know if there's a team assigned to get us working on 1.5?
<mgz_> I know that some of the other-way-uppers have fixed bugs relating to it, but just as good citizens
<mfoord> dimitern: ping
<katco> frobware 's team is on bug squad i think
<katco> natefinch: mgz_: frobware: seems like getting 1.5 bugs fixed needs to be high priority
<ericsnow> with a plugin provider it wouldn't be a short-term issue...
<ericsnow> just sayin' :)
<mgz_> the other thing I see a lot of in the history is worker/peer group related test failures
<natefinch> ericsnow: we'd still need 1.5 support in trusty, and I don't think we'd also have 1.2 in trusty, so that would be a problem
<ericsnow> natefinch: true
<mgz_> yeah, we can't backport toolchain to trusty
<frobware> katco, ack
<dimitern> mfoord, pong
<mfoord> dimitern: reading through the ignore-machine-addresses bug it looks like it only affected containers
<mfoord> dimitern: is that true?
<mfoord> dimitern: https://bugs.launchpad.net/juju-core/+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>
<mfoord> I assume without addressable containers on as they're starting pre-1.24
<dimitern> mfoord, yeah
<mfoord> also it looks hard to reproduce (timing related)
<mfoord> dimitern: so to reproduce this I really need to add an lxc container
<mfoord> and add the virtual nic there (?)
<mfoord> I have a build with extra instrumentation and a shorter poll time on the instancepoller
<dimitern> mfoord, let me think
<natefinch> mgz_: how can we require 1.5 if 1.5 is not in trusty?
<mfoord> although it looks to me like the instancepoller only requests provider addresses and that machine addresses are done by the machiner
<dimitern> mfoord, yeah, the machine addresses are updated on machiner startup
<mfoord> dimitern: so really rebooting the machine should trigger it
<mfoord> dimitern: I'll add a container and reboot
<mfoord> once the container is up
<dimitern> mfoord, no need to reboot - just restart the machine agent
<mfoord> dimitern: but should I add the extra nic to the container or to the host
<mfoord> or both just to be sure...
<dimitern> mfoord, I guess both, and that address should be like 10.0.0.x
<mfoord> dimitern: ok
<mfoord> thanks
<mgz_> natefinch: you can't, but how are you running an lxd provider on trusty?
<natefinch> mgz_: Is trusty never having anything beyond juju 1.25?
<mgz_> natefinch: that's not the plan, but I don't know what the intention is with your lxd provider work
<natefinch> mgz_: our intention is to have a juju provider that uses lxd in 1.26
<mgz_> so, what's your plan with the existing backports to trusty scheme?
 * mgz_ enjoys circular conversations
<mfoord> our normal plan is to leave that up to QA to sort out...
<natefinch> ^^
<mgz_> how to release software you're writing is not someone else's problem
<natefinch> mgz_: it is when someone else is putting up the restrictions while simultaneously telling us to deliver software that has a problem with those restrictions
<mgz_> you do know those two things are not from me, and are different parties, right?
<natefinch> mgz_: absolutely.  Sorry if my tone indicated I thought it was your fault.  I know it's not.
<mgz_> the distro, and sanity in general, limits what we can do in terms of backports
<mgz_> and mark, and the desire for shiny features, wants everyone to have a great experience
<natefinch> mgz_: I guess the answer is, people at a higher pay grade are going to have to figure out what to do
<natefinch> mgz_: the LXD provider will fail gracefully if lxd is not installed... but the code still requires 1.5 to build.
<mgz_> there's so such thing as a !build for go versions, right...
<mgz_> we can always do the equivelent in the debian rules, just rm the package
<natefinch> mgz_: no, but you can just set flags at build time to trigger !build code
<natefinch> mgz_: however, having the same codebase support both 1.2 and 1.5 would seem to be adding a lot of developer/qa/etc overhead.... but again, that's above my pay grade.
<mgz_> anyway, the first thing is getting it working well in development
<mgz_> natefinch: well, it's what we do currently, and isn't too hard
<mgz_> I know it's anti-go, but python code manages to support multiple *interpreter* versions okay
<mgz_> trusty has go 1.21. vivid has go 1.33. wily/xenial have go 1.5.1
<mgz_> +.
<alexisb> mgz_, natefinch trusty will need 1.5 for lxd as well as juju
<alexisb> the current plan is to work on getting it into backports
<alexisb> so it can be used both by juju and lxd
<mgz_> alexisb: actual backports? or srued?
<alexisb> mgz_, actual backports
<alexisb> sru not needed
<mgz_> okay, ace. so, the provider failing neatly is a requirement.
<mup> Bug #1512399 opened: ERROR environment destruction failed: destroying storage: listing volumes: Get https://x.x.x.x:8776/v2/<UUID>/volumes/detail: local error: record overflow <amulet> <openstack> <uosci> <juju-core:New> <https://launchpad.net/bugs/1512399>
<mgz_> anyway, this is something to work out early, thanks for asking nate, we do want to know exactly how we're getting the lxc provider distributed.
* You're now known as ubuntulog2
<rogpeppe> mgz_: do you know whether cookie isolation in CI has been done yet?
<mgz_> jog set the env var as you'd discussed, not sure it's everywhere it's needed but at least in the obvious place.
<mgz_> hm, actually that change got reverted
<mgz_> rogpeppe: gimme a sec, I'll find out.
<jog> mgz_, It broke other tests
<jog> older versions of Juju
<mup> Bug #1511771 changed: regression setting tools-metadata-url <blocker> <ci> <regression> <set-env> <juju-core:Triaged> <https://launchpad.net/bugs/1511771>
<mup> Bug #1511771 opened: regression setting tools-metadata-url <blocker> <ci> <regression> <set-env> <juju-core:Triaged> <https://launchpad.net/bugs/1511771>
<mup> Bug #1511771 changed: regression setting tools-metadata-url <blocker> <ci> <regression> <set-env> <juju-core:Triaged> <https://launchpad.net/bugs/1511771>
<mup> Bug #1511771 opened: regression setting tools-metadata-url <blocker> <ci> <regression> <set-env> <juju-core:Triaged> <https://launchpad.net/bugs/1511771>
<mup> Bug #1511771 changed: regression setting tools-metadata-url <blocker> <ci> <regression> <set-env> <juju-core:Triaged> <https://launchpad.net/bugs/1511771>
<natefinch> ericsnow: you mentioned in your review of my better error message PR that I should rebase against either your or wayne's personal branches... I hesitate to rebase against a personal branch. Are you guys going to get one of those things landed soon so I can just rebase against the main lxd branch?
<ericsnow> natefinch: just waiting for your reviews :)
<natefinch> ericsnow: that the support using local lxd as remote?
<ericsnow> natefinch: http://reviews.vapour.ws/r/3012/ and http://reviews.vapour.ws/r/3013/
<natefinch> ericsnow: ok, yeah, I'm looking at those now.  Guess it'll be an unofficial review day for me
<ericsnow> natefinch: thanks
<frobware> mfoord, a heads-up on our recent changes to rendering /e/n/i --- https://bugs.launchpad.net/juju-core/+bug/1512371
<mup> Bug #1512371: Using MAAS 1.9 as provider using DHCP  NIC will prevent juju bootstrap <bug-squad> <maas-provider> <network> <juju-core:Triaged> <https://launchpad.net/bugs/1512371>
<natefinch> ericsnow: gah... saw the copied file from github.com/lxd, so I went to look at their repo for licensing... and they don't even have a LICENSE file.  Geez
<ericsnow> natefinch: yep
<cmars> mgz_, here's a cookie update for 1.25, what do you think? http://reviews.vapour.ws/r/3041/
<natefinch> ericsnow: wow, that lxd/shared.GenCert function is awful.  Have you filed a bug to their project to de-awful it?
<ericsnow> natefinch: was waiting :)
<natefinch> ericsnow: for what?
<ericsnow> natefinch: until we had settled down on our LXD provider work
<natefinch> ericsnow: If that's the only way to create certs for LXD, seems pretty awful regardless of what anyone else is doing
<ericsnow> natefinch: agreed
<natefinch> ericsnow: I'm willing to write a bug now if you'd prefer.
<ericsnow> natefinch: sure, though I'd prefer the reviews first :)
<natefinch> ericsnow: right right
<mfoord> frobware: I saw
<mfoord> frobware: ouch
<mfoord> frobware: although I don't think it's the recent changes to be fair, I think it's maas 1.9
<mfoord> frobware: will look tomorrow
<mfoord> EOD
<davechen1y> thumper: afk breakfast
<davechen1y> i'll call you after taht
<mup> Bug #1512481 opened: register dns names for units in MAAS <juju-core:New> <https://launchpad.net/bugs/1512481>
<mup> Bug #1512481 changed: register dns names for units in MAAS <juju-core:New> <https://launchpad.net/bugs/1512481>
<mup> Bug #1512481 opened: register dns names for units in MAAS <juju-core:New> <https://launchpad.net/bugs/1512481>
<thumper> davechen1y: ack
<cmars> hey waigani i'd like to try writing a CI test. where should I start?
<waigani> cmars: https://github.com/juju/juju/wiki/ci-tests :)
<cmars> waigani, thanks
<waigani> np
<perrito666> ah finally, the server holding my irc got cut from part of the world
<perrito666> (and by cut I mean something sliced the fiber)
<mwhudson> perrito666: https://www.reddit.com/r/cablefail/comments/1y2ei8/lost_in_the_woods_call_a_backhoe/cfh4wox
<perrito666> lol
<davechen1y> thumper: ping
#juju-dev 2015-11-03
<axw> wallyworld: would you kindly create me a feature branch for azure?
<wallyworld> sure
<wallyworld> axw: done
<axw> wallyworld: thanks
<thumper> wallyworld: just once...
<thumper> wallyworld: haha RWC 2015 to the All Blacks!!!
 * thumper is done now
<wallyworld> sigh
<wallyworld> i even hopped up at 2am to watch :-(
<thumper> Got the family up early to watch it in a pub in Queenstown
<thumper> getting the girls up a 4:30am was interesting
<wallyworld> worth it though
<thumper> yeah, pub was packed, even one guy with a wallabies jersey on
<wallyworld> poor bastard
<thumper> yeah, I thought he was pretty game
<wallyworld> especially if we had won
<thumper> heh
<thumper> TBH though, I did think that the All Blacks were the better team on the day
<anastasiamac> thumper: wasnt it yesterday? did u celebrate this whole time?
<thumper> the frustrating times
<thumper> are when you feel your team played better but gets pipped at the post
<thumper> anastasiamac: it was Sunday morning
<thumper> anastasiamac: but I was away for a wedding over the weekend, and was driving home yesterday
<anastasiamac> thumper: i watched haka - that's as far as I go :D
<anastasiamac> oh and richie mccaw
<thumper> anastasiamac: :)
<wallyworld> thumper: do you have an eta on removing mult env feature flag in master?
<wallyworld> or shoudl i say, mrging in the feature branch?
<thumper> wallyworld: wat?
<thumper> feature branch was merged for 1.25
<thumper> flag being removed for 1.26
<wallyworld> thumper: yeah, sorry, what you said above is what i meant
<wallyworld> eta for flag removal from master?
<thumper> soon
<thumper> perhaps this week
<thumper> I'm actively working on it
<wallyworld> yay, ok
<wallyworld> i'll take advantage of that for cross mdel stuff
 * thumper nods
 * thumper is heading away from internet
<thumper> I have to take Maia to jui jitsu, taking laptop and working from the gym while she does her thing
<thumper> soon
<natefinch> wallyworld: do you know what hotel we're staying at in oakland/
<anastasiamac> natefinch: is it not Marriott Oakland City Center?
<anastasiamac> cmars: ping?
<natefinch> anastasiamac: I don't know.  Did it say that somewhere?
<anastasiamac> it's on the spreadsheet, hotel tab
<natefinch> anastasiamac: arg... tabs in the spreadsheet.  Honestly, who uses a spreadsheet to disseminate long-form information :/
<anastasiamac> :D
<anastasiamac> natefinch: i hear ur pain \o/
<natefinch> anastasiamac: I must have looked at that spreadsheet three times and never saw the tabs :/
<davechen1y> spreadsheets are for making lists of things, duh
<davechen1y> word documents are for distributing screenshots
<natefinch> *shudder*
<anastasiamac> :P
<natefinch> trying to figure out if I should just fly into SFO and take a cab, rather than trying to get to oakland airport, which takes 2 hours extra and an extra layover
<natefinch> looks like it's 15 minutes from Oakland airport and 30 from SFO
<anastasiamac> it depends - do u like flying?
<anastasiamac> u r very lucky to have a choice :D
<anastasiamac> i'd imagine flying to Oakland will also be a smaller plane than to SFO (m not gr8 fun of small planes)
<wallyworld> natefinch: marriott
<wallyworld> 1001 broadway
<natefinch> wallyworld: thanks.  realized I was being dumb and missed the hotels tab on the spreadsheet.  Someday I'll remember that's there.
<wallyworld> yeah, easy to do
<cherylj> axw: ping?
<axw> cherylj: pong
<cherylj> hey axw :)  I'm looking at bug 1512399 and it looks like the error they're getting is a TLS error
<mup> Bug #1512399: ERROR environment destruction failed: destroying storage: listing volumes: Get https://x.x.x.x:8776/v2/<UUID>/volumes/detail: local error: record overflow <amulet> <openstack> <uosci> <juju-core:Triaged> <https://launchpad.net/bugs/1512399>
<cherylj> and I'm wondering if it's a config error?  or if you've seen that in your testing?
<axw> cherylj: I have not seen that. we have a separate API for Cinder, so it's most likely we're not configuring the client for it the same way we do the other clients
<cherylj> axw: ok, thanks!  I'll keep looking
<davechen1y> running the juju/state tets
<davechen1y> i can see mongo using 1/2 a core
<davechen1y> that seems excessive
<davechen1y> can anyone confirm ?
<davechen1y> select(9, [7 8], NULL, NULL, {0, 10000}) = 0 (Timeout)
<davechen1y> billions and billions of these
<natefinch> davechen1y: yeah, usually 40-50% of a core for me most of the time, except when it jumps to the occasionaly 180%
<mup> Bug #1512566 changed: Panic in deployerSuite unittests while attempting to connect to mongo <ci> <test-failure> <unit-tests> <juju-core:New> <https://launchpad.net/bugs/1512566>
<davechen1y> i wonder if mongo 3.0 will be better
<natefinch> not sure if a faster car will make towing the giant boulder behind us much easier
<mup> Bug #1512566 opened: Panic in deployerSuite unittests while attempting to connect to mongo <ci> <test-failure> <unit-tests> <juju-core:New> <https://launchpad.net/bugs/1512566>
<natefinch> ....or some other analogy saying our tests suck
<davechen1y> any "database" that consumes 50% cpu with a single client
<davechen1y> owns the market on suckage
<davechen1y> oh fucking golf cla
<davechen1y> now mongo used up all my /tmp
<davechen1y> all 8gb
<mup> Bug #1512566 opened: Panic in deployerSuite unittests while attempting to connect to mongo <ci> <test-failure> <unit-tests> <juju-core:Triaged> <https://launchpad.net/bugs/1512566>
<mup> Bug #1512569 opened: UniterSuite.TestRebootNowKillsHook fails with: uniter still alive <ci> <test-failure> <unit-tests> <juju-core:Triaged> <https://launchpad.net/bugs/1512569>
<mup> Bug #1512569 changed: UniterSuite.TestRebootNowKillsHook fails with: uniter still alive <ci> <test-failure> <unit-tests> <juju-core:Triaged> <https://launchpad.net/bugs/1512569>
<mup> Bug #1512569 opened: UniterSuite.TestRebootNowKillsHook fails with: uniter still alive <ci> <test-failure> <unit-tests> <juju-core:Triaged> <https://launchpad.net/bugs/1512569>
<fwereade_> axw, http://reviews.vapour.ws/r/3045/ may be relevant to your interests
<fwereade_> anyone else, http://reviews.vapour.ws/r/3032/ is a few days old and could use a review (and should be trivial)
<voidspace> fwereade_: looking at the second
<fwereade_> voidspace, ta
<voidspace> waiting for an environment to bootstrap anyway
<axw> fwereade_: my brain is a bit fried, will take a look tomorrow. skimming through it looks good. NewWorker in config bothers me, but will have to ruminate
<fwereade_> axw, yeah, that's the main thing I'm ambivalent about
<fwereade_> axw, I can't think of a good reason not to do it, though :-/
<fwereade_> axw, (NewFacde less bothersome?)
<fwereade_> axw, (I feel they're as bad as one another)
<fwereade_> axw, anyway don't think about it now :)
<axw> fwereade_: a little :)  NewFacade bothers me less because you're configuring an external resource
<axw> fwereade_: whereas the worker is an internal detail
<axw> fwereade_: I guess neither would bother me if the manifold were in a different package
<fwereade_> axw, yeah, I've been feeling some of them pulling that way as well
<fwereade_> axw, and I don't think a given worker type will necessarily always want the same manifold
<fwereade_> axw, but for now, it seems least wrong to put them with the workers
<fwereade_> will think more on it
<voidspace> fwereade_: LGTM bar one typo
<fwereade_> voidspace, cheers
<fwereade_> http://reviews.vapour.ws/r/3045/diff/#
<voidspace> frobware: looks like I an upgrade from 1.22.8 to 1.24 tip with upload-tools
<voidspace> which is good news
<frobware> voidspace, yep
<dimitern> my NUCs et al have just arrived!
<perrito666> morning
<perrito666> dimitern: I envy you a lot right now
<dimitern> perrito666, :) don't - considering the amount of work we need to do in the next 3 weeks on those NUCs
<rick_h__> go go gadget dimitern
<dimitern> rick_h__, :) indeed
<dimitern> rick_h__, nice ODS talk btw!
<rick_h__> dimitern: thanks
<jam> rick_h__: are you around for the meetup ?
<dimitern> frobware, oh sorry, omw
<rick_h__> jam: yes sorry
<voidspace> dimitern: is the maas meeting on today?
<dimitern> voidspace, yep
<voidspace> dimitern: thanks
<voidspace> frobware: I was wrong by the way - 1.22.8 to 1.24 tip fails. It just fails without error message.
<cmars> why is master still blocked? is CI running on it yet?
<mup> Bug #1512718 opened: Leader election fails with "leadership failure: leadership manager stopped" <landscape> <juju-core:New> <https://launchpad.net/bugs/1512718>
<natefinch> ericsnow: did we update the version of reviewboard we're using?  Seems like it handles file moves a lot better than it did just a week or so ago.
<frobware> cherylj, ping - does your vMAAS setup have a static IP range set for the cluster controller / interface?
<ericsnow> natefinch: nope :)
<natefinch> ericsnow: weird, I swear the last time I looked at your renaming review, it was all screwed up because reviewboard just showed renames as deletes and adds, but now it looks fine.  Maybe I'm just crazy.
<perrito666> natefinch: rb is a sentient being and tries to make you doubt your sanity
<natefinch> perrito666: I can believe it
<perrito666> off course you can, it is true
<cherylj> frobware: I have it set up to use a particular virtual network I created
<perrito666> does anyone know exactly what is responsible for ~ expansion? I am trying to do an exec.Command with ~ on a path and it is not being expanded
<voidspace> perrito666: it's the shell that does it not the os
<perrito666> voidspace: mm, I presume that for this to work the process I should be running with exec.Command its bash
<voidspace> perrito666: that would work, but beware of windows
<voidspace> perrito666: or you can do the expansion yourself
<perrito666> I could totally wear a shirt with that "beware of windows"
<perrito666> voidspace: true
<voidspace> :-)
<rogpeppe> trivial change to environs/config, so that I don't need to do an error string comparison... anyone want an easy review? http://reviews.vapour.ws/r/3047/
<cmars> why is master still blocked? is CI running on it yet?
<cmars> sinzui, mgz_ ^^
<sinzui> cmars: ci hasn't tested a pass yet. I believe master will be retested in a few hours.
<cmars> sinzui, ok, thanks
<frobware> cherylj, do you have time for a quick HO?
<cherylj> frobware: I have 8 minutes :)  is that enough time?
<frobware> yep
<frobware> cherylj, https://plus.google.com/hangouts/_/canonical.com/juju-sapphire
<cherylj> I'm there
<mup> Bug #1512782 opened: wget cert issues causing failure to create containers <cloud-installer> <juju-core:Triaged> <https://launchpad.net/bugs/1512782>
<mup> Bug #1512782 changed: wget cert issues causing failure to create containers <cloud-installer> <juju-core:Triaged> <https://launchpad.net/bugs/1512782>
<mup> Bug #1512782 opened: wget cert issues causing failure to create containers <cloud-installer> <juju-core:Triaged> <https://launchpad.net/bugs/1512782>
<rogpeppe> mgz_: any chance we might get a CI run on master today?
<mgz_> rogpeppe: it'll happen shortly
<rogpeppe> mgz_: cool
<natefinch> and then the stampede to get stuff landed before it breaks again
<rogpeppe> mgz_: istm that 24 hours to unblock after critical bugfix gets landed is probably too long
<natefinch> ^ +1
<rogpeppe> for our feature branch it was more like 7 days.
<natefinch> mgz_: is it a resources problem?  i.e. do we not have an environment dedicated to running CI on master?
<mgz_> natefinch: every ci run is against a bunch of environments
<natefinch> mgz_: sorry, overloaded term.  Do we not have dedicated hardware for CI runs on master?
<natefinch> mgz_: maybe a better way to phrase it is - it sounds like CI on master can be blocked by other CI runs.  Is there a way we can make that not so?
<mgz_> well, we're still talking about a whole bunch of machines in different cloud provuders
<mgz_> so, two things
<mgz_> we're getting new hardware for maas Soon hopefully, which is a major bottleneck
<natefinch> good
<mgz_> also abentley has been getting parallel streams working over the past few weeks, which means we can run more than one revision in across clouds
<mgz_> anyway, the reson this was slow is that the rev was tested and failed (for unrelated env issues, machine ran out of root disk),
<mgz_> so needed someone to wake up and get it run again, any aussie could have done that
<natefinch> obviously we need to hire an aussie for the QA team
<katco> mgz_: hey you all had started writing ci tests for the rackspace provider, correct?
<mgz_> katco: there's not really tests to write
<mgz_> we just need rackspace creds we can use, and then we can use the existing provider tests
<katco> mgz_: ah great! is anything blocking you on getting those creds?
<mgz_> well, I have a non-functional personal account,
<mgz_> ideally we'd have a system of getting creds as a company, but that's never really happened in the past
<katco> mgz_: i'll ping alexisb to see what we need to do
<katco> mgz_: i also need to bug someone about what it would take to get CI testing the LXD provider
<mup> Bug # changed: 1302118, 1392814, 1464304, 1485784
<mup> Bug #1512847 opened: Unit suffix incremented after fresh post-destroy-service deploy <juju-core:New> <https://launchpad.net/bugs/1512847>
<thumper> haha
<thumper> bug 1512847 now complaining about our "correct" behaviour
<mup> Bug #1512847: Unit suffix incremented after fresh post-destroy-service deploy <juju-core:New> <https://launchpad.net/bugs/1512847>
 * thumper wonders what the original bug number was that outlined the behaviour....
<mup> Bug #1512847 changed: Unit suffix incremented after fresh post-destroy-service deploy <juju-core:New> <https://launchpad.net/bugs/1512847>
<mup> Bug # opened: 1302118, 1392814, 1464304, 1485784
<mup> Bug # changed: 1302118, 1357045, 1392814, 1464304, 1485784, 1494476, 1498982, 1500703, 1500721, 1500769, 1500803, 1501173, 1501559, 1501637, 1501642, 1501710, 1505648
<mup> Bug #1512847 opened: Unit suffix incremented after fresh post-destroy-service deploy <juju-core:New> <https://launchpad.net/bugs/1512847>
<mup> Bug # opened: 1357045, 1494476, 1498982, 1500703, 1500721, 1500769, 1500803, 1501173, 1501559, 1501637, 1501642, 1501710, 1505648
<mup> Bug # changed: 1357045, 1494476, 1498982, 1500703, 1500721, 1500769, 1500803, 1501173, 1501559, 1501637, 1501642, 1501710, 1505648
<thumper> sinzui: master is still blocked?
<thumper> it is the same bug as yesterday...
<sinzui> yes, thumper master is being retested now
<thumper> why has it taken over 24 hours? just curious
<davecheney> thumper: https://github.com/golang/go/issues/13137
<davecheney> upstream issue for the ssh blocker that prevents me moving the ssh code to juju/utils
<davecheney> thumper: i also tried adding dependencies.tsv to juju/utils to pin the ssh version
<davecheney> by our build bot doesn't understand that
<natefinch> thumper: I asked the same question earlier, sounds like the build machine ran out of disk space, so needed manual intervention
<thumper> ah
 * natefinch needs to write a bot that'll watch master's CI status and auto-$$merge$$ his PR when master unblocks.
<mup> Bug #1512875 opened: juju 1.25.0 using MAAS 1.9-beta2 juju incorrectly reports the private address <addressability> <maas-provider> <networking> <juju-core:New> <https://launchpad.net/bugs/1512875>
<mup> Bug #1512875 changed: juju 1.25.0 using MAAS 1.9-beta2 juju incorrectly reports the private address <addressability> <maas-provider> <networking> <juju-core:New> <https://launchpad.net/bugs/1512875>
<sinzui> wallyworld: can you review http://reviews.vapour.ws/r/3050/
<wallyworld> sure
<wallyworld> another difficult one
<mup> Bug #1512875 opened: juju 1.25.0 using MAAS 1.9-beta2 juju incorrectly reports the private address <addressability> <maas-provider> <networking> <juju-core:New> <https://launchpad.net/bugs/1512875>
<mup> Bug #1512847 changed: Unit suffix incremented after fresh post-destroy-service deploy <juju-core:Invalid> <https://launchpad.net/bugs/1512847>
<mup> Bug #1367962 changed: HTML entities accidentally escaped <docs> <juju-core:Fix Released by cjohnston> <https://launchpad.net/bugs/1367962>
<mup> Bug # changed: 1439375, 1456851, 1476918, 1486254, 1492095, 1497241, 1500283, 1502202, 1506353, 1509097, 1509292
<mup> Bug # opened: 1439375, 1456851, 1476918, 1486254, 1492095, 1497241, 1500283, 1502202, 1506353, 1509097, 1509292
<mup> Bug # changed: 1439375, 1456851, 1476918, 1486254, 1492095, 1497241, 1500283, 1502202, 1506353, 1509097, 1509292
<anastasiamac> cmars: ping :D
<mup> Bug #1511717 changed: Incompatible cookie format change <blocker> <ci> <compatibility> <regression> <juju-core:Fix Released by cmars> <juju-core 1.25:In Progress by cmars> <juju-core 1.26:Fix Committed by cmars> <https://launchpad.net/bugs/1511717>
<mup> Bug #1511717 opened: Incompatible cookie format change <blocker> <ci> <compatibility> <regression> <juju-core:Fix Released by cmars> <juju-core 1.25:In Progress by cmars> <juju-core 1.26:Fix Committed by cmars> <https://launchpad.net/bugs/1511717>
<mup> Bug #1511717 changed: Incompatible cookie format change <blocker> <ci> <compatibility> <regression> <juju-core:Fix Released by cmars> <juju-core 1.25:In Progress by cmars> <juju-core 1.26:Fix Committed by cmars> <https://launchpad.net/bugs/1511717>
<perrito666> anastasiamac: send me the song name
<davecheney> thumper: upstream told us to go stuffed on the ssh problem
<davecheney> thumper: where did the go 1.5 discussion go after we talked yesterday ?
<anastasiamac> perrito666: tyvm for reminder :D i will as soon as my DJ gets back to me
<thumper> davecheney: sorry, dropped the ball on that email, will do it now
<davecheney> thumper: thanks
<davecheney> what's going on with the build
<davecheney> is it unblocked uet ?
<davecheney> oh goody it is
<thumper> waigani: I've just created a feature branch "controller-rename"
<thumper> which I'll retarget my landings against
<waigani> thumper: that's a good idea
<thumper> I have a feeling we may break some CI tests :)
<thumper> so best to get it in a feature branch IMO
<thumper> especially taking off the feature flag
<waigani> that will help me land this destroy*System* work too
<waigani> as I can just finish off the logic and then merge in the controller stuff
<thumper> waigani: also means we can do final checks to make sure we catch all the system names
<waigani> right
<thumper> waigani: probably best to see if we can get your stuff landed first
 * thumper hopes
<waigani> okay
<waigani> on it :)
<davecheney> sinzui: ping
<davecheney> sinzui: i have a problem trying to land https://github.com/juju/utils/pull/167
<mgz_> davecheney: did you read my comment?
<davecheney> the build bot doesn't seem to respect dependencies.txt
<davecheney> mgz_: thanks for replying
<davecheney> i added a dependencies.tsv to pin the crypto repo to a specific revision
<davecheney> but the bot doesn't appear to use it
<mgz_> davecheney: you need to add *all* the dependencies
<davecheney> ok
<davecheney> but how does the bot know ?
<mgz_> I can make the bot get the deps with godeps
<davecheney> i can add all the deps to that PR
<davecheney> can you switch the bot to using godeps please ?
<mgz_> but it's either go get *or* godeps, we can't mix and match
<davecheney> understood
<davecheney> i'll ammend the PR to have a complete set of dependencies
<mgz_> so, I can switch the bot, and the branch will still fail for now
<mgz_> k
<davecheney> give me a few mins
<davecheney> won't take long
<mgz_> this is baiscally, in the config of the github-merge-juju-utils job (access is in the consoles.txt file in cloud-city),
<mgz_> s/--go-get-all/--tsv-path $PROJECT_PATH/dependencies.tsv/
<davecheney> mkay
<mgz_> anyway, retry when ready
<davecheney> mgz_: thanks, i'll be able to fix this on my own if I find deps I haven't pinned
<cmars> master be all like: https://i.giphy.com/11Ss9q3F4zf5VC.gif
<cmars> anastasiamac, pong
<anastasiamac> cmars: send u an email but if u want to HO, can do too :D
<cmars> anastasiamac, right, blueprint. i'll try to update it soon
<anastasiamac> cmars: \o/
<anastasiamac> cmars: love the pic btw :D indeed feels like when it unblocks :P
#juju-dev 2015-11-04
<davecheney> mgz_: thanks for your help
<davecheney> this is working a treat
<mgz_> davecheney: ace
<davecheney> a few small issues and i'll be able to land this branch
<davecheney> thumper: a pint of grog for mgz_ !
<thumper> awesome
<thumper> hmm....
<thumper> I'm seeing state/leadership package sometimes timeout after 20 minutes
 * thumper smells race
<thumper> but my --race doesn't work
<mwhudson> it's totally possible to have logical races without memory races
<thumper> sure
<axw> thumper: why discard that PR about server->controller? is that rename not happening anymore?
<thumper> axw: it is, but I'm going to retarget it against the new 'controller-rename' feature branch
<thumper> as I feel that I'm going to break CI
<axw> thumper: okey dokey
<thumper> especially as I change some of the command stuff
<thumper> and remove the feature falg
<thumper> so I thought I retarget it all
<thumper> hopefully a very short lived feature branch
<thumper> as conflicts against master are going to be a biatch
<axw> thumper: did you see my latest email about multi-env vs. azure?
<thumper> I think so
 * thumper goes to look again
<axw> thumper: did not get a reply. just curious about how we're supposed to do create/destroy when an env has resources shared between machines
<axw> setup/teardown, a la bootstrap/destroy
<thumper> like what?
<axw> thumper: in the case of azure: a resource group, subnet, network security group, storage account
<axw> thumper: each env will have its own everything, except for a single virtual network that all envs are connected to
<thumper> ok...
<thumper> well, shouldn't we just hook into the create environment, and destroy environment endpoints?
<thumper> when we destroy a controller, we take down all the hosted environments first
<thumper> axw: waigani has been refactoring all our destruction code so it is nicer and more async
<axw> thumper: yeah, but atm EnvironProvider just has "PrepareForCreateEnvironment" - I'm using htis but it doesn't feel quite right
<axw> thumper: sounds good
<thumper> you should use the create environment, not the prepare
<axw> thumper: there is no "create environment" in EnvironProvider, at least not on master. maybe in a feature branch?
<thumper> where are you looking?
<thumper> hmm...
<axw> thumper: https://github.com/juju/juju/blob/master/environs/interface.go
 * thumper thinks...
 * thumper looks
<thumper> axw: actually, there is currently no function we call at all in the provider when creating a new environment
<thumper> before there was never anything to execute
<thumper> hmm...
<axw> thumper: so I think we need a CreateEnvironment as well as a PrepareForCreateEnvironment
<thumper> I think you may be right
 * thumper greps for the Prepare...
<axw> thumper: PrepareForCreateEnvironment is called (twice), and it is usable
<thumper> hmmm
<thumper> yeah, checking for valid Config
<axw> thumper: i.e. I've got multi-env working in azure
<thumper> axw: it feels better to have a separate CreateEnvironment call
<thumper> that we call just once
<axw> thumper: +1
<axw> thumper: also, it's not obvious why Prepare is called twice (once before assigning UUID, once after) - would be good to have better docs on that
<thumper> I believe it is the two step call we do
<thumper> which we are looking to fix
<thumper> the first is to ask for a config skeleton
<thumper> and then the validation when the user passes it back
<thumper> but to be honest, I'm not entirely clear
<thumper> we are wanting to make the juju cli do the same as jem
<thumper> and have all providers supply the configschema
<thumper> oh...
<thumper> can you make the new azure provider supply the configschema?
<thumper> not sure if the old one did
<axw> thumper: it didn't. I'll add it to the list.
<thumper> axw: here is that branch retargeted to the controller-rename branch http://reviews.vapour.ws/r/3053/
<wallyworld> axw: small one if you have a moment https://github.com/juju/charmrepo/pull/36
<menn0> thumper: http://reviews.vapour.ws/r/3054/
<menn0> thumper: adds "no tail" support to state.LogTailer
 * thumper looks
<thumper> menn0: why do we need to call tailer.Stop when we said "don't tail" ?
<menn0> thumper: you don't ...
<menn0> thumper: it's just in case the tailer isn't working during tests
<menn0> thumper: like when I wrote the test but NoTail wasn't implemented yet
<menn0> thumper: happy to reemove it if you think it's confusing
<thumper> perhaps just a comment would be enough
 * thumper sighs
<thumper> state/leadership is failing for me again...
<menn0> thumper: i've responded to the review
<axw> wallyworld: reviewed
<wallyworld> ty
<thumper> waigani: http://reviews.vapour.ws/r/3056/
<thumper> waigani: it is the earlier branch retargetted and many of the missed systems renamed too
<mup> Bug #1454466 changed: Deployment times out waiting for relation convergence - nvp-transport-node in installing state <deploy> <oil> <juju-core:Expired> <juju-deployer:Invalid>
<mup> <neutron-gateway (Juju Charms Collection):Expired> <nvp-transport-node (Juju Charms Collection):Expired> <https://launchpad.net/bugs/1454466>
<mup> Bug #1454466 opened: Deployment times out waiting for relation convergence - nvp-transport-node in installing state <deploy> <oil> <juju-core:Expired> <juju-deployer:Invalid>
<mup> <neutron-gateway (Juju Charms Collection):Expired> <nvp-transport-node (Juju Charms Collection):Expired> <https://launchpad.net/bugs/1454466>
<mup> Bug #1454466 changed: Deployment times out waiting for relation convergence - nvp-transport-node in installing state <deploy> <oil> <juju-core:Expired> <juju-deployer:Invalid>
<mup> <neutron-gateway (Juju Charms Collection):Expired> <nvp-transport-node (Juju Charms Collection):Expired> <https://launchpad.net/bugs/1454466>
<waigani> thumper: shipit with a question about "controller environment"
<davecheney> thumper: menn0 axw http://reviews.vapour.ws/r/3057/
<axw> davecheney: shipit
<menn0> axw: that was awfully fast!
<davecheney> boom
<axw> menn0: awfully easy review :)
<davecheney> -2700 lines -> ship it!
<axw> heh
<menn0> I think axw has a bot that just automatically replies with ship it
<axw> ;)
<axw> in seriousness, I wish we had one for back/forwardports
<axw> or a way to just not post to RB
<wallyworld> axw: sorry, one more https://github.com/juju/charmrepo/pull/37
<axw> wallyworld: you should probably use yaml.v1, it's in dependencies.tsv
<wallyworld> axw: ah, yeah, thanks
<anastasiamac> ericsnow: ping?
<fwereade_> axw, I think you're probably right re manifold-in-different-package, but I'm really reluctant for some reason
<fwereade_> axw, possibly because so many others are not yet sufficiently separate from their worker packages as to cleanly accommodate that?
<frobware> dimitern, dooferlad: standup?
<axw> fwereade_: sorry, I was away from IRC. I'm of two minds. On the one hand, it's obviously inherently tied to the worker, but on the other, it has a separate role to play (policy over starting the worker, and connecting the worker to other things). I think having it in a separate package just keeps the responsibilities clearer
<fwereade_> axw, yeah, I think you're right. subpackage is probably not *really* the right place, but close enough for now
<voidspace> perrito666: thanks
<perrito666> voidspace: yw
 * perrito666 overslept, rainy day, fresh drapes, impossible not to
<frankban> cherylj: hi, could you please take a look at http://reviews.vapour.ws/r/3063/ when you have time?
<jam> fwereade_: I realized late that alexisb moved our meeting time (relative to my tz at least). I need to take the dog out, but will try to be back for the meeting
<alexisb> jam, we dropped but I am here if you want to chat post dog walk
<Shawn_> Hello, I am trying to build the packages from source, how can i download the dependency packages individually instead using the makefile ?
<jam> alexisb: hiya. I don't have anything specific. You dropped the meeting for today?
<alexisb> jam, fwereade_ and I met for a moment and then dropped
<jam> alexisb: you realize you really have nothing to say to eachother without me ? :)
<alexisb> jam, so very true ;)
<cherylj> frankban: did you have any write up on using the new bundle support that can go out into the release notes for 1.26-alpha1?
<fwereade_> rogpeppe, do you recall why EnvironObserver has a mutex, and replaces its environ, instead of doing a SetConfig? environs are meant to be goroutine-safe...
<fwereade_> rogpeppe, (I know it's from, what, 20 months ago :))
<frankban> cherylj: no I don't but I can get it prepared
<cherylj> frankban: that would be great.  Just enough to tell people it's there and how they can use it.
<frankban> cherylj: cool, Makyo ^^^ would you like to prepare something about bundle deployment in core?
<frankban> cherylj: will you have time to look at the branch today?
<rogpeppe> fwereade_: i'll have a look
<fwereade_> rogpeppe, cheers
<rogpeppe> fwereade_: even if an Environ itself is goroutine-safe, a worker still doesn't want it changing underneath itself with no warning
<cherylj> frankban: yes, I can.  I see you have two ship it reviews already.  Did you still want me to take a look?
<frankban> cherylj: yes please, I need a review from a core developer
<cherylj> frankban: ah, ok.  Will look at it this morning
<frankban> cherylj: ty!
<fwereade_> rogpeppe, sorry, why not?
<fwereade_> rogpeppe, isn't that the point of it being goroutine-safe, that someone updating the config should be no cause for concern?
<fwereade_> bother
<fwereade_> rogpeppe, sorry, bad timing before
<rogpeppe> fwereade_: np
<fwereade_> rogpeppe, what's the problem with the environ config being updated under a worker? I rather thought that was the point of the boroutine-safety?
<rogpeppe> fwereade_: if i'm writing a worker, i might be doing something on the basis of one attribute, but another attribute might change underfoot so it's inconsistent
<rogpeppe> fwereade_: i think it's better if the config is treated as immutable
<mup> Bug #1513084 opened: 1.20 cannot upgrade to 1.26-alpha1: run.socket: no such file or directory <1.20> <ci> <intermittent-failure> <run> <upgrade-juju> <juju-core:Triaged> <https://launchpad.net/bugs/1513084>
<fwereade_> rogpeppe, that sounds like a problem with the Config method alone then?
<fwereade_> rogpeppe, (also: if a worker's depending on env config values from the env, not from state, isn't it already confused?)
<rogpeppe> fwereade_: if that's an issue, why are we creating the env at all?
<fwereade_> rogpeppe, to call methods that do something to the substrate
<rogpeppe> fwereade_: ok, so those methods will depend on env config values in the env, right?
<fwereade_> rogpeppe, yes, but that's the env's problem, not the client's
<rogpeppe> fwereade_: so should the worker rely on two sources of truth for the config values from the state - the env and another watcher?
<rogpeppe> fwereade_: currently a worker needs only to use the EnvironObserver, which gives it the config values from state (and an environment that can use them)
<mup> Bug #1513096 opened: invalid agent version in environment configuration: "1.26-alpha1" <ci> <deploy> <juju-core:Triaged> <https://launchpad.net/bugs/1513096>
<fwereade_> rogpeppe, what's the overlap between worker-relevant values and env-relevant values?
<rogpeppe> fwereade_: i don't know. but i wouldn't want to rely on there being none ever
<rogpeppe> fwereade_: having a single place to watch seems like a reasonable thing to me
<fwereade_> rogpeppe, in practice, what the EnvironObserver is used for is to create an environ, hand it over to instancepoller, and never update it
<fwereade_> rogpeppe, the instancepoller doesn't remotely care about what wwe're doing in the background, it just wants its instancegetter to work
<rogpeppe> fwereade_: i'm slightly surpised the provisioner worker doesn't use it
<fwereade_> rogpeppe, what would the point be? if it doesn't update the environ we still have to thread env-watching through every worker
<fwereade_> rogpeppe, if it simplified its clients, then it'd be great, but as it is there's no reason to switch implementations to use that afaics
<rogpeppe> fwereade_: presumably the provision *does* update its Environ when the environ config changes?
<rogpeppe> fwereade_: ah yes, it does
<fwereade_> rogpeppe, yeah -- and that one is also sl. different in that it has an interest in actual juju-model config as opposed to just the substrate config
<fwereade_> rogpeppe, but I'm pretty sure that if it's paying attention to the substrate config it's DIW somewhere
<rogpeppe> fwereade_: "dead in water" "doing it wrong" ?
<fwereade_> rogpeppe, the latter was my intent :)
<rogpeppe> fwereade_: it feels a bit racy to me
<fwereade_> rogpeppe, only if the environ itself is, surely?
<rogpeppe> fwereade_: not really.
<rogpeppe> fwereade_: i don't like state changing underfoot
<rogpeppe> fwereade_: i mean, it's *probably* ok
<fwereade_> rogpeppe, I feel like the biggest worry is that few environs have ever been actually used from multiple goroutines, so their safety is not battle-tested
<rogpeppe> fwereade_: there should be at least one cross-environment test that's designed to trigger the race detector in such cases
<fwereade_> rogpeppe, sure, but the number of ways to subtly break safety tends to overwhelm any but exhaustive/invasive testing, and I don't think we really have anything sophisticated enough
<rogpeppe> fwereade_: ah, i was being confused by the configObserver - it's only there for testing
<rogpeppe> fwereade_: if a provider doesn't simply use a mutex, it's probably doing it wrong
<rogpeppe> fwereade_: and that simple mutex logic can be easily tested with the race detector
<fwereade_> rogpeppe, there's another way to approach it that I quite liked, but forget the details of
<rogpeppe> fwereade_: i tend to just make a test like: go setConfig(); go getConfig(); go setConfig(); go getConfig()
<rogpeppe> fwereade_: which will trigger a failure in the race detector if the appropriate mutexes aren't used
<fwereade_> rogpeppe, right, but that's just 2 methods and still rather luck-dependent
<rogpeppe> fwereade_: true that it's only 2 methods (it should probably be all of 'em), but i don't think it's that luck dependent
<fwereade_> rogpeppe, I accept it'll probably fail most of the time, but I doubt it'll be 100% :)
<rogpeppe> fwereade_: why wouldn't it be?
<fwereade_> rogpeppe, it might happen to run them all serially by sheer coincidence, and never happen to flag the issue -- is it smarter than that? I thought it erred in fvaour of false negatives
<rogpeppe> fwereade_: even if it runs them all serially, the race detector will flag it
 * fwereade_ scrubs that bad data out of his brain then
<rogpeppe> fwereade_: of course you can get false negatives if the code never actually accesses the memory in question
<fwereade_> rogpeppe, cool
<rogpeppe> fwereade_: it's a pretty good tool
<fwereade_> rogpeppe, yeah, but that's not the case here
<rogpeppe> fwereade_: i'm a big fan of race-detector-oriented tests
<fwereade_> rogpeppe, indeed, I have a deep and abiding love for the race detector
<mup> Bug #1511822 changed: imports github.com/juju/juju/workload/api/internal/client: use of internal package not allowed <blocker> <ci> <regression> <wily> <juju-core 1.25:In Progress by ericsnowcurrently> <https://launchpad.net/bugs/1511822>
<mup> Bug #1513096 changed: invalid agent version in environment configuration: "1.26-alpha1" <ci> <deploy> <juju-core:Triaged> <https://launchpad.net/bugs/1513096>
<fwereade_> rogpeppe, ok, so, some go-spam-every-method tests would be good in general
<rogpeppe> fwereade_: so presumably your motivation for the initial question was wondering why the instance poller aggregator isn't seeing env config changes?
<fwereade_> rogpeppe, not so much, actually, I came across that later -- I was more thinking of running a separate EnvironObserver that *could* be shared by the various workers that use environs
<rogpeppe> fwereade_: well, the current one can be in fact
<rogpeppe> fwereade_: you could do the SetConfig locally in each worker as desired
<fwereade_> rogpeppe, don't think so? there's only one Environ in the observer
<rogpeppe> fwereade_: each worker would have its own Environ
<fwereade_> rogpeppe, that's what I'm trying to get away from
<rogpeppe> fwereade_: for reasons of efficiency?
<fwereade_> rogpeppe, more that the env-watching is unnecessary extra complexity in a bunch of different workers
<fwereade_> rogpeppe, and yeah, there's some efficiency improvement as well
<fwereade_> rogpeppe, and it opens the door to us being able to actually manager rate limits sanely, instead of having a herd of N environs stampeding to talk to the same endpoint from a single agent
<rogpeppe> fwereade_: the difficulty is that it's all bound up with environ config and that smears a bunch of semi-related attributes together
<rogpeppe> fwereade_: i'm toying with the thought that workers shouldn't ever look at the environ config directly at all
<fwereade_> rogpeppe, I do agree that env config is a mess; but AFAICS the potential for harm comes from people using the environ config -- ha, yeah
<fwereade_> rogpeppe, can you think of any legitimate uses for .Config() for a client? :)
<rogpeppe> fwereade_: but instead have the parameters passed in and derived from the config
<fwereade_> rogpeppe, yeah, absolutely
<rogpeppe> fwereade_: then you'd probably need to restart the worker when config relevant to it changed
<fwereade_> rogpeppe, we just want to pass in something that knows how to ask for instances, and which isn't all whiny and needy about being updated by the same client who wants instances
<fwereade_> rogpeppe, still not really understanding why not to SetConfig and be done with it?
<fwereade_> rogpeppe, in the observer, I mean
<rogpeppe> fwereade_: SetConfig and use chan struct{} ?
<fwereade_> rogpeppe, no, I don't want the clients to have to care about environ config at all
<rogpeppe> fwereade_: that's ok iff there's no overlap between the attrs used by the worker vs those used by the provider
<rogpeppe> fwereade_: i wonder what it would take to split 'em
<fwereade_> rogpeppe, well, at least in the instancepoller case, it doesn't care about env config at all
<rogpeppe> fwereade_: i'm more thinking of the provider case actually
<fwereade_> rogpeppe, in the provisioner case all I can think of is, uh, instance-reaping mode, whatever it's called
<rogpeppe> sorry
<rogpeppe> provisioner
<rogpeppe> fwereade_: yeah
<fwereade_> rogpeppe, which the provisioner shouldn't really know is to do with the env config anyway, it shoudl just be watching/asking for reaping mode
<rogpeppe> fwereade_: one way to be more sure that the workers aren't doing anything untoward might be to make the Environ with Config and SetConfig methods that return an error or panic
<fwereade_> rogpeppe, mm, yeah, I will poke around in that direction and see what happens
<rogpeppe> fwereade_: that wouldn't be compatible with logic doing type inspection of the Environ, but i would hope that nothing is doing that anyway (and i've always considered it seriously misguided in the places we *are* doing it)
<rogpeppe> s/hope that nothing/hope that nothing in the workers/
<fwereade_> rogpeppe, yeah
<natefinch> gc.ErrorMatches is horrible and bad, and anyone who uses it should feel bad.
<fwereade_> natefinch, gtg out, would still be interested to hear more on this -- I'd say that *overbroad* ErrorMatches~s are the usual problem?
<natefinch> fwereade_: the only time the *text* of an error message matters, is if it is shown to a user... which 99% of the time it is not
<natefinch> fwereade_: we use it as a shorthand for "I expect this specific error to be returned"
<natefinch> fwereade_: which is not what is actually being tested
<rogpeppe> natefinch: i disagree. i think it's really helpful to see what our errors look like
<rogpeppe> natefinch: the alternative is often just asserting that the error is non-nil, which isn't very helpful (i have discovered lots of places where we generated a really stupid or malformed error which we never knew about because of that)
<natefinch> rogpeppe: the problem is that asserting the error message asserts a ton of information you don't actually care about.  Like how certain types serialize into strings, like how many levels of abstraction there are between you and the origin of the error
<rogpeppe> natefinch: yes, i agree. that can be problematic too. but i think the upside of seeing what your error messages actually look like outweighs that.
<rogpeppe> natefinch: i often finish an ErrorMatches string with .*
<rogpeppe> natefinch: i've found the error string thing really helpful recently - i found one error that was mentioning the same URL 3 times in the same error message.
<rogpeppe> natefinch: crafting decent error messages is important for the user experience
<rogpeppe> natefinch: and the tests are usually the only place *we* will ever see them
<rogpeppe> natefinch: if it hadn't been for ErrorMatches, we wouldn't have made the recent fix to the charm error messages ("charm or bundle not found" vs "entity not found") caught when ian was reviewing our juju-core changes in response to a charm dep update
<natefinch> rogpeppe: sure, there are times when we show errors to users, and in those cases, error text matters.. but we use ErrorMatches *everywhere* in places we know the user will never see the message (logs don't really count).
<rogpeppe> natefinch: logs definitely count
<natefinch> rogpeppe: not down to the letter
<rogpeppe> natefinch: so what would you do? just check that the error isn't nil?
<natefinch> rogpeppe: no, check what you actually care about, that we detected a specific type of error and failed in an expected way.  Use a custom error type or something.
<rogpeppe> natefinch: another issue i found recently was where an API test wasn't actually testing what it thought it was - the error was for an entirely different reason.
<rogpeppe> natefinch: i don't think we should need a custom error type or value for every kind of error we want to test for
<natefinch> rogpeppe: the thing that brought this up for me was that a test started failing on master because I added a level of indirection, so the error message had an extra section of "while you were doing  foo:"
<rogpeppe> natefinch: yes, that's definitely the down side
<rogpeppe> natefinch: it does make for more churm
<rogpeppe> natefinch: but i still think it's worth it
<rogpeppe> natefinch: (and i have thought about this quite a bit when making similar changes)
<natefinch> rogpeppe: and the problem is that no one is actually thinking about what the error message says or means.  For example, to fix that test, I just copied what the new text is from the error and pasted it into the regex.  That's not really making our code or tests better.
<natefinch> rogpeppe: imagine if we decided to change how tags print out, so now they print out as "tag: foo/0" ... we'd have thousands of broken tests.
<rogpeppe> natefinch: when you did that, i hope you asked yourself the question "does this error accurately and reasonably represent the error that's being tested for?"
<rogpeppe> natefinch: yes we would
<rogpeppe> natefinch: but if we changed the representation of tag.String we'd have lots of other issues too
<natefinch> rogpeppe: but there would be 1000 failing tests that are failing because they're testing something they don't actually care about.   certainly there are places that care what tag's String() function outputs... but that's not the only tests that would fial.
<rogpeppe> natefinch: yes, it's a tradeoff
<rogpeppe> natefinch: but i don't see a better alternative
<ericsnow> rogpeppe: checking for specific error types (a la os.IsNotExist and errors.IsNotFound)
<rogpeppe> ericsnow: so every different error message should have its own error type?
<natefinch> rogpeppe: no, but they shouldn't all be effectively bare strings either
<ericsnow> rogpeppe: arguably one for each equivalence class of error
<rogpeppe> ericsnow: how do you decide that?
<ericsnow> rogpeppe: through bikeshedding <wink>
<rogpeppe> ericsnow: and adding hundreds of different error types is a serious maintenance burden
<ericsnow> rogpeppe: unlike hard-coding checks for error strings ;)
<rogpeppe> ericsnow: at least that's only in the tests and easily changed
<rogpeppe> ericsnow: the problem with having error types is that they're a burden on every developer and need to be maintained as part of the API
<rogpeppe> ericsnow: but often a given error might only have meaning within the context of a given implementation
<ericsnow> rogpeppe: I'd argue that the errors you get *are* part of the API
<rogpeppe> ericsnow: i agree totally
<rogpeppe> ericsnow: and i think that any API should think very hard about the set of error types it exposes
<ericsnow> rogpeppe: definitely
<rogpeppe> ericsnow: which doesn't mesh well with tests that want to test internal functionality
<ericsnow> rogpeppe: agreed, though often having to test internal functionality is a code smell
<ericsnow> rogpeppe: regardless, as you said there are tradeoffs
<rogpeppe> ericsnow: if you're aiming for high coverage, you have to do that in practice
<rogpeppe> ericsnow: (and i think aiming for high test coverage is worthwhile)
<ericsnow> rogpeppe: I'll leave it to katco to expound the higher plane that is dependency injection :)
<ericsnow> rogpeppe: and I couldn't agree more about the importance of high test coverage
<katco> quick, look over there!
 * rogpeppe looks at the pretty birdy
<natefinch> I'm with roger on internal tests.  I think they greatly increase the confidence you can have in your tests.  They make writing tests immensely faster, and they prevent you from mangling your exported API just to support testing.
<katco> does anyone remember what the environmental var is for tabular status?
<rogpeppe> katco: maybe JUJU_CLI_VERSION=2 ?
<rogpeppe> katco: (haven't tried it, just scanned the code)
<katco> that works
<katco> rogpeppe: ty
<rogpeppe> katco: np
<mup> Bug #1513165 opened: Containers registered with MAAS use wrong name <juju-core:Triaged> <https://launchpad.net/bugs/1513165>
<mup> Bug #1513165 changed: Containers registered with MAAS use wrong name <juju-core:Triaged> <https://launchpad.net/bugs/1513165>
<mgz_> katco: got a sec? bug 1512399
<mup> Bug #1512399: ERROR environment destruction failed: destroying storage: listing volumes: Get https://x.x.x.x:8776/v2/<UUID>/volumes/detail: local error: record overflow <amulet> <bug-squad> <openstack> <uosci> <juju-core:Triaged> <https://launchpad.net/bugs/1512399>
<mgz_> why does the autogenerated cinder stuff have "https://cinder.example.com" in it at all? can't it just have the path?
<mup> Bug #1513165 opened: Containers registered with MAAS use wrong name <juju-core:Triaged> <https://launchpad.net/bugs/1513165>
<mgz_> issue is the calling code overrides the host, but not the scheme
<mgz_> so, it breaks if the endpoint is not https
<mup> Bug #1513165 changed: Containers registered with MAAS use wrong name <juju-core:Triaged> <https://launchpad.net/bugs/1513165>
<mup> Bug #1513165 opened: Containers registered with MAAS use wrong name <juju-core:Triaged> <https://launchpad.net/bugs/1513165>
<natefinch> katco: "Pull request successfully merged and closed. Youâre all setâthe natefinch:assign-worker branch can be safely deleted."
<alexisb> mgz_, cherylj has been looking at lp 1512399
<mgz_> alexisb: it's easy to fix, it's just katco's autogenration code needs changing to take an endpoint rather than do this weird overriding
<mgz_> wanted to check with her before hacking it
<alexisb> mgz_, ack
<alexisb> I will stay out of it, thanks
<mgz_> alexisb: no worries
<katco> mgz_: natefinch: sorry was eating lunch
<katco> natefinch: grats... feel like we should throw a party or something :p
<natefinch> katco: right? :)
<katco> mgz_: i believe axw has already modified the auto-generated code, so further modification is probably ok
<mgz_> ...that's more like not okay then, unless he pull requested back to your repo?
<mgz_> oh, or you mean he modified the generated file?
<katco> mgz_: yes i think so
<mgz_> yeah, seems like that... mehp, that make updating more annoying
<mgz_> looks trivial
<katco> mgz_: fwiw he asked first. we were both busy and i think the cinder project made some modifications that broke auto-generation w/o looking into it
<perrito666> beautiful, this is what mongorestore says when file not found: don't know what to do with file
<katco> mgz_: but yes, because of the layering approach, it should be very trivial :)
<mgz_> katco: anyway, the code just needs to build urls in a sane way
<katco> mgz_: should just have to modify protocol here: https://github.com/go-goose/goose/blob/v1/cinder/client.go#L25-L33
<mgz_> an endpoint is not just a host, it's a scheme+host+path that you then append a path to
<katco> mgz_: still, just need to modify that 1 function
<katco> mgz_: and that's not even auto-generated code. that's goose
<mgz_> katco: just + req.URL.Scheme = endpoint.Scheme in SetEndpointFn works for the bug as reported, but that code is still wrong
<katco> mgz_: modify the path in the same place
<mgz_> the auto gen code should append paths to the endpoint
<mgz_> and having hardcodes fake urls is ugly.
<natefinch> katco, ericsnow_afk, wwitzel3:  the tech debt bug to fix the tests: perrito666: nice error message
<natefinch> lol wrong copy
<natefinch> http://reviews.vapour.ws/r/3068/
<natefinch> wwitzel3: why does the package_test.go file need a +build go1.3?
<wwitzel3> the card said it did?
<wwitzel3> I foobar'd my go install trying to install 1.2 so I could test the build flags
<wwitzel3> so I'm playing with that right now, when I threw it at the bot through, it still didn't work, so I missed some
<wwitzel3> natefinch: feel free to give it a try if you have 1.2
<natefinch> wwitzel3: install go from source, it's easy and easy to switch versions
<natefinch> (switching versions is just git checkout go1.2 and then make.bash)
 * natefinch just switched from 1.4 to 1.2 in like 10 seconds)
<natefinch> wwitzel3: every file that imports github.com/lxc/lxd is going to have to be +build go1.3 ... and every file that imports anything those files
<wwitzel3> natefinch: so if the file that imports lxd is go1.3, all the files in the lxd package still have to have it?
<natefinch> ahahahahahahahahahaha ....
<natefinch> oh shit
<natefinch> wwitzel3: go 1.2 doesn't have a "go1.3" build tag implemented
<natefinch> waity wait... no, that should still work
<natefinch> nevermind, sorry
<natefinch> screwing myself up
<natefinch> wwitzel3: if you do go install ./... it'll independently try to build that package regardless of whether anything else imports it.
<natefinch> wwitzel3: it's looking like probably all of the provider/lxd files will need // +build go1.3
<wwitzel3> great
<natefinch> wwitzel3: I have most of the changes on my local machine... haven't run tests which will also need it.
<natefinch> > Directory: /home/nate/src/github.com/juju/juju/provider/lxd
<natefinch> > Command: /home/nate/go/bin/go test ./...
<natefinch> > Output:
<natefinch> ?   	github.com/juju/juju/provider/lxd	[no test files]
<natefinch> > Elapsed: 0.131s
<natefinch> > Result: Success
<natefinch> Success!
<ericsnow> cherylj: PTAL: http://reviews.vapour.ws/r/3067/
<natefinch> wwitzel3: running a full compile of test code now, but I think I got everything
<natefinch> hmm.....
<natefinch> I bet just having github.com/lxc/lxd in dependencies.tsv is going to be a non-starter
<natefinch> katco: ^
<natefinch> wwitzel3: I'm getting some wacky compile errors in environs/bootstrap
<natefinch> a bunch of these:
<natefinch> ./bootstrap_test.go:79: cannot use env (type *bootstrapEnviron) as type environs.Environ in function argument:
<natefinch> 	*bootstrapEnviron does not implement environs.Environ (wrong type for Bootstrap method)
<natefinch> 		have Bootstrap(environs.BootstrapContext, environs.BootstrapParams) (string, string, environs.BootstrapFinalizer, error)
<natefinch> 		want Bootstrap(environs.BootstrapContext, environs.BootstrapParams) (*environs.BootstrapResult, error)
<cherylj> ericsnow: can you give me a quick explanation of what the bug was about?
<ericsnow> cherylj: Go 1.5 disallows packages named "internal" from being used outside the package tree they are in
<cherylj> oic
<natefinch> it's a feature!  ... just not one we intended to be using ;)
<natefinch> wwitzel3: I pushed a bunch of my changes here : https://github.com/natefinch/juju/tree/lxd-provider-flags
<perrito666> ericsnow: I thought I should share the hapiness with you http://reports.vapour.ws/releases/3261
<ericsnow> perrito666: nice! :)
<perrito666> old restore is no more
<perrito666> and CI is now using the new one which is faster
<ericsnow> yay
<perrito666> and, works flawlessly on HA
<davecheney> can someone please review this to unblock me
<davecheney> https://github.com/juju/utils/pull/170
<davecheney> it's fairly uncontraversial
<mgz_> davecheney: well, I disagree
<mgz_> but fine
<mgz_> the reason it's stalled is because this bullshit change-it-everywhere-or-nowhere problem
<mgz_> there's no reason that our deps shouldn't change apart from people want to keep lock-step on them
<mgz_> which is then... why are they even seperate github projects
<mgz_> and this is not going to be different when the big-bang v2 change has happened
<mgz_> people wanting to get a new fix in utils for a stable branch are going to cope
<mgz_> there's no utils 1.24 or 1.25 at present
<davecheney> mgz_: yaml.v1/2 is only renferenced from one file in juju/utils
<davecheney> called trivial.go
<davecheney> which contains one function
<davecheney> WriteYAML
<davecheney> i'm going to move that function back into juju/juju where it is used
<davecheney> and end this madness
<davecheney> and yes, i agree taht this upgrade everything at once thing is bullshit
<mgz_> but the project is called utils! lets just stuff everything in there :)
<davecheney> i hold that as prima facie evidence that putting version numbers in your import paths is a mistake
<davecheney> i agree, creating a package called utils is bad enough
<davecheney> then a repository called utils is asking for it
<davecheney> at atlassian to try to counteract this we created a jar called 'bucket'
<davecheney> so people would feel embaressed about using classes from it
<davecheney> it didn't work, we ended up with bucket2
<natefinch> davecheney: the problem is not version numbers in your import paths, its that we don't care about backwards compatibility in those branches, and we use godeps in addition for some BS busywork on top of it just for kicks
<davecheney> objection!
<davecheney> this is an unrelated argument
<davecheney> yaml.v1 and yaml.v2 _ARE_ different
<davecheney> it says so right in their name
<natefinch> davecheney: yes
<davecheney> the problem is one we have created for oursleves where we _WANT_ to think of them as the same
<davecheney> so there is no argument about backward compatability
<davecheney> if you want them to be backwards compativle, they'd have the same major version number
<davecheney> according to the rules of gopkg.in
<natefinch> davecheney: sorry, I was thinking more of our own repos, charm.v5 etc
<davecheney> don't even get me started on v6-unstable
<natefinch> lol
<natefinch> yes
<davecheney> and yes, i have no idea why we use godeps _and_ gopkg.in versioned import paths
<davecheney> the fact that we have to do both says that neither of those alone is a workable solutin
<natefinch> davecheney: honestly, the problem s till seems to be godeps.  that code doesn't expose yaml objects through its api, and I presume the yaml output is valid whether it's v1 or v2 of goyaml.
<mgz_> katco: I'm going to murder the autogen-ness of this cinder stuff. The current upstream wadl doesn't make working code, and if we're not syncing we're not gaining anything for the pain of using this.
<katco> mgz_: that's fine
<natefinch> davecheney: so why do we even care if some helper function uses yaml.v2 instead of v1?
<davecheney> natefinch: beacuse we have tests in juju that look for a precise string match
<mgz_> katco: I pr'd some changes I needed to test, diff I get is http://paste.ubuntu.com/13105359
<davecheney> v2 changes the string form, and handling of empty keys
<natefinch> davecheney: well I think I know where the problem lies :/
<davecheney> you get $0 for pointing out that our tests are fragile
<natefinch> aww
 * natefinch was ranting about gc.ErrorMatches earlier
<mgz_> natefinch: the problem is not godeps, we have lots of code that depends on how json is handled, and it's part of our api stability contract
<mgz_> which we're already not good on.
<natefinch> mgz_: ....and there were tests that were failing because we changed how we handled stuff in this function....?
<davecheney> natefinch: in this case, how yaml is rendered to the client
<mgz_> not in dave's current case, that's just an error message change, but the charm stuff is scary
<davecheney> there is also that yaml.v2 changes the handling of fields/map keys with empty values
<davecheney> wow, worker/meterstatus/state.go:
<davecheney> 47:     return errors.Trace(utils.WriteYaml(f.path, st))
<davecheney> oh
<davecheney> sorry
<davecheney> that writeyaml doesn't return yaml
<davecheney> it returns an error if it couldn't write
<mgz_> eheh
<waigani> review please: http://reviews.vapour.ws/r/3061
 * perrito666 ponders buying a paper book after some time
<davecheney> thumper: wow, utils.WriteYaml has a huge concurrency failbomb
<davecheney>         prep := path + ".preparing"
<davecheney>         f, err := os.OpenFile(prep, os.O_WRONLY|os.O_CREATE|os.O_SYNC, 0644)
<perrito666> davecheney: did you actually read the DK book about go? is it good?
<davecheney> perrito666: nope, both my physical and ebook copies are still on order
<davecheney> but it has been reviewed by the whole go team
<davecheney> so if you were looking for _the_ word on go
<davecheney> you could not do better than that book
 * perrito666 sends to sprint hotel
<natefinch> davecheney: yeah, that writeyaml function is pretty awful
<natefinch> davecheney: we have an atomic writefile somewhere
<natefinch> (probably in a utils package somewhere ;)
<thumper> menn0, waigani: boring rename branch http://reviews.vapour.ws/r/3056/
<waigani> thumper: swap you: http://reviews.vapour.ws/r/3061/
<thumper> davecheney: I bet many of our tests have certain concurrency expectations
<thumper> waigani: looking
<waigani> thumper: woops, I reviewed that one yesterday, but didn't publish it
<natefinch> wwitzel3: my branch now compiles (including tests) on go 1.2
<wwitzel3> natefinch: nice, we should just use that then?
<natefinch> wwitzel3: yeah. probably. I'll PR it
<wwitzel3> natefinch: make the PR and I'll review  :)
<natefinch> wwitzel3: http://reviews.vapour.ws/r/3070/
<natefinch> ericsnow, katco: super simple review to support go 1.2 in the lxd provider branch ^
<thumper> waigani: "controller environment" vs "controller", I do think that it is worthwhile talking about both. Mark wanted the initial environment / state server environment to be called the "controller environment".
<thumper> I have tried to do that in the places we talked about the other
<thumper> the controller itself encompasses the whole thing (in my mind at least)
<thumper> meaning the environment, and the machines and bits in that env
<thumper> waigani: but I do take your point, and we should perhaps think a bit more on our language
<thumper> at least grepping for "controller environment" shouldn't be too hard
<ericsnow> natefinch: if you rebase against my lxd-fix-local-remote branch, you don't need to touch the instance and container/factory packages
<natefinch> ericsnow: is that branch landing soon?
<ericsnow> natefinch: not before we get the 1.3+ support we need
<natefinch> ericsnow: well, this PR is so we don't need 1.3+ support
<natefinch> )ish)
<ericsnow> natefinch: just to trick the merge bot?
<ericsnow> natefinch: strike that :)
<ericsnow> natefinch: regardless, feel free to strip all the LXD-as-a-container code now rather than waiting for any of my code to land
<katco> natefinch: how is this different from wwitzel3 's pr? http://reviews.vapour.ws/r/3064/
<waigani> thumper: right. It's really about the concept we want to sell. "controller environment vs an environment in a controller" or just "controller vs environment". Either is fine, but we should consciously chose one and be consistent.
<natefinch> katco: mine works ;)
<wwitzel3> yeah
<wwitzel3> lol
<ericsnow> natefinch: also, I'm pretty sure we don't import github/lxc/lxd anywhere under provider/lxd so why is the build constraint needed there?
<natefinch> ericsnow: transitive dependencies... since we're not building all the lxdclient code, the code that uses *that* code now won't compile
<thumper> waigani: the tricky bit of this concept is that we have a controller that hosts environments, but also the controller environment that is the environment that contains the API server bits
<waigani> yep
<thumper> waigani: so I think I'm doing to defer changing these comments for now :)
<waigani> okay, sure
<ericsnow> natefinch: meh, I meant solve that a different way but that would be worse than sprinkling the build constraints all over :)
<natefinch> ericsnow: you could make fake implementations of the lxdclient stuff for go1.2... but I think this actually might be ore clear and less real work.  Really didn't take long, and it'll be trivial to undo (even if it does touch a lot of files... it's just one line per file).
<ericsnow> natefinch: right; not worth it
<waigani> thumper: But I do think it's worth thinking about. AFAICS, fact that a controller is an environ is implementation detail  to support the API - as you say. It shouldn't be confusing the language we use to describe the overall design.
<thumper> except it shows up whenever we talk about "all environments"
<thumper> and environment commands work on the controller
<thumper> I definitely agree that it is worth thinking about
<waigani> thumper: I think it comes down to implementation details vs design. Are those details leaking into the design? If so, do we separate them (e.g. never speak of a "controller environment", rename env cmds on the controller to controller cmds) or do we update the design (e.g. always talk about "controller environment").
<natefinch> katco, ericsnow: I think we need to talk about dependency injection for the purpose of testing, re: http://reviews.vapour.ws/r/3021/#comment18995
<thumper> I don't think so... I think it depends a lot on context
<thumper> you are either talking about the controller environment, and dealing with environment *things*
<katco> natefinch: it's been queued for awhile. i have half an hour if everyone else does
<thumper> or you are talking about the controller in a hosting capacity
<thumper> the controller environment doesn't host environments
<natefinch> katco: I have 15 minutes, which is probably not going to be enough.  Tomorrow?
<thumper> but talking about environment things on the controller doesn't make sense really either
<katco> natefinch: tomorrow is meeting day for me =/
<natefinch> katco: I'm willing to sacrifice my 1:1 time to talk about this.  I think it's worthy.
<katco> natefinch: we can do that if everyone is available
<waigani> thumper: ah okay. In a similar way you could talk about a controller machine?
<thumper> I'm not sure you would...
<thumper> you may talk about an API server machine
<thumper> but a controller machine doesn't really make sense
<waigani> so what do we call what we use to call the state server machine?
<thumper> a machine in the controller environment is ok...
<ericsnow> katco, natefinch, wwitzel3: I'm game
<thumper> personally I tend to still call them state server machines
<katco> ericsnow: natefinch: wwitzel3: invite in the mail
<thumper> :)
<waigani> haha
<natefinch> thumper, waigani: FWIW, I think that "talking out loud" about the new names for things is a very good way to nail down gaps in the vocabulary, and exposes places where names may be misleading.
<natefinch> like state server machine :)
<thumper> agreed
<thumper> definitely think it needs a new name :)
<thumper> like: Bob
<waigani> lol
<natefinch> +1 ship it
<thumper> I used to use Eric all the time, from Eric the Viking
<thumper> but I feel I have to stop that now that we have ericsnow
<natefinch> way to mess it up ericsnow
<ericsnow> mwahaha
<thumper> ericsnow: how about you change your name?
<thumper> perhaps "snowman"
<cherylj> ericsnow: for this branch:  http://reviews.vapour.ws/r/3067/  Did you just do a rename for internal to private?
<ericsnow> nah :)
<ericsnow> cherylj: yep, that's it
<natefinch> snowman sorta sounds like the codename for a mobster
<cherylj> ericsnow: it's just showing up in a not-clear way in RB and github.  Like it shows that you modified something in internal/client/unitfacade.go, but it doesn't show that you deleted any of the old files
<thumper> natefinch: haha
<ericsnow> cherylj: yeah, GH is confused and RB isn't helpful when it comes to renames
<natefinch> I heard he snowed someone just for looking at him wrong.
<cherylj> bleh.  fun.
<ericsnow> cherylj: in case it helps, I rebased that PR so GH is showing the changes correctly now
<cherylj> ah yeah, that helps
<cherylj> ericsnow: there were just a couple things
<ericsnow> cherylj: thanks
<mup> Bug #1513236 opened: Cannot build trusty armhf with go1.2 on from master <armhf> <blocker> <go1.2> <regression> <juju-core:Triaged> <https://launchpad.net/bugs/1513236>
<thumper> who loves shitty rename branches? http://reviews.vapour.ws/r/3072/diff/#
<ericsnow> katco: FYI, I have the payloads-into-master patch up
 * ericsnow raises hand
<katco> ericsnow: nice :)
<katco> ericsnow: go ahead and merge your payloads branch into master
<ericsnow> katco: k
<ericsnow> katco: alas, master is blocked
<katco> ericsnow: doh
<davecheney> katco: ericsnow this may very well be an upstream bug
<davecheney> looking at the ci dashboard
<ericsnow> davecheney: k
<davecheney> no builds for the crypto repo have run on arm for months
<davecheney> and the go team turned off build faiure notifications a while back
<davecheney> so yeah, there is that
<davecheney> let me quickly check something
<ericsnow> davecheney: thanks
<davecheney> builds on go 1.5
<davecheney> we might have to chalk this one up to go 1.2 being unsupported
<davecheney> katco: please unblock the build
<davecheney> we cannot fix this
<davecheney> it is blocked on other work which has been scheduled
<davecheney> but has not reasonable ETA that can be used to unblock the build
#juju-dev 2015-11-05
<menn0> thumper, axw or wallyworld: review pls  http://reviews.vapour.ws/r/3073/
<menn0> this makes a feature test i'm writing a lot cleaner
<thumper> menn0: done
 * thumper goes to walk the dog in the sun
<menn0> thumper: thanks
<davecheney> OH WOW
<davecheney> the maas provider demands yaml.v2
<davecheney> but also calls a utilty function with requires yaml.v1
<davecheney> mgz_: thumper http://reviews.vapour.ws/r/3074/
<davecheney> please view
<davecheney> should break the arguments about which version of yaml.v2 juju/utils can use
<davecheney> also, spot the WTF in that pach
<davecheney> also, spot the WTF in that patch
<natefinch> davecheney: heh, looks familiar: https://github.com/natefinch/atomic/blob/master/atomic.go#L17
<natefinch> davecheney:  looks like I should steal some safeguards from yours, though.
<perrito666> mm, the chmod wont work in windows, but since it is not tested it wont break anything either
<natefinch> perrito666: chmod is just a noop on winows
<perrito666> natefinch: not entirely
<perrito666> there is an implementation in go that does something stupid
<perrito666> it changes fs properties for the file but these are ignored by windows
<natefinch> effectively a noop :)
<perrito666> natefinch: well the fact that those things can be changed means that something is using them
<perrito666> I have no clue what that is
<perrito666> most likely windows 3 :p
<thumper> menn0, davecheney, axw: team meeting
<natefinch> davecheney: seems like this must be a bug: http://reviews.vapour.ws/r/3074/#comment19133
<davecheney> coming
<davecheney> oh
<davecheney> i'm 33 mins late
<davecheney> natefinch: thanks for your comments
<davecheney> PTAL
<natefinch> davecheney: we're still talking on the hangout btw
<davecheney> ok, coming
<natefinch> davecheney: tests?
<natefinch> thumper: Looking at that retry package, seems like it would be useful to be able to encapsulate call args into a value, and then be able to call value.Call(somefunc) .... so you could use the same retry semantics with any number of different functions.  Also it then doesn't hide the function you're retrying inside a huge list of args.
<natefinch> thumper: also you should call the package sisyphus
<davecheney> natefinch: this is only temporary
<davecheney> once everyone is at yaml.v2 i'll be deleting those forks
<davecheney> my goal is not to move code from other packages into juju
<davecheney> in fact the opposite
<davecheney> but this yaml.v2 dep keeps fucking that plan up
<cherylj> what's the difference between stateaddresses and apiaddresses in agent.conf?
<cherylj> thumper, menn0 ^^ ?
<menn0> cherylj: iirc stateaddresses has the mongodb server addresses and apiaddresses is the API server addresses
 * menn0 checks something
<thumper> natefinch: interesting idea
<menn0> cherylj: yep, that's right
<thumper> natefinch: and pretty easy to implement
<menn0> cherylj: really stateaddresses shouldn't be there except on the state/controller servers, but it is
<cherylj> ok, thanks, menn0
<menn0> cherylj: it's probably a historical vestiage - non state agents used to connect directly to mongo for some things
<thumper> menn0: could I get you to cast your eyes over http://reviews.vapour.ws/r/3072/ ?
<thumper> cherylj: menn0 is right in his musings :)
<menn0> cherylj: related tidbit: a lot of (probably older) code uses "state" to mean "the mongodb server". not at all confusing.
<menn0> thumper: looking
<cherylj> ha, ok :)
<natefinch> thumper: also, if you're going to make retry a standalone package, you gotta move clock into a standalone package
<thumper> natefinch: axw is moving the clock out in his one
<natefinch> thumper: awesome
<thumper> natefinch, axw: although perhaps we should have a common top level one...
<thumper> axw: perhaps juju/clock ...
<axw> natefinch: FYI, this is the branch talked about on the call: https://github.com/axw/juju-time
<axw> thumper: I was thinking juju/time/clock, but *shrug*
<natefinch> thumper: yeah. thats what I meant, just juju/clock
<thumper> axw: I was thinking more to have a common parent for the scheduler one too, rather that the clock with the scheduler
<axw> thumper: yes, definitely not in the one package
<axw> we have enough utils already :)
<thumper> I was thinking not in the same repo
<thumper> agreed
<natefinch> thumper: btw, I think the error handling in your retry code could be improved by following davecheney's advice to assert behavior: http://dave.cheney.net/2014/12/24/inspecting-errors   .. so like have a 'Last() error' method on the error types, etc.
 * thumper looks
<menn0> thumper: well that sucked. review done. lots of stuff missed.
<thumper> menn0: :(
<menn0> thumper: the review process sucked... not the PR
<thumper> menn0: it isn't complete...
<thumper> geez
<thumper> there is another one following...
<thumper> I think
<thumper> at least
 * thumper looks
<menn0> thumper: there's lots of test names that still say System and bits of help text missed and a few other things
<thumper> ok
<menn0> thumper: I basically just did a search in my browser for "system" looked to see if it came up on the right side of the diff :)
<menn0> thumper: also "server" comes up a bit
 * thumper sighs
<menn0> not sure if you're fixing those
<thumper> so much stuff to change
<natefinch> I can't believe we're spending so much time just to change the names of things, instead of, like, implementing features.
<natefinch> oh yeah, hey, I had a 1.26-alpha1.1 server running, and tried to interact with it via a client built from master, and was getting this error message printing out with a lot of my commands: 2015/11/04 21:27:00 warning: discarding cookies in invalid format (error: json: cannot unmarshal object into Go value of type []cookiejar.entry)
<natefinch> davecheney: what's wrong with this picture? https://github.com/juju/persistent-cookiejar/blob/master/jar.go#L10
<davecheney> natefinch: the type isn't public ?
<natefinch> davecheney: repo name is "persistent-cookiejar" :/
<natefinch> package name is "cookiejar
<davecheney> oh for fucks sake
 * davecheney throws something
<natefinch> also, using that package seems to break client-server compatibility
<natefinch> I saw this:
<natefinch> $ juju destroy-environment local -y
<natefinch> ERROR cannot connect to API: cannot load cookies: json: cannot unmarshal object into Go value of type []cookiejar.entry
<natefinch> whewn my client was a different version than my server... presumably one of them was using the old cookiejar and one the new
 * davecheney bursts into tears
<davecheney> natefinch: i'm convencined we've passed more than 100% technical debt to gdp
<natefinch> davecheney: time to rewrite juju in rust
<davecheney> that wasn't the exact point I was trying to make ...
<natefinch> davecheney: well, we're working on tech debt at oakland, right?  One week should just about do it.
<davecheney> i'll be late
 * natefinch calls it a night to go read his new Go programming book
<thumper> davecheney: https://github.com/howbazaar/clock-proposed
<thumper> davecheney: I know you like non-util named packages :)
<thumper> davecheney: to become github.com/juju/clock
<thumper> axw: ^^
<thumper> added in the testing clock from juju/juju/testing/clock.go
<thumper> and added a few tests
<thumper> and type assertions in the test file
<axw> thumper: LGTM, but I'd like it if you renamed clock/testing to clock/clocktest
<axw> thumper: saves aliasing everywhere
<thumper> clock/testclock?
<axw> thumper: I was thinking clocktest as in testing things related to the clock package, not as in a package that contains a TestClock
<thumper> I agree with renaming it
<axw> thumper: much like net/http/httptest
<thumper> ah.. ok
<thumper> happy to follow precident
<axw> thumper: still not really sure about having a whole repo to its own. we're goingto want other time-related things which would be nice to group together
<axw> thumper: e.g. delay functions for retry/scheduler/backoff thing that bogdan is working
<thumper> axw: let's ask fwereade, given tech-lead hat :)
<axw> thumper: I'm thinking they'd live in juju/time/delays or something like that... and then having clock over by itself feels a bit odd
<axw> thumper: SGTM
<davecheney> \o/ all praise the clock
<davecheney> 15:32 < axw> thumper: LGTM, but I'd like it if you renamed clock/testing to clock/clocktest
<davecheney> ^ yes, a million times, yes
<thumper> I'm just asking our architect and TLs about guidance around separate repo for clock, or one for time that includes the scheduler that axw has
<thumper> davecheney: the clock-proposed repo now has that package renamed
<davecheney> thumper: also if it's going to be a juju project, it needs a cute name
<davecheney> what about clocky ? https://upload.wikimedia.org/wikipedia/commons/4/4b/Clocky_almond_panorama1680.jpg
<thumper> :)
<thumper> axw: got the link to your time proposed repo?
<thumper> axw: I'll include it in the email
<axw> thumper: https://github.com/axw/juju-time
<thumper> ta
<menn0> thumper: here's juju-dumplogs. I'm just doing the /usr/local/bin symlink now.
<menn0> http://reviews.vapour.ws/r/3075/
<thumper> menn0: I'll continue reviewing shortly, got to go and drop of kids to guides/show
<thumper> bbs
<menn0> thumper: np
<jam> morning all
<dimitern> dooferlad, hey, can you check if you open http://imgur.com/a/ky3cl please?
<fwereade> dimitern, nice
<dooferlad> dimitern: yep
<dimitern> fwereade, dooferlad, thanks :)
<dimitern> wasn't sure I need to actually sign up for imgur to "public" the album - never used it, and their UI is confusing
<dooferlad> dimitern: I have an environment in EC2 that has had its agent-state-info stuck in "Request limit exceeded" since last night.
<dooferlad> dimitern: any thoughts?
<dimitern> dooferlad, hmm - is it the shared account?
<dooferlad> dimitern: https://console.aws.amazon.com/trustedadvisor/home?#/dashboard says I am below the service limits
<dooferlad> so I expect this is a cached response :-|
<dimitern> dooferlad, if it's the shared account, I can have a look
<dooferlad> dimitern: it is shared, in eu-central
<dimitern> dooferlad, ok, looking
<dooferlad> dimitern: and, the fun part is, I only have 3 machines running after I did an ensure-availability -n 3 and had a charm on machine 1.
<dooferlad> dimitern: so it looks like Juju tried to add another machine then gave up
<dooferlad> dimitern: http://pastebin.ubuntu.com/13111330/
<dimitern> dooferlad, that smells like the instancepoller getting overexcited
<dimitern> and polling more often than needed
<dooferlad> dimitern: even though we are, at the moment, under limit?
<dooferlad> dimitern: ignore that comment, I was looking at service limits, not request limits
<dooferlad> dimitern: we definitely need exponential backoff in our EC2 API with automatic retries. Is it supposed to have it already?
<dimitern> dooferlad, IIRC we already have that
<dimitern> dooferlad, or maybe it was just for the instancepoller
<dooferlad> dimitern: it shouldn't be related to the bug I am looking at anyway since the customer is using MAAS.
<dimitern> dooferlad, yeah
<dimitern> dooferlad, can you try destroy-machine --force on those with the error and add new ones?
<dooferlad> dimitern: possibly, but it isn't important right now. Was just wondering about a quick fix.
<dooferlad> dimitern: just seemed odd
<dimitern> dooferlad, indeed - before destroying the env, it might be useful to get the machine-0.log for some insight
<jam> frobware: sorry I missed standup. Was still meeting with Mark. are you guys still chatting?
<frobware> jam: yep
<frobware> jam: into topics "catacomb and rate limiting"
<jam> k. using the restroom and I'll be right there
<fwereade> jam, it's a `.Kill(nil)`, so that's even easier :)
 * perrito666 applies for a visa for the first time in around 20 years
<perrito666> axw: you have a pretty strict migration policy :p
<lazypower> dimitern - Help me out for a sec. Whats the name of your juju-core team?
<rick_h__> lazypower: sapphire
<lazypower> ah! thank you
<lazypower> is there a chart/roster somewhere?
<lazypower> It'll help when blogging and pointing credit arrows :D
<rick_h__> lazypower: honestly I use the canonical directory
<lazypower> Ah, allright
<rick_h__> lazypower: if you look up dimiter it shows "Juju Core - Sapphire" as his team
<rick_h__> lazypower: I'm sure there's others but just what I tend to use when I forget.
<dimitern> lazypower, hey :)
<perrito666> it would be really nice to have an api for the directory so I can write a plugin for my irc client
<rick_h__> perrito666: come on, web scrapers ftw! :P
<lazypower> perrito666 - automate away the pain. Embedded profiles for IRC
<jam> perrito666: do you know about mup?
<perrito666> jam: I do I would like my client to show me faces on hover though :)
<jam> perrito666: would be good
<cherylj> frankban: I see that you're reverting your update for crypto.  Was it updated originally for a particular reason?
<mup> Bug #1513466 opened: Different behavior on ServiceDeploy with Config/ConfigYAML <juju-core:New> <https://launchpad.net/bugs/1513466>
<mup> Bug #1513468 opened: imports github.com/juju/juju/workload/api/internal/client: use of internal package not allowed <blocker> <ci> <regression> <testing> <wily> <juju-core:New> <juju-core 1.25:Fix Released> <https://launchpad.net/bugs/1513468>
<frankban> cherylj: I don;t remember specific reasons, probably just ended up there because it was updated in my GOPATH by some other project
<cherylj> frankban: ok, thanks!
<frankban> cherylj: should I merge it?
<cherylj> frankban: did your local tests pass?
<frankban> cherylj: I alway have some intermittent failures locally, but they seems not related to the downgrade, CI will tell us I guess
 * cherylj curses intermittent failures
<cherylj> frankban: yes, please merge
<frankban> cherylj: done, how do we know if this fixes armhf?
<cherylj> frankban: I don't think we have any way to test that without requesting images be built for 1.26-alpha 1
<frankban> cherylj: ok, does merging this automatically unblock master?
<cherylj> frankban: no, we'll need to verify that the fix worked first
<perrito666> someone gave more machine to CI? curses are coming faster
<frankban> cherylj: Does not match ['fixes-1513236'], I wrote fixes-1513236 in the pr comment, what else should I do?
<perrito666> frankban: $$fixes-1513236$$ should do the trick
<cherylj> frankban:  use "$$fixes-1513236$$"
<cherylj> rather than $$merge$$
<frankban> ok done
<cherylj> thanks, frankban!
<abentley> frankban: If master is blessed, your bug will automatically be marked fix-released.  If there are no other blockers, that will unblock master.
<frankban> abentley: sounds good
<frankban> cherylj: downgrade branch landed
<abentley> frankban: master bec300366 now testing.
<mup> Bug #1513492 opened: add-machine with vsphere triggers machine-0: panic: juju home hasn't been initialized <add-machine> <panic> <vsphere> <juju-core:Triaged> <https://launchpad.net/bugs/1513492>
<cory_fu> With the release of Juju 1.25, we seem to be seeing shorter idle times on the agent-state, possibly due to update-status hook being called more frequently.  Was there a specific change related to that in 1.25?
<perrito666> bbl lunch
<perrito666> cory_fu: update status hook will call before entering idle status
<perrito666> but the added time there might make idle time shorter as a consequence
<perrito666> fwereade: correct me if that changed
<perrito666> now yes, bbl
<fwereade> perrito666, cory_fu: yes, I wouldn't expect a non-errored agent to be idle for longer than 5 mins (I think that's the update-status period)
<fwereade> cory_fu, but if it never gets close to that there might be something up
<cory_fu> I'm not sure if I understand.  The issue I'm running up against is that I'm waiting for a 30s idle period and am not seeing it within a 30min window.  This seems to mostly happen on Azure
<cory_fu> Which is notoriously slow for these deploys, so that may be a factor.
<tvansteenburgh> cory_fu: i have examples on other clouds too
<cory_fu> tvansteenburgh: But it's not 100% consistent on other clouds?
<tvansteenburgh> cory_fu: azure is notable b/c it hasn't passed on 1.25 at all. hp on the other hand, has passed at least twice :P
<katco> wwitzel3: standup?
<wwitzel3> katco: trying .. :/
<tvansteenburgh> fwereade, cory_fu: seems to me that agent-status.since should not be updated unless the value of agent-status.current actually changes
<fwereade> tvansteenburgh, right, but it executes a hook every 5 minutes
<fwereade> tvansteenburgh, is workload-status also shortened?
<fwereade> tvansteenburgh, I would expect ~5mins of idle, separated by (likely) sub-second blips of executing
<tvansteenburgh> fwereade: no, in our examples, wordload-status.since is much older - 8 to 15 minutes older in the one i'm looking at
<fwereade> tvansteenburgh, cool, I think that's what I'd expect
<fwereade> tvansteenburgh, is it unhelpful to you?
<tvansteenburgh> fwereade: i'm not sure. we've been using agent-status.since to determine when an environment had "settled" - all agents idle for 30 seconds. that worked well prior to 1.25, but now we see most deployments never reaching that settled state. trying to figure out what changed
<frankban> cherylj, abentley: bec30036 failed, errors don't seem related though
<fwereade> tvansteenburgh, well, the update-status thing is the clear proximate cause, but ultimately I think it's incorrect to depend on agent status as a proxy for environment stability
<fwereade> tvansteenburgh, that should be what workload-status is for -- assuming the charm implements it
<abentley> frankban: no, but it does seem like a legit failure.  The same test failed for the last test of master.
<tvansteenburgh> fwereade: yeah, fair enough. we were trying to accommodate the charms that don't, but i see your point
<fwereade> tvansteenburgh, cool -- forwarded you a mail where I go into a bit more detail, in case it's relevant :)
<tvansteenburgh> fwereade: thanks!
<frankban> abentley: how do we check that https://bugs.launchpad.net/juju-core/+bug/1513236 is fixed?
<mup> Bug #1513236: Cannot build trusty armhf with go1.2 on from master <armhf> <blocker> <go1.2> <regression> <juju-core:Triaged> <https://launchpad.net/bugs/1513236>
<katco> davecheney: did you have a golang issue or something to justify unblocking master for bug 1513236 ?
<katco> davecheney: (just now seeing your message) i'd like to update that bug with justification before untagging it as a blocker
<abentley> frankban: Regardless of whether that bug is fixed, we don't want to unblock until we get a bless.
<frankban> abentley: I don't question that
<abentley> frankban: That's tricky, because we don't build armhf as part of testing, because we don't have suitable hardware to test with.  I'd talk to sinzui.
<sinzui> abentley: mgz: I beleive we could crossbuild it, which would catch the error.
<natefinch> abentley, frankban, sinzui : note that davecheney said that this was very likely an upstream go 1.2 bug that is not likely to be fixed anytime soon, possibly ever
<sinzui> abentley: mgz: I was also thinking of asking for armhf hardware, but mgz might be able to prove the cae for us with this chromebook
<sinzui> natefinch: yeah, Go has moved on to newer versions
<cherylj> hey dimitern, is there any update on bug 1483879?  I know the fix isn't trivial, but the bug was brought up in the cross team call and I wanted to make sure it was still in progress...
<mup> Bug #1483879: MAAS provider: terminate-machine --force or destroy-environment don't DHCP release container IPs <bug-squad> <destroy-machine> <landscape> <maas-provider> <sts> <juju-core:Triaged> <juju-core 1.24:Triaged> <juju-core 1.25:In Progress by dimitern> <https://launchpad.net/bugs/1483879>
<dimitern> cherylj, it still is - I'm close to proposing 1.24 fix (needed to fix my maas setup to test it properly, which I finished a couple of hours ago)
<cherylj> dimitern: great, thanks!  I'll put an update in the bug that it's close for 1.24.
<cherylj> dimitern: will it be difficult to forward port?
<dimitern> cherylj, the 1.24 fix is the most difficult, as it needs some cherry-picking from 1.25
<cherylj> ah, ok
<dimitern> cherylj, the 1.25 and master forward ports  should be much simpler
<natefinch> wwitzel3, ericsnow: fyi, a few tests failed on the lxd build tags merge, I can fix easily, but just letting you know.
<ericsnow> natefinch: k
<wwitzel3> natefinch: ty
<natefinch> alexisb, katco:  I notice the "roomie" thing on the oakland spreadsheet says N/A for everyone.  Does that mean we all get our own rooms?
<katco> natefinch: that is my understanding
<natefinch> katco: awesome :)
<katco> natefinch: yes, as an introvert that makes me extremely happy
<katco> natefinch: i.e. i'll actually have a place i can recharge
 * dooferlad is a happy introvert as well at this news
<natefinch> katco: yeah, totally understand that
<natefinch> katco: I'm generally fine with sharing a room... right up until the actual sleeping part... then I really just want my own room, thankyouverymuch.
<katco> natefinch: it's pretty disastrous for me as i feel like i have to be "on" for 24/7 for an entire week
<wwitzel3> I usually wake up at 7am and don't go to bed until 3am during sprints .. they should really do a timeshare thing, probably save money
<katco> wwitzel3: 1:1?
<wwitzel3> I also feed off the engery of introverts, so that helps
<natefinch> wwitzel3: rofl
<katco> haha
<lazypower> > I feed off he energy of introverts
<lazypower> strange place to join the conversation, but knowing wwitzel3 i'm not surprised...
<wwitzel3> lazypower: :)
<natefinch> no wonder wwitzel3 likes programming so much... neverending supply of food.
<frobware> cherylj, would you have time to try a fix for https://bugs.launchpad.net/juju-core/+bug/1412621
<mup> Bug #1412621: replica set EMPTYCONFIG MAAS bootstrap <adoption> <bootstrap> <bug-squad> <charmers> <cpec> <cpp> <maas-provider> <mongodb> <oil> <juju-core:Triaged by frobware> <juju-core 1.24:Triaged> <https://launchpad.net/bugs/1412621>
<natefinch> man, prices for flights went up like 25% from yesterday afternoon :/
<perrito666> natefinch: nearing christmas
<natefinch> perrito666: I think we just crossed the "30 days from flight day" mark
<perrito666> ah, ok, that makes me panic
<perrito666> my before trip todo is especially long
<ericsnow> natefinch: I found a couple typos in your build constraints patch (left a review)
<natefinch> ericsnow: thanks!
<ericsnow> natefinch: np
<ericsnow> natefinch: found it while rebasing my patches on yours :)
<natefinch> ericsnow: "how did this compile before?"  exactly my question
<ericsnow> natefinch: I don't think it did :/
<natefinch> ericsnow: there were two compiler errors before I even changed anything.  My guess is that they were because of a merge/rebase
<ericsnow> natefinch: yep
<natefinch> ericsnow: fixed those spots btw
<ericsnow> natefinch: thanks
<natefinch> ericsnow: the only thing left is some provisioner tests that are failing
<ericsnow> natefinch: weird
<ericsnow> natefinch: look for instance.LXD in those tests
<mup> Bug #1513552 opened: master cannot deploy charms <blocker> <charm> <ci> <deploy> <regression> <juju-core:Triaged> <https://launchpad.net/bugs/1513552>
<natefinch> the letters lxd don't even exist in files in this directory :/
<natefinch> ericsnow: it's suspicious because it's in container_initialisation_test.go .. which implies it is our fault (maybe we're being punished for the UK spelling in the filename)
<perrito666> bbll
 * perrito666 goes to curse ha screaming and will be back later
<cherylj> natefinch: can you take a look at bug 1513552?  It looks like some of your recent commits are causing widespread CI failures
<mup> Bug #1513552: master cannot deploy charms <blocker> <charm> <ci> <deploy> <regression> <juju-core:Triaged> <https://launchpad.net/bugs/1513552>
<ericsnow> alexisb: sorry, zillow killed my browser
<alexisb> lol
<alexisb> :)
<cherylj> could anyone tell me when we would see SECURE_STATESERVER_CONNECTION: "false" in agent.conf rather than "true"?
<natefinch> cherylj: ok looking
<natefinch> hmm... many of those failures mention deployer... seems suspicious
<natefinch> sinzui: I wonder if deployer is doing something different than juju-core... because I can deploy charms just fine with juju deploy
<natefinch> sinzui: re: that "cannot assign unit" problem
<natefinch> katco: FYI, spending some non-trivial time looking into bug 1513552
<mup> Bug #1513552: master cannot deploy charms <blocker> <charm> <ci> <deploy> <regression> <juju-core:Triaged> <https://launchpad.net/bugs/1513552>
<sinzui> natefinch: the deployer jobs that stand up openstack report the same problem
<katco> natefinch: yep thx for the heads-up
<sinzui> natefinch: eg: http://reports.vapour.ws/releases/3270/job/OS-deployer/attempt/502
<sinzui> natefinch: the quickstart error is also the same (though reported differently) http://reports.vapour.ws/releases/3270/job/aws-quickstart-bundle/attempt/1282
<sinzui> ^ landscape bundle
<natefinch> sinzui: do we have tests that just use juju deploy?
<natefinch> (not being snarky, real question... want to make sure I'm right in thinking it's deployer etc)
<sinzui> natefinch: to deploy a bundle? not yet
<natefinch> sinzui: no, to deploy a charm
<sinzui> natefinch: many tens of tests deploy a charm
<natefinch> sinzui: and those all pass?  So it's just deployer and quickstart?
<sinzui> natefinch: no. http://reports.vapour.ws/releases/3270 clearly shows "deploy", "deployer", and "quickstart" are broken on all substrates, all series, all archs
<sinzui> natefinch: this shows every test that failed in the two revs that were tested http://reports.vapour.ws/releases/issue/563b902c749a563ed218b6cf
<sinzui> natefinch: I think I see the issue :)
<sinzui> natefinch: nm, I am looking at stale data
<cherylj> aww, I had gotten my hopes up
<natefinch> man I wish we didn't redact the API parameters
<ericsnow> fwereade: isn't it gloomy in the catacombs?
<ericsnow> fwereade: I suppose they have a certain charm :)
<fwereade> ericsnow, terribly glum, yeah :)
<thumper> menn0: test failure: [LOG] 0:00.206 ERROR juju.apiserver debug-log handler error: tailer stopped: tailable cursor requested on non capped collection
<wwitzel3> katco ericsnow natefinch ping
<katco> wwitzel3: brt
<natefinch> sinzui: I bet this is a race condition where the script is calling expose or something before the unit has a machine assigned, and that's causing us to go down a codepath we didn't previously go down, because unit creation and assignment happened in lock step.
<natefinch> sinzui: because a simple deploy definitely still works
<sinzui> natefinch: maybe. the deploy_stack.py copies a lot of deployment where expose is called immediately after deploy and add-relation. I thnk deployer though deferred that operation until relations were added, and relations were deffered until all units were up
<sinzui> natefinch: http://reports.vapour.ws/releases/3270/job/aws-deploy-trusty-amd64/attempt/2476 does show that deploy, add-relation, and export were all called withing seconds of each other
<katco> wwitzel3: ericsnow natefinch sorry, almost there
<natefinch> sinzui: definitely looks like expose and/or add-relation is the problem, I can repro if I do juju deploy wordpress && juju add-relation wordpress mysql && juju expose wordpress
<thumper> fwereade: ping
<fwereade> thumper, pong
<thumper> fwereade: can we chat in about 10min?
<fwereade> thumper, sure
<fwereade> natefinch, I think you're right
<fwereade> natefinch, is that the firewaller falling over?
<natefinch> fwereade: sorry, in a meeting
<fwereade> natefinch, np
<thumper> fwereade: https://plus.google.com/hangouts/_/canonical.com/chat?authuser=1
<cherylj> wallyworld: you around?
<wallyworld> cherylj: sorta
<cherylj> wallyworld: could you ping me when you get a few minutes?  I need some help with a bug
<wallyworld> sure, give me 10 mins
<cherylj> sounds good, thanks
<wallyworld> cherylj: which bug?
<cherylj> https://bugs.launchpad.net/juju-core/+bug/1512782
<mup> Bug #1512782: wget cert issues causing failure to create containers <cloud-installer> <juju-core:Triaged> <https://launchpad.net/bugs/1512782>
<cherylj> They're doing some weird stuff with their lxcbr0 and nested kvm / lxc
<wallyworld> cherylj: give me a minute to read bug info; that's wget/lxc stuff hasn't changed in ages so it's likely to be specific to their setup
<cherylj> The last update is probably the most useful
<cherylj> wallyworld: this line in the machine-0.log also looks really weird to me:  DEBUG juju.worker.certupdater certupdater.go:191 new addresses [localhost juju-apiserver juju-mongodb anything 10.0.7.1]
<wallyworld> cherylj: that's normal - we use those hard coded names plus machine IP addresses in the CA cert SAN
<cherylj> ok
<wallyworld> cherylj: what may be the issue though is that we add the IP address of juju managed maches to the cert SAN - that I address has to be the source of where the wget comes from
<wallyworld> if they are using some weird network setup the cert addresses won't match
<cherylj> wallyworld: I think that's the case
<wallyworld> hmmm
<wallyworld> off hand i'm not sure how to solve that
<cherylj> the logs for the lxc-create show they're getting the image through 10.0.3.45, but the only ip in the certupdater is the 10.0.7.1
<wallyworld> yup
<menn0> thumper: wrt to that the juju-run/juju-dumplogs symlink issue, I've had a better idea
<wallyworld> the cert updater wroks off listening to the addresses juju records for the machines
<thumper> menn0: yeah?
<menn0> thumper: make the symlinks relative to the cmd.Context's Dir
<thumper> will that always work?
<wallyworld> cherylj: so we need to look at the address updater worker to see how to make it recognise and report the correct addresses
<menn0> thumper: in production this will be "/", but in tests (when using testing.RunCommand) it'll be a temp directory
<wallyworld> cherylj: off hand, i'd need to look into how all that works
<thumper> menn0: have you checked that production it is "/" ?
<menn0> thumper: yep, I just checked that
<thumper> menn0: also consider the current local provider
<menn0> thumper: what's different with the local provider?
<thumper> menn0: it is just "special"
<thumper> datadir is ~/.juju/<env-name>/
<wallyworld> cherylj: actrually, looking at the logs, that 10.0.3.45 address is the state server address
<menn0> thumper: yep, that's not related to this. the source of the symlink doesn't change. it's just where the symlink gets put.
<wallyworld> i'm talking about the machine on which the container is being created
<thumper> menn0: k
<cherylj> wallyworld: yeah...
<menn0> thumper: i'll make the change now as a separate PR so you can have a look
<wallyworld> cherylj: so we need to ensure the CA cert records in its SAN list the IP addresses of all worker machines, the addresses from which wget requests originate
<wallyworld> that means we need juju to record the correct thing in the machine address field
<wallyworld> so we need the machine agent (i think it's the agent) to report the correct addresses
<wallyworld> not sure how smart this all is with different nrtwork setups
<cherylj> wallyworld: I see that it picks up 10.0.3.45 as a machine address.  Not sure why the certupdater didn't include that one
<wallyworld> cherylj: that's the state server address
<wallyworld> we need to record the machine address from which the wget originates
<wallyworld> cherylj: so we need each machine to correctly report to juju its address
<wallyworld> or addresses
<wallyworld> those are stored in the machine addresses field in state
<wallyworld> that's what the cert updater listens to
<wallyworld> i think its the machine agent on each machine which reports those addresses
<cherylj> wallyworld:  you mean like this?  INFO juju.worker.machiner machiner.go:100 setting addresses for machine-0 to ["local-machine:127.0.0.1" "local-cloud:192.168.122.1" "local-cloud:10.0.3.45" "local-machine:::1"]
<wallyworld> so my guess from memory is that we need to look at how the machine agent queries its host addresses
<wallyworld> cherylj: are they running the lxc containers on machine 0?
<wallyworld> i was assuming there'd be a machine 1 or 2 or whatever
<cherylj> wallyworld: no, I think they're doing it on machine-1
<wallyworld> i think you said they were nesting lxc inside kvm?
<wallyworld> cherylj: right ok. so whatever the source IP address of the wget request is has to be recorded in the SAN list
<wallyworld> cherylj: that source address is the machine hosting the lxc containers
<wallyworld> which is typically machine 1's address. or it needs to be the kvm address if lxc inside kvm
<wallyworld> cherylj: so there needs to be a line in the logs like the above but which says setting addresses for machine-1 ....
<cherylj> wallyworld: okay, I see what you mean now
<wallyworld> cherylj: i have to relocate, will be afk for 20 minutes
<cherylj> wallyworld: sure, np
<ericsnow> natefinch: check out http://reviews.vapour.ws/r/3080/
<menn0> thumper: this approach is working out pretty nicely
<thumper> menn0: awesome
<thumper> menn0: did the no tail bit land in master?
<thumper> menn0: it may help me fix this problem :)
<menn0> thumper: yep, that's landed
<menn0> man there's lots of tests that use cmd.DefaultContext that should probably be using cmdtesting.Context
 * menn0 ignores for now
<perrito666> and then you froze
<perrito666> wwitzel3:
<perrito666> I meant wallyworld
<axw_> perrito666: what do you need a visa for?
<perrito666> axw_: enter australia
<axw_> perrito666: just for meetings? :/
<perrito666> axw_: I got an e-visa
<wallyworld> perrito666: we're here now
<davechen1y> https://github.com/docker/docker/pull/17700
<davechen1y> ^ docker have removed support for lxc
<mup> Bug #1513659 opened: 1.24.6 fails to bootstrap with "ERROR juju.cmd supercommand.go:430 upgrade in progress - Juju functionality is limited" <cloud-installer> <juju-core:New> <https://launchpad.net/bugs/1513659>
<mup> Bug #1513659 changed: 1.24.6 fails to bootstrap with "ERROR juju.cmd supercommand.go:430 upgrade in progress - Juju functionality is limited" <cloud-installer> <juju-core:New> <https://launchpad.net/bugs/1513659>
<mup> Bug #1513659 opened: 1.24.6 fails to bootstrap with "ERROR juju.cmd supercommand.go:430 upgrade in progress - Juju functionality is limited" <cloud-installer> <juju-core:New> <https://launchpad.net/bugs/1513659>
<davechen1y> mwhudson: ding ding ding.
 * mwhudson vibrates tunefully
<mwhudson> davechen1y: eh?
<davechen1y> your ppc64 observation
<ericsnow> katco: am I okay landing my fix of natefinch's patch?  http://reviews.vapour.ws/r/3080/
<mwhudson> davechen1y: ah heh
<ericsnow> katco: I'd like to land those LXD patches today
<mwhudson> davechen1y: can you re-run test_shared on arm64 pls?
<mwhudson> davechen1y: that was pretty mystically debugging from russ
<davechen1y> he is the master to psychic debugging
<davechen1y> mwhudson: arm64 -- will do
<mwhudson> ta
#juju-dev 2015-11-06
<lazypower> Is this bit just some spam or have i encountered a bug? http://paste.ubuntu.com/13118294/
<davechen1y> lazypower: yeah, that's not an awesome message
<davechen1y> it doesn't give a hint _why_ the dependency is unavailable
<davechen1y> ie, should you wait, or should you declare defcon 4
<lazypower> I just noticed that i dont have a leader in the service pool. Possibly related?
<davechen1y> almost certainly
<davechen1y> but that log message is shit
<davechen1y> please log a bug
<mup> Bug #1513667 opened: Better error messaging around uniter failure <juju-core:New> <https://launchpad.net/bugs/1513667>
<mup> Bug #1513667 changed: Better error messaging around uniter failure <juju-core:New> <https://launchpad.net/bugs/1513667>
<mup> Bug #1513667 opened: Better error messaging around uniter failure <juju-core:New> <https://launchpad.net/bugs/1513667>
<mup> Bug #1513671 opened: juju bootstrap fails <local-provider> <network> <wily> <juju-core:New> <https://launchpad.net/bugs/1513671>
<mup> Bug #1513671 changed: juju bootstrap fails <local-provider> <network> <wily> <juju-core:New> <https://launchpad.net/bugs/1513671>
<mup> Bug #1513671 opened: juju bootstrap fails <local-provider> <network> <wily> <juju-core:New> <https://launchpad.net/bugs/1513671>
<menn0> thumper: phew. here's the machine agent symlink improvements: http://reviews.vapour.ws/r/3082/
<thumper> m'kay
<menn0> this makes setting the symlink for juju-dumplogs a piece of cake
<thumper> just going through the rename branch suggestions you had
<thumper> menn0: http://reviews.vapour.ws/r/3072/
 * menn0 looks
<thumper> menn0: shipit
<menn0> thumper: thanks
<thumper> np
<menn0> thumper: ship it with a bunch more things to change
 * thumper sighs
<thumper> oh FFS
<thumper> I feel that this is never ending
 * thumper looks for a knife so he can finish it all...
<natefinch> thumper: have you looked at using gorename?  It won't find things to rename, but it should type-safely rename all copies of type/method/etc
<thumper> natefinch: that isn't the problem...
<thumper> there are many methods with System in the name
<thumper> system in docs
<thumper> help docs
<thumper> variable names
<thumper> spewed everywhere
<thumper> environment rename will be worse
<davechen1y> thumper: tried the vpn
<davechen1y> no job
<davechen1y> joy
<davechen1y> see email, i'm waitin on the ibm contact to fix
<thumper> davechen1y: did you try using the name rather than the ip address?
<thumper> I think that was in the email thread
<davechen1y> i'm using the openconnect strink that popey used
<davechen1y> i have no problem conneting to the service
<davechen1y> but my credientials expired 5/11/2015
<davechen1y> i don't know which timezone that is
<davechen1y> but they need to be refreshed and I cannot do that because the interface to do so is behind the vpn
<thumper> hazaah
<thumper> magical
 * thumper goes back to smashing his head against the table
 * thumper sadface
<thumper> just came across another intermittent failure in worker/provisioner
<davechen1y> thumper: would you care for a break and a chat about the various charm.* types in state ?
<menn0> thumper: juju-dumplogs work is done: http://reviews.vapour.ws/r/3075/diff/#
<thumper> sure, two minutes
<menn0> this is what you've reviewed + the symlink stuff
<menn0> no rush
<natefinch> thumper: what's the error you're seeing?  I was getting a weird error in provisioner earlier today
<natefinch> thumper: http://pastebin.ubuntu.com/13115387/
<thumper> nope, http://paste.ubuntu.com/13121047/
<natefinch> hmm
<thumper> davechen1y: 1:1 hangout
<davechen1y> thumper: yup
<davechen1y> just getting my other laptop
<davechen1y>         return insertAnyCharmOps(&charmDoc{
<davechen1y>                 DocID:        curl.String(),
<davechen1y>                 URL:          curl,
<davechen1y> thumper: oh oh, maybe reflect.DeepEqual will do all the magic we need
<davechen1y> gonna run some test
<davechen1y> gonna run some tests
 * thumper feels sad
<thumper> we have a method ConnectStream that takes a path and attrs
<thumper> and every single test passes nil for the attrs
<cherylj> wallyworld: ping?
<davechen1y> thumper: if that parameter is 99% unused, especially in the default case
<davechen1y> it should be removed
<davechen1y> and a second method added for the case that needs the second parameter
<thumper> no, real use passes it in
<thumper> but our tests don't test
<davechen1y> where is the emoji for jaw hitting table
<thumper> menn0: looks like I'm implementing the juju/api and apiserver bits for NoTail for debug log just to get the freaking tests passing...
<menn0> thumper: well that takes care of the that bug 1390585 then  :)
<mup> Bug #1390585: juju debug-log and EOF <debug-log> <landscape> <juju-core:Triaged by menno.smits> <https://launchpad.net/bugs/1390585>
 * menn0 assigned the card to thumper and moves it to "in progress" :-p
<thumper> \o/
<davechen1y> thumper: I have 7 version of juju/charm in my GOPATH
<davechen1y> 4 released, 3 unreleased
<thumper> \o/
<davechen1y> this scares the piss out of me
<davechen1y> how did we not manage to insert invalid data into mongo ?
<natefinch> did something change with how machine numbers are assigned?  I seem to be getting machine 0, 1, 3, 8 (+-1) instead of reliably 0 1 2 3 4
<davechen1y> natefinch: yes, they are now assigned exponentially
<menn0> natefinch: didn't you change something in this area recently?
<natefinch> menn0: yeah, the unit assignment now runs on a worker... but in theory that shouldn't have changed how the machine  numbers are assigned.  That code is the same, it's just getting run slightly later.
<menn0> natefinch: granted, but given the locality of the change...
<natefinch> menn0: oh sure, my first assumption was that it was my fault :)
<menn0> :0
<menn0> :) even
 * thumper chucks it in for the week
<thumper> laters
<natefinch> well crap, I suppose I should just revert my unit assigner merge until such a time as I can fix these bugs....
<natefinch> gah, what the hell is the magic incantation to tell CI that I'm trying to merge the fix to the blocker?
<natefinch> sinzui: don't suppose you're around?
<natefinch> wallyworld: you around?
<natefinch> or menn0 ?
<wallyworld> maybe :-)
<natefinch> how the hell do I mark my PR as fixing the blocking bug?
<wallyworld> zup?
<menn0> natefinch: $$fixes-NNNNNN$$
<wallyworld> $$fixes-12345$$
<menn0> ha :)
<natefinch> I friggin' have that in my first comment...
<wallyworld> which pr?
<natefinch> https://github.com/juju/juju/pull/3679
<wallyworld> it needs to go in the merge command
<wallyworld> not the cover description
<menn0> actually, I don't think it has to be in the merge command
<wallyworld> sure?
<menn0> but it has to be in a comment, not the description
<wallyworld> yup
<natefinch> dumb
<wallyworld> that's what i meant
<menn0> yeah, i'm pretty sure you can do fixes-NNNNNNN in one comment and then separately do $$merge$$ later
<menn0> $$fixes-NNNNNN$$ is just the most convenient way to do it
<natefinch> it would be nice if the error message more clearly indicated how to fix the problem.
<natefinch> (and if we checked the description as well :/)
<wallyworld> natefinch: Build failed: Does not match ['fixes-1513552']   is not clear enough?
<natefinch> wallyworld: no.  It doesn't say how to get the PR to merge. It says something does not match something else.  There's zero context.
<wallyworld> there is a tiny bit of assumed knoweldge there
<natefinch> It only takes 30 seconds to write a better error message to avoid confusion.  For example, it could say that the string 'fixes-NNN' must be in a comment, not the description.
<menn0> natefinch: suggest it to mgz_ and it might happehn
<natefinch> Target branch is blocked by a critical bug (http://pad.lv/NNNNN).  If this PR would fix that bug, include the string 'fixes-nnnn' in a comment (not the description) on this PR, before using $$merge$$.
<natefinch> menn0: will do
<natefinch> davechen1y: what is this, java? https://github.com/juju/juju/blob/master/state/unit.go#L739
<natefinch> davechen1y: related: https://github.com/juju/juju/blob/master/apiserver/client/status.go#L660
<frobware> j
<davechen1y> natefinch, nailed it
<rogpeppe1> wallyworld: ping
<voidspace> dimitern: frobware: grabbing coffee, be three minutes
<dimitern> omw as well
<voidspace> omw
<voidspace> dimitern: frobware: gah, firefox misbehaving - having to restart browser
<perrito666> wallyworld: still here?
<wallyworld> perrito666: hey
<wallyworld> rogpeppe1: hi, you rang?
<rogpeppe1> wallyworld: hiya
<rogpeppe1> wallyworld: yeah, i just discovered that a PR of yours (that I reviewed!) broke stuff, and just wanted to check that you thought the fix was ok: https://github.com/juju/charm/pull/167
<wallyworld> oh no, looking
<wallyworld> rogpeppe: seriously? I mesed up capitisation?
<wallyworld> sigh
<rogpeppe> wallyworld: np
<rogpeppe> wallyworld: easy to do
<wallyworld> ty for fixing
<wallyworld> rogpeppe: i'll update the dep for core on monday
<rogpeppe> wallyworld: FWIW i recently started on a tool for automatic API compatibility checking. i'll try and move it forward - it would've helped here i think: https://github.com/rogpeppe/apicompat
<wallyworld> oh, sounds nice, i'll look
<rogpeppe> wallyworld: (that's just a one day spike to see if it was viable so no tests or docs...)
<wallyworld> sure :-)
<wallyworld> rogpeppe: too tired to look properly now, but on my todo list
<rogpeppe> wallyworld: the basic idea is that you write out type info on all the types you're interested in (e.g. all the types that have been serialised/deserialised) to a file; then later you can check that the types are still compatible with what you wrote before
<wallyworld> ok
<cherylj> frobware: looks like this old bug has now become part of a crit sit:  https://bugs.launchpad.net/juju-core/+bug/1382556
<mup> Bug #1382556:  "cannot allocate memory" when running "juju run" <cpe-critsit> <run> <juju-core:Triaged> <https://launchpad.net/bugs/1382556>
<cherylj> frobware: got anyone who can take a look?
<cherylj> alexisb, fyi ^^
<frobware> cherylj, I can take a look as my current bug has stalled (broken tests).
<cherylj> thanks, frobware
<dimitern> fwereade, hey, so it seems you got back online before me :)
<fwereade> dimitern, haha, yeah
<katco> frobware: hey
<frobware> katco, what's up?
<katco> frobware: can i move the cards from sapphire's kanban to moonstone's for those bugs?
<frobware> katco, please do
<katco> frobware: the ones that won't be finished anyway
<katco> frobware: perfect, ty!
<frobware> dooferlad, if you have chance today could you post links to your scripts for the HA bug, or better yet update the bug to reflect their location
<katco> frobware: lol oops, looks like i don't have permissions
<frobware> katco, ^^^
<katco> frobware: dooferlad: yes, updating the bug would be perfect! ty for creating those
<dooferlad> frobware: will do
<frobware> katco, just updated your profile on kanban board, care to try again?
 * katco attempting
<katco> frobware: looks like it's working... ty
<katco> frobware: am i blind? i can't seem to find more than 1 card for all those bugs
<frobware> katco, did you move the HA card?
<katco> frobware: yeah, that's the only one i could find
<frobware> katco, I'm trying to remember whether they were there this morning (from planning) or they got nuked...
<frobware> frobware, as I notice our archive has now been compressed to show 0 cards...
<frobware> dimitern, ^^ did you do some cleanup in the kanban board?
<katco> frobware: looks like there are some in the archive'd super-card
<frobware> katco, I wouldn't dig through our trash - create a new card...
<katco> frobware: haha ok
<dimitern> frobware, nope, it automatically does that I think after 2 weeks
<frobware> dimitern, eco friendly. :)
<katco> dimitern: o/ looking forward to seeing you again in dec.
<dimitern> katco, hey - yeah, it will be a change of pace for sure :)
<mup> Bug #1513671 changed: juju bootstrap fails <local-provider> <network> <wily> <juju-core:Invalid> <https://launchpad.net/bugs/1513671>
<natefinch> katco, ericsnow: that last 1 pointer is merging now... made the code review changes eric suggested and will do the IOC stuff in a separate PR.
<ericsnow> natefinch: cool
<katco> natefinch: but... but! i want to bikeshed more!
<fwereade> katco, I am inspecting something that might be a bikeshed right now... trying to figure out whether it's actually a good idea to close watcher Changes chans when the watcher stops
<katco> fwereade: ah i think i remember when that came up
<fwereade> katco, because I *think* that it's an artifact of the lack of something-like-catacomb
<katco> fwereade: wasn't the consensus that it's fine not to close it because the process would be torn down momentarily?
<katco> lol
<katco> something-like-catacomb
<katco> hoenycomb?
<katco> paris?
<fwereade> katco, http://reviews.vapour.ws/r/3079/ ;p
<fwereade> katco, so I think the forces are
<katco> oh catacomb is actually a thing
<fwereade> katco, when using a watcher you generally start it, defer a stop, and then select on changes forever
<fwereade> katco, and so your only (heh) channel for notification of watcher problems is the changes chan
<fwereade> katco, and closing it seems, eh, nice and idiomatic because then you could range over it, and it means "you're not getting any more values" so it seems to fit perfectly
<fwereade> katco, and so we can make the select loop aware of problems
<fwereade> katco, and then every select needs to check for that condition
<fwereade> katco, and `if !ok { return watcher.EnsureErr(w) }`
<katco> fwereade: this idea seems very good... reading through code
<fwereade> katco, but I think the flaw is basically: just because you *can* use the changes chan for that notification does not mean you *shoul*
<fwereade> katco, so, with something like catacomb, if you bind the watcher's lifetime to the containing worker's and the worker's life to the watcher's lack of failure
<fwereade> katco, you'll get the something-is-wrong notifications direct to the Dying chan
<fwereade> katco, and the worker's tomb will actually have been hit with (something much more likely to be) the *first* error encountered in that goroutine tree
<katco> yeah... on the surface i really like the idea of encapsulating that coupling in a codified type
<fwereade> katco, another thing that I like is that it means we don't have to `defer watcher.Stop(`
<katco> fwereade: it removes some of the discipline required to get watchers right
<fwereade> katco, which I have just realised is almost always subtly wrong
<fwereade> katco, because when the loop errors out and then a watcher fails for boring reasons, the watcher faillure hits the worker's tomb first
<katco> fwereade: re: doc comment; i wouldn't worry about # of goroutines
<katco> fwereade: i doubt we could spawn enough for it to really matter
<fwereade> katco, well, it is a fundamental difference -- a catacomb needs its own lifetime management
<fwereade> katco, once you New() you're responsible for it
<fwereade> katco, but maybe it's not important at that point in the doc
<natefinch> fwereade: you need to move the core worker code into its own repo, so that catacomb can live in its own repo... we gotta stop hiding all this good code deep in the juju internals
 * fwereade blushes
<fwereade> natefinch, but, yeah, there is a chunk of worker-related functionality that's starting to want to move into its own repo
<natefinch> fwereade: I think the quality of code goes up when we decide we want to be able to share it with the entire world, rather than keeping it buried in juju somewhere.
<fwereade> natefinch, yeah, could well be
<fwereade> natefinch, and this + dependency.Engine should go nicely together
<natefinch> fwereade: yeah, all our really generic code like worker, dependency engine, catacomb, etc.  I think would be valuable to share with people.  Who knows, we might even get PRs against them (I know I have with some of my repos)
<fwereade> natefinch, although it's also seeming a bit like catcomb wants/ought to do error-ranking like dependency engine (and worker.Runner) do
<fwereade> natefinch, so I'm suspicious that I haven't got stable enough interfaces
<natefinch> I think putting it in its own repo helps with that, too.  Easy to show to people, easy to view the godoc on godoc.org, forces you to write better documentation, include a readme, etc.
<fwereade> natefinch, on the one hand, that increases the resistance to putting it in its own repo; on the other, that's no goddamn excuse really, is it ;)
<natefinch> you can certainly put a disclaimer at the top that says it's still in flux.  I did that for https://github.com/juju/deputy
<fwereade> natefinch, yeah... but, sorry, gtg, bbiab I hope?
<natefinch> ..which, hey, has a PR against it :)
<fwereade> nice :D
<natefinch> fwereade: kk
<katco> fwereade: ty
<natefinch> gah
<natefinch> I can't merge PRs under github.com/juju anymore :/
<natefinch> katco: can you give me write access to github.com/juju/deputy so I can merge PRs to it?
<katco> natefinch: done
<natefinch> katco: thanks!
<jcastro> can a core dev give a nice answer to this one? http://askubuntu.com/questions/693689/juju-charms-rest-api
<mgz_> natefinch: can we just set access on juju/deputy to the hackers group? or does it need to be just you?
<katco> mgz_: i almost did the hackers group, but wanted to ask you first
<mgz_> katco: we gernally have either that or bots - if the project has a good test suite we can make it gated and use bots, otherwise hackers means the magic erge button appears for all of us
<cherylj> hey evilnick__ , someone pointed out to me today that the command usage statements on this page all have "no-highlight" in front of them:  https://jujucharms.com/docs/devel/commands
<katco> mgz_: i could go either way
<evilnick__> cherylj, ah yes, thanks for pointing it out - that is a bug in the rendering of the site. After a new release, the page gets automatically regenerated and in this case, it hasn't been patched to fix the problem. I will take care of it.
<cherylj> thanks, evilnick__ !
<katco> cherylj: are we going to do a 1.24.8?
<cherylj> katco: that is the $64,000 question
<katco> cherylj: i'm going to mark the milestone as inactive. we can always turn it back on
<cherylj> I think we'd like to avoid it, since we're going to try and get 1.25 back into trusty
<dimitern> cherylj, in that line of thought, I've just proposed the fix for bug 1483879
<mup> Bug #1483879: MAAS provider: terminate-machine --force or destroy-environment don't DHCP release container IPs <bug-squad> <destroy-machine> <landscape> <maas-provider>
<mup> <sts> <juju-core:Triaged> <juju-core 1.24:In Progress by dimitern> <juju-core 1.25:In Progress by dimitern> <https://launchpad.net/bugs/1483879>
<cherylj> awesome, thanks dimitern
<cherylj> I'll take a look this afternoon
<dimitern> frobware, ^^
<dimitern> cherylj, sure, I'd appreciate it - it's a bit quick-and-dirty in a few places, because I really want to get it out the door (1.24.8 will be the last 1.24 I hope), it should be tested better for 1.25/master
<cmars> jcastro, i don't have a working stackexchange account, but this would probably be helpful: https://github.com/juju/juju/blob/master/doc/api.txt
<cmars> jcastro, short of a nice library for accessing the api, which we don't have yet
<mgz_> cmars: you can sso using lp, no?
<cmars> mgz_, oh, maybe so, there's a lp for this one, isn't there. ok
<mgz_> well, anything that just needs an open id endpoint like stack overflow etc you can just paste your lp user page
<natefinch> mgz_, katco: I'm fine with using the bot.  deputy has 94% test coverage.
<cmars> mgz_, got it. ok, i'll answer it :)
<wwitzel3> natefinch, katco, ericsnow: ping
<katco> wwitzel3: hey
<katco> wwitzel3: tried to bootstrap lxd and got an error on the unix socket. controller machine is started. what am i doing wrong?
<wwitzel3> katco: that's odd
<wwitzel3> katco: what is the head of your lxd-branch?
<katco> wwitzel3: 0a01db9
<katco> oh jees
<katco> that's what's wrong
<katco> 3 weeks ago
<katco> i must not have pulled
<wwitzel3> lol
<katco> there we go... this should be a lot better
<katco> this provider is so nice
<katco> no mongo on my host ^.^
<wwitzel3> I uninstalled mongo
<wwitzel3> completely, it is great
<katco> i recently switched machines and never installed juju-local
<katco> it's beautiful
<natefinch> don't you need mongo to run the tests?
<katco> natefinch: i don't typically run all the tests, just the ones around what i'm working on
<katco> natefinch: so far, hasn't been a problem, but i'm atypical
<mup> Bug #1513552 changed: master cannot deploy charms <blocker> <charm> <ci> <deploy> <regression> <juju-core:Fix Released by natefinch> <https://launchpad.net/bugs/1513552>
<natefinch> ericsnow, katco: is the bot supposed to work on the lxd-provider branch?
<katco> natefinch: yeah
<ericsnow> natefinch: yes, but it won't run our tests (runs Go 1.2)
<natefinch> ericsnow: right
<ericsnow> natefinch: so we have some failing tests that got merged
<natefinch> ericsnow: ahh, I see the problem, I forgot to mark my test file as go1.3
<katco> ericsnow: natefinch: wwitzel3: you all ready to do the demos?
<ericsnow> katco: yep
<wwitzel3> katco: yep
<natefinch> yep
<natefinch> katco: can you make that juju/version repo and give juju-hackers write access to it?
<katco> natefinch: sec, in a hangout debugging a charm
<natefinch> katco: no rush, just wanted to be able to work on that later on tonight...
<perrito666> natefinch: see you have killer friday nights
<mup> Bug #1513982 opened: Juju can't find daily image streams from cloud-images.ubuntu.com/daily <streams> <juju-core:Triaged> <https://launchpad.net/bugs/1513982>
<jog> ericsnow, I just opened bug 1513982, it may be a dup of 1287949 but I'd like input from someone else, are you able to look it over?
<mup> Bug #1513982: Juju can't find daily image streams from cloud-images.ubuntu.com/daily <streams> <juju-core:Triaged> <https://launchpad.net/bugs/1513982>
<perrito666> k EOD
<perrito666> EOW
<perrito666> game set match :p cheers
<ericsnow> jog: it could be related to metadata signing; I seem to recall Sergey mentioning something about this
<ericsnow> jog: this is vsphere-specific, right?
<jog> yes... I'm trying to test an updated OVA for use by vsphere, that utlemming has pushed into daily
<ericsnow> jog: yep, I'm pretty sure Sergey had a work-around that he used when manually testing the provider
<ericsnow> jog: if I remember right, it involved commenting out some line of code somewhere to disable that signed image check
<jog> I'll subscribe him to the bug and see if he can give some guidance. Although I was able to test this image when I used a locally hosted image stream and set image-metadata-url
#juju-dev 2015-11-07
<katco> natefinch: https://github.com/juju/version
<natefinch> katco: thanks!
<mup> Bug #1513468 changed: imports github.com/juju/juju/payload/api/internal/client: use of internal package not allowed <blocker> <ci> <regression> <testing> <wily> <juju-core:Invalid> <juju-core 1.25:Fix Released> <juju-core feature-payloads:Won't Fix> <https://launchpad.net/bugs/1513468>
<mup> Bug #1513468 opened: imports github.com/juju/juju/payload/api/internal/client: use of internal package not allowed <blocker> <ci> <regression> <testing> <wily> <juju-core:Invalid> <juju-core 1.25:Fix Released> <juju-core feature-payloads:Won't Fix> <https://launchpad.net/bugs/1513468>
<mup> Bug #1513468 changed: imports github.com/juju/juju/payload/api/internal/client: use of internal package not allowed <blocker> <ci> <regression> <testing> <wily> <juju-core:Invalid> <juju-core 1.25:Fix Released> <juju-core feature-payloads:Won't Fix> <https://launchpad.net/bugs/1513468>
<natefinch> never read the comments
#juju-dev 2015-11-08
<mup> Bug #1491226 changed: juju status hangs at 'connection established to' until jujud-machine-0 restarted <api> <juju-core:Expired> <https://launchpad.net/bugs/1491226>
<menn0> thumper: I still need a ship it on this: http://reviews.vapour.ws/r/3075/diff/
<menn0> you've reviewed most of it already, it's the symlink setting parts that are new
<thumper> k
 * thumper has to run out for a bit
<thumper> bbl
<thumper> back
<menn0> thumper: the PRs that http://reviews.vapour.ws/r/3075/diff/# depends on have landed. I just need a ship it for it now.
<thumper> k
<davecheney> wow
<davecheney> charm.v6-unstable contains a copy of charm.v4
<davecheney> god damnit
<davecheney> my ibm password has expired again
<davecheney> they issued it over the weekend
<davecheney> and it's alread expired
<davecheney> thumper: https://github.com/juju/juju/pull/3671/files#diff-2f723729fea9cfb2d2969e45da24fcdbR20
<davecheney> the number of unwritten assumptions on this simple function is quite large
<davecheney> https://github.com/juju/juju/pull/3671/files#diff-2f723729fea9cfb2d2969e45da24fcdbR62
<davecheney> ^ don't wrap here, 'cos the caller is checking for a magic value
#juju-dev 2016-11-07
<babbageclunk> veebers: Sorry, went and grabbed some lunch - it looks like I'm the only one here! I guess no need to do it if it's just going to be me and you.
<veebers> babbageclunk: ugh, sorry forgot to jump on. but yeah I have nothing new for the standup
<babbageclunk> veebers: I thought I'd go just in case anyone else wasn't going and I'd forgotten.
<babbageclunk> veebers: I mean, wasn't going to the sprint.
<veebers> babbageclunk: ah good point.
<babbageclunk> Anyone around that feels like doing an easy review? https://github.com/juju/juju/pull/6544
<veebers> babbageclunk: would you know anyone that might be around that is a charms master?
<veebers> I have an issue where a service that I'm setting up in a charm responds once and then seems to die (any follow up responses fail)
<babbageclunk> veebers: not that would be around now, I don't think - the ones I've dealt with are in the eastern US
<babbageclunk> Nothing in logs?
<veebers> babbageclunk: aye, not surprising :-) Would you be able to suggest someone that I might be able to ping tomorrow?
<veebers> babbageclunk: no, it's a bit of a head scratcher for me. I can't find any relevant logs etc. (although I might be looking in the wrong place)
<babbageclunk> oh, apparently stub is in Bangkok and it's 9:53am there, so he might be worth pinging
<veebers> babbageclunk: awesome thanks I'll give it a try
<babbageclunk> veebers: :)
<babbageclunk> otherwise marcoceppi seems like a person who could give you pointers
<babbageclunk> veebers: ^
<veebers> babbageclunk: sweet, thanks again
<mgz> morning all
<SimonKLB> hey could someone please explain how i can expand the charm client with the terms commands?
<SimonKLB> this: https://github.com/juju/terms-client
<rick_h___> ashipika: ^
<rick_h___> ashipika: is that not built into charm currently?
<ashipika> rick_h___: sorry? i missed that..
<rick_h___> SimonKLB: is asking "hey could someone please explain how i can expand the charm client with the terms commands?
<rick_h___> 11:29 AM this: https://github.com/juju/terms-client"
<rick_h___> ashipika: ^
<ashipika> rick_h___: currently you have to check out the project and run go install ./â¦ to install plugins.. there was talk of a .deb â¦ let me check
<rick_h___> ashipika: thanks, if you can help SimonKLB with it <3
<ashipika> SimonKLB: ping?
<SimonKLB> ashipika: pong!
<SimonKLB> was on lunch, thanks ill install it myself
<ashipika> SimonKLB: so.. "snap install charm"  should work for you
<SimonKLB> great
<voidspace> dooferlad: so our standup time has moved again due to US daylight savings?
<voidspace> I wasn't expecting that...
<dooferlad> voidspace: not that I know of
<voidspace> dooferlad: it's now back in my calendar as 3pm
<dooferlad> voidspace: ISWYM
<voidspace> Ah well
<dooferlad> voidspace: Shows how much attention I pay to the clock rather than the calendar
<voidspace> :-)
<voidspace> I'm trying to remember to check my calendar at the start of the day
<voidspace> didn't quite manage it today...
<dooferlad> voidspace: https://github.com/juju/testing/pull/116/files is about as small a change as I can make - PTAL
<voidspace> dooferlad: hah
<voidspace> dooferlad: LGTM :-)
<dooferlad> voidspace: thanks :-)
<dooferlad> voidspace: another 1 line change... https://github.com/juju/juju/pull/6545
<dooferlad> voidspace: if you could do the honors
 * macgreagoir is having trouble joining the HO...
<katco> macgreagoir: you were in there momentarily
<katco> frobware: dooferlad: standup time
<mup> Bug #1639855 opened: 2.0 metrics breaks 1.25 <juju-core:New> <https://launchpad.net/bugs/1639855>
<dooferlad> katco: could you take a quick look at this deps bump? https://github.com/juju/juju/pull/6545
<katco> dooferlad: tal
<dooferlad> katco: for the mongo needing to have --option=value not --option value issue
<dooferlad> katco: not a lot to review really :-)
<katco> dooferlad: yeah :) are you wanting me to rubber stamp, or look at why the checks failed?
<dooferlad> katco: stamp
<dooferlad> katco: the tests failed for not interesting reasons
<katco> dooferlad: our test suite continues to make me sad
<dooferlad> katco: thanks!
<katco> dooferlad: ty!
<dooferlad> katco: +1 to that
<natefinch> voidspace: you around?
<voidspace> natefinch: yep
<natefinch> voidspace: so you replied about no tests for cloudschema... I'm not entirely sure how I'd test the schema, since it's sort of like declaring a value. I suppose I could make what I consider to be a valid schema and make sure it is validated by the schema.  Would that work? did you have something else in mind?
<voidspace> natefinch: well, the ones that return nil are easy to test
<voidspace> natefinch: and for the not nil ones your idea sounds good
<voidspace> natefinch: making sure that the schema returned validates something that should and not something that shouldn't
<voidspace> natefinch: it's a nuisance, but otherwise it's uncovered code
<natefinch> voidspace: fair enough
<natefinch> voidspace: I would skip testing the ones that return nil. The code is entirely correct from trivial inspection, and I don't think having a test there adds any assurance.  Also, there are indirect tests in the add-cloud code that if anything but the expected providers return a schema, that test will fail.
<thumper> morning folks
<voidspace> thumper: o/
<voidspace> thumper: morning, you made it back home then?
<thumper> yeah, eventually
<thumper> feeling kinda fuzzy headed thought
<voidspace> thumper: sounds like quite the adventure...
<voidspace> thumper: yeah, not surprised
<thumper> it's a story
<thumper> :)
<voidspace> thumper: always good to collect a new story :-)
<thumper> I can laugh about it now, but at 4:30am at the airport, not so much
<thumper> babbageclunk: morning
<babbageclunk> hey thumper, sounds like you had an adventure getting back?
<perrito666> hey thumper I assumed you would be dayswapping today
<babbageclunk> yeah, same
<thumper> swap days when you are feeling better
<thumper> :)
<babbageclunk> lol
 * thumper has been going through lots of email
<thumper> time for another coffee though
<perrito666> I just convinced my neigborhood to communicate through a mailing list, that must be an achivement of some sort
<babbageclunk> perrito666: you're living in a 90's vision of the future!
<perrito666> babbageclunk: well they where using whatsapp and thinking into transitioning to facebook
<perrito666> so ill take the 90s any day over that
<babbageclunk> perrito666: oh right - well, that's much better than our semi-dystopyian present.
<babbageclunk> ugh spelling
<perrito666> ok, I am bit at a loss, here, suppose I have a *state.State object and want to get a hold of the *providers.Environ for that particular state, what is the path?
<perrito666> babbageclunk: well they where killing the battery of my phone with all the whatsapping so that might have been a  bit of my motivation :p
<thumper> perrito666: hmm
<thumper> you need to get the config
<thumper> then environ.Open the details
<perrito666> mmm, ok, not my favorite path but what can I do
<babbageclunk> You could look in the environ tracker for an example.
<perrito666> babbageclunk: tx
<thumper> perrito666: how would you expect to do it?
 * thumper tries to prioritise his tasks
<perrito666> thumper: state.State{}.ItsLateAndIAmTiredGiveMeAnEnviron()
<thumper> babbageclunk: quick hangout to sync on migrations?
<thumper> perrito666: heh
<perrito666> thumper: sorry to distract you of your prioritizing, should I expect you at the standup?
<thumper> yeah, but note that the US times changed
<thumper> so I can now make lunchtime BJJ class
<babbageclunk> thumper: yes please!
<thumper> again
<perrito666> thumper: oh look at that
<perrito666> so its 1h late
<thumper> babbageclunk: let's jump in our 1:1 hangout
<babbageclunk> okeydoke
<perrito666> I think our standup has only 1 person from the US... I feel cheated :p
<perrito666> oh, 2 people
<perrito666> the rest of us are from southern hemisphere
<perrito666> ok, bbl
<veebers> marcoceppi: Ping, would you have a moment for a charm question?
<thumper> ugh, gave up on the idea of gym at lunchtime
<thumper> too knackered
<perrito666> I gave up my gym time for a home owner association meeting and in more than 1h we decided nothing and I believe undecided a few things
#juju-dev 2016-11-08
<babbageclunk> thumper, perrito666, redir: Anyone up for a review? https://github.com/juju/juju/pull/6544
<redir> babbageclunk: someone lookin?
<babbageclunk> redir: I think thumper said he would.
<redir> ack
<babbageclunk> haha, mistyped that as thumber first
<thumper> yeah, I'm looking
<thumper> babbageclunk: sorry for the delay
<babbageclunk> thumper: no worries
<thumper> got myself confused with something in the review
<thumper> but all good
<babbageclunk> veebers: my build failed due to lack of memory: http://juju-ci.vapour.ws:8080/job/github-merge-juju/9627/console
<babbageclunk> veebers: can you give something a kick? Should I just restart the build?
<veebers> babbageclunk: let me have a look
<veebers> babbageclunk: the issue is there are a bunch of (probably) leaked lxd containers running on that machine, i'm just attempting to clarify what I can kill safely to free up space
<veebers> babbageclunk: ok, hopefully I haven't destroyed the universe (just killed a bunch of machines) can you go ahead and !!build!! that PR of yours? It should get through this time
<babbageclunk> veebers: Thanks!
<veebers> babbageclunk: nw, let me know if you have any other issues
<thumper> poo
<thumper> something screwy is happening
<veebers> thumper: with CI? (he asks after having removed some machines)
<thumper> veebers: no, with migration
<thumper> babbageclunk: around to be a rubber duck?
<babbageclunk> thumper: sure - actually I could use a rubber duck in turn
<thumper> ok, 1:1 HO?
<mup> Bug #1640113 opened: In LXD machines in localdomain not resolvable <juju-core:New> <https://launchpad.net/bugs/1640113>
<SimonKLB> uhm, i just deployed wordpress+mysql on one machine and haproxy on another then BOOM it deployed 15 machines all of a sudden on aws
<SimonKLB> i have no idea how that happened
<perrito666> morning all
<dooferlad> mgz: is http://juju-ci.vapour.ws:8080/job/github-merge-develop-to-staging/ really the merge develop to staging job?
 * dooferlad has a conflict I can't resolve because develop hasn't merged back into staging
<mgz> dooferlad: that should be it
<mgz> dooferlad: if you want to actually land your branch you'll need to merge the conflicting change from staging into it to resolve (or rebase on later change)
<rick_h> voidspace: can you join the other #juju please and help someone out?
<voidspace> rick_h: #juju on canonical?
<rick_h> voidspace: yes please
<voidspace> rick_h: in standup now, but will take a look as well
<rick_h> K
<natefinch> rick_h: standup?
<rick_h> natefinch: can't ATM. About to give a lightening talk.
<natefinch> rick_h: kk
<rick_h> Phone irc'ing while in line
<natefinch> ahh
<aisrael> Is there a reason why action names can't include numbers, i.e., an action named iperf3 will throw a "ERROR bad action name iperf3" when trying to deploy/upgrade the charm.
<voidspace> at the moment my girl is at "science club" on Tuesdays, so I can stay for the whole of standup
<voidspace> just FYI
<voidspace> and I have a hospital appointment tomorrow morning
<mgz> science club sounds fun
<voidspace> mgz: only her second one today, they made a dinosaur tooth last week but she really wants explosions which they have been promised at some point by "Atomic Tom" who takes it...
<mgz> ehehe, in it for the bangs
<voidspace> always
<voidspace> :-)
<voidspace> katco: o/
<voidspace> uhm, nope, my hospital appointment is Thursday morning
<voidspace> perrito666: can you answer aisrael's question about actions?
<voidspace> aisrael: I suspect the answer maybe "no good reason"... Can you file a bug about it?
<natefinch> AFAIK, no good reason
<natefinch> var actionNameRule = regexp.MustCompile("^[a-z](?:[a-z-]*[a-z])?$")
<aisrael> voidspace: Yep, I'll do that. I figured if it was for a reason, the docs/charm tools need to be updated to reflect it.
<voidspace> aisrael: yep
<voidspace> aisrael: natefinch: looks easy to fix then...
<aisrael> voidspace: natefinch: excellent, thanks. Filing a bug now.
<voidspace> assuming there is no good reason
<voidspace> aisrael: if we find a reason we'll let you know :-D
<perrito666> voidspace: no, I dont know why that is
<dooferlad> voidspace: do you know why we have a networking interface defined for vsphere? https://bugs.launchpad.net/juju/+bug/1638401 exists because provider/vsphere/environ_network.go exists
<mup> Bug #1638401: vsphere: spaces spams the logs with an error <juju:Triaged> <https://launchpad.net/bugs/1638401>
<perrito666> dooferlad: that was done by third party so they might have just cargo culted
<dooferlad> perrito666: ah, thanks
<voidspace> dooferlad: no, no idea
<dooferlad> voidspace: no worries, the question was answered by perrito666.
<voidspace> dooferlad: cool :-)
<perrito666> bbl relocation
 * redir steps out to vote and grab lunch on the way back.
<perrito666> bbl
<thumper> o/ babbageclunk
<babbageclunk> morning thumper!
<babbageclunk> exciting day today
<perrito666> back
<SimonKLB> seeing this when bootstraping an LXD controller: ERROR juju.state database.go:231 using unknown collection "remoteApplications"
<SimonKLB> any ideas?
<SimonKLB> 2.0.1-xenial-amd64
<thumper> babbageclunk: terrifying day you mean?
<thumper> babbageclunk: I worked out how to work around the bug in migrations to finish QAing my branch
<babbageclunk> thumper: yes, that
<babbageclunk> thumper: oh, nice!
<thumper> so doing that now
<babbageclunk> thumper: I think I worked out an approach to sharing some of the code in logsink, trying it out.
<perrito666> SimonKLB: oh, that looks like a bug, what bootstrap command did you use?
<SimonKLB> perrito666: just `juju bootstrap localhost a-name`
<SimonKLB> i saw this: https://bugs.launchpad.net/juju/cross-model-relations/+bug/1634956
<mup> Bug #1634956: unknown remoteApplications on deploy <ci> <deploy> <jujuqa> <juju:Incomplete> <juju cross-model-relations:Triaged> <https://launchpad.net/bugs/1634956>
<SimonKLB> but in my case it was right away after the controller was installed
<SimonKLB> i didnt deploy anything
<perrito666> SimonKLB: I see, I believe we can work around this bug by setting a flag, let me look for it
 * redir back
<thumper> babbageclunk: hazaar, have now confirmed it works
<perrito666> SimonKLB: JUJU_DEV_FEATURE_FLAGS=cross-model
<SimonKLB> perrito666: great, thanks! i realized why i saw it early btw, it shows up when i run juju status
<thumper> babbageclunk: https://github.com/juju/juju/pull/6548
<babbageclunk> thumper: ooh, longish - let me finish the thought I'm sketching out then I'll review yours.
<thumper> babbageclunk: ta
<babbageclunk> thumper: Sorry, got a bit caught up in the weeds there. Can you look at this https://github.com/juju/juju/commit/eafd1f8286d4898907bf826af12c8512b1e76f8a and tell me what you think of the approach?
<babbageclunk> thumper: reviewing your PR now
<thumper> ok
<thumper> babbageclunk: where should I comment?
<babbageclunk> thumper: not sure. On the commit? Or here is fine.
<thumper> newStrategy as a member of logSinkHandler seems weird, dbStrategy ?
<thumper> is it always a db strategy?
<babbageclunk> Well, it's a func that makes a strategy (because the strategy is stateful).
<thumper> ugh....
<thumper> it is doing two things, and I think it should do one
<babbageclunk> thumper: it's always a db strategy, but it also has an opinion about the log file prefix.
<thumper> should be a dbStrategy and a fileStrategy
<thumper> I don't think the migration logs should be put into the same file as the logsink file
<babbageclunk> thumper: no, they wouldn't - I'd expect that we'd give it a different directory
<thumper> hmm...
<thumper> like what?
<babbageclunk> I guess it depends how we want the migrated logs to look after the migration is finished.
<babbageclunk> Should they be in the same places they would've been on the source controller machine?
<babbageclunk> Or is it ok to have them mashed in to one place? Basically I haven't thought about the file side of it.
<thumper> the logsink file is really just a backup of the logs that the controller has received
<thumper> not normally meant for user consumption
<babbageclunk> Right - so we mostly care about the DB logs then?
<thumper> much more, yes
<babbageclunk> ok
<thumper> I'm just thinking about how much we care about migration logs on the disk of the controller
<thumper> problem is that it won't get rolled
<thumper> unlikely to be too big, but you never know
<thumper> and how many we may have on any particular controller
<babbageclunk> True - it could be big, although it's not growing.
 * thumper nods
<babbageclunk> A different file prefix sounds alright to start with then.
<thumper> yeah
<babbageclunk> Also, these are model logs - I was thinking about controller logs, which have much more in them, right?
<thumper> true
<thumper> although I have been talking with menno about how to make the models have the apiserver logs for that model
<thumper> so, small for now
<mgz> thumper: yo, you wanted a repo bot-managed?
<thumper> it already is
<thumper> so no worries
<babbageclunk> thumper: oops, misunderstood what fileprefix was doing there - I thought it was a filename prefix, not a log line prefix
<babbageclunk> thumper: In that case maybe I move all of the logging into the strategy, as well as the version number parsing.
 * thumper nods
<babbageclunk> thumper: not at all attached to the name strategy, by the way, if you can think of something better - just picked something so I could try it.
<mgz> thumper: as in, someone did it yesterday, or we'd done it before and forgot?
<babbageclunk> thumper: reviewd
<babbageclunk> e
#juju-dev 2016-11-09
<redir> I assume we already have some tooling for storing time values as json on disk. Can someone point me at an example?
<babbageclunk> going for a run, hope it doesn't all go wrong while I'm out!
<voidspace> thumper: ping
<thumper> voidspace: hey
<voidspace> thumper: hey, hi
<voidspace> thumper: I'm working on bug 1632362
<mup> Bug #1632362: error during juju-wait ERROR cannot load cookies: file locked for too long; giving up: cannot acquire lock: resource temporarily unavailable <eda> <oil> <juju:Triaged by rharding> <Juju Wait Plugin:Invalid> <https://launchpad.net/bugs/1632362>
<voidspace> thumper: which *appears* to be a problem with the juju/persistent-cookiejar library around the way it does file locking
<voidspace> thumper: the suggestion in the bug is to switch to a many-readers-one-writer style lock
<thumper> ugh, otp right now
<voidspace> thumper: I'll email it
<thumper> ack
<voidspace> thumper: I hear you have "opinions" on file locking...
<voidspace> thumper: :-)
<thumper> :)
<voidspace> thumper: although it seems like really we want a database...
<voidspace> thumper: which may only be as complex as rewriting file locking from scratch
<voidspace> or less...
<voidspace> thumper: assuming that's the real bug...
<redir> OK. I'm calling it. Time to go watch the incoming results.
<voidspace> good luck America
<voidspace> I'm also calling it time
<voidspace> g'night all
<alexisb> thumper, ping
<thumper> alexisb: pong
<alexisb> heya do you have a second to chat?
<thumper> yep
<thumper> hangout or bluejeans?
<alexisb> k meet you in bluejeans
<thumper> ack
<alexisb> let me plug in my laptop
<mup> Bug # changed: 1543362, 1544158, 1565943, 1607786
<redir> someone shoot me
 * anastasiamac does not want to shoot redir
<rick_h> alexisb: ping, can you grab wallyworld for the session?
<anastasiamac> rick_h: where r u?
<rick_h> anastasiamac: in the bolero room for the cross cloud controller
<anastasiamac> rick_h: we r in opereta, talking with uros
<rick_h> anastasiamac: wallyworld is there as well? I've got some guests in here it'd be good to get backup here
<anastasiamac> rick_h: come over here - the same conversation is taking place
<anastasiamac> rick_h: yes, wallyworld is here
<rick_h> anastasiamac: k, the calendar says this room so we've got 5 folks in here to talk about it
<anastasiamac> rick_h: there is more here :D
<cmars> good morning juju-land. can I get a review of https://github.com/juju/charm/pull/225 and https://github.com/juju/juju/pull/6549 to fix https://bugs.launchpad.net/juju-core/+bug/1639855 ?
<mup> Bug #1639855: 2.0 metrics breaks 1.25 <juju-core:In Progress by cmars> <https://launchpad.net/bugs/1639855>
<redir> no seriously.
<redir> Shoot me.
 * redir goes to bed hoping not to have a 4 year hangover
<hoenir> could someone review these patches? https://github.com/juju/juju/pull/6523 https://github.com/juju/utils/pull/249
<voidspace> dooferlad: ping
<voidspace> rick_h: we doing 1:1 today?
<dooferlad> voidspace: how can I help?
<voidspace> rick_h: I'll be a bit late anyway, nothing *burning* that I need to talk about that can't be done by email
<voidspace> rick_h: so happy to skip, but also very happy to chat if you're around
<voidspace> dooferlad: hey
<voidspace> dooferlad: so I'm fixing the file locking to use juju/mutex instead of filelock
<voidspace> dooferlad: which uses named pipes (etc) to do the locking instead of the filesystem
<voidspace> dooferlad: but it has a 40 char max, and cookiejar uses full file paths which can exceed 40 chars
<voidspace> dooferlad: so I'm thinking that a hash of the full path is the thing to do
<voidspace> dooferlad: and am wondering which hashing algorithm to use - SHA1 looks promising in terms of a small output hash sized
<dooferlad> voidspace: can you give me a path to the file that has the problem?
<voidspace> dooferlad: but I thought you might have "opinions" that would be helpful
<dooferlad> voidspace: :-)
<voidspace> dooferlad: I'll have to dig to get that
<voidspace> dooferlad: and my wife just got back, let me come back to you on it
<dooferlad> voidspace: sounds good
<voidspace> rick_h: I just got the MAAS storage email
<voidspace> rick_h: I'm very close to a complete PR for the issue I'm on currently, so I'll complete that then switch to MAAS storage
<voidspace> rick_h: I've not looked at storage before, but there are plenty of people to ask if I need to (most of them on sprint with you though...) :-)
<rick_h> Voidspace thank you. Understand it's not an immediate turnaround.
<dooferlad> voidspace: on the subject of locking I would say that looking at the persistent-cookiejar code we could name a mutex 'juju-cookies' as long as we only have one location for the cookie file (next to the Juju settings) and that we need to import any existing cookies from the current location (JUJU_COOKIEFILE, GOCOOKIES or $HOME) if
<dooferlad> $HOME/.local/share/juju/cookies doesn't exist.
<rick_h> jam: ping
<voidspace> dooferlad: I think it's ok to use 29 character hash (of SHA256) : last ten chars of file path
<voidspace> dooferlad: and as we're the only user for juju cookies I don't think the cross-version incompatibility will be a problem
<dooferlad> voidspace: if we are the only users, why not just ask for a jar name on creation and use "juju/cookies/<name
<dooferlad> sorry, juju/cookies as that name
<dooferlad> when calling from our code
<voidspace> dooferlad: because the underlying library needs to generate locks for arbitrary paths
<dooferlad> voidspace: good point, well made :-)
<dooferlad> this feels a lot like we forked the cookie code instead of implementing a library to wrap file access inside a juju/mutex
<mup> Bug #1640521 opened: Unable to deploy Windows 2012 R2 on AWS <juju-core:New> <https://launchpad.net/bugs/1640521>
<mup> Bug #1640521 changed: Unable to deploy Windows 2012 R2 on AWS <juju-core:New> <https://launchpad.net/bugs/1640521>
<mup> Bug #1640521 opened: Unable to deploy Windows 2012 R2 on AWS <juju-core:New> <https://launchpad.net/bugs/1640521>
<lazyPower> rick_h - correct me if i'm wrong, but to bootstrap a controller with proxy settings we just drop http-proxy|https-proxy flags in a config.yaml and bootstrap with --config=myfile.yaml?
#juju-dev 2016-11-10
<redir> thumper: should arm64, s390x, etc skip on azure provider tests?
<thumper> NFI
<thumper> perhaps it would be prudent to flick axw a quick email and ask
<redir> OK.
<redir> thanks
<redir> is he at the sprint too?
<thumper> yep
<redir> bbiab
<redir> g'nite
<voidspace> off to hospital - back soon(ish)
<deanman> Is it possible to kill jujud inside a controller and rerunning it?
<hoenir> can someone take a look quickly on these ? https://github.com/juju/utils/pull/250 https://github.com/juju/juju/pull/6556
<hoenir> it's just a move from juju/cert to juju/utils and import path updates.
<hoenir> could someone tell me the exact procedure to move a core pkg to utils? There's something special to do? Or just update the dependencies.tsv and I'm done?
<mgz> hoenir: one step that I think is not well written down anywhere
<mgz> is probably just announcing it on the dev list
<mgz> there are a few projects that actually depend on juju/juju and may need to be updated
<perrito666> hoenir: announce it and then you have a shipit from me
<perrito666> oh, axw instead has comments
<perrito666> :p
<hoenir> perrito666, checking now
<hoenir> ping axw
<axw> hoenir: pong. in a meeting, but what's up?
<hoenir> axw, sorry for disturbing.
<hoenir> could you take another peek on https://github.com/juju/utils/pull/250 when you have time?
<axw> hoenir: sure
<axw> hoenir: just one little thing and then it's LGTM
<hoenir> axw, working now ! thanks !
<hoenir> axw, can I hit the $$merge$$ https://github.com/juju/utils/pull/250 ?
<axw> hoenir: yes, go ahead please
<axw> not sure if the bot will listen though, I think it has to come from a juju org member
<axw> we'll see...
<axw> oh you're already added as a member
<hoenir> axw, so satisfying to hit the $$merge$$ thing..
<hoenir> http://i3.kym-cdn.com/entries/icons/facebook/000/006/077/so_good.jpg
<axw> hoenir: :)
<rick_h> dooferlad: able to join back to the standup?
<dooferlad> rick_h: sorry, not today
<mup> Bug #1639170 changed: openstack trusty:liberty deployment fails due to no relations and insufficient peer units <juju-core:Invalid> <juju-quickstart:New> <https://launchpad.net/bugs/1639170>
<mup> Bug #1639494 changed: juju model-default no-proxy setting invalid for CIDR (172.16.0.0/16) <juju:New> <https://launchpad.net/bugs/1639494>
<mup> Bug #1640113 changed: In LXD machines localdomain not resolvable <juju:New> <https://launchpad.net/bugs/1640113>
<mup> Bug #1640079 opened: LXDs doesn't start after a reboot <juju-core:New> <juju (Ubuntu):Triaged> <https://launchpad.net/bugs/1640079>
<mup> Bug #1640079 changed: LXDs doesn't start after a reboot <juju-core:New> <juju (Ubuntu):Triaged> <https://launchpad.net/bugs/1640079>
<mup> Bug #1640079 opened: LXDs doesn't start after a reboot <juju-core:New> <juju (Ubuntu):Triaged> <https://launchpad.net/bugs/1640079>
<redir> soo quiet
<mgz> heyup redir :)
<redir> mgz \o
<redir> mgz: can you confirm https://github.com/juju/juju/pull/6557#issuecomment-259751567
<mgz> let me have a look
<mgz> redir: so, I agree with you on the selective arch skip maybe
<mgz> but there's no real different between the github merge runs and the full revision test runs apart from that arch and many more runs happen
<redir> mgz how about https://github.com/juju/juju/pull/6558 ?
<mgz> redir: that looks sane to me
<mgz> have you qaed it or do you need a pointer?
<redir> i'd ned a pointer to qa on a read arm64/ppc64/s390 arch
<mgz> okay, sinzui suggests the arm64 machine is the best option
<mgz> the details of how to get to it are in the cloud-city repo, see ssh config in jenkins-ssh... config thingy
<mgz> use the staging key from cloud city and either the vpn or bounce through with those ssh rules
<mgz> poke me if you need help
<mgz> you should be able to just ssh in as jenkins user, unpack source and run that unit test (to confirm it fails) then pull or apply your change
 * redir looks
<redir> phew
<redir> QA'd https://github.com/juju/juju/pull/6558 ready for review, PTAL.
<redir> Also should https://github.com/juju/juju/issues/6557 be reverted?
<mgz> redir: lgtm, and probably, yes, maybe poke anastasia first?
<redir> I'll send an email
<redir> How do fixes targeted at 2.0 branch make it back to staging?
<rick_h> redir: you submit a new PR against develop
<mgz> you need to cherrypick that change
<rick_h> redir: has to go through review/etc
<mgz> and propose again, I'll be happy to stamp
<rick_h> redir: the idea is trunk vs 2.0 will skew over time and it's not safe to just cherry-pick, needs to pass tests/etc over
<redir> So that means 2.0 is long lived
<redir> forever
<redir> ?
<rick_h> redir: yes, 2.0 is a release branch that lives on until we no longer support 2.0
<redir> k thanks. just making sure I understand
<redir> and support ends n time after 2.1
<alexisb> babbageclunk, ping
<babbageclunk> alexisb: pong
<alexisb> heya babbageclunk, happy friday to you
<alexisb> I wanted to check in on this bug: https://bugs.launchpad.net/juju/+bug/1640282
<mup> Bug #1640282: upgrade-juju: manual-provider no matching tools available <ci> <manual-provider> <regression> <upgrade-juju> <juju:Triaged by alexis-bruemmer> <juju 2.0:In Progress by 2-xtian> <https://launchpad.net/bugs/1640282>
<babbageclunk> alexisb: thanks!
<alexisb> balloons, confirmed today that he can recreate on latest 2.0.2
<veebers> sinzui: this is interesting ^^
<babbageclunk> alexisb: I've been failing to reproduce it on the jenkins host.
<alexisb> veebers, is tere some way we can get babbageclunk on the machine you guys use to test?  balloons did recreate today in front of me by re-running the test
<babbageclunk> alexisb: using the binary from the report. I'll try uploading the latest 2.0.2 version and rebuilding.
<alexisb> k
<veebers> alexisb: yes, sinzui and I are talking about this. we're just OTP but will be in touch shortly
<babbageclunk> alexisb: is balloons around? I'm probably doing something wrong, I'm just not clear what.
<alexisb> babbageclunk, probably not it is late here
<babbageclunk> alexisb: I tried pinging him this morning but I guess he's in the wrong timezone atm
<alexisb> yeah :) he had team dinner for QA today
<alexisb> all 2 of them
<babbageclunk> alexisb: sounds intimate
<alexisb> heh
<babbageclunk> Hmm - if I want the same version as he used, where should I get the latest 2.0.2. develop?
<babbageclunk> alexisb: or staging?
<alexisb> tip off teh 2.0 branch
<alexisb> not staging
<redir> 2.0 branch babbageclunk
<babbageclunk> alexisb: oh, duh - he said in the comment on the bug. Ok, thanks - building.
<babbageclunk> alexisb: oh, no, just reread his comment - the comment revision is the one that works.
<babbageclunk> alexisb: ok, using 2.0 branch
<voidspace> perrito666: you still around?
<voidspace> babbageclunk: you ever snapped juju?
<perrito666> voidspace: sadly, I am
<voidspace> perrito666: hah, me too...
<voidspace> perrito666: I hear a rumour you've snapped juju before
<perrito666> nah, I have snapped at juju
<perrito666> common mistake
<voidspace> perrito666: is the rumour true, is it easy, have you automated it? (providing a devel version for someone to try)
<voidspace> hah
<perrito666> voidspace: but honestly I have not but if what you want is to craft a juju snap should be easy
<voidspace> voidspace: I'm off tomorrow and I need to provide a binary to a couple of users
<voidspace> oops
<voidspace> perrito666: ^^
<perrito666> voidspace: coopy the snapcraft.yaml file to a folder
<perrito666> then run snapcraft on it
<perrito666> that will produce a snap of juju for your arch for master I guess
<voidspace> "the" snapcraft.yaml...
<voidspace> ah, there *is* a snapcraft of master
<voidspace> I mean, snapcraft.yaml...
<perrito666> voidspace: yes, snapcraft.yaml in our root folder of the repo
<perrito666> voidspace: sadly that might give you master
<perrito666> which is not what you want
<voidspace> perrito666: that uses master from the repo -  I want to use a custom local binary
<voidspace> perrito666: yeah, I'll work it out on Monday
<voidspace> perrito666: I'll just zip up juju/jujud for today
<perrito666> voidspace: there is a yaml attribute
<perrito666> that will allow you to specify the checkout
<perrito666> and then that will work
<voidspace> right
<voidspace> still, a task for Monday I think
<voidspace> sounds easy enough
<voidspace> but I want to get ready for bed :-)
<voidspace> No command 'mkdur' found
<voidspace> definitely too late to be working...
<perrito666> voidspace: just ship the binary and go to sleep
<voidspace> perrito666: hey, see you soon
<perrito666> voidspace: sleep tight
<voidspace> g'night
<babbageclunk> voidspace: make sure to change the version, otherwise it could still match the one in the streams.
<voidspace> babbageclunk: it's off staging
<voidspace> babbageclunk: is the version number still the latest release
<voidspace> babbageclunk: hmm... it could be
<voidspace> goddammit
<voidspace> what if I use develop?
<babbageclunk> voidspace: not sure - best to check, otherwise you'll have a couple of roundtrips sorting it out.
<babbageclunk> voidspace: just bump it locally before building and zipping your binaries.
<voidspace> babbageclunk: building develop just to see
<voidspace> develop should *always* have a bumped number, it should be part of the release process
<babbageclunk> voidspace: develop should work though.
<voidspace> about to find out
<voidspace> babbageclunk: morning
<voidspace> babbageclunk: you read my article yet?
<babbageclunk> voidspace: evening!
<voidspace> babbageclunk: yep, develop is good
<babbageclunk> voidspace: I read the novel in ntoll's comments, haven't had a chance to comment yet
<voidspace> babbageclunk: I turned it into an article, doesn't look so big then
<voidspace> babbageclunk: interested in your comments
<babbageclunk> voidspace: pretty fun - sounds like you're drifting towards excommunication though
<voidspace> babbageclunk: it's only mental agility, but I like it
<voidspace> babbageclunk: hah, I've been headed that way for years
<voidspace> babbageclunk: the trouble is, they actually like me, so they're not keen to excommunicate me
<babbageclunk> nice
<voidspace> babbageclunk: they aren't keen to make me an official "leader" either (which is not even really a big deal) - I unofficially am, so they tolerate me in the leaders meetings, but won't make it official
<voidspace> babbageclunk: truth be told, they're mostly a bit scared of me
<babbageclunk> voidspace: aren't we all!
<voidspace> babbageclunk: are you? ;-)
<voidspace> I think that's fairly reasonable if you are...
<voidspace> did you see the zombie day photos?
<babbageclunk> alexisb: still no luck. My understanding of the test is that it bootstraps with the old juju binary it finds on the path, so really the version of the binary I'm running it with is irrelevant - it's the one that's on the path interacting with the stream. Do you know what versions he had on the path and which stream he ran it with?
<babbageclunk> voidspace: only a bit, now that I'm on the other side of the world.
<redir> mgz: if you're still about: https://github.com/juju/juju/pull/6560
<babbageclunk> voidspace: yeah, looked good!
<voidspace> babbageclunk: such fun!
<voidspace> babbageclunk: moments of panic and terror
<voidspace> very well done
<voidspace> right, comments left and binary uploaded
<voidspace> g'night all
<voidspace> o/
<babbageclunk> voidspace: \o
<redir> voidspace: what article?
<redir> or g'nite
<voidspace> redir: :-)
<voidspace> redir: http://www.michaelfoord.co.uk/2016/11/an-evolutionary-spirituality-goodness.html
<voidspace> redir: reaching for synthethis of science, religion, psychology and philosophy
<voidspace> redir: utterly un-work-related and merely my fetid musings
<redir> ah ha, was looking at voidspace.uk...
<mgz> redir: lgtm
<redir> mgz: tx
<voidspace> redir: I haven't done anything there for a very long time
<voidspace> redir: I probably won't - as I'm not doing Python if I start a new blog I'll put it somewhere else
<voidspace> redir: anything technical I do post, which is rare at the moment (shouldn't be) I tend to put on google+
<voidspace> redir: although I'm moderately active on twitter too
<redir> voidspace: I noticed
<redir> I don't do much twitter.
<voidspace> I enjoy twitter and facebook, I keep in touch with a lot of friends through them
<voidspace> although some of my friends are too posh for facebook it seems
<voidspace> *coff* katco *coff*
<katco> lol
<voidspace> :-)
<katco> not posh, just feel it's a waste of time, and an energy drain, and an invasion of privacy
<voidspace> I enjoy it :-)
<voidspace> anyway
<katco> at some point i got very tired of reading crappy political memes
<voidspace> ah yeah, it's the psyche of humanity on full display
<katco> at least my peers are on twitter
<voidspace> full of crap and beauty in about equal measure
<voidspace> staunch filters
<redir> I don't do much facebook either
<voidspace> I'm really off
<voidspace> g'night all
<voidspace> o/
<katco> tc voidspace
<voidspace> see you again on monday
<redir> \o
<perrito666> facebook, in my case, has the exact same contents hotmail had in the early 2000s when my mom got hold of mail
<redir> perrito666: heh
<perrito666> basically fake articles, inspirational power point like presentations, etc
<perrito666> a bit low on cats though, which is odd
<katco> lol
<katco> i actually am on facebook. i've just enacted a big-data deep-ai filter to give me the truly important news. she is my wife
<perrito666> katco: lol
<redir> awesome. I think I might be that filter for M.
<perrito666> katco: I usually get the truly important stuff from facebook, basically when my internet is down and I get the blank page
<perrito666> I do laugh at people from high school treating everyone as sheeple while quoting articles from media of the journalistic quality of the onion
<redir> Whelp, I guess I need to start getting on twitter to find out what our president elect thought about during midnight toilet runs.
#juju-dev 2016-11-11
<veebers> babbageclunk: the help summary for show-model states "Shows information about the current or specified model." yet there is no way to specify a model (i.e. no -m) is the summary wrong or is it wrong that it doesn't take -m
<veebers> ?
<babbageclunk> veebers: It takes model as a positional argument.
<veebers> babbageclunk: d'oh, reading fail for me. Thanks :-)
<babbageclunk> veebers: :)
<hoenir> can someone take a look at this ? https://github.com/juju/juju/pull/6556
<mup> Bug #1640079 changed: LXDs doesn't start after a reboot <lxd-provider> <openstack> <uosci> <juju:Triaged> <juju (Ubuntu):Triaged> <https://launchpad.net/bugs/1640079>
<mgz> no one for standup?
<macgreagoir> mgz: I can rejoin. I was there alone :-)
<natefinch> we just did a super short one
<mgz> macgreagoir: nate and I just did a lightning standup
<mgz> feel free to fill us in here
<macgreagoir> ipv6 blah blah blah
<macgreagoir> Just trying to see if the enable-ha issue I'm hitting is ipv6 relatd or something else.
<natefinch> macgreagoir: I wouldn't be surprised.
<natefinch> macgreagoir: what version of mongo?
<macgreagoir> 3.2
<macgreagoir> .9
<natefinch> hmmm... ok, if it had been 2.6 I'd almost assuredly think it was ipv6, but 3.2 is supposed to work
<natefinch> but definitely could be a juju specific bug
<macgreagoir> ipv6 seems good in 3.2. Seems to be an id clash somewhere in the momngo docs.
<hoenir> could someone take a look on this PR https://github.com/juju/juju/pull/6556 ? and also could someone tell me that the CI logs are ok on the last commit ?
<hoenir> what are your thoughts on this?
<hoenir> someone?
<mgz> hoenir: sorry, have been deep in several things today
<mgz> hoenir: the checks passed, is there something in particular you want to see in the logs?
<hoenir> mgz, I'm referring on that "bad certificates" warnings..
<mgz> there are some "remote error: bad certificate" lines on stdout for the trusty unit tests
<mgz> not actually causing any tests to fail
<hoenir> so it's safe to merge
<mgz> I don't know, what's the background?
<hoenir> The background is that, on a previous PR axw suggested, in order to make these changes possible I should move the juju/cert (all the generic-common pieces) into a utils/cert pkg , the utils/cert part is already merged.
<hoenir> this patch is already merged so.. I wanted to finish the job by merging the other patch in (juju-core).
<hoenir> https://github.com/juju/utils/pull/250
<hoenir> so mgz it's safe to $$merge$$ this bad boy?
<mgz> as it's a us holiday and end of sprint, I think the people who were looking at your code just weren't around today
<mgz> hoenir: the check says yes, and perrito666 approved
<mgz> might be nice to send a message to the dev list about the cert error spam, so people are aware, and can follow up to fix?
#juju-dev 2016-11-12
<rock_> Hi all. I need to know the answer for one question. This is very important for us. To push a juju charm we required Ubuntu SSO account right. I have Ubuntu SSO account.
<rock_> How can I remove/delete created Ubuntu SSO account permanently even account username should not be stored anywhere ?
<rock_> Once I delete the Ubuntu SSO account permanently, I will reuse that permanently deleted account username again to create a new account.
<redir> rock_: https://help.ubuntu.com/community/SSO/FAQs/Delete_SSO_Account
 * redir eods
<redir> eows even
<rock_> redir: Thanks . But we have the following issue. https://github.com/CanonicalLtd/jujucharms.com/issues/372. could you please help me in resolving the mentioned issue.
<rock_> redir: Hi. Actually,  before deactivating the launchpad account I deleted Ubuntu SSO account permanently. Due to that account username stored in ubuntu server cache.  Then I created another account using the deleted account mail id and another user name.. Now how can I delete that stored username.?
#juju-dev 2016-11-13
<redir> rock_: I'm afraid I'm beyond my charmstore knowledge there. Does anyone know who we can escalate to? The issue mentioned by rock is a week old. It is in GH. pperhaps it needs to be in LP. Anyone?
<mup> Bug #1557726 opened: Restore fails on some openstacks like prodstack <backup-restore> <jujuqa> <openstack-provider> <juju:Fix Committed by hduran-8> <juju 2.0:Fix Released by reedobrien> <juju-core:Triaged> <https://launchpad.net/bugs/1557726>
<rock_> redir: Thanks
<mup> Bug #1512569 opened: UniterSuite.TestRebootNowKillsHook fails with: uniter still alive <ci> <test-failure> <unit-tests> <juju:Triaged> <juju-core:Triaged> <https://launchpad.net/bugs/1512569>
<mup> Bug #1512569 changed: UniterSuite.TestRebootNowKillsHook fails with: uniter still alive <ci> <test-failure> <unit-tests> <juju:Triaged> <juju-core:Triaged> <https://launchpad.net/bugs/1512569>
<mup> Bug #1512569 opened: UniterSuite.TestRebootNowKillsHook fails with: uniter still alive <ci> <test-failure> <unit-tests> <juju:Triaged> <juju-core:Triaged> <https://launchpad.net/bugs/1512569>
<redir> hope everyone is doing ok over in kiwiland
<mup> Bug #1638560 changed: 1.25 broken on MacOS sierra <osx> <juju-core:Fix Released by sinzui> <https://launchpad.net/bugs/1638560>
<mup> Bug #1639855 changed: 2.0 metrics breaks 1.25 <uosci> <juju-core:Fix Released by cmars> <https://launchpad.net/bugs/1639855>
<babbageclunk> morning everyone! o/
<babbageclunk> veebers: sounds like it wasn't too bad down there?
<babbageclunk> mwhudson: must have been pretty scary in Welly?
<veebers> babbageclunk: I don't think it was too bad. I may have have felt some swaying but that might have been me 1/2 asleep.
<veebers> babbageclunk: and you? (I thought you were in Welly? Or are you in Palmerston North?)
<babbageclunk> veebers: We picked a great time to go visit my parents in Banks Peninsula! I'm working from theirs for a few days.
<babbageclunk> veebers: We're staying with my inlaws in Palmy mostly, then moving to Welly when our stuff arrives in mid-Jan.
<veebers> babbageclunk: nicely timed!
<babbageclunk> veebers: I guess for consistency with with Palmy and Welly, we're in Banksy now.
<veebers> babbageclunk: ^_^
<veebers> babbageclunk: I've never been to "Banksy" before, hopefully the weather is good for you while you're there
<babbageclunk> veebers: it was rubbish in the weekend, but it's pretty nice now. Just my luck!
<veebers> lucky, we have overcast and rain forecast for the week :-\
<babbageclunk> veebers: At least I'll have a good view of the tsunami if it comes: https://goo.gl/photos/AntK5C6gSWHMgefc8
<veebers> babbageclunk: dude, that's beautiful! How many spare rooms do your parents have? Might have to pop up ;-)
<babbageclunk> veebers: you can crash on the couch! :)
<veebers> ^_^
<mwhudson> babbageclunk: yeah, that was the most shaking i've had here
<mwhudson> (or anywhere, come to that)
<mwhudson> happy to be above the blue lines and so didn't have to evacuate
<perrito666> Well I have a couple of spare rooms and I live in the exact opposite of the world and in the most inland place of my country
<veebers> perrito666: heh, the "opposite part of the world" part makes it a little hard to just pop over for a visit :-)
<babbageclunk> ok those aftershocks are doing my head in
<veebers> babbageclunk: stay safe!
<perrito666> Babbageclunk feet on the floor if that is not enough sit on the floor usually resets your inner accel well
<perrito666> Or get wasted and then you can't be sure if it's shaking or you (true story)
<babbageclunk> veebers, perrito666 - thanks guys - I think part of the problem is that my parents' house is on poles. That's actually safer, but it can make the wobbles more noticeable.
<veebers> babbageclunk: hah, that's scary!
<veebers> babbageclunk, mwhudson: Have you heard from Menno at all? I presume he's travelling back or so?
<babbageclunk> veebers: yeah, on twitter he said he was in the air when the earthquake happened.
<anastasiamac> babbageclunk: and how r u and ur family? I assume u were not in the air?...\o/
<babbageclunk> anastasiamac: we're all good thanks! Ada didn't even wake up when I grabbed her out of bed and stood in the doorway.
<anastasiamac> babbageclunk: i can't even imagine how scary it'd b \o/
<anastasiamac> babbageclunk: at least there is no tsunami? is there more excitement on its way to u guys?
<veebers> babbageclunk: ah cool thanks :-)
<babbageclunk> anastasiamac: no, doesn't look like there's going to be a tsunami where I am, although they've asked people to stay away from the beach.
<veebers> babbageclunk: of course they would say that, they want the beach all to themselves (/s)
<anastasiamac> :)
<babbageclunk> veebers: :)
<anastasiamac> babbageclunk: and where abut's r u these days?
<babbageclunk> anastasiamac: At the moment we're on Banks Peninsula visiting my parents - just outside Christchurch. It's the sticky-out bit on the South Island.
<anastasiamac> niiice \o/
#juju-dev 2017-11-06
<jam> axw: ping
<axw> jam: bit late, but pong (was on holidays and past normal EOD anyway, double whammy)
#juju-dev 2017-11-07
<thumper> axw: I have another leadership wonder for you
<thumper> axw: forwarding email now
<axw> thumper: okey dokey
<jam> axw: yeah, I realized that late. Uros was commenting on something for you, so I wanted to reach out to not forget, but of course now I've forgotten.
<axw> jam: hah :)
<jam> axw: welcome back, hope you had a good time
<axw> jam: thanks. yeah, it was a nice little family holiday. good to unplug too.
#juju-dev 2017-11-08
<axw> thumper: I added https://bugs.launchpad.net/juju/+bug/1730809 to 2.3-rc1, feel free to move off if you think it should wait. seems like a good time to add support, and should be quick
<mup> Bug #1730809: ec2: add support for C5 instance types <ec2-provider> <juju:Triaged> <https://launchpad.net/bugs/1730809>
<wallyworld> +1 from me
<axw> hmm maybe not entirely straight forward though, since with C5, EBS volumes are exposed as NVME devices
<axw> so probably need some changes to support storage
<axw> I'll bump to 2.4 for that reason, we can bring it back if there's time
<thumper> axw: sounds reasonable
<thumper> axw: although to be honest, we won't have time
<thumper> too many other things
<axw> thumper: ok
<axw> a boy can dream
<thumper> wallyworld, axw, jam: with you shortly
<wallyworld> ok
<axw> wallyworld: are you able to add juju/mutex to the github powerup on trello?
<axw> wallyworld: says it can't find it when I try
<wallyworld> ok, looking
<wallyworld> axw: done
<axw> wallyworld: thanks
<axw> jam: you have a mac, right? would you be able to run the tests for https://github.com/juju/mutex/pull/4 on it?
<jam> yes
<axw> jam: thanks, no rush - when you have some time
<jam> axw: where did you push the branch to?
<jam> I'm missing something in the github UX to make sure I'm grabing your exact branch
<jam> I see axw:mutex-blocking but what *repo* is that?
<axw> jam: http://github.com/axw/juju-mutex
<jam> axw: thx. Am I just dense or does Github not give you a link back to the branch that is being proposed?
<jam> I can browse the revision, but it does so in the juju/mutex contex
<jam> not in the axw/juju-mutex one
<jam> axw: http://paste.ubuntu.com/25915717/
<jam> doesn't seem particularly interesting, is there any manual steps you'd want me to try?
<jam> ah, I see the fairness program
<jam> axw: fairness confirmed
<jam> axw: want me to test on Windows as well?
<jam> axw: test fails on Windows
<jam> axw: and the fairness check breaks, too
<jam> axw: I updated the PR with some Windows results. HereBeABug
<axw> jam: thanks, will try to repro here. I was running under Wine before, maybe something's a bit off - or could just be timing
<jam> axw: seems reproducible here, if you need me to, I could try investigating, but I'm happy to do other things too :)
<axw> jam: I can reproduce the fairness failure with Wine
<axw> so I'll take it from here, thanks
<axw> I've got a Windows laptop too, it's just a bit slower going back and forth
<jam> axw: yeah, I can guess that maybe flock et al depend on kernel things, and so wine's emulation isn't exact
<jam> axw: thoughts on me landing the mgo patches? Care to have a quick HO cause I want to talk through an edge case
<axw> jam: sure
<jam> axw: https://hangouts.google.com/hangouts/_/canonical.com/morning-jam?authuser=1
<jam> axw: so... small hiccup.
<jam> abort-or-reload wants the list of revnos for the docs in the txn op
<jam> not sure what its doing with it yet
<jam> but you don't really get that revno until you hit prepared (I think)
<axw> jam: instead of $addToSet and then $pullAll, I *think* you could use $slice with $addToSet and then you'll have the revno as well as the current queue
<axw> jam: you do have the revno in txnInfo struct
<axw> or is that not what you need?
<jam> axw: that's not what I need. Txn docs include the revno of all the related documents in the txns.Ops slice
<jam> its accumulated when you go from preparing => prepared
<jam> but if we fail to go to prepared half-way
<jam> then we don't have the revno for all of the docs we didn't get to
<axw> I see
<jam> i'm tracking through to see if it matters
<axw> balloons: I'm looking at https://bugs.launchpad.net/juju/+bug/1701142, and noticed that deploy-trusty-amd64-vsphere is gone. is that because vsphere was busted? is it coming back?
<mup> Bug #1701142: juju destroy-controller failed on vSphere. <ci> <controller> <destroy> <juju> <jujuqa> <vmware> <vsphere> <juju:In Progress by axwalk> <https://launchpad.net/bugs/1701142>
<axw> balloons: we have "add-cloud-vsphere", maybe that's its replacement?
<axw> balloons: did you change the password for aron? I can't log in anymore
<axw> welp, braixen is buggered again
<balloons> axw, :(
<balloons> I didn't change anything
<axw> balloons: okey dokey. I'm not sure what to do now. do we have access to the MAAS that's running aron?
<balloons> We don't AFAIK. I was surprised you could ssh in
<axw> balloons: I was ssh'ing to aron, not the MAAS. isn't aron ours?
<balloons> I was hoping IS would help out in helping us how the two machines are setup / ensuring access
<balloons> It predates me, and I had to cobble together some info to figure out it existed and how to access.
<balloons> I can go look at the original rt and see if there are more clues
<axw> balloons: there's https://wiki.canonical.com/InformationInfrastructure/IS/JujuVMware
<balloons> But yes, both braixen and Aron are ours
<axw> balloons: do you know what TUP means?
<balloons> Nice axw. I never knew about that page
<balloons> No, not sure about TUP. Just enigma for secrets
<balloons> Let's just ask is
<axw> balloons: ah, derp, the password is the same. my script was munging the password
<balloons> axw, please send along what you do if successful so we have it for our notes
<axw> balloons: sure
<axw> balloons: sent an email. I just deleted the juju VMs and it seems happy now :/
<balloons> axw, on the deploy we removed it as redundant. network-health-vsphere is the replacement
<axw> jam: tyvm for the review, will look to add more tests for compat tomorrow, then land
<axw> balloons: ok
<balloons> axw, right need to add a cleanup script to that substrate now
<axw> balloons: I failed to include the command, I just did "govc vm.destroy juju-*"
<balloons> axw, perhaps something you could easily whip up?
<axw> balloons: that leaves some VM folders behind, but there doesn't appear to be any govc command to delete them
<axw> balloons: maybe? depends on what else I have going on tomorrow, need to finish some other stuff off too
<balloons> Basically we would want to remove instances older than a couple hours is generally how we do it. And run that on cron every hour
<axw> and also get to the bottom of why this happened
<axw> don't want to be hosing customer systems, if it is juju that's at fault
<balloons> axw, right. Just asking ;) it's a task on the list, but vsphere needs to be working first
<balloons> I'm just glad you have a working playground now.
<axw> balloons: yup, I'll add a card and add myself to it. I can advise if somebody gets to it first
<balloons> There is a card in the quality section, you can put your face on
<axw> balloons: no QA board yet?
<axw> oh I don't see it - maybe I don't have access
<balloons> No, I'll do it today. Haven't moved from leankit yet
<balloons> Card is still in there
<axw> right I see
<balloons> Didn't finish migration
<axw> I'll look tomorrow then, I'm going to sign off shortly
<balloons> Anyways, thank you
<axw> balloons: nps
<balloons> You have a lovely evening
<bdx> axw: sup
<bdx> ahh I see you are signing off
<bdx> no worries
<bdx> hitting some crazy issues with storage
<bdx> ill file a bug
<jam> hml: I responded to your email
<jam> let me know if I can help clarify things
<hml> jam: ty - iâm taking a look
<hml> jam: one thing to note - right now DeriveAvailabilityZones only looks at the StartInstanceParams.Placement and the volume availability zones, spaces/constraints are handled in StartInstance().  Itâs be easy enough to move spaces to DeriveAvailabilityZones however
#juju-dev 2017-11-09
<axw> thumper: can you please add me as a committer to github.com/juju/mutex and/or merge my PR?
<thumper> axw: ack
<thumper> axw: we should get the bot lined up for it
<thumper> axw: merged your PR while we get it sorted
<axw> thumper: thanks
<thumper> veebers: care to add a card to your board?
<veebers> thumper: sure, what card is that?
<thumper> veebers: getting juju/mutex under auto landing
<veebers> thumper: do you not have access to add cards to the backlog?
<axw> wallyworld: trivial review? https://github.com/juju/juju/pull/8039
<wallyworld> sure
<wallyworld> lgtm
<axw> gracias
<wallyworld> axw: this is largely mechanical, but touches several files. if you get a chance, but no rush https://github.com/juju/juju/pull/8043
<axw> wallyworld: gotta take charlotte to ballet soon, will try to take a look afterwards
<wallyworld> axw: no worries, i'm in rush
<wallyworld> *no
#juju-dev 2017-11-10
<wallyworld> axw: looking at 1.25 PR. interesting that in 2.x, we have leaseClientId as an attribute on State and hence set that as part of State.start() instead of during lease worker startup as your 1.25 change does
<axw> wallyworld: yeah probably should do it in 1.25 too, since it should be a terminal error. just made things a little simpler this way
<wallyworld> axw: yeah, it may be what's proposed is good enough. i guess if we can't get the clientId stuff will still break, but in a different way
<wallyworld> anastasiamac: hml: axw: forgot to remind - if there's anything you want to add to release notes for beta3, now is the time
<hml> wallyworld: nothing coming to mind
<wallyworld> yeah, mostly bug fixes this time
<wallyworld> i added a few key things
<anastasiamac> wallyworld: m all good but will confirm with the rest of the squad later on in the day
<wallyworld> ty, may be too late then :-)
<axw> nah I don't think so
<anastasiamac> really? 4pm our time?..
<axw> only thing was the mutex fix, and that's out :~(
<anastasiamac> wallyworld: most bug fixes anyway :)
<wallyworld> indeed
<wallyworld> anastasiamac: yeah veebers is on fire, i expect it wil be done by 4pm our time as that will be well into his evening and he will already be on the beer :-)
<anastasiamac> wallyworld: :D
<veebers> wallyworld: hah more like cleaning up spit-up and baby wees off my hands, but hopefully there will be a beer there sometime ^_^
<wallyworld> the joys of parenthood
<wallyworld> you'll be doing the same thing to yuorself when you hit 80
<veebers> hah ^_^
<veebers> s/when/if/ /me dies of parenthood related stress
<axw> wallyworld: https://github.com/juju/mutex/pull/5
<axw> currently running the network-health test with the old code to repro locally, then will run with this to make sure it's the problem
<axw> it's definitely *a* problem though
<wallyworld> axw: looking. good we have CI
<axw> indeed
<wallyworld> axw: lgtm, just a comment typo
<axw> wallyworld: heh thanks
<axw> wallyworld: do you have rights to merge https://github.com/juju/mutex/pull/5 ?
<wallyworld> yup, i think so
<wallyworld> axw: added you with perms to merge
<wallyworld> try it?
<axw> wallyworld: thanks
<hml> wallyworld: changes we discussed have been made, pr updated
<thumper> axw: what was happening with the mutex?
<thumper> axw: was it inheriting the lock, and only one closed it, so it was still "held" or something?
<axw> thumper: subprocess inherited the file descriptor, so flock was held by subprocess even though juju closed its FD
<thumper> but that sub process would have finished as well, releasing it, right?
<axw> thumper: yeah, unless it spawned off something like "timeout"
<thumper> axw: is that what the tests were doing?
<thumper> so that explains why some hooks were fine and others not yes?
<axw> thumper: the network-health test starts a server from one of the hooks, and never stops it AFAICT
<axw> thumper: yeah, depends on the hook implementation for sure
<thumper> ah..
<thumper> ok, I like to know why things fail :)
<wallyworld> axw: the state we attach to the apiRoot object - the one facades get via ctx.GetState() - i can't see where that gets closed. do you know?
<axw> wallyworld: looking, have to remind myself
<wallyworld> i also can't see where we Stop() resources
<axw> wallyworld: it's the same State that's attached to the Server
<wallyworld> and we stop that one? let me look
<axw> wallyworld: which is closed by the agent
<wallyworld> ok, ta
<wallyworld> axw: trying to decide whether to add a "controller" Resource
<wallyworld> rather that yet another attribute on server
<wallyworld> as resources i think is the preferred way to add stuff to the facade context
<axw> wallyworld: I'd prefer it was part of the Server
<wallyworld> there's a snaky comment from willian next to ctx.State() that it should be a resource
<wallyworld> any reason for preferring to add to Server?
<axw> wallyworld: I don't know what that would buy us
<axw> wallyworld: because State and StatePool are there. and because it's not a per-connectio nresource
<wallyworld> keeps facade Context interface stable
<axw> it's owned by the Server, not by the connection
<axw> and eventually it shouldn't even be owned by the Server, but passed in and owned by a manifold
<wallyworld> hmmm, ok, let me think on it
<axw> wallyworld: perhaps we should start a new branch for this work? I have some things I'd like to land too, but have been holding off until after 2.3
<wallyworld> a feature branch? yeah maybe
<axw> wallyworld: though possibly my work will make fixing https://bugs.launchpad.net/juju/+bug/1642618 easier anyway
<mup> Bug #1642618: enable-ha using existing machines breaks agents <enable-ha> <juju:In Progress by axwalk> <https://launchpad.net/bugs/1642618>
<wallyworld> i think we can do a few things on develop
<wallyworld> a lot of this stuff is shifting furnature around
<axw> wallyworld: sometimes the furniture is accidentally load bearing though :)
<wallyworld> that is true
<wallyworld> i'll do this work and see how it looks
<wallyworld> can propose against a fb if it looks too messy
<wallyworld> axw: sorry, another question. do you know why we pass in a State to startStateWorkers() but then provide a separate openState() method to the apiserverWorkerStarter? we barely use the result from openState(). but noentheless, why not just use the one we already have, especially when that one we alrready have comes from the manifold
<wallyworld> openState() as it turns out provides a State used to get ControllerConfig(), which we could just pass in from the original st, and create an audit log sink, which we also could get from a manifold.
<axw> wallyworld: I thought there was a comment, but can't find it now. it's because the apiserver kills the state workers
<axw> wallyworld: so if hte apiserver restarts, it needs a new State
<axw> sas the old's watchers, lease manager, etc. will have been stopped
<axw> *as
<axw> wallyworld: this is one of the things I have fixes for in the pipeline
<axw> wallyworld: if it makes it easier for you to do what you want to do, I can look to land my work sooner rather than later
<wallyworld> yeah, that would be good. i want to thread through a controller
<wallyworld> but need a state
<axw> wallyworld: I have a branch that will move the apiserver to a manifold, too, but needs a bit more work
<axw> wallyworld: probably better to get that in, then you can use the controller manifold?
<wallyworld> would be good to get that stuff landed
<wallyworld> yes
<wallyworld> maybe a fb then?
<wallyworld> it's all very messy atm
<wallyworld> would be good to get this cleaned up
<axw> wallyworld: I think that'd be prudent. then fold it into develop as soon as we branch
<wallyworld> yup
<axw> wallyworld: first step is to land https://github.com/juju/juju/pull/8038 in a feature branch then
<wallyworld> ok, and it's been approved
<axw> wallyworld: want to review for me? it has rog's +1, would be good to get a second opinion tho, as it's core
<wallyworld> ok
<wallyworld> i'll create the fb
<wallyworld> as well
<wallyworld> axw: https://github.com/juju/juju/tree/state-controller-refactor
<wallyworld> looking at PR now
<axw> wallyworld: thanks
<axw> wallyworld: note there's two commits, might be easier to review them independently
<axw> one after the other, rather
<wallyworld> ok
<wallyworld> axw: i had a look earlier - we disucssed a bit already this week, i'll re-review
<axw> wallyworld: we did? I don't remember htat at all :o
 * axw is losing the plot
<wallyworld> i was asking about exposing context to api leayer, and clarifying operation on apiserver sid eetc
 * wallyworld has already lost the plot
<axw> sounds vaguely familiar :p
<wallyworld> axw: +1 to go into fb. i'd like to ensure we get some good CI runs (which we will) and do some more extensive manual testing with all the other changes we will be landing soon
<axw> wallyworld: ok. I think I broke something in the API package with a change I made about an hour ago, will fix that and land
<wallyworld> sgtm
<wallyworld> axw: and then you had a followup bit of work to go on top of this?
<wallyworld> i'll look to pick up my stuff next week perhaps
<axw> wallyworld: yes, to move apiserver to the dependency engine
<wallyworld> great, ok
<axw> then there'll be more followups on top of that I'm sure
<wallyworld> yep
<axw> wallyworld: e.g. once we move to using a single StatePool, the introspection code can be cleaned up a bit
<axw> it's really awkward atm, the apiserver starter needs to create a new StatePool, then set that on the agent so the introspection worker can reference it
<wpk> wpk@minnie:~/dev/src/gopkg.in/juju/names.v2$ grep -r IsValidRelation *
<wpk> wpk@minnie:~/dev/src/gopkg.in/juju/names.v2$ grep -r IsValidRelation relation_test.go
<wpk> 			c.Assert(names.IsValidRelation(key), gc.Equals, isValid)
<wpk> magic
<wpk> 			c.Assert(names.IsValidRelation(peerKey), gc.Equals, isValid)
