#juju-dev 2012-12-10
<wallyworld> jam: 1 on 1?
<jam> wallyworld: sure, guess I missed my alarm
<jam> wallyworld: I just lost mumble connection, will try again
<wallyworld> ok
<jam> wallyworld: it seems dead from my view... Are you still on mumble.canonical.com?
<wallyworld> yes, i'll retry also
<TheMue> Morning
<jam> wallyworld: it is possible the great firewall of the UAE has been updated to block mumble :).
<jam> TheMue: hi
<jam> clearly I still have some internet access.
<wallyworld> jam: when i restart, it says host unreachble for me too
<jam> k
<jam> maybe just a dns issue?
<wallyworld> so maybe mumble is down
<jam> (migrating to a new host, and DNS updates being done.)
<TheMue> jam: Hi, and yes, seems so.
<jam> I got remote host closed it, connected now, but invalid password.
<jam> maybe they are just restarting it or something
<wallyworld> works now
<davecheney> morning/evening
<TheMue> davecheney: Hiya
<jam> and mumble dies again...
 * davecheney sad trombone
<jam> TheMue: How's stuff going? I saw that you're working on the firewalling code. Mark mentioned that you'll be starting to look into the MaaS code soon. Do you know when that might be?
<jam> I think I also saw that you're going on vacation next week?
<jam> davecheney: http://www.sadtrombone.com/
<jam> sorry: http://www.sadtrombone.com/?play=true
<jam> the latter will autopaly
<jam> play
 * davecheney bookmarks
<jam> davecheney: though I wonder if you need a bit.ly link to it, so you can surprise people.
<TheMue> jam: Yes, right now I'm fixing/fixed the firewaller.
<davecheney> jam lmgtfy
<TheMue> jam: I already took a first look into MAAS, but now I have to coordinate with Aram who started with it too.
<Aram> good morning.
<davecheney> morning
<TheMue> Aram: Hiya
 * Aram installed Debian because Unity doesn't work with NX.
<Aram> I forgot computers could be this fast.
<davecheney> debian is quite lean
 * davecheney has been playing with plan9 on a Pi
<Aram> I'm still waiting for my Pis. I somehow managed to order Pis in Australia, no wonder no Pi came.
<Aram> perhaps I donated some Pis to someone this way.
<davecheney> Aram: another canonical guy sold me his 512mb pi
<davecheney> do you want my old 256mb one ?
<davecheney> apart from running acme on your telly, it isn't all that useful
<Aram> nah, thanks, I think I'll get one in a week or so.
<davecheney> understood
<Aram> yeah, I suppose/.
 * davecheney is still waiting on the TTL 3.3v usb adapter
 * TheMue is playing with Smalltalk again and always wonders about the Power of such a small environment like Pharo. Funny how ST has been too large for most computers in its early days. 
<davecheney> Aram: over the weekend some significant improvements were made on compiler memory usage
<davecheney> there are CL's in review that effectively halve the amount of memory the compiler uses
<Aram> fantastic.
<davecheney> yup, pkg/net now takes ~ 43mb on 32bit platforms
<davecheney> down from 108
<davecheney> 103 on 8g
<davecheney> 5g is slightly larger because the Prog structure and Reg list is longer
<rogpeppe> morning all!
<Aram> hi.
<TheMue> rogpeppe: Hi
<rogpeppe> afk while the boiler man is fixing our boiler... hopefully.
<TheMue> Anyone interest in reviewing the changed firewaller? https://codereview.appspot.com/6875053/
<TheMue> interested
<TheMue> Aram: Do you want to take a look on the changed firewaller? https://codereview.appspot.com/6875053/
<TheMue> s/on/at/
<jam> mgz: /wave
<TheMue> Aram: Having fun doing installations with following reboots? ;)
<Aram> TheMue: just configuring NX.
<TheMue> Aram: IC
<rogpeppe> fwereade: ping
<TheMue> rogpeppe: He's out this morning.
<rogpeppe> TheMue: ah, thanks
<TheMue> rogpeppe: yw
<jam> rogpeppe: I've been meaning to ask. What does "CL" actually stand for?
<rogpeppe> jam: change list
<rogpeppe> jam: (i believe)
<jam> it doesn't seem to be a very good fit, IMO, but as long as it is known. :)
<rogpeppe> jam: yeah, i don't think it matters too much.
<dimitern> rogpeppe: do you think having a single mutex for all maps and other internal structures will suffice to overcome possible race conditions, or it's better to have one mutex per member (I'm referring to my CL for nova double)
<jam> dimitern: my suggesstion is to just put the mutex in ServeHTTP like the ec2 version
<rogpeppe> jam: +1
<rogpeppe> jam: do you really need to export all those Nove functions?
<rogpeppe> s/Nove/Nova/
<dimitern> jam, rogpeppe: but dave pointed out that since the API is public this might not be enough?
<rogpeppe> s/jam/dimitern/
<rogpeppe> dimitern: that's my question: does this API need to be public?
<rogpeppe> dimitern: who are you seeing as the clients of this API?
<dimitern> rogpeppe: well, since they're used for tests only, unless we use them outside the package, they can be private
<rogpeppe> dimitern: that's what i thought
<rogpeppe> dimitern: i'd suggest making them private
<jam> I'd slightly suggest that it is being a bit over prescriptive, but we can start there.
<rogpeppe> dimitern: then we can ignore concurrency issues for the tests (because we know we're not calling them concurrently) and the ServeHTTP mutex will be sufficient.
<rogpeppe> jam: if we don't do that, i think we'll probably end up needing a different entry point for each one of those calls, one for internal use (with lock held) and one for external use
<dimitern> rogpeppe: ok, seems reasonable
<rogpeppe> jam: given that almost all the functionality will be provided through the http interface, i'm not sure that's necessary.
<rogpeppe> jam: but maybe you see some utility to the entry points that i don't?
<jam> rogpeppe: I just think it is slightly overly prophylactic to say that you shouldn't have any public methods in case someone might use them incorrectly. But we can always go the 'its default private and we'll make it public when we need them'
<jam> I'm also a bit more used to Python where everything that is "private" is still public.
<jam> (consenting adults approach)
<rogpeppe> jam: given that it's an http server, i'm not sure it's possible to use the methods correctly without second-guessing what the server is doing behind the scenes (which breaks modularity)
<rogpeppe> jam: (because it's perfectly legitimate for the server to have something concurrent going on)
<jam> rogpeppe: it is possible that in testing you would take out the HTTP section of the communication because it isn't always relevant for the tests themselves. (the fact that goose talks HTTP to openstack *should* be an implementation detail).
<jam> ATM, we do, and we do for the forseeable future
<jam> so we can go that route.
<jam> but if HTTP overhead starts slowing down the tests, it would make sense to pull it out as uninteresting
<rogpeppe> jam: it's one of those areas in Go that we tend to be very careful about, because unlocked concurrent access is a source of hard-to-find bugs.
<rogpeppe> jam: if that happens to be the case (which i think is fairly unlikely), post-facto refactoring to make this possible would not be hard.
<rogpeppe> jam: also, we have had times when the http section of the communication has contributed to test failures, so it's worth keeping it in the loop IMHO.
<TheMue> Lunchtime, biab.
<dimitern> rogpeppe: PTAL https://codereview.appspot.com/6877054
<rogpeppe> dimitern: looking
<dimitern> jam: you too pls ^^
<rogpeppe> dimitern: replied
<dimitern> rogpeppe: thanks!
<dimitern> rogpeppe: was not sure *x.y when x is *T and y is *W will be the same as *x.*y
<rogpeppe> dimitern: you can't do *x.*y :-)
<dimitern> rogpeppe: yeah, but you got my point :)
<rogpeppe> *x.y is always the same as *(x.y)
<rogpeppe> dimitern: if x is a pointer, x.y is the same as (*x).y
<dimitern> rogpeppe: I was confused, because before x was T and y was *W, hence the parens
<dimitern> rogpeppe: I see, ok, good to know
<rogpeppe> dimitern: so when both x and y are pointers, *x.y is the same as *((*x).y)
<dimitern> rogpeppe: and no, flavors and servers must have links according to the OS API
<rogpeppe> dimitern: so perhaps building links automatically if none are given is reasonable behaviour
<rogpeppe> dimitern: but probably no need to distinguish []Link{} and nil there.
<rogpeppe> dimitern: BTW for chapter and verse on selector expressions, see http://golang.org/ref/spec#Selectors
<dimitern> rogpeppe: ok, so I can change it so it checks for len(links) = 0 and adds them
<rogpeppe> dimitern: that seems reasonable to me, assuming it does to jam
<dimitern> rogpeppe: but if Links []Link is nil, will len(Links) make sense?
<rogpeppe> dimitern: absolutely
<rogpeppe> dimitern: you can len([]T(nil)) and range over it too
<dimitern> rogpeppe: good!\
<rogpeppe> dimitern: same with maps
<rogpeppe> dimitern: and channels actually
<rogpeppe> dimitern: it simplifies quite a bit of logic
<dimitern> rogpeppe: yeah, for sure - learning new things about go every day :)
<rogpeppe> dimitern: it's worth reading parts of the spec until they make sense
<TheMue> Aram: How far has your digging into MAAS gone? Already found a suitable OAuth client for a MAAS client?
<Aram> TheMue: bradfitz wrote an oauth library.
<TheMue> Aram: OAuth 1 or 2?
<TheMue> Aram: IMHO MAAS need OAuth 1.
<dimitern> rogpeppe: but the problem is len([]T{}) == len([]T{nil}) == 0, so I cannot distinguish between those
<rogpeppe> dimitern: yes, but do you want to?
<dimitern> rogpeppe: well, originally my point was to create links only explicitly, so I can simplify my tests, otherwise I have to add the Links: []nova.Link{} to EACH server or flavor
<rogpeppe> dimitern: i'm not sure i understand. why do you have to do that?
<dimitern> rogpeppe: because if I don't DeepEquals will fail
<dimitern> rogpeppe: I'll have to have server := nova.ServerDetail{Id: "x", Links: []nova.Link{}} instead of just {Id: "x"}
<Aram> yes, DeepEquals distinguishes between []T{}, and the nil equivalent, that's a pity.
<Aram> just wrap DeepEquals.
<dimitern> rogpeppe: because in the latter case add will create the links, and what I passed and what got stored in the map will be different
<rogpeppe> dimitern: so you're using the []nova.Link{} to suppress the link creation?
<dimitern> rogpeppe: exactly
<dimitern> Aram: how?
<rogpeppe> dimitern: presumably you could put the expected links in there?
<Aram> pseudocode: if len(a) == len(b) == 0 { return true} DeepEquals(a, b)...
<dimitern> Aram: that's seems reasonable
<rogpeppe> dimitern: but i think the "buildlinks" argument is a perfectly reasonable solution too
<dimitern> rogpeppe: yes, but that will complicate a lot of cases, where I don't really need links at all
<rogpeppe> Aram: that won't work in this case
<Aram> rogpeppe: why not?
<rogpeppe> Aram: because the slice is embedded in a struct
<Aram> aah, ok.
<rogpeppe> dimitern: here's another possibility:
<Aram> well, you can write an Equals function for that struct.
<rogpeppe> dimitern: you could have a method on FlavorDetail that builds the links for it
<rogpeppe> dimitern: that would mean that addFlavor is a little less magic, and the link-building logic gets its own function, independent of addFlavor
<rogpeppe> dimitern: then you could call flavor.BuildLinks() before addFlavor, and the DeepEquals would work ok
<dimitern> rogpeppe: I was thinking of that actually, but the FlavorDetail is outside the package (in nova, not novatests)
<rogpeppe> dimitern: then add a function instead
<dimitern> rogpeppe: ok, that seems the least amount of overhead, I'll do it
<rogpeppe> dimitern: perhaps AddLinks(f *FlavorDetail) ?
<dimitern> rogpeppe: I was thinking of suite.buildLinksFlavor(f FlavorDetail) FlavorDetail and suite.buildLinksServer(s ServerDetail) ServerDetail
<dimitern> rogpeppe: I need the suite to construct the URLs (the hostname, etc. are in the suite)
<rogpeppe> dimitern: is it not functionality that you to be usable outside the test suite?
<dimitern> rogpeppe: hmm, hold on - actually that won't work
<rogpeppe> s/you to/you want to/ :-)
<dimitern> rogpeppe: my original idea was to make the direct api complete in a sense that calling addServer is enough to have everything initialized in the state, so the HTTP API will just need to get the server and serialize the ServerDetail to json
<dimitern> rogpeppe: but I suppose adding it to the suite won't be enough - i have to add it to the service itself and put a comment to call this always before add*() to produce a consistent result for the http api
<rogpeppe> dimitern: that seems reasonable.
<dimitern> rogpeppe: ok :) 10x for the walkthrough
<rogpeppe> dimitern: np
<dimitern> rogpeppe: ok, so now it should be fine https://codereview.appspot.com/6877054
<dimitern> rogpeppe: it you think it looks good I can go ahead and submit it
<rogpeppe> dimitern: one thought (sorry for not catching it earlier) - you could just mutate the links field *ServerDetail in place, rather than passing it in and out by value. YMMV though.
<dimitern> rogpeppe: I thought so, but I followed the same pattern append() uses for example
<rogpeppe> dimitern: append is a bit of a special case
<rogpeppe> dimitern: because it's designed to be called in many scenarios
<rogpeppe> dimitern: anyway (and including if you choose not to change it), still LGTM
<dimitern> rogpeppe: ok, I'll change it, 10x
<TheMue> fwereade: ping
<fwereade> TheMue, pong
<fwereade> TheMue, I'm just looking at your CL right now :)
<TheMue> fwereade: Aaaah, that's what I wanted to ask you to do. Thx. ;)
<fwereade> TheMue, quick question: in initMachine, you appear only to start a unit watch when the service is exposed
<fwereade> TheMue, AFAICT, in the rest of the FW, the unit watch is started regardless and the service exposure is only taken into account when refcounting?
<TheMue> fwereade: Yes
<fwereade> TheMue, did I misread somewhere? I'm still not familiar with the whole thing in detail :)
<TheMue> fwereade: One moment, have to look, because it tries to act like later in "runtime mode".
<fwereade> TheMue, ok, just to confirm: line 224, `if service.IsExposed() {`
<fwereade> TheMue, vs line 276, `} else if unit != nil && unit.Life() != state.Dead && fw.machine ds[machineId] != nil {`
<TheMue> fwereade: Yes, you're right.
<fwereade> TheMue, so, definitely a bug?
<TheMue> fwereade: Hmm, have to think what changes if the watch is started also for not yet exposed services.
<dimitern> rogpeppe: while you're still fresh on the topic, PTAL https://codereview.appspot.com/6910055/
<TheMue> fwereade: Funnily all tests are green, even repeated multiple (150x) in a row.
<dimitern> rogpeppe: this the follow up - removing interface and get prefix from methods
<rogpeppe> dimitern: looking
<rogpeppe> dimitern: just wondering: why NovaService rather than Nova?
<rogpeppe> dimitern: (novaservice.NovaService seems perhaps unnecessarily stuttering)
<dimitern> rogpeppe: well, as a convention - the other doubles are like that, and the package is novaservice to distinguish it from the nova package
<fwereade> TheMue, sure, but it's quite possible they just don't have a test case with the right parameters to trigger a bug -- or maybe it comes out not to be a bug after all
<TheMue> fwereade: Funny, behaves the same way.
<dimitern> rogpeppe: you think it's too long?
<fwereade> TheMue, but I am still having a bit of a hard time following all the different ways and times for creating the various datas
<rogpeppe> dimitern: the package name is fine. if it's a convention i don't mind much, but, yeah i think it could be shorter without loss of clarity
<fwereade> TheMue, ok, I think I have a fail case
<fwereade> TheMue, let me check it's not covered by the tests
<dimitern> rogpeppe: ok, fair enough I like shorter names too :)
<rogpeppe> dimitern: (given that it's always going to be qualified with the package name)
<rogpeppe> dimitern: generally the changes look great
<rogpeppe> dimitern: LGTM with that thought about the name
<dimitern> rogpeppe: thanks! I'll change the name and submit it then
<fwereade> TheMue, ISTM that there are no test cases that check the behaviour when a FW is started with an unexposed service -- which is then exposed while the FW is running
<TheMue> fwereade: OK, good hint, I'll add one for both modes.
<fwereade> TheMue, ok, but wait a mo
<fwereade> TheMue, there's something I think could be explored a bit further
<fwereade> TheMue, if we look more at initMachineData and assume the service is exposed and everything is fine
<fwereade> TheMue, sorry initMachine
<fwereade> TheMue, just after the createUnitData call
<fwereade> TheMue, when you get the OpenedPorts
<fwereade> TheMue, (sorry, thinking out loud, crrect me when I go off the rails)
<TheMue> fwereade: Go on.
<fwereade> TheMue, you set them directly on the unitData and then start the ud's watch
<TheMue> fwereade: The IsExposed() block has to be from before retrieving the OpenedPorts() and setting them in ud and md.
<TheMue> fwereade: Additional tests are working fine.
<fwereade> TheMue, hmm, ok
<fwereade> TheMue, I think the thing I'm finding hard to follow is the creation chain now
<fwereade> TheMue, you have several different funcs that create the same kinds of data in different ways
<TheMue> fwereade: I find it now even more clear than before.
<fwereade> TheMue, and I'm trying to think of a reason why any of those creation funcs need to be different in any way
<TheMue> fwereade: Not at all, but maybe I can move it into own methods to avoid code doubling, yes.
<fwereade> TheMue, ok; and yu now have two different styles of initialization too
<TheMue> fwereade: No
<fwereade> TheMue, I think that by using the new one troughout you will see a dramatic simplification
<TheMue> fwereade: Before we had two, now there is only one left.
<fwereade> TheMue, sometimes you fill in a machine's units and sometimes you don't, right?
<TheMue> fwereade: Huh?
<fwereade> TheMue, dammit, sorry
<fwereade> TheMue, line 437
<TheMue> fwereade: *lol*
<fwereade> TheMue, at what point does that machine's set of units contain valid data?
<TheMue> fwereade: After it's unit watcher sent its initial event which is then handled by the firewaller, that sets the data.
<TheMue> fwereade: This is the logic we had from beginning.
<fwereade> TheMue, ok, how long does it take for the initial event to be handled?
<fwereade> TheMue, or rather, at what point o yo know that all the initial events have been handled?
<fwereade> TheMue, (does this line of questioning sound familiar? ;))
<TheMue> fwereade: Stop
<TheMue> fwereade: This newMachineData() is only used after (!) the initial stuff is handled.
<TheMue> fwereade: That's what changed.
<fwereade> TheMue, yes
<fwereade> TheMue, I know
<TheMue> fwereade: In init() and in there in initMache(). Where explicitely the initial events of those initial watchers are handled before (!) the firewaller loop starts handling new changes.
<fwereade> TheMue, initMachine is a step in the direction we need to take
<fwereade> TheMue, but you do now have two ways of initializing a machine
<fwereade> TheMue, in one of them, the machine has the correct unit data and can be safely used at any point onwards
<fwereade> TheMue, in the other one, the machine starts off with empty unit data and has it added gradually after the fact
<fwereade> TheMue, I think that the second approach *is* in fact adequate to the needs of a running FW
<fwereade> TheMue, but I'm having difficulty figuring out why we have two separate initialization modes when we could have one that is correct in all circumstances
<TheMue> fwereade: Yes, and port changing is done when the information has arived. The problem has been when the firewaller starts and there are already open ports that have to be closed or closed ports that have to be open.
<TheMue> fwereade: But when those are handled all further initial and changing events handle the rest.
<fwereade> TheMue, are you arguing that it is better to have two separate ways of initing the various *Data structs?
<fwereade> TheMue, it really does make it hard for me to follow what's going on
<fwereade> TheMue, it feels like you're drawing information from a whole bunch of different sources and asserting that you have enough information to cover every possible case
<fwereade> TheMue, but every different data source is a potential race
<fwereade> TheMue, and I'm not sure I'm equal to the task of analyzing them all
<TheMue> fwereade: Avoiding code duplication for sure is a good goal.
<TheMue> fwereade: Step by step the FW is totally rewritte. :/
<TheMue> rewritten
<fwereade> TheMue, well, I was a little surprised by this direction -- I had thought we were clear on the advantages of doing *everything* based on watchers, instead of adding more random desynchronized data sources into the mix
<TheMue> fwereade: The bad think is that you're right, but on the other hand the change grows and grows. :(
<fwereade> TheMue, I *think* it's possible to make it shrink
<fwereade> TheMue, you only need a single creation function for each *Data type
<TheMue> fwereade: It is everythink done by watchers. But only in init() it's done on the initial event and later lazy.
<fwereade> TheMue, initMachine uses IsExposed() and OpenedPorts(), completely divorced from any sort of watches on those things
<fwereade> TheMue, you've moved the desynchronization up a level but not resolved it
<fwereade> TheMue, so: in each *Data creation function, you must *consume the guaranteed first event* from your own watcher, and fill in your state based on the information received
<TheMue> fwereade: Sorry, can't follow.
<fwereade> TheMue, ok, any time you create a machine
<fwereade> TheMue, all its unit and service data must be created and filled in before the watch lop is started and the creation function returns
<fwereade> TheMue, that is all you need to do, and all these alternate ways of initialization just fall away
<fwereade> TheMue, the *only* initialization you need is a `var reconciled bool` at the top of the FW loop
<fwereade> TheMue, and then `if !reconciled { reconciled := true; err := fw.initWhateverMode() etc }` at the end of the <-machinew.Changes branch
<TheMue> fwereade: ???
<fwereade> TheMue, ok
<fwereade> TheMue, let's turn this around
<fwereade> TheMue, why do you have more than one way of creating unit data, or machine data?
<fwereade> TheMue, why are the serviceDatas for those units created in different ways?
<TheMue> fwereade: That's already understood, the ??? has been for the reconciled mode.
<fwereade> TheMue, it is a bool which is used to fire off some logic once and only once when the time is opportune
<fwereade> TheMue, ie, once you have handled the first machines change
<fwereade> TheMue, you then have complete state, and can run initGlobalMode() or whatever to reconcile with provider-supplied reality
<fwereade> TheMue, then set the bool to true so we don;t hit the branch again
<fwereade> TheMue, and just casually handle all other changes as they come
<TheMue> fwereade: OK, just trying to bring it together.
<dimitern> if I do x := y, when y is struct {..}, does this mean it's making a copy and you can change x independently?
<dimitern> dimitern: answering to myself :) yep, it seems so - i checked
<TheMue> fwereade: But you still would init the first machines wtacher event before the firewaller loop?
<TheMue> fwereade: Eh, handle it.
<fwereade> TheMue, no, why?
<fwereade> TheMue, nothing is going to start sending on the other channels until the various *Datas have been set up
<TheMue> fwereade: Ah, no, get it with the reconciled.
<fwereade> TheMue, if you handle the whole chain in the first event that's all you need
<fwereade> TheMue, (ok, you might get an env change before the machines change, but that's all to the good)
<TheMue> fwereade: So the first event I get IS the initial machine watcher event, but in the loop. And there I use that flag to reconcile with the current real world.
<TheMue> fwereade: That sound reasonable.
<fwereade> TheMue, yeah, so, the first event is "all known machines"
<fwereade> TheMue, you do the machineLifeChanged for each machine as before
<fwereade> TheMue, the only difference is that you handle the initial event from the units watcher *before* starting the loop and returning the created machine
<fwereade> TheMue, but, ofc, for each unit in the initial event for that machine, you have data to create and fill in before starting the watch and returning the unit data
<fwereade> TheMue, this may even include starting a service watch, getting the initial event
<fwereade> TheMue, etc
<fwereade> TheMue, the idea is just to make sure that there's only one way to create each *Data kind, and that it always completely fills in its own data before it returns from the creation function (and has its watches based on diffs from that known state)
<fwereade> TheMue, I *think* this hugely simplifies matters
<fwereade> TheMue, am I making any sense?
<TheMue> fwereade: Hmm, to make it clean I have to move those newâ¦Data() to methods in firewaller, because the firewaller changes datas but not vice versa.
<fwereade> TheMue, yeah, my gut was suggesting that would be a good way to go
<fwereade> TheMue, I didn't want to be excessively prescriptive
<fwereade> TheMue, what's your feeling about the relative simplicity of the above approach? I think it would be smaller and easier to follow
<TheMue> fwereade: No, you aren't. But next time you've got such a redesign in mind just write down a little outline with comments. That's simpler than to do it in a dialog.
<mramm> fwereade: TheMue: I agree that we would all benefit from a bit of design documentation around lifecycle stuff
<TheMue> mramm: Hiya.
<mramm> in general I think we often find out that there are disagreements about design later in the process than we should
<mramm> some of that is inevitable
<mramm> and I don't want to do Big Design Up Front
<fwereade> mramm, yeah, I know what you mean
<mramm> but a few quick notes about what is planed would be good to have more often
<fwereade> yeah -- I think that perhaps some artifacts were preserved from lisbon, but I couldn't tell you *where*
<fwereade> mramm, if you think it would still be a win at this stage I would be more than happy to document what I plan to be doing to them over the coming weeks
<fwereade> mramm, what I plan to write does not differ in any significant way from what we agreed back then -- the fundamental dependencies have not changed
<mramm> fwereade: I do think it would be a win
<mramm> fwereade: I know, but we didn't really document what we agreed that well, so I think it would be good to do still
<TheMue> So, AFK for a few minutes, playing daughters taxi. BRB
<mramm> rogpeppe: I think it would also be good to document a bit about how we expect the API to work
<mramm> TheMue: cool, see you soon.
<rogpeppe> mramm: i agree
<mramm> rogpeppe: and also a little bit about the plan for building it
<rogpeppe> mramm: we some ideas but we haven't worked out what the message format will be like
<mramm> rogpeppe: so that we can see if we are over-promising for 13.04
<rogpeppe> mramm: i've already got a preliminary branch submitted with some of the basics done
<mramm> even writing down what we have now would be valuable I think, but of course the message format/content is the key
<rogpeppe> mramm: i'm building the framework from the bottom up and leaving decisions about the actual protocol until later
<mramm> ok, thats fine
<mramm> let's just define what we know, and write todo items for the decisions that still need to be made
<rogpeppe> mramm: i also did a preliminary top-down implementation, but it didn't go down that well
<mramm> always good to give it time
<TheMue> So, back again
<rogpeppe> for anyone that would like something to look at, a small CL: https://codereview.appspot.com/6902070/
<rogpeppe> time for me to go. have a good rest-of-day, peeps
#juju-dev 2012-12-11
<davechen1y> http://paste.ubuntu.com/1424439/
<davechen1y> ^ improvement ?
<davechen1y> ffs - tuesday is leaf blowing day in my block of units
<davechen1y> 3 fucking hours it takes the gardener
<davechen1y> the place is honestly not that big
<TheMue> Morning
<davechen1y> morning / evening
<dimitern> morning :)
<dimitern> anyone up for a review? https://codereview.appspot.com/6924043/
<TheMue_> dimitern: Morning, will take a look after I've handled the review I've got by fwereade_
<dimitern> TheMue_: thanks!
<rogpeppe1> TheMue_, dimitern, davechen1y, fwereade_, mramm: morning!
<TheMue_> rogpeppe1: Morning.
<dimitern> rogpeppe1: morning!
<dimitern> rogpeppe1: you too, wanna take a look? https://codereview.appspot.com/6924043/
<rogpeppe1> dimitern: will do
<dimitern> rogpeppe1: thanks!
<fwereade_> morning everyone -- dropped laura at school, busses were somewhat unhelpful
<dimitern> fwereade_: morning
<fwereade_> rogpeppe1, TheMue_, I would appreciate comments on https://codereview.appspot.com/6906046/ which has been out for a few days
<fwereade_> dimitern, (heyhey)
<TheMue_> fwereade_: Hey, will take a look
<fwereade_> rogpeppe1, TheMue_: "this is awful, there's no way you can do that" is not an unreasonable response, but if you feel that way I would appreciate advice re better approaches to the change
<rogpeppe1> fwereade_: sorry, i must have missed it, will take a look after i've finished on dimitern's review
<fwereade_> TheMue_, btw, nice work on the firewaller, I'm much more comfortable with it now, I think the unit port initialization is the only major thing I have quibbles about
<fwereade_> rogpeppe1, most of those days have been weekends tbh :)
<TheMue_> fwereade_: Hehe, thx, changed it and now the test breaks. Have to look what I've missed.
<fwereade_> TheMue_, heh, it may be something I've missed
<TheMue_> fwereade_: I'll see, but indeed, thx to your critical review it looks by far better now.
<fwereade_> morning Aram
<Aram> hi.
<dimitern> Aram: morning
<TheMue_> fwereade_: Removing the changes of initializing the unitData.ports and the ports in its watchLoop() with OpenedPorts() lets everything work again.
<TheMue_> Aram: Hiya.
<fwereade_> TheMue_, sorry, missed that message
<fwereade_> TheMue_, would you expand? you're saying the suggestion breaks everything, right?
<TheMue_> fwereade_: NP, just looking for another one so I'll come back to you later.
<fwereade_> TheMue_, I'd like to figure out why if possible :)
<fwereade_> TheMue_, but whenever works for you is fine by me
<TheMue_> fwereade_: Two global tests are breaking when initializing the unitData and its watchLoop ports with unit.OpenedPorts()
<TheMue_> fwereade_: But now I've changed it back and possibly I missed something because a test hangs. So let me figure that out and we can talk about the unit port init again.
<fwereade_> TheMue_, great, just grab me when you feel like it :)
<TheMue_> fwereade_: Yep, will do so.
<dimitern> rogpeppe1: how is it?
<dimitern> rogpeppe1: i hope not too bad for a second phase of the http implementation :)
<rogpeppe1> dimitern: generally good. i'm just finishing writing up a few ideas for how it might be simplified
<dimitern> rogpeppe1: great!
<rogpeppe1> dimitern: you've got some comments
<dimitern> rogpeppe1: thanks
<rogpeppe1> dimitern: BTW, i forgot to mention, i think your current handler will panic if you give it the url "/v2"
<dimitern> rogpeppe1: hmm, I left the panic temporarily there for the time being, I'll fix that
<rogpeppe1> dimitern: no, it'll panic with an out-of-range-index error
<dimitern> rogpeppe1: I see, ok, I missed that then
<rogpeppe1> dimitern: but rather than fix it, i suggest using http.ServeMux instead, if you think it's feasible
<dimitern> rogpeppe1: ok
<dimitern> rogpeppe1: and about the templating - wouldn't it be confused by the { } in the JSON? That's why I didn't use it - was not sure it'll work
<rogpeppe1> dimitern: no - it requires {{ }} not { }
<rogpeppe1> dimitern: hmm, except
<rogpeppe1> dimitern: well, it might be ok as it is. but you can change the delimiters too
<dimitern> rogpeppe1: ok, I'll give it a go
<rogpeppe1> dimitern: see http://golang.org/pkg/text/template/#Template.Delims
<dimitern> rogpeppe1: 10x, looks promising
<rogpeppe1> dimitern: ${ }$ maybe?
<dimitern> rogpeppe1: yeah
<dimitern> rogpeppe1: could you explain more about what table-based approach you'd use instead of the nested switch statements in handleFlavors?\
<rogpeppe1> dimitern: well, i think ServeMux gives you a lot of what you need
<rogpeppe1> dimitern: that gets rid of one level of the switch
<dimitern> rogpeppe1: so handleFlavors and handleFlavorsDetail as separate things?
<rogpeppe1> dimitern: but i don't know if it's appropriate for all the requests you need to handle
<rogpeppe1> dimitern: yes
<rogpeppe1> dimitern: but...
<rogpeppe1> dimitern: not necessarily
<rogpeppe1> dimitern: only if you think it works out well
<dimitern> rogpeppe1: ok, I'll try a few solutions to see which one looks best
<niemeyer> Morning all!
<dimitern> niemeyer: morning!
<rogpeppe1> fwereade_: you've got a review
<rogpeppe1> niemeyer: yo!
<fwereade_> rogpeppe1, cheers
<fwereade_> niemeyer, heyhey
<niemeyer> Btw, right now I'm fully on battery + 3G
<niemeyer> I should have a few hours still.. hopefully it'll come back before then
<niemeyer> Huge storm last night
<TheMue_> niemeyer: Hiya, hope no damage at your home.
<niemeyer> TheMue_: Heya! All good here luckily..
<niemeyer> Only a ton of wind and noise
<fwereade_> incidentally, if anyone feels life a spot of light reading, I'd appreciate a sanity check on the lifecycle stuff I wrote last night
<TheMue_> niemeyer: Phew, I always have much respect for those natural powers.
<fwereade_> and perhaps a discussion on where I should be putting such things long-term
<fwereade_> maybe we do want a doc/ dir?
<TheMue_> fwereade_: I would prefer a google doc.
<niemeyer> fwereade_: Where's that?
<niemeyer> mramm: Has the meeting time shifted again?
<fwereade_> niemeyer, sorry, lp:~fwereade/+junk/juju-braindump
<niemeyer> fwereade_: np, cheers
<mramm> niemeyer: I think the tuesday version of the meeting just never got shifted
<mramm> perhaps I'm wrong though, it is too early and I have not had my coffee yet this morning
<fwereade_> niemeyer, it has a few bits and pieces I also wrote for evilnick a while back as, er, kinda proto-documentation
<niemeyer> mramm: I thougth we had agreed to 13UTC and 22UTC for the time beeing
<niemeyer> being
<mgz> fwereade_: ah, have you updated that? I read through when you first posted it and found it really useful
<fwereade_> mgz, cool :D
<fwereade_> mgz, there's one new document describing lifecycles
<mramm> right, and I just shifted it from 12:00 utc to 13:00
<fwereade_> mgz, it's more a statement of intent than a description of current state, though
<mramm> at least that's what I thought I did ... looking again
<niemeyer> fwereade_: I think the way to put that kind of discussion is indeed in a branch, preferably up for review
<dimitern> mramm: so it's going to be in a bit more than an hour from now, not in 20m?
<mramm> yea
<niemeyer> mramm: It's at 12UTC right now
<niemeyer> mramm: in 20 minutes
<fwereade_> niemeyer, fair enough -- I'm just not quite sure where I should be targeting
<mramm> I just updated it to be 1 hour from now
<niemeyer> fwereade_: Hmm.. where you should be targeting?
<mramm> about 10 minutes ago
<fwereade_> niemeyer, do we want a doc/ directory in juju?
<niemeyer> mramm: Ah, thanks
<mramm> I thought your message was in response to that update e-mail
<mramm> because it came *right* after I did the update
<mramm> very confusing ;)
<mramm> correlation does not imply causation
<niemeyer> fwereade_: We already have the sphinx docs somewhere.. we could integrate there, but that seems less important than just being able to discuss the proposal in the first place
<fwereade_> niemeyer, (the other issue is that that branch is definitely not polished and not really quite right for actual documentation -- it's useful, I hope, but not quite something we want to call "official")
<fwereade_> niemeyer, the main point is to capture the stuff that's in my head and maybe not anywhere else
<mgz> that kind of doc is still far better than not having any
<fwereade_> niemeyer, still, codereview is indeed a good discussion vector
<niemeyer> fwereade_: That's what we used to call a draft in the old system
<niemeyer> fwereade_: There's no cut-off for drafts
<fwereade_> niemeyer, ok, a proposal for juju-core/doc/draft then?
<niemeyer> fwereade_: Sounds good.. at least that'll give us the ability to comment/respond comfortably
<niemeyer> fwereade_: Even if we later disagree on the end location
<fwereade_> niemeyer, ok, great
<rogpeppe1> fwereade_: in your comment here (https://codereview.appspot.com/6902070/diff/2001/state/api/serve.go#newcode65), what's your reason for asking for a defer? a simple statement seems fine for that straightforward logic to me.
<rogpeppe1> fwereade_: (i think that dfc's remark is a red herring - lis.Close can't panic, 'cos we've checked the listener's ok elsewhere, and even if it does, the panic takes out the whole system, so the defer doesn't help at all
<rogpeppe1> )
<fwereade_> rogpeppe1, it just feels that little bit more "correct" -- you never know when some tricky sod will recover() :)
<fwereade_> rogpeppe1, I'm easy on that one though
<rogpeppe1> fwereade_: you do here - it's in a go func() { } !
<fwereade_> rogpeppe1, ha! good point :)
<fwereade_> rogpeppe1, consider my +1 decremented then :)
<niemeyer> :)
 * niemeyer switches to fast network connection again
<davecheney> heh hey
<davecheney> can someone send me the hangout code
<Aram> I believe it's in one hour.
<davecheney> the meeting time was for 11pm aud
<Aram> perhaps I am mistaken with these things, as I usually am, but <mramm> right, and I just shifted it from 12:00 utc to 13:00
<dimitern> davecheney: it was changed from 12 UTC to 13 UTC just 20m ago
<davecheney> jesus fuck people, this is importnat
<niemeyer> davecheney: Heya! The meeting was mischeduled 1h too early.. the first one is still at 13UTC as last week
<niemeyer> davecheney: The mistake was in Google Calendar.. it hadn't been fixed since we agreed on the timings last week
<Aram> I remember something about a calendar where we put or holidays.
<Aram> does anyone else remember that?
<Aram> s/or/our/
<niemeyer> Aram: mramm will know
<davecheney> Aram: try this http://www.google.com/calendar/embed?src=canonical.com_ia67e1a7hjm1e6s3r2lid9nhs4%40group.calendar.google.com&ctz=Australia/Sydney
<davecheney> or in canonical google apps, add "Juju Team Calendar"
<Aram> thank you sir.
<mramm> sorry, I'm in a meeting now
<mramm> I'm very sorry that I didn't get the meeting invite updated
<davecheney> mramm: shit man, i was at a place with an open bar tab
<davecheney> mramm: s'ok, timezones are hard, no real harm done
<mramm> davecheney: I'll buy you something nice, sorry
<mramm> ;)
<TheMue> fwereade_: Your firewaller review is commented, the next propose is in.
<fwereade_> TheMue, cool, I'll take a look
<davecheney> TheMue: did you see the data race that the race detector found ?
<TheMue> fwereade_: Cheers.
<TheMue> davecheney: Yes, and I think it's covered now. The unit watcher loop is started after the service access now.
<davecheney> TheMue: superb
<TheMue> davecheney: But I still have to learn how to read the race analysis output. ;)
<davecheney> TheMue: >> the manual >> http://code.google.com/p/go-wiki/wiki/RaceDetector
<TheMue> So, quick lunchtime before we'll meet. BIAB.
<Aram> mramm: please add me to the hangout, when you make it.
<mramm> Aram: I added the hangout link to the meeting invite
<mramm> I think I also got everybody added to the invite list
<mramm> but if you aren't on the list, the link is in the invite
<rogpeppe1> Aram: you lose, i'm afraid
<mramm> well, meeting is now full
<davecheney> bzzt
<davecheney> Aram: don't worry, someone will drop off in a few minutes
<davecheney> if previous experiences are any guide
<Aram> what's the point of two meeting if everyone wants to be in the first one?
<mramm> yea
<mramm> that's a problem
<mramm> but I don't think this will happen regularly
<mramm> unless the AU guys are always up at midnight
<mramm> didn't happen last week...
<davecheney> mramm: it won't happen again
<davecheney> once you fix the meeting invite
<davecheney> *subtle hint*
<mramm> I will also try to dig into the meeting invite thing
<mramm> davecheney: is it still wrong?   I thought I got it fixed this morning.
<davecheney> mramm: i can confirm it said 23:00 hours as of 22:00 hours tonight
<Aram> well, even if we manage to balance the meetings, I still don't understand the point. I thought we had this meeting so that everyone gets familiar with other team member's work. what's the value in becoming familiar with only half the work from people changing each week?
<Aram> or does this meeting have any other purpose?
<mramm> davecheney: yea, that was my fault, I thought I updated the meeting in perpetuity, but only ended up updating the one on thursday last week
<mramm> then when I checked this morning it was already just after 23:00 :(
<davecheney> mramm: you have now sent a meeting invite for an hour earlier than the time that it wasn't already
<davecheney> Juju Team Meeting
<davecheney> When
<davecheney> Weekly from 22:00 to 22:25 on Tuesday Eastern Time - Melbourne, Sydney
<mramm> hmm.  Something strange going on, I will dig in after the meeting.
<rogpeppe1> Aram: you can join now if you like
<rogpeppe1> Aram: one free slot :-)
<davecheney> mramm: sorry, i had to leave
<davecheney> i was given an unequivical command
<mramm> davecheney: no problem
<mramm> davecheney: you have to take care of your self, and your relationships -- far more important than this meeting
<Aram> mgz: jam: Launchpad bug 1069570
<jam> bug #1069570
<dimitern> no bug bot here it seems
<Aram> https://launchpad.net/bugs/1069570
<jam> Aram: if you are able to reproduce it, I think maas would love to get the feedback on the bug. Essentially Julian/Diogo/Raphael can't reproduce it on their hardware, so need more details.
<Aram> I can reproduce it 100% of the time, nothing works because of it.
<Aram> I can reproduce it in different deployments.
<Aram> virtual and physical.
<jam> Aram: just to check, what version of Ubuntu and Maas are you using?
<niemeyer> jam, dimitern: Now we do
<Aram> 12.10, packaged maas.
<dimitern> niemeyer: good, let's try that: bug 1069570
<jam> Aram: you may want to try: https://launchpad.net/~maas-maintainers/+archive/daily-qa-ok as they've put forth effort of a bunch of fixes that are planned to be SRU'd to 12.10
<_mup_> Bug #1069570: 1 MAC Address, two IPs - DNS is "out of sync" with DHCP leases databases, I think... <MAAS:Incomplete> <maas (Ubuntu):Incomplete> < https://launchpad.net/bugs/1069570 >
<dimitern> cool :)
<Aram> I will try that version.
<jam> (I'm guessing it may not fix the immediate issue, but it is likely it may fix other bugs that you might run into.)
<jam> Sarah Bartlett <sarah.bartlett@canonical.com>
<niemeyer_> jam: Let's try to get "juju submit -tarmaq" working somehow
<niemeyer_> (or whatever, really)
<jam> niemeyer_: you mean 'lbox submit -tarmac' right?
<niemeyer_> jam: Duh, sorry, yes
<niemeyer> Lunch time here too
<niemeyer> biab
<fwereade_> TheMue, btw, the big question I meant to ask was about the unitData ports-setting only when the service is exposed
<fwereade_> TheMue, because ISTM that that is just papering over a bug in reconcileGlobal (which doesn't take account of service exposure) and is not in fact correct
<fwereade_> TheMue, because otherwise we have no way to figure out what ports should be opened on a machine whose units have previously opened ports but whose services have just become exposed
<fwereade_> TheMue, sensible?
<TheMue> fwereade_: Sounds to me as two ways to approach the same situation.
<fwereade_> TheMue, let's go through how it works
<TheMue> fwereade_: The unitData's ports shall represent which ports the unit wants to have.
<fwereade_> TheMue, machine m has a unit u of service s
<fwereade_> TheMue, u has opened port 80
<fwereade_> TheMue, s is not exposed
<fwereade_> TheMue, when you collect this data and run initGlobal, u's ud has no ports
<fwereade_> TheMue, u does not change again
<fwereade_> TheMue, but s becomes exposed
<TheMue> fwereade_: Yes. So when ud is started it doesn't add port 80, but when s is exposed it will get notified.
<fwereade_> TheMue, how do we know to open port 80?
<fwereade_> TheMue, explain the mechanism
<fwereade_> TheMue, it *will* happen, by accident, if you're lucky enough to get an intervening change to u
<TheMue> fwereade_: Will do, one moment.
<TheMue> fwereade_: No
<TheMue> fwereade_: The services exposed flag is watched.
<fwereade_> TheMue, indeed so
<TheMue> fwereade_: And this change will be sent to the FW loop.
<fwereade_> TheMue, when we get a service change, do we rescan all the units?
<TheMue> fwereade_: And it retrieves the services units and flushes them ( fw.flushUnits() ).
<fwereade_> TheMue, agreed
<fwereade_> TheMue, how does the unit know what ports are open?
<fwereade_> TheMue, AIUI, the unit should know what ports are open because they're set on the unitData
<fwereade_> TheMue, but actually they're not, because you trashed them ;p
<TheMue> fwereade_: One moment, have to follow the logic again.
<TheMue> fwereade_: Where?
<fwereade_> TheMue, lines 165-169
<fwereade_> TheMue, ok, technically you didn't trash them, you just never got them
<fwereade_> TheMue, the impact is the same :)
<TheMue> fwereade_: Maybe you should rephrase it.
<fwereade_> TheMue, do you agree that you only set ports on the ud when the service is exposed?
<TheMue> fwereade_: At start time when it's exposed. And it's meant to react later on the exposed events. I've got to compare it to the old code to see what has got lost.
<fwereade_> TheMue, we can figure it out right here I think
<rogpeppe1> wouldn't it be nice if the canonical "My Leave" page could at least show leave ordered by date?
<TheMue> fwereade_: Please give me some moments, I have to see code in parallel.
<fwereade_> TheMue, I honestly think it will be simpler to consider just the code that exists
<TheMue> fwereade_: Port changes effect the unitData in line 101.
<fwereade_> TheMue, what makes you think you're going to get a ports change before the service exposure change?
<TheMue> fwereade_: And line 347 collects thos per machine.
<fwereade_> TheMue, yeah, line 347 is great
<fwereade_> TheMue, I'm asking why line 213 isn't doing the same thing
<fwereade_> TheMue, look, it's even simpler
<fwereade_> TheMue, ISTM that the unit ports data is *wrong* if you discard it based on lack of service exposure
<TheMue> fwereade_: When a UD is started it represents its valad status at this time. If then ports change or its services exposed flag is changing it is reacting, regardles what is first.
<tasdomas> hi
<tasdomas> I'm having problems setting up a juju environment
<tasdomas> locally, using lxc
<tasdomas> after setting up the environments.yaml file and running juju bootstrap, I get:
<tasdomas> error: environment "local" has an unknown provider type "local"
<fwereade_> TheMue, when a UD is created for a unit that has opened port 80
<fwereade_> TheMue, and the UD's ports field is empty
<fwereade_> TheMue, is this correct?
<TheMue> fwereade_: Sorry, doesn't sound logical to me.
<fwereade_> TheMue, ok, but that's what you're doing, right?
<TheMue> fwereade_: You mean a started UD with a U with open port 80 but S is not exposed has no ports? Then yes.
<fwereade_> TheMue, then why does a change in the unit's actual ports update the UD's ports regardless of service exposure?
<fwereade_> TheMue, if you believe this is a bug, you will need to explain how you;re meant to get the open ports for 100k units when the service is exposed :)
<TheMue> fwereade_: So you think a UD should always represent all open ports and only reconcileXyz or the processing of the servicesses exposed event have to take care?
<fwereade_> TheMue, not exactly
<fwereade_> TheMue, I think that service exposure tracking and unit port tracking are orthogonal
<fwereade_> TheMue, and that the only connections between the two are (1) that service watches are started and stopped based on the existence of at least one unit of that service
<TheMue> fwereade_: That's what I IMHO said.
<fwereade_> TheMue, and (2) that a units ports only contribute to its machine/environment when the relevant service is exposed
<fwereade_> TheMue, I'm not sure whether I've managed to communicate the problem
<fwereade_> TheMue, is it your position that UDs' ports fields should only contain ports when the service is exposed?
<TheMue> fwereade_: Sounds like several places in the code you want to be changed again, especially lots of the old logic we began with.
<fwereade_> TheMue, nope, it's all new logic that I'm complaining about
<fwereade_> TheMue, that doesn't fit with the old logic
<TheMue> fwereade_: OK, then I did get those (1) and (2) wrong, because in the statement before it has been more clear to me.
<fwereade_> TheMue, ok, will you look at line 346?
<TheMue> fwereade_: And that indeed is only in the new parts.
<fwereade_> TheMue, and explain what it does?
<TheMue> fwereade_: Got it
<fwereade_> TheMue, (that's old code AFAIK and it looks to me like it's doing the right thing -- for your position to be consistent, that line must I think be redundant)
<fwereade_> TheMue, line 346 is I think in flushMachine -- are we maybe looking at different versions or something?
<TheMue> fwereade_: No, just said, I got your point. Will change it.
<fwereade_> TheMue, ah sorry -- I misunderstood
<fwereade_> TheMue, ok, I'll send my comments, there are a couple of other minors
<rogpeppe1> niemeyer: ping
<niemeyer> rogpeppe1: pongus
<rogpeppe1> niemeyer: wanna chat about the API?
<niemeyer> rogpeppe1: Yeah, G+?
<rogpeppe1> niemeyer: sounds good, will try and regain ownership of the mac, one mo
<niemeyer> rogpeppe1: COol :)
<niemeyer> I'll grab some coffee meanwhile
<TheMue> So guys, have to step out, drive to the neighbour town for a concert (Night of the Proms). CU tomorrow.
<TheMue> fwereade_: The changed CL is in.
<fwereade_> TheMue, cool, looking
<TheMue> fwereade_: Cheers.
<rogpeppe1> niemeyer: invite out
<rogpeppe1> http://paste.ubuntu.com/1425552/
<rogpeppe1> it's time for me to go.
<rogpeppe1> g'night all
<rogpeppe1> oh yeah, i'll be in late tomorrow morning, as i've got to go into town for an errand
<niemeyer_> I'm stepping out as well, but will be back later for the evening meeting today
<niemeyer_> Well, evening for me anyway :)
<niemeyer> Isn't it meeting time?
<niemeyer> davecheney, mramm?
 * davecheney waves
<davecheney> where is mramm ?
<niemeyer> mramm: pingous
<niemeyer> davecheney: We should meet anyway
<niemeyer> davecheney: I'll fire the chat
<davecheney> ok
<niemeyer> Everybody is invited
<wallyworld> use the hangout url in the invite?
<mramm> davecheney: pong
<davecheney> mramm: https://plus.google.com/hangouts/_/ff8fbcfc0274167525781f024d8e2131cc3b4972?authuser=1&hl=en
#juju-dev 2012-12-12
<wallyworld> davecheney: are you able to take one more look at https://codereview.appspot.com/6867073/ and see if it's now good to go?
<davecheney> wallyworld: surethign
<wallyworld> thanks
<wallyworld> davecheney: the current config schema works for ec2, but for OpenStack username, tenantname, authorisation url, (and even region) should be supported to allow these things to go in the environment YAML file rather than having to be set via env vars. is this a reasonable assumption?
<davecheney> wallyworld: sounds reasonable
<davecheney> in the ec2 config you can specify your key and stuff in either the environs.yaml, or ENV vars
<davecheney> wallyworld: am I talking about the same thing ?
<wallyworld> yes
<wallyworld> in config/config.go the schema is defined
<wallyworld> but it only has ec2 things
<wallyworld> meaning the only way to connect to openstack is to use env vars for the required parameters
<wallyworld> well at least that's how i see it
<wallyworld> i could be wrong
<davecheney> wallyworld: will check about ec2 things
<davecheney> by config/config.go is the generic configuration items
<davecheney> then each provider has their own */config.go which adds the specific items like region, et al
<davecheney> wallyworld: please hold, checking
<wallyworld> ok
<wallyworld> davecheney: yes you are right, found it
<wallyworld> each provider does have it's own schema setup
<wallyworld> i will look at that, thanks
<davecheney> wallyworld: so the idea is config/config.go is the generic config (it's at the bottom of the file, which is confusing)
<davecheney> then that struct is embedded in the config struct for each provider
<davecheney> so they /extend/ (sort of)
<davecheney> then config with their own attributes
<davecheney> configuration was *ahem* contenious
<wallyworld> :-)
<wallyworld> like error handling :-)
<davecheney> don't mention the war
<wallyworld> i don't want to mention it but i am trying to get a code review approved :-)
<wallyworld> and it has been contentious
<davecheney> you and me both
<TheMue> Morning all
<fwereade__> TheMue, heyhey
<fwereade__> TheMue, does that review look roughly sane to you?
<TheMue> fwereade__: Oh, thought you're not here today.
<TheMue> fwereade__: Looked good on a first view I've yesterday done on my mobile. Will start with it in a few moments. Still tired a bit from yesterday evening.
<fwereade__> TheMue, no worries :)
<dimitern> TheMue, fwereade__: morning!
<fwereade__> dimitern, heyhey
<TheMue> fwereade__: So you're out tomorrow and Friday?
<TheMue> dimitern: Hiya
<fwereade__> TheMue, yeah, but I'll work a half day one of those days to make up for mon morn
<TheMue> Ok
<fwereade__> dimitern, jam, mgz, TheMue, mramm: I believe that all of you will have some interest in https://codereview.appspot.com/6922051 -- comments would be most welcome
<TheMue> fwereade__: Will have a look in a few moments.
<fwereade__> (it's the doc stuff we were talking about yesterday)
<dimitern> fwereade__: 10x, I'll have a look
<mgz> blopom.
<dimitern> is there a way to stop http.ServeMux from redirecting with 301 when I have /path/ defined, so I can handle both /path/ and /path with the same handler?
<Aram> yo.
<dimitern> now i have mux.Handle("/path/", somehandler) and passing "/path" responds with 301 -> /path/
<dimitern> Aram: hey
<TheMue> Aram: Hiya
<TheMue> fwereade__: Btw, while I'm reading your texts, my CL is back in again.
<fwereade__> TheMue, cheers, I'll take a look when I'm done with my bug-capture pass
<TheMue> fwereade__: Great, thanks.
<fwereade__> mramm, when you're around, there's a huge list of new bugs culled from TODOs in the docs -- sorry I didn't get to them yesterday :(
<mramm> fwereade__: thanks!
<mramm> fwereade__: no problem, there was no hurry
<mramm> fwereade__: but it is good to have them so that we can get in on the fancy burn down chart action
<fwereade__> mramm, cool
<dimitern> nevermind, I found a way around :)
<fwereade__> Aram, morning
<fwereade__> Aram, I would appreciate any comments you might have on https://codereview.appspot.com/6922051 -- I'm particularly concerned that I not propagate misinformation
<dimitern> fwereade__, TheMue, jam: PTAL https://codereview.appspot.com/6924043
<fwereade__> dimitern, I should get to that shortly
<dimitern> fwereade__: cheers!
<TheMue> dimitern: Will do after ending with Wiliams.
<dimitern> TheMue: thanks
<Aram> fwereade__: looking.
<TheMue> fwereade__: Yay *hug*
<fwereade__> TheMue, haha, I was just about to say it in chat
<fwereade__> TheMue, I imagine you had an alert hooked up to a confetti cannon for that LGTM :)
<fwereade__> niemeyer, morning
<TheMue> fwereade__: My mobile signals the Google mail sent after the review immediately.
<fwereade__> TheMue, nice
<TheMue> fwereade__: Exactly, I'm starting a party now. ;)
<TheMue> fwereade__: Btw, really like the work you've put into your documents. I'm still reading and it's great so far. Also helping new team members getting into the system.
<fwereade__> TheMue, cool, thanks :)
<fwereade__> TheMue, they're still very rough
<TheMue> fwereade__: But written in a good readable way.
<fwereade__> TheMue, excellent :D
<niemeyer> fwereade__: Yo
<niemeyer> Good morning all
<fwereade__> niemeyer, how's it going?
<niemeyer> fwereade__: Good stuff, still waking up :)
<TheMue> fwereade__: Could you explain your comment on line 145 a bit more?
<fwereade__> TheMue, it's just an extension of what I was saying about the tomb access -- if the underlying Stop fails, watcher.Stop will kill the supplied tomb
<fwereade__> TheMue, and that error is actually a consequence of the one you return
<fwereade__> TheMue, so we'll get misleading kill reasons if we're unlucky
<fwereade__> TheMue, in general I like it when tomb.Kills are not scattered too widely, it makes it hard for me to follow expected shutdown procedures
<TheMue> fwereade__: To make it more clear, which Stop() do you mean here? The machind isn't running at that point.
<fwereade__> TheMue, 145 watcher.Stop(unitw, &fw.tomb)
<fwereade__> TheMue, this will call unitw.Stop, and perhaps fw.tomb.Kill
<TheMue> fwereade__: Ah, now I've got it.
<rogpeppe1> morning all
<fwereade__> rogpeppe1, heyhey
<TheMue> fwereade__: I've been confused, becaus e machineData has a stop() too but that could not be used here.
<TheMue> rogpeppe: Morning
<fwereade__> TheMue, yeah, the tombs are an aspect of the FW about which I am not wild
<fwereade__> TheMue, but I have no interest in further delaying this work because of them
<TheMue> fwereade__: OK
<fwereade__> TheMue, I can see why they're the way they are, and I'm not sure I have a better suggestion anyway :)
<TheMue> fwereade__: *lol*
<rogpeppe> fwereade__, niemeyer: can i run an idea past you for crackfulness?
<fwereade__> rogpeppe, btw, your comments on https://codereview.appspot.com/6906046/ have (probably) been addressed
<fwereade__> rogpeppe, ofc
<niemeyer> rogpeppe: Sure
<rogpeppe> fwereade__: i'm wondering about having the agents use a juju.Conn (without an Environ) instead of always State directly
<rogpeppe> fwereade__: that way we can put an API connection in there too
<fwereade__> rogpeppe, hmm, gut says -1 (mainly because I'm not sure what a Conn without an Environ actually is)
<fwereade__> rogpeppe, but I have always been a bit ambivalent about Conn itself anyway
<niemeyer> That sounds like turning COnn into State, which doesn't sound very appealing on itself
<rogpeppe> fwereade__: it's a wrapper around the State. (almost nothing that you do on the Conn actually involves the environ, actually)
<niemeyer> rogpeppe: It's a high-level wrapper for comfortable library-like usage
<rogpeppe> niemeyer: i'm not suggesting hiding the State completely
<rogpeppe> niemeyer: just making it so that agents can access functionality through the API when they want
<niemeyer> rogpeppe: I don't think I get it.. they should use functionality through the API at all times
<dimitern> rogpeppe: hey :) wanna take a look - https://codereview.appspot.com/6906046/
<rogpeppe> niemeyer: agreed, but i was thinking this might be a reasonable transitional step
<niemeyer> rogpeppe: The idea still scapes me
<fwereade__> niemeyer, I think the issue is that that's unworkable until we have a complete API, and that the "Conn" suggestion allows a path there without a big bang change
<niemeyer> escapes
<fwereade__> niemeyer, rogpeppe: suggestion: drop the word "Conn" from the discussion
<niemeyer> fwereade__: I don't see how it changes the problem
<niemeyer> fwereade__: Huh.. I think I don't know what we're talking about :)
<niemeyer> <rogpeppe> fwereade__: i'm wondering about having the agents use a juju.Conn (without an Environ) instead of always State directly
<niemeyer> How do we drop Conn from that proposal?
<fwereade__> niemeyer, rogpeppe: so it becomes "we need to be able to use parts of the API before we have a complete API, and I think we should have a type containing both a State and an ApiState"
<rogpeppe> fwereade__: yes
<rogpeppe> fwereade__: Conn was just a place i thought might be reasonable for doing that
<fwereade__> rogpeppe, I remain -1 on putting that into Conn, myself
<niemeyer> fwereade__: Well, sure.. just put add both of them to the function that creates the worker
<rogpeppe> hmm, i wonder if api.State could just embed state.State
<fwereade__> rogpeppe, that's kinda dirty, but I think I like it
<fwereade__> rogpeppe, we can get an instant picture of how far we have to go by comenting out the embed and trying to build :)
<rogpeppe> fwereade__: i'm not entirely sure it'll work though
<niemeyer> It feels pretty dirty indeed, and it's not clear what the advantage is comparing to doing the obvious and having two values and using each of them when we want to
<fwereade__> niemeyer, I am not really keen on having all our client code have to keep track of two "state" things, and transitioning every client over call by call
<rogpeppe> niemeyer: it means that, potentially, we can add new calls to the api and have them automatically used by all state clients.
<fwereade__> niemeyer, not having to do that is the main advantage of the suggestion, I think
<niemeyer> fwereade__: What would be the problem with doing so?
<niemeyer> fwereade__: We can also get an instant picture of what is left
<fwereade__> niemeyer, busywork, confusion, places we miss
<dimitern> I'll grab some lunch
<fwereade__> niemeyer, in my own personal calculus of nastiness the two approaches are roughly equal, but for different reasons
<niemeyer> fwereade__: All of those things seem equally applicable to the previous suggestion
<niemeyer> fwereade__: The difference is that the second one is explicit
<rogpeppe> in a way, the api *is* a wrapper around state.State, if you want to look at it that way, so embedding it doesn't feel too untoward
<fwereade__> niemeyer, isn't just a matter of removing a method from State and adding it to ApiState every time?
<niemeyer> fwereade__: You know exactly what is going on
<niemeyer> fwereade__: Which is a surprisingly important property
<rogpeppe> i'm not sure i want to change everywhere to pass two things around where we're only talking to one state
<fwereade__> niemeyer, (huh, yeah, my previous comment applies in both places)
<niemeyer> rogpeppe: That's great.. let's try to avoid that by actually finishing that work :)
<rogpeppe> perhaps we could just pass around api.State and have a state.State member
<rogpeppe> so all existing code calls apiState.State.Foo
<niemeyer> rogpeppe: This seems much more hackish to me
<rogpeppe> hmm, but that doesn't work
<niemeyer> rogpeppe: It's pretty much impossible to tell if things you're passing apiState in actually are ported or not, without investigating all calls
<niemeyer> rogpeppe: In general, when something is ported we can actually *port* it
<niemeyer> rogpeppe: Take State out, put api.State in
<niemeyer> (or whatever the name is)
<niemeyer> rogpeppe: and that's it
<niemeyer> rogpeppe: No two states
<niemeyer> rogpeppe: If that's hard to do and there is value in doing it gradually, it seems rather sane to have the two values around
<niemeyer> rogpeppe: so the one variable isn't a big deal
<rogpeppe> niemeyer: ok. in practice, i think that means one big change all at once, but that's probably inevitable really
<niemeyer> rogpeppe: There's no reason for that to be the case
<rogpeppe> niemeyer: because once you start talking to, say, api.Machine, then api.Machine must implement all the relevant state.Machine methods
<niemeyer> rogpeppe: That seems rather orthogonal
<niemeyer> rogpeppe: It's not like any of these approaches would solve it
<rogpeppe> niemeyer: the embedding approach *could*, i think. but it might end up hackish, yeah.
<niemeyer> rogpeppe: That's a great reason not to even try it
<rogpeppe> niemeyer: the hacks would eventually go :-)
<niemeyer> rogpeppe: If we don't put them there, they are already gone right now.. magic! :)
<rogpeppe> niemeyer: ok fair enough, it was just a thought.
<niemeyer> rogpeppe: Sure, always happy to brainstorm
 * fwereade__ lunches
<dimitern> rogpeppe: ping
<rogpeppe> dimitern: pong
<dimitern> rogpeppe: PTAL https://codereview.appspot.com/6906046/
<dimitern> :)
<rogpeppe> dimitern: ah, sorry, looking now.
<rogpeppe> dimitern: um, are you sure that's the right CL?
<dimitern> rogpeppe:  whoops :) no sorry https://codereview.appspot.com/6924043/
<niemeyer> rogpeppe: Hopefully that's the end of the default-series fix: https://codereview.appspot.com/6868070
<rogpeppe> niemeyer: will look after i'm done with dimitern's review
<niemeyer> Super, thanks
<niemeyer> Someone else's review would be appreciated too
<niemeyer> I'll step out for lunch and move to review mode in the afternoon
<jcastro_> niemeyer: heya, whens your next core team call? I have a sort of plan to tackle the docs
<dimitern> jcastro_: I think it's every tuesday at 13 UTC and 22 UTC
<jcastro_> thanks!
<fwereade> jcastro_, fwiw, I have some *very* rough docs in review -- they weren't even really intended as documentation in anything but the loosest sense
<jcastro_> yeah
<fwereade> jcastro_, but if you can see past the crappy aspects, then they are hopefully clear and current, and should be considered a provisional source of truth for (parts of) juju-core
<jcastro_> so right off the bat when reorging them, I think we should have them be in 2 major sections, user docs, and developer docs.
<fwereade> jcastro_, https://codereview.appspot.com/6922051/
<jcastro_> right now they're kind of jumbled together
<fwereade> jcastro_, indeed -- and I'm afraid that the above suffers similarly to a degree
<jcastro_> it's like having to read a physics book to learn how to light your stove, don't care about the guts, I just need fire, and so on.
<fwereade> jcastro_, those who have read the glossary have been generally positive though
<fwereade> jcastro_, it's not super-fluffy but it should be clear
<jcastro_> fwereade: lifecycles.txt is awesome
<fwereade> jcastro_, ty :D
<rogpeppe> niemeyer: LGTM
<jcastro_> fwereade: I think our ecosystem team can easily handle the "using juju" and charm parts. And then have you guys handle the core sections.
<jcastro_> fwereade: it might make us more focused instead of "hey everyone, try to fix the docs."
<fwereade> jcastro_, the trouble is I'm not *really* trying to fix the docs
<fwereade> jcastro_, I wrote a few in-case-I-die braindumps that are pretty useful -- almost documentation -- and they are sliding in that direction almost by accident
<jcastro_> heh
<fwereade> jcastro_, the other problem is that the charm parts in particular have changed in some ways -- which I have tried to capture in charms-in-action -- but that document is not comprehensive
<fwereade> jcastro_, this is less of a big deal than you might think, because AFAWCT charms do tend to work
<jcastro_> that's ok, as long as one of us on ~charmers understands it we can massage it
<rogpeppe> dimitern: replied
<dimitern> rogpeppe: cheers!
<fwereade> jcastro_, jolly good -- I just have to tell you about it somehow then :)
<niemeyer> jcastro_: Team calls are on Tuesday generally
<niemeyer> rogpeppe: Thanks!
<niemeyer>  // Note that ... this comment shouldn't be here!
<fwereade> niemeyer, haha :)
<niemeyer> ;-)
<fwereade> niemeyer, btw, sorry -- I responded to this ancient CL but apparently failed to, er, repropose it
<fwereade> niemeyer, the bug's been marked invalid as failed to repro but I don't see any harm to a laxer timeout anyway
<niemeyer> fwereade: Where's that?
<fwereade> niemeyer, waiting for unit public address to be set on uniter startup
<fwereade> niemeyer, you commented "shouldn't there be a StartSync here"
<niemeyer> fwereade: Ah, indeed
<fwereade> niemeyer, I said "no but yes" and went offf to fix it and decided the answer was actually just "no"
<niemeyer> fwereade: I also failed there.. I recall about a fix I should have sent to make one of those tests more resilient a century ago
<fwereade> niemeyer, at least I'm not alone then, cheers :)
<niemeyer> fwereade: So, why is the answer no, out of curiosity?
<fwereade> niemeyer, because we could use a watcher to detect the change, but we'd have to keep spamming syncs at it
<fwereade> niemeyer, so "watcher + spam syncs" seemed more complex than "poll" and I resolved thatit was better as it was
<niemeyer> fwereade: Ah, sure, I wasn't suggesting that specific change originally
<niemeyer> fwereade: I was suggesting just the StartSync
<niemeyer> fwereade: Which shall reduce the timeout necessary, hopefully
<fwereade> niemeyer, ah, ok -- I think that's not necessary because the uniter's not waiting for anything to set it
<fwereade> niemeyer, it's just about the first thing it does
<fwereade> niemeyer, so, indeed, 5s is generous
<fwereade> niemeyer, but the theory we developed was that it was possibly a rogue canonistack pause and we may as well be resilient to such things
<niemeyer> fwereade: Imagine E is an event we're waiting for, SS in StartSync, R is the time we read the state to see if it's what we expect, and dot (.) is time passing.. if we just loop, it may go like:
<fwereade> niemeyer, (I'm 80% sure it was exposed in one of davecheney's canonistack runs)
<niemeyer> fwereade:  E . R . . . . . . E
<niemeyer> fwereade: With SS, it becomes:    E . SS . E . R
<niemeyer> fwereade: So the global timeout may be shorter..
<niemeyer> fwereade: Actually, it's more clear as
<niemeyer> fwereade:  R .. R .. R .. R ..  R .. E
<niemeyer> vs.
<niemeyer> fwereade:  SS R .. SS E
<niemeyer> Or something like that
<fwereade> niemeyer, ok, I see a nicer way to do it than I had before, just a mo
<niemeyer> Hmm
<niemeyer> Got a failure on
<fwereade> niemeyer, huh, perhaps not
<niemeyer> provisioner_test.go:103:
<niemeyer>     c.Errorf("provisioner did not start an instance")
<niemeyer> ... Error: provisioner did not start an instance
<niemeyer> Anyone seen this before?
<fwereade> niemeyer, does SS do this:
<fwereade> niemeyer, sorry, restate: how long after a call to StartSync will a change not send of a watch channel?
<fwereade> niemeyer, *on* a watch channel
<fwereade> niemeyer, hm, I'm not sure that question makes sense even, bother
<niemeyer> fwereade: Yeah, there doesn't seem to be a definitive answer to it
<fwereade> niemeyer, so, that is my problem
<niemeyer> fwereade: Why does it matter in this case?
<fwereade> niemeyer, I know an event will occur at some future time
<fwereade> niemeyer, butthat any given StartSync's sync may not happen to complete in time to see that change
<niemeyer> fwereade: There's not even a "completion" of StartSync so to speak
<niemeyer> fwereade: (that's the "Start" in it)
<fwereade> niemeyer, ok, so a StartSync causes a sync to occur
<fwereade> niemeyer, and at some stage in the future that sync will complete
<niemeyer> fwereade: Right, it schedules a sync to occur
<niemeyer> fwereade: Yes, in the near future
<fwereade> niemeyer, and after that sync is complete it is unhelpful re detecting future events
<niemeyer> fwereade: Hmm.. that seems to lack context
<niemeyer> fwereade: It may be helpful or not
<fwereade> niemeyer, 5 minutes from now, I will change a unit that you are watching: is it helpful for you to call StartSync now and expect it to deliver the event faster when it does come?
<fwereade> niemeyer, I believe it is not
<niemeyer> fwereade: That's the graph above
<niemeyer> fwereade: Compare this:
<niemeyer> fwereade:  R . . . . . . . . . R . E . . . . . . . R
<niemeyer> fwereade: With this:
<niemeyer> fwereade:  SS R . .  E . . . . . . R
<niemeyer> fwereade: Makes sense?
<fwereade> niemeyer, I'm sorry, I'm not taking your point :(
<niemeyer> fwereade: Sorry.. hmm
<fwereade> niemeyer, as a point of common ground, would you confirm or deny my previous statement re 5-minute waits?
<niemeyer> fwereade: It's false
<niemeyer> fwereade: StartSync is unrelated to the time of the event
<niemeyer> fwereade: It's related to the time of the watch loop instead
<niemeyer> fwereade: We dont' call it to make the event happen faster.. we call it to observe its occurrence faster
<fwereade> niemeyer, yes, I am well aware of this
<niemeyer> fwereade: Okay.. the problem is I think you understand everything I'm saying, so I'm unsure about which piece is missing there or here
<fwereade> niemeyer, I was trying to ask whether the observation delay in an event 5 minutes in the future will be reduced by a call to StartSync now
<fwereade> niemeyer, my understanding is that it will not
<niemeyer> fwereade: It will not, and that's unrelated to the reason why StartSync is suggested
<niemeyer> fwereade: Which is why it's unclear
<fwereade> niemeyer, ok, what do you believe StartSync will speed up?
<niemeyer> fwereade: It speeds up the observation of events when you're polling repeatedly
<niemeyer> fwereade: It makes the time of the poll rule the time of the watcher refreshing
<niemeyer> fwereade: This is all unrelated to how long it will take for the event to actually happen
<fwereade> niemeyer, sorry, phone
<fwereade> niemeyer, ok
<fwereade> niemeyer, I think we may be talking at cross purposes
<niemeyer> fwereade: I'm pretty sure about it :)
<fwereade> niemeyer, when I "poll", I refresh the unit every 50ms and see if it has the address I want
<fwereade> niemeyer, I do not see how startsync factors in here
<fwereade> niemeyer, because none of the events that lead the unit's address to be set are waiting for any watchers
<fwereade> niemeyer, *if* I were to use a unit watcher, then I could maybe avoid any sort of polling -- but actually, if I want events to arrive in a timely way, I need to call StartSync repeatedly
<fwereade> niemeyer, because the sync might complete before the change I'm waiting for actually happens
<fwereade> niemeyer, so I need to start a new sync every, say, 50ms
<fwereade> niemeyer, ...or am I on crack?
<niemeyer> fwereade: No, quite possibly I'm the one off
<niemeyer> fwereade: So is there no watcher in the pipeline towards the expected point?
<fwereade> niemeyer, I'm pretty sure not
<niemeyer> fwereade: Okay, so surely there is no need to refresh the watcher :)
<niemeyer> fwereade: Phew, sorry
<fwereade> niemeyer, no worries, it's a pretty unexpected situation for juju ;)
<niemeyer> fwereade: Yeah :-)
<niemeyer> fwereade: LGTM
<niemeyer> fwereade: Sorry for the confusion
<niemeyer> YouTube is the new radio
<fwereade> niemeyer, np :)
<niemeyer> One of these days I'll make a small app that allows one to type a search statement, and it'll just pick entries out of the list for playing
<niemeyer> It'd also be nice to have a no-video mode to save bandwidth
 * Aram can't listen to lossily compressed audio.
<niemeyer> Aram: Having less hearing accuracy has its advantages :-D
<Aram> I suppose.
 * Aram bought tickets to The Hobbit.
<Aram> I was undecided between IMAX 3D and regular 3D.
<Aram> but I had to chose regular since the IMAX is not available in English.
<rogpeppe> i'm done for the day
<rogpeppe> g'night all
<niemeyer> rogpeppe: Nighty night
 * niemeyer => exercising
#juju-dev 2012-12-13
<davecheney> bzr: ERROR: Cannot lock LockDir(chroot-93404944:///%2Bbranch/gocheck/.bzr/branch/lock): Transport operation not possible: readonly transport
<davecheney> ^ any ideas ?
<davecheney> screw it, hit it with the rm hammer
<davecheney> nope
<davecheney> that hasn't worked either
<wallyworld_> davecheney: i've not seen that issue before, sorry, i'll see if i can find out
<wallyworld_> davecheney: actually, it aappears to be because you may not have write permissions to the gocheck project codebase?
<davecheney> wallyworld_: yeah
<davecheney> i guess I havent' submitted anything to that previously
<davecheney> i've written to gustavo
<wallyworld_> nice easy error message :-)
<TheMue> Morning
<Aram> morning.
<TheMue> Aram: Hi
<jam> hi aram and TheMue
<TheMue> jam: Heya
<rogpeppe> mornin' all
<TheMue> rogpeppe: Morning
<TheMue> Anyone interested in reviewing the Firewaller 2.0? ;) https://codereview.appspot.com/6875053/
<dimitern> rogpeppe, TheMue: morning
<TheMue> dimitern: Hello
<rogpeppe> TheMue: i'm having a look
<TheMue> rogpeppe: Great, thanks.
<rogpeppe> TheMue: line 184: copy(ports, unitd.ports)
<rogpeppe> TheMue: how can that ever work?
<rogpeppe> TheMue: because ports is a zero length slice
<TheMue> rogpeppe: Oh, funnily it works. Have to look into copy().
<rogpeppe> TheMue: it can't do - it will never copy any elements
<rogpeppe> TheMue: so unitd.watchLoop will always be started with no ports
<TheMue> rogpeppe: Good catch, will change.
<rogpeppe> TheMue: make a test that fails before making the change
<TheMue> rogpeppe: Any idea on how that test should look like?
<rogpeppe> TheMue: i haven't looked too deeply, but the question is: why do you start watchLoop with some ports? does it make any difference to the externally visible semantics?
<rogpeppe> TheMue: if it doesn't make a difference, maybe you should just pass nil to watchLoop and delete those two lines
<TheMue> rogpeppe: Has been the result of longer discussions to do every startup with the current state.
<rogpeppe> TheMue: so i guess it'll just set the same ports twice, right?
<TheMue> Ruetobas: Pardon?
<TheMue> Oops
<TheMue> rogpeppe: ???
<TheMue> rogpeppe: Passing them to the watchLoop() just avoids a first change event.
<rogpeppe> TheMue: that's what i mean. won't that first change event trigger a redundant setting of the ports? (i actually meant "i guess it'll just set the ports redundantly")
<TheMue> rogpeppe: Yes, it would do so.
<rogpeppe> TheMue: hmm, and because you don't see environment port-setting events directly, you can't observe the difference
<TheMue> rogpeppe: It's job of the both reconcileXyz() methods to compare the initial state with that of the environment or the instances. And then needed changes are done.
<TheMue> rogpeppe: Everything later is then based on change events.
<TheMue> rogpeppe: And the initial state is taken from the first events of the regarding watchers.
<rogpeppe> TheMue: yes, that all seems fine. i was just wondering on whether it was possible to test that broken code.
<TheMue> rogpeppe: With exporting internal states of the firewaller maybe. But I don't think it's worth it, your capture has been great and it would only demonstrate that you're right. :D
<niemeyer> GOod morning juju-devs
<TheMue> niemeyer: Hiya
<dimitern> niemeyer: morning :)
<rogpeppe> niemeyer: yo!
<TheMue> Lunchtime, BIAB
<TheMue> niemeyer: ping
<niemeyer> TheMue: Hey
<TheMue> niemeyer: Hi, could you please take a look at https://bugs.launchpad.net/juju-core/+bug/1084867 which Mark assigned to me yesterday.
<_mup_> Bug #1084867: conn: conn connections should pause between retry attempts <juju-core:New for themue> < https://launchpad.net/bugs/1084867 >
<TheMue> niemeyer: It's in state.Open() and I've got a question. Regarding mgo.
<TheMue> niemeyer: If I'm right mgo.DialWithInfo() uses a func for dialing, but the timing if it's failing is controlled inside the method. You only may specify a timeout (here 10 minutes). Am I right?
<niemeyer> TheMue: Where are the messages in that bug being printed?
<niemeyer> TheMue: That code must necessarily be repeated for the message printing to be repeated, right?
<TheMue> niemeyer: In the func passed to DialWithInfo()
<TheMue> niemeyer: Yes, until the conn is established or the timeout happens.
<TheMue> niemeyer: Is there a fixed time between those retries?
<niemeyer> TheMue: There are retries, there are timeouts, there are delays
<TheMue> niemeyer: Yes. IMHO Dave recomments a kind of exponential delay behavior. Alternatively to static delays.
<TheMue> niemeyer: But maybe I misunderstand the comment.
<niemeyer> TheMue: Yes, I can see in the bug that he recommends that
<niemeyer> TheMue: Where is the repetition happening, for how long does it repeat quickly, how long does it wait until the quick repetitions?
<TheMue> niemeyer: Sorry, no more details so far than written in the issue. So I'll try to talk to Dave tomorrow morning. Just wanted to know first if I'm missing something about the mgo dialing behavior.
<niemeyer> TheMue: You don't have to talk to Dave, you have to understand the problem instead
<TheMue> niemeyer: And will start some test runs here.
<niemeyer> TheMue: Sorry, I definitely don't intend to sound harsh, but you have to do your home work when a bug is assigned to you
<TheMue> niemeyer: No problem.
<niemeyer> TheMue: This sounds like a trivial problem of a missing delay in the right place
<TheMue> niemeyer: This would have been the next where I would have talked to you about. Such a kind of delay is possible in the dial func, but it may also be interesting for you as the creator of mgo to make it configurable via DialInfo in a next release.
<niemeyer> TheMue: Where is the repetition happening? Who's dialing so quickly?
<niemeyer> TheMue: You seem to have no idea
<niemeyer> TheMue: Putting sleeps in the code when you have no idea about exactly how work is taking place is a terrible plan
<niemeyer> TheMue: It can be in mgo, it can be in Open, it can be in the call site of Open, etc
<niemeyer> TheMue: You have the whole code base at your hand
<TheMue> niemeyer: It looks to me that the dial func passed to DialWithInfo() is repeated quickly. Am I right? It contains no own loop. And it is passed to DialWithInfo with the DialInfo.
<niemeyer> TheMue: Exactly.. it contains no loop.. things that contain no loop do not lead to repetition
<niemeyer> TheMue: How can it possibly be repeated?
<niemeyer> TheMue: Staring at it and wondering how to control repetition is going to be ineffective
<TheMue> niemeyer: It returns an error and no connection, so DWI() retries.
<niemeyer> TheMue: Where?
<TheMue> niemeyer: Aaargh, I think I've got it.
<TheMue> niemeyer: I'm currently walking the call tree upwards.
<TheMue> niemeyer: Have been too fixed on that Open().
<niemeyer> TheMue: Don't guess.. put debug statements in, watch the timings, watch call traces
<TheMue> niemeyer: Yes, will do so.
<niemeyer> Three branches off the queue.. 10 to go
<niemeyer> Lunch first, though
<niemeyer> rogpeppe2: https://codereview.appspot.com/6902070/ is reviewed
<niemeyer> rogpeppe2: Either I'm on crack, or the logic there isn't entirely sound
<rogpeppe> niemeyer: you may well be right. let me check.
<rogpeppe> niemeyer: the first add is because we can't do an add before the websocket handler function is invoked
<rogpeppe> niemeyer: the websocket handler uses a different goroutine for each call (like the http server)
<niemeyer> rogpeppe: Yeah, even then it doesn't seem entirely okay
<niemeyer> rogpeppe: There are four different goroutines there
<niemeyer> rogpeppe: With adds all around
<niemeyer> rogpeppe: and it's not clear why
<niemeyer> rogpeppe: There is also a channel blocking at the end of each handled connection, which also doesn't sound okay
<rogpeppe> niemeyer: we need to wait until everything has cleaned up before dying
<niemeyer> rogpeppe: We need to do a lot of things
<niemeyer> rogpeppe: But that doesnt' mean we need a new goroutine for each one of those things
<rogpeppe> niemeyer: i'm not sure how to avoid the goroutines
<niemeyer> rogpeppe: I suggest starting from the principle that you don't need them, rather than from the principle that you do need them
<rogpeppe> niemeyer: the only way to get the http listener to quit is to close its Listener
<niemeyer> rogpeppe: Also note how run(lis) never returns an error, despite the fact it has an error return.. which means the outside goroutine, doing a Kill, never does it
<niemeyer> rogpeppe: There's surprisingly little logic for that ton of logic
<rogpeppe> niemeyer: yes, run never returns an error, because the error that it almost always gets is "use of closed listener"
<rogpeppe> niemeyer: (if we used the error from http.Serve, that is)
<niemeyer> rogpeppe: Sorry, I'm not sure I understand what you mean
<rogpeppe> niemeyer: what error could Server.run return?
<niemeyer> rogpeppe: Things that never return an error should not have an error return, and the error return from things that never return an error should not be used
<niemeyer> rogpeppe: Both of these are false
<niemeyer> In the branch
<rogpeppe> niemeyer: that's true. i should probably remove the error return from run
<niemeyer> rogpeppe: Yes, that's a start
<niemeyer> rogpeppe: What about that blocking channel at the end of every single handled connection?
<rogpeppe> niemeyer: hmm, yes, that does seem a bit crackful
<rogpeppe> niemeyer: i think it needs to be a select
<rogpeppe> niemeyer: and wait for the st.run() to finish as well as the dying tomb
<niemeyer> rogpeppe: Why? Why do we have a goroutine being created within the per-connection goroutine?
<rogpeppe> niemeyer: i'm not sure i can use any less goroutines though
<rogpeppe> niemeyer: because we need somewhere to wait for the dying tomb
<rogpeppe> niemeyer: so that we can kill the connection
<niemeyer> rogpeppe: One of the reasons why we have a tomb is precisely to not shut the door on running logic
<rogpeppe> niemeyer: we're not shutting the door on running logic, we're waiting for websocket.JSON.Receive to receive an EOF, and quit the run loop
<rogpeppe> niemeyer: that's the only way to terminate that run loop AFAIK
<niemeyer> rogpeppe: That's not what conn.Close does
<rogpeppe> niemeyer: what does it do?
<niemeyer> rogpeppe: It closes the connection, doesn't it?
<niemeyer> rogpeppe: Irrespective of whatever is going on within the goroutine
<rogpeppe> niemeyer: yes. hmm, that will stop replies being sent, yesah
<rogpeppe> niemeyer: there probably needs to be something so that we can tell when the message receiver is blocked on a message receive.
<rogpeppe> niemeyer: (pity we can't half-close the connection)
<rogpeppe> niemeyer: perhaps before it does a message receive, it could send the connection to another goroutine which will close it if it sees Dying.
<rogpeppe> niemeyer: once it's got the message, it can ask for the connection back again
<rogpeppe> niemeyer: it would still be the same number of goroutines, but the receiver would be more in control.
<niemeyer> rogpeppe: The point isn't closing, I think.. the point is stopping and returning.. Close can be deferred on spot
<niemeyer> func(conn ...) {
<niemeyer>     defer conn.Close()
<niemeyer> }
<rogpeppe> niemeyer: the loop in run is blocked on receive. someone calls Server.Stop. how do we stop the run loop?
<niemeyer> rogpeppe: Exactly..
<niemeyer> rogpeppe: That's the issue we must solve: how to stop and return.. that decision must be taken with context, unlike what's being done right now
<rogpeppe> niemeyer: i think closing the conn is the only way to do that
<rogpeppe> niemeyer: but you're right that it shouldn't be done outside of run
<niemeyer> rogpeppe: Of course not.. that's taking a cheap route from outside to knock logic we don't control down
<rogpeppe> niemeyer: ok, so how do we get the run loop to unblock, if we can't close the conn?
<niemeyer> rogpeppe: "if we can't close the Conn" is a red-herring
<niemeyer> rogpeppe: Where would you close the Conn?  That's where you get the loop to unblock
<niemeyer> rogpeppe: You don't want to close the Conn without context
<rogpeppe> niemeyer: we need to close the conn *somewhere* right?
<niemeyer> <niemeyer> rogpeppe: The point isn't closing, I think.. the point is stopping and returning.. Close can be deferred on spot
<niemeyer> <niemeyer> func(conn ...) {
<niemeyer> <niemeyer>     defer conn.Close()
<niemeyer> rogpeppe: That's where you close the Conn
<rogpeppe> niemeyer: i don't understand that code without further context
<niemeyer> rogpeppe: handler := websocket.Handler(func(conn *websocket.Conn) { defer conn.Close()
<niemeyer> rogpeppe: The connection must be closed when the handler is done running
<niemeyer> rogpeppe: We don't close the connection to interrupt.. we interrupt to close the connection
<rogpeppe> niemeyer: how can that work? the handler blocks receiving a message. if it's blocked receiving a message, how can it know that the server has been killed?
<niemeyer> rogpeppe: That's the right question
<niemeyer> rogpeppe: Answering it is what we must find out
<rogpeppe> niemeyer: we could receive messages in a separate goroutine
<niemeyer> rogpeppe: That's not solving the problem
<rogpeppe> niemeyer: (that's still the same number of goroutines though)
<rogpeppe> niemeyer: isn't it?
<niemeyer> rogpeppe: We can have 10 goroutines.. we still must find a way to interrupt in the right spot
<rogpeppe> niemeyer: i mean we could read messages in a goroutine, and send them on a channel.
<rogpeppe> niemeyer: then select on that channel and Dying.
<niemeyer> rogpeppe: It's not.. you're saying "we can move the problem to a separate goroutine".. surely we can. The problem is still in the other goroutine, though.
<rogpeppe> niemeyer: we can't do it with one goroutine. period.
<niemeyer> rogpeppe: That's an irrelevant invariant.. we should look for the solution, rather than how many goroutines we need to put an untold solution in place.
<rogpeppe> niemeyer: this would work, but you'll probably think it's messy: http://paste.ubuntu.com/1430008/
<niemeyer> rogpeppe: How does conn.SetDeadline work?
<rogpeppe> niemeyer: i think it hooks into net.TCPConn.SetDeadline, but i'll check
<niemeyer> rogpeppe: It does.. but what happens when the deadline expires?
<rogpeppe> niemeyer: you get an error that satisfies IsTimeout (IsTemporary?) AFAIR
<niemeyer> rogpeppe: Sure, but the interesting question is what happens to the connection itself and the data that was being received when that takes place
<rogpeppe> niemeyer: i *think* it may be left intact. but i don't think that helps us.
<rogpeppe> niemeyer: if something is doing a ReadFull and it gets a temporary error, it is likely to be fatal
<niemeyer> rogpeppe: Yeah, it'd likely introduce that kind of weird issue indeed
<rogpeppe> niemeyer: something like this is fairly clean: http://paste.ubuntu.com/1430030/
<rogpeppe> niemeyer: then the close can go in the function as you suggest
<niemeyer> rogpeppe: Yeah, that looks like a nice directoin
<niemeyer> rogpeppe: The error must be taken care of, etc, but looks nice
<rogpeppe> niemeyer: that's what i was thinking of when i said
<rogpeppe> [16:38:48] <rogpeppe> niemeyer: i mean we could read messages in a goroutine, and send them on a channel.
<rogpeppe> [16:39:02] <rogpeppe> niemeyer: then select on that channel and Dying.
<rogpeppe> niemeyer: i'm not sure what the best thing to do with the errors is though
<rogpeppe> niemeyer: we don't want to take the whole server down because a single client sends an bogus request
<niemeyer> rogpeppe: Indeed, I guess that's fine
<rogpeppe> niemeyer: i think that a simple log message might be the best way
<niemeyer> rogpeppe: +1
<rogpeppe> niemeyer: https://codereview.appspot.com/6902070
<niemeyer> rogpeppe: srv.run still returns an error that is never used.. its result is still used on Kill despite the fact it never changes
<rogpeppe> niemeyer: ah, i'd forgotten that. will remove.
<niemeyer> rogpeppe: Add and Done within websocket.Handler is still very awkward
<rogpeppe> niemeyer: yes
<rogpeppe> niemeyer: got a better solution?
<niemeyer> rogpeppe: It is pretty much never sensible to call those in the same goroutine
<rogpeppe> niemeyer: unfortunately we don't have control over the moment that http starts a new goroutine AFAIK
<rogpeppe> niemeyer: i'm pretty sure my ErrStillAlive check makes the logic sound, but it is definitely awkward.
<niemeyer> rogpeppe: Where is Wait?
<rogpeppe> niemeyer: ha
<rogpeppe> niemeyer: i'm sure it used to be *somewhere* :-)
<rogpeppe> niemeyer: i was contemplating putting in a long-running request (some kind of waiter, perhaps) so that i could test these issues better
<niemeyer> rogpeppe: Why do we need that goroutine at the start of run?
<rogpeppe> niemeyer: it's either that or http.Serve
<rogpeppe> niemeyer: hmm, and since we're not using the error returned by http.Serve, maybe we should just do "go http.Serve(...)"
<rogpeppe> niemeyer: oh, but we can't
<rogpeppe> niemeyer: it would look just the same as the other go statement
<niemeyer> rogpeppe: Why?
<niemeyer> rogpeppe: Why?
<rogpeppe> niemeyer: we want to block until it's completed, i think
<niemeyer> rogpeppe: Indeed, sounds like a good idea
<niemeyer> rogpeppe: This also sounds a bit bogus, btw:
<niemeyer> 	  71 Â»       Â»       // If we've got to this stage and the tomb is still
<niemeyer>   72 Â»       Â»       // alive, we know that any tomb.Kill must occur after we
<niemeyer>   73 Â»       Â»       // have called wg.Add, so we avoid the possibility of a
<niemeyer>   74 Â»       Â»       // handler goroutine running after Stop has returned.
<rogpeppe> niemeyer: PTAL (waitgroup added)
<niemeyer> rogpeppe: Stop won't return before Done is called
<niemeyer> rogpeppe: and we should not call Done while there's stuff running in background.. that's the invariant on tomb
<rogpeppe> niemeyer: that's fine
<niemeyer> rogpeppe:
<niemeyer>   47 Â»       go func() {
<niemeyer>   48 Â»       Â»       defer srv.tomb.Done()
<niemeyer>   49 Â»       Â»       srv.run(lis)
<niemeyer>   50 Â»       }()
<niemeyer> rogpeppe: How about go srv.run(lis)?
<niemeyer> rogpeppe: The Done there isn't right
<rogpeppe> niemeyer: the Tomb.Done in the above code?
<niemeyer> rogpeppe: Sorry, I guess it is now that you've added wg.Wait
<rogpeppe> niemeyer: i *think* it's ok
<niemeyer> rogpeppe: Still, we don't need a closure just to call a function
<rogpeppe> niemeyer: good point.
<rogpeppe> niemeyer: it was nice when it was returning an error, but now a bit redundant
<rogpeppe> niemeyer: will make smaller
<niemeyer> rogpeppe: Agreed on both points
<niemeyer> rogpeppe: Line 152 will wedge on Dying
<rogpeppe> niemeyer: argh, yes. it probably needs to select on dying too
<rogpeppe> niemeyer: alternatively, we could close the conn and wait for readRequests to die, which might be cleaner.
<rogpeppe> niemeyer: at least then we know we've cleaned up *all* resources
<niemeyer> rogpeppe: closing under a sender?
<rogpeppe> niemeyer: no
<rogpeppe> niemeyer: http://paste.ubuntu.com/1430107/
<niemeyer> rogpeppe: Doesn't look cleaner
<niemeyer> rogpeppe: That means we'll have to Close twice, and wait for messages we don't care about just to unblock the other side
<rogpeppe> niemeyer: it's cleaner in that no log messages can be produced after the server has been stopped
<rogpeppe> niemeyer: i don't think we'll have to close twice
<niemeyer> rogpeppe: So that paste already has a bug
<niemeyer> rogpeppe: There are two returns.. one of them doesn't close the connection
<rogpeppe> niemeyer: that's right
<niemeyer> rogpeppe: !?
<rogpeppe> niemeyer: does that invalidate the general approach?
<niemeyer> rogpeppe: Sorry, I'm a bit lost.. it's right to not close the connection?
<rogpeppe> niemeyer: no. but the piece i was trying to demonstrate was the bit that closes the connection and waits for the readRequests goroutine to finish
<niemeyer> rogpeppe: All of the comments above were made about this
<rogpeppe> niemeyer: i think this is different, as the readRequests goroutine has no side effects
<rogpeppe> niemeyer: (this is a slightly different phrasing of the idea: http://paste.ubuntu.com/1430129/)
<niemeyer> rogpeppe: I have no idea about what side effects has to do with the above points
<niemeyer> rogpeppe: Either the paste had a missing Close, or it was Closing twice
<rogpeppe> niemeyer: oh, sorry, i thought you were referring to much earlier comments
<rogpeppe> niemeyer: "above" is, erm, ambiguous, in IRC context :-)
<niemeyer> rogpeppe: You said it doesnt
<rogpeppe> niemeyer: i said it doesn't what?
<niemeyer> rogpeppe: So I don't know what you have in mind.. either way, all of that makes it sound like a bad idea.
<niemeyer> <rogpeppe> niemeyer: i don't think we'll have to close twice
<rogpeppe> niemeyer: did you look at my most recent paste?
<niemeyer> rogpeppe: No, I'm still trying to understand what we're talking about
<niemeyer> rogpeppe: We're clearly talking across each other
<niemeyer> rogpeppe: And looking at more pastes won't help
<rogpeppe> niemeyer: you were concerned about readRequests blocking forever when run returns, right?
<niemeyer> rogpeppe: I made a very specific statement, saying that there was a missing Close or that it was closing twice
<niemeyer> rogpeppe: You said "I don't think so", and didn't explain why, and ignored further comments
<rogpeppe> niemeyer: my paste was supposed to be an explanation, sorry
<rogpeppe> niemeyer: and the most recent paste shows how we can close once only, and reliably.
<niemeyer> rogpeppe: Your different paste has different logic, and ignores my questioning
<niemeyer> rogpeppe: "Yes, I wanted it to close twice"; "Yes, there was a bug".. those are all trivial to say
<niemeyer> rogpeppe: and keep us on the same page
<rogpeppe> niemeyer: your only question has been "it's right not to close the connection?"
<rogpeppe> niemeyer: which sounds rhetorical to me - of course it's not right not to close the connection
<niemeyer> rogpeppe: Sorry, that's not working at all
<niemeyer> rogpeppe: I make a comment, and you say I'm wrong, and ignore it, and then say it's obvious that I'm right
<niemeyer> rogpeppe: Just send the code you think is right for review then
<rogpeppe> niemeyer: will do
<rogpeppe> niemeyer: PTAL https://codereview.appspot.com/6902070
<niemeyer> rogpeppe: Done
<rogpeppe> niemeyer: you're probably right that it's not worth saving one allocation per message :-)
<rogpeppe> niemeyer: i wondered if you'd jump on that
<niemeyer> rogpeppe: There's no allocation being saved in either case
<niemeyer> rogpeppe: Both send the address of a local variable across to another function, and both send a copy of it over the channel. There's no reason for one to allocate and the other not.
<rogpeppe> niemeyer: i think that the pointer passed to json.Unmarshal counts as escaping, so the local variable will be allocated each time round the loop
<niemeyer> rogpeppe: See above
<rogpeppe> niemeyer: it makes a difference if the variable is declared inside or outside the loop
<rogpeppe> niemeyer: if it's declared outside, it will be allocated only once for the lifetime of the function
<rogpeppe> niemeyer: if it's declared inside, it will be allocated each time it comes into scope (because it escapes)
<rogpeppe> niemeyer: but still, it's only one allocation out of many, who cares? :-)
<niemeyer> rogpeppe: Doesn't sound correct.. "escaping" is not defined by looping
<niemeyer> rogpeppe: If you call f(&foo), the question is whether f keeps &foo or not
<rogpeppe> niemeyer: no, "escaping" is defined by being passed to json.Unmarshal, in this case
<niemeyer> rogpeppe: But really, it doesn't matter
<niemeyer> rogpeppe: Yep, which both do
<niemeyer> rogpeppe: I don't care, though.. this branch has been reviewed enough, and that's an early optimization anyway
<rogpeppe> niemeyer: true
<rogpeppe> niemeyer: i'll go with that
<rogpeppe> niemeyer: for illustration: http://play.golang.org/p/9vsPOfjOmJ
<niemeyer> rogpeppe: That's totally unrelated to escape analysis.. both are escaping.
<rogpeppe> niemeyer: it illustrates the difference between the old version of the code and the new version of the code
<rogpeppe> niemeyer: with "escape" standing in for some function that lets its argument escape
<rogpeppe> niemeyer: (in our case JSON.Receive)
<niemeyer> rogpeppe: Sure, I misunderstood what you meant.. it's obvious that it'll do more allocation *IF IT ESCAPES*
<niemeyer> rogpeppe: <niemeyer> rogpeppe: If you call f(&foo), the question is whether f keeps &foo or not
<rogpeppe> niemeyer: sure. and i'm absolutely certain that the argument the JSON.Unmarshal will escape. so we will allocate more.
<rogpeppe> niemeyer: well, to be more accurate:
<rogpeppe> niemeyer: the compiler can't tell that the argument doesn't escape
<niemeyer> rogpeppe: There's zero intrinsic reason for it to escape
<niemeyer> rogpeppe: Since it's side-effects free
<niemeyer> rogpeppe: But.. I don't mind either way. Glad we've cleared the issue, though, thanks.
<rogpeppe> niemeyer: yes, but it goes into reflect-based code, so the compiler throws up its hands and says "i dunno"
<niemeyer> rogpeppe: Quite possibly
<rogpeppe> niemeyer: just checked: http://play.golang.org/p/Wz7Z94cKaV
<niemeyer> rogpeppe: Nice, feel free to revert the code if you want.
<rogpeppe> niemeyer: submitted, thanks for the very useful review
<niemeyer> rogpeppe: My pleasure
<rogpeppe> niemeyer: time for me to go.
<rogpeppe> niemeyer: and i guess we won't be seeing you for a little while
<rogpeppe> niemeyer: good luck with everything!
<rogpeppe> niemeyer: (i'm off tomorrow BTW)
<niemeyer> rogpeppe: Ahh, cool, enjoy the holiday, and see you soon
<niemeyer> rogpeppe: I'll certainly be around every now and then
<rogpeppe> g'night all
#juju-dev 2012-12-14
<davecheney> soooo much better
<davecheney> http://paste.ubuntu.com/1433970/
<TheMue> Morning
<fwereade> TheMue, heyhey
<TheMue> fwereade: Can't see you, you are not here. ;)
<TheMue> fwereade: Morning. :)
<TheMue> fwereade: Thought you're on vacation today?
<fwereade> TheMue, kinda sorta -- I need to do a half day today to catch up with monday when I took an uncheduled one
<fwereade> TheMue, I haven't quite decied whether I'm "really" working this morning yet though
<fwereade> ;)
<TheMue> fwereade: Hehe, here sometimes typical office jobs have more clear constraints.
<fwereade> TheMue, ok, just popping out, sent another comment on the FW
<TheMue> fwereade: Just seen it, thanks. Enjoy your day.
<dimitern> mgz: ping
<wallyworld_> dimitern: can you hear me?
<dimitern> wallyworld_: no
<TheMue> *lol*
<mgz> dimitern: hey
<dimitern> mgz: mumble?
<mgz> I'm on.
<Aram> hello.
<TheMue> Aram: Hi
<niemeyer> Mornings!
<dimitern> niemeyer: morning
<TheMue> niemeyer: Hiya
<TheMue> So, lunchtime. BIAB
<fwereade> morning everyone
<niemeyer> TheMue: ping
<fwereade> niemeyer, in case TheMue's still at lunch, I was wondering a bit about EnsureSubordinate naming
<niemeyer> fwereade: Heya
<niemeyer> fwereade: Are you working or on holiday today?
<fwereade> niemeyer, catching up a half day I took off unscheduled on monday
<niemeyer> fwereade: Just to see how much I can bother you ;_)
<fwereade> niemeyer, I am eminently botherable :)
<niemeyer> ROTFL
<niemeyer> fwereade: Cool, let's see naming first then :)
<fwereade> niemeyer, EnsureSubordinate is, in my mind, a sensible contraction of EnsureHasSubordinateIfThatIsSensible
<niemeyer> fwereade: Agreed, not trying to explain it all there
<fwereade> niemeyer, for some reason EnsureHasSubordinate feels, er, a bit different
<niemeyer> fwereade: The clarity I was aming for is that foo.EnsureBarer generally ensures that foo is a barer
<niemeyer> fwereade: It feels awkward to call out ru.EnsureSubordinate() when ru must necessarily not be a subordinate
<fwereade> niemeyer, yeah, that makes sense -- I was also pondering EnsureSubordinateState at one point, but that didn't seem quite clear either
<niemeyer> fwereade: To be honest, I think ru.CreateSubordinate would be best
<niemeyer> fwereade: Returning ErrSubordinateExists or ErrSubordinateInvalid
<fwereade> niemeyer, I was just about to suggest those :)
<niemeyer> fwereade: Hah, jinx then :)
<TheMue> niemeyer: Pong, just had to bring my daughter to her voluntary work.
<fwereade> niemeyer, that's great then -- grab me when you're done with TheMue then?
<niemeyer> TheMue: Nice.. does she work voluntarily on the voluntary work? :-)
<niemeyer> TheMue: I'll need some extra time to look over the logic on the branch actually
<fwereade> niemeyer, hah, when I was at school, there was an institution called "voluntary tea" on friday afternoons
<fwereade> niemeyer, no, it was not voluntary :/
<niemeyer> TheMue: I'm just going over the firewaller change
<TheMue> niemeyer: Hehe, yes, it's for bridging the time until her education as occupational therapist.
<niemeyer> fwereade: Hehe, that's how it generally goes :-)
<TheMue> niemeyer: Ah, fine, has been a lot of discussion by fwereade and me in there.
 * fwereade hopes he hasn't been leading TheMue up the garden path
<fwereade> niemeyer, a thought is squatting toadlike in my brain, and while I don't like it very much it will not leave peacefully
<fwereade> niemeyer, I don't think that CreateSubordinate actually deserves an independent existence -- it'd only ever be called just after EnterScope, and it depends on basically the same things... I can't think of a good reason not to roll CS into ES
<niemeyer> fwereade: Sounds good as well.
<fwereade> niemeyer, ok, great, I'll have a go at that -- and that then means the errors collapse back down to ErrCannotEnterScope, I think
<fwereade> niemeyer, it will also demand a RelationUnit.Subordinate method, I think, but I don't need that quite yet (in fact I will only want it for testing)
<fwereade> niemeyer, anyway I will try it out and let you know how it goes
<fwereade> niemeyer, oh: crack check: I shouldn't bother to check related service life state because, if the relation is alive, both its services must also be alive
<niemeyer> fwereade: Hmm.. good point
<fwereade> niemeyer, (and, yay, that is a statement of truth not just of intent)
<fwereade> niemeyer, cool, cheers
<fwereade> niemeyer, just in case, do you know if anyone knows what next spring's UDS dates will be?
<niemeyer> fwereade: Not yet.. have you checked the UDS website?
<fwereade> niemeyer, all it seems to have is copenhagen
<niemeyer> TheMue: Review sent
<TheMue> niemeyer: Great, thanks.
<niemeyer> TheMue: np, please let me know if it makes sense
<niemeyer> Heading to lunch now
<TheMue> niemeyer: Yes, first look is fine, just started to adopt it. For the approach we have to thank William and his steadiness. It has been a great help.
<TheMue> niemeyer: Enjoy your luch.
<fwereade> TheMue, a pleasure, thanks for your patience, I'm not sure I was always very clear :)
<TheMue> fwereade: It has been fine to tame this pretty nice beast, a good experience.
<mgz> is there a neat way to run a single live test? I'm failing at finding the right go test spelling.
<Aram> -gocheck.f <regexp>
<Aram> where regexp matches the test function name.
<Aram> mgz: ^ ^
<mgz> ah, that was it, need to remember -gocheck not -test flags
<mgz> thanks Aram
<Aram> cheers.
<mgz> okay, fixing this bug the way I would like will be annoying
<mgz> ideally I'd write a way in the goamz fake server thing that reproduced this behaviour, so running the problematic live test failed in the correct manner, then fix the live test itself
<mgz> but that's two different projects and custom behaviour for a specific test...
<TheMue> So, AFK again.
<fwereade> niemeyer, rolled subordinate creation into EnterScope in https://codereview.appspot.com/6906046/
<fwereade> niemeyer, (I also addressed your comments in https://codereview.appspot.com/6845120/ -- I would love it if you had a moment to take a look before you depart...)
<fwereade> TheMue, a second look at https://codereview.appspot.com/6906046/ would be appreciated: it's changed pretty significantly since you saw it last
<niemeyer> fwereade: Yo
<niemeyer> fwereade: Will look at both
<niemeyer> Now
<niemeyer> fwereade: "This'd be Unit.EnsureDead's job, but it doesn't do it."
<niemeyer> fwereade: Should we adapt comments in the respective places so they reflect what we want to happen then?
<fwereade> niemeyer, yeah, that's a good idea
<fwereade> niemeyer, I thought of that just after I submitted :/
<niemeyer> fwereade: Super
<niemeyer> fwereade: "Nothing -- but it was a single-use method that I factored back into the single
<niemeyer> caller... and then forgot to delete."
<niemeyer> fwereade: So the method is now unused?
<fwereade> niemeyer, isn't it gone in that CL?
<fwereade> niemeyer, ah, yes, it is deleted now
<fwereade> niemeyer, yeah
<niemeyer> fwereade: Cool, sounds good then
<niemeyer> fwereade: I think there was some misunderstanding regarding the name
<niemeyer> fwereade: I was suggesting isAliveDoc for the bson.D document
<fwereade> niemeyer, oh, sorry?
<fwereade> niemeyer, ha!
<fwereade> sorry
<niemeyer> fwereade: np
<niemeyer> fwereade: and isDeadDoc, respectively
<fwereade> niemeyer, notDeadDoc I presume
<niemeyer> fwereade: Ugh, yes
<fwereade> niemeyer, sgtm
<niemeyer> fwereade: Nice to see how much simpler the logic is since we don't have to consider errors
<niemeyer> fwereade: I mean, we don't have to figure what happened to return the proper error
<fwereade> niemeyer, isn't it-- although EnterScope is some where near the edge my comfortable-complexity limit
<niemeyer> fwereade: Indeed, it's probably the most complex function we have in state ATM
<fwereade> niemeyer, at least I can't think of any others that'll be that bad
<niemeyer> fwereade: Agreed. And the logic is also readable, I think
<niemeyer> fwereade: Perhaps requiring some context, though
<fwereade> niemeyer, ah, I tried to do that :(
<niemeyer> fwereade: Should LeaveScope kill the subordinate unit?
<fwereade> niemeyer, nope, don't think so -- it has an independent existence and agent and its own shutdown sequence
<fwereade> niemeyer, setting the prinicpal to dying should do the same to its subordinates, and then we should just sit back and wait
<niemeyer> fwereade: Hmm..
<niemeyer> fwereade: What kills the unit when the relation is departed then?
<fwereade> niemeyer, good point
<fwereade> niemeyer, I still don't think it's LeaveScope's job
<fwereade> niemeyer, I think if anything that a subordinate unit should also be watching for its relation's death
<fwereade> niemeyer, s/death/Dying/
<fwereade> niemeyer, just as all units do with their services
<niemeyer> fwereade: Sounds sensible, but isn't LeaveScope precisely the final cue that the relation is gone?
<niemeyer> fwereade: Perhaps the action should take in the subordinate, though, rather than the principal
<niemeyer> s/take/be taken/
<niemeyer> fwereade: Perhaps not.. if the relation is removed earlier the subordinate will never enter it
<fwereade> niemeyer, yeah, I'm still thinking it through
<fwereade> niemeyer, in general LeaveScope happens pretty late though
<fwereade> niemeyer, I think I'd like the subordinate agents to start clearing themselves up at the right point independently of what the principal does
<niemeyer> fwereade: Sure, but let's think about a worse case scenario
<niemeyer> fwereade: It's entirely possible that by the time the subordinate unit runs, the relation doesn't even exist anymore
<niemeyer> s/worse/worst/
<niemeyer> fwereade: Right?
<niemeyer> fwereade: +1 on your last comment
<fwereade> niemeyer, yeah, you're right
<fwereade> niemeyer, this is a dependency I had not hitherto considered :/
<niemeyer> fwereade: I think it's all good, though.. we just need specific logic in the subordinate unit agent that observes the right moment to suicide
<fwereade> niemeyer, yeah, indeed -- it's just that there's no very obvious way to be sure which relation the subordinate exists as a consequence of
<fwereade> niemeyer, I *think* the easiest way to handle that is to tag subordinate units with the relation ID they exist because of
<fwereade> niemeyer, but that has not been thought through with any rigour
<niemeyer> fwereade: Every subordinate unit has a principal field
<niemeyer> fwereade: Either there must be a relation with that unit, or its life is compromised
<niemeyer> A container relation, specifically
<fwereade> niemeyer, true -- so we *can* figure out the two services involved, and thereby figure out the relation, maybe-probably, because I am suspicious of what happens if that relation is discarded and recreated
<fwereade> niemeyer, IMO an additional field meaning "this unit's life is also contingent on that of this relation" feels like a more certain way to do it
<niemeyer> fwereade: That'd probably be a situation in which it'd be fine for the unit to stay around
<niemeyer> fwereade: That'd open the potential for other races, though
<niemeyer> fwereade: Such as having two subordinate units
<fwereade> niemeyer, *probably*, yeah, but it's the sort of chain of suppositions that I am suspicious of
<niemeyer> fwereade: For the same service
<fwereade> niemeyer, I don't *think* that can happen
<fwereade> niemeyer, but I am not willing to swear that there will be no surprising consequences
<fwereade> niemeyer, I would prefer to keep the chains of logic as short as possible
<niemeyer> fwereade: Sounds good, but I'm not sure of what you mean by that
<fwereade> niemeyer, principal -> principal's service -> figure out the relation
<fwereade> niemeyer, vs
<fwereade> niemeyer, relation
<fwereade> niemeyer, there are a lot more opportunities for bugs in the former
<fwereade> niemeyer, given two services we cannot necessarily uniquely determine the relation between them
<fwereade> niemeyer, but, ha, that's enough to sink my proposal
<fwereade> niemeyer, there's nothing stopping us having two distinct container relations between the same two services, is there?
<fwereade> niemeyer, not that that's a *nice* thing to do
<niemeyer> fwereade: Nope
<niemeyer> fwereade: I think it's a fine thing to do
<niemeyer> fwereade: For the same reason that it's fine to have more than one relation between arbitrary services
<fwereade> niemeyer, indeed so
<fwereade> niemeyer, ok, maybe you're right
<niemeyer> fwereade: Either way, I'm vaguely convinced that being able to ask whether two named units are part of a common relation must not be a hard question
<fwereade> niemeyer, if *any* Alive container relation exists between the subordinate's service and its principal, the subordinate should be Alive
<niemeyer> fwereade: Given that a uniter already maintains tight control of remote participant units on any given relation
<niemeyer> fwereade: That's right
<fwereade> niemeyer, I think that's a subtly different question
<niemeyer> fwereade: Ah, you're right, yes
<niemeyer> fwereade: It doesn't really matter whether the relation is established or not
<niemeyer> fwereade: It matters if it exists
<fwereade> niemeyer, yeah, exactly
<fwereade> niemeyer, but, still, I think it's less hard than I feared two minutes ago
<niemeyer> fwereade: Yeah, thinking in terms of a database query, it's "foo:.* bar:.*" || "bar:.* foo:.*" exist and is alive
<fwereade> niemeyer, (and, fwiw, this CL is very firmly focused on creation rather than removal -- subordinates we can't delete are suboptimal but (?) on par with python)
<niemeyer> exists
<fwereade> niemeyer, yep, exactly
<niemeyer> fwereade: I know.. it's approved already
<fwereade> niemeyer, ah, nice :)
 * fwereade can be slow at times
<niemeyer> fwereade: I just raised the issue as a brainstorm for future steps
<fwereade> niemeyer, yeah, much appreciated
<fwereade> niemeyer, but we're agreed that it's not LeaveScope then? (the only bug I am aware of in LeaveScope is that it doesn't delete services when it needs to)
<niemeyer> fwereade: Yeah, agreed
<fwereade> niemeyer, perfect
<niemeyer> fwereade: next one is good to go too
<fwereade> niemeyer, sweet :D
<niemeyer> TheMue: https://codereview.appspot.com/6875053/ reviewed too
<fwereade> niemeyer, would you expand a little on "deploying agent" vs "deploying unit" -- my heart still favours the first
<fwereade> niemeyer, (I'm fine changing it, I'm just not sure why :))
<niemeyer> fwereade: DeployUnit does significantly more than deploying an agent
<niemeyer> fwereade: An agent is jujud process running
<niemeyer> fwereade: DeployUnit can do whatever it pleases to put the agent to run
<fwereade> niemeyer, bingo, thanks
<niemeyer> fwereade: Including creating a container, downloading an image, running a container, etc
<TheMue> niemeyer: Thx for review.
<fwereade> niemeyer, ok, well, now that deployer's in, the how-to-merge-question comes up: I'm still not convincer that a MachinerWorker is a good reason to start a Deployer worker
<fwereade> niemeyer, it feels a bit off to me
<niemeyer> fwereade: So let's do the change we discussed the other day and have flags there instead
<fwereade> niemeyer, task-per-flag? <3
<fwereade> niemeyer, upgrader I presume remains implicit?
<niemeyer> fwereade: Not task per flag.. flag per flag :).. the idea is precisely to avoid the 1-to-1 relationship between code and run mode
<niemeyer> fwereade: Flags can possibly change the way that code run, instead of adding a new task
<fwereade> niemeyer, ah, ok, I wasn't really quite expecting you to have changed your mind there
<niemeyer> fwereade: We had already gotten to that point in our last conversation IIRC
<fwereade> niemeyer, but the idea has not quite clicked with me, I'm afraid, and I'm a little nervous that I will do something completely unlike what you expect
<fwereade> niemeyer, yeah, but I did some independent thinking last weekend and accidentally dragged my comprehension of the problem back towards my initial viewpoint
<niemeyer> fwereade: Okay, so how does it stand now?
<fwereade> niemeyer, basically I've confused myself -- I ran with an Agent idea for a bit and I think it's nice but I can't really justify it yet :(
<fwereade> niemeyer, or, at least, I don't have the time or emotional fortitude necessary to convince you before you go on holiday even if I am right ;p
<niemeyer> fwereade: Hehe :)
<fwereade> niemeyer, and I am reluctant to sneak it past you while you're away
<fwereade> niemeyer, because I doubt you would appreciatethat too much ;)_
<niemeyer> fwereade: So let's try to reach some quick agreement.. feel free to sneak it in as we go
<fwereade> niemeyer, haha
<niemeyer> fwereade: What we have now is a document in the database representing the machine
<niemeyer> fwereade: That document has a field with a few names that we map 1-to-1 to what we call workers, which are really packages under the worker directory which tend to do relevant and mostly independent tasks within an agent
<niemeyer> fwereade: agent being the name we give to a jujud process that we run to control stuff up in situations where one or more workers are necessary
<niemeyer> fwereade: So far so good?
<fwereade> niemeyer, yep
<niemeyer> fwereade: Cool.. so the discomfort we're sitting in happens because we rightfully renamed one of our workers to adapt the code
<fwereade> niemeyer, indeed
<niemeyer> fwereade: and the fact we have fields which are tied to code name rather than the intended semantics for the running logic means we're forced to swallow a mismatch, or fix it, or change the way we refer to that kind of semantics so that we avoid future mismatches
<niemeyer> fwereade: I'm suggesting the latter
<niemeyer> fwereade: and part of my motivation is that I think the 1-to-1 mapping between package name and semantics is too artificial to survive over time
<fwereade> niemeyer, ok -- I guess my own discomfort here is that I'm not clear on what the intended semantics are
<niemeyer> fwereade: Understood. That's easy to solve, I think.
<fwereade> niemeyer, you have stated the problem helpfully though
 * fwereade is all ears
<niemeyer> fwereade: We have three different flags today:
<niemeyer> fwereade: Flag 1) "I want this agent to manage the firewall for the environment"
<niemeyer> fwereade: Flag 2) "I want this agent to manage the provisioning of machines for the environment"
<niemeyer> fwereade: Flag 2) "I want this agent to manage the hosting of units for that machine"
<niemeyer> s/2/3/ on the last, of course
<fwereade> niemeyer, right, yes, agreed
 * niemeyer holds off a bit
<niemeyer> fwereade: Welcome back
<niemeyer> fwereade: So
<fwereade> grar, sorry
<niemeyer> LOL
<fwereade> sorry, that time the actual client crashed :/
<niemeyer> fwereade: No worries
<niemeyer> fwereade: So!
<niemeyer> :)
<niemeyer> fwereade: We have these three stated semantics
 * fwereade sits very still
<niemeyer> fwereade: My proposal was to find a way to name the intended semantics without actually referring to worker, or task
<niemeyer> fwereade: But rather as a property of the machine itself
<niemeyer> fwereade: and at the agent side, we map these flags to workers, tasks, or whatever we please
<fwereade> niemeyer, ok, that SGTM -- and that reduces the current problem to a naming question really, just a different one to that I had previously imagined
<niemeyer> fwereade: Cool.. so how do we name those flags? Hmmm
 * fwereade is still a touch baffled by this question
<niemeyer> fwereade: Hm?
<niemeyer> fwereade: I'm baffled by your baffledness :-D
<fwereade> niemeyer, I don't know what we should name them
<fwereade> niemeyer, well, Firewaller and Provisioner are a bit too close to the worker names for comfort -- the implication is that flags *do* map onto workers
<fwereade> niemeyer, and I really don't like "machiner"
<niemeyer> fwereade: Strawman: HostProvisioner, HostFirewaller, HostUnits
<fwereade> niemeyer, ok, I think I can work with those :)
<niemeyer> fwereade: Although HostFirewaller is still not great
<niemeyer> fwereade: Because we'll likely have local firewall management soonish
<fwereade> niemeyer, I think the big issue there is ... exactly
<fwereade> niemeyer, I'm almost tempted to roll firewalling into provisioning again
<niemeyer> fwereade: ManageEnvironFirewall, ManageEnvironProvisioning, HostUnits
<fwereade> niemeyer, ie if HostProvisioner, we run both P and FW workers
<niemeyer> fwereade: Hmm
<niemeyer> fwereade: Interesting
<fwereade> niemeyer, or HostEnvironStuff ;p
<fwereade> niemeyer, (bad name, just saying I'm not attached ot the specific chars that make it up)
<niemeyer> fwereade: Sounds like a good idea.. there's no great reason to separate those
<fwereade> niemeyer, ok, fantastic -- that feels like enough to be going on with
<fwereade> niemeyer, I am being encouraged to be a monster, and I think I should be off
<fwereade> niemeyer, have a very happy christmas with much joy and adequate sleep -- see you in the new year, I expect :)
<niemeyer> fwereade: UnitsMachine and ControlMachine?
<fwereade> niemeyer, ...ambivalent, I will take those under consideration :)
<niemeyer> fwereade: With int flags, so we can tweak names over time as we see fit
<niemeyer> fwereade: Thanks a lot man :-)
<fwereade> niemeyer, ok, sounds sensible
<niemeyer> fwereade: Have a great break as wel
<niemeyer> l
<fwereade> niemeyer, always a pleasure, take care :)
<niemeyer> fwereade: Tell Laura there's a little friend coming
<niemeyer> fwereade: ;_)
<fwereade> niemeyer, will do :)
<niemeyer> fwereade: I'll just have to make an effort for them to be able to communicate :_0
<niemeyer> :-)
#juju-dev 2013-12-09
 * thumper takes kid to sports
<jam>  wallyworld: I'm probably not going to make our 1:1 today, my son has his "Winter Musical" this morning
<wallyworld> ok
<wallyworld> enjoy :-)
<wallyworld> thumper: hey. i added fingerprint support to the ssh utils
<thumper> wallyworld: cool
<wallyworld> had to call out to ssh-keygen
<wallyworld> i couldn't find a Go implementation
<thumper> jam: I'm actually around now
<thumper> if fwereade_ is too
<jam> thumper: I'm around as well, not sure about fwereade_
<thumper> I had another call at 0800UTC, but it has been moved
<jam> thumper: well, william responded to one of my emails at 11pm last night, so it may be that he's going to be a bit later today
<wallyworld> thumper: don't forget to look at my ssh branch again :-) tomorrow first thing your time will be fine :-)
<thumper> wallyworld: ack
<wallyworld> thanks
<fwereade_> jam, thumper: if you're both here let's chat now
<jam> fwereade_: I'm just chatting with dimiter for a bit, and then I'll be right with you guys
<thumper> sorry, was making a coffee
<thumper> fwereade_: , jam (when you're ready): https://plus.google.com/hangouts/_/7ecpitcov2peobbk7u31s52nn0?hl=en
<rogpeppe> mornin' all
<jam> hey rogpeppe, just in another call, will be there in a sec
<jam> rogpeppe: I'm in now, whenever you're available
<jam> mgz: good morning!
<jam> I'm just about to go make a coffee, and then I'll be around, mumble or hangout is fine for me.
<mgz> jam: sure
<jam> mgz: I'm back, mumble or hangout?
<mgz> jam: mumble!
<jam> mgz: I'm already there
<jam> mgz: you're completely unintelligible
<mgz> it's unhappy...
<jam> he-e-e-l-l-l-o-o-o-o-o
<mgz> that's how you're coming through for me
<jam> time to stand up, raisin' the roof
<jam> https://plus.google.com/hangouts/_/calendar/am9obi5tZWluZWxAY2Fub25pY2FsLmNvbQ.mf0d8r5pfb44m16v9b2n5i29ig
<jam> rogpeppe: fwereade_, TheMue ^^
<jam> dimitern: ^^
<natefinch> can someone give me the meeting link? my chrome is acting up
<mgz> natefinch: https://plus.google.com/hangouts/_/calendar/am9obi5tZWluZWxAY2Fub25pY2FsLmNvbQ.mf0d8r5pfb44m16v9b2n5i29ig
<wallyworld> fwereade_: for later when you are free, i renamed "credentials" package to "keyupdater" https://codereview.appspot.com/37570043
<mgz> dstroppa: dimitern mentioned you want to run `go fmt ./...` on lp:gojoyent
<mgz> and the others are also taking a look at the cl
<dstroppa> thanks, will do that
<mgz> if we did it all correctly, you should be able to make changes then run the same lbox command to update the review
<dimitern> dstroppa, mgz, thanks!
<rogpeppe> jam: i updated the firmware on my router and it seems to have fixed the issue
<rogpeppe> jam: (even though the firmware update notes contained no mention of the bug)
<dimitern_> rogpeppe, jam, fwereade_, mgz, et al - just letting you know ^^
<rogpeppe> dimitern_: just letting us know what?
<dimitern_> ah, sorry
<dimitern_> * dimitern_ needs to be off for a while, the electrician came to change the wires and i won't have power for at least 1 hour
<dimitern_> ( though I managed to send it, but apparently not)
<mgz> dimitern: good luck :)
<dimitern_> mgz, cheers :)
<mgz> rogpeppe: query about doing providery things from inside the apiserver
<rogpeppe>  mgz: go on
<mgz> to actually recreate status as it exists currently, I'd need to do provider Instances() to get instance statuses
<mgz> this is something the apiserver doesn't actually want to do... how can I get around that for now without borking things?
<rogpeppe> mgz: if we can avoid that, we should
<mgz> currently the output is just different...
<rogpeppe> mgz: eventually, we probably want a worker that keeps the instance status in the state up to date
<rogpeppe> mgz: for the time being, perhaps you can't avoid it
<mgz> one option is to leave some of that client-side for now
<rogpeppe> mgz: let's not do that
<mgz> but that makes api-status less fun
<rogpeppe> mgz: that loses a lot of the bonus of client-side status
<rogpeppe> s/client-side/API-based/
<mgz> right
<mgz> so, it's not completely unsafe to construct and use a provider inside an api call? I note some make one to look at config stuff
<rogpeppe> mgz: no, it's notr
<rogpeppe> mgz: and some calls currently do that, i think
<mgz> but nothing seems to actually use the provider to do and cloud-operations, so I'm a little scared
<rogpeppe> mgz: well, currently the deploy API call (whatever it's called) does
<rogpeppe> mgz: it puts stuff into provider storage
<mgz> ah, I'll have a look at that, a grep didn't turn it up
<rogpeppe> mgz: look for ConnFromState
<rogpeppe> mgz: yeah, looks like it's just charm putting
<rogpeppe> mgz: i think that for the time being, we should probably just move the provider Instance calls into the API.
<mgz> rogpeppe: okay, thanks, I'll have a play around
<rogpeppe> mgz: but...
<rogpeppe> mgz: if we can, we should avoid iterating when the instance doesn't exist
<rogpeppe> mgz: and we should make only one provider call if possible to get all the instances
<rogpeppe> mgz: that way the overhead's not too bad
<mgz> well, my current scheme is just to bung everything behind one single call
<mgz> not split the instance fetching and machine fetching at all
<rogpeppe> mgz: i'm talking about the implementation of the Client.Status call
<rogpeppe> mgz: ah, looking at the current implementation, that's what it does anyway,
<rogpeppe> mgz: so that's fine
<mgz> right, in the cmd status it just lists everything once then sticks in in a struct to do further work on
<rogpeppe> mgz: yeah - that's just fine
<rogpeppe> mgz: the place we want to be a bit more intelligent is in the address updater, but that's a different discussion
<hazmat> jam, fwereade_ re the manual provider support in 1.16.. does that effect the api ongoing for 1.18/trunk?
 * rogpeppe is done for the day
<jam> hazmat: inasmuch as we want to be backwards compatible to what we had in 1.16 (fallback to direct DB access), it does, but I don't think it is massively deep. A couple hours for me to finish making 1.17 compatible with the 1.16 manual provisioning steps.
 * jam is off to bed
<mgz> night jam!
<hazmat> jam.. ic. so no api changes per se to 1.18/trunk?
<hazmat> jam, g'night.. i just want to avoid non go clients from contemplating tool lookup, the current machine config api does that nicely.
<thumper> any one know if the result from os.Pipe() is serializable over net/rpc ?
<thumper> just considering options in testing...
<thumper> but I suppose I can test it now...
 * thumper pokes
#juju-dev 2013-12-10
<arosales> do folks know which ports juju client needs to be open?
<arosales> also I am working with mxc in #juju and he is hitting http://pastebin.com/AQArivJz
<arosales> doing a comparison the next logical step from juju should have been juju.provider.azure environ.go:406 picked tools
<arosales> but that is where the bad request comes from
<arosales> does anyone know why juju.provider.azure environ.go:406 would fail in a bad request on bootstrap?
<thumper> arosales: um...
<thumper> arosales: the api/state ports to the server
<thumper> arosales: i'd poke axw when he starts about the bootstrap issue
<arosales> thumper, thanks i'll see if axw has any insights when he comes online
<arosales> thumper, re the api/state ports to the server
<thumper> yes...
<arosales> on the client
<arosales> does juju-core binary need to call out on any specific port?
<thumper> probably also needs access to the charm store (not sure which port) if deploying standard charms
<arosales> aside from deploying and even at that the client wouldn't do the the deploying
<thumper> the default port for state is 37017 and api is 17070
<arosales> client in this context is where juju commands are being issues form
<arosales> *from
<thumper> right, the juju binary talks to the bootstrap node primarily over the api now (17070), but a few still use state directly (37017)
<arosales> thumper, gotcha thanksfor the info
<arosales> axw, hello
<axw> arosales: howdy
<arosales>  I am working with mxc in #juju and he is hitting http://pastebin.com/AQArivJz
<arosales>  doing a comparison the next logical step from juju should have been juju.provider.azure environ.go:40
<arosales>  doing a comparison the next logical step from juju should have been juju.provider.azure environ.go:406
<arosales> do you know why that section of code would fail with a 400: bad request
<arosales> axw, ^
<axw> arosales: not sure, looking
<arosales> axw thanks
<arosales> I wasn't able to reproduce the issue he was seeing
<arosales> axw, I am going to step away from the computer but any insights you have would be appreciated.  I think at this early in the process he may have a cert config issue, but I am uncertain on how to confirm that.
<axw> arosales: no worries, I will see what I can see
<axw> arosales: is there a bug or something I can update?
<axw> no mxc on #juju atm
<arosales> axw, unfortunately no, he only posted http://askubuntu.com/questions/388419/juju-bootstrap-fails-in-azure-badrequest-the-affinity-group-name-is-empty-or
<arosales> he was in #juju but left
<arosales> he also had a post to the juju mailing list
<arosales> axw, don't spend too much time I thought I would just check with you on why that section of code was failing as a clue to what may have been going on.
<axw> okey dokey, I will update the list if I find something, or file a bug if there is one
<arosales> axw, thanks
<axw> arosales: sure, nps
<jam> hazmat: There will be a couple of new APIs coming in 1.18 still, but we don't expect any existing ones to be removed. (status is added, PutCharm/Deploy/UpgradeCharm added, etc) MachineConfig is likely to stick around as is (though wasn't in 1.16)
<axw> uh oh, I think my hard drive is failing
 * axw fscks, bbs
 * thumper heads to the supermarket
<dimitern> thumper, did you get my mail yesterday about cadmin?
<thumper> hi dimitern
<dimitern> thumper, hey
<thumper> dimitern: yeah, I got it, but not looked yet sorry
<dimitern> thumper, no worries
<dimitern> hatch, hey, you around?
<hatch> dimitern sortof :) what's up?
<dimitern> hatch, I wanted to check with you about the charms upload implementation
<hatch> oh ok cool, so where are we on that?
<dimitern> hatch, basically, we settled on no API calls, just a POST /charms?series=<series> and a multipart/form-data body containing a single zip file with the charm, and returning a json response in the form {"code":<int status code>, "error": "message", "charmUrl": "the url"}
<hatch> what about the auth?
<dimitern> hatch, if there is an error code and error are populated, charmUrl is missing, on success charmUrl is populated and error and code are missing
<dimitern> hatch, basic http auth with a user-tag and password
<dimitern> hatch, i'm finishing the proposal later today
<hatch> hmm
<hatch> so https post with username and secret?
<dimitern> hatch, the implementation allows further development, like implementing GET /charms?url=<charmUrl>&file=icon.svg, but not implemented for now
<dimitern> hatch, the same creds as for Login() - tag and password, where the tag must be a "user-xxx"
<hatch> and what does this give us over the previously discussed pattern?
<dimitern> hatch, it's the simplest approach
<hatch> The only part I'm concerned about is the http auth stuff
<hatch> not that we can't do it
<hatch> I can't remember how the auth data is handled across the various login methods
<hatch> I'll have to check when I'm back at my computer
<dimitern> hatch, well, it's standard "Authorization" header containing `Basic realm="juju" <base64-encoded "tag:password" plain text string>`
<hatch> right but I'm not sure if we store that information or not
<dimitern> hatch, ah, sorry `Basic <base64-part>` no realm
<hatch> it's been quite a while since I looked at the login code
<dimitern> hatch, it should be almost exactly the same
<hatch> I mean that the user will already be logged in
<hatch> so if we don't store their creds we will need to ask for it again
<dimitern> hatch, hmm, yes, but you can generate the base64 token and store it in a cookie or something i guess
<hatch> right yeah
<dimitern> hatch, anyway, all that is just a heads up for what's coming, not set in stone, we'll change accordingly to accommodate the gui as needed
<hatch> right, yeah thanks, I've got this all down and when I'm not so darn tired I'll take a look at what we have/need - but it sounds good :)
<hatch> thanks
<dimitern> hatch, sure, sorry to bug you so late btw :)
<hatch> dimitern can you cc me on the proposal so I can take a look in the morning?
<hatch> haha no problem :) thanks for keeping me up to date
<dimitern> hatch, I will update the document and send you a link
<hatch> great thanks
<hatch> have a good one!
<dimitern> hatch, you too!
 * thumper has a "fuck yeah!" moment
<dimitern> thumper, \o/
<thumper> dimitern: yay tests is all I can say
<thumper> dimitern: http://pastebin.ubuntu.com/6549442/ are the tests that are passing :-)
<dimitern> thumper, :) looking
<thumper> dimitern: working on the server side of juju-run
<dimitern> thumper, great!
<thumper> dimitern: so you can do something like this on any machine hosting a unit
<dimitern> thumper, looking forward to trying it out when done
<thumper> juju-run my-unit/4 "some magic"
<thumper> inside cron
<thumper> so runs in a hook context etc...
 * thumper pops the stack and writes tests for uniter.RunCommands
<dimitern> nice!
<thumper> actually, now might be a good time to stop for the day
<thumper> finish on a high and all that
 * thumper does some admin bits
<dimitern> :)
<davecheney> axw: i hope that failure is not related to not having a tty
<axw> davecheney: which failure is that?
<axw> davecheney: the azure/ec2/etc. bootstrap failure?
<davecheney> the same
<davecheney> my money is still on timeouts
<axw> davecheney: nfi, the gpgv thing is weird
<axw> I've found a bunch of bug reports on this, and all the resolutions are "oh I just re-ran apt-get update and it fixed it"
<davecheney> axw: do you pass ssh -t when dialing the bootstrap node ?
<axw> davecheney: yes, for sudo
<davecheney> why would sudo require that
<davecheney> ubuntu user doesn't need a password
<axw> davecheney: it's needed for manual provisioning/bootstrap
<axw> could be disabled for cloud provider
<davecheney> nonsense
<axw> davecheney: nonsense? it's needed because the ubuntu user doesn't necessarily exist on a machine you're manually bootstrapping
<davecheney> axw: seriously ?
<davecheney> oh ffs
<davecheney> that's just peachy
<axw> davecheney: why does that matter?
<davecheney> i guess if you pass -t to ssh
<davecheney> that is all we need
<axw> yup
<thumper> night all
<fwereade_> jam, so, looks like we can pull the trigger on 1.16.5?
<jam> fwereade_: I believe so. I don't have anything stuck in my head we're waiting for
<fwereade_> jam, \o/
<jam> 1.17.0 on the other hand ... :)
<axw> does anyone know if there are cloud (ec2, azure, ...) mirrors for cloud-archive?
<axw> seems that installing monogdb-server from cloud archive is what takes so damn long on azure
<fwereade_> jam, yeah :(
<jam> axw: I don't believe it is mirrored by anyone, ATM.
<fwereade_> jam, actually, hmm, I should make force-destroy-machine delegate actual removal to the provisioner
<fwereade_> jam, axw, who should we be talking  to about that? ben howard?
<axw> jam: okey dokey
<jam> fwereade_: I think it is possible, but hard to mirror stuff that isn't in the central archive.
<jam> I actually think the juju-mongodb proposal, possibly with V8 stripped out will get us big wins here
<jam> as we can make the package that gets installed a lot smaller
<jam> (today we install 'mongodb' which gives us client and server, and client is 60-90MB)
<jam> while I agree local mirrors will still be faster, I'm not sure how that works with non Ubuntu archives
<jam> (when we say "add cloud-archive:tools" how is that found in a mirror?)
<axw> jam, fwereade_: https://bugs.launchpad.net/juju-core/+bug/1259453   -- marked as Low, feel free to increase if you think it's worth pursuing
<_mup_> Bug #1259453: Bootstrap is significantly delayed by installing mongodb-server from cloud-archive <juju-core:Triaged> <https://launchpad.net/bugs/1259453>
<axw> it won't be a problem with Trusty
<fwereade_> axw, I think precise is still pretty important, but it sounds like it may be hard to do
<axw> yeah, probably
 * fwereade_ wrote some code!
<fwereade_> rogpeppe1, you're OCR -- https://codereview.appspot.com/39970043/ and https://codereview.appspot.com/37610044/
<fwereade_> rogpeppe1, they're identical
<rogpeppe1> fwereade_: looking
<jam> fwereade_: dimitern did comment on it. if you set safe-mode: true will this actually stop instances?
<fwereade_> jam, safe mode distinguishes between "stopping" and "unknown"
<axw> if anyone has spare cycles, this could do with a review sooner rather than later (it fixes a 1.17 critical): https://codereview.appspot.com/39940043/
<jam> fwereade_: did you actually test this?
<dimitern> fwereade_, so safe-mode is selectively destructive then :)
 * axw eods
<fwereade_> jam, I'm running it now, I *think* I'm being clever and parallel rather than slapdash ;p
<jam> fwereade_: so this is 'juju status' in manual provisioning when you try to add, and it can create the machine in the DB but calls DestroyMachine http://paste.ubuntu.com/6550335/
<jam> that is what I was saying about it ending up 'pending but dying'
<jam> but never alive
<fwereade_> jam, so what is it that failed after the machine was created in the db?
<jam> fwereade_: well, I haven't finished the manual stuff, so MachineConfig failed in the middle, and then it couldn't set up upstart, but the theorical "something after allocating a machine id but before the agent is actually running"
<jam> we try to clean up
<jam> but I don't *quite* see the point, as the cleanup doesn't actually work
<fwereade_> jam, yeah, the problem is (I think) that an instance id is assigned so we don't fast-forward the destroy
<fwereade_> jam, I'm not reallycomfortable with differentiating based on the "manual:" bit
<jam> fwereade_: well, we're in manual provisioning code right then, if we have a way to actually signal it should be destroyed
<fwereade_> jam, just because I'm sure that one day some provider will give us a real instance id starting with "manual:"
<jam> we *could* call something to remove the instance id as we clean up
<fwereade_> jam, well, yeah, we can write the code :)
<fwereade_> jam, but, generally, removing an instance id is a pretty surprising thing to do
<fwereade_> jam, and I'm reluctant to normalise it
<fwereade_> jam, really we should have flagged manual instances in some way that wasn't just a magic string embedded in the instance id
<fwereade_> jam, plausibly we could start doing that now, though..?
<jam> fwereade_: given that this is all about compatibility with 1.16 direct DB access, I'm not planning on changing DB internals just yet :)
<fwereade_> jam, rogpeppe1: fwiw, yes, the provisioner works as expectedlive
<jam> I think it is fine that in the "cleanup we have an error while manual provisioning" for us to do the steps we need to clean it up
<jam> fwereade_: great
<jam> fwereade_: we'll need to think what that looks like in the API-only case as well, because that is also broken in trunk
<jam> so there is certainly "it is out of scope for today" but I think it is a bug to be fixed
<rogpeppe1> fwereade_: sorry, some context?
<fwereade_> jam, yeah, indeed -- an easy fix here is fine -- but for trunk, and going forward, I think we should be a bit more precise about specific machines' providers
<fwereade_> rogpeppe1, jam asked if I'd tested it live, I just finisheddoing so
<rogpeppe1> fwereade_: ah, cool
<rogpeppe1> fwereade_: i *thought* that's what you meant, but just checking
<fwereade_> jam, the trouble is that we still don't have an explicit concept of provider in state, it's still all gummed up with the environment
<jam> fwereade_: anyway, I'm at the "file a bug, and get on with what I'm actually trying to solve" point.
<fwereade_> jam, yeah, that sounds reasonable
<jam> fwereade_: so there isn't anyway to actually get rid of the machine in 1.16.3, right? (We might be able to call ForceDestroyMachines if it was available)
<fwereade_> jam, I think that is so, yes
<fwereade_> jam, and with my change there still won't be in 1.16.5
<fwereade_> jam, it'll get to Dead but won't actually be removed, I think
<fwereade_> jam, would you bug it for 1.18 please?
<jam> fwereade_: and I think we would still want to distinguish from "I did get it set up, so I want the agent to clean up after itself" from "I create the record, but the agent will never come up"
<jam> fwereade_: https://bugs.launchpad.net/juju-core/+bug/1259496
<_mup_> Bug #1259496: juju add-machine ssh: may not clean up properly on failure <manual-provider> <juju-core:Triaged> <https://launchpad.net/bugs/1259496>
<fwereade_> jam, definitely, it's a very specific situation
<fwereade_> jam, I worry most about the code being abused once it exists
<jam> fwereade_: bug #1259490 ... It sounds to me like he means "juju debug-log" is too verbose, but what he actually means is that the only way he has to see what is going on is an overly-verbose-for-debugging log
<_mup_> Bug #1259490: juju-log in debug mode is too verbose <debug-log> <juju-core:New> <https://launchpad.net/bugs/1259490>
<fwereade_> jam, maybe -- the hook-tool invocation line is probably more a DEBUG-level thing -- but it sounds like what he actually wants is to set the log level to INFO..?
<jam> It *might* be that he just wants to be able to INFO level filter the debug-log, but it sounds mostly like he's having trouble getting appropriate feedback.
<dimitern> jam, rogpeppe1, standup?
<jam> natefinch: still up for 1:1?
<natefinch> natefinch, yep
<jam> k, I'm there
<jam> natefinch: you're feed is paused, is it working for you?
<natefinch> wow, had to hard-reset my laptop
<jam> welcome back natefinch
<jam> natefinch: I sent you an email, I'm not sure there's much to finish up
<natefinch> jam: ok, cool. I sorta figured
<TheMue> rogpeppe1: https://codereview.appspot.com/36540043/ is in again, looks and feels better now.
<TheMue> rogpeppe1: thx for your review hints, helped a lot.
<rogpeppe1>  TheMue: cool. looking.
<rogpeppe1> TheMue: hmm, seems like you didn't use bzr mv, which is a pity as i can't easily see the diffs from my last review
<TheMue> rogpeppe1: I used bzr mv
<rogpeppe1> TheMue: weird
<TheMue> rogpeppe1: and rietveld discovers it correctly
<rogpeppe1> TheMue: oh well, it's probably just a rietveld thing
<TheMue> rogpeppe1: our good old friend :D
<TheMue> rogpeppe1: oh, interesting, changed the patch sets in display, see your troubles :(
<mgz> okay, I'm back around reliably again now
<dimitern> fwereade_, jam: charm upload's state operations https://codereview.appspot.com/40160043
<smoser> hey.
<smoser> general question...
<mgz> generic answer...
<smoser> what woudl people think about having a 'environment' file for jujud
<mgz> that does what?
<smoser> my motivation for this is right now 'lxc-create' uses 'ubuntu-cloudimg-query', which *can* read a environment variable to set a mirror.
<smoser> but there is no way to get environment variable into juju
<smoser> same is true for 'http_proxy' and 'https_proxy'
<smoser> which would be respected by utilities if they could be set.
<smoser> but putting stuff in /etc/environment does'nt perculate through to daemons started with upstart.
<mgz> smoser: I agree some way to chuck in extra cloud-init values seems really useful
<mgz> though, that also means the bypass that manual provisioning currently does need to start using cloud-init...
<smoser> mgz, well, i wasn't talking about cloud-init specifically
<smoser> but for the manual provisioning, my solution for that is to actually use cloud-init
<smoser> (and cloud-init provide a consistent interface to "run cloud-init now")
<mgz> yeah, that would be good
<mgz> smoser: I'd prefer cloud-init extra config to random envvars
<smoser> well, cloud-config wouldn't even suffice here.
<smoser> mgz, well... out oside of somewhat abusing it.
<smoser> cloud-init can set http-proxy for apt
<smoser> but doesn't do it for /etc/environment a
<smoser> the only way to solve this would be to provide a boothook that dpkg-divert'd the lxc-create to a wrapper.
<mgz> some guy hacked around this previously by modifying his base image to have HTTP_PROXY set for the ubuntu user... but it seems like a really fragile why of saying you need to go out through a gateway for your cloud
<mgz> rogpeppe1: any hints on debugging "panic: Session already closed" in tests for status cmd after I've been fiddling with the api bits?
<rogpeppe1> mgz: what does the traceback look like?
<mgz> I shall pastebin
<mgz> rogpeppe1: http://paste.ubuntu.com/6551589/
<rogpeppe1> TheMue: you've got a review BTW
<rogpeppe1> mgz: i think i'd start by trying to find out when the state.State was closed
<rogpeppe1> mgz: as i think that's probably the only way that that panic can happen
<rogpeppe1> mgz: usual drill: add some printfs...
<mgz> it's a begger as it's one giant table test, so I can't really do a minimal run...
<TheMue> rogpeppe1: just seen, thx
<rogpeppe1> mgz: you could see if you get the issue with all but two of the tests omitted
<mgz> rogpeppe1: heh, if I only use the fallback path, it works
<rogpeppe1> mgz: the fallback path?
<mgz> probably something in the testing reset state logic breaks the api
<mgz> fallback to direct state access
<rogpeppe1> mgz: ah yes
<rogpeppe1> mgz: yeah, probably
<mgz> kills some pingers and calls JujuConnSuite.Reset()...
<mgz> rogpeppe1: okay, it involves how I'm using conn from inside the apiserver...
<rogpeppe1> mgz: oh yes?
<mgz> if I just don't close it after creating one, everything is fine... but that seems like a leak?
<mgz> rogpeppe1: http://paste.ubuntu.com/6551726/ how bogus is that?
<rogpeppe1> mgz: were you closing the Conn?
<rogpeppe1> mgz: if so, that was definitely the reason for the problem
<rogpeppe1> mgz: NewConnFromState just shares the State that's passed into it
<mgz> I was, doubtingly, and not does indeed help. but if I'm calling New... every api call, what's doing the c... okay, ace
<mgz> thanks!
<rogpeppe1> mgz: np
<rogpeppe1> dimitern: you've got a review https://codereview.appspot.com/40160043/
<dimitern> rogpeppe1, cheers!
<mgz> another fun mystery...
<mgz> switching to the api has lead to a test mismatch, where setting a machine's agent state is expected to be:
<mgz> "agent-state":"started"
<mgz> but comes out as:
<mgz> "agent-state":"down", "agent-state-info":"(started)"
<rogpeppe1> mgz: is that a function of instance state?
<mgz> it's all entwined in a bunch of declarative testing stuff, but I can't quite see how I have affected it at all with the api...
<mgz> may well just be a fixup error I made somewhere, in whice case I'm happy for the test... but it's not obvious where the problem lies
<mgz> hm, more likely, the provider bit is just not working
<mgz> what could cause AgentAlive to be unhappy...
<dimitern> rogpeppe1, fwereade_, next (and last for today) CL https://codereview.appspot.com/40290044
 * dimitern reached eod
<rogpeppe1> dimitern: looking
<dimitern> rogpeppe1, thanks
 * fwereade_ supper, might pop backonlater
<rogpeppe1> dimitern: i'd like to see a version of the PutCharm document that encapsulates the current proposal
<rogpeppe1> dimitern: i'm not sure the history matters so much
<dimitern> rogpeppe1, well see it - i've updated the doc and even sent you (and the others a mail
<dimitern> rogpeppe1, last section "Chosen Implementation"
<rogpeppe1> dimitern: ah cool. perhaps that could go at the top.
<dimitern> rogpeppe1, feel free to edit to your heart's content :)
<rogpeppe1> dimitern: okeydokey :-)
<webbrandon> I am getting a ERROR Get : 301 response missing Location header.  It started happening after I destroyed-environment.  I hadn't done anything to juju from the bootstrap previous to make this happen except a system update
<webbrandon> I tried removing and reinstalling juju-core but it still exist
<mgz> rogpeppe1, (et al): have posted https://codereview.appspot.com/40350043 with current progress and cry for help
<rogpeppe1> mgz: will look after i've finished with dimitern's
<mgz> thanks!
<rogpeppe1> dimitern: reviewed
<dimitern> rogpeppe1, thank you
<rogpeppe1> mgz: you've got a review
<mgz> rogpeppe1: thanks!
<rogpeppe1> mgz: i don't quite understand your CL description
<rogpeppe1> mgz: what are the #1, #3 etc referring to?
<mgz> rogpeppe1: in cmd/juju/status_test.go statusTests is a list of test() things, which have several expect{} asserts withing
<mgz> -g
<rogpeppe1> mgz: yeah, i'm looking at it currently
<rogpeppe1> mgz: are the #1 etc referring to steps of test 0 ?
<mgz> yeah, I didn't 0-index
<rogpeppe1> mgz: oh, confusing?
<mgz> and the first test() fails
<rogpeppe1> s/?/
<mgz> see the string for which one it actually is if the numbering is confusing :)
<dimitern> rogpeppe1, mgz, when I wrote those tests, each test() was a separate case
<dimitern> rogpeppe1, mgz, and it seems it still is
<rogpeppe1> mgz: i'm finding it difficult to parse: "
<rogpeppe1> The test #1 expect #3 which does SetAgentAlive
<rogpeppe1> passes
<rogpeppe1> "
<mgz> right
<dimitern> rogpeppe1, mgz, it just written so that you can also build cases incrementally with multiple expects
<mgz> and the following one fails
<rogpeppe1> mgz: should that be "expects" ?
<dimitern> mgz, once you're using the api, the setagentalive tests are meaningless
<dimitern> mgz, because once you connect to the api as a machine or a unit the agent is set to alive
<rogpeppe1> dimitern: surely they're not meaningless?
<rogpeppe1> dimitern: 'cos we're connecting as a client
<mgz> status still needs to care, is the issue
<dimitern> rogpeppe1, oh, right
<rogpeppe1> mgz: i see step #6 fail FWIW
<rogpeppe1> mgz: ah, you're counting expects!
<mgz> rogpeppe1: yeah, it's step #6, but expect #4
<rogpeppe1> mgz: ... using 0-based counting for steps, but 1-based for expects :-)
<dimitern> mgz, if it helps, split the test()s so that each one has a single expect(), then you can comment out the rest and run them one by one
<dimitern> mgz, this will introduce some code duplication, because the first test case relies on setting and testing stuff as it goes
<rogpeppe1> mgz: it's weird - i've just verified that SetAgentAlive is called and AgentAlive initially returns true but returns false a few moments later
<dimitern> rogpeppe1, i had that issue before
<rogpeppe1> dimitern: oh yeah?
<rogpeppe1> dimitern: do you remember what the issue was?
<dimitern> rogpeppe1, it was something to do with the pinger being killed at some point
<mgz> rogpeppe1: right, that's why the cry for help :)
<dimitern> rogpeppe1, or maybe it was related to startsync on the right state - BackkingState or State in the suite
 * dimitern has can type? time to call it a night
<dimitern> g'night all, see you tomorrow guys
<mgz> night dimitern :)
<rogpeppe1> mgz: ah, i think i know what the issue might be
<rogpeppe1> mgz: the api's state presence hasn't seen the agent becoming alive yet
<rogpeppe1> mgz: dimiter is right - if you startsync in the api's state, it should fix the issue.
<mgz> ah, interesting
<rogpeppe1> mgz: the logic in startAliveMachine is doing the right thing but on the wrong State
<rogpeppe1> mgz: i have a feeling that it's there because of the issue that dimiter encountered before (the same issue)
<rogpeppe1> mgz: hope that helps enough to get you through it.
<mgz> rogpeppe1: hopefully! thanks!
<rogpeppe1> mgz: perhaps this is a case for moving those tests closer to the implementation
<mgz> rogpeppe1: indeed
<rogpeppe1> mgz: and making the status tests in cmd/juju just a smoke test
<mgz> rogpeppe1: how do I get a reference to the api, given that it's created with NewApiClientFromName on each Run invocation?
<sinzui> mgz, I am seeing  a test failure in 1.16 tip. I think something in my own configuration is interfering. any insights? http://pastebin.ubuntu.com/6552812/
<mgz> sinzui: looking
<mgz> that looks like joy
<sinzui> I am on trusty BTW, though I did a major git reconfiguration last week
<mgz> it seems like you may have personal git config that breaks the expectations of how juju-core things git does things
<mgz> which is pretty naive
<rogpeppe1> mgz: ISTR there's a method on the dummy provider
<rogpeppe1> mgz: that returns the State used by the API server
<mgz> rogpeppe1: GetStateInAPIServer sounds good
<mgz> okay, all fixed
<abentley> thumper: Is there an equivalent to all-machines.log for the local provider?  So far, I've only found individual agent logs.
<thumper> abentley: yes, all-machines.log
<thumper> abentley: well, in trunk
<thumper> abentley: there were changes recently to have the local provider use rsyslog too
<thumper> but not in the 1.16 branch
<abentley> thumper: Oh, cool.  Yes, I was using the 1.16 branch.
<abentley> jcsackett: the big changes are done for splitting upgrade and deploy into separate tests.
<natefinch> thumper: you know anything about the uniter test failures I mentioned in email?
<thumper> hi natefinch
<thumper> ah... which email?
 * thumper looks at email
<natefinch> thumper - very recemt
<natefinch> recent
<thumper> no, not seen it
<thumper> different git?
<thumper> seems only to be leading #
<natefinch> yeah. thats what I was thinking
<natefinch> thumper, what's your git version?  I'm 1.8.5
<thumper>  Installed: 1:1.8.3.2-1
<natefinch> so maybe that's it.  I'm too bleeding-edge for Juju :)
<jcsackett> abentley: ack, thanks.
 * thumper takes a deep breath
 * thumper exhales slowly
 * wallyworld -> dentist, yay :-(
<thumper> hi wallyworld
#juju-dev 2013-12-11
<thumper> I'm sure writing this test would be easier if I actually understood the jujuc commands
<hazmat> lots of good stuff on the merge proposals page
<hazmat> putcharm/env life/svc owners/status api/ssh key mgmt
<thumper> wallyworld: back from the dentist yet?
<wallyworld> yep
<thumper> wallyworld: were you not well yesterday, didn't hear from you
<wallyworld> thumper: no all good. just busy
<wallyworld> head stuck in code
<thumper> wallyworld: ok, why didn't you land the approved code?
<thumper> busy further down the pipe?
<wallyworld> yeah
 * thumper nods
<wallyworld> waiting till more stuff done in case of upstream tweaks
<wallyworld> got about 5 branches with more tocome
<thumper> how's it all going?
<thumper> why so many?
<wallyworld> hangout?
<thumper> sure
<wallyworld> https://plus.google.com/hangouts/_/d3f48db1cccf0d24b0573a02f3a46f709af109a6
<thumper> wallyworld: the party is over
<thumper> so it says
<wallyworld> hmmm. i'm in
<thumper> is the link right?
<wallyworld> just sent an invite
<wallyworld> https://plus.google.com/hangouts/_/72cpjqoho8enpq0msp9kbjj06s
<wallyworld> wrong link
<wallyworld> thumper: lost you?
<_thumper_> wallyworld: sorry, lost connectivity for some reason
<wallyworld> same habgout url :-)
<wallyworld> hangout even
<axw_> davecheney: say if we wanted a fallback SSH for Juju CLI on Windows, would go.crypto/ssh be suitable? not necessarily for interactive usage, but for bootstrapping
<davecheney> axw_: sure
<davecheney> i wouldnt' use it for histing an ssh server
<davecheney> by as a client, no worries
<axw_> cool.
 * davecheney celebrates a birthday while juju bootstraps
<davecheney> % juju add-relation w1 p1
<davecheney> ERROR no relations found
<davecheney> fuck me
<davecheney> people people stop fucking with the haproxy charm
<davecheney> why, why does nothing work today ?
<davecheney> https://gist.github.com/davecheney/7905375
<davecheney> what am I doing wrong ?
<axw_> fwereade_: when you're awake, can you please take a look at https://codereview.appspot.com/28880043/diff/80001/state/environ.go#newcode90 and https://codereview.appspot.com/28880043/diff/80001/state/state.go#newcode492
 * fwereade_ will not be distracted from booking travel, but will look as soon as he can
<dimitern> morning all
<jam> morning dimitern
<dimitern> fwereade_, hey
<dimitern> fwereade_, i see you're reviewing - perhaps you can take a look at my 2 CLs as well? https://codereview.appspot.com/40160043/ https://codereview.appspot.com/40290044/
<fwereade_> dimitern, I'm just getting there, but I've got to go out for a couple of hours I'm afraid :(
<fwereade_> dimitern, if someone else gets there first that's fine, otherwise they're atthe topof my list when I get back
<dimitern> fwereade_, sure, thanks
<fwereade_> dimitern, probably won't make the standupbut I'll stick my headin incase anyone's still there
<dimitern> fwereade_, ok
<jamespage> any of the juju-core dev team interested in blogging about how juju uses mongodb?  czajkowski asked if we would - they will federate it to the mongodb blog
<jamespage> happy to co-author but I don't know all of the cool stuff we are doing in detail
<rogpeppe> jamespage: i'm not entirely sure it's something to shout about - our usage is somewhat odd and not the most... efficient.
<rogpeppe> dimitern: i just sent another review of  https://codereview.appspot.com/40160043/
<dimitern> rogpeppe, thanks, looking
<dimitern> rogpeppe, I think you said to panic if curl==nil, no?
<dimitern> rogpeppe, or you're now suggesting to remove the whole test + the panic?
<rogpeppe> dimitern: yeah, but you don't need an explicit test - the panic will happen anyway as a matter of course, just like using any nil pointer
<rogpeppe> dimitern: yes
<dimitern> rogpeppe, ok then
<rogpeppe> dimitern: sorry if i wasn't clear
<dimitern> rogpeppe, it was one of "perhaps this or perhaps that" and I picked one :)
<rogpeppe> dimitern: np
<jam> fwereade_: dimitern: standup time
<jam> https://plus.google.com/hangouts/_/calendar/am9obi5tZWluZWxAY2Fub25pY2FsLmNvbQ.mf0d8r5pfb44m16v9b2n5i29ig
 * dimitern lunch
<jam> dimitern: for when you get back. If PendingUpload is false by default, then old clients will not set it (and it will be nil), I'm guessing that works correctly for compatibility? I just wanted to verify that.
<jam> jamespage: interestingly, you can't just "go get launchpad.net/juju-core/..." because mgo is labix.org/v2/mgo redirected to launchpad.net, so you have to go check that bit out manually. Anyway, I should have a working juju dev tool there now
<jam> rogpeppe: does godeps help get you to the right versions? or does it just populate the file?
<jam> I guess godeps -u does the right thing. ISTR that I tried it in the past and it didn't work, but looks like it did this time
<jam> mgz: it would appear that 'go test' still requires that you have a ~/.ssh/id_rsa.pub :(
<natefinch> jam,: FWIW, go get labix.org/v2/mgo works just fine.
<jam> natefinch: not on the bastion host with firewalled/proxied egress
<jam> which is what james set up for us
<jam> natefinch: but you're right that it does usually work
<natefinch> jam: ahh, ok, I missed that context
<mgz> jam: that was fixed and reintroduced several times I think
<rogpeppe> jam: godeps -u doesn't pull the right versions if they're not currently available
<jam> mgz: do you get 'strip' from build-essential?
<jam> it seems we have a part of the test suite that complains if there isn't an executable 'strip' in your path
<jam> mgz: ah, go bot *has* an ssh key because it has to to push stuff to LP, shame we don't enforce that stuff there.
<jam> well, installing build-essential got it for me, though we shouldn't really depend on it. And I thought strip wasn't safe on go binaries anyway (because it uses the debug info for reflect stuff)
<mgz> jam: I get it from binutils
<jam> fwereade_: did you get your destroy-machine changes from 1.16 into trunk?
<mgz> which doeswhich comes in via dpkg-dev
<jam> mgz: which certainly isn't what *we* should depend on for testing juju-core, right ? :)
<mgz> well, it's fine(ish) with build-essential
<jam> mgz: but isn't that stuff to build C/C++ stuff, which Go doesn't need?
<jam> also, for someone with more experience with local provider, does 'juju destroy-environment  local' properly nuke the Charm cache? There was discussion in #juju that it wasn't
<mgz> yeeeas
<fwereade_> jam, yes, they're in
<dimitern> jam, it should work even if PendingUpload is missing, when unmarshalled it will be false; that's the idea
<dimitern> rogpeppe, take a final look at this before I trow it away, will you? :) https://codereview.appspot.com/40290044/
<dimitern> *throw
<rogpeppe> dimitern: i've been on it :-)
<rogpeppe> dimitern: not far off posting the review
<dimitern> rogpeppe, cheers!
<rogpeppe> dimitern: i suggest evolving it not throwing it away, BTW...
<dimitern> rogpeppe, you mean devolving it like 40% and evolving another 15%
<dimitern> :)
<jam> dimitern: I don't think you would throw away much. The only bit that changes in "processPost" isn't it?
<jam> all of the work to move the auth stuff around you still need
<rogpeppe> dimitern: i think the changes (in charms.go anyway) will pretty much amount to throwing away 20 lines of code
<jam> and as rogpeppe mentions, the change is that you don't use a MultipartReader but something that checks the contet type and then reads the bytes into the temp file.
<rogpeppe> dimitern: we should chat with gary about the change too
<dimitern> yeah
<dimitern> i'm looking into it to minimize the damage
<jam> dimitern: arguably you just get ird of MultipartReader and go straight to the application/zip handler
<rogpeppe> dimitern: reviewed
<dimitern> rogpeppe, thanks
<jam> dimitern: rogpeppe: any idea why "juju deploy ubuntu" in trunk against a local 1.16.4 environment would give "service already exists" ? I'm seeing failure to deploy with trunk, but success with /usr/bin/juju ==1.16.4
<rogpeppe> jam: what does juju status show?
<jam> rogpeppe: juju status shows only machine-0 running
<jam> and then juju deploy gives me "service already exists"
<dimitern> jam, no idea off hand
<rogpeppe> dimitern: that does seem odd
<rogpeppe> jam: ^
<jam> dimitern: yeah, since you haven't actually finished what you're working on, I would have thought deploy in trunk is essentially unchanged
<jam> but it definitely seems repeatably broken :(
<rogpeppe> jam: yeah, i'd have thought that too
<rogpeppe> jam: i'd put some printfs into trunk and see what's going on...
<rogpeppe> jam: what does deply --debug print?
<dimitern> jam, it is unchanged
<jam> rogpeppe: nothing particularly helpful in this case
<jam> rogpeppe: you can see the --debug output here: https://bugs.launchpad.net/juju-core/+bug/1259925
<_mup_> Bug #1259925: juju destroy-environment does not delete the local charm cache <destroy-environment> <local-provider> <juju-core:Triaged> <https://launchpad.net/bugs/1259925>
<jam> rogpeppe: interestingly, after having called "juju destroy-service -e local ubuntu" and then trying again I get a slightly different (but still unhelpful) log: http://paste.ubuntu.com/6556054/
<jam> so now it is clearly not trying to upload the charm (good), but it still says the service already exists (bad)
<rogpeppe> jam: what do you see if you connect directly to the mongo instance and look in the settingsRefs and services collections?
<dimitern> rogpeppe, it seems you edited https://docs.google.com/a/canonical.com/document/d/1TxnOCLPDqG6y3kCzmUGIkDr0tywXk1XQnHx7G6gO5tI/edit#heading=h.t7svtxl846ha and most of the implementation got lost
<rogpeppe> dimitern: oops, will check
<dimitern> rogpeppe, ah, sorry, you just reformatted it to the top
<dimitern> rogpeppe, perhaps we can remove the footnotes and the history and leave only the implementation description
<rogpeppe> dimitern: i did, but i think i did miss some stuff
<rogpeppe> dimitern: i'd do that
<dimitern> rogpeppe, cheers
<jam> rogpeppe: "mongo localhost:37017/admin" doesn't actually let me do anything, am I spelling somethingwrong? (it gives me failures running 'whatsmyurl")
<rogpeppe> dimitern: it's all still available
<rogpeppe> dimitern: even if we remove it from the current version
<dimitern> rogpeppe, yeah, good point
<rogpeppe> jam: you probably need to connect in auth mode
<dimitern> rogpeppe, it actually much easier to handle binary post uploads and to test them in go than in javascript it seems
<rogpeppe> dimitern: you chatted to gary?
<dimitern> rogpeppe, just doing so now, as you see :)
<rogpeppe> dimitern: :-)
<rogpeppe> dimitern: i updated the charm upload doc to cut out all the old stuff
<dimitern> rogpeppe, cheers, looking
<rogpeppe> lunch
<mgz> gobblegobble
<dimitern> rogpeppe, URL vs Url comes from my C# days I guess :) and I didn't like it one bit then, glad to unlearn it!
<natefinch> rogpeppe, let me know when you're back and when you'd like to talk about next steps
<abentley> jcsackett, sinzui: AFAICT, the "Build Failure Analyzer" plugin does expose the failure type into the API.  I am disappointed.
<sinzui> :(
<abentley> s/does/does *not*/
<abentley> sinzui: If you have a chance, I'd like to do a pre-imp on the i386 thing.
<rogpeppe> natefinch: back
<rogpeppe> natefinch: hangout?
<natefinch> rogpeppe, sure
<rogpeppe> natefinch: https://plus.google.com/hangouts/_/calendar/am9obi5tZWluZWxAY2Fub25pY2FsLmNvbQ.mf0d8r5pfb44m16v9b2n5i29ig
<natefinch> did I miss you?  Sorry, my wife asked for help at an inopportune time
<natefinch> hmm.... seems to not be joining... weird
<sinzui> abentley, okay
<abentley> sinzui: https://plus.google.com/hangouts/_/76cpihrgnbqj3fqb0hu5umjbso?authuser=1&hl=en
<rogpeppe> natefinch: my machine display driver has just died
<rogpeppe> natefinch: i need to reboot, sorry
<jcsackett> abentley: ack. i share your disappointment.
<dimitern> gah, just finished with https://codereview.appspot.com/40290044/ and rogpeppe disappeared
<nate_finch> he's here
<nate_finch> in a hangout with me
<dimitern> send him the link pls nate_finch
<nate_finch> sure
<rogpeppe> grrr
<dimitern> rogpeppe, review poke
<rogpeppe> dimitern: ah, looking
<rogpeppe> dimitern: LGTM
<dimitern> rogpeppe, cheers
<dimitern> rogpeppe, you're sure about defer req.Body.Close() ? req.Body is a ReadCloser
<rogpeppe> dimitern: yeah
<rogpeppe> dimitern: from the docs for Request:
<rogpeppe> // The Server will close the request body. The ServeHTTP
<rogpeppe>         // Handler does not need to.
<dimitern> rogpeppe, yeah, was just about to say that
<dimitern> :) good to know
<sinzui> I am losing a fight with lbox. It complains I don't have vet. This probably relates to the fact I have a most of golang now in my local path to do cross-compiling
<rogpeppe> sinzui: if in doubt, you can do what i do, which is have an entirely separate golang repo and GOPATH. then go get lbox with GOPATH set to that
<rogpeppe> sinzui: with CGO_ENABLED to true or unset
<sinzui> rogpeppe, I think I have done that
<rogpeppe> sinzui: hmm
<sinzui> well GOROOT is pointing to system installed path. that looks like what is blocking me from go install
<rogpeppe> what do you see if you do go get code.google.com/p/go.tools/cmd/vet ?
<sinzui> rogpeppe, go install code.google.com/p/go.tools/cmd/vet: open /usr/lib/go/pkg/tool/linux_amd64/vet: permission denied
<rogpeppe> sinzui: BTW there's nothing in lbox itself that requires govet
<sinzui> ^ obviously not my intent
<sinzui> :(
<sinzui> lbox propose -cr -for=xxx seems to think I need it
<rogpeppe> sinzui: it's called by the .lbox.check script
<rogpeppe> sinzui: if you're using the system installed go, i'm surprised that vet isn't installed
<sinzui> maybe I am a victim of trusty
 * sinzui looks at packages
<rogpeppe> sinzui: i have to say i haven't used the system-installed go much - i usually pull the mercurial archive
<rogpeppe> sinzui: what if you chmod a+w /usr/lib/go/pkg/tool/linux_amd64, then run the go install command again?
<sinzui> ah, I will move my gopath to the start of my path to see if the right binaries are found
<rogpeppe> sinzui: unfortunately there's a special case in the go tool for installing tools
<rogpeppe> sinzui: it always installs them to $GOROOT/pkg/tool/$arch
<sinzui> rogpeppe, I don't want to touch /usr. I want to work in my $GOPATH. I may need to build out more go in my work dirs, or just remove the system go for now
<rogpeppe> sinzui: i suggest downloading the go distribution and having an entirely separate thing
<sinzui> rogpeppe, I think I did that to setup cross-compiling. I see vet in the src, but I don't think everything was built and installed
<rogpeppe> sinzui: what does "go env" print for you?
<sinzui> rogpeppe, informative: http://pastebin.ubuntu.com/6556978/
<TheMue> rogpeppe: the Tailer is in again *phew*
<TheMue> rogpeppe: and me is off for dinner, but will look again later for a possible review result ;)
<rogpeppe> sinzui: if you want to build go vet without sudo, you'll need to use a go binary from a different go root
<sinzui> agreed
<sinzui> still I wonder about where vet went to
<rogpeppe> sinzui: because "go get code.google.com/p/go.tools/cmd/vet" will always install to /usr/lib
<rogpeppe> sinzui: yeah, i'm surprised it didn't come with the package
<nate_finch> rogpeppe: back, sorry.... turns out we had the time wrong, so were a half hour early and had to wait around.
<rogpeppe> nate_finch: that's ok
<rogpeppe> nate_finch: just on a review currently but we can continue in a bit if you'd like
<rogpeppe> nate_finch: (i'll need to reboot again though :-[)
<nate_finch> yeah, no problem, sounds good
<nate_finch> (except for the reboot :)
<rogpeppe> TheMue: you have a review
<rogpeppe> nate_finch: that took longer than i thought it would, sorry, and now it's getting a bit too late
<rogpeppe> nate_finch: i've updated the Juju HA Notes document a reasonable amount
<nate_finch> rogpeppe,  yeah, I figured
<nate_finch> cool
<rogpeppe> nate_finch: since, you've been dealing closely with starting mongo recently, how would you feel about doing EnsureMongoServer ?
<rogpeppe> nate_finch: it would replace the existing cloudinit shell script logic
<rogpeppe> nate_finch: (eventually)
<nate_finch> yeah, that's what I was thinking
<rogpeppe> nate_finch: cool
<bac> hi negronjl, i've just proposed a branch for merging into the mongodb charm.  you seem like the right guy to review it and i'd like your feedback.
<negronjl> bac: I'll review it in a few ... thx for the heads up
<bac> np
<sinzui> I think trusty has hexed me. I am on go 1.2 now.
<sinzui> natefinch, do you have a few minutes to review https://codereview.appspot.com/41030044
<natefinch> sinzui, sure
<thumper> mramm: morning, there is no hangout associated with the meeting
<wallyworld> fwereade_: hi
<fwereade_> wallyworld, hey dude
<wallyworld> did you want a quick chat about that review?
<fwereade_> wallyworld, damn, I was meant to have thought more about something before I talked to you ;p
<fwereade_> wallyworld, yes, I will have to figure it out as I go along, just a sec ;)
<wallyworld> ok
<wallyworld> https://plus.google.com/hangouts/_/76cpiot72i7502oceu38mint0k
<wallyworld> fwereade_: https://codereview.appspot.com/39790043/
<wallyworld> davecheney: hey
<davecheney> wallyworld: o/
<wallyworld> i have a go yaml question
<davecheney> shoot
<wallyworld> i have a long string with a space in it. when go yaml marshalls it, it splits the string over two lines. this is bad
<wallyworld> since it breaks cloud init
<davecheney> wallyworld: so it's converting it to the | long form ?
<wallyworld> long form?
<davecheney> you can do
<davecheney> descriptoin: some string
<davecheney> or
<davecheney> description: |
<davecheney>    some really long string
<davecheney>    that rivals war and peace
<wallyworld> it's doing this....
<wallyworld> #cloud-config
<wallyworld> ssh-auth-keys:
<wallyworld>   - some really long string
<wallyworld>    some more of the string
<davecheney> hmm, that smells like a bug
<davecheney> can you email me the deatils
<davecheney> or something
<davecheney> and i'll make a test case
<davecheney> then i can fix the bug and have it reverted the next day \o/
<wallyworld> sure, will do. i want the whole string on the one line starting with the -
<wallyworld> what?
<wallyworld> did your --- fix get reverted?
<davecheney> wallyworld: i'm guessing the key you're having problems with is your own
<davecheney> so i guess you can't paste it :)
<wallyworld> davecheney: well, it's the public portion
<wallyworld> but the difference is that now i'm adding a key comment
<wallyworld> which is ppending to the key blob with a space
<wallyworld> and the yaml marshalling is splitting the string at the space
<wallyworld> but i need it all on one line
<davecheney> you sure do
<davecheney> that is where I thought it was braking
 * davecheney adds a test case
#juju-dev 2013-12-12
<wallyworld> davecheney: i got it to work by hacking the goyaml code and forcing a call to yaml_emitter_set_width
<wallyworld> so now i need to see if that can be done "properly"
<davechen1y> right, so it's related to yaml wrapping the output to some length
 * davechen1y applause
<wallyworld> davechen1y: so, there's a whole lot of unused config methods in the goyaml code. i was thinking of a new method MarshalWithOptions(in interface{}, options Options) where Options is a strut with attrs width, indent.  (just those initially, can add more later)
<davechen1y> wallyworld: there might also be a tag on the structure we can use
<davechen1y> buuuuuuuuuuuuuut
<davechen1y> that said
<wallyworld> there is no struct here
<wallyworld> it's just a map
<davechen1y> why should the ssh key like string be any different from a charm description
 * davechen1y is still investigating
<wallyworld> ok, i'll pause any work i'm doing wand wait to hear back from you?
<davechen1y> yy
<davechen1y> will have an update this arvo
<wallyworld> ok, i'll keep my hacked version for now so i can test
<wallyworld> davechen1y: fwiw, here's the code snippet i hacked
<wallyworld> func newEncoder() (e *encoder) {
<wallyworld> 	e = &encoder{}
<wallyworld> 	e.must(yaml_emitter_initialize(&e.emitter))
<wallyworld> 	yaml_emitter_set_width(&e.emitter, -1)
<wallyworld> my line is the last one above
<thumper> success
<thumper> ubuntu@tim-local-machine-1:~$ juju-run unit-ubuntu-0 'echo $JUJU_UNIT_NAME'
<thumper> ubuntu/0
<axw> hey thumper, how's the juju-run stuff going? I saw you had some success yesterday
<thumper> ubuntu@tim-local-machine-1:~$ juju-run unit-ubuntu-0 'echo $JUJU_UNIT_NAME'
<thumper> ubuntu/0
<thumper> working
<thumper> axw: just need to add a few more tests
<axw> cool :)
<thumper> and break it up for review
<thumper> just over 1k lines right now
<axw> thumper: that's just the server side part right?
<thumper> right
<axw> wallyworld: can you confirm that this is buggered? http://cloud-images.ubuntu.com/releases/streams/v1/com.ubuntu.cloud:released:azure.json
<axw> all I see is stuff for China
<wallyworld> looking
<wallyworld> axw: sure looks that way. index file also only has china entries
<axw> wallyworld: do you know who I ping?
<wallyworld> smoser or ben howard
<wallyworld> or i'd ask in #is cause they should have a copy from yesterday that can be restored
<axw> okey dokey, ta
<wallyworld> assuming that an older copy is ok
<wallyworld> i wonder when it changed/broke
<axw> hmm yeah I don't know if I can make that call, might have to just let scott/ben know
<wallyworld> i might have a look at the ci dashboard
<axw> wallyworld: it was working yesterday, I had been playing with Azure
<axw> but I don't know the reason for the change, so...
<wallyworld> axw: yep, looks like a recent breakage
<wallyworld> http://162.213.35.54:8080/job/azure-deploy/
<axw> ah only a couple of hours ago
<wallyworld> axw: i asked in #is
<axw> thanks wallyworld
<wallyworld> looks like no one is using the validation tools i wrote :-(
<axw> :(
<wallyworld> axw: how did you notice the breakage? did you try and deploy to azure?
<axw> wallyworld: yup
<axw> said it couldn't find any images
<wallyworld> axw: it's all borked. the bzr tree to hold the image metadata history hasn't been committed to. so we can't revert to any previous version. i'll just have to conact people to get it sorted
<axw> wallyworld: I left a message for smoser and utlemming on cloud-dev
<axw> presumably they're asleep :)
<wallyworld> yeah
<wallyworld> i'm a little disappointed
<wallyworld> hopefully there won't be a third time :-)
<wallyworld> since this is the second breakage
<axw> ah
<wallyworld> after the first breakage, i did the validation tools and bzr was set up for the metadata hisotry
<axw> ;)
<davecheney> axw: i figured out wtf was going on with the haproxy charm
<davecheney> just running a test now
<davecheney> you're going to love it
<axw> oh yes?
<davecheney> axw: i'll tell you if I was right in ~ 10 minutes
<davecheney> axw: hmm, well, that didn't work
<davecheney> let me try again
<davecheney> axw: http://paste.ubuntu.com/6559460/
<davecheney> see if you can figure out what im trying to do
<axw> davecheney: ?
<axw> I haven't used "charm" before if those steps have something to do with it...
<davecheney> charm get is just a shortcut for checking out the charm from lp
<davecheney> charm create just makes a skeleton
<davecheney> my theory is juju is parsing *all* the charms
<davecheney> overwriting one haproxy definition with another
<axw> ah, hm
<davecheney> put it another way
 * axw has no idea about that bit of code
<davecheney> if I renamed haproxy to memysql
<davecheney> mysql
<davecheney> the did juju deploy mysql
<davecheney> the service you get would be called haproxy
<axw> I can understand how that might work, since it's in the metadata...
<davecheney> conversely
<davecheney> if I have two chamrms who's metadata.yaml says they are 'haproxy'
<davecheney> the order in which they are evaluated it, well, random
<davecheney> the only sensible option is to reject a charm who's metadata name doesn't match it's containing directory
<davecheney> wow, this is getting even more weird
<davecheney> axw: right, new issue
<davecheney> juju deploy $CHARM && sleep 60 && juju destory-service $CHARM
<davecheney> leaks a machine
<davecheney> it'll probaby be reused later
<davecheney> but still, it'll sit there and cost you money
<axw> davecheney: yeah, I think that was discussed at SFO?
 * davecheney logs a bug
<davecheney> shit testing on ec2 is expensive
<davecheney> deploying 4 machines
<davecheney> takes < 15 minutes
<davecheney> so that is 4 tests an hour minimum
<davecheney> BUT
<davecheney> ec2 charge you a full hour for every machine you spin up
<davecheney> so that is 4x the cost
<axw> which is why I have been using my corporate Azure account :)
<davecheney> does azure charge by the hour ?
<axw> dunno, charges me nothing
<davecheney> \o/
<davecheney> axw: how hard would it be to get a timestamp on the sync bootstrap lines ?
<axw> davecheney: not very, I think
<davecheney> axw: that last bootstrap took 10 minutes
<davecheney> RIGHT
<davecheney> gotcha
<davecheney> I have a repro for this bizare issue
<davecheney> https://bugs.launchpad.net/juju-core/+bug/1260170
<_mup_> Bug #1260170: local charms are not deploy by filename <juju-core:New> <https://launchpad.net/bugs/1260170>
<thumper> anyone know if the gocheck *C Assert methods are goroutine safe?
<thumper> how batshit crazy is it to pass a *gc.C through to a go routine that I know will finish before the test finishes?
<thumper> davecheney, axw: got any comments?
<axw> hmm, I'm sure we do that around the place already
<axw> I'll see if I can find one...
<thumper> do we?
<jam> davecheney: there is a bug about having destroy-unit kill the machine it was on by default, but that hasn't been implemented yet AFAIK. And no, the machine won't be reused because charms don't generally clean themselves up properly.
<axw> thumper: not sure now
<thumper> cmd/jujud/machine_test.go:330:
<thumper> found one
<axw> cool
<jam> https://bugs.launchpad.net/juju-core/+bug/1206532 is probably the bug that will track it
<_mup_> Bug #1206532: --terminate option for destroy-unit <canonical-webops> <destroy-unit> <terminate-machine> <juju-core:Triaged> <https://launchpad.net/bugs/1206532>
<hazmat> destroy machine --force might work just as well for the use case as its destroying units
<hazmat> nice to have the default remove machine (or container) though
<davecheney> jam: really
<davecheney> even if the service was removed before the machine made it through cloud init ?
<davecheney> i've verified that the unit doesn't run through install and remove
<davecheney> the machien just sits there
<jam> davecheney: I don't know when the logic is to mark a machine dirty, but I believe it is when a unit is assigned to a machine, not when the unit fires its started hook
<jam> I think having "destroy-unit" tear down the machine as a first step is good, and then delaying when it is dirty is a further refinement
<davecheney> jam: i'm not really fussed about reusing the spare machine
<davecheney> the WTF is that it stays around
<jam> yep, that is what the bug is about
<davecheney> sort of like ^C'ing bootstrap
<davecheney> then having a bootstrap machine anyway
<davecheney> jam: fair enough, sorry for the dup
<davecheney> jam: this bug is far more fun, https://bugs.launchpad.net/bugs/1260170
<_mup_> Bug #1260170: local charms are not deploy by filename <juju-core:New> <https://launchpad.net/bugs/1260170>
<dimitern> jam, hey, I saw your comment about the test failure in loginSuite.TestLoginSetsLogIdentifier, here's a fix as you suggested https://codereview.appspot.com/37820051
<jam> dimitern: LGTM. I wasn't sure if your other branch would land without that fix, thanks for doing it
<dimitern> jam, thanks, better to be on the safe side
<dimitern> jam, it seems the bot hates me
<dimitern> jam, another random failure in an unrelated package, let's see if re-approving will help
<axw_> rogpeppe1: thanks for the review. the dnsNameErr is assigned to err because it's used in the error message. I'll add a brief comment to that effect
<axw_> rogpeppe1: "used in the error message" -- in the globalTimeout case
<rogpeppe1> axw_: ok, thanks - i missed that
<rogpeppe1> axw_: perhaps it might be nicer to use a differently named variable for it
<rogpeppe1> axw_: lastError or something
 * rogpeppe1 reboots
<rogpeppe> mgz: https://plus.google.com/hangouts/_/calendar/bWFyay5yYW1tLWNocmlzdGVuc2VuQGNhbm9uaWNhbC5jb20.8sj9smn017584lljvp63djdnn8?authuser=1
<mgz> rog, thanks
<axw_> mgz: rogpeppe mentioned you have some ideas about how to fix https://bugs.launchpad.net/juju-core/+bug/1258240 ?
<_mup_> Bug #1258240: juju 1.17.0 bootstrap on Hp fails <hp-cloud> <regression> <juju-core:In Progress by axwalk> <https://launchpad.net/bugs/1258240>
<jam> axw_: mgz: was that watching for BUILD(spawning) like we did in the API connect stuff?
<jam> axw_: ISTR that rogpeppe said if you just use DNSName we actually cache the value for it, which means that even though the instance got a new IP we won't actually use it
<jam> but I didn't read all of your last patch with the channels, etc
<axw_> jam: yep, that's right - my latest patch doesn't address that
<jam> axw_: so the latest patch *doesn't* actually fix HP cloud bootstrap, though it might be closer/
<jam> ?
<axw_> so we either actually refresh the DNSName, or do something else
<axw_> jam: right
<mgz> axw_: yeah, I have some wild ideas, and some simple ones. the easiest option is to wait for the instance state to be far enough along before trying to ssh
<rogpeppe> mgz: is it feasible to just make DNSName work correctly? (i.e. to not return the private address)
<axw_> jam: it also makes interruption quicker and allows for longer timeouts
<mgz> rogpeppe: it's poissible for the just-hp case
<mgz> we can't really make dnsname never return private addresses, as various deployments rely on having *some* address there in status even when machines don't have public addresses
<rogpeppe> mgz: in the end i feel there's no right answer, i guess - we might be bootstrapping from within the private network and public addresses might not be routable
<rogpeppe> mgz: but using a private address from outside the network is wrong
<mgz> another good option would be to not use waitdnsname, and instead look at the list of addresses, and defer till we get a usable one
<rogpeppe> mgz: there might be a valid local machine with the given private address
<mgz> again, that doesn't know about ssh config tricks as used with canonistack, but hey
<rogpeppe> mgz: and dialling its ssh port may well succeed
<mgz> indeed.
<jam> rogpeppe: case in point, the "private" address is the only address you generally use in Canonistack
<mgz> randomly trying to connect to 10. addresses is not a good idea
<rogpeppe> mgz: i wonder if there's no real solution other than giving bootstrap an flag that says "please use the private address"
<rogpeppe> s/an/a/
<rogpeppe> mgz: or i suppose there might be some trick we could play with ip configuration and netmasks
<jam> mgz: it isn't a particularly random 10. address, it was one that was assigned by a network :)
<rogpeppe> hmm, no that can't work
<jam> also, the Havana test cluster is controlled from within it's 10. address space, so again it *is* the routable address.
<jam> rogpeppe: so if you allow for VPN stuff, you could probably say "do I have a direct route to this address" and then you could use it.
<rogpeppe> jam: i don't think that works in general, does it?
<jam> It still doesn't work for Canonistack, but we might try axw's Idea of "ssh-tunneling: true" which would let us do it that way.
<rogpeppe> jam: you might have a direct route to the address,  but it might still connect to the wrong machine
<jam> rogpeppe: so we can special case the 10. and 192. and is it 176.?. ?
<rogpeppe> jam: what would the special casing do?
<axw_> why do we not just try all the addresses, preferring public first?
<jam> rogpeppe: those are the "these are only private networks" addresses, right? And then for things that aren't one of them, we assume it is publically routable
<rogpeppe> axw_: i thought about that, but i don't think it can work in general
<rogpeppe> axw_: sometimes we definitely want to use the private address
<rogpeppe> axw_: but
<rogpeppe> axw_: sometimes we definitely want *not* to use the private address
<jam> rogpeppe: I don't need it to work 100.% as long as it is in the high 9's and we can provide ways to force something.
<rogpeppe> axw_: and i'm not sure there's any automatic way of distinguishing the two cases
<axw_> rogpeppe: so it's not just that we can't route, but we can route and bad things happen ?
<rogpeppe> axw_: indeed
<axw_> ok
<jam> rogpeppe: axw_: I don't think particularly bad things happen, though.
<rogpeppe> axw_: the connection can potentially succeed, but we're not connecting to the right machine
<jam> It *is* possible that you have a home network that assigns identical IP addresses as a cloud that you want to provision on, and that your SSH key will work there, etc. But couldn't we check that the target is what we want once we're in?
<axw_> I think that's feasible. We'd need to forego the port check and go straight to SSH, but that's no big deal
<jam> axw_: well, we could still do the port check, and just still recover if SSH doesn't connect.
<jam> we'd need *some* care because of "I configured things wrong and it will never work"
<axw_> true
<jam> which is what we've seen in the CI stuff
<jam> but we do have the global timeout there
<rogpeppe> i guess we can make the ssh connection check the environ uuid or something
<rogpeppe> which is perhaps another good reason to generate the env uuid client-side
<rogpeppe> 'cos the ssh connection may succeed even if it's the wrong machine
<axw_> rogpeppe: any random thing would do, since the waitSSH bit comes just after we do cloud-init
<axw_> rogpeppe: this could also be used for the cloudinit/sshinit "wait for cloud-init to finish" bug
<axw_> i.e. plonk a file with some known random contents
<rogpeppe> i wonder if just having a flag saying "i'm bootstrapping in a private cloud - please use private addresses for connections" might be less magic and actually not too bad to use in practice.
<axw_> this is sounding slightly convoluted :)
<rogpeppe> juju bootstrap --in-cloud ?
<axw_> anyway, I have to head off now. I'll have another look tomorrow. If someone else wants to look at fixing the bug, just reassign - I clearly don't have the answer
<rogpeppe> actually, it's a problem for normal juju client usage too
<rogpeppe> axw_: ttfn
<jam> rogpeppe: it might, but it also is "1 more thing you have to set right in configuration" when we I think can get a 90% solution that doesn't require any configuration, and maybe provide a way to force it
<rogpeppe> jam: could you outline your proposal?
<wallyworld> jam: will you have any time to look at my remaining branches today (i think you are ocr?) or maybe i can beg fwereade_
<fwereade_> wallyworld, I think I should manage
<wallyworld> fwereade_: thanks :-) i made some changes based on your latest comments. there's also the auth worker one which you started before. plus the new ones
<wallyworld> for key manager service (2 branches) plus aut-keys list (1 branch)
<jam> wallyworld: I was taking a look at tim's stuff, but then I can try to get to whatever william doesn't
<wallyworld> np. sorry to be pushy. i don't want to have any remaining work to land
<jam> wallyworld: I understand
<wallyworld> i've got so many branches on the go my brain hurts trying to keep up with it all, especially when i have to make changes at the first one and push all the way down :-)
<jam> rogpeppe: if we just look for addresses, try them, and update what addresses we try as we go, it solves almost everyone's case except when they have an odd configuration with local 10.* addresses that happen to match the cloud's 10.* addresses. So I'd be fine with the ability to configure "never-try-private-ip-addresses" but I think we'll have more "It Just Works" if we try them, as long as we can detect if we shouldn't be there.
<natefinch> Mongo HA package is ready if anyone wants to take a look.  (Roger already looked at it, but seems like something others might be interested in): https://codereview.appspot.com/35790047/
<rogpeppe> jam: the "odd configuration" case may end up less unusual than you might think - it's quite likely to happen any time you deploy from from one cloud to a similar cloud (they're both likely to have similar and predictable private address allocation schemes)
<jam> rogpeppe: you still don't end up having to configure it more often than if we didn't try them by default, and it means we get it right when you don't need to configure it.
<rogpeppe> jam: do you think we should try dialling private addresses with normal juju client connections too?
<jam> rogpeppe: if that is the only addresses we have, certainly
<jam> I wouldn't use *different* logic between "juju bootstrap" and "juju status"
<rogpeppe> jam: what if we've got both?
<jam> I'd expect juju bootstrap to connect, and write down the API address it connected to
<rogpeppe> jam: what if we bootstrap within the cloud, then administrate from outside the cloud?
<rogpeppe> jam: (that's actually something that might be more common that not in the future)
<rogpeppe> s/that not/than not/
<jam> rogpeppe: so we still haven't quite sorted out if we're keeping the fallback case when the API endpoint is unavailable. But if we go to provider-state, and then see the instance has 2 addresses, we can try the more-public one first, and if it fails, fallback to the private one
<jam> rogpeppe: note that Canonistack is also configured that if you try to connect to the Public address from *within* the cloud, it will fail (you have to go private <=> private inside the cloud)
<jam> and while I don't think that is a common case, we *know it exists in the world* because we have one right here
<rogpeppe> jam: exactly
<jam> rogpeppe: I don't have a problem trying all the addresses we have for a node in some preferred order
<jam> rogpeppe: also note, we might have *many* addresses once we figure out modelling networking for juju
<rogpeppe> jam: i guess i feel that in that case it's even more important to try to figure out the right address to dial rather than just randomly connecting to all and sundry
<jam> rogpeppe: why not just try them in order
<jam> the wrong ones will fail
<jam> and TLS connect is much cheaper than SSH connect
<jam> rogpeppe: from a security standpoint, we still validate the Cert is valid
<rogpeppe> jam: they might fail, or they might not. i think we have to deal with the case where they don't fail too.
<jam> rogpeppe: how would they not fail?
<jam> rogpeppe: you expect someone to run a Server on port 17070 on their home network mirroring a cloud network, and then us not realize its the wrong location?
<jam> running the same Certs?
<rogpeppe> jam: ah, the tcp connection succeeds but the cert verification fails, yes
<rogpeppe> jam: it would be nicer if we could know which address to connect to though.
<jam> rogpeppe: that is what bootstrap *does*
<jam> it is still only a fallback case
<jam> rogpeppe: if bootstrap gets it right, then we record it in the .jenv
<rogpeppe> jam: when do we decide to fall back?
<jam> as "you can connect on this address"
<jam> rogpeppe: well, the HA story says we fallback if we fail to connect, right?
<rogpeppe> jam: i'm not sure we want to wait that long though
<jam> rogpeppe: "wait how long" ?
<rogpeppe> jam: for the connection to fail
<jam> rogpeppe: meh, this is only when *something fucked up*, not like we're doing this on a regular basis
<rogpeppe> jam: 'cos if we're trying the wrong address, it may take ages
<jam> rogpeppe: right, but only when the cached address is invalid
<jam> and when we manage to connect, we update the cached address
<rogpeppe> jam: really? if we're bootstrapping within canonistack, won't this happen every time?
<jam> rogpeppe: *once we connect we CACHE the working value*
<jam> rogpeppe: that's what the: state-servers: [] is for, right?
<rogpeppe> yeah
<jam> rogpeppe: we want to update that value when we have HA, so that we can fallback quickly anyway
<jam> we still haven't quite sorted out the fallback logic there
<rogpeppe> jam: i wonder if we should cache all the addresses but mark which one succeeded
<jam> (do we try the first always, do we try a random one, do we try all and use the first we succeeded on, etc)
<jam> rogpeppe: for each node?
<rogpeppe> jam: ?
<jam> rogpeppe: HA, we have potentially 3-5 servers with potentially multiple addresses each
<rogpeppe> jam: i think with no prior info, we should try a random one
<jam> which we'll try in some order
<rogpeppe> jam: we should probably try all the addresses at once...
<jam> I'd say cache values that have worked, and if we have a fallback that lists all possible addresses, use to discover if we're on the private ring or the public one
<rogpeppe> jam: or in random order staggered by some interval
<jam> rogpeppe: we could try all at once, but I think random order would be better, we have a high expectation that the first we try will succeed
<jam> otherwise we're coding wrong
<jam> if the control nodes are coming and going all the time
<rogpeppe> jam: yeah, that's pretty much what i was thinking of when i said "cache all the addresses but mark which one succeeded"
<jam> rogpeppe: I think a key point could be detecting what network it was that we connected to, and cache all API addresses on that network.
<rogpeppe> jam: we should perhaps cache all API addresses on all networks - the .jenv file might be sent over to another network
<jam> so if we have API1 = (1.2.3.4, 10.0.0.5), API2 = (1.2.3.5, 10.0.0.6), API3 = (1.2.3.6, 10.0.0.7), and we succeed on 1.2.3.5, then we'd write [1.2.3.4, 1.2.3.5, 1.2.3.6] and maybe the other set as a different fallback
<jam> rogpeppe: so we might, though I'd also say if we have a "fallback to reading provider-state, and listing all possible addresses" I would be ok with using that as the way to switch networks.
<rogpeppe> jam: some clients may not be able to read provider-state
<jam> rogpeppe: I don't think we have to solve all possible cases where nobody ever needs to edit the file, either
<rogpeppe> jam: i think it might be quite straightforward to cache all address info, but also cache some metadata that records last-known-liveness
<rogpeppe> jam: then we can use the last-known-liveness to guide our connection strategy
<rogpeppe> jam: but we still have all the info we need for falling back
<jam> fairy nuff
<rogpeppe> jam: useful discussion, thanks!
<jam> fwereade_: I have that we should be chatting with Mark now, but I don't know where, do you have an idea?
<fwereade_> jam, ha, is he not around, I was stuck out and just made it back
<jam> fwereade_: k: https://plus.google.com/hangouts/_/76cpiplgq36rl5ps8qckhpk6po
<smoser> wallyworld, are we sorted ?
<smoser> or still screwed
<wallyworld> smoser: i haven't checked, i
<wallyworld> ill look now
<smoser> looks broken
<smoser> i'll take a look and see if i can't kick something.
<wallyworld> smoser: still borked. azure metadata only has 2 chinese regions
<wallyworld> missing all the others
<mramm> jam, fwereade_: sorry I missed our meeting -- I seem to have come down with some kind of super-flu type thing
<fwereade_> mramm, ouch,bad luck
<wallyworld> jam: if you're still around, this fixes most of the issues you raised in the ssh utils branch. https://codereview.appspot.com/40870047
<bac> negronjl: thanks for the review and merge
<jam> wallyworld: commented
<wallyworld> jam: thanks, just fixing the rename thing. can't believe i didn't use that. i'm tired
<TheMue> rogpeppe: heya, next round, the Tailer is in again, more hardened, tests more elegant and no more race :)
<rogpeppe> TheMue: cool, looking
<abentley> sinzui: Have you seen the latest Azure failures?  "no OS images found for location..." http://162.213.35.54:8080/job/azure-deploy/68/console
<sinzui> abentley, you be psychic
<sinzui> abentley, I did, and I got email from wallyworld .
<sinzui> looks like cloud-images.ubuntu.com has streams data for images in china, but not else where
<abentley> Oh boy.
<sinzui> abentley, I replied that CI is not involved with os images or deployments, but it does show when Azure broken.
<sinzui> abentley, I think we have more arguments related to yesterdays discussion. We do want to test on revision changes, but we need to maintain a constant test to check the health of each cloud
<abentley> sinzui: Yesterday, you said you wanted to separate those concerns.  That still seems reasonable to me.
<sinzui> abentley, separation is good, but we wont switch to per commit runs until we have the health process in place
<smoser> wallyworld, ok.. good news and bad news.
<smoser> good news is i think we're fixed.
<smoser> bad news is all i did was "run the job again".
<wallyworld> \o/
<wallyworld> oh :-)
<smoser> i think timeouts / api failure on azure caused the issue.
<smoser> but clearly it should fail better than that.
<wallyworld> smoser: it would be good if you gated the release on running the validation tools successfully
<smoser> well, yeah. that is really utlemmings ball. i agree. and i think he would too.
<sinzui> timeouts on azure often cause spurious test failures for CI
<wallyworld> smoser: also the bzr branch to store the history?
<smoser> i dont know if there is one for that or not.
<sinzui> ^ abentley, I think we might see CI start passing again
<wallyworld> i tried to get #is to help me revert today but they said the was no hisotyr
<smoser> the code that i had done in the past did revision control the data, which is nice.
<smoser> but unfortunately, rolling back isn't always possible, since its  a moving target.
<smoser> (ie, images could have been deleted.. that issn't so much an issue with released, but with daily)
<wallyworld> better to run tests before release then :-)
<smoser> yeah.
<smoser> anyway, fire is out for now, i'm sure ben can take a look when he wakes up.
<wallyworld> thanks for helping
 * wallyworld -> bed
<rogpeppe> TheMue: reviewed
<TheMue> rogpeppe: thx
<bac> hey sinzui could you join us in #juju-gui?
<sinzui> smoser, wallyworld CI didn't pass azure a few minutes ago. Another test has started. Could we be experiencing replication lag?
<smoser> bugger
<smoser> now i'm wondering if i prematurely thought it was fixed.
<smoser> (versus if it regressed)
<smoser> sinzui, there is data there.
<smoser> http://paste.ubuntu.com/6561783/
<sinzui> thank you smoser. I see the data is there for West US where CI runs.
<sinzui> smoser, I think juju is looking in a different location that was published/regenerated:
<sinzui> http://pastebin.ubuntu.com/6561876/
<sinzui> which is
<sinzui> http://cloud-images.ubuntu.com/releases/streams/v1/index.sjson
<smoser> sinzui, hm..
<smoser> http://paste.ubuntu.com/6561902/
<sinzui> It's just the index isn't it. The actual data in com.ubuntu.cloud:released:azure.json is good
<smoser> that last pastebin there hits the index
<smoser> "hits" == "goes through"
<sinzui> smoser, I think I see. json is good, sjson is bad
<smoser> no. i hit the sjson.
<sinzui> smoser, http://cloud-images.ubuntu.com/releases/streams/v1/index.sjson only has china when I view it
<sinzui> but the .json version looks complete
<smoser> sinzui, you're right.
<smoser> and my usage of it just went "through"
<smoser> it is more lax and doesnt specificlaly limit. just crawls everything and then filters
<natefinch> jam, you around?
<mgz> natefinch: it's past his eod, so he may not be
<natefinch> mgz, I know, but figured it couldnt hurt to ask, sometimes he's on way too late :)
<smoser> :-(
<smoser> it looks like just about nothing is actually updating index.sson
<smoser> index.sjson
<smoser> this is very odd.
<jcastro> hey fwereade_
<jcastro> do you know the command syntax offhand to destroy a container?
<jcastro> so is it like "juju destroy-machine blah"
<jcastro> "juju destroy-machine lxc:3"?
<jcastro> I was thinking I might as well update the documentation as well
<smoser> sinzui, ok. i think we're almost fixed.
<sinzui> :)
<sinzui> smoser, I just bootstrapped.
<smoser> ill send mail on whats going on.
<sinzui> abentley, I got a successful bootstrap on azure. CI may pass azure in the next run
<arosales> mgz, fwereade_ you guys got a few minutes for a juju/maas/openstack sync?
<abentley> sinzui: Cool.
<natefinch> jcastro, should be destroy-machine 3:lxc:2  for lxc container #2 on machine #3
<abentley> sinzui: The current run was started after you bootstrapped.
<mgz> arosales: I can
<arosales> mgz, thanks
<marcoceppi> There's a question about contstraints and root-disk in #juju if someone could help out
<natefinch> marcoceppi: I can help... I wasn't in there before (need to reset my default channels)
<jcastro> natefinch, I was just told that doing a destroy-unit first will do the trick
<natefinch> jcastro, oh, yeah, it won't let you destroy the machine if there's a unit on it
<jcastro> destroy-unit, then destroy-machine will remove the container cleanly from the node
<fwereade_> arosales, sorry I'm on a call
<mgz> rogpeppe: is there any chance you'll get some time to look at the gojoyent provider review?
<rogpeppe> mgz: probably not today, if i'm honest.
<rogpeppe> mgz: it's huge
<rogpeppe> mgz: it probably needs a week
<rogpeppe> mgz: i'll try to skim it tomorrow
<mgz> rogpeppe: I think that's a slight overestimation :) I'll alos try and go over it properly tomorrow
<TheMue> rogpeppe: fighting with your reading goroutine in the assertCollected(). the goroutine blocks after reading the first bunch of data waiting for more.
<TheMue> rogpeppe: but this is sent with the second assertion where never data is received due to the new created channel
<rogpeppe> TheMue: could you push the branch? i'll have a look
<TheMue> rogpeppe: so have to use one reading goroutine for both asserts or find a way to sync. first way sounds better.
<rogpeppe> TheMue: yeah, of course
<rogpeppe> TheMue: you're creating two bufio.Readers on the same input
<rogpeppe> TheMue: so of course the first one reads too much data
<TheMue> rogpeppe: it's exactly the assertCollected() you sent, her line, err := reader.ReadString('\n') blocks
<rogpeppe> TheMue: the other possibility is to make the reader quit after exactly n lines
<mgz> dstroppa: I'm going to have a crack at working out the testservice http issue now
<TheMue> rogpeppe: hmm, would be possible, but like the other way more
<TheMue> rogpeppe: will do tomorrow morning, now dinner. :)
<dstroppa> mgz: cool, thanks. let me know if there anything you would need from my side
<TheMue> rogpeppe: hehe, we get a more general Tailer than it intentionally has been planned for
<mgz> the main thing that jumps out is the tests are dealing with an http.Response object directly and not being careful about cleanup
 * TheMue => afk
<mgz> but trying to quickly patch it in doesn't help
<mgz> we probaably want to provide some neater helpers that make it impossible to screw up the http connection between requests
<rogpeppe> mgz: how does not cleaning it up screw up the http connection?
<rogpeppe> mgz: i thought it was just a leak
<mgz> rogpeppe: it may not, but something odd is going on
<mgz> sec, Ill pastebin
<mgz> rogpeppe: http://paste.ubuntu.com/6562449
<rogpeppe> mgz: hmm, that does look odd
<rogpeppe> mgz: i don't think you can get that kind of thing by not closing a response object
<mgz> this is trunk lp:gojoyent (cd localservices/manta&&go test)
<rogpeppe> mgz: you're referring to closing the Body, right?
<mgz> rogpeppe: that kind of thing, but just adding those client side doesn't help, and seems like it might be the server side that's unhappy
<rogpeppe> mgz: yeah, i think it probably is
<rogpeppe> mgz: although...
<mgz> it's certainly requests-after-the-first related
<rogpeppe> mgz: it might be good to see what's actually happening on the wire
<mgz> as the failures change if you run a test with one sendRequest in isolation
<mgz> looks to be in the error handling path in localservices/manta/service_http.go
<mgz> something isn't quite right there...
<mgz> dstroppa: so, the #1 with these tests is they need to actually be independant
<mgz> rather than assuming they get run sequentially and have the stuff from previous one around
<mgz> this does mean we get larger, more ugly things for live testing
<dstroppa> that is what is was trying to avoid
<dstroppa> and why the test are numbered
<rogpeppe> dstroppa: it's a difficult issue - on the one hand you want tests to run as fast as possible. on the other hand, we've found that when one test relies on all the others before, the result can end up unmaintainable
<dstroppa> so the best practice is that all test are independent, right?
<rogpeppe> dstroppa: yes
<rogpeppe> dstroppa: that means that if a test fails, we can run it on its own to try and isolate the problem to a smaller amount of code
<dstroppa> rogpeppe, mgz: understood, will change my tests
<rogpeppe> dstroppa: and it makes it easy to add and delete tests without needing to know about the surrounding context
 * rogpeppe is done for the day
<bac> sinzui: would you have time/interest to do a quick charmworld charm review?
<sinzui> i do
<thumper> morning
<natefinch> thumper: morning
 * thumper sighs
<thumper> morning natefinch
<thumper> my flight options are back
<thumper> nz -> cape town via LHR?
<natefinch> ummm...
<natefinch> I had to go look at a map to see how bad that is.  It's pretty bad.
<bac> sinzui: oh, https://code.launchpad.net/~bac/charms/precise/charmworld/logrotate/+merge/198825
 * sinzui looks
<bac> thumper: wow, worst routing ever
<thumper> bac: yeah...
<thumper> I've replied and asked if I can go via Perth, AU
<thumper> much  more direct
<thumper> even via Singapore would be better
<thumper> it is like they aren't even trying
<wallyworld> fwereade_: still around?
<thumper> o/ wallyworld
<wallyworld> hey
<thumper> I've got to get dressed up in a red suit, wig and beard shortly
<wallyworld> ha ha ha
<thumper> go and play santa for a bunch of kids down the road
<wallyworld> thumper: ping me when back? i really need to try and get my work landed. too many branches are yet to be reviewed :-(
<thumper> wallyworld: ack
<thumper> wallyworld: we could trade reviews :)
<wallyworld> or 1/2 reviewed
<wallyworld> ok
<TheMue> thumper: heya. heard about the
<TheMue> thumper: Cape town tour. What kind of trip is it?
<thumper> TheMue: mid-cycle review with team leads
<TheMue> thumper: Ah, like the isle of man tour this year?
<thumper> TheMue: yeah, the isle of man is normally july
<thumper> TheMue: the jan/feb one is elsewhere
<thumper> I managed to avoid it in Jan
<TheMue> thumper: Ok, hard trip for many of you.
<thumper> I think it was SFO again
 * thumper shrugs
<thumper> you get used to it
<TheMue> Hehe
<thumper> I don't mind going via LHR for europe
<thumper> but via LHA for South Africa just seems dumb
<thumper> s/LHA/LHR
<TheMue> thumper: Is there no tour via bengaluru or so?
<thumper> wat?
<TheMue> thumper: They've got a large airport.
<thumper> where is that?
<TheMue> thumper: South india
<thumper> ah, singapore should also be an option
<TheMue> Banagalore on indian
<TheMue> Have to leave keyboard again, hope you'll find a relative stressless flight.
<hazmat> thumper, dubai has direct flights as well
<hazmat> to capetown
<thumper> cheers
<thumper> hazmat: air nz doesn't go to dubai
<hazmat> thumper, star alliance does... air nz doesn't technically go to capetown either.. its all partner setup.. there's a list of partners and connections here fwiw http://en.wikipedia.org/wiki/Cape_Town_International_Airport ...
<hazmat> singapore does look like the best one for you
 * thumper looks
<thumper> perhaps telling BTS the options would make it better
<thumper> otherwise I'm flying for freaking ever
<hazmat> thumper, i primarily use the interface at https://www.google.com/flights/  you can select air alliance, connecting airports etc.
<hazmat> its pretty slick
<thumper> ah, nice
 * thumper looks
<thumper> hazmat: flights from nz not supported, flights from singapore not supported
<thumper> dumb system
<hazmat> thumper, that's sad.. it works going to nz..
<sinzui> bac: LGTM, I can confirm production uses the same location as defined by the charm
 * thumper works on tests for the last pipe
#juju-dev 2013-12-13
<wallyworld> thumper: you around?
<wallyworld> i was hoping to see what i could get reviewed out of my remaining 4 (+ another 2 partially reviewed) branches
<thumper> wallyworld: I am now
<thumper> busy freaking week
<thumper> got back from the gym
<thumper> and Rachel is like "you forgot about Caitlin's end of year assembly didn't you"
<thumper> which is going now
<thumper> but there is no room
<wallyworld> oh no :-)
<thumper> ended up standing outside for a bit
<thumper> but I hadn't eaten
<thumper> so the combination of not being able to see and being hungry drove me home
<thumper> so here I am
<wallyworld> ta da
<wallyworld> thumper: i reviewed your branches. i looked at the first one john reviewed. i sorta agree it's a shame there is yet another socket/listener
<thumper> wallyworld: yeah, been thinking about that
<thumper> part of the issue was around lifetimes
<thumper> there is a note there somewhere to refactor the jujuc listener
<thumper> we should look to do that
<wallyworld> i got so confused trying to sort through that hooks code. hard to know what runs where when just reading it
<thumper> but somewhat out of scope for this change
 * thumper nods
<thumper> I know what you mean
<wallyworld> i wish there was some doc
<wallyworld> to explain all the moving parts
<wallyworld> thumper: so i'd be happy to discuss the current state of play with my branches if you want
<thumper> ok
<thumper> lets do it
<wallyworld> https://plus.google.com/hangouts/_/7ecpibd25ularnidet2ikrkeq8
<axw_> thumper: do you know who I need to ask to get access to the HP Cloud account?
<thumper> axw_: antonio?
<thumper> that'd be my best guess
<axw_> probably, I'll try him
<axw_> thanks
<thumper> or davecheney?
<axw_> speak of the devil
<axw_> davecheney: do I need to talk to arosales to get HP cloud access?
<thumper> axw_: and he shall appear :)
<axw_> or are you able to hook me up?
<wallyworld> thumper: any chance of doing the last branches?
<wallyworld> :-D
 * wallyworld flutters eyelashes
<thumper> wallyworld: yep, let me just finsih off these tests
<thumper> wallyworld: I'll look at the next one while I run make check
<wallyworld> ok ta
<wallyworld> big queue in the bot
<thumper> wallyworld: did you want jam to sign off on https://codereview.appspot.com/40870047/ ?
<wallyworld> thumper: nah. i reckon my explanation is ok
<thumper> so I don't need to look at that one do i?
<thumper> wallyworld: here is the last of the juju-run ones:  https://codereview.appspot.com/41660044
<wallyworld> thumper: don't think so
<thumper> kk, looking at your last
<wallyworld> and i'm looking at yours :-)
<thumper> it has been a busy landing day today
<thumper> you'd think we've been doing real work or something...
<wallyworld> thumper: with cloud init, will jujud be in place at the time the sym link is created?
<thumper> wallyworld: yes, but given the magic of symlinks, it doesn't matter if it isn't :)
<wallyworld> ok
<thumper> it is quite valid to make a symlink that points to something that doesn't exist
<wallyworld> thumper: done. you can almost EOW :-) is the sprint approved?
<thumper> wallyworld: yes, and I sent you an email about it
<thumper> you need to do the travel request form
<wallyworld> ah, too busy landing code to check :-)
<wallyworld> i'llbook my own flights
<thumper> wallyworld: you say to use cfg.jujuTools
<thumper> wallyworld: my answer is "no"
<thumper> wallyworld: jujuTools is the versioned directory
<thumper> we specifically want the one through the symlink
<wallyworld> ah ok
<wallyworld> sorry
<thumper> otherwise juju-run will never get updated when the machine updates
<wallyworld> igmore me
<thumper> I'll add a comment
<thumper> wallyworld: if you were confused by it, sure as eggs, the next person will be too
<thumper> hence the comment :)
<wallyworld> yeah, or i could just be stupid
<thumper> wallyworld: no, a very valid point, and the comment helps explain why
<wallyworld> well, the two assertions aren't mutually exclusive :-)
<thumper> hell pizza ordered
<thumper> $13 large pizzas for Friday the 13th
<thumper> ok, so last juju-run branch is in the landing chain
 * thumper EOWs
<wallyworld> axw: hey, any chance of a review of my last branch before i go away for a few days? it is hopefully the final piece in a series of branches to add ssh key management https://codereview.appspot.com/40690050
<axw> wallyworld: looking
<wallyworld> thanks :-)
<wallyworld> the bot is being a bitch for my previous branches
<wallyworld> a few spurious failures
<axw> wallyworld: dumb question: why is the default user "admin". shouldn't it be ubuntu?
<wallyworld> axw: it's the juju user which i believe is admin
<wallyworld> right now juju only has one user
<wallyworld> i think
<wallyworld> there is and AddUser api but i'm not sure what if anything uses it
<wallyworld> RBAC is coming though
<axw> wallyworld: all our ssh commands log in as "ubuntu@"
<axw> I'm a bit confused
<axw> I'm not aware of us creating an admin user
<wallyworld> it's the api user
<axw> ohhh
<axw> sorry
<axw> got it
<wallyworld> np :-) it is confusing
<axw> wallyworld: done
<wallyworld> axw: great thanks very much
<axw> np
<wallyworld> i'm not sure why the cmd doesn't support multiple keys
<wallyworld> perhaps it should
<wallyworld> i might make that change before landing
<axw> not a major issue, since it can be added later easily
<wallyworld> sure. but i'll add it as it's annoying me now :-)
<wallyworld> i'll also fix add and delete i think while i'm there
<axw> hehe
<axw> cool
<wallyworld> axw: commands fixed :-) i'll land unless you have an objections
<axw> wallyworld: go for it
<wallyworld> \o/
<TheMue> rogpeppe: ping
<rogpeppe> TheMue: pong
<TheMue> rogpeppe: I separated the goroutine, it's running fine
<TheMue> rogpeppe: but I would like to discuss the idea of the WriteCloser with you
 * rogpeppe tries to remember which goroutine
<rogpeppe> TheMue: ok
<TheMue> rogpeppe: the reader goroutine in the tests
<rogpeppe> TheMue: ah, of course
<rogpeppe> TheMue: go on
<TheMue> rogpeppe: the assert now uses the returned one and only string channel
<TheMue> rogpeppe: ok, WriteCloser
<TheMue> rogpeppe: the philosophy to use it has been, that it is simply an interface which allows the tailer to signal the writer that it doesn't has to expect more of the tailer
<rogpeppe> TheMue: i think that the tailer finishing is probably just as good a way to do that
<TheMue> rogpeppe: if I want multiple source write into one writer (which never has been the idea of the tailer, only all-machines.log) it's no problem to implement that interface with a kind of multiplexer
<rogpeppe> TheMue: ISTM that the tailer is just a specialised form of io.Copy
<TheMue> rogpeppe: w/o a Close the writer doesn't know that the tailer finished
<rogpeppe> TheMue: io.Copy doesn't close the stream it's writing to
<rogpeppe> TheMue: that's why I suggested adding a Wait method
<rogpeppe> TheMue: similarly to most other similar interfaces we have
<TheMue> rogpeppe: hmm, ok, that's an argument. but in that case the writer (or the using environment) needs perhaps a different way to know if the tailer has been stopped
<rogpeppe> TheMue: different from Wait?
<TheMue> rogpeppe: no, had written in while you wrote ;)
<rogpeppe> TheMue: ah, sorry
<TheMue> rogpeppe: so does the Tailer has a Wait? how would it be used?
<rogpeppe> TheMue: we'll almost certainly want a Wait method anyway, so the agent can know when it needs to restart the tailer
<TheMue> rogpeppe: hmm, can't follow
<rogpeppe> TheMue: Wait would work just like any other Wait method that we implement - func (t *Tailer) Wait() {return t.tomb.Wait()}
<rogpeppe> TheMue: we might want to also expose func (t *Tailer) Dead() <-chan struct{} {return t.tomb.Dead()}
<rogpeppe> TheMue: for convenience
<TheMue> rogpeppe: yes, but how would a writer implementation use it to get aware, that the Tailer has been Stopped by calling Stop()?
<rogpeppe> TheMue: so, (responding to your "can't follow"), something is running the tailer right/
<rogpeppe> ?
<rogpeppe> TheMue: why does it need to know that?
<TheMue> rogpeppe: yep, and passes a Writer, in my case one to write into a StringsWatcher
<TheMue> rogpeppe: to stop work when it runs in a loop (like the one you proposed in your review)
<rogpeppe> TheMue: so, assuming we have the machine agent running a Tailer, it presumably needs to know when the Tailer exits, so it can restart it
<rogpeppe> TheMue: it's trivial to Wait for the Tailer, then call Close on the Writer if that's what you need to do
<rogpeppe> TheMue: sorry, i'm not quite sure what you mean by "to stop work when it runs in a loop" - what's "it" there?
<TheMue> rogpeppe: take a look at the reading goroutine in your review. how do you think will it terminate?
<rogpeppe> TheMue: go func() {tailer.Wait(); pipeWriter.Close()}
<TheMue> rogpeppe: ah, ok, not as is but with a second goroutine
<TheMue> rogpeppe: feels a bit inconvenient to me, but it's ok. for an own implementation still would use the WriteCloser because I like to let a user implement an interface the best fitting way. but that's a different design philosophy
<TheMue> rogpeppe: so thanks, will add it and then repropose
<rogpeppe> TheMue: thanks
<rogpeppe> TheMue: i suspect when we use this for real, we won't want to close the Tailer immediately it finishes - we might want to append a message saying what's happened, for example.
<TheMue> rogpeppe: here I'm more defensive, the problematic word is "might" ;) the tailer already today does more than the existing requirements
<rogpeppe1> TheMue: i guess I'm saying that by doing less, it's actually more flexible
<TheMue> rogpeppe1: maybe. I so far reach mostly the same in my code by focus on interfaces
<rogpeppe1> mgz: standup?
<TheMue> rogpeppe1: next run, just proposed
<rogpeppe1> TheMue: ok, looking
 * TheMue => lunch
<rogpeppe1> I'm going to be travelling this afternoon, so proabably incommunicado most of the time
<rogpeppe1> natefinch: ^
<TheMue> rogpeppe1: thx for the review, and the index error inside the test data (missing the lines w/o termination) convinced me to use the mixed notation :D
<rogpeppe1> TheMue: thanks
<TheMue> rogpeppe1: I've got to thank you, has been a very good process
<rogpeppe1> TheMue: cool - sorry it took a while :-)
<TheMue> rogpeppe1: hehe, np
<TheMue> hmm, very quiet here today. did i miss a public holiday?
<rogpeppe1> TheMue: various people are on hols
<rogpeppe1> TheMue: malta has a public holiday i think
 * rogpeppe1 goes for lunch
<TheMue> rogpeppe1: ah, ic
<TheMue> rogpeppe1: thx and enjoy
<rogpeppe1> then i'll be out of touch for a while, depending on motorway 3G connectivity
<TheMue> gets empty here
<marcoceppi> If anyone with MAAS experience, heh, could help out in #juju, that'd be great
<jcastro> hi guys, I am still getting: agent-state-info: '(error: container "jorge-local-machine-3" is already created)' style errors with the local provider
<jcastro> fresh install, saucy
<rogpeppe2> natefinch: here's what i've ended up with for the concurrent connecting stuff: http://paste.ubuntu.com/6567727/
<rogpeppe> natefinch: it's probably not obvious how it is intended to be used, though
<jcastro> heya natefinch
<jcastro> https://bugs.launchpad.net/juju-core/+bug/1259350
<_mup_> Bug #1259350: juju bootstrap fails in Azure (BadRequest - The affinity group name is empty or was not specified.) <azure-provider> <bootstrap> <juju-core:Triaged> <https://launchpad.net/bugs/1259350>
<jcastro> any ideas on this one?
<fcorrea> hey there. Anyone here using the postgresql charm with an attached volume? A nova volume in this case
<fcorrea> I'm having trouble trying to get it to work and wanted to double check I'm not doing it wrong
<natefinch> fcorrea: sorry, most of the juju devs are out today for one reason or another.  You might try asking on #juju if anyone else has tried that.  I don't really know anything about nova, so not sure I can help much.
<natefinch> jcastro, looking
<fcorrea> natefinch, Will do. Thanks
<natefinch> jcastro: I wonder if azure changed their API... they've done that before
#juju-dev 2014-12-08
<axw> anastasiamac: sent you an email with a few links
<anastasiamac> axw: thnx :-0
<anastasiamac> axw: in terms of appeal - both content and presentation - I think that katco's spec is the winner :-)
<anastasiamac> axw: do u know what she used?
<axw> anastasiamac: yeah. nope, sorry
<axw> it's certainly more structured than others, which is good for a spec
<anastasiamac> axw: and I can see that she has used cucmber for user stories (functional testing)
<anastasiamac> axw: structure but also gr8 visuals
<menn0> waigani: doing this automatic env UUID filtering has exposed some things that were missed with the env UUID migrations
<waigani> menn0: that's good
<menn0> waigani: i've just spent a bit of time tracking down why my branch won't land and it's because EnvUUID wasn't being set on minUnitsDoc
<menn0> waigani: of course my upcoming branch would fix that automatically but I want to get the query side of things landed first
<waigani> menn0: do you want me to set EnvUUID on minUnitsDoc?
<menn0> waigani: it's ok,. i've just fixed the problem in my branch
<menn0> waigani: it would be good to know if the minUnits collection was migrated to use env UUIDs in 1.21 though or if that came after
<menn0> waigani: we might need to add an upgrade step in 1.22 that populates env UUID if it's missing
<waigani> menn0: it was migrated in 1.21
<waigani> menn0: adding another catchall upgrade step for missing UUIDs sounds like a good idea
<menn0> waigani: definitely
<menn0> waigani: I wonder if the existing upgrade step can just be re-run for 1.22?
<waigani> menn0: I'd have to take a close look when we come to actually doing it
<waigani> menn0: btw the test for your hack to upgrade state 1.20->1.21 fails with my branch, as state tests now have two states/envs by default. My solution is to destroy the second env and close the second state for that test.
<menn0> waigani: which hack is that?
<waigani> me
<waigani> menn0:
<waigani> 	// StateServerInfo contains a hack that assumes a single environment. This
<waigani> 	// hack is executed when environmentDoc is missing the env-uuid field, as
<waigani> 	// in the case below. As such, we destroy the other environment and close
<waigani> 	// OtherState to emulate the expected single environment state.
<waigani> menn0: test = TestStateServerInfoWithPreMigrationDoc
<menn0> waigani: right. i think what you've done is probably ok.
<waigani> menn0: it makes that test more ugly, but I think it is better to keep that test the exception and the  default to be for two envs to be set up for state tests
<waigani> as this is the new world that the code needs to work in
 * menn0 nods
<axw> davecheney: I'm going to move state/storage.go to a new package, state/storage, and state/tools.go -> state/storage/tools
<axw> davecheney: state/toolstorage -> state/storage/tools too
<axw> (just letting you know because you've been moving bits around in that area)
<menn0> waigani: the branch that automatically adds env UUID when querying is in
<menn0> waigani: http://reviews.vapour.ws/r/594/diff/ removes many of the docID calls that are now unnecessary
<menn0> waigani: can you PTAL?
<waigani> menn0: just gave it a shipit
<menn0> waigani: cheers
<davecheney> axw: -1 to two new packages
<davecheney> +0 to state/storage
<davecheney> as long as state/storage doesn't import state, i'm fine with this
<davecheney> tools is a shitty pacakge name
<davecheney> state/storage/storagetools  if you must
<axw> davecheney: state/storage is fine with me. it will not depend on state
<axw> I'll leave the existing toolstorage one alone then. never was happy with the name, but storagetools sounds like tools for dealing with storage rather than a place to store tools
<menn0> davecheney or axw: would you mind quickly looking over http://reviews.vapour.ws/r/594/ ?
<davecheney> menn0: LGTM
<davecheney> thank god for tat
<menn0> davecheney: and there's a lot more of that kind of thing coming up
<davecheney> nice
<menn0> damn... my last branch (already merged) broke upgrades
<menn0> reverting...
<menn0> waigani: hmmmm looks like there's no unit test for the pre-migration settings loading hack
<menn0> upgrade problem fixed without reverting. fix merging now.
<mattyw> menn0, ping?
<dimitern> jam1, 1:1?
<jam1> dimitern: yeah, brt
<fwereade> jam1, it's a public holiday and I'm going out for breakfast but I should be back for our chat
<jam1> fwereade: enjoy
<fwereade> anastasiamac, likewise, I should be free for ours later
<menn0> mattyw: hi. i've got to head out for a bit but i'll be back later on
<mattyw> menn0, no problem, I'm in gmt+8 at the moment so we can just discuss it tomorrow
<anastasiamac> fwereade: i'd rather talk tomorrow then :-) enjoy ur holiday!
<voidspace> jam1: dimitern: standup?
<dimitern> voidspace, omw
<jam1> voidspace: just a few, be there soon
<voidspace> dimitern: when you get a chance http://reviews.vapour.ws/r/596/
<dimitern> voidspace, sure, in a moment
<voidspace> dimitern: I'm taking a break anyway, so no massive hurry
<dimitern> voidspace, reviewed
<voidspace> dimitern: thanks
<dimitern> voidspace, please ping me if something is not clear
<voidspace> dimitern: I think the major concerns you have are entirely unwarranted :-)
<voidspace> dimitern: I will try to explain why
<voidspace> dimitern: after I get coffee
<dimitern> voidspace, :) ok, I'm listening
<voidspace> dimitern: I don't think there is any race condition at all
<voidspace> hmmmm... actually, *maybe* there is
<voidspace> dimitern: however you're incorrect about state filtering of addresses
<dimitern> voidspace, exactly - between the time you read the initial list of addresses and you try to add a new one
<voidspace> dimitern: right
<voidspace> dimitern: so we need to check the return value of AddIPAddress and retry on failure
<dimitern> voidspace, that one I rephrased several times - I understand what allocated map is for (name could be better yes)
<voidspace> dimitern: but TestPickNewAddressIgnoresUnavailableAndAllocated doesn't make sense
<dimitern> voidspace, well with that test now it will pass when it shouldn't
<voidspace> dimitern: no, more specifically
<voidspace> dimitern: see my reply to your comment on line 254 subnets.go
<voidspace> dimitern: and the for loop doesn't need a max tries - the algorithm guarantees it won't go on forever
<voidspace> doorbell (and coffee)
<dimitern> voidspace, yes - the map can be used to track all addresses, regardless of their state
<dimitern> voidspace, so the allocated map will work fine, just the retrying needs to be in place and the two-step allocation
<dimitern> voidspace, i.e. find an available address - create it as "unknown" if it still does not exist; if it does (regardless of state) - retry
<voidspace> yep
<dimitern> voidspace, sorry, now I realize PickNewAddress shouldn't mark the address as allocated
<voidspace> dimitern: no, it creates it Unknown for the provider to allocate (or fail)
<dimitern> voidspace, it should only add is as a placeholder ("Unknown") until tried to allocate it and either got OK (then set it to allocated) or error (set it to unavailable)
<voidspace> indeed
<dimitern> voidspace, yeah
<voidspace> AddIPAddress does this for us anyway
<sinzui> dimitern, voidspace perrito666 . Win builds broke. I think a win dep is missing: http://juju-ci.vapour.ws:8080/job/win-client-build-installer/1362/console
<dimitern> voidspace, ok, but it will be helpful to have a comment about it - before AddIPAddress, ideally in the PickNewAddress doc comment as well (... creates an address with AddressStateUnknown..)
<dimitern> sinzui, looking
<dimitern> sinzui, it appears the regression occurred quite some time ago - commit https://github.com/juju/juju/commit/99c2bcd0de788321a73d1c32ed5c114dbe9adb89 - Sept, 30
<dimitern> sinzui, were the windows builds not tested in a while?
<sinzui> We test EVERY run
<sinzui> and that is why we knew the regression from last week was fixed
<dimitern> sinzui, ok, I'll dig deeper then
<sinzui> dimitern, http://juju-ci.vapour.ws:8080/view/Juju%20Revisions/job/win-client-build-installer/1359/console is the last pass from Friday
<sinzui> I am looking for the candidate revs
<sinzui> dimitern, This is what we know about the windows failure https://bugs.launchpad.net/juju-core/+bug/1400344
<mup> Bug #1400344: Windows dependencies broken <ci> <regression> <windows> <juju-core:Triaged> <https://launchpad.net/bugs/1400344>
<dimitern> sinzui, I can't see how a missing dependency can cause this build failure and how it did pass before
<sinzui> dimitern, okay. For each release tarball, we due a redundant setup for cross compilation on windows for386 and amd64. That is what you may have seen in the log. I think that kind of ensures no one tampered with our go setup between runs. The script then build 386 to make the win client, then builds amd64 to make the win agent
<dimitern> sinzui, that sounds sensible to me
<wwitzel3> fwereade: ping
<fwereade> wwitzel3, pong
<wwitzel3> fwereade: oops, just saw the calendar, you're on holiday I won't bother you :)
<dimitern> sinzui, i'm still looking for the root cause though
<bogdanteleaga> stat_t doesn't exist on windows
<bogdanteleaga> if you're still on that
<fwereade> wwitzel3, if it's quick it's fine
<fwereade> wwitzel3, because then I can hit you up for a review of http://reviews.vapour.ws/r/598/ which is directly relevant to your interests
<fwereade> wwitzel3, ;p
<wwitzel3> fwereade: I wanted to chat about min version, probably not likely to be quick
<wwitzel3> fwereade: I will take a look
<fwereade> wwitzel3, ok, natefinch is hopefully circulating it among users for great clarity and sanity
<dimitern> sinzui, this is the commit that introduced the regression I think - https://github.com/juju/juju/commit/99c2bcd0de788321a73d1c32ed5c114dbe9adb89 (3 days ago)
<dimitern> katco, ping
<natefinch> ericsnow: sorry to hear you didn't get the job at Canonical
<ericsnow> natefinch: lol me too!
<katco> dimitern: howdy
<sinzui> dimitern, That is very interesting because there is *another* regression that relates to metadata. I just reported https://bugs.launchpad.net/juju-core/+bug/1400350
<mup> Bug #1400350: metadata_test consistently fails in ppc64el unit tests <ci> <ppc64el> <regression> <test-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1400350>
<katco> ericsnow: natefinch lol i JUST got the same email
<natefinch> katco: really?  That's hilarious
<ericsnow> katco: sorry to hear it!
<wwitzel3> fwereade: ok, thanks, there must be a doc I haven't seen yet, the doc I have for min version is basically blank :)
<katco> natefinch: yep. apparently i've outstayed my welcome! (sniff)
<ericsnow> katco: mine was from Good Luck Jonathan ;)
<dimitern> katco, can you tell me more info about this commit - https://github.com/juju/juju/commit/99c2bcd0de788321a73d1c32ed5c114dbe9adb89
<ericsnow> katco: j/k
<natefinch> ericsnow, wwitzel3, perrito666 : BRT
<katco> ericsnow: haha
<dimitern> katco, it appears it introduced a regression for windows builds
<katco> dimitern: it looks like ericsnow authored this?
<katco> dimitern: sorry, am i missing something?
<dimitern> katco, hmm..  sorry I meant https://github.com/juju/juju/commit/0c7de1a60355b3dfa3b5db23b9b5551680eae76e
<ericsnow> katco, dimitern: curse you syscall!
<dimitern> katco, it seems like a backport of some sorty
<katco> dimitern: ahhh ok
<dimitern> sort*
<dimitern> ericsnow, yay, windows :)
<dimitern> katco, but that seems a merge into some feature branch, not master, 1.21 or 1.20
<katco> dimitern: yeah trying to make sense of this. definitely a merge, but into what?
<natefinch> ericsnow, katco: https://www.youtube.com/watch?v=F4eCd6xUSik
<dimitern> sinzui, that ppc failure it due to the same thing btw
<dimitern> ericsnow, was that change necessary just to access the creation time of the backup?
<sinzui> dimitern, I agree, and jog just noted that the recent failures in run-unit-tests-precise-i386 are about that test
<katco> dimitern: ok, looks like that was me trying to land my leadership/lease branch. it wouldn't do an automatic merge so i merged locally.
<dimitern> katco, on master though, or?
<katco> dimitern: sinzui: do we have a test run from commit https://github.com/juju/juju/commit/216aa121c173b625f6417f3ac3ca8f960c862a38?
<katco> dimitern: yes on master
<dimitern> katco, right, thanks for confirming
<katco> dimitern: is this a regression on master, or 1.21, or?
<katco> nothing in my branch should have caused a regression unless i merged incorrectly
<sinzui> katco, I don't think that was the merged rev
<katco> sinzui: sorry, can you rephrase that?
<dimitern> katco, it appears it affects only master
<katco> dimitern: oh, well at least that's good news
<sinzui> katco, that rev isn't listed because git merged it as a different commit hash.
<wwitzel3> fwereade: I went through that code 3 times and I am disappointed to say I couldn't find anything wrong :p
<dimitern> katco, what you merged actually came from an earlier commit by ericsnow - https://github.com/juju/juju/commit/99c2bcd0de788321a73d1c32ed5c114dbe9adb89
<ericsnow> dimitern: yep, that's the one
<katco> dimitern: right... so... is it my code, or what i merged?
 * katco is a little slow pre-coffee o.0
<dimitern> ericsnow, and there's a related test - https://github.com/juju/juju/commit/d5044f634bbe569271f589de2f15ba7f3e1fece8 which will fail on non-linux environments
<sinzui> katco, I am looking at the range, but looking at http://reports.vapour.ws/releases, we can see when 1.22-alpha1 starts to fail
<dimitern> katco, it appears to me you've merged a bunch of changes, some of them earlier on master, but the merge overwrote some of the hashes or something - that's why it doesn't show the source immediately
<katco> dimitern: so i have performed the merge incorrectly?
<sinzui> katco, http://reports.vapour.ws/releases/2152 is the first build with that revision
<katco> sinzui: so http://reports.vapour.ws/releases/2150 is the more likely candidate?
<dimitern> katco, I don't think so - you've merged what was on master already - landed with ericsnow's https://github.com/juju/juju/pull/1238
<sinzui> katco, There are many regressions in master right now
<katco> dimitern: ah ok.
<voidspace> dimitern: I have something that automatically adds new imports when I need them - I almost never do them manually
<sinzui> katco there we have opened three so far, and we may open more when we know why manual env tests fail
<voidspace> dimitern: which is my excuse for how they *always* end up in the wrong place...
<voidspace> dimitern: I need to start checking them in the diff...
<voidspace> dimitern: sorry
<katco> voidspace: i have the same problem
<voidspace> katco: I have a foolproof way of checking them
<voidspace> katco: get dimitern to review...
<katco> haha
<dimitern> voidspace, I know, I use goimports as well - it does screw up sometimes when removing imports it can remove blank lines between groups
<katco> voidspace: we should really write a linter so these kinds of things don't clog up reviews
<voidspace> yep
<voidspace> sounds good
<voidspace> check for doc comments and a few other stylistic issues
<katco> yeah
<dimitern> katco, voidspace, I was actually considering proposing a patch for goimports to fix this, but the process is a bit long
<katco> that is one of my cardinals rules of reviews, let's not discuss style guidlines we've already agreed upon
<katco> dimitern: it would be much appreciated
<katco> dimitern: yeah looking at the diff b/t my fork and master, i don't think this would have caused a regression on other platforms: https://github.com/katco-/juju/commit/a632fb4237a2da1cebfcb136874bed665644d408
<katco> same thing from juju/juju perspective: https://github.com/juju/juju/commit/a632fb4237a2da1cebfcb136874bed665644d408
<dimitern> katco, it does look fine, although I just had a quick look around - checking for syscall and map comparisons
<dimitern> ericsnow, alright so you'll be fixing those two related to Stat_t ?
<katco> dimitern: lmk if i can help at all. otherwise moving onto planned work!
<dimitern> katco, sure, but if ericsnow is already on it I think it's fine
<ericsnow> dimitern: I'm going to fix bug #1400350 and I expect that will fix 1400344 too :)
<mup> Bug #1400350: metadata_test consistently fails in ppc64el unit tests <ci> <ppc64el> <regression> <test-failure> <juju-core:Triaged by ericsnowcurrently> <https://launchpad.net/bugs/1400350>
<katco> ericsnow: your job is on the line apparently! ;)
<dimitern> ericsnow, :) yeah, it appears so
<ericsnow> katco: lol, yours too!
<katco> ericsnow: haha
<ericsnow> natefinch: for the windows-only file I put "// +build windows" at the top, right?
<ericsnow> natefinch:  and "// +build !windows" for the non-windows file?
<natefinch> ericsnow: or _windows.go for the windows one (but yes, you need // +build !windows for the non-windows one
<ericsnow> natefinch: the filename doesn't impact the compilation related to windows, does it?
<ericsnow> natefinch: I have metadata.go, metadata_windows.go, and metadata_unix.go
<ericsnow> natefinch: the special-case files just defined the OS-specific functionality as a function that metadata.go calls
<natefinch> ericsnow: yes it does.  _<os/arch>.go will be treated the same as // +build <os/arch>
<ericsnow> natefinch: (on windows the func is empty)
<ericsnow> natefinch: sweet
<natefinch> ericsnow: I prefer the filename version because it's much more obvious... it's fairly easy to miss the build tag at the top of a file
<ericsnow> natefinch: agreed
<natefinch> (but you can't do fancy stuff like !windows with the filename version)
<ericsnow> natefinch: got it
<ericsnow> natefinch: if you got a sec, take a look: http://reviews.vapour.ws/r/599/
<katco> to be entertained: traceroute 216.81.59.173
<ericsnow> katco: nice!
<natefinch> traceroute isn't installed by default?  Geez, even windows has that preinstalled.
<natefinch> Also.... awesome.  Though they should slow down the ping times between them to give a more dramatic effect :)
<katco> natefinch: lol not sure if it's an actual network they need to work
<natefinch> katco: "damn, the web server is pegged again, go reboot 'against.the.evil.Galactic.Empire'"
<katco> natefinch: rofl
<voidspace> dimitern: about to finish this
<voidspace> dimitern: do you have something else I can move onto?
<voidspace> dimitern: I'm asking now so I catch you before you EOD
<dimitern> voidspace, just a sec
<voidspace> dimitern: sure
<voidspace> dimitern: I still need to write a test for the race
<voidspace> dimitern: although it's fixed
<voidspace> as are the other issues
<dimitern> voidspace, nice!
<dimitern> voidspace, there is one thing that comes to mind
<dimitern> voidspace, I believe we have what's necessary to implement Subnets() on ec2
<voidspace> dimitern: do we not have it?
<voidspace> dimitern: I thought we did
<voidspace> dimitern: Subnets(instanceId)
<dimitern> voidspace, I still see it as returning notimplementedf
<voidspace> dimitern: indeed, me too
<voidspace> I thought we had it
<dimitern> voidspace, we have it for maas
<voidspace> ok
<dimitern> voidspace, it should be quick and easy - returning all subnets (there will only be default vpc subnets for now, but that's fine)
<voidspace> dimitern: ok, do you know the ec2 call off the top of your head?
<voidspace> if not I can look into it and shout if I get stuck
<dimitern> voidspace, one quirk though - AllocatableIPLow and AllocatableIPHigh need to be set so we respect AWS limits
<dimitern> voidspace, the api call is DescribeSubnets, but in goamz it's called Subnets
<voidspace> right
<voidspace> dimitern: so we need to extend network.BasicInfo to include that info I think
<voidspace> dimitern: then possibly adjust the maas implementation to fill this in too
<dimitern> voidspace, the aws docs says the first 4 and the last ip in a subnet cidr are reserved I think
<voidspace> ok
<voidspace> I'll check on that
<dimitern> voidspace, but please double check
<voidspace> ok
<dimitern> voidspace, well we'll need to add the high/low range to network.BasicInfo anyway
<voidspace> dimitern: ok
<dimitern> voidspace, maybe even rename that to SubnetInfo ?
<voidspace> dimitern: I'll see how it's used elsewhere
<voidspace> dimitern: that sounds better for us
<voidspace> better in general
<dimitern> voidspace, yeah, I think it sounds better in the face of recent changes :)
<ericsnow> sinzui: two of the backups blockers should be fixed now (1400344 and 1400350)
<ericsnow> sinzui: (same fix)
<sinzui> thank you ericsnow
<ericsnow> natefinch: i've updated http://reviews.vapour.ws/r/557/
<ericsnow> natefinch: FYI, you're the only one who hasn't recused themself from a LGTM :)
<ericsnow> natefinch: if you don't feel up to it I'll see if axw will tackle it
<lazyPower> is there a way to specify the hookenv you want to execute a juju run command in? juju run -h doesn't say
<lazyPower> reason being, i'd like to see what was sent otw without entering debug hooks if i can get away with it - hackedbellini is experencing an issue wrt some data being sent by postgres and it seems really cumbersome to have to deploy a second unit, attach debug hooks, and step through an entire deployment to get at that data.
<marcoceppi> wwitzel3: ^
<wwitzel3> lazyPower: no, not currently.
<wwitzel3> lazyPower: in master we have the ability to do that with juju-run
<lazyPower> wwitzel3: ack, i figured that was the case for now.
<wwitzel3> natefinch: I'm going to grab lunch, want to talk gce when I get back?
<lazyPower> wwitzel3: wait - i just saw a drop in #juju from stub about juju run -r relation:id - is this the current trunk capability?
<ericsnow> natefinch: could you take a quick look at http://reviews.vapour.ws/r/600/ (for CI blocker)
<natefinch> ericsnow: looking
<ericsnow> natefinch: ta
 * natefinch gives ericsnow a ship it with a moral quandry.
<ericsnow> natefinch: k
<katco> have to run to the dr. bbiab
<natefinch> Dr Bbiab must have a hard time with people misspelling his name.
<natefinch> sorry his/her  ... don't want to presume
<voidspace> g'night all
<wwitzel3> lazyPower: yes, -r is in trunk for juju-run, but not juju run
<natefinch> wwitzel3: re: gce, yes, in a couple minutes
<wwitzel3> natefinch: sounds good, just ping me when you're ready
<natefinch> wwitzel3: I'm in moonstone
<wwitzel3> natefinch: omw
<ericsnow> natefinch, wwitzel3 mind if I join in?
<ericsnow> natefinch, wwitzel3: I'm going to assume not :)
<alexisb> natefinch, on the hangout when you are ready
<wwitzel3> alexisb: we are wrapping up some google provide hand off stuff, he'll be right there :)
<alexisb> wwitzel3, heh no rush
<alexisb> I have plenty to keep me occupied in the meantime
<menn0> does anyone know how to get the landing bot to look at a branch again when a previous merge attempt was manually cancelled?
<menn0> thumper: ^
<thumper> menn0: try the merge magic string again?
<menn0> thumper: I did that
 * thumper shrugs
<menn0> thumper: I think previously wallyworld had to do something
<menn0> thumper: it's something to do with the bot not seeing it's own fail message in the conversation
<menn0> I wonder if I just copy a failure from elsewhere...
<thumper> ah... sorry don't know what to do there
<menn0> thumper: I'm trying a few things. it's academic anyway since CI is blocked.
<menn0> thumper: that totally worked though :) I just copied a "Build failed..." message from elsewhere and then the bot was happy to consider the branch again.
<menn0> thumper: of course it didn't get anywhere due to CI being blocked
<thumper> haha
<natefinch> alexisb: hi, sorry, coming
<ericsnow> could I get a second opinion on http://reviews.vapour.ws/r/557/#comment5998?
<menn0> is anyone looking at bug 1400348?
<mup> Bug #1400348: Azure deployment broken <azure-provider> <bootstrap> <ci> <regression> <juju-core:Triaged> <https://launchpad.net/bugs/1400348>
<thumper> menn0: I have noticed a few intermittent failures in jujud around logging in during upgrade
<thumper> menn0: have you seen these?
<menn0> thumper: yep. there's a ticket for that which I plan on getting to soon.
<thumper> kk
<thumper> mramm: chat time?
<mramm> sure thing, I'm in the hangout
<thumper> mramm: so am I
<thumper> dumb googld
<thumper> menn0: care to look at that azure bug?
<menn0> thumper: I was thinking about it. i've already sent axw some questions for when he starts
<menn0> thumper: do we have a company account to access azure that I can use?
<katco> any lxc experts? could use some help debugging an issue in canonical/#juju
<menn0> thumper: or should I set up my own?
<thumper> menn0: could ask sinzui
<menn0> thumper: actually... I think I know where some creds might be
<sinzui> menn0, I can help
<menn0> sinzui: great
<menn0> thumper: I have what I need from sinzui so I'll start on that bug now
<thumper> menn0: thank you
<katco> axw: ping you on yet?
<anastasiamac> katco: it's about 7am where andrew is...
<anastasiamac> he usually jumps in in around 3hrs... just before our standup...
<anastasiamac> katco: well in about 2hrs now... :-)
<katco> anastasiamac: yeah just thought i'd check. do you recall if ian was working on an issue with certs and simple streams?
<katco> anastasiamac: it's ringing a bell but i can't place it
<anastasiamac> katco: both ring a bell
<anastasiamac> katco: i thought that he landed the cert stuff...
<katco> anastasiamac: i'm wondering if i'm thinking of this: https://bugs.launchpad.net/juju-core/+bug/1397909
<mup> Bug #1397909: State server certificate has empty SAN list <juju-core:In Progress by wallyworld> <https://launchpad.net/bugs/1397909>
<anastasiamac> katco: sounds rite...
<anastasiamac> katco: Merge pull request #1241 from wallyworld/update-server-certificate
<anastasiamac> katco: about 3 days ago...
<katco> anastasiamac: thanks, but if that's what i'm thinking of then it's not appropriate
<anastasiamac> katco: k :-)
<menn0> thumper: I can easily duplicate that problem but I'm having a hard time understanding why it's azure specific
<menn0> thumper: trying on ec2 now as a sanity check
<menn0> thumper: then will try to narrow down the commit but I'm pretty sure it's wallyworld's credupdater worker
<anastasiamac> katco: well done for solving that issue on #juju
<anastasiamac> katco: thnx for the email too
<anastasiamac> katco: emacs...
<katco> anastasiamac: mwhudson helped a lot
<anastasiamac> katco: team work is amazing :)
<katco> anastasiamac: np about the email. yes, i agree mentioning the word emacs brings calm and joy to an irc chatroom ;)
<katco> unlike the editor which shall not be named!
<mattyw> morning all
<katco> good morning mattyw
<mattyw> katco, what time is it for you?
<katco> mattyw: 17:35
<anastasiamac> katco:  m sure it thinks of itself as IDE not an editor
<katco> anastasiamac: what, emacs?
<anastasiamac> katco: IDEA
<katco> ah
<anastasiamac> katco: but m not racist and m happy to try emacs
<katco> what would be the correct term for one who discriminates against editors?
<katco> editorist?
<mattyw> katco, foolish?
<katco> mattyw: lol, yes i'd say so.
<mattyw> anastasiamac, what do you use at the moment?
<mattyw> anastasiamac, also - hi!
<anastasiamac> mattyw: hi :-)
<anastasiamac> katco: considering E in IDE is an environment = environmentalist?
<anastasiamac> mattyw: IntelliJ
<katco> haha
<katco> environmentalist, i like that
<anastasiamac> katco: :)
<anastasiamac> katco: but neither u nor I r that
<anastasiamac> katco: i just live conflict resolution GUI in IntelliJ
<katco> anastasiamac: absolutely not. i support everyone's right to use a totally-worse-than-emacs editor :)
<katco> </snark>
<anastasiamac> katco: m glad u clarified :-)
<menn0> thumper: so the CI blocker was definitely introduced by the 009aef5 merge
<menn0> thumper: it's a pretty big change which introduces a new jujud worker
<menn0> thumper:  git log  009aef5~..009aef5
<menn0> thumper: do I try to rip the whole thing out or try to fix the issue?
<menn0> thumper: I've ripped it out (only one conflict) and am running tests
#juju-dev 2014-12-09
<axw> katco: I'm on now
<katco> axw: howdy. we can talk in the standup, not urgent
<axw> okey dokey
<axw> ericsnow: do you still need a review?
<axw> I see Dimiter LGTMd
<ericsnow> axw: nope
<axw> cool
<ericsnow> axw: exactly :)
<thumper> menn0: ok...
<thumper> menn0: I'd prefer if we fixed the problem
<thumper> menn0: perhaps axw could help point in the right direction
<axw> thumper: I'm going to have a look at the same time
<axw> see if I can see why azure's special
<thumper> axw: ok, cheers
<menn0> thumper: yep i've been talking to axw
<menn0> thumper, axw: well anyway I have a branch ready with Ian's changes reverted. unit tests pass and bootstrap on azure works
<menn0> so we have that if we end up going that way
<thumper> ok cheers
<menn0> axw: I've added relevant details to the ticket (including the revs in question)
<axw> menn0: thanks
 * menn0 is desperate for lunch... back soon
<axw> I have nfi how it was ever meant to work, it's using juju-apiserver as the hostname to verify in the client, but the server doesn't have that in its list of host names ...
<axw> if we change the client, it'll reject old servers ... so we'll have to change the certupdater to add juju-apiserver to its list of names
<axw> menn0 thumper: I've got a one-liner fix, will propose after I add a test
<thumper> axw: awesome!
<axw> thumper menn0: I think the reason why this only affects Azure is because it doesn't record public IP addresses, only a hostname, and the verification step is skipped if connecting to an IP address
<menn0> axw: a one line fix sounds much better than reverting the change
<axw> menn0: RB hook seems to have gone MIA. mind reviewing here? https://github.com/juju/juju/pull/1287
<menn0> axw: looking now
<menn0> axw: looks good.
<menn0> axw: just one minor comment
<thumper> hmm... wondering why it picked up waigani's branch but not axw's
<axw> menn0: thanks
<thumper> axw: I agree with menn0
<menn0> axw: and (stupid question) you've tested this with azure?
<axw> menn0: yes :)
<menn0> axw: and some other providers?
<axw> nope, I will do before I land
<mattyw> davecheney, are you awake?
<menn0> axw: cool.
<menn0> axw: thanks for picking up where I left off and sorting it out
<menn0> really glad that the whole change didn't need to get pulled
<davecheney> mattyw: no
<axw> menn0: no worries
<mattyw> davecheney, no problem - sleep well
<waigani> thumper, menn0: when you have a moment, first pass: http://reviews.vapour.ws/r/602/diff/#
<thumper> k
<mattyw> davecheney, lucky for you I've answered my own question
<menn0> waigani: done
<menn0> mattyw: did you still want to chat? I have to duck out to do some errands. you'll be around for a while right?
<waigani> thumper, menn0: thanks
<thumper> I'm just waiting for the bot to be unblocked
<thumper> so I can land my branches
<thumper> this is a grunty review: https://github.com/juju/juju/pull/1289
 * thumper waits for RB
<thumper> http://reviews.vapour.ws/r/603/
<thumper> anyone bored?
<thumper> oh...
<thumper> it seems that github is much better at determining the diff than review board
<thumper> github has the files moved and edited, whereas RB just thinks they are new and deleted
<thumper> axw: tests failed
<axw> thumper: flaky CI
<axw> retrying
 * thumper sighs
<thumper> ack
<mattyw> menn0, I'll be around for a while, whenever is good
<anastasiamac> thumper: looks awesome :_)
<anastasiamac> thumper: just block remove tests r lost?..
<thumper> anastasiamac: I'm assuming you are meaning the branch :)
 * anastasiamac rools eyes
<thumper> anastasiamac: probably...
<anastasiamac> rolls even
<thumper> anastasiamac: I remember adding one, but that must have been add
<thumper> anastasiamac: add a comment and I'll add in the remove one too
 * thumper is now doing environment set/get/unset
<thumper> then remove
<thumper> well, destroy-environment
<anastasiamac> thumper: i have added comments
<anastasiamac> thumper: looking forward to new ones
<thumper> in preparation for "juju environment share/unshare/create" which will be behind a feature flag
<anastasiamac> thumper: supercommands r very neat
<thumper> assuming I ever get to land anything
<thumper> anastasiamac: ta
<anastasiamac> thumper: a pleasure - enjoy
<thumper> anastasiamac: re-declaring table tests
<thumper> anastasiamac: we have moved to declaring them with the tests
<thumper> inside the test func itself
<thumper> that way you don't have types or arrays lying around at package scope
<thumper> anastasiamac: I think you just get used to reading it all together
<thumper> anastasiamac: when I first started they were very separate, but it meant that the things being tested and the test that tested them were often far apart
<anastasiamac> thumper: hmm. it'd be great to have a separate setupTestData to generate tables
<thumper> why?
<anastasiamac> thumper: otherwise tests r looking sooo unnecesarily veerbose..
<anastasiamac> thumper: verbose even
<thumper> you may just have to trust me on this one
<anastasiamac> thumper: i have done them this way when i started
<thumper> but I can certainly point to poor examples of both
<anastasiamac> thumper: but eric pulled me on this
 * thumper will slap eric
<anastasiamac> thumper: eric is good - no slapping
<thumper> ericsnow: you still around
<anastasiamac> thumper: another way would be to use shims
<thumper> anastasiamac: as long as the body of the for block isn't too convoluted (and a few are), having it all together is better than the alternative
 * anastasiamac really like shims
<anastasiamac> is nz not in asian cup?!
<menn0> mattyw: ping?
<mattyw> menn0, pong
<menn0> mattyw: do you want to have that chat?
<mattyw> menn0, sure - is irc ok?
<menn0> mattyw: yep
<thumper> anastasiamac: for what?
<anastasiamac> thumper: soccer :-) what other sport is there?
<thumper> anastasiamac: I have a funny link for you
<thumper> SFW
 * thumper works out how to extract from facebook
<thumper> ah noo...
<thumper> seems like it has been removed
 * anastasiamac waiting for thumper to extract a link...
<thumper> https://www.youtube.com/watch?v=8F9jXYOH2c0 had to find it
<thumper> the person who originally shared it on facebook removed it
<anastasiamac> thumper: oh yeah, i've seen it
<anastasiamac> thumper: didnt like it :(
 * thumper is watching it again
<thumper> and laughing
<thumper> sorry
<anastasiamac> thumper: it's k - have ur moment :)
<thumper> third time I have watched that today, and it still makes me laugh
<thumper> Scott Sterling!!!
<menn0> thumper: on bug 1400358 now
<mup> Bug #1400358: TestLoginsDuringUpgrade broken on i386 <ci> <testing> <juju-core:In Progress by menno.smits> <https://launchpad.net/bugs/1400358>
<thumper> menn0: thanks
<menn0> thumper, axw : hmmm looks like that's also wallyworld's certupdater branch... the precise i386 unit test run has failed 100% of the time since that landed.
<menn0> thumper, axw : it fails intermittently for me
<thumper> hmm
<axw> fun
<axw> closed explicitly smells like a mongo connection being left open for a long time
<menn0> thumper, axw: I think I see the problem in the logs. the test that's failing is bringing up an entire machine agent and when the certupdater worker regenerates certs it kills the API worker which drops the connection used by the test and causes it to fail
<menn0> thumper, axw: I'll see if I can make the test do it's thing in a different way.
<thumper> haha
<thumper> damn
<axw> ah heh
<menn0> thumper, axw: i've never been that happy with that test and a few of the others on the same suite
<thumper> menn0: feel free to hack and refactor
<menn0> thumper: well I wrote this test in the first place :)
<thumper> ha
<TheMue> morning
<axw> fwereade: can you please take a look at this later? http://reviews.vapour.ws/r/589/diff/#
<fwereade> axw, thanks, will do
<axw> fwereade: one thing that feels a bit iffy to me is Source; it's there primarily because of shared storage
<fwereade> axw, ok, I'll keep that in mind
<axw> thanks
<axw> fwereade: I did also respond to your comments and make some updates to https://github.com/juju/charm/pull/77, but that's less important right now
<axw> the latter will feed the former
<fwereade> axw, yeah, sorry I didn't do that properly, I got grumpy about the bson requirement and then got distracted by something and haven't got back to it
<axw> fwereade: no worries
<mattyw> fwereade, ping?
<mattyw> jam1, ping?
<jam1> hey mattyw, just otp now
<voidspace> dimitern: when you get a chance, this has been updated http://reviews.vapour.ws/r/596/
<voidspace> dimitern: the race condition is tested
<voidspace> dimitern: it occurs to me that the race is tested by mocking out the rand.Int63n call - so it doesn't actually *need* to be tested with concurrent goroutines
<voidspace> dimitern: testing sequential calls would still be the same test
<voidspace> dimitern: and that would simplify the test a great deal
<voidspace> dimitern: let me know what you think
<voidspace> dimitern: I'm on ec2 Subnets - so no great hurry
<dimitern> voidspace, I'm back just now -- I'll have a look after standup
<voidspace> dimitern: cool
<jam1> dimitern: voidspace: standup?
<dimitern> jam1, omw
<voidspace> jam1: dimitern: TheMue: I got booted out
<voidspace> jam1: dimitern: TheMue: probably need to re-auth
<voidspace> sorry
<voidspace> I was done anyway
<jam1> voidspace: then good riddance anyway :)
<voidspace> hah
<voidspace> it won't let me login
<voidspace> :-/
<jam1> voidspace: sorry, I didn't want to have to tell you this way... :)
<voidspace> jam1: :-)
<anastasiamac> fwereade: big storm on the way here... if i'll lose internet, I am y not b able to talk to u
<anastasiamac> s/y/
<fwereade> anastasiamac, if you think that's likely, we could talk sooner? I'd like a *bit* of time to tie up some loose ends with what I'm doing though...
<anastasiamac> fwereade: k. let me know when u r ready ;-)
<perrito666> morning all
<dimitern> voidspace, reviewed
<dimitern> morning perrito666
<voidspace> dimitern: thaks
<voidspace> *thanks even
<dimitern> :)
<anastasiamac_> fwereade: it looks like z storm passed, internet flickered but stayed... I can make allocate time - please do not rush!
<perrito666> anastasiamac_: zombie invasion?
<anastasiamac_> perrito666: lol ;-)
<anastasiamac_> perrito666: with lighting bolts!
<anastasiamac_> perrito666: and hail :-0
<anastasiamac_> perrito666: we maybe not in canada (http://news.nationalpost.com/2013/02/13/canada-will-never-be-a-safe-haven-for-zombies-foreign-minister-john-baird-tells-house-of-commons/)
<anastasiamac_> perrito666: but we r still pretty hard to invade -.-
<perrito666> lol
<voidspace> dimitern: fixed those minor issues and merging
<dimitern> voidspace, cheers
<fwereade> anastasiamac_, ha, thanks, it turns out I'm *just* coming up to done now anyway :/
<anastasiamac_> fwereade: perfect :-) tyvm for ur time! I'll c u in a few :-)
<fwereade> GAAAAH if err == nil { return err }
<perrito666> meh some diffs are so hard to follow
<perrito666> fwereade: well, ugly but functional :p
<perrito666> dimitern: could you add your blessing to http://reviews.vapour.ws/r/601/ ? :p it is a 4 line diff and I dont have superpowers
<dimitern> perrito666, sure, will have a look in a bit
<perrito666> tx
<natefinch> I "ship it!"ed it
<dimitern> perrito666, ship it
<perrito666> we all shipit'ed now its wwitzel3's problem
<perrito666> :p
<perrito666> I just didn't feel like having him wait 12hs until my mentor was back online
<TheMue> Gna, provider seems to have a DNS problem. Sometimes names are directly resolved, sometimes I need a number of retries. :(
<ericsnow> natefinch: standup?
<wwitzel3> ericsnow: ping
<ericsnow> wwitzel3: ready?
<wwitzel3> ericsnow: yep
<perrito666> ericsnow: 15 conflicts only, not bad
<perrito666> bbl
<ericsnow> perrito666: sweet! :)
<natefinch> back from purgatory
<natefinch> katco: turns out, I'm in the minority in thinking of Missouri as "The South": http://fivethirtyeight.com/datalab/which-states-are-in-the-south/
<katco> lol
<katco> natefinch: well, i narrow my claim to St. Louis
<katco> there are some pretty "southern" areas of MO
<katco> but STL is pretty metropolitan/urban
<natefinch> katco: heh.... what's funny is the people claiming Pennsylvania is the south... must be all those Mainers ... "Ayuh, that's pretty fa' south"
<katco> natefinch: lol PA? wow
<natefinch> right?
<katco> there should just be some latitudinal line that defines it and we should leave it at that lol
<natefinch> katco: what, like some sort of mason-dixon line? http://en.wikipedia.org/wiki/Mason%E2%80%93Dixon_line
<natefinch> http://en.wikipedia.org/wiki/Mason%E2%80%93Dixon_line#Symbolism
<katco> natefinch: well, maybe a bit more scientific :)
<katco> natefinch: like subdivide the country into two mostly-equal halves. below, south. above, north.
<natefinch> katco: anything that separates me from Kentucky and West Virginia is good in my book.
<katco> haha
<katco> natefinch: i can't tell you the angst i feel when people lump STL into that category
<katco> natefinch: because mostly it's like any other largish city
<katco> except out downtown really sucks.
<katco> "downtown"
<katco> no one lives downtown
<katco> or very few
<natefinch> katco: right... pretty much all cities are fairly progressive...
<natefinch> katco: yeah, downtown-downtown Boston is very expensive to live in, so not a lot of people do, but there's some subsections of Boston that are really crummy.
<katco> natefinch: well, that implies it's desirable to live in downtown boston. our downtown has very very little residential. and like 1 supermarket.
<katco> natefinch: conversely, what st. louisans define as "St. Louis" is *huge*, so there are some really nice "sub cities" of St. Louis
<natefinch> *nod*  People like downtown Boston because you're close to work and theaters and night life.
<katco> natefinch: e.g.: clayton, a largish "sub city"'s skyline: http://farm3.static.flickr.com/2191/2400264760_711ff5fb2d.jpg
<katco> natefinch: and stl's: http://stormhighway.com/stlouisphotos/skyline/east-view-clear-sky-panorama-e-1330pan.php
<katco> natefinch: claytons is about as big, and it's a much nicer city
<natefinch> *nod*
<katco> i wish we would have had more time when we were in boston to explore
<natefinch> katco: yeah, that's one thing I dislike about the sprints... not much time to explore.  And the problem with you guys being in Lexington is that it's just so far from Boston... at best you're a 30-40 minute car ride without traffic.
<katco> yeah
<katco> i got kind of a nice driving tour on the way back to the airport
<katco> too bad the driver was a racist homophobe
<natefinch> ouch, sorry :(  I guess those sorts live everywhere.... someday they'll all have died off, and the world will be a better place.
<katco> natefinch: https://plus.google.com/u/0/100662126766165980060/posts/B2mzGaPVbfM
<ericsnow> natefinch: you have a minute?
<ericsnow> natefinch: wwitzel3 and I are on moonstone
<natefinch> ericsnow: brt
<natefinch> fwereade: don't suppose you're around?
<fwereade> natefinch, kinda
<natefinch> fwereade: I just noticed that environs.EnvironProvider.Validate returns a (presumably modified) config.Config.... so no matter what changes I make to the provider's own configuration struct... they all need to be encapsulated in the config's map[string]interface({} thingy
<fwereade> natefinch, yeah, sorry, I evidently didn't make that wrinkle clear enough last time we chatted
<fwereade> natefinch, whatever you do needs to be trivially convertibleback to an m[s]i
<natefinch> gah
<fwereade> natefinch, it's not intrinsically enough to sink the idea but it's a complication for sure
<fwereade> natefinch, OTOH it's just one extra method on the struct type really
<fwereade> natefinch, might easily turn out to be worth the effort
<natefinch> fwereade: yeah, I'll see how it looks
<natefinch> fwereade: what confused me was that we build up this valid environConfig struct.... but then we throw it away and just return the modified config.Config: http://bazaar.launchpad.net/~fwereade/juju-core/provider-skeleton/view/head:/provider/skeleton/provider.go#L71
<thumper> sinzui: the landing bot is out of disk space, what do we need to do?
<natefinch> thumper: pay for a bigger disk :)
<natefinch> thumper: and/or fix whatever is leaking files
<thumper> hmm...
<thumper> euca-create-tags: error (InvalidInstanceID.NotFound): The instance ID 'i-79999a93' does not exist
<thumper> Test failures, reporting on proposal
<sinzui> thumper, I have no experience with the landing bot, but I am very good at deleting everything in /tmp and zillions of tarballs left behind
<natefinch> heh
<fwereade> natefinch, yeah, the main point there is to make sure there OAOO validation path that's shared by both the config-level stuff and the env.SetConfig stuff
<thumper> sinzui: why does the landing bot think it is something else?
<fwereade> natefinch, so long as that property stays I'm not bothered what path we take to get it
<fwereade> natefinch, within reason
<thumper> sinzui: looking at http://juju-ci.vapour.ws:8080/job/github-merge-juju/1573/console
<natefinch> fwereade: I always try to stay within reason :)  (within reason) ;)
<thumper> sinzui: who does look after the landing bot?
<fwereade> natefinch, haha
<thumper> rick_h_: you have some understanding of the landing bot yes?
<sinzui> thumper, ah. well that isn't the merge job. that slave has 23G free
 * sinzui looks
<ericsnow> thumper: mgz maintains the landing bot, no?
<thumper> sinzui: the previous attempt failed last night with out of disk space
<thumper> I tried again this morning, and got the above error
<sinzui> thumper, I think that error means ec2 expired the ami and we need a new one
<thumper> huh? and why?
<thumper> how do we get a new one?
<rick_h_> thumper: yes, wrote the originaly
<sinzui> yep the juju-core-slave really has 24G free and the most full partition is just at 18%
 * sinzui looks up instance and ami
<thumper> rick_h_: seen the error listed here? http://juju-ci.vapour.ws:8080/job/github-merge-juju/1573/console
<rick_h_> thumper: that's not the landing bot but the job that's running and it's config
<rick_h_> ++ /var/lib/jenkins/juju-ci-tools/ec2-run-instance-get-id
<rick_h_> was run and seems it found a non-existant instance on there?
<thumper> so just CI stuff...
<rick_h_> thumper: yea, the landing bot doesn't directly touch the cloud, just github api
<thumper> ah
<thumper> kk
 * thumper is frustrated
<thumper> it has been over a week since I have been able to land code, and now the bot is unblocked, I still can't land stuff
<thumper> heh, and now hangouts hate me
<thumper> "there is a problem with this call, please try again in a few minutes"
<waigani> thumper: tried firefox?
<thumper> almost feel like checking the whole day in now
<thumper> s/checking/chucking/
<thumper> sinzui: any info about the instance id?
<sinzui> thumper, still looking...I think the id was hardcoded, damn it
<perrito666> thumper: hey you reviewed http://reviews.vapour.ws/r/547/ with -1 unless changes where made, I see changes plus I asked the author to file https://bugs.launchpad.net/juju-core/+bug/1400782  which he also offered to address, with all that, do you still -1?
<mup> Bug #1400782: Errors returned by the system are improperly wrapped. <system-errors> <juju-core:Triaged> <https://launchpad.net/bugs/1400782>
<perrito666> aaan, good morning also
<sinzui> thumper, I have setup the unittests to use a much new ami. you can retry $$merge$$, and we can watch to verify the ami and the instance-type are happy
<natefinch> dammit, there's an update for chrome (which has been super unstable in utopic)... and apt-get can't download it for some reason
<perrito666> natefinch: its apt's way to say "stop hitting yourself"
<natefinch> perrito666: ahh, now it's working
<natefinch> perrito666: if you can call a 54kB/s download "working"
<perrito666> natefinch: you would not know how often I call that working :p
<perrito666> natefinch: that usually is your mirror being crappy, just open the conf thinguie and choose a different one
<natefinch> perrito666: hrm, but it's the chrome PPA, so I don't think I can choose a mirror for that
<perrito666> ah, you are on your own then :p
<thumper> sinzui: ack
<thumper> sinzui: trying again now
<thumper> perrito666: I've said shipit now
<thumper> perrito666: I'm still not 100% happy, but we can fix it later
<perrito666> thumper: I am not either, I only said I would go ahead with accepting that solution if the bug was created and addressed
<thumper> perrito666: ack
<katco> well that's a first
<katco> refactoring some tests, and i've missed patching a value. brought my system down
<natefinch> doh
<mbruzek> Does anyone know what causes this error http://pastebin.ubuntu.com/9447169/  or how to resolve?
<natefinch> thumper: ^
<davecheney> thumper: i'm getting trolled on twitter for something canonilca has done
<davecheney> have we released anothe rproduct ?
<davecheney> oh, http://www.markshuttleworth.com/archives/1434
<mbruzek> davecheney: Snappy Ubuntu Core is the new hotness
<mbruzek> davecheney: Do you know how I would resolve this error? http://pastebin.ubuntu.com/9447169/
<davecheney> mbruzek: getting trolled on twitter 'cos there is no code
<davecheney> i'm inclined to agree
<davecheney> mbruzek: looks like you're deploying on i386
<mbruzek> davecheney: How would I have done that?
<mbruzek> davecheney: how do I change it?
<davecheney> dunno
<davecheney> just trying to decipher that paste failuyre
<davecheney> basically lxc shat itself
<davecheney> why ? is not clear
<mbruzek> davecheney: when I do lxc-ls --fancy I see no images.
<mbruzek> but I have an image bootstrapped.  There should be some image out there yes?
<menn0> mbruzek: you're doing that as root right? if you do it as your own user you won't see any lxc images.
<mbruzek> sudo lxc-ls --fancy     yes I am using sudo
<menn0> mbruzek: just checking. i've been caught by that before.
<mbruzek> menn0: Yes and thanks for double checking.
<thumper> davecheney: yeah
<menn0> mbruzek: what does this give you? : sudo ls /var/lib/lxc
<menn0> mbruzek: also: lxc-ls --version
<mbruzek> sudo ls /var/lib/lxc
<mbruzek> lxc-monitord.log
<urulama_> thumper: that xamarin looks cool, thanks
<mbruzek> version 1.0.6
<thumper> urulama_: are you doing mobile dev?
<menn0> mbruzek: looking at the error it looks like ubuntu-cloudimg-query wasn't found in the $PATH
<menn0> mbruzek: what does "type ubuntu-cloudimg-query" give you
<urulama_> thumper: yeah, i did ... don't have time currently though
<thumper> urulama_: that I get
<menn0> mbruzek: if it's missing you'll need to install cloud-image-utils
<urulama_> thumper: i like doing it directly with ios or android ... but this does look cool. gotta check it out
<mbruzek> menn0: I see one in ~/.cache/ubunu-cloudimg-query
<mbruzek> bash: type: /home/mbruzek/.cache/ubuntu-cloudimg-query: not found
<menn0> mbruzek:: on my machine it's in /usr/bin... and it comes from cloud-image-utils
<menn0> mbruzek: do you have cloud-image-utils installed
<mbruzek> It does not appear that I do.
<mbruzek> menn0: How was I able to run this before?
<menn0> mbruzek: I have no idea... thumper?
<mbruzek> installing cloud-image-utils now
<mbruzek> unless you want me to hold off
<menn0> mbruzek: no go ahead
<thumper> mbruzek: do you have "juju-local" package installed?
<menn0> mbruzek: from the error and from looking at the lxc-ubuntu-cloud script which is used to generate an ubuntu LXC container it really looks like you need ubuntu-cloudimg-query and it comes from cloud-image-utils
<mbruzek> thumper I should. I was running juju local yesterday.  juju-local is already the newest version.
<menn0> mbruzek, thumper: cloud-image-utils doesn't appear to be directly required by juju-local
<mbruzek> strange, it was not installed on my system... I use local on a daily basis
<thumper> not sure what is going on actually
<menn0> mbruzek, thumper: the dependency path is: juju-local -> lxc -> lxc-templates -> cloud-image-utils
<menn0> mbruzek, thumper: not sure how cloud-image-utils went missing for you...
<mbruzek> lxc-templates is already the newest version.
<mbruzek> I rebootstrapped my environment
<menn0> if you do "apt-cache showpkg lxc-templates" you'll see it needs cloud-image-utils
<menn0> but somehow it was uninstalled on your system
<mbruzek> menn0: I do apt-get upgrade every morning.
<menn0> mbruzek: yeah, this is pretty strange
<menn0> mbruzek: with the package installed do things work?
<mbruzek> menn0: Yes it appears that solved my problem.
<mbruzek> many thanks menn0 and thumper!
<menn0> mbruzek: please let us know if it happens again.
<mbruzek> menn0: It was reproducible only today for me.  I did several destroy-environment, bootstrap with the same error.
<mbruzek> but now it looks good, thanks for working with me on this.
<davecheney> https://code.launchpad.net/snappy-ubuntu
<davecheney> sad
<jw4> thumper: it looks like your feature flag branch landed - is it ready for me to start using?
<thumper> jw4: yep
<jw4> thumper: cool!
#juju-dev 2014-12-10
 * thumper looks at anastasiamac_
<thumper> anastasiamac_: Is there a reason that block.ProcessBlockedError doesn't use errors.Cause(err) ?
 * thumper stops staring and wonders why the test is still failing with that line added
<thumper> haha
<thumper> ha
<thumper> hmm...
 * thumper looks at trunk
<thumper> yep... broken in trunk
 * thumper enfixorates
 * thumper does a little dance
<thumper> my three outstanding branches landed today
<waigani> \o/
 * menn0_ is struggling with the damn open ports migration (again)
<menn0_> the tests are sensitive to anything with the DB changing...
 * thumper weeps 
<thumper> I know what is a great idea...
<thumper> lets test the apiserver by exhaustively testing the command line client
<thumper> or even better...
<thumper> let's test the apiserver by calling the api client
<thumper> what could possibly go wrong?
<thumper> stabby stabby
 * thumper takes a deep breath
 * thumper breathes out
<thumper> why does this make me so fucking angry?
<wwitzel3> because it's wrong
<thumper> thank you waigani
<thumper> waigani: I think it is work I made you do earlier this year that makes the work I'm doing now slightly less painful
<waigani> ha, I thought it was another wallyworld typo
<thumper> menn0_: https://github.com/juju/juju/pull/1295
<menn0_> thumper: looking
<thumper> menn0: like the machine command branch but for environment commands
<thumper> 1710 lines, and I tried to keep it small
<thumper> geez
<thumper> menn0: I suppose I could have landed the apiserver and client test refactoring separately
<thumper> that would have reduced it by about 300 lines
<menn0> menn0: yeah I was thinking that but now that you've done it
<menn0> ...
<thumper> meh
<thumper> just noticed doc help for environment get still metions get-environment
 * thumper stops for coffee
<mattyw> jam1, are you around?
<menn0> thedac: phew! review done.
<menn0> thedac: that should have been thumper
<mattyw> jam1, ping?
<jam1> mattyw: hi
<mattyw> jam1, hi there, I fixed http://reviews.vapour.ws/r/563/ after your comments, would you mind taking another look?
<jam1> mattyw: looking
<jam1> the diff still hasn't loaded....
<jam1> mattyw: refresh worked. Anyway LGTM
<mattyw> jam1, thanks very much
<mattyw> jam1, I'm going to land it
<jam1> np
<jam1> sounds good
<fwereade> axw, would you take a look at the latest diff on  http://reviews.vapour.ws/r/606/ please? context is failed test here: http://juju-ci.vapour.ws:8080/job/github-merge-juju/1581/console
<axw> fwereade: looking
<axw> fwereade: http://reviews.vapour.ws/r/589/? :)
<fwereade> axw, dammit, ty
<fwereade> axw, so, the doubled fields don't feel quite right to me -- ISTM that there's a fundamental properties-of-a-single-block-device struct that wants to get out
<fwereade> axw, altough I *also* know that it's not quite that simple, witness the Constraints/HardwareCharacteristics dichotomy
<axw> fwereade: there is one already: storage.BlockDevice. it's pretty much parallel to Constraints/HC
<fwereade> axw, and I can also see the attraction to parsing constraints into a single struct that replaces the service-level one that came from the charm
<fwereade> axw, yeah, I'm quibbling about the doubled fields more than anything
<axw> fwereade: you mean Size vs. MinSize?
<fwereade> axw, instinct is suggesting that Minimum and Preferred would be better top-level fields?
<axw> ah, I see
<fwereade> axw, and I see how Count is a bit of a problem from that perspective
<fwereade> axw, but I'm starting to think that maybe it's a matter of an array of duped {min, pref} structs?
<axw> fwereade: I did wonder about that, but how do you say that a struct isn
<axw> erk
<axw> isn't required at all
<axw> s/struct/disk/
<axw> i.e. I might like 100 disks, but I'll be happy if you have one or two
<fwereade> axw, right, I see, it probably can't sanely be an array
<axw> I would prefer if it's not in there though, since it's not an independent variable...
<fwereade> axw, indeed, it does feel like it wants to exist at another level
<fwereade> axw, although, hmm
<fwereade> axw, I think the min/pref thing does still apply
<fwereade> axw, we need at least 2 disks but really want 6
<fwereade> axw, but you're right that they're independent
<fwereade> axw, I can well imagine preferring to have 2 awesome disks than 6 crappy ones
<fwereade> axw, that feels like it's pushing us towards more sophisticated fallback behaviour again
<fwereade> axw, because if we just do straight "try preferred, then try minimum" we'd end up with 2 crappy disks
<axw> good point
<axw> ugh
<fwereade> axw, can we make a case for count being different enough to be a separate dimension, even if it's specified together?
<fwereade> axw, but even then
<axw> fwereade: I think so- try preferred and then min count of (other) preferred constraints before
<axw> anything else
<fwereade> axw, it feels like we should *definitely* get explicit user feedback re choosing whether to degrade count or quality first
<axw> which equates to, "give me as many of the best disks you can give me"
<axw> yeah
<fwereade> axw, some people will certainly care more about redundancy than speed
<axw> fwereade: there's always going to be the option of being explicit about the constraints, in which case there's no degradation anyway
<axw> but yes, this needs some input from interested parties
<fwereade> axw, yeah, indeed
<axw> my last email got crickets...
<fwereade> axw, yeah, I feel this is something of a systemic issue
<fwereade> axw, there *are* interested parties, but they all have their own priorities, and fixing the bugs today tends to take priority over defining the features of tomorrow
 * axw nods
<axw> fwereade: your diff LGTM
<fwereade> axw, cool, thanks
<perrito666> morning
<TheMue> perrito666: o/
<jam1> dimitern: standup ?
<dimitern> jam, brt
<axw> fwereade: in the interest of getting something working, would you be satisfied with separating the constraints out into top-level Minimum and Preferred, and refactoring if it turns out that it doesn't fit with the default fallback approach decided on later?
<fwereade> axw, +1
<axw> cool
<fwereade> axw, I think it's one of those cases where we'll have to converge to what's actually right regardless
<axw> fwereade: maybe, but I can't really see how there is a "right" here; it depends on the user, so it'd have to be policy driven
<fwereade> axw, I'm really just thinking about the shape of the code and the structs that most happily map between the user view and the substrate
<axw> oh, right
<fwereade> so, I'm suffering an attack of incandescent rage re: the uniter tests building jujud
<fwereade> does anyone have any bright ideas for how we might avoid doing this?
<hazmat> what's the story on juju actions?
<hazmat> we have apis but no cli?
<fwereade> hazmat, they're under development, in https://github.com/juju-actions
<fwereade> hazmat, hopefully soon tobe behind a feature flag as proposed by thumper, but I haven't kept up on whether he's done that
<fwereade> hazmat, jw4 or bodie_ should know the latest
<axw> fwereade: why do the uniter tests need jujud? are they executing hook tools?
<fwereade> axw, yeah
<fwereade> axw, I am *sooo* tempted to just use jsonrpc and hack up jujuc in python already :/
<fwereade> axw, it used to be a separate executable
<fwereade> axw, but it's not very small
<fwereade> axw, and so we rolled it into jujud
<axw> yeah, not long after I started I think
<fwereade> axw, (but then that's not very nice for windows... /sigh)
<fwereade> axw, I thought it was even before that
<axw> maybe, maybe I just remember the old packages
<fwereade> axw, hey ho :)
 * perrito666 tipes fearful that the power might once again go off ..
<perrito666> you have to love local power company
<axw> fwereade: as a minimal change, perhaps move jujuCMain out of cmd/jujud/main.go into worker/uniter/jujuc somewhere, and add a new minimal cmd package just for those tests that calls jujuCMain
<axw> then at least it doesn't build the entire tree
<fwereade> axw, yeah, I was thinking about that, and then I got stressed about having a separate code path for the tests
<fwereade> axw, which was leading me towards just doing a separate implementation in a scripting language
<fwereade> axw, and then I started trying to find out what the protocol was for plain golang rpc and *ofc* we'd have to change it out for json and grr arrgh hmmph
<axw> fwereade: what, everyone doesn't use websockets+json ? :)
<fwereade> axw, ;p
<jw4> hazmat: wrt actions - we've been holding off on the CLI until we can land the full implementation, but now that we have feature toggle we'll start landing what we have behind a flag.
<coreycb> jw4, interesting timing on this topic, I was just going to ask about it :)
<jw4> coreycb: :)
<coreycb> jw4, any estimates on when cli will start to land?
<jw4> Well, we have some finished already in the github.com/juju-actions/juju fork under the cli-action-dev branch
<jw4> coreycb: my mission in the next couple days is to start landing the super command and sub commands behind a feature toggle
<coreycb> jw4, great, thanks.  any chance you could point me to a charm that has action hooks?
<jw4> coreycb: bodie_ mocked up a demo one that he's using for sample usage : https://github.com/binary132/actions-demo
<jw4> coreycb: also, marcoceppi is using bleeding edge versions of the API for a project he's working on
<coreycb> jw4, awesome, thank you
<jw4> coreycb: please hit bodie_, TheMue , or I up with any and all comments / feedback / issues
<coreycb> jw4, will do
<wwitzel3> natefinch: ping
<natefinch> ericsnow, wwitzel3: btw, realized I made a mistake with some of the configuration code for GCE..... we can talk about it in standup, but long story short, we have to keep all configuration in the original map[string]interface{}, unfortunately
<natefinch> wwitzel3: howdy
<natefinch> wwitzel3: want to hop in moonstone for the 1:1?
<wwitzel3> natefinch: yep
<sinzui> natefinch, We have a regressions bug 1401130 about joyent. There is only 1 suspect commit. Can you ask someone to investigate
<mup> Bug #1401130: Joyent deployments cannot download agents from state-server <ci> <joyent-provider> <regression> <juju-core:Triaged> <https://launchpad.net/bugs/1401130>
<natefinch> sinzui: sure
<sinzui> dimitern, how goes the work on bug 1397376?
<mup> Bug #1397376: maas provider: 1.21b3 removes ip from api-endpoints <api> <cloud-installer> <fallout> <landscape> <maas-provider> <juju-core:In Progress by dimitern> <juju-core 1.21:In Progress by dimitern> <https://launchpad.net/bugs/1397376>
<dimitern> sinzui, live testing latest changes - maas still gives me some issues
<sinzui> :/
<dimitern> sinzui, I'll propose the fix while waiting
<sinzui> thank you dimitern
<hazmat> coreycb, jw4 re marcoceppi's prototype action cli via api https://github.com/juju-solutions/juju-action
<jw4> thanks hazmat
<coreycb> jw4, thanks!
<coreycb> I mean, hazmat ^
* ChanServ changed the topic of #juju-dev to: https://juju.ubuntu.com | On-call reviewer: see calendar | Open critical bugs:  1401130 1400358
<katco> ericsnow: ping
<ericsnow> katco: hey
<katco> ericsnow: good morning :)
<katco> ericsnow: i'm reviewing http://reviews.vapour.ws/r/608/
<katco> ericsnow: the code looks good, but i'm having trouble knowing if it's complete. can you point me to some light literature on the nature of the change?
<ericsnow> katco: https://github.com/juju/juju ;)
<katco> ericsnow: haha
<ericsnow> katco: I'm not expert on the uniter code nor on jujuc
<katco> ericsnow: i guess i'm trying to understand if availability zones need to be added elsewhere, or if any additional tests are needed
<katco> ericsnow: as i am not an expert on this concept either
<ericsnow> katco: for this change I simply traced how we get the IP address stuff into relation-get and did the same for the availability zone
<katco> ericsnow: ah ok. so the use-case is much the same
<ericsnow> katco: yep
<katco> ericsnow: do you think any additional tests are needed to ensure it's being set?
<ericsnow> katco: see https://docs.google.com/a/canonical.com/document/d/1yVlzgKqfhKccUbm3WcZBq7WnzglBygknscr_I_u4bUg/
<katco> ericsnow: thanks
<ericsnow> katco: this patch is just a tiny part of all that spec
<katco> ericsnow: like maybe instead of checking for an empty string in uniter_base_test.go, we maybe fill in an availability zone and check it?
<ericsnow> katco: I'd be glad to add more tests (there's always a gap to fill)
<katco> ericsnow: nothing too crazy or anything, maybe just a single test to ensure it's being passed around correctly?
<ericsnow> katco: suggesting it in a review comment would be most helpful
<katco> ericsnow: you got it
<ericsnow> katco: good idea
<ericsnow> katco: tas
<katco> ericsnow: thanks for the explanation :)
<ericsnow> katco: I just dumped everything I know on the subject ;)
<katco> ericsnow: haha well it was helpful :)
<ericsnow> katco: good
<ericsnow> natefinch: standup?
<natefinch> ericsnow: doh, coming
<dimitern> ericsnow, is the RB hook not working?
<dimitern> ericsnow, I have this PR https://github.com/juju/juju/pull/1297 - maybe the description is too long for the hook to handle and add the RB link?
<dimitern> anyway..
<ericsnow> dimitern: this happened the other day to axw
<ericsnow> dimitern: I'll check it out
<dimitern> ericsnow, yeah, I guess the bot just said tl;dr :)
<ericsnow> dimitern: :)
<dimitern> katco, as OCR can you have a look at this fix for bug 1397376 ?  https://github.com/juju/juju/pull/1297
<mup> Bug #1397376: maas provider: 1.21b3 removes ip from api-endpoints <api> <cloud-installer> <fallout> <landscape> <maas-provider> <juju-core:In Progress by dimitern> <juju-core 1.21:In Progress by dimitern> <https://launchpad.net/bugs/1397376>
<katco> dimitern: one sec, on a call
<dimitern> katco, np, when you can
<dimitern> fwereade, is you're still around and willing can you have a look as well? ^^
<dimitern> if*
<katco> dimitern: apologies. i am in the middle of reviewing axw's storage branch and then i'll hop onto yours
<katco> dimitern: ty for the ping :)
<dimitern> katco, it's ok, take your time
<katco> ericsnow: hey can you look at the diff for http://reviews.vapour.ws/r/589/
<katco> ericsnow: i think review board has an error
<katco> ericsnow: it's not displaying the diff for some files
<ericsnow> katco: will do
<ericsnow> katco: were those files removed?
<katco> ericsnow: ty sir
<katco> ericsnow: um. hrm.
<katco> ericsnow: let me check, didn't think of that
<katco> ericsnow: ah yes they were. but that shouldn't show up as an error should it?
<katco> ericsnow: i would expect it to say something sensible, like "file deleted" for the RHS
<katco> dimitern: hey am i daft? i don't see your PR on review board?
<dimitern> katco, yeah - it got hit by the "desc tl;dr" RB bot bug
<dimitern> ..apparently
<katco> dimitern: oh, haven't hit that one yet. so can you post the diffs to RB manually?
<dimitern> katco, I can certainly try.. give me a sec
<katco> dimitern: ty sir
<ericsnow> dimitern: looks like github is giving us a 404 when we go to pull the diff
<ericsnow> dimitern: I'll need to investigate further
<dimitern> katco, there you go - http://reviews.vapour.ws/r/611/diff/
<dimitern> ericsnow, oh boy.. it's not even that big :) ~1K lines
<sinzui> natefinch, is anyone working on bug 1401130 or bug 1400358 that block merges
<ericsnow> dimitern: (though the 404 may actually mean 401)
<mup> Bug #1401130: Joyent deployments cannot download agents from state-server <ci> <joyent-provider> <regression> <juju-core:Triaged> <https://launchpad.net/bugs/1401130>
<mup> Bug #1400358: TestLoginsDuringUpgrade broken on i386 <ci> <regression> <testing> <juju-core:In Progress by menno.smits> <https://launchpad.net/bugs/1400358>
<katco> dimitern: tyvm!
<dimitern> ericsnow, interesting - some auth cache/cookie expired?
<sinzui> dimitern, if you need to submit you fix for api-endpoints and CI is blocked, use "__JFDI__" in the message
<natefinch> sinzui: no, sorry, been in meetings all morning.  I'll try to get someone on those now.
<dimitern> sinzui, yep, I know the drill :)
<ericsnow> dimitern: pretty sure the auth is okay (but the 400 implies it's not)
<dimitern> weird..
<dimitern> anyway I'll be off now
<dimitern> sinzui, I'll merge the fix tomorrow morning. it seems
<katco> dimitern: i'll ping you after i'm done reviewing in the off-chance you're still on
<katco> dimitern: but this one is likely going to take awhile
<dimitern> katco, ok
<dimitern> katco, btw don't feel obliged to approve it, if it's not clear; it's was a mess before, a little less now, but still not perfect
<katco> dimitern: no worries
<wwitzel3> ericsnow: ping
<ericsnow> wwitzel3: ready?
<wwitzel3> ericsnow: yep, in moonstone
<ericsnow> wwitzel3: brt
<ericsnow> wwitzel3: port range parsing: http://reviews.vapour.ws/r/612/
<natefinch> perrito666: can you take a look at https://bugs.launchpad.net/juju-core/+bug/1401130 ?   unfortunately, I have to take the kids while my wife goes to a prenatal checkup, so I'll be out most of the afternoon.
<mup> Bug #1401130: Joyent deployments cannot download agents from state-server <ci> <joyent-provider> <regression> <juju-core:Triaged> <https://launchpad.net/bugs/1401130>
<natefinch> sinzui: menno has a fix for the other one, I think it best for him to just get that in later today (early in his day)
<sinzui> okay. thank you natefinch
<perrito666> looking
<jw4> We're beginning to land Actions CLI commands now behind an "action" feature flag
<jw4> the first PR is http://reviews.vapour.ws/r/613/
<jw4> PTAL OCR ^^
<jw4> :)
<katco> jw4: PTAL? sorry still working my way through dimitern's change
<perrito666> sinzui: has anyone tried that by hand?
<sinzui> perrito666, about the which thing?
<sinzui> oh, I see
<perrito666> sinzui: sorry I swallowed the context
<perrito666> about the joyent issue
<sinzui> perrito666, Yes. I tried joyent with tip and 1.20.13 and 1.20.14
<sinzui> perrito666, I the 1.20.x do work
<sinzui> perrito666, I attached the cloud-init-output.log of the 1.22-alpha1 machine that was stuck in pending
<perrito666> sinzui: it is interesting that you think it can be related to this bug https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1283992
<mup> Bug #1283992: Multi-monitor: wallpaper is corrupted <amd64> <apport-bug> <compiz-0.9> <trusty> <ubuntu> <unity (Ubuntu):Invalid> <https://launchpad.net/bugs/1283992>
<sinzui> perrito666, Joyent has a history of good bootstraps and bad deployments because the other machines got a different network than the one the state-server was one. A few months ago, wallyworld or awx added a rule to select the right network
<perrito666> ahh buu the title is right here
<sinzui> oops.
 * sinzui looks for other joyent network bug
 * perrito666 changes wallpaper
<sinzui> perrito666, I think the current issue may relate to bug 1383922
<mup> Bug #1383922: Services deployed joyent have broken networks <ci> <deploy> <joyent-provider> <reliability> <juju-core:Triaged> <https://launchpad.net/bugs/1383922>
<sinzui> perrito666, there is one other nuance. Joyent added firewalls as a feature for each. machine. We don't use them, but I wondered if joyent ever had a rule to bring up the machine with with firewall up, then takes it down when it thinks the machine is ready
<perrito666> sinzui: sorry to bother again, I am trying to make a picture of the issue here
<sinzui> go ahead perrito666
<perrito666> sinzui: the cloudinit log from a failure, comes from an attempt with master tip?
<perrito666> (sorry for the dramatic pause, dog ran away into a pool of muddle)
<sinzui> perrito666, yes, was a few hours ago
 * sinzui looks for commit
<sinzui> perrito666, it was commit 0363d9c6
<perrito666> sinzui: I think a valid test would be to run by hand the last successful commit
<perrito666> it is a quick way to know if its us or them
<sinzui> perrito666, this log is uniformative http://juju-ci.vapour.ws:8080/job/joyent-deploy-precise-amd64/1240/console, so while it was stalled in pending, I sshed into one of the machine
<sinzui> perrito666, but there are no streams for it. I can run the entire build or...
 * perrito666 thinks
<perrito666> I think the test would be valid enough with upload tools
<sinzui> ...or use a binary from http://juju-ci.vapour.ws:8080/job/publish-revision/1283/ with --upload tools
<perrito666> sidenote: we need to have a non hackish tools to publish a stream
<sinzui> perrito666, that last version just worked for me.
<perrito666> ok, so we broke something
<thumper> waigani_: so "state-id" in the dummy config seems like it is not important
<thumper> waigani_: I'm trying to see where it is used
<thumper> waigani_: what exactly is failing for you?
<waigani_> ... value *errors.Err = &errors.Err{message:"cannot add a new machine", cause:(*errors.errorString)(0xc21027f730), previous:(*errors.errorString)(0xc21027f730), file:"github.com/juju/juju/state/addmachine.go", line:168} ("cannot add a new machine: invalid state-id \"90168e4c-2f10-4e9c-83c2-feedfacee5a9\"")
<waigani_> and if I don't pass the state-id in:
<waigani_> 	... value *errors.Err = &errors.Err{message:"cannot add a new machine", cause:(*errors.errorString)(0xc21008b9c0), previous:(*errors.errorString)(0xc21008b9c0), file:"github.com/juju/juju/state/addmachine.go", line:168} ("cannot add a new machine: environment is not prepared")
<waigani_> thumper: ^
<thumper> waigani_: well a state id needs to be an integer
<thumper> waigani_: and it seems llike the dummy env sets it itself
<thumper> waigani_: because it expects only one environment
<waigani_> ah
<thumper> waigani_: you may need to look through the dummy provider somewhat
<thumper> waigani_: the dummy provider calls 'newState' which seems to do stuff we don't want
<thumper> for secondary environments
<waigani_> thumper: right, maybe a new branch to get dummy to work with non-state-server envs?
<thumper> waigani_: yeah... I think that may be needed
<thumper> waigani_: it seems that dummy assumes too much now
<waigani_> haha, I am now three branches removed from what I started on this week
<thumper> :-)
<thumper> push another on the stack
<thumper> eventually you'll get to pop some
<waigani_> yep
<thumper> waigani_: please add a task card on kanban :)
<menn0> waigani_: it could be worse. you might be using Subversion.
<waigani_> lol
<waigani_> thumper: okay, I'll shelve others, update kanban and start this new branch.
 * thumper nods
<menn0> thumper: here's that test fix: http://reviews.vapour.ws/r/615/
<menn0> thumper: I think it's ok now (not *too* ugly)
 * thumper looks
<thumper> menn0: why refactor the machine agent?
<thumper> what do you get out of it?
<menn0> thumper: so that the specific workers that the test needs can be run
<menn0> thumper: instead of spinning up the whole agent
<menn0> thumper: moving the code that starts workers into methods makes it available from the test
<menn0> s/it/them/
<thumper> ah..
<thumper> kk
<thumper> hadn't got to the tests yet :)
<menn0> thumper: right, I can see how the machine agent changes might have seemed unnecessary without seeing the tests :)
<thumper> menn0: ship it!
<menn0> thumper: cheers
<menn0> thumper: I hadn't realised that this bug had been "promoted" to a CI blocker
<menn0> thumper: just as well that I was working on it
<thumper> :)
<thumper> I didn't know either
<thumper> oh, looky looky, there are two critical bugs in the topic
<alexisb> thumper, that is very observant of you
<alexisb> perrito666 is working one
<alexisb> or was the last time I checked in
<thumper> alexisb: I try
<jw4> Okay take two :: OCR PTAL http://reviews.vapour.ws/r/616/
<jw4> thumper: included your feedback into this new PR ^^
<thumper> jw4: ok, I'll take a look after lunch. not OCR but interested
<jw4> thumper: cool, thanks - fwiw my approach to setting and restoring the flags might need to be generalized but I wanted to keep it light
<thumper> jw4: I've not looked, but we probably want two tests for the commands, one to show it isn't there by default, and one to show it is when flag is set
 * thumper wanders off for a bit
<jw4> thumper: +1
<menn0> hmmm... this is a new merge failure
<menn0> Traceback (most recent call last):
<menn0>   File "/var/lib/jenkins/juju-ci-tools/ec2-terminate-job-instances", line 3, in <module>
<menn0>     from deploy_stack import destroy_job_instances
<menn0>   File "/var/lib/jenkins/juju-ci-tools/deploy_stack.py", line 23, in <module>
<menn0>     from jujupy import (
<menn0>   File "/var/lib/jenkins/juju-ci-tools/jujupy.py", line 25, in <module>
<menn0>     from utility import (
<menn0>   File "/var/lib/jenkins/juju-ci-tools/utility.py", line 16, in <module>
<menn0>     from mock import patch
<menn0> ImportError: No module named mock
<menn0> looks like mock isn't installed on the build host
<menn0> or something
<ericsnow> wwitzel3: I didn't realize it was so late for you
<ericsnow> wwitzel3: want to pick this up tomorrow?
<ericsnow> wwitzel3: I got the PortSet patch up: http://reviews.vapour.ws/r/617/
<ericsnow> wwitzel3: I also updated dependencies.tsv on the GCE branch
<ericsnow> wwitzel3: I'll still be here a while
<perrito666> alexisb: hey I was looking at the joyent one until the power went down
<perrito666> I am just back
<wwitzel3> ericsnow: ok, sorry, yeah was doing the dinner thing
<ericsnow> wwitzel3: no worries
<ericsnow> wwitzel3: I feel dumb for taking you so far past lunch :(
<ericsnow> wwitzel3: ...that you simply went straight to dinner
<ericsnow> wwitzel3: timezones stink
<wwitzel3> ericsnow: it's fine, it was fun, I will give a review to PortSet and helpers before I take off. Then we can pickup tomorrow where you we leave off with you driving.
<ericsnow> wwitzel3: perfect
<ericsnow> wwitzel3: have a nice evening
<menn0> davecheney: would you mind taking a look at http://reviews.vapour.ws/r/618/
<menn0> davecheney: it's a one line change
<menn0> so builds are broken right now
<menn0> I'm trying to merge the fix for one of the CI blockers. The test all pass but the CI tool that cleans up the EC2 instances dies because it can't import the Python "mock" library.
<menn0> thumper: ^^^
<menn0> thumper: looks like we're blocked until someone for the QA team is around
<davecheney> sure
<davecheney> looking
<thumper> jw4: I thought you were going to break that branch up?
<jw4> thumper: exactly
<jw4> thumper: that's why I didn't the first time
<thumper> jw4: 616 is still everything
<jw4> thumper: bodie made that initial commit set up the framework for all the subcommands
<jw4> thumper: no, none of the subcommands are implemented
<jw4> thumper: just skeletal
<jw4> thumper: later commits fill in all the subcommands
<thumper> ah...
<thumper> ok
 * thumper looks again
<jw4> thumper: I'd have to actually break up that one commit to get it smaller
<jw4> thumper: and it'd be a royal pain
<jw4> thumper: but... if that's what is required
#juju-dev 2014-12-11
<jw4> thumper: for context we've been building up a backlog of code in the juju-actions repo - your feature flags made it possible for us to begin landing that code without it being available by default while it's incomplete
 * thumper nods
<perrito666> ericsnow: is it tomorrow for you already?
<perrito666> I sent the two first patches for restore :p
<ericsnow> perrito666: yeah, I saw
<ericsnow> perrito666: sweetness
 * perrito666 wonders how many more times is the power going to go off
 * perrito666 also wonders why he forgot to get an UPS for the internet
<anastasiamac_> thumper: was my answer to block.ProcessBlockedError doesn't use errors.Cause(err) digestable?
<anastasiamac_> thumper: "was my answer to your question - why block.ProcessBlockedError doesn't use errors.Cause(err) -  digestable?" even
<thumper> anastasiamac_: hey
<thumper> just busy right now
<thumper> with you shortly
<anastasiamac_> thumper: np
<thumper> anastasiamac_: well yesterday with my machine branch, I changed it to use errors.Cause
<anastasiamac_> thumper: did ur machine branch land?
<thumper> anastasiamac_: yep
<thumper> anastasiamac_: all tests pass
<thumper> anastasiamac_: don't stress, I know what I'm doing
<mgz_> menn0: I'll fix that, looks like an unrelated ci-tools change brought in a dep it probably shouldn't
<anastasiamac_> thumper: m not stressed about tests but the actual output on command line :D
<thumper> anastasiamac_: doesn't change
<thumper> jw4: review done...
<jw4> thumper: much appreciated
<jw4> thumper: just getting ready to update the TestHelpCommands for with and without feature
 * thumper nods
<jw4> thumper: good feedback - I'll work on some of these, but bodie_ knows more about most of this.
<thumper> jw4: I recomment quite a few changes
<anastasiamac_> thumper: thnx ')
<jw4> thumper: s/recomment/recommend/? : if so, yeah - good stuff
<thumper> was going for recommended
<jw4> hehe
 * thumper shrugs
 * thumper is very tired
<thumper> perrito666: are you looking at the joyent bug?
<mgz_> menn0: requeued
<thumper> menn0: it seems that the immutable values aren't tested in the state tests, but probably are in the config
 * thumper double checks
<menn0> mgz_: thank you!
<thumper> menn0: yep tested there
<menn0> thumper: ok. so is that good enough for them not be retested at the API level?
<thumper> menn0: I think I'll leave one there to show the message
<thumper> but won't do all
<menn0> thumper: that sounds good to me
<thumper> menn0: you seem to be invoking the boyscout rule of code
<thumper> menn0: I'll clean the code even though it isn't my mess :-)
<anastasiamac_> thumper: boyscout rule of code...
<thumper> anastasiamac_: leave the code cleaner than you found it
<thumper> anastasiamac_: like "leave the camp ground cleaner than you arrived"
<anastasiamac_> thumper: oh.. and i thought it was "pray at the end of the session'...
<thumper> haha
<thumper> maybe that is apt too
<thumper> pray before submitting
<anastasiamac_> thumper: at least, that's what boyscout groups do here
<anastasiamac_> thumper: :D
<anastasiamac_> menn0: thnx for cleaning messes!
<anastasiamac_> menn0: and campsites
<menn0> anastasiamac_, thumper: :)
 * thumper frowns
<thumper> ah...
<thumper> fark
<thumper> found it
<menn0> I just saw all the Ship Its for one of my branches. Thanks all for reviewing my fix that moves one line of code :)
<menn0> thumper: should someone be looking at bug 1401130?
<mup> Bug #1401130: Joyent deployments cannot download agents from state-server <ci> <joyent-provider> <regression> <juju-core:Triaged> <https://launchpad.net/bugs/1401130>
<menn0> that's the other CI blocker
<thumper> menn0: I just had to get in on that action
<thumper> menn0: I thought perrito666 was looking at it, but he enver marked himself as in progress
<thumper> ericsnow: do you know?
<ericsnow> thumper: nope
<perrito666> thumper: I have been having power issues the whole day and I tried to look at it without much success
<ericsnow> thumper: nate said he was going to get someone on it earlier in the day
<thumper> menn0: if you could look that would be very helpful
 * perrito666 has not had a full hour with power today
<thumper> do we have creds we can use?
<menn0> thumper: ok
<menn0> thumper: I think I know where to look
<thumper> menn0: oh, ok
<thumper> menn0: just one question on your review on environments command that made no sense to me
<thumper> menn0: could I get you to clarify?
<menn0> thumper: sure
<thumper> currently running the entire test suite
<perrito666> thumper: I dont, I was running things through sinzui
<thumper> perrito666: that's ok, menn0 is on it :)
<thumper> \o/
<menn0> thumper: yeah, that comment makes no sense. if there was something to unset it wouldn't be unknown :)
<menn0> thumper: drop that
<thumper> ok
<anastasiamac_> thumper: RB shows that block tests were lost again (on environment super-command branch)
<anastasiamac_> thumper: is it just RB's perspective?
<thumper> anastasiamac_: yeah
<thumper> also... wat?
<thumper> no definitely there
<thumper> but moved
<thumper> and changed
<thumper> \o/.
<thumper> set_test.go, unset_test.go
<anastasiamac_> thumper: tyvm for making them cleaner and more readibale
<thumper> at the bottom
<anastasiamac_> thumper: a bit of boyscouting seem to run in nz
<thumper> that's fine
<thumper> all good
<thumper> by faking out the api fully we get much more control over tests
<thumper> and we stop testing everything at every layer
<thumper> which is a waste
<thumper> as long as we still have enough tests to show that everything is wired up correctly
<anastasiamac_> thumper: makes sense! thnx again :-)
<thumper> that's fine
<dimitern> axw, ping
<dimitern> thumper, afternoon
<dimitern> http://reviews.vapour.ws/r/611/ can any of you have a look at this MP for bug 1397376 please?
<mup> Bug #1397376: maas provider: 1.21b3 removes ip from api-endpoints <api> <cloud-installer> <fallout> <landscape> <maas-provider> <juju-core:In Progress by dimitern> <juju-core 1.21:In Progress by dimitern> <https://launchpad.net/bugs/1397376>
<thumper> o/ dimitern
<axw> dimitern: pong
<axw> ok
<dimitern> axw, ta!
<alexisb> jam, leads call
<menn0> thumper: ping?
<thumper> menn0: otp
<menn0> thumper: i've reproed and characterised bug 1401130. I've added the details to the ticket.
<mup> Bug #1401130: Joyent deployments cannot download agents from state-server <ci> <joyent-provider> <regression> <juju-core:In Progress by menno.smits> <https://launchpad.net/bugs/1401130>
<menn0> thumper: not sure where to look now. we might need to contact Joyent.
<thumper> ok
<menn0> thumper: I need to head out for a bit but will be back later
<thumper> kk
<thumper> jam, dimitern: passing on this critical bug to you two: https://bugs.launchpad.net/juju-core/+bug/1401130
<mup> Bug #1401130: Joyent deployments cannot download agents from state-server <ci> <joyent-provider> <regression> <juju-core:In Progress by menno.smits> <https://launchpad.net/bugs/1401130>
<dimitern> thumper, ok
<thumper> dimitern: menno added details, including some diagnostics
<dimitern> btw my chrome crashed, but I still hear audio - no video from the call
<jam> thumper: so all of the discussion I read on that seems to be pointing fingers at Joyent.
<thumper> dimitern: very networky
<jam> dimitern: we can still see your video feed
<jam> I've seen that when you run into JS in another window locking up
<dimitern> wow - it did crash without kicking me out of the hangout and then fixed itself
<jam> fwereade: I keep meaning to schedule time to chat with you again, and now we're at the end of my week. Ping me when you're around
<dimitern> menn0, ping
<dimitern> thumper, menn0, jam, do we have any joyent testing account I could use?
<menn0> dimitern: hi i'm back
<dimitern> menn0, hey, it's fine jam got me sorted out; but can I still bug you if I have questions re bug 1401130?
<mup> Bug #1401130: Joyent deployments cannot download agents from state-server <ci> <joyent-provider> <regression> <juju-core:In Progress by menno.smits> <https://launchpad.net/bugs/1401130>
<menn0> dimitern: sure can
<menn0> dimitern: i've got to help get kids to bed but just ask here and i'll get back to you
<menn0> dimitern: did you see the details i added to the ticket
<dimitern> menn0, cheers, no worries
<dimitern> menn0, yeah, it looks weird.. I'll dig into it some more
<menn0> dimitern: my theories are that either something's wrong at joyent
<menn0> dimitern: or Juju is using the wrong addresses or wrong routing
<menn0> or wrong netmasks
<menn0> dimitern: i'll check back in a bit
<dimitern> menn0, right
<menn0> dimitern: hey hey, kids asleep. i've got a little bit of time.
<menn0> dimitern: figure anything out?
<dimitern> menn0, nope, I was preparing a response to axw's review
<dimitern> menn0, but since you're here, I'll try it now
<menn0> dimitern: kk
<menn0> dimitern: i'm just creating a card on LK
<dimitern> axw, thanks btw - you've raised some very good points
<axw> dimitern: nps
<axw> dimitern: did you go to sleep last night? you were on very early :)
<axw> or are you sprinting
<dimitern> axw, I did - shortly after 8pm
<dimitern> to wake up in time for the 5am call :)
<axw> ah, fun
<fwereade> jam, heyhey
<jam> hey fwereade, how's it going?
<jam> just finishing up lunch, care to meet in about 30min?
<fwereade> jam, ehh, tolerable, a bit low-level fluey, but yes let's
<dimitern> I'd appreciate a review on http://reviews.vapour.ws/r/623/ - it unblocks ci for the critical bug 1401130
<mup> Bug #1401130: Joyent deployments cannot download agents from state-server <ci> <joyent-provider> <regression> <juju-core:In Progress by dimitern> <https://launchpad.net/bugs/1401130>
<dimitern> jam, axw, menn0, ^^
<jam> dimitern: that seems like our Networker needs some lovin', but otherwise LGTM
<jam> dimitern: you did test that it both *failed* before this, and *worked* after, right?
<dimitern> jam, indeed it does :)
<dimitern> jam, I couldn't get it to fail as described, but I've seen the overwritten /etc/network/interfaces file, which wasn't including eth1.cfg for the internal network the api server is on
<dimitern> jam, after the fix it doesn't happen
<dimitern> jam, so even though the networker didn't stop eth1 it won't be brought up after reboot
<jam> fwereade: whenever you would like to chat
<fwereade> jam, joining sapphire standup
<jam> dimitern: right, so they have a custom /etc/network/interfaces which we are overwriting and not quite matching what was there
<jam> and dimitern, we aren't really going to be having a smart networker on Joyent soon anyway, so we're fine
<dimitern> jam, yeah, and by sheer chance eth0 wasn't brought down (the one with the public ip) as it was considered "primary" :)
<dimitern> jam, so I could ssh into it, and eth1 wasn't present in state (no network info during provisioning), so it wasn't stopped immediately
<dimitern> jam, definitely not a priority now
<dimitern> mgz_, ping
<dimitern> jam, omw to standup
<jam> dimitern: core-team meeting today
<dimitern> oops team meeting actually
<dimitern> jam, backport of that joyent bug fix for 1.21 if you're so kind :) http://reviews.vapour.ws/r/624/
<jam> dimitern: did you have time to test it explicitly as well, or is it just a strict backport w/o testing ?
<jam> axw: team meeting? (if you're available)
<jam> mgz_: do you come to the juju-core-team meetings to see how we're doing ?
<dimitern> jam, testing now
<jam> dimitern: reviewed
<jam> wwitzel3: if you are around as well
<dimitern> jam, cheers
<menn0_> dimitern: i'm back
<menn0_> dimitern: glad that you got it figured out
<dimitern> menn0_, yeah, I got lucky I guess :)
<jam> fwereade: selfie got added to the Oxford dictionary, but I don't think Moar has reached that level yet :)
<jam> fwereade: I need moar coffee, but then I'm up for moar chatting if you would like
<perrito666> wwitzel3: ping me when you are back please
<perrito666> axw: tx for the reviews you are the first person ever to review that part of restore :p it was too far at the end of the large patch
<mbruzek> ping abentley
<abentley> mbruzek: pong
<mbruzek> Good morning.  I kicked off 5 jenkins builds yesterday to retest some of the charms hoping to update the report by charm: http://reports.vapour.ws/charm-tests-by-charm
<mbruzek> abentley:  #10658, #10659, #10660, #10663, #10664.
<mup> Bug #10658: evms: new changes from Debian require merging <evms (Ubuntu):Fix Released by mdz> <https://launchpad.net/bugs/10658>
<mup> Bug #10659: mozilla-firefox-locale-it: new changes from Debian require merging <mozilla-firefox-locale-it (Ubuntu):Fix Released by thombot> <https://launchpad.net/bugs/10659>
<mup> Bug #10660: Modem lights not working with "networks" <gnome-applets (Ubuntu):Invalid by seb128> <https://launchpad.net/bugs/10660>
<mup> Bug #10663: Boot menu help references Morphix <Ubuntu:Invalid by amu> <https://launchpad.net/bugs/10663>
<mup> Bug #10664: Framebuffer bootsplatch logo jpeg-like <Ubuntu:Fix Released by amu> <https://launchpad.net/bugs/10664>
<mbruzek> Those are not bugs sorry about that.
<mbruzek> Those are jenkins build numbers.
<mbruzek> abentley: None of the results were reflected on the report on vapour.  Is there another step that has to happen to get the report to update?
<abentley> mbruzek: No, it should update automatically within a minute.  I'll try to see what's going on.
<mbruzek> abentley: The consol output shows the s3cmd run at the end of the last 4 of those 5.
<mbruzek> abentley: Thanks for looking into it
<abentley> mbruzek: I see results for everything except 10658.
<mbruzek> abentley: I see results for all of them but they are not updated with the Dec 10 results.  http://reports.vapour.ws/charm-tests-by-charm
<mbruzek> abentley: for example build 10659 is cs:precise/shelrtv, that entry has a date of August 26 2014, not December 10
<mbruzek> abentley: build 10660 is cs:precise/solr, the entry on reports has it at September 09
<mbruzek> abentley: I see other December 10 entries, just not for the ones I request on December 10.
<ericsnow> wwitzel3: should we just get started after standup?
<abentley> mbruzek: Everything you built is shown in the "All charm and bundle results" table.
<ericsnow> wwitzel3: I'm available before too
<abentley> mbruzek: I suspect this is a sorting bug.
<mbruzek> abentley: OK I was looking at the charm-tests-by-charm what process builds that report?
<mbruzek> abentley: I see a difference. the ones I requested were cs:precise/charm-name the ones in the charm-tests-by-charm have a revision number in the name.
<abentley> mbruzek: That report is generated on the fly.  The results are ingested from s3 by a shell script.
<abentley> mbruzek: Well, a python script.
<mbruzek> abentley: So the ones I requested are missing a revision number.
<abentley> mbruzek: That's right.  We test specific charm versions when we do automatic testing.
<mbruzek> abentley: But how would I know the version numbers?  I just wanted to test the latest charm so I sent "cs:precise/solr" to charmguardian
<abentley> mbruzek: That's not something we support, but the charm store and manage.jujucharms.com know the charm versions.
<abentley> mbruzek: Since you're retesting the same version, you can also just look at the previous test results.
<voidspace> dimitern: any objection to me moving decimalToIP and ipToDecimal into network and making them public?
<voidspace> dimitern: I need them in ec2
<dimitern> voidspace, +1
<voidspace> dimitern: or at least I *may* do, I'll only move them if I actually need them
<voidspace> dimitern: cool, thanks
<mbruzek> abentley: How is it supposed to work?  When the charms get a new version number are new tests kicked off?  I thought I saw a few instances where the charms are of a newer revision.
<mbruzek> And the tests did not get kicked off.
<dimitern> voidspace, sorry, I got deep into bug fixing again and haven't actually asked how's it going today? :)
<abentley> Yes, when the charms get a new version number we see that we have no results for that number in the database, so we kick off a new test.
<dimitern> voidspace, any issues?
<dimitern> voidspace, I hope you are feeling better today
<ericsnow> fwereade: axw suggested I ask you about http://reviews.vapour.ws/r/608/
<abentley> mbruzek: Please file a bug, but be aware that certain charms are blacklisted because they break charmguardian: cs:precise/cassandra cs:trusty/hdp-hadoop cs:trusty/swift-proxy
<mbruzek> abentley: I am not trying to create more work, I just did not know an easy way to find the version number.
<mbruzek> abentley: bug against charmguardian?
<abentley> mbruzek: No, if you see instances where we failed to test a new version, file a bug against https://launchpad.net/juju-reports
<voidspace> dimitern: a bit better
<voidspace> dimitern: well enough to not be in bed anyway :-)
<voidspace> dimitern: yeah, going fine - I've just picked back up the Subnets work
<voidspace> dimitern: no issues - you were right about aws
<voidspace> dimitern: first four and last IP in a CIDR are reserved
<dimitern> voidspace, \o/
<dimitern> voidspace, great, ping me if there's anything then :)
<voidspace> dimitern: I will do, thanks
<fwereade> ericsnow, I'm a bit unconvinced by putting az into *every* relation setting
<fwereade> ericsnow, what's the thinking behind that?
<fwereade> ericsnow, we definitely agreed to make AZ available to units
<ericsnow> fwereade: to be honest I just followed the example of the IP address
<fwereade> ericsnow, but I don't see how that translates to making them part of everyrelation protocol
<ericsnow> fwereade: as far as I understand it is part of the spec: https://docs.google.com/a/canonical.com/document/d/1yVlzgKqfhKccUbm3WcZBq7WnzglBygknscr_I_u4bUg/edit
<abentley> mbruzek: So here's what's going on: cs:trusty/hdp-storm-3 breaks charmguardian, so we never get any results for it.  Since we don't have any results for it, we test it, and we never get around to anything else.  This has been going on with hdp-zookeeper, hdp-tez, hdp-storm, hdp-pig, hdp-hive, hdp-hive since Nov 22.
<wwitzel3> when deploying a local charm using local provider, do that charm get cached anywhere?
<ericsnow> fwereade: it's entirely possible I took the wrong approach
<wwitzel3> or will juju already just read from the path I provide it
<mbruzek> abentley: thus the black list that I read about?
<ericsnow> fwereade: I've been nervous at how small that patch is :)
<abentley> mbruzek: Yes.
<fwereade> ericsnow, hmm, so, I do see that in there, but (1) it only mentions peers and (2) I think it's a really bad idea
<ericsnow> fwereade: See the "exposing to charms" section and the part about relation-get in the "mechanisms" section
<fwereade> ericsnow, so on one side we shouldn't be inserting it in non-peer relations
<ericsnow> fwereade: I'm fine with dropping it but it's not my spec :)
<ericsnow> fwereade: good point
<fwereade> ericsnow, and on the other, every charm which uses a peer relation now suddenly has two protocols, and might be using one or the other depending on what the juju version is
<fwereade> ericsnow, which is probably not *that* harmful because I'm pretty certain we don't distinguish between "" and `missing` in relation-get
<mbruzek> abentley: What about the storage charm?  Is that on your blacklist?  I tried running that one several times and it never gets to the s3cmd to upload the results.
<fwereade> ericsnow, but still :)
<fwereade> hazmat, ping
<mbruzek> abentley: build 10647, 10658
<abentley> mbruzek: No, it's not on the blacklist.
<abentley> mbruzek: I have not figured out why that one doesn't upload to s3, but it isn't breaking charmguardian like the others did.
<ericsnow> fwereade: so is "private-address" set for all relations?
<mbruzek> abentley: I will file a bug
<fwereade> ericsnow, yes it is
<ericsnow> fwereade: k
<ericsnow> fwereade: so at the least "availability-zone" should only be set if the units in the relation are peers?
<hazmat> fwereade, pong
<ericsnow> fwereade: or are you opposed to the adding zones to relation-get at all?
 * hazmat reads backlog
<natefinch> fwereade, ericsnow, hazmat: my understanding is that we needed AZ for all relations
<fwereade> hazmat, I'm surprised about putting AZ into any relation by default
<fwereade> natefinch, so we should change the protocol for every relation, when we have enough trouble with protocols already? colour me unconvinced
<hazmat> fwereade, at minimal to achieve the use case it needs to be in peer relations.
<natefinch> fwereade: I was just following the spec... it says "The set of zone names in which peer **and per-relationship counterpart units are running**"
<natefinch> fwereade: I might be misunderstanding the spec
<hazmat> fwereade, its not a change in protocol its analogous to the work we already do with address
<fwereade> hazmat, auto-adding it doesn't seem worth the effort -- can't the charms that need it make it part of theirprotocol explicitly?
<hazmat> fwereade, they could.. however. its implicit to the iaas infrastructure provisioning responsibility juju is already taking
<hazmat> having juju provide that for relations to me automatically seems a logical extension just as we do with ip addrs
<fwereade> hazmat, fwiw it*is* a change in protocol, you may have a case that it's not an *important* change in the protocol
<hazmat> fwereade, hence the notion of prefixing the key in the rel
<hazmat> fwereade, the protocol communication itself is unchanged as its a seed value
<fwereade> hazmat, and we make those keys unwritableby normal means?
<hazmat> fwereade, no.. they should be writable
<fwereade> hazmat, so the juju- prefix is just a sort of hint?
<hazmat> fwereade, natefinch, ericsnow .. fwiw. i'm fine if we don't pre-seed the rels. the advantage requires explicit charm awareness and therefore they can seed
<hazmat> fwereade, proxy charms need to override such values and it may not have meaning to them
<fwereade> hazmat, indeed
<fwereade> hazmat, if we don't *need* them in every relation I'd much rather not put them in any relations by default
<hazmat> i think thats okay
<fwereade> hazmat, cool, thanks
<fwereade> hazmat, btw, about the suggested unit-get changes
<fwereade> hazmat, given that the two existing uses of unit-get are basically broken in any world with interesting networks
<fwereade> hazmat, is there any strong reason to add to unit-get vs putting them in env vars?
<fwereade> hazmat, also I fear that spec needs rather more detail re listing zones and/or configuring zone spread
<fwereade> hazmat, eg it makes no sense to make all provider zones available to a charm that's meant to spread over only 3 of them
<fwereade> hazmat, and I'm not 100% sure it makes sense to tell a service with 2 units about the 3 zones over which it might spread
<fwereade> hazmat, possibly specifying a zone spread should also imply a minimum unit count?
<fwereade> hazmat, (also, what happens if zone spread changes? is it immutable?)
<natefinch> fwereade: we had decided not to list available zones
<natefinch> fwereade: only list zones in which units exist
<natefinch> fwereade: or rather, only list zones for units.  No general list of zones
<fwereade> natefinch, yeah, but *that's* tricky when you go from one unit to 3
<fwereade> natefinch, in general, if we're changing info on which a charm depends, we should be firing some hook to let it know about it
<fwereade> natefinch, which hooks should we fire?
<perrito666> natefinch: standup?
<natefinch> fwereade: it's just exposing information about the units
<natefinch> fwereade: so, peer-relation-changed I guess?
<fwereade> natefinch, right, but then every single unit comes up seeing itself alone in a single zone
<fwereade> natefinch, so it's more about goal-state/active-state
<fwereade> hazmat, btw, I would really appreciate your thoughts on that
<fwereade> hazmat, there was a thread a couple of weeks back on juju-dev
<fwereade> hazmat, something like "feature request: expose relations in juju status"
<fwereade> hazmat, AFAICS we need to expose both those measures to be useful
<fwereade> natefinch, (did you see that thread btw?)
<natefinch> fwereade: btw I'm taking this over from eric, since he and wayne are heads down on GCE
<fwereade> natefinch, ah ok :)
<natefinch> fwereade: yeah, I remember the thread, though not too many specifics.
<fwereade> natefinch, tbh I was hoping it'd get some more thought and responses
<fwereade> natefinch, it may be that I need to write up a half-assed proposal before people will really start saying what won't work for them
<natefinch> fwereade: the only way to get the right answer is to propose the wrong answer :)
<fwereade> natefinch, yeah, indeed
<fwereade> natefinch, http://thecodelesscode.com/case/170
<hazmat> fwereade, sorry stepped out, catching up
<hazmat> fwereade, unit-get still makes sense, and even more so with multiple networks, the issue atm that bites with unit-get is the address is both ip and dns addr which is inappropriate depending on the use case and needs disambiguation
<hazmat> fwereade, zone is immutable for an instance lifetime
<hazmat> fwereade, the zone spread behavior is independent of surfacing zone to a unit. i agree it would be nice to have some configurable policy on the zone spread but thats not really  the issue at hand, and even a default behavior of max 3 is good enough any use case that comes to mind.. the exception is max zone 1, but we've decided to punt on that one till we have actual need.
<hazmat> fwereade, the information doesn't change, and the charm already hooks for observing and conveying this information via relations if it so choses
<fwereade> hazmat, I know that a single unit's zone is immutable, but the list of zones -- be it those in the provider, or those across which units are spread -- is not necessrily so
<fwereade> hazmat, if we're exposing the list, we need to notify on changes to the list
<hazmat> fwereade, the mutation awareness in the zone set is accompanied by new units joining the relation and there by conveying that information
<hazmat> fwereade, we're not exposing the list
<fwereade> hazmat, the spec has unit-get list-zones
<fwereade> hazmat, if we can drop that I'm totally fine there
<hazmat> fwereade, i think that was speculative, and even then it would only be those of the units in the service
<fwereade> hazmat, but then I'm not sure that there's much benefit to unit-get zone vs $JUJU_AVAILABILITY_ZONE
<hazmat> fwereade, the full zone list isn't really meaningiful if the service isn't present
<hazmat> in all of them
<fwereade> hazmat, agreed
<fwereade> hazmat, so then we still have the active/goal state issue, I think
<fwereade> hazmat, that everything comes up in an empty universe and needs to wait around until it has the full picture
<hazmat> fwereade, unit-get is an information channel.. we have other uses for it, including arrays of data (net lists, addrs. etc). i'd rather not baby and bath water everything into env vars
<fwereade> hazmat, and is never quite certain when it does
<hazmat> fwereade, being able to know the goal state of the service would be useful
<hazmat> ie. 8 other units are expected
<fwereade> hazmat, it kinda feels like what zones they'll be in is also relevant info -- or at least the expected spread?
<hazmat> fwereade, depends on the software, mongo and cassandra don't care, they'll add new partitions to the token ring or replica set respectively.. there might be others that care
 * hazmat checks on riak
<fwereade> hazmat, (and it remains true that the only current uses of unit-get are problematic at best -- I have no problem with hook tools, but for completely static data env vars feel somewhat neater?)
<hazmat> fwereade, disambiguating address to ip and address is separate issue, conflating them doesn't help.  just as problematic in an env var
<fwereade> hazmat, the concern is that while bringing a service up (or, worse, scaling it while already running) we induce an orgy of rebalancing
<fwereade> hazmat, ok, ip vs dns is *also* a problem
<fwereade> hazmat, my problem is that private-address and public-address are damn near meaningless in a situation where we have two networks of each kind (leaving aside the question of exactly what "public" implies)
<hazmat> fwereade, right it needs to grow and change re unit-get, but parsing lists in env var doesn't make that better
<hazmat> vs a cli that can format per invoker request
<fwereade> hazmat, I wasn't at *all* suggesting lists in env var, I was suggesting "my zone" in env var
<fwereade> hazmat, on the basis that I imagine it to be just a string
<fwereade> hazmat, listing zones is absolutely more suitable for a hook tool
<fwereade> hazmat, no argument there
<fwereade> hazmat, I just thought you'd said we could drop that
<hazmat> fwiw just checked riak and influxdb neither has rack/zone awareness so not applicable.
<hazmat> effectively the software needs some notion of that for zone awareness to be meaningful
<fwereade> hazmat, addresswise, we were talking address-get [-r ...], please talk to dimitern re the details there
<fwereade> hazmat, quite so
<fwereade> hazmat, the issue is that one's address is not very meaningful except in relation to something else that wants to connect over that address
<fwereade> hazmat, re goal state
<fwereade> hazmat, at least knowing that 8 more units are coming
<fwereade> hazmat, will allow you to hold off on configuring until you can see those 8 units, and they have told you their zones
<hazmat> fwereade, zone in env var vs unit-get.. i'm fine either way.. i'd rather not get rid of unit-get.. and we have tons of dynamic env vars as well. so the distinction between the two mechanisms isn't really clear. cli commands are much more discoverable then undocumented env vars.
<hazmat> but that's a separate case of actually documenting things that are implemented
<fwereade> hazmat, I heartily agree that dynamic env vars are likely to be bugs, because we generally don't trigger on changes to same
<fwereade> hazmat, state server address
<fwereade> hazmat, proxy settings
<fwereade> hazmat, no doubt more
<hazmat> fwereade, re zone and goal state awareness, that feels like perfect enemy of good to paraphrase ;-)
<hazmat> fwereade, potentially we could surface goal state awareness to leader to coordinate at some point
<fwereade> hazmat, (fwiw I agree that https://juju.ubuntu.com/docs/authors-hook-environment.html#environment-variables is *incomplete*)
 * fwereade glares around at everybody who may at some stage have added env vars without updating the docs
<hazmat> leader election alone is the probably the biggest feature thats missing atm for charm authors (resource impl would be second). the zone spread behavior we currently exhibit has good enough effects for many, getting units to at least be zone aware allows more featureful things to be built.
<hazmat> fwereade, goal state will never substitute for the need to handle runtime changes
<fwereade> hazmat, I think goal state is necessary across the board so units can differentiate between waiting and blocked
<fwereade> hazmat, I know that
<hazmat> fwereade, and initial bring up has minimal thrashing due to lack of data
<fwereade> hazmat, subsequent scaling, not so much
<fwereade> hazmat, to restate the above, goal state feels like a necessary part of the status work
<fwereade> hazmat, "I'm waiting for the rest of my cluster" vs "I can't do anything, 2/3 of my cluster is not talking to me HALP"
<hazmat> fwereade, i think its useful to surface to the leader determing service health/status
<hazmat> fwereade, but i don't see any reason that it can't be independently implemented later
<fwereade> hazmat, ok, to take a step back
<hazmat> fwereade, right.. but i don't think its useful to block features till their perfect, nothings perfect, but we incremental advance the state
<fwereade> hazmat, I'm not trying to block anything
<hazmat> k
<fwereade> hazmat, AFAICS there is no disagreement re exposing to units what zone they're in
<fwereade> hazmat, the more we add, the more quibbles I have, because I worry that it's prejudicing other features like goal state
<hazmat> fwereade, service leader determining service state just provides proper point of invocation/consideration of goal state in future
<hazmat> afaics
<fwereade> hazmat, goal state allows units to report status better
<fwereade> hazmat, so they can tell the difference between "I'm not working yet and that's fine because I know friends are coming" and "I'm not working yet and I never will until something changes"
<fwereade> hazmat, but that is indeed a separate conversation
<hazmat> fwereade, the leader should make that distinction, units should really just report their own state knowledge not service
<hazmat> fwereade, ie the unit scope is the unit. the leader scope is the service
<fwereade> hazmat, it's not just about peers, is it?
<fwereade> hazmat, "I don't work because I can't talk to the one database I know about" may or may not have a "yet" in there, depending on whether or not more units are going to join
<fwereade> hazmat, and that's the distinction between "still coming up, part of a big deployment,some error rate is expected" and "I have no reason to believe anything will ever work"
<hazmat> fwereade, re peers.. i think in practice we'll find leaders useful for actions, status, etc .. ie beyond peers.
<fwereade> hazmat, yellow vs red
<fwereade> hazmat, agreed
<fwereade> hazmat, I'm talking about goal states, not leaders -- they'll be useful both to leaders and to other units
<hazmat> fwereade, unit level my db isn't there yet.. is still unit level. that status will change as the db comes up... ie. knowing the goal state doesn't change the status
<hazmat> ie. imo knowing goal state is for leaders and orchestrators.
<fwereade> hazmat, it's the difference between *that unit* being blocked vs waiting
<fwereade> hazmat, I have to pop out, can we pick back up in a bit please?
<hazmat> fwereade, even then i have to know the health of the remote side to properly evaluate.
<hazmat> fwereade, its turning into a topology awareness problem instead of a unit problem
<hazmat> fwereade, k
<fwereade> hazmat, (fwiw I am super happy that you are engaging on this problem, am *very* keen to talk more about it)
<voidspace> I'm going offline for a bit
<voidspace> maybe see you later
<jw4> OCR, thumper : PTAL http://reviews.vapour.ws/r/616/
<jw4> addressed feedback from thumper ^^
<thumper> sinzui: what's the status of the CI runs to unblock trunk?
<sinzui> master still fails on deploy joyent
<sinzui> thumper, I ponder if precise is the issue
<thumper> sinzui: I thought that dimiter said he tested it...
 * thumper sighs
<sinzui> thumper, test failed 3 times on master, but the immediate 1.21-beta4 tests that followed passed
<thumper> hmm...
<thumper> sinzui: so it still seems like something in the master branch is causing failures?
<sinzui> thumper, yes. I was pondering rerunning tip with some extra joyent jobs to compare precise with trusty
<thumper> sinzui: is the same test passing on trusty but not precise?
<sinzui> thumper, it didn't for  me, but since several people said it worked, I wondered is series as a factor
<ericsnow> jw4: taking a look
<jw4> ericsnow: ta
<wwitzel3> ericsnow: ping
<ericsnow> wwitzel3: hey
<ericsnow> wwitzel3: brt
<thumper> menn0: got a minute?
<menn0> thumper: yep[
<jw4> ericsnow: great feedback - thank you!
<ericsnow> jw4: you bet :)
<perrito666> it is amazing how, whenever I try to write a spec all possible noises and movement happen in the house
<menn0> thumper: this joyent problem isn't fixed at all
<menn0> thumper: it still happens with the 1.21 branch, even with Dimiter's change in
<menn0> thumper: and it still happens with master
<menn0> thumper: and it happens with 1.21 beta3
<menn0> thumper: going to try 1.20 to try and figure out where it started
<menn0> thumper: and start a conversation with Joyent
<bac> hi alexisb, do you know who is responsible for https://juju-docs.readthedocs.org/en/latest/ ? i think it should be updated or removed.
<menn0> thumper: here's the problem but their fix is a bit shite. https://help.joyent.com/entries/21748665-Private-vlans-are-not-routing-to-each-other-by-default-
<waigani_> I have a branch which relies on another branch which is yet to land. Is there a special dance I have to do to make github/reviewboard handle the diffs correctly?
<perrito666> waigani_: I believe there is a dance you can do to have reviewboard know about this, you will have to ask ericsnow
<waigani_> perrito666: thanks. ericsnow?
<ericsnow> waigani_: rbt post -u --parent <name-of-parent-branch>
<waigani_> ericsnow: sweet. thanks
<ericsnow> waigani_: you'll also have to do that every time you push up to your branch
<waigani_> ericsnow: right. good to know.
<waigani_> ericsnow: when I push the initial pr to github, it is automatically added to RB. Should I follow up with the rbt post to flag the correct parent?
<ericsnow> waigani_: correct
<ericsnow> waigani_: I've hoped to have time to implement code that takes care of the dependent branch dance but haven't had time
<ericsnow> waigani_: until then it's manual (and you end up with twice as many patch revisions in reviewboard)
<waigani_> ericsnow: ah really? as long as we have a working solution, that is good enough for now.
<ericsnow> waigani_: cool
<ericsnow> waigani_: I use --parent with rbt all the time
#juju-dev 2014-12-12
<davecheney> so I used git pull -r and now my working copy is fucked
<davecheney> thanks
<thumper> menn0: that is indeed a shitty problem
<perrito666> davecheney: rebase?
<perrito666> man a year in go and my python is all kinds of rusty
<thumper> ha
<mwhudson> davecheney: o
<mwhudson> davecheney: i've been reduced to hacking locally and doing edits through the github web ui...
<menn0> axw: ping
<axw> menn0: pong
<menn0> axw: do you know anything about provisioners and cloud-init?
<axw> menn0: a reasonable amount, yes - what do you need to know?
<menn0> i'm dealing with this Joyent networking issue
<menn0> axw: hangout might be more efficient
<axw> menn0: sure
<menn0> axw: calling you know
<menn0> axw: now even
<axw> menn0: I don't know what the deal is exactly, but your machine has networks that don't show up in sdc-listnetworks
<menn0> what does sdc-listnetworks show?
<menn0> axw: ^
<axw> menn0: sec, pastebinning
<axw> menn0: http://paste.ubuntu.com/9484090/
<axw> menn0: http://paste.ubuntu.com/9484113/
 * menn0 looks
<menn0> axw:  that matches
<menn0> those networks match what's on the interfaces
<menn0> axw: well all but one
<axw> menn0: can you try hacking up the environ_instance.go code to add those network IDs I listed in the CloudMachineOpts.Networks field?
<axw> I think what's happening is that in lieu of us specifying the network, Joyent automatically creates an internal and external subnet for each instance
<menn0> axw: actually, no they all match up
<axw> which may or may not be routable
<axw> between each instance I mean
<menn0> but I don't think adding those network ids will help
<menn0> because those private networks can't route to each other
<axw> menn0: I mean the IDs from sdc-listnetworks
<menn0> and that matches what the machines have anyway
<axw> menn0: the ones from sdc-listnetworks are different to what's allocated to the machines
<menn0> no they're not :)
<menn0> axw: ^
<menn0> axw: they're just network addresses
<axw> menn0: ?? in my first pastebin, "id" for each network returned by sdc-listnetworks is different to what's in sdc-listmachines
 * menn0 looks again
<axw> I expect the subnet in the names of the networks in the second pastebin to match what's on the machine, because those are for the networks assigned to the machines
<menn0> axw: but they do!
<menn0> axw: it's a little tricky to work out because they're /21
<menn0> axw: but when you do, you'll see they match
<menn0> axw: the networks in the output from sdc-getnetwork are network addresses
<menn0> axw: if you take the ip and netmask of the interfaces on the hosts
<menn0> axw: and calculate the network address
<menn0> axw: you end up with those networks
<axw> menn0: right, I understand those are the same as what's on the machine
<axw> those are the networks assigned to the machines
<axw> what I'm saying is that each machine has separate networks
<axw> and those networks are not what's in sdc-listnetworks
<menn0> axw: right
<menn0> axw: now I've got you
<menn0> axw: so I should try using the networks returned by sdx-listnetworks?
<axw> so, try modifying CreateMachineOpts to include the IDs from the top of the first pastebin
<axw> right
<axw> 5983940e-58a5-4543-b732-c689b1fe4c08 and 9ec60129-9034-47b4-b111-3026f9b1a10f
<menn0> axw: yep. i'll try that
<menn0> ok change made
<menn0> so juju upgrade-juju --upload-tools and then add a new machine?
<menn0> axw: what are those networks anyway? can you use sdc-getnetwork to see?
<axw> menn0: you'll need to rebootstrap or machine 0's network won't be changed
<axw> will see if I can get more detail about the networks
<menn0> axw: yeah, but what if joyent expects the new envrionment to use a different network?
<axw> menn0: https://apidocs.joyent.com/cloudapi/#CreateMachine
<axw> networks	Array	Desired networks ids, obtained from ListNetworks
<menn0> ok
<axw> given that, I'm assuming it's valid...
<menn0> axw: i'll give it a try
<axw> it's not particularly clear
<axw> sdc-getnetwork doesn't give much information, just whether it's public or private
<menn0> axw: I've been reading the API docs as this env bootstraps and the networks stuff is very vague isn't it?
<axw> menn0: yes, it is a bit
<menn0> axw: ok machine-0 is up
<menn0> interestingly, eth0 is now the internal interface and eth1 is the external so I think this change has done something
<menn0> axw: seems functionally fine though
<menn0> axw: adding more machines
<axw> menn0: it's still created separate networks *shrug*
<menn0> menn0: where can you see that? those machine just coming up now
<axw> menn0: sdc-listmachines shows it
<menn0> axw: right
<menn0> axw: i'm just checking now what they actually get
<menn0> axw: yeah, different networks
<menn0> axw: these are all going to fail to come up
<axw> menn0: I'm out of ideas
<menn0> axw: so am i
<menn0> axw: i've just been looking at the cloud-init userData for clues (I modified the tools to log that too)
<menn0> axw: nothing stands out
<menn0> axw: might have to wait until we hear back from Joyent
<axw> menn0: it has to be a Joyent thing, the API is telling me they've been assigned different subnets
<axw> cloud-init can't affect that
<menn0> axw: the only workaround I can think of in the mean time is to have cloud-init install that static route
<menn0> axw: I'll email the list and ask if we can have this no longer be CI blocking
<menn0> axw: thanks for all the help anyway
<axw> menn0: no worries
<axw> menn0: if it's not too late, and you've got some time, I'd appreciate a glance over http://reviews.vapour.ws/r/604/
<axw> if you're about to EOD then just leave it for next week
<menn0> axw: I was about to EOD but I might be able to squeeze it after this email...
<menn0> axw: reviewing now
<axw> menn0: thanks
<menn0> axw: can you remember which file in the PR had the conflict?
<menn0> axw: never mind. all done. Ship It!
 * fwereade has actually succumbed to the fluey thing that's been hovering over him all week :-/
<fwereade> I think it would be a very good idea if someone were to fix https://bugs.launchpad.net/bugs/1297559 for 1.18, there's a branch already, haven't looked at it but description is sane
<mup> Bug #1297559: upgrade-charm fails because of git  <canonical-is> <git> <upgrade-charm> <juju-core:Fix Released by fwereade> <juju-core 1.18:Triaged> <https://launchpad.net/bugs/1297559>
<dimitern> fwereade, hey
<dimitern> fwereade, I guess you'll be off mostly today then - get well soon!
<dimitern> TheMue, still otp?
<jamespage> dimitern, morning - can you point me in the direction of where the lxc config files are generate for Juju with MAAS provider?
<dimitern> jamespage, morning
<dimitern> jamespage, just a sec
<dimitern> jamespage, is that the mtu bug you've just reported?
<jamespage> dimitern, well its related to the mtu setting problem I've had for a while
<jamespage> (that bug is old-ish)
<jamespage> https://bugs.launchpad.net/ubuntu/+source/juju-core/+bug/1355813
<mup> Bug #1355813: Interface MTU management across MAAS/juju <add-unit> <amd64> <apport-bug> <cts> <cts-cloud-review> <landscape> <network> <placement> <smoosh> <trusty> <uec-images> <juju-core:Triaged> <MAAS:New> <juju-core (Ubuntu):Triaged> <lxc (Ubuntu):Invalid> <https://launchpad.net/bugs/1355813>
<jamespage> dimitern, configuring maas to set the physical host interfaces to mtu 9000 is quite easy using dhcp
<jamespage> dimitern, more tricky with the LXC containers which then foobar that configuration
<dimitern> jamespage, so does it seem it's related to juju-br0 config that gets generated at cloudinit time?
<dimitern> jamespage, I doubt it's the lxc config for individual containers, as that's pretty basic
<jamespage> dimitern, juju-br0 gets the correct mtu, but as soon as the veth's for LXC containers get plugged into it, it drops down to the lowest - 1500 be detaul
<dimitern> jamespage, ah, so it's the veth then
<dimitern> jamespage, if you tweak networkTemplate and writeLxcConfig in container/lxc.go you can add the necessary lxc.network.xyz settings there
<jamespage> dimitern, ack
<jamespage> dimitern, I was trying to think how this could be generally improved
<jamespage> dimitern, detecting the physical interface mtu and using that would make sense
<TheMue> dimitern: voidspace: so, phone call done. has been an important one by the mobile phone company, saving money now ;)
<dimitern> TheMue, nice!
<TheMue> dimitern: voidspace: my news for today is the ending of the yaml.v1 test fixes. done the major changes yesterday but found two new/unknowns test cases. one is done, one is now in progress, so I hope I can propose it in a few minutes
<dimitern> TheMue, sounds good
<dimitern> jamespage, that's definitely a possibility
<voidspace> TheMue: cool
<dimitern> jamespage, especially if there's a feature bug filed so we won't forget it :)
<perrito666> good morning
<perrito666> natefinch: apparently chocolate and butter cookies are not something to be eaten in the amounts I did
<perrito666> did you get my email?
<TheMue> dimitern: ping
<dimitern> TheMue, pong
<TheMue> dimitern: could you do me a favor and run go test in juju/juju/worker?
<TheMue> dimitern: I've got errors there even in trunk
<TheMue> dimitern: notifyworker and stringsworker fail
<dimitern> TheMue, sure, will do now - what errors?
<TheMue> dimitern: we expect []string{"setup"} but get []string(nil)
<dimitern> TheMue, could it be an issue that could be resolved by running godeps -u dependencies.tsv?
<TheMue> dimitern: I've done that before
<dimitern> TheMue, well, so far they pass - on the worker/uniter now
<TheMue> dimitern: astonishing
<TheMue> dimitern: so it's a local problem. have to take a deeper look at the dependencies.tsv. I've changed it, but switching the branch should had changed it back.
<dimitern> TheMue, all passed :/
<TheMue> dimitern: ok, thanks, helpful
<perrito666> are we still blocked on joyent?
<natefinch> fwereade: -
<natefinch> 3..bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbh-
<natefinch>              
<natefinch> damg kids
<dimitern> TheMue, voidspace, I'd really appreciate if you can have a look at http://reviews.vapour.ws/r/611/ - I know it's big, but 75% of the added lines are tests
<dimitern> maybe looking at the diff on GH will be better
<sinzui> natefinch, I once set IRC to only send with control+enter. Then one night a cat managed to type and send a message. People thought I fell a sleep at the keyboard.
<dimitern> sinzui, I think bug 1401130 should be taken off the ci blockers
<mup> Bug #1401130: Joyent instances sometimes can't communicate via the internal network <ci> <joyent-provider> <regression> <juju-core:In Progress by menno.smits> <juju-core 1.21:In Progress by menno.smits> <https://launchpad.net/bugs/1401130>
<sinzui> dimitern, I am thinking about. I agree the issue is everywhere. I am looking for evidence in CI that master had some bad luck, that the situation is not worse
<dimitern> sinzui, or at least taken down in priority - it seems like an inane joyent issue which was there for some time now
<sinzui> dimitern, I don't think we can lower the priority given the systemic unreliability of menno's report. I am using joeynt with 1.20x a lot and it is quite reliable. we also completed a round of reliability tests with on joyent using 1.20.13, 1.20.14, 1.21.beta4, and and older version of 1.22-alpha1, and joyent was very reliable
<dimitern> sinzui, well, if the failure happens "sometimes" after adding more than 2 machines how can you be sure the tests were simply not hitting the issue often enough?
<dimitern> mgz_, are you around?
<sinzui> dimitern, I am proposing to my team that we retest master now. we can see Joyent is healthy with 1.20.x
<dimitern> sinzui,  right, can you test both with default-series: precise and trusty ? I suspect trusty has it, while precise doesn't (different networking setup)
<sinzui> dimitern, ci tests wil precise most of the time for joyent.
<sinzui> well.
<sinzui> the deploy test was precise. The health check is trusty
<sinzui> okay, I am adding a test to cover both right now
<dimitern> sinzui, but the health check just does bootstrap + destroy, right?
<dimitern> sinzui, it my tests yesterday I've seen quite frequently destroy-environment hanging for a long time, even after the instances were stopped
<dimitern> sinzui, also there's a z-joyent-something job to clean up old running machines, which is not working due to some --old-age arg not being recognized; and I could see quite a few running yesterday
<sinzui> dimitern, the health check deploy one service
<dimitern> sinzui, going back a few lines - the health check job is not enough to trigger the issue, menno said he had to spin up 10 machines sometimes to reproduce it, but still wasn't reliable
<sinzui> dimitern, yes I saw the hang often this week. was deploying bundles on Monday and Tuesday. Deployments were a success, but destroy-env hung twice. I confirmed that machines were shutdown and deleted.
<sinzui> dimitern, I agree about the machine count. We will retest master. The situation is that in 7 days master have never passed, yet 1.21-beta4 did pass when it was tested
<dimitern> sinzui, right, the workaround menno discovered - adding a static route for 10.0.0.0 in cloudinit seems to fix the connectivity issues when they happen, so this is probably the correct fix
<dimitern> sinzui, but without a definite way of reproducing it..
<sinzui> dimitern, isn't that too wide?
<dimitern> sinzui, it's both wide and also nasty, but if that's how it has to be..
<dimitern> sinzui, I hope it won't introduce other regressions - like the ability to see and talk to instances foreign to the environment
<sinzui> dimitern, CI noticed I added a new test and immediately started testing with 1.21-beta4. I will let it complete so that we have a comparison of the two branches
<dimitern> sinzui, cool
<sinzui> dimitern, if we get passes for 1.21 and master, I will change the precise version to non-voting, which will prevent the test from curing the revision. That will justify the the removal of regression
<sinzui> dimitern, beta4+trusty+joyent just passed. I am starting the retest of master
<dimitern> sinzui, \o/
<wwitzel3> ericsnow: ping
<ericsnow> wwitzel3: hey
<ericsnow> wwitzel3: coming
<perrito666> btw voidspace fwereade you are OCR I have a couple of things in queue if you want to take a look
<voidspace> perrito666: I can try shortly
<perrito666> tx they are very small
<perrito666> because I didnt want to spoil your friday
<voidspace> perrito666: :-)
<perrito666> are the critica bugs really still open?
<perrito666> I saw an email from menn0 with a complelling argument against having the joyent one a blocker
<voidspace> perrito666: joyent was "more info needed" and the other was "fix committed"
<voidspace> right
<coreycb> aisrael, marcoceppi_, I'm trying to use https://github.com/juju-solutions/juju-action and when I run a command the "if service in services" check in action.py is never true.  have any tips?  I'm probably doing something dumb.
<marcoceppi_> coreycb: we've abandonded that
<coreycb> marcoceppi_, got any alternatives?
<marcoceppi_> coreycb: yeah, juju-actions fork of the juju core
<coreycb> marcoceppi_, k thanks
<marcoceppi_> coreycb: https://github.com/juju-actions/juju/tree/actions
<jw4> coreycb, marcoceppi_ hopefully we'll be landing these into juju core in the next few days - using a feature flag
<coreycb> jw4, marcoceppi_, awesome, thanks
<bac> marcoceppi_, tvansteenburgh: amulet PR when you have a chance: https://github.com/juju/amulet/pull/59
<tvansteenburgh> bac: ack
<bac> mramm: we've asked for lp:~yellow to be added to lp:~rhinos so we can work on lp:convoy.  could you approve the invite?
<voidspace> perrito666: two LGTMs
<perrito666> voidspace: tx
<perrito666> fwereade: ping
 * dimitern sings and dances \o/
<dimitern> we have lp:goamz migration to github ! https://github.com/go-amz/amz
<natefinch> dimitern: awesome!  Man, about time :)
<natefinch> dimitern: btw, check out https://github.com/stripe/aws-go
<dimitern> natefinch, cheers :)
<dimitern> natefinch, oh nice - autogenerated ?
<natefinch> yep
<natefinch> dimitern: I haven't had a chance to check it out, but if it's based on schema provided by AWS, that's pretty nice
<katco> can anyone tell me why this is giving a go vet warning? logger.Logf(loggo.INFO, fmt.Sprintf("%s: %s", user.Tag(), format), args...)
<katco> "constant 3 is not a string in call to Logf"
<katco> i'm stumped
<katco> brb tea
<jw4> katco: you switched to go 1.4 didn't you
<jw4> katco: davecheney filed a bug in go vet for that issue
<jw4> katco: I proposed a fix a few weeks ago that he nixed b'cause it was ugly
<katco> jw4: ah yes i did
<katco> so back to 1.3 i guess?
<jw4> katco: that's what I ended up doing
<katco> bleh
<katco> jw4: do you happen to have the tracker for the bug?
<katco> jw4: the url i mean
<jw4> katco: already looking for it
<jw4> :)
<katco> jw4: you are kind! :)
 * katco starts switching back to 1.3
<jw4> katco: https://code.google.com/p/go/issues/detail?id=9080
<katco> jw4: ty!
<jw4> katco: my proposed (ugly) fix - https://github.com/juju/juju/pull/1087
<jw4> katco: comments on the migrated issue (https://github.com/golang/go/issues/9080) might be helpful
 * jw4 investigating
<katco> jw4: don't worry about it, i'll just use 1.3 for Juju until it's fixed
<jw4> katco: kk (but I've got my own inquisitiveness up again)
<katco> jw4: an easier fix might just be to combine those args in audit.go into a single string
<katco> jw4: assign it to a var and pass it in that way
<jw4> katco: yeah - I need to look again, but I thought there was deferred execution involved - but I may be wrong
<jw4> anyway, looking at our verify.bash script this might actually be a trivial fix
<voidspace> EOW
<voidspace> have a good weekend all
<katco> tc voi
<jw4> katco: tut tut - autocomplete doesn't work when they've disconnected
<katco> hehe
<jw4> katco: http://reviews.vapour.ws/r/630/
<jw4> OCR PTAL ^^
<jw4> (although I think both voidspace and fwereade are gone now)
<ericsnow> jw4: I'll take a look
<jw4> ericsnow: ta
<ericsnow> jw4: Could you explain more about where go vet is finding a problem?
<jw4> ericsnow: yes sure - otp, but I'll connect in a minute
<ericsnow> jw4: I'm not seeing why it wants a string where loggo.INFO is being used.
<ericsnow> jw4: no worries
<jw4> ericsnow: I haven't actually delved into go vet - I'm just basing my fix on the new error message that go 1.4 gives with go vet
<ericsnow> jw4: does go vet recurse? (i.e. does the loggo package pass?)
<jw4> ericsnow: go vet actually allows you to specify -printfuncs=Logf:1 to tell go vet to ignore the first param, which avoids this error message, but introduces 30 new ones
<jw4> ericsnow: no, I don't think go vet recurses
<ericsnow> jw4: yeah, I'd doubt it
<jw4> ericsnow: I think this fix actually works mostly because the name of the function doesn't match Logf anymore
<jw4> ericsnow: my previous suggestion a month or so ago that davecheney rightfully shot down was to introduce a local func var with a different name :)
<ericsnow> jw4: why would Logf be special?
<jw4> ericsnow: it matches a pattern that go vet is designed to look for
<ericsnow> jw4: the thing that makes me confused is that loggo.INFO is a loggo.Level (a uint32) and logger.Logf takes a Level in the spot where INFO is passed)
<jw4> ericsnow: I can tell you're gonna force me to actually look at go vet source
<ericsnow> jw4: nah
<jw4> ericsnow: yeah - there is absolutely nothing wrong with the code
<jw4> ericsnow: we're just trying to pacify go vet
<ericsnow> jw4: but it may be worth noting in a comment that we're working around a go vet bug
<ericsnow> jw4: it's a bug, right?
<jw4> ericsnow: forest / trees
<jw4> ericsnow: yep
<jw4> ericsnow: I will update the comment
<ericsnow> jw4: has a bug report been opened? If so, a link to it could go into the comment.
<jw4> ericsnow: +1
<jw4> ericsnow: for the record: https://github.com/golang/go/issues/9080
<ericsnow> jw4: cool
<ericsnow> jw4: I opened an issue in my review for that (and LGTM)
<jw4> ericsnow: ta - my update is pushed now too
<ericsnow> jw4: looks good
<jw4> kk - no point in rushing for a senior sign off yet - I doubt CI will open before Monday :-/
<jw4> on the bright side - I, and katco, can now begin using go 1.4 for juju dev :)
<katco> :)
<jw4> katco: after you've done all the work of reverting
<katco> jw4: it's not work at all... i have them installed side-by-side ~/.local/go-1.{3.4|4.0}
<katco> symlink
<jw4> katco: I actually have a fairly useful scheme involving symlinks that allows me to easily switch between go versions while maintaining separate .... well I'll send this comment anyway :)
<katco> haha
<jw4> katco: you beat me to it - brevity wins every time
<katco> os x does much the same thing i think
<jw4> brevity or symlinks?
<jw4> ;)
<katco> lol
<jw4> FWIW, ntfs has a pretty decent symlink lookalike too : junctions
<katco> i have no reason to use that anymore
<jw4> "she said with a faint curl to her lip"
<katco> haha
<katco> this branch is going to be the death of me
<perrito666> katco: welcome to restore
<perrito666> :p
<katco> perrito666: lol
<katco> perrito666: i'm refactoring cmd/jujud =|
<perrito666> is anyone doing anything with the joyent issue?
<wwitzel3> ericsnow: ping
<ericsnow> wwitzel3: pong
<wwitzel3> ericsnow: I'm in moonstone
<ericsnow> brt
<jw4> any chartered reviewers willing to LGTM http://reviews.vapour.ws/r/630/ and maybe even authori(s|z)e JFDI? :)
 * jw4 likes working in go 1.4
#juju-dev 2014-12-13
<jw4> davecheney: in loggo and juju-core (github.com/juju/loggo and github.com/juju/juju) LogCallf is only used directly in this area.  logger.Logf is harder to check with grep, but I can try renaming and compliling to see where it breaks
#juju-dev 2015-12-07
<davecheney> ping anyone around who can reivew https://github.com/juju/juju/pull/3899
<mup> Bug #1513084 changed: 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:Won't Fix> <https://launchpad.net/bugs/1513084>
<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:Won't Fix> <https://launchpad.net/bugs/1513084>
<mup> Bug #1513084 changed: 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:Won't Fix> <https://launchpad.net/bugs/1513084>
<davecheney> ping anyone around who can reivew https://github.com/juju/juju/pull/3899
<blackboxsw> https://docs.google.com/document/d/1xzQh-2RCo798SFA5Ac3W-Mk5nhWvdHBxtWRdRTmu5Ts/edit
<blackboxsw> landscape-crew ^
<blackboxsw> oops
<blackboxsw> wrong channel
<frobware> voidspace, you about?
<frobware> voidspace, http://reviews.vapour.ws/r/3328/
<voidspace> frobware: finally online and on freenode
<voidspace> frobware: sorry about that
<frobware> voidspace, PTAL @ http://reviews.vapour.ws/r/3328/
<frobware> voidspace, and then I can land a real fix. :)
<voidspace> frobware: looking
<voidspace> frobware: LGTM
<frobware> voidspace, ty
<frobware> voidspace, PTAL @ http://reviews.vapour.ws/r/3329/
<voidspace> frobware: will look shortly
<voidspace> frobware: LGTM
 * frobware waves at the Oakland sprint... o/
<mup> Bug #1523626 opened: enable-os-refresh-update: false causes bootstrap to fail <juju-core:New> <https://launchpad.net/bugs/1523626>
<mup> Bug #1523608 opened: MAAS 1.9rc3 + Juju 1.25.0:  bootstrap fails, unit has same IP assigned to eth0 and juju-br0 <uosci> <juju-core:New> <MAAS:Incomplete> <https://launchpad.net/bugs/1523608>
<mup> Bug #1516541 changed: payload/api/private: tests do not pass <juju-core:Fix Released by ericsnowcurrently> <https://launchpad.net/bugs/1516541>
<jam> frobware: ping. Just wondering what you're plans are for this week. Are you working regular hours or timeshifting or on holiday? :)
<frobware> jam: trying to timeshift - mostly with the exception of tomorrow where I plan to start very early and finish by 2pm.
<jam> frobware: k. We're going over our plan for the week, so if there is anything you want us to put high in priority, let us know
<frobware> jam: CI h/w for testing openstack deployments on MAAS
<jam> frobware: isn't that the hardware that is coming in on Dec 9th?
<jam> or is that different HW ?
<frobware> jam: paas (or maybe I need to read my email)
<frobware> jam: ah. is that general CI h/w?
<jam> frobware: they are supposed to be getting 6-ish large machines to run a lot of VMs for MAAS CI testing
<jam> I thought that included deploying an openstack and upgrading it
<frobware> jam: it seems we will need some significant setup on the MAAS side for vlans/spaces, et al.
<frobware> cherylj, I will investigate 1523608 tomorrow (or later today)
<perrito666> has anyone ever bumped against juju claiming: no registered provider for "local" ?
<mup> Bug #1523626 changed: enable-os-refresh-update: false causes bootstrap to fail <juju-core:Won't Fix> <https://launchpad.net/bugs/1523626>
<mup> Bug #1523626 opened: enable-os-refresh-update: false causes bootstrap to fail <juju-core:Won't Fix> <https://launchpad.net/bugs/1523626>
<mup> Bug #1523626 changed: enable-os-refresh-update: false causes bootstrap to fail <juju-core:Won't Fix> <https://launchpad.net/bugs/1523626>
<mgz> wallyworld: see bug 1320312 also, which is about the default behaviour not on aws being bad
<wallyworld> mgz: sinzui: bug 1523693
<mup> Bug #1320312: fallback to unsigned stream metadata may have security issues <improvement> <metadata> <security> <simplestreams> <juju-core:Triaged> <https://launchpad.net/bugs/1320312>
<mup> Bug #1523693: Support centos and windows image metadata <juju-core:Triaged by wallyworld> <https://launchpad.net/bugs/1523693>
<mup> Bug #1523693 opened: Support centos and windows image metadata <juju-core:Triaged by wallyworld> <https://launchpad.net/bugs/1523693>
<mup> Bug #1523693 changed: Support centos and windows image metadata <juju-core:Triaged by wallyworld> <https://launchpad.net/bugs/1523693>
<mup> Bug #1523693 opened: Support centos and windows image metadata <juju-core:Triaged by wallyworld> <https://launchpad.net/bugs/1523693>
<mup> Bug #1523693 changed: Support centos and windows image metadata <juju-core:Triaged by wallyworld> <https://launchpad.net/bugs/1523693>
<mup> Bug #1523693 opened: Support centos and windows image metadata <juju-core:Triaged by wallyworld> <https://launchpad.net/bugs/1523693>
<beisner> frobware, yep, will plan to kick off a wily of the same.  but the cloud-init sru / version bump is highly suspect imho
<beisner> frobware, i'm eod, will have to revisit in the US morning tomorrow.
<frobware> beisner, I wanted to add some automated testing in this area as I'm changing the bridging script quite a bit at the moment
<frobware> beisner, ack. time for me to EOD too.
#juju-dev 2015-12-08
<mup> Bug #1522948 opened: ensure-availability on rackspace spawns endless machines <ci> <ensure-availability> <ha> <rackspace-provider> <juju-core:Incomplete> <https://launchpad.net/bugs/1522948>
<mup> Bug #1522948 changed: ensure-availability on rackspace spawns endless machines <ci> <ensure-availability> <ha> <rackspace-provider> <juju-core:Incomplete> <https://launchpad.net/bugs/1522948>
<mup> Bug #1522948 opened: ensure-availability on rackspace spawns endless machines <ci> <ensure-availability> <ha> <rackspace-provider> <juju-core:Incomplete> <https://launchpad.net/bugs/1522948>
<mgz> jam: http://juju-ci.vapour.ws/job/run-unit-tests-mongodb3/ was not super health when last run
<perrito666> axw_: I believe what nate found is a bug where DestroyVolumes is getting something other than what it expects in term of volume identifier :(
<wallyworld> sinzui: quick +1 on my licence foo? https://github.com/juju/utils/pull/182
<natefinch> sinzui: kvm-slave isn't resolving for me
<mup> Bug #1523783 opened: Bootstrap failures: ERROR upgrade in progress - Juju functionality is limited <oil> <juju-core:New> <https://launchpad.net/bugs/1523783>
<mup> Bug #1523783 changed: Bootstrap failures: ERROR upgrade in progress - Juju functionality is limited <oil> <juju-core:New> <https://launchpad.net/bugs/1523783>
<mup> Bug #1523783 opened: Bootstrap failures: ERROR upgrade in progress - Juju functionality is limited <oil> <juju-core:New> <https://launchpad.net/bugs/1523783>
<voidspace> frobware: morning
<voidspace> frobware: we going to do standup today?
<frobware> frobware, morning!
<frobware> voidspace, can do. I was trucking along with bridge per active NIC
<voidspace> cool
<voidspace> ditto on the apiserver side of the new facade
<voidspace> first things first though
<voidspace> coffee
<frobware> voidspace, want to meet now?
<frobware> ah
<voidspace> :-)
<voidspace> gimme 10
<voidspace> I'll ping you when I have coffee
<voidspace> frobware: ok
<frobware> voidspace, in the HO
<voidspace> omw
<TheMue> heyz and good morning, I thought you're in SFO/OAK right now? *stunning*
<frobware> voidspace, any comments on https://github.com/frobware/juju/blob/master-multi-bridge-support/provider/maas/n.py would be appreciated. It's not the final name, just the bridge per NIC variant as we discussed in the standup.
<voidspace> frobware: looking
<frobware> ty
<voidspace> it's *so* much nicer than the bash
<voidspace> I actually understand what it's doing...
<mup> Bug #1523837 opened: juju add-relation blocked Waiting for agent initialization to finish <juju-core:New> <https://launchpad.net/bugs/1523837>
<voidspace> the interesting stuff is in bridge_iface
<voidspace> frobware: it doesn't seem like it would be resilient against broken / strange eni formats
<voidspace> frobware: but I'm not sure that's possible, we're not trying to solve the general case
<frobware> voidspace, agreed.
<voidspace> frobware: for example, the split on line 190 will break if there are not exactly four results from the split
<frobware> voidspace, because the /e/n/i we parse is machine generated.
<voidspace> right
<frobware> voidspace, I wasn't attempting a generic parser; for that you would really have to make it token based.
<voidspace> yeah
<voidspace> and it would be better to find one already built
<voidspace> but then bundling dependencies in cloud-init becomes problematic
<voidspace> so better to avoid going there if we can
<voidspace> frobware: it looks good to me
<voidspace> frobware: I can't see any problems with it (not there aren't any - just I can't see them!!)
<voidspace> frobware: and the Python is good, very readable
<frobware> voidspace, the tests are still in Go which helps prove the generation of the script that gets run on the bootstrap host.
<voidspace> I would separate out the library and the script part so the library part can be unit tested
<voidspace> but maybe just black box testing the whole thing is sufficient
<voidspace> frobware: right, cool
<voidspace> and if we test the in/out of all the cases we know of then it's sufficiently tested
<voidspace> if it grows more we may want to unit test the components
<frobware> voidspace, I was very conscious I wanted to test the interaction in Go, hence leaving them as Go unit tests. Ordinarily, I would have added python-based unit tests.
<frobware> voidspace, for me there's two parts; re-rendering and making the interfaces active.
<frobware> voidspace, the latter is pointless as a unit test IMO
<voidspace> it's still essentially a text transformation, so a black box test works well
<voidspace> right
<frobware> voidspace, too many things on the target side can change; ubuntu series, kernel version, newer packages, et al.
<voidspace> needs to be a functional test
<voidspace> fun
<frobware> voidspace, right. I think we need those functional tests. I just don't see any point mocking the fact that the pseudo interface became active. it will always pass or fail - depending on what you want.
<voidspace> frobware: agreed
<frobware> voidspace, I think there are things we can do at the end of the script to verify that the default route still works, for example.
<voidspace> frobware: you could do that from Python too
<frobware> voidspace, sure. the whole thing would be python based now.
<TheMue> there seems to be a TheMue filter :D
<voidspace> TheMue: o/
<TheMue> voidspace: o/
<frobware> voidspace, it doesn't seem possible to rely the return value of ifup(1) or ifdown(1).
<voidspace> TheMue: have you started your new job yet?
<voidspace> frobware: ah... that's a nuisance
<voidspace> frobware: parse the results of ifconfig...
<TheMue> I'm only wondering that there's no sprint in OAK as it seems.
<voidspace> TheMue: the sprint is on, frobware and I aren't attending though
<TheMue> voidspace: Yep, sitting here creating a scalable message store in erlang.
<voidspace> TheMue: I have a nine month old baby and a tired wife and frobware has a wife going into hospital
<voidspace> TheMue: everyone else is there
<voidspace> TheMue: cool, you enjoying it? sounds like a challenge
<TheMue> voidspace: ah, ic. because I really would like to be there too. I love SFO.
<voidspace> TheMue: I'd love to be there too
<TheMue> voidspace: good reasons to stay at home, definitely.
<voidspace> yeah, unfortunately
<TheMue> voidspace: yeah, it's a challenge, especially the timeline for a first release :D technologically it's interesting and I reuse several experiences we've made during Juju development
<voidspace> cool
<voidspace> TheMue: a challenge is not a bad thing! glad your experience is proving useful
<TheMue> voidspace: definitely, I enjoy it. looking forward the numbers (of users, throughput, etc) when it is running in production
<mup> Bug #1517258 opened: juju 1.24.7 precise: container failed to start and was destroyed <oil> <juju-core:Triaged> <https://launchpad.net/bugs/1517258>
<frobware> beisner, hiya! do you still plan to try with wily?
<cherylj> frobware: are you still looking @ bug 1523608?
<mup> Bug #1523608: Timed out waiting for device sys-subsystem-net-devices-juju-br0.device <uosci> <juju-core:Triaged> <MAAS:Invalid> <https://launchpad.net/bugs/1523608>
<beisner> frobware, indeed.  cycling T & V atm.  interestingly, i'm now having T bootstrap success, still V fails.  W is up next.
<beisner> frobware, W bootstrap succeeded, V failed.  but i get this trying to deploy a charm to the W enviro.  is there a known issue?:
<beisner>  ERROR cannot upload charm: Post https://10.245.168.13:17070/environment/c08eab82-d996-4e0f-89df-97ed329a3b3e/charms?series=wily: EOF
<beisner> frobware, ok interesting.  i waited a bit, then re-attempted juju deploy, and it uploaded and started off to the races now.   i'll not get distracted with that issue atm (needed to wait), in the interest of getting our lab back up.
<mup> Bug #1523783 changed: Bootstrap failures: ERROR upgrade in progress - Juju functionality is limited <oil> <juju-core:New> <https://launchpad.net/bugs/1523783>
<frobware> cherylj, I can later (~ 1.5 hours)
<perrito666> since when do we have instance state on the status?
<mup> Bug #1522090 opened: Juju storage add fails with additional units <juju-core:New> <https://launchpad.net/bugs/1522090>
<mup> Bug #1522090 changed: Juju storage add fails with additional units <juju-core:Triaged> <https://launchpad.net/bugs/1522090>
<mup> Bug #1522090 opened: Juju storage add fails with additional units <juju-core:New> <https://launchpad.net/bugs/1522090>
<mup> Bug #1524021 opened: bootstrap timeout error should be more informative <uosci> <juju-core:Triaged> <https://launchpad.net/bugs/1524021>
<mup> Bug #1524021 changed: bootstrap timeout error should be more informative <uosci> <juju-core:Triaged> <https://launchpad.net/bugs/1524021>
<mup> Bug #1524021 opened: bootstrap timeout error should be more informative <uosci> <juju-core:Triaged> <https://launchpad.net/bugs/1524021>
<beisner> frobware, cherylj - you'll wanna see the last comment on bug 1523608  /o\
<mup> Bug #1523608: Timed out waiting for device sys-subsystem-net-devices-juju-br0.device <uosci> <juju-core:Triaged> <MAAS:Invalid> <https://launchpad.net/bugs/1523608>
<cherylj> beisner: ah!  glad you were able to get it to work.
<cherylj> and yeah, a better message would help
<beisner> cherylj, yeah, can i get a refund on my 1.5 days?  ;)
<cherylj> beisner: ha!  if only I could refund time
<beisner> ha!
<beisner> cherylj, frobware so anyway - thanks for your work on those too.   and future-work on the latter.
<frobware> beisner, cherylj: looks like I return to peace and harmony
<cherylj> frobware: for now...
<frobware> cherylj, You're gonna spoil xmas...
<cherylj> mwahahaha
<beisner> frobware, cherylj - weeee!
<thumper> alexisb: https://github.com/juju/juju/pull/3920
<thumper> katco: https://github.com/juju/retry/pull/3
<mup> Bug #1524064 opened: provider/lxd: remove manual steps to add images <lxd> <juju-core:Triaged by ericsnowcurrently> <https://launchpad.net/bugs/1524064>
<mup> Bug #1524077 opened: provider/azure: creating subnet fails if the environment name is too long <azure-provider> <juju-core:Triaged by axwalk> <https://launchpad.net/bugs/1524077>
<mup> Bug #1524077 changed: provider/azure: creating subnet fails if the environment name is too long <azure-provider> <juju-core:Triaged by axwalk> <https://launchpad.net/bugs/1524077>
<mgz> dooferlad: http://juju-ci.vapour.ws/job/functional-container-networking/4/console
<mup> Bug #1524077 opened: provider/azure: creating subnet fails if the environment name is too long <azure-provider> <juju-core:Triaged by axwalk> <https://launchpad.net/bugs/1524077>
<mup> Bug #1524089 opened: update-status is rather noisy when there is nothing to do <logging> <observability> <juju-core:Triaged> <https://launchpad.net/bugs/1524089>
<mup> Bug #1524089 changed: update-status is rather noisy when there is nothing to do <logging> <observability> <juju-core:Triaged> <https://launchpad.net/bugs/1524089>
<mup> Bug #1524089 opened: update-status is rather noisy when there is nothing to do <logging> <observability> <juju-core:Triaged> <https://launchpad.net/bugs/1524089>
<mup> Bug #1524089 changed: update-status is rather noisy when there is nothing to do <logging> <observability> <juju-core:Triaged> <https://launchpad.net/bugs/1524089>
<jam> dimitern: want an easy code review? https://github.com/juju/juju/pull/3922
<dimitern> jam, looking
<mup> Bug #1524089 opened: update-status is rather noisy when there is nothing to do <logging> <observability> <juju-core:Triaged> <https://launchpad.net/bugs/1524089>
<dimitern> jam, ship it
<dimitern> jam, http://reviews.vapour.ws/r/3342/
<dimitern> dooferlad, if you can spare some time I'd appreciate a look as well ^^
<wallyworld> mgz: review please :-) http://reviews.vapour.ws/r/3344/
<dooferlad> ack
<frobware__> dimitern, ping
<frobware__> dimitern, if you can drop me some email regarding the VLAN issue in the bridge script I'll take a look tomorrow.
 * frobware__ EOD
#juju-dev 2015-12-09
<cherylj> mgz: http://paste.ubuntu.com/13840643/
<mup> Bug #1524135 opened: 'debug-log' fails when logs are large when using db-log <logging> <juju-core:Triaged> <https://launchpad.net/bugs/1524135>
<mup> Bug #1524135 changed: 'debug-log' fails when logs are large when using db-log <logging> <juju-core:Triaged> <https://launchpad.net/bugs/1524135>
<mup> Bug #1524135 opened: 'debug-log' fails when logs are large when using db-log <logging> <juju-core:Triaged> <https://launchpad.net/bugs/1524135>
<mup> Bug #1524171 opened: make preupgrade disk space checks smarter <juju-core:Triaged> <https://launchpad.net/bugs/1524171>
<mup> Bug #1524171 changed: make preupgrade disk space checks smarter <juju-core:Triaged> <https://launchpad.net/bugs/1524171>
<mup> Bug #1524171 opened: make preupgrade disk space checks smarter <juju-core:Triaged> <https://launchpad.net/bugs/1524171>
<mup> Bug #1524190 opened: Undocumented update-status hook <juju-core:New> <https://launchpad.net/bugs/1524190>
<voidspace> frobware: I need coffee and the loo (bad timing)
<voidspace> frobware: can we postpone ten minutes?
<frobware> sure
<voidspace> frobware: omw
<voidspace> frobware: just a note
<voidspace> frobware: my internet switches over to fibre tomorrow
<voidspace> frobware: so I expect to be offline for some of tomorrow whilst the switch happens
<mup> Bug #1524297 opened: juju behaviour in multi-hypervisor OpenStack clouds <juju-core:New> <https://launchpad.net/bugs/1524297>
<frobware> voidspace, ack
<frobware> voidspace, pretty sure you'll like the net result though
<voidspace> frobware: :-)
<voidspace> frobware: gah, worked out the difference between my code and master
<frobware> voidspace, rebase gone awry, or something else?
<voidspace> frobware: it's not strictly between my code and master - it's my code and the apiserver/spaces stuff
<voidspace> frobware: there is a type mismatch, but we have this horrible piece of code called stateShim that works as an adaptor
<voidspace> From the code: stateShim forwards and adapts state.State methods to Backing   method.
<voidspace> *sigh*
<voidspace> so I'll move the common code first and then adapt the new api to use it
<mup> Bug #1524369 opened: i386 github.com/juju/juju/upgrades_test constant overflows int <blocke> <ci> <i386> <test-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1524369>
<mup> Bug #1524385 opened: local precise cannot be upgraded <ci> <local-provider> <precise> <regression> <upgrade-juju> <juju-core:Triaged> <https://launchpad.net/bugs/1524385>
<mup> Bug #1524385 changed: local precise cannot be upgraded <ci> <local-provider> <precise> <regression> <upgrade-juju> <juju-core:Triaged> <https://launchpad.net/bugs/1524385>
<mup> Bug #1524385 opened: local precise cannot be upgraded <ci> <local-provider> <precise> <regression> <upgrade-juju> <juju-core:Triaged> <https://launchpad.net/bugs/1524385>
<dimitern> frobware, hey there
<dimitern> frobware, I'm currently bootstrapping with your branch on 1.9 with 1 phys and 2 vlan nics on the vm
<dimitern> frobware, I'm not sure though if we should add multiple bridges by default in master yet, rather than do it in maas-spaces first
<dimitern> voidspace, o/
<voidspace> dimitern: o/
<dimitern> voidspace, how's the discovery going ? :)
<voidspace> dimitern: stateShim is an abomination
<voidspace> dimitern: I'm still moving code into common
<voidspace> dimitern: nearly done with the apiserver - don't think I'll get it finished today but nearly
<dimitern> voidspace, right, that's great
<dimitern> frobware, well, it worked like charm!
<voidspace> better in Python isn't it :-D
<dimitern> voidspace, indeed :)
<dimitern> frobware, uhm.. however it didn't create multiple bridges, just juju-br0
<frobware> dimitern, ping
<frobware> dimitern, can you pastebin your /e/n/i that didn't work
<dimitern> frobware, just a sec
<dimitern> frobware, http://paste.ubuntu.com/13863808/
<frobware> dimitern, so I was wondering about this a little earlier. the expectation is that eth0.100 becomes juju-br-eth0.100
<frobware> dimitern, much in the same way we do for eth0/juju-br0?
<dimitern> frobware, it did work and connectivity is there, but I kinda expected I guess, to see juju-br0 for eth0, juju-brXYZ for eth0.50, juju-brUXV for eth0.100 (names of the bridges do not matter)
<frobware> dimitern, so just a naming concern?
<frobware> dimitern, I was conscious of len(name)
<dimitern> frobware, yeah - the point is to be able to enslave an lxc NIC per bridge, such that if the host has IPs on eth0, eth0.50, and eth0.100, the container can mirror that with its eth0, eth1, and eth2 (as seen inside the container)
<dimitern> frobware, am I making sense ? :)
<frobware> nope
<frobware> :)
<dimitern> frobware, sorry, let me try again..
<frobware> dimitern, any way we can HO or not very practical?
<frobware> dimitern, alternatively annotate your pastebin with your expectations
<dimitern> frobware, we're in a session and it won't work very well I'm afraid
<dimitern> frobware, sure, let me do that
<frobware> dimitern, you also said: "I'm not sure though if we should add multiple bridges by default in master yet" - agreed, though the script in my branch is so much better than either on master of 1.25 that I would like to get some of it there soon-ish. Also, I'm not sure what the net affect is addressable containers, which is why I wanted to chat.
<dimitern> frobware, right, addressable containers in maas a less of a concern to me, as with the bridges we get addressability (for the primary nic now, with this script for all nics, which is even better)
<frobware> dimitern, do we foresee a case where ethN is not active (ie. it is manual) but the vlans associated with it are active (ie. "static/dhcp")? Because that won't bridge atm...
<frobware> dimitern, before catering for that case I wanted to know it that's in any way a reality as the parsing would have to hold more state to make this work.
<dimitern> frobware, any vlans have to be on an active, link up device
<dimitern> frobware, if the raw device is down, there won't be any possibility to pass vlan traffic on it
<dimitern> frobware, I'm preparing /e/n/i example, just a few minutes and I'll paste it
<frobware> dimitern, so from a re-rendering perspective if the raw device is not active we won't add a bridge. or should not.
<frobware> thx
<dimitern> frobware, we're making some experiments with dooferlad here to figure out what we can do with bridges and vlans
<dimitern> frobware, if it gets late, don't stay up :) we'll stay in touch by mail
<dimitern> frobware, the open question is can "juju-br0.50" be both a vlan virtual device AND a bridge we ca use for container nics
<dimitern> or it has to be e.g. juju-br0-50 as a bridge, which has vlan-raw-device and vlan_id on
<frobware> dimitern, the latter was mostly my question when I was doing this; I'll experiment a little after dinner too.
<cherylj> can I get a review?   http://reviews.vapour.ws/r/3346/
<mup> Bug #1524190 changed: Undocumented update-status hook <juju-core:Invalid> <https://launchpad.net/bugs/1524190>
<mup> Bug #1524190 opened: Undocumented update-status hook <juju-core:Invalid> <https://launchpad.net/bugs/1524190>
<mup> Bug #1524190 changed: Undocumented update-status hook <juju-core:Invalid> <https://launchpad.net/bugs/1524190>
<menn0> thumper: git merge-base upstream/<parent-branch> HEAD should give you the commit that's the common ancestor
<menn0> thumper: then git log <sha>.. or git log <sha>..
<menn0> diff
<perrito666> how can I find out what provider is one running? never thought of that
<mup> Bug #1494951 changed: Panic "unexpected message" in vivid and wily tests <bug-squad> <ci> <intermittent-failure> <panic> <unit-tests> <wily> <juju-core:Triaged by cherylj> <https://launchpad.net/bugs/1494951>
<mup> Bug #1524527 opened: deploy incompatible charm using --to should error earlier <juju-core:Triaged> <https://launchpad.net/bugs/1524527>
<jw4> wq
<perrito666> jw4: vi ftw
<jw4> heh
<jw4> don't tell katco
<perrito666> seems that we didn't thought much how to upgrade stuff in the provider side
<rick_h_> cccccceefhiubfgdelvcctfftfklkugnjciiefbtcvkl
<perrito666> rick_h_: yeah, I agree
#juju-dev 2015-12-10
<perrito666> https://github.com/juju/juju/pull/3937
<mup> Bug #1524572 opened: Azure provider: bootstrap results in error "PUT request failed: BadRequest - XML Schema validation error in network configuration at line 24,18." <azure-provider> <bootstrap> <juju-core:New> <https://launchpad.net/bugs/1524572>
<voidspace> frobware: ping
<voidspace> frobware: time escaped me
<voidspace> frobware: stdup?
<frobware> voidspace, heh, and me.
<frobware> sure
<voidspace> omw
<TheMue> for standup I'm currently introducing Skyrum here. Skyrum is "Sky"pe and Sc"rum". we've got a closed Skype group here and the people shall do their daily status in it. idea is to have it async and also that e'body tries to keep short. *lol*
<TheMue> hello btw
<voidspace> TheMue: o/
<voidspace> sounds interesting
<voidspace> TheMue: it works on Ubuntu?
<TheMue> yeah, real life meetings tend to directly drift into topics. I want to avoid it.
<TheMue> it's possible with any chat room, even here on irc, but in a smaller channel for example. I only have chosen Skype because it's there.
<mup> Bug #1524823 opened: Support AWS price API <juju-core:New> <https://launchpad.net/bugs/1524823>
<mattyw> voidspace, you're not in oakland either?
<voidspace> mattyw: nope
<voidspace> mattyw: you not?
<mattyw> voidspace, no, the weather here is too good to miss ;)
<voidspace> heh
<voidspace> mattyw: where is here, Scotland?
<perrito666> axw_: ping
<mgz> thumper thumper thumper http://reports.vapour.ws/releases/3419/job/run-unit-tests-race/attempt/701
<mgz> .. Panic: cannot create lease client: end of read window preceded beginning (1.365297ms) (PC=0x414EE6)
<thumper> mgz: is that the biggest one?
<mgz> ~1ms is the largest, most are micro seconds
<thumper> 1.44ms
<thumper> perhaps 2ms wiggle
<thumper> or 10ms even?
<mup> Bug #1516989 changed: juju status <service_name> broken <canonical-bootstack> <sts> <juju-core:Invalid by waigani> <juju-core 1.25:Fix Committed by waigani> <juju-core (Ubuntu):Confirmed> <https://launchpad.net/bugs/1516989>
<mup> Bug #1524906 opened: ToolsMetadataSuite fails with 2.0-alpha1 version <2.0-readiness> <juju-core:Triaged> <https://launchpad.net/bugs/1524906>
<mup> Bug #1524914 opened:  envManagerSuite.TestCreateEnvironmentBadAgentVersion fails with 2.0-alpha1 <2.0-readiness> <juju-core:Triaged> <https://launchpad.net/bugs/1524914>
<menn0> jam: see minor suggestion on the logging PR
<mup> Bug #1524915 opened: toolsSuite.TestFindToolsNotFound panics with 2.0-alpha1 <2.0-readiness> <juju-core:Triaged> <https://launchpad.net/bugs/1524915>
<menn0> fwereade: http://juju-ci.vapour.ws:8080/job/github-merge-juju/5699/console
<fwereade> menn0, opinion: https://github.com/juju/juju/wiki/howto:-implement-effective-config-structs ?
<fwereade> mgz, https://github.com/juju/juju/wiki/howto:-implement-effective-config-structs
<mup> Bug #1506649 changed: On juju upgrade the security group lost ports for the exposed services <networking> <upgrade-juju> <juju-core:Invalid> <juju-core 1.25:Fix Committed by thumper> <https://launchpad.net/bugs/1506649>
<mup> Bug #1524369 changed: i386 github.com/juju/juju/upgrades_test constant overflows int <blocker> <ci> <i386> <test-failure> <juju-core:Fix Released by wallyworld> <https://launchpad.net/bugs/1524369>
<mgz> wallyworld: bug 1403655
<mup> Bug #1403655: upgrade-juju shows available tools and best version but did not output what it decided to do <2.0> <docteam> <ui> <upgrade-juju> <juju-core:Triaged> <https://launchpad.net/bugs/1403655>
<dimitern> mgz, http://reviews.vapour.ws/r/3342/
<mup> Bug #1524958 opened: cloudinitSuite.TestCloudInit broken on windows by new key rules <ci> <regression> <test-failure> <windows> <juju-core:Triaged by wallyworld> <juju-core 1.25:New> <https://launchpad.net/bugs/1524958>
<mgz> alexisb: bug 1287665
<mup> Bug #1287665: Export bundle without juju GUI <canonical-is> <deployer> <sts> <juju-core:Triaged> <juju-deployer:New> <https://launchpad.net/bugs/1287665>
<alexisb> cherylj, can you put this on our feature list ^^ on the wiki
<cherylj> alexisb: sure
<perrito666> ericsnow: ping?
<ericsnow> perrito666: hey
<cherylj> alexisb: don
<perrito666> ericsnow: hey, I let you a privmsg a moment ago
<cherylj> +e
<ericsnow> perrito666: I'm in the next room, FYI
<perrito666> ericsnow: I am in the silent room :p Ill go there
<alexisb> cherylj, awesome thanks
#juju-dev 2015-12-11
<fwereade> thumper, https://vimeo.com/95066828
<thumper> fwereade: http://reviews.vapour.ws/r/3370/
<perrito666> everything is happy
<mup> Bug #1525030 opened: 'ERROR while removing instance' when destroying lxd environment <juju-core:Triaged> <https://launchpad.net/bugs/1525030>
<mup> Bug #1525030 changed: 'ERROR while removing instance' when destroying lxd environment <juju-core:Triaged> <https://launchpad.net/bugs/1525030>
<mup> Bug #1525030 opened: 'ERROR while removing instance' when destroying lxd environment <juju-core:Triaged> <https://launchpad.net/bugs/1525030>
<wallyworld> cherylj: pretty please :-) http://reviews.vapour.ws/r/3372/
<voidspace> frobware: seems to have worked and after adding the interface to maas I have a new subnet in a new fabric
<frobware> voidspace, great
<voidspace> I can now add a new space and can test my code
<voidspace> once it's written... ;-)
<rick_h_> voidspace: that sounds like 'woot!'
<voidspace> rick_h_: sorry, missed that. Yeah, a minor woot!
<frobware> dimitern, voidspace, dooferlad: playing around with macvlan I *think* I have a configuration where all the guests can see each other, and each guest can access external hosts, plus virt host. and host can see all the guests. Isn't that what we were previously looking for?
<voidspace> frobware: that sounds right
<frobware> voidspace, admittedly I have only been verifying with libvirt/kvm
<mup> Bug #1525280 opened: 1.25.1 with maas 1.8: devices dns allocation uses non-unique hostname <kanban-cross-team> <juju-core:New> <https://launchpad.net/bugs/1525280>
<voidspace> frobware: worth seeing if you can get it to work with lxc too, because if we can't...
<voidspace> shouldn't be different though
<voidspace> except in all the details
<frobware> voidspace, right. and that's why I mentioned it.
<mup> Bug #1525280 changed: 1.25.1 with maas 1.8: devices dns allocation uses non-unique hostname <kanban-cross-team> <juju-core:New> <https://launchpad.net/bugs/1525280>
<mup> Bug #1525280 opened: 1.25.1 with maas 1.8: devices dns allocation uses non-unique hostname <kanban-cross-team> <juju-core:New> <https://launchpad.net/bugs/1525280>
<arosales> for the controller in juju-core 2.0 what will be the required version of MongoDB
<perrito666> wallyworld: did you get my email?
<wallyworld> perrito666: am behind on emails, need to scan inbox
<perrito666> k, sent it during breakfast if you have questions just answer it, it is about the estimates
<perrito666> https://github.com/GoogleCloudPlatform/gcloud-java/issues/302 <- such is my luck
<rick_h_> arosales: 2.0 should be shipping with 3.2 mongodb
<dimitern> frobware, hey, are you still around by any chance?
<dimitern> frobware, I was just wondering if you have any feedback about the multi-bridge script and comments on the test I've sent you details from
<dimitern> frobware, no rush, I'll check when I'm back home
<arosales> rick_h_: ok thanks
<mup> Bug #1524385 changed: local precise cannot be upgraded <ci> <local-provider> <precise> <regression> <upgrade-juju> <juju-core:Invalid> <https://launchpad.net/bugs/1524385>
<mgz> ericsnow: hit nate over the head with this diff <http://paste.ubuntu.com/13947202/>
#juju-dev 2015-12-12
<mgz> natefinch: https://code.launchpad.net/~gz/juju-ci-tools/gate_feature_branch_rego/+merge/280377
<mgz> natefinch: http://juju-ci.vapour.ws/job/github-merge-juju-charm/24/console
<mup> Bug #1525529 opened: toolsSuite.SetUpTest invalid version on windows <ci> <regression> <test-failure> <windows> <juju-core:Triaged> <https://launchpad.net/bugs/1525529>
<mup> Bug #1525529 changed: toolsSuite.SetUpTest invalid version on windows <ci> <regression> <test-failure> <windows> <juju-core:Triaged> <https://launchpad.net/bugs/1525529>
<mup> Bug #1525529 opened: toolsSuite.SetUpTest invalid version on windows <ci> <regression> <test-failure> <windows> <juju-core:Triaged> <https://launchpad.net/bugs/1525529>
<mup> Bug #1525531 opened: Manual precise upgrades fail in 1.25.2 <ci> <manual-provider> <precise> <regression> <upgrade-juju> <juju-core:Incomplete> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1525531>
<mup> Bug #1525531 changed: Manual precise upgrades fail in 1.25.2 <ci> <manual-provider> <precise> <regression> <upgrade-juju> <juju-core:Incomplete> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1525531>
<mup> Bug #1525531 opened: Manual precise upgrades fail in 1.25.2 <ci> <manual-provider> <precise> <regression> <upgrade-juju> <juju-core:Incomplete> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1525531>
<mup> Bug #1525531 changed: Manual precise upgrades fail in 1.25.2 <ci> <manual-provider> <precise> <regression> <upgrade-juju> <juju-core:Incomplete> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1525531>
<mup> Bug #1525531 opened: Manual precise upgrades fail in 1.25.2 <ci> <manual-provider> <precise> <regression> <upgrade-juju> <juju-core:Incomplete> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1525531>
#juju-dev 2016-12-12
<menn0> anastasiamac: gah. just found in nasty bug with resources (not migrations but resources themselves).
<menn0> anastasiamac: should be easy enough to fix
<veebers> menn0: (eavesdropping) what's the bug? Might be a candidate for EDA
<menn0> veebers: EDA?
<menn0> veebers: the problem is with "placeholder" resources. A placeholder resource is where a charm has defined a resource but no unit has retrieved it yet.
<veebers> menn0: escaped defect analysis that qa does i.e. why did this bug git hit outside our testing
<veebers> git/get
<menn0> veebers: when the application is removed a cleanup operation is scheduled for the placeholder resource to remove it from gridfs
<menn0> veebers: but there's nothing to remove, so the cleanup fails
<menn0> veebers: it's only visible from the logs (and also prevents a migration from starting, which is how I noticed)
<veebers> menn0: ah I see, nice catch :-)
<menn0> veebers: there's no unit test coverage for this (which I will fix)
<menn0> veebers: not sure if it makes sense to cover in functional tests - it's a corner case
<veebers> menn0: ack, cheers
<blahdeblah> axw: Around, or still on a sprint?
<blahdeblah> Or anyone else around familiar enough with https://bugs.launchpad.net/juju-core/+bug/1645729 to help me work out a problem with testing it?
<mup> Bug #1645729: environment unstable after 1.25.8 upgrade <juju:Fix Committed by axwalk> <juju 2.1:Fix Committed by axwalk> <juju-core:Fix Committed by axwalk> <juju-core 1.25:Fix Released by axwalk> <https://launchpad.net/bugs/1645729>
<blahdeblah> Well, I'll throw my questions here and hope someone sees them:
<blahdeblah> I've added the proposed ppa and upgraded my local package such that "juju version" reports 1.25.9. I've also added agent-stream: proposed to environments.yaml for the environments I want to upgrade.
<blahdeblah> But when I try an upgrade-juju --dry-run, it tells me no upgrades are available.
<blahdeblah> Tried once with --upload-tools and it didn't work, but looks like it might be working now. o.O
<anastasiamac> menn0: this is brilliant \o/ thank you for finiding it and for fixing it \o/
 * anastasiamac wonders if nay part of HA would require migration.. menn0could fix it as drive-by
<anastasiamac> any*
<anastasiamac> blahdeblah: axw is on holiday until mid-Jan. how is ur upgrade?
<blahdeblah> anastasiamac: I'm not sure
<blahdeblah> Still waiting for sync-tools to finish
<blahdeblah> yay ADSL 1Mbps upload
<anastasiamac> blahdeblah: *\o/*
<anastasiamac> blahdeblah: i need to go afk - **sigh** kids... - but will check backscroll later.. alternatively, feel free to email ;D
<blahdeblah> anastasiamac: Is there anything that explains the process of upgrading a stable environment to proposed other than the paragraph on the PPA?
<anastasiamac> blahdeblah: as far as I kow, u need to upgrade you tools stream value to 'proposed' and that's it
<blahdeblah> I don't suppose there's a way to get the bootstrap node to pull the tools directly from streams?
<blahdeblah> Or should that be the default
<blahdeblah> ?
<anastasiamac> blahdeblah: i think setting agent-metadata-url could do it...
 * blahdeblah gives up on letting sync-tools trash his ADSL link
<blahdeblah> setting it to what?
<anastasiamac> blahdeblah: i need to go but for Juju 1.x, you could ...
<anastasiamac> juju set-env agent-metadata-url=https://streams.canonical.com/juju/tools
<anastasiamac> juju upgrade-juju --version 1.25.6
<anastasiamac> blahdeblah: u might b able to do equivalent for Juju 2.x
<blahdeblah> This is 1.25.8
<anastasiamac> blahdeblah: sorry, I'll b back in cuple of hrs ... promise :)
<blahdeblah> no worries - thanks anastasiamac
<anastasiamac> blahdeblah: yes, so it should work as long as --version set to ur next desired..
<anastasiamac> blahdeblah: u'd still need agent-stream value to b set to proposed tho
<blahdeblah> yep
<blahdeblah> anastasiamac: Thanks for the help; I seemed to need juju sync-tools before things would work.
<blahdeblah> I'll update the bug shortly
<voidspace> frobware: ping
<frobware> voidspace: pong
<voidspace> frobware: morning :-)
<voidspace> frobware: I'm having a chat with Ante about his network issues at noon
<frobware> voidspace: ok, can join.
<voidspace> frobware: I added you to the meeting if you'll be available
<frankban> hey, I need a review for the quick fix at https://github.com/juju/juju/pull/6694, anyone available?
<voidspace> frobware: cool, thanks
<voidspace> frankban: not possible to test it I guess
<frankban> voidspace: just bootstrap a controller, and run "juju gui"
<voidspace> frankban: I mean an automated test
<voidspace> frankban: but that sounds like a good thing to do too
<frankban> voidspace: unit tests are already there, and they keep passing
<anastasiamac> blahdeblah: ack
<voidspace> frankban: so if we're specifying the target directory there's no difference (except signature of function) between ioutil.TempDir and os.MkDir
<voidspace> frankban: I know it's a trivial change, just want to ensure I *actually* understand it
<voidspace> frankban: "juju gui" didn't fail with lxd, trying it with maas to watch it fail
<frankban> voidspace: the difference is that os.MkDir receives the dir name, while TempDir creates a temporary dir (therefore with an available random name) in the given directory, with the given prefix
<voidspace> frankban: ah yes, it's still a random name in the specified directory
<voidspace> frankban: thanks
<voidspace> frankban: I'm pretty sure your one line change is fine, I'm just trying it out
<voidspace> frankban: :-)
<frankban> voidspace: cool, and thanks!
<voidspace> frankban: so I can't repro the original problem without multiple storage devices on my maas nodes
<voidspace> frankban: but the new branch at least works fine, so LGTM
<frankban> voidspace: ty!
<mattyw> hey folks, is it possible to force juju to change the leader, so I can test leadership election in charms?
<voidspace> frobware: ping for networking
<frobware> voidspace: omw
<kjackal> Hey rick_h got a question you might be able to help me with or route me to the right person. When I "juju register" a controller the password field inside the ~/.local/share/juju/accounts.yaml is not set. The python jujuclient we have is failing to parse the environment.
<kjackal> rick_h: Is this a problem with the "juju register" command or with the jujuclient lib?
<rick_h> kjackal: thinking
<kjackal> rick_h: http://pastebin.ubuntu.com/23619350/
<kjackal> rick_h: Here is cwr failing because of this problem
<voidspace> frobware: ping
<rick_h> kjackal: so, what client is doing the register?
<rick_h> kjackal: so when you normally cli register you get a chance to set a password
<rick_h> kjackal: but if not set, there's a cookie I think that gets set
<rick_h> kjackal: so it could be client issue in registering, reading the cookie, etc
<rick_h> kjackal: but hard to say from the pastebin as that's after the fact so not sure what got up to there
<kjackal> rick_h: you "juju register" the controller and you provide a password. After that the controller is operational. Bundle tester works fine with it. No problem there.
<kjackal> rick_h: The registration process does not add the password field in the accounts.yaml so the jujuclient library is failing
<rick_h> kjackal: right so what's bundle tester using that jujuclient isn't then. I'm guessing it's not able to read the cookie data?
<kjackal> rick_h: from your answer I gather that the password field in accounts.yaml is optional
<rick_h> kjackal: yea, though I'm trying to think about that.
<rick_h> kjackal: I mean the only real 'permanent' password is the credentials.yaml
<rick_h> kjackal: that's persistent, so I'm curious if there's something that we should be doing in credentials.yaml that's correct or not
<rick_h> kjackal: that one I need to chat with some other folks on and see why we don't. I guess because that's for a cloud and not a controller that's already running...
<kjackal> rick_h: is password is optional then this line here seems wrong: http://bazaar.launchpad.net/~juju-deployers/python-jujuclient/trunk/view/head:/jujuclient/juju2/connector.py#L64
<kjackal> *if
<rick_h> kjackal: yea, I just can't think of a great reason not to fill it in if the user has entered it. Maybe worth an email to juju-dev email list.
<rick_h> kjackal: can you do full repro steps and bring it up and I'll chime in and see if we can get some feedback from the folks that did it if there was some reason I'm blanking on atm?
<kjackal> ok, will do that. thanks rick_h
<frobware> voidspace: pong
<voidspace> frobware: tycho's patch uses the constraints off the instanceConfig
<voidspace> frobware: however the CreateContainer method it is in takes a parameter called cons, which is a constraints.Value
<frobware> voidspace: the patch is quite old. :/
<voidspace> frobware: obviously kvm needs to specify these constraints differently from within the CreateContainer call
<voidspace> frobware: ah, ok - so it may just be out of date
<voidspace> frobware: I'm trying to see how it's used
<frobware> voidspace: pretty sure this was done at the austin sprint, so march/april this year.
<voidspace> frobware: that's no *soooo* olld
<voidspace> *old even
<frobware> voidspace: 2016 still. :)
<voidspace> frobware: right
<voidspace> frobware: so StartInstanceParams dows have Constraints, which is also a constraints.Value
<voidspace> I wonder if it's just the same stuff duplicated or different
<voidspace> time for some instrumentation I think
<mup> Bug #1649379 opened: bootstrap failed sigabrt when installing services <bootstrap> <intermittent-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1649379>
<alexisb> ping anastasiamac
<cmars> hey, does the GCE provider support exposing port ranges?
<cmars> i may have found a bug..
<mup> Bug #1510689 changed: juju upgrade --upload-tools tries to upload tools agents that are not permitted by the state server <bug-squad> <simplestreams> <upgrade-juju> <upload-tools> <juju:Triaged> <juju-core:Won't Fix> <https://launchpad.net/bugs/1510689>
<mup> Bug #1510689 opened: juju upgrade --upload-tools tries to upload tools agents that are not permitted by the state server <bug-squad> <simplestreams> <upgrade-juju> <upload-tools> <juju:Triaged> <juju-core:Won't Fix> <https://launchpad.net/bugs/1510689>
<mup> Bug #1510689 changed: juju upgrade --upload-tools tries to upload tools agents that are not permitted by the state server <bug-squad> <simplestreams> <upgrade-juju> <upload-tools> <juju:Triaged> <juju-core:Won't Fix> <https://launchpad.net/bugs/1510689>
<mup> Bug #1649379 changed: bootstrap failed sigabrt when installing services <bootstrap> <intermittent-failure> <juju-core:Won't Fix> <https://launchpad.net/bugs/1649379>
#juju-dev 2016-12-13
<blahdeblah> anastasiamac: just dropped some preliminary results from 1.25.9-proposed testing into lp:1645729
<blahdeblah> Anyone looking after that bug in axw's absence?
<hoenir> can someone review this PR? https://github.com/juju/juju/pull/6523
<anastasiamac> hoenir: looking
<anastasiamac> hoenir: natefinch should b online soon and he is today's reviewer and has windows expertise. I'll pass this on :) thank you!
<hoenir> anastasiamac, thanks!
<hoenir> anastasiamac, could you please post the review calendar ?
<anastasiamac> hoenir: i think it's internal to juju team calendar
<anastasiamac> hoenir: but if u ask here, we can tell u who is on a particular day :)
<anastasiamac> hoenir: with holidays just around the corner, some ppl r on and off so the schedule is not easily read
<voidspace> frobware: ping
<redir> web sokets.
<redir> ignore ^^
<voidspace> jam: so lxc is showing that only default and docker profiles exist on the machine, and despite specifying a memory constraint the default profile has been used
<voidspace> jam: and the memory amount is *incorrect* (constraint not honoured) - this is with a modified version of tych0's patch
<voidspace> jam: so it looks like this isn't enough and there's more work to do...
<jam> voidspace: there can also be instance specific configuration, let me track it down
<jam> voidspace: lxc config is where you can set it directly for each instance
<voidspace> jam: I'll look
<jam> lxc config show $INSTANCE_ID
<voidspace> jam thanks
<jam> profiles are just a way of aggregating a bunch of default config (AIUI)
<jam> but ultimately it is the config of the instance itself that controlls it.
<voidspace> jam: so we wouldn't/shouldn't create a new profile per config permutation but should do it via config
<jam> voidspace: correct.
<jam> that's also what we're planning on (already do?) for per container network devices.
<voidspace> jam: so I see this: in the config for the instance:   user.limits.memory: 0xc8206f7080MB
<jam> voidspace: right, so you're running into our other bug
<voidspace> jam: which looks suspicious
<jam> I don't have the number offhand
<jam> voidspace: but we have an open bug that all of our config gets prefixed with "user."
<jam> voidspace: we have some other ones that end up showing up as "user.user.stuff"
<jam> I think the machine-ids/model/controller-uuids
<voidspace> jam: so all our config is broken anyway... ?
<voidspace> ouch
<voidspace> but this doesn't look like a sensible value anyway 0xc8206f7080MB
<voidspace> jam: I requested 888M
<jam> voidspace: *that* looks like it is serializing a memory pointer
<voidspace> I will see what a default config looks like
<voidspace> yep
<jam> so we probably have "Memory"
<jam> where it should be
<jam> "Memory()"
<voidspace> hah
<voidspace> jam: this gives me some tools to check though, thanks
<jam> voidspace: and it sounds like all our config is, indeed, broken, and we need to fix it and have some care for keys that we are going to look up later
<jam> we may need to force some to be "user.user."
<jam> voidspace: https://bugs.launchpad.net/ubuntu/+source/juju/+bug/1640079/comments/6 mentions the bug
<mup> Bug #1640079: LXDs doesn't start after a reboot <lxd-provider> <openstack> <uosci> <juju:Triaged by rharding> <juju (Ubuntu):Triaged> <https://launchpad.net/bugs/1640079>
<jam> but I don't have a root bug
<voidspace> jam: ok, thanks - so there maybe three bugs to fix
<jam> voidspace: well, that might be the bug, given it seems we set "user.boot.autostart"
<voidspace> jam: use the correct config keys, use the right values (not pointers), *then* we can use constraints
<voidspace> but fixing constraints won't actually work until the other two  are fixed
<voidspace> at least with lxd
<jam> voidspace: presumably
<voidspace> nice :-)
<voidspace> jam: the pointer issue is my fault - constraints.Value is defined with pointers
<voidspace> jam: trying again, I think the "user" prefix on the key will *still* mean it doesn't work
<jam> voidspace: agreed
<jam> we have to fix that other bug first
<voidspace> jam: the specific problem that ante has is with kvm containers - as reported in the specific bug I'm on
<voidspace> jam: I only started looking at lxd first as we had this patch from tycho and thought it would be easier
<voidspace> jam: I'm switching to looking at kvm instead, I'll email rick_h to keep him up to date
<voidspace> jam: when kvm is done I can look at fixing the lxd issue too which will mean fixing the user key bug too
<jam> voidspace: fwiw, I'm pretty sure we care far more about LXD than KVM
<voidspace> jam: hmmm, ante doesn't I don't think as he's doing kvm placement on physical hardware
<voidspace> jam: so I will ask rick_h then which is higher priority :-)
<rick_h> voidspace: the reason that lxd wasn't in the original bug is because lxd has not handled constraints on the container.
<voidspace> rick_h: so from discussion above with jam, we have another bug with lxd that means our config options are being specified incorrectly
<rick_h> voidspace: jam so I think it's worth validating with Ante, but I do believe the ideal state is lxd respecting constraints with both kvm/lxd respecting them with the placement directive.
<rick_h> voidspace: I see
<voidspace> rick_h: see https://bugs.launchpad.net/ubuntu/+source/juju/+bug/1640079/comments/6
<mup> Bug #1640079: LXDs doesn't start after a reboot <lxd-provider> <openstack> <uosci> <juju:Triaged by rharding> <juju (Ubuntu):Triaged> <https://launchpad.net/bugs/1640079>
<voidspace> rick_h: so for lxd constraints to work at all, that needs fixing too
<rick_h> voidspace: right, that one is the one macgreagoir is looking at
<voidspace> rick_h: ah...
<jam> rick_h: that bug is also that we are setting "user.user.stuff"
<voidspace> jam: rick_h: so what gets set in the lxd config is "user.limits.memory: 888MB" instead of "limits.memory" and thusly lxd ignores it
<rick_h> voidspace: ok, so please go ahead and chase the kvm side if you're unlocked to do that now with nested kvms
<rick_h> voidspace: and then macgreagoir and yourself can peek and test the fix for the lxd config issues
<voidspace> rick_h: ok, yep
<frobware> voidspace: pong; though looking through the scrollback it looks you have answers & further questions...
<voidspace> frobware: I do, but I think I'm switching to kvm anyway for the moment
<voidspace> frobware: rick_h: for creating a root disk of a specific size for lxd we need to create a new lxd *device* (rather than overriding settings in the metadata)
<rick_h> voidspace: let's leave the disk along for now please
<voidspace> frobware: rick_h: currently the only devices we create are nics, so it would need to be new code to create a block device
<rick_h> voidspace: just focus on the memory/cpu/easy ones
<voidspace> rick_h: yep, that's just how we would do it
<rick_h> ah ok coolio
<voidspace> rick_h: not hard code, just new code
<rick_h> voidspace: rgr
<voidspace> rick_h: it's not a config setting via metadata - it's a setting on a block device, which we don't do yet because we just use the default block device
<rick_h> voidspace: makes sense.
<voidspace> rick_h: with current 2.1 branch, if I do juju add-machine kvm:0 -constraints="mem=888M" then I see the memory constraint honoured
<voidspace> rick_h: is "kvm:0" a placement directive or is that not enough to trigger the bug?
<rick_h> voidspace: can you check that if that's done in a bundle?
<voidspace> rick_h: I can try and do it with a bundle
<voidspace> ack
<rick_h> voidspace: maybe we're barking up the wrong tree in that he was doing it from a bundle in that bug if I recall? /me checks the bug again
<voidspace> rick_h: the bug was specifically from a bundle, yes
<voidspace> rick_h: I will try that
<rick_h> voidspace: k, ty
<voidspace> rick_h: I'm still hopeful it's already been fixed by someone else by accident ;-)
<rick_h> voidspace: I give you hope...but reserver the right to take it away :P
<voidspace> rick_h: hah :-)
<voidspace> sounds about right...
<voidspace> macgreagoir: setting the node cpu type to "host-passthrough" in virt-manager is enough to enable nested kvm
<voidspace> macgreagoir: that or "copy host cpu configuration" works, but either option has (or had) known issues
<voidspace> macgreagoir: and allegedly "host-passthrough" is the least buggy way - according to the fedora and virt-manager folks anyway
<voidspace> macgreagoir: but it works...
<macgreagoir> voidspace: Cool.
<macgreagoir> voidspace: I'll make a note to test that in my env too, cheers.
<mup> Bug #1649637 opened: Juju agent in a "failed" state after machine reboot on some charms <juju-core:New> <https://launchpad.net/bugs/1649637>
<voidspace> rick_h: ping
<rick_h> voidspace: pong, otp if I'm slow to react
<voidspace> rick_h: kk
<voidspace> rick_h: who is a good person to talk to about bundle format?
<voidspace> rick_h: I might just email ivoks and ask  to see their actual bundle...
<rick_h> voidspace: might as well and see, but the format is https://github.com/juju/charm/blob/v5/bundledata.go
<voidspace> rick_h: thanks
<voidspace> rick_h: I cannot successfuly set the constraint on the kvm machine -as far as I can tell that isn't permitted by bundles
<voidspace> rick_h: however if I set the constraint at the service level and use constraints it *does* appear to be ignored
<voidspace> rick_h: so I am pursuing that as the bug and emailing ante about the specific way they are doing it
<voidspace> rick_h: yup, the *only* valid names are numbers, so I do not *believe* they are specifying the constraint at the machine level
<rick_h> voidspace: correct
<rick_h> voidspace: I mean normally you'd say juju deploy $aplication --constraints...
<voidspace> rick_h: but I can reproduce a service level constraint being ignored by a placement directive in a bundle
<voidspace> rick_h: where the service has a constraint and is placed into a KVM container that constraint is ignored in the container creation
<voidspace> rick_h: I do not know if that is the bug they mean, the snippet example in the bug seems fictitious
<voidspace> rick_h: I have emailed anyway
<menn0> thumper, babbageclunk: morning
<menn0> thumper, babbageclunk: review please: https://github.com/juju/juju/pull/6695
<thumper> menn0: morning
<babbageclunk> morning menn0!
<thumper> I looked
<babbageclunk> also morning thumper!
<thumper> and I'd like an answer to anastasiamac
<babbageclunk> I did not looked.
<thumper> apart from that , looked fine
<menn0> thumper: already answered
 * thumper looks again
<thumper> menn0: but where is that close?
<menn0> thumper: I believe you implemented it!
 * menn0 looks
<thumper> must be good then
<menn0> thumper: in migration/precheck.go, the defer at the bottom of SourcePrecheck
<thumper> ok, got it
<thumper> approved
<menn0> thumper: cheers
<anastasiamac> menn0: thumper: thnx \o/
<veebers> thumper: would you have any idea why juju (or may it's just lxd) would create lxd containers with ~1GB disk space?
<thumper> nope
<veebers> only happening on one host, the others seem fine
<thumper> some lxd local config?
<veebers> hmm, any pointers on who to poke thumper ?
<thumper> stgraber
<veebers> none of the profiles suggest anything. I'll dig deeper though
<veebers> ah yeah very good point, I'll ping him. CHeers
<anastasiamac> thumper: menn0: babbageclunk: any takers to review https://github.com/go-goose/goose/pull/36?
<menn0> anastasiamac: i've had a look and have a question
<anastasiamac> menn0: thnx
<anastasiamac> babbageclunk: could u plz also land this for 2.2 (develop) https://github.com/juju/juju/pull/6678
<thumper> menn0: oh ffs, I found my bug
<thumper> menn0: not the line number problem, but the other bit
<thumper> was a copy paste error from a previous test
<thumper> where I was calling workertest.CleanKill(c, w)
<thumper> I now need to defer that :)
<thumper> yes, the worker was dead, so had unsubscribed, so... unsurprisingly, didn't do anything
<mup> Bug #1649637 changed: Juju agent in a "failed" state after machine reboot on some charms <juju:Triaged> <https://launchpad.net/bugs/1649637>
<babbageclunk> anastasiamac: oops, yup, recreating that PR for develop
<anastasiamac> babbageclunk: \o/
<alexisb> anastasiamac, ping
<alexisb> thumper, ping
<thumper> hey
<alexisb> heya in ian's abscense can you jump on the release call
<thumper> sure
<alexisb> abentley has a q I need a tech lead for
<babbageclunk> anastasiamac: review plz? (forward ported migration fix) https://github.com/juju/juju/pull/6700
<anastasiamac> babbageclunk: u do not need review for simple forward port. u can self-stamp :D
<babbageclunk> anastasiamac: ok cool, thanks
<anastasiamac> babbageclunk: \o/
<alexisb> thumper, babbageclunk thoughts on this: https://bugs.launchpad.net/juju/+bug/1649719
<mup> Bug #1649719: 2.1-beta2: memory leak  <oil> <oil-2.0> <juju:New> <https://launchpad.net/bugs/1649719>
<thumper> alexisb: hmm...
<thumper> did the beta-2 have the fix from axw?
<alexisb> that is a good point
<alexisb> the one he fwd ported from 1.25 correct?
 * alexisb looks
<anastasiamac> alexisb: thumper: looks like it has been committed https://github.com/juju/juju/commit/cd41f256af304b883be5176e8562ff7b002e4ace
<anastasiamac> alexisb: thumper: dunno if it made beta cut tho...
<alexisb> ok that fix is not in beta2
<alexisb> so will start with that
<thumper> alexisb: I commented on the bug
<alexisb> heh, glad you told me
<alexisb> was doing that myself, /me refreshes
<alexisb> anastasiamac, fyi, the request thumper made in https://launchpad.net/bugs/1649719
<mup> Bug #1649719: 2.1-beta2: memory leak  <oil> <oil-2.0> <juju:New> <https://launchpad.net/bugs/1649719>
<alexisb> is what we need to send paul
<menn0> thumper: great that you found the bug
<menn0> the line number thing is still weird though
<thumper> yeah
<anastasiamac> blahdeblah: ^^
<blahdeblah> Oh, that was me Paul, not him Paul?
#juju-dev 2016-12-14
<wallyworld> babbageclunk: i have to head out for a bit soon to take kid to doctor in case you need me
<babbageclunk> wallyworld: no, I'm good for now
<menn0> babbageclunk: bug 1641824 is fixed right?
<mup> Bug #1641824: Migrating a model back to controller fails: model XXXX has been removed <model-migration> <juju:In Progress by 2-xtian> <https://launchpad.net/bugs/1641824>
<babbageclunk> menn0: hmm - all but the last case.
<babbageclunk> menn0: I need to chase down the stuff that calls the NewHandlerArgs.Connect function and ensure that it calls release on the state at some point. I tried a while back but got lost in all the component stuff.
<menn0> babbageclunk: ah right. that rings a bell.
<menn0> babbageclunk: critical for 2.1?
<babbageclunk> menn0: oh hey, you fixed that bit to use my stateForRequestAuthenticatedTag func - that should make it easier.
<menn0> babbageclunk: hooray :)
<menn0> babbageclunk: that rings a bell too :)
<babbageclunk> menn0: I guess so - state leak on any model that uses resources.
<babbageclunk> menn0: sorry - I mean, I guess it's critical in that case.
<menn0> babbageclunk: if you can find to take a look before the release goes out that would be awesome.
<anastasiamac> babbageclunk: menn0: this week only beta release is going out (beta3), first week of Jan - rc1 (tentative), 2nd week final (tentative too)... just an fyi \o/
<babbageclunk> menn0, anastasiamac: I'll take another look now.
<menn0> anastasiamac: ok thanks
<babbageclunk> menn0: Ok, I think I see how to do it now.
<anastasiamac> menn0: thumper: Ci is still seeing this issue https://bugs.launchpad.net/juju/+bug/1620438
<mup> Bug #1620438: model-migration pre-checks failed to catch issue: not idle <ci> <intermittent-failure> <regression> <juju:Fix Committed by thumper> <https://launchpad.net/bugs/1620438>
<anastasiamac> the latest failure was on Dec 13.... on 2.1
<anastasiamac> menn0: thumper: is there a backport that needed to happen?
<menn0> anastasiamac: not sure when the fix was made. thumper ?
<anastasiamac> menn0: last PR on the bug was merged 14 days ago...
<anastasiamac> menn0: and since it went into develop... I am guessing the issue is not fixed :(
<menn0> anastasiamac: or the test is trying to start a migration before the model has actually finished deploying
<anastasiamac> menn0: http://reports.vapour.ws/releases/issue/57ce2d2b749a563a65a52631
<menn0> anastasiamac: let's reopen it for now
<anastasiamac> menn0: or that :)
<menn0> so we don't forget
<anastasiamac> menn0: doen
<anastasiamac> done even
<menn0> anastasiamac: that last resource migration PR landed btw
<anastasiamac> menn0: \o/ (I saw)
<anastasiamac> menn0: well done
<babbageclunk> menn0: What's a charm I can deploy that uses resources?
<menn0> babbageclunk: cs:~cmars/mattermost
<menn0> babbageclunk: that actively uses them
<menn0> babbageclunk: etcd uses a resource too but it's only tied to a specific action
<menn0> babbageclunk: just a placeholder resource after deploy
<menn0> depends what you want to test
<babbageclunk> menn0: wow, the resources stuff doesn't have good test coverage, huh? I just changed the signature of several bits and still have a know nil pointer exception in my code but I can't make any of the tests fail.
<babbageclunk> *known
<menn0> babbageclunk: yep :(   I've found a bunch of places where there's no tests at all
<menn0> babbageclunk: fixing one of those now while fixing a bug
<anastasiamac> menn0: should bug 1649738 be targeted to 2.1.1? or later like 2.2?
<mup> Bug #1649738: migrations should support renaming of models <model-migration> <juju:New> <https://launchpad.net/bugs/1649738>
<anastasiamac> menn0: my understanding that 2.1.1 should b mainly bug fixes for 2.1.x rather than new functionality..
<menn0> anastasiamac: 2.2 is more realistic given that it's potentially a big piece of work but alexis suggested 2.1.1
<menn0> anastasiamac: depending on where model names are still used to tag things, it might be quite small/easy or big/horrible
<anastasiamac> menn0: k. this means alexisb has a plan \o/ will go with her suggestion :D
<anastasiamac> menn0: well, we are all about extremes nowdays - nothing in the middle ;)
<alexisb> babbageclunk, validation complete :)
<alexisb> thank you
<babbageclunk> alexisb: yay!
<menn0> thumper, anastasiamac or babbageclunk: https://github.com/juju/juju/pull/6702
 * anastasiamac looking
<menn0> thumper: so what do we want the policy to be wrt downgrades with migrations?
<menn0> thumper: 1.2.4 to 1.2.3 is ok?
<anastasiamac> menn0: lgtm
<menn0> thumper: that is, only check major.minor?
<menn0> anastasiamac: tyvm
<anastasiamac> menn0: anytime (...almost) \o/
<babbageclunk> menn0: to make mattermost use resources, do I need to deploy it with an overriding resource, or is just deploying it enough?
<menn0> babbageclunk: with mattermost, deploying it is enough
<babbageclunk> :(
<babbageclunk> I can't get it to hit my problem code.
<menn0> babbageclunk: the mattermost binary distribution is a resource, used during the install hook
<wallyworld> menn0: thumper: is there a meeting today?
 * thumper votes no
<wallyworld> sgtm
<menn0> wallyworld: I'd forgotten about it. I vote no as well.
<thumper> menn0: re downgrade, I'd suggest patch only
<thumper> so 2.0.3 -> 2.0.2
<thumper> 2.1.0 -> 2.0.2 seems more dodgy
<menn0> thumper: cool, that's what I've done.
<thumper> menn0: we don't have a way to negotiate a version to talk to
<menn0> thumper: basically, patch, build and tag are ignored
<thumper> what if 2.0.3 modifies the descritpion format and 2.0.2 doesn't understand
<menn0> thumper: 2.0.3 shouldn't do that
<menn0> thumper: it's for bug fixes only
<thumper> we should ensure that is the case then
<menn0> thumper: the description format should arguably only be allowed to change if the minor version increases
<thumper> something to add to a checklist
 * thumper is testing HA pubsub branch
<menn0> thumper: or we can allow downgrades only if the build or tag is different?
<jam> menn0: did you still want to meet in an hour?
<thumper> I like your first idea better
<thumper> ensure that the descirption format doesn't change in bug fix releases
<menn0> jam: i'm happy to skip. lots of little bits of tidy up for the 2.1 release.
<jam> menn0: sgtm, hope you have a good day.
<jam> btw, I agree with the "major.minor" stuff
<anastasiamac> menn0: resources fix landed on 2.1... if ther is a chance plz forwardport to 2.2 (develop)
<menn0> jam: and we only just had the sprint
<jam> though we have *not* been good about keeping real differences out of the micro releases
<menn0> anastasiamac: not forgotten. I have a list of branches to forward port and that's on it.
<anastasiamac> jam: mayb it should b our NY resolution :D
<anastasiamac> menn0: \o/
<menn0> jam, thumper: i'm not sure how we robustly enforce it...
<thumper> I'm not sure we can effectively...
<thumper> could just be convention
<thumper> and beatings
<anastasiamac> a cycle on a team that supports users?
<menn0> anastasiamac: that's just crazy talk...
<menn0> so a checklist then ... where to keep it?
<anastasiamac> menn0: part of review checklist? along with the item of 'did u consider upgradability?'
<menn0> anastasiamac: but it's more of a thing to check at review time
<menn0> anastasiamac: when commiting a PR you don't always know which version of Juju your change is going to land in
<menn0> thumper, jam: there's a problem with relaxing the migration version check: post-migration you end up with a model with agents that are running tools ahead of the controller
<anastasiamac> menn0: hmmm if only we had some set of rules that could check codebase...
<thumper> menn0: no...
<thumper> menn0: we shouldn't support that
<thumper> consider this
<thumper> migrating from 2.0.2 -> 2.0.3 controller
<thumper> the model doesn't change
<thumper> it is still 2.0.2
<thumper> you can migrate it back then
<thumper> but if you upgrade the model
<thumper> nada
<thumper> sorry
<thumper> no move back for you
<menn0> thumper: well that's already supported as it is now, without my PR
<thumper> that is what we need to support...
<thumper> I don't think we should support other than that
<menn0> thumper: ok... well that works right now
<menn0> thumper: what's missing is that we don't check controller versions, only the model version to the target controller version
<menn0> thumper: there's a gap there where the model might be compatible with the target controller but the source controller is ahead of the target controller, meaning that migration API support might be missing
<menn0> thumper: fixing that now
<thumper> ok...
<thumper> but ...
<thumper> hmm...
<thumper> so testing that target controller version >= source controller version, or just patch levels behind, yes?
<thumper> menn0: ^^ that
<menn0> thumper: quick HO?
<thumper> sure
<babbageclunk> menn0, thumper: could one of you take a look at https://github.com/juju/juju/pull/6703
<babbageclunk> It fixes the resource state leak.
<babbageclunk> I'mm'a go for a run
 * babbageclunk goes for a run
<babbageclunk> gah, no I'm not - still doesn't work
<wallyworld> babbageclunk: i'll have a PR ready for review a bit later, after your EOD. if you could look when you start tomorrow that would be greate
<babbageclunk> wallyworld: wilco
<wallyworld> babbageclunk: it's to change how register remote relation works so we can remove a hack needed to lookup the remote app id on the consuming side
<anastasiamac> wallyworld: have u seen this one? remoteRelationsSuite.TestRemoteRelationsDead got nil instead of changes: https://bugs.launchpad.net/juju/+bug/1646861
<mup> Bug #1646861: remoteRelationsSuite.TestRemoteRelationsDead got nil instead of changes <ci> <intermittent-failure> <regression> <unit-tests> <juju:Triaged> <https://launchpad.net/bugs/1646861>
<wallyworld> that got fixed last week IIANM
<anastasiamac> wallyworld: do u have a PR? and do u know what branch it landed on?
<wallyworld> develop
<anastasiamac> before we branched?
<wallyworld> https://github.com/juju/juju/pull/6685
<wallyworld> no idea
<wallyworld> maybe after
<anastasiamac> according to http://reports.vapour.ws/releases/issue/58418a80749a5656beeae59f, it was seen on Dec 12 on 2.1
<wallyworld> must have been after then
<wallyworld> backport time
<anastasiamac> could u plz backport to 2.1? u may need to consider if it needs to b on 2.0 too
<anastasiamac> \o/
<voidspace> jam: ping
<jam> voidspace: ?
<voidspace> jam: hey, you said you thought you'd seen code explicitly discarding constraints  when there is placement
<voidspace> jam: above the container creation level
<voidspace> jam: and indeed the bundledata spec explicitly states this to be the case (but we'd like to change it)
<voidspace> jam: I wondered if you recalled whereabouts you'd seen this code?
<jam> voidspace: checking
<voidspace> jam: I don't *think* the charm package itself discards this information
<jam> voidspace: I don't see it right now. It was just something I came across in the past, might have been in lots of places as I've been digging in a lot of code lately.
<voidspace> jam: ok, no problem
<voidspace> jam: I'll keep digging
<voidspace> jam: it is explicitly documented in charm bundledata - so I'll construct a test to see if it does come out of that package
<jam> voidspace: I didn't think it was there, I thought it was somewhere like worker/provisioner
<voidspace> jam: rick_h: juju deploy ubuntu --constraints="mem=888M" --to kvm:0
<voidspace> jam: rick_h: the constraint is honoured and works
<voidspace> jam: rick_h: definitely bundle specific
<jam> voidspace: good to know, sad to hear :)
<alexisb> perrito666, ping
<perrito666> alexisb: pong
<perrito666> sorry was taking a pill because yesterday I used my back in the wrong way
<perrito666> plus my internet is down :p good thing I have a backup internet
<perrito666> feels like monday
<alexisb> perrito666, it is monday for you isnt it?
<perrito666> it is, nad I have not had a Monday so Monday in months
<alexisb> perrito666, to help improve your monday...
<alexisb> I have a bug for you
<alexisb> https://bugs.launchpad.net/juju/+bug/1640210
<mup> Bug #1640210: Restore-backup model is not usable because upgrade in progress <ci> <intermittent-failure> <regression> <restore-backup> <juju:Triaged> <https://launchpad.net/bugs/1640210>
<perrito666> also something triggered my differencial breaker in the office so after EOD ill have to run a full diagnostic to make sure nothing is leaking current
<alexisb> your favorite kind of bug
<alexisb> perrito666, please dont burn your new house down
<perrito666> alexisb: lol, lovely, Ill jump on it since my pending work from the sprint is awaiting for axw's patch to merge
<alexisb> I knew you would appreciate that bug ;)
<voidspace> wallyworld: ping - don't suppose you're around yet?
<perrito666> brb, relocation
<perrito666> voidspace: he will be here in about 5 hs
<alexisb> voidspace, wallyworld typcially starts around 9PM UTC
<voidspace> alexisb: thanks
<voidspace> perrito666: I guess I'll catch him later tonight
<voidspace> I have questions about the bundlechanges packages
<katco> voidspace: it's a lie; he is omnipresent
<voidspace> haha
<katco> voidspace: he's watching right now
<voidspace> katco: that would be nice...
<jam> frobware: voidspace: do you know if we ever implemented the default space as a configuration setting?
<voidspace> no-one has much experience with bundlechanges, but as usual it's more wallyworld's fault than anyone else
<voidspace> jam: I don't believe so
<jam> I'm wondering if "machine.AllSpaces" should be returning the default space if nothing else has been specified
<voidspace> jam: it would be better for us always to be explicit about spaces
<voidspace> jam: so machine.AllSpaces can always tell the truth
<jam> voidspace: well at some point we need to do *something* when requesting a container or machine that doesn't have a "--bind" or "--constraint space=" set
<jam> so *something* has to determine that the container/machine needs to go in the default space
<jam> voidspace: is there a bit of code that knows about the default space, or is it just that we let MAAS/EC2 give us a machine, which can be in any subnet/space ?
<jam> voidspace: theoretically there was supposed to be a default space that you would bootstrap into (detected at bootstrap time if nothing else supplied)
<jam> the extra cheap has is that it is the one that is named "default", but that especially feels bad on MAAS where you want to name them something meaningful to you
<voidspace> jam: my goodness, this was a while ago and you're making me think
<voidspace> jam: yep, on maas you should be able to specify which is the default
<voidspace> jam: I don't think we *enforce* the restriction that every machine must be in "the controller space", we just assume that everything is routable
<jam> voidspace: right, but there should also be a default space that applies to all machines when you don't specify something
<voidspace> jam: for ec2 we always have a default space and we don't let you remove spaces
<jam> which is not the controller space
<jam> but if you specify *nothing* then controller = default = whatever we bootstrap into
<voidspace> yep
<jam> voidspace: but is that *named* default, or is it a named space that we treat as default ?=
<jam> named "default"
<voidspace> jam: bah, so my understanding was a named space called "default" as it wasn't configurable
<voidspace> jam: I may be incorrect I'm afraid though
<voidspace> jam: gah, it's near EOD and I have my head in the bundlechanges code - I ought to be able to navigate this though
<jam> voidspace: sorry to distract you. good luck
<jam> voidspace: able to trace the calls through?
<voidspace> jam: no problem, I'm annoyed it isn't clearer
<jam> (for containers, if you haven't specified anything, but end up on a machine, if *it* is in a single space, then it seems ok to just use it)
<voidspace> yep, that has to be true
<jam> but that feels more like it should have only picked a machine that would have fit in the first place
<natefinch> rick_h, katco: currently add-credential requires a parameter specifying the cloud to which you're adding a credential.  Do we want to make that optional?  It would be more consistent with add-cloud if you could run interactive with zero args
<rick_h> natefinch: not at the moment
<rick_h> natefinch: for now let's leave that part
<natefinch> rick_h: yeah, outside the scope of this PR, you're right
<rick_h> natefinch: i agree that in interactive mode that's the consistent work we want, but there's bigger fish to fry atm
<fengxia41103> Any document on developing juju provider?
<perrito666> back
<redir> fengxia41103: There's this https://github.com/juju/juju/wiki/Implementing-environment-providers
<natefinch> ruh roh  juju.tools.lxdclient client_instance.go:278 while removing instance "juju-e2f2ef-0": Failed to destroy ZFS filesystem: cannot open 'lxd-pool/containers/juju-e2f2ef-0': dataset does not exist
<natefinch> hmm... that might be fixed by now, realized this is an old test
<natefinch> er old test run
<natefinch> mgz, sinzui: is there something wonky with the representative tests?
<natefinch> abentley: ^
<natefinch> http://juju-ci.vapour.ws/job/github-check-merge-juju/441/
<mgz> natefinch: they have sadly been pretty wonky for a while
<mgz> anything in particular? I'll look.
<natefinch> 19:30:24 ERROR cmd supercommand.go:458 failed to bootstrap model: refreshing addresses: instances not found
<mgz> oh, that message again... that's a new(ish) thing masking real problems
<mgz> natefinch: means the lxd container didn't come up
<mgz> natefinch: machine is probably full or similar again
<mgz> natefinch: request, can you send a message to a list, any list, mentioning that the check job is failing your branch?
<mgz> I've been fixing this stuff as people mention it and I think the overall message about things being screwed has not propogated upwards
<redir> brb reboot
<abentley> sinzui: could you please review https://code.launchpad.net/~abentley/juju-ci-tools/manual-endpoint-xfail/+merge/313274 ?
<natefinch> mgz: will do
<abentley> mgz: Do you suppose it's because the representative tests can run concurrently?
<redir> how does one relate application in different models?
<redir> applications
<mgz> abentley: I think that is certainly a factor
<abentley> mgz: test_check_token_win_remote_failure is failing on my machine.  Is this due to your "OSX/Windows client tests now more useful" changes?
<rick_h> redir: that's the cross model relations work that wallyworld is driving and is behind a feature flag
<rick_h> redir: what makes you ask?
<redir> rick_h: OCR trying to verify QA but I don't know the spelling for making that relation.
<redir> rick_h: on a CMR bit wallyworld has a PR for
<rick_h> redir: juju relate model/application:endpoint I think
<redir> figured I'd dig up the spec if the lazy IRC didn't help
<redir> ahh / I tried :
<redir> but that's already used, duh.
<redir> doesn't work. I bet I need to run with a feature flag or something
<rick_h> redir: yea, need to have the FF enabled, probably at bootstrap time
<wallyworld> redir: rick_h: that syntaxt isn't used yet. for now you 1. offer "juju offer mysql:db local:/u/me/mysql" and 2. relate "juju relate wordpress local:/u/me/mysql". steps 1 and 2 are done in different models
<rick_h> wallyworld: doh! ok I wasn't sure
<wallyworld> tis ok, all wip
<redir> wallyworld: what's the FF magic incantation?
<wallyworld> ff is called "cross-model"
<babbageclunk> wallyworld: sorry, still going through yours - thumper tried to trick me into looking at one of his, he was all "he's asleep, he won't mind"
<wallyworld> lol
<babbageclunk> Alice is taking the baby birds we found in our Christmas tree to the SPCA.
<redir> Nice
<natefinch> mgz, abentley, sinzui: is there a fix for the representative tests machines?  I can't land stuff right now because I don't know if the representative tests pass.  I mean, I guess I could just ignore it and try to merge anyway, but that seems bad.
<rick_h> natefinch: what branch is this?
<redir> babbageclunk: are you looking at 6707
<redir> ?
<natefinch> rick_h: the add cred updates and model status stuff
<rick_h> natefinch: so the add-cred updates we were going to hold until beta3 is tagged?
<natefinch> rick_h: right, right, sorry, got distracted by the test failures
<rick_h> natefinch: all good
<rick_h> natefinch: might as well hold both at this point since we're looking to tag just to not introduce anything the day of please
<rick_h> natefinch: and that'll give folks time to look and correct things
<natefinch> rick_h: sure thing
<rick_h> natefinch: ty for the email
<babbageclunk> redir: yeah, wallyworld emailed me it last night
<redir> oh
 * redir stops looking
<wallyworld> redir: sorry, i thought you we almost done and when babbageclunk stood me up in favour of thumper i figured you would come to the rescue :-)
<redir> well QA checked out
<wallyworld> good cause it worked for me too
<redir> and I got as far as that one comment.
<redir> but I know babbageclunk is working on CMR with you so prolly more useful to have him looking at it
<wallyworld> yeah
<natefinch> trivial port anyone? https://github.com/juju/juju/pull/6710    +10 -40, exactly same code merged into 2.1
<anastasiamac> natefinch: ports do not need review unless they r vastly different from original
<natefinch> anastasiamac: cool
<anastasiamac> natefinch: self-stamp :D
<alexisb> wallyworld, ping
<wallyworld> yo
<alexisb> do you mind if we meet early for our 1x1?
<alexisb> I am ready anytime
<wallyworld> alexisb: sure, give me 10?
<alexisb> yep meet you in the HO
<babbageclunk> wallyworld: reviewed, sorry for the delay!
<wallyworld> np at all ty
<wallyworld> babbageclunk: changes pushed
<perrito666> I am getting a few mins late to standup caught in traffic
<thumper> perrito666: no standup today
<perrito666> Oh didn't know, why?
 * perrito666 stops driving like a mad man
<perrito666> Irc on the phone is fantastic for traffic jams
<thumper> perrito666: due to not many people
<veebers> thumper: hah, the one time since I'm back that I remember about the standup and it's not happening :-)
<redir> well looks like bluejeans isn't happening either
<perrito666> I wanted to try my new webcam :p
<redir> so maybe bluejeans is working fine, but chromium 53 is not.
<menn0> redir: i'm on chromium 53 and bluejeans appears to be working
<redir> menn0: don't update
<redir> or something. Appears related to https://sslmate.com/blog/post/ct_redaction_in_chrome_53
<redir> which is definitely happening for me on other sites (smile.amazon.com)
<redir> and if I look at the network requests when loading bluejeans I see that error too
<redir> this started after I updated and rebooted today.
<anastasiamac> menn0: redir: chromium did not work for me with bluejeans. had to use chrome :D otherwise i had no sound
<redir> are we not having standups this week or just today?
#juju-dev 2016-12-15
<menn0> anastasiamac: I thought you were off today?
<wallyworld> babbageclunk: i have to head to cricket in about an hour - you ok to take another look at pr so i can land before i go?
<anastasiamac> menn0: m not working :) wallyworld made me log in \o/
<menn0> anastasiamac: that bastard
<anastasiamac> menn0: :D to organise the PARTY \o/
<anastasiamac> come to think of it - not that much different from my usual work
<menn0> haha
<menn0> party?
 * wallyworld is innocent
<blahdeblah> because my bugs are always a party!
<wallyworld> menn0: you get to have an xmas party, 2 x per diem
<wallyworld> there's 5 of us close by in brisbane
<anastasiamac> menn0: redir made us acquire a taste for michelin star restaurants, i've found an equivalent in bne ;)
<anastasiamac> menn0: http://www.restaurant2.com.au
<menn0> anastasiamac: nice! can I come too?
<redir> anastasiamac: you arranging my flight?
<wallyworld> menn0: of course but you need to pay your own flight :-)
<anastasiamac> menn0: redir: as long as u r ready for sauna :D VERY HOT here
<redir> anastasiamac: hehe. I think Mari would be very unhappy...
<anastasiamac> redir: partners r invited too :)
<wallyworld> but partners pay their own :-)
<anastasiamac> wallyworld: of course! partners and plane tickets r not covered ;)
<wallyworld> would have been good to have menn0 and redir fly in :-)
<blahdeblah> anastasiamac: I was just thinking how nice & cool it was here yesterday
<blahdeblah> And ocean still isn't like a bath (as of this morning, at least)
<anastasiamac> blahdeblah: u r killing me almost as much as wallyworld with his pool
<blahdeblah> pool schmool - give me waves & salt any day
<anastasiamac> blahdeblah: m more of spa kind of person - everything else involves effort :)
<anastasiamac> also m not big fan of sand in my bathing suite
<anastasiamac> suit*
<blahdeblah> Exercise is actually good for you, y'know... ;-)
<anastasiamac> not in this heat :)
<babbageclunk> wallyworld: yup - sorry was lunching
<wallyworld> no wuckers
<babbageclunk> wallyworld: looks good
<wallyworld> yay tyvm
<wallyworld> hopefully it lands first time
<babbageclunk> wallyworld: I'll keep an eye on it
<wallyworld> babbageclunk: ty. i'm about to head off, pr is almost done, hopefully it gets through
<babbageclunk> anastasiamac: do you think I need to port the fix for bug 1641824 to the 2.0 branch?
<mup> Bug #1641824: Migrating a model back to controller fails: model XXXX has been removed <model-migration> <juju:In Progress by 2-xtian> <https://launchpad.net/bugs/1641824>
<babbageclunk> anastasiamac: the bug's about migrations but the underlying problem is a resource leak when the model is destroyed
<wallyworld> babbageclunk: damn, windows failures. hit merge againn but go to head off now, will be back later tonight
<babbageclunk> wallyworld: stink - will watch it like an easily-distracted hawk
<wallyworld> np, ty
<babbageclunk> like a sort of hawk-magpie hybrid
<wallyworld> babbageclunk: anastasiamac is supposed to be on leave, but given we are supporting 2.0.x and the leak exists, would be worth a backport IMHO
<anastasiamac> babbageclunk: i agree with wallyworld (both about being on holiday and the backport) \o/
<wallyworld> anastasiamac: go away :-)
<wallyworld> oh, my ride is here, gotta go
<babbageclunk> anastasiamac: oops, sorry! you shouldn't be in here then! Ok, will do the backport - it's not totally straightforward unfortunately
<anastasiamac> wallyworld: nice try :) i need numbers tho unless u can txt me :)
<babbageclunk> wallyworld: ok, will do
<menn0> thumper: here's the fix to the unit agents going failed as the migration starts: https://github.com/juju/juju/pull/6712
 * thumper looks
<menn0> thumper: coming to hangout now
<menn0> thumper: i'm fairly certain there even used to be an attempt field but I removed because I didn't think it was needed
<thumper> :)
<babbageclunk> can I get a review of https://github.com/juju/juju/pull/6713
<babbageclunk> thumper, menn0: ^
<babbageclunk> It's a backport of the state pool fixes to 2.0
<menn0> babbageclunk: is it basically the same or did you have to restructure things?
<menn0> babbageclunk: if it's the same, no need for a re-review
<babbageclunk> It's basically the same, modulo some conflicts - yeah, probably doesn't need rereview
 * thumper sighs
<thumper> menn0: I may have found another...
<menn0> thumper: fuuuuuuu
<menn0> babbageclunk: just land it
<menn0> thumper: better us than end users I guess
<thumper> let's just say I went to migrate a model, had  no units deployed because I hadn't go to that
<thumper> and it is in the target
<thumper> but still in the source
<thumper> shows in show-models
<thumper> shows in list-models
<thumper> but won't in show-model
<thumper> I get permission denied
<menn0> that implies that reap didn't work
<menn0> thumper: PR coming for dumb migration sorting bug
<thumper> k
<thumper> menn0: also I want to change the migration master logger
<thumper> so it uses a "." not a ":" separator
<thumper> because you can't use --include-module juju.worker.migrationmaster with debug-log
<thumper> because of the :xxx
<menn0> thumper: ok sounds good
<menn0> thumper: here it is: https://github.com/juju/juju/pull/6715
<menn0> thumper: there's QA steps on https://github.com/juju/juju/pull/6715 now
<thumper> looking
<menn0> thumper: so where are we at the "" is not a valid tag issue?
<menn0> thumper: derailed by all the other problems discovered?
<thumper> menn0: extra logging added to the CI test
<thumper> waiting for it to happen again
<thumper> the bug is marked incomplete with a note
<menn0> thumper: ok cool
<thumper> menn0: interestingly, the 6 hex digit suffix to the logger for the migration master uses the last 6, all other places use the first 6 from the model uuid
<menn0> thumper: we should change that too
<menn0> thumper: I honestly thought other places used the last digits as well
<menn0> thumper: what's used for the instance ids?
<thumper> :)
<thumper> first 6
<menn0> that's what I thought I checked against
<menn0> ok
<menn0> thumper: if you're in there please fix that too
<menn0> thumper: i'm onto the next thing. is there anything I can do with the "migration already in progress" (like reap issue) problem
<menn0> ?
<thumper> I just hit the unit not idle bug
<menn0> i've been trying to land that - it's attempting now
<thumper> approved the attempt addition one
<menn0> thumper: thanks
<veebers> thumper, menn0 I may have found a bug with migrations, I'm trying to confirm it further now. It seems that superuser migrating a users model causes issues with controller cleanup
<veebers> i.e. this test passes that the superuser can migrate the model, but during cleanup the model is mentioned in both controllers cleanup output, while sitting there waiting for it to die for ages
<thumper> veebers: that is the bug I'm currently trying to fix I think
<thumper> where the reap phase hits a bug
<thumper> which is the one that cleans things up
<veebers> thumper: ah, well, ok then. In that case it seems we have a test case in place that can confirm it's fixed
<veebers> thumper: do you have a bug id for that?
<thumper> it is very intermittent
<thumper> I've done 30 migrations without triggering it
<thumper> veebers: is it reproducable for you?
<veebers> thumper: if it's the same bug I'm hitting I can get it every time it seems
<thumper> oh
<thumper> interesting
<veebers> thumper: what can I check to see if it's the same thing?
<thumper> how confident are you with the mongo shell?
<thumper> actaully
<thumper> what log level are the controllers capturing?
<veebers> thumper: its a ci test so the default level they run at
<thumper> ugh...
<veebers> thumper: i canrun with --debug if you like
<thumper> which isn't high enough to see what's going on
<thumper> yeah, run with debug
<thumper> then search the source controller logs for "setting migration phase to REAP"
<veebers> thumper: cool, I'll just wait for this to clean up then re-run
<thumper> if it is successful, you'll see "setting migration phase to DONE"
<thumper> if you are hitting the same bug, you'll not see that
<veebers> thumper: cool I'll get on that and let you know
<veebers> thumper, menn0: further model migration question: migration of model logs is done?
<thumper> yes
<veebers> thumper: cool, I'll check the implementation of the test because it fails for me currently
<thumper> k
<thumper> menn0: I'm struggling to reproduce the error
<thumper> menn0: I'll just land a patch that does the logging and reapfail
<thumper> menn0: huh... you may be right re: last 6 digits
<thumper> I thought it was the first
<menn0> thumper: possibily b/c there's less variation at the start?
<thumper> menn0: trivial https://github.com/juju/juju/pull/6717/files
<menn0> thumper: looking
<menn0> thumper: ship it
<menn0> babbageclunk: trivial one: https://github.com/juju/juju/pull/6718
<babbageclunk> menn0: looking
<menn0> babbageclunk: cheers
<babbageclunk> menn0: minor typo in docstring otherwise LGTM
<menn0> babbageclunk: doh ... thanks
<veebers> thumper: remind me what JES is in reference to juju?
<thumper> wow
<thumper> old name
<thumper> Juju Environment Server
<thumper> what Controllers are now
<veebers> thumper: coolio, thanks
<babbageclunk> menn0: no comment on my funny joke :(
<menn0> babbageclunk: youse guys are very funny
<babbageclunk> I think it's delayed jetlag
<veebers> menn0: if you're still around, I'm not seeing REAP mentioned at all in the source controllers machine-0.log file, does that mean I'm not seeing the same bug as thumper or something else?
<hoenir> could anyone provide some oppinions on this patch? https://github.com/juju/juju/pull/6523
<voidspace> wallyworld: ping
<jam> voidspace: calendar says that today is a wallyworld swap day
<jam> voidspace: looks like he's gone until the end of winter break, so if you need him, I'd recommend email
<voidspace> jam: ah, thanks - I will do
<voidspace> jam: I still want to think about your default space email, it seems like a good analysis
<jam> hm. 'juju show-machine 0/lxd/0' doesn't work. you have to specify the host machine
<perrito666> morning all
<jam> morning perrito666
<jam> frobware: voidspace: should 'juju add-machine --constraints spaces=UNKNOWN' be rejected early?
<jam> I'm seeing it try to provision and then fail, cause who is 'unknown' ?
<voidspace> jam: failing early always seems better
<frobware> voidspace, jam: +1 on failing early
<wallyworld> voidspace: hey, am here now
<jam> frobware: voidspace: rick_h: https://pastebin.canonical.com/173699/ "juju show-machine" showing that the host machine has 3 bridges, but 0/lxd/2 is only in one of them
<voidspace> wallyworld: hey, hi
<jam> wallyworld: go home
<jam> :)
<voidspace> wallyworld: how well do you recall the details of bundlechanges?
<jam> wallyworld: well, you're probably home. but you shouldn't be working. you have vacation time for a reason :)
<voidspace> wallyworld: it has good tools for me to play with it, so I'm finding my way round it slowly...
<rick_h> jam: <3 !!
<voidspace> wallyworld: I need to copy application constraints from the application to container creation (sometimes)
<wallyworld> jam: just got back from cricket match, so i'll go away soon
<voidspace> wallyworld: I'm about to go into a call though - I'll email you...
<wallyworld> voidspace: you meant the juju/bundlechanges repo?
<rick_h> wallyworld: did anyone win? or do you go back tomorrow for more game?
<voidspace> wallyworld: yep
<wallyworld> voidspace: +
<frobware> jam: I'm wondering if that is misleading. That's fallen back to using lxdbr0
<wallyworld> that was written by rick's guys
<rick_h> psh, wallyworld is rick's guys :P
<wallyworld> voidspace: i did make sime tweaks to account for multi-series
<voidspace> wallyworld: rick_h thinks frankban would be a better person to talk to...
<voidspace> wallyworld: I will pester him instead :-)
<wallyworld> voidspace: correct, i tweaked that package but didn't write it
<jam> frobware: heh, well, it could just be broken, indeed. I saw 10... but missed that it wasn't 10.100.
<jam> frobware: but it only has 1 :)
<frobware> jam, that I can agree with. :)
<frobware> yet again maas 2.1.1 failed to relase my node. Need to capture logs for this + bug.
<frobware> or... it could be Juju.
<jam> frobware: db.linklayerdevices.find() shows that I don't have any records for the container...
<jam> time for more debugging
<frobware> jam: https://github.com/juju/juju/blob/staging/apiserver/machine/machiner.go#L233
<frobware> jam: and various other places that do the same check
<jam> frobware: I don't think that is valid here. I think I'm getting an error somewhere, but it isn't getting logged/reported
<jam> frobware: 20MB upload of .gz to try out a new jujud
<frobware> jam: build locally @frobware.com if it helps
<jam> frobware: that would be 14M if we used xz instead of gz
<frobware> jam: I would use pxz. MOAR CORES! :)
<frobware> jam: well, same format, just quicker to compress/decompress
<jam> frobware: yeah, I was getting an error, it was triggering: got error looking for host spaces: subnet "127.0.0.0/8" not found
<jam> so our tests need to include Addresses that aren't in known spaces, and we see that it properly skips them
<frobware> jam: did you just run into https://bugs.launchpad.net/charms/+source/ceph-osd/+bug/1603074
<mup> Bug #1603074: subnet "127.0.0.0/8" not found <juju:New> <ceph-osd (Juju Charms Collection):Invalid> <https://launchpad.net/bugs/1603074>
<frobware> rick_h: ^^
<perrito666> meh either my office RCD is malfunctioning of the pc is
<voidspace> perrito666: sounds worse than my lights problem :-(
<voidspace> rick_h: yup, with my change to bundlechanges (not yet pushed anywhere - will do that now and work on test)
<voidspace> rick_h: application constraints are honoured by KVM placement
<voidspace> rick_h: and it's a relatively simple change
<rick_h> voidspace: <3 great to hear
<jam> mgz: thoughts on having Juju support '.xz' for agent binary tarballs? On my machine it is 20MB as a .gz, but 14MB as a .xz
<mgz> can ubuntu core unpack them?
<jam> mgz: 'xz' is the standard distribution of deb files now, I believe
<jam> mgz: http://juju-ci.vapour.ws/job/github-check-merge-juju/454/console I accidentally submitted it 1 time against staging, but it is now targetting 'develop'
<jam> mgz: why is it still complaining?
<mgz> jam: lets see
<jam> mgz: unfortunately the 'check' system doesn't let you go back and see old vs new (or I haven't found it)
<jam> so I don't know if it is a stale failure
<jam> or it ran again and is still failing
<mgz> jam: I see the pr targetted vs staging still?
<mgz> #6720
<jam> mgz: but I'm trying to get 6722 checked
<jam> sorry https://github.com/juju/juju/pull/6721
<jam> 6721
<jam> mgz: why is the link from 6721 linking to the check for 6720 ?
<jam> mgz: do we only support 1 source branch?
<mgz> jam: you can confused it it seems :)
<jam> (1 pr per source branch even though I hvae targetted it 2x)
<jam> I even closed the 6720
<mgz> jam: let's see if I can do a manual build to unstick
<jam> mgz: I can't retarget 6720 cause something is already targetting develop
<jam> (6721)
<jam> and googling says you can't delete PR, only close them
<mgz> jam: I believe I have unstack you
<jam> rick_h: voidspace: frobware: a proper 'juju show-machine' https://pastebin.canonical.com/173707/
<jam> note that the address is from the right IP range
<jam> 172.16.102.34 instead of 172.16.101 or 10.*
<rick_h> jam: ty
<rick_h> macgreagoir: ^
<voidspace> jam: cool
<jam> the ip results from that machine, I'm wondering if it doesn't have a default gateway at all:
<jam> https://pastebin.canonical.com/173708/
<jam> it must have something, as I can ping 8.8.8.8
<jam> but it definitely has an unroutable resolver
<voidspace> rick_h: jam: heh, looks like I uncovered (and fixed by accident) another bug in bundlechanges - application constraints were ignored for "new" machines as well (when specified with placement) - not just containers
<rick_h> voidspace: gotta love drive-by improvements
<voidspace> just need add a test to cover that change and frankban is happy
<rick_h> voidspace: make sure to get frankban|afk as one of the reviewers if we can please.
<rick_h> voidspace: <3
<voidspace> rick_h: already done
<natefinch> ha, I misread that as "just need a test to see if frankban is happy"   which seems like a pretty fragile test, IMO
<voidspace> natefinch: hehe, yeah - making that deterministic would be "challenging"
<natefinch> crap, why did CI fail this time?  Oh, dang, frank stubbed his toe again.
<voidspace> :-)
<frankban> natefinch: yeah I hate when it happens
<frobware> rick_h, macgreagoir, jam: so other info to capture as part of  show-machine is: gateway,  DNS nameserver entries. And probably more as containers are not bridged onto all subnets...
<frobware> Just noticed: Gogdand - https://www.jetbrains.com/go/
<frobware> or, gogland :/
<macgreagoir> frobware: Do you mind adding anything you think of to that card. I'll add these now.
<frobware> macgreagoir: will do. ty for adding the ones I just mentioned.
<macgreagoir> It'll be a straight dump of the machines doc soon :-)
<natefinch> this is the worst:
<natefinch> $ juju credentials
<natefinch> ERROR removing secrets from credentials for cloud azure: auth-type "userpass" not supported
<frobware> macgreagoir: we could just run, in a fuzzy way, all of ip, brctl, cat /etc/ .... :)
<natefinch> katco: you wanted to talk about pollster?
<katco> natefinch: yes, i couldn't find how to give default values for questions
<natefinch> katco: like a default for an open ended question, e.g. name?
<katco> natefinch: yeah, e.g.: "What would you like to name your cloud? [my-cloud]: "
<katco> natefinch: i thought you had said yesterday that this was possible
<natefinch> katco: I haven't written support for it yet.
<katco> natefinch: ah ok. i'll just skip that question then
<natefinch> katco: I have support for defaults for multiple choice, but not open ended
<katco> natefinch: ta
<natefinch> welcome./.. I actually will be adding that with my bug fix I'm working on today
<natefinch> so it'll probably work out
<voidspace> mgz: hey, the jujugui bot has different magic to trigger a merge - do you know it?
<rick_h> voidspace: :shipit:
<voidspace> rick_h: ah....
<voidspace> rick_h: thanks :-)
<mgz> rick_h won
<voidspace> mgz: you can do a review though instead...
<voidspace> mgz: https://github.com/juju/juju/pull/6723
<voidspace> mgz: if you would like...
<rick_h> voidspace: just sanity checking, is there any way this can cause is issues in non-container setups?
<rick_h> voidspace: the change didn't seem to key off containers in any way so if I deploy with a constraint to a machine on the bare metal it can blow up now vs what is used to do?
<voidspace> rick_h: it has two changes - new machines will now honour app constraints
<voidspace> rick_h: and also containers will honour app constraints
<rick_h> ah ok, since it's not a "new machine" it'll be ok
<voidspace> rick_h: those are the only two places that now have constraints that previously didn't
<voidspace> rick_h: and the absence of those two places are both bugs
<rick_h> voidspace: rgr ty
<voidspace> rick_h: both new changes are guarded by a check - either ContainerType != ""
<voidspace> rick_h: or placement.Machine == "new"
<voidspace> rick_h: so I'm *fairly sure* there are no new issues being created here...
<rick_h> voidspace: you're good. I was just looking at the diff scanning for container checks but those were already there
<rick_h> voidspace: sorry, just got my brain thinking appreciate you reassuring my worry-self :)
<voidspace> :-)
<voidspace> frobware: you're OCR today I believe, would be nice to land this on 2.1 and develop today before I EOD
<voidspace> frobware: https://github.com/juju/juju/pull/6723
<mgz> voidspace: I have stamped the branch, have not done the QA steps
<mgz> you might want to flatten to one commit
<voidspace> mgz: thanks, I have tried the QA step myself
<voidspace> also https://github.com/juju/juju/pull/6724
<katco> natefinch: you're probably the best to review this (small): https://github.com/juju/juju/pull/6725
<voidspace> mgz: hopefully one last time please
<voidspace> mgz: https://github.com/juju/juju/pull/6726
<natefinch> katco: looking
<katco> natefinch: ta
<mgz> voidspace: approved
<voidspace> mgz: you rock, as always
<redir> +1
<natefinch> dammit... my 24" monitor just made a nasty hissing noise and turned off... and now won't turn on
<natefinch> possibly just a fuse or something, but.... dammit.
<perrito666> natefinch: lol, yes, that definitely is something burning
<perrito666> hissing sound i would go for something more serious than a fuse
<mgz> unless there is a snake sheltering in there for warmth, and it hit the power button
<natefinch> Gah, this is horrible... all my muscle memory has me looking at my now-dead monitor for IRC :/
<natefinch> on a different note, I see this test failing: TestAgentConnectionDelaysShutdownWithPing    anyone seen this as an unrelaible test?  It fails with "connection didn't get shut down"  which sounds suspiciously like a timeout
<natefinch> sinzui, abentley, mgz: have you seen this failure? ^  full failing output: http://pastebin.ubuntu.com/23634769/
<sinzui> natefinch: that looks like the old timing bug we often see in lxd
<sinzui> natefinch: https://bugs.launchpad.net/juju/+bug/1632485
<mup> Bug #1632485: TestAgentConnectionDelaysShutdownWithPing fails <ci> <intermittent-failure> <unit-tests> <juju:Incomplete> <juju-core:Won't Fix> <juju-core 1.25:Won't Fix> <https://launchpad.net/bugs/1632485>
<natefinch> sinzui: thanks for the bug link
<redir> bugger commodity hardware
<alexisb> hml, sorry omw
<hml> alexisb: okay
 * redir lunches
<alexisb> veebers, ping
<veebers> alexisb: hello o/
<alexisb> heya veebers I hear there is some turmoil in the MM tests
<alexisb> wanted to let you know that with menno and tim out babbageclunk is around if you need a developer to take a look
<veebers> alexisb: ah excellent thanks :-) I'll be bothering babbageclunk a little bit today to clarify some concerns I've run into with the tests
<veebers> I'm just retesting some now as I see some fixes landed between my last testing and now
<babbageclunk> veebers: cool cool
<alexisb> awesome will leave you guys to it, thank you both
<veebers> babbageclunk: So I have a test here which is passing the migration part, but the controllers fail to be cleaned up (kill-controller is waiting for ages as well as attempting to kill the migrated model on both controllers)
<veebers> babbageclunk: thumper mentioned it may be related to a bug he was working on but I'm not sure. The test creates a user with superuser perms and does the model migration (that's the difference between this test and the migration test that passes)
<mup> Bug #1650401 opened: Kubernetes-core bundle fails to deploy. Easy-rsa results with failed hook <juju-core:New> <https://launchpad.net/bugs/1650401>
<veebers> babbageclunk: would you have some time to take a look with me at this issue?
<mgz> veebers: kill-controller waits more than 5 minutes? or just destroy-controller
<mgz> veebers: my starting point would be to turn on trace logging, ssh in during destroy controller, and pull down all the logs from the controller machine 0
<mgz> we have seen a bunch of teardown issues following migrations, of interesting nature
<babbageclunk> veebers: sorry, missed this until now!
<mup> Bug #1650405 opened: Juju Embedded - Juju logout/login not working for multiple users connected to same controller   <juju-core:New> <https://launchpad.net/bugs/1650405>
<babbageclunk> veebers: ready to look at it with you now
<veebers> babbageclunk: nw, I have something to try out now so will try collect those logs
<veebers> mgz: is there a nice way to turn on trace logging for a test? --debug is easy enough but maybe not the level that you want?
<babbageclunk> veebers: ok, let me know if you want me to take a look too
<veebers> babbageclunk: will do, I'll probably call on you when I'm going through the collected logs etc.
<mgz> veebers: export JUJU_LOGGING_CONFIG="<root>=TRACE" before bootstrap (or running a ci test)
<babbageclunk> veebers: ok
<mgz> or babbageclunk can perhaps give you a more targetting logging config
<mgz> we might just want the workers stuff and some other bits at trace
<babbageclunk> mgz, veebers: well, there was the dependency problem that I fixed while we were in Barcelona, but that shouldn't be happening anymore.
<babbageclunk> veebers: Does this problem happen reliably?
<mup> Bug #1650405 changed: Juju Embedded - Juju logout/login not working for multiple users connected to same controller   <juju-core:New> <https://launchpad.net/bugs/1650405>
<veebers> babbageclunk: yes it does, everytime I run this test
<mgz> veebers: grab the logs and trace during the hung teardown, and some careful pouring should give an idea
<veebers> mgz, babbageclunk test is running now. I'm about to pop down to town for an errand so might be a short delay before I can get you the logs
<babbageclunk> veebers: ok cool
<babbageclunk> mgz: ping
<mgz> babbageclunk: heya
<babbageclunk> mgz: Hey (isn't it super late for you?)
<babbageclunk> mgz: I'm trying to change my lxd config using `lxd init` but it keeps complaining that I've got containers when I don't. Any ideas?
<babbageclunk> mgz: correction - I didn't when I was running the command, but I do now, so I probably can't try anything out.
<mgz> babbageclunk: I'm back in for the evening
<mgz> babbageclunk: did you run lxd init as root? there may also be some other bits of setup that prevent it being rerun
<babbageclunk> mgz: yup, ran with sudo.
<babbageclunk> mgz: I could've sworn that I've run it before to change subnet + stuff
<babbageclunk> mgz: trying to turn off zfs given worse performance
<mgz> yeah, it is rerunable to some extent
#juju-dev 2016-12-16
<veebers> right, mgz babbageclunk sorry for the delay, that test has run through. Should I put the 2 controller logs somewhere or is there something obvious I can check for?
<babbageclunk> hey veebers - yeah, could you look to see whether the migrationmaster says "successful, removing model from source controller" twice for some reason?
<veebers> babbageclunk: is that the exact text to search?
<babbageclunk> veebers: I'm chasing a big about that at the moment.
<babbageclunk> veebers: yup
<veebers> ack
<babbageclunk> *bug
<babbageclunk> veebers: are you running your test against develop?
<babbageclunk> natefinch: ping?
<veebers> babbageclunk: hah, i mess that up I don't have the logs for the destruction period. I don't see that string at all in either controller logs (machine-0.log)
<veebers> babbageclunk: I'm running it against the latest 2.1 build
<babbageclunk> veebers: so maybe the migration isn't successful?
<babbageclunk> veebers: ah, ok - I think I've tracked down this bug to something that landed in develop about 4 hours ago, so it won't be related
<babbageclunk> veebers: and what are you doing in the test - deploying a charm, migrating, migrating back?
<veebers> babbageclunk: I see "setting migration phase to SUCCESS" once in the logs, but that'll be for the first migration not the migration back
<veebers> babbageclunk: exactly that
<veebers> babbageclunk: also after the migration adding a unit to that model and ensuring it's working
<babbageclunk> oh, nice
<babbageclunk> veebers: hmm. I think maybe I should fix this one and then just try to reproduce your one on 2.1.
<veebers> babbageclunk: ok, it's easy enough to reproduce
<natefinch> babbageclunk: what did I break?
<natefinch> veebers: ^
<veebers> natefinch: I don't know if babbageclunks ping has something to to with the bug I was talking to him about sorry
<natefinch> veebers: quite possible... I landed some stuff today that is triggered during migrations
<veebers> natefinch: the issue I'm seeing was happening yesterday (and before) too. Perhaps it's to do with the other bug he was working on
<natefinch> ahh hmm, then yeah, probably not my thing
<veebers> natefinch: we'll have to wait with bated breath to find out :-)
<veebers> babbageclunk: FYI I have a run of this test where I have the environment still in tact (i.e the controllers weren't killed) so we can poke around that if it's of interest
<babbageclunk> natefinch: still around? It looks like your migration status change fails at the end of the migration - it tries to set the status for the model after it's been removed
<babbageclunk> (sorry, was on a call)
<natefinch> babbageclunk: hmm... crud
<babbageclunk> natefinch: https://bugs.launchpad.net/juju/+bug/1650425
<mup> Bug #1650425: migration: migrating back gives "target prechecks failed: model is being migrated out of target controller" <juju:New> <https://launchpad.net/bugs/1650425>
<natefinch> ahh, you know, I saw that error and brought it up at the sprint, but someone said it was a different bug that would get fixed later.  guess it was the same effect but different cause
<babbageclunk> natefinch: I've made a change to the unit test for migration.SetPhase so it fails - if I send that to you can you look at this tomorrow?
<natefinch> babbageclunk: yeah, thanks
<babbageclunk> natefinch: then I can chase some other migration bugs :(
<babbageclunk> natefinch: awesome, thanks!
<babbageclunk> (like veebers's one)
<natefinch> babbageclunk: thanks for writing that test
<babbageclunk> natefinch: it's a tweak to the existing one to make it match reality more (by removing the model before setting the phase to DONE).
<babbageclunk> natefinch: I'll send you the patch
<natefinch> awesome
<Andrew_jedi> jamespage: Hello, I was wondering that Juju creates an "Admin" role but in policy.json, mapping is done for "admin" role. How does that work here?
<Andrew_jedi> jamespage: Hello, I was wondering which service user owns the "users and projects" created by heat ? juju or heat-cfn_heat ?
<natefinch> perrito666: https://pbs.twimg.com/media/CzzeFsSXUAA815I.jpg:large
<natefinch> looks doable
<perrito666> natefinch: I dont see signs of component burn (the rightmost green one is the one you want to change) there should be some if youheard a buzzing noise
<perrito666> perhaps in the other side of the board?
<perrito666> the fuse might be at fault but that kind of fuse usually burns with a dry "click" noise and also, if the fuse blows it means something else is failing
<natefinch> yeah, I'll look on the other side.  It was definitely a hiss, like air rapidly leaving a small hole, not a click
<perrito666> capacitors could do that if leaking fluid, most other components make a sound like a match burning
<perrito666> also, next time use a better cam or more light
<natefinch> heh
<natefinch> perrito666: http://imgur.com/a/4rmIU
<deanman> Any idea why juju 2.0.2 won't let me deploy my own charm and i get this error ? http://paste.ubuntu.com/23638330/. I can deploy other charms just fine
<natefinch> deanman: seems like a proxy problem... we try to HTTP POST the local charm to your controller, but there's a proxy getting mad at you for some reason
<deanman> natefinch, Yes im behind proxy and there is a bug reported and found a workaround but it seems like this is something new in 2.0.2. Does this look ok to you ? http://paste.ubuntu.com/23638370/
<deanman> ok found it, juju prefers NO_PROXY over no_proxy and in my case i had script setting NO_PROXY which i wasn't monitoring.
<natefinch> deanman: glad you figured it out. Sorry I had to bug out for a while
<perrito666> ill be relocating bbl
<redir> maas instructions say to choose "multiple server install with maas" however I don't see that when I boot from the xenial server iso. Did something change?
<deanman> natefinch, no worries, still learning my way so more than often im usually to blame
<perrito666> redir: mm, what options do you have?
<redir> perrito666: region or rack controller
<perrito666> redir: rack controller
<redir> perrito666: tx
<perrito666> hold
<perrito666> I got it wrong
<perrito666> mm, I did this in a much different way last time
<perrito666> I used the maas package
<perrito666> redir: here is a detail https://maas.ubuntu.com/docs/install.html
<redir> perrito666: I saw that which also says to choose multiple server install.... or do it from the cli
<redir> which maybe I should just do the latter
<perrito666> redir: I am not sure how to do this using the actual install disk
<perrito666> redir: have you tried #maas?
<redir> perrito666: nope, me goes there
<redir> asked in maas as well.
<katco> alexisb: happy birthday :)
<natefinch> sinzui: getting a weird represenative test failure... trusty unit tests pass, but the trusty job still fails... http://juju-ci.vapour.ws/job/github-check-merge-juju/462/artifact/artifacts/trusty-err.log
<perrito666> katco: I believe alexisb is k.o with a flu
<perrito666> alexisb: hb in any case :)
<katco> perrito666: doh. trying to fight off a respiratory infection myself. travel is hard on the body
<perrito666> katco: It only affects my stomach, which is not that bad because I take gastritis meds anyway :)
 * sinzui looks
 * perrito666 wishes CI tests would print a summary at the ened
<perrito666> end
<katco> perrito666: since having a kiddo, i have discovered that my lungs are apparently my weakness
<katco> perrito666: never got sick < kid < respiratory infections
<perrito666> lol
<perrito666> katco: happens a lot
<perrito666> I am son of a doctor so I got an epecially good inmune system just because of how many things my mom broght back form the hospital :p
<sinzui> natefinch: The tests are *incomplete* the 255 exit code implies ssh was dropped during the test. The test s got as far as github.com/juju/juju/feature
<sinzui> natefinch: do you want me to requeue?
<natefinch> sinzui: oh weird, ok, yeah, I missed that they didn't actually finish (or at least, we couldnt' tell they finished)
<natefinch> sinzui: yes please requeue
<sinzui> I sussed macgreagoir's bug. Juju's default contstraints for privisioning a non-controller machine are invalid for the new regions. If I use --constraints mem=4G as I think the controller contrains do I get a machine
<natefinch> katco: I think eventually your immune system adjusts... I don't get sick as often any more, but it took a few years.
<sinzui> natefinch: No shame in missing that. It tooks me a few weaks of looking at those abominalble ppc63el logs to learn they often dropped connection
<katco> natefinch: i am definitely getting sick less. but seems as though travel still gets me with lack of sleep/dry air
<mgz> sinzui: hm, invalid in what what?
<mgz> *way
<mgz> there are no possible instance types matching the constraint? or they match an instance type that doesn't really exist in the region?
<sinzui> mgz --constraints mem=4G cs:trusty/ubuntu tu works.  the default constrains for a hosted machine are invalif
<rick_h> katco: yea, my son's second year is the 'year we don't talk about'
<rick_h> katco: for 11 months at any given time at least one of us was sick
<katco> rick_h: it is really the only thing about having a kid that took me by surprise. the rest i expected to be surprised by
<rick_h> lol
<natefinch> review anyone?  Pretty simple: https://github.com/juju/juju/pull/6730
<natefinch> katco: if you have time, this adds ability to have defaults on open ended queries from Pollster
<katco> natefinch: sure will tal
<mgz> hm, so it would be nicer to not prompt, but if I'm reading this right the prompt does include the url that will be set if nothing is entered?
<mgz> ah, it includes "use cloud api url"
<mgz> which is fine
<deanman> Is it possible to provide something like a local `simplestreams` service so you could deploy a centos7 lxd image served from your local lxd daemon ?
<natefinch> deanman: you can definitely do custom simplestreams urls
<natefinch> but obviously you can serve them from your laptop to an AWS machine (unless you have some wacky networking set up).
<natefinch> s/can/can't
<deanman> natefinch, What's the status with centos7 support? Any idea when will there be support other than private clouds?
<natefinch> deanman: I'm not sure of the official status... but it's one of those things were you have to get 3 different very large companies to agree on something
<natefinch> FWIW, custom image streams is bootstrap -config image-metadata-url=http://xxx.xxx.xxx.xxx/simplestream/images/
<deanman> will that work for LXD images?
<natefinch> deanman: lxd provider, or lxd containers on another provider?
<deanman> hmm that is a good question
<deanman> dare to say any? Simply want to see that i can re-purpose my workload from centos7 to jujufied centos7 charm.
<deanman> natefinch, open to any suggestions. At the end probably publish the workload as an lxd image, and then write a charm that pulls that on top of a xenial charm ??
<natefinch> deanman: that sounds like it's outside the scope of what juju provides.  The charm can, of course, tell lxd to download images from wherever
<sinzui> deanman: There is some monkey business involving lxd images
<natefinch> deanman: but then it'll be opaque to juju
<sinzui> deanman: lxd images always come from cloud-images.ubuntu.com and ubuntu names them in such a way to use the alias as a cache
<sinzui> deanman: I have created my own lxd images, then gave them an alias like ubuntu-xenial to convice juju to use it
<rick_h> deanman: it's something we were looking at as part of some work to cache lxd images and such, but it's not implemented at the moment so you have to go hacky like sinzui mentions
<sinzui> deanman: I don't know if juju+lxd can be tricked to serve a centos image, bug the alias might be ubuntu-centos7
<sinzui> deanman: I can point you to testing images for aws that has centos7. I would love to get some feed back about their usefulness
<sinzui> deanman: I mean testing stream with centos7 images registered for aws
<deanman> natefinch, agreed, but need to demonstrate the power of juju, working on local and then just deploy on a cloud for staging/production.
<deanman> sinzui, Im happy to assist, give feedback with any workaround till official fix lands on 2.1.0 (at least from what i see on launchpad)
<sinzui> deanman: bootstrap with image-metadata-url: https://s3.amazonaws.com/temp-streams/aws-image-streams/
<sinzui> deanman: or use model-config to set it
<deanman> sinzui, i was looking into that https://streams.canonical.com/juju/images/releases/streams/v1/index.json
<sinzui> deanman: That is the official local that augement ubuntu streams with windows and centos image data. the testing stream successes are promoted to that location. I believe the problem with centos images streams is that they break juju 1.25
<deanman> sinzui, should i select a specific aws region ?
<natefinch> katco: how much do you care about those test names?  My thought was that Test<FunctionName> is a reasonable convention to indicate "here's a normal happy-path style test for FunctionName"
<katco> natefinch: well, the problem is "which happy path"?
<katco> natefinch: i approved the PR, but i would prefer to see folks begin encoding some expectation into the name of the test
<natefinch> katco: I know, but at the same time, I can't really see calling it TestEnterVerifyWhereVerifyPassesOnTheFirstTry
<katco> natefinch: gentle probing into why not?
<sinzui> deanman: oh, you might need to. us-east-1 defintely works
<deanman> sinzui, ok yes, eu-central allready failed, retrying with us-east1
<sinzui> deanman: I see. Indeed the regions are only a subset. I see eight regions https://s3.amazonaws.com/temp-streams/aws-image-streams/streams/v1/com.ubuntu.cloud.released-aws.json
<natefinch> Because it makes the test output harder to read, and because CamelCase  can never fully encode the expectations of multiple lines of code, so why not give something easier to read?
<natefinch> no matter what, when you see test Foo failed at line 87, expected "foo" got "bar".... you need to go look at line 87 to understand what exactly failed.
<deanman> sinzui, eu-west-1 seems like a better fit for me Greek
<katco> natefinch: i am not really convinced that it makes test output harder to read. i also use underscores in my tests, e.g. Test<precondition>_<expectation>
<deanman> :-)
<natefinch> katco: I am generally for being more verbose for tests, but I think you rapidly reach the point of diminishing returns with test names.  In addition, I think that long names may obscure minor differences in the name and thus cause confusion.
<katco> natefinch: how do you propose differentiating happy path tests?
<natefinch> katco: generally, by the code and/or comments.   I mean, obviously they also need separate function names (unless you'
<natefinch> you're using subtests)
<katco> natefinch: yes, what will those function names be?
<deanman> sinzui, http://paste.ubuntu.com/23639866/
<natefinch> katco: I guess I see it as mostly subjective and not worth worrying that much about.  I wouldn't ding someone for making names I consider too long (unless they're truly egregious, like unable to fit on the screen) and I would hope others wouldn't ding me for making mine too short (again, except egregious outliers, like TestX TestY etc)
<natefinch> as long as they're relatively descriptive... there's really only so much you can encode in a single line of text.  You can't put everything in there, so where do you stop?
<katco> natefinch: sorry, trying to get at the heart of your objection here. so you're retracting your earlier criticism?
<katco> natefinch: my objection is that Test<noun> only tells me the thing i'm testing (maybe), but not the behavior, and i care more about the behavior
<katco> natefinch: it is not about number of characters at all
<natefinch> katco: my point is that nothing except the code of the test can tell you the behavior.  The name of the test can give you a hint.  And I thought that Test<Noun> was a reasonable "basic usage test" name.
<deanman> sinzui, guessing that my juju aws account somehow needs to be authorized to spin centos7 images?
<katco> natefinch: how do you name your test functions when you want to test 2 behaviors of <noun>?
<sinzui> :/
<natefinch> katco: *shrug* something else.  TestFooOdd  TestFooEven.  The problem comes with more complicated arguments.  When you take a struct with 8 fields, it breaks down.
<sinzui> deanman: I don't think that should be the case. the stream was made with public images. There were selected from a query for centos7 built by some party I don't recall
<katco> natefinch: not sure what you mean re. # fields
 * sinzui looks into images
<sinzui> deanman: oh, yes, I do recall that message from the pastebin. I think you just need to accept that you will use them and that the owner is not responsible for what might happen
<natefinch> How do I name a test that tests SetUser with the value User{ Name: "Bill" , Age: 30,  SSN: ###, Balance: 50, Maiden: nil, State: MA, Email: "foo@example.com", Active: false }
<katco> natefinch: what behavior are we hypothetically testing?
<natefinch> If you are over 25 and your balance is under $100 and you live in HasMinBalanceFee(st State) and you're active, we send an email with your name telling you that your balance is low.
<natefinch> to be fair, that's only 6 fields that we actually look at
<deanman> sinzui, unfortunately i can't log into AWS account to opt-in, i think no-one can from the AWS charmer program.
<katco> natefinch: what label encapsulates the behavior of that situation?
<natefinch> I would call it TestSendLowBalanceEmail
<natefinch> But obviously the name doesn't encompass everything in the preconditions necessary.  But that's what comments are for.
<katco> natefinch: what is the label that describes those criteria? a low balance user?
<sinzui> deanman: well I think that needs to be fixed. the charmer program should allow peple to develop with for centos and windows. I do recall that a member of my team had to accept the use of the centos images. I don't see it in billing though
<katco> natefinch: TestSetUser_EmailSentWhenLowBalance, or whatever it is that describes that situation
<natefinch> katco: my point is... it's bikeshedding.  If you want a convention of TestFunctionName_TestDetails, I think that's fine as a way to easily find the tests for a specific function.  Of course, some tests may test more general cases which aren'
<deanman> sinzui, Is it Marco that should look into this ? Jorge?
<natefinch> aren't merely a test of a single function
<sinzui> deanman: I think jcastro is our point of contact
<katco> natefinch: if we're testing > 1 thing in a test, this is a problem; in my view, another +1 for this approach
<katco> natefinch: i'm sorry you see it as bikeshedding; i still can't glean what your objections are
<sinzui> deanman: I honestly cannot see how my test of centos worked two hours ago. Some one my team must have accepted the terms at the start of this year, but I cannot see any billing regarding our use
<sinzui> deanman: this is my last day of the year. We might not have an easy solution this month for this, but I am certain we can find a way to ensure developers can get access to our testing images.
<deanman> sinzui, did try the centos hack for lxd with `lxc image copy images:centos/7 local: --alias ubuntu-centos7` but didn't work. Any hints for me ?
<deanman> sinzui, thank you for your time, i might send an email to Marco or Jorge
<natefinch> katco: my objections are that I feel like we're making a rule to fix something that hasn't been shown to be a problem.  I do kinda like the ease of searching for TestFunctionName_stuff but I would kind of hope that a search for FunctionName itself in the test file would be just as useful.
<sinzui> deanman: try an alias like centos-centos7. I think the naming conventions is OS-release
<natefinch> katco: I have to run and make enchiladas.... but don't get me wrong.  I'm not burning down the house to have my way here.  I only care like 20%.
<katco> natefinch: cheers, enjoy your enchiladas
<natefinch> :D
<deanman> sinzui, that didn't work either, it looks for ubuntu-centos7 http://paste.ubuntu.com/23639956/
<sinzui> oh, it is ignoring the alias-as-cache
<deanman> hmmm, should that image be on host running juju command or on lxd controller ?
<sinzui> deanman: I think I know what is failing us, but don't know how to hack around it. Juju once used the matching alias. Then Juju got smart and now  checks that the alias's image is not stale.
<sinzui> deanman: I don't see any setting to convicne juju or lxd to not check
<sinzui> deanman: I had some misdventures with ubuntu devel images too. would manually copy the image from daily streams. that was good for a few weeks, then I get the image not foudn message you see, so I manually copied a new one in
<deanman> sinzui, could it be the image autoupdate feature of lxd ?
<sinzui> deanman: maybe
<sinzui> deanman: I see "lxc image import" lets you set --expires-at. maybe set that to a decade from now
<deanman> sinzui, but which lxd daemon is making this check? that of the host or of the controller ?
<deanman> the logs saying that the image cannot be found come from the controller
<sinzui> deanman: It is the host of each machine you deploy. the controller does not cache yet.
<deanman> ok
<sinzui> deanman: I need to leave. sorry for nit finding a solution today
<jcastro> deanman: back, what's up?
<deanman> sinzui, once again, thanks for the tips, have a nice vacation time :-D
<jcastro> deanman: ok so Marco runs those accounts and he's on a work trip, when he calls me tonight I'll ask him to investigate
<deanman> jcastro, thank you
<sinzui> jcastro: Juju will use centos images from http://aws.amazon.com/marketplace/pp?sku=aw0evgkw8e5c1q413zgy5pjce which requires the user to agree to the cost. If the charmer accoutn accepts this, they anyone in the charmers program to test their centos charrms
<jcastro> ok so what the ask is for us to accept that so that charmers can test on centos then?
<sinzui> jcastro: yes
<jcastro> ack
#juju-dev 2016-12-18
<mup> Bug #1275745 changed: juju run doesn't have an option to trigger debug-hooks <run> <juju-core:Expired> <https://launchpad.net/bugs/1275745>
<babbageclunk> redir: not working, just respinding blindly to prompts popping up on my phone!
<babbageclunk> *responding
#juju-dev 2017-12-11
<axw> wallyworld: FYI, https://github.com/google/metallb
<axw> don't recall seeing that in discussions before
<wallyworld> no, interesting
<thumper> I'm back, and eating lunch carefully
<thumper> mouth is still numb
<thumper> but I'm hungry
<thumper> axw: for this relation status problem, and the missing status values, are they being added on migration import?
<axw> thumper: so I've just looked, and migration import is not guaranteed to create a relation status doc. only if there was a status in the description
<axw> we need another bug for that
<thumper> yeah
<thumper> when did it change from being optional to required?
<axw> thumper: it was only introduced with CMR. wallyworld thinks it may have morphed from being optional to required somewhere during development
<axw> I don't know
<thumper> FWIW, I don't think we should have optional statuses, it breaks expectations
<axw> thumper: I agree
<wallyworld> i can't recall when it changed, either
<axw> thumper: created https://bugs.launchpad.net/juju/+bug/1737456
<mup> Bug #1737456: migration import doesn't always create relation status docs <juju:Triaged> <https://launchpad.net/bugs/1737456>
<thumper> axw: thanks
<thumper> wallyworld: I'm going to have to run out to collect my daughter around the time of our planning meeting in an hour
<thumper> wallyworld: so I'll be a little late
<thumper> but will be there
<thumper> jam: ping
<jam> hi thumper
<thumper> jam: care to jump in the 1:1 hangout?
<jam> thumper: omw
<axw> wallyworld: are you still working on your PR? doesn't look like you pushed changes
<wallyworld> axw: the firewaller one? i meant to, i'm on the next thing now
<axw> wallyworld: yeah firewaller
<wallyworld> hmmm, i'll check
<wallyworld> axw: something messed up with the base branch. i had to create a new pr. the last commit has the recent changes. the other commits are as per the original pr https://github.com/juju/juju/pull/8202
<axw> ok
<axw> wallyworld: so ExposeService and UnexposeService are already idempotent?
<babbageclunk> thumper: sorry, my token expired
<thumper> I figured
<babbageclunk> wallyworld: can you take another look at https://github.com/juju/juju/pull/8184?
<babbageclunk> I've made your changes, and moved it over to
<babbageclunk> 2.3
<thumper> veebers: hey, have you got a few minutes?
<thumper> veebers: to discuss scale testing?
<veebers> thumper: just OTP will ping
<veebers> thumper: sweet, free now
<thumper> veebers: 1:1 ?
<veebers> thumper: sounds good, omw
<wallyworld> babbageclunk: sorry, been in meeting, looking
<babbageclunk> wallyworld: thanks!
<wallyworld> babbageclunk: i have a purely mechanical pr if you had a chance. rename some things https://github.com/juju/juju/pull/8199
<babbageclunk> wallyworld: oh, it's like that is it? Quid pro quo?
<babbageclunk> looking now
<babbageclunk> :)
<wallyworld> babbageclunk: sorry :-( btw, lgtm for your with one small question
<wallyworld> babbageclunk: also, can you ensure we have trello cards for the todos, like getting config from agent conf etc
<babbageclunk> wallyworld: yup - I've been creating them when I add the TODO
<wallyworld> awesome, ty
<babbageclunk> I think we need the logging - the error response from the call will go to the caller, but the controller admin needs to know if audit logging is failing (preventing any user commands)
<babbageclunk> wallyworld: ^
<babbageclunk> wallyworld: Not sure about the format - I guess we probably don't need the %T, I cargo-culted that from somewhere else.
<wallyworld> babbageclunk: ok, no worries
<babbageclunk> wallyworld: why Application.CharmConfig rather than Charm.Config? Can 2 applications with the same charm have different CharmConfig?
<wallyworld> yes
<wallyworld> each app configures their charm their own way
<babbageclunk> wallyworld: cool, I guess that's why then
<wallyworld> babbageclunk: so if i deploy mysql, i can alias that to "mysql1" and "mysql2". each of those separare, distinct apps can configure mysql however they like
<babbageclunk> yeah, that makes sense.
<babbageclunk> wallyworld: approved
<wallyworld> tyvm
<babbageclunk> wallyworld: really quick one before the meeting? ;) https://github.com/juju/juju/pull/8203
<wallyworld> sure
<wallyworld> babbageclunk: lgtm
<babbageclunk> wallyworld: thanks, just in time!
<wallyworld> indeed
#juju-dev 2017-12-12
<wgrant> Ooh, scale testing?
<axw> wallyworld: back
<wallyworld> axw: standup ho?
<thumper> wallyworld: my testing has reproduced a number of issues we are seeing at scale
<wallyworld> well that is good
<wallyworld> finally
<thumper> 513 models, 142 apps, 2324 units
<thumper> no
<thumper> 3234 units
<thumper> restarting the app servers on 2.3.1 caused much issues
<thumper> massive db load
<thumper> txns.log lost iterators
<thumper> broken apiservers
<thumper> yay
<wallyworld> thumper: and your PR fixes the above I assume when you add in a custom jujud
<thumper> yeah, writing up test results now
<thumper> I'll make sure you get a copy
<wallyworld> axw: well, this is great. juju deploy is broken. the doc claims that it accepts --config foo=bar but it clearly doesn't and has been that way for a while
<wallyworld> it only accepts a yaml file for --config
<axw> wallyworld: :/
<axw> let the yak shaving begin
<veebers> wallyworld: that sounds like an EDA, it should be easy enough to add a functional test for it (probably tack onto the right place somewhere)
<wallyworld> yeah, sigh, we are awesome. the change to the code at add the config parsing looks like it was first done in 2012
<veebers> wow
<wallyworld> so clearly no one ever does juju deploy myapp --config foo=bar
<wgrant> Oh.
<wgrant> We all want to do that but assumed it was deliberately removed!
<wgrant> I have heaps of YAML files around with like three lines to work around that
<wgrant> thumper: Did the load return to normal with roughly the same profile as the post-upgrade graph?
<thumper> wgrant: yeah
<wgrant> thumper: Very nice
<wgrant> thumper: And +1 on 2.2.7, since we can't upgrade until at least 2.3.2 and by that point we're dangerously close to Christmas.
<thumper> wgrant: hmmm... wallyworld, jam, thoughts?
<wgrant> All very good news, anyway. Hopefully this will make the remaining scaling issues a lot more obvious.
<wgrant> I'll run my smaller controllers on 2.3.x over the break for validation, but don't particularly want to subject the big one to even 2.3.2 without running the small ones for a while -- despite the obvious wins from removing update-status DB writes, it's a big risk to a lot of teams and applications.
<wgrant> And it's likely that your fix will pull the shared controller out of its current pit of despair without big risk.
<wallyworld> axw: here's that deploy fix https://github.com/juju/juju/pull/8206
<wallyworld> wgrant: i just did a PR to fix. i'll backport to 2.3 for the next releae also
<wallyworld> thumper: i think a 2.2.7 would be great actually
<wallyworld> given the delay in 2.3.2
<wgrant> Do we have an ETA for 2.3.2? No rush, just wondering.
<wgrant> Also have the holes in the QA process been identified?
<axw> wallyworld: -1 on treating file contents differently based on how many are specified
<wallyworld> axw: we have to
<wallyworld> if we want to retain compatibility
<wallyworld> and sensible behaviour
<wallyworld> and conform to semantics of --config
<wallyworld> there's competing concerns here
<axw> wallyworld: why do we _have_ to? why can't we merge the values underneath the application name?
<wallyworld> because of how --config behaves - it can't distinguisg btween a yaml file with just key=values and one with the charm settings format
<wallyworld> it could guess but that would be bad IMO
<anastasiamac> wallyworld: why r we doing something silly for the sake of compaibility? i'd rather do the right thing
<wallyworld> we can't break compatibility
<wallyworld> and there's a reason for a single yaml file to have that format
<wallyworld> as it allows juju config to be redirected to a file and resued
<wallyworld> but that then cinflicts wirh --config behaviour
<wallyworld> so we need to try and accommodate both
<thumper> wgrant: probably not until the new year based on extra tests we are getting in place, and the fact that many people aren't around
<axw> wallyworld: sorry, I don't follow. can you point me at some code or docs or something?
<wallyworld> there will only ever be one yaml file with charm config format
<wallyworld> axw: hang out? will be easier
<wgrant> thumper: Sounds entirely reasonable. Thanks for the info.
<axw> wallyworld: sure
<axw> see you in standup
 * thumper at EOD
<thumper> caio
<wallyworld> axw: from what i can see, we allow for bundle storage from the CLi to override what is in the bundle itself, but as of now, there;s no equivalent mechanism for charm config - you get what's in the bundle and that's it
<wallyworld> so i think we can defer doing that stright up
<wallyworld> and just support charms for now using --config
<axw> wallyworld: sounds fine to me, if that's how it is now
<wallyworld> that's what it looks like
<wallyworld> we pass in bundleStorage to the bundle handler
<wallyworld> but not any config - that's just used in deployXCharm
<wallyworld> and all bundle config looks like it is just read from the bundle yaml
<axw> wallyworld: yep, I can't see anywhere it's used either
<wallyworld> i still need to combine yaml and config name/value for v5 of the api though
<wallyworld> if both are specified
<wallyworld> axw: that PR is updated
<axw> jam: thanks for the reviews mr. mylastname :o)
<jam> :)
<axw> jam: don't suppose you know what normally gets cleaned up on the CI machine when spaces runs out?
<jam> axw: I do not, unfortunately
<jam> axw: did you check /tmp or /var/log ?
<axw> not much in either
<jam> I would also potentially check 'ps' output in case there are file handles that are open but 'deleted'.
<jam> axw: du --max-depth=3 / | sort -n
<jam> has always been my friend
<jam> maybe max-depth=4 if you're at '/'
<axw> thanks
<axw> gotta go, I'll bbl
<axw> balloons: juju-core-slave has run out of disk. can you please let me know what you would normally delete, so I can fix it next time?  there's some stuff in /var/lib/lxd.old, taking up 1.5GB of precious space
<axw> unchanged since July 19 2016
<axw> *probably* safe to remove...
<axw> I dunno if these things are backed up though
<akshay_> 4:31 pm <akshay__> Hi All, one of our charms uploaded on charms store is not getting listed  on the portal. We have uploaded total 6 charms and only 5 are getting listed. Having said that we can see the missing charm by exact url.
<akshay_> List of the charms can be seen at: https://jujucharms.com/q/hyperscale
<jam> anyone care to review a near-trivial change: https://github.com/juju/juju/pull/8208
<jam> akshay_: I think you can ask on juju@lists.ubuntu.com
<akshay_> Thanks @jam I have sent out a mail to the same, will wait for the response.
<rogpeppe> jam: I don't understand this sentence: "you have to somehow sighup juju itself to allow it to reopen its file handles, without also restarting all of the 1000s of units that are actively communicating with juju"
<jam> rogpeppe: most things that use an external log rotator, restart the underlying process, or at least tell it to close the handles and reopen them, so they stop writing to the old location.
<jam> however, if you restart jujud, then everything connected to it (all the other agents), also lose their connections
<jam> which seems very bad in a large deployment
<jam> so I'd rather we just leave stdout/stderr to an unrotated file, but don't put much content there, and then rotate our logs without bouncing anything.
<rogpeppe> jam: what do you mean by "external log rotator" there?
<jam> rogpeppe: some process that isn't juju that rotates logs
<jam> rogpeppe: eg 'apt install logrotate'
<rogpeppe> jam: so which process are you talking about restarting?
<jam> rogpeppe: if you just 'mv stdout.log stdout-123456.log' you then have to get the process that was writing to 'stdout.log' to close its file handle, and open a new one.
<jam> the standard 'logrotate' mechanism is to bounce the agent (eg, postgresql)
<rogpeppe> jam: i wasn't suggesting doing that
<rogpeppe> jam: i was thinking of an external process that reads stdin and writes it to the current file, changing that file when it gets too big
<rogpeppe> jam: then pipe jujud output to that
<rogpeppe> jam: i guess the down side is that it's a tad less efficient because you're not writing directly to disk
<jam> i'm less concerned with that then having it be confusing because of more moving parts
<rogpeppe> jam: it would be less moving parts inside jujud itself (although I guess the scripts would need changing)
<rogpeppe> jam: i'm concerned that having stack traces separate from the log messages would make it hard to work out exactly where/when the stack trace occurred, making it hard to post-mortem debug
<rogpeppe> jam: also it means another log file to remember to gather up (and i guess that file would potentially need rotating too)
<rogpeppe> jam: because stack traces can be enormous
<jam> rogpeppe: what if we just rotated on every startup ?
<rogpeppe> jam: how would that work for long-running daemons?
<jam> rogpeppe: you don't have panic stacktraces in long running daemons, because SIGQUIT kills the process
<rogpeppe> jam: it's not improbably that a jujud might run for 6 months
<rogpeppe> s/bably/bable
<rogpeppe> jam: the problem that originally prompted the issue to be created was when we had a long running daemon that produced a stack dump
<rogpeppe> jam: another possibility would be to get juju to redirect its stderr to the rotated log file itself (by using syscall.Dup2)
<soumaya_> We are bootstrapping on openstack using https identity service ...
<soumaya_>  endpoint is https://192.168.23.222:5000/v3
<soumaya_>  but bootstrap is failing with following error ....
<soumaya_> INFO  juju.provider.openstack provider.go:144 opening model "controller" 07:41:20 DEBUG juju.provider.openstack provider.go:798 authentication failed: authentication failed caused by: requesting token: failed executing the request https://192.168.23.222:5000/v3/auth/tokens caused by: Post https://192.168.23.222:5000/v3/auth/tokens: x509: cannot validate certificate for 192.168.23.222 because it doesn't contain any IP SANs ERROR au
<balloons> axw, back
<balloons> That slave is always close to full. I would remove old workspaces, but lxd data also sounds fine
<gsamfira> hello folks
<gsamfira> is there any ppa where I can still get juju 2.2.6 ?
<gsamfira> version 2.3.1 seems to have issues with LXD containers :)
<balloons> gsamfira, there isn't a ppa but you can still get it from a snap branch
<balloons> gsamfira, what issues with lxd containers are you having? are you talking about the ubuntu-fan bug?
<balloons> gsamfira, https://bugs.launchpad.net/juju/+bug/1737640
<mup> Bug #1737640: /usr/sbin/fanctl: arithmetic expression: expecting primary | unconfigured interfaces cause ifup failures <cdo-qa> <cdo-qa-blocker> <cpe-onsite> <foundations-engine> <regression-update> <verification-needed> <verification-needed-xenial> <juju:Triaged> <ubuntu-fan (Ubuntu):Confirmed for
<mup> smb> <ubuntu-fan (Ubuntu Xenial):Fix Committed> <https://launchpad.net/bugs/1737640>
<balloons> gsamfira, snap install juju --channel=stable/2.2.6 --classic
<hallyn> ok - https://jujucharms.com/docs/1.22/howto-proxies tells me that "juju set-env" should work, but it doesn't exist
<hallyn> how do I set http_proxy and no_proxy now?
<hallyn> juju bootstrap --config somehow?
<hml> hallyn: you found an old version of the docs - itâs listed as no longer supported.
<hml> hallyn: hereâs a list of the model keys for config: https://jujucharms.com/docs/stable/models-config
<hml> hallyn: juju bootstrap âconfig http-proxy=<string>
<hml> hallyn: you might want to look at âmodel-default as well with bootstrap
<hml> babbageclunk: ping
<babbageclunk> hml: hey, sorry - was at the bank
<hml> babbageclunk: have a few minutes for an HO?
<babbageclunk> yup yup
<babbageclunk> standup?
<hml> babbageclunk: sure
<wallyworld> balloons: no call today?
<balloons> wallyworld, tim is out, and trying to stay productive :-)
<wallyworld> no worries
<balloons> wallyworld, but I thought we were going to cancel the calls for this week
<wallyworld> probs yeah
<gsamfira> balloons: yes, the fan bug it is! Thanks for the hint about the snaps
<gsamfira> <3 snaps
<hml> babbageclunk: the config used was hiding in ProvisionerSuite.Model  :-)  now to clean up the test
<babbageclunk> oh yay!
#juju-dev 2017-12-13
<axw> veebers: any idea what's up in http://ci.jujucharms.com/job/github-merge-goose/56/console? /tmp/jenkins7796601857268642679.sh: line 23: /var/lib/jenkins/juju-ci-tools/git_gate.py: No such file or directory
<axw> veebers: more to the point, what's the proper way to fix?
<veebers> axw: hey I'll have a look now
<veebers> axw: that node was aggressively cleaned up, a little too aggressively. I'm righting it now
<veebers> axw: right, that's now running and succeeded. Sorry for the noise
<wallyworld> axw: pr updated back to using map[string]string. verified with a float and a bool
<axw> veebers: thanks
<axw> veebers: is it a manual step to get the juju-ci-tools bits on there?
<veebers> axw: for the initial setup yes, but then there is a script that keeps things up to date. This slave in particular had some manual intevention recently (and is a bit of a snow flake)
<axw> veebers: okey dokey, thanks
<wallyworld> axw: thanks for review. i wanted the "preserveType" value to, by default, retain existing beheaviour, ie the yaml unmarshalling.  "preserveType" means do not mess with the values' types by unmarshalling
<wallyworld> "setDecodedYAMLValues" would need to be explictly set to true for all the current use cases
<axw> wallyworld: that seems to be the opposite of what hte doc comment says hto
<wallyworld> the comment makes sense to me i guess. maybe i can reword it
<wallyworld> i can explain what true/false means
<axw> wallyworld: "... sets whether name values should be converted to a type that is inferred from their string value"  <- they're inferred by default, so it's setting them to *not* be inferred
<axw> wallyworld: perhaps "SetPreserveStringValue"
<wallyworld> they are inferred by the default - the comment just says that the value of the attr will controll the behaviour of it. "SetPreserveStringValue" works for me
<babbageclunk> wallyworld: take a look at https://github.com/juju/juju/pull/8210 please?
<hml> wallyworld: youâre popular, though babbageclunk got there first, no rush, but if you could review please: https://github.com/juju/juju/pull/8211
<hml> gânight
<wallyworld> babbageclunk: sure, looking
<babbageclunk> wallyworld: thanks
<wallyworld> sorry i missed the ping
<wallyworld> axw: here's the next PR in the series https://github.com/juju/juju/pull/8212
<wallyworld> axw: lgtm. i can see we will be asked to allow this to be set on an existing controller. regardless, have you considered upgrade steps? will thingsbreak if we run edge on a 2.2.6 controller
<wallyworld> i guess not because everything has a default
<wallyworld> but worth checking
<wallyworld> oops
<wallyworld> babbageclunk: ^^^^^
<wallyworld> sorry, wrong person
<babbageclunk> you mean me right/
<wallyworld> poor andrew, i didn't mean to insult him :-P
<babbageclunk> ha
<wallyworld> :-D
<babbageclunk> I've thought through all of the new ones to make sure they work if there's no value, but I should try it too.
<babbageclunk> wallyworld: time for a quick chat about the problem I've been talking to blahdeblah about?
<babbageclunk> in 1:1?
<wallyworld> sure, give me 1 minute
<wallyworld> axw: thanks for review. about to test the final piece to make it all work, and then need to add more tests, but really close now
<axw> wallyworld: cool  :)
<axw> balloons: in case you get a bunch of failures in CI, I just deleted all the resource groups. there were a bunch of old ones, and new jobs were failing because the resource quota was hit for public IPs
<wallyworld> axw: there's a vspherebug that is confusing - it tries to connect to an <ipaddr>/sdk and the ip addr is something not sure of where it came from
<axw> balloons: in case it helps for automated cleanups, I did this: az group list --query "[?starts_with(name, 'juju-')].name" -o tsv | xargs -L1 az group delete -y --no-wait --name
<wallyworld> did you see that float past? have you see anything similar before?
<axw> wallyworld: I haven't seen the bug
<wallyworld> https://bugs.launchpad.net/bugs/1737868
<mup> Bug #1737868: Can't bootstrap with vsphere 6.0 <vmware> <juju:Triaged> <https://launchpad.net/bugs/1737868>
<axw> wallyworld: I believe govmomi tacks "/sdk" on the end
<axw> I'll take a look and see if anything jumps out
<wallyworld> ok, ty
<wallyworld> axw: here's the last bit if you had time https://github.com/juju/juju/pull/8214  i'm still going through manual testing, will doube check everything before landing
<wallyworld> got to make dinner, bbiab
<jam> anyone have ideas on how we could test https://github.com/juju/juju/pull/8216 ?
<manadart> Is there a method somewhere that filters a host/port collection by network space subnets?
<manadart> NVM network/address.go
<balloons> axw, thanks for the cleanups
<bdx> how's it going all
<bdx> https://bugs.launchpad.net/juju/+bug/1736022 is killing me
<mup> Bug #1736022: failed to bridge devices: bridge activaction error: bridge activation failed: Killed old client process <juju> <juju:Incomplete> <MAAS:Incomplete> <https://launchpad.net/bugs/1736022>
<bdx> I'm willing to just hand over my maas to you guys so you can pound on it and get what you need to fix it
<bdx> if anyone has a few extra minutes to look into this^ further with me it would be greatly appreciated
<bdx> thx thx
<bdx> oooh shoot
<bdx> I think my bug #1736022
<mup> Bug #1736022: failed to bridge devices: bridge activaction error: bridge activation failed: Killed old client process <juju> <juju:Incomplete> <MAAS:Incomplete> <https://launchpad.net/bugs/1736022>
<bdx> is really
<bdx> https://bugs.launchpad.net/juju/+bug/1737640
<mup> Bug #1737640: /usr/sbin/fanctl: arithmetic expression: expecting primary | unconfigured interfaces cause ifup failures <cdo-qa> <cdo-qa-blocker> <cpe-onsite> <foundations-engine> <regression-update> <verification-done-xenial> <verification-needed> <juju:Triaged> <ubuntu-fan (Ubuntu):Confirmed for
<mup> smb> <ubuntu-fan (Ubuntu Xenial):Fix Committed> <https://launchpad.net/bugs/1737640>
<thumper> hml: I'm going to be a few minutes late, dropping kiddo in town
<hml> thumper: ack
<thumper> hml: here now
<thumper> wallyworld: ping
<wallyworld> thumper: hey
<thumper> wallyworld: hey
<thumper> quick chat?
<wallyworld> sure, give me 2 minutes
<rick_h> thumper: can we bail tonight? we're getting snowed in and I need to finish this round of shoveling
<thumper> rick_h: sure
<thumper> rick_h: have a good holiday break
<wallyworld> thumper: 1:1?
<rick_h> thumper: I don't have anything atm, just doing stuff as folks start to disappear for the year
<thumper> rick_h: I'm off after tomorrow
<rick_h> thumper: you too
<thumper> wallyworld: ack
<rick_h> thumper: yea, common these days :P
<balloons> so wallyworld, shall we meet? I have just 2 things to ask about
<wallyworld> balloons: sure, wanna do it now?
<balloons> wallyworld, sure
#juju-dev 2017-12-14
<wallyworld> babbageclunk: standup?
<thumper> wallyworld: https://github.com/juju/juju/pull/8220
<thumper> I'm going to make coffee
<wallyworld> ok, looking
<thumper> wallyworld: I'm asking for a review because it isn't just a backport
<thumper> but it is sufficient for what we need
<wallyworld> righto
 * thumper -> coffee
<wallyworld> thumper: it looks like just testing chnges, did the PR include a functional change also?
<thumper> nope
<thumper> wallyworld: interface one up next
<thumper> then the functional change
<thumper> I'm trying to reduce the scope of the final review
<wallyworld> ok
<wallyworld> testing one lgtm
<thumper> wallyworld: this one has the testing commit and the interface https://github.com/juju/juju/pull/8221
<wallyworld> righto
<babbageclunk> wallyworld: https://github.com/juju/juju/pull/8222 plz?
<wallyworld> sure
<wallyworld> babbageclunk: i made a suggestion
<babbageclunk> wallyworld: yeah, thanks - tweaking it now
<wallyworld> awesome
<wallyworld> thumper: ? 1:1
<thumper> yeah, just finishing up with IS call
<thumper> wallyworld, jam: review up https://github.com/juju/juju/pull/8223
<wallyworld> ok
<wallyworld> thumper: has the hub watcher stuff been reviewed elsewhere? i think so?
<jam> wallyworld: I reviewed it on a target for 2.3, so I'll give Tim's branch a review here.
<wallyworld> jam: i have a small PR to add caas application-config to the applocation entity in the juju/description repo (if you have a chance) https://github.com/juju/description/pull/32
<thumper> wallyworld, jam: I'm probably going to miss the team standup tomorrow as my daughter has a school end of year assembly where she is getting a prize
<thumper> so I should be there :)
<thumper> morning
<thumper> balloons: I realised that I probably won't be around for the release call due to a school assembly that I need to be at
<thumper> balloons: got time to chat now?
<balloons> thumper, ohh, morning
<balloons> give me 5
<thumper> ack
<balloons> ok, hopping into release call thumper
<thumper> ok
<babbageclunk> wallyworld: ping?
<thumper> balloons: managed to reproduce failure...
<thumper> and it happens on both 2.2.7 and 2.3.2
<thumper> which makes me happier
<balloons> oO?
<wallyworld> babbageclunk: hey
<babbageclunk> wallyworld: sorry, had you been waiting for me to do that description review?
<wallyworld> not really, i only just added it at my EOD
<babbageclunk> ok cool
<wallyworld> i need it for today, so all good, ty
<wallyworld> babbageclunk: thanks for the version pickup in setApplications, i missed that
<wallyworld> there should be a test for that stuff
<babbageclunk> wallyworld: no worries. Can you look at this audit log errors one? https://github.com/juju/juju/pull/8225
<wallyworld> to ensure that the model has all the latest versions set
<babbageclunk> wallyworld: yeah, true
<wallyworld> sure, i'll need 30 mins - just woke up
<babbageclunk> no hurry.
<thumper> balloons: a subordinate charm with no relations is being confused for a principal
<thumper> balloons: so we are asking for constraints
<thumper> however juju status doesn't show any difference between a subordinate with no relations, and a normal charm with no units
<balloons> thumper, ahh.. I was confused why that made you happy, but I get wanting consistency
<thumper> I ended up bootstrapping two controllers
<thumper> and doing the exact same thing on both
<thumper> and was getting the same results
<thumper> finally worked out what it might have been
<thumper> and it failed on both
<balloons> wallyworld, babbageclunk we still on to talk upgrade testing in 30 mins?
<thumper> so, yes, consistence
<babbageclunk> balloons: yup yup
<balloons> brillant, ty
<thumper> ok, I'm about to head off, back after lunch
<babbageclunk> gah, thumper - can I quickly get your opinion?
<babbageclunk> or wallyworld, since he really is away?
<babbageclunk> wallyworld: re exclude list for audit logging it occurred to me that we don't want empty conversations (where the requests and responses are all for uninteresting API methods) clogging up the log.
<babbageclunk> so what I'm planning on doing is buffering up the conversation (with any uninteresting API requests/responses) in the recorder until we see an interesting request, at which point the buffered conversation and req/resps will also be written. Does that sound sensible or crazy?
<babbageclunk> anyway, I'll talk to you about it at the end of the meeting.
<wallyworld> babbageclunk: did you want to  talk now?
<babbageclunk> wallyworld: sorry give me 5?
<wallyworld> sure
<babbageclunk> wallyworld: ok now's good
<babbageclunk> in 1:1?
<wallyworld> ok
<wallyworld> babbageclunk: lgtm with a suggestion
<babbageclunk> wallyworld: thanks!
<wallyworld> babbageclunk: i'm having trouble joining hte call
#juju-dev 2017-12-15
<wallyworld> babbageclunk: here's that small migration fix https://github.com/juju/juju/pull/8227
<babbageclunk> wallyworld: looking now
<wallyworld> \o/
<babbageclunk> wallyworld: approved
<wallyworld> babbageclunk: tyvm
 * thumper is traditionally terrible at changing nicks back
<thumper> https://github.com/juju/juju/pull/8228 anyone
<wallyworld> thumper: looking
<wallyworld> babbageclunk: one more really small one https://github.com/juju/juju/pull/8229
<wallyworld> thumper: what happens when we exclude a principal app with no units?
<babbageclunk> wallyworld: sorry, went for a run and forgot to mention - looking now
<wallyworld> no worries
<babbageclunk> wallyworld: lgtm'd
<wallyworld> yay
<wallyworld> ty
<thumper> wallyworld: it won't get the constraints for it, and if there are some defined in the bundle it will try and set them again
<thumper> nothing bad, just extra work
<thumper> but at least it works
<wallyworld> thumper: but if there are none elsewhere in the bundle, we could actually miss out on using constraints right?
<thumper> no
<thumper> wallyworld: if the app isn't in the bundle, it doesn't matter
<thumper> if the app is in the bundle but has no constraints, there is nothing to do
<thumper> if the app is in the bundle but has constraints, it will try to set them
<thumper> worst case, we set the constraints to what they are already
<wallyworld> ok
<wallyworld> i'm not overly familiar with the logic
<wallyworld> i'll take your word it wil be ok :-)
<thumper> it'll be ok
<wallyworld> thumper: lgtm
<thumper> wallyworld: another very small onehttps://github.com/juju/juju/pull/8231/files
<wallyworld> ok
<thumper> wallyworld: another very small one https://github.com/juju/juju/pull/8231/files
<thumper> we can talk through the testing, or lack of it, if you like
<thumper> the only way rog reproduced it was to hack the API calls
<wallyworld> thumper: i think maybe at least a warning? tp pick up any typos or whatever
<wallyworld> or at least tellpeople something is being ignored or might be amiss
<wallyworld> but keep working
<thumper> wallyworld: any warnings would be on the server, not the client
<thumper> so they wouldn't see it anyway
<wallyworld> ok
<wallyworld> babbageclunk: sorry, another small one https://github.com/juju/description/pull/33
<babbageclunk> wallyworld: I'll accept it as penance for booting you
<babbageclunk> wallyworld: Approved
<wallyworld> babbageclunk: yay, ty
<wallyworld> babbageclunk: last one for the year! I promise :-) https://github.com/juju/juju/pull/8232
<babbageclunk> wallyworld: yay, nice one! Done!
<wallyworld> tyvm
<wgrant> Huh, what is an application password?
<wallyworld> wgrant: same as a unit and machine password
<wgrant> Oh is this for CAAS?
<wallyworld> used to authenticate api connections for that entity
<wallyworld> yeah
<wgrant> Since in IAAS an app never auths
<wgrant> Right makes sense
<wgrant> Thanks
<wallyworld> np
<wallyworld> wgrant: if you are interested i can share a "what can it do as of now" doc with you
<wgrant> wallyworld: Ooh, enough works now that such a doc exists?
<wallyworld> wgrant: you can deloy and scale and expose a charm :-)
<wallyworld> and configure it
<wallyworld> with k8s specific settings for service/ingress as well as charm workload ones
<wallyworld> wgrant: shared with you. next major bit of work is to support relations. that will happen next year as today is my last for the year
<wgrant> wallyworld: Nice, thanks. Good progress :)
<wgrant> Have a good break!
<wallyworld> will try, you too
<balloons> wpk, you about?
<wpk> balloons: yep
<wpk> balloons: sup?
<balloons> wpk, hey, did you get a chance to look at that pr i sent along?
<balloons> wpk, specifically, we aren't sure about how subnets should be created
<balloons> hml, are you about?
<hml> balloons: here
