#juju-dev 2012-05-14
<TheMue> morning
<fwereade> heya TheMue
<TheMue> Hi fwereade, had a good flight back?
<fwereade> TheMue, not bad, thanks; and yourself?
<TheMue> This time I've been able to sleep a lot a the flight back. That helped. Today it's almost normal, but I think I'll get tired early today.
<TheMue> But those safety controls suck, had three this time. Will next time try to have a different flight with only one stop.
<fwereade> TheMue, heh, I totally haven't adjusted, I started at 4am this morning ;p
<TheMue> Uuuh, a bit early.
<wrtp> fwereade, TheMue: morning!
<wrtp> (just)
 * wrtp just slept for 14 hours straight.
<TheMue> wrtp: Yo' man.
<TheMue> wrtp: Hehe, fwereade started 4am this morning.
<Aram> moin.
<wrtp> Aram: hiya
<wrtp> TheMue: i think he probably had *some* sleep the night before :-)
<TheMue> wrtp: I slept a lot during flight and so slept from 11pm to 7am this morning. We'll see when I get tired again.
<TheMue> Aram: Moin.
<wrtp> TheMue: i didn't sleep at all in the flight. managed to do a little translator into a packet filter language, but didn't actually get it working quite.
<TheMue> wrtp: I've yesterday not been able to concentrate on anything.
<wrtp> TheMue: i came up with the neatest use for defer that i've yet found.
<fwereade> heya wrtp
<wrtp> fwereade: how's tricks?
<fwereade> wrtp, not too bad, my body still thinks it's in the wrong place
<wrtp> fwereade: not sure how my technique of almost no sleep for days beforehand and then lots of sleep now will work for body-clock adjustment. experiment still in progress!
<Aram> wrtp: what use of defer did you find?
<fwereade> wrtp, not really sleeping on the flight and going to bed slightly early really didn't work at all for me
<wrtp> Aram: some code for generating virtual machine instructions. until you've generated the instructions, you don't know the destination for forward jumps. i use defer to do the late patching for me. here's some of the code (see the emit function) http://paste.ubuntu.com/986981/
<Aram> ah yes, this seems a really great use case.
<wrtp> Aram: it won't work if i start generating jump instructions inside subroutines though.
<Aram> heh, yes, still.
<TheMue> lunchtime
<wrtp> TheMue: you're running ubuntu in a VM, right?
<wrtp> oh, darn, too late
<wrtp> i discovered i could crash my machine with one echo statement
<wrtp> echo /dev/*/tun*
<wrtp> don't try it unless you don't care about an instant kernel panic
<Aram> interesting.
<TheMue> Hmm, strange, losing connection very often today.
<niemeyer> Hello everybody!
<niemeyer> Welcome back home to those that were at UDS. :)
<Aram> hi.
<fwereade> niemeyer, heyhey
<niemeyer> Hey folks
<fwereade> niemeyer, how's it going?
<niemeyer> fwereade: Wonderfully
<fwereade> niemeyer, awesomd :D
<niemeyer> fwereade: Good trip home, all worked out nicely, had a great rest, and glad to be back in action now too :)
<fwereade> niemeyer, jolly good :)
<fwereade> niemeyer, I'm a touch messed up on my sleep still so it'll be my EOD very soon
<fwereade> niemeyer, I was going to take a quick look at the review queue first and gently remind you that I'm waiting for 4 of my own when yu get a moment ;)
<niemeyer> fwereade: Thanks for the reminder
<niemeyer> fwereade: My day is a bit messed up by pending stuff too, but I definitely have all those reviews close to the top of my list
<fwereade> niemeyer, cool
<fwereade> niemeyer, btw, I was wondering what your thoughts were on caching stuff in the local provider
<niemeyer> fwereade: Hmm
<niemeyer> fwereade: How do you mena?
<niemeyer> mean
<fwereade> niemeyer, I have the impression you're -1 on released binaries; does this imply the same for charm-store charms?
<niemeyer> fwereade: Sorry, I'm a bit out of context
<niemeyer> fwereade: What was I -1 about again?
<fwereade> niemeyer, putting the jujud etc binaries into provider storage when they're the released versions that can be got from a canonical place
<fwereade> niemeyer, this is secondhand, perhaps via wrtp; I may have misunderstood
<niemeyer> fwereade: Ah, yeah, I think it was partially misunderstood in one of the hops
<fwereade> niemeyer, my own heart says that we should stick everything in provider storage and always get it from the same place (with likely-to-be-lower bandwidth costs)
<fwereade> niemeyer, the disadvantage is that if we do it naively we round-trip through the user's machine
<niemeyer> fwereade: My original idea around that was to indeed allow uploading released binaries, but only when --upload-tools is used
<wrtp> niemeyer: the question was whether we should always copy the juju tools binaries into local provider storage AFAIR
<wrtp> niemeyer: hi BTW!
<niemeyer> wrtp: Heya!
<niemeyer> wrtp: Ah, yes, for that my vote is -1..
<wrtp> niemeyer: thought so
<wrtp> niemeyer: so why aren't charms the same?
<fwereade> niemeyer, ok, the followup: does that imply that charm-store charms should also not be copied into provider storage?
<fwereade> niemeyer, we've always done it so far; but that may just be an artifact of not having had a charm store until very recently
<niemeyer> fwereade: It's a great question
<niemeyer> fwereade: and I suspect we may end up with similar answers for both
<niemeyer> fwereade: which look unlike what we have right now in both cases
<fwereade> niemeyer, yeah, it feels like fundamentally the same question
<niemeyer> fwereade: The issues is this:
<niemeyer> fwereade: Downloading several MB from S3 to stick back onto S3 sounds quite silly
<niemeyer> fwereade: Even more considering we may have to download several different versions, depending on which constrains we're satisfying
<niemeyer> fwereade: There's also the issue that the environment stands on itself
<niemeyer> fwereade: We may not be around by the time the environment decides to fire a machine for which we didn't yet upload the respective binaries
<niemeyer> fwereade: I think the ultimate goal would be to indeed cache binaries locally onto the environment, but have it so that the *environment* is able to do that by itself
<niemeyer> fwereade: and this sounds like a sane approach both for the toolset and for the charms
<niemeyer> fwereade: In edge cases, such as with --upload-tools, we'll continue to upload though
<fwereade> niemeyer, cool, avoiding the round-trip sounds like a good thing to me
<fwereade> niemeyer, the question becomes relevant because I'm looking at juju deploy and thinking I have no reason to download cs: charms at all
<fwereade> niemeyer, because I can get the SHA256 and the bundle URL from the store anyway
<niemeyer> fwereade: Right, that's indeed the original intention
<niemeyer> fwereade: We didn't do that because it was cheap
<niemeyer> fwereade: (to just continue to do the same)
<fwereade> niemeyer, ok, great, I'll do what's definitely needed for cs: charms to begin with, and defer the caching for now
<niemeyer> fwereade: Sounds good
<niemeyer> mthaddon: ping
<wrtp> niemeyer, fwereade, TheMue: i'm going to take the afternoon off as half swap day, if that's ok.
<niemeyer> wrtp: Absolutely
<fwereade> wrtp, fine by me
<TheMue> wrtp: Understandable.
<wrtp> thanks. i'll see y'all tomorrow!
<niemeyer> wrtp: Have a good one
<niemeyer> fwereade, TheMue: Please feel free to do the same and take some good rest today.. we need fresh brains! 8)
<fwereade> niemeyer, I'm still confused what time it is; woke up fresh as a daisy at 3 and started at 4, so I consider my day kinda over already ;)
<fwereade> niemeyer, I'm just picking up what easy reviews I can now
<niemeyer> fwereade: Woah
<niemeyer> fwereade: Indeed.. this has the sound of a great afternoon nap
<fwereade> niemeyer, yeah, I'm feeling it a bit now
<TheMue> niemeyer: I'm currently fixing a local mail prob. Afterwards I want at least to finish the tests after the latest refactorings William and I discussed last week.
<TheMue> niemeyer: But I'll be offline from Wednesday to Sunday.
<niemeyer> TheMue: Super
<TheMue> niemeyer: The changes for relations and endpoints really feel better. More simple.
 * TheMue this morning discovered that there's a plugin for his editor to directly jump into Godoc/GoPkgDoc.
<niemeyer> TheMue: Sweet
<niemeyer> TheMue: I tend to use the web page.. I really like the formatting and all
<TheMue> niemeyer: Yes, so do I. And this plugin tells Firefox to open a browser tab there.
<Aram> I guess in acme one might come up with a plumbing rule that invokes either go doc or the browser.
<Aram> might try it at some point.
<niemeyer> TheMue: Yeah, I imagined this was the case since GoPkgDoc only works in a web browser
<niemeyer> Aram: Indeed
<TheMue> niemeyer: A nice HTML rendering in an editor tab would be fine too. But that doesn't work.
<niemeyer> andrewsmedina: Heya
<andrewsmedina> niemeyer: everything ok?
<niemeyer> andrewsmedina: Yeah, all good
<niemeyer> andrewsmedina: Back at home after two intense weeks
<fsouza> hi
<niemeyer> fsouza: Hey! Bye!
<niemeyer> fsouza: Heya
<niemeyer> Lunch time here
<niemeyer> Back in ~1h
<niemeyer> mthaddon: ping
<niemeyer> Stepping out for a doc appointment.. back later
 * niemeyer respawns
 * davechen1y waves
<niemeyer> davechen1y: Heya
<niemeyer> davechen1y: Will pick Ale up.. back in a few minutes
<davecheney> protip: bzr remove-branch doens't do what I it did
<davecheney> afk: breakfast
#juju-dev 2012-05-15
<niemeyer> davecheney: :-)
<niemeyer> davecheney: Are you using cobzr?
<niemeyer> davecheney: It may help
<niemeyer> davecheney: It's really boring to use GOPATH without it
<niemeyer> Alright, calling a day I am
<niemeyer> Have a good night/day all
<davecheney> niemeyer: yes, alias bzr=cobzr
<davecheney> will cobzr close (ie, remove from my local branch list) branches that have been submitted ?
<TheMue> morning
 * davecheney waves
 * TheMue waves back
<davecheney> i heard tell there is a pastebin for canonical
<davecheney> the public one
<TheMue> davArrived in the right timezone? ;)
<davecheney> yesterday was not pretty
<TheMue> davecheney: Yes
<davecheney> walked around like a zombie til 5pm
<davecheney> then gave in to the inevitable
<TheMue> http://paste.ubuntu.com/
<davecheney> TheMue: http://paste.ubuntu.com/988455/
<TheMue> davecheney: Funnily this time I had almost no problems. But I slept a lot during flight.
<davecheney> what do you think of that?
<davecheney> the logic is, watch /environment
<davecheney> get the *ConfigNode, pass config.Map() to this function, receive Environ
<TheMue> davecheney: Loks straight.
<TheMue> Looks
 * davecheney shakes his fist at the interface{}'s being passed around everywhere
<davecheney> well, mainly inside environs/config.go
<TheMue> davecheney: Hehe, indeed, anonymous interfaces are always some kind of double-edged.
<davecheney> dummy.Open expect a schema.MapType, but ec2,Open expects a *providerConfig
<davecheney> I can't see a way to reconcile the two
<davecheney> apart from changing environProvider.ConfigCheck() to coerce everything to a map[string]interface{}
<davecheney> ohh, it's actually worse than that
<TheMue> davecheney: I hope Roger is around soon. This is his playground.
<davecheney> OK: 6 passed
<davecheney> i got it to pass, but it is really ugly
<TheMue> davecheney: Now that it's working it's time to make it elegant. ;)
<davecheney> in the face of interface{}, little can be done
<davecheney> but I think I pushed some of the nastyness out of sight
<davecheney> TheMue: https://codereview.appspot.com/6215045
<davecheney> just checking it over before i send it out
<davecheney> halo rog
<davecheney> i'm just finishing up
<davecheney> check out https://codereview.appspot.com/6215045
<rog> davecheney: hi there
<rog> davecheney: am very bleary!
<davecheney> took far too long (read most the day)
<davecheney> to produce that
 * rog looks
<davecheney> but hopefully it's a faithful representation of what we discussed last week
<rog> davecheney: cool.
<rog> davecheney: what time of day is it for you?
<davecheney> 18:06
<davecheney> so i'd better go and make the dinner
<davecheney> and tackle the mountain of washing up that sam left for me
<TheMue> rog: Heya
<rog> davecheney: ok :-)
<rog> TheMue: mornin'
<TheMue> davecheney: You got my comment. Mostly looks good.
<rog> davecheney: i thought we were going to use Setter/Getter or something like that
<davecheney> Open can't take a getter, the value of attributes is provider specific
<davecheney> it spent most the day bashing my head on that
<davecheney> ok, going afk for a few hours at least
<rog> davecheney: ok, have fun.
<rog> davecheney: washing up, yeah!
<rog> davecheney: BTW i was suggesting to pass a Getter to Check, not Open.
<TheMue> rog: Too late. (lol)
<TheMue> rog: Seen on the log that you yesterday asked for running Ubuntu in a VM.
<rog> TheMue: yeah
<rog> TheMue: was just wondering if my crash scenario was specific to me only...
<TheMue> rog: Oh, tell me more.
<rog> TheMue: ok, if you don't mind your VM crashing, try this: echo /dev/*/tun*
<TheMue> rog: Maybe later on a copy. ;) So you play around with the tunneling?
<rog> TheMue: yeah, but i couldn't get it working, and i don't know why.
<rog> TheMue: that was on the plane.
<TheMue> rog: That can't work.
<rog> TheMue: what can't work?
<TheMue> rog: Tunnels are below earth, not 10.000 feet above. (scnr)
<rog> :-)
<TheMue> rog: But what did you expect by echoing directly on the devices?
<rog> TheMue: i expected it to tell me what files were in /dev
<rog> TheMue: i ended up posting a stackoverflow question: http://stackoverflow.com/questions/10583601/how-should-the-tunattachfilter-ioctl-be-called
<TheMue> rog: Never used echo for it, only ls.
<rog> TheMue: you'd get the same behaviour if you passed the same argument to ls
<rog> TheMue: echo is nice because it prints all the names on one line
<TheMue> rog: attributes in config are always a map[string]interface{}? I already wondered about the usage of interface{} here.
<rog> TheMue: they only happen to be a map[string]interface{} if the yaml is written correctly.
<TheMue> rog: So I would define a type Attributes map[string]interface{} with setter/getter and Check(*EnvironChecker) (or something like that).
<rog> actually....
<rog> i think they're usually map[interface{}
<rog> ] interface{}
<rog> TheMue: don't you like my Getter/Setter idea?
<TheMue> rog: Could live with that too, even if it's very generic.
<TheMue> rog: Get and Set on Checker?
<rog> TheMue: the idea is that you should be able to pass a *ConfigNode to EnvironProvider.Check
<rog> TheMue: you saw my comment, right?
<TheMue> rog: Only a quick look so far.
<rog> TheMue: https://codereview.appspot.com/6215045/diff/13/environs/open.go#newcode36
<TheMue> rog: So your idea is to pass anything where you can "get" a value by key from as an input to the checker? Am I right?
<rog> TheMue: yes
<TheMue> rog: Sounds good.
<rog> TheMue: and it also works the other way around
<TheMue> rog: Yes
<rog> TheMue: an environ config can be saved directly to a config node
<TheMue> rog: So if it later will be something else and not the config node it's no problem.
<rog> TheMue: yes
<TheMue> +1
<rog> cool
<TheMue> rog: Got this one http://shop.canonical.com/product_info.php?products_id=708 at UDS. Now here in the cold and wet Germany it's really useful.
<rog> TheMue: doesn't look like it'll keep out the rain much :-)
<TheMue> rog: No, but it keeps warm. Thankfully there's no rain inside my house. ;) And it's dry enough for the way to the car.
<rog> :-)
<fwereade> TheMue, rog: I *did* sleep well last night but I'm feeling the aggregate effect of too many weird days... taking a swap day today
<rog> fwereade: ok, good plan
<rog> fwereade: enjoy the day!
<TheMue> fwereade: OK, enjoy it.
<fwereade> rog, cheers :)
<fwereade> TheMue, cheers also :)
<TheMue> ;)
<niemeyer> Heya!
<TheMue> niemeyer: Heya.
<niemeyer> TheMue: How're things?
<TheMue> niemeyer: Fine, just working on relations. And you?
<rogpeppe> niemeyer: yo!
<niemeyer> TheMue: I'm waking up after a rough night where the jetlag ruled out, and getting on some reviewing
<niemeyer> rogpeppe: Heya!
<TheMue> niemeyer: Yeah, adjusting the inner clock back is hard. And you've been there almost two weeks.
<Aram> I have a 26 hour biological clock, it's terrible.
<rogpeppe> niemeyer: https://codereview.appspot.com/6145043/ is feeling a bit neglected :-)
<niemeyer> rogpeppe: The whole queue is feeling neglected
<rogpeppe> niemeyer: i think that might be one of the older items...
<niemeyer> rogpeppe: I'm sure some of them are older than the others :)
<niemeyer> rogpeppe: My day will be pretty much just reviews today
<niemeyer> Except for lunch and a meeting I have in about 1h
<niemeyer> rogpeppe: Will do a quick pass on this one now.. hopefully we can get it in now
<rogpeppe> niemeyer: thanks!
<niemeyer> rogpeppe: version.ToolsPath makes no sense to me
<rogpeppe> niemeyer: where do you think it should go?
<rogpeppe> niemeyer: i was duplicating it all over the place
<niemeyer> rogpeppe: If anywhere, this should live within environs.ToolsPath
<rogpeppe> niemeyer: that could make sense. let me check.
<niemeyer> rogpeppe: Although, maybe it should be a function instead, and let the implementation details off
<niemeyer> rogpeppe: environs.GetTools(env)
<niemeyer> Aram: Ouch :)
<rogpeppe> niemeyer: i'm not sure that's right
<rogpeppe> niemeyer: the tools path is independent of the provider
<rogpeppe> niemeyer: i think
<rogpeppe> niemeyer: otherwise we've documented the interface to PutFile wrong.
<niemeyer> rogpeppe: Not sure I see what you mean.. environs is not environment-specific either
<rogpeppe> niemeyer: ah, so you'd have environs.PutTools too?
<Aram> niemeyer: yeah, basically only once every 13 days I wake up when I should. All the other days I feel jet lagged. I compensate with caffeine, heh.
<Aram> maybe that makes it worse.
<niemeyer> rogpeppe: Don't we have that already?
<rogpeppe> niemeyer: UploadTools, yeah.
<rogpeppe> niemeyer: but without ToolsPath, it's difficult to test that the correct file has been written, because we don't know its name.
<niemeyer> Aram: I bet it does indeed :)
<niemeyer> rogpeppe: We only have to know its name once, in a single test
<niemeyer> rogpeppe: If UploadTools works as it should, everything is else may rely on that
<niemeyer> rogpeppe: We can test that DownloadTools (?) gets the same content that UploadTools supposedly uploaded, for example
<niemeyer> rogpeppe: We don't have to test the path for that
<rogpeppe> niemeyer: i'm still not happy about cmd_test.go knowing about the underlying path name.
<niemeyer> rogpeppe: I just pointed out that it doesn't have to..?
<niemeyer> rogpeppe: I'm happy with PutTools and GetTools as well, btw
<niemeyer> rogpeppe: Probably more sensible for GetFile/PutFile
<rogpeppe> niemeyer: yeah, i tend to agree
<rogpeppe> niemeyer: even though the flag is called --upload-tools
<rogpeppe> maybe it might be better named --put-tools in fact
<niemeyer> rogpeppe: Yeah, that's fine.. the language on the command line has to be more sensible for the user instead
<niemeyer> rogpeppe: --upload-tools feels more clear in that sense
<rogpeppe> niemeyer: ok
<rogpeppe> niemeyer: ok, i'll see how it goes without ToolsPath
<niemeyer> rogpeppe: Thanks.. I'll be here for about 20 mins more before lunch
<rogpeppe> niemeyer: one thought: nothing is ever going to use GetTools except tests.
<rogpeppe> niemeyer: hmm, update will, i suppose.
<niemeyer> rogpeppe: Curious.. I wonder what's the purpose of uploading a file we never download :-)
<rogpeppe> niemeyer: we use wget and tar...
<niemeyer> rogpeppe: That's done for bootstrap only
<rogpeppe> niemeyer: when else do we download tools?
<rogpeppe> niemeyer: update will, i think, so i think it seems ok to me.
<niemeyer> rogpeppe: Yep
<niemeyer> rogpeppe: Whenever we have Go code running that wants to download tools
<niemeyer> rogpeppe: Updating has to do that
<rogpeppe> niemeyer: yeah
<rogpeppe> niemeyer: i'll still need to verify against tar xz though
<niemeyer> rogpeppe: Yeah, once, though
<rogpeppe> oh darn
<rogpeppe> niemeyer: GetTools won't work without support for ListFiles in Environ
<rogpeppe> niemeyer: and even that's not quite there, as we've got a two-tier system.
<niemeyer> rogpeppe: I don't understand how we can have ToolsPath in version and can't have a function instead
<rogpeppe> niemeyer: because GetTools doesn't get a particular version - it searches for the latest appropriate version.
<niemeyer> rogpeppe: So ToolsPath is equally bogus
<rogpeppe> niemeyer: ToolsPath gives the path for the *current* tools. that's why i put it in version.
<niemeyer> rogpeppe: Ugh.. that's not great
<niemeyer> rogpeppe: Let's have ListFiles in the environment then, and have GetTools
<rogpeppe> niemeyer: we'll need two ListFiles-type functions (or one with a bool arg) because we need to be able to look in private storage first before failing over to public storage.
<rogpeppe> niemeyer: perhaps ListFiles(private bool) ([]string, error)
<niemeyer> rogpeppe: That sounds like yet another great reason to have GetTools.. this is unrelated to ListFiles in the environment
<rogpeppe> niemeyer: really?
<rogpeppe> niemeyer: which bucket would ListFiles list?
<niemeyer> rogpeppe: Well, maybe it could be.. thinking
<niemeyer> rogpeppe: ListFiles should list the files in the environment
<niemeyer> rogpeppe: That has a very well defined meaning
<rogpeppe> niemeyer: so how do we list the files in the public bucket so we can use publicly uploaded tools?
<niemeyer> rogpeppe: Which is in theory unrelated to anything about how-do-I-get-public-tools
<niemeyer> rogpeppe: That's a good question for which we need a good answer.. it doesn't invalidate the former point, though
<rogpeppe> niemeyer:  the environment knows about both, so i'd put that logic into the environment. if it's not in the environment, then we need some way of extracting info about the public bucket from it
<rogpeppe> s/i'd/i/
<niemeyer> rogpeppe: Please explain "the environment knows about both"
<rogpeppe> niemeyer: the names for both the private and public buckets are stored in environments.yaml
<rogpeppe> niemeyer: and they're environment-specific
<niemeyer> rogpeppe: You're putting statements as if they were true as you go, but it feels to me like the implementation of these details is actually still undefined
<rogpeppe> niemeyer: ok. i'm happy to refactor.
<niemeyer> rogpeppe: It is not true that the public files are environment-specific, for instance
<rogpeppe> niemeyer: i'm not sure how we'd specify mutable storage in a provider-independent way though.
<niemeyer> rogpeppe: All the environments for a given provider, or even for multiple providers, may share files
<rogpeppe> niemeyer: oh, is the list-bucket functionality provider-independent?
<niemeyer> rogpeppe: It is also not necessarily true that they are stored in environments.yaml either
<niemeyer> rogpeppe: Since we'll have defaults
<niemeyer> rogpeppe: It may be.. and it doesn't even have to be a bucket, for example
<rogpeppe> niemeyer: what we need is some generic "container-like" functionality, i think
<rogpeppe> niemeyer: if we want to go in this direction
<niemeyer> rogpeppe: I think we can actually have an interface that defines a public-files thingy (name to be defined), and have a HTTP(S) consumer implementation for that
<niemeyer> rogpeppe: I *suspect* we can use that single implementation with every provider we know about so far
 * rogpeppe doesn't know about anything other than s3
<niemeyer> rogpeppe: Then, we can have a env.PublicFilesThingy() or similar
<niemeyer> rogpeppe: Which in pretty much all cases does
<rogpeppe> niemeyer: and PrivateFilesThing() ?
<niemeyer> rogpeppe: I suspect the env itself is a PrivateFilesThing
<rogpeppe> ew
<rogpeppe> niemeyer: that seems a little icky
<rogpeppe> niemeyer: i'm not sure why PublicFiles and PrivateFiles wouldn't be symmetrical
<niemeyer> rogpeppe: env.PublicFilesThingy() will return TheBasicHTTPPublicFilesThingy(defaultURL or configURL) for pretty much all providers
<niemeyer> rogpeppe: Because they are not in real life.. the environment manages storage of its own files.. the public files is managed by someone else
<niemeyer> rogpeppe: There's nothing icky about that to me
<niemeyer> rogpeppe: Although, I'm fine to have PrivateFilesThingy if you prefer that
<rogpeppe> niemeyer: i'll think about it.
<niemeyer> rogpeppe: It sounds sane to me as well
<rogpeppe> Environ.Files vs Environ.PublicFiles ?
<rogpeppe> niemeyer: then the file interface can be simply be: interface {Put(...) error; Get(...) error; List( ...) ([]string, error)}
<rogpeppe> niemeyer: because we won't need to disambiguate
<niemeyer> rogpeppe: I'm happy with that.. feels very clean
<rogpeppe> niemeyer: i'll see how it looks
<niemeyer> rogpeppe: Happy with PrivateFilesThing too
<niemeyer> rogpeppe: Btw, we need a name :)
<niemeyer> rogpeppe: I'll have lunch, and try to come up with some suggestions
<rogpeppe> niemeyer: Storage?
<rogpeppe> niemeyer: ok, enjoy
<rogpeppe> !
<niemeyer> rogpeppe: Sounds great
 * niemeyer => lunch
 * niemeyer_ is back
<niemeyer_> rogpeppe: How does it feel?
<rogpeppe> niemeyer_: it's looking quite nice
<rogpeppe> niemeyer_: http://paste.ubuntu.com/989159/
<rogpeppe> niemeyer_: it feels like another piece of the puzzle has dropped into place
<rogpeppe> niemeyer_: what do you think?
 * niemeyer_ reads
<niemeyer_> rogpeppe: Looks very good indeed
<niemeyer_> rogpeppe: A couple of suggestions:
<rogpeppe> niemeyer_: cool.
<niemeyer_> rogpeppe: Let's not get into the S3 prefix madness
<niemeyer_> rogpeppe: Let's call it a dir
<rogpeppe> niemeyer_: ok. i started with that.
<rogpeppe> niemeyer_: but it's hard to do proper dirs with s3
<niemeyer_> rogpeppe: I thougth it was trivial?
<rogpeppe> niemeyer_: List(prefix="e", separator="/") will return "elephant" AFAIR
<rogpeppe> (if "elephant" exists, of course)
<niemeyer_> rogpeppe: What will "e/" return?
<rogpeppe> niemeyer_: good point - just always append a /
<niemeyer_> rogpeppe: The only reason to not do that would be efficiency I guess
<niemeyer_> rogpeppe: In the sense we could list precisely what we want, if possible
<niemeyer_> rogpeppe: This might be enough of a reason to implement the prefix-based stuff
<rogpeppe> niemeyer_: if we know precisely what we want, then why are we doing a LIST?
<niemeyer_> rogpeppe: "foo-*
<rogpeppe> niemeyer_: i don't think we should worry.
<rogpeppe> niemeyer_: we're not going to have *that* many versions.
<rogpeppe> niemeyer_: and if we do, we can partition the dirs
<niemeyer_> rogpeppe: It may be useful to avoid returning 100s of tools from the public storage, actually
<niemeyer_> rogpeppe: tools-<major>.*
<rogpeppe> niemeyer_: in which case, why not make tools-<major> a directory?
<rogpeppe> niemeyer_: as you said, the S3 prefix stuff is madness
<niemeyer_> rogpeppe: Well, we can make it saner.. we'd not support varied separators, or distinguish common prefixes in separate lists
<rogpeppe> niemeyer_: not quite whether to go for "/" or "" as the root directory.
<rogpeppe> niemeyer_: i don't see the need for the abstraction - you've persuaded me. prefix might not be as easy to implement in other providers
<rogpeppe> niemeyer_: directories are sufficient
<niemeyer_> rogpeppe: I can't see how that would possibly be the case
<rogpeppe> niemeyer_: if the provider actually uses a directory-like structure, prefix matching will be harder to do efficiently.
<rogpeppe> niemeyer_: (we'd need to do it client-side)
<niemeyer_> rogpeppe: Anywhere we can list a directory, we can filter it out with three lines (for+if+append)
<rogpeppe> niemeyer_: exactly. but then we'll be getting the inefficiency we're trying to remove by using the prefix abstraction.
<rogpeppe> niemeyer_: and using a directory will be the same efficiency in both cases.
<niemeyer_> rogpeppe: We'll be getting the inefficiency you're suggesting we'd have all the time
<niemeyer_> rogpeppe: Yes, the same *inefficiency* in both cases..
<rogpeppe> niemeyer_: not if we store tools as tools-$MAJOR/$MINOR-$PATCH.tgz
<niemeyer_> rogpeppe: Which means filtering it out by hand, client side, in both cases..
<niemeyer_> rogpeppe: Not sure about what you're arguing for, to be honest
<rogpeppe> the above
<rogpeppe> niemeyer_: note the "/" between major and minor versions
<rogpeppe> niemeyer_: then we can just List("tools-$MAJOR")
<niemeyer_> rogpeppe: Ok, but this naming isn't great
<rogpeppe> niemeyer_: no?
<niemeyer_> rogpeppe: "tools/$MAJOR/tools-$MAJOR.$MINOR.$PATCH.tar.gz" then
<rogpeppe> niemeyer_: why does it need to have the same pattern on the provider as on disk?
<niemeyer_> rogpeppe: Because I don't want to wget 1.2.tar.gz
<rogpeppe> wget tools/2/1.2.tgz seems ok to me.
<niemeyer_> rogpeppe: Sorry, 1.2.tar.gz isn't a proper file name
<rogpeppe> niemeyer_: but anyway, all this is premature optimisation - we can change it all later trivially.
<rogpeppe> niemeyer_: i think we've shown that we don't need prefix matching to do this efficiently
<rogpeppe> niemeyer_: and i'm ok with the redundant major version too
<rogpeppe> niemeyer_: by the time we've got hundreds of versions, we'll have upgrade and we can change the schema on the fly :-)
<niemeyer_> rogpeppe: No, let's do it now please.. the need is obvious, the implementation trivial
<niemeyer_> rogpeppe: You can pick either.. tools/tools-$MAJOR.$MINOR.PATCH.tar.gz + prefix <OR> tools/$MAJOR/tools-$MAJOR.$MINOR.$PATCH.tar.gz + dir
<rogpeppe> niemeyer_: ok.
<rogpeppe> niemeyer_: i vote for the latter.
<niemeyer_> rogpeppe: Cool, let's go with it then
<rogpeppe> niemeyer_: any other suggestions?
<rogpeppe> right, off for the day. see y'all tomorrow.
<niemeyer> What the heck
<niemeyer> Google+ Hangout has f* up my connection permanently..
<niemeyer> I had to reboot and reconnect the router..
<niemeyer> I wonder if the Hangout servers are DoSing me somehow
<Daviey> I wonder if he had the 'DoS me' option enabled in Advance pref's?
<ahasenack> hi guys, niemeyer tells me his internet is down for good
<ahasenack> hazmat, jimbaker, others: ^^^
<hazmat> ahasenack, thanks for relaying
<ahasenack> hazmat: 3g is also down, not just adsl, so it must be something more serious in that region
<hazmat> indeed, that's uncommon
<jimbaker> interesting
<niemeyer> Okay
<niemeyer> Something funky is happening with the local ISPs
<niemeyer> Managed to get in via 3G now
<ahasenack> maybe everybody is playing diablo 3 ;)
<niemeyer> ahasenack: That might explain it
<TheMue> niemeyer: Who may be interested in a possible bug in relation.py in the current implementation?
<niemeyer> TheMue: Ben, Jim, or Kapil
<niemeyer> TheMue: Everybody would be *interested* though, but one of them will have to look at the code
<TheMue> niemeyer: I'm not sure if it's a bug, but I think it's worth a look.
<TheMue> jimbaker: Still around?
<hazmat> TheMue, what's up?
<TheMue> hazmat: Ah, heya.
<TheMue> hazmat: Please take a look at relation.py at line 91.
<hazmat> TheMue, yeah.. thats suspect its only checking one endpoint
<TheMue> hazmat: I think service_id has to be service_relation.internal_service_id().
<TheMue> hazmat: Yep, that's what I thought. Especially inside the loop.
<hazmat> TheMue, it should be service_relation.service_id
<hazmat> er. internal_service_id
<TheMue> hazmat: The service id is stored in _service_id. So you have to use the accessor.
<TheMue> hazmat: Yeah
<jimbaker> TheMue, still around, but looks like hazmat has got you covered
<TheMue> jimbaker: Heya. Yes, hes has. ;) Thx.
<hazmat> bzr blame suggests otherwise ;-)
<hazmat> jimbaker, trivial http://paste.ubuntu.com/989322/
<jimbaker> hazmat, looks like a check to ensure we are not seeing inconsistent topology. iirc this was a bug fix to fix looping tests
<hazmat> jimbaker, it looks it was part of the initial impl
<hazmat> jimbaker, updated trivial w/ test http://paste.ubuntu.com/989333/
<hazmat> jimbaker, okay.. given lack of objections.. adding to trunk.. the failure without the change is InternalTopo..Error instead of StateChanged
<jimbaker> hazmat, ok, got context - it just looked like all the other checks we have added to avoid InternalTopologyError, so along the same lines
<jimbaker> hazmat, +1
<hazmat> thanks TheMue
<niemeyer> rogpeppe: ping
<TheMue> hazmat: np, happy to help
<niemeyer> mthaddon: ping
<TheMue> So, I'm off. Good night.
 * hazmat meanders off for food
<flaviamissi> do you guys have any intention of implementing an api for juju?
<hazmat> flaviamissi, definitely
<hazmat> flaviamissi, there's a very rough draft extant in http://bazaar.launchpad.net/~hazmat/juju/rest-api-spec/files/head:/source/drafts/
<flaviamissi> hazmat: great! it would be very useful, I'll take a look at it, maybe I can help on that
<hazmat> flaviamissi, great, comments welcome, its basically in three parts, a REST api, an HTTP command api corresponding to the CLI, and websocket notification mechanism.
<flaviamissi> hazmat: yeah, I'm reading the spec now, is anyone working on that?
<hazmat> flaviamissi, there's an experimental branch that someone through together, but its probably not going in as is. there's some drive to have this done for 12.10 to support other activities though.
<hazmat> flaviamissi, the experiment is attached to https://bugs.launchpad.net/juju/+bug/804284
<flaviamissi> hazmat: great, thank you
<hazmat> flaviamissi, that's a client side rest api though..
<hazmat> ie. its not deployed as part of juju
<flaviamissi> hazmat: hmm... but this is the intention? I mean, the api won't be deployed as part of juju?
<hazmat> flaviamissi, yes that's the goal.. like i said that branch is experimental.. its not clear its the basis for an official rest api yet
<flaviamissi> hazmat: ok
<flaviamissi> hazmat: that's for the python version, right?
<hazmat> flaviamissi, it is
<hazmat> flaviamissi, at this point feedback on the spec would be the most helpful, ie. making sure we're covering appropriate use cases and functionality
<flaviamissi> hazmat: I can do that
<hazmat> negronjl, where would you want to take jrapi?
<davecheney> 'sup 'sup
<negronjl> hazmat:  what do you mean ?
<negronjl> hazmat:  If it serves a purpose, let's use it.  If anyone comes up with something better, we can use that ...
<negronjl> hazmat: but, until something better shows up, I am playing with jrapi
<hazmat> negronjl, sure, but trying to figure out where it goes from here.. ie do we evolve it add tests, match it to spec and try to merge it, or do we end up with a separate official project that gets merged.
<flaviamissi> hazmat: the spec looks really good, looks like all cases are covered, but I'll take another look later
<niemeyer> flaviamissi: There was some mixup there..
<niemeyer> <flaviamissi> hazmat: hmm... but this is the intention? I mean, the api won't be deployed as part of juju?
<niemeyer> <hazmat> flaviamissi, yes that's the goal.. like i said that branch is experimental.. its not clear its the basis for an official rest api yet
<niemeyer> flaviamissi: hazmat intended to say that, yes the goal is to have the API deployed as part of juju
<flaviamissi> niemeyer:  hmmm
<flaviamissi> niemeyer: that makes more sense to me :)
<niemeyer> flaviamissi: It's one of the next major features that will come
<niemeyer> flaviamissi: After the port is done
<flaviamissi> niemeyer: so, the plan is not have the api for the python version?
<niemeyer> flaviamissi: Yes, Python is in maintenance mode, and we're working on getting the port done in time for 12.10
<flaviamissi> niemeyer: great
<flaviamissi> I'm leaving, we chat more later
 * niemeyer => dinner too
<hazmat> niemeyer, doh.. yeah.. totally it should be deployed as part of juju
<hazmat> that was unclear
<hazmat> async response communication  fail
<negronjl> hazmat:  Can you make the spec available to me?
<negronjl> hazmat:  I'm up for using this API of course but, the final decision on that I believe it to be yours
<hazmat> negronjl, its publicly pushed to docs and editable by charmers
<hazmat> negronjl, http://bazaar.launchpad.net/~hazmat/juju/rest-api-spec/files/head:/source/drafts/
<negronjl> hazmat:  I'm up for modifying/merging jrapi
<hazmat> negronjl, testing would be key
<negronjl> hazmat:  I agree on testing... I can start adding some testing to the project as well... Let me take a moment to read the spec in full...
<hazmat> negronjl, i am as well.. realistically this month i don't have much spare time,  i'd like to get the spec approved and rolling though before then.
<negronjl> hazmat:  ok.  Not sure what the next step on this is .... Has the spec been approved by the powers that be ?
<hazmat> negronjl, no.. its in decent shape, but needs some polish
<hazmat> and some parts need to be flushed out a lot more
<hazmat> like auth
<negronjl> hazmat: I see.  Well.  I want to take some time to read the specs.  This will give me more information to come up with more intelligent questions.
<negronjl> hazmat: I can get back to you with some feedback tomorrow.  Does that work for you ?
<hazmat> negronjl, sounds good
<SpamapS> jimbaker: can you please reference bug numbers on all commits to trunk!
<SpamapS> jimbaker: I need a bug report for every change or we cannot SRU to 12.04.1
<SpamapS> jimbaker: trivials included, though r536 actually doesn't look trivial *at all*
<hazmat> SpamapS, its like 5 lines
<SpamapS> its not about the size
<SpamapS> I need to understand why its ok to update the stable release with it.
<hazmat> SpamapS, its nothing something thats needed in practice, it still raises an error in either csae
<hazmat> just cleans up the error to something intended for the user instead of an internal error
<SpamapS> we have to justify every change
<SpamapS> so, Low priority change, that was not on the galapagos list
<SpamapS> I think I need to fork a 12.04.1 branch and only pull in High bug fixes
<hazmat> SpamapS, indeed it came out of of a porting comment
<hazmat> from frank while looking at the relation code
<SpamapS> I'm going to be pushing 535 into precise-proposed tomorrow
<hazmat> SpamapS, i can back it out.. if need be
<hazmat> just put it on the unfettered branch
<SpamapS> Then we have to verify all 4 bugs fixed then it goes to precise-updates.
<SpamapS> I plan to keep trickling in the galapagos bugs as they're comitted
<SpamapS> hazmat: if it has a reasonable test case, impact statement, and regression potential is Low, then we can leave it
<SpamapS> just document it with a bug
<hazmat> all those things are true
 * hazmat adds a bugs
<SpamapS> yeah I figure as much. Just have no way of knowing that w/o a bug #
<SpamapS> We can go nuts w/ commits again after June 6, but for just this month.. lets fix bugs. :)
<SpamapS> hazmat: I want to get acls in. Can we do that without breaking the world?
<SpamapS> crap its 45 minutes later than I wanted to EOD today.. :-P
<hazmat> SpamapS, define breaking the world ;-)
<hazmat> hmmm
<hazmat> SpamapS, actually we could
<hazmat> SpamapS,  its done at the connection level, so we can detect support and activate it without too much trouble.
<hazmat> just switch the security policy from acl to the noop
<SpamapS> hazmat: I think all we need to do is make the secret arg to the agents optional
<hazmat> ah... mixed mode envs
<SpamapS> hazmat: existing bootstrapped envs will just work w/o acls
<hazmat> newer client with older env isn't too bad
<hazmat> newer agent with older env could work
<SpamapS> and we'll make a note that if you upgrade the provisioning agent, you have to re-bootstrap or something
<hazmat> it would apply generically to all of them
<hazmat> er... all agents
<SpamapS> I don't want to support mixed mode
<SpamapS> I just want to make sure existing bootstrapped envs with juju-origin: distro can continue to add-unit and deploy
<hazmat> well then we need the upgrade/consistent version stuff that rog is doing on the go version
<hazmat> SpamapS, that is mixed mode
<SpamapS> um, ok
#juju-dev 2012-05-16
<hazmat> SpamapS, the versions vary across the env
<hazmat> sorry poor naming choice
<SpamapS> versions of juju, but as long as provisioning agent doesn't pass a zk secret.. you just wouldn't have a zk secret, right?
<hazmat> mixed mode == multiple versions extant in the env
<SpamapS> sure ok I don't care what you call it, I just want it to work :)
<hazmat> SpamapS, yup.. no otp identity token, nothing to do
<SpamapS> Its the only thing I really think we have to get into 12.04.1
<SpamapS> everything else we can pull people to PPA I think
<hazmat> SpamapS, my timeline is  bit stretched
<SpamapS> if we merged it now
<SpamapS> would it just break all add-units ?
<hazmat> SpamapS, its not done, i still need to propogate identities to all the agents
<hazmat> SpamapS, so with the move to august for 12.04.1 what's the date for last merge
 * SpamapS makes the FAIL face
<hazmat> you wanted 6 weeks
<SpamapS> oh dude
<SpamapS> I don't care about *actual* 12.04.1
<SpamapS> June 6 man. I don't want to hold onto trunk like this for 3 months
<SpamapS> If we can't get it in, we can't get it in.
<SpamapS> c'est la vie.
<hazmat> actually i take that back, there is a branch that does the agent identity thing
<hazmat> SpamapS, let's just branch then
<hazmat> SpamapS, you want 9 weeks of no changes ?
<hazmat> for 12.04.1?
<SpamapS> No stress. I just think, priority wise, thats the only one that really needs to get back to the conservative "hey whats this thing juju" users that will use it from the distro.
<hazmat> june 6th isn't going to happen, i'm fully booked till june 14th
<SpamapS> hazmat: alright, then we won't ship stuff to those users.
<hazmat> i'd have to pull a resource to make other stuff move
<SpamapS> or we'll branch a stable branch.
<SpamapS> Don't stress, thats the key.
<SpamapS> It happens, or it doesn't, but no heroic efforts are needed.
<hazmat> SpamapS, too late.... my post uds bliss has passed
<SpamapS> hazmat: thats why we have deadlines
<SpamapS> so we *don't* have to stress
<SpamapS> immovable deadlines even
<hazmat> SpamapS, that works when you only have one deadline maybe, but when you have four concurrently, its a bit different
<SpamapS> thats why stuff needs to be done *before* feature freeze
<SpamapS> even in universe/unsupported .. we shouldn't target to go nuts the last week of the cycle.
<SpamapS> hazmat: meh, it still works. You have a deadline, you know how much time you have available for this one project. Its not enough.. resource starvation communicated. No stress.
<hazmat> ack
<SpamapS> And I can set expectations for the precise-updates version appropriately as well.
<SpamapS> I think instead I'll just try and make an 'unstable' PPA on June 6, and make sure there's some way to get juju-origin to use it.
<SpamapS> then we can just freeze ppa:juju/ppa onto the galapgos release, which I hope we can call 0.5.1, and then just start building trunk into ppa:juju/unstable and let users know they should get on that one if they want the new stuff from honolulu
<hazmat> SpamapS, so 12.04.1 got moved back a month, why doesn't our deadline move with it?
<hazmat> amusing.. https://bugs.launchpad.net/edubuntu/+bug/1000000
<jimbaker> yes, a nice variant on https://bugs.launchpad.net/ubuntu/+bug/1
<SpamapS> hazmat: because I want trunk to open up for features
<hazmat> SpamapS, then let's cut a precise branch, but that should still change june 6th to july 6th
<SpamapS> hazmat: we can just make the precise packaging branch the precise branch :)
<SpamapS> hazmat: in fact, with the Low priority stuff thats been landing in galapagos, I think I may give up on trying to ship "galapagos" into precise-updates
<SpamapS> hazmat: the idea was extreme discipline so we could adhere to SRU policy. That has basically gone out the window.
<hazmat> SpamapS, i think we have different notions of extreme.. anyways.. the question to me at the moment is what in the current set of revs doesn't meet that notion, we can revert, cut the branch, and reapply to trunk
<SpamapS> hazmat: Well the SRU policy is pretty clear that only high impact bugs will be SRU'd
<SpamapS> hazmat: so, cosmetic fixes are generally rejected, and with the heavy testing requirement, are kind of a waste of time.
<hazmat> SpamapS, but things aren't tested in isolation?
<SpamapS> hazmat: plus we have to extract each and every one into its own quilt patch so SRU team can review each change. It just becomes a lot of red tape and b.s. for cosmetic fixes.
<hazmat> SpamapS, this also applies to universe?
<hazmat> or that thing formerly known as
<hazmat> hm
<SpamapS> hazmat: yes, the only difference is that with universe, the community is expected to do the fixes (which, since we're juju devs.. we are considered the community)
<hazmat> amusing
<SpamapS> the policy is identical, just the expectation of response is different.
<hazmat> SpamapS, so outside of 536, i could probably a valid case for each of the other 4 commits
<hazmat> SpamapS, also we need the output formating fix that bcsaller is working on wrt to not having python stringification of values
<hazmat> ie. one more
<SpamapS> hazmat: we also have the problem of not being able to test from -proposed easily. ;)
<hazmat> yeah.. i got lost in the weeds trying to make local use cloud-image so i didnt have to implement that twice
<hazmat>  lp:~hazmat/juju/proposed-support ;-)
<SpamapS> so many branches
<SpamapS> so little time :)
<SpamapS> hazmat: I'm willing to do all the test verification on even the Low priority bugs .. as long as the SRU team is willing to review the uploads.
<SpamapS> hazmat: I figure if we ship 3 - 5 in an upload every 2 weeks the SRU team should be ok with that.
<hazmat> SpamapS, any reason not to go ahead and cut the precise branch now
<SpamapS> hazmat: we have.. its at lp:ubuntu/juju
<SpamapS> actually lp:ubuntu/precise/juju ;)
<hazmat> gotcha
<hazmat> cool
<SpamapS> hazmat: so I'll just manage the flow of things from lp:juju -> lp:ubuntu/precise/juju :)
<SpamapS> hazmat: and you guys can keep doing trivials as long as they don't cause me any conflicts. :)
<davecheney> rogpeppe: you in the house ?
<fwereade> davecheney, heyhey
<fwereade> davecheney, instance id is not the same as machine id; machine id is juju-internal but instance id is provider-supplied
<fwereade> davecheney, the providers don't have any reason I'm aware of to know about the details of juju state, so I don't think they should know about instance ids
<fwereade> davecheney, gaah, providers should not know about *machine* ids
<fwereade> davecheney, they should deal purely with *instance* ids
<fwereade> davecheney, the machine state should contain the corresponding instance id which you can use to shut down the machine
<rogpeppe> mornin' to anyone who's around...
<Aram> hi there.
<rogpeppe> Aram: if you don't type my irc alias, i don't see your remark!
<Aram> :).
<rogpeppe> lunch
<niemeyer> Hello!
<niemeyer> I suspect my Thinkpad's battery has just died on me
<niemeyer> Quick reboot..
<rogpeppe> niemeyer: hiya
<niemeyer> rogpeppe: Heya
<niemeyer> Looks like battery is no more indeed
<rogpeppe> niemeyer: bummer
<rogpeppe> niemeyer: about List: i've gone with directories, but said that it should return the entire (recursive) contents of the directory. that means you can find out the entire contents of a bucket without explicitly recurring.
<niemeyer> rogpeppe: Ok
<niemeyer> rogpeppe: Where do I get a replacement bat in the UK?
<rogpeppe> niemeyer: also, you said you had a couple of suggestions around that paste. do you remember another?
<rogpeppe> niemeyer: in the UK i'd order it on the internet
<rogpeppe> niemeyer: why UK?
<niemeyer> rogpeppe: ROTFL.. *really*!? You'd use the *internet*!
<niemeyer> :-)
<rogpeppe> niemeyer: i can't be more specific - i'd froogle it.
<niemeyer> rogpeppe: Yeah, got it.. I just had a good laugh :)
<niemeyer> rogpeppe: I may be going there in a couple of weeks
<rogpeppe> niemeyer: cool. whereabouts?
<niemeyer> rogpeppe: London
<niemeyer> rogpeppe: There's a sprint being planned and I was invited to help out as possible
<rogpeppe> niemeyer: would it be helpful if i sourced a battery for you?
<niemeyer> rogpeppe: Not sure.. if I can find a good spot to buy it, I might just send it to the office.
<niemeyer> rogpeppe: I'd appreciate your help in case the place doesn't take international credit cards, though
<rogpeppe> niemeyer: sounds like a good plan. that also sounds like a possibility.
<niemeyer> rogpeppe: I'll have a look later at Amazon UK to see if I can find anything
<rogpeppe> niemeyer: usually they do, but you might find the exchange rate isn't great.
<niemeyer> For now, just put my battery in the fridge for it to relax for a moment
<niemeyer> rogpeppe: The exchange rate with credit cards is controlled by the government.. they're forced to use the official rates
<rogpeppe> chill out that battery man
<niemeyer> rogpeppe: I'll just have to pay 6% extra of tax, unfortunately
<rogpeppe> niemeyer: really? i never knew that.
<rogpeppe> niemeyer: on top of our 20% VAT?
<niemeyer> rogpeppe: Yeah.. financial operations tax in Brazil
<niemeyer> rogpeppe: To discourage people from buying stuff abroad, is my guess
<niemeyer> rogpeppe: Silly
<rogpeppe> niemeyer: sounds like you *do* want me to buy it for you :-)
<niemeyer> rogpeppe: Hehe, thanks, but don't worry for now..
<rogpeppe> niemeyer: just let me know if you need it
<niemeyer> This is the second time this happens to me, btw
<niemeyer> Last Thinkpad I had, the exact same happened
<niemeyer> Looks like Lenovo has issues with batteries
<Aram> what model is this thinkpad?
<niemeyer> Aram: T410
<Aram> I have one as well.
<Aram> curious that you had problems, I never had battery problems with any thinkpad.
<Aram> had a lot of problems with dells and hps though
<niemeyer> Aram: It's the second time
<niemeyer> Aram: Last one died in the same way
<Aram> strange.
<niemeyer> Aram: Maybe I use it too much? :)
<niemeyer> rogpeppe: My current battery costs Â£164.16 at Lenovo (!!)
<rogpeppe> niemeyer: yeah, they're way expensive.
<rogpeppe> niemeyer: i was looking at getting a spare recently.
<niemeyer> It's almost the price of a whole laptop these days
<rogpeppe> niemeyer: you can get an OEM battery
<rogpeppe> niemeyer: but who knows how good it'll be...
<niemeyer> Oh, found the same one on Amazon uk for Â£84.56
<rogpeppe> niemeyer: that's cool. link?
<niemeyer> I wonder how long it's been in stock though.. that's always an issue with batteries
<niemeyer> rogpeppe: http://www.amazon.co.uk/Lenovo-ThinkPad-Battery-55-battery/dp/B003FXQ3ZK/ref=sr_1_1?ie=UTF8&qid=1337177298&sr=8-1
<rogpeppe> niemeyer: given that they're the cheapest supplier, maybe they'll be clearing stock quickly...
<rogpeppe> niemeyer: interesting to see how much of a markup lenovo direct has though.
<niemeyer> rogpeppe: Yeah.. even if the cheap one lasts half as long, it's still ok :)
<rogpeppe> niemeyer: some bizarre behaviour from gnu tar: http://paste.ubuntu.com/990736/
<niemeyer> Reading
<rogpeppe> niemeyer: i can work around it with tar xzf /dev/fd/0, but....
<niemeyer> rogpeppe: Weird indeed
<rogpeppe> niemeyer: ah! i've found the problem.
<niemeyer> rogpeppe: Oh?
<rogpeppe> niemeyer: i had a bogus version of tar in my path
<rogpeppe> niemeyer: it's a pity our tests will fail if someone has an odd environment. but i don't want to hard-code /usr/bin/tar ...
<rogpeppe> pwd
<niemeyer> rogpeppe: Yeah, this is fine IMO
<niemeyer> rogpeppe: All kinds of crazy things can happen if you has a buggy env
<niemeyer> s/you/one
<niemeyer> rogpeppe: Btw, the battery death reminded me that I started the mgo zk in the trip to Brazil
<niemeyer> rogpeppe: Looking really nice so far
<rogpeppe> niemeyer: it's a bit weird really, because one of the original advantages of unix is that you can customise your commands.
<niemeyer> rogpeppe: Next time I have a moment I'll start on watches
<rogpeppe> niemeyer: cool. have you proof-of-concept-ed the watchers?
<rogpeppe> oh, ok
<niemeyer> rogpeppe: Not yet, but I have a pretty good idea about how to implement them now
<niemeyer> rogpeppe: I started the research on the trip
<niemeyer> rogpeppe: It's quite racy, so has to be carefully thought out
<rogpeppe> niemeyer: yeah. it's a critical component.
<niemeyer> rogpeppe: I'm planning to use the internal replication mechanism to do it.. I *think* it'll end up quite nice
<Aram> maybe we should do like the web guys that try to detect browser capability and serve custom pages depending on that, that way we could support user customized environments :P.
 * Aram hides.
<rogpeppe> niemeyer: it'll be interesting to see how the benchmarks (network bandwidth & latency particularly) work out
<niemeyer> rogpeppe: Quite optimistic on that regard
<rogpeppe> Aram: ./configure :-)
<niemeyer> rogpeppe: Don't be silly.. we should start with autoconf.sh
<rogpeppe> niemeyer: good to hear
<rogpeppe> niemeyer: of course!
<rogpeppe> not
<niemeyer> :-)
<niemeyer> autoconf.sh => configure => make.. it's crazy how people end up finding that normal
<rogpeppe> the whole notion of probing a system to find out what kind of thing it is is bogus
<Aram> yeah, that worked so well for cross compiling :).
<rogpeppe> tbh, i wouldn't mind setting PATH=/bin:/usr/bin
<Aram> that's what I do most of the time in my scripts.
<rogpeppe> Aram: it's a reasonably sane approach.
<rogpeppe> niemeyer: question: do you think List should return the full path names of the files, or the pathnames with the dir prefix stripped off?
<rogpeppe> niemeyer: i'm starting to question how much effort i want to put in to make S3 buckets look like directories.
<rogpeppe> niemeyer: maybe we *should* just use a prefix model
<niemeyer> rogpeppe: I'm happy with that too
<rogpeppe> niemeyer: i think i'll go with that for the time being as the path of least resistance.
<niemeyer> rogpeppe: Full path names sounds simpler
<rogpeppe> niemeyer: then we don't have to worry about the impedance mismatch. and we can revisit the decision later if we need to.
<niemeyer> rogpeppe: Yeah
<niemeyer> rogpeppe: Btw, I'm thinking we'll end up having some kind of manifest file for the generic HTTP public provider
<niemeyer> rogpeppe: This will also make that simpler
<rogpeppe> niemeyer: no need to use the Separator stuff either.
<niemeyer> rogpeppe: Definitely
<rogpeppe> niemeyer: the manifest file should be auto-generated, otherwise we've got a problem with two clients uploading tools concurrently.
<niemeyer> rogpeppe: This is about the public storage
<niemeyer> rogpeppe: For the private storage we should be able to list our stuff
<niemeyer> rogpeppe: Which will be guaranteed, given we're hopefully moving towards a internal storage mechanism
<rogpeppe> niemeyer: ok, that seems reasonable. the interface can be the same in both cases (StorageReader)
<niemeyer> rogpeppe: RIght
 * rogpeppe quite likes the StorageReader/StorageWriter distinction.
<niemeyer> rogpeppe: Btw, I was going to suggest this before my ISP broke yesterday: StorageReadWriter may be spelled as Storage only
<niemeyer> rogpeppe: StorageReader, StorageWriter, and Storage
<rogpeppe> niemeyer: that works
<rogpeppe> +1
<niemeyer> Supa'
<niemeyer> :)
<niemeyer> Ok, it's lunch time here
<niemeyer> Back soon.. reviews on the afternoon today
<rogpeppe> niemeyer: enjoy
<Aram> niemeyer: why does your battery stats indicate 0 for the cycle count?
<Aram> s/does/do/
<niemeyer> Aram: Probably side effect of death
<rogpeppe> niemeyer: https://codereview.appspot.com/6145043
<rogpeppe> niemeyer: slightly worried that the branch is too big now and i'll need to spend some more hours splitting it up... :-|
<rogpeppe> niemeyer: i'm going to have to go soon
<niemeyer> rogpeppe: I'll have a careful look
<rogpeppe> niemeyer: just replied to https://codereview.appspot.com/6215045/ . it would probably be good to have a chat about this tomorrow.
<niemeyer> rogpeppe: Sure
<niemeyer> rogpeppe: There's a leap in your description that I can't follow
<niemeyer> rogpeppe: "by making Environ.Check operate directly on a map[string]interface{}, we make that possible."
<niemeyer> rogpeppe: Nothing has to change in the way CheckConfig works to make that possible
<rogpeppe> niemeyer: how do we merge the attributes generated when marshalling an environment with the other attributes held in the environment settings node?
<rogpeppe> niemeyer: (i don't have to go immediately, BTW)
 * rogpeppe is trying to recall all the discussion points that came up with fwereade and dfc at the time.
<niemeyer> rogpeppe: Hm
<niemeyer> rogpeppe: I don't understand hte problem
<niemeyer> rogpeppe: Check isn't about merging
<niemeyer> rogpeppe: ConfigCheck is about validation and coercion
<rogpeppe> niemeyer: Check has to parse the attributes that are created with Marshal (or whatever it would be called)
<rogpeppe> niemeyer: so it helps if the two things read and write the same structure
<niemeyer> rogpeppe: That's fine.. there's still no reason to change the function signature
<rogpeppe> niemeyer: i don't see how it can work. what if Marshal returns a single int?
<niemeyer> rogpeppe: I still don't get what problem you're trying to solve, sorry.. ConfigCheck returns a schema checker, which checks the schema by validating and coercing to the proper types in case it is valid
<niemeyer> rogpeppe: What is Marshal?
<niemeyer> rogpeppe: What problem are we trying to solve?
<rogpeppe> niemeyer: ok, so...
<rogpeppe> niemeyer: when we bootstrap, we need to ask the environment to save some of itself to the State.
<rogpeppe> niemeyer: or at least that needs to happen at some point
<niemeyer> Yep
<niemeyer> I'm with you
<rogpeppe> niemeyer: so the question is: how does that happen? and once we've got the settings inside the State, how do we create an Environ from them?
<niemeyer> rogpeppe: We create an environment by retrieving the ConfigNode for the environment configuration, and providing the Map() onto a new environment via Open.
<niemeyer> rogpeppe: Another Option is to provide the ConfigNode itself onto Open, and change Open's signature to take a Getter, for example.
<niemeyer> rogpeppe: Neither of those options require any changes to ConfigChecker
<rogpeppe> niemeyer: that doesn't work - Open expects a nicely formatted structure that has been produced through Check.
<niemeyer> rogpeppe: No, it doesn't.. there's no Check today, and neither of us mentioned anything about it so far
<rogpeppe> niemeyer: ok, i'm proposing to rename Coerce to Check.
<niemeyer> rogpeppe: Yes, I can see *that* :-)
<niemeyer> rogpeppe: But you didn't mention why, and I can't see any reason to
<rogpeppe> niemeyer: but the point is: all the preconditions are checked there. if we start passing attributes directly to Open, then the checks will have to go there too.
<niemeyer> rogpeppe: One thing isn't related to the other in any way..
<niemeyer> rogpeppe: If you pass a Getter into Open, there's no guarantee it's right either
<rogpeppe> niemeyer: i wasn't proposing to pass a Getter into Open
<rogpeppe> niemeyer: i was proposing to pass a Getter into *Check*
<niemeyer> rogpeppe: Yeah, you're proposing something else, and I'm trying to guess why
<rogpeppe> niemeyer: then Check can do all the checks it does right now.
<niemeyer> rogpeppe: Yes, you were proposing that, but you didn't say why, and I can't see any reason to do that in the explanation above
<niemeyer> rogpeppe: We seem to be a bit stuck on the lack of reasoning around htat
<rogpeppe> niemeyer: it depends if you think the current division of labour works well or not
<niemeyer> rogpeppe: It works very well today, and nothing I can see above seems to change that
<rogpeppe> niemeyer: currently the Coerce method checks that all the fields are there and have sane values
<rogpeppe> niemeyer: if we start passing unchecked values to Open, then that checking will have to move into Open.
<niemeyer> rogpeppe: The values we pass today onto Open are checked. Renaming a method doesn't solve anything.
<rogpeppe> [18:39:22] <niemeyer> rogpeppe: We create an environment by retrieving the ConfigNode for the environment configuration, and providing the Map() onto a new environment via Open.
<niemeyer> rogpeppe: Yes!?
<rogpeppe> niemeyer: so in that case, where is the checking done?
<niemeyer> rogpeppe: I *really* hope we're not saving an invalid configuration onto the state!?
<rogpeppe> niemeyer: who knows? we need to check it.
<niemeyer> rogpeppe: No, sorry.. this is a broken design
<rogpeppe> niemeyer: also, currently Check saves everything into a nice private structure.
<niemeyer> rogpeppe: If you want to valid the state, it should be on its way in, not on its way out
<rogpeppe> niemeyer: state is external.
<rogpeppe> niemeyer: we might have got the version checking wrong
<rogpeppe> niemeyer: we don't want to do unchecked type conversions.
<niemeyer> rogpeppe: Besides that, validating the state would mean passing the result of Map() onto exactly the same validation & coercion function
<niemeyer> rogpeppe: Which goes back onto the point that there's unjustified fuzz around that method
<rogpeppe> niemeyer: i don't find it fuzzy. the Coerce and Open methods have a close relationship, but it's well defined.
<niemeyer> rogpeppe: Yep. It's well define, works, and it's all good. You're suggesting we change the method name and signature and introduce an interface, because...? I don't know.
<rogpeppe> niemeyer: i'm proposing passing the ConfigNode, in some form, to Coerce.
<niemeyer> rogpeppe: Because...?
<rogpeppe> niemeyer: so that Coerce can do exactly the same checking that it does when it gets stuff from environments.yaml
<rogpeppe> niemeyer: with no code needing to be changed.
<niemeyer> rogpeppe: ConfigCheck can do exactly that, today, with no changes to its signature, and no new interfaces.
<rogpeppe> niemeyer: ConfigCheck?
<rogpeppe> niemeyer: ConfigChecker, oh yes
<rogpeppe> niemeyer: so what happens the other way around?
<rogpeppe> niemeyer: i.e. how do we do the marshalling?
<niemeyer> rogpeppe: the other way around we return.. :-)
<rogpeppe> niemeyer: do we require that Marshal always return a map[string]interface{} ?
<niemeyer> rogpeppe: env.Config() map[string]interface{} seems easy enough
<rogpeppe> niemeyer: ok, so if we return map[string]interface{}, can't we guarantee that Coerce is called with that same type?
<rogpeppe> niemeyer: and reflect that in the type signature
<niemeyer> rogpeppe: That sounds fine to me.. I believe it's already called with that type today, right?
<niemeyer> rogpeppe: We just don't enforce it by passing it via an interface{}
<niemeyer> rogpeppe: But we could, and it sounds sane to do it
<rogpeppe> niemeyer: to change the type signature?
<niemeyer> rogpeppe: To be explicit that what we're passing in today is a map.. it's already a map
<rogpeppe> niemeyer: explicit to the compiler, or just to document it?
<niemeyer> rogpeppe: Explicit to the compiler..
<rogpeppe> niemeyer: ok. so... what we've ended up with there is *almost* the same as what i was proposing.
<rogpeppe> niemeyer: the only difference being that if we use Getter and Setter we can pass in the ConfigNode directly.
<niemeyer> rogpeppe: That's my point the whole time.. you're proposing a change that isn't necessary, because what we have already works
<rogpeppe> niemeyer: fair enough. it saves some code doing to map copying, but we can use map[string]interface{} throughout if we like.
<rogpeppe> s/doing to/doing the/
<niemeyer> rogpeppe: I don't think it saves any code.. the current scheme needs *less* code, actually
<rogpeppe> niemeyer: (what's being passed to Coerce currently isn't actually map[string]interface{} BTW)
<niemeyer> rogpeppe: Because we work natively with maps on both ends
<rogpeppe> niemeyer: really?
<rogpeppe> niemeyer: one side we've got map[interface{}]interface{}; the other we've got *ConfigNode
<rogpeppe> (which already has Get and Set methods)
<niemeyer> rogpeppe: What's below ConfigNode?
<niemeyer> rogpeppe: What does ConfigNode.Map return?
<niemeyer> rogpeppe: It's a map on both ends, really
<niemeyer> rogpeppe: The fact it's a map[interface{}] is also irrelevant.. we'll never have non-strings on that first level
<niemeyer> 1: WOAH!?
<rogpeppe> niemeyer: it's not type-compatible with map[string], so we'll have to copy it to pass it in
<niemeyer> :)
<niemeyer> rogpeppe: Why can't we just have map[string]?
<rogpeppe> niemeyer: because that's not what goyaml.Unmarshal returns.... or maybe we could make it...
<niemeyer> rogpeppe: Coerce..
 * rogpeppe has a look
<rogpeppe> niemeyer: maybe ReadEnvironsBytes could unmarshal into map[string]map[string]interface{}
<niemeyer> rogpeppe: Coerce is what has to manage it
<rogpeppe> niemeyer: not necessarily, i think
 * niemeyer waits for the light bulb to show up
<rogpeppe> niemeyer: the problem currently is that ReadEnvironsBytes produces a map[interface{}]interface{} which is then passed to Coerce
<rogpeppe> niemeyer: but i *think* we can unmarshal into map[string]interface{} at the top level and save the Coerce checking
<rogpeppe> niemeyer: (of course Coerce would still need to check other things, but we could make its signature map[string] and avoid the map copying.
<rogpeppe> )
<niemeyer> rogpeppe: We can't..
<rogpeppe> niemeyer: oh. no?
<niemeyer> rogpeppe: Coerce validates the values, and transforms them onto expected types
<rogpeppe> niemeyer: go on
<niemeyer> That's it..
<rogpeppe> niemeyer: what if the signature of Coerce was Coerce(map[string]interface{}) (interface{}, error) ?
<niemeyer> rogpeppe: It would still not help.. coerce coerces
<rogpeppe> niemeyer: i.e. that Coerce took the exact output of Marshal as input
<rogpeppe> niemeyer: that's fine.
<niemeyer> Ok then :)
<niemeyer> I'll stop arguing and let you read the code
<rogpeppe> niemeyer: ok, so i'm ok with using map[string]interface{} throughout rather than Getter/Setter, i think.
<niemeyer> rogpeppe: Sounds great, thanks
<rogpeppe> niemeyer: hmm, might not work very well with the schema package, which uses map[interface{}]interface{} throughout.
<niemeyer> I see a light bulb starting to show up :-)
<rogpeppe> niemeyer: i'm not convinced we gain much from using the schema package tbh
<niemeyer> rogpeppe: Let's not throw the baby out with the bath please.. we have to walk forward
<rogpeppe> niemeyer: it's higher-order code, but just a few type checks would be equivalent.
<niemeyer> rogpeppe: There's zero reason to do by hand what the schema package does elegantly
<niemeyer> rogpeppe: It's ready, works
<niemeyer> rogpeppe: I believe FieldMap can return a map[string]interface{}, though
<rogpeppe> niemeyer: nope.
<niemeyer> rogpeppe: FieldMap is supposed to work with strings already.. we can enforce it in its return value I believe
<rogpeppe> niemeyer: hence my v.(schema.MapType) conversion
<niemeyer> rogpeppe: Don't know what you mean
<rogpeppe> niemeyer: in fieldMapC.Coerce: 	out := make(MapType, l)
<niemeyer> rogpeppe: can != does today
<rogpeppe> niemeyer: that would make for a very different schema package. (one that i'd like to see, i agree, but not the one we have today, which outputs a small set of known types, rather than coercing to a specified type)
<niemeyer> rogpeppe: Do you want me to code on that *very* different schema package?
<niemeyer> rogpeppe: I bet the patch is less than 10 lines long
<rogpeppe> niemeyer: all we're using schema for currently is the equivalent of: x, ok := m["field"].(string)
<niemeyer> rogpeppe: and consists of removals
<niemeyer> and a couple of replacements
<rogpeppe> niemeyer: really?
 * niemeyer writes it
<rogpeppe> niemeyer: but still, we've got all this higher-order machinery, but we're not using any of it in any particularly useful way.
<niemeyer> rogpeppe: We are, it works, today, let's *please* move on!
<niemeyer> rogpeppe: I really don't want to be moving backwards and doing checks by hand when we have that nice mechanism in place already
<rogpeppe> niemeyer: it's because it was making it awkward that i was considering avoiding its use. changing its use is about 10 minutes work.
<niemeyer> rogpeppe: I don't want to be checking whether it's int32 or int64
<niemeyer> rogpeppe: Or whether it's something else entirely
<rogpeppe> niemeyer: will we actually have any int-valued keys?
<rogpeppe> values i mean
<niemeyer> rogpeppe: No, it's impossible..
<niemeyer> :-/
<rogpeppe> niemeyer: i mean, are there any int values that we actually *want*?
<rogpeppe> niemeyer: because that's the only time that int32 vs int64 makes a difference.
<niemeyer> rogpeppe: Please try to ponder about your question for a moment
<niemeyer> rogpeppe: This is getting non-productive
<rogpeppe> niemeyer: this is the kind of thing i was thinking of. i think it compares favourably to the current code. it actually reduces the overall line count (by 30 lines) and easier to understand IMHO, because you don't need to understand how schema works to follow the logic. i'll leave things as they are, but i think ewe should at least consider this possibility.
<rogpeppe> http://paste.ubuntu.com/991155/
<rogpeppe> all tests pass BTW
<rogpeppe> s/ewe/we/
<rogpeppe> right, i really should go now.
<niemeyer> rogpeppe: How does it reduce the line count? Seems to have the same number of lines
<rogpeppe> niemeyer: sorry for the distraction
<rogpeppe> niemeyer: the line count goes down in other places (the schema helpers in ec2/util.go for example)
<niemeyer> rogpeppe: The errors are bogus, though
<rogpeppe> niemeyer: it could be more compact with a little table
<niemeyer> rogpeppe: That's one important benefit from the schema package
<rogpeppe> niemeyer: as always, i think it's a trade-off. the higher order stuff is worth it when it really makes things easier to understand and reduces the line count by lots.
<rogpeppe> niemeyer: in this case, i'm not convinced of its worth.
<niemeyer> rogpeppe: It think it's worth based on these factors
<rogpeppe> s/worth/worse/ ?
<niemeyer> rogpeppe: Yeah
<niemeyer> rogpeppe: Error checking, for example
<rogpeppe> niemeyer: all the error checking in schema is implicit - to understand the logic in config.go you have to understand the schema package (which isn't trivial)
<niemeyer> rogpeppe: https://codereview.appspot.com/6212054
<niemeyer> rogpeppe: Implicit?
<rogpeppe> niemeyer: yes, it's not obvious what inputs will result in what errors. (or even what code is calling what, due to the indirect nature of the schema.Checker)
<niemeyer> rogpeppe: Sorry, I don't get it.. bad input will result in errors
<niemeyer> rogpeppe: bad types, missing fields
<niemeyer> rogpeppe: There's nothing implicit about that
<rogpeppe> niemeyer: yes, and all that logic is defined within schema.
<niemeyer> rogpeppe: Yep!
<rogpeppe> niemeyer: which is quite complex.
<niemeyer> rogpeppe: and it seems to work
<niemeyer> rogpeppe: Not really..
<rogpeppe> niemeyer: i'm saying we can cut out all that complexity and still reduce line count.
<niemeyer> rogpeppe: It's used in ec2, in charm config, in charm meta, ...
<rogpeppe> niemeyer: ec2 is what i was suggesting losing it in...
<niemeyer> rogpeppe: Yes, and I'm pointing out you're not getting rid of schema
<niemeyer> Actually, that combined checker is excessively complex for schema..
<niemeyer> There's a lot of stuff being done by hand there..
<niemeyer>                         c.authorizedKeys = maybeString(m["authorized-keys"], "")
<niemeyer> !?
<rogpeppe> niemeyer: that's necessary, because that key may not exist
<rogpeppe> well, i suppose i could do: c.authorizedKeys, _ = m["..."]
<niemeyer> rogpeppe: And how's this any simpler:
<niemeyer> 	c.authorizedKeysPath, err = configString(false, m, "authorized-keys-path", "")
<niemeyer> ?
<rogpeppe> niemeyer: because all the logic is right there.
<niemeyer> rogpeppe: Yeah, because you're reimplementing the schema package right there.. sorry, I don't see the point
<niemeyer> http://paste.ubuntu.com/991192/
<rogpeppe> niemeyer: yeah, i agree there are arguments both ways. i think currently that making the Environs interface simpler would be a good thing (and it can still use schema inside if it wants), but i can see arguments for keeping it as it is too.
<rogpeppe> niemeyer: i really have to go :-)
<niemeyer> rogpeppe: Once we have some spare time, we can even make schema unmarshal directly onto the struct
<niemeyer> rogpeppe: That was already my plan, but I never got to it
<rogpeppe> niemeyer: +1
<rogpeppe> niemeyer: now *that* will be properly useful :-)
<niemeyer> rogpeppe: yeah..
<rogpeppe> (for all kinds of things)
<niemeyer> rogpeppe: It's already on the way to that
<rogpeppe> anyway, i have an idea.
<rogpeppe> will propose something tomorrow
<rogpeppe> if you manage to look at https://codereview.appspot.com/6145043/ that would be scrumptiolicious. :-)
<rogpeppe> see you tomorrow, have a good rest-of-day.
<rogpeppe> niemeyer: ^
<niemeyer> rogpeppe: Thanks, have a good one too
<niemeyer> Time for an afternoon food break... biab
<niemeyer> Phew.. long branch..
 * niemeyer steps out.. back later for another round
#juju-dev 2012-05-17
<davecheney> niemeyer: do you have any further comments on https://codereview.appspot.com/6215045/ ?
<niemeyer> davecheney: Heya
<niemeyer> davecheney: Good morning
<niemeyer> davecheney: I'll have a pass on your branches
<niemeyer> davecheney: Just back from dinner now
<niemeyer> davecheney: Will finish Rog's one first, though.. already half way through the massive branch
<niemeyer> davecheney: ping?
<davecheney> ack
<niemeyer> davecheney: Heya
<niemeyer> davecheney: How are you?
<davecheney> good
<davecheney> sorry, was downstairs having breakfast
<niemeyer> davecheney: No worries at all
<davecheney> i generally work from when I get up to when sam gets up
<niemeyer> davecheney: Just wanted to take the chance we're both up and kicking to chat a bit
<davecheney> sure thing
<niemeyer> davecheney: Who's Sam?
<davecheney> my partner
<davecheney> she's not a morning person
<niemeyer> davecheney: Aha, I can understand that! :)
<davecheney> so, what can I do to get those reviews cleared away
<niemeyer> davecheney: I work in the morning because I interact with the guys in the EU, but it's certainly not my most productive moment in the day
<niemeyer> davecheney: I'm just finishing that monster review for Rog.. I have yours next up
<davecheney> no worries
<niemeyer> davecheney: I think I still have spare energy to get through them
<davecheney> i'm not blocked at the moment
<niemeyer> davecheney: How've you been feeling this week with the work-at-home situation?
<davecheney> it's working well
<davecheney> i ordered a new X220
<davecheney> so when taht arrives i'll be more mobile
<davecheney> but for the moment i'm just kicking it in the spare room
<niemeyer> davecheney: Nice. Coincidently, my battery just died today, so I'm stuck in the office :)
<davecheney> so i read
<davecheney> li-ions tend to fall off a cliff
<niemeyer> Phew..
<niemeyer> davecheney: Yeah
<niemeyer> Branch reviewed
<niemeyer> That was a long oen
<davecheney> nice work
<davecheney> i understand, small branches >> large brances
<andrewsmedina> hi guys
<andrewsmedina> :D
 * davecheney waves
<niemeyer> davecheney: https://codereview.appspot.com/6215045/ has a review, and LGTM with the points addressed.
<niemeyer> andrewsmedina: Heya!
<niemeyer> andrewsmedina: juju team is 24x7 now ;)
<niemeyer> Well, 24x5 at least!
<andrewsmedina> I'm 24x7
<andrewsmedina> niemeyer: I'm working on https://codereview.appspot.com/6099051/
<niemeyer> andrewsmedina: No, I'm serious.. davecheney is in Australia.. we're going round-the-clock now :)
<davecheney> niemeyer: thanks for https://codereview.appspot.com/6215045/, i'll address those comments and submit
<andrewsmedina> I will tell you when I finish it
<niemeyer> davecheney: My pleasure, and thanks
<niemeyer> andrewsmedina: Super!
<davecheney> negronjl: re your final comment
<davecheney> I would personally find it ok if we injected the "name" attribute on the
<davecheney> environment configuration when reading it out of environments.yaml.
<davecheney> can I handle that in a later branch ?
<davecheney> i'll change the config to be a TODO
<davecheney> niemeyer: did you have a chance to consider the race with AddMachine() ?
<niemeyer> davecheney: Re. "name", yeah, definitely.. wasn't suggesting it'd be for the same branch. I suggest fixing the "TODO", though.
<niemeyer> davecheney: re. the race, which race?
<davecheney> the way state.AddMachine works currently, it's changes are visible to the MachineWatcher while the topology is inconsistent
<niemeyer> davecheney: Duh.. that kind of thing is the core reason why we have the topology
<niemeyer> davecheney: I forgot about it when reviewing. Thanks a lot for pointing that out.
<davecheney> i haven't looked into it too much, but it might be possible to fix the problem by reordering the operations inside AddMachines
<davecheney> but as it stands now, the MachineWatcher observes /machines changing, but when it calls state.Machine("the name of the key that just arrived"), it can fail because the topology has not yet changed to reflect that
<niemeyer> davecheney: The only reason we have a central monotonic topology is so that we can get atomicity in that kind of operation
<niemeyer> davecheney: I suggest a quick look at the watch_machine_states in the Python side
<davecheney> will do
<niemeyer> davecheney: If we reorder operations, we have the same problem on the opposite side
<niemeyer> davecheney: (code reading the topology explodes due to lack of nodes)
<davecheney> right
<niemeyer> davecheney: Eventually, we may have to get smarted than that to scale up to more extreme levels
<niemeyer> smarter
<niemeyer> davecheney: But then we'll need to consider races, locks, expirations, etc
<niemeyer> davecheney: The monotonic topology is a cheap way to get going for a long time without having to invest much on scenarios that re unrealistic in the near future
<davecheney> i think i haven't explain myself properly
<davecheney> i shouldn't have said the topology is inconsistent
<davecheney> more that state.Machine() races with state.AddMachine()
<niemeyer> davecheney: It doesn't
<niemeyer> davecheney: At least not any more than the fact everything always races with everything
<niemeyer> davecheney: Changing the topology is atomic.. AddMachine will add to the topology atomically, and state.Machine will read it atomically
<niemeyer> davecheney: The watcher needs to observe the topology, though, not the nodes themselves
<niemeyer> davecheney: Btw, when you "lbox submit", the latest changes in the branch are pushed to the codereview
<niemeyer> davecheney: So, unless you want to have a last look online, the propose preceding it isn't necessary
<niemeyer> davecheney: Ah, I think I've got the context for what you're talking about now, looking at your branch
<niemeyer> davecheney: Sorry for the noise
<davecheney> niemeyer: re lbox propose, yeah I do that so I have a diff of what is the final state
<davecheney> it probably don't need to do that
<niemeyer> davecheney: It doesn't bother me.. was just pointing out that submit does send the diff too
<niemeyer> (since it's not obvious)
<davecheney> niemeyer: when you say context, you're talking about the comment at the bottom of MachinesWatcher.toMachines
<niemeyer> davecheney: yeah
<niemeyer> davecheney: Was just prising the comments, coincidently
<niemeyer> davecheney: You got a LGTM on it
<davecheney> nice
<davecheney> there is a similar problem with doing state.Machine('an id which was just deleted') but for more obvious reasons
<niemeyer> davecheney: yeah
<davecheney> niemeyer: thanks for the reviews
<davecheney> I started to work on the provisioning agent proper yesterday
<davecheney> so I shold have a wip branch this evening
<niemeyer> davecheney: Woot
<davecheney> i have a plan to model the current privider (environs.Environ) as a goroutine
<davecheney> which should hide the fact that it can reload itself as the environment changes
<davecheney> without having to require a lot of retry logic
<niemeyer> davecheney: Btw, would you mind to work on a branch fixing WatchMachines?
<davecheney> sure
<davecheney> so, you would like WatchMachines to not return a *Machine unless it is properly visible in the topology ?
<niemeyer> davecheney: WatchMachines should be a content watcher, not a child watcher
<niemeyer> davecheney: and watch the topology
<niemeyer> davecheney: Otherwise it will be notifying about machines before they are visible, which will create all kinds of bugs
<niemeyer> davecheney: The Python logic already works like that for the same reason
<davecheney> ok, understood
<niemeyer> Aaand that's bad time!
<niemeyer> I mean, good time!
<niemeyer> Good time for bed! :)
<niemeyer> Have a good night all
<niemeyer> davecheney: And a good day to you, Dave
<davecheney> night mate
<hazmat> davecheney, x230s are around the corner
<hazmat> always something i suppose
<rogpeppe> davecheney: hiya
<davecheney> hi rog
<davecheney> hazmat: don't tell me that, i just dropped a gorilla on an x 220
<rogpeppe> davecheney: hey, we coincide!
<davecheney> shazam
<davecheney> so, after redoing watchmachine, i have to redo it again :)
<davecheney> oh well, at least I got two commits off my plate today
<rogpeppe> davecheney: yeah, i saw that. bummer.
<rogpeppe> davecheney: is it that it can't use the child watcher?
<davecheney> no, not directly, although i'll probably end up implenting the same logic
<davecheney> the problem witht eh child watcher is i observe new /machine keys arriving before they exist in the topology
<davecheney> gustavo says i need to watch the topology insteam
<rogpeppe> davecheney: i wonder if *anything* can legitimately use the child watcher
<davecheney> rogpeppe: i'm starting to think not
<davecheney> still, once we get the provisioning agent right, the machine and unit agents will probably be 95% the same
<rogpeppe> davecheney: interesting. i'm sure the python version watches children somewhere. but maybe it's wrong.
<rogpeppe> davecheney: machine agent is simple. the unit agent is a bit more complex as it needs the logic for determining which hook to run when (the core of juju in fact)
<davecheney> no, it watches the topology,
<rogpeppe> trunk/juju/state/relation.py:653
<rogpeppe> trunk/juju/state/relation.py:839
<rogpeppe> davecheney: so there is at least *one* place that watches children
<rogpeppe> davecheney: i can't immediately work out if it's legit though
<davecheney> will read in a sec
<rogpeppe> davecheney: BTW after discussion with gustavo last night, i have an idea for simplifying the ConfigChecker part of EnvironProvider, and making it slightly more statically typed.
<davecheney> rogpeppe: if you want to do a branch for that, i'll gladly review it
<rogpeppe> davecheney: cool. it might only be 10 minute's work. i'll have a look now.
<davecheney> rogpeppe: the part where you pass an untyped 'something' through the Checker and receive another opaque 'something' back which is specific to the Provider that checked it, doesn't make me feel wholesome
<rogpeppe> davecheney: yeah. i don't mind the second part so much, but now that we mandate that the initial "something" is actually [string]interface{}, we should reflect that in the API.
<davecheney> rogpeppe: +1
<rogpeppe> davecheney: heh, maybe it should return a func() Environ, rather than an opaque "something"
<rogpeppe> davecheney: then the state would be hidden behind a closure.
<davecheney> rogpeppe: now that would be more appropriate for Go
<rogpeppe> davecheney: i think so
<rogpeppe> davecheney: how about something like this: http://paste.ubuntu.com/991940/
<davecheney> btw, state/machine.py ~ 103 sort of does what your child watcher does
<rogpeppe> davecheney: yeah. i think when i did the child watcher i was misremembering that piece of code.
<davecheney> well, it does do what your child does, ie it takes an old set, then waits for a new set, the produces a delta of machines added and machines left
<rogpeppe> davecheney: BTW if you don't mention my IRC nick, i tend not to see your comments (it makes my machine beep...)
<rogpeppe> davecheney: exactly. i think i'd misremembered the fact that it reads topology not children.
<davecheney> rogpeppe: np, anyway, i hope the functionality exists inside the topology (haven't looked yet)
<rogpeppe> davecheney: i don't think there's a similar watcher yet.
 * davecheney fml
<rogpeppe> fml?
<davecheney> http://www.urbandictionary.com/define.php?term=FML&defid=5145198
<rogpeppe> that bad, eh?
<davecheney> no, not really
<davecheney> rogpeppe: re http://paste.ubuntu.com/991940/
<davecheney> rogpeppe: why produce a func that produces an Environ, why not produce the Environ directly ?
<rogpeppe> davecheney: because we want to be able to check all the environments in environments.yaml for correctness without instantiating them all.
<rogpeppe> davecheney: an environment is perfectly entitled to do some expensive operation when opened.
<davecheney> fair enough
<rogpeppe> davecheney: i'm liking the way it's looking so far
<davecheney> rogpeppe: yup, fair point, in that case func(Environ, error) is really just an anonymous type for EnvironProviderHolder, or something
<davecheney> but it gets the job done
<rogpeppe> davecheney: yeah.
<rogpeppe> it could return a Config type. type Config interface { Open() (Environ, error) }
<rogpeppe> but i don't mind returning a simple function.
<rogpeppe> although....
<davecheney> i'd argue for the functional approach
<rogpeppe> actually that might be nice. we've already got a config type in ec2 and elsewhere.
<rogpeppe> and we'd just need to define an Open method on it.
<rogpeppe> i could go either way
<davecheney> rogpeppe: so, Check(config map) => Config; Config.Open() => Environ ?
<rogpeppe> davecheney: yeah
<rogpeppe> davecheney: i think i prefer that actually.
<rogpeppe> s/Config/EnvironConfig/ i think
<rogpeppe> davecheney: current state: http://paste.ubuntu.com/991957/
<davecheney> rogpeppe: LGTM
<davecheney> rogpeppe: how did your networking explorations go ?
<rogpeppe> davecheney: i totally failed to set up a bpf filter (no idea why - couldn't see anything in the kernel code to indicate why i was getting EINVAL); but i've realised that i *think* i can just use the tun device and get the kernel to do all the filtering for me.
<rogpeppe> davecheney: had fun on the plane writing a little translator to the bpf VM language. came across a really nice use of defer.
<davecheney> rogpeppe: as a suggestion, if you're bringing up a tun device, then you can just use IP routing to do what you want
<rogpeppe> davecheney: exactly.
<davecheney> rogpeppe: bpf might get you max nerd cred, but IP routing is easier and better understood
<rogpeppe> davecheney: i just have to work out how to use an etun device because you can't share a network interface across lxc instances
<rogpeppe> davecheney: but that's probably easy to do through the lxc interface in fact.
<davecheney> rogpeppe: yeah, lxc has a number of networking options; I would _think_ that we do _not_ want bridging (which is what it does out of the box)
<rogpeppe> davecheney: yes.
<davecheney> from experience with OpenVZ, on the host side, you get an interface called venet0, which you assign all the ip's of the containers you're running
<davecheney> as long as you get the IP packets to the host, it will do the rest
<rogpeppe> davecheney: i *think* that etun (a kind of interface "pipe") does what i'm after, but i haven't had great joy finding docs.
<davecheney> essentially the OpenVZ guests are running ppp (think point to point, not ppp serial) links to the host
<davecheney> so there is layer 3 routing involved
<rogpeppe> davecheney: the most important thing is being able to read the IP packets generated by the guests from some central point.
<rogpeppe> davecheney: and that the kernel knows enough to route between local guests.
<davecheney> yeah, dunno if you can sniff on the host side of an LXC container
<davecheney> the kernel will be able to route between the local LXC containers
<davecheney> that sorta comes for free
<rogpeppe> davecheney: i found this to be a useful intro: http://backreference.org/2010/03/26/tuntap-interface-tutorial/
<davecheney> rogpeppe: thanks for the link
<rogpeppe> davecheney: i got all that stuff working ok.
<rogpeppe> davecheney: but i haven't put it together with lxc yet
<davecheney> rogpeppe: ip (iproute2) is an amazing tool, and virtually completely without documentation, unless you've used cisco routers, then it's like second nature
<rogpeppe> davecheney: it seems ok actually. the syntax isn't too shit.
<davecheney> rogpeppe: i found it pretty unfriendly to exploration
<rogpeppe> davecheney: it reminds me of the configuration language you use for talking to the plan 9 ip device
<davecheney> althoguh i got pretty friendly with ip r s
<rogpeppe> davecheney: it would be nice to have some decent docs though, it's true.
<rogpeppe> ip r s?
<davecheney> ip route show
<rogpeppe> ah
<davecheney> ip r a 10.0.0.1/32 gw tun0
<davecheney> was another favorite
<rogpeppe> davecheney: using the ip command beats working out the right argument to pass to the right ioctls...
<rogpeppe> davecheney: what's the difference between route add and addr add?
<davecheney> rogpeppe: adding an address to an interface is an endpoint
<davecheney> adding a route, establishes a possible flow between endpoints
<rogpeppe> davecheney: ok. that makes sense.
<rogpeppe> davecheney: in my case though, i'm using an endpoint as a route...
<davecheney> rogpeppe: yeah, it gets murkey
<davecheney> traditionally you'll say, ip r a 192.168/16 gw tun0
<davecheney> sorry
<davecheney> ip r a 192.168/16 gw 10.0.0.1
<davecheney> that is, send anything for 192.168/16 to 10.0.0.1, it knows what to do
<rogpeppe> davecheney: is 192.168/16 equiv to 192.168.0.0/16 ?
<davecheney> but there are more complex combinations, generally when the next hop is either not local to our network, or a point to point link
<davecheney> yes, http://en.wikipedia.org/wiki/CIDR_notation
<davecheney> they are all shorthand
<davecheney> anyway, i'd better get my self together to go out
<davecheney> devops sydney starts in an hour
<rogpeppe> davecheney: k
<rogpeppe> davecheney: have fun
<davecheney> wd
<rogpeppe> davecheney: hmm, not obvious from that page that 192.168 is equivalent to 192.168.0.0.
<rogpeppe> davecheney: i've used 127.1 as an alias for 127.0.0.1 in the past, so it's not universal...
<fwereade> heya rogpeppe
<rogpeppe> fwereade: yo man!
<rogpeppe> fwereade: thought you were off!
<fwereade> rogpeppe, today's cold and dull :)
<rogpeppe> fwereade: where r u?
<fwereade> rogpeppe, my mum's house in gloucestershire
<rogpeppe> fwereade: ah, cold and grey is par for the course currently...
<fwereade> rogpeppe, I will almost certainly take a couple more off over the next week but I don't want to entirely cut myself off :)
<rogpeppe> fwereade: cool.
<fwereade> rogpeppe, btw, I really enjoyed lord valentine's castle
<rogpeppe> fwereade: great, innit?!
<rogpeppe> fwereade: there are sequels...
<fwereade> rogpeppe, good old-fasjioned gripping yarn, nicely written, cool tech just peeking out of the background
<rogpeppe> 'xactly
<rogpeppe> i really liked that world
<fwereade> rogpeppe, yeah, I was thinking I'd have to look them up :)
<fwereade> rogpeppe, also there's something quite nice about a world running on tech they don't understand that *doesn't* draw all its drama from the obvious "it's breaking down and nobody understands it" scenario
<rogpeppe> fwereade: yeah. the tech is not central.
<rogpeppe> fwereade: i also fondly imagine, though i haven't read it in a while, that it hasn't dated badly.
<rogpeppe> fwereade: because of its lack of connection to the present day
<rogpeppe> fwereade: did you ever read Helliconia Spring BTW?
<fwereade> rogpeppe, perhaps ever such a gentle sepia tinge
<fwereade> rogpeppe, but quite possibly that was just triggered off it being an old book, becaue I can't think of anything specific
<fwereade> rogpeppe, nope
<rogpeppe> fwereade: great series. Brian Aldiss.
 * fwereade is *sure* he read some of his stuff but can't remember what
 * rogpeppe hasn't read any of his stuff in ages, but read most of it years ago.
<rogpeppe> fwereade: http://www.amazon.co.uk/Helliconia-Spring-Summer-Hellonica-MASTERWORKS/dp/0575086157/ref=sr_1_1?ie=UTF8&qid=1337250194&sr=8-1
<fwereade> rogpeppe, cool, that series has not led me wrong at any time I can recall
<rogpeppe> fwereade: not sure i've read anything from that series actually
<rogpeppe> fwereade: the original helliconia covers were definitely better.
<rogpeppe> fwereade: http://www.amazon.co.uk/Helliconia-Spring-Brian-W-Aldiss/dp/0586053654/ref=sr_1_4?ie=UTF8&qid=1337250194&sr=8-4
<rogpeppe> fwereade: http://www.amazon.co.uk/Helliconia-Summer-Panther-Books-Aldiss/dp/0586053662/ref=sr_1_5?ie=UTF8&qid=1337250194&sr=8-5
<fwereade> rogpeppe, I haven't read all that many I guess but all the ones I've read have been good
<rogpeppe> fwereade: http://www.amazon.co.uk/Helliconia-Winter-Brian-Aldiss/dp/0586053670/ref=sr_1_6?ie=UTF8&qid=1337250194&sr=8-6
<rogpeppe> :-)
<fwereade> rogpeppe, yeah, those are much more interesting
<rogpeppe> fwereade: they're also fairly close to the actual contents of the book, which is unusual
<fwereade> rogpeppe, I still keenly remember the disappointment of my first don't-judge-etc moment ;)
<rogpeppe> fwereade: :-)
<rogpeppe> fwereade: the style isn't as accessible as Valentine's Castle. you can get a good idea from the Look Inside...
<fwereade> rogpeppe, seems quite pleasing to me
<fwereade> rogpeppe, I can imagine times I wouldn't be in the mood for it
<rogpeppe> fwereade: it's definitely lingered in my mind.
<rogpeppe> fwereade: you might want to have a look at https://codereview.appspot.com/6145043/
<rogpeppe> fwereade: it's got quite a bit of new stuff in after discussions with niemeyer
<rogpeppe> fwereade: in particular, check out the Storage types in environs/interface.go
<Aram> morning.
<fwereade> rogpeppe, sorry I missed that, I'll take a look; morning Aram
<rogpeppe> Aram: hey
<rogpeppe> fwereade: i've uploaded a new version addressing niemeyer's comments.
<fwereade> rogpeppe, just saw, thanks
<fwereade> rogpeppe, and the storage stuff is indeed very pleasing, nice work
<rogpeppe> fwereade: cool. it's funny how a tiny niggle (ToolsPath in this case) can lead to a significant advance.
<rogpeppe> fwereade: "This being an interface method says to me that it's done by definition ;)."
<rogpeppe> fwereade: not quite sure what you mean there
<rogpeppe> fwereade: "juju1.2.3-precise-i386.tgz" vs "juju-1.2.3-precise-i386.tgz" ?
<rogpeppe> fwereade: which do you prefer?
<fwereade> rogpeppe, sorry, it would appear I can't read and failed to notice it was commented out
 * fwereade looks bashful and goes to eat lunch
<rogpeppe> fwereade: np
<Aram> rogpeppe: juju-1.2.3-precise-i386.tgz is better for awk.
<rogpeppe> Aram: ok. good enough. that's what i have already.
<rogpeppe> i just noticed i had also had the other variant in the past
 * rogpeppe goes for lunch
<niemeyer> Morning!
<fwereade> heya niemeyer
<niemeyer> fwereade: Heya, how're things going there?
<niemeyer> fwereade: Still in the uk?
<fwereade> niemeyer, not bad; cold and wet
<fwereade> niemeyer, that should answer your followup too ;)
<niemeyer> Haha :)
<niemeyer> fwereade: Having fun with the family?
<fwereade> niemeyer, yeah, it's lovely
<niemeyer> fwereade: nice
<fwereade> niemeyer, I think since I have the opportunity I will take tomorrow until tues as a proper holiday if that's ok with you
<niemeyer> fwereade: Yeah, it's cool
<fwereade> niemeyer, great, thanks :)
<niemeyer> fwereade: no worries, good to enjoy the family every once in a while :)
<fwereade> niemeyer, absolutely :)
<fwereade> niemeyer, laura brought be a bunch of flowers today, it was awesome :)
<niemeyer> fwereade: Hah, so sweet :)
<andrewsmedina> Heya!
<niemeyer> andrewsmedina: Morning!
<andrewsmedina> niemeyer: morning!
<rogpeppe> niemeyer: hiya!
<niemeyer> rogpeppe: Hey man
<niemeyer> rogpeppe: How's tricks?
<rogpeppe> niemeyer: great. am pleased with the last couple of branches. just working on upload-tools, to integrate the upstream stuff.
<rogpeppe> niemeyer: sorry about the size of the last one
<rogpeppe> niemeyer: lp doesn't make it easy to split a branch during review
<niemeyer> rogpeppe: No worries, it was partly self-inflicted :)
<rogpeppe> niemeyer: i'm hoping you like the new Listen/Close thing in the dummy environ.
<rogpeppe> niemeyer: that's the only substantive change this time round, i think.
<niemeyer> rogpeppe: Why do we need it?
<niemeyer> rogpeppe: Can't we simply Reset a single time in the test?
<rogpeppe> niemeyer: because we need to be able to signal to the dummy environ that no more changes are coming
<rogpeppe> niemeyer: we need to Reset to listen; then we need to wait for any changes on the channel.
<niemeyer> rogpeppe: Ok, that may be done with a single Reset
<rogpeppe> niemeyer: by closing it, we know there are no more to come.
<rogpeppe> niemeyer: but we also want to be able introspect the state after the channel has been closed.
<rogpeppe> niemeyer: so that we can tell that tools have been uploaded for example.
<rogpeppe> niemeyer: that was why i added the bool arg, but i think Listen/Close is cleaner.
<niemeyer> rogpeppe: I don't see why we need to do that afterwards.. but either way I like the sound of it too
<rogpeppe> niemeyer: well, we can't do it before!
<rogpeppe> pwd
<niemeyer> rogpeppe: We only need to Reset once in a test.. you then have a channel of events to introspect
<niemeyer> rogpeppe: You can use that single channel of events in all verifications
<rogpeppe> niemeyer: yes, but we need to introspect *after* all events have completed.
<niemeyer> rogpeppe: Not really
<niemeyer> rogpeppe: There's no intrinsic reason why that would be the case
<rogpeppe> niemeyer: we don't necessarily know what operations will be performed
<Aram> what's a branch in this context, it seems to me the branches you're talking about are not VCS branches, right?
<rogpeppe> Aram: VCS branches, yes
<Aram> or is bzr different?
<niemeyer> rogpeppe: Yes, we don't.. welcome to mocking
<Aram> hmm.
<niemeyer> rogpeppe: You're asserting that you know it..
<rogpeppe> niemeyer: i don't *think* so.
<rogpeppe> niemeyer: i'm asserting that i know at least one operation that will be performed. and that the files can be downloaded afterwards.
<rogpeppe> niemeyer: if the channel isn't closed, then i'll have to time out on error, and i don't want to do that.
<niemeyer> rogpeppe: Huh.. you're asserting a sequence of operations, and closing the channel in a way that explodes if it doesn't work
<niemeyer> rogpeppe: Anything else done by the environment will cause the test to explode
<niemeyer> rogpeppe: You might as well do that without resetting in the middle, for example
<rogpeppe> niemeyer: i'm asserting that the operation does a sequence of operations, yes. i don't think anything will explode if it doesn't work - unless the operation does operations aynchronously after it's returned.
<niemeyer> rogpeppe: I can't follow you.. "i'm asserting that the operation does" and "i don't think anything will explode if it doesn't work" are not compatible with each other
 * rogpeppe goes to look at the code again
<rogpeppe> niemeyer: what do you mean by "explode"?
<niemeyer> rogpeppe: The test will explode
<rogpeppe> niemeyer: nothing will panic, if that's what you mean
<niemeyer> rogpeppe: Fail
<rogpeppe> niemeyer: that's what i want to happen
<niemeyer> rogpeppe: No.. I mean the test will fail
<rogpeppe> niemeyer: isn't that the correct behaviour?
<niemeyer> rogpeppe: Yes, and this correct behavior doesn't need Reset in the middle.
<niemeyer> rogpeppe: It will fail if you don't reset in between things too.
<rogpeppe> niemeyer: what happens if the operation does no actions?
<niemeyer> rogpeppe: Yes, what happens?
<niemeyer> rogpeppe: Today?
<niemeyer> rogpeppe: The same will happen
<rogpeppe> niemeyer: i wait for something to arrive on the channel, but nothing arrives.
<niemeyer> rogpeppe: Yep.. same will happen if you don't reset
<rogpeppe> niemeyer: no, that's why i have Close.
<niemeyer> Sorry, I don't get it..
<niemeyer> rogpeppe: Reset, A, B, Reset, C, D
<niemeyer> rogpeppe: Why do you need the Reset in the middle?
<niemeyer> rogpeppe: Reset the dummy environment, and use a single channel from end to end..
<rogpeppe> niemeyer: we need a Reset at the end of the test as well as at the beginning.
<niemeyer> rogpeppe: That's not the question asked
<rogpeppe> niemeyer: otherwise what happens when we're expecting to read D but it wasn't sent
<rogpeppe> ?
<niemeyer> rogpeppe: Why do you need the Reset in the middle
<rogpeppe> niemeyer: we don't. we have one Reset at each side of the tested operation (or, in the new way, a Reset at the start and a Close at the end)
<niemeyer> rogpeppe: Bingo.. we don't need a Reset in the middle, which means we don't need clear, or to change the interface of the dummy package.
<rogpeppe> niemeyer: there is no Reset in the middle right now. there never has been.
<niemeyer> rogpeppe: There is.. that's the only reason why you've introduced clear
<niemeyer> or clean
<niemeyer> rogpeppe: To reset the environment without actually resetting it
<niemeyer> rogpeppe: If you only actually reset when the test starts or ends, the current interface suffices
<rogpeppe> niemeyer: look at cmd_test.go:150
<rogpeppe> niemeyer: what happens if the operation fails to send a bootstrap op?
<niemeyer> Checking
<niemeyer> rogpeppe: Ok, that sounds fine.. so there is a reason
<rogpeppe> niemeyer: yes, i was trying to explain to you :-)
<rogpeppe> niemeyer: sorry if my explanations were a bit shit
 * rogpeppe is wondering how he could make the comments clearer
<niemeyer> rogpeppe: You have a Reset in the middle of the test.. and it wasn't clear why. Denying that the Reset existed was one of the difficulties for me to understand what was going on, at least.
<niemeyer> rogpeppe: Either way, Listen+Close looks great
<rogpeppe> niemeyer: yeah, i was unclear sorry. i was confusing "test" and "operation"...
<rogpeppe> niemeyer: cool. i think it works ok.
<niemeyer> Lunch time.. back in a moment
<fwereade> need to be away for a while; I'll pop back on later tonight
<rogpeppe> fwereade: ok. see you tomorrow.
 * niemeyer waves
<niemeyer> robbiew: Do we have a call now?
<robbiew> yes
<robbiew> well...in 1.5min...but yes
<rogpeppe> niemeyer: i'm off a little earlier today. i'll see you tomorrow.
<niemeyer> rogpeppe: Cool, cheers, I'll try clean things up by the EOD tomorrow (hopefully!)
<niemeyer> Erm, EOD today
<niemeyer> robbiew: Cool, welcome back
<rogpeppe> niemeyer: that would be great. it feels a little cluttered at the moment. i'm trying to avoid criss-cross merges...
<niemeyer> rogpeppe: Yeah, I've been making my way through it, but still a bit to go
<robbiew> niemeyer: biobreak..then will send g+ link :)
<robbiew> TMI
<niemeyer> robbiew: Ok, I'll send the invite.. just join when you're back
<niemeyer> robbiew: Sent
<robbiew> niemeyer: on my way
<niemeyer> I suspect this is the largest branch/review yet: https://codereview.appspot.com/6145043/
<niemeyer> It's an awesome step forward, and it's also a great counter example for branch size :)
<niemeyer> andrewsmedina: ping
<niemeyer> andrewsmedina: pingous
<niemeyer> andrewsmedina: Well, there's a ton of comments form Rog.. I'll put the branch as Work In Progress. Once you re-propose, it will show up in the active reviews again
<niemeyer> andrewsmedina: If there's anything I can do in between, just ping me please
<andrewsmedina> niemeyer: Im back
<andrewsmedina> someone know why juju ssh use hostname instead ip?
<SpamapS> niemeyer: any word on cs:precise/ubuntu ?
<niemeyer> SpamapS: I've pinged Tom Haddon several times, without responses, and finally opened an rt ticket.. still waiting
<niemeyer> SpamapS: devops ftw
<SpamapS> niemeyer: RT is as agile as a bowling ball in a lake.
<davecheney> niemeyer: https://codereview.appspot.com/6203083
<davecheney> niemeyer: i can't figure out why all this other stuff has leaked into this branch
<davecheney> niemeyer: i figured it out, the -req this branch was based on was not up to date
<niemeyer> davecheney: Heya
<davecheney> niemeyer: hey
<niemeyer> davecheney: Ah, yeah, easiest is to push the previous branch
<niemeyer> davecheney: and then propose again.. should clean it up
<davecheney> niemeyer: is there a way to switch the -req (maybe by hacking the lbox data?)
<davecheney> niemeyer: yeah, that worked for me
<niemeyer> davecheney: No, it doesn't work, only if you push it again
<davecheney> niemeyer: fair enough
<davecheney> niemeyer: % jujud -v provisioning --zookeeper-servers 127.0.0.1:2181
<davecheney> 2012/05/18 09:37:54 JUJU state: opening state; zookeeper addresses: ["127.0.0.1:2181"]
<davecheney> 2012/05/18 09:37:54 JUJU state: waiting for state to be initialized
<davecheney> 2012/05/18 09:37:54 JUJU invalid environment configuration: key "kind"  was not present in the supplied configuration
<davecheney> getting there
<niemeyer> davecheney: Hah, neat!
<davecheney> niemeyer: i look forward to the feedback from the team, but i'll keep working it this morning, and then move on to another pass at WatchMachines
#juju-dev 2012-05-18
<andrewsmedina> niemeyer: error: Get https://api.launchpad.net/devel/people/+me: x509: certificate has expired or is not yet valid
<niemeyer> andrewsmedina: I get Object: <lp.registry.model.person.PersonSet object at 0xa787750>, name: u'+me:'
<andrewsmedina> niemeyer: Im trying to send a proposal with lbox and returns this error
<niemeyer> andrewsmedina: Ok, not sure then
<niemeyer> andrewsmedina: Please ping me tomorrow if you still have the issue.. I really need some bed time now
<rogpeppe> davecheney: yo!
<davecheney> rogpeppe: howdy
<davecheney> you've got some commits to make my man
<rogpeppe> brilliant
<davecheney> gustavo green lighted a heap of branches overnight
<davecheney> I would also be very keen to hear your feedback on my proposal for the provisioning agent
<rogpeppe> davecheney: i only see one actually, but maybe i'm missing something
<davecheney> rogpeppe: the ConfigNode one got the tick
<davecheney> what about upload-tools ?
<rogpeppe> davecheney: i already submitted the confignode one
<davecheney> ok
<rogpeppe> davecheney: i'm interested in feedback on https://codereview.appspot.com/6213050/
 * davecheney looks
<rogpeppe> davecheney: any particular reason that ProviderService is an interface?
<davecheney> So I can mock it
<davecheney> you could make an argument either way
<davecheney> it's still a wip
<rogpeppe> davecheney: i'm wondering if there's a need to mock it when we can mock the state itself.
<davecheney> rogpeppe: indeed, there are probably other ways to do it
<davecheney> rogpeppe: but putting that to one side, do you have any comments on the use of the an internal goroutine which insulates callers from the environ reloading ?
<rogpeppe> davecheney: i think it looks good.
<rogpeppe> davecheney: although i'm still mulling over the implications
<davecheney> understood
<davecheney> rogpeppe: when I sat down yesterday and realised I had two loops of control going on at once; the machines watcher and the environ watcher
<davecheney> it appeared simpler to model it this way
<davecheney> there are also interesting possibilities to introduce paralism
<davecheney> rogpeppe: also, rewriting machine watcher (again), https://codereview.appspot.com/6210066/
<rogpeppe> davecheney: i guess i'm slightly surprised that the machines watcher doesn't just watch the environs config too
<rogpeppe> davecheney: it looks like you've still got two loops of control going on
<rogpeppe> davecheney: although i may misunderstand how AddMachine etc are intended to be used.
<davecheney> rogpeppe: s/AddMachine/StartInstance/g, s/RemoveMachine/StopInstance/g
<davecheney> I should have used better names
<rogpeppe> davecheney: i don't think that affects the point though. who's calling those methods?
<davecheney> rogpeppe: provisioning.go
<davecheney> rogpeppe: it also just occured to me, why don't I just implement the environs.Envrion interface
<rogpeppe> davecheney: we've got dummy for that, perhaps.
<davecheney> the goal is to buffer callers to those methods from having to deal wit the fact the environ is not ready/available
<rogpeppe> davecheney: that's only right at the start though, yes?
<rogpeppe> davecheney: can we do anything at all until that happens, in fact?
<davecheney> rogpeppe: hmm, the way gustavo explained it, we have to deal with the fact that environ can change at any time
<rogpeppe> davecheney: that's no problem i think. i'll paste a little pseudo code to try and explain what i'm thinking.
<davecheney> kk
<rogpeppe> davecheney: http://paste.ubuntu.com/993735/
<rogpeppe> davecheney: as a very rough sketch
<davecheney> rogpeppe: yup, that is what I had first
<rogpeppe> davecheney: so where's the other loop of control?
<davecheney> so, what happens if case e := <-envWatcher: env = e
<davecheney> fires, and the env is now broken or nil
<davecheney> also, once c := <-configWatcher has fired, we need to keep trying that action until it succeeds, or the process exits
<davecheney> so, if e is broken, then we need to put c somewhere, then come back to it when e is not broken
<rogpeppe> davecheney: two possibilities: either you loop inside that arm of the select when env is broken, until it's not; or you introduce another goroutine so that only valid environments are send on the env watch channel
<davecheney> rogpeppe: I think i've implemented the latter
<davecheney> rogpeppe: but sort of inside out
<rogpeppe> davecheney: yeah
<rogpeppe> davecheney: i *think* things would be clearer (and probably smaller) if the extra goroutine *just* did that - another component in the pipeline, with no side effects.
<davecheney> rogpeppe: hmm, i do like simplicity
<davecheney> and it would resolve the requirement to have two stages, waiting for the first environ, then acting on changes
<davecheney> rogpeppe: you are right, that is a lot simpler
<rogpeppe> davecheney: we have to decide if having an invalid environ should cause the provisioning agent to stop until it's valid, or continue with the old, valid environ
<davecheney> rogpeppe: that could be the blocker
<rogpeppe> davecheney: my problem with the current proposal is that there are really two loci of control, and i think that's awkward.
<rogpeppe> davecheney: both are possible, i think, and not hard.
<rogpeppe> davecheney: we just have to decide what semantic we actually want
<davecheney> rogpeppe: in your env <- channel approach, you always have _an_ environ; but there is no way to give it a broken one
<davecheney> in my approach, you always hold a proxy environ, which may block calls through it if the undernlying environ is invalid
<rogpeppe> davecheney: in that case, you choose the first approach i mentioned
<rogpeppe> davecheney: "loop inside that arm of the select when env is broken, until it's not"
<davecheney> rogpeppe: i need to ponder this
<rogpeppe> davecheney: that automatically excludes the other part of the select from acting on it.
<davecheney> i like your approach, it's less code and clearer
<rogpeppe> davecheney: cool.
<davecheney> rogpeppe: i guess it comes down to 'what is broken'
<rogpeppe> davecheney: yes - and "what do we want to do about that?"
<davecheney> i see there are two kinds of broken, one is missing key fields, basically unyaml'ing ""
<davecheney> the other is valid, but incorrect, so incorrect AWS credentials
<davecheney> which I don't think is invalid, tf/ it shuld be passed to the provisioning agent, and provisioning attempted against it
<rogpeppe> davecheney: yeah. so the first *should* never happen. a goroutine filtering out those occurrences and logging them would probably be fine.
<davecheney> rogpeppe: i think it's the opposite
<davecheney> the first will always happen
<rogpeppe> davecheney: agreed. i don't think you can tell otherwise.
<rogpeppe> davecheney: really?
<davecheney> when the provisioning agent starts up, /environment is ""
<rogpeppe> yes, but that's a special case at the start, which we cater for specifically
<davecheney> it has to wait until it gets a config node that is properly formed
<rogpeppe> we wait until that time has passed before entering the provisioning loop proper
<rogpeppe> what about when we're *in* the loop?
<rogpeppe> i don't *think* we should see it then
<rogpeppe> unless something else fucks up
<rogpeppe> davecheney: BTW what happened to our idea of having a goroutine per machine?
<davecheney> rogpeppe: kinda fell in a heap when I understood that environment could change over time
<rogpeppe> davecheney: hmm. i *wonder*... we could just model the environ as a global variable, guarded by an RWMutex.
<davecheney> rogpeppe: that is what I was aiming for with the ProviderService
<davecheney> by communicating with it via a channel, it has a mutex of sorts
<davecheney> it only accepts your commands when it's in a state to act on them
<davecheney> otherwise they block
 * rogpeppe thinks
<rogpeppe> davecheney: thing is, if we want any concurrency at all, when the environment changes, there are still going to be actions acting on the old environment.
<davecheney> rogpeppe: i agree
<rogpeppe> davecheney: which i think is ok. we just want to make sure that any new actions use the new environment.
<davecheney> rogpeppe: so actions on the Environ are going to fail, and should be retried (via some business logic)
<davecheney> so the key will be they can pick up the new value of Environ
<davecheney> rogpeppe: which sort of leans me back to my original proposal this morning
<rogpeppe> davecheney: exactly - we need to distribute the new Environ to everyone
<davecheney> 'except i'll make it implment a full proxy Environ, so you can just keep retrying against the proxy.
<rogpeppe> davecheney: i think it's quite a lot of code for something that's really just a mutexed global variable at heart.
<rogpeppe> davecheney: and if you do it that way, we can keep the original vision of having a separate goroutine for each machine, right at the heart of the provisioning agent.
<davecheney> rogpeppe: here is a quick stab at your version, http://paste.ubuntu.com/993760/
<davecheney> rogpeppe: yes! so each 'machine' proxy has a channel for commands, provision yourself, deprovision yourself
<davecheney> and those commands talk to the Environ proxy
<rogpeppe> davecheney: yeah
<davecheney> and they retry according to some business logic
<davecheney> that would solve one of my concerns about running adds and deletes in parallel
<rogpeppe> davecheney: yeah
<davecheney> this has been very useful
<rogpeppe> davecheney: great!
<davecheney> unfortuntely i'm going out in 20 minutes
<davecheney> but i'll hack on this when I get home
<rogpeppe> davecheney: np, i'm glad i got up early...
<davecheney> what time is it in +1 over there ?
<davecheney> it's 17:40
<rogpeppe> davecheney: 0841
<davecheney> right
<rogpeppe> davecheney: thanks for the comments on the simplified provider interface, BTW
<davecheney> rogpeppe: i think i attempted a half assed version of that when I did environ.NewEnviron, but ended up backing out most of it
<rogpeppe> davecheney: it seems to mesh well. and i think the overall line count probably dropped, which is always a good sign...
<davecheney> never hurts
<rogpeppe> davecheney: i like the fact that Check now matches NewEnviron. and when we have Marshal, that'll return the same type too.
<davecheney> rogpeppe: now that is good, and less untyped interface{}'s
<rogpeppe> davecheney: defo
<rogpeppe> davecheney: BTW in the provisioning agent, i *think* you'll only want one channel to the machine goroutine - to remove the machine.
<davecheney> rogpeppe: yeah, i'll be doing some surgery on that tomorrow
<davecheney> but for now, it's good night from me
<rogpeppe> davecheney: have a good one!
<rogpeppe> fwereade: ping
<fwereade> rogpeppe, pong
<rogpeppe> fwereade: hiya
<fwereade> rogpeppe, (landing stuff doesn't count as working :p)
<fwereade> rogpeppe, heyhey
<rogpeppe> ?
<fwereade> rogpeppe, but I am actually about to stop ;p
<rogpeppe> ah...
<fwereade> rogpeppe, I'm off until weds now :0
<rogpeppe> cool
<rogpeppe> fwereade: just wondered if you could clarify about the machine key stuff, but don't worry if you're stopping
<fwereade> rogpeppe, regardless, what can I do for you while I'm here?
<fwereade> rogpeppe, it's just a vague sense that the correspondence between keys and ids feel coincidental rather than fundamental
<rogpeppe> fwereade: what is a machine key?
<rogpeppe> fwereade: i know about machine ids and instance ids
<rogpeppe> but not machine keys...
<fwereade> rogpeppe, it's the node name in zookeeper
<fwereade> rogpeppe, machine-0000000001
<rogpeppe> fwereade: and that's not named after the machine id?
<fwereade> rogpeppe, it feels to me that that's an accident of happenstance rather than a fundamental truth
<rogpeppe> fwereade: it's not always fmt.Sprintf("machine-%010d", machine.Id) ?
<rogpeppe> fwereade: what's primary?
<rogpeppe> fwereade: we talk about machine id 0 for the bootstrap machine, for example
<fwereade> rogpeppe, I guess it's just an idea that juju ids *ought* to increase "smoothly" rather than just monotonically
<rogpeppe> fwereade: what's the difference?
<fwereade> rogpeppe, just that the fact that we can end up skipping an id that's held by an orphan node has the feel of a leaked implementation detail
<rogpeppe> fwereade: when are we going to add more than 1 to the new machine id?
<rogpeppe> ah
<fwereade> rogpeppe, and that the platonic ideal of juju would have machines 0-N without skipping any
<rogpeppe> fwereade: when do we get an orphan node?
<fwereade> rogpeppe, when something bad happens after the node has been created but before the topology is updated
<rogpeppe> "something bad"?
<fwereade> rogpeppe, someone trips over a network cable, say
<fwereade> rogpeppe, this is not something I'm strongly invested in though
<fwereade> rogpeppe, I think I'm -0 rather than -1
<rogpeppe> fwereade: i'm slightly surprised that the node is created *before* the topology is changed.
<fwereade> rogpeppe, the topology needs to know which node it's pointing to
<rogpeppe> fwereade: that doesn't square with my understanding of the way things work, but that's fairly sketchy!
<fwereade> rogpeppe, if we update the topology first, we can't guarantee what the next sequence node will be
<rogpeppe> fwereade: the topology doesn't just talk about "machine 0", "machine 1", etc?
<fwereade> rogpeppe, I'm pretty sure it knows which keys it's pointing to, but I could be on crack
<rogpeppe> fwereade: so the machine-000001 node name can skip numbers, but not the machine id, right?
<fwereade> rogpeppe, coincidentally they do always correspond IIRC
<rogpeppe> fwereade: what about orphans?
<fwereade> rogpeppe, they're just trash
<fwereade> rogpeppe, they don't exist according to the topology, which is the sole source of truth
<rogpeppe> fwereade: what are they named?
<fwereade> rogpeppe, they would, I think, be named after the key; but they don't exist so the question is philosophically shaky ;)
<rogpeppe> fwereade: i'll try to explain what i think i understand, and perhaps you can tell me if i'm more-or-less right
<rogpeppe> 1) someone calls add-unit
<rogpeppe> 2) the client adds a machine node to the state
<rogpeppe> 3) the client adds a topology node referencing the new machine node
<fwereade> rogpeppe, I think so, yeah
<rogpeppe> 4) the provisioning agent sees the change to the topology node and starts a new instance
<fwereade> rogpeppe, exactly
<rogpeppe> 5) the new machine registers that it's up in its machine node.
<rogpeppe> so the problem with orphan nodes happens if the network breaks between 2) and 3)
<fwereade> rogpeppe, probably, I forget the details of the machine agent; I think it has a separate presence node
<fwereade> rogpeppe, yeah
<fwereade> rogpeppe, sorry: but lunch is on the table
<rogpeppe> fwereade: ok
<rogpeppe> fwereade: one last question to ponder:
<fwereade> rogpeppe, may have a moment before I leave later but don;t count on it
 * fwereade listens
<rogpeppe> fwereade: why doesn't the provisioning agent allocate the new machine node?
<rogpeppe> fwereade: anyway, enjoy your time at home! go to lunch! (early lunch, BTW! i've just had breaky...)
<fwereade> rogpeppe, I can't think of a good reason, that may be a nicer way to do it
<fwereade> I'll think :)
<fwereade> rogpeppe, train at proper lunchtime :)
<fwereade> rogpeppe, cheers
<rogpeppe> fwereade: ttfn
<rogpeppe> there ought to be a word for the noise a branch makes when landing.
<niemeyer> GOod morning all
<rogpeppe> niemeyer: hiya!
<rogpeppe> niemeyer: pretty quiet around here...
<rogpeppe> niemeyer: thanks for okaying that huge branch BTW
<niemeyer> rogpeppe: Yeah, quiet indeed
<niemeyer> rogpeppe: Must be Friday :)
<niemeyer> rogpeppe: I'm just sipping some chimarrÃ£o and going over the inbox for a moment
<rogpeppe> niemeyer: fwereade's on hols. don't know about TheMue
<niemeyer> mthaddon: Thanks for checking out that charm
<niemeyer> rogpeppe: He said he'd be out too.. don't recall if he'd be back today or not
<rogpeppe> niemeyer: i'm thinking about refactoring dummy a little
<niemeyer> rogpeppe: I think it's fine for the moment..
<rogpeppe> niemeyer: i realised that i wanted it to serve urls (for the storage URL service) and it's awkwardly structured for that
<niemeyer> rogpeppe: I'd prefer to keep pushing forward, and then get back later once we have some more use cases known
<niemeyer> rogpeppe: Hmm
<niemeyer> rogpeppe: What's the issue?
<rogpeppe> niemeyer: the difficulty is that we now want two storage services from the same dummy environ
<niemeyer> rogpeppe: How's that a problem?
<rogpeppe> niemeyer: and the way environ is the same as storage doesn't work too well with that
<niemeyer> rogpeppe: Ah, I see, yeah, might be good to have that fixed
<rogpeppe> niemeyer: and i realised that really the environ shouldn't be recreated with every Environ.Open
<rogpeppe> niemeyer: it should be shared, as part of state.
<rogpeppe> niemeyer: so...
<rogpeppe> niemeyer: that means that we can't take all the environ settings from the environ config (otherwise that gives too much precedence to the first one parsed)
<rogpeppe> niemeyer: so...
<niemeyer> rogpeppe: Hmm.. yeah, and it wasn't recreated..?
<niemeyer> rogpeppe: That's what we had Reset for, right?
<rogpeppe> niemeyer: i'm thinking that perhaps Reset should take an argument which asks for the kind of capabilities we want
<niemeyer> rogpeppe: I don't think that's necessary
<rogpeppe> niemeyer: so you can ask for a dummy env that mocks zookeeper, perhaps (in the future), or serves a storage web server, or has a required field in the config
<rogpeppe> niemeyer: at the moment all those things are determined by the provider config, which seems slightly wrong.
<niemeyer> rogpeppe: I don't think that's necessary.. config is passed onto Open.. mocking ZooKeeper is not on the table right now, and serving a storage web server may be done a single way
<niemeyer> rogpeppe: There's really no great reason to increase the number of knobs there
<niemeyer> rogpeppe: Why is it wrong ? dummy is a provider.. and you're talking about configuring it
<niemeyer> rogpeppe: I'd like to make it simpler, not more complex
<rogpeppe> niemeyer: because the configuration is shared; the configuration is used to connect to it, not create it.
<rogpeppe> niemeyer: also, i was slightly hoping to avoid starting a new web server on every Reset. but i guess that's ok really.
<rogpeppe> niemeyer: it currently seems slightly bogus that i require a zookeeper attribute on all dummy environ configs, just so i can check that starting an environment with a missing attribute fails correctly.
<rogpeppe> [14:54:39] <rogpeppe> niemeyer: because the configuration is shared; the configuration is used to connect to it, not create it.
<rogpeppe> that was badly said
<rogpeppe> i meant "the environment is shared"
<Aram> evening.
<niemeyer> Aram: Heya
<andrewsmedina> niemeyer: Hi
<niemeyer> andrewsmedina: Yo
<niemeyer> rogpeppe: Re. https://codereview.appspot.com/6203083/, did you discuss ideas with Dave this morning?
<rogpeppe> niemeyer: yeah. we came up with something quite nice i think.
<niemeyer> rogpeppe: That's great, thanks a lot
<rogpeppe> niemeyer: i could paste the relevant log if you like
<niemeyer> rogpeppe: I'll mark the branch as WIP
<niemeyer> rogpeppe: I'm happy to wait for the result of it
<rogpeppe> niemeyer: i think it should be marked as that anyway - at least that was his intention
<rogpeppe> niemeyer: did you take a look at https://codereview.appspot.com/6213050/ ?
<niemeyer> Ah, and so it is
<rogpeppe> niemeyer: it's my "i have an idea" from the other evening
<niemeyer> rogpeppe: Not yet.. it's the largest branch in the queue, so I've been reviewing the others first
<rogpeppe> niemeyer: np
<niemeyer> rogpeppe: But I'll get there
<niemeyer> We should dial back the branch sizes.. yesterday most of them were over 400 lines
<niemeyer> (of diff)
<rogpeppe> niemeyer: BTW the tests are broken at the moment. i think william forgot to run tests before submitting...
<niemeyer> rogpeppe: Cool, we should get a fix in soon
<rogpeppe> niemeyer: i wanted to but the fix wasn't immediately obvious to me and i'm trying to get this stuff proposed.
<rogpeppe> niemeyer: only problem is, in integrating the previous branches, i want to insert a branch before one i've already proposed... it's a pity that's not easy. i'll just not stack them, i think, and mark the last one as WIP
<rogpeppe> niemeyer: some of the diffs are made larger by the fact that not everyone runs gofmt before proposing/submitting.
<rogpeppe> niemeyer: some time it might be nice to make lbox fail if go files aren't gofmted.
<niemeyer> rogpeppe: I generally try to make branches independent when pushing my own work
<niemeyer> rogpeppe: Tends to pay off in these cases
<rogpeppe> niemeyer: me too, but in this case, the reason i want to insert a branch is because i want to use some of that functionality in the upcoming branch, but don't want to bloat it.
<niemeyer> rogpeppe: Well, in that case there's no choice.. just propose the branch and put the follow up as WIP or repropose with pre-req
<rogpeppe> niemeyer: can't change the prereq once proposed, sadly
<rogpeppe> i think
<rogpeppe> i'll just wait until the prereq is submitted
<niemeyer> Cool
<niemeyer> Lunch!
<rogpeppe> niemeyer: here's the prereq: https://codereview.appspot.com/6209078/
<niemeyer> rogpeppe: Checking
<rogpeppe> niemeyer: it's time for me to go; have a great weekend!
<niemeyer> rogpeppe: For you as well.. almost finishing the review
<rogpeppe> niemeyer: great, thanks a lot
<hazmat> rogpeppe, have a good one
<rogpeppe> hazmat: and you. you still up for that editor challenge BTW? :-)
<hazmat> rogpeppe, anytime! :-)
<rogpeppe> hazmat: alright, i'll see how much sublime costs and whether i can deal with it...
 * hazmat wonders if he should start recruiting some ringers for the challenge
<hazmat> rogpeppe, its free to try out
<rogpeppe> hazmat: ringers?
<hazmat> rogpeppe, experts posing as novices
<hazmat> rogpeppe, so wait.. i have to learn acme then?
<hazmat> :-)
<rogpeppe> hazmat: that's the deal
 * hazmat forget the challenge details
<rogpeppe> hazmat: acme exclusively for a month
<rogpeppe> hazmat: well, apart from when it's not possible
<hazmat> rogpeppe, not this month then
<hazmat> rogpeppe, incidentally how do you install it?
<rogpeppe> hazmat: grab the plan9port tarball, run INSTALL
<hazmat> rogpeppe, cool thanks
<hazmat> rogpeppe, yeah.. i'm under some tight deadlines, so not this month, but i'm game
<rogpeppe> hazmat: i am too (he says, worried about dropping productivity :-])
<rogpeppe> http://swtch.com/plan9port/plan9port.tgz
<rogpeppe> anyway, gotta go
<andrewsmedina> niemeyer: I still could not send the proposal
<niemeyer> andrewsmedina: Ok, let's see then
<niemeyer> andrewsmedina: What's going on?
<andrewsmedina> niemeyer: http://dpaste.org/XKeHn/
<niemeyer> andrewsmedina: Try to load https://api.launchpad.net/ in your browser
<niemeyer> andrewsmedina: What OS and OS version are you using?
<andrewsmedina> niemeyer: ubuntu and centos
<niemeyer> andrewsmedina: At the same time!? :-)
<andrewsmedina> niemeyer: yes, with vms :)
<niemeyer> andrewsmedina: I mean where is this command failing
<niemeyer> andrewsmedina: On both?
<andrewsmedina> niemeyer: I tryed do a wget http://paste.ubuntu.com/
<andrewsmedina> niemeyer: I tried on ubuntu and centos
<andrewsmedina> ubuntu 12.04
<niemeyer> andrewsmedina: Ok, that's pretty weird
<niemeyer> andrewsmedina: Are you under a proxy?
<niemeyer> andrewsmedina: Could the proxy be getting in the way of the https connection?
<andrewsmedina> niemeyer: I dont use proxy here
<niemeyer> andrewsmedina: Wow, do you develop as root?
<andrewsmedina> niemeyer: :-p
<niemeyer> andrewsmedina: Can you see my look of disapproval from there? ;-)
<andrewsmedina> niemeyer: I use "andrezias" user to (on ubuntu). But in centos I use root :-p
<niemeyer> andrewsmedina: Can you please try to wget from https://api.launchpad.net/devel/branches?
<niemeyer> andrewsmedina: Tsc tsc :)
<andrewsmedina> niemeyer: same result
<andrewsmedina> http://paste.ubuntu.com/994583/
<niemeyer> andrewsmedina: Sounds like you have a bad set of certs
<niemeyer> andrewsmedina: Have you tried to update your installation?
<andrewsmedina> niemeyer: installation of?
<niemeyer> andrewsmedina: Of your OS
<andrewsmedina> why? how so version can affect the launchpad certs?
<andrewsmedina> so == OS :p
<niemeyer> andrewsmedina: The certificates that are used to verify the validity of a given site certificate are installed in your disk
<andrewsmedina> niemeyer: humm.. my vms are headless
<andrewsmedina> but I already used lbox another times without problem
<niemeyer> andrewsmedina: Why is it an issue that your vms are headless?
<andrewsmedina> niemeyer: when lpad tell do aprove the req I opened it on my mac os ( :-p )
<niemeyer> andrewsmedina: This is irrelevant for the problem.. the certificates within the vms must work too
<andrewsmedina> niemeyer: you're right
 * hazmat lunches bbiab
#juju-dev 2012-05-19
<Aram> morning.
#juju-dev 2012-05-20
<twobottux> Announcement from my owner (amithkk): Hey! I'm 2bottuX, A bot by Amith KK. I'm on 2 ubuntu channels and #2buntu. My Function is to provide AskUbuntu Integration. If you want me in any of your channels watching a tag, msg amithkk
<Aram> morning.
#juju-dev 2013-05-13
<hazmat> anyone around that can help debug some openstack issues?
#juju-dev 2013-05-14
<hazmat> goyaml seems to have some issues with go 1.1 http://paste.ubuntu.com/5663122/
<hazmat> argh... nevermind some sort of GOPATH wierdness was picking up  a GOROOT value
<hazmat> re goyaml
<rogpeppe> yay! internet is finally back on!
<teknico> they don't want to delay the propagation of Go 1.1 ;-)
<mattyw> rogpeppe, how much experience do you have running benchmarks in gocheck?
<rogpeppe> mattyw: i've done a few
<mattyw> rogpeppe, I've got two packages with benchmarks in them, but I don't seem to be able to run all of them at once (in one command)
<rogpeppe> mattyw: go test -gocheck.b should do it
<mattyw> rogpeppe, it doesn't seem to, although it's just occured to me that it might be my tree that's causing it. I've got benchmarks in juju/ws/ws_test.go and juju/api/api_test.go but no tests in juju
<rogpeppe> mattyw: what directory are you running the tests in?
<mattyw> rogpeppe, well I have to be in juju/api or juju/ws as there aren't any tests higher up
<rogpeppe> mattyw: what do you see if you do go test -gocheck.b -gocheck.v ?
<mattyw> rogpeppe, it's only running the api test if I'm in the api package when I run the command
<mattyw> rogpeppe, I guess this sort of makes sense
<rogpeppe> mattyw: go test only tests the package in the current directory by default
<rogpeppe> mattyw: you can give it a list of packages if you want
<rogpeppe> mattyw: or a wildcard (see "go help packages" for some docs on that)
<mattyw> rogpeppe, but if I'm supplying -gocheck.b I need to do that from within a package wich has a gocheck test it looks like
<rogpeppe> mattyw: yes
<rogpeppe> mattyw: most packages do, but not quite all unfortunately
<mattyw> rogpeppe, so if I wanted to run all the benchmarks in my codebase by doing go test -gocheck.b launchpad.net/thing/foo/... launchpad.net/thing/bar/... I need to have a gocheck package in my current dir?
<rogpeppe> mattyw: no
<mattyw> rogpeppe, (jet lag is probably causing me to not be making much sense)
<rogpeppe> mattyw: just in the packages that you're testing
<rogpeppe> mattyw: you can see which packages match by using go list
<mattyw> rogpeppe, would a quick hangout be possible? might be quicker for you to see what I'm talking about
<rogpeppe> mattyw: sure
<mattyw> rogpeppe, thanks very much https://plus.google.com/hangouts/_/6fabced08041ffc4a35b6ebdd200962be8e826ba
<hazmat> rogpeppe2, the provider port opening for the api is generic or is it per provider?
<rogpeppe2> hazmat: in the api, it's generic (it just sets the flag in the state). the firewaller agent is responsible for acting on that state change, and each provider implements port opening privately.
<hazmat> rogpeppe2, i've been seeing some issues with client connectivity to the api in openstack environments, just trying to debug.. it works on localhost but remotely it generates an http 400 server error
<hazmat> i suspect its something to do with the origin header on the websocket
<hazmat> works ootb on ec2
<rogpeppe2> hazmat: hmm odd.
<rogpeppe2> hazmat: could it be something to do with limited public ip address space?
<hazmat> rogpeppe2, its happened on canonistack and hpcloud
<rogpeppe2> hazmat: you're getting a 400 server error from the API? or from the service you've deployed?
<hazmat> in the canonistack case the user had sshuttle setup as transparent proxy
<hazmat> rogpeppe2, api server
<rogpeppe2> hazmat: through the GUI or direct?
<hazmat> rogpeppe2, direct
<rogpeppe2> hazmat: what's the full body of the error?
<hazmat> rogpeppe2, nothing in the juju logs, its silent.. looks like pre login nothing gets logged there
<rogpeppe2> hazmat: i meant of the 400 error.
<hazmat> rogpeppe2, empty body
<rogpeppe2> hazmat: i'm wondering if the error is coming from the API server or something else
<rogpeppe2> hazmat: and "400 server error" is the whole text of the error?
 * hazmat setups a reproduce csae
<hazmat> rogpeppe2, so this is out of the box on hpcloud.. generates a 403.. http://pastebin.ubuntu.com/5664742/
<rogpeppe2> hazmat: ah, "forbidden". hmm.
<hazmat> rogpeppe2, if i setup the client on the localhost there i can get it to work
<rogpeppe2> hazmat: is that a public ip address i could try ?
<hazmat> rogpeppe2, that is a public ip address
<hazmat> rogpeppe2, i'll import your key
<hazmat> rogpeppe2, you can ssh into the instance as well / u=ubuntu
<hazmat> rogpeppe2, the agent logs are useless since there isn't anything logged till post login afaics
<hazmat> rogpeppe2, i suspect its something in go.net websocket lib that's barfing
<rogpeppe2> hazmat: it may be. i'm just writing a little bit of test code.
<rogpeppe2> hazmat: i'm wondering if it's something to do with the "localhost" in this line:
<rogpeppe2> 	cfg, err := websocket.NewConfig("wss://"+info.Addrs[0]+"/", "http://localhost/")
<hazmat> rogpeppe2, the odd bit, is that there is no '403' in that package
<hazmat> hmm
<hazmat> yes
<hazmat> that might be it
<rogpeppe2> but no
<hazmat> but we use the address that the instance thinks it has so ...
<rogpeppe2> hazmat: that's the client-side code
<hazmat> oh, not likely relevant then
<hazmat> rogpeppe2, got it...
<hazmat> its the go.net websocket server.go around the handshake
<hazmat> line 41-43
<rogpeppe2> hazmat: hmm, my line 41 says "config.Protocol = nil"
<hazmat> rogpeppe2, revision 49? of go.net
<hazmat> rogpeppe2, of websocket/server.go ?
<rogpeppe2> hazmat: ah, i'm on r48
<rogpeppe2> hazmat: it's changed quite a bi
<rogpeppe2> t
<rogpeppe2> pity it discards the actual text of the error
<hazmat> rogpeppe2, so it looks like its the checkOrigin func of the handler
<hazmat> but that's a guess
<rogpeppe2> hazmat: yes it looks like that
<hazmat> rogpeppe2, 2013/05/14 15:01:32 INFO environs/openstack: closed ports in security group juju-hp-0: [tcp:17070]
<hazmat> probably not relevant
<hazmat> the env group port is still open
<hazmat> that was juju correcting my manual changes
<rogpeppe2> hazmat: hmm, it might have been rev 49 that broke it - it's a recent change with some relevant looking stuff
<rogpeppe2> hazmat: are you using the release version of juju?
<hazmat> rogpeppe2, no.. there are other issues with that
<rogpeppe2> hazmat: can you try with r48 of websocket?
<hazmat> rogpeppe2, i just see it re-jigging the origin parsing
<hazmat> rogpeppe2, but as per the content dump its present in the request
<hazmat> rogpeppe2, i'll add some debugging prints and redeploy it
<rogpeppe2> hazmat: it looks like you'd get that result if the origin couldn't be parsed
<hazmat> rogpeppe2, hmm that could be it
<hazmat> rogpeppe2, yeah its the port number there
<hazmat> and the delta between 48/49 on origin parsing
<rogpeppe2> hazmat: there's a port number in the origin?
<hazmat> rogpeppe2, per my pastebin yes
<hazmat> let me modify the client and see what happens
<rogpeppe2> hazmat: ah!
<rogpeppe2> hazmat: so it's all your fault :-)
<hazmat> rogpeppe2, debatable :-)
<hazmat> rogpeppe2, as in this case i didn't write the websocket client lib, and it did previously work against juju-core
<hazmat> and its still not identified as the actual bug
<rogpeppe2> hazmat: oh yes
<rogpeppe2> hazmat: Origin should be a url
<hazmat> rogpeppe2, its not the issue
<rogpeppe2> hazmat: it's nothing to do with the port number
 * hazmat plays around with url.Parse
<rogpeppe2> jeeze this is inpenetrable http://tools.ietf.org/id/draft-abarth-origin-03.html
<rogpeppe2> hazmat: here's a start: http://paste.ubuntu.com/5664817/
<hazmat> rogpeppe2, do you get an err with that?
<rogpeppe2> hazmat: yes
<hazmat> i just switched out to 1.1
<hazmat> rogpeppe2, this might be a delta with go 1.0
<rogpeppe2> hazmat: i doubt it
<rogpeppe2> hazmat: looks like that websocket update to me
<hazmat> rogpeppe2, ah yes.. ic
<hazmat> previously it only parsed with url if didn't match 13 or 8 on websocket protocol
<rogpeppe2> by my shallow reading of http://tools.ietf.org/id/draft-abarth-origin-03.html it looks like your client is wrong
<rogpeppe2>   serialized-origin = scheme "://" host [ ":" port ]
<hazmat> rogpeppe2, depends .. looking at the websocket spec.. its not clear that's it meaningful.. the client can fake whatever they want.. so the server checking here is mostly just of the obnoxious broken sort.
<hazmat> http://learnitcorrect.com/blog/websocket-is-great-but-not-the-origin-policy.html
<rogpeppe2> hazmat: i'm with you that the origin header is fundamentally weird and probably broken
<rogpeppe2> hazmat: but that doesn't mean that the websocket code isn't correct to check it for syntactic correctness
<hazmat> rogpeppe2, the checking is also optional
<hazmat> what broke is the changing from optional to required
<rogpeppe2> hazmat: yeah
<rogpeppe2> hazmat: looks like i can get around it easily though
<hazmat> rogpeppe2, thanks for debugging with me
<hazmat> i'll workaround in the client
<rogpeppe2> hazmat: by creating websocket.Server rather than using websocket.Handler directly
<rogpeppe2> hazmat: and using a nil handshake function
<hazmat> rogpeppe2, yeah.. i was wondering why you were doing it that way.. ie not using most of the stuff in the server.go
<rogpeppe2> hazmat: all that stuff is new
<hazmat> ah
<rogpeppe2> hazmat: with r48
<rogpeppe2> hazmat: sorry, 49
<rogpeppe2> hazmat: i wonder if the default is wrong. who gives a f*** about Origin?
<hazmat> rogpeppe2, or more to the point, it looks like its there as a policy hook point for people that provider custom handshakes that do care.. just to avoid them having to do the origin parse themselves, as is its mostly useless though
<rogpeppe2> hazmat: yeah. it's a pity that the default is to do a meaningless check on a header that noone cares about though.
<hazmat> rogpeppe2, revno 51.. summary:     go.net/websocket: fix handshake error.
<hazmat> rogpeppe2, agreed
<hazmat> rogpeppe2, or even if they cared about is trivially faked
<rogpeppe2> hazmat: i'm not sure r51 fixes the issue we're seeing here.
<hazmat> rogpeppe2, it doesn't
<rogpeppe2> hazmat: i think the point is to avoid hoaxing people using normal browsers
<rogpeppe2> hazmat: because you can't fake it from js
<rogpeppe2> hazmat: i may be wrong though. it always seemed odd to me.
<hazmat> rogpeppe2, released new client versions w/ workaround/proper origin, thanks again
<rogpeppe2> hazmat: np. i learned something new :-)
<rogpeppe2> hazmat: i think i'll change the server to ignore the origin explicitly
<mramm> Anybody going to the virtual UDS Juju Core session at 19:05 UTC?
<mramm> http://summit.ubuntu.com/uds-1305/meeting/21818/juju-core-development/
<mramm> I will be there, but would appreciate help from anybody from core or blue that can attend.
<rogpeppe2> mramm: i'm out i'm afraid
<rogpeppe2> mramm: just leaving now
<mramm> rogpeppe2: understood
<mramm> just putting it out there ;)
<rogpeppe2> mramm: i finally have internet back BTW
<mramm> rogpeppe2: awesome!
<rogpeppe2> mramm: lots of ancient lead wiring replaced apparently
<rogpeppe2> mramm: so my connection may get faster
<rogpeppe2> mramm: (takes 5-6 days to ramp up they said)
<mramm> rogpeppe2: that is interesting
<mramm> rogpeppe2: strange but interesting
<rogpeppe2> mramm: apparently there *is* a button they can push to say "we know we just replaced the cable, so try the faster speed now" but they're not allowed to use it.
<mramm> rogpeppe2: interesting
<rogpeppe2> g'night all
<dpb1> Hi -- is this a known issue? Am I doing something wrong? var/lib/go/src/launchpad.net/juju-core/environs/openstack/provider.go:547: undefined: identity.AuthKeyPair (during go install -v launchpad.net/juju-core/...)
<mramm> dpb1: I have not seen it, but perhaps davecheney will know more than me
<mramm> seems like a version mismatch between juju-core and goose (the openstack API library)
 * davecheney pricks up his ears
<davecheney> i'm not really here (waiting for a flight)
<davecheney> but I can try to help
<dpb1> davecheney, mramm: if you need me to try something out, let me know
<dpb1> interesting... go get is pulling in old bits for goose.  /me looks into why
<davecheney> dpb1: the simplest way to fix this is
<davecheney> rm -rf $GOPATH/src/launchpad.net/goose
<dpb1> ok.
<davecheney> go get -u -v launchpad.net/juju-core/....
<davecheney> there are more complicated explanations
<davecheney> but this one will get you going
 * dpb1 tries
<dpb1> davecheney: awesome.  that is working.  I see the parent branch changed locations.  I guess go doesn't better deal with that?
<davecheney> the support for bzr in the go tool is best effort
<davecheney> we've moved the bloody project that many times
<davecheney> maybe it would be easier to update the instructions to not use the go tool, and just tell people which packages to branch
<dpb1> davecheney: it is nice to bootstrap.  about as dead simple as I have ever seen a project. :)
<davecheney> i don't think we (at canonical) are paying enough attention to what happens when we move projects around
<davecheney> i'll add some words to the README
<dpb1> k
<dpb1> thx, enjoy your flight. :)
<davecheney> dpb1: email me, david.cheney@canonical.com if you get stuck again
<dpb1> davecheney: sure thing
#juju-dev 2013-05-15
<jam> wallyworld: you're running a juju test right now, correct?
<wallyworld> jam: yes
<wallyworld> it just finished
<jam> wallyworld: not a problem, just saw some active images and wanted to double check.
<wallyworld> jam: i'm checking also - i'm about to kill those since they are left over
<wallyworld> i've run a lot of live tests today
<wallyworld> finally got them passing
<jam> wallyworld: np, I'm just starting one up myself, but it is a t1.micro for some testing.
<jam> wallyworld: great to hear that you got them passing.
<jam> Now, we just need to get them continually passing :)
<wallyworld> yep :-) plus they take soooooo long
<wallyworld> so the code/test cycle blew out a bit
<wallyworld> jam: just to make 100% sure - i've terminated all my mediums and left a micro running
<jam> sounds good
<jam> wallyworld: yeah. I understand. I wonder how much of that is required. I guess some of the time is that EC2 takes a bit longer to spin things up?
<jam> morning dimitern
<dimitern> morning all
<jam> wallyworld: though also the local "live" tests are also quite a bit slower on ec2 because of the automatic S3 consistency retry code.
<wallyworld> jam: i haven't profiled it but i do think spin up time accounts for a lot, as it seems to run through stuff ok (but a little slow) once the instance is running
<wallyworld> fwereade: hi there, i'm off to soccer training for a few hours. perhaps while i'm gone you could look at my latest ec2 live test fixes mp. there's one thing i'm not 2100% sure on - i've commented in the cover letter
<fwereade> wallyworld, will do
<wallyworld> thanks. talk later
<fwereade> wallyworld, but I only demand 1800% certainty ;p
<wallyworld> typo!
<dimitern> fwereade: so api work is on now, right?
<fwereade> dimitern, yeah, that's top of the list
<fwereade> dimitern, is rog around today, do you know?
<dimitern> fwereade: i'm not aware he's away at least
<dimitern> go 1.1 is released now, so I'm switching to it (as we all should)
<fwereade> dimitern, +1
<fwereade> hey, does the "Title" field in a charm.Option ring any bells with anyone?
<rogpeppe2> mornin' all
<dimitern> rogpeppe: morning
<dimitern> fwereade: what's "change agents to use API connection where available"? how could it be unavailable?
<jam> dimitern: I believe that means "where there is an API that has been written, make sure agents are using the API rather than direct DB access"
<fwereade> dimitern, jam, sorry that was unclear
<dimitern> jam: I see ok
<fwereade> dimitern, jam: I don't think an API connection *is* generally available though
<dimitern> fwereade: but it must, eventually
<fwereade> dimitern, jam: *maybe* we always write sensible API info
<fwereade> dimitern, yeah, that step is really just "make sure that we always start an API connection"
<fwereade> dimitern, with a side order of "hmm, what if we're an API server"
<dimitern> fwereade: ok, it looks like a good candidate for a card
<jam> fwereade: we do always set APIInfo in the start instance code.
<fwereade> dimitern, sgtm
<dimitern> btw i'm getting test failures in trunk after a fresh rebuild with go1.1 - http://paste.ubuntu.com/5666973/
<fwereade> jam, ok, cool -- but I'm not sure that all the pieces are actually joined up, just that the environs probably do the right thing does not imply anything about either the input or the agent itself
<jam> dimitern: it looks like you're getting a panic running Main which obviously means you don't get 'help' and changes the return code.
<dimitern> jam: i was thinking these tests rely on having jujud binaries - i did go install and running the tests again
<dimitern> nah, still the same failures
<dimitern> anyone seen these or should i file a bug?
<dimitern> (any why does it say $GOPATH not set when it is set?!)
<jam> dimitern: is the test suite isolating it from us?
<dimitern> jam: not sure what do you mean - but running  the tests in isolation produces the same errors
<rogpeppe> dimitern: hmm, odd
<jam> dimitern: I mean that the test suite infrastructure is sanitizing environment variables
<jam> like GOPATH
<jam> though given the 'build' (?) package, you'd think we'd need it.
<rogpeppe> jam: yes, i'm wondering that
<dimitern> jam: that's possible but a silly thing to do :)
<rogpeppe> jam: but i don't have a problem, i don't think
<rogpeppe> will try again
<jam> it is usually good to sanitize some variables, but GOPATH seems foolish to change.
<dimitern> that's go 1.1 specific perhaps?
<jam> dimitern: I think just tracking into the panic is likely to be fruitful, but if GOPATH is getting unset that looks worrying, too.
<dimitern> although on friday I was running on go1.1rc3 all the tests from a fresh build & checkout w/o any errors
<dimitern> jam: i'll take a look what got landed since then first
<jam> dimitern: certainly if they were using normal "Release Candidate" naming, nothing should land but a version bump.
<jam> otherwise they should have had a new "candidate"
<jam> but I don't know go core policy
<rogpeppe> jam: yes, i think that's what happened.
<rogpeppe> jam: rc3 became 1.1
<dimitern> jam: no i mean i need to see what changed in juju since friday so it fails now, whereas it wasn't failing with 1.1rc3 on friday
<jam> ah, sure
<rogpeppe> all jujud tests pass for me against 1.1
<dimitern> rogpeppe: yeah, i also suspect my setup could be somehow wrong: i have ~/go/1.1/ (goroot); ~/work/go/1.1/ (gopath) both set and ~/src/1.1/juju-core (symlink to gopath/src/lp.net/juju-core)
<rogpeppe> dimitern: something looks very odd
<rogpeppe> dimitern: that traceback looks fishy
<rogpeppe> dimitern: have you tried removing $GOPATH/pkg and recompiling?
<dimitern> rogpeppe: no, i'll try - however everything was clean when I started (created the dirs empty and then rebuilt 1.1 then go get -u lp/juju-core/..., etc)
<rogpeppe> dimitern: what happens if you do "go test -i" in cmd/jujud ?
<mgz> jam: will have to miss standup today, have appointment in town across it
<dimitern> rogpeppe: completes in a couple of seconds w/o errors
<dimitern> rogpeppe: still running the full test suite though
<dimitern> rogpeppe: still the same failures
<rogpeppe> dimitern: is that the only package that fails?
<dimitern> rogpeppe: yes
<rogpeppe> dimitern: that's very odd, because lots of other packages import juju-core/testing, and it's an init function in there that's failing
<rogpeppe> dimitern: how about putting a printf in testing/charm.go, in the init function that calls build.Import ?
<dimitern> rogpeppe: i don't think the problem is not finding testing at all - it some weird way of invoking the commands that screws up the env vars
<rogpeppe> dimitern: print the value of os.Getenv("GOPATH") and perhaps os.Getenv("GOROOT") too
<rogpeppe> dimitern: ah, i see the problem
<rogpeppe> dimitern: hmm, maybe not
<dimitern> rogpeppe: nothing is printed out with the failures
<dimitern> 	fmt.Printf(">>> GOPATH = %s; GOROOT = %s\n", os.Getenv("GOPATH"), os.Getenv("GOROOT"))
<dimitern> added that as a first line in init() in testing/charm.go
<rogpeppe> dimitern: what do you see if you add a string to the panic in check. (e.g. panic(fmt.Errorf("check failed: %v", err))) ?
<rogpeppe> dimitern: if you don't see the extra string, there's something odd going on
<dimitern> rogpeppe: checking
<rogpeppe> dimitern: it might also be worth printing the value of ps.Env in jujud.run
<rogpeppe> dimitern: to make sure it looks sane
<dimitern> rogpeppe: nothing; i think that's not the check() that gets called - it's in cmd/jujud/_test/jujud.test
<rogpeppe> dimitern: i'm not sure what you mean there
<rogpeppe> dimitern: so you're saying you don't see the extra "check failed" message?
<dimitern> rogpeppe: just a sec
<dimitern> rogpeppe: my emacs setup was not finding gofmt and not saving the files :|
<rogpeppe> dimitern: ah, that might explain some things :-)
<fwereade> jam, responded on https://codereview.appspot.com/9175043/ - let me know if anything's clearly insane ;p
<rogpeppe> anyone know how i can change which browser gets started by default when i click on a link outside the browser, BTW? since i upgraded to raring, it's always choosing firefox and i want chrome
<mgz> rogpeppe: should be settable under default applications, see askubuntu google results
<rogpeppe> mgz: i couldn't think of a decent search term
<mgz> there are like, four different underlying mechanisms
<rogpeppe> mgz: ah, System->Details!
<rogpeppe> mgz: that's a bloody obscure place to keep it
<rogpeppe> mgz: hmm, my default browser *is* chrome
<rogpeppe> mgz: i guess one of the other mechanisms is kicking in
<mgz> so, you can also check `update-alternatives --config x-www-browser`, the $BROWSER envvar, and mime types if you get desperate
<rogpeppe> mgz: update-alternatives prints this: http://paste.ubuntu.com/5667132/ (i.e. it looks like chrome is the default, although i don't know what "manual mode" is)
<rogpeppe> mgz: $BROWSER isn't set
<rogpeppe> mgz: i'm not sure how mime types would come into play when clicking a link in my irc browser
<jam> rogpeppe: is your irc in a browser already? Or perhaps a Mozilla based one?
<rogpeppe> jam: no. i use Konversation
<rogpeppe> jam: and it worked fine before upgrading
<jam> rogpeppe: http://docs.kde.org/stable/en/extragear-network/konversation/webbrowser.html ?
<rogpeppe> jam: good catch, thanks!
<rogpeppe> jam: yeah, that works
<rogpeppe> jam: i wonder why it changed
<jam> rogpeppe: did you have to set a new one, or was something already set?
<rogpeppe> jam: "use a custom browser" was unchecked, but the text in grey said "firefox"
<rogpeppe> jam: i looked at that settings panel too - just missed the setting
<jam> fwereade: so why is a slice + channel for a "self mutexed" variable better than just putting a mutex around the variable?
<jam> I'm a little confused by your statement that it is good for N goroutines, but then follow it up with "more than one goroutine renders this technique worthless"
<fwereade> jam, the testing is worthless if you don't know what transaction you'll be trying to run -- but the code itself does in fact have to work in concurrent conditions
<fwereade> jam, I could plausibly instead switch out a transaction runner at test time, but that felt like an additional layer for not much benefit
<fwereade> jam, wrt the one-buffered channel it just ...seemed cleaner to me
<fwereade> jam, lock/change/unlock/lock/change/unlock feels like more work and easier to mess up that pop/push/pop/push
<jam> fwereade: so I don't quite understand why you need to set it to nil when you aren't sure that you're actually done with the thing, I think that is my big sticking point.
<jam> especially setting it to nil, only to pop that back off again once you start actually doing something.
<fwereade> jam, I need to set it to nil while the hooks are run so that they can themselves run transactions
<jam> fwereade: what happened to only 1 transaction under test?
<fwereade> jam, ...that's the point
<fwereade> jam, there is only one transaction under test
<jam> fwereade: so you're missing my point, then.
<jam> yes, you should only test 1 transaction per test case.
<fwereade> jam, sounds like )
<jam> but you should be explicit about which one you are testing during the test
<jam> in case the specific ordering of actual transactions
<jam> changes
<jam> and things suddenly pass/fail for odd reasons.
<jam> (be explicit so side effects don't confuse you)
<jam> if multiple transactions are occurring during the test case
<fwereade> jam, I'm not sure what sort of situation you're describing
<jam> then your method only allows you to ever test the "first" transaction hit.
<jam> if the code ever changes
<jam> and order of operations (say a new action is done)
<jam> then the test breaks which might be hard to reason about why
<jam> or it doesn't break
<fwereade> jam, where do we use multiple transactions in a state method (that aren't obviously wrong, and candidates for fixing)?
<jam> but you stop testing what you thought you were.
<jam> fwereade: you just said "I need to set it to nil so that they can run transations"
<jam> is that so the hooks themselves, but not other code.
<jam> I think I misread that sentence.
<fwereade> jam, how should I break state for the txn under test *wuthout* running others?
<jam> I thought it was "so that stuff going on during the transaction can run transations"
<jam> fwereade: well, since TXN is purely opt-in, you could always break the DB at any time :)
<fwereade> jam, ah sorry no -- I just mean so that the hooks themselves can run transactions
<fwereade> jam, not in a useful way, though, I think
<jam> however, that is a moot point, though a potentially interesting tangent.
<jam> anyway. I'm still generally in favor of getting an error of the form "the transaction you thought you were testing is not the one that is being run" rather than "did not get ErrAborted"
<fwereade> jam, I did ponder passing ops into the hooks, but I thought that'd probably encourage overly brittle testing
<fwereade> jam, and I'm not sure what if anything the hook name would tell you -- I'm probably misunderstanding again
<jam> fwereade: I like having arbitrary callbacks personally. Since you may need to do some inspection/etc rather than just ops on the db
<jam> fwereade: so the "runTxn" function would become "runTxn(name string, ops []txn.Ops)"
<jam> and the hooks would get a descriptor of what name they are associated with
<jam> and you would get a direct error/panic if runTxn was running something that didn't match the name in the hook.
<jam> (in other systems, I just wouldn't run the hooks, but you mention you want to be clear that only 1 transaction is ever running under test)
<fwereade> jam, that's more a goal statement than a position statement, but offhand I'm not sure how bad we are there
<jam> fwereade: anyway, your system is fine (as I'm pretty sure I've stated). I think I'm being a bit overbroad about an idea of having hooks executing before and after transactions, in which case you want to name the thing you are running before or after.
<fwereade> jam, hmm, I do *kinda* like the idea of naming transactions but I'd prefer to let it marinate a bit
<jam> fwereade: another small bit is the "one transaction run" rule, which is slightly violated by the design. In that you have a chain of before/after/before/after.
<jam> And in your current method
<jam> those "should" be the same transaction being run in a loop
<jam> because that is how you are testing it
<fwereade> jam, same transaction doesn't imply same ops
<jam> fwereade: sure, but my point is, the design is perfectly amenable to "run txn A, then txn B, then txn C"
<jam> except it doesn't actually track that
<jam> (as in, you could use the structure you set forth to test a function which ran 3 separate transactions linearly)
<jam> but if the code underneath changed from A B C to A C B the test infrastructure is all lined up
<jam> but the assertions all break
<jam> and it could be helpful if you were informed directly about the precondintions (A B C) being violated.
<fwereade> jam, my point is that a state method doing A B C is Doing It Wrong
<fwereade> jam, and that testing 3 state methods in one go is kinda pointless
<jam> fwereade: in which case, having an assertion that you *aren't* doing A B C seems like a win as well
<fwereade> jam, not sure how I'd do that...
<jam> fwereade: as I said before, what you did works, and is better than not having it. I'm happy to have a discussion about ways I think it could  be better.
<jam> fwereade: if you name the transactions, then the thing that installs the hook names it
<jam> then you just check the name matches
<fwereade> jam, (that's what I think we're doing :))
<jam> fwereade: right. a couple of your statements made it feel like I was blocking you, which I'm not trying to do.
<fwereade> jam, ah, sorry, not intended
<fwereade> jam, I'm just not 100% sure that named transactions really help all that much... but nor am I sure they hurt that much either ;)
<fwereade> jam, I expect we'll figure out what really work in practice when we try to write tests for the cases I haven't thought of yet ;)
<jam> fwereade: so. I think my point boils down to, if doing X is "Doing it Wrong" lets try to add bits into the system to make it hard to "Do it Wrong" rather than trusting that we'll catch it in review, etc.
<jam> wallyworld, dimitern: ping for standup
<dimitern> jam: just a sec
<dimitern> rogpeppe: how is the errors package going?
<rogpeppe> dimitern: i'm hoping to write the tests later today - i'm just polishing up my rpc package changes to propose
<dimitern> rogpeppe: ah ok, can't wait to start using it! :)
<rogpeppe> dimitern: here\'s the doc for the revamped rpc API BTW. feedback appreciated: http://paste.ubuntu.com/5667354/
<wallyworld> rogpeppe: hey, when you get a spare moment (or are bored), could you take another look at the simplestreams stuff. i think/hope i've covered all the necessary fixes etc.
<rogpeppe> wallyworld: will do
<wallyworld> thanks. there's now 4 branches to potentially look at :-)
<wallyworld> i'll land them all at once
<rogpeppe> wallyworld: could you give me links to them in pipeline order, please?
<wallyworld> rogpeppe:
<wallyworld> https://codereview.appspot.com/9138044/
<wallyworld> https://codereview.appspot.com/9128047/
<wallyworld> https://codereview.appspot.com/9130044/
<wallyworld> https://codereview.appspot.com/9419047/
<wallyworld> thanks :-)
<rogpeppe> wallyworld: ta
<rogpeppe> fwereade, dimitern, jam: reviews appreciated - i *think* this is a significant improvement. https://codereview.appspot.com/9410043
<dimitern> rogpeppe: looking
<mramm> morning everybody
<mgz> morning mramm
<mramm> friendly neighborhood reminder: kanban board review in 10 min
<dimitern> is this the link? https://plus.google.com/hangouts/_/539f4239bf2fd8f454b789d64cd7307166bc9083
<mramm> dimitern: yes
<mramm> rogpeppe: ^^^^
<rogpeppe> dimitern, fwereade: https://codereview.appspot.com/9426045
<dimitern> rogpeppe: ah cool!
<rogpeppe> dimitern: did you get any further with the rpc review?
<dimitern> rogpeppe: will be done shortly, sorry got distracted a bit
<rogpeppe> dimitern: np
<rogpeppe> i'm taking a lunch break now. back soon.
<rogpeppe> back
<mgz> late lunch :)
<dimitern> rogpeppe: 2 reviews done
<rogpeppe> dimitern: thanks!
<rogpeppe> right, that's me for the day
<rogpeppe> g'night all
<mattyw> QUESTION: I'm a bit confused by the idea of the contrib directory. Are we saying this is where contributers would merge to, and then it would get taken into 'main' when it was deemed ready?
<mattyw> sorry - wrong place :(
#juju-dev 2013-05-16
<jam> morning dimitern
<dimitern> jam: morning
<rogpeppe> jam, dimitern: mornin'
<jam> morning rogpeppe
<dimitern> rogpeppe: heyhey
<wallyworld_> fwereade_: later when you have a moment, this will interest you https://codereview.appspot.com/9303051
 * wallyworld_ dinner
<fwereade_> wallyworld_, cheers
* ChanServ changed the topic of #juju-dev to: https://juju.ubuntu.com | On-call reviewer: dimitern | Bugs: 8 Critical, 68 High - https://bugs.launchpad.net/juju-core/
<dimitern> oh, I just realized I'm the OCR today
<dimitern> bring it on! :)
<mgz> me passes dimitern a document in particularly bad handwriting
<dimitern> mgz: not that kind of OCR :D
<jam> mgz: I wanted to chat with you a bit about the version dependency stuff.
<jam> I saw that you had a data file listing everything.
<mgz> jam: let's do that
<jam> mgz: um, I was hoping to learn the context and what code you were actually using, etc.
<mgz> ah, not literally a chat?
<mgz> so, what we have:
<jam> mgz: ah, I misunderstood the "lets do that"
<jam> I'm fine voice chatting.
<jam> I thought you were saying "lets do that version dependency stuff"
<mgz> * kapil's script that reads a text file and updates branches lp:goreq
<jam> mgz: I'm on mumble if you want to join me.
<mgz> * roger's project that derives dependencies by looking at go packages lp:godep
<mgz> * I wrote a throwaway thing for generating a release tarball, which is up in a juju-core branch under ~gz
<mgz> so, we really want to combine those bits into something that gets the bot off the ground
<mgz> * lp:godeps
<mgz> ...and actually, need the branch
<mgz> lp:~rogpeppe/godeps/03-clean
<mgz> fwereade_: ARE YOU FREE?
<mgz> gah, sorry, caps
<fwereade_> mgz, hey, yeah
 * fwereade_ was briefly worried that he'd just been staring into space for an hour or something ;p
<mgz> hace a moment to talk constraints briefly with me and wallyworld_?
<wallyworld_> hace?
<mgz> have
<fwereade_> mgz, wallyworld_, sure
<wallyworld_> fwereade_: mgz can't do google
<mgz> I can atm
<wallyworld_> really?
<danilos> mgz, just remap that useless Caps key to Control and all your troubles will go away :)
<fwereade_> sweet, because I forgot to set up mumble again
<mgz> I have a non-ubuntu machine here :)
 * wallyworld_ starts a hangout
<wallyworld_> fwereade_: mgz: https://plus.google.com/hangouts/_/d3f48db1cccf0d24b0573a02f3a46f709af109a6
<jam> mgz: very frustrating. Identical config, but 'test' properly runs and fails the test suite, but "trunk' does not
<jam> http://paste.ubuntu.com/5670575/
<jam> anyway, I'm off for now.
<mgz> hm, crazy
<rogpeppe> fwereade_: any chance of a review of https://codereview.appspot.com/9410043/ ?
<fwereade_> rogpeppe, ah, sorry, I'll finish that up
<rogpeppe> anyone else too. it's big, it's quite a big CL i'm afraid, but the more eyes the better
<rogpeppe> fwereade_: np
<sidnei> is there any document that i can follow to get started on submitting changes to juju-core?
<mgz> sidnei: see CONTRIBUTING in lp:juju-core
<sidnei> cool, thanks!
<mgz> you may want to not use cobzr though, and use native colo, or your own arrangement instead
<sidnei> im happily using cobzr elsewhere
<mgz> then stick with it.
 * fwereade_ is off for the day, take care & have fun everybody
<rogpeppe> fwereade_: see ya
<mramm2> so it is not clear to me if all implementations of websockets actually use the heartbeat stuff
<mramm2> some browsers do, others don't
<mramm2> and I have not yet seen how the go implementation works
<mramm2> rogpeppe, fwereade_: ^^^^
<rogpeppe> mramm2: thanks
<rogpeppe> mramm2: there's no mention in the go source code of heartbeats
<rogpeppe> mramm2: the diagram on this page is useful http://en.wikipedia.org/wiki/Comparison_of_WebSocket_implementations
<hazmat> mramm2, most do.. not sure that go does
<hazmat> er.. ping/pong is what i meant
<hazmat> i didn't know there was a separate heartbeat
<hazmat> isn't that just a ping on a timer
<mramm2> it pretty much is
<mramm2> everybody responds to ping/pong
<mramm2> http://en.wikipedia.org/wiki/Comparison_of_WebSocket_implementations
<hazmat> per the spec heartbeat is just unsolicited pong, no response expected
#juju-dev 2013-05-17
* ChanServ changed the topic of #juju-dev to: https://juju.ubuntu.com | On-call reviewer: - | Bugs: 8 Critical, 68 High - https://bugs.launchpad.net/juju-core/
<rogpeppe> mornin' all
 * fwereade_ lunch
<danilos> mgz, dimitern, hi, I'm not feeling well enough to have a call now, will likely file a sick day :/
<dimitern> danilos: ok, get well soon!
<danilos> dimitern, cheers
<mgz> okay dimitern.
<mgz> call anyway, or just crack on?
<dimitern> mgz: can we just skip it today?
<mgz> sure.
<dimitern> cool
<mgz> btw poke me for ocr reviews everyone. I'll leave some comments in Ian's branches
<marcoceppi> I was poking around the help for juju-core 1.10, what version (if any) can you specify an alternate .juju/environments.yaml (or different .juju "home")?
<marcoceppi> I didn't see it in the help docs in 1.10
<fwereade_> marcoceppi, 1.10 will respect the JUJU_HOME env var, in which yu can put your alternative environments.yaml
<marcoceppi> fwereade_: thanks, that's what I was looking for!
<fwereade_> marcoceppi, yw :)
<rogpeppe> marcoceppi: there's also JUJU_ENV
<rogpeppe> marcoceppi: i think py and go environments can coexist in the same file if you want
<sidnei> oh, that's something i hadn't thought about
<marcoceppi> rogpeppe: I have a few that do, but this was specifically for juju-testing which has an --isolate option I'm trying to replicate
<marcoceppi> Which leads me to my next question
<marcoceppi> In pyjuju there's a DELEGATE_CHARM and DELEGATE_REPOSITORY environment variable that _can_ be set (according to the jitsu test code). Does this notion exist in the go version?
<fwereade_> marcoceppi, sorry, I don't think so -- what's it for? is it perhaps jitsu-specific?
<marcoceppi> fwereade_: I think it was something baked in to pyjuju for testing specifically. I'm not too worried about it for go-juju at this point, but I think it was a way to get around having juju deploy <charm> actually do a local deploy /instead/ of from cs
<rogpeppe> right, i'm done
<rogpeppe> g'night all
#juju-dev 2013-05-19
<thumper> morning folks
<thumper> davecheney: hi
<thumper> davecheney: I have some go questions for you
<thumper> davecheney: got some time?
<davecheney> thumper: shoot
<thumper> davecheney: I want to run a collection of commands in parallel, and have each of those commands execute another app, however instead of waiting for it to definitely finish, wait for a defined time, and return the combined output if it finished and something else if it didn't
<thumper> the Command object doesn't allow a timed wait
<thumper> and I want the outer function to gather the results
<davecheney> thumper: no, you should spin off a goroutine to do this
<davecheney> i *believe* that worker/uniter already does exactly this
<thumper> hmm...
<thumper> I know that it should be theoretically possible
<thumper> but I'm struggling with the go routine structure, and communication using tombs
<thumper> since the os/exec package doesn't have a timed wait
<thumper> only a definite wait
<thumper> so we need more go routines, yes?
<davecheney> you
<davecheney> yup
<davecheney> i think something that sits in select { case <-tomb.Dying: // everything is fine, exit ; case <- timeout: cmd.Kill()
<thumper> since I'm wanting to simultaneously run X commands in parallel
<thumper> I have a feeling I need multiple tombs
<thumper> and can't really do with one
<davecheney> this is going to need some scaffolding
 * thumper nods
<thumper> let me explain what this is for
<thumper> I want to have "juju help plugins"
<thumper> it will call "juju-<pluginName> --description" for each plugin
<thumper> but it only waits 1s (or some value)
<thumper> and if the plugin takes too long to return
<thumper> it kills it and says "took too long to respond"
<thumper> that way we can gather descriptions for all plugins in ~1s
<thumper> make sense?
<davecheney> yup
<davecheney> if you want to wait on multiple goroutines, the common pattern is a fan in via a channel
<thumper> I have a method that returns []string for all the plugins it found
<thumper> right
<thumper> I got that far :)
<thumper> it is the timed killing and appropriate waits that I'm struggling with
<thumper> I feel that given enough time (like hours this afternoon), I could come up with something hackish
<thumper> but was wonering if you had a more concise solution in less time :)
<davecheney> gimme a few mins to sketch something out
<thumper> ta
<thumper> I have a test framework that I can plug the method into already
<thumper> yay tests
<thumper> davecheney: I'm going to leave shortly for the gym, but will check back in when I return :)
<davecheney> thumper: nearly done
<davecheney> i have something working
<thumper> davecheney: that's awesome!
<davecheney> thumper: http://play.golang.org/p/3Avy6eHj4K
<davecheney> what I have so far
<thumper> ok, I'll plug it in to my testy things and check back after lunch
<thumper> just putting gym shoes on
<thumper> and thanks
#juju-dev 2014-05-12
<davecheney> oh ffs
<davecheney> There is a problem connecting to this video call. Try again in a few minutes.
<davecheney> FAAAAAAAAAAAAAAARK
<davecheney> thumper: right, sorry about that
<davecheney> i'll use a different computer tomorrow
<thumper> shit internet or shit computer?
<thumper> is your laptop not happy with trusty?
<waigani> okay, so how do I resolve this: http://paste.ubuntu.com/7449953/
<waigani> I'm using ec2
<waigani> i'm trying to destroy the vanilla service and redeploy it
<davecheney> thumper: tusty + chrome == failboat
<davecheney> will just use a mac tomorrow
<davecheney> thumper: how come we're doing this identity work
<davecheney> this is something green are pushing
<davecheney> ie, they need it
<davecheney> they are probably in the best place to describe what they need
<menn0> davecheney: weird. I'm on trusty + chrome and hangouts are working ok
<thumper> davecheney: you mean emerald?
<davecheney> thumper: i mean casey
<thumper> :)
<davecheney> didn't casey and rog spend a week whiteboardin this ?
<thumper> some of it
<thumper> there was a big focus on jaaz identity
<thumper> which is on their plate
<thumper> we are looking at it from the juju-core side
<waigani> menn0: I just saw "juju resolved -r <unit-name>". -r = re-execute failed hooks
<waigani> looks like I'll have to blow away the env and start again though
<menn0> waigani: yep. thumper mentioned that just before the hangout
<waigani> is this a bug that I've hit though? I've got a dying service that I can't redeploy or resolve
<thumper> waigani: dude... use the long names
<thumper> it is ueasier
<waigani> thumper: okay, okay
<davecheney> waigani: if it is in state dying
<davecheney> and the machine that host's it gone
<davecheney> then you're sorta screwed
<davecheney> s/it/is
<davecheney> waigani: i'm assuming the local provider ?
<waigani> yep, this is the case.
<waigani> davecheney: ec2
<davecheney> ORLY
<waigani> but how can I get into that state so easily?
<davecheney> btw, does everyone know about the juju-local footgun ?
<waigani> nop
<davecheney> ie, you *MUST* install juju-local to use juju at all
<davecheney> even from source
<davecheney> but if you do that, /usr/bin/juju will take precidence in your path
<thumper> davecheney: it complains now if you don't
<thumper> davecheney: I explicitly set my PATH in .bashrc
<thumper> to have $GOPATH/bin first
<davecheney> so unless you're paying a lot of attention, you won't be using the juju you think you are using
<davecheney> and bootstrap --upload-tools will upload the wrong one
<davecheney> thumper: yes there are a few workarounds
<davecheney> 1. put $GOPATH/bin in the top of your path
<thumper> I do think that most people who compile from source are aware of this...
<davecheney> 2. there is apparently a tool which can make up fake packages just to shut up apt, sinzui uses it
<davecheney> thumper: i've found one on this channel this morning who wasnt :)
<davecheney> thumper: this is an unbelievable cockup
<davecheney> is anyone looking at it ?
<davecheney> https://bugs.launchpad.net/juju-core/+bug/1306544
<_mup_> Bug #1306544: developing juju requires juju-local  to be installed <juju-core:Won't Fix> <https://launchpad.net/bugs/1306544>
<davecheney> i don't agree with this issue status
<wallyworld_> axw: morning, good weekend?
<axw> wallyworld_: heya. hectic weekend
<axw> house hunting & mothers day
<axw> and yourself?
<wallyworld_> well, i had the latter, but not the former
<wallyworld_> and a wedding
<wallyworld_> bit sick sunday morning
<axw> self inflicted? :)
<wallyworld_> yeah :-(
<wallyworld_> quick catchup?
<axw> sure
<menn0> review please: https://codereview.appspot.com/97330044
<thumper> menn0: done
<menn0> thumper: thanks
<waigani> menn0: did you use the mysql charm at all?
<menn0> waigani: no I haven't looked at it. I found the postgresql charm to be pretty useful to look at though.
<waigani> I have a relation-changed hook, which is meant to grab "user", i.e. relation-get user - but user never gets set my mysql
<waigani> at least I assume it doesn't
<davecheney> waigani: the relatino-* hooks get run multiple times
<davecheney> so generally you need to put guards in place to bail out if the relation value isn't set yet
<waigani> davecheney: so I should be patient?
<davecheney> waigani: you just need to exit 0 if you are waiting for more information
<davecheney> in theory the remote side will set some more relatoin values later and your hook will be called again
<waigani> davecheney: yep, already doing that. mysql has been up for ages. I fixed the install hook in my webservice a few times. Got it all working. BUT can't get user from relation-get yet.
<waigani> no I've ironed out the bugs, I might destroy env and bootstrap/deploy again
<thumper> jam: o/
<thumper> jam: we probably need to find a different time for our call as my girls have ice-skating now on a monday afternoon
<jam> thumper: np
<jam> is there a time you have in mind?
<thumper> not really...
<thumper> jam: what time do you normally start your work day?
<jam> thumper: officially in 1.5hrs
<jam> but we had our 1:1 an hour before I started when DST was different
<jam> thumper: and, ya know, occasionally I'm online a bit earlier than that. Espec. when my wife is away :)
<thumper> hmm...
<thumper> ya know
<thumper> pretty much every day sucks :)
<thumper> tuesday's probably suck least
<jam> thumper: we can go in your evening if that is better for you
<jam> Its great for me, but probably sucky for you
<thumper> perhaps monday evening, and I could try to get you and william done together
<thumper> :)
<thumper> at the moment william is missing my 9am timeslot (11pm for him)
<thumper> not entirely surprising really
<jam> well, I've been waking up at 1UTC (5am), because I'm trying to take the dog for a walk before it gets too hot, and thus before I have to get my son ready for school, etc.
<jam> I believe that slot is 2am for me, so that wouldn't work either
<jam> but your evening is my mid-day
<wallyworld_> jam: hiya, a few of us talked about having a kanban board for each team (since there's now 5 teams). woud you be happy with that?
<jam> thumper: so your monday evening or same time on Tues is fine with me. I need to know about Monday since I'll probably have to move around my team 1:1's, but that is generally more flexible than our overlap.
<jam> wallyworld_: not very happy, though I'm not sure how to make it all work.
<jam> I'm really concerned about people losing visibilty outside of their small squad
<jam> but I certainly understand you can't keep fine grained visibility over 20 people
<wallyworld_> sure, but i can't see how we can manage sooo many cards, especially if we plan 2 weeks out
<wallyworld_> maybe a lane per squad then for the 2 week cards
<wallyworld_> ie i want to start adding cards for the next 2 weeks but there's nowhere really to put them
<jam> wallyworld_: right, lane per squad was the hope
<wallyworld_> jam: i haven't got editing permissions on the board - are you able to add a tanzanite lane?
<waigani> is environments.yaml only used on the initial bootstrap to create the jenv? Is it ever used after jenv is created?
<jam> I don't have great answers here. I was hoping to find some way to balance getting some cross coverage without having all of it.
<jam> wallyworld_: I'll just give you edit rights, just a sec
<wallyworld_> ta
<wallyworld_> waigani: nope, not used after jenv is created
<waigani> why do we keep it around then?
<wallyworld_> jam: we can/should discuss the best approach but till then a lane is great so we can at least start planning
<jam> waigani: well for one env.yaml has many environs in it
<wallyworld_> waigani: so it can be edited for next time, and histerical reasons
<jam> and 2, it is the place that users wrote their stuff
<jam> and deleting stuff that people actually wrote is usually bad
<jam> waigani: did you hear any of the juju 2.0 conf stuff?
<waigani> nop
<jam> the intent is to change out what is written, so instead users have a separate .conf file that just include account descriptions
<waigani> that makes a bit more sense
<jam> and then on bootstrap you would do "juju bootstrap $ACCOUNT $NAME [âtemplate some.yaml]"
<jam> wallyworld_: I just made you and Nate Managers so that you should be able to edit the board
<wallyworld_> thanks
 * jam needs to head to the grocery store before they get extra busy, bbiab
<jam> thumper: just to confirm, you're calling off our regular 1:1 today
<wallyworld_> jam: thumper: i added lanes for the squads, i think we need to get all the cards out of general and then delete that lane?
<davecheney> \o/ I cannot download the mongo driver because labix.org is down ...
 * davecheney hacks it
<thumper> jam: yes...
<axw> woo, only 44 conflicts to resolve
<wallyworld_> \o/
<wallyworld_> thumper: do you think we should remove the fast-lxc option in trunk and just make it work that way always? i can't see why we'd ever not want to have it
<wallyworld_> s/option/config setting
<thumper> wallyworld_: I'm not convinced that we always want it in every situation
<thumper> willing to be convinced
<wallyworld_> when wouldn't we want it?
<wallyworld_> in any case, i think the deafult should be true if we keep the option
<wallyworld_> and now it's a global setting, we can refactor a little - remove the local provider setting
<davecheney> wallyworld_: want about precise
<davecheney> or kernels that don't support aufs
<davecheney> (or it might be btrfs)
<wallyworld_> davecheney: if there's no aufs or btrfs we just copy the template image
<wallyworld_> still faster than download 100000000GB
<wallyworld_> davecheney: you saying that lxc on precise doesn't support cloning?
<davecheney> wallyworld_: i know of two places in our current LTS releases that would not support fast-lxc
<wallyworld_> these are?
<davecheney> precise on all platforms and trusty on ppc64el
<wallyworld_> davecheney: ok, so i reckon we can detect those and default to true otherwise
<wallyworld_> make the setting mean "clone if supported by series and arch"
<wallyworld_> fast-lxc-where-possible or whatever
<davecheney> wallyworld_: +1 to dumping the setting and making it automatic
<davecheney> less options is alway more good
<wallyworld_> yeah, and users *want* the behaviour if it is available
<wallyworld_> no one wants to wait 30 minutes to deploy a few lxc hosted charms
<jam> wallyworld_: AIUI all LXC implementations still use the cached .tgz that gets downloaded
<jam> it is just a question of whether the FS is cloned or not
<wallyworld_> jam: i must be confused then because thumper said, if i understood correctly, that we still wanted to create a template image file. if aufs or btrfs, it's cheap to copy the template, but even without, we just copy the entire template file, causing more i/o but still faster than downloading again
<jam> and AIUI the question then is, do you always double disk space (1 for template, 1 for first container), or do you sometimes only do 1 (1 for container)
<jam> wallyworld_: so there is the question of "when wouldn't you want it," what are the actual tradeoffs. thumper probably knows the details better than I do, but my understanding is
<jam> 1) lxc copies down the template rootfs from cloud-images
<jam> 2) it keeps that .tgz around
<jam> 3) with lxc-clone, we then expand that into a template lxc
<jam> 4) and then copy the expanded version (optionally doing a nice copy-on-write clone with btrfs) for each new lxc
<jam> without lxc-clone
<jam> we just create the one you asked for
<jam> so if you ever create 2, then you have to unpack a .tgz again
<jam> if you actually have to redownload the tools, that would be bad
<jam> the other bits that I didn't mention are
<jam> 3a) we do 'apt-get update' in the template before we start copying
<jam> 4a) we never do apt-get update again
<jam> vs
<jam> without lxc-clone whenever you deploy a new container we apt-get update in it.
<jam> its possible the apt-get update was what was killing cloning from dan's guys
<jam> if LXC wasn't caching the .tgz that would also be terrible, but it would be an LXC bug (AIUI)
<jam> So, if the expectation is that anyone who wants to deploy 1 service into a container is always going to deploy >1, then we're likely at a net win
<jam> if, on average, people deploy only 1, then we are at a net loss
<jam> hence, the configuration flag.
<jam> I would be fine with defaulting it to true, I think.
<jam> wallyworld_: for the "no aufs or btrfs" I agree that copying an expanded template is still faster than extracting from a tarball, so we could go ahead and do that
<wallyworld_> ok, clearly i misunderstood the mechanations. i  guess it was the apt-get update then. thanks for clarifying. i guess i didn't see that apt-get update would take so long
<jam> it is more about having 2 copies when you may only want 1
<wallyworld_> i think we'd want > 1 most of the timne
<jam> wallyworld_: well, I'm guessing, without being there and having them say anything other than "this took a long time" it is hard to say for sure
<wallyworld_> so we can just flip the setting to default to true
<jam> wallyworld_: note that Tim felt strongly that you needed the "juju-local" plugin which gives you a way to refresh/update your template
<jam> which was intentionally a hackish-plugin-that-only-works-locally
<wallyworld_> so as per dave's comment then, what would be any issue with precise or ppc64?
<jam> wallyworld_: so AIUI you can still copy everything, you just don't get "cheap" clones
<davecheney> wallyworld_: no idea
<davecheney> but when fast-lxc landed in trunk
<davecheney> it broke precise and ppc64
<davecheney> so we had to add a flag to *enable* it specifically
<davecheney> thereby disabling it by default
<jam> wallyworld_: potentially the issue is that they claim to support aufs, but it is broken
<jam> so we have to explicitly not use it and do straight copying
<wallyworld_> maybe we can hard code something then for now
<jam> even though the platform says "I can do a cheap clone with aufs"
<wallyworld_> i guess i'm saying i think we should support "use-clone" as true by default
<wallyworld_> so the out of the box experience for most users is nice without having to read release notes etc
<davecheney> i thought it was more that lxc didn't gracefully degrade
<davecheney> but we didn't have time to implement the detection
<davecheney> so turned it off by default
<wallyworld_> i guess i'm not sure what lxc has to support - don't all versions use a cached .tgz to use whenever a new container is asked for
<davecheney> wallyworld_: thumper knows the answer
<davecheney> all i know is this broke ppc when it landed
<davecheney> so we had to turn it off by default
<wallyworld_> np, i'll ask him
<wallyworld_> i reckon/hope we can detect when supported and default to true in that case
<davecheney> i agree
<davecheney> wallyworld_: or
<davecheney> fix the pcc kernel so it supports that optoin
<davecheney> precise is a noop
<davecheney> we already do not recommend precise when using the local provider
<davecheney> or
<davecheney> even cheaper
<davecheney> make fast-lxc the default, and we have to turn it off on trusty/ppc64el or upgrade the kernel
<jam> davecheney: note that this isn't about the local provider, this is turning it on everywhere that you use containers
<wallyworld_> correct. we added it everywhere for the maas guys for ods
<davecheney> sure
<davecheney> but i think what i said still applies
<davecheney> ppc is the outlier
<davecheney> nobody sohuld have to suffer becuase it's lame
<wallyworld_> i still can't see why precise would be different
<davecheney> wallyworld_: 12.04 <- lxc is broken
<wallyworld_> but if it is, we can detect that and not use it on precise
<wallyworld_> lxc in general?
<davecheney> but that is fine because we have continually said that use juju with the local provider (insert whatever name lxc has)
<davecheney> is *not* supported on precise
<davecheney> there is some hand waving and floor peering about applying a backport kernel
<wallyworld_> ok, no we don't need to check for precise then, just ppc
<wallyworld_> if they want to try lxc on precise, it's at their own risk
<davecheney> correct
<wallyworld_> since it's considered broken
<davecheney> so ppc is the only outlier
<wallyworld_> great, ok, that makes it easier
<jam> wallyworld_: is it possible for you guys to size your cards?
<jam> in kanban?
<jam> that gives us a way to track average velocity for future planning.
<wallyworld_> sure, just gathering a list first
<jam> np
<jam> I wasn't sure what stage you were at
<jam> thanks for doing the lanes
<jam> we probably need to clear out the "TODO" lane
<wallyworld_> sure. i'm hoping we can get all the ones i've added done in 2 weeks
<wallyworld_> we need to clear out a bunch of stuff
<jam> get the items moved into the team lanes, and then close/move TODO into backlog or somesuch
<wallyworld_> and also clear out general
<jam> wallyworld_: I mean all of the TODO, which is general/HA/MaaS etc
<wallyworld_> so what's in the todo/general vertical block becomes feature related lanes
<wallyworld_> ah ok
<wallyworld_> i was thinking the feature lanes could still be useful
<jam> wallyworld_: perhaps, but I think the feature-related is really just the teams
<jam> maybe not
<wallyworld_> a team could be on more than one feature concurrently
<wallyworld_> and folks outside core may want to look to see what's being done for feature A vs B
<wallyworld_> just athought
<vladk> jam: morning
<vladk> jam: hangout time
<jam> vladk: yep
<jam> wallyworld_: you merged 1.18 into trunk, but it didn't seem to include my changes to testing/mgo.go
<jam> is there a reason?i
<jam> wallyworld_: from what I can tell you explicitly reverted everything outside of cmd/8
<wallyworld_> jam: that was a mistake, sorry
<wallyworld_> there were so many conflicts
<jam> wallyworld_: k. I just noticed the test suite is just broken for me, and I thought I had fixed that
<jam> I was trying to merge trunk to get the fix
<jam> butâ¦ still broken :)
<wallyworld_> i'll fix
<jam> wallyworld_: so when doing patches with big conflicts, you can go back to stepping the merges
<jam> so you know you can reject everything in "Backport fix for â¦" but you probably don't want to reject one "Init EnvCommandBase.EnvNamâ¦" etc.
<wallyworld_> yeah
<fwereade> jam, wallyworld_: oops, sorry -- I knew I recognised everything when I LGTMed, didn't spot there were some things missing that I *should* have recognised ;)
<jam> fwereade: fwiw, it did end up conflicting on trunk because store/ in trunk changed how they were doing the test suite
<wallyworld_> nah, it was my fault, the number of conflicts confused me
<jam> wallyworld_: I didn't realize it was going to conflict, so I can pick it up
<wallyworld_> ok, if that works
<jam> wallyworld_: otherwise you should be able to just "bzr merge -c 2248.26.15 ." on trunk, but mgo_test.go is gone now
<jam> wallyworld_: I'll fix it up for trunk
<wallyworld_> ok, thank you
<jam> wallyworld_: fwereade: https://codereview.appspot.com/100380044/
<wallyworld_> looking
<wallyworld_> looks good, thanks for fixing my snafu
<jam> wallyworld_: np, it had to be fixed different in trunk anyway, so it wasn't like a simple clean "merge up"
<jam> I didn't realize the mongo infrastructure had changed this much, or I would have done 2 branches to start with.
<voidspace> morning all
<fwereade> voidspace, heyhey
<TheMue> morning
<jam> morning TheMue
<TheMue> jam: heya
<jam> TheMue: so in Las Vegas it sounded like you were coming back to juju-core, has that started?
<TheMue> jam: Iâll have to talk to Curtis, but I understood so too.
<TheMue> jam: How has Vegas been? Iâve seen that one result is the discovered urgency for dev docs. Thatâs a good news. :)
<TheMue> jam: And what is the status about moving to GitHub? I read about this discussion some time ago.
<jam> TheMue: vegas was pretty good. Good conversations, a giant document of possible work items with pretty good granularity
<jam> https://docs.google.com/a/canonical.com/document/d/1XZN2Wnqlag9je73mGqk-Qs9tx1gvOH0-wxMwrlDrQU4/edit#
<jam> I think it is about 90 pages long
<jam> :)
<jam> as for Github, Ian and Curtis appear to be working together to do a conversion, and get a Lander and CI, etc up and running.
<TheMue> jam: 90 pages??? OK, I have to read a lot. :D
<jam> not all of it is going to be done, and the work is going to be divided across 5 teams, but it all got put together in one big doc
<TheMue> jam: Moving to GH sounds good to me. I moved my private projects too after I learned a bit more about it when working for docs (hosted in GH too).
<TheMue> jam: 5 teams now? Wow.
 * TheMue thinks back of the start with one little team.
<voidspace> has anyone else seen go install not replacing binaries?
<davecheney> voidspace: only if there is nothing to built
<davecheney> ie, they are up to date
<davecheney> voidspace: have you been bitten by /usr/bin/juju ?
<davecheney> juju-local, which is required to run the tests installs a version of juju higher up your path
<voidspace> davecheney: no, but I've been switching branches and rebuilding a lot to test some changes
<voidspace> davecheney: and wwitzel3 thinks he has seen cases where "go install ./..." doesn't replace old binaries with the new ones
<davecheney> always use -v
<voidspace> davecheney: which would screw all the results of my testing
<davecheney> alias gb='go install -v'
<voidspace> davecheney: ah, which will tell me when it's replacing binaries
<davecheney> that is what I use
<voidspace> ok
<voidspace> good idea, thanks
<davecheney> the only case it would not replace the final executable is where it thought there was no work to do
<voidspace> right, that's what it *should* do :-)
<davecheney> voidspace: go install -x will show the commands being run
<davecheney> you can start debugging it there
<davecheney> voidspace: one thing which might throw it off is if you have a 'creative' GOPATH
<davecheney> the best advice isjust to export GOPATH=$HOME
<davecheney> or GOPATH=$HOME/code
<voidspace> davecheney: my GOPATH is highly uncreative
<voidspace> yeah, it's a fixed location
<davecheney> voidspace: in that case I cannot explain why you are having issues
<davecheney> use -v or -x
<davecheney> so you have some details we can dig through
<voidspace> davecheney: I was just worried by Wayne - I don't *think* I've seen it, but he says he has - and I wondered if this was a general issue
<voidspace> in which case I'd need to always delete binaries when I build
<voidspace> I have a more juju specific question
<voidspace> on a state server I need to get the addresses of all the *other* api servers (not including itself)
<voidspace> there is agentConfig.APIAddresses() which gets all addresses
<voidspace> how do I determine the address of the state server this is being run on to remove it?
<voidspace> inside cmd/jujud/agent.go (specifically inside newRsyslogConfigWorker)
<davecheney> func (st *State) DeployerConnectionInfo() (*DeployerConnectionValues, error)
<davecheney> state has this odd method
<davecheney> which returns an object which has a list of api and state servers
<davecheney> apart from that
<davecheney> nfi
<voidspace> a list of *all* api and state servers?
<davecheney> type DeployerConnectionValues struct { StateAddresses []string APIAddresses   []string
<davecheney> }
<davecheney> apparently
<davecheney> never used it myself
<voidspace> davecheney: right, I have *that* information - I want just the current one
<voidspace> (to remove it from the list)
<voidspace> I guess I have to see how that information is populated, and where the information comes from
<davecheney> hmm, there is this one
<voidspace> each api server must publish this information
<davecheney> func (st *State) APIHostPorts() ([][]instance.HostPort, error) APIHostPorts returns the API addresses as set by SetAPIHostPorts.
<voidspace> again, that's all of them
<davecheney> yeah
<davecheney> looks like that information isn't accessible
<voidspace> davecheney: I'll dig into it - thanks though
<davecheney> it's just regurgitating what is in mongo
<voidspace> right
<voidspace> so I need to find where that information is published into mongo
<voidspace> sounds like a job requiring more coffee :-)
<jam> voidspace: there is probably something like Machine.PublicAddress (es?)
<jam> but yes, what you want is something like APIHostPorts but for only your agent
<jam> potentially you only want private addresses which I think there is Machine.PrivateAddresses
<jam> though I don't know what our exact story is for rsyslog and manually provisioned machines
<jam> as they need to contact the API server on the Public ports
<jam> natefinch just did a patch so that they will try to connect to API servers on both addresses in case they cannot connect privately
<jam> though I think I convinced him it was worth changing how we cache addresses so that we can do stuff like "try the private addresses first"
<axw> fwereade: we can take git out of the packages installed during cloud-init now, right?
<voidspace> jam: right, interesting
<voidspace> jam: however - I remember another conversation with you
<voidspace> jam: I can *not* filter out the machine's own address and instead of logging local messages on the state server
<voidspace> jam: rely on it broadcasting messages to all state servers, and logging its own messages "remotely" as well
<voidspace> jam: that way is slightly inefficient
<voidspace> jam: but I don't need to filter the addresses
<voidspace> jam: and will do for a first cut
<voidspace> jam: as it makes the state server config slightly simpler too
<jam> voidspace: sounds ~ok to me.
<jam> if we are intending to change logging completely anyway
<voidspace> right
<jam> I wouldn't spend huge amounts of time figuring out all of this, though some of it might still be useful for future work
<voidspace> we *finally* have the new ryslog config working
<voidspace> (units broadcasting to all state servers)
<voidspace> that took a *long* time to get right
<voidspace> due mainly to horrible documentation and no error messages
<voidspace> so this shouldn't take anything like as long
<voidspace> (i.e. today hopefully)
<axw> voidspace: aha, you've had the pleasure of reading rsyslog docs I see
<axw> took ages to get the original stuff working right too :)
<axw> such cryptic configuration language
<voidspace> axw: yeah, great fun. Not.
<jam> axw: voidspace I think the lack of messages like "unable to forward messages to XXXXX" that would give you a bit more of a hint as to why the syntax wasn't doing what you thought it was
<jam> but the fact that the configuration file is actually a mini program
<jam> but without all the nice things like visible control flow
<voidspace> yep
<voidspace> the parser must be a beast, especially for the legacy format rulesets
<voidspace> there's no documentation on how the parser decides if a directive is global or within the ruleset definition
<voidspace> or even how you terminate a ruleset definition
<voidspace> the new syntax is better
<voidspace> I'm giving a bash with the legacy format - if that doesn't work I'll switch to the new syntax and the state server logging broadcasting will be trusty only
<voidspace> right, now to test this with canonistack
<jam> perrito666: sorry I missed our 1:1, and while I realize you're on Nate's team, I was at least planning on saying goodbye.
<jam> fwereade: if you're around, care to join the standup chat early, there is something I'd like to bounce off of you
<voidspace> it's always slightly disconcerting to log into a juju machine and see "System restart required"
<voidspace> I assume that after the "apt upgrade" we don't restart
<voidspace> so some security upgrades aren't *actually* applied
<jam> voidspace: I thought we had a bug open about possibly restarting machines when we see that apt wants a restart, but I can't find it in my 30s googling
<voidspace> jam: shall I create one?
<jam> voidspace: certainly
<voidspace> yay, I'm seeing logging from state server machine-1 on machine-0
<voidspace> so the state server logging broadcasting is working
<voidspace> so how exactly to write a useful test for this...
<fwereade> jam, sorry, I was having lunch and paying no attention to the time -- are you all done?
<fwereade> jam, I'm here for idea-bouncing regardless
<jam> not yet, we're now in the "juju-sapphire" hangout
<perrito666> good morning
<natefinch> morning perrito666 (and everyone else... I've been lurking for a while)
<voidspace> perrito666: morning
<voidspace> natefinch: morning
<perrito666> natefinch: I didnt, I tried that wwitzel3 trick to sleep a bit more for one day
<natefinch> perrito666: haha... one of my cats woke me up just at the time I used to get up, and then I was screwed.
<wwitzel3> hello all
<natefinch> morning wwitzel3
<voidspace> wwitzel3: morning
<voidspace> wwitzel3: so the logging config changes you made Friday seem to work for state servers too
<voidspace> wwitzel3: I have state servers broadcasting their logging to all the other state servers
<voidspace> wwitzel3: just fixing up tests
<voidspace> wwitzel3: I just put the broadcast loop into the local ruleset and it worked without changes
<voidspace> wwitzel3: which was nice :-)
<wwitzel3> voidspace: nice :)
<vladk> natefinch: in ./cmd/jujud/machine.go all workers are started with startWorkerAfterUpgrade expect apiserver and peergrouper that are started with runner.StartWorker.
<vladk> natefinch: is any reason to start peergrouper before upgrade completes?
<jam> natefinch: did you still want to do our 1:1 today?
<natefinch> vladk: I don't believe so.  Seems like it would be good for it to wait until we're done upgrading
<natefinch> jam: oh yeah, sorry, lost track of time.  Sure, give me a minute to change a diaper.
<voidspace> vladk: my daughter loves the sochi teddy bear - thank you
<jam> natefinch: then I'll just get my son set up quickly
<jam> back, I'm in the hangout
<vladk> voidspace: glad to hear it
<voidspace> right, lunch
<_benoit_> Hmmm the ec2 provider does not work at all without S3
<_benoit_> This will give me a good excuse to learn how go interfaces work :)
<perrito666> btw, now that there are more of us back, could anyone else ptal? https://codereview.appspot.com/94330043/
<perrito666> vladk: I answered your comments
<jam> perrito666: reviewed
<perrito666> jam: tx
<_benoit_> Could the Ssh Storage worker be used to replace S3 in to support the outscale EC2 compatible provider ?
<_benoit_> I mean does it have some serious issues preventing to use it to do this ?
<fwereade> _benoit_, the ssh storage provider is kinda broken, because it won't work in a HA context -- we're going to be moving environment storage intogridfs within mongo
<fwereade> _benoit_, not sure offhand exactly when it's scheduled
<fwereade> if anyone's watching irc, I'd appreciate a review of https://code.launchpad.net/~fwereade/juju-core/arch-docs-1/+merge/219190 -- it's just a beginning, but I wanted to get something in
<_benoit_> fwereade: what is the smothest option right now configuration wize ?
<_benoit_> fwereade: the http storage seem to require a lot of intervention from the user
<_benoit_> fwereade: I would like to replace S3 without asking the user to enter a configuration for storage
<fwereade> _benoit_, sorry, had to dash out to collect laura
<fwereade> _benoit_, what exactly is the use case? ec2-like, but not-really-ec2, environments?
<_benoit_> fwereade: mostly (98%) ec2 without S3
<_benoit_> fwereade: I am looking for a way to have a smooth integration (not the manual provider)
<_benoit_> fwereade: https://wiki.outscale.net/display/DOCU/AWS+Compatibility+Matrix
<_benoit_> I already patches goamz to add the provider regions
<_benoit_> s/patches/patched:
<fwereade> _benoit_, I see, cool
<fwereade> _benoit_, well, if you don't mind that HA won't be possible in the short term, I guess ssh storage might be viable
<_benoit_> ok
<voidspace> anyone else have this test failure on trunk?
<voidspace> validatetoolsmetadata_test.go:123: ValidateToolsMetadataSuite.TestEc2LocalMetadataUsingIncompleteEnvironment
<natefinch> wwitzel3: standup?
<wwitzel3> natefinch: sorry off in space
<wwitzel3> coming
<wwitzel3> natefinch, voidspace: https://codereview.appspot.com/96190043/
<bac> juju help scp shows using the -r option.  when i try to use it i get an error saying "error: flag provided but not defined: -r"
<bac> sinzui: have you seen ^^^
<sinzui> bac: yes
<sinzui> I think juju ssh has mangled ssh and scp command line
<bac> sinzui: is there a work-around?
<sinzui> bac, last week I used scp with -i
<sinzui> bac, we always know the key that was used, and we can always ssh to the public address
<sinzui> of the unit
<bac> sinzui: there is a bug filed?
<natefinch> wwitzel3: LGTM'd
<sinzui> bac, there isn't a bug.
<bac> sinzui: i've filed bug 1318711
<_mup_> Bug #1318711: juju scp reports -r as an invalid option <juju-core:New> <https://launchpad.net/bugs/1318711>
<sinzui> I see
<sinzui> bac, which version of juju?
<bac> 1.19.2
<sinzui> excellent, thank you bac
<bac> sinzui: i'll add that
<sinzui> bac, I just did thank you
<sinzui> hazmat`, did you provide wallyworld_ with a list of bug that we want to fix to improve juju's reliability and and usability?
<hazmat`> sinzui, i did
<hazmat`> spreadsheet form
<hazmat`> sinzui, the three bug tags were usability, observability, reliability afaicr
<sinzui> hazmat`, may I see it. I want to ensure the bugs are kept high and on our list to fix soon
<hazmat`> sinzui, yup.. just looking up the url.. ods network is a bit spotty
<voidspace> does lbox propose work if there's a pre-requisite branch?
<voidspace> or is the fact that it's *not* working for me due to some other reason...
<perrito666> voidspace: did you tell lbox that there is such pre requisite?
<perrito666> --req iirc
<voidspace> perrito666: hm... no, but it's set in launchpad
<voidspace> I did not know I needed to
<voidspace> when I run lbox propose it just says:
<perrito666> not to sound like fwereade but "its on the docs"
<voidspace> Branches: lp:~mfoord/juju-core/ha-rsyslog => lp:juju-core
<voidspace> perrito666: hah, sure - along with a million other things you don't need to know until you do
<perrito666> lol
<voidspace> perrito666: which docs specifically?
<voidspace> it's not in CONTRIBUTING
<voidspace> ah, I stand corrected
<voidspace> it is
<voidspace> let me try that
<voidspace> perrito666: thanks
<perrito666> CONTRIBUTING
<perrito666> tx
<perrito666> heh your grep is faster than mine
<voidspace> hmm... nope - still does the same no-op
<stokachu> sinzui: did juju 1.18.3 get uploaded to proposed in trusty yet?
<sinzui> stokachu, I have not seen it
<stokachu> sinzui: ok do i need to file a proper sru for it?
<sinzui> thank you stokachu
<stokachu> sinzui: np i didnt know if juju was bound by same sru process
<sinzui> stokachu, yes, the issue is a bit ambiguous. we are working on an MRE exception for the "juju" command to ensure trusty will always have the latest command-line client
<stokachu> sinzui: ok cool, ill create the necessary diffs and get the sru process rolling for those bugs you listed in the release note
<stokachu> ill only do trusty though since precise only has 1.16 in the archive
<voidspace> ok, so deleting the existing merge proposal allowed lbox to work
<voidspace> I don't think lbox can handle an existing merge proposal with a pre-requisite branch already set
<stokachu> wallyworld_: this fast clone is soooooo awesome
<perrito666> voidspace: there are lots of things lbox cant handle :) yet i like it
<stokachu> openstack deployed (not including initial cloud dl and import of glance iamges) in 3 minutes
<voidspace> going to krav maga
<voidspace> back online later
<stokachu> voidspace: gl dont kill anyone with single strike
<stokachu> ;p
<voidspace> stokachu: hah, I spend more time trying to avoid being killed...
<voidspace> first one for four weeks
<voidspace> bye all
<stokachu> cya :)
<natefinch> alexisb: sorry, that took a lot longer than I expected.  $800 down and now we have AC again.
<alexisb> the $800 sucks
<alexisb> but yay for AC!
<alexisb> natefinch, do you still have time to meet?
<alexisb> if not I can reschedule for tomorrow
<wwitzel3> EOD for me, see everyone tomorrow
<alexisb> bye wwitzel3
<natefinch> alexisb: yeah, I can meet more now.  Honestly, $800 sucks, but I'd pay $800 every year for central A/C if I really had to.
<alexisb> ok natefinch, I will rejoin the hangout
<perrito666> mongo is really anoying regarding errors
<waigani> fwereade: you about?
<fwereade> waigani, yeah, with you in 5
<thumper> hmm... need socks
<natefinch> thumper: pretty sure socks are optional in the home office.
<waigani> natefinch: not in dunedin!
<thumper> natefinch: a bit too cold to work sockless right now
<natefinch> hmm good point, you guys are going into winter
<natefinch> thumper: there's a revision on trunk, 2656, that I want to update my branch to.... bzr update -r --revision=2656 doesn't work.  How do I do it?
<thumper> natefinch: what do you mean by update to?
<natefinch> (bzr says the revision doesn't exist)
<thumper> you can change the tree
<thumper> pull first
<thumper> then either revert the tree to the revision
<thumper> or pull that revision
<thumper> you can branch from a particular revision
<natefinch> thumper: not sure what the bzr word for it is.  I'm on HEAD of trunk, I need to go back in time to 2656, without making a new branch
<thumper> natefinch: for what purpose?
<bac> ping jamespage
<natefinch> thumper: diffing versus the branch the windows guys worked on
<thumper> natefinch: if you just want to look at the files at that revision
<thumper> you can go "bzr revert -r 2656"
<menn0> natefinch: bzr update -r 2656
<thumper> that will make the working tree reset to that revision I think
<menn0> natefinch: using update will get you the same thing but bzr will warn you that your working copy is out of date. bzr update without a rev gets you back.
<natefinch> ahh, ok, so --revisionm was a red herring
<natefinch> I see what I did, -r and --revision were the same thing, so I confused it
<natefinch> funny
<natefinch> ok, I gotta run, thanks for the help
<menn0> anyway... morning all :)
<thumper> o/ menn0
<menn0>   \o thumper
 * thumper grunts
<thumper> why is reversing a slice not a one liner?
<menn0> thumper: do you mind if I reorg our identity document a little?
<menn0> thumper: sort.Sort(sort.Reverse(sort.IntSlice(keys))) apparently
<thumper> menn0: not at all
<thumper> menn0: that doesn't work
<thumper> I don't want it sorted
<thumper> I just want it reversed
<menn0> thumper: ah of course
<thumper> the Reverse function doesn't actually reverse it
<thumper> it just changes the meaning of 'less'
<menn0> thumper: yep. my brain is still waking up.
<menn0> thumper: re the doc. I promise I won't delete anything just shuffle things around.
<thumper> ok
<fwereade> fwiw I will probably land this anyway first thing tomorrow, but I would appreciate eyeballs on https://codereview.appspot.com/91390043/ regardless, because I probably get *something* hilariously wrong
<fwereade> (just docs, I'm not going to *break* anything with wanton landing, except possibly people's brains)
<waigani> fwereade: yay I've been wanting something like this :D
<fwereade> waigani, it's not complete by any means, but it's a start :)
 * perrito666 obtains a succesful restore of HA machine and with it EODS
<menn0> thumper: doc reorg done. I'm still going through the source doc and adding more notes about stuff nobody has commented on yet.
<thumper> cool
<thumper> oh ffs
<thumper> why oh why does go make it so hard to test for instance equality?
<thumper> I just want to know if these two errors are the same error
<thumper> and I can't
<thumper> (for one of the tests)
<thumper> because of incomparable error types
<thumper> all I want to know is if they are the same, not equal
<voidspace> can't you get an unsafe pointer from them and compare?
 * voidspace not entirely serious
<voidspace> morning southern folk
<rick_h_> southern folk, haven't run into that one
<menn0> voidspace: hi!
<voidspace> o/
<voidspace> hi rick_h_
<rick_h_> voidspace: hey, jealous of your pics and travels. The canyon heli tour is on my todo list.
<voidspace> rick_h_: yeah, it was pretty awesome
<voidspace> just being at the canyon is awesome. It's as spectacular as you would expect.
<rick_h_> yea, I'm trying to talk my wife into renting an airstream and doing a tour around all the parks around there.
<rick_h_> https://airstream2go.com/
<jcw4> rick_h_ oooh... always wanted one of those
<rick_h_> jcw4: yea, working on getting her used to that idea for our next camper
<jcw4> :)
<thumper> o/ voidspace
<thumper> voidspace: I have been thinking of doing exactly that
<voidspace> thumper: hi
<voidspace> oh dear
<thumper> it seems like a complete deficiency in the language to not allow that
<voidspace> wrap it in a helper and hide the shame
<voidspace> yeah, seems pretty basic
<voidspace> but then when you have pass by value the concept of "identity" is less useful
<jamespage> bac, pong
<thumper> cmars: oh hai
<thumper> cmars: we need to make sure we have regular calls
<cmars> thumper, hi
<thumper> cmars: how's things?
<cmars> thumper, not too bad
<thumper> cmars: are you up for a catch up call tomorrow?
<thumper> say 21:00 UTC?
<cmars> thumper, certainly. that's 16:00 here i think. definitely wfm
<thumper> cmars: would that work weekly for you?
<cmars> thumper, yep, sounds good
<thumper> ok, I'll book it in
<thumper> cmars: I want to make sure we keep in sync with the identity work
<waigani> davecheney: https://plus.google.com/hangouts/_/canonical.com/onyx-standup
<waigani> cmars: https://plus.google.com/hangouts/_/canonical.com/onyx-standup
<thumper> davecheney: I lost that last play link when I closed the hangout
<thumper> davecheney: is there a real golang reason why I can't test for interface identity across (for example errors of uncomparable types) ?
<thumper> hmm... that didn't read very well
<thumper> I have two errors, I just want to see if they are the same error (not equal, but actually the same interface)
<thumper> effectively don't deep compare the implementation of the interface, just compare the interface tuple
<davecheney> thumper: so you want to say 'are these two errors the same type' ?
<davecheney> use reflection
<davecheney> 4 lines
<davecheney> it gets easier if you don't want to compare every possible error implementation eith every other error implmentation
<davecheney> ie, is this error and instance of the errgo wrapper and that one not
<thumper> I just care about the implementation pointers
<thumper> (and the type I guess)
<davecheney> and only the implementation pointers ?
<thumper> that is sufficient
 * thumper heads to the gym
<davecheney> thumper: http://play.golang.org/p/F2oLtm3jd7
<davecheney> ^ a little surprising
<davecheney> but you just figured out how io.EOF is implemented
<davecheney> /s/you/i
<davecheney> hmm
#juju-dev 2014-05-13
<davecheney> http://play.golang.org/p/0jeSRlVe8B
<davecheney> ^ maybe that makes a little more sense
<davecheney> thumper: can you show me the hole in the code where this function would fit
<davecheney> maybe that would help me suggest a better implementation
<rick_h_> davecheney: via the api we want to colocate a service with another on an existing machine. If I create a service with 0 units, and then add a unit with the machine id of an existing machine any chance of it working?
<rick_h_> I cna't test it out via the cli becaus I can't deploy a service with --num-units=0
<davecheney> rick_h_: deploy --to
<davecheney> ^ that is what you are trying to do, right ?
<rick_h_> yea, that's cli, but I need api for the gui
<rick_h_> davecheney: yes, basically
<davecheney> ok, let me figure out how the cli does it
<rick_h_> but doing it with manual placement
<rick_h_> davecheney: thanks
<rick_h_> davecheney: sorry, we're getting the demo rules changed on us and trying to get back to a working demo
<rick_h_> appreciate the help
<davecheney> rick_h_: ok, i dont know what that means
<davecheney> oh yes i dio
<davecheney> ODS is here isn't it
<rick_h_> davecheney: yep :)
<rick_h_> davecheney: and our demo of lxc container on a running machine isn't happy with openstack running on openstack
<rick_h_> so we're trying to change it on the fly to colocated on bare metal vs in lxc
<davecheney>         err = client.ServiceDeployWithNetworks(
<davecheney>                 curl.String(),
<davecheney>                 serviceName,
<davecheney>                 numUnits,
<davecheney>                 string(configYAML),
<davecheney>                 c.Constraints,
<davecheney>                 c.ToMachineSpec,
<davecheney>                 includeNetworks,
<davecheney>                 excludeNetworks,
<davecheney>         )
<davecheney> this is the api (i guess call), there is a numunits on ther
<rick_h_> ok, so it's coming in with the service
<rick_h_> we need to break the steps up, but will see how we do
<davecheney> hang on , still checking
<davecheney> http://paste.ubuntu.com/7455044/
<rick_h_> thanks looking
<davecheney> so num units 1
<davecheney> tomachinespec <- the machine you want to pin the service to
<rick_h_> yea, we're deploying the service with 0 units and then making individual add unit calls.
<davecheney> that won't work
<davecheney> --to is a dirty hack
<davecheney> its internal name is 'hulk smash'
<rick_h_> ugh
<rick_h_> ok
<davecheney> so you'll have to deply one unit with --to, then make additional calls to add-unit --to
<rick_h_> yea, that breaks more stuff for us then. thanks for looking
<davecheney> the reason its like this is --to skips the normal machine selection logic, and just spats the unit on that machine
<davecheney> that splatting isn't recorded in mongo at all
<rick_h_> understood
<axw> wallyworld_: that issue curtis reported is fixed by the tools CL you just did?
<wallyworld_> axw: yes
<axw> cool
<wallyworld_> axw: did you have time for a quick standup?
<axw> wallyworld_: sure
<thumper> davecheney: around?
<davecheney> thumper: ack
<thumper> davecheney: got time for a hangout?
<davecheney> thumper: sure
<thumper> let me just let the dog in
<thumper> davecheney:  https://plus.google.com/hangouts/_/g4gj3fe657m4xgcesqioprs6vqa?hl=en
<davecheney> joining ...
<thumper> davecheney: play.golang.org/p/3LV_d5HJb3
<waigani> axw: ping
<axw> waigani: pong
<waigani> axw can I pick your brain? hangout?
<axw> sure
<axw> waigani: sorry was a bit hard to hear you, didn't realise you were logging off. cya ;)
<waigani> oh whoops, didn't mean to hang up on you :/
<axw> waigani: nps
<axw> you got everything you needed right?
<waigani> yep, all good now, thanks :)
<axw> nps
<waigani> I was going to ask how harding was going, but you seem to be in the thick of it
<axw> waigani: just picking off bugs one at a time, not that different from before
<waigani> axw: you're looking very productive! Thunderbird keeps popping up with merge proposals from you an wallyworld_ every 5min!
<axw> I don't really feel very productive doing bitsy things, but it's still useful
<wallyworld_> getting the test suite to pass reliably is very productive :-)
<axw> wallyworld_: do you really want me to look at the LXC defaults thing, or was that just an idea? I've got a good idea about how to fix #1316272
<_mup_> Bug #1316272: juju destroy-environment >=256 nodes fails <amd64> <apport-bug> <destroy-environment> <maas-provider> <sm15k> <third-party-packages> <trusty> <juju-core:Triaged> <MAAS:Invalid> <juju-core (Ubuntu):New> <maas (Ubuntu):Invalid> <https://launchpad.net/bugs/1316272>
<wallyworld_> go for it, it was just an idea
<wallyworld_> that maas one is more important
<axw> cool
<jam> thumper: gocheck provides a gc.FitsTypeOf checker that takes two objects and tells you if the first one matches the type of the second one
<thumper> jam: I don't want the type, but object identity
<jam> thumper: so it isn't "unsafe" to grab a uintptr object
<jam> AIUI
<jam> it is only "unsafe" to cast that back into a type
<thumper> jam: however the interface is a tuple of two pointers
<jam> thumper: reflect.Value(obj).Pointer() == reflect.Value(obj2).Pointer()
<thumper> jam: doesn't work if the type isn't a pointer
<jam> I don't have the scrollback on this terminal for your non-comparable types
<thumper> it panics
<jam> thumper: &obj is still a pointer
<jam> well, would always be a pointer
<thumper> no
<thumper> no it isn't
<thumper> a value type can implement an interface
<thumper> and in fact we have an example in juju-core
<jam> sure, but &obj is still a pointer
<thumper> where a value type is an error and uncomparable
<jam> thumper: if it is a value type, then they *are not* the same obj.ect.
<jam> object
<thumper> jam: but you don't know
<thumper> jam: look, I have examples in test code
<thumper> which expected behaviour
<thumper> if it can be done a different way
<thumper> I'm happy, but AFAIK, it cannot
<jam> thumper, so to start with, I'm not sure that comparing errors by identity is actually what we want to be doing, rather than checking if this error is part of this type of errors.
<jam> I realize our code is a bit mixed on this point
<jam> where we have some concrete errors
<jam> and we have other variable ones
<jam> and we get some unhashable/uncomparable ones from various libs
<thumper> it isn't helpful to discuss this here without examples
<jam> I've run into it elsewhere in our code where I wanted to put error types into a map
<jam> but it fails to lookup because we get an unhashable error type.
<jam> In that case, we just swallowed the panic
<jam> that was the Serve code, IIRC
<jam> which wants to map known errors into error codes
<jam> thumper: state/apiserver/common/errors.go func singletonCode(err error) (string, bool)
<jam> 	// All error types may not be hashable; deal with
<jam> 	// that by catching the panic if we try to look up
<jam> 	// a non-hashable type.
<jam> thumper: if your error is a value type, then it pretty much *cannot* be the same object as some other object, because as soon as it is passed on the stack, it is a new object.
<jam> as such, you can just say "if this isn't a Pointer() then it isn't the same object"
<jam> and force the equivalence to false in that case.
<thumper> jam: play.golang.org/p/dnd98Gl1O4
<jam> thumper: http://play.golang.org/p/IjRIj8SaWk
<jam> without unboxing the internal implementation
<jam> of interface
<thumper> but catching panic is just as horrible
<thumper> jam: I'm going to take this to the list anyway
<thumper> jam: so we can discuss it there
<thumper> personally I wish that golang made this easier for me, but it doesn't
<thumper> we will have one icky thing or the other
<thumper> both are horrible IMO
<thumper> but which is more horrible?
 * thumper shrugs
<jam> thumper: they give different results, too: http://play.golang.org/p/JQ5Ga8k-xd
<jam> since if you have an 'error' it is pointing at a concrete value, so while you can't pass that value around without it changing to a new value, you *can* pass around the error interface to it
<jam> which gives you a new interface at each step, but the underlying object is the same.
<thumper> jam: well that is problematic
<jam> thumper: though is the actual error you care about comparing to a value type ?
<thumper> it may be
<thumper> and that is one horrible bit
<thumper> it may be a value type
<thumper> and it *may* be uncomparable
<thumper> and since it might happen
<thumper> we need to handle it
<jam> thumper: well, we do have some control on the system and can say things like "if you want your errors to be compared to be the same, they must be comparable types"
<jam> I'm not sure what the use case is for being able to compare all possible error implementations
<thumper> um... because you are writing an error handling library?
<jam> thumper: its still your code
<jam> you can give parameters of what is supported
<thumper> not all of it
<thumper> ugh
<jam> Value type errors that are uncomparable aren't *nice* errors in go world
<thumper> agreed
<davecheney> waigani: ping
<waigani> davecheney: pong
<davecheney> waigani: do you remember the issue that we had before vegas related to juju blowing up on 64k kernels ?
<waigani> davecheney: going offline soon
<davecheney> there was one test package that would always blow up
<davecheney> waigani: if you don't remember, that is fine
<waigani> davecheney: just trying to think ...
<waigani> everything stopped working for me before vegas
<waigani> yeah sorry, I'll have a look over the issues/emails in the morning and see if I can remember
<davecheney> waigani: np
<davecheney> i'll figure it out
<davecheney> 2014-05-13 07:06:58 INFO juju.worker runner.go:260 start "peergrouper"
<davecheney> 2014-05-13 07:06:58 DEBUG juju.worker.peergrouper worker.go:421 found new machine "0"
<davecheney> 2014-05-13 07:06:58 ERROR juju.worker.peergrouper worker.go:137 peergrouper loop terminated: cannot get replica set status: cannot get replica set status: not running with --replSet
<davecheney> 2014-05-13 07:06:58 ERROR juju.worker runner.go:218 exited "peergrouper": cannot get replica set status: cannot get replica set status: not running with --replSet
<davecheney> 2014-05-13 07:06:58 INFO juju.worker runner.go:252 restarting "peergrouper" in 3s
<davecheney> local provider shits itself in a loop
<davecheney> bugs raised today: 3
<davecheney> bugs fixed today: 0
<davecheney> if I do
<davecheney> juju deploy X
<davecheney> X is resolved by the charm store, yes ?
<davecheney> is it resolved by the client, or by the api server ?
<davecheney> (having proxy issues)
<davecheney> ubuntu@winton-02:~/src/launchpad.net/juju-core$ juju deploy --debug cs:trusty/mysql                                                                                       2014-05-13 07:54:41 INFO juju.cmd supercommand.go:301 running juju-1.19.3-trusty-ppc64 [gccgo]
<davecheney> 2014-05-13 07:54:41 DEBUG juju.conn api.go:185 trying cached API connection settings
<davecheney> 2014-05-13 07:54:41 INFO juju.conn api.go:268 connecting to API addresses: [10.245.67.6:17070]
<davecheney> 2014-05-13 07:54:41 INFO juju.state.api apiclient.go:198 dialing "wss://10.245.67.6:17070/"
<davecheney> 2014-05-13 07:54:41 INFO juju.state.api apiclient.go:144 connection established to "wss://10.245.67.6:17070/"
<davecheney> 2014-05-13 07:56:49 ERROR juju.cmd supercommand.go:304 cannot download charm "cs:trusty/mysql-0": Cannot access the charm store. Are you connected to the internet? Error details: Get https://store.juju.ubuntu.com/charm-info?charms=cs%3Atrusty%2Fmysql-0: dial tcp 91.189.95.67:443: connection timed out
<voidspace> morning all
<axw> morning voidspace
<axw> can someone please review a change to gomaasapi? https://code.launchpad.net/~axwalk/gomaasapi/testservice-nodes-release/+merge/219309
<axw> (I'm updating the MAAS provider's StopInstances to do bulk release)
<wwitzel3> voidspace: ping
<voidspace> wwitzel3: morning :-)
<voidspace> axw: morning
<voidspace> wwitzel3: give me a few minutes and I'll join you in the hangout?
<wwitzel3> voidspace: sounds good
<fwereade> axw, lbox? I really like line-by-line comments :)
<fwereade> axw, (this is not really a case where it's super-important, 'tis true)
<fwereade> axw, basically LGTM but a few comments
<fwereade> jam, axw, voidspace, wwitzel3, et al: I'm approving https://codereview.appspot.com/91390043/ but I'd still appreciate comments
<axw> fwereade: sorry, does gomaasapi have lbox set up?
<axw> does not appear to
<fwereade> axw, good point -- but is it more than a .lbox file in the source tree?
<axw> fwereade: making dinner, will take a look at your doc later
<axw> fwereade: I have no idea
<jam1> fwereade: I've come up with a possible problem with just putting Version into another attribute of the request header.
<fwereade> jam1, oh yes?
<jam1> In that old servers will just happily ignore the field and return the wrong thing
<jam1> fwereade: it just means we have to be more careful in not allowing the client-side code to accidentally try a new version request
<voidspace> fwereade: will read
<voidspace> fwereade: thanks
<jam1> fwereade: if we were to re-use the "id" field, then we would have gotten back ErrBadId, and we could have mapped that into "oh, that actually means NotImplemented"
<jam1> now we just get "ok"
<fwereade> jam1, ie only send versioned requests to server that have already stated they support versions? that does sound reasonable to me
<jam1> I *think* we're ok, because we detect what the server supports at Login time.
<jam1> fwereade: it is just one of those things where we have to be "extra careful" because we can do it wrong and things will still seem to be working, but might be subtly broken.
<jam1> Like when we want to change the Set() api so that blank strings are accepted and don't mean "set to default".
<jam1> if the client code had a bug that it just always used 2,Set() it would "just work" except when you tried to set to an empty string on an old server and it would set it to the default value.
<jam1> fwereade: anyway, I have a model for how the client side code might work, and since we probe for available versions at Login time we should be able to do client side filtering appropriately
<fwereade> jam1, yeah, I see your point, my personal instinct still slightly leads toward not reusing the field but I'm having a hard time justifying it -- at least a single layer of id-munging to support old clients using watcher ids is much more localised
<jam1> Its just one of those "I'd like it to break noisily when we make a mistake"
<jam1> fwereade: yeah, I like having it as an explicit Version. I was mostly just bringing up an issue that we should at least be aware of.
<fwereade> jam1, cheers
<jam1> fwereade: I guess partially I was also hoping that I wouldn't have to do as much changes to the RPC package because I had a new field and could do magic there, but it turns out everything was only nice and orderly because of all the other changes I've done along the way.
<jam1> like handling Id early rather than late, etc.
 * fwereade cheers
<jam> fwereade: I'm about halfway through your arch overview, and I'm trying to get a feel for how much we need the "here be dragons" side comments vs the "this is how it is laid out". I like letting people know that what we have is not perfect yet, I just wonder if they distract from getting an understanding first.
<jam> IF we had footnotes, I think they'd make excellent footnotes
<fwereade> jam1, I go back and forth -- "how it is" and "how it should be" *are* separate, but I find that focusing only on the former ends up giving it a misleading air of the latter
<fwereade> jam1, yeah, footnotes would be the answer, wouldn'tthey
<jam> sidebars, something :)
<jam> fwereade: yeah, I certainly appreciate the "it is this way because it has been this way, and we don't quite understand why the alternatives weren't chosen"
<jam> which seems like something an overview could at least hint at.
<jam> "eponymous" a word I've probably only ever read, I'm not actually sure how it is pronounced :)
<fwereade> jam, I like that word so I probably shouldn't use it ;)
<fwereade> jam, I thought I remembered deleting it actually, maybe some part of my brain rebelled and inserted it somewhere else
<jam> fwereade: for example, `Provisioner`, `Upgrader`, and `Uniter`, each used by the eponymous +worker types
<jam> I'm fine with it, fwiw
<jam> I was just reading it over and realized, I know exactly what he means, but I don't actually know how to pronounce that word.
<fwereade> jam, I can say what I think it should sound like in the standup, but I'm not *certain* that I haven't just made that up
<jam> fwereade: https://www.google.com/search?client=ubuntu&channel=fs&q=eponymous&ie=utf-8&oe=utf-8 has a "pronounce it" button
<fwereade> jam, well, google agrees with me
<fwereade> jam, not sure that's enough to pronounce myself "right" but I'll go with it ;)
<jam> fwereade: :)
<jam> fwereade: LGTM with some trivials
<jam> for your arch doc
<jam> https://codereview.appspot.com/91390043/
<fwereade> jam, thanks, I'll work those into the next CL
<jam1> fwereade: so API versioning again. I like the idea that changing the Version argument can change the type of the thing being returned, but changing the Id should *not* be allowed to do so.
<jam1> However, with us just registering a "give me an object" function
<jam1> we can't quite tell the type without actually getting a concrete one.
<jam1> the existing code used static introspection of functions to do some of this
<jam1> what I'd *like* is to be able to have
<jam1> instead of Register(func(State, Resources, Authorizer) (interface{}, error))
<jam1> instead have
<jam1> Register(func(State, Resources, Authorizer) (FixedType, error))
<jam1> but I'm not sure if you can actually get away with that.
<jam1> just because you need to be able to cast the function pointer you get to *something* to be able to call it (I think)
<wwitzel3> jam1, fwereade: you guys have time to chat about rsyslog API stuff real quick? voidspace and I are in a hangout
<fwereade> wwitzel3, sure
<jam1> wwitzel3: can you link the hangout?
<wwitzel3> https://plus.google.com/hangouts/_/canonical.com/moonstone
<fwereade> jam1, sorry, don't wait for me re standup
<jam1> fwereade: np
<fwereade> jam1, just 1 main thing: you have work items, but do you also have people writing proto-docs and handing over to evilnickveitch?
<jam1> fwereade: I believe the intent is to have Frank focus on some of that as he comes over to core
<jam1> or you're talking more about proto-docs before implementation of current feature?
<jam1> fwereade: for what I'm working on, I still haven't actually gotten enough implementation to know how its going to hang together, but when I get a bit further I would be happy to write how to use API versioning doc
<voidspace> jam1: as you suspected, bringing up new state servers doesn't rewrite the rsyslog conf on units
<voidspace> jam1: so we *definitely* need the additional notification
<jam> voidspace: so my guess is, that if you then bounce unit-wordpress-0 it will rewrite syslog.conf because it will read the new addresses from agent.conf
<jam> but I think we want to do it right away
<voidspace> right
<voidspace> we're working on doing it the right way
<jam> voidspace: I think ideally we would be writing rsyslog data from information we get directly from the API server, rather than punning the apiaddresses data
<jam> agent.conf (pie-in-the-sky) would be only enough information to get your real truth from the API server.
<voidspace> jam: we're going to add an RsyslogHostPorts endpoint (or similar) that effectively (currently) wraps APIHostPorts
<voidspace> I think :-)
<axw> jam: is there a way to merge an MP to trunk via LP?
<jam> voidspace: so thats good, we just need to change the ports as the data goes through.
<voidspace> right
<axw> jam: or do I need to branch/merge/push
<jam> axw: what trunk?
<voidspace> we'll currently just add the global port to each address
<axw> jam: gomaasapi
<voidspace> but that's easy to then change if we *actually* have different ports
<jam> axw: branch and push
<axw> ok, ta
<jam> axw: gwacl is controlled by our bot, but gomaas is manual
<jam> IIRC
<axw> yep, seems so. thanks
<wwitzel3> voidspace: https://code.launchpad.net/~wwitzel3/juju-core/009-ha-rsyslog-api
<perrito666> could someone please tal https://codereview.appspot.com/92320043/ ?
<perrito666> and yes, that is awk that I am using, I am from the past
<natefinch> perrito666: looking
<perrito666> natefinch: turns out it was a bit less trivial than originally thought :p
<natefinch> perrito666: heh, I never thought it would be trivial ;)
<perrito666> I am an optimistic guy
<natefinch> sleep 60 ...  well that inspires confidence
<natefinch> (not a judgement of the programmer)
<perrito666> mm, did I push that?
<natefinch> it's there, yeah
<perrito666> tx god for restores, bugs in bash in go are a pain to spot
<perrito666> s/restores/reviews
<natefinch> honestly, the problem is that we're just passing huge strings to bash.  That's not really the way we should be running terminal commands
<natefinch> the single { for mongo and the double {{ for go templates is particularly gnarly
<perrito666> natefinch: you should see how that outputs to the shell
<perrito666> '\"'\"' <-- that is '
<natefinch> heh
<natefinch> reminds me of "\\\\" for a literal \ in a regex
<natefinch> "http:\\\\\\\\"
<jam> perrito666: I'm ~ sure that you can change the agent.conf on machine-0 to just read "localhost:17070" and it would be happy
<perrito666> I can try
<jam> perrito666: that can potentially simplify your logic a lot
<perrito666> jam: true
<jam> perrito666: also, is it possible to use the values for "state-port" and "api-port" instead of assuming they are 37017 and 17017 respectively?
<jam> If it is hard to do, don't worry too much about it, as I don't think anyone has *actually* run with a non-standard port, but the configuration *is* ther.
<perrito666> jam: it is not that much effort to add it, I have been avoiding additions beyond necessity because restore is quite fragile and I did not want to make future/present bug hunting even harder
<natefinch> I wish we could just remove the port configuration, it would make our code significantly simpler.
<perrito666> brb
<natefinch> jam: how do I figure out what revision a branch is on, say if the code were copied to a github, for example?  .bzr/branch/last-revision  has a revision number, but the diffs look off
<jam> natefinch: every branch has its own revision numbering but the revision-id is unique. You can do "bzr revno" or "bzr revision-info" to get details
<jam> natefinch: and you can't exactly push a bzr branch to github
<jam> but otherwise you can pass "-d" to revision-info to select a different location
<jam> bzr revision-info -d lp:juju-core
<jam> for example
<natefinch> bzr revno worked.
<jam> natefinch: sure I just wanted to be clear that having the same revno doesn't mean it has the same contents, because if we are both at 2250 and we both commit, we'll both be at 2251 but have different revision-ids
<natefinch> the code was copied into git, but I wasan't sure if that would throw off bzr, but it seems  the .bzr stuff was left intact
<natefinch> jam: ahh I see
<jam> natefinch: so if you're using bzr-git, we might  be magic enough to map into git and then back into bzr again.
<jam> otherwise you wouldn't be able to do "bzr revno $GITLOCATION"
<natefinch> I presume revnos are at least unique per branch, right?  so trunk 2200 is a definitive revision
<jam> natefinch: it is, but pull/push can change the order of history and 2200 *can* become something different.
<jam> there are ways to enforce it (set append-revisions-only will refuse a push that would change revnos)
<natefinch> ew.... so, why even bother with revision numbers if they don't mean anything static?
<jam> natefinch: because most of the time (and the tool can help enforce it) they are static within a branch
<jam> and they are *far* more meaningful and understandable than hashes
<jam> if I tell you I changed it at rev 2500 in trunk, you can tell really quickly if your copy of trunk has the change I proposed
<jam> things like trunk branches should always have append_revisions_only set (I believe I did that for juju-core)
<jam> so push can't change the old numbers.
<natefinch> interesting
<natefinch> I do like numbers I can understand rather than just giant hashes that have no intrinsic meaning
<bodie_> mornin fellas
<natefinch> morning bodie_
<perrito666> sinzui: you can try turning on the restore test again
<sinzui> perrito666, I saw the  change and queued the test
<perrito666> great, not that I dont have faith but Ill be expectant
<fwereade> guys, I'm feeling somewhat sick, I'm going to go and lie down for a while, probably back later
<perrito666> ok, get better
<wwitzel3> natefinch: you want to assit with this code structuring?
<wwitzel3> assist
<natefinch> wwitzel3: oh yeah, sorry, one second, I'll get back in the hangout
<jam> sinzui: is there a new URL for reports.vapor.ws ? or is it intended to be private
<sinzui> jam, oh!
<sinzui> jam, I think abentley put it behind apache in the last 12 hours
<sinzui> http://reports.vapour.ws/
<jam> sinzui: ah, just directly not at the random port
<perrito666> hey, does anyone have the link to the doc from the sprint, it is not showing in my docs as shared with me
<perrito666> natefinch: well, apparently we where very consistent on not writing details regardin WAL
<perrito666> :p
<natefinch> perrito666: https://docs.google.com/a/canonical.com/document/d/1XZN2Wnqlag9je73mGqk-Qs9tx1gvOH0-wxMwrlDrQU4/edit#heading=h.hpeo5xue46ue
<natefinch> perrito666: if you go to google docs for canonical, it should be in the list of recent documents, which is where I ususally go to find stuff
<perrito666> ah, recent, didnt think of that
 * perrito666 facepalms
<natefinch> perrito666: it's ok, it took me like 6 months at canonical to start using recent :)
<perrito666> the fact that the listing of files for google docs looks like a teenagers windows desktop in the 90s does not help at all :p
<sinzui> perrito666, your revision is building now in CI. I hope to see a pass in the next 80 minutes http://juju-ci.vapour.ws:8080/
<perrito666> sinzui: oh the suspense
<perrito666> hey anyone around here was present at the HA talks, most precisely when you talked about WAL? I think I am on track but would love to double check
<perrito666> sinzui: yay, a dns humanly readable name cool
<sinzui> perrito666, PASS http://juju-ci.vapour.ws:8080/job/functional-backup-restore-devel/806/console
<perrito666> \o/
<Sebas_> hi folks :)
<voidspace> fwereade: ping
<fwereade> voidspace, pong
<voidspace> fwereade: you gave my branch an LGTM today
<fwereade> voidspace, that was nice of me :)
<voidspace> fwereade: it turned out I'd missed some of our copy-pasta config tests
<voidspace> fwereade: haha, it was premature of you ;-)
<voidspace> but yes, nice
<voidspace> fwereade: so I've fixed those tests to use the new format, including the ruleset for a single state server
<voidspace> fwereade: plus a test that if we have multiple state servers that we get entries for both (for the case of two) in the generated template
<fwereade> voidspace, <3
<voidspace> fwereade: essential testing the logic in the template
<voidspace> fwereade: should I ask for another look at the branch, or as it's *essentially* test fixes should I just reapprove?
<bodie_> fwereade: should we think about merging the action yaml parsing stuff into our code before dressing it for MR?
<fwereade> voidspace, the general answer is "use your judgment" -- if you're confident in it, and the approach has been LGTMed, don't feel you *have* to get *everything* rereviewed
<bodie_> or make those two separate mr's (we'd assumed the previous work was a discard)
<voidspace> fwereade: it's just fixing tests, and they all pass this time (*coff*) so I'm inclined to just re-approve
<voidspace> thanks
<fwereade> voidspace, go for it
<fwereade> voidspace, we have the landing bot after all, so all you *really* risk there is looking stupid if they keep on failing ;p
<fwereade> bodie_, keep them separate
<fwereade> bodie_, that CL is basically fine, I don't want it to grow and grow and incorporate more and more, that's painful for everybody
<voidspace> fwereade: if I was afraid of looking stupid I wouldn't get much done...
<bodie_> was that a dumb enough question?  ;)
<bodie_> yes
<fwereade> bodie_, until it's exposed in the UX, and until it's doing things that affect actual DB integrity/sanity, small incremental steps are great
<fwereade> bodie_, keep trying ;p
<fwereade> bodie_, I'm sure you can ask much dumber questions if you put your mind to it ;p
<bodie_> fwereade, I suppose the worst of them are the ones that remain unasked and instead are expressed as dumb code ;)
<fwereade> bodie_, exactly :)
<wwitzel3> anyone have a second to look at a screenshare and tell my why my tests are getting a state server not found error? fwereade, natefinch ?
<fwereade> wwitzel3, not much more than a second tbh, but I can try :)
<wwitzel3> https://plus.google.com/hangouts/_/canonical.com/moonstone
<natefinch> wwitzel3: ug.  I can look, though the tests that try to set up an environment always give me like 3 days of trouble
<voidspace> natefinch: we have 20 minutes ;-)
<natefinch> voidspace: luckily fwereade offered assistance for a second, which is almost certainly worth more than my 20 minutes :)
<Sebas_> hey there! I'm recently having an issue with lxc containers created by the juju-local in an ubuntu trusty
<Sebas_> I installed a new fresh ubuntu each time (3 times by now)
<Sebas_> the lxcbr0 is missing
<Sebas_> so everything is failing apart :(
<Sebas_> someone have's a clue of what can be or where to look?
<natefinch> Sebas_: can you pastebin your /etc/lxc/lxc.conf   /etc/default/lxc and /etc/default/lxc-net ?
<Sebas_> natefinch: of course!
<Sebas_> natefinch: just a minute
<natefinch> Sebas_: I'm not an lxc expert, but it sounds like maybe your lxc is configured to use a different bridge, which is a known problem with juju local
<Sebas_> natefinch: there's no /etc/lxc/lxc.conf
<natefinch> Sebas_: that's ok, there isn't for me either, I think that's the default
<Sebas_> hmmm but in the local machine exist properly
<Sebas_> like lxcbr0
<natefinch> Sebas_: check /etc/default/lxc-net    - that's where mine is configured to use lxcbr0, perhaps yours is configured differently for some reason
<Sebas_> natefinch: take a look http://pastebin.com/KN4XxqrD
<Sebas_> i'm comparing with a local virtualbox machine that is working
<natefinch> looks just like mine
<natefinch> Sebas_: Specifically what error are you seeing?
<Sebas_> natefinch: the bridge is just missing :(
<Sebas_> in the container
<Sebas_> its really wired
<natefinch> Sebas_: can you copy and paste the actual text? It'll help me find it in the code and maybe figure out what it's trying to do and why it's failing
<Sebas_> natefinch: the problem is that there isn't an error
<Sebas_> its just missing so, the from it can't access internet from the container
<voidspace> EOD folks
<voidspace> g'night all
<voidspace> see you tomorrow
<natefinch> night voidspace
<Sebas_> voidspace g'night
<Sebas_> natefinch: whats your kernel? mine is 3.13.0-24-generic
<Sebas_> seems ok
<natefinch> Sebas_: I'm on 3.13.1, but I doubt that's the difference
<Sebas_> yep :(
<Sebas_> natefinch: i dump some dmesg
<Sebas_> http://pastebin.com/ZHjDkhHE
<Sebas_> just wat I thought is relevant
<wwitzel3> EOD for me
<perrito666> wwitzel3: bye
<natefinch> Sebas_: brb, I need to reboot
<perrito666> fwereade: still on the clock?
<natefinch> perrito666: he's salary, that means he's always on the clock ;)
<perrito666> natefinch: I have no clue what that means
<perrito666> :p
<natefinch> perrito666: salaried vs. hourly wages.  he gets paid the same amount whether he works 20 hours a week or 120.  In theory, "on the clock" applies to people who have to clock in and out because they're paid by the hour (wage).
<perrito666> ahh I see no such linguistic distinction in spanish
<perrito666> salary person means you get paid :p and then you need to specify by/the X
<natefinch> yeah, we say salaried vs. hourly to differentiate
<perrito666> anyway, I just wanted to know what percentage of his attention was still on the screen, which apparently amounts to 0 :p
<natefinch> haha well, it is rather late there
<perrito666> If I understood correctly the adding wal to mongo was only to add --journal to the mongo-db invocation, and perhaps find a way to test that
<perrito666> I was just hunting for someone that actually took part on that conversation
<natefinch> perrito666: if --journal is defined by the mongo docs as turning on WAL, then all you need to test is that we call --journal.  No need to test that mongodb does what it says it'll do
<natefinch> and maybe contemplate what happens when someone upgrades from a previous juju that didn't specify --journal
<perrito666> natefinch: so it says :) http://docs.mongodb.org/manual/tutorial/manage-journaling/
<Sebas__> natefinch: thoughts ? :P
<natefinch> Sebas__: sorry, got distracted.  Is the problem then just that the containers can't contact the internet?
<Sebas__> natefinch: btw thanks for your help :)
<natefinch> Sebas__: doing my best, but you've unfortunately encountered the Juju dev with the least amount of Linux experience :)
<Sebas__> yep, because of the missing lxcbr0 bridge
<natefinch> Sebas__: you said you had lxcbr0 on your local machine, right?
<Sebas__> yes
<Sebas__> but not into the container
<Sebas__> which is wired hehe
<natefinch> Sebas__: so, the container doesn't need lxcbr0.... mine don't have that, and they can contact the internet just fine
<Sebas__> hmmm
<Sebas__> natefinch: you are right!
<Sebas__> so now i more lost
<Sebas__> hehe
<natefinch> perrito666: do you know anything about lxc containers and their networking?
<perrito666> natefinch: very little you want to ask to vladk|offline or dimitern
<Sebas__> the thing is that, it isn't a random error
<Sebas__> is with fresh installed ubuntu trusty
<perrito666> lxbr0 iirc is the virt interface for bridging lxc containers, the containers themselves should have "regular" ifaces
<Sebas__> perrito666: yeah, and it seems it haves, i checked now
<Sebas__> and the eth0 is there like it should
<natefinch> Sebas__: so, all juju does is make LXC containers using the usual methods. It's not really doing anything magical to the containers.  I don't know why your containers are broken, but it's likely an environmental issue rather than a juju issue, per se.  I know that doesn't help you much, though.   You might try getting on #ubuntu and seeing if someone there can help debug your lxc issues.
<Sebas__> ooh ohh! i think i know what is it
<Sebas__> natefinch: you are correct
<Sebas__> till now I didn't know what was it
<Sebas__> but
<Sebas__> i ping just the ip to see if wasn't an resolve problem
<Sebas__> of geteway
<Sebas__> and it pings!!
<Sebas__> im going to try to route by hand
<natefinch> cool :)
<natefinch> brb, gotta water the carrots
<Sebas__> natefinch: yeah but the route already exist :(
<Sebas__> damn it !
<Sebas__> hehe
<fwereade> perrito666, passing by briefly: http://docs.mongodb.org/manual/tutorial/manage-journaling/ seems to imply it's on by default (at least on 64-bit) -- might we be thinking about the writeconcern, which I think needs fixing too?
<natefinch> fwereade: I have writeconcern in a different branch.  Possibly this is a noop then
<fwereade> perrito666, cool -- it's still worth doing for 32-bit systems though
<perrito666> fwereade: indeed, for what I see we even have tests that check for journaling stuff happening, we seem to be assuming it on by default
<perrito666> ok, eod for me
<perrito666> bye guys
<natefinch> perrito666: see ya
<thumper> cmars: morning
<cmars> hi thumper
<thumper> cmars: when I organised our chat in about an hour I had forgotten about a physio appt I have
<thumper> cmars: can we push it back an hour?
<thumper> so in 1:50?
<cmars> sure
<thumper> thanks
<thumper> I'll put in the calendar this time
<fwereade> thumper, btw, my eyes glazed over a little looking at that CL, but progress seems sane -- was there anything in particular you wanted to talk about?
<thumper> fwereade: agreement on direction mainly
<fwereade> cmars, not sure if you saw my review; I'm mainly just unsure what forces prompted it. separate certs for state vs api seems perfectly sane to me, I just haven't thought through the upgrade process and wanted to be reassured that someone had
<sinzui> hello rocket scientists. Does anyone have a strategy for using a newly built tool for an arch not in the streams. I want to add-machine a ppc instance. Ubuntu never published an official juju-core 1.18.2, but I tested a tool that I want juju to use when provisioning
 * sinzui ponders creating a private stream with  extra tools.
<sinzui> natefinch, ^ have you ever pondered this
<fwereade> sinzui, that would be my advice -- wallyworld's `juju metadata` stuff should make it doable?
 * fwereade waves his hands enthusiastically
<sinzui> fwereade, yes, I can do that making a new stream. I can change juju-metadata-tools exactly once because of a bug in juju
<fwereade> sinzui, hmm, is that failed mutability or failed immutability?
<wallyworld> you should be able to create metadata for just the one tarball, and put that plus the tarball in cloud storage. it will look there and fallback to streams.c.c for other arches
<sinzui> fwereade, we cannot change *-metadata-url once set, but we can bootstrap with out it (use streams.canonical.com), then change it once later
<fwereade> wallyworld, I still get nervous about the falling back :)
<fwereade> sinzui, heh, failed immutability then
<sinzui> I reported the tools version of the bug, other users reported the image- version of the bug
<fwereade> wallyworld, do you recall why we made those immutable? I can see how it *could* be a can of worms, but there's a clear use case there as well
<wallyworld> fwereade: can't recall now sorry :-( i'm sure it was a good idea at the time
<wallyworld> also, it never used to fallback, but we made it so
<sinzui> fwereade, Once juju-1.18.2-trusty-ppc64el.tgz is know to the juju-ci-3 env, I am 30 minutes from have two slaves in two different networks to prove trans-cloud envs rock
<sinzui> wallyworld, It might have made sense to not let you change the values before we added mirrors
<fwereade> wallyworld, yeah, I think the falling back was a bit of an act of desperation... if it's *possible* to find *some* tools, please do :)
<fwereade> sinzui, awesome
<wallyworld> fwereade: don't quite grok the last tools comment. the fallback thing was to allow some tools to be found in cloud storage, say, and the rest from streams
<fwereade> wallyworld, yeah, it's precisely that that makes me nervous -- 2 different locations for tools raises an unholy spectre of two different versions of juju that think they're the same
<fwereade> wallyworld, it's something that scares me, but probably not something I ought to get too stressed about
<fwereade> wallyworld, and the happy path is evidently happy
<wallyworld> i sorta agree but users complained and it was not usable the other way
<bodie_> famous last words
<fwereade> wallyworld, I'm just whining, you know how I love to do that
<wallyworld> you are english :-)
<fwereade> bodie_, I've had 6 months since I first said them ;p
<wallyworld> sinzui: do you have all you need to try out the jenkins github lander with my test core repo? is there anything i can do?
<sinzui> fwereade, wallyworld . I think the scenario here is ops may want to choose new source for images and tools. They certainly want just one source. they may want to change the source to get special images or tools. private clouds need to do this if they move things. envs in public clouds may want to get special streams
<waigani> morning all, back again :)
<sinzui> wallyworld, I need time. I don't think I can start the tests until monday.
<wallyworld> no worries, just ensuring i didn't need to do anything else to help
<wallyworld> not urgent :-)
<fwereade> sinzui, that was sorta my perspective; definitely +1 on making them mutable; *also* +1 on mandating a single source, but my nightmares re allowing multiple have not yet come to pass, so your job right now should be easier even if not for my favourite reaons
<wallyworld> sinzui: if that url bug is not already high, we can add it to the high pool
<bodie_> fwereade -- I'm getting a strong spidey sense about the way we're trying to do Actions.  can you help me understand why it's necessary for the hook to trust the action info?
<bodie_> if I were writing an Action hook, I'd be parsing args myself
<bodie_> unless I'm misunderstanding the purpose of this
<fwereade> bodie_, one somewhat-significant reason is so that we can provide a nice gui for it, but that probably shouldn't be (the* overriding reason within core
<fwereade> bodie_, declaring what an action accepts in a standard format STM to be a Good Thing on general principles, too, fwiw
<fwereade> bodie_, and if we *do* guarantee that the data we deliver will match the declared interface, we should be able to save charm authors quite a lot of boilerplate checking
<fwereade> bodie_, if we don't, I think we add quite a lot to the burden of implementing an action
<fwereade> bodie_, imagine how bad it would suck if every single method just took (args ...interface{})
<fwereade> bodie_, spidey-sense rising or fading? ;)
<cmars> does anyone else see intermittent failures in cmd/jujud when running all the tests? they usually disappear if I 'go test ./cmd/jujud' by itself
<thumper> yes
<bodie_> fwereade, I see regarding reducing Action boilerplate
<bodie_> should've mentioned I was stepping away
<bodie_> yes, it seems like everything using interface{} would somewhat defeat the utility of Go ;)
<bodie_> yet if we're using json-schema on the charm, why is it OK to define in a yaml file?
<wallyworld> cmars: we're working on fixing the test suite but there's a lot to work through
<wallyworld> fingers crossed we'll get it sorted real soon now
<cmars> wallyworld, thanks. I was mostly wondering if it was just my dev env
<wallyworld> nah, the bot is sad too
<wallyworld> cmars: feel free to file a bug tagged test-failure and we can look to ensure it's not a new issue
<wallyworld> thumper: if you are interested or have a spare moment, i'd love a look at https://codereview.appspot.com/94410043  it consolidates the lxc clone settings
<thumper> will look later
<wallyworld> no hurry
<sinzui> wallyworld, any insights? http://pastebin.ubuntu.com/7459884/
<wallyworld> looking
<wallyworld> sinzui: can you also paste the index file?
<sinzui> wallyworld, http://pastebin.ubuntu.com/7459905/
<wallyworld> sinzui: sadly there's a lack of logging in the code around where i suspect it's failing, i'm still looking
<waigani> menn0: standup :)
<wallyworld> can we get the all-machines.log?
<sinzui> wallyworld, thank you. I have a fallback plan of bootstrapping the machine as a separate env.
<wallyworld> sinzui: before you do, grab the all-machines.log for me and i'll look at that
<wallyworld> i think it's failing creating the manual provisioning script
 * sinzui does
<sinzui> wallyworld, oh, 403. damn, when I recreated this container it lost the public permissions
<sinzui> wallyworld, I see a ppc64 machine on a different cloud being provisioned
<perrito666> sinzui: still around?
 * sinzui is so excited
<sinzui> perrito666, I am
<perrito666> sinzui: I have a patch proposed for HA restore, I was wondering if I should push it once its reviewed or if there is a CI test for that story in the foreseeable future
<perrito666> no pressure
<sinzui> perrito666, I will have a test running tomorrow morning or even tonight. I sketched it out last week.
<perrito666> wow you are fast :) there is a comment asking this on the bug, if you couuld add the info as an answer there once the test is there I will be very thankful
<perrito666> (also I will be happy not to do that by hand again :p)
#juju-dev 2014-05-14
<wallyworld> sinzui: just got back from vet, haven't looked at log yet. does the above scrollback mean your ppc64 tools issue is solved?
<sinzui> wallyworld, almost. The tools not found issue was because juju was swallowing a 403
<wallyworld> well that sucks, the error needs to be propagated
<sinzui> wallyworld, I need to get creative with /etc/hosts to get access to download the actual tool. the lab shouldn't need access to the tools
<sinzui> wallyworld, This is a cases where streams.canonical.com is the correct site to get tools., but ubuntu didn't build tools to put there
<wallyworld> ok
<wallyworld> axw: morning. standup?
<axw> wallyworld: morning, otp with waigani
<wallyworld> ok, ping me when you're free
<axw> wallyworld: free now
<waigani> wallyworld: sorry, for stealing axw, didn't realise it was your standup
<axw> wallyworld: I need to get a proper webcam... I get that weird crackly feedback, but only on G+ for some reason
<wallyworld> G+ maxes out my cpu also
<wallyworld> so it's not my favourite
<axw> wallyworld: https://bugs.launchpad.net/juju-core/+bug/1317197/comments/14
<_mup_> Bug #1317197: juju deployed services to lxc containers stuck in pending <oil> <juju-core:Fix Committed by axwalk> <https://launchpad.net/bugs/1317197>
<axw> I hope that's clear enough
<wallyworld> yeah, looks good, thank you
<wallyworld> we do the the status stuff at some point cause if things take a while to complete that's useful
<axw> yes absolutely
<axw> just didn't want ryan to think we were doing something that we weren't
<stokachu> wallyworld: in order to speed up downloading of cloud images is there a way to specify a root image tarball to lxc-create via juju?
<stokachu> its only 175M so not a huge deal but times like tonight its slow for some reason
<wallyworld> not that i am aware of directly. maybe you could put the tarball in the lxc cache dir
<stokachu> wallyworld: ahh good idea
<wallyworld> the same place where lxc would put it
<stokachu> can use juju scp or something
<wallyworld> not sure of exact details
<stokachu> wallyworld: ill mess around with it and let you know
<wallyworld> ok
<stokachu> wallyworld: it is so much faster already btw
<wallyworld> great :-)
<wallyworld> demos going well?
<stokachu> yea there is a contest going on in getting an openstack cloud deployed in under 30 minutes
<stokachu> i think i can make that happen with this cloning
<stokachu> all in kvm's/lxcs
<stokachu> the quickest install is 33 minutes i think
<wallyworld> are you deploying stuff to the kvm instance?
<wallyworld> of just to the lxc containers?
<stokachu> yea ive got like 8 kvm's running
<stokachu> 1 kvm with nested lxcs for cloud controller and other bits
<stokachu> 1 for compute
<stokachu> 3 for swift, and 3 for swift-proxy
<wallyworld> so all charms are deployed to lxc
<stokachu> so 8 kvms and 7 lxcs
<stokachu> swift, swift-proxy, nova-compute are on separate kvms
<stokachu> but everything else is on lxcs nested within 1 kvm
<wallyworld> there's a bug whereby if you deploy charms to kvm *and* start lxc containers within that kvm host it could fail
<wallyworld> but sounds like you are not affected
<stokachu> i manually bind the lxc bridge to eth0 in the kvm
<stokachu> with some juju scp magic
<stokachu> and restart the kvm node before deploying the lxcs
<wallyworld> ok
<stokachu> wallyworld: otherwise https://bugs.launchpad.net/juju-core/+bug/1304530
<_mup_> Bug #1304530: nested lxc's within a kvm machine are not accessible <addressability> <cloud-installer> <kvm> <local-provider> <lxc> <juju-core:Triaged> <https://launchpad.net/bugs/1304530>
<stokachu> that issue happens
<wallyworld> yeah, that's being worked on this cycle
<stokachu> ok cool
<stokachu> not a blocker since i can work around it
<wallyworld> good :-)
<stokachu> yea i think if the nested lxc's would honor the network-bridge option in the environments file
<stokachu> that could work
<stokachu> but im sure there is a better approach
<wallyworld> i'm not sure tbh, but at this point any approach that works is good i reckon
<thumper> davecheney: do you have a list of the tests that currently fail on power?
<davecheney> thumper: two secs
<davecheney> didn't I include that in my mail ?
<stokachu> wallyworld: im sure people will want vlan support within those lxc's maybe
<wallyworld> understandable
<stokachu> though it probably only matters with local provider
<stokachu> since maas does vlan now
<thumper> davecheney: no, there was a link to the ppc64el bugs in juju-core, but no list of currently failing tests
<menn0> davecheney: what does SGTM mean in a review comment? Sounds Good To Me or Silently Giggling To Myself? :)
<thumper> menn0: the frist
<menn0> davecheney: thumper: I figured. Next question, does the landing bot treat SGTM the same as LGTM?
<thumper> I don't think so
<menn0> ok thanks for clarifying
<davecheney> menn0: sounds good to me
<menn0> I saw davecheney use it and wasn't sure if it has special meaning to the landing bot
<thumper> davecheney: also, any idea why juju/errors tests fail with gccgo?
<thumper> davecheney: I can't see it myself
<thumper> davecheney: given that I had the ones in arrar passing with gccgo
<davecheney> on da phnoe
<thumper> kk
<davecheney> menn0: the sgtnm/lgtm thing comes from code review
<davecheney> lgtm (case insensitive) trigger the green success line in code review
<wallyworld> thumper: we want to introduce a universally used base test suite to kill outgoing http egress, protect the user's home real dir, encapsulate loggingsuite etc - do you like the name "BaseSuite"?
<davecheney> even if you say
<davecheney> there is no way in hell i would lgtm this in a millino years
<thumper> wallyworld: sounds fine
<davecheney> it's still a thimbs up
<davecheney> so, sgtm is a way of saying i like it, but i'm not prepared to put my name to it
<davecheney> thumper: i'll take a look a tthe errors tests now
<davecheney> i have trusty and gccgo
<thumper> davecheney: to avoid the juju/errors package
<thumper> you could just start with juju/errgo
<menn0> davecheney: makes sense. thanks.
<thumper> which also fails with gccgo
<thumper> get the foundations right first I guess
<davecheney> thumper: got time for a hangout
<thumper> yup
<davecheney> i think i'm confused about which error packge is broken
<thumper> :)
<davecheney> this being able to hangout with your boss thing is sorta neat
<davecheney> ... only taken 2 years
<thumper> davecheney: https://plus.google.com/hangouts/_/g36ayyi6golhypoflszins4leia?hl=en
<axw> wallyworld: if you haven't thought about this already: the thread on signature wrapping reminds me that we should create a git pre-push hook, a la lbox.check
<axw> wallyworld: also, would be nice to run the checks in the lander bot, if we don't already
<wallyworld> agree with lander bot checks, hadn't thought of a pre push hook
<wallyworld> sounds like a good idea
<wallyworld> i was deferring thinking about it till next week when hopefully there'll be some progress on the jenkins side of things
<rick_h_> wallyworld: we do that https://github.com/juju/juju-gui/blob/develop/HACKING.rst#hooks and then in our CI lander side http://ci.jujugui.org:8080/job/juju-gui-merge/
<wallyworld> rick_h_: awesome, thanks, we'll look to do something similar
<rick_h_> wallyworld: yea, let me know if you want a run through the lander stuff we setup when you get that far https://github.com/juju/jenkins-github-lander
<wallyworld> rick_h_: will do. curtis was going to start looking at setting up juju-core's jenkins next week
<rick_h_> wallyworld: cool
<wallyworld> i already have a migrated repo to test with
<rick_h_> very nice
<wallyworld> github/wallyworld/core
<rick_h_> when you get the migration script let me know. We want to move more stuff over but we didn't have it collapse commits so our history is messy
<wallyworld> has a pending pull request to merge and everything :-)
<rick_h_> :)
<wallyworld> i have the migration steps which i follow, and i think i collapsed history
<rick_h_> cool maybe I can see if sinzui's team has the bandwidth to subordinate the lander code for jenkins
<rick_h_> wallyworld: cool, yea when I use bzr fast import it didn't collapse so lots of old commits of "fix lint"
<wallyworld> rick_h_:  i used these steps http://flexion.org/posts/2012-10-migrating-bzr-to-git.html
<wallyworld> rick_h_: as a rule, i hate how git workflow seems to be to rebase out history
<wallyworld> throws away information
<wallyworld> bzr's model is much nicer
<rick_h_> yea, but it's usually useless information ime
<wallyworld> hide it by default, but show it if needed
<rick_h_> but I can appreciate both sides
<axw> wallyworld: can you please update gomaasapi on the bot?
<wallyworld> sure
<axw> rick_h_: is there a way to see old comments in GH after you rebase?
<axw> line comments
<rick_h_> wallyworld: can you see https://bazaar.launchpad.net/~rharding/juju-gui-lander/trunk/files
<rick_h_> axw: it leaves the comments, but marks them as "xxx commented on an outdated branch"
<axw> hmm, when I have done PRs the comments always disappear after I rebase and push -f
<wallyworld> rick_h_: yep
<rick_h_> wallyworld: so might be useful to sinzui as well I don't know. That's the scripted setup we used to migrate
<rick_h_> wallyworld: the git upload, the jenkins deploy/initial install/etc
<wallyworld> rick_h_: ok, ta. i've sent curtis the link previously
<rick_h_> wallyworld: there's some api creds and such in there which is why it's private
<rick_h_> ah ok
<wallyworld> well, i think so
<sinzui> that doesn't look right
<sinzui> bzr-git and git-bzr can preserve commit histoyr
<sinzui> I symlink my .bazaar/ignore to .gitignore
<rick_h_> axw: https://github.com/juju/juju-gui/pull/303 (hatched commented on an outdated diff 2 days ago)
<wallyworld> sinzui: i think the issue is we need to rebase to get a single revision for merging?
<rick_h_> axw: and click on the '2 days ago' to get the comment in with a snippet
<axw> rick_h_: cool, thanks
<davecheney> aaaaaaaaaaand, that's lunch
<wallyworld> axw: gomaasapi on rev 50 now
<axw> wallyworld: thanks
<sinzui> wallyworld, Yeah,  git is like multi-inheritance  diamond parents. Just fucked. bazaar was smart in that respect. the left-hand ancestry is special and we can traverse that to learn the direct commits and choose to go deeper later
<sinzui> wallyworld, rebase is essentially a hack to fix a logging problem
<rick_h_> heh, every commit is in teh reflog, just how easy can you get at it ;P
 * wallyworld will miss bzr :-(
<sinzui> wallyworld, since juju likes informative commit messages with links, it is essentially at odds with most projects that use git. They want all the details squashed to a single line
<wallyworld> yeah, i hate that :-(
<rick_h_> huh? I disagree with that
<sinzui> wallyworld, We might have a policy to never delete the branches from our public repos. They have all the commits. The merge bot will create a squashed commit using the pull request subject and description
<wallyworld> might be all we can do
<sinzui> the merge bot would include the link to the source branch with preserved history
<sinzui> No one needs to rebase
<rick_h_> maybe auto push to a second remote to track all commits?
<rick_h_> it'll be a bit nuts to have all branches ever in github
<rick_h_> and we force users to fork so they can keep their branches in their own fork if they want
<rick_h_> so that the main repo looks clean
<rick_h_> https://github.com/juju/juju-gui vs https://github.com/mitechie/juju-gui
<sinzui> rick_h_, I assumed that developers would be using the triangle trade arrangement. The juju/juju just has stables a devels with the squashed revs. The commit message will have a link to the developer's repo with the squashed revs
<sinzui> But we could have juju/juju-deep which is where the merge bot puts a copy of the unsquaded branch
<thumper> juju/juju?
<thumper> are we not having juju/core?
<wallyworld> not, it's juju/core
<wallyworld> s/not/no
<davecheney> sgtm
<davecheney> juju/sgtm
<wallyworld> lol
<thumper> otherwise we'd have "github.com/juju/juju/juju"
<davecheney> yeah, no
<wallyworld> we decided at the sprint it would be core
<thumper> \o/
<thumper> hmm...
<thumper> I notice that the .jenv file has a user and password entry at the top of it
<thumper> but both are empty strings
<thumper> why?
 * thumper steps away for a bit as heaps of calls later tonight
 * thumper needs to put on dinner
<menn0> can anyone confirm whether it's possible to use API and state port numbers other than the defaults?
<menn0> I know they can't be changed once an env is bootstrap but could someone use a different value at bootstrap time
<axw> menn0: yes I have done this in the past
<axw> it's necessary when using the local provider with multiple users on the same host
<menn0> ok cool.
<menn0> I was reviewing a change to "juju restore" and noticed it generates bash scripts with hardcoded port numbers.
<menn0> I guess my review comments are valid concerns then :)
<axw> cool
<menn0> thanks
<axw> was just about to review that. now I have to stop procrastinating... :)
<jam> perrito666: the journal thing is a parameter we have to pass on the Session/Write request.
<jam> fwereade: ^^
<jam> wallyworld: fwereade: IIRC the specifics of why we fallback was because we had the "released" vs "daily" streams, and it was searching the "daily" and not finding any "released" items and then stopping. And when we discussed it, it seemed better to keep searching.
<wallyworld> jam: and also, people adding their own images etc as overrides
<wallyworld> i'm ok with it, william seems twitchy about it
<jam> wallyworld: pre-checks ala lbox propose, we *can* but if it is things like "go fmt is sad" I'd rather just have the box run go fmt and clean things up than stall someone to tell them to go run a command and propose again.
<wallyworld> i don't mind either way tbh
<jam> wallyworld: you don't have to rebase, and I'd rather we didn't have single commit for review
<jam> git does have "git log --follow-first-parent"
<wallyworld> my git foo is poor, i'm just going by what curtis etc said at the sprint. curtis will be doing the landing side of things pretty much so we can liaise with hin to et the model right
<jam> I certainly don't have final say in any of this, but while I don't think we need all branches on master, I'd really rather we didn't rebase to land
<wallyworld> i think it was being canvased to allow a single rev to be easily cherry picked etc
<wallyworld> like we do with bzr with backports etc
<jam>  wallyworld: for cherrypicking you can do "merge ABCD ~ ABCD^" IIIRC
<jam> wallyworld: which is the same meaning as "bzr merge -c"
<jam> just different syntax
<jam> $REV^ is the parent of REV
<jam> aka, before:REV or REV-1 to bzr users
<wallyworld> i'm totally ok with whatever folks who know git recommend
<jam> wallyworld: well in the git world you can still do things in different ways, I'd like to push back on how the gui guys decide
<jam> decided
<jam> because I think you can use git in a form that allows easier exposure of specific detail
<wallyworld> i don't like how git rebase discards history
<jam> Though, TBH, if rebase still refers to the old commits in a sensible fashion, that might be ok, but I don't quite see how it works
<wallyworld> if we can work aornd it, great
<jam> vs giving you the detail only if you have the magic revs that aren't pulled in by default
<wallyworld> i just want to it work like bzr :-)
<wallyworld> so for dev workflow, i hope we just push up the raw branch, and let the landing bot sort out how to deal with the final merge
<wallyworld> so we need to talk to curtis et al about the rules for that
<jam> wallyworld: interestingly you can "git rebase --exec $RUNMYTESTSUITE" which is nice
<wallyworld> what does that do? rebase and then run the tests?
<jam> wallyworld: I believe it runs the test after each rebased commit
<wallyworld> ok
<jam> wallyworld: conceptually I'm hesitant about throwing away history. Though having someone actually spend time to make sure there is logical meaning to commits is nice, having a policy of "throw away all the stuff you were thinking about at the time and only give me a summary" isn't great either.
<jam> Often when spelunking I'd really like to understand why someone changed *this exact line* rather that "this was changed as part of doing foo"
<wallyworld> jam: i'm +1 on that, hence i dislike rebase
<menn0> wallyworld: jam: I get what you guys are saying. There are definite downsides to overuse of rebase but that's more a policy/process thing IMHO.
<jam> menn0: gui's policy is that every commit gets squashed when merging to master
<jam> which I disagree with
<wallyworld> i guess they view commit history as noise?
<menn0> wallyworld: jam: one thing I'm finding with bzr is that I'm committing less often because I know it's much harder to go back and tidy things up.
<jam> wallyworld: by default "git log" shows everything in time-sorted order
<jam> it doesn't have the indented logging that bzr has
<wallyworld> which is poor :-(
<jam> so you don't have "here is a summary commit, and here are the commits that made up that summary commit"
<wallyworld> exactly
<menn0> git log output has tons of configuration options
<jam> wallyworld: yes, but we paid *a fuckton* of CPU for it that lots us a lot of hearts and we weren't quite good enough at explaining why
<jam> it is actually quite expensive to compute
<jam> menn0: but not that one
<jam> it does have --follow-first-parent
<menn0> brb
<jam> which will get you "bzr log -n1"
<jam> and it does have topological sorting
<jam> but topo doesn't help when 2 people are doing concurrent work
<jam> neither one is "before" the other
<jam> the sort bzr uses is "include a commit after the last commit that didn't have it, and before the one that does"
<jam> but doing the "what commit doesn't have this" is expensive to compute
<wallyworld> O(n) ? or O(what?)
<jcw4> fwereade: https://codereview.appspot.com/98260043
 * menn0 is back from dealing with vomiting child...
<jam> wallyworld: so to be able to compute lots of them fast, the algorithm isn't bad if you just walk the whole history, as you can push on a stack everything you've seen so far. So the one we use is O(N=all_history)
<jam> to do it by walking just a bit of the graph
<jam> it easily gets into N^2 or N^3 or thereabouts because of needing to do backtracking
<jam> so N is smaller, but the order is higher
<wallyworld> ok
<jam> wallyworld: so I still love it, and for histories the size of Juju it is actually still a wonderful view of the world (IMO)
<jam> but for things like the kernel/mozilla/etc it made things slow
<jam> and, of course, it is off by default in bzr, too with "bzr log -n1" being the default
<jcw4> fwereade, bodie_ I made some changes after the discussion today and put in a new MR.  I didn't implement the Unit cleanup yet.  Some prerequisites still arent in.
<menn0> jam, wallyworld: would it help if we followed a different policy than the GUI team in terms of squashing commits. it's not a given that we do that is it?
<jam> wallyworld: "time bzr log -n1 -r -10..-1" vs "time bzr log -n0 -r -10..-1" is 85ms vs 250ms on juju today, which is noticeable
<jam> menn0: no it isn't a given, but that's why I'm bringing it up
<wallyworld> we can decide how *we* want to do it
<jam> menn0: we *are* switching to git, that has been enforced on us
<wallyworld> :-(
<menn0> in my experience that's not at all standard practice
<jam> menn0: but the details are what we are hashing out, and I'm just participating in the discusison
<menn0> with git projects
<wallyworld> jam: i was going to experiment a bit once the test landing bot on my test repo got set up next week
<menn0> on projects that use git that i've worked on, people might do some tidying up with rebase before pushing but rarely down to just one commit.
<jam> menn0: so I think some cleaning up can be nice, but often I've wished people would have committed *more* detail because they aren't explaining the actual steps, just the global chunks
<menn0> it's usually about making things more coherent and easier to follow for other developers (and yourself in 2 weeks)
<menn0> jam: I get that.
<menn0> different people use different approaches when committing and rebase makes it easier for people to hide detail
<menn0> perhaps the best we can do is educate each other as part of the review process
<menn0> if you feel like someone didn't break up their commits into small enough pieces then call them on it
<jam> menn0: there seem to be projects in git that review your merge by the commits you did, so you have to clean it up into logical steps. Which can be good, but you can also lose some of the "why is it this way".
<jam> menn0: I really like the default of looking at the global thing rather than the individual bits , we can have multiple branches for landing something that needs evolution
<jam> I'm not sure the github default view, though.
<jam> Does it default to the global commit change or the individual commits?
<jam> menn0: so if merge --squash or rebase had a way to still reference the old commits and just not show them by default in log, that would be ideal for me, but I haven't seen a tool that really separates the two
<menn0> jam: yeah I've never heard of such a thing
<jam> menn0: so looms was bzr's evolution towards that, and bzr-pipelines is a good approximation of it. Where you have several branches and you are iterating among them.
<menn0> with git once you squash revs those old revs are effectively gone
<jam> And the tips of each branch are the "patch for review" while the individual commits are still there.
<menn0> jam: yeah i've read a little about looms
<jam> and then in bzr when you merge a commit, by default you only see the merge commit, rather than the details, but the details are all there.
<jam> menn0: and certainly things like stacked-git, or quilt, etc are also similar approaches.
<jam> though again, most of those are explicitly squashing the intermediates down to the final patch
<jam> menn0: like I think stacked git is actually a great workflow, but I wish it actually kept the intermediates as an alternate view.
<menn0> i've just been looking at the stacked git site and yeah it doesn't look it helps with keeping the intermediate commits
<jam> menn0: looms/stacked-git/etc have lots of nice process built in for managing multiple branches that you want to eventually apply all together, but still keep things in logical chunks
<jam> like what I'm working on now for the API Versioning has about 4 logical steps
<jam> start doing the internals, start exposing it on the server, start consuming it in the client, etc.
<jam> it is great to separate those out and still sync between them
<menn0> jam: yep that makes sense
<jam> bzr pipelines lets you create a "pipeline" aka stack of branches, and then switch to the first one, and "pump" the changes through the pipeline.
<menn0> jam: in the past I've done that kind of thing manually but it gets tricky when you get beyond a handful of concurrent branches.
<menn0> jam: a tool to help would sometimes be nice
<jam> menn0: yeah, I don't know state-of-the-art with git here. I bzr-pipelines are used the most on our team, and got the most love and attention. Looms had a potentially better data model, but were a bit bigger picture (you could merge looms at the conceptual loom level), and didn't actually get as much polish
<jam> the idea being that you could collaborate on the set of patches that are being tacked on
<jam> which is stuff that OS people do
<jam> because they track UPSTREAM and have their local (deb) patches applied, and need to sync from what Debian is doing to how Ubuntu is doing, etc.
<axw> wallyworld: are you fixing the TestConstraintsValidator network isolation? if not I will
<menn0> jam: yeah I've maintained a linux kernel fork for a product before. I know the problem space
<wallyworld> axw: not explicitly but it will be done as part of the overall network isolation work
<wallyworld> so yeah, i'll do it
<axw> wallyworld: ok. it is calling out to cloud-images.ubuntu.com
<axw> wallyworld: seems to be only provider/maas
<wallyworld> axw: i was leaving it till i go the framework in place to see that it failed :-)
<axw> wallyworld: I just ran the tests with "unshare", as described in #1233601
<_mup_> Bug #1233601: juju test suite should be isolated and do 0 outbound network requests <test-failure> <testing> <juju-core:Triaged> <https://launchpad.net/bugs/1233601>
<axw> that was the only test that failed
<menn0> wallyworld, jam: potentually useful for the basics: http://agateau.com/talks/2010/git-for-bzr-users_uds-natty/git-for-bzr-users.pdf
<axw> wallyworld: eh sorry, only package. 3 tests failed in maas
<jam> menn0: mercurial had "mq" or mercurial queues to work in the same process space, but it seems stacked-git is the only similar one for git
<wallyworld> ok, i thought there was one for store also
<axw> wallyworld: *shrug*, did not fail in my run
<wallyworld> axw: you know the one i mean? it shows up in failure logs but i haven't looked in detail yet
<menn0> anyway I've got to go... see you'll tomorrow
<menn0> you all even
<axw> wallyworld: I forget. I've seen store fail in the past, but not atm
<axw> later menn0
<wallyworld> axw: i can't recall the specifics right atm. it's in the logs somewhere
<jam> wallyworld: how did you end up doing the conversion?
<wallyworld> jam: http://flexion.org/posts/2012-10-migrating-bzr-to-git.html
<wallyworld> seemed to work fine
<wallyworld> htp://github/wallyworld/core
<wallyworld> i didn't rename any authors though
<jam> wallyworld: sounds about like how I'd do it
<wallyworld> jam: good :-) must be right then :-)
<wallyworld> it did work nicely
<jam> An interesting alias:     ll = !git --no-pager log --first-parent HEAD~10..HEAD --reverse --pretty=short
<jam> matches pretty close to my default bzr output, though doesn't have *any* datestamp
<wallyworld> a good start i guess
<jam> I personally find dates like: Mon May 12 09:28:05 2014 +1000 to be a bit too complete
<jam> vs just ISO dates
<wallyworld> yep
<jam> wallyworld: git log --date=iso
<jam> :)
<wallyworld> once small hurdle solved
<wallyworld> so many more to go
<jam> git log --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit
<jam> is quite pretty
<wallyworld> niiiiiiiiice
<jam> I still like --first-parent logs, but having a terminal graph is fun
<jam> git --no-pager log --first-parent --reverse --pretty=tformat:"%C(yellow)%h%Creset%<|(25) %an %ai%n        %B" -10
<jam> is the closest I could get to my "bzr log --short --forward -r-10..-1" alias
<jam> I couldn't find a way to indent all lines of the body, though *maybe* %w()
<jam> wallyworld:     ll = !git --no-pager log --first-parent --reverse --pretty=\"tformat:%C(yellow)%h%Creset%<(25) %an %ai%n%w(72,8,8)%s%+b%n\" -10
<jam> that looks really close to "bzr log --short" though the date is full instead of just YYMMDD, and it doesn't have [merge] markers
<jam> found it, instead of "%ai" for iso date, use "%ad" and --date=short
<jam> [alias]
<jam>     ll = !git --no-pager log --first-parent --reverse --pretty=\"tformat:%C(yellow)%h%Creset%<(30) %an %ad%n%w(72,8,8)%s%+b%n\" -10 --date=short
<jam> wallyworld: so the reason people like squashing commits is because 'git log' and 'giggle' and 'gitk' look nowhere near as nice as "bzr qlog" on the same data.
<wallyworld> well that's not a goof excuse :-(
<jam> you can tell what commits are "mainline" because tarmac puts "[r=" in the header, but it only takes a few commits before all of those are lost
<wallyworld> fix the tool, don't throw away data
<jam> wallyworld: if you're tool can't show you good history, you clean up your history first
<wallyworld> that's arse about
<jam> wallyworld: well, your preaching to the choir here, but if you try to look at the juju-core history with anything I've found it is a bit hard to figure out what is going on
<jam> outside of about 3 steps
<jam> and if you do "gitk --first-parent" it shows you just the mainline
<jam> but for some reason, it wants half of the merges to be from the right, and half from the left
<wallyworld> jam i get a syntax error with git --no-pager log --first-parent --reverse --pretty=\"tformat:%C(yellow)%h%Creset%<(30) %an %ad%n%w(72,8,8)%s%+b%n\" -10 --date=short
<jam> wallyworld: if you are pasting it into shell, you need to remove the "\"
<wallyworld> sigh
<jam> that is the escape for putting it in ~/.gitconfig
<wallyworld> yes
<jam> wallyworld: it took me a while to find the right escape point for gitconfig
<wallyworld> i didn't look too closely clearly
<jam> because without escaping " it treats the | as a shel lchar
<jam> well the <
<wallyworld> hey i like that latest log output
<wallyworld> i just wish the revs nums were monotonically increasing
<jam> ah, ffs, I figured out how log decides which commit comes first
<jam> alphabetical sort of the hash...
<wallyworld> i can't fathom the hashes
<wallyworld> why not date?
<jam> wallyworld: consider hashes arbitrary handles that you just have to copy & paste
<wallyworld> sure
<wallyworld> but not user friendly
<jam> wallyworld: sort of the hashes is because in the git world, everyone is "equal" there is no "mainline"
<jam> so me merging you is equivalent to you merging me
<jam> AIUI
<wallyworld> which is a design flaw to me
<wallyworld> not how most projects work, except maybe the kernel
<jam> wallyworld: anyway, that is why 'gitk' et al can't really do mainline, because they don't think about it, and they take the most arbitrary thing (the hash) and use it for sorting
<wallyworld> and yet we've been mandated to use it
<jam> it is a *stable* sort, I can give them that
 * wallyworld wishes we could use the best tool for the job
<jam> wallyworld: so there are certainly things that show git's had more man-hours put into it. Like the configurability of log is better than what bzr gives you
<jam> we'll get stockholm syndrome eventually
<wallyworld> hope not :-)
<wallyworld> you can pry bzr from my cold, dead hands
<jam> wallyworld: you can always polish up your bzr-git and have it both ways
<wallyworld> true, i need to look into that
<wallyworld> i also need to figure out how to make working with github nice
<wallyworld> from the cmd line etc
<jam> wallyworld: I believe working with github is "clone core into your own namespace, and then push and pull from there"
<wallyworld> sure, but all the bzr setup to allieviate typing i need to figure out - parent location based on repo etc etc
<jam> used named branches (don't commit directly to master), push those names back to github, merge from named branches to trunk.
<wallyworld> plus it keeps asking me for username and password all the time
<jam> wallyworld: git's "origin" policy works decent here, I think you have to set it up 1 per "repo" but then it should continue to work for all branches.
<wallyworld> yeah, that stuff i need to read
<wallyworld> haven't found time yet
<wallyworld> i need a "github for bzr/launchpad refugees" document
<TheMue> morning
<jam> wallyworld: if you set up an SSH key with github, you then push to the magic "git@github.com:wallyworld/core" and it will detect who you are from your SSH key fingerprint
<jam> note that "user@host:/path" is git's way of declaring an SSH path
<jam> vs bzr's bzr+ssh://...
<wallyworld> jam: ah, i've been pushing to just github.com/... i think
<wallyworld> i'm also hoping to just git push and it knows where to push to like bzr does with lp
<wallyworld> i don't like typing the full remote location each time
<axw> wallyworld: you create "remotes" for that
<axw> essentially aliases for a repo location
<wallyworld> rightio, that's the github 101 stuff i haven't read yet
<jam> wallyworld: https://help.github.com/articles/error-permission-denied-publickey is how to set up your ssh key stuff, and the default from github is to use "https://" which require username & password, but if you look at the "clone from here" there is a link for getting the SSH address.
<wallyworld> great, thanks
<wallyworld> some weekend reading
<jam> by default I believe "git clone $SOMETHING" will set that something as an origin so "git push" will push back to it
<jam> wallyworld: I think working out this stuff/documenting it is all part of actually getting the team moved over
<wallyworld> yes indeed
 * wallyworld -> dinner
<jam> http://www.seamicro.com/node/313 "Up to 64 8-core processors with 64GB dram each" and up to 4TB of RAM for the 10U box.
<jam> that's a big box
<TheMue> jam: nice, indeed. but also a nice power consumption. may also use it as heating system. :)
<jam> TheMue: apparently it is about 2x as efficient as regular boxes of that size (6 racks of 40kW for normal machines gets replaced with 2 racks of 20kW)
<jam> so it is definitely power-dense
<jam> but maybe slightly more efficient per kW than othres.
<jam> at least, the numbers they give put it as 1.5x more kW/rack space, but 3x the compute power
<TheMue> jam: yeah, itâs fantastic. espcially when thinking back to the good old Sun E10K times.
<TheMue> jam: we once ran three of those boxes, at that time absolutely top (around 2000).
<jam> TheMue:  http://en.wikipedia.org/wiki/Sun_Enterprise#Enterprise_10000 quite a machine in 2000
<TheMue> jam: absolutely. our computer room has been under the roof of our building and they had to deliver it with a large crane. :D
 * TheMue thinks about quad-core mobiles or notebooks (with 8 hyperthreads and 16 gb ram) today compared to the good old Z80 he started with
 * axw punches peergrouper tests in the face
<voidspace> morning all
<jam> morning voidspace
<perrito666> morning
<voidspace> perrito666: morning
<wwitzel3> morning
<voidspace> wwitzel3: morning
<voidspace> wwitzel3: did you pull out your tests yesterday, or just not push them?
<wwitzel3> voidspace: never pushed them, never got them working
<voidspace> wwitzel3: the changes look pretty complete in terms of replacing the EnvironConfig watcher with the Rsyslog watcher
<voidspace> wwitzel3: :-/
<wwitzel3> voidspace: I will push them now
<voidspace> wwitzel3: cool
<voidspace> wwitzel3: want to pair again? Shall I drive this time?
<wwitzel3> voidspace: yep, that seemed to work well yesterday
<voidspace> wwitzel3: yeah, when we finally got a screen resolution I could see :-)
<voidspace> wwitzel3: it meant that for the first hour or two you were doing all the work and describing it to me as we went
<voidspace> sorry about that
<voidspace> wwitzel3: my branch landed by the way
<wwitzel3> voidspace: ahh, good
<voidspace> yep
<voidspace> right, so coffee update then hangout
<wwitzel3> voidspace: sounds good, doing the same
<vladk> jam: hangout?
<voidspace> wwitzel3: nearly 2pm here, so I'm going on lunch
<voidspace> see you back soon :-)
<wwitzel3> voidspace: ok, sounds good
<bodie_> fwereade / mgz -- working through some of this Action stuff in my head.  I think I got a much better picture of what we need to do! :)
<fwereade> bodie_, cool, we can have another chat about it later if you think that'd be useful?
<bodie_> fwereade, absolutely.  I was looking at the gojsonschema stuff.  should we be assuming that the args for an Action will be defined as a json-schema file?
<bodie_> instead of the "actions.yaml" I was basing my thoughts on -- because if so, our work is literally cut out for us
<bodie_> or does the schema define what a legit actions.json might look like?
<bodie_> i.e. action, description, args, types
<fwereade> bodie_, so ISTM that we unmarshal the contents of actions.yaml, and call NewJsonSchemaDocument with the params definition for each action; and then we call Validate on that doc, passing in the unmarshalled params we got from the user
<fwereade> bodie_, I perceived you as talking about json *files* which I think is a slight derail
<bodie_> won't the UI be generating json-schema?
<rick_h_> the UI will be using the json schema document you send us over the api
<bodie_> that is, the charm definition GUI
<rick_h_> and we'll construct a UI, do client side validation, but juju must do the same
<rick_h_> to jump in as I follow along :)
<fwereade> bodie_, it will be using a json-schema document to generate the ui, and we will be using that same json-schema document to validate what they send to us, yeah
<bodie_> I see, but the charm will define the action spec using yaml?
<rick_h_> the GUI might wish to ask you what actions are available, what is the schema doc for a specific charm/action.
<fwereade> bodie_, but the representation in the charm of that json-schema document will just be a bunch of maps/lists/values under a particular key in the yaml
<bodie_> I thought there was some JSON-schema builder which was desired to be used to actually put the charm's actions spec together
<fwereade> bodie_, we unmarshal that stuff and then pass the resulting interface{} into the gojsonschema funcs
<bodie_> sorry, fwereade / rick_h_, talking about charm manufacture, not UX
<fwereade> bodie_, that hadn't really crossed my mind -- a simple json-schema can be pretty simple, though, according to my reading of it
<fwereade> bodie_, certainly no worse than a charm config schema
<bodie_> right, it's very human-readable
<fwereade> bodie_, but with more scope for complexity if it's warranted
<rick_h_> yea, didn't realize there was talk of a charm building UI/tool. I think that's something of a follow up though to  actually having actions work
<fwereade> rick_h_, +1 to that
<bodie_> :)
<bodie_> well, hopefully that will be coming soon now that I have the conceptual framework in place much more clearly
<fwereade> bodie_, +1 also to that :)
<rick_h_> sorry, didn't mean that to come across as snarky, just mean a UI tool to help you build a charm shouldn't influence how to write a charm without.
<rick_h_> imo
<bodie_> right, the question was more whether json-schema is going to replace YAML
<bodie_> since that would obviously make validation / parsing really simple
<bodie_> perhaps I'm not listening lol, rereading
<rick_h_> since yaml is a superset of json, my understanding is that we'll update charm proof to validate actions yaml files to be valid json files.
<rick_h_> charms will write yaml
<rick_h_> and what they are internally once pulled into juju doesn't matter (so using json would be ok?)
<rick_h_> especially since the GUI will be requesting json anyway
<rick_h_> but asking charm devs to do part XX in json and part YY in yaml isn't a great experience for them
<bodie_> Gotcha, so really the ideal interface takes either-or
<fwereade> rick_h_, yeah, exactly -- although really the only parts that *have* to be valid json are the subsections of those files that will actually be piped into gojsonschema
<fwereade> rick_h_, ie the params definitions
<rick_h_> fwereade: true, I was under the actions.yaml perspective so not pondered the nested structure idea yet
<fwereade> rick_h_, (I would be surprised if actions.yaml *actually* ended up containing anything that wasn't *representable* as json though)
<rick_h_> fwereade: but definitely, we can scope the issue down easily enough.
<fwereade> rick_h_, I wouldn't expect the gui to have to care about that fwiw
<bodie_> :) well I think my work is cut out for me
<rick_h_> fwereade: right, just that yaml allows some form of variables and such if I recall, which wouldn't dump to pure json correctly
<fwereade> rick_h_, ask us about the charm over the api, we'll tell you the schemas for the actions
<fwereade> rick_h_, yeah
<fwereade> rick_h_, I'm not taking it off the table, just saying I'd be surprised
<rick_h_> fwereade: right, that's cool. Easy to work with.
<fwereade> rick_h_, cool
<bodie_> rick_h_, what you said about the json-schema sent over the API
<rick_h_> delivery truck, have to run for a few
<bodie_> let me know when you're back :)
<bodie_> never mind, seems simple enough.  just need to add a "get-schema" api endpoint
<bodie_> fwereade, the question in my mind is still whether to simply store the params and spec as json or as an interface map
<fwereade> bodie_, let me turn that round: what's the benefit of storing as json?
<bodie_> heh :)
<bodie_> makes it a simple gojsonschema call internally
<bodie_> whereas storing as k/v makes it easy to send args to the charm
<bodie_> is that something like what you're thinking
<bodie_> ?*
<fwereade> bodie_, ISTM that the gojsonschema funcs actually work with interface{}, and supply convenience functions to turn json text into them
<bodie_> ah
<bodie_> didn't realize that
<fwereade> bodie_, maybe I'm looking at the wrong gojsonschema, it's not immediately apparent which of xeipuuv's and tolsen's is better, if there's any difference at all
<bodie_> fwereade, it appears xeipuuv's is much more maintained -- tolsen's is a fork of it from 8 months ago
<bodie_> hm, it was actually merged into xeipuuv's a couple of months ago
<bodie_> maybe I'm looking at the wrong numbers here
<bodie_> https://github.com/tolsen/gojsonschema/network
<bodie_> so, probably xeipuuv's is our best bet :)
<rick_h_> sorry back
<fwereade> bodie_, I think we'd likely want to vendor it anyway, I presume the license is tolerable
<fwereade> bodie_, but maybe we just stick with godeps
<bodie_> hi rick_h_, no worries.  Just wanted to reflect what you said about a get-schema API endpoint to make sure I'm on the same page :)
<bodie_> fwereade, it doesn't appear to be licensed at all.  under Github's TOS, I believe that means if you fork it, it's yours :P under the most liberal interpretation, afaik
<fwereade> bodie_, ha, fun :/
<rick_h_> bodie_: I think we should file an issue to get a license in place and suggest we're willing to add one in a pull request that's of a version we'd like to see :)
<bodie_> perfect
<fwereade> rick_h_, sgtm; bodie_, would you handle that please?
<rick_h_> explicit ftw, shoot, maybe even start with a pull request that's bsd or MIT and see if it gets the discussion going
<bodie_> https://github.com/xeipuuv/gojsonschema/issues/16 -- is this good?
<bodie_> it's an active repo and there are about 2 issues open
<bodie_> didn't see your suggestion of opening the MR myself
<bodie_> but, that of course would've been a good idea ;) and I can still go ahead and do that if you'd like
<rick_h_> bodie_: oh, you'd have to fork it and then do a pull request against it?
<bodie_> correct
<rick_h_> oic, yea. That's cool, just might use pull request vs MR as MR is launchpad centric terminology
<rick_h_> but nitpicking language there
<bodie_> he he.  just caught that myself
<bodie_> I wasn't sure if I ought to mention what project it's for
<rick_h_> bodie_: if it comes up it comes up.
<wwitzel3> voidspace: standup
<jcw4> fwereade: (bodie_) I re-submitted the MR after addressing the issues in the review
<jcw4> fwereade: I didn't start working on the Unit cleanup though... I figured that could be the next MR?
<bodie_> jcw4, perfect :) I just broke several MR's out of that monolithic one from earlier
<jcw4> bodie_: nice
<bodie_> so, each of those should be pretty clean and easy to get in, we might even want to consolidate a couple of them
<fwereade> jcw4, dammit, sorry, I started looking this morning and something distracted me
<jcw4> fwereade: no worries...  I know you have a lot of demands :)  I appreciate whatever you're able to help us with
<fwereade> jcw4, I'd rather like it if you did fix up the cleanup, I don't *think* it'd grow the CL too far, but feel free to start working on it in another branch -- you can always merge them into one to land
<jcw4> fwereade: Yeah. I'll start that this morning
<fwereade> jcw4, (or ofc demonstrate that I'm crazy, and it does/would grow it too far ;))
<jcw4> fwereade: hehe will do
<bodie_> fwereade, were you saying an Actions spec ought to be an interface{} or a map[string] interface{} ?
<voidspace> fwereade: ping
<voidspace> fwereade: we're implementing WatchForRsyslogChanges
<jam1> void
<jam1> voidspace: i'm around if fwereade isn't
<voidspace> cool
<voidspace> jam1:  fwereade: what we *really* want is a "MultiEntityWatcher"
<voidspace> that will watch two mongo collections and notify the client when *either* of them change
<jam1> fwereade: le sighâ¦ I can't find AllWatcher in a test suite to validate my changes...
<voidspace> is that a) something that already exists  or b) a feasible approach we just need to do it or c) a dumb idea
<jam1> voidspace: I don't know that we've written the code, but AIUI NotifyWatchers can be trivially collapsed
<voidspace> NotifyWatcher is client side, right?
<jam1> voidspace: it is both sides
<voidspace> We'd rather collapse the EntityWatcher on the server
<voidspace> ah, ok
<voidspace> we'll have a go at it then
<jam1> voidspace: MuxNotifyWatcher ?
<voidspace> we just didn't want to burn time on it if it was an approach that was never going to work and we should just use two of them
<sinzui> Hi Devs. If you look at juju-ci, don't panic. HP is very ill. IS knows about it and are in contact with HP.
<jam1> voidspace: well IIRC the discussion from fwereade was that we really should treat the items in environconfig as immutable, in which case you don't need to watch them anymore.
<voidspace> jam1: ah, so *just* watch APIHostPorts
<jam1> sinzui: thanks for the heads up, IIRC azure was having some troubles
<voidspace> jam1: that's certainly easier...
<jam1> sinzui: was that just temporary?
<sinzui> jam1, azure often resolves itself over 4 hours
<jam1> voidspace: right I'm hesitant to just change the code that we've already had working
<jam1> but fwereade seemed pretty confident that we can't just change things like ports and ca certs
<jam1> voidspace: so as long as we have some sort of implementation of a WatchForRsyslogStuff
<jam1> then we can make it trigger with whatever logic we converge on
<sinzui> jam1 This HP outage is cause by bad archives or networks. Apt is crippled. This happen in March when I did the 1.17.4 release I think
<voidspace> jam1: we have that done. It's currently just doing WatchForEnvironConfigChanges under the covers
<jam1> voidspace: certainly you can *start* with just APIHostPorts
<jam1> sinzui: did we ever get trusty in HP ?
<voidspace> jam1: we can switch it to APIHostPorts and check that everything still works *plus* the parts that weren't working before
<voidspace> and if everything works then great
<sinzui> jam1 it is listed :)
<voidspace> awesome
<jam1> k, I thought for a while it wasn't available, but yeah, ISTR HP having archive routing issues in the past
 * jam1 is sad, I can delete the AllWatcher which GUI critically depends on and nothing in juju-core would notice (at least that I can find)
<natefinch> jam1: well, the GUI is an important part of Juju, obviously.  Is there a way we could support them differently without the AllWatcher?
<voidspace> pubhubsubpubhub!
<jam1> natefinch: well I can just migrate the code over there, it isn't like I'm getting rid of it.
<jam1> the *bug* is that we don't actually test that we don't break them all the time
<jam1> If I mess up the permissions, or accidentally don't expose the API, nothing notices
<jam1> we have some client code
<jam1> but it isn't exercised (AFAICT
<jam1> rick_h_: do you do regular testing with dev-releases or trunk ?
<rick_h_> jam1: no, it's something we brought up with sinzui about getting into the CI/QA steps
<jam1> wallyworld_: if you want to write some extra tests bug #1319441
<_mup_> Bug #1319441: AllWatcher API is untested in juju-core <tech-debt> <testing> <juju-core:Triaged> <https://launchpad.net/bugs/1319441>
<jam1> rick_h_: k. this is mostly about "I should be able to refactor code and know that everything works"
<rick_h_> jam1: agreed, it's a hole we hit with quickstart leading to 14.04 and we brought up in vegas to address
<jam1> but AllWatcher just "exists" as an API. It looks like the underlying "megawatcher" code is reasonably tested, just not that we can actually get anything from it via the api
<jam1> rick_h_: is it possible to drive the GUI from a script?
<jam1> rick_h_: I guess you have quite a bit of JS tests written
<rick_h_> jam1: we do have a few functional tests using selenium we run to drive the gui in a couple of ways
<sinzui> jam1. rick_h_ and I agreed that QA needs to test the next juju against quickstart and gui. Run their tests suites that exercise juju too
<sinzui> perrito666, regarding the ha restore test. Do I expect to see just a master (users need to rerun ensure-ha) after the restore completes?
<perrito666> sinzui: yes
<sinzui> thank you.
<perrito666> sinzui: btw, I found that in "restore_present_state" server you are masking possible juju-restore runtime errors
<sinzui> oh, how do I fix that?
<perrito666> well, you try to match the instance name to destroy the instance, if there is no match you raise a generic exception with a string, you might want to append the output from err in that string
<sinzui> thank you perrito666
<perrito666> sinzui: np
<voidspace> when is TestStartStop called in a suite (how does it differ from SetUp)?
<jam1> voidspace: it is just a test
<voidspace> ah...
<voidspace> that explains why changing it isn't affecting the other tests :-)
<voidspace> jam1: d'oh, thanks
<jam1> voidspace: Ithink anything starting with Test* is just atest, the SetUpSuite et al start differently
<voidspace> yep, shoulda twigged
<wwitzel3> :q
<wwitzel3> irssi is the worst vim ever
<jcw4> :)
<jcw4> :w
<jcw4> :w!
<jcw4> :qa!
<perrito666> wwitzel3: you should have seen my week trying to switch to emacs, I have never corrupted so many files with ESC^i and :w in my life
<_benoit_> Outscale has a S3 endpoint in fact! so juju should work easily \Â°/
<fwereade> _benoit_, sweet!
<jcw4> fwereade: about cleaning up the unit.... 1) I assume the cleanup should go in func (u *Unit) Remove()
<jcw4> fwereade: and 2) the same predicate used by the watcher to find Actions specific to the unit can be used to find and remove the Actions queued for the unit being Removed
<fwereade> jcw4, look in cleanup.go, I think
<jcw4> ok
<jcw4> fwereade: thx
<fwereade> jcw4, I think you need to look at service.removeUnitOps to find the stuff that'd definitely run when a unit is actually removed
<fwereade> jcw4, do we have an opinion about running actions on units after someone's destroyed them, though?
<jcw4> fwereade: good question
<jcw4> fwereade: I'll review the draft doc to see if it's mentioned
<fwereade> jcw4, because we might be in a position to actually mark them all failed at that point, I'm right now writing a cleanup op that's queued when someone calls Destroy on a unit
<fwereade> jcw4, pretty sure it's not
<fwereade> jcw4, btw, I'm afraid I need to be off pretty sharpish now, otherwise I'd pop in and talk to you
<fwereade> jcw4, if I'm around later I will try to get you a fresh review
<jcw4> fwereade: tx!
<jam2> reasonably trivial code review: https://codereview.appspot.com/98250044
<_benoit_> fwereade: http://paste.debian.net/99505/ how can I bypass this lord of the ring check ?
<voidspace> natefinch: ping
<voidspace> natefinch: worker/rsyslog/rsyslog_test.go TestNamespace - do you know anything about this test?
<voidspace> natefinch: being our resident rsyslog expert
<perrito666> is anyone having problems with amazon taking forever to initialize machines?
<voidspace> jam1: sooo... we have some of our tests that call the following and expect rsyslog to be restarted
<voidspace> s.APIState.Client().EnvironmentSet(map[string]interface{}{"rsyslog-ca-cert": coretesting.CACert})
<voidspace> jam1: I can put a workaround in the tests, but is it possible that the rsyslog cert will be set *after* APIHostPorts have changed?
<voidspace> jam1: in our manual testing everything appears to work for all the relevant scenarios
<voidspace> non-HA, HA, deploy unit *then* ensure-availability
<jam1> voidspace: so the argument from fwereade was that rsyslog-ca-cert could be treated as immutable, and if we can consider it thusly, then the above test is invalid
<jam1> voidspace: rsyslog-ca-cert has to be set up on machine-0 before anything happens
<voidspace> jam1: immutable except for *initial setting*, but would that *not* be done through the api
<voidspace> right
<voidspace> so in which case I will modify the test
<jam1> the only bit you have to worry about is if something comes up right away before bootstrap actually sets up the cert
<voidspace> that's my specific question
<voidspace> do I have to worry about that
<jam1> voidspace: so I'd rather get fwereade to confirm, but that is my understanding from our conversation
<jam1> it should be considered immutable-once-set
<jam1> though it would be best if we actually enforced that.
<voidspace> right
<jam1> I'm not entirely sure why it is in environconfig
<voidspace> heh
<jam1> (which lets user's touch it) other than we may not have a grab-bag for stuff we want to create and keep track of
<voidspace> it was probably just somewhere convenient
<voidspace> it certainly seems like *in practise* the cert is already set when we write out the initial rsyslog conf
<voidspace> but I'd like to be certain that *must* be the case, otherwise we'll have intermittent problems
<voidspace> and if we can't be certain then we need to watch environconfig changes at least until the cert is set
<voidspace> which is extra code
<natefinch> voidspace: just got back
<voidspace> natefinch: hey, hi
<voidspace> natefinch: see the above conversation with jam1 from where I pinged you
<voidspace> natefinch: we're now only triggering rsyslog conf to be rewritten, and rsyslog to be restarted, when the set of APIHostPorts changes
<voidspace> natefinch: because we consider the rsyslog stuff in environconfig (cert and port) to be immutable
<natefinch> voidspace: sounds good
<voidspace> natefinch: the only danger is that this information is "somehow" set *after* the config has been written the first time
<voidspace> I'd like to assume that's impossible - and it certainly seems to work in practise
<jam1> voidspace: so my personal view is I'd rather have the ability to change it and not use it than not allow it at all (especilaly if we don't enforce that it is immutable). However, since it is easier to implement and fwereade liked it being immutable we can go with it
<voidspace> jam1: it's easy to change
<voidspace> jam1: on the other hand EnvironConfig changes for a lot of irrelevant things, so the new way restarts rsyslog a lot less
<natefinch> jam1, voidspace: my preference is for whatever makes the code simpler.  It sounds like assuming it's immutable will make the code simpler
<natefinch> I don't want us to write and maintain code that only .001% of people will actually use
<natefinch> hell, I don't want to write and maintain code that only 1% of people will actually use :)
<voidspace> at some point 1% becomes a lot of people
<natefinch> Don't care, that means 99% is always way way more people
<natefinch> more complexity and more features will just slow us down for the features the 99% want
<fwereade> jam1, I'm not even necessarily *against* having it mutable, but if we do we should be careful to make it sane; and we haven't, and nor have we scheduled mutability, so we should just save ourselves hassle by making it immutable
<fwereade> jam1, and it's easy, and simple, and maybe one day there will be a compelling case for changing it, and that will be fine too
 * fwereade is done for the day (or at least for now) anyway
<jam1> fwereade: night, have a good evening
<voidspace> fwereade: night
<voidspace> hmmm... my actual error now is a permissions error
<voidspace> natefinch: should all api endpoints do a permissions check?
<voidspace> natefinch: our initial implementation of WatchRsyslogChanges included this check
<voidspace> if api.authorizer.AuthOwner(agent.Tag)
<voidspace> which caused a test to fail elsewhere
<voidspace> I wonder if it's needed
<voidspace> brb
<natefinch> voidspace: it seems like watching shouldn't need permissions, since you're not changing anything, but I'm actually not sure what the policy is.
<voidspace> natefinch: it looks to me like the WatchAPIHostPorts itself doesn't have this check
<natefinch> voidspace: that sounds like a good enough precedent to me
<voidspace> natefinch: and as this is *essentially* what WatchRsyslogChanges is doing it shouldn't need extra permissions I don't think
<voidspace> heh, cool
<voidspace> we probably just copied the permissions check from somewhere else anyway...
<jam1> voidspace: natefinch: all API methods do permission checking
<jam1> voidspace: especially when it was exposing the raw EnvironmentConfig before, but even now, it is only for use by Agents
<jam1> probably you just had a wrong Authorizer set up
<jam1> natefinch: voidspace: WatchAPIHostPorts is special, because *everyone* needs to watch that
<jam1> but Clients shouldn't have WatchRsyslogChanges exposed to them.
<voidspace> ah, dammit
<voidspace> at least I've confirmed the error even if my fix is wrong :-)
<voidspace> although it seems like this new check must be more draconian than the previous one
<natefinch> jam1: thanks for the clarification.  I guess I sort of assume that read-only stuff doesn't really need authentication because.... who cares?  But good to know the policy anyway.
<jam1> natefinch: well readonly of your Environment credentials would be a bad thing, right?
<natefinch> jam1: yes, true
<jam1> natefinch: so while I could see "does security really matter on *this* function", it is more of a "lets not think about it, and just restrict everything"
<natefinch> jam1: fair enough
<jam1> because I can agree, why would leaking rsyslog needs changing be a security hole
<natefinch> jam1: but then again, you never can tell where you might leak information in an indirect way that gives an attacker just enough advantage
<voidspace> jam1: so the correct permissions check is
<voidspace> authorizer.AuthMachineAgent() ?
<jam1> voidspace: the UnitAgent doesn't run rsyslog, right?
<jam1> then AuthMachineAgent
 * perrito666 wishes lbox didn 't h a n g  t h e  w h o lemachinewhilerunning
<natefinch> perrito666: get a better machine ;)    lbox does do a lot of stuff, and Linux (Unity?  not sure the culprit) does have the unfortunate bug where if you're hammering the CPU, it tends to freeze up everything.
<voidspace> so, the test now passes...
<voidspace> with that change in place
<voidspace> time to run all the tests and go jogging
<perrito666> natefinch: perhaps a less mobile processor, but it is hard to go back from an extremely lightweight machine
<mramm> hey all!
<perrito666> hey mramm
<mramm> ODS demo yesterday was #*(%ing amazing
<mramm> great work everybody
<natefinch> mramm: yeah it was.  I watched it this morning.  Damn awesome.
<mramm> natefinch: how hard would it be for you to do a sprint for a few days in a couple of weeks?   (I know it is both short notice, and close to the last juju sprint temporaly speaking)
<mramm> natefinch: and am I remembering right that you/your squad have Windows and CentOS on your work list for this cycle?
<natefinch> mramm: yeah, we have non-ubuntu workloads
<natefinch> mramm: as for a sprint, if it's within commuting distance (like at the Lexington, MA office), then it's cool.  Going elsewhere and my wife might kill me.
<mramm> well, let me talk to the cloudbase guys
<mramm> and see if I can get them to come back to the US
<mramm> It's too late (I think) to keep them here after ODS
<mramm> who has the resources work on their schedule?
<lazyPower> hey, did we add a fsmount type of rpc_bindfs wrt bind mounting local filesystems on local provider?
<natefinch> mramm: Onyx (Tim) has resources, looks like
<rick_h_> mramm: I think that's thumpers team
<sinzui> The HP archive issue is resolved. Juju is confirmed to be fine
<sinzui> http://juju-ci.vapour.ws:8080/
<sinzui> ^ if we fixes the i386 and ppc unittests, every test would have passed
<natefinch> sinzui: nice!
<voidspace> wwitzel3: I fixed the auth issues
<voidspace> wwitzel3: but there's a bunch of failing tests in state/api/rsyslog/rsyslog_test.go
<voidspace> no state/apiserver/rsyslog/rsyslog_test.go
<voidspace> wwitzel3: they look like the same failure we've fixed before ("No state server machines found")
<voidspace> wwitzel3: but I have to EOD
<voidspace> wwitzel3: all my changes are pushedc
<voidspace> *pushed
<voidspace> wwitzel3: so have fun :-)
<voidspace> g'night everyone
<voidspace> EOD
<natefinch> night voidspace
<perrito666> nite vds
<perrito666> agh
<perrito666> nick autocomplete should work after they left :)
<natefinch> heh
<lazyPower> natefinch:  did we add a fsmount type of rpc_bindfs wrt bind mounting local filesystems on local provider?
<lazyPower> i ran into a corner case with apparmor not having the correct profile defition that blocked me from spinning up lxc containers this morning - working with ty helped me get it sorted.
<lazyPower> *Definition
<natefinch> lazyPower: interesting... we haven't twiddled with the local provider code very much recently.  I don't believe we've changed anything about the filesystem, or anything like that... though I know there's been some lxc/apparmor problems in the past
<lazyPower> natefinch: http://paste.ubuntu.com/7463805/
<lazyPower> this is what i found - and it only happens when deploying local charms. if i specify CS charms i don't see the behavior.
<lazyPower> if we made some alterations to lxc without getting the app armor, i was requested to forward on teh bug so they can SRU the app armor fixes. just let me know either way and i'll put in the due dilligence.
<natefinch> lazyPower: hmm... I really doubt we mucked with lxc lately.... can you try just spinning up a container manually and make sure it works without juju?
<lazyPower> natefinch: i only encountered the issue when using juju to deploy a local charm. otherwise it had no issues.
<lazyPower> i've created lxc containers while debugging, that didn't exhibit the issue
<natefinch> lazyPower: weird.  Ok. There must be something we're doing with the local charms that is making app armor mad.... if you can make a bug for it, that would be great.  Obviously it's something we'll need to fix ASAP
<lazyPower> ack. I'll add what i've got - which isn't much. but i can comment out the app armor patch and reproduce.
<lazyPower> natefinch: https://bugs.launchpad.net/juju-core/+bug/1319525
<_mup_> Bug #1319525: juju-local LXC containers hang due to App Armor Denial of rpc_fsbind request with local charms <local-provider> <lxc> <juju-core:New> <https://launchpad.net/bugs/1319525>
<natefinch> lazyPower: awesome, thanks
<lazyPower> Thanks for taking a look. I hope its just a corner case that I've found - and not something thats out there in the wild.
<perrito666> if anyone has literally 2 seconds https://codereview.appspot.com/97370044
<natefinch> neat, I may finally get to use the windows named pipe package that I wrote for Gustavo during(ish) my interview
<menn0> morning all
<waigani> morning all :)
<menn0> waigani: howdy
<perrito666> menn0: iirc, agent.conf from the old machine is put in place and services restarted in these ports
<perrito666> menn0: the old agent.conf is ignored
<menn0> perrito666: ok, so the agent.conf that awk is manipulating isn't the one from the backup?
 * menn0 pulls branch to have a closer look
<perrito666> menn0: is the one from the backup
<perrito666> what it currently does is it untars the backup over the fresh mashine
<perrito666> machine*
<perrito666> and then makes some surgery there
<perrito666> :p
<menn0> yep I get that
<menn0> but if somehow the ports in the .jenv on the host that's running "juju restore" don't match what's in the backup then the user will never be able to connect to the env after it's bootstrapped
<menn0> I know this should really never happen
<menn0> sorry, I meant after it's restored, not after it's bootstrapped
<perrito666> mmm, you mean if the port change between the backup and the new machine?
<menn0> I'm thinking: backup is taken, someone monkeys with the ports, then restore is done
<menn0> shouldn't happen I know
<perrito666> menn0: mm,true, that is a story I am really not so happy to support for the moment
<menn0> fair enough.
<menn0> you have your LGTM anyway :)
<perrito666> but, really not that far from where I am
<perrito666> so I think I can give a shot at your idea until shinzui finishes the test :)
<menn0> just refusing to restore with an error should be enough I would have thought
<menn0> especially given that we currently don't support changing the API or state server ports once an env is bootstrapped
<menn0> if the ports don't match between the .jenv and the backup then someone has done something they shouldn't have (or we have a bug)
<sinzui> thumper, is this bug in juju-core, or does it belong  ubuntu/trusty/+source/lxc https://bugs.launchpad.net/bugs/1319525
<_mup_> Bug #1319525: juju-local LXC containers hang due to App Armor Denial of rpc_fsbind request with local charms <local-provider> <lxc> <juju-core:New> <https://launchpad.net/bugs/1319525>
 * thumper looks
<thumper> sinzui: I'm unclear, but most likely lxc
<thumper> sinzui: I asked lazyPower in the bug if he knows what caused the problems with the wordpress charm
<lazyPower> thumper: its any local charm. if i pull seafile and deploy it locally
<lazyPower> it has the same denial message
<lazyPower> i ran into this working the rev queue
<thumper> ah...
<thumper> I don't know the local charm area very well at all
<thumper> I don't think it should trigger anything with lxc
<thumper> sinzui: it could be either juju or lxc...
<sinzui> Is this issue different from https://bugs.launchpad.net/juju-core/+bug/1305280
<_mup_> Bug #1305280: apparmor get_cgroup fails when creating lxc with juju local provider <apparmor> <armhf> <local-provider> <lxc> <packaging> <regression> <juju-core:Invalid> <apparmor (Ubuntu):Confirmed> <https://launchpad.net/bugs/1305280>
<lazyPower> it appears to be some kidn of fs mounting voodoo, because the error it threw was rpc_bindfs
<lazyPower> which i immediatly thought about that feature we talked about in vegas about bind mounting the local fs, but i didn't know if we did anything with that as of yet.
<thumper> sinzui: the second bug there appears to be nested lxc failing
<thumper> which is expected
<thumper> lazyPower: we don't yet
<sinzui> thumper, what make you think the cgoup bug is lxc in lxc?
<thumper> because that is the failure you get if you try?
 * thumper looks at the bug
<thumper> sinzui: ok, could just be apparmour on arm
<thumper> don't think it is us
<sinzui> thumper, I am sure it isn't us. I just could get someone other than us to look at the issue
<thumper> rick_h_: you there?
 * thumper calculates time zones
<rick_h_> thumper: kinda
<thumper> dinner time?
<rick_h_> thumper: 6:30pm
<thumper> rick_h_: got time for 10 min chat?
<rick_h_> yea, dinner is in the oven, what's up?
<rick_h_> sure thing
<thumper> cheers
<thumper> rick_h_: https://plus.google.com/hangouts/_/gsuud6kuvi6fowv6i3dfnpwsbqa?hl=en
<rick_h_> lol
<rick_h_> thumper: all good, let me know if you want to chat more, I want to make sure we get it right
<thumper> rick_h_: I'll start documenting what we need and keep you in sync
<thumper> we are done for today
<rick_h_> thumper: k, thanks for the chat
<rick_h_> thumper: how dare you make me think about stuff :P
<thumper> rick_h_: np... more coming
#juju-dev 2014-05-15
<bigjools> $ juju status
<bigjools> ERROR state/api: websocket.Dial wss://10.55.60.209:17070/: EOF
<bigjools> what does that mean?
<bigjools> everything is up AFAICS
<bigjools> well, here we go:
<bigjools> -rw-r----- 1 syslog adm    25G May 13 06:38 all-machines.log
<bigjools> -rw-r--r-- 1 root   root   23G May 15 00:28 machine-0.log
<bigjools> Filed https://bugs.launchpad.net/juju-core/+bug/1319608
<_mup_> Bug #1319608: Poor error message when "status" fails <juju-core:New> <https://launchpad.net/bugs/1319608>
<bigjools> and https://bugs.launchpad.net/juju-core/+bug/1319607
<_mup_> Bug #1319607: Logs are not rotated <juju-core:New> <https://launchpad.net/bugs/1319607>
<menn0> well I just learned something. If you put "NOT LGTM" in a review, Rietveld counts that as disapproval.
<davecheney> yup
<bigjools> axw: the dupe detector never works in LP does it? :)
<bigjools> you'd think my keywords would have matched that one you duped it to
<axw> bigjools: took me a few searches too
<axw> bigjools: only "logrotate" came up with it
<bigjools> urgh
<bigjools> I must admit I was surprised when I didn't see a dupe
<bigjools> hey while I am here, what's the approved way to upgrade a bootstrap node? I have one on precise that I want on trusty.
<bigjools> just a regular dist upgrade?
<axw> I'm not sure that we have an approved method... I actually don't know what happens if you change series underneath juju
<axw> wallyworld_: I'm ready whenever you want to have a standup
<wallyworld_> sure
<bigjools> axw: it's an interesting question in the context of a distro going out of support
<axw> bigjools: agreed, I just don't know the answer ;)
<thumper> axw, wallyworld_: small review? https://codereview.appspot.com/93410043/
<wallyworld_> ok
<axw> funny man
<wallyworld_> wtf
<wallyworld_> small
<axw> thumper: reviewed
<thumper> thanks
<thumper> I was trying to be funny 8-)
<axw> wallyworld_: I think lxc-use-clone made it into 1.18.3 didn't it?
<thumper> but didn't notice the responses until my client pinged me
<axw> wallyworld_: so I think we should technically handle upgrade/deprecation warning
<axw> but I wonder if it's really worthwhile, given how long it's been out
<wallyworld_> axw: ah, yeah. for some reason i had convinced myself it hadn't
<wallyworld_> sadly if it's in 1.18.3 i think we need to
<thumper> axw: I was trying to keep the diff small
<thumper> you might not think that...
<thumper> but I did
<axw> :)
<thumper> I'll review the use of coreerrors
<axw> it was mostly trivial anyway
<axw> wallyworld_: sorry about that
<wallyworld_> no need to say sorry
<axw> wallyworld_: wish I had remembered there was an existing config earlier
<thumper> axw: only 33 matches in 14 files
<wallyworld_> i should have picked it up in review
<wallyworld_> but we were rushed to try and get something to them
<axw> sinzui: are you awake?
<axw> sinzui: actually never mind... question is for someone else
<axw> wallyworld_: do you know if the bot uses juju-mongodb?
<axw> or just mongodb-server
<wallyworld_> axw: not sure but i can check, just otp at the moment
<axw> sure
<sinzui> aws It was using mongodb-server
<sinzui> jam1 forced it to install
<sinzui> axw, ^ sorry It is a bit late
<axw> sinzui: thanks
<sinzui> axw, and CI installs both mongos for the trusty test as of last week
<axw> ok cool
<waigani> axw: reading through the code. does azure call a vm a "role"?
<axw> waigani: yes that is right
<axw> waigani: there is a doc on azure in dthe docs directory
<waigani> okay, I should probably read that
<waigani> axw: and the api lib is called gwacl. Both very misleading
<axw> waigani: roles can be things other than VMs, but for our purposes they are the same
<waigani> axw: just within azure right?
<axw> yes, azure roles
<waigani> axw: we might be introducing authorisation roles for users
<axw> ah, yeah, totally different type of role :)
<waigani> yeah!
<thumper> gah... dumb gobot
 * thumper tries to remember how to get there
<wallyworld_> thumper: 10.55.61.118
<thumper> wallyworld_: I have an alias called "gobot"
<thumper> wallyworld_: that does the ssh for me so I don't have to think
<thumper> \o/ r2731
 * thumper does a little dance
 * thumper loses energy and goes back to writing planning documents
<thumper> davecheney, waigani, menn0: iteration one email sent out, I'm still working on the work item breakdown
<waigani> thumper, davecheney, menn0: first pass over codebase's current use of identity: https://docs.google.com/a/canonical.com/document/d/1t8i0uHuHM3zgPC8QF0_v_K3SB6syXM32IxTZGIJd_f0/edit#
<davecheney> thumper: ta
<axw> wallyworld_: heading out shortly, will review your test suite branch when I get back
<wallyworld_> ok, ta
<wallyworld_> finally got it all to work
<menn0> can anyone help me with a bzr newbie question?
<jam> fwereade: when you're around, I would like to run something by you quickly
<axw> jam: is gobot running in lcy01 or lcy02? and do you know the constraints of the machine?
<axw> jam: I can't reproduce the peergrouper error locally, but it's happening pretty frequently on the bot now...
<jam> axw: I believe we've bounced back and forth, but right now we're on lcy01with a dual-core 4GB machine
<jam> axw: it is also running precise, if that matters
<axw> jam: cool, thanks
<TheMue> morning
<TheMue> jam: just answered your mail, free for a hangout now
<jam> TheMue: morning. I'm jut finishing up some stuff, can we chat in about 1 hr?
<TheMue> jam: yep, Iâm ready when you are
<TheMue> jam: hmm, just wrote you that Iâve read your mail and answered it directly after my âmorningâ, but cannot see it here *stunning* seems I accidently cancelled the sending :(
<TheMue> oh,done a refresh now, itâs there. strange.
<jam> I got it
<TheMue> jam: yeah, I see it now. looks like a display problem with my client.
<voidspace> morning all
<TheMue> voidspace: heya
<axw> jam: would you mind importing my lp key into the bot? I'd like to have a look around to see if there's something different to the instance I created; I still can't reproduce the error even in lcy01 with the same constraints
<jam> axw: axwalk?
<axw> jam: yup
<jam> axw: done 10.55.61.118 is the IP
<axw> thanks
<axw> jam: sorry, what user?
<axw> system login
<axw> nm, realised it's ubuntu
<axw> fwereade: never realised comprise could be used like that; I always use compose in that case
<fwereade> axw, it's a funny word, part of me always worries that I'm using it the wrong way round
<axw> fwereade: SIGABRT tells the machine agent to exit with ErrTerminateAgent, which is what causes a cleanup
<axw> fwereade: it's for the manual provider, but I don't think we actually need it anymore
<fwereade> axw, a cleanup on the state server though? or just a local cleanup of the upstart conf etc?
<axw> fwereade: the Destroy method for manual does all the things now anyway, in case the machine agent didn't get set up correctly
<axw> umm
<axw> removes the upstart conf, and deletes the data-dir
<fwereade> axw, yeah, thought so
<fwereade> axw, I am definitely wondering if we still want it
<fwereade> axw, it's a bit of a drastic kill-switch in general I think
<axw> fwereade: the main benefit is that the server may know about things that the client does not
<axw> fwereade: e.g. if the server is a version ahead of the client
<jam> axw: you ssh in as ubuntu, the test suite runs as user "tarmac"
<axw> jam: thanks. I was hoping not to have to run them manually, but I can't see any obvious discrepancies. what's the protocol for locking the bot so I can run tests manually?
<jam> axw: flock -n /home/tarmac/tarmack.lock sleep 3600
<jam> is what I run in screen
<jam> (screen -xRR as the Ubuntu user will get you some interesting shells
<axw> thanks
<axw> argh! ascii goatse
<jam> axw: I said they were interesting, I didn't specify SFW :)
<axw> ;)
<jam> I do think ascii goatse would lose some of its oomph
<axw> fwereade: that shouldEnableHA code is intended to be temporary; certainly if/when the local provider is changed to have an external provider agent, we could enable it for all providers
<axw> fwereade: it's only disabled at all right now because there's a bug in the replicaset initiation code (or mongo?)
<axw> theoretically it should be fine to initiate with a single member
<jam> axw: so wallyworld_ had tests fail with --replicaSet passed, but neither thumper nor I had the test suite fail with it.
<axw> jam: yeah. I think there may have been failures on the bot too? or CI? I forget
<jam> I believe CI said that local was failing for them
<axw> so AFAIK we don't do anything special for local, so really it's a bit of a hack to disable it for local
<axw> we're probably just papering over general brokenness
<jam> axw: yeah, my concern is that it really is something that would be failing ,we are just *noticing* in the CI local tests.
<jam> axw: there *is* a reason to disable HA for local, because only machine-0 can actually do provisioning
<axw> jam: yes, true, for now
<jam> though I'm reluctant to have lots of special code paths just for that.
<axw> agreed
<wallyworld_> i only put in the local hack cause we needed to cut a new release and time was running out
<jam> wallyworld_: sure, but it was also supported because of questions about "should we really have HA with local", which seems to go around a bit in circles
<wallyworld_> well yeah, but would be nice to have it to experiment, even wit the machine 0 limitation
<perrito666> good morning everyone
<voidspace> perrito666: morning
 * perrito666 makes some effort to avoid falling asleep in the kb
<jam> perrito666: at least those keys usually are pokey enough to help keep you awake :)
<perrito666> are we doing the big team meeting?
<jam> perrito666: for people that want to be there
<voidspace> perrito666: yes, now
<thumper> are you guys actually in the meeting?
<thumper> I thought we were going to stop that one
 * thumper wanders off for a bit
<voidspace> thumper: we're doing it
<voidspace> http://www.zdnet.com/canonical-juju-devops-tool-coming-to-centos-and-windows-7000029418/#ftag=RSS510d04f
<voidspace> Juju on windows and CentOS!!
<voidspace> we'd better make it happen then
<voidspace> according to that article we've already done it...
<natefinch> They were demoing Windows at ODS
<voidspace> natefinch: cool
<voidspace> anyone know the url to the github repo for docs?
<voidspace> I'd like to add a note about the HA logging
<perrito666> voidspace github.com/juju/docs iirc
<lazyPower> github.com/juju/docs
<voidspace> thanks
<jam> voidspace: my understanding through the channels is that it is a bunch  of "if $PLATFORM" hacks, but does "work"
<voidspace> jam: right
<voidspace> what is evil nick's nick? (irc handle)
<voidspace> jam: the article starts with
<voidspace> " No news may have been more surprising than that Canonical had ported its Juju DevOps  program to its rival's operating systems: Red Hat's CentOS and Microsoft's Hyber-V and Windows Server 2012."
<jam> evilnick, IIRC
<voidspace> Certainly surprising to me that we've ported it to CentOS :-)
<jam> voidspace: well the client probably almost "just works" there, but Mark was pretty clear that it is "in the next few weeks" and not "already working"
<voidspace> Although later the article does say "Thanks to a customer request, Canonical will be releasing Juju for CentOS."
<jam> though "in the next few weeks" is still pretty ambitious
<voidspace> right, it's just typical tech-journal hyperbole
<voidspace> yep :-)
<jam> depending on your definition of "few"
<voidspace> jam: we have an api call (server side implementation) that does it's permissions check with:
<voidspace> "if !api.canModify {"
<voidspace> what permission is that checking for?
<voidspace> jam: answer when you have spare cycles... no rush
<voidspace> I can provide more context to the question
<voidspace> I think the specific test that is failing may not make sense any more
<jam> voidspace: which set of code?
<jam> rsyslog ?
<voidspace> this is in state/apiserver/rsyslog/rsyslog.go
<voidspace> so yes
<jam> 		canModify:      authorizer.AuthEnvironManager(),
<jam> voidspace: so this was checking whether you are allowed to do something like set the ca-cert
<voidspace> the test is checking that calling SetRsyslogCert fails with a permissions error appropriately
<jam> and only EnvironManagers (aka state servers) were supposed to be allowed.
<voidspace> right, that's what I suspected
<voidspace> the test does
<voidspace> st.Rsyslog().SetRsyslogCert(coretesting.CACert)
<jam> voidspace: we don't want generic Machine/Unit agents be abel to set it, but they need to be able to read it
<jam> voidspace: sure, it should be done with an Authorizer that doesn't have AuthEnvironManager()
<jam> If that API is exposed then we should test that !EnvironManagers get a permission failure trying to call it
<voidspace> hmmm...
<jam> voidspace: apiserver/testing.FakeAuthorizer generally gives you lots of ability to tweak things.
<voidspace> jam: so the problem is that the test was previously doing "s.OpenAPIAsNewMachine(c, state.JobHostUnits)"
<voidspace> but that was failing because we need a "real" state server in order to be able to access st.Rsyslog()
<perrito666> bbl
<voidspace> but changing it to JobManageEnvirons causes the test to fail because there is no permissions error
<voidspace> so I think I need to create a state server, but then make this call from a unit
<wallyworld_> fwereade: after the next meeting i'd like to have a quick chat about the BaseSuite stuff if you have some time
<voidspace> jam: thanks
<jam> voidspace: I don't quite understand what you mean about the real state server to access st.Rsyslog(), you can create a machine entity which has JobManageEnviron and then create *another* one that doesn't
<voidspace> st.Rsyslog() fails with "no state servers can be found"
<voidspace> because Rsyslog checks APIHostPorts and if this is empty that call errors
<jam> voidspace: sure, there is a general thing that JujuConnSuite doesn't create a Machine-0 for you that has JobManageEnviron, you should be able to look around for tests that create one
<jam> and then do that firsrt
<jam> and then do OpenAPIAsNewMachine()
<jam> and then the rest of the test probably doesn't need much changing.
<voidspace> yep, that's what I meant - create a state server (and set address) but call Rsyslog from a machine with JobHostUnits
<voidspace> and that now passes
<jam> voidspace: right, so like state/apiserver/client/client_test.go line 2198 is creating machine0, but is connecting to the API server as Client
<jam> voidspace: cheers
<voidspace> no file should *ever* have a line 2198 :-D
<natefinch> +100
<voidspace> jam: I've done this
<voidspace> https://pastebin.canonical.com/110265/
<natefinch> I remember a 1000 line function from one of my early jobs...  now I can't imagine how it wasn't broken up
<voidspace> jam: is s.State.AddMachine(...) preferable, or just a different spelling of the same thing?
<jam> voidspace: I believe OpenAPIAsNewMachine does s.State.AddMachine behind the scenes, but then goes on and connects to stuff, which you don't actually use
<jam> so just doing the s.State.AddMachine is prob better
<voidspace> jam: right, I'll try that then - thanks
<voidspace> to be fair, huge files are *less* of an issue for test files
<voidspace> still not ideal though
<voidspace> brb
<jam> voidspace: I'd be happy with a "// ensure there is a machine-0 so we have an address to copy logs to"
<voidspace> jam: yep, good call
<voidspace> wwitzel3: ping
<wwitzel3> voidspace: pong
<jam> TheMue: do you feel like you have enough guidance to start working on cleaning up the giant agenda doc, or do you need some more discussion?
<TheMue> jam: in my first step Iâm running through the doc and make my notes what I think it is to change (from should/want to we do) and what is to cleanup
<TheMue> jam: in a second run I would like to share it with you to discuss it
<TheMue> jam: Iâm currently working in a copy of that doc
<jam> that sounds good
<voidspace> wwitzel3: hey, hi
<wwitzel3> voidspace: hangout?
<voidspace> wwitzel3: so I have all tests passing in our branch
<voidspace> wwitzel3: sure
<voidspace> lunch
<wwitzel3> voidspace: it ended up being a permissions issue
<wwitzel3> voidspace: I pushed the changes, tested successfully with ec2 and maas
<perrito666> jam: did yo really mean to invite me to this meeting? "Every 3 weeks from 23:00 to 00:00 on Wednesday (ART)"
<jam> perrito666: I just sent out an email to canonical-juju explaining it
<wwitzel3> voidspace: I'm going to start fleshing out some of the test cases a bit more and working on doc
<jam> the idea is that the weekly meeting starts rotating by 8 hours
<jam> so some of them you can't make
<jam> hopefully most you can
<bodie_> booya, gojsonschema now apache2 licensed
<jcw4> bodie_: nice!
<voidspace> wwitzel3: cool, I suspected as much
<voidspace> wwitzel3: yup, MachineAgent *or* UnitAgent
<wwitzel3> voidspace: yep
<voidspace> I wondered if that would be the fix :-)
<voidspace> wwitzel3: nice work, thanks
<voidspace> grabbing coffee
<voidspace> wwitzel3: I have some simple docs by the way
<sinzui> jam, natefinch : is anyone about to look into bug 1319822
<_mup_> Bug #1319822: lxc unit tests broken for trusty <lxc> <regression> <test-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1319822>
<voidspace> wwitzel3: http://pastebin.ubuntu.com/7467981/
<sinzui> ^ telling my CI is mis-configured is an acceptable answer
<voidspace> sorry about the line wrapping
<wwitzel3> voidspace: cool, I just pushed some comment updates
<natefinch> sinzui: seems it's likely an environmental issue, but I'm not sure exactly what's going on there
<wwitzel3> voidspace: did the initial propose, figure people can start looking at it now while we button things up with doc
<natefinch> fwereade: are you back?
<voidspace> wwitzel3: ok
<voidspace> cool
<wwitzel3> natefinch, jam, fwereade, voidspace: https://codereview.appspot.com/94510043/ (rsyslog API/watcher changes), fixes bug #1310268
<_mup_> Bug #1310268: rsyslog should accumulate on all state machines <debug-log> <ha> <juju-core:In Progress by wwitzel3> <https://launchpad.net/bugs/1310268>
<sinzui> natefinch, the trusty unit-tests setup forces mongodb-server. I don't think it is a factor. trusty /could/ get a newer lxc, but I hasn't
<wwitzel3> voidspace: I'm going to test what happens with multiple units --to the same machine, then doing ensure-availability
<voidspace> great
<wwitzel3> voidspace: also that doc you wrote LGTM
<voidspace> wwitzel3: I'll go though checking our test coverage
<voidspace> wwitzel3: cool - I sent an email to juju list asking where it should go, but I didn't see the email land
<voidspace> wwitzel3: ah, it did - curtis replied
<voidspace> and Nick
<voidspace> I'll put those in a github issue
<natefinch> sinzui: you on the cross team call?
<sinzui> I am
<mattyw> natefinch, after the call cmars has suggested you guys could do with some help on the ha work, ping me when you have a moment and we'll see if there's anything I can help with
<natefinch> mattyw: that would be awesome
<natefinch> I'm off to pick up some chicks (of the baby chicken variety).  Back in like an hour and a half-ish.
<perrito666> I must say natefinch has the best bbl messages
<wwitzel3> perrito666: haha, yeah
<perrito666> mm, what is the proper way to make juju look for juju-local in gopath?
<voidspace> jam: ping
<perrito666> mm, juju local is broken?
<perrito666> I mean in trunk
<voidspace> perrito666: local provider or the juju-local package?
<perrito666> voidspace: no, I built the one from trunk and am using that, but I suspect is not working so well
<voidspace> perrito666: juju local what though?
<voidspace> perrito666: I thought juju-local was just an empty package to declare dependencies
<voidspace> perrito666: what on trunk did you build/
<voidspace> ?
<perrito666> voidspace: I meant juju-local the binary
<perrito666> :)
<voidspace> oh
<voidspace> heh
<voidspace> perrito666: fair enough :-)
<perrito666> which bootstraps but the bootstraped env has address localhost, which is wrong
<voidspace> hmmm... doesn't sound good
<voidspace> but I'm EOD
<perrito666> voidspace: have a nice day
<voidspace> perrito666: thanks
<natefinch> I'm back, sadly without chicks.
<perrito666> natefinch: eggs, a hot lamp and time?
<natefinch> perrito666: haha, no.  When I called, they said the chicks had come in, but it turns out only half their order had come in - sadly, the half that had the varieties we were not interested in
<perrito666> natefinch: I am slightly curious, what are you going to do with the chicks?
<natefinch> perrito666: they're egg layers.  We eat some and sell most of them to a local hostel
<perrito666> natefinch: you are a full fledged farmer
<natefinch> perrito666: heh... I have chickens and bees and a vegetable garden.  Not really a farmer, but working my way there.  Someday we'll have goats and maybe pigs... right now the kids kinda make that too much to take on.
<mattyw> natefinch, that sounds like farming to me
<TheMue> natefinch: and donât forget your coffee
<TheMue> yummy
<mattyw> does your vegetable garden require a tractor to sow?
<mattyw> natefinch, I'm going to be ending my day soon, do you have a few minutes to talk about ha work items you need help with?
<perrito666> natefinch: heh, too much work, I only do bread and yogurt
<natefinch> mattyw: haha... I wish, then I'd have an excuse to buy a tractor ;)
<natefinch> TheMue: I roast coffee, but I don't grow it, that hardly counts :)
<natefinch> mattyw: yes, sorry I didn't get to you earlier.
<TheMue> natefinch: I know, but itâs still very special
<mattyw> natefinch, no problem at all
<natefinch> perrito666: btw, are you working on that APIWorker thing? If so, you should assign the card to yourself and put it in doing
<perrito666> natefinch: yup sorry
<natefinch> mattyw: we have our kanban board here, my team is Moonstone, so you can see the stuff that is in the "2 week planning" which is essentially the "Todo" lane (ignore the actual todo lane, that's not in current use) https://canonical.leankit.com/Boards/View/103148069#workflow-view
<natefinch> mattyw: anything not assigned to anyone is up for grabs.
<mattyw> natefinch, it appears that my leankit account has been deactivated (despite me asking it not to be)
<natefinch> mattyw: doh, I'll talk to IS about getting it set back up
<natefinch> mattyw: you can look here instead, this is basically the same stuff: https://docs.google.com/a/canonical.com/document/d/17yV2hZHhTch7fn33s3qJoT3qXJrXSeD40z8k7Rt90I8/edit
<natefinch> mattyw: how familiar are you with the juju-core code?
<natefinch> mattyw: we can talk tomorrow too, if that's easier.  I don't want to keep you past EOD
<wwitzel3> natefinch: https://codereview.appspot.com/94510043/ when you have a chance (rsyslog stuff from voidspace and myself)
<natefinch> wwitzel3: sweet, I'll take a look
<mattyw> natefinch, I'm "hopefully" in the process of getting my leankit account setup again
<natefinch> mattyw:
<natefinch> cool
<natefinch> somehow hit enter rather than space... stupid fingers
<perrito666> natefinch: they are close... :p
<mattyw> natefinch, I've done some stuff with the api before, and a little bit of stuff around the service docs in the state server, but that's about it
<mattyw> natefinch, yeah, if it's ok with you can we talk tomorrow morning (your time) about ha and I'll pick something up
<natefinch> mattyw: that's cool.  Have a good evening, we can talk tomorrow.
<bodie_> fwereade, the thinking behind "actionsspec" was that Actions would be the list of actions on the state
<bodie_> I guess a charm can't have a list of actions :)
<fwereade> bodie_, hey, I'm here now for a bit
<fwereade> bodie_, need to push that code for jcw4, it depends on some more code I should push, need a few mins
<bodie_> right on.  I'm still mid-stride with the last bits here in state
<bodie_> added actions.yaml, reader, and charm member
<bodie_> I don't want it to become another monolithic commit but adding it as a piece of the Charm interface has a pretty long-reaching effect
<bodie_> however I think I've been able to pare it down significantly from what we had before
<fwereade> bodie_, you could rationally add the types and reader to the charm package without needing to hit anything else -- not even reading them when you read a charm
<bodie_> ah
<fwereade> bodie_, adding a type and actually using it in 2 CLs generally makes me pretty happy even :)
<bodie_> ^_^
<bodie_> should I snip the other bits out then?  I figured the mission was "add Actions to Charm"
<fwereade> bodie_, and inevitably the second CL includes a tweak or 2 to adapt to reality, but that's just fine
<bodie_> which, I think is mostly pushed through by now
<fwereade> bodie_, sure, but the more and smaller the steps you take to get there the smoother everything usually goes -- but if it's bigger don't let that stop you either
<bodie_> I can of course yoink the relevant bits but I think this is pretty sane
<bodie_> okay, cool
<menn0> hi ppl.
<fwereade> menn0, heyhey
<menn0> fwereade: do you not sleep? :-p
<fwereade> menn0, I'm well behind wallyworld_ in the no-sleep stakes :)
<fwereade> menn0, and actually I had a nap this afternoon so I'm feeling a bit guilty about that ;)
<bodie_> no rest for the wicked!
<menn0> fair enough
<menn0> question: I picked up this yesterday but it appears that it's already been fixed. https://bugs.launchpad.net/juju-core/+bug/1194481
<_mup_> Bug #1194481: Can't determine which relation is in error from status <hours> <observability> <ui> <juju-core:In Progress by menno.smits> <https://launchpad.net/bugs/1194481>
<fwereade> menn0, hmm, I knew we recorded the necessary information, didn't remember that we actually exposed that in status
<fwereade> menn0, do we expose the relation id, or just the name?
<menn0> actually, now that I re-read the ticket... I think I understand the problem more.
<menn0> the full hook name is given but the relation isn't
<menn0> nevermind
<fwereade> menn0, knowing that mysql's "db" relation has an error is not quite all we need; it might be driving wordpress, mediawiki, etc
<fwereade> menn0, cool
<fwereade> menn0, that info is in the status data dict
<menn0> fwereade: yeah but the StatusData map isn't pushed through the API yet
<thumper> o/
<menn0> i'll sort that out!
 * thumper has a haircut appt shortly
<menn0> thumper:   \o
<fwereade> thumper, heyhey
<fwereade> menn0, heh, "dict", my python is showing
<menn0> fwereade: I noticed but chose not to tease you :)
<fwereade> jcw4, https://codereview.appspot.com/94540043 is a quick hack that I'm not yet sure is a good idea; but it does involve adding a new cleanup type, as I suspect we'll need to deal with actions referencing dead units
<jcw4> fwereade: thanks~
<menn0> fwereade: StatusData doesn't have the relation name either so I may have to fix that. Or is it easy to derive the relation name from the id?
 * thumper back soonish
<fwereade> menn0, name is a tricky concept in a relation, the two sides might call it different things
<fwereade> menn0, but, yes, you can look up relations be id and get a human-readable name out
<fwereade> menn0, eg "wordpress:mysql mysql:db"
<bodie_> fwereade, I'm starting to think this MR is going to be a little out of control, but again, broad scope.... well, maybe you can give me a little feedback in a couple of minutes here
<fwereade> menn0, that's a pair of "endpoints" -- not sure if you cast an eye over doc/glossary.txt?
<menn0> fwereade: that makes sense. I guess I need to figure out if juju status has enough information to figure out the appropriate endpoint name from just the relation-id and the unit.
<menn0> fwereade: or if I need to put more in to the StatusData map so that it can show the required info
<menn0> fwereade: yep, I have read glossary.txt
<fwereade> menn0, you shouldn;t need more in the statusdata map -- just get it if you need it when you're generating the actual status
<menn0> fwereade: cool
<jcw4> fwereade: per your cleanup code... I would add code to cleanupDyingUnit for scrubbing Actions?
<fwereade> jcw4, well, it'd be a deadUnit cleanup, but yeah
<jcw4> bingo
<jcw4> fwereade: got it
<menn0> fwereade: first step then is to thread StatusData through the API, which I think I've almost done
<jcw4> fwereade: should I merge your branch in, or just emulate it and we'll merge before landing?
<fwereade> jcw4, I would just clone the structure, all the *actual* code will be different I think
<fwereade> menn0, not 100% sure there -- see state/apiserver/client.go:525
<jcw4> fwereade: ok so by clone you mean copy and modify for Dead vs. Dying?
<fwereade> menn0, one thing we did discuss at the sprint -- but I forget under what heading -- was the unification of the AllWatcher data stream and the Status result
<fwereade> menn0, they're different for no good reason ATM
<fwereade> menn0, if (as I think it is) it's in the AllWatcher stream, consider poking it into status in a vaguely similar way -- but *consider*, it might be crazy/impossible to do so
 * menn0 looks at code. knows nothing about AllWatcher stream.
<fwereade> menn0, ideally we'll let the two formats converge and have CLI status just be a wrapper converting exactly the same data into the existing output format
<fwereade> menn0, but I don;t want to trigger crazy refactorings in the course of this bug fix
<fwereade> menn0, just do it if it's easy :)
<fwereade> jcw4, I think you'll find there;s little that actually gets copied
<menn0> fwereade: I will have a go
<fwereade> jcw4, a branch in the switch, but new and different code for (1) queuing it and (2) handling it
<jcw4> fwereade: yeah.. okay -- the code helps tremendously as a guide
<fwereade> jcw4, cool
<menn0> fwereade: that line number in state/apiserver/client.go doesn't seem at all relevant to our discussion. It lands me half way down GetServiceConstraints
<menn0> fwereade: I've just pulled to be sure
<fwereade> menn0, balls, sorry: /client/status.go
<fwereade> menn0, FWIW there's another TODO in that about maybe not hitting the DB at least twice for each relation -- might be good to address that one tbh, rather than worrying about AllWatcher now
<menn0> fwereade: I've already spiked to address that TODO in status.go :)
 * fwereade cheers at menn0
<menn0> fwereade: I'll check out the other TODO as well
 * menn0 is having fun
 * fwereade is happy
 * fwereade maybe bbiab, but most likely going to sleep
<waigani> menn0: what bug are you working on?
<menn0> waigani: https://bugs.launchpad.net/juju-core/+bug/1194481
<_mup_> Bug #1194481: Can't determine which relation is in error from status <hours> <observability> <ui> <juju-core:In Progress by menno.smits> <https://launchpad.net/bugs/1194481>
<thumper> rick_h_: around?
<thumper> rick_h_: I'd like to understand some more the charmstore work
<thumper> also...
<thumper> damnit
<thumper> I had a great idea for an email I was going to write to the juju-dev list outlining something
<thumper> and now it has gone
 * thumper sits back and thinks through what he was thinking through
<thumper> oh
<thumper> that was it
<thumper> yay
<thumper> note to self: email juju-dev about schema upgrade process
<rick_h_> thumper: around
<thumper> rick_h_: got time?
<rick_h_> thumper: sure, sec
<thumper> rick_h_: https://plus.google.com/hangouts/_/gsd6yrioblijf2oz3fvdnyesjma?hl=en
<thumper> davecheney: re: https://github.com/juju/errgo/pull/2/files I don't get why this fixes the errgo tests, but when called from juju/errors it behaves correctly (given the extra generated method that we now side step)
<thumper> davecheney: can you explain it?
<thumper> is it related to the testing module?
<thumper> that is the only other difference between the tests, juju/errors uses gocheck whereas juju/errgo just uses the builtin testing module
#juju-dev 2014-05-16
<davecheney> thumper: yes, that was a mistake
<davecheney> that line doesn't do anything
<davecheney> but commenting it out was a mistake
<davecheney> i will revert that part from the PR
<davecheney> and add some more test coverage to exercise that line
<thumper> davecheney: I'm concerned
<thumper> how do I pull your branch locally?
<thumper> davecheney: do you know what causes the empty caller stack item between the test function and the code?
<thumper> davecheney: I'm wondering if when called in real life, we don't get that
<thumper> davecheney: in particular, the errgo.New method in the global var block gets the wrong location
<thumper> davecheney: as it doesn't have a blank caller entry
<thumper> davecheney: also, when called from juju/errors we get the correct stack
<thumper> but if this change goes in, they will be wrong
<rick_h_> thumper: toss some notes/feedback in your doc. I can't edit or I'd spell out some of the use cases/etc. Let me know if any of it seems crazy.
<davecheney> thumper: go to the PR, there is link to the instructions on how to checkout my branch
<davecheney> thumper: the final error remaining to be fixed ?
<thumper> davecheney: I'll look again
<davecheney> i don't know the cause at the moent, if I did, I would have fixed it :)
<thumper> davecheney: the pull request doesn't tell me how to get it locally
<thumper> or at least not in any way obvious I can see
<thumper> rick_h_: kk, ta
<thumper> davecheney: do you know how I can get your branch locally? I'm stumped
<davecheney> thumper: https://github.com/juju/errgo/pull/2
<davecheney> ^ click You can also merge branches on the  command line.
<davecheney> do step 1
<davecheney> don't do step 2
<thumper> ahh...
<thumper> ta
<davecheney> thumper: welcome to the monoculture
<thumper> davecheney: as expected, with the change to errgo, all of the stack tests in juju/errors now fail
 * thumper has to go do daughter's lunch now
<davecheney> shit
 * davecheney has a horrible feeling this may not be fixable i the general case
<sinzui> hi wallyworld_ https://bugs.launchpad.net/juju-core/+bug/1319822 appeared with your branch to change lxc
<_mup_> Bug #1319822: lxc unit tests broken for trusty <lxc> <regression> <test-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1319822>
<wallyworld_> sinzui: yeah, it's on my todo list today. sad that it passed the bot but breaks on CI
<sinzui> wallyworld_, can you review what went wrong?
<wallyworld_> yeah, just finishing another branch first
<sinzui> wallyworld_, It might be CI. I am willing to accept the bame
<wallyworld_> more likely my fault
<wallyworld_> i also gotta look to see if precise containers on trusty host has broken again
<sinzui> wallyworld_, I now have aws, canonistack, and lexington under by control. http://juju-ci.vapour.ws:8080/
<wallyworld_> great
<sinzui> but alas, I forgot the test I wanted to play needs a built package, and CI doesn't know how to do that ppc64 and arm64
<wallyworld_> i like all the blue dots
 * menn0 is being inducted^Wbrainwashed
<thumper> davecheney: https://github.com/juju/errgo/pull/3
 * davecheney looks
<davecheney> thumper: if it passed under gc
<davecheney> check it in
<thumper> it did
<davecheney> cool
<thumper> and it passes with gccgo
<thumper> fwiw
<davecheney> thumper: so here is my concern
<davecheney> runtime.Callers is basically different between gc and gccgo
<davecheney> normally you can work around it by adjusting the offset of the initial runtime.Callers
<thumper> for many values yes
<davecheney> but if we stack these things, and there are embedded strcuts involved
<davecheney> i am not sure it will work for all possible variation
<davecheney> variations
<thumper> however I *think* that the one causing a problem is just for tests
<davecheney> yes
<davecheney> and the effect on real code is you may see an odd line in the stack trace that either has no source line
<thumper> so perhaps we patch the initial level only for gccgo and just for the tests?
<thumper> and it seems to be just the test methods themselves
<thumper> oh...
<thumper> I have a plan
<wallyworld_> axw: hiya, standup?
<davecheney> the &embed{err} one is the complete fucker
<thumper> davecheney: let me try something
<davecheney> thumper: hold up, i'll update my PR
<thumper> davecheney: I'd like some approval on that test addition PR
<thumper> davecheney: so it looks like I'm getting other feedback :)
<davecheney> thumper: i can drop it from the PR
<thumper> is there a git command to branch and checkout?
<davecheney> keep things simple
<davecheney> thumper: you're asking the wrong man
<davecheney> i use
<davecheney> git checkout -b NAME
<davecheney> which branchs and switchs to NAME
<axw> wallyworld_: hey, yep
<thumper> that what I want
<davecheney> excellent, grammar good
<thumper> davecheney: ya know...
<thumper> davecheney: I bet if we changed errgo to use gocheck, this would work
<thumper> davecheney: so... TestNew failes but TestNewf succeeds
<thumper> with gccgo
<davecheney> https://github.com/juju/errgo/pull/2
<davecheney> updated
<davecheney> now with less contraversy
<davecheney> --- FAIL: TestNoteUsage (0.00 seconds)
<davecheney>  errors_test.go:250: unexpected details: want "[{/home/dfc/src/github.com/juju/errgo/errorstest.go:38: annotate2} {/home/dfc/src/github.com/juju/errgo/errors_test.go:32: annotate1} {/home/dfc/src/github.com/juju/errgo/errors_test.go:29: some error}]"; got "[{/home/dfc/src/github.com/juju/errgo/errors_test.go:43: annotate2} {/home/dfc/src/github.com/juju/errgoj/errors_test.go:37: annotate1} {/tmp/go-build412244215/github.com/juju/errgo/_t
<davecheney> yup, that test fails on my branch with those adjustments
 * davecheney goes back to hunting wumpus'
<thumper> davecheney: I'm pretty confused as to why TestNew fails but TestNewf succeeds
<davecheney> same
<davecheney> it calls the same damn methods
<thumper> yeah
<davecheney> fyi, % go test && go test -compiler=gccgo
<thumper> who do we know on gccgo that we can throw this at?
 * davecheney raises hands
<davecheney> seriusly, it might be me
<thumper> handy to do that in one command
<thumper> heh
<davecheney> we did log a bug about this with the upstream
<davecheney> we == michael and me last year
 * davecheney searches
<thumper> I think a key point would be to focus on that one use case
<thumper> TestNew vs TestNewf
<thumper> if we can work that out
<thumper> the rest should be simple
<thumper> I'm goint to write other emails...
<davecheney> roger
<davecheney> you're trained for that now
<davecheney> with your ceritificate
<thumper> heh
<thumper> mwhudson: you around?
<thumper> mwhudson: have you been poking gccgo too?
<davecheney> thumper: https://code.google.com/p/go/issues/detail?id=6835
<mwhudson> thumper: not recently
<mwhudson> but i am here
<thumper> davecheney: yeah, read that one, and that is how I fixed the juju/errors work
<davecheney> thumper: bingo
 * thumper jumps on a different hangout
<stokachu> is juju-core/errors being moved out of the tree?
<thumper> stokachu: it has been
<thumper> yes
<thumper> stokachu: to github.com/juju/errors
<stokachu> thumper: ah ok, go get was giving me errors
<thumper> no pun intended?
<stokachu> so i should be doing go get github.com/juju now?
<stokachu> doesn't look like the core bits are on github -- is this a migration in progress i take it?
<davecheney> stokachu: go get -u launchpad.net/juju-core/... will always pull in the correct dependencies
<davecheney> you should run godeps -u dependencies.tsv afterwards to set all the repos to their correct revisions
<stokachu> so go get -u fails to find launchpad.net/juju-core/errors
<stokachu> ran that a few minutes ago
<davecheney> that ios correct
<davecheney> that has been removed
<stokachu> ah lemme re-run then could be fast on the draw
<stokachu> i should probably stop messing with juju-core so late at night :X
<thumper> davecheney: haha, guess what?
<thumper> davecheney: I have a branch that uses gocheck, and all the tests pass with both compilers
<thumper> davecheney: https://github.com/juju/errgo/pull/4
<davecheney> i cannot explain that
<davecheney> and it terrifies me
<davecheney> this is the difference between being called from a function or called from a method
<davecheney> which under the hood are EXACTLY THE SAME!
<davecheney> methods on types are just like static methods on C classes
<davecheney> there is no virtual dispact
<davecheney> dispatch
<thumper> mwhudson: which compiler do we use for juju on armhf and armel?
<thumper> davecheney: I know...
<mwhudson> thumper: gc
<mwhudson> i think
<thumper> davecheney: something screwy is happening
<davecheney> thumper: there is no supprt on armel
<mwhudson> thumper: we don't do anything for armel any more do we?
<davecheney> that is harm without a floating point unit
<thumper> kk
<davecheney> armhf, we use gc
<thumper> cheers
<davecheney> but gccgo is also known to work on linux
<davecheney> thumper: but not juju/errors does not pass
<thumper> huh?
<thumper> davecheney: pass here
<davecheney> hmm, ok
 * davecheney deletes things
<thumper> davecheney: as expected, I bet that the core testing library is doing weird things, perhaps calling functions using reflect which may well be adding synthetic methods through gccgo
<thumper> with gocheck, those synthetic methods are so far up the stack we don't care
<davecheney> thumper: yes it does
<davecheney> the wya testing works is it builds a list of functions by name at compile time, then uses reflect to find those functions at run time an execute them
<davecheney> ok, i call lunch
<axw> wallyworld_: if I run TestInitiateReplicaSet in a loop inside the testing framework (i.e. no per-test SetUp/TearDown), I can reliably get it to fail on the bot - but not on my laptop
<axw> seems the bot is actually faster than may laptop
<davecheney> axw: lol
<wallyworld_> hmmm
<wallyworld_> at least it fails
<davecheney> thumper: [0] for some implementations of great
<davecheney> right, now I really am going for lunch
<waigani> wallyworld_: would you be able to have a look at this: https://codereview.appspot.com/87130045
<waigani>  fwereade has reviewed. Basically, he is happy if you're happy
<waigani> wallyworld_: I have to do school run now, so no rush
<wallyworld_> ok
<waigani> cya :)
<wallyworld_> l8tr
<wallyworld_> axw: i have a fix for the trusty tests on CI https://codereview.appspot.com/99330043
<axw> looking
<wallyworld_> thank you
<menn0> Do I have to worry about compatibility if I'm adding fields to the machine and unit status API responses?
<thumper> hmm...
<thumper> as long as the deserialization code can handle that they are missing
<thumper> you *should* be ok
<thumper> we know that during upgrades, the api server should be done first
<thumper> so an agent should never be a higher version than that api server
<menn0> understood.
<thumper> however, the agent might not be as up to date as the server
<menn0> I think I'll be ok as my change only affects the API server. it's exposing information that is already being reported but just wasn't available in the status response.
<menn0> i'll check the api server / client mismatch issue to make sure there isn't a deserialization issue
<menn0> as an aside: jam is working on versioning for the API isn't he?
<thumper> menn0: just emailed you leankit stuff
<menn0> just saw it thanks
<menn0> "After logging in for the first time, you will have to option to change this temporary password."
<menn0> or not... :(
<thumper> menn0: have you found out where to change it yet?
<thumper> iirc it isn't entirely obvious
<menn0> thumper: no. the UI mentioned in the help isn't there for me. I'm hovering over the Leankit logo in the top right and changing my password isn't available on the menu that appears.
<axw> wallyworld_: puttiing replSetInitiate in a retry loop does the trick
<thumper> menn0: priv msg :)
<wallyworld_> axw: great, a bit hacky but it will server the purpose for now i reckon
<axw> wallyworld_: want me to look at the i386 tests?
<wallyworld_> axw: yeah, that's the next highest priority, thanks
<wallyworld_> it might turn into a "fix tools handling" exercise
 * axw nods
<davecheney> axw: thanks for the review
<axw> davecheney: nps
<axw> always glad to be rid of another panic("unreachable")
<wallyworld__> axw: i'm off to soccer, so have a good weekend. i'm part way through replacing LoggingSuite with BaseSuite and rewriting tests to avoid outgoing http.
<axw> wallyworld__: later, you too. I'm scratching my head at i386 test failures :)
<wallyworld__> does seem like we should consider pluggin in basesuite when the suite is registered
<wallyworld__> yeah, i didn't look too closely at the i386 faiures, looke dtools related
<davecheney> axw: can you clarify if we need to support 1.0 style unreachable stuff ?
<davecheney> I was under the understanding that we
<davecheney> a. did have to support precise
<davecheney> b. the version of Go in precise was not capable of compiling Juju
<davecheney> tf. our minimum is actually 1.1
<axw> davecheney: yeah our minimum is 1.1 (we use 1.1.2 on the bot)
<davecheney> axw: right, in that case there are some more warnings I can address
<axw> bueno
<davecheney> multo gusti!
<axw> and yes we need to support precise. there was talk about moving to 1.2 (and may still), but precise only has 1.1.2 in the ppa right now
<davecheney> given that precise is built from a dependant ppa
<davecheney> and we have to support two compilers anyway
<davecheney> i vote for not shooting ourselves in the foot and having to support two versions of one compiler
<davecheney> that is, Go 1.2 across the board
<davecheney> both as the upper and lower bound
<axw> I would prefer that
 * davecheney will propose
<davecheney> done
<davecheney> omg, goose bot merges things SO FAST
<voidspace> morning all
<fwereade> wallyworld__, ping
<fwereade> waigani, LGTM, just trivials
<jam> fwereade: my thoughts exactly: "LGTM. The yuck of the reflection is more than balanced by the squee of
<jam> the external interface."
<jam> thanks for the reviews
<voidspace> for gccgo should we be testing with the packaged version (apt-get gccgo) or building from source, or something else (building/using a specific version)?
<jam> voidspace: gccgo is packaged on Trusty
<jam> outside of Trusty, you'll probably need to roll your own (or push us to get something into a PPA)
<voidspace> ah, and in the next thread David says "gccgo-4.9"
<voidspace> I'm on trusty
<voidspace> jam: thanks
<jam> voidspace: yeah, the gccgo in trusty is good enough for working with.
<jam> It *is* being used in anger for the ppc64 ports.
<jam> and amd64
<voidspace> fwereade: you wanted to be pinged about rsyslog-ca-cert in wwitzel3's branch - which is also my branch
<voidspace> jam: yeah, there's a thread that says we should be testing with it
<voidspace> fwereade: so we had a big discussion about this issue (is watching APIHostPorts alone sufficient or not)?
<voidspace> fwereade: and no-one wanted to commit to an answer, but the consensus seemed to be
<voidspace> fwereade: if we're treating the rsyslog config entries as "immutable once set" then watching APIHostPorts alone to trigger rsyslog config rewriting should be enough
<voidspace> fwereade: and it works for the scenarios we've manually tested
<voidspace> non-HA with unit deployed, HA without units, HA then units deployed, non-HA with units deployed then ensure-availability
<voidspace> rsyslog config is rewritten in all these cases and logging happens correctly
<voidspace> fwereade: so the only wrinkle would be if the rsyslog config can be written out *before* the certificate is set for the first time on bootstrap
<voidspace> fwereade: in which case it wouldn't be rewritten
<voidspace> fwereade: when we asked nobody thought that was likely, but no-one would *commit* to it being impossible
<voidspace> fwereade: however "they" (jam and natefinch) did think that if we're treating the rsyslog config as "immutable once set" then watching just APIHostPorts *should* be sufficient
<voidspace> so that's what we did
<vladk> jam: hangout
<jam> vladk: I'm not actually "working" today
<jam> its my weekend
<TheMue> vladk: here
<wwitzel3> hello
<voidspace> wwitzel3: hey, hi
<voidspace> wwitzel3: there were some comments on the mp from fwereade
<voidspace> wwitzel3: I replied
<voidspace> wwitzel3: one thing we forgot - we made GetRsyslogConfig return HostPorts
<voidspace> wwitzel3: the reason for that is so that the templates can use host-port pairs rather than host plus global port
<voidspace> wwitzel3: but we didn't change the template rendering code to do that
<voidspace> wwitzel3: I've made a start on that (whilst also starting some more manual testing against canonistack and reading William's architecture doc)
<voidspace> wwitzel3: nothing to push yet
<voidspace> wwitzel3: we can probably lose the global port on the RsyslogConfigParams then
<voidspace> but you arrived (as always) just as I need coffee)
<voidspace> natefinch: morning
<davecheney> this is a lie
<davecheney> it is not morning for natefinch
<voidspace> davecheney: it's *always* morning on the internet
<natefinch> +1
<natefinch> also, yes, it is morning :)(
<natefinch> morning davecheney :)
<wallyworld__> fwereade: hi, was at soccer, back now
<fwereade> wallyworld__, er, what did I want
<fwereade> wallyworld__, oh yes: are you doing git things?
<wallyworld__> yes, sorta
<fwereade> wallyworld__, ie landing bot change etc
<fwereade> wallyworld__, can I put the use-go-1.2 stuff on your plate then please?
<wallyworld__> i have a repo that i've migrated to github https://github.com/wallyworld/core
<wallyworld__> and i'm working with curtis to get the landing bot sorted out
<wallyworld__> sure
<wallyworld__> so we want the bot to use go 1.2?
<wallyworld__> fwereade: also, i'd like a meeting with you first thing your monday AM to talk about storage, would that be ok?
<fwereade> wallyworld__, sure
<wallyworld__> ok, just ping me when you're online
<fwereade> wallyworld__, will do
<mattyw> natefinch, myself and tasdomas are available to help with ha, let me know when would be a good time to grab your for a chat about it
<natefinch> mattyw: cool, let me bring up the docs
<fwereade> voidspace, wwitzel3: is anyone free to briefly educate me on rsyslog-ca-cert, where it came from, why it exists, etc?
<fwereade> voidspace, wwitzel3: I suspect it interacts with stuff cmars is doing at the moment but I don't really have a clear picture of how it all ends up interacting
<fwereade> voidspace, wwitzel3: in particular I'm +1 on separate certs for separate services, but less convinced that we need a different ca cert for rsyslog, unless we're thinking of setting up external rsyslog targets
<fwereade> voidspace, wwitzel3: and even then *we* wouldn't be generating server certs from it?
<natefinch> mattyw: sorry, my daughter detected I might get work done and woke up.  It'll be an hour or so for my wife to wake up and be ready to take her, so probably don't wait for me for right now
<mattyw> natefinch, ok no problem, I'll take the time to sort my little on out as well :), just ping me when you're ready
<natefinch> mattyw: cool
<voidspace> fwereade: we already have these certs, so no I'm not able to educate you on why we have it :-)
<voidspace> I have to go on lunch
<voidspace> meeting a friend
<voidspace> but I'll be back soonish
<fwereade> voidspace, np, enjoy, I will go hunting
<voidspace> ta, see you all soon
 * bodie_ pings fwereade -- going to slice that commit back down to what you'd mentioned and get it in this morning :)
<fwereade> bodie_, don't feel you have to, go ahead and propose as it is if you like -- you can slice bits out while I take a first look if you like
<TheMue> lunchtime
<perrito666> TheMue: I will not lunch at 9 am :p
<bodie_> on that note fwereade and jcw4 -- the interface{} option for gojsonschema is looking for a raw JSON string.  I think it's appropriate to transform the unmarshaled YAML map into a JSON string to check whether it conforms to JSON-schema, but I'm not positive what the behavior will be like (whether it will, e.g., silently truncate nonconformant values from the map)
<fwereade> bodie_, huh, that's really bizarre, Iwonder why on earth they would do that
<fwereade> bodie_, https://github.com/xeipuuv/gojsonschema/blob/master/schemaDocument.go :66 seems to imply it can handle map[string]interface{} at least for schemaDocument
<bodie_> I could be misinterpreting something, but when I try to "smush" the unmarshaled YAML into the gojsonschema loader, it's saying it "must be a jsonReference string or Json as map[string]interface{}"
<fwereade> bodie_, if we *have* to go via json we could, I guess, but I think it's a last resort
<fwereade> bodie_, I think map[string]interface{} is nice for us all around though
<bodie_> I agree
<bodie_> I could be misinterpreting the error, too, or it could be happening for a different reason
<fwereade> bodie_, we could use the juju-core/schema package to coerce that stuff into map[string]interface{} on ingest
<fwereade> bodie_, I suspect it's because it's map[interface{}]interface{} until it's coerced?
 * bodie_ ponders
<bodie_> it's probably a silly type issue
<bodie_> right now an Actions is just an alias for map[string]interface{} but perhaps it doesn't know how to unmarshal yaml into that alias
<bodie_> either way I need to really cut down the scope on this
<bodie_> if you'd like to have a look it's here -- https://code.launchpad.net/~binary132/juju-core/charm-actions
<bodie_> the problem code is here http://bazaar.launchpad.net/~binary132/juju-core/charm-actions/revision/2736
<bodie_> actually, if anyone has input on that, it would be welcome.  I suspect it's to do with unmarshaling to "actions" and attempting to do NewJsonSchemaDocument on "actions" which is of type ... Actions map[string]interface instead of directly on such a map
<fwereade> bodie_, "Actions" doesn't sound quite right for that type anyway
<bodie_> that's the type formerly known as ActionsSpec... lol
<bodie_> it's a charm's Actions
<fwereade> bodie_, giving whatever encloses it a "schema" field of type map[string]interface{} seems like a perfectly reasonable thing to unmarshal the yaml into, then you should be able to hand over to gojsonschema directly, I think
<fwereade> bodie_, I don't think the whole set of actions wants to be a schema, does it?
<bodie_> rather a <action_name>.yaml for each action in the charm?
<bodie_> an*
<fwereade> bodie_, we want a map[name]ActionSpec or something, in which an ActionSpec has name, description, schema (or something roughlylike  that anyway, I think)
<fwereade> bodie_, yeah, actions.yaml seems like a nice way to express it
<bodie_> well the idea was to define the loosest possible schema, but a sane charm would have its top level keys be the names of actions
<fwereade> bodie_, not sure, don't we want `actions: {...}` at the top level for forward compatibility?
<fwereade> bodie_, otherwise there's nowhere nice to tack on a version field if (when ;)) we need it
<fwereade> bodie_, (but yeah we don't want name explicitly I guess, that can come from the map keys, ofc)
<bodie_> presumed version would be for the entire charm?
<bodie_> if you change the actions, that ought to increment the charm version
<fwereade> bodie_, no, I mean the format of the actions.yaml file itself
<fwereade> bodie_, I have yet to see a v1 of a format that never needed to be changed ;p
<bodie_> hehe
<fwereade> bodie_, (given a year of two if usage anyway)
<bodie_> my assumption here was that our goal is to permit the charmer to define his actions spec however he pleases, as long as it's "some kind of" json-schema
<bodie_> I'm not grasping what you're envisioning
<fwereade> bodie_, well, we need stuff that juju can interpret -- the name comes from the map key, but we want a description; we'll need a field defining the target (service/unit) even if that's implicitly unit for now; probably we'll want something else at some point, eg is it valid to run it in an error state, etc etc
<fwereade> bodie_, then we need another field containing the jsonschema stuff that we use to validate the payload when the action actually gets queued/run
<bodie_> interesting
<bodie_> so almost like a schema with an args sub-schema
<bodie_> the top-level schema being the one WE perform checks against
<fwereade> bodie_, http://paste.ubuntu.com/7472971/
<fwereade> bodie_, yeah, exactly
<bodie_> fwereade, to play Devil's advocate, it seems to me like we want to give charmers that ability as a "manual" mode as it were, where we assume defaults if the top-level keys don't match a set we check for
<bodie_> a more permissive spec could still enable the functionality you're describing while not enforcing a strict format
<fwereade> bodie_, well, we still need a reliable place to add our own fields, right?
<fwereade> bodie_, what are you envisioning? just a top-level dict of name to schema?
<bodie_> for actions.yaml or for Charm's Actions?
<fwereade> bodie_, what's the distinction between the two? actions.yaml is a serialisation format for a charm's actions definition
<fwereade> bodie_, but I guess I'm talking about actions.yaml
<fwereade> bodie_, I'm just not really considering a hard separation between the charm representation and the in-memory one
<fwereade> bodie_, they won't look exactly the same, that's what our reading code will handle
<bodie_> I see, what you were saying about having a sub-spec got me thinking that perhaps if there's no encapsulating spec in the user's actions.yaml, we have a default map in the memory representation, something like {actions: {spec: {...}, version: {...}, ...}}
<bodie_> i.e. if the user doesn't match our schema, we just dump his or her schema into the "spec" subkey of our actions dict
<fwereade> bodie_, I think we can ignore extra keys for forward compatibility's sake, but we really want to be storing it as a type
<fwereade> bodie_, type Actions struct { Actions map[string]Action }
<fwereade> bodie_, type Action struct { Name string; Description string; Schema map[string]interface{} }
<fwereade> bodie_, sort of thing
<fwereade> bodie_, am I making sense? would a hangout help?
<bodie_> it's a little crazy here right now, michelle just discovered we have a small ant infestation.  I need to process for a minute...
<perrito666> bodie_: ouch, buy a ton of ant gel, that usually works charms
<wwitzel3> yeah, the gel works nicely because they take it back with them
<bodie_> we had awesome results at my old place with this chalk that kills them if they cross it
<bodie_> it's got to be a high-grade neurotoxin, I'm sure, probably wreaking havoc on my DNA
<bodie_> bet you there's a super easy way to do it
<bodie_> woops, wrong channel
<natefinch> bodie_: we're having an ant problem here, too, I can sympathize
<bodie_> let's see
<bodie_> I've heard there's basically one massive hive that extends from Mexico to Canada
<bodie_> haven't seen them like that back East
<bodie_> that was mortal combat....
<bodie_> fwereade, you're making sense but I was under the impression we should be parsing and storing the info more as a schemaless blob
<bodie_> that perhaps the way we'd been doing it (parsing out a spec for each action) was too restrictive and we simply were to let the charmer define the schema according to his or her preference
<bodie_> so, I'm continuing to have a really hard time understanding which way is preferable (blob versus more detailed parsed map)
<bodie_> it's very challenging to make progress on this when I feel both ways are nixed in favor of the opposite... heh
<natefinch> bodie_: I had thought the blob was better, but I forgot about the GUI - we need to be able to support people setting values in there without having to type out json in a big text field
<bodie_> but I want to understand the reasoning and goals so I can move forward
<bodie_> yes -- which means that shouldn't the Charm's Actions map be a valid JSON-schema and perhaps not more?
<fwereade> bodie_, but we need metadata that juju can interpret cleanly
<fwereade> bodie_, and expose parts of it to the user
<fwereade> bodie_, users will need a rough description of what a given action will do
<fwereade> bodie_, and juju itself will need to know what the action's target is
<bodie_> I'm getting this tattooed on my arm....  ;)
<bodie_> OK, that makes good sense
<fwereade> bodie_, actions.yaml itself thus needs to have the data that we (or our users) need in some standard format so we can find it and use it
<fwereade> bodie_, and even the params schema itself has structure, it's just that we can hand over the interpretation of that part of the structure to gojsonschema
<fwereade> bodie_, of the parts that we need to interpret, we don't want to just store a map unless we really have to -- an actual struct with typed fields is far preferable for our own use in code
<bodie_> yes, that also makes sense
<fwereade> bodie_, of the parts that gojsonschema needs to interpret, a map[string]interface{} is a format that goes well with gojsonschema
<perrito666> hey agent/mongo/mongo.go has a noauthCommand that is not tested nor used anywere anybody knows what it does? (running blame now)
<perrito666> ahh it is used sorry
<perrito666> I missgreped
<perrito666> :p
<bodie_> fwereade, my question then is whether we want to enforce that {{metadata}, {actions}} form as the expectation for the charmer's actions.yaml
<bodie_> or whether something that doesn't conform should instead be assumed to be the {actions} bit
<fwereade> bodie_, I think that if an actions.yaml exists, but it doesn't conform to our expectations, we reject the whole charm as invalid
<fwereade> bodie_, and that applies also to the jsonschema bits -- if it's not a valid json-schema, the file is not valid and so the charm is not valid
<bodie_> (fwereade++)++
<voidspace> hah, all my canonistack instances have "disappeared"
<voidspace> that's why juju status was hanging
<voidspace> natefinch: now you're just being *too smart* :-)
<wwitzel3> voidspace: ship it
<voidspace> wwitzel3: hah, it shipped itself
<natefinch> voidspace: heh
<voidspace> somewhere else
<voidspace> I still have moonstone standup in the calendar twice
<natefinch> voidspace: you have to delete the one off your personal calendar yourself
<voidspace> natefinch: ah right
<voidspace> natefinch: in which case I don't care
<natefinch> fwereade: There's a card about a dead state machine that is replaces by ensure availability, if that machine comes back to life, it should have no vote and no API.   I get the no vote part, but I'm not sure why we'd need to remove the API.
<natefinch> fwereade: Seems like running an API is independent of your vote status... and there's very little drawback to having more API servers.
<fwereade> natefinch, mainly just because we don't have a model-level distinction between state server and api server, and until we can express that in the model I think we'll have problems
<fwereade> natefinch, I'm +1 on allowing more api servers in the fullness of time but I don't thin kwe're there yet
<natefinch> fwereade: that's cool
<natefinch> fwereade: makes sense... no need for a state server in some weird in between state
<fwereade> natefinch, yeah, exactly
<fwereade> natefinch, we did at one stage draw the distinction, but since it was a distinction without a difference people drew all sorts of random inferences and removing it was a win
<perrito666> man, these hangouts really overheat my computer
<jcw4> fwereade: 2 quick questions if you haven't started the weekend yet :)
<fwereade> jcw4, sure :)
<jcw4> 1) we're moving AddAction to the Unit ... but I think the collection stays where it is on state
<jcw4> and unit just finds it using prefix
<fwereade> jcw4, yep
<jcw4> 2) in cleanup, I can cleanup all actions with the Dead unit prefix in one Txn right in the cleanup method
<jcw4> no need to call some method on Unit for each Action
<jcw4> make sense?
<natefinch> mattyw: sorry, ended up doing a bunch of other stuff, but on the up side, I think I found something bite sized for you and domas to work on, if you wanted to try pairing on a problem.
<jcw4> fwereade: sort of how the cleanup of relations is working
<jcw4> obviously not exactly the same
<fwereade> jcw4, yeah, agreed
<jcw4> fwereade: cool. tx
<fwereade> jcw4, so long as we assert the unit is not dead on action-add, we can be sure that no additional ones can be created after the cleanup was scheulded
<jcw4> fwereade: +1
<mattyw> natefinch, sorry - only just saw your message - go ahead
<mattyw> natefinch, have I lost you again?
<jam> fwereade: for Use RegisterStandardFacade, a thought occurs to me. We could still track the exact type being returned, and do introspection on it early
<jam> we change Register to require a reflect.Type object along with the factory
<jam> and RegisterStandardFacade pulls that out of the appropriate slot.
<perrito666> mattyw: iirc, he was leaving for a moment but returning
<jam> That would let us determine all methods that are exposed in the API without having to construct them
 * jam goes to take his son to bed
<perrito666> mattyw: I can give you the headstart on what was the task
<mattyw> perrito666, ok great
<perrito666> mattyw: iirc, we said that, there would be benefit in obtaining a better output from ensure-availability, wwitzel3 correct me if I am wrong
<mattyw> perrito666, better output?
<perrito666> mattyw: mm, let me explain this
<perrito666> but first, I need to restart my router
<natefinch> mattyw: sorry... back again
<mattyw> natefinch, no problem
<natefinch> mattyw: there's a command ensure-availability which sets up HA for the state servers, making sure you have at least the number of state servers available specified (for example  juju ensure-availability -n 3).  Right now the command ends with no output, and the API doesn't return anything useful.
<natefinch> mattyw: we want the api and the command line to output the actions that were taken as a result of the command (for example, added machine 5, added machine 6)
<mattyw> natefinch, the only parts of core I've spent an time with have been the commands and api so it sounds like a something I would be able to do
<natefinch> mattyw: ahh, that works out
<mattyw> natefinch, it's nearly my eod but I'll start work on it on monday
<natefinch> mattyw: cool, I'll try to write up some more about it and send in email.  Thanks again for the help.
<mattyw> natefinch, no problem, our standups are at the same time as yours, but I'll try to pop along to yours on monday if I've made some progress
<natefinch> mattyw: ok
<mattyw> natefinch, if you can send more in an email as well that would be great
<natefinch> mattyw: will do
<perrito666> mattyw: well natefinch did explain that much better than I
<voidspace> right, EOW
<voidspace> see you all on Monday
<perrito666> mm, a proper markup would have been EOD, EOW
<perrito666> :p
<dannf> trying to get juju to bootstrap a really slow (simulated) system. i increased timeouts in various places, but now its timing out setting up mongo:
<dannf> 2014-05-16 19:07:08 ERROR juju.cmd supercommand.go:304 can't dial mongo to initiate replicaset: no reachable servers
<dannf> i tried bumping up mongoSocketTimeout and defaultDialTimeout, but that doesn't seem to give it any extra patience
<natefinch> dannf: There's a 10 minute connection timeout that is hard coded in the code (which we actually want to fix, but haven't gotten to).  That's probably the problem.
<dannf> natefinch: yeah - i'm hacking the code, so i can do a test build. i up'd both mongoSocketTimeout and defaultDialTimeout - is this a different one?
<dannf> right now i'm trying setting FastFail to false in the dials struct to see if that helps
<dannf> its timing out faster than 10minutes
<natefinch> dannf: ahh, hmm, if it's faster than 10 minutes then I'm not sure
<dannf> http://paste.ubuntu.com/7474646/
<dannf> it does fail in about 10 minutes - but seems like it stopped retrying before then
<natefinch> dannf: I know we've had a mystery 10 minute timeout that we haven't been able to figure out before, this seems like it's hitting the same problem.
<natefinch> dannf: you're welcome to create a bug for it, I think it would be helpful to have a way to track the problem (or I can make one if you prefer)
<dannf> natefinch: ack; yeah, i'll create one
#juju-dev 2014-05-17
<bodie_> hrm
<rick_h_> hrm?
<bodie_> I keep getting this when I lbox propose
<bodie_> http://paste.ubuntu.com/7475867/
<bodie_> but, bzr push has been working fine
<rick_h_> code hosting had a notice of going down today
<rick_h_> https://twitter.com/launchpadstatus
<rick_h_> just guessing
<bodie_> well, that would explain that :)
<bodie_> yep, bzr push isn't working any more either
<rick_h_> yea, maint windows ftw
<bodie_> anywho, got a charm/actions MR up :)
<rick_h_> how goes?
<bodie_> this one's just a little more conservative ;)
<rick_h_> I like small bite sized chunks :)
<fwereade> bodie_, https://codereview.appspot.com/94540044/ reviewed
<bodie_> thankye sir
<fwereade> bodie_, I've got some friends coming round imminently so I might have to drop at short notice, but I'm here to chat for now if you want
<bodie_> cool!  I thought of a few changes I wanted to make last night at an ungodly hour..  looking over this.  I may be on more reliably in 5-7 hours
<fwereade> bodie_, cool, I might be too -- they've just arrived
<fwereade> bodie_, I'll try to pass by
<fwereade> bodie_, I will probably have been drinking slowly but steadily in the interim, though, so apologies in advance ;p
<bodie_> enjoy!
#juju-dev 2014-05-18
<thumper> morning people
<rick_h_> morning thumper
<thumper> rick_h_: oh hai
<thumper> rick_h_: sunday night and you can't think of anything else to do than work?
<rick_h_> heh, actually trying to sync up with my GSoC student and looking at 802.11ac routers for home
<rick_h_> have to rework my network rack to accomidate my nuc/switch maas setup :)
<thumper> :)
<rick_h_> thumper: https://www.dropbox.com/s/olxqxufe5r5do12/2014-05-18%2017.55.22.jpg
<thumper> rick_h_: that looks somewhat chaotic
<rick_h_> yea, I need to tear it down, redo the zip ties and such
<thumper> sure
<thumper> davecheney: ugh, I'll poke the bot unless you have already
<thumper> someone should so fix godeps so it pulls
<thumper> or at least can pull
<menn0> review please: https://codereview.appspot.com/93480044/
<waigani> wallyworld: ping
#juju-dev 2015-05-11
<menn0> wallyworld: can you make this PR merge please? https://github.com/juju/juju/pull/2239
<menn0> wallyworld: I think I aborted a previous build attempt in Jenkins on Friday b/c I realised it wasn't going to work
<menn0> wallyworld: so now the landing bot is confused.
<wallyworld> sure
<wallyworld> menn0: i have resubmitted it to the bot - you just have to record a build failed message in the PR for the bot to realise it needs to process it again
<menn0> wallyworld: ok thanks
<wallyworld> menn0: except it failed again
<wallyworld> i didn't look at the reason
<menn0> wallyworld: just looking now
<axw> wallyworld: teensy review please: http://reviews.vapour.ws/r/1384/
<wallyworld> sure
<wallyworld> axw: i'd just self review one as small as that
<axw> wallyworld: ok
<thumper> wallyworld: did you have any time in the next hour for a catch up? since I missed Friday
<thumper> menn0: has wallyworld suitably kicked the bot?
<wallyworld> thumper: sure, i was waiting for you and you ditched me
<thumper> sorry, was out Friday morning
<wallyworld> was just pressing your buttons
<thumper> and I have so many to press
<wallyworld> indeed
<thumper> wallyworld: I'm in our 1:1 hangout
<wallyworld> ok, one sec
<menn0> thumper: yep he did
<mup> Bug #1453634 was opened: juju upgrage-juju --upload-tools hangs <ec2-provider> <upload-tools> <juju-core:Triaged> <https://launchpad.net/bugs/1453634>
<mup> Bug #1453634 changed: juju upgrage-juju --upload-tools hangs <ec2-provider> <upload-tools> <juju-core:Triaged> <https://launchpad.net/bugs/1453634>
<mup> Bug #1453634 was opened: juju upgrage-juju --upload-tools hangs <ec2-provider> <upload-tools> <juju-core:Triaged> <https://launchpad.net/bugs/1453634>
<waigani> axw: does upgrade also work for 1.25 for you?
<axw> waigani: haven't tried
<waigani> axw: I'm debugging with 1.25 now. Any chance you could try on your box?
<axw> waigani: ok
<waigani> axw: thanks. I've tried about 4 times in a row now. same issue each time. I can ssh to machine 0, debug-log works, but it always hangs on upgrade-juju --upload-tools
<axw> waigani: it did take a long time to upload the tools, but it always does for me
<axw> anyway, trying with master now
<axw> waigani: have you tried with 1.22 or 1.23? that should tell you if it's a regression, or if it's just your network
<waigani> axw: I'll try 1.23 now.
<waigani> axw: 1.23 works fine for me
<axw> hmk, strange
<axw> waigani: open it back up with that then I guess. master is still bootstrapping for me ..
<waigani> axw: though if it is my network, maybe it's better now. I'll test 1.23 one more time and wait to see what 1.25 does for you.
<axw> waigani: master works for me too
<waigani> axw: really? then it's me :/
<waigani> axw: looks like 1.23 is hanging. It hangs after tools are uploaded (i.e. after it reports "available tools:...").
<axw> waigani: you said it worked fine before?
<mup> Bug #1453644 was opened: One unit remains pending with local provider <juju-core:New> <https://launchpad.net/bugs/1453644>
<waigani> axw: I'll dig a little more, but as it's only on my box I'll knock down the importance. Thanks for testing 1.25.
<axw> sure
<waigani> ha
<anastasiamac> waigani: did u have a "eureka" moment?
<anastasiamac> waigani: or is it" high availability" moment?
<waigani> hehe
<waigani> so I had export JUJU_DEV_FEATURE_FLAGS=jes in my .bashrc
<waigani> when I tried 1.23 the first time, it was in an old terminal window that hadn't sourced .bashrc
<waigani> when I commented out the export and tried the upgrade, it worked
<waigani> long story short, I think something hiding behind the jes flag is breaking upgrade-juju
<waigani> axw: ^^
<axw> waigani: ok. please add that to the bug, change the title, drop the severity and leave it open only on whatever branch JES is being released in
<waigani> axw: okay
<axw> wallyworld: I updated TestCreateVolume to wait for status != ""
<wallyworld> looking
<axw> wallyworld: createVolume returns with Status==""
<wallyworld> axw: i already reviewed just before
<wallyworld> i think a test is missing
<wallyworld> ah hang on
<wallyworld> i see what you're saying
<axw> wallyworld: ok to land?
<wallyworld> axw: i guess what i was looking for was that the status would be "" until the test triggered it to be not "". otherwise the old code would also have passed the test if you know what i mean. but i guess it doesn't really matter
<axw> wallyworld: I could change it to only return "available" after a couple of iterations
<axw> I'll do that
<wallyworld> axw: and record that at least one failed attempt occurred
<axw> yep
<wallyworld> that would be neat, thanks
<axw> wallyworld: although that means I need to patch the attempt strategy.. bleh
<wallyworld> if it's a hassle, ship it :-)
<wallyworld> strictly speaking, we should test for it i guess
<wallyworld> maybe a todo
<axw> wallyworld: done, landing
<wallyworld> ty
<axw> wallyworld: I think I might have a lie down, feeling a bit average
<wallyworld> :-( ok, take it easy
 * thumper chuckles
<thumper> wallyworld: and average is so far down from normal...
<thumper> damn it
<wallyworld> depends who you are
<thumper> If I stopped when I felt average, I'd never get anything done...
<wallyworld> so you feel average a lot then
<thumper> heh
<thumper> ciao
 * thumper is off
<TheMue> morning
<voidspace> dooferlad: stdup?
<voidspace> dooferlad: TheMue: I got booted out
<voidspace> dooferlad: TheMue: probably have to log back in, sorry
<mup> Bug #1453744 was opened: juju version 1.23.2-trusty-amd64  console need agent-metadata-url flag? <juju-core:New> <https://launchpad.net/bugs/1453744>
<mup> Bug #1453760 was opened: "u'Error': u'status for key "<unit>" not found" before adding relations when using juju 1.24 <juju-deployer:New> <https://launchpad.net/bugs/1453760>
<mup> Bug #1453760 changed: "u'Error': u'status for key "<unit>" not found" before adding relations when using juju 1.24 <juju-core:Triaged> <juju-core 1.24:Triaged> <juju-deployer:New> <https://launchpad.net/bugs/1453760>
<mup> Bug #1453760 was opened: "u'Error': u'status for key "<unit>" not found" before adding relations when using juju 1.24 <juju-core:Triaged> <juju-core 1.24:Triaged> <juju-deployer:New> <https://launchpad.net/bugs/1453760>
<mup> Bug #1453760 changed: "u'Error': u'status for key "<unit>" not found" before adding relations when using juju 1.24 <juju-core:Triaged> <juju-core 1.24:Triaged> <juju-deployer:New> <https://launchpad.net/bugs/1453760>
<mup> Bug #1453785 was opened: transaction collection (txns) grows without bound <stakeholder> <juju-core:Triaged> <https://launchpad.net/bugs/1453785>
<mup> Bug #1453801 was opened: /var/spool/rsyslog grows without bound <stakeholder> <juju-core:Triaged> <https://launchpad.net/bugs/1453801>
<mup> Bug #1453805 was opened: Juju takes more than 20 minutes to enable voting <ensure-availability> <intermittent-failure> <juju-core:Incomplete> <juju-core 1.23:Triaged> <juju-core 1.24:Triaged> <https://launchpad.net/bugs/1453805>
<mup> Bug #1453744 changed: juju version 1.23.2-trusty-amd64  console need agent-metadata-url flag? <juju-core:Invalid> <https://launchpad.net/bugs/1453744>
<mup> Bug #1453814 was opened: rsyslog configuration forwards log messages that were already forwarded <logging> <rsyslog> <stakeholder> <juju-core:Triaged> <https://launchpad.net/bugs/1453814>
<mup> Bug #1453744 was opened: juju version 1.23.2-trusty-amd64  console need agent-metadata-url flag? <juju-core:Invalid> <https://launchpad.net/bugs/1453744>
<mup> Bug #1453814 changed: rsyslog configuration forwards log messages that were already forwarded <logging> <rsyslog> <stakeholder> <juju-core:Triaged> <https://launchpad.net/bugs/1453814>
<mup> Bug #1453744 changed: juju version 1.23.2-trusty-amd64  console need agent-metadata-url flag? <juju-core:Invalid> <https://launchpad.net/bugs/1453744>
<mup> Bug #1453814 was opened: rsyslog configuration forwards log messages that were already forwarded <logging> <rsyslog> <stakeholder> <juju-core:Triaged> <https://launchpad.net/bugs/1453814>
<sinzui> katco`, : I need help triaging bug 1453644. I think an engineer needs to determine if we need to/can fix this bug for 1.24 or 1.25
<mup> Bug #1453644: One unit remains pending with local provider <deploy> <lxc> <reliability> <repeatability> <juju-core:New> <https://launchpad.net/bugs/1453644>
<mup> Bug #1453814 changed: rsyslog configuration forwards log messages that were already forwarded <logging> <rsyslog> <stakeholder> <juju-core:Triaged> <https://launchpad.net/bugs/1453814>
<katco`> sinzui: just in a meeting, one sec
<voidspace> alexisb: ping
<mup> Bug #1434741 changed: PruneLogs suffers from an indeterminate map iteration order bug <juju-core:Fix Released by johnweldon4> <https://launchpad.net/bugs/1434741>
<jcastro> mgz, have you tried juju with dreamhost yet?
<mgz> jcastro: no, not recently
<jcastro> do you know anyone who has tried it? I'm trying to document it for the docs but I get auth errors
<mgz> I've not seen anything on the list, I'll see if I have creds around somewhere still
<jcastro> ideally using keypairs would be lovely
<mgz> yeah, I need to re-add that code to juju-core
<jcastro> ok so it only does userpass?
<jcastro> they do give me a .pem file as well
<katco> cherylj: perrito666: wwitzel3: is anyone free to triage 1453644? lxc + CA issue of some sort. possibly a race?
<wwitzel3> katco: sure
<mgz> well, keypair should actually work... it's just not actually been exercised for ever now
<jcastro> they don't give me a keypair though
<jcastro> just a pem file with a private key in it
<katco> wwitzel3: ty. i don't think we have to actually fix it just yet, so just prioritization with some idea of what might be happening
<jcastro> is the fingerprint in horizon considered the access-key?
<mgz> I'll need to look at the dreamhost docs, I'm not sure exactly what they expect
<wwitzel3> katco: k, if it is more than a 30 minute fix after I find the problem, I'll just triage and make notes
<mgz> the only cloud keypair was ever used against was hpv1
<katco> wwitzel3: sounds good
<katco> sinzui: we're on 1453644. ty
<sinzui> thank you katco
<jcastro> http://wiki.dreamhost.com/DreamCompute_Overview this seems to be the closest I can find wrt. docs
* ChanServ changed the topic of #juju-dev to: https://juju.ubuntu.com | On-call reviewer: see calendar | Open critical bugs: 1453805
<voidspace> dammit, can't set instance ID on ip address when creating container because we don't have the instance id set until *after* the container is created
<voidspace> it needs to be set when the new machine is provisioned in state
<voidspace> slightly more fiddly
<sinzui> katco, merges are blocked by bug 1453805. I recommend reverting the bad commit, then resubmitting  that commit with a proven fix
<mup> Bug #1453805: Juju takes more than 20 minutes to enable voting <blocker> <ci> <ensure-availability> <intermittent-failure> <regression> <juju-core:Triaged> <juju-core 1.23:Triaged> <juju-core 1.24:Triaged> <https://launchpad.net/bugs/1453805>
<katco> sinzui: ty. it looks like at least on master, there's a lot of PRs on top of that commit. i don't know how easy it would be to back out
<sinzui> katco, :/ well starting with 1.24 might be most practical. If I need to release 1.23, I can use the previous commit, and 1.23.3 is intended to be our final release for 1.23
<katco> sinzui: even on 1.24, there's a page of prs after that pr =/
<katco> sinzui: wondering why we landed a refactoring pr in something we're trying to release
<sinzui> katco, great point.
<katco> sinzui: it looks like it did fix a bug
<katco> sinzui: hmmm... it may be more practical to try and fix the issue at this point
<katco> cherylj: ping
<sinzui> katco, I think we were clobbered by optimism. looking at the times of the commits. I think 1.24 and master were committed to before CI to demonstrate the fix was good
<katco> sinzui: ah i see
<cherylj> katco: what up
<katco> cherylj: we have a blocking bug that looks like it involves some of menn0's code
<katco> cherylj: bug 1453805
<mup> Bug #1453805: Juju takes more than 20 minutes to enable voting <blocker> <ci> <ensure-availability> <intermittent-failure> <regression> <juju-core:Triaged> <juju-core 1.23:Triaged> <juju-core 1.24:Triaged> <https://launchpad.net/bugs/1453805>
<katco> cherylj: sinzui has suggested we back it out, but from the # of prs that came after, it looks like that may be difficult
<katco> cherylj: in any branch
<katco> cherylj: wondering how hard it would be to find the issue and fix it?
<cherylj> katco: guess we won't know 'til we try :)  I can take a look
<katco> cherylj: ty
<perrito666> katco: you could try to apply a reverse patch and see if everything works afterwards, it is the easiest path
<katco> perrito666: feel free to ping cherylj and see if that works
<perrito666> ah seems like cherylj is taking a look
<perrito666> :p I should refrain from commenting until I read the whole backlog
<katco> perrito666: nah, valuable info! :)
<cherylj> perrito666: how do you apply a reverse patch?
<perrito666> first you get the patch the easy way
<perrito666> https://github.com/juju/juju/commit/c8c41b048df0e038b75c353856d021080713408f.diff
<perrito666> adding .diff to the commit in gh :p
<perrito666> bc I am lazy to do it otterwise
<perrito666> and then patch -R -p1 < thatdiff.diff
<perrito666> and that un applies the changes
<perrito666> in an easy to test way that doesn t mess that much with git change tree
<perrito666> that .diff thing in github is so useful, its a shame its not documented more clearly
<cherylj> perrito666: okay, let me give that a try.  Thanks!
<mup> Bug #1453890 was opened: Bootstrap fails if aws feigns ignorance of an instance <bootstrap> <ec2-provider> <juju-core:Triaged> <https://launchpad.net/bugs/1453890>
<cherylj> katco, perrito666: http://reviews.vapour.ws/r/1645/
<cherylj> I used patch -R to back out menn0's changes for 1.23
<cherylj> local testing passed fine.
<urulama_> perrito666: hey, just fyi, you're lending code in charm.v6-unstable. if that's your intention all is fine, just wanted to point out that you're not adding it to charm.v5.
<perrito666> urulama_: I did two prs, one for 5 and one for 6
<urulama_> perrito666: ok. in the end, we'll have to merge new stuff from v5 to v6 anyway
<perrito666> urulama_: just trying to be consistent :)
<perrito666> I want to avoid breakage when we go from 5 to 6 in master
<urulama_> perrito666: ;)
<perrito666> urulama_: I assume merge is by hand right?
<urulama_> perrito666: for charm, yes
<mup> Bug #1452785 changed: os-enable-refresh-update is false and some security packages are not available <juju-core:Invalid> <https://launchpad.net/bugs/1452785>
<sinzui> natefinch, katco: do either of you have a moment to review http://reviews.vapour.ws/dashboard/?view=outgoing
<sinzui> sorry http://reviews.vapour.ws/r/1648/
<katco> sinzui: natefinch is occupied, i can tal in a bit
<natefinch> I looked because I know his changes are usually 2 characters :)
<natefinch> ship it!
<katco> ah lol
<sinzui> thank you.
<mup> Bug #1452796 was opened: template download failed <juju-core:New> <https://launchpad.net/bugs/1452796>
<thumper> mramm: our call now clashes with the onyx standup
<thumper> mramm: are you ok to push it out half an hour?
<alexisb> thumper, mramm is out this afternoon
<davecheney> thumper: % tail -n2 /etc/hosts
<davecheney> # 127.0.0.100   cloud-images.ubuntu.com
<thumper> ta
<wallyworld> menn0: you are that fix for bug 1453805 has been backed out?
<mup> Bug #1453805: Juju takes more than 20 minutes to enable voting <blocker> <ci> <ensure-availability> <intermittent-failure> <regression> <juju-core:Triaged by cherylj> <juju-core 1.23:Triaged by cherylj> <juju-core 1.24:Triaged by cherylj> <https://launchpad.net/bugs/1453805>
<cherylj> wallyworld: menn0 and I are looking at it now
<wallyworld> thatnks cherylj
<cherylj> wallyworld: chatted with menn0 and he found the problem.  He's going to work on a fix rather than back out his changes.
<wallyworld> \o/
<wallyworld> sinzui: if you comment on the mongo log bug, i think you could move it off to 1.25 milestone at the same time?
<sinzui> wallyworld, yep. debian doesn't have 2.8. So if we need it or newer, we need to add  a task asking for it to be packages into wily and then discuss backporting schemes to trusty as jujudb
<wallyworld> sounds like a lot of "fun"
<wallyworld> sinzui: if we start the process now, it might be early enough in W to get traction on it?
<sinzui> agreed
<alexisb> xwwt, ^^^ we should follow-up with foundations on this
<wallyworld> sinzui: so i reckon if we move to 1.25, then maybe we can have a chance of getting something done by the nominal 1.25 release date
<sinzui> okay wallyworld
<wallyworld> well that's my hope :-)
<perrito666> wallyworld: axw anastasiamac_ brt, melting some chocolate
<wallyworld> perrito666: where's ours
<thumper> menn0: what's the story with the replicaset problem?
<menn0> thumper: it's my fault. the replicaset init changes don't work for new state servers added for ensure-availability
<menn0> thumper: i'm just trying out a likely fix now on EC2
<thumper> menn0: ok
#juju-dev 2015-05-12
<davecheney> great, now my ppc64 machines are offline
<davecheney> thumper: http://paste.ubuntu.com/11087681/
<davecheney> what is this test trying to test ?
<davecheney> what should be listening on port 19034
<natefinch> katco: you still around?
<natefinch> davecheney: I'd like your insight on a review comment.  I have a struct that implements an interface from the same package. The struct has no exported methods other than the ones on the interface, and no exported data fields.  I have a constructor function for the struct... I had made the struct non-exported and had the constructor just return the interface. I was given a review comment that returning an interface is an an
<natefinch> tipattern, and to just have it return the concrete value.  I had made it return the interface to keep the package's API smaller.  What are your thoughts?
<davecheney> natefinch: link to review ?
<natefinch> davecheney: http://reviews.vapour.ws/r/1619/
 * davecheney looks
<natefinch> I converted cmd/jujud/agent/AgentConf from a struct to an interface to make it testable... I don't necessarily like making an interface just to make something testable, but it seemed like the most reasonable solution.
<natefinch> davecheney: the relevant changes are from revision 1 to revision 2
<davecheney> kk
<thumper> davecheney: looking now
<menn0> wallyworld, thumper: update on the CI blocker. I have a working fix that I've manually tested in a variety of bootstrap, upgrade and HA scenarios.
<menn0> wallyworld, thumper: tests need updating though and that'll take a while
<thumper> menn0: ETA?
<menn0> thumper: no idea. anywhere from 30 to 90 mins?
<thumper> menn0: ack
 * natefinch thinks he has a different definition than menn0 has of what "no idea" means.
<menn0> natefinch: :)
<natefinch> :)
<mwhudson> somewhere between a femtosecond and a millenium
<natefinch> now that's more like it.
<davecheney> thumper: any idea what is going on there ?
<thumper> davecheney: sorry, there wasn't quite enough context
<thumper> davecheney: which test?
<thumper> davecheney: the proxy detection was probably part of the auto-proxy detection
<thumper> but the error I'm guessing would be the test trying to get to cdimages
<thumper> no?
<natefinch> davecheney: any thoughts on that review?  No big deal if you don't have time, just wanted anything you had off the top of your head.
<davecheney> thumper: http://paste.ubuntu.com/11087681/
<menn0> wallyworld, thumper: here's the blocker fix for 1.23. http://reviews.vapour.ws/r/1654/
<davecheney> what is this test looking for on port 19034 ?
<wallyworld> looking
<thumper> davecheney: likely to be the random port number assigned to either mongo or the api server
<davecheney> not random
<davecheney> happens over and over again
<thumper> hmm..
<davecheney> all the way through the test
<davecheney> all the way through the test suite
<thumper> /home/tim/go/src/github.com/juju/juju/testing/environ.go:
<thumper>    52: 		"state-port":                19034,
<davecheney> so the state server didn't start up ?
 * thumper shrugs...
<thumper> maybe
<davecheney> righto
<davecheney> thanks
<thumper> davecheney: or...
<davecheney> hang on
<thumper> davecheney: the test isn't a mgo suite so no mongo started, but the code is expecting it to be started?
<davecheney> if that port isn't random
<davecheney> and two tests using that suite run at the same time ...
<davecheney> they'll fight over the port
<thumper> ack
<davecheney> how the f did this ever work ?
<thumper> I didn't think we ran things in parallel
<davecheney> go test github.com/juju/juju/...
<thumper> don't we compile in parallel, but run in serial?
<davecheney> ^ will run n cores of tests concurrently
<thumper> not sure that is how gocheck works
<davecheney> gocheck is a test
<wallyworld> menn0: lgtm, a question about var name
<davecheney> but each packge is it's own test runner
<davecheney> and up to n cores of them will be running at any time
<thumper> davecheney: I thought that for most of the tests, we used random port assignment
<thumper> davecheney: and the fixed numbers were only used for static checks
<davecheney> indeed
<thumper> but perhaps I'm wrong
<davecheney> maybe this suite is only used by one provider
<davecheney> the local provider tests
<thumper> I have certainly run tests in parallel before
<thumper> in multiple terminals
<menn0> wallyworld: yeah, I might call it needReplicasetInit and change the sense. good call.
<davecheney> if you pass multiple packages to go test
<davecheney> they will be run in parallel
<thumper> ah fark
<thumper> adding lxd ppa brought in golang 1.3.3
<thumper> my build .a files are now all fubared
 * thumper goes to delete stuff
<thumper> ...
<thumper> why is rm -r pkg not working?
 * thumper is going crazy
<thumper> davecheney: sanity check plz
<thumper> damn it
 * thumper reboots
<bradm> anyone about?  I'm seeing weird errors from a juju bootstrap
<bradm> WARNING juju.replicaset replicaset.go:87 Initiate: fetching replication status failed: cannot get replica set status: can't get local.system.replset config from self or any seed (EMPTYCONFIG)
<davecheney> natefinch: i read that review twice
<davecheney> are you testing AgentConf ? or the thing that consumes AgentConf ?
<natefinch> davecheney: the thing that consumes it
<natefinch> davecheney: which is why I wanted to make it an interface so that I could mock out its behavior
<davecheney> in that case, I agree
<natefinch> that returning the interface is ok?
<davecheney> although dogmatic, it seems like a good rule of thumb that functions should return concrete types and consume interfaces
<natefinch> oh, ok
<natefinch> I'm cool with that
<davecheney> and consuming an interface gives you heaps of flexibilty to control the _outputs_ of that interface
<davecheney> so i think this change is good
<davecheney> but i am reminded of this quote
<davecheney> Donât be trapped by dogma â which is living with the results of other peopleâs thinking.
<bradm> ah, LP#1412621 and LP#1441913 seems similar-ish.
<_thumper_> davecheney: got a minute? I have an x509 cert question, and I found your name in the source :)
 * thumper stabs x509 and asn.1 in the face
 * thumper goes to make coffee
 * thumper guesses davecheney is having lunch
<menn0> wallyworld: trying to merge this CI blocker but so far i've had good ol' "bad record mac" and EC2 failures
<wallyworld> ffs
<thumper> :(
<menn0> bad record MAC happens so often
<wallyworld> fixed in 2.6, we need to get off 2.4
 * thumper nods
<wallyworld> thumper: menn0: we need to get onto 2.8+ to get rid of the noisy logs, but W only has 2.6 so there's a packaging process that has to be followed
 * thumper grunts
<davecheney> thumper: i'm just off for lunch
<davecheney> what line ?
<davecheney> this was probabl somethig about the ASN.1 decoding
<thumper> wallyworld: we need some packaging monkey at our beck and call
<wallyworld> yes we do
<thumper> davecheney: I have a cert pool, and I get the subjects out
<thumper> davecheney: I was wanting some meaningful decoding for the test
<thumper> davecheney: but asn1.Unmarshall with a pkix.Name fails
<thumper> when I assumed it would work
<thumper> given that it is what is passed in to the cert
<davecheney> what's the error
<thumper> asn1.StructuralError{Msg:"tags don't match (16 vs {class:0 tag:17 length:13 isCompound:true}) {optional:false explicit:false application:false defaultValue:<nil> tag:<nil> stringType:0 set:false omitEmpty:false}  @2"}
<davecheney> urgh, it's been 4 years since I left that comment turd
<thumper> asn1 marshalling looks a bit ick
<davecheney> yueah, there are lots of non obivious differences between a stirng
<davecheney> a mature string (or seomthing)
<thumper> looking at the raw bytes, it looks like it definitely has the Org and CN
<davecheney> an empty string
<davecheney> a raw string
<davecheney> a set of raw bytes
<davecheney> etc
<davecheney> none of them map cleanly on to the string "tim"
<davecheney> 16	SEQUENCE, SEQUENCE OF
<davecheney> 17	SET, SET OF
<davecheney> map vs [] i'd say
<davecheney> whatever you're doing now
<davecheney> do the opposite
<thumper> davecheney: ugh... I'm using pxik.Name which uses []string for members
<davecheney> nfi sorry
<davecheney> it's been 4 years
<davecheney> and I think I only fixed it enogh last time to decode some SNMP records
<thumper> hmm... for the test, the CN would be fine
<thumper> perhaps I should just define a struct that uses just that...
<thumper> davecheney: don't stress, I'm just kinda gunna ignore it
<thumper> and assume if the loading of the pool worked, a count of certs should be fine
<menn0> wallyworld: while testing upgrades of HA envs (1.20 to 1.23 on EC2) I ran into a failure of the "migrate tools into environment storage" upgrade step
<menn0> wallyworld: something about an invalid URL
<wallyworld> oh joy
<wallyworld> got an error message?
<menn0> pgrade step "migrate tools into environment storage" failed: cannot find tools in provider storage: cannot read product data, invalid URL "https://s3-us-west-2.amazonaws.com/46494ee31f7046468790ca9b1ac37795/tools/streams/v1/com.ubuntu.juju:released:tools.json?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAI3NTF6NNI5343APQ%2F20150512%2Fus-west-2%2Fs3%2Faws4_request&X-Amz-Date=20150512T040240Z&X-Amz-Expires=604800&X-Amz-Signature=3
<menn0> 131f68ef4919a36267d56a20490b4746208423247196fbac578dc637d370144&X-Amz-SignedHeaders=host" not found
<wallyworld> menn0: i *think* we have now switched to V4 auth for S3, perhaps there's an issue in that region or something
<menn0> wallyworld: file a bug?
<wallyworld> hmmm, i think i truncated to url, fixing that gave a sig mismatch which i think might be expected if i just cut and paste
<wallyworld> but it could also be a real issue
<wallyworld> did it happen all the time?
<wallyworld> or just the once?
<menn0> i've only tried this particular upgrade (1.20 to 1.23) once
<wallyworld> aws does not always work all the time
<wallyworld> CI needs to often retry
<menn0> wallyworld: but there were a bunch of attempts to hit that URL and they all failed
<wallyworld> sometimes though there are cloud outages
<wallyworld> i can't see offhand where any juju bug would be
<menn0> wallyworld: ok it could be that
<wallyworld> the url looks correct
<menn0> wallyworld: the upgrade retried 5 times and has now given up
<wallyworld> not sure what to do - juju is asking S3 for a file and S3 says f*ck off
<menn0> wallyworld: so we hit that URL something like 50 times over 10 minutes and it didn't work
<wallyworld> hmmmm, NFi offhand
<wallyworld> menn0: if i try the url without the auth stuff i get a weird redirect from aws. not sure if that's relevant but i've not seen that before
<menn0> wallyworld: here's the full correct URL
<menn0> https://s3-us-west-2.amazonaws.com/46494ee31f7046468790ca9b1ac37795/tools/streams/v1/com.ubuntu.juju:released:tools.json?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAI3NTF6NNI5343APQ%2F20150512%2Fus-west-2%2Fs3%2Faws4_request&X-Amz-Date=20150512T043517Z&X-Amz-Expires=604800&X-Amz-Signature=3754e068be3d7588022c5ed7d485fff4f3c2df1fd917ed12c29fa7bd9a430a12&X-Amz-SignedHeaders=host
<menn0> wallyworld: the error is about signing: The request signature we calculated does not match the signature you provided. Check your key and signing method.
<wallyworld> yes, but i've seen that will url pastes before
<menn0> wallyworld: ok right
<wallyworld> it may be relevant here but i can't be sure off hand
<menn0> wallyworld: i've just searched the logs and I see the same error there
<wallyworld> i wonder if you specified an explicit region would it work
<wallyworld> hmmm, maybe that region is having issues with V4
<thumper> menn0: it merged \o/
<menn0> thumper: thank $deity for that
<thumper> menn0: I think $deity should be Odin
<thumper> was always partial to Norse
<menn0> thumper: that fits you so well
<menn0> getting the 1.24 and master merges ready now
<thumper> menn0: although perhaps it should be Loki as he was god of mischief, and that fits the intermittent nature better I think
<menn0> thumper:  ha :)
<mup> Bug #1454043 was opened: Machine.SetAddresses should not generate transactions for noop changes <stakeholder> <juju-core:Triaged> <https://launchpad.net/bugs/1454043>
<anastasiamac_> thumper: if we r voting, i'd say Odin
<anastasiamac_> thumper: Odin's "special" warriors were berserkers
<thumper> davecheney: remember this 10 minute go test timeout thing...
<thumper> davecheney: are you sure that `go test -test.timeout=1200s ` doesn't increase that to 20 minutes?
<menn0> wallyworld, thumper: the fix for the CI blocker is now merged into 1.23, 1.24 and master
<wallyworld> huzah
<menn0> wallyworld: CI hasn't run the functional-ha-backup-restore job with the new code yet
<wallyworld> yeah, have to wait to unblock
<menn0> wallyworld: i'll add a note to the ticket to make it clear when it can be unblocked
<wallyworld> sounds good, ty
<thumper> menn0: hoo ray
<jam> axw: ping
<mup> Bug #1454059 was opened: SetTools fills up transaction log <stakeholder> <juju-core:Triaged> <https://launchpad.net/bugs/1454059>
<jam> TheMue: ping
<TheMue> morning
<TheMue> jam: pong
<jam> hi TheMue just looking for someone from the team. We found a bug in the instance poller and were wondering who did the Addresses consolidation.
<jam> dimiter might be more knowledgeable if he's around today
<TheMue> jam: yeah, but he's out until thursday
<TheMue> jam: Address poller? hmm, could you tell me more about it?
<jam> TheMue: basic bug is https://bugs.launchpad.net/juju-core/+bug/1454043
<mup> Bug #1454043: Machine.SetAddresses should not generate transactions for noop changes <stakeholder> <juju-core:Triaged> <https://launchpad.net/bugs/1454043>
<jam> TheMue: essentially the InstancePoller is doing a check
<jam> If machine.Addresses() != cloud.Addresses() { machine.SetAddresses(cloud.Addresses))
<jam> TheMue: however, machine.Addresses() merges "machine" addresses with "cloud" addresses
<jam> thus once you have any machine addresses, the comparison *always* fails.
<TheMue> iiirks
<jam> TheMue: essentially SetAddress() && Addresses() gives you a different value
<jam> which isn't a great API internally :)
<TheMue> hmmm, will be hard to disagree ;)
<voidspace> morning all
<TheMue> voidspace: heya
 * TheMue is taking a deeper look
<mattyw> voidspace, morning
<mattyw> voidspace, you did work on the networking stuff right?
<voidspace> TheMue: o/
<voidspace> mattyw: uhm... yes...
<mattyw> voidspace, I've not really started looking at it - so be prepared for a totally daft question....
<voidspace> mattyw: back in a minute, ask the question and I'll answer
<mattyw> voidspace, is it possible to move a unit from one space to another?
<voidspace> mattyw: oh
<voidspace> mattyw: units aren't "in spaces"
<voidspace> mattyw: units are on machines, machines are on networks / have interfaces - and those networks / interfaces have subnets that are in spaces
<voidspace> mattyw: you specify the space constraints at *deploy time* (so we can pick a machine0
<voidspace> mattyw: and then a unit endpoint can get an address on any subnet available to the machine
<voidspace> mattyw: that is how it *will* work  I believe
<voidspace> mattyw: not implemented yet
<mattyw> voidspace, ok understood - so I can't use networking to cause partitions in a running service (for testing purposes)
<voidspace> mattyw: but it's machines that are "in spaces", and we pick a machine for the unit based on the spaces you specify (for endpoint bindings) at deploy time
<voidspace> mattyw: not dynamically no
<mattyw> voidspace, understood
<TheMue> mattyw: as I understand it you can install a charm with a different name in a different space, but not different units of one service
<mattyw> TheMue, that makes a lot of sense
<TheMue> jam: I like your solution, always had my troubles with the mixing of both address sets.
<mup> Bug #1454143 was opened: Deployer failure upgrading to proposed 1.23.3 from 1.23.2 client <landscape> <juju-core:New> <juju-deployer:New> <https://launchpad.net/bugs/1454143>
<dooferlad> voidspace: hangout
<voidspace> dooferlad: omw
<voidspace> TheMue: dooferlad: oh, forgot to mention in standup - but last night I spent a bit of time on my HP Microserver
<TheMue> voidspace: and now, up and running?
<voidspace> TheMue: dooferlad: got the ram and HD fitted. Unfortunately failed to get an OS installed as the flash drive I made from 15.04 was corrupt
<voidspace> TheMue: dooferlad: I did find a python interface to the OneView HP RESTful API
<voidspace> * ashipika has quit (Quit: Leaving.)
<voidspace> oops...
<TheMue> hehe
<voidspace> https://github.com/HewlettPackard/python-hpOneView
<voidspace> Not clear if it supports the functionality we need - but a good place to start.
<TheMue> voidspace: could you point me with an URL to the HW?
<voidspace> TheMue: the doc by dooferlad has a link to the device on ebuyer (UK site of course)
<voidspace> https://docs.google.com/document/d/1jjw80acrwVMITCiAKI3UJ5FoZFuN9kuBcG0mtHRmMIA/edit
<voidspace> it's the G1610T HP Proliant Microserver
<TheMue> voidspace: thx
<ashipika> ?
<voidspace> ashipika: heh
<voidspace> ashipika: I managed to get the wrong thing in my copy-paste buffer...
<voidspace> ashipika: meant to post a link instead... sorry
<ashipika> voidspace: np :)
<dooferlad> voidspace, TheMue: The API spec is in that document. We only need a single endpoint: {"Action": "Reset", "ResetType": <foo>} where <foo> can be "On", "ForceOff". That is it.
<dooferlad> As long as you can find the IP address that the management interface is listening on we are fine.
<dooferlad> voidspace: you don't need to install an OS, you just need to get in the BIOS to set up network booting.
<voidspace> dooferlad: sure, but I want to make sure it works and have something to play with :-)
<voidspace> dooferlad: pretty sure it network boots by default
<voidspace> dooferlad: it's definitely looking for pxe
<wallyworld> TheMue: hey, did you see that 1.24 bug i assigned you? it appeared as if you were the last one to touch that code :-) looks like a simple fix. are you able to fix it?
<TheMue> wallyworld: not yet seen, one moment
<perrito666> morning
<TheMue> wallyworld: #1437266?
<TheMue> perrito666: heya
<wallyworld> perrito666: morning, i haven't landed the 1.24 merge into master which will bring in the charm.v5 stuff you need because 1.24 was blocked; should be unblocked soon
<perrito666> np
<wallyworld> TheMue: yeah, that's the one
<TheMue> wallyworld: ok, will do it
<TheMue> ... now
<wallyworld> \o/ ty
<voidspace> wallyworld: as you're here, quick question
<voidspace> wallyworld: when setting the instance ID on a newly provisioned machine I need to set the instance id on a bunch (potentially) of IP addresses as well
<voidspace> wallyworld: state already has a method to fetch all the IP addresses associated with the machine
<voidspace> wallyworld: after the successful transaction, ok to just call addr.SetInstanceId on them all
<voidspace> wallyworld: or is it significantly preferred that I build this in as part of the transaction (by extending []txn.Op for setting the instance id on the instanceData record)
<voidspace> ?
<wallyworld> voidspace: give me a few minutes to check, i can't recall the code 100%
<voidspace> wallyworld: well, it's mostly new code
<voidspace> wallyworld: specifically I'm looking at state.Machine.SetProvisioned
<voidspace> setting the instance id is a method call on machine, so it seems having a method to set the instance id on the addresses fits
<voidspace> but it means a few extra DB calls instead of building it into a single transaction
<wallyworld> voidspace: if the method is on state and hence talking to mongo directly, a few extra calls isn't so bad in general
<wallyworld> we do that elsewhere
<voidspace> wallyworld: well, it's on state.IPAddress which has a direct connection to state
<voidspace> wallyworld: cool, thanks
<voidspace> it's directly working with state entities, no extra layers
<wallyworld> if depends if we expect all the data to be written at once for integrity
<voidspace> hmmm... although these are cross collection anyway
<voidspace> so the transaction doesn't guarantee that I don't think
<voidspace> instanceDataC and ipaddressesC
<voidspace> IIRC
<wallyworld> yeah, cross collection txns i think can be an issue
<wallyworld> is it an issue if the instance ids are not all set at once?
<voidspace> wallyworld: nope. They're only used on machine destruction.
<voidspace> wallyworld: so unless you can set the instance id on the machine and then destroy the machine (EnsureDead *and* Remove) before they're set
<voidspace> which I'm pretty sure you can't...
<wallyworld> voidspace: i think then it sounds ok to set individually via repeated direct calls to mgo from state
<wallyworld> seing the final code would help
<voidspace> wallyworld: cool, thanks
<voidspace> wallyworld: I'll link you to the wip code to get a clearer idea.
<wallyworld> sorry i was only vague
<voidspace> hmmm... problem as always is what to do with the error
<voidspace> if setting the id on an address fails *after* the transaction succeeds returning an error will make it look like setting the instance id failed
<voidspace> maybe better to do it in the transaction so we get a single failure
<voidspace> slightly more fiddly code which I was hoping to avoid
<perrito666> davecheney: are you still around?
<wallyworld> voidspace: another option is to rollback using a defer
<voidspace> wallyworld: right, thanks
<wallyworld> rogpeppe1: hiya, i have a question for you if  you are free at some point
<rogpeppe1> wallyworld: go ahead.
<rogpeppe1> wallyworld: i am fairly busy but will time-slice :)
<wallyworld> rogpeppe1: so, there's a bug. deployer calls AllWatcher.Next(). this errors with an error that appears to come from an update() call at some point on one of the backing objects. 1. does this sound plausible that an error generated during an update() callback on megawatcher would appear when Next() is called?
<wallyworld> 2. the error seems "impossible"
<wallyworld> the error is due to a missing status record for a unit
<wallyworld> but when units are created, they get a status record as part of the txn ops
<rogpeppe1> wallyworld: perhaps Next is returning the error from an underlying tomb?
<wallyworld> could be i guess. i didn't realise the update() on the mulitwatcher set the tomb error
<rogpeppe1> wallyworld: if that tomb is killed with an error, all watchers will die with that error.
<rogpeppe1> wallyworld: i don't know either
<rogpeppe1> wallyworld: it's a random guess without looking at the code
<rogpeppe1> wallyworld: (which i haven't looked at in ages and ages)
<wallyworld> ok, , i'll keep digging, ty
<rogpeppe1> wallyworld: np, good luck!
<wallyworld> i'll need it :-)
<wallyworld> sinzui: can we unblock 1.24? bug 1453805 seem sot have fixed the HA functional tests in CI
<sinzui> wallyworld, Not until i understand all the failures.
<wallyworld> sinzui: you talking about the maas 1.7 failure?
<sinzui> wallyworld, I am talking about all maas failures and kvm failures
<sinzui> no maas passed.
<wallyworld> oh ok, i just saw the onw maas 1.7 one
<sinzui> wallyworld, CI will unblock when the branch was blessed, so CI thinks wont unblock until QA proves Juju wasn't at fault for any of the failures
<wallyworld> ok, i was hoping that as soon as the recorded blocking bug was seen to be fixed we could unblock
<sinzui> wallyworld, yes, and CI recognises that as a blessed branch. CI doesn't care about a specific test. It cares about having a releasable branch
<wallyworld> ok, so that means that even though the bug causing the original blockage is fixed, we still need to wait in case there are new bugs oto be raised
<sinzui> katco, We need someone to look into bug 1454143. We may not be able to the finale release of 1.23.3
<wwitzel3> katco: sorry, omw, was chatting with cory_fu and lost track of time
<katco> dpb1: hey can you provide any guidance on bug 1454143
<dpb1> #1454143
<cory_fu> Don't go blaming me.  ;)
 * dpb1 kicks mup
<katco> <fake mup>: hi! here's bug https://bugs.launchpad.net/juju-core/+bug/1454143
 * ericsnow worries that mup might not be well
<dpb1> LOL
 * perrito666 kicks his computer in anger because nothing works well today
<dpb1> niemeyer has been pinged, he's probably looking at it
<jcastro> mgz, still no luck on dreamcompute, I'm stuck, any help someone on your team could provide would be most welcome!
<mgz> jcastro: okay, I'll try to have a go myself today
<mgz> I saw you hadn't got a response to your mail
<jcastro> heh
<jcastro> Will we be testing on dreamcompute in the future for releases?
<mgz> we haven't got a plan to at the moment, it seems reasonable though
<sinzui> ericsnow, wallyworld 1.23 and 1.24. bug 1392407 was the involved in a system failure caused by a held lock
<sinzui> ericsnow, wallyworld CI blessed and opened 1.24. I opened 1.23 because I think I accounted for every failure as a cloud or substrate issue
<ericsnow> sinzui: cool, thanks!
<lazyPower> o/  - Juju's amazon provider does not understand how to leverage the VPC correct? Thats still something we do manually, and then use the manual provider to consume?
<alexisb> lazyPower, that is correct VPC support is still under development
<lazyPower> alexisb: thanks, thast what I thought :)
<lazyPower> just making sure i hadn't missed an update
* ChanServ changed the topic of #juju-dev to: https://juju.ubuntu.com | On-call reviewer: see calendar | Open critical bugs: None
<natefinch> ericsnow: you around?
<ericsnow> natefinch: otp
<ericsnow> natefinch: what's up?
<mgz> ocr: can I get a stamp on backport http://reviews.vapour.ws/r/1660/
<lazyPower> I'm running into a weird issue bootstrapping on AWS in a VPC w/ 1.24 and 1.23 - i've confirmed the issue affects both - https://bugs.launchpad.net/juju-core/+bug/1412621
<mup> Bug #1412621: replica set EMPTYCONFIG MAAS bootstrap <bootstrap> <maas-provider> <mongodb> <juju-core:Triaged> <juju-core 1.24:Triaged> <https://launchpad.net/bugs/1412621>
<lazyPower> i attached here as it was the same issue - but the bug title seems to scope it to maas.
<lazyPower> and I think i see whats happening, its inserted a host that is the NAT'd address as the replset configuration, and not the local address of the unit
<lazyPower> updated the bug w/ the workaround/steps to fix the bootstrap issue - now the system appears stuck when issuing "juju status"
<mup> Bug #1454359 was opened: Unexpected api shutdown followed by panic <juju-core:New> <https://launchpad.net/bugs/1454359>
<mgz> is there anyone around to do reviews atm?
<katco> cherylj: perrito666: wwitzel3: have time for a hangout?
<cherylj> katco: sure
<katco> cherylj: perrito666: wwitzel3: https://plus.google.com/hangouts/_/canonical.com/moonstone?authuser=1
<katco> getting some tea brt
<mup> Bug #1453805 changed: Juju takes more than 20 minutes to enable voting <blocker> <ci> <ensure-availability> <intermittent-failure> <regression> <juju-core:Fix
<mup> Released by menno.smits> <juju-core 1.23:Fix Released by menno.smits> <juju-core 1.24:Fix Released by menno.smits> <https://launchpad.net/bugs/1453805>
<katco> cherylj: i'm in there now. is perrito666 out today?
<cherylj> katco: can't seem to join.  keeps timing out :(
<katco> cherylj: weird...
<mup> Bug #1453805 was opened: Juju takes more than 20 minutes to enable voting <blocker> <ci> <ensure-availability> <intermittent-failure> <regression> <juju-core:Fix
<mup> Released by menno.smits> <juju-core 1.23:Fix Released by menno.smits> <juju-core 1.24:Fix Released by menno.smits> <https://launchpad.net/bugs/1453805>
<mup> Bug #1453805 changed: Juju takes more than 20 minutes to enable voting <blocker> <ci> <ensure-availability> <intermittent-failure> <regression> <juju-core:Fix
<mup> Released by menno.smits> <juju-core 1.23:Fix Released by menno.smits> <juju-core 1.24:Fix Released by menno.smits> <https://launchpad.net/bugs/1453805>
<alexisb> katco, can you have cmars join that
<alexisb> katco, he mgiht have some volunteers available on his team as well
<katco> alexisb: sure, cmars you're welcome to join
<sinzui> mgz, katco can either of you take a moment to review http://reviews.vapour.ws/r/1663/
<mgz> sinzui: shipit
<sinzui> thank you mgz
<mgz> perrito666: I have three backport branches up, 1660, 1664, 1665, when you have a minute can you eyeball and stamp them?
<katco> mgz: i haven't heard anything from him since this morning
<katco> mgz: he mentioned nothing working well, so i wonder if his computer is on the blink
<mgz> katco: hm, do I have to bug you then? have seen a dearth of other reviewers on this afternoon
<katco> mgz: if i can find a spare moment... how big are the diffs?
<mgz> small, nice sane ones (hardest bit is one dep change)
<perrito666> Hey quick update I am working offline until tonight when I get the time to fix whatever the last update of vivid broke on my laptops network
<perrito666> If you need me please reach me through email as the constant up and down of irc drives me crazy
<mgz> perrito666: aha!
<mgz> perrito666: how offline?
<mgz> too offline to do reviews?
<perrito666> Meh no matter how many times I type it, this phone keeps trying to correct irc as Orc
<perrito666> Mgz nope shoot
<mgz> perrito666: I have three backport bug fixes up, 1660, 1664, 1665
<mgz> they should all be straightforward to stamp
<perrito666> mgz: are you sure 1665 doesn' t break backup restore CI tests?
<wallyworld> perrito666: i also need you to look at http://reviews.vapour.ws/r/1658/ if you have time
<perrito666> ffs man do you ever sleep?
<wallyworld> sometimes
<katco> wallyworld: thumper: sorry i reversed the meeting invites
<wallyworld> :-)
<katco> isn't menn0 in NZ?
<katco> how was he talking to me this morning?
<menn0> katco: yes, I am in NZ
<perrito666> katco: nobody in this team sleeps anymore
<katco> menn0: what time was it for you when we talked yesterday (my this morning)?
<wallyworld> katco: fyi i can't make the very next sky meeting as i have a conflict with another meeting
<katco> wallyworld: no worries, but do need at least 1 lead to hand off to
 * wallyworld looks at thumper 
<davecheney>  sinzui is arm64 tested as part of ci ?
<thumper> standup
<davecheney> sinzui: or to say it another way, some tests are being run on ppc64, are those also being run on arm64 ?
 * thumper has calls for the next 1.5 hours
<thumper> right now
<perrito666> wallyworld: shipit
<wallyworld> perrito666: tyvm :-)
<katco> menn0: sorry for the meeting spam... my brain was playing tricks on me
<menn0> katco: did we actually talk during your morning?
<sinzui> davecheney, not in many months. and even then. not really. The machine we were given never had to power to run unit tests, are do a local deployment.
<menn0> katco: I thought it was your evening
<katco> menn0: i don't think so haha
<katco> menn0: i think i was thinking of your yesterday morning
<sinzui> davecheney, the slave is up and listed as dead by jenkins.
<davecheney> sinzui: ah
<menn0> katco: that make sense
<davecheney> thanks for confirming
<thumper> cmars: I'm going to have to skip out on our call again
<thumper> cmars: have yet another clash
<cmars> thumper, ok, i see how it is
<cmars> thumper, :) np. we should catch up at some point though
<thumper> cmars: yeah, sorry, but katco is more important
<thumper> cmars: definitely
<cmars> thumper, sky?
<thumper> cmars: blue today, slight cloud
<thumper> thanks for asking
<cmars> thumper, rainy here all day
 * thumper smirks to himself
<thumper> oh man, so much rain yesterday
<thumper> at least today I should get outside at some stage
<thumper> get that vitamin D
<katco> cmars: https://plus.google.com/hangouts/_/canonical.com/sky-handoff?authuser=1
<wallyworld> ericsnow: ffs
<wallyworld> provider/vsphere/ova_import_manager.go:166: arg resp.StatusCode for printf verb %s of wrong type: int
<wallyworld> provider/vsphere/ova_import_manager.go:251: missing verb at end of format string in Debugf call
<ericsnow> wallyworld: gah
<wallyworld> go vet is sad
<ericsnow> wallyworld: will fix
<wallyworld> ty :-)
<ericsnow> wallyworld: I could swear I fixed those (twice)
<wallyworld> we've all been there :-)
<ericsnow> wallyworld: hmm, I'm not seeing any problems with 1.24, nor with the branch that's merging right now
<ericsnow> wallyworld: (rather, just merged :) )
<voidspace> wwitzel3: ping
<katco> ericsnow: make sure you're taking time off from work please
#juju-dev 2015-05-13
<menn0> wallyworld: this doesn't actually need a review right? http://reviews.vapour.ws/r/1653/diff/
<mup> Bug #1454468 was opened: Hyper-V Server 2012 R2 node deployed by maas but juju status remains pending <oil> <juju-core:New> <https://launchpad.net/bugs/1454468>
<wallyworld> menn0: hey, sorry was out at accountant. anastasia has looked at it, i was just waiting for 1.24 to be unblocked
<wallyworld> thanks for asking
<wallyworld> ericsnow: it was master
<davecheney> thumper: i have a horrible feeling I know what is going on with arm64 and juju
<davecheney> long story short, the text of most of the net error messages has changed
<davecheney> i'm sure we're doing string sniffing
<davecheney> that's why it's not figuring out when ports are not available and stuff
<menn0> wallyworld: ok cool
<menn0> wallyworld: what's blocking 1.24? I don't see anything
<wallyworld> menn0: was blocked yesterday, and i landed another one first this morning before i had to pop out. will land this one now
<menn0> wallyworld: cool cool
<davecheney> thumper: yup, i was right
<davecheney> juju local provider tests fail on amd64
<davecheney> under go 1.5
<davecheney> (which is what we have to use for arm64)
<davecheney> it's the changes to the net output text
<davecheney> :-<
<davecheney> grr
<natefinch-afk> ...and what have we learned, kids?  Don't do string matching on error messages.
<mup> Bug #1454359 changed: Unexpected api shutdown followed by panic <juju-core:New> <https://launchpad.net/bugs/1454359>
<davecheney> natefinch-afk: sad trombone
<natefinch> yeah....   it's unfortunate that gocheck makes it so easy to do string parsing on errors
<thumper> davecheney: net output text?
<davecheney> my guess is somewhere in the local provider we're looking a err.Error() to figure out what kind of failure it was
<thumper> ugh
<davecheney> yeah, this is going to suck for a while
<davecheney> straddling a bunch of different go versions
<natefinch> good for us... make us stop doing stupid things
<davecheney> http://paste.ubuntu.com/11105279/
<davecheney> lets hear it for juju/errors
<menn0> davecheney: nice
<natefinch> I need a smart diff tool that can diff two git patch files to prove a forward port really is just a copy of another PR.
<natefinch> it has to be smart, because for some reason, the order of files in the patches is not constant, so you can't easily just do a text diff
<natefinch> related... can someone review this forward port to 1.23 of a fix already merged to 1.22?  http://reviews.vapour.ws/r/1659/
<natefinch> menn0: if you're not working on that customer issue? ^
<menn0> natefinch: if it's a forward port of an already reviewed PR with minimal additional changes then it doesn't need another review
<natefinch> menn0: even better
<menn0> natefinch: I did see it :)
<natefinch> :)
<davecheney> natefinch: menn0 thumper https://github.com/juju/juju/pull/2304
<natefinch> davecheney: wow, that seems kind of broken
<davecheney> the contract for the net pacakge says the errors will be of type *net.OpError
<davecheney> natefinch: https://groups.google.com/d/topic/golang-dev/nHMOfuSBYLs/discussion
<mwhudson> davecheney: is this why everything was timing out?
<davecheney> yup
<davecheney> well, sort of the opposite
<davecheney> the test was expecting that ECONNREFUSED was ok
<davecheney> err
<davecheney> it was expecting to get ECONREFUSED
<davecheney> it got another error and freaked
<natefinch> wish there had just been a IsConnectionRefused(error) bool
<davecheney> i considered breaking that big block of logic out into a function
<davecheney> if you review my PR
<davecheney> you can ask me to do that
<natefinch> davecheney: I meant in the stdlib :)
<davecheney> hmm
<davecheney> maybe
<davecheney> but where does it end
<natefinch> dang, I always forget how to do "fix it then ship it" :/
<natefinch> there, close enough
<menn0> davecheney: looking
<natefinch> davecheney: lol, just saw your post to that golang-dev thread on this change.
<davecheney> natefinch: pride comes before the fall
<davecheney> natefinch: menn0 thanks for your review
<davecheney> i've pulled the logic out into a function
<davecheney> let's see if it'll fit through the CI needle
<mup> Bug #1454481 was opened: juju log spams ERROR juju.worker.diskmanager lsblk.go:111 error checking if "sr0" is in use: open /dev/sr0: no medium found <juju-core:New> <https://launchpad.net/bugs/1454481>
 * thumper snorts
<thumper> davecheney: I also looked but you already had two shipits
<thumper> so I didn't bother adding another
<thumper> was more snorting at the 'fit through the CI needle" comment :-)
<anastasiamac> thumper: interestinghow ur virtual reactions are so different to ur real life ones..
<thumper> anastasiamac: or not so different...
<thumper> anastasiamac: although to be honest, I have never stabbed anyone in the face in person
<mup> Bug #1454481 changed: juju log spams ERROR juju.worker.diskmanager lsblk.go:111 error checking if "sr0" is in use: open /dev/sr0: no medium found <juju-core:New> <https://launchpad.net/bugs/1454481>
<anastasiamac> can't imagine u  "snort"ing :D
 * natefinch can.
 * natefinch ducks
<anastasiamac> u r brave, Nate :D
<natefinch> anastasiamac: nah, I'm just very far away ;)
<anastasiamac> :D
<mup> Bug #1454481 was opened: juju log spams ERROR juju.worker.diskmanager lsblk.go:111 error checking if "sr0" is in use: open /dev/sr0: no medium found <juju-core:New> <https://launchpad.net/bugs/1454481>
<thumper> WT actual F
<thumper> ha
<thumper> hmm
<thumper> I should set an alias for 'got est' to be 'go test'
<thumper> I hate timing based intermittent failures in our test suite
<thumper> just sayin
<thumper> ActionSuite.TestActionsWatcherEmitsInitialChanges
 * thumper looks at jw4
<anastasiamac> -*- thumper watches jw4 sleep...
<thumper> fark
 * thumper hates git at times
 * thumper branches then does a git dance
<davecheney> http://juju-ci.vapour.ws:8080/job/github-merge-juju/3219/console
<davecheney> what gives
<davecheney> is this a flake ?
<davecheney> thumper: well, i'm testing with go trunk
<thumper> probably one of the more boring fixes for a critical issue http://reviews.vapour.ws/r/1669/
<davecheney> i need to check it'll fit through the 1.2 sieve
<davecheney> git it
<davecheney> hulk smash
<thumper> davecheney: looks like an ec2 failure
<thumper> menn0: you were reviewer right?
<menn0> thumper: I am
<thumper> menn0: care to look at the above review?
<menn0> thumper: looking
<thumper> menn0: cheers
<menn0> thumper: wow so that was a bit of screwup
<thumper> yeah
<thumper> naming things is hard, right?
<menn0> thumper: that explains the huge number of SetAddresses calls
<menn0> and the resulting txns
<thumper> right
<menn0> thumper: ship it... no comments
 * thumper looks at something
<thumper> this would add one transaction per machine per 15 minutes
<thumper> so in an environment with 100 machines, 400 per hour
<thumper> hmm...
<thumper> I wonder if I got that __fixes__ thing right, or even if this fix needed it
<natefinch> thumper: AFAIK nothing is blocked
<thumper> merge accepted
 * natefinch has landed stuff on 1.22, 1.23, 1.24, and master today
<thumper> menn0: I'll look to forward port the fix once it has landed
<menn0> thumper: sweet
<jw4> thumper: Yeah, that WatcherEmitsIntialChanges test sux0rs
<jw4> thumper: mea culpa
<jw4> hopefully I'll get a chance to fix it if no-one else does this cycle
<axw> menn0: would you please take a look at http://reviews.vapour.ws/r/1670/? trivial change, fixes a critical bug
<jw4> I'll squeeze it in with Actions 2.0
<menn0> axw: looking
<wallyworld> axw: what about existing systems - do we need an upgrade step?
<menn0> axw: looks good. what manual testing have you done to confirm it works?
<jw4> anastasiamac: it's only 9:20 pm... but I feel like I *should* be sleeping
<anastasiamac> jw4: well, if ur were working from an office, would u have been available?..
<jw4> anastasiamac: nope
<jw4> anastasiamac: at least not normally :)
<davecheney> checking: go vet ...
<davecheney> provider/vsphere/ova_import_manager.go:269: missing verb at end of format string in Debugf call
<davecheney> what's the point of doing this check if it doesn't fail ?
<anastasiamac> jw4: :D ur dedication and quick reponse is appreaciated
<jw4> davecheney: you ranted about that last week didn't you?
<jw4> anastasiamac: ;)
<davecheney> i rant about a lot of stuff
<jw4> :)
<davecheney> it's hard for me to keep track
<wallyworld> davecheney: i already ranted about that earlier today too
<wallyworld> davecheney: i think go vet doesn't always exit with an error (at least for the Go version used by the bot)
<wallyworld> but ffs, why don't developers have it turned on locally
<jw4> wallyworld, davecheney the scripts/verify.bash file does return non-zero... the error must be swallowed elsewhere in CI?
<wallyworld> jw4: it depends on the version og go vet i believe
<jw4> wallyworld: ah
<wallyworld> earlier versions were broken
<wallyworld> and CI uses Go 1.2.1
<axw> wallyworld: worker/rsyslog will rewrite the config if changes, so no upgrade step required
<wallyworld> axw: awesome thanks, just wanted to double check due to the sensitity of the site
 * thumper goes to walk the dog while the landing bot does its thing
<axw> menn0: I confirmed that the config is updated, and that logging still works/is distributed. I couldn't repro; I left a note to that effect in the bug, will test manually if someone is able to give me the steps
<menn0> axw: I suspect you need to have an HA setup where rsyslog isn't up on one or more of the state servers so that the outbound queue fills up. with your change, the queue should fill up to 512MB instead of to all free space.
<axw> menn0: yeah, I tried that
<menn0> axw: (the outbound queue should fill up on the hosts where rsyslog is working obviously)
<axw> menn0: from the bug: "I tried creating an HA env, creating a giant machine-0.log and all-machines.log on machine 0, and then disabling rsyslog on the 2nd and 3rd state servers; didn't cause the spool to grow by more than a couple MB."
<menn0> axw: then I don't know. jam might have better context (he's around)
<axw> jam: ^^  any ideas on how to repro https://bugs.launchpad.net/juju-core/+bug/1453801
<mup> Bug #1453801: /var/spool/rsyslog grows without bound <stakeholder> <juju-core:Triaged> <juju-core 1.22:In Progress by axwalk> <juju-core 1.23:New> <juju-core 1.24:New> <https://launchpad.net/bugs/1453801>
<jam> axw: looking
<jam> axw: put 4GB of data into machine-0.log
<axw> jam: from the bug: "I tried creating an HA env, creating a giant machine-0.log and all-machines.log on machine 0, and then disabling rsyslog on the 2nd and 3rd state servers; didn't cause the spool to grow by more than a couple MB."
<axw> (giant was ~512MB, not 4GB, though)
<jam> axw: so to start with what version is your env?
<axw> jam: 1.22.3
<jam> axw: so to repro, I'd recommend using 1.20 if you can
<jam> at the very least because I believe rsyslog might be configured slightly differently (forward messages from the log file vs connect to rsyslog and send messages directly)
<jam> you're Right about ActionQueueMaxDiskSpace
<axw> I'll give 1.20 a shot
<jam> axw: do you see if 1.22 is reading machine-X.log and forwarding the content?
<jam> axw: ah I have another way
<jam> python!
<axw> jam: it was when rsyslog was enabled, yes
<jam> python -m "import syslog; syslog.openlog('juju-test'); syslog.syslog(syslog.LOG_WARNING, 'test this out'))"
<jam> axw should end up in the all-machines.log
<jam> axw: and you can trivially loop over that to create as much logspam as you want
<axw> jam: thanks, I'll try with that
<thumper-bbs> grr... bad record mac
<axw> jam: I think my previous attempts failed because I was creating log lines that were too long, not fitting into syslog messages
<axw> this seems to be creating more spool files
<jam> axw: so you need lots of short messages rather than few long ones ?
<axw> jam: at least log lines smaller than 1MB :)
<jam> axw: we probably have some sort of "max message length"
<axw> yes probably. I'm testing with 1K now, seems to be doing the trick. now to see what happens when it gets to 512MB
<davecheney> what the heck http://paste.ubuntu.com/11107599/
<davecheney> ... error stack: github.com/juju/juju/environs/bootstrap/bootstrap.go:103: Juju cannot bootstrap because no tools are available for your environment.
<davecheney> You may want to use the 'agent-metadata-url' configuration setting to specify the tools location.
<davecheney> did juju just tell me to go fuck muself ?
<thumper-bbs> davecheney: but nicely...
<davecheney> ok, i think these are all symptoms of missing tools
<jam> axw: how goes?
<axw> jam: trying to figure out where my rsyslog config files went...they've disappeared out of /etc/rsyslog.d
<jam> axw: that doesn't sound very good. I thought juju writes them on startup/etc.
<axw> jam: yeah, worker/rsyslog is meant to write it out
<thumper-bbs> wallyworld: we aren't reviewing forward ports of fixes are we?
 * thumper-bbs forgot to change nick
 * thumper guesses not
<axw> jam: finally, verified. I think the worker/rsyslog code isn't very robust to rsyslog being restarted externally
<axw> i.e. if it's not running, and tries to stop/restart it, it'll be unhappy
<jam> axw: ah, we're probably just issuing a "stop" which will fail if it isn't running, and not handling the "stop a stopped service"
<jam> axw: but you found you could overload the queue ?
<axw> jam: yes, and it stopped growing when I added the patch
<jam> axw: can you confirm if the patch would obviously apply to a 1.20 branch?
<jam> axw: and any thoughts on how we might test in "as realistic as we can for CI" ?
<axw> jam: yes, the 1.20 code is pretty similar, so would work there
<jam> axw: you're doing this on 1.22, right? Have you checked 1.24/master as well?
<jam> I haven't heard the official statement from alexis and wes about what version we're targetting
<axw> jam: ensure-availability, juju ssh 1 "sudo stop rsyslog", logspam on machine 0 until all-machines.log grows to 512MB, and then a bit more
<axw> jam: I thought 1.22 was the important one, that's all I've looked into so far. AFAIK the others haven't changed dramatically
<axw> I'll work on forward porting them now
<jam> axw: I agree with that basic sentiment, wes and alexis were supposed to meet last night to discuss official upgrade plans for them
<axw> wallyworld: do you know any more about ^^ ?
 * thumper head desks
 * thumper grunts
<thumper> *another* damn intermittent failure
<thumper> fuck fuck fuckity fuck
<thumper> provider/vsphere tests on 1.24
<thumper> and for extra hillarity
<thumper> environ_broker_test.go:93:
<thumper>     c.Assert(err, gc.ErrorMatches, "no mathicng images found for given constraints: .*")
<thumper> ... error string = "invalid URL \"http://cloud-images.ubuntu.com/releases/streams/v1/index.json\" not found"
<thumper> ... regex string = "no mathicng images found for given constraints: .*"
<thumper> note the spelling mistake in the regex
 * thumper fixes that first
<jam> axw: I'm happy with your patch, but I'm wondering why we ended up with lines added in 2 places
<wallyworld> axw: we are going to patch 1.22 afaik
<jam> ah non API vs API
<wallyworld> jam: that's your understanding too right? we talked this morning at the release meeting that the imminent arrival of 1.22.x into trusy is now being delayed till these issues are fixed in 1.22
<jam> wallyworld: Last I had heard it was going to be discussed at the release meeting, which I was not at
<jam> and it was a "do we go for 1.22 and push back 1.24"
<wallyworld> so, if i understood correctly, it is 1.22
<wallyworld> as we want these fixes in trusty also
<thumper> wallyworld: care to cast your eye over this commit? https://github.com/howbazaar/juju/commit/9757821b5070ff26510cedc58e7919450ebfa9a6
<thumper> wallyworld: not sure why it was intermittently failing
<wallyworld> looking
<thumper> wallyworld: but with this patch, it passes all the time
<thumper> wallyworld: the log showed that the file source was read, and didn't find an image
<thumper> but sometimes it would try to get to cloud-images.ubuntu.com...
<thumper> no idea why it was only sometimes
<wallyworld> thumper: NFI about intermittent nature either
<wallyworld> but good that you fixed the other stuff
<thumper> this does seem to make it go away though
<wallyworld> hmmm
<wallyworld> if it works, but would like to understand the root cause
<wallyworld> i'm looking at another bug related to this
<wallyworld> i'll poke around a bit
<thumper> yeah... me too
<thumper> fix it taking a while to land
<thumper> landed in 1.22
<thumper> trying 1.23
<wallyworld> thumper: i'm looking at bug 1452422
<thumper> before I try 1.24
<mup> Bug #1452422: Cannot boostrap from custom image-metadata-url or by specifying metadata-source <sts> <juju-core:Triaged> <https://launchpad.net/bugs/1452422>
<wallyworld> we're not overlapping are we?
<thumper> don't think so
<thumper> not at all
<thumper> all my changes have been around machine Addresses and SetAddresses
<wallyworld> ok, just when you said me too i wasn't sure
<thumper> just a slight diversion to fix the intermittent vsphere test failure
<wallyworld> ok
<thumper> me too was relating to wanting to know the root cause
<wallyworld> ah
<wallyworld> anyway, +1 on that fix
<thumper> I hate weird shit like that
<wallyworld> yup
<thumper> cheers
<thumper> just checking
<wallyworld> the regexp typo made me laugh
<wallyworld> talk about tweaking the test to match bad code :-)
<wallyworld> you can tell it wasn't TDD :-)
<jam> wallyworld: prob just copy and paste
<wallyworld> yup
<jam> thumper: do we know what menn0's plan is for working on https://bugs.launchpad.net/juju-core/+bug/1453785 ?
<mup> Bug #1453785: transaction collection (txns) grows without bound <stakeholder> <juju-core:Triaged> <juju-core 1.22:In Progress by menno.smits> <juju-core 1.23:Triaged> <juju-core 1.24:Triaged> <https://launchpad.net/bugs/1453785>
<jam> I feel like we should have some coordination to find out when we can purge items from the txn collection
<jam> it is possible that everything can be purged once they have been in APPLIED
<thumper> jam, wallyworld: quick hangout to hand off?
<wallyworld> sure
<thumper> wallyworld, jam: https://plus.google.com/hangouts/_/canonical.com/handoff?authuser=0
<jam> rogpeppe2: ^^
<axw> wallyworld: when you're free, can you please pastebin the output of "sudo lsblk"? I don't have an optical drive :)
<wallyworld> axw: me either
<axw> wallyworld: oh, I thought sr0 was optical. well, anyway, I don't have one of them
<wallyworld> axw: neither does my output
<axw> wallyworld: same machine you had juju running on? juju just runs "lsblk"...
<axw> wallyworld: juju just runs lsblk. you're on the same machine you had juju running, where the log was spammed?
<axw> sorry, thought I was disconnected
<axw> wallyworld: sorry, I'm an idiot
<axw> wallyworld: you didn't send the bug report... :)
<wallyworld> :-)
<mup> Bug #1454599 was opened: firewaller gets an exception if a machine is not provisioned <cpec> <stakeholder> <juju-core:Triaged> <https://launchpad.net/bugs/1454599>
<wallyworld> axw: very small review? http://reviews.vapour.ws/r/1677/
<axw> looking
<wallyworld> ty
<axw> wallyworld: done
<wallyworld> axw: tyvm
<voidspace> wallyworld: axw: ping - know anything about lifecycle watchers?
<wallyworld> a little
<axw> voidspace: what about them?
<voidspace> wallyworld: axw: I have a new watcher / worker combo watching for when IPAddresses become Dead and releasing them with the provider
<wallyworld> ohh, nice
<voidspace> machine removal marks the addresses as dead, which should trigger the worker to release and remove them
<voidspace> the watcher / worker is tested - setting an IPAddress to Dead triggers its removal
<voidspace> machine removal is tested
<voidspace> removing a machine marks associated IP addresses as dead
<voidspace> but an end-to-end test fails
<voidspace> allocating an ip address to a machine and then removing the machine *does* mark the address as Dead
<voidspace> but the watcher doesn't seem to notice it - it's not released
<voidspace> I wonder if I'm missing anything obvious
<wallyworld> it is most likely a resource catsing issue
<wallyworld> casting
<wallyworld> i've seen before
<axw> voidspace: where's the worker?
<voidspace> I figure it maybe something about our test infrastructure - two states or something
<voidspace> worker/addresser/worker.go
<voidspace> let me link you to the current WIP
<wallyworld> where if  struct was not castable to an interface i can't remember, events were rejected
<voidspace> <voidspace> I figure it maybe something about our test infrastructure - two states or
<voidspace> dammit
<voidspace> axw: https://github.com/juju/juju/compare/1.23...voidspace:addresser-machine-destruction
<voidspace> wallyworld: interesting
<voidspace> the only difference is that when a machine is removed the ipaddress is set to Dead as part of a bigger transaction
<voidspace> axw: TestMachineRemovalTriggersWorker is the failing test
<axw> mk
<voidspace> axw: it fails in waitForReleaseOp
<voidspace> (and without waiting for the release op it fails because the address really isn't removed)
<wallyworld> voidspace: i'll see if i can find the code
<voidspace> if I change state.Machine.Remove to call address.EnsureDead (set the address to dead in its own transaction) the test *still fails*
<voidspace> yet tests that do *exactly that* pass
<voidspace> so I suspect test infrastructure problems
<voidspace> wallyworld: ok, cool
<voidspace> the debug output shows that the watcher never sees the event
<axw> voidspace: what first came to mind was that you might need to do s.State.StartSync() just before waitForReleaseOp... but it looks like you're using just the one State, and not BackingState+State
<axw> voidspace: nothing jumps out, sorry
<wallyworld> voidspace: do you have the watcher code?
<axw> wallyworld: it's a plain old lifecycle watcher: https://github.com/juju/juju/blob/master/state/watcher.go#L174
<wallyworld> oh, right
<voidspace> StartSync doesn't appear to help
<voidspace> I see the ip address life set to Dead - watcher isn't triggered
<voidspace> wallyworld: axw: ok, time to start digging into the event code
<voidspace> hah
<voidspace> axw: wallyworld: moving the StartSync to later in the test worked
<voidspace> magically...
<voidspace> axw: wallyworld: thanks...
<voidspace> yay for mysterious magic
<wallyworld> didn't do anything, glad you got it working
<axw> voidspace: where in the test did you add it?
<wallyworld> but i hate magic :-)
<axw> I'm curious to know why that works
<wallyworld> me too
<voidspace> axw: just before the "machine.EnsureDead()"
<axw> huh, that doesn't make any sense
<voidspace> test now passes
<axw> voidspace: I can't repro success with that change, is it passing reliably for you?
<voidspace> celebration coffee
<voidspace> axw: I also needed to tweak the instance ID I allocate to
<voidspace> axw: just pushed a passing branch
<voidspace> ah no
<voidspace> axw: just failed
<voidspace> axw: maybe it's a timing issue
<voidspace> goddammit
<axw> voidspace: if the sync were to make sense anywhere, it'd be after the machine.Remove()
<axw> but that fails for me too
<voidspace> I just had two passes
<voidspace> now two fails
<voidspace> axw: with *three* calls to StartSync it reliably passes, remove any one and it seems to fail
<voidspace> after machine provisioning, after address creation and allocation and after machine removal
<axw> voidspace: still fails with three for me; I suspect it's just adding enough time for it to see the event in your case
<voidspace> that's awful
<voidspace> hmmm... no, it seems like only the first two are needed
<axw> sorry, didn't try in all those spots
<voidspace> it's still reliably passing
<voidspace> that kind of makes sense - it syncs the two new entities - the machine and the address
<axw> voidspace: sorry not sure, gotta go help get kids ready for bed.. I'd be interested to know if you get to the bottom of it
<voidspace> axw: well, that works...
<voidspace> I can dig through the connsuite and try and see where we end up using the different states
<voidspace> axw: laters o/
<natefinch> is wallyworld on?  I want to bitch about launchpad some more ;)
<wallyworld> \o/
<natefinch> wallyworld:  I added a tag to a bug,  but when I click on the link for that tag that was created, it brings me to a list of bugs that doesn't include the bug I just tagged
<natefinch> bug: https://bugs.launchpad.net/juju-core/+bug/1452285
<mup> Bug #1452285: logs don't rotate <cpec> <logging> <stakeholder> <juju-core:Fix Released by natefinch> <juju-core 1.22:Fix Committed by natefinch> <juju-core 1.23:Fix Committed by natefinch> <juju-core 1.24:Fix Committed by natefinch> <https://launchpad.net/bugs/1452285>
<natefinch> link from tag: https://bugs.launchpad.net/juju-core/+bugs?field.tag=cpec
<wallyworld> it the bug assigned to the 1.24 series?
<wallyworld> yes, i can see it is
<mup> Bug #1452285 changed: logs don't rotate <cpec> <logging> <stakeholder> <juju-core:Fix Released by natefinch> <juju-core 1.22:Fix Committed by natefinch> <juju-core 1.23:Fix Committed by natefinch> <juju-core 1.24:Fix Committed by natefinch> <https://launchpad.net/bugs/1452285>
<mup> Bug #1454627 was opened: presence shouldn't try to hold all possible Sequences at once <performance> <tech-debt> <juju-core:Triaged> <https://launchpad.net/bugs/1454627>
<wallyworld> natefinch: the default search criteria only includes open bugs i think
<wallyworld> so if the bug is fix committed it won't show up (a guess)
<wallyworld> you may need to go to advanced deatch so you can explicitly select the bug sates you want
<wallyworld> states
<wallyworld> eg fix committed, triaged, in progress etc
<natefinch> ahh, that actually almost makes sense :)
<wallyworld> natefinch: and i just tested it, advanced search works
<wallyworld> if you clock on advanced search, you'll see the default tags
<natefinch> wallyworld: yeah, I did too.
<wallyworld> s/tags/states
<wallyworld> not obvious i agree
<natefinch> it didn't help that I'd *just* set it to fix released...  plus the whole "only searching one series" thing.
<wallyworld> yeah
<dooferlad> TheMue: http://reviews.vapour.ws/r/1679/ - if you could take a look. This should be getting familiar now!
<jam> wallyworld: or axw: question about "juju status" and agent up/down
<wallyworld> yo
<jam> this is older code, but it might be stuff that you guys have thought about recently
<TheMue> dooferlad: sure, will do
<TheMue> dooferlad: done
<TheMue> dooferlad: a diff between two PRs would be nice, so that it more easily can be compared
 * TheMue is at lunch now
<mup> Bug #1454661 was opened: presence collection grows without bound <performance> <tech-debt> <juju-core:Triaged> <https://launchpad.net/bugs/1454661>
<anastasiamac> jam: ping
<jam> hey anastasiamac, sorry I got my head deep in this sky stuff. Give me a sec and I'll be right there.
<anastasiamac> jam: can reschedule if it's easier :D
<jam> anastasiamac: joining now
<voidspace> known problem in ubuntu 15.04: can't enter decryption password for encrypted hard drive on boot
<voidspace> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1359689
<mup> Bug #1359689: cryptsetup password prompt not shown <apport-collected> <iso-testing> <kernel-da-key> <kernel-fixed-upstream> <kernel-graphics> <rls-v-incoming> <utopic>
<mup> <vivid> <linux (Ubuntu):Triaged by mathieu-tl> <linux (Ubuntu Utopic):Triaged> <linux (Ubuntu Vivid):Triaged by mathieu-tl> <https://launchpad.net/bugs/1359689>
<voidspace> *sigh*
<voidspace> and there's no supported way to remove full disk encryption either
<mup> Bug #1454676 was opened: failed to retrieve the template to clone - 500 Internal Server error - error creating container juju-trusty-lxc-template - <oil> <juju-core:New> <https://launchpad.net/bugs/1454676>
<mup> Bug #1454676 changed: failed to retrieve the template to clone - 500 Internal Server error - error creating container juju-trusty-lxc-template - <oil> <juju-core:New> <https://launchpad.net/bugs/1454676>
<mup> Bug #1454676 was opened: failed to retrieve the template to clone - 500 Internal Server error - error creating container juju-trusty-lxc-template - <oil> <juju-core:New> <https://launchpad.net/bugs/1454676>
<mup> Bug #1454678 was opened: "relation-set --file -" doesn't seem to work <landscape> <juju-core:New> <https://launchpad.net/bugs/1454678>
<mup> Bug #1454678 changed: "relation-set --file -" doesn't seem to work <landscape> <juju-core:New> <https://launchpad.net/bugs/1454678>
<mup> Bug #1454678 was opened: "relation-set --file -" doesn't seem to work <landscape> <juju-core:New> <https://launchpad.net/bugs/1454678>
<wwitzel3> ericsnow: ping
<mup> Bug #1454697 was opened: jujud leaking file handles <cpec> <stakeholder> <juju-core:Triaged> <https://launchpad.net/bugs/1454697>
<jcastro> mgz, any luck with dreamhost?
<mgz> jcastro: expect to have some news shortly, I need to poke a bit more
<jcastro> ack
<katco> ericsnow: standup
<katco> voidspace: hey are you in #juju on canonical's irc?
<natefinch> katco: he hides there as mfoord
<lazyPower> x-post from #juju -- "Man, actions + the new status  stuff in 1.24 is really nice. hattip @ jujucore for this"
<rogpeppe2> anyone know how to change the debug level of a running juju environment?
<mgz> rogpeppe2: `juju set-environment logging-config=<>`
<rogpeppe2> mgz: ah, ok, i wondered if it was set-environment
<rogpeppe2> mgz: the help could be more helpful there, i think :)
<mgz> `juju help logging` isn't bad... just not super concise
<natefinch> cherylj: how's the file handle bug going?
<katco> cherylj: perrito666: btw if you don't think you'll get a patch up for your bugs before your EOD, please be sure to update the bug with any information so we can hand them off
<perrito666> katco: sure
 * perrito666 tries to reproduce a bug by having crappy db
<perrito666> s/db/bw
<cherylj> natefinch, katco:  sorry, was at an appointment.  I'm still digging into that bug
<katco> wwitzel3: hey do you have some code i can look at for the container management stuff?
<wwitzel3> katco: I do
<wwitzel3> katco: https://github.com/wwitzel3/juju/tree/ww3-container-mgmt
<perrito666> oh great, I am almost falling sleep on the kb and spotify decides to play total eclipse of the heart
 * perrito666 makes coffee
<katco> lol
<wwitzel3> katco: that is fairly recent, I haven't pushed anything from today yet, will after it is actually compiling :)
<katco> wwitzel3: can i suggest this (https://github.com/juju/juju/blob/master/apiserver/leadership/leadership.go#L41-L49) as a way of doing IoC for the apiserver stuff?
<katco> wwitzel3: also wondering if we really need a state object in api/procmanager/procmanager.go? what functionality are we using from state?
<katco> wwitzel3: and last observation, ericsnow and i have been talking about organizing code into modules, so would it make sense to put all of this code in a central spot, and then utilize the interesting bits in the various areas of Juju?
<wwitzel3> katco: yeah, I like the idea of all the code being in the same package, we are going to be registering / unregistering the process with state, those methods aren't there yet
<katco> wwitzel3: ah gotcha. so could we just pass in a few closures or an interface that handle the registration?
<wwitzel3> katco: that is the idea, yeah
<katco> wwitzel3: awesome... looking forward to seeing the next iteration of code
<wwitzel3> katco: thanks for looking at the WIP, appreicate the reivew, it should all be a little more concerete tomorrow and we can shop it to every one via a review
<katco> wwitzel3: sweet
<natefinch> cherylj: want some help?  I could help try to repro or something.
<perrito666> natefinch: have a maas?
 * perrito666 grins
<natefinch> perrito666: nope.  I got a maas half set up at the sprint but then hit some problems and never got further with it
<perrito666> meh, I thought you had a hardware maas
<natefinch> perrito666: I have hardware that I could probably make into maas given time. ... but time is not something I have much of.
<cherylj> natefinch: yeah, that would be helpful if you could do that...
<natefinch> haha juju 1.20 does *not* appreciate all the extra garbage in my environments.yaml
<natefinch> huge list of 'WARNING unknown config field "blah"'
<natefinch> sinzui: what do we expect for backwards compatibility between juju versions?  I had a 1.22 local environment and tried to  juju status using a 1.20 client, and it just failed
<natefinch> (hung forever)
<sinzui> natefinch, that is a very bad. I don't think CI has seen that though. The compatibility tests for 1.20 clients to 1.22 servers could get status and do other ops
<natefinch> sinzui: I wonder if juju local is just special
<sinzui> natefinch, shouldn't be, but since everyones local id a little different it can be
<natefinch> cherylj: for what it's worth, I can't seem to reproduce the file descriptor leak.  At least from the proposed hypothesis of it just being because the API server is down.
<natefinch> cherylj: granted, I'm using 1.20.14, not 1.20.11 like at the customer site... I can try 1.20.11 and see if it changes anything though (also trying on juju local, but I can't imagine that matters).
<cherylj> natefinch: yeah, I haven't had much luck with that either.
<perrito666> and you dont have a lot of descriptors open?
<perrito666> if it is a  leak it most likely showing even when not arriving to a critical point
<sinzui> natefinch, I think you have found a regressions. I may need to block 1.22.1 going into trusty.
<sinzui> natefinch, 1.20.x client sees this error talking to a 1.22.x env: x509: certificate is valid for localhost, juju-apiserver, juju-mongodb, not anything
<natefinch> sinzui: oops
<sinzui> natefinch, I wonder if this error is about closing a security issue, in which case, it is intentional
<natefinch> sinzui:  I don't know
<sinzui> natefinch, I think this is just for new envs. I am retesting upgraded envs
<natefinch> sinzui: yes, this was not an upgraded environment
<TheMue> anyone free for reviewing http://reviews.vapour.ws/r/1681/ ?
<sinzui> natefinch, this is just old clients cannot be guaranteed to talk to envs bootstrapped by newer/securer clients. upgraded envs continue to to work. I just took 1.20.11 to 1.21, 1.1.22, then 1.23 and all is good
<natefinch> sinzui: ok... I find that odd, but since I don't really care about backwards compatibility personally, I'm ok with it if you're ok with it ;)
<perrito666> brb, new firmware for my wifi card
<perrito666> well, no improvements, new hardware an linux is a nightmare
<mup> Bug #1454829 was opened: 1.20.x client cannot communicate with 1.22.x env <compatibility> <status> <juju-core:Triaged> <https://launchpad.net/bugs/1454829>
<natefinch> well, the good news is, we're going to have a brand new A/C unit.  That's also the bad news.
<perrito666> natefinch: well, that fix gave you an extra year
<natefinch> perrito666: yes, but it cost me $1000
<natefinch> perrito666: I don't really want to pay $1000 for a year of A/C
<perrito666> no warranty on the fix?
<perrito666> the bad part is, if you had known this a couple of months ago you could have saved the time you spent trying to protect it from the falling ice
<natefinch> perrito666: not sure about warranty, probably not (or not more than like 30-60 days)
<natefinch> gotta run, Lily has an art show at her school
<natefinch> cherylj: FWIW, I have some agents that are very very slowly gaining file handles (like one per half hour), not sure where though, so I'll leave them to run and see what happens.
<perrito666> there is a joke around there about running, heat and AC but I cannot quite make it
<natefinch> haha
<perrito666> bbl
<mup> Bug #1454658 was opened: TestUseLumberjack fails on windows <blocker> <ci> <regression> <test-failure> <windows> <juju-core:Triaged> <juju-core 1.23:Triaged> <juju-core 1.24:Triaged> <https://launchpad.net/bugs/1454658>
<thumper> FFS
<thumper> waigani: I don't suppose you have a windows box handy to run tests on?
<thumper> waigani: can I get you to look at bug 1454658 ?
<mup> Bug #1454658: TestUseLumberjack fails on windows <blocker> <ci> <regression> <test-failure> <windows> <juju-core:Triaged> <juju-core 1.23:Triaged> <juju-core 1.24:Triaged> <https://launchpad.net/bugs/1454658>
<waigani> thumper: windows? what's that?
<thumper> waigani: CI blocker, and very simple fix
<thumper> this is the merge that brought in the failure: https://github.com/juju/juju/pull/2303/files
<waigani> thumper: okay, I'm giving this upgrade bug one final pock (I may have Stockholm syndrome)
<thumper> waigani: please leave it for a bit, and look at this critical bug
<waigani> *poke
<waigani> thumper: yep, will do
<thumper> cmd/jujud/agent/machine_test.go needs two tweaks
<thumper> func (FakeConfig) LogDir() string should wrap the file path in filepath.FromSlash
<thumper> unit_test needs it too in the same palce
<thumper> and the test that checks the filename also needs filepath.FromSlash
<thumper> I *think* that should be sufficient
<thumper> to fix the windows issue
 * thumper has other ports to fix
<waigani> thumper: sure. I'm not going to be able to test in on windows though.
<thumper> waigani: it is purely an assumption on slash file path separators
<thumper> waigani: that's fine, as long as it passes locally, submit it as a fix for that bug and CI will tell us
<thumper> I'm 98% sure this will fix it
<waigani> ok, on it
<thumper> cheers
<thumper> waigani: also not that you should start on the 1.23 branch
<thumper> and forward port through 1.24 and master
<waigani> I was going to ask, okay
<thumper> s/not/note/
<wallyworld> alexisb: you joining sky handoff?
<waigani> thumper:  http://reviews.vapour.ws/r/1683/
<waigani> thumper: local unit tests pass
<thumper> waigani: first one merged, now to forward port :)
<waigani> thumper: okay. ports don't need reviews right?
<thumper> waigani: as long as they apply cleanly (and it should)
<waigani> thumper: https://github.com/juju/juju/pull/2323 - 1.24 port
<thumper> waigani: LGTM
<thumper> waigani: the one thing I'd add for the next one is to mention in the pull request that it is a forward port of a previously reviewed and landed fix
<thumper> waigani: please also keep the bug tasks up to date :-) ta
<waigani> thumper: https://github.com/juju/juju/pull/2324 - 125 port, added comment
<thumper> waigani: nice, thanks - generally I wait for the previous target to merge before pushing the next in
<waigani> thumper: yep. I haven't tried to merge 1.25, waiting for 1.24
<thumper> cool
<mup> Bug #1454870 was opened: Client last login time writes should not use mgo.txn <juju-core:In Progress by thumper> <juju-core 1.22:In Progress by thumper> <juju-core 1.23:Triaged> <juju-core 1.24:Triaged> <https://launchpad.net/bugs/1454870>
<thumper> menn0: do you know of examples in state where we write to the db without a transaction?
<menn0> thumper: state/sequence.go does
<thumper> ta
<waigani> thumper: 1.24 landed, 1.25 landing... bug status updated
<menn0> thumper: but that uses mgo.Change and Apply which is a little esoteric
<menn0> thumper: State.AddCharm doesn't use a txn... and probably should. that looks like a bug to me.
<thumper> menn0: if not mgo.Change and Apply then what?
<menn0> thumper: someCollection.Insert/Update/RemoveId/etc etc
<thumper> hmm..
<menn0> there's lots of methods on collections which let you add, modify and delete docs
<thumper> do we do an Update on a collection anywhere?
 * thumper looks for the mgo docs
<menn0> thumper: not in state proper
<menn0> thumper: you probably want UpdateId
<thumper> yeah, that is what i'm doing :)
<menn0> thumper: i've just noticed that the collection type you get back due to the auto multi-env stuff doesn't support any of the Update* methods :(
<menn0> thumper: easily added though
<thumper> agh
<menn0> thumper: i probably didn't implement them b/c we weren't using them anywhere
<thumper> I don't think that is in 1.22
<thumper> but I'll talk to you about adding it as I go
<menn0> thumper: might not be, in which case you're ok ther
<menn0> there
<menn0> thumper: and the compiler will tell you when you get to the version that does have the multi-env collections stuff
<menn0> :)
 * thumper nods
<thumper> menn0: oh shit
<thumper> menn0: it is in 1.22
<menn0> thumper: ha
<menn0> thumper: ok, it's easy enough to add the required method(s)
 * thumper nods
<menn0> thumper: do you just need UpdateId/
<thumper> I'm going to add update and updateid for consistency
<thumper> menn0: could I get you to look at http://reviews.vapour.ws/r/1687/ for me plz?
<thumper> much appreciated
 * thumper goes to the gym
<menn0> thumper: looking
#juju-dev 2015-05-14
<mup> Bug #1454697 changed: jujud leaking file handles <cpec> <stakeholder> <juju-core:Triaged> <juju-core 1.22:In Progress by cherylj> <juju-core 1.23:New> <juju-core 1.24:New> <https://launchpad.net/bugs/1454697>
<wallyworld> ericsnow: we still got a vet issue
<wallyworld> provider/vsphere/ova_import_manager.go:269: missing verb at end of format string in Debugf call
<wallyworld> definitely in master and maybe 1.24
<wallyworld> next time a branch lands could be fixed as a driveby
<katco> wallyworld: ericsnow was working an issue all day =/
<katco> wallyworld: with any luck we can return to planned work tomorrow
<wallyworld> katco: yeah, i know, just letting him know about an issue from the day before
<wallyworld> there were 2 - looks one one got misssed
<wallyworld> i'll fix as a driveby if it's not done before i next need to land somethong
<katco> wallyworld: kk ty
<davecheney> whee, juju find another runtime bug
<davecheney> https://github.com/golang/go/issues/10844
<hatch> davecheney: Juju test suite ~= golang test suite? ;)
<mup> Bug #1454891 was opened: 1.23.2.1, mongo: document is larger than capped size <landscape> <juju-core:New> <https://launchpad.net/bugs/1454891>
<davecheney> hatch: we find bugs in go every release
<hatch> yay for us!
<hatch> maybe we should run those tests before it gets released ;)
<axw> thumper: with your connection time change, does that mean you no longer need a mongo majority to login?
<axw> thumper: I stumbled across "juju status" hanging yesterday when 2/3 of my state servers were dead, I think it's the ~same issue as the one that triggered this?
<axw> actually it was "juju ssh", but same deal
<thumper> oh... interesting
<thumper> axw: 1.20 didn't have this issue because we weren't recording login time
<thumper> but 1.22+ did
<thumper> not sure about majority
<thumper> but if it needed it, that would suck
<thumper> menn0: ideas?
<axw> thumper: I was on 1.22. I think majority only comes in when you try to write, which is why login was getting stuck
<axw> I can test it out
<thumper> axw: we still try to write, just not using txns
<axw> ah yes, of course
<axw> hm, bugger
<thumper> perhaps we can change the connection requirement
<thumper> to try and return straight away
<thumper> it is no biggie if it fails
<wallyworld> menn0: do you know why mgo/txn doesn't prune the txn collection? seems like an oversight to me. doesn't it mean in general people's dbs will grow unbounded?
<axw> thumper: think it's worth me raising a bug for that?
<thumper> axw: nah, I'll try to do it with this change I have in progress
<axw> okey dokey
<thumper> wallyworld: yes, IMO
<menn0> thumper, axw: could be a majority thing... not sure
<thumper> menn0: how can I change the write requirements for this single update?
<menn0> wallyworld: it's an oversight
<thumper> menn0: you have become our resident mgo expert now
<wallyworld> menn0: will it be fixed in mgo?
<thumper> menn0: thanks for taking that for the team
 * menn0 had noticed
<wallyworld> menn0: make sure when you brace you grip with both hands
<davecheney> hatch: the bugs we find get turned into tests in the main repo
<hatch> ahh cool
<davecheney> as for running juju over go before its released
<davecheney> that's me, every day
<hatch> haha :)
<menn0> wallyworld: i've talked to niemeyer_ and we're going to see what the solution I come up with looks like and see it if makes sense to be in mgo/txn
<wallyworld> ok
<menn0> at any rate i'm confident we can fix it within juju
<wallyworld> sure, but that doesn't help other mgo use cases :-)
<menn0> juju is the biggest user of mgo/txn so we're hitting these things first
<wallyworld> yup
<menn0> wallyworld, thumper: so what I want to do might involve pulling in a golang package that implements a bloom filter
 * wallyworld likes flowers
<menn0> wallyworld, thumper: otherwise we either have to do huge numbers of DB lookups or risk eating up lots of memory with a large map
<thumper> I haven't heard about bloom filters since bzr days
<menn0> a bloom filter fits this problem really well
<thumper> menn0: can you explain bloom filters in works of two syllables or less, and how it fits this problem?
<thumper> s/works/words/
<menn0> this one looks appropriate: https://github.com/willf/bloom
<menn0> thumper: probably not in 2 words :)
<menn0> thumper: but we need to know all the transaction ids that are still be referenced by all docs in all collections, and then go through the txns collection and remove the ones that aren't there
<menn0> thumper: that set of txn ids could be huge
<wallyworld> thumper:  an algorithm on large sets supporting queries returning either "possibly in set" or "definitely not in set"
<menn0> thumper: a bloom filter could store that much more efficiently
<thumper> os
<menn0> thumper: and tells us with 100% certainty when a txn isn't in use
<thumper> ok
<thumper> geez, what is up with me today
<menn0> thumper: it will occasionally indicate that a txn is in use when it actually isn't but that's ok
<menn0> thumper: it can get pruned next time
 * thumper nods
<menn0> thumper: the alternative is to do multiple db hits for each txn doc to see if it's use
<menn0> which is doable but will be slow and i/o intensive
<thumper> hmm...
<thumper> menn0: the license there says we must copy the copyright for the binary distribution
<menn0> thumper: hmmm that's annoying. do we already do that for other packages?
<menn0> thumper: i can also hunt around for other implementations...
<menn0> thumper: i'm getting called for lunch. bbs
<thumper> menn0: when you are back, I'd like to talk about testing
<axw> wallyworld: json schema? I wasn't planning to do a json schema, just using juju/schema to define types and defaults like we have in environs/config and the env providers
<wallyworld> ah, sorry, typo
<axw> wallyworld: did you have something else in mind, or shall I reword the card
<axw> ok
<axw> wallyworld: renamed it
<wallyworld> ty
<menn0> thumper: back
<thumper> menn0: hangout?
<menn0> yep, 1:1?
<thumper> kk
<natefinch> menn0: did you ever figure out what caused this bug? https://bugs.launchpad.net/juju-core/+bug/1420057  We're seeing the same thing with the customer we've all been working on so hard lately.
<mup> Bug #1420057: agents see "too many open files" errors after many failed API attempts <juju-core:Triaged by cherylj> <juju-core 1.24:Triaged by cherylj> <https://launchpad.net/bugs/1420057>
<mup> Bug #1454919 was opened: destroy-environment should cleanup all .jenvs connecting to environ <juju-core:Triaged> <juju-core 1.24:Triaged> <https://launchpad.net/bugs/1454919>
<menn0> natefinch: cherylj is on the case (the ticket related to that customer has marked as a dup of the original ticket)
<menn0> cherylj: has a test running overnight trying to simulate the issue and before she finished it seemed like she was seeing a growing number of leaking sockets
<menn0> we should know more tomorrow
<natefinch> ahh, cool.  I hadn't realized she had been able to repro it.  I haven't (but I was using 1.20.14, not 1.20.11, which possibly maybe might have been the problem... but I also wasn't in HA at the time)
<axw> wallyworld: the bug links from tanzanite leankit don't work. there's a stray "Bug " in the URL
<wallyworld> bah, will fix, thanks
<wallyworld> axw: done
<axw> wallyworld: thanks
<dimitern> o/
<voidspace> dimitern: welcome back
<voidspace> dimitern: I hope you had a good break
<dimitern> voidspace, thanks! :) yeah, it was much needed
 * dimitern needs to catch up on a ton of mails
<voidspace> dimitern: :-)
<dooferlad> dimitern: o/
<dimitern> dooferlad, morning!
<TheMue> wallyworld: I've got a high fix for 1.24, the lp:1437266, but cannot merge it because it doesn't match the current restriction
<TheMue> morning btw
<TheMue> dimitern: welcome back btw
<TheMue> dimitern: I'm stepping out in a few minutes, would you retry merging https://github.com/juju/juju/pull/2320 into 1.24 for  me? I'll also port the fix later to master
<dimitern> TheMue, hey, thanks! will do
<TheMue> dimitern: great, master is also almost done. sadly have to leave now, visiting parents in law
<dimitern> TheMue, np, see you later then
<dimitern> TheMue, ah, I see you're actually on leave today :) enjoy
<TheMue> yep
<TheMue> dimitern: got Ascension Day and Father's Day here in Germany today
<dimitern> TheMue, sounds nice - a looong weekend :)
<TheMue> dimitern: yeeeeeah, and from tomorrow till Sunday the first beer festival here in the city :D
<TheMue> ah, master runs
<dimitern> TheMue, oh boy!
<TheMue> dimitern: so, fix is in for review. you already know https://docs.google.com/spreadsheets/d/1T5RrTFviR4Gpjm5gxOCP5aB7L9BL7_2QzYqQm7fOPHQ/edit#gid=0? just a quick help to get a simple overview. dooferlad will create something automatic based on lp ;)
 * TheMue is stepping out, cu
<dimitern> TheMue, yeah, I saw that spreadsheet and thanks for organizing this
<dimitern> dooferlad, hey, looking at https://github.com/juju/juju/pull/2281 it seems to imply only lxc connectivity is restored after a reboot, but it should also be true for kvm right? the forward rules..
<voidspace> TheMue: dimitern: dooferlad: problems joining the hangout, I think I have to restart my browser
<voidspace> be there in a minute
<dimitern> voidspace, np
<wallyworld> TheMue: sorry, was at soccer, thanks for fix
<mattyw> katco, you around?
<katco> mattyw: in a meeting and for 2 more minutes :)
<wwitzel3> jam: thanks for the feedback, I know you've had some other priorities so I appreciate you taking the time on the spec
<jam> wwitzel3: you're welcome, I did want to meet with you directly. Maybe next week sometime since sky has quieted down?
<wwitzel3> jam: yeah, that sounds great
<marcoceppi> what as annotations in the api that you can set/read?
<marcoceppi> does every "thing" have them or only a limited set?
<marcoceppi> jw4: can you set an annotation on an action?
<jw4> marcoceppi: I don't think so
<jw4> marcoceppi: when I initially wrote the back end I put in the globalKey stuff to use with annotations
<jw4> marcoceppi: but then I vaguely recall a discussion with fwereade where he said they wouldn't be used for actions
<jw4> marcoceppi: so I'm pretty sure that ability has been removed now
<marcoceppi> ah man :( I have a use case where I want to set annotations on a per action level
<marcoceppi> oh well, I'll just file a bug for feature then, thanks
<jw4> marcoceppi: I don't think it's too difficult to put in - yeah feature request would be good
<marcoceppi> Okay, so I have a question about 1.24 juju status-history
<marcoceppi> from an api standpoint can I query a point in time and get the status of the environment in that time frame?
<fwereade> jw4, that was silly of me if I said that
<fwereade> jw4, I do remember saying we shouldn't *expose* the globalKey outside state
<jw4> fwereade: I knew if I mentioned your name carelessly I'd get the real story
<jw4> fwereade: you're probably right - I may have misinterpreted your feedback
<jw4> fwereade: or it may have even been someone else
<jw4> fwereade: it was a while ago
<fwereade> jw4, marcoceppi: anyway adding it should be trivial -- a version bump to the api and some internal notion of globalKey for actions
<fwereade> anastasiamac, was it you who did the annotations api change to add charms?
<marcoceppi> fwereade: cool, any idea on the whole status-history thing? I imagine it's in the API but I'm having a hard time figuring out where teh latest api docs live
<anastasiamac> fwereade: yes
<marcoceppi> doc/api.txt hasn't been touched for about a year
<fwereade> marcoceppi, yeah, I should probably just delete that, it's got so out of date :/
<fwereade> marcoceppi, wallyworld will know for sure
<fwereade> anastasiamac, adding another type shouldn't be too hard, right?
<anastasiamac> fwereade: 1line of code and a test :D
<fwereade> anastasiamac, <3
<marcoceppi> this sounds like something I could even patch :D
<marcoceppi> but /me won't
<fwereade> anastasiamac, (although technically that's an api version bump too, so a *little* more than that, I think?)
<anastasiamac> fwereade: m not sure why u'd bump version...
<anastasiamac> fwereade: signatures won't change
<fwereade> anastasiamac, so clients can tell the difference between a server that's refusing to annotate an action because it won't, or because it can't
<anastasiamac> fwereade: k and bump the version then :D
<anastasiamac> marcoceppi: fwereade: this should be rtreated as usual feature /improvement request, right? :D
<anastasiamac> marcoceppi: fwereade: as in, log as bug in lp?..
<fwereade> marcoceppi, yes, I think so
<jw4> anastasiamac: yes
<anastasiamac> jw4: tyvm :D i guess marcoceppi is the best person to describe use case in lp :)
<jw4> anastasiamac: yep - he's probably got a spec all entered already
 * jw4 out for a bit
<anastasiamac> jw4: :) yes, i think his efficiency is nothing short of legendary
<jw4> hehe
 * marcoceppi pings wallyworld about new status stuff
 * wallyworld was thinkng about sleep
<wallyworld> what would marcoceppi like to know?
 * marcoceppi allows wallyworld to sleep
<marcoceppi> it's like wicked late, isnt it?
<wallyworld> only 23:08
<marcoceppi> oh, still "today"
<marcoceppi> ;)
<wallyworld> yeah :-)
<marcoceppi> I'll be quick
<wallyworld> long day though
<wallyworld> sure
<marcoceppi> wallyworld: I'm trying to, in 1.24 query the API for the status history, Ideally I'd like to using a timestamp, recreate the status of that environment at that point in time
<marcoceppi> is something like that possible? and what API endpoint should I be using
<marcoceppi> and I'll start piecing that together from there
<wallyworld> client facade, "UnitStatusHistory" is the method/api name
<wallyworld> args are Kind, Size, Name
<wallyworld> Kind = "combined" or "agent" or "workload"
<wallyworld> Size is how many entries to fetch
<wallyworld> i think default is 20
<wallyworld> Name is unit name
<wallyworld> so right now you can only query 1 unit at a time
<wallyworld> and there's no filtering as such (eg on time)
<marcoceppi> wallyworld: excellent, I'll start from there. Does the statushistory caputre things like configuration changes? or is this really just a history of the status of each unit
<marcoceppi> I suppose I'm actually digging in the wrong part of the API for what I want
<wallyworld> it captures hook executions eg config-change
<wallyworld> it also captures action execution
<wallyworld> and juju-run execution
<marcoceppi> right, hum, I think I may be going down the wrong API channel. I'll let you capture sleep and just go back to asking random questions of the rest of the devs taht are still awake
<wallyworld> ok, sorry, i wasn't sure exactly what you were after
<wallyworld> but what i said above pretty much describes the history api as it stands today
<wallyworld> we can add to it if it is not suitable as is
<marcoceppi> wallyworld: awesome
<marcoceppi> well, my goal is to recreate a bundle of a deployment from a point in time
<marcoceppi> which means I'd need to know if there's a history of the configuration values or if that's just a bucket, etc
<wallyworld> yeah, so afaik, we don't snapshot state like that
<marcoceppi> and need to know how many units were there, so it seems I may just need to replay all the API calls made to juju from start of deployment to X time
<wallyworld> we do log apis calls but the params are redacted
<marcoceppi> bleh
<wallyworld> juju doesn't really have what you want as of right now
<marcoceppi> I will open a bug then to figure out what'd it take to do this
<marcoceppi> thanks wallyworld
<wallyworld> sure
<wallyworld> we could look at taking a copy of state at time X - the state model isn't that large, but there would be all sorts of niggly complications
<wallyworld> not a quick fix for you sadly i don't think
<marcoceppi> anastasiamac fwereade: https://bugs.launchpad.net/juju-core/+bug/1455089
<mup> Bug #1455089: Allow annotations on actions <juju-core:New> <https://launchpad.net/bugs/1455089>
<mgz> gsamfira: bug 1394223
<mup> Bug #1394223: panic: Session already closed in provisioner tests <ci> <test-failure> <unit-tests> <juju-core:Triaged> <https://launchpad.net/bugs/1394223>
<mgz> ...we had a bug with more details than that
<gsamfira> mgz: thanks
<mup> Bug #1455089 was opened: Allow annotations on actions <juju-core:New> <https://launchpad.net/bugs/1455089>
 * fwereade bbiab
<anastasiamac> marcoceppi: tyvm :D
<dimitern> oh boy, cloud-init userdata generation is broken on precise for cloud-tools packages since the CentOS support landed
<natefinch> doh
<wwitzel3> not sure why my browser is telling me I have to allow the hangout plugin ..
<wwitzel3> since it was working yesterday
<katco> natefinch: stand up
<mgz> dimitern: in what way? we have precise deploy/upgrade jobs in ci
<dimitern> mgz, well, cloud-init fails to complete on a precise host, not container
<dimitern> mgz, still testing and will file a bug
<jcastro> mgz, any luck?
<mgz> jcastro: yeah, should have instructions shortly
<mgz> jcastro: I just need to get my own account now, with the trial thing, to see if the signup bit is what I expect
 * mgz reluctanly gives credit card details to them
<jcastro> mgz, oh ok so if it works for you then I don't need to bring it up at the cross team in 3 minutes?
<jcastro> ie, it was a config issue Juju works fine?
<mgz> jcastro: the auth worked with the details I had, I'll try with the new account in a sec, there may still need to be some code changes
<mgz> jcastro: feel free to mention in the cross team
<mgz> userpass with the api password (not the account password) should be fine
<jcastro> huh, I was using the API password
<mgz> jcastro: what did you have set as the username?
<mgz> there's both a user id and a tenant id
<jcastro> the one they generated for me
<jcastro> I am using the tenant-name though, not the tenant-id
<mgz> jcastro: so, I think we need to explictly support OS_TENANT_ID
<jcastro> so like do I need to set the variable or is there a way to put it in environments.yaml?
<mgz> jcastro: I'm seeing if I can get the other value out of the keystone api
 * jcastro nods
<mgz> jcastro: I can't see that
<mgz> jcastro: but the RC file that you can download on the "Access & Security" page in the dashboard, "API Access" tab,
<mgz> has OS_TENANT_NAME in it as well, looks like dhc000000
<mgz> you can set that as your tenant-name in your environments.yaml
<mgz> I just don't see it listed anywhere else
<mgz> and our code ignores the alternative tenant-id which is what's displayed
<jcastro> yeah I'm using dhc-blah as my tenant-id
<jcastro> oh sorry, I mean as my tenant-name
<natefinch> katco: left some notes on your rich status spec.
<jose> hello everyone. has the use of t1.micros been deprecated? the same constraints I used are now trying to launch a t2.micro instead
<natefinch> jose: Amazon has been deploying fewer and fewer t1.* machines, so we're moving our defaults to t2
<katco> natefinch: ty
<jose> natefinch: is there a way for me to force the use of a t1? t2s are basically... not useful
<jose> also, it throws errors when I set the constraints
<natefinch> jose: juju deploy --constraints "instance-type=t1.micro"  *should* work
<jose> natefinch: it isn't, ERROR failed to bootstrap environment: cannot start bootstrap instance: no instance types in us-east-1 matching constraints "cpu-power=100 instance-type=t1.micro""
<natefinch> jose: yeah, that the error message saying amazon just doesn't have any of those in that AZ.  You can try a different availability zone... just add  --to zone=us-central-1a
<jose> ah. gotcha, thanks
<natefinch> jose: also, it's probably never correct to specify instance-type and any other constraint... since the instance type determines all features of a machine
<jose> I didn't specify cpu-power
<jose> I guess it was grabbed by the instance-type
<natefinch> jose: oh, ok, nevermind then :)
<jose> and looks like that did it!
<jose> thanks
<natefinch> awesome! :)
<natefinch> jose: you're welcome.  BTW, you can specify the default AZ in your environments.yaml, so you don't have to specify it each time... from my experience us-east is very often low on t1.* machines, so you might want to default to central
<jose> yeah, I was about to do that
<jose> there was an error with the az though, said az didn't exist
<jose> I'll double check on my side and see what I can do, but looks like it's a go for now
<natefinch> yeah, you might need to leave off the a, so like us-central-1
<jose> just what I did
<natefinch> mgz: I have evidently forgotten everything about bzr.... why am I getting this when I bzr pull?  bzr: ERROR: Not a branch: "bzr+ssh://bazaar.launchpad.net/~juju-qa/juju-core/ci-cd-scripts2/".
<perrito666> natefinch: branch changed name?
<natefinch> perrito666: certainly that branch does not seem to exist
<jose> natefinch: eh, nope. it's not letting me - tried with central and west, and says 'az doesn't exist'.
<natefinch> jose: hmm
<mgz> natefinch: what's that branch got in it locally for you?
<natefinch> mgz: ci tests for juju... like jujupy.py etc
<mgz> natefinch: that's lp:juju-ci-tools
<natefinch> jose: sorry, should be regions, not availability zones, which is a subtle difference: http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html    try us-west-1
<jose> yep, did us-west-1 and us-west-2 and nope. tried setting the region on my environments.yaml to see if that helps
<jose> ok, this is starting to look pretty weird. I can't launch the instances from Juju but I can from the aws console
<jose> in both the regions I've tried to launch them.
<natefinch> It's not impossible that they put more restrictions on API access than they do on their own console... but I would kinda hope they wouldn't.
<natefinch> jose: I have to step out for an hour-ish to get my kid from school and make lunch.  Hopefully someone else on here can help, like perrito666 or wwitzel3 or ericsnow
<jose> np, thanks
<jose> have a great day!
<natefinch> jose: you too, and good luck!
<jose> thanks!
<mup> Bug #1454658 changed: TestUseLumberjack fails on windows <blocker> <ci> <regression> <test-failure> <windows> <juju-core:Fix Released by waigani> <juju-core 1.23:Fix Committed by waigani> <juju-core 1.24:Fix Released by waigani> <https://launchpad.net/bugs/1454658>
<wwitzel3> ericsnow: ping
<mup> Bug #1455158 was opened: Destroying a machine with a placed unit errors then destroys anyway. <destroy-machine> <lxc> <juju-core:New> <https://launchpad.net/bugs/1455158>
<ericsnow> wwitzel3: hi
<wwitzel3> ericsnow: my ping was premature, I just realized I hadn't eaten yet and got really hungry the moment I pinged you
<ericsnow> wwitzel3: I have that effect :)
<wwitzel3> ericsnow: I'm moving all of the procmanager stuff in to it's own module, but then I'd love to take some of your time to walk through and maybe help flush out the rest of the interface it will be exposing to juju
<ericsnow> wwitzel3: sure
<wwitzel3> ericsnow: ok, I'm going to grab some food and then I'll ping you and we can jump on a hangout
<wwitzel3> ericsnow: then after we jump, we can just relax and look at the code
<ericsnow> wwitzel3: k
<voidspace> right, EOD
<voidspace> g'night all
<perrito666> https://twitter.com/MEIZU/status/598865451880415232 <-- just in case you are wondering what I want for my birthday :p
<jw4> perrito666: looks quite nice
<jw4> perrito666: when is your birthday... y'know just in case I'm feeling philanthropic
<perrito666> lol, may 25th
<jw4> oh.. coming up soon :)
<mattyw> mgz, I'll grab you tomorrow to talk about chaosmonkey if that's ok?
<katco> natefinch: just going to take my dog out and i'll brt
<natefinch> katco: ok
<mgz> mattyw: sure thing
<mup> Bug #1453280 changed: Juju machine service for Windows creates incorrect tools symlinks  <windows> <juju-core:Fix Released by bteleaga> <https://launchpad.net/bugs/1453280>
<katco> natefinch: did i freeze?
<mup> Bug #1455222 was opened: juju doesn't see MAAS' "failed deployment" state <oil> <juju-core:New> <https://launchpad.net/bugs/1455222>
<mup> Bug #1455224 was opened: TestListBlockDevicesDeviceFiltering fails on ppc64el/gccgo <blocker> <ci> <regression> <unit-tests> <juju-core:Triaged> <juju-core 1.24:Triaged> <https://launchpad.net/bugs/1455224>
<mup> Bug #1455224 changed: TestListBlockDevicesDeviceFiltering fails on ppc64el/gccgo <blocker> <ci> <regression> <unit-tests> <juju-core:Invalid> <juju-core 1.24:Triaged> <https://launchpad.net/bugs/1455224>
<natefinch> is there an environment variable for setting where your .config dir is, or is it always assumed to be in $HOME/.config ?
<sinzui> natefinch, yes, there is a way to change it. let me think
<sinzui> natefinch, $XDG_CONFIG_HOME ? from http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html
<natefinch> sinzui: ahh, yes, now I remember.  I thought there was a standard.  Thanks.
<wallyworld> sinzui: was the release standup cancelled today?
<sinzui> wallyworld, yes it was
<wallyworld> ok, i see beta3 is getting released \o/
<sinzui> wallyworld, in a few minutes that will be true
<wallyworld> sinzui: did you have a minute to explain to me this upgrade issue?
<sinzui> wallyworld, sure, do you want to reuse the release meeting hangout?
<wallyworld> yup
<wallyworld> thumper: do you have a sec? https://plus.google.com/hangouts/_/canonical.com/juju-release
<thumper> wallyworld: no, in a call with rick_h_
<wallyworld> oh, np will talk later
<mup> Bug #1452680 changed: Failed to upgrade from 1.22.1 to 1.22.3 during deployment <cloud-installer> <landscape> <upgrade-juju> <juju-core:Incomplete by cherylj> <https://launchpad.net/bugs/1452680>
<mup> Bug #1455260 was opened: Deployments fail when juju implicitly upgrade after bootstrap <bootstrap> <ci> <cloud-installer> <deployer> <landscape> <oil> <quickstart> <juju-core:Triaged> <juju-core 1.24:Triaged> <juju-deployer:New> <juju-quickstart:New> <https://launchpad.net/bugs/1455260>
<mup> Bug #1452680 was opened: Failed to upgrade from 1.22.1 to 1.22.3 during deployment <cloud-installer> <landscape> <upgrade-juju> <juju-core:Incomplete by cherylj> <https://launchpad.net/bugs/1452680>
<mup> Bug #1455260 changed: Deployments fail when juju implicitly upgrade after bootstrap <bootstrap> <ci> <cloud-installer> <deployer> <landscape> <oil> <quickstart> <juju-core:Triaged> <juju-core 1.24:Triaged> <juju-deployer:New> <juju-quickstart:New> <https://launchpad.net/bugs/1455260>
<mup> Bug #1247232 changed: Juju client deploys agent newer than itself <canonical-is> <ci> <deploy> <juju-core:Triaged> <https://launchpad.net/bugs/1247232>
<mup> Bug #1374253 changed: hpcloud: index file has no data for cloud on region-b.geo-1 <bootstrap> <hp-cloud> <juju-core:Fix Released> <https://launchpad.net/bugs/1374253>
<mup> Bug #1399504 changed: Tools are automatically upgraded during deploy <bootstrap> <canonical-bootstack> <upgrade-juju> <juju-core:Triaged> <https://launchpad.net/bugs/1399504>
<mup> Bug #1452680 changed: Failed to upgrade from 1.22.1 to 1.22.3 during deployment <cloud-installer> <landscape> <upgrade-juju> <juju-core:Incomplete by cherylj> <https://launchpad.net/bugs/1452680>
<mup> Bug #1455260 was opened: Deployments fail when juju implicitly upgrade after bootstrap <bootstrap> <ci> <cloud-installer> <deployer> <landscape> <oil> <quickstart> <juju-core:Triaged> <juju-core 1.24:Triaged> <juju-deployer:New> <juju-quickstart:New> <https://launchpad.net/bugs/1455260>
<menn0> davecheney: what's the deal with the golang.org/x/net packages?
<menn0> davecheney: it looks like Juju is using similar (outdated?) stuff from code.google.com/p/go
<menn0> davecheney: it's looking like the socket leaking problem cherylj's been looking at is caused by a bug in the websocket library from there (which still exists in the similar looking code on Github)
<mup> Bug #1345638 changed: ec2 changes? rising failure rate in ec2 health checks <ec2-provider> <juju-core:Fix Released> <https://launchpad.net/bugs/1345638>
<mup> Bug #1356363 changed: azure bootstrap failed virtual network juju-ENV-vnet does not exist <azure-provider> <bootstrap> <network> <juju-core:Fix Released> <https://launchpad.net/bugs/1356363>
<mup> Bug #1372550 changed: juju metadata missing from brew juju 1.20.7 <feature> <metadata> <osx> <papercut> <juju-core:Fix Released by sinzui> <https://launchpad.net/bugs/1372550>
#juju-dev 2015-05-15
<davecheney> GOD DAMN CI BOT
<davecheney> let me commit the fix that fixes that flakey test ... bastard!
<davecheney> menn0: yes, we need to move off code.google.com
<davecheney> i can take that if everyone else is busy
<davecheney> i think there is a bug
<davecheney> or maybe a few
<wallyworld> thumper: ?
<davecheney> ARGH, failed again!
<davecheney> can someone please review https://github.com/juju/juju/pull/2321
<davecheney> this fixes the panic that causes the tests to fail
<thumper> wallyworld: yes?
<thumper> wallyworld: gah... that damn meeting
<thumper> wallyworld: I've missed it every time since daylight savings
<thumper> wallyworld: we need to push it out another hour
<mup> Bug #1455284 was opened: Juju run doesn't displays returncode 0 <juju-core:New for niedbalski> <https://launchpad.net/bugs/1455284>
<thumper> davecheney: got a few minutes?
<davecheney> thumper: sure
<davecheney> now ?
<thumper> yeah
<thumper> 1:1 hangout?
<davecheney> give me 2 mins
<davecheney> downstarirs
<thumper> kk
<axw> wallyworld: do you know what the regex for MAAS storage tags is?
<thumper> axw: has bug 1455224 passed CI yet?
<mup> Bug #1455224: TestListBlockDevicesDeviceFiltering fails on ppc64el/gccgo <blocker> <ci> <regression> <unit-tests> <juju-core:Invalid> <juju-core 1.24:Fix Committed by axwalk> <https://launchpad.net/bugs/1455224>
<axw> thumper: nope
<thumper> axw: actually, yes
<thumper> http://juju-ci.vapour.ws:8080/view/Juju%20Revisions/job/run-unit-tests-trusty-ppc64el/
<axw> yes, sorry
<axw> just realised I looked at the wrong place :)
 * thumper marks it fix released
<axw> thanks
<thumper> np, I'm trying to land something on 1.24
<wallyworld> axw: sorry, missed ping, after vivid upgrade, quassel doesn't make any sounds :-(
<wallyworld> STORAGE_REGEX = re.compile(
<wallyworld>     r"(?:(?P<label>[a-zA-Z0-9]+)\:)?"  # Optional label
<wallyworld>     "(?P<size>[0-9.]+)"                # Mandatory size
<wallyworld>     "(?:\((?P<tags>[^)]+)\))?",        # Optional tag list between parentheses
<wallyworld>     re.VERBOSE)
<wallyworld> that's what it is currently
<axw> so, basically anything other than a right parenthesis? I guess it's processed further down the line again
<axw> wallyworld: thanks. I'll just leave it as it was, but I've added internal whitespace checking to validation
<wallyworld> ok
<anastasiamac> axw: wallyworld: storage add, next layer :D http://reviews.vapour.ws/r/1702/
<axw> looking
<anastasiamac> axw: tyvm ;D
<anastasiamac> axw: i was not too sure about input as map of map of map is scary
<axw> anastasiamac: yes, I'm about to comment on it :)
<anastasiamac> axw: i seem to recall seeing params structs
<anastasiamac> axw: would prefer to use that :D
<anastasiamac> axw: oh, must b gr8 minds and all...
<anastasiamac> :P
<axw> anastasiamac: couple of comments, please change the signature and revert apiserver code - then I'll take another look
<anastasiamac> axw: tyvm :D
<axw> anastasiamac: if you did that map^3 thing because it made testing simpler, add a helper in the test code instead
<anastasiamac> axw: i did this thing coz i was coping from a place that had it :D
<axw> anastasiamac: can you point me? just curious
<anastasiamac> axw: annotations api
 * anastasiamac hides
<wallyworld> ooh, i like hide and seek
<axw> hm yeah, that's kind of bad :)
<anastasiamac> wallyworld: can't hide from u :D
<axw> it's only in code though, wire format is fine
<anastasiamac> axw: :)
<anastasiamac> axw: i wrote it originally to have ErrorResults as rturn
<anastasiamac> axw: but then we had a discussion about having success messages
<anastasiamac> axw: actually could u do a quick hangout?
<axw> sure
<axw> see you in tanzanite
<anastasiamac> coming
<mup> Bug #1455368 was opened: Expose juju version to the hook environment <juju-core:New> <https://launchpad.net/bugs/1455368>
<dimitern> dooferlad, hey there
<dimitern> dooferlad, I've discovered an issue yesterday with cloudinit on precise - it seems after the centos support has landed some of my workarounds for supporting 0.6.3 c-i (the one in precise) were dropped or changed
<dooferlad> dimitern: yikes!
<dimitern> dooferlad, I've also had mixed success with bootstrapping on precise and then adding a trusty machine; it seems the precise cloudinit has been upgraded to 0.7
<dimitern> dooferlad, so can you spin up a few tests locally with master on maas with precise and trusty + lxc/kvm containers?
<dimitern> dooferlad, if you can see issues in the /var/log/cloud-init*.log around apt-get install, I think we should file a bug
<dooferlad> dimitern: I don't think I have tested with multiple Ubuntu releases before. Fun!
<dooferlad> dimitern: will take a look
<dimitern> dooferlad, :) cheers
<dimitern> dooferlad, the issue is around using e.g. apt-get install --target-release precise-updates/cloud-tools cloud-utils - it becomes apt-get install '--target-release foo/bar cloud-utils'
<dimitern> for cloud-tools packages
<dooferlad> dimitern: so how do I ask juju to add a machine running $ubuntu_version?
<dooferlad> dimitern: or do I just create it in maas then add-machine with ssh:<machine name>?
<dimitern> dooferlad, assuming you "default-series" is missing from envs.yaml, it defaults to yours or trusty (not sure); when you add-machine --series precise it should spin up another node
<dimitern> dooferlad, you'll need precise images on maas up to date as well
<dooferlad> dimitern: thanks. Will start pulling images
<dimitern> dooferlad, standup
<voidspace> dimitern: http://reviews.vapour.ws/r/1694/
<voidspace> dimitern: I have a review from Eric - but in case you want to take a look to
<frankban> perrito666: ping
<perrito666> Frankban pong
<frankban> perrito666: hi, I am getting those errors while trying to merge a branch: http://juju-ci.vapour.ws:8080/job/github-merge-juju/3280/console
<frankban> perrito666: this is due to the fact that my branch updates to the last charm.v5, which includes the new UpdateStatus hook kind, which in turn is not mentioned when validating hooks in worker/uniter/hook/hook.go:Validate
<frankban> perrito666: so, to move forward, I can either 1) comment out that new kind in charm.v5, or 2) just add it in validate (perhaps line 50?)
<perrito666> frankban: that is master right?
<frankban> perrito666: what is master?
<perrito666> frankban: you are trying to merge with master
<frankban> perrito666: yes
<perrito666> frankban: pass me the v5 version please
<frankban> perrito666: 39463053128b672308c459958d00f260b58ce79e (current master trunk)
<frankban> perrito666: your change is in https://github.com/juju/charm/pull/122/files
<frankban> perrito666: UpdateStatus is the offending hook not recognized by core
<perrito666> I know
<perrito666> frankban: there https://github.com/juju/juju/pull/2133
<perrito666> that branch, which was waiting on other work to land, is now merging
<perrito666> it contains what you need
<perrito666> :)
<frankban> perrito666: great
<frankban> perrito666: I'll merge trunk back after it lands and try again with my branch
<perrito666> frankban: until recently, the head of charm.v5 had other issues that made it impossible to merge
<frankban> perrito666: out of curiosity, what issues?
<perrito666> frankban: worker/uniter/hook/hook.go:54: undefined: hooks.StorageDetached
<perrito666> that changed names
<perrito666> it was changed in 1.24 but not in master so until it was fwported we could not use charm.v5 tip
<frankban> perrito666: ok
<frankban> perrito666: so, good timing
<mup> Bug #1455445 was opened: Instance ERROR status not noticed by Juju <landscape> <openstack-provider> <juju-core:New> <https://launchpad.net/bugs/1455445>
<natefinch> oh we noticed... we just didn't care ;)
<mup> Bug #1455445 changed: Instance ERROR status not noticed by Juju <landscape> <openstack-provider> <juju-core:New> <https://launchpad.net/bugs/1455445>
<mup> Bug #1455445 was opened: Instance ERROR status not noticed by Juju <landscape> <openstack-provider> <juju-core:New> <https://launchpad.net/bugs/1455445>
<wwitzel3> natefinch: are you talking to the bot again?
<mup> Bug #1454143 changed: Deployer failure upgrading to proposed 1.23.3 from 1.23.2 client <blocker> <deployer> <landscape> <upgrade-charm> <juju-core:Triaged> <juju-core 1.23:Triaged> <juju-core 1.24:Triaged> <juju-deployer:New> <https://launchpad.net/bugs/1454143>
<ericsnow> wwitzel3: ping
<wwitzel3> ericsnow: pong
<mgz> nate died...
<perrito666> mgz: that is what children do to you
<sinzui> ericsnow, can you help with bug 1454678. This issue might be a dupe of bug 1408467
<mup> Bug #1454678: "relation-set --file -" doesn't seem to work <landscape> <relation-set> <juju-core:New> <https://launchpad.net/bugs/1454678>
<mup> Bug #1408467: juju help-tool does not reflect all options available to relation-set <audit> <docs> <help> <juju> <papercut> <relation-set> <ui> <juju-core:Triaged> <https://launchpad.net/bugs/1408467>
<mup> Bug #1455490 was opened: Panic: no reachable servers in unit test <intermittent-failure> <panic> <unit-tests> <juju-core:New> <juju-core 1.24:New> <https://launchpad.net/bugs/1455490>
<ericsnow> sinzui: I don't think it's a dupe, but I won't be able to look at it for a little while
<sinzui> thank you ericsnow
<mup> Bug #1452796 changed: template download failed <deploy> <lxc> <juju-core:Incomplete> <https://launchpad.net/bugs/1452796>
<mup> Bug #1455222 changed: juju doesn't see MAAS' "failed deployment" state <landscape> <maas-provider> <oil> <juju-core:New> <https://launchpad.net/bugs/1455222>
<mup> Bug #1452796 was opened: template download failed <deploy> <lxc> <juju-core:Incomplete> <https://launchpad.net/bugs/1452796>
<mup> Bug #1455222 was opened: juju doesn't see MAAS' "failed deployment" state <landscape> <maas-provider> <oil> <juju-core:New> <https://launchpad.net/bugs/1455222>
<mup> Bug #1452796 changed: template download failed <deploy> <lxc> <juju-core:Incomplete> <https://launchpad.net/bugs/1452796>
<mup> Bug #1455222 changed: juju doesn't see MAAS' "failed deployment" state <landscape> <maas-provider> <oil> <juju-core:New> <https://launchpad.net/bugs/1455222>
<katco> wwitzel3: ericsnow: bonus points: make the timing of the registration more explicit than init so we can control ordering
<katco> wwitzel3: ericsnow: see bug 1452422 for why that might be important. init registrations are getting overwritten by --metadata-source which should not be happening
 * perrito666 sees ordering and time and panics
<mup> Bug #1452422: Cannot boostrap from custom image-metadata-url or by specifying metadata-source <sts> <juju-core:Triaged> <https://launchpad.net/bugs/1452422>
<ericsnow> katco: k
<perrito666> I am SO going to build one of these https://pbs.twimg.com/media/CDC9FfDWEAAYgfS.jpg:large
<katco> perrito666: i often dream of doing something like that, but the steady stream of old computers makes it too easy to use them as servers.
<perrito666> katco: that seems to be something that can be built here for 1k USD
<perrito666> given the right prices :)
<katco> perrito666: $1k > 0 ;p
<perrito666> lol
<perrito666> katco: that is true, I dont have a stream of old computers (yet, if I did, I would make a rack like that one)
<katco> perrito666: i tend to get a new one every 5 years or so
<katco> perrito666: and the servers last that long easily
<katco> perrito666: so i use my computers ~10 years :)
<perrito666> katco: I have not used a desktop in 5 years
<perrito666> or more
<perrito666> I do change my laptop every one or two years
<katco> perrito666: i always have a desktop for the graphics card
<perrito666> katco: I felt behind too much on my hardware so I only play in consoles now
<katco> bleck consoles
<katco> bleck
<perrito666> katco: consoles are non updatable hardware, which is a very convenient thing
<perrito666> especially living in noNewHardwareGoesTroughCustomsLand
<katco> haha
<perrito666> I really deeply hate juju local
<mattyw> cherylj, ping?
<cherylj> mattyw: what's up?
 * natefinch is totally rocking some actions for his CI tests.
<jw4>  /natefinch totally rocks
<natefinch> :)
<natefinch> they really make this test way easier.  I'm testing log rotation, so I'm writing a charm that I can tell to dump a bunch of data into the logs, and then ask it how big the log file is :)
<jw4> sweet
<natefinch> jw4: docs are pretty good, too.  I was afraid it would be difficult to figure out how to do it, but it's totally not.
<jw4> natefinch: bodie_ is responsible for all the good docs
<natefinch> nice, well done, bodie_
<jw4> natefinch: glad to hear its working well
<natefinch> jw4: I haven't actually tested it yet, but writing it has been pretty painless :)   Not really any different than writing a regular hook.
<jw4> natefinch: heh.. well I'll be happy to get any feedback along the way
<cherylj> ericsnow: ping?
<ericsnow> cherylj: hi
<cherylj> ericsnow: I have some questions about systemd unit files.  Got a few minutes?
<ericsnow> cherylj: sure
<Argon]> hi. first time using such a (semi) automated review/merge system. my PR was marked "ship it", am I supposed to do anything else now?
<natefinch> jw4: I do think it's kind of weird that the input is schema'd and the output is not.  I kept looking to try to find how to define in the metadata what it returns.
 * bodie_ tips fedora to natefinch
<natefinch> bodie_: fedoras are not allowed here ;)
<bodie_> hehe
<jw4> natefinch: yeah that was discussed quite a bit - rationale for not using output schemas is lost in the mists of my memory
<natefinch> jw4: haha... that's ok
<mgz> Argon]: I (or someone else) will need to do the $$merge$$ comment for you
<natefinch> jw4: I figured it was one of those things that went back and forth 1000x :)
<bodie_> depends on the rationale for schemas
<bodie_> although I have thought it would be nice for the charm to document what would come back from various actions
<bodie_> and, obviously for building UI around it on the GUI, it would be good
<natefinch> I guess the input schema makes web page controls configurable... but for output you don't want to write to a number picker or whatever.
<Argon]> mgz: ah ok, that's fine, thanks
<bodie_> but for the purposes of validation, clearly the contents of the charm are expected to be trustworthy
<mgz> Argon]: was going to get someone else to look at it as well, but there's no real need
<mgz> Argon]: I was confused about storage types/virt types initially, but have now read up again and basically understand
<Argon]> mgz: no need to hurry. but this turns out to be a little problem (not related to merging the patch), because while I can patch my local juju, I can't patch the agent version juju is installing on the remote machine
<Argon]> so I can bootstrap an amazon env using t2 instances (because my local juju is patched), but subsequent actions like "deploy wordpress" (I'm following your introduction tutorial) fail because it, once again, tries to use paravirt images on a hvm type instance
<mgz> Argon]: so, there's a developer hack around that
<mgz> generally, we pick a released juju out of streams.canonical.com that matches the version of your local client
<natefinch> rick_h_: little bit of feedback on jujucharms docs... it's really hard to find the docs on hook tools and environment variables (super important and used pretty much every time you write a charm).  They're under "how hooks are run"... which was not an obvious place for me to look.  They're important enough that I think they deserve their own page.
<mgz> but, you can tell juju to use your own streams instead, which can be whatever juju binaries you want
<rick_h_> natefinch: please file a bug on the github.com/juju/docs on that please. We'll see if we can get the docs folks to look at/split that up.
<natefinch> rick_h_: cool, will do
<mgz> Argon]: limits you to arches you can built locally, but that's likely not a problem for ec2 (except when I'm using my arm chromebook... why no arm instances ec2)
<Argon]> mgz oh that's fine, I could spin up a instance and build it there anyway. however, I'm not exactly sure how to specify this, are you talking about the config var "image-stream"?
<mgz> Argon]: so, the robust way is with the `juju metadata` plugin and then the agent-metadata-url pointing at the streams you generate
<mgz> Argon]: for throwaway environments, you can just bootstrap with --upload-tools param
<Argon]> mgz: great, thanks!
<sinzui> mgz: let me correct your. there are no arm instances that "run" in ec2. there are several that walk so slowly that it takes 12 hours to build a juju and jujud
<mgz> ehehe
<cherylj> ericsnow: just fyi - the containter still didn't stop, but I didn't get that same error this time.  Looking more...
<ericsnow> cherylj: k
<perrito666> upgrade-juju --upload-tools will upgrade every time even if the toos have the same version?
<natefinch> Can anyone think of a way for a charm to get something written to the machine log?
<perrito666> natefinch: ?
<natefinch> perrito666: I'm testing log rotation with a custom charm... but it occurred to me that while the charm's output is written to the unit agent's log (making it easy to spam the log to make it big), there's no direct way for a charm to output to the machine agent's log
<perrito666> you mean to machine-N.log?
<natefinch> yeah
<perrito666> mmm, nope, cant think of a nice way
<natefinch> I suppose I could do something like stop the machine agent, manually dump a bunch of data to the log file, and then restart the agent... but I'd prefer a way to do so through normal log output.
<mup> Bug #1455627 was opened: TestAgentConnectionDelaysShutdownWithPing fails <ci> <intermittent-failure> <test-failure> <juju-core:New> <juju-core 1.24:Triaged> <https://launchpad.net/bugs/1455627>
<natefinch> jw4, bodie_: can I call action-set multiple times?  So like action-set result-map.foo=bar   action-set result-map.baz=bat   etc?
<jw4> natefinch: yes
<bodie_> overwrites if you collide keys, btw
<natefinch> jw4: I thought so.  It seemed implied in the docs, but not explicitly stated.
<natefinch> bodie_: ok...  but result-map.foo=x and result-map.bar=y  don't count as collisions, correct?
<bodie_> correct
<natefinch> ok
<mup> Bug #1455628 was opened: TestPingTimeout fails <ci> <intermittent-failure> <test-failure> <unit-tests> <juju-core:New> <juju-core 1.24:Triaged> <https://launchpad.net/bugs/1455628>
<natefinch> I wish juju help action do would actually do the right thing
<natefinch> 'juju help action do'  that is.... it just returns the help for action generally
<perrito666> natefinch: juju help action do sounds like something yoda would say
<natefinch> lol
<natefinch> yeah, I kinda hate the way nested commands end up being reverse polish notation
<perrito666> natefinch: http://i.imgur.com/qVbuAPU.jpg
<perrito666> here for you to hang on the wall
<natefinch> rof,l
<natefinch> awesome
<natefinch> jw4: so, I guess we don't automatically log the output of actions the way we do with hooks?
<aisrael> What's the best practice for upgrading juju (from beta2 -> beta3)? After install, I run juju upgrade-juju --upload-tools so my current (local) environment is in sync. After that, though, juju status, ssh, etc all hang
<natefinch> jw4: nvm, may be my fault
<natefinch> wow, now there's an interesting bug
<natefinch> if you forget to make your action hooks executable.... no one actually complains, but they just don't run
<natefinch> jw4: ^
<alexisb> aisrael, that sounds like a bug
<aisrael> alexisb: ack. I'll file a bug
<ericsnow> wwitzel3: ping:q
<mup> Bug #1455646 was opened: Juju doesn't complain if action files aren't executable <actions> <juju-core:Triaged> <https://launchpad.net/bugs/1455646>
<ericsnow> cherylj: did that work out with LXC?
<cherylj> ericsnow: I had to go take my daughter to the doctor for a well check, so I haven't been able to look much more at it.
<ericsnow> cherylj: np :)
<cherylj> But it didn't shut down and I'm not sure why
<cherylj> ericsnow: I'm seeing a lot of "peer has disconnected" errors and I don't know if that's a separate issue
<cherylj> ericsnow: what is cloud-final?
<wwitzel3> katco: ping
<katco> wwitzel3: pong
<wwitzel3> katco: have time to jump in to moonstone real quick?
<ericsnow> cherylj: the cloud-init service or something like that
<katco> wwitzel3: for a short bit, need to EOD
<wwitzel3> katco: shouldn't take long
<wwitzel3> katco: thanks
<alexisb> happy weekend all!  I am off to pick up kiddo so granny can head to a dinner party
<perrito666> cheers, happy weekend
#juju-dev 2015-05-16
<natefinch> jw4: don't suppose you're actually online?
<mup> Bug #1455703 was opened: action-set w/ bad data goes into the ether <actions> <charmers> <juju-core:New> <https://launchpad.net/bugs/1455703>
#juju-dev 2015-05-17
<mup> Bug #1455840 was opened: network-bridge compatibility with Open vSwitch <network> <openvswitch> <ovs> <juju-core:New> <https://launchpad.net/bugs/1455840>
<davecheney> mwhudson: do arm put "superceeded" on the background of every page unconditionally
<davecheney> or are there actually some pages they have not yet depricated ?
<mwhudson> davecheney: heh
<mwhudson> davecheney: only the pages that have been around long enough to be found by google, i think
<mwhudson> there will be a version that does not have superceded written on
<mwhudson> but it can be pretty hard to find
<davecheney> mwhudson: http://paste.ubuntu.com/11193890/
<davecheney> sad NEON is sad
<mwhudson> fun times
<davecheney> for limited values of fun
<mwhudson> is there no neon at all?
<davecheney> my guess is it's disabled in the kernel
<davecheney> is that a thing ?
<davecheney> model name	: ARMv7 Processor rev 10 (v7l)
<davecheney> BogoMIPS	: 790.52
<davecheney> Features	: swp half thumb fastmult vfp edsp neon vfpv3 tls vfpd32
<davecheney> compared to my freescale imx6
<mwhudson> oh yeah, no noen in features
<mwhudson> *neon
<davecheney> but is that something you can disable in ther kernel
<davecheney> or does their SoC not have that feature ?
<mwhudson> it is also something you can not include the silicon for
<mwhudson> no idea, i don't know much about marvell designs
<davecheney> as in , it's not optional in cortex-A ?
<mwhudson> not sure about the answer to that specific question
<mwhudson> it's optional in armv7
 * mwhudson asks @scaleway on twitter
<mwhudson> ... and people ask why arm hasn't taken over the data centre
<davecheney> mwhudson: i also dm'd the guy
<davecheney> we'll see what happens
<mwhudson> cool
<davecheney> i'd be amazed that
<davecheney> a. they go their own silicon, rather than just taking a marvell or freescale soc
<mwhudson> i guess 2am on monday morning is not a good time to expect quick replies
<mwhudson> it's a slightly custom marvell part
<davecheney> o_O!
<davecheney> why do people do things like this
<mwhudson> i did manage to dig that out of their site
<mwhudson> "We developed with Marvell a Cortex A9 ARM SoC offering excellent performances for web applications."
<mwhudson> https://www.scaleway.com/faq/server#why-did-you-choose-arm-
<davecheney> blah blah
<mwhudson> it's also hinted at in the cpuinfo
<mwhudson> Processor       : Marvell PJ4Bv7 Processor rev 2 (v7l)
<davecheney> the number of things you can tweak on a custom silicon that actually make a difference
<davecheney> are effectively zero
<mwhudson> it's probably just form factor or something
<mwhudson> cortex a9 means it's arm's design for the actual cpu bit
<mwhudson> s
<davecheney> yeah
<davecheney> oh
<davecheney> a9
<davecheney> booh
<mwhudson> although it's always possible that scaleway's marketing material is using the terms wrong :)
<davecheney> inconceivable
<mwhudson> the hints i see around the net sort of imply that they are
<mwhudson> i _think_ it's based on the armada 370, which is not a cortex a9
<mwhudson> and does not have neon
<mwhudson> (and i think cortex a9s always do have neon)
<davecheney> yeah, looks like armada 370
<davecheney> that is oooooooooooooold
<mwhudson> yeah
<mwhudson> at least it has better IO than a panda :)
<davecheney> how they got a 4 core version of that is a great mistery
<davecheney> a yugo has better io than a pandaboard
<mwhudson> oh yeah
<mwhudson> cortex a9 is also dual core
<mwhudson> oh no, 1-4
<mwhudson> lying there
<mwhudson> ah, and neon is optional
<mwhudson> specifications on http://www.arm.com/cortex-a9.php
#juju-dev 2016-05-16
<mup> Bug #1582065 opened: Juju seems confused about a newly defined MAAS cloud <juju-core:New> <https://launchpad.net/bugs/1582065>
<fwereade> anastasiamac, the only thing that springs to mind is to stop the machine agent, remove all evidence of the failed charm, and let the machine agent come up and deploy it again
<fwereade> anastasiamac, (would have been better to do that first, but I can't immediately think of anything that the dying principal would break)
<fwereade> anastasiamac, (my working theory is that worker/deployer failed half way through and left garbage it subsequently interpreted as a successful deployment)
<anastasiamac> fwereade: thnx.. i htink it's on state server... so m not sure what the implications would be..
<anastasiamac> i mena the unit was deployed on state server machine
<bradm> fwereade: the only thing I can find is the agent.conf, so you're suggesting remove that?
<bradm> fwereade: as in /var/lib/juju/agents/unit-<foo>/agents.conf, I couldn't find any other evidence of it on disk
<bradm> fwereade: and it is deployed to a state server
<mup> Bug #1582105 opened: lxd provider doesn't honour memory constraints <juju-core:New> <https://launchpad.net/bugs/1582105>
<fwereade> bradm, anastasiamac: also check for the init system conf
<fwereade> bradm, anastasiamac: state server shouldn't matter, it's not super-elegant to stop it but it shouldn't do any harm
<bradm> fwereade: no init system conf for it
<bradm> fwereade: so you're saying move the /var/lib/juju/agents/unit-<foo> and restart the machine agent?
<anastasiamac> fwereade: bradm: got to run - family, dinner, etc... but i'll read the scroll \o/
<fwereade> bradm, I think so, just reading the deployer code to see what I might be missing
<bradm> fwereade: its odd, because this is the only subordinate of its type that failed
<fwereade> bradm, also move the tools dir for that unit
<bradm> fwereade: ah, the symlink?  can do
<fwereade> bradm, (shouldn't *really* matter, but it's another thing the deployer is responsible for)
<fwereade> bradm, what should happen when you start the machine agent is that it'll see unit-dying, nothing-deployer, and advance the unit to dead immediately
<fwereade> bradm, ...wait a mo
<bradm> fwereade: ugh, I've already done that
<fwereade> bradm, ah no don't worry :)
<bradm> nothing seems to have changed, though.
<bradm> jujud is chewing away at cpu though
<fwereade> bradm, anything from juju.worker.deployer in the logs?
<bradm> fwereade: nope
<bradm> fwereade: the last thing was from juju.worker.firewaller
<fwereade> bradm, sorry, just to be clear on the syncing: from a fresh start of the state server, we see *nothing* in the juju.worker.deployer logs? but e.g. status shows units assigned to the machine?
<fwereade> bradm, I would expect at least a "checking unit %q" message or two...
<bradm> fwereade: I don't see anything about "checking unit" in the machine logs at all
<bradm> fwereade: oh, no, I'm wrong
<fwereade> bradm, phew :)
<fwereade> bradm, at least some part of the universe makes sense ;p
<bradm> fwereade: there's some from quite a number of hours ago, nothing for my problematic subordinate
<bradm> fwereade: I'm getting quite a bit of stuff thrown out to juju debug-log though, seemingly all from units
<fwereade> bradm, huh, I don't see how it could have messed up the deploy in the first place without at least noticing and checking it
<bradm> fwereade: this jujud is seemingly quite flakey
<bradm> I seem to get a lot of write: broken pipe in the logs
<fwereade> bradm, what sort of things are happening? that doesn't feel *too* unexpected if we're bouncing state servers
<bradm> fwereade: well, for a start a subordinate didn't deploy cleanly.. :)
<fwereade> bradm, indeed :)
<bradm> fwereade: this was landscape-client, and only on the state server did it fail
<bradm> ugh, I'm going to run out of day, will have to disappear for dinner soon
<fwereade> bradm, can you paste any of the logs anywhere for me to take a look at?
<bradm> there's a bunch of juju.apiserver logs about "login for machine-x-lxc-y blocked because upgrade in progress"
<bradm> which is odd, because it was deployed with 1.25.5 and hasn't been upgraded
<fwereade> bradm, what that really means is the state server is still waking up and isn't yet certain that it's fully upgraded
<fwereade> bradm, if it keeps saying that for a long time it's a problem, though
<bradm> macgreagoir: fancy seeing you here!
<macgreagoir> bradm: :-D
<frobware> dimitern: ping
<dimitern> frobware: pong
<frobware> dimitern: do you have 15 mins before standup - would like to sync on the private-address issue
<dimitern> frobware: ok, in :45 ?
<frobware> dimitern: fine, thx
<hoenir> does anyone have time to review my patch please?
<rogpeppe1> dimitern, fwereade: so what's with the smiley face on juju.fail? i can still see critical bugs open...
<dimitern> hoenir: well, beta7 is out, that's why master is unblocked
<dimitern> hoenir: sorry :) that ^^ was for rogpeppe1
<rogpeppe1> dimitern: so master doesn't get blocked on critical bugs any more?
<rogpeppe1> dimitern: woo!
<dimitern> hoenir: I was about to say that most of us are less familiar with the windows support code and I'd suggest asking for a review from e.g. gsamfira or bogdanteleaga as they're most familiar with that code
<dimitern> rogpeppe1: only for those with 'ci' and 'blocker' tags IIRC
<rogpeppe1> dimitern: ah, cool
 * rogpeppe1 hits $$merge$$ and hopes
<dimitern> frobware: joining standup ho now
<rogpeppe1> dimitern: i thought it was gonna be months until i was able to land my "high" importance bug fix :)
<dimitern> rogpeppe1: merge while you can :D
<hoenir> dimitern, bogdanteleaga already reviewed my code and it said it was ok, but he advised me also to seek some more review on irc.
<rogpeppe1> dimitern: BTW, i just saw this comment in the ec2 provider: 	// TODO(dimitern): Both of these shouldn't be restricted for hosted models.
<rogpeppe1> dimitern: i think that, for the time being at least, region should remain restricted
<dimitern> rogpeppe1: why so?
<rogpeppe1> dimitern: because we currently rely on the fact that models will be deployed to the same region
<rogpeppe1> dimitern: and there's no mechanism in place to determine "default" region
<dimitern> rogpeppe1: I see, well good that I haven't made 'region' unrestricted :)
<babbageclunk> hoenir: I've updated my review.
<rogpeppe1> dimitern: looks like vpc id is still restricted thougth
<dimitern> rogpeppe1: 'vpc-id-force' is
<rogpeppe1> dimitern: ah, what does that do?
<dimitern> rogpeppe1: forces juju use 'vpc-id' at bootstrap only
<rogpeppe1> dimitern: sorry, i don't understand that
<babbageclunk> Why is it so hard to get from a PR to the originating branch in github? I always end up editing the URL.
<hoenir> babbageclunk, thanks again
<dimitern> voidspace, babbageclunk: standup?
<babbageclunk> Shouldn't the branches in "hoenirvili  wants to merge 1 commit into juju:master from hoenirvili:refactor-userdata-cloudconfig" be links?
<voidspace> dimitern: omw
<babbageclunk> Oh yeah, sorry - too much ranting.
<fwereade> hoenir, made a couple of comments
<fwereade> hoenir, hmm, (I should probably look at the filetoconst one more closely if it wasn't just a move)
<TheMue> morning, folks
<hoenir> babbageclunk, fwereade , thanks again for the comments and reviwing my code, I will start working right now to fix the mistakes.
<fwereade> hoenir, yw, ping me if anything is not clear
<hoenir> fwereade, after the modification I will ping you for more advice ..
<fwereade> hoenir, cheers
<voidspace> dimitern: babbageclunk: frobware: http://reviews.vapour.ws/r/4838/
<voidspace> dooferlad: http://reviews.vapour.ws/r/4838/
<dimitern> voidspace: that looks like it includes the spaces PR as well/
<dimitern> ?
<voidspace> dimitern: oh yes it does - sorry
<voidspace> dimitern: it requires it, and that is still landing
<voidspace> dimitern: https://github.com/juju/juju/pull/5394
<voidspace> dooferlad: that PR includes the "already reviewed but not yet landed" spaces PR - https://github.com/juju/juju/pull/5394
<dimitern> voidspace: cheers
<babbageclunk> voidspace - You can use rbt to change the base commit for the review so it doesn't include the other changes.
<voidspace> babbageclunk: ah, ok
<voidspace> hmm, if rbt worked for me
<voidspace> it's python 2 code and my default python is now 3 (xenial) - I *assume* that is the cause orf "no module named datetime" anyway
<voidspace> rbt is in a virtualenv I can blow it away and restart
<dimitern> voidspace: what happens with AddSpace when you try to add a space with yet-unknown name, but providerID matching existing space?
<voidspace> dimitern: the same as before
<voidspace> dimitern: how can the name be unknown?
<dimitern> voidspace: won't you get ErrAborted from runTransaction due to txn.DocMissing failed for the providerID ?
<voidspace> dimitern: just looking
<dimitern> voidspace: I mean add space "foo" with providerID "42", then try adding space "bar" also with provID "42"
<voidspace> dimitern: it fails
<voidspace> dimitern: there's a test for that
<voidspace> dimitern: it fails with ProviderId not unique
<dimitern> voidspace: hmm because of the refresh + check notfound yeah I see
<dimitern> voidspace: ok, just checking :)
<voidspace> dimitern: it would have been nice to avoid that Refresh
<dimitern> nice when we have tests that already cover this case - makes refactoring with impunity possible :D
<voidspace> yeah :-)
<fwereade> voidspace, dimitern: Refresh-inside-txn is unhelpful anyway, it means that any call that changes remote state might also change arbitrary local state
<voidspace> that test failed initially - I had to move the Refresh code
<dimitern> voidspace: you can - looking up the providerIDsC doc by the providerID + global key of the space
<voidspace> fwereade: it's "internal local state"
<dimitern> i.e. findid()
<voidspace> fwereade: the space we're refreshing is one created inside AddSpace and not returned
<fwereade> voidspace, dimitern: ah cool
<dimitern> fwereade: yeah, I think the refresh there is relatively safe, as it's adding a new doc
<voidspace> we're already in an error path at that point
<fwereade> voidspace, dimitern: I *would* say that the notion of an error path doesn't quite fit right with txns -- the loop should be (1) check everything in-memory, (2) try to apply change with matching asserts
<fwereade> voidspace, dimitern: so just always reading the space doc fresh might be cleanest?
<fwereade> ...I should look at the code before pontificating too much
<dimitern> fwereade: that's not a bad idea
<voidspace> fwereade: what we're checking for in the assert is that another space with a different name doesn't have the same provider id
<voidspace> so it isn't in memory
<voidspace> and when we get ErrAborted we need to know why it failed to return the right error (message)
<dimitern> fwereade: however, in that particular case we have no loop (i.e. no buildTxn, but a single try-check-erraborted-and-fail-accordingly)
<voidspace> the refresh failing confirms that it failed due to a duplicate provider id and not because the name already existed
<voidspace> the refresh is unnecessary - we've already checked for the "already exists" case so it should be safe to *assume* that it was the other assert that failed
<voidspace> we used to *have to refresh* because the failure was silent, no assert failure, so we had to check the insert worked by refreshing
<dimitern> voidspace: hmm not quite though, we have 3 asserts - model alive, doc missing for spacesC, doc missing for providerIDsC
<voidspace> ah yes
<voidspace> the refresh is now only in the error path though, not on the happy path
<dimitern> uhm
<voidspace> so it's already better
<dimitern> actually also 1 assert per subnet
<dimitern> when subnetids is not empty
<fwereade> voidspace, and that's the trouble with assuming based on asserts :) it's way too easy to lose track of the assumptions
<voidspace> yes, but we check for that before the refresh as well
<voidspace> so we'll leave the refresh in place then
<voidspace> it's an unlikely (theoretically impossible) failure mode anyway...
 * dimitern brb
 * fwereade has seen the code, and, yeah, that Aborted branch is too long -- IMO it's crying out to be restructured to loop over: (1) check provider id not already used (2) check subnets all exist (3) shouldn't we check that we're not sneaking subnets away from other spaces?
<dimitern> fwereade: that sounds better and more thorough
<fwereade> then you (1) check sanity with a bunch of cheap reads instead of firing off an expensive txn without any reason to believe it works and (2) just let the runner mechanism handle the details
<fwereade> if you've messed up you'll get an ErrExcessiveContention which usually actually means that your memory checks don't match your asserts
<dimitern> voidspace: how about fixing that ^^ in a follow-up?
<fwereade> dimitern, voidspace: the other reason to favour that structure, btw, is so you can build up your asserts alongside your memory checks
<fwereade> dimitern, voidspace: having to dupe the logic sucks almost unbearably hard anyway
<dimitern> fwereade: in the attempt > 0 case in buildTxn you mean?
<fwereade> dimitern, voidspace: having the memory version of the code far away from the assert version is a recipe for screwups
<fwereade> dimitern, I don't think you need to check attempt, do you?
<dimitern> fwereade: even to know when to re-eval your local state?
<fwereade> dimitern, yeah, but I thought there wasn't any here?
<fwereade> dimitern, voidspace: https://github.com/juju/juju/wiki/mgo-txn-example attempts to exemplify what I'm talking about
<dimitern> fwereade: it's not there in AddSpace code, but I reading back I see what you mean - nice example btw! thanks
<fwereade> dimitern, cheers
<dimitern> fwereade: any particular preference between txn.Op{.., Insert: docType{}} vs txn.Op{.., Insert: &docType{}} ?
<dimitern> I see the former is more common
<fwereade> dimitern, I don't much care really -- I have a slight preference for passing values rather than pointers, to signal that modifications are not expected/intended
<fwereade> dimitern, because I *have* seen people silently changing fields when given access
<dimitern> fwereade: right, it also looks somewhat cleaner with a value
<fwereade> dimitern, indeed
<fwereade> dimitern, the only argument against I can think of is that it might take more memory -- and people *do* keep bringing this up -- but it kinda baffles me. maybe when your struct is 4k big or something? in the meantime we have gigs available, let's not fret ;)
<dimitern> fwereade: yeah, I guess for storing binary blobs it makes more sense
<dimitern> but even then..
<fwereade> dimitern, well, yeah, and if it's a slice it won't copy anyway
<dimitern> fwereade: what really scares me are maps as docs actually (or subdocs)
<fwereade> dimitern, what's the case you need to worry about... non-pointer receivers on methods backed by array types? I think that copies the whole thing
<fwereade> dimitern, yeah, indeed
<dimitern> voidspace: reviewed
<fwereade> dimitern, fixed a bug just the other day with internal maps leaking out uncopied
<dimitern> fwereade: nasty :/
<fwereade> dimitern, even then, I will worry about that when I write a type like that ;)
<fwereade> dimitern, but anyway
<dimitern> fwereade: yeah :)
<fwereade> dimitern, I'm pretty sure our txn composers copy internally anyway
<dimitern> fwereade: it seems they do
<dimitern> voidspace, babbageclunk, dooferlad: a tiny review http://reviews.vapour.ws/r/4839/, please take a look
<dimitern> thanks babbageclunk!
<babbageclunk> dimitern: hmm - something interesting.
<dimitern> babbageclunk: yeah?
<babbageclunk> dimitern: because the state tests use Reset to teardown and re-setup in tests...
<babbageclunk> dimitern: and cleanups don't get removed in teardown...
<babbageclunk> dimitern: I end up seeing repeated calls to state.Close()
<dimitern> babbageclunk: and panics I presume?
<babbageclunk> dimitern: nope
<dimitern> babbageclunk: by "cleanups" do you mean the cleanups collection?
<voidspace> dimitern: fwereade: thanks for the reviews by the way
<fwereade> voidspace, sorry it was only a glance, I think you and dimitern have it in hand
<babbageclunk> dimitern: Yes, functions registered in suite.addCleanup
<voidspace> fwereade: cool
<babbageclunk> dimitern: I'm going to change CleanupSuite to set them to nil after executing them.
<dimitern> babbageclunk: ah, that's different - that's for bits changed by PatchValue etc.
<fwereade> babbageclunk, multiple Close()s should be fine/safe, but we should have got them all out of the way before we hit Reset, I think
<dimitern> babbageclunk: setting that to nil without un-patching everything sounds really bad
<babbageclunk> dimitern: Executing the cleanup *is* unpatching everything.
<dimitern> babbageclunk: or you mean they're already un-patched, but the slice is never nil
<babbageclunk> dimitern: yes, that
<dimitern> babbageclunk: right, then it sounds safe
<babbageclunk> fwereade: What do you mean by "should have got them all out of the way before Reset"?
<babbageclunk> fwereade: Aren't the closes being done by Reset (which calls TearDownTest)?
<fwereade> babbageclunk, hm, maybe I have the wrong context, code reference?
<dimitern> babbageclunk: if anything, it should be the other way around: TearDownTest is called by gocheck, which probably calls Reset
<fwereade> babbageclunk, I was thinking of the nuke-db-state Reset? which I think undercuts everything else
<fwereade> babbageclunk, the dummy provider will do it to you in the middle of your tests if you're not careful >_<
<babbageclunk> fwereade: oh, no - this is a method on the allwatcher_internal_test that calls teardown and then setup - it's called in the middle of a test (because the test is running multiple scenarios).
<fwereade> babbageclunk, oh ffs :(
<fwereade> babbageclunk, don't suppose I can prevail upon you to just pull out the tests that so clearly want to be separate and deserve a test runner written for the job?
<babbageclunk> fwereade: maybe? I'm not sure I get the second bit.
<fwereade> babbageclunk, insight of katco's, crudely paraphrased by me: table-based tests are rubbish because you're writing your own test runner and that's a waste of effort
<fwereade> babbageclunk, TBTs do have their place but it's an increidbly narrow simple one
<fwereade> babbageclunk, if it doesn't look like a table any more, it's probably too complex to be a good TBT IMO
<fwereade> babbageclunk, also, imagine how nice it will be when the tests just have their own names
<dimitern> babbageclunk: i.e. instead of that test calling TearDownTest inside, it should have a cleanSetup and cleanCleanup helpers that do not depend on calling SetUpTest or TearDownTest
<fwereade> babbageclunk, and failures get reported individually
<fwereade> babbageclunk, and you don't need to find your failure in the middle of 30 pages of successful logs
<babbageclunk> fwereade: Yeah, that makes sense - I think the reason for this one is that the tests are parameterised into allModelWatcher and allwatcher flavours.
<babbageclunk> fwereade: But I'll have a go.
<fwereade> babbageclunk, bleh, I see -- thanks
<fwereade> dimitern, I'm more saying, use SetUpTest and TearDownTest as expected, and write 50 TestFooBarBaz methods that don't abuse their infrastructure
<dimitern> fwereade: I know :) I was just trying to make it slightly easier for babbageclunk
<fwereade> dimitern, that way you get to see which bits failed, and see their logs in isolation, and not have to worry about Assert cutting short a run
<fwereade> etc :)
<babbageclunk> fwereade: But still, I think the point is a good one - I'll see if I can figure out a better way of making the tests split out.
<fwereade> babbageclunk, cheers
<dimitern> babbageclunk: might help using multiple suites to better separate concerns
<dimitern> and minimize code duplication around setup/teardown
<dimitern> babbageclunk: beware though, if you're embedding a "allWatcherBaseSuite" into e.g. "allModelWatcherSuite", and both of those are registered in gocheck (gc.Suite(..)), you'll get run all tests for both suites
<fwereade> babbageclunk, I admit I'm not really aware of a good pattern for running the same suite against different fixtures -- everything I can immediately think of smells too much of trying to do inheritance in golang, which is pretty much always a terrible idea
<babbageclunk> fwereade: Well, at the bottom level I can give each of the not-quite-test funcs a name and then multiply out the actual tests.
<babbageclunk> fwereade: then it's just a matter of editor automation
<fwereade> babbageclunk, yeah, I think that's progress
<fwereade> babbageclunk, dimitern: also, yeah -- I am getting increasingly irritated at suites that are also fixtures
<dimitern> fwereade: me too!
<dimitern> fwereade: I've fixed a bunch of those recently, around the provisioner
<fwereade> babbageclunk, dimitern: have been making a point of `(*FooSuite)` receivers and explicit fixture setup and I think it's working out pretty well
<fwereade> dimitern, nice
<babbageclunk> fwereade, dimitern: Oh, cool - I've been mostly doing that for a bit in Python too (since JB pointed me at a blog post about it)
<babbageclunk> Hmm, that said though - allwatcher_internal_test.go is 3244 lines, so maybe I'll rewrite them all in a separate diff.
<katco> anastasiamac: ericsnow: perrito666: meeting time
<fwereade> babbageclunk, holy shit :(
<katco> anastasiamac: perrito666: hello?
<perrito666> katco: ericsnow natefinch anastasiamac getting there, I sent an email about being late
<mup> Bug #1582214 opened: upgrade-juju output is confusing <juju-core:New> <https://launchpad.net/bugs/1582214>
<rogpeppe1> i'm after a review of this change to the GCE provider if anyone wants to help out, thanks! http://reviews.vapour.ws/r/4840/
<voidspace> dimitern: PR updated
<dimitern> voidspace: thanks, will look shortly
<voidspace> dimitern: cool
<babbageclunk> dimitern: Ha ha, it turns out that clearing out the transaction system's collections and then asking it to run another set of operations in a transaction doesn't work very well.
<babbageclunk> dimitern: This is obvious in retrospect.
<fwereade> babbageclunk, haha
<fwereade> babbageclunk, (do you know about SetBeforeHooks et al?)
<babbageclunk> fwereade: no - what are those?
<fwereade> babbageclunk, repeatable race tests for txns
<fwereade> babbageclunk, hooks in just before executing the txn, so you can change state underneath it and check it aborts as expected
<fwereade> babbageclunk, (and just after, if you want, as well: there are a few tests that just change state under every txn and restore it before the SUT reconstructs it and checks that the runner gives up
<babbageclunk> fwereade: oh, neat
<fwereade> babbageclunk, they're not quite in the right place any more because the underlying functionality moved out of state so it's not really a state responsibility any more, but still ;)
<fwereade> babbageclunk, they come in very handy ;)
<fwereade> babbageclunk, search in state for examples
<babbageclunk> fwereade: thanks - I'll see if I can use them for this.
 * dimitern needs to step out for ~1h
<perrito666> katco: I got kicked out of the call brt
<perrito666> k there is something not ok with google calendar, can anyone give me the link? natefinch?
<natefinch> https://plus.google.com/hangouts/_/canonical.com/tanzanite?authuser=1
<natefinch> perrito666: log out and back in to google?
<perrito666> natefinch: tx, google decided that I should logout of every account
<babbageclunk> fwereade, dimitern: If I get an ErrAborted from running a transaction, how can I work out what's causing it?
<rogpeppe> dooferlad: i see you're OCR today... fancy a review? :) http://reviews.vapour.ws/r/4840/
<rogpeppe> babbageclunk: you can't
<dooferlad> rogpeppe: *click*
<babbageclunk> rogpeppe: :(
<rogpeppe> babbageclunk: the transaction might have been run by another client
<rogpeppe> babbageclunk: that's the way that mgo/txn works
<rogpeppe> babbageclunk: the usual approach is to delve back into the db and see what might've been the cause
<rogpeppe> babbageclunk: and yes, it's pretty crap
<babbageclunk> rogpeppe: Ah, so it doesn't necessarily mean that the changes didn't get made?
<rogpeppe> babbageclunk: if you get ErrAborted from a transaction, no changes have been made
<rogpeppe> babbageclunk: transactions work by first checking all assertions, and only if all of them pass, applying all changes
<babbageclunk> rogpeppe: right - makes sense. Thanks.
<rogpeppe> dooferlad: ta!
<rogpeppe> dooferlad: BTW if you see mhilton's review, ignore it. he isn't a qualified juju-core reviewer. and he was part-author of the changes.
<dooferlad> sure
<fwereade> babbageclunk, you can't -- that's why you have to loop, and check all the things you depend on every time
<babbageclunk> fwereade: In this case I've just deleted all of the things from all of the collections (but not the txns now :). So there really shouldn't be any asserts failing in the transaction.
<rogpeppe> babbageclunk: you haven't got an asserts in your txn?
<rogpeppe> s/an/any/
<fwereade> babbageclunk, hmm, unless they're all txn.DocMissing I would expect any that imply the existence of a doc to fail
<babbageclunk> rogpeppe: They're all DocMissing...
<fwereade> babbageclunk, but, how are you deleting everything?
<fwereade> babbageclunk, once you've used mgo/txn on a document it's basicaly off-limits for everything else
<fwereade> babbageclunk, SetBeforeHooks is better suited to changes you can make via the exported interface
<babbageclunk> fwereade: Ok, that might be it - I'm deleting them using collection.RemoveAll, so outside a transaction.
<fwereade> babbageclunk, how are you getting that collection? .Writeable()?
<babbageclunk> fwereade: weirdly, it works fine in mongo3.2 (for some value of works), just not in 2.4
<fwereade> / Collection imperfectly insulates clients from the capacity to write to
<fwereade> / MongoDB. Query results can still be used to write; and the Writeable
<fwereade> / method exposes the underlying *mgo.Collection when absolutely required;
<fwereade> / but the general expectation in juju is that writes will occur only via
<fwereade> / mgo/txn, and any layer-skipping is done only in exceptional and well-
<fwereade> / supported circumstances.
<babbageclunk> fwereade: Maybe some context is in order. I'm working on this: https://bugs.launchpad.net/juju-core/+bug/1573294
<mup> Bug #1573294: state tests run 100x slower with mongodb3.2 <juju-release-support> <mongo3> <mongodb> <juju-core:Triaged> <https://launchpad.net/bugs/1573294>
<babbageclunk> fwereade: I don't know whether it constitutes exceptional circumstances though.
<fwereade> babbageclunk, ahh, ok... hmm
<babbageclunk> So I'm trying out an approach where instead of deleting and recreating the DB I scrape all of the data out and make it look all clean and new.
<babbageclunk> fwereade: But I definitely might be trying to do this at the wrong level.
<fwereade> babbageclunk, thinking
<fwereade> babbageclunk, so, are we confident it's the index-creation that's slowing us down?
<babbageclunk> fwereade: not totally - it's big, but it's not the only big part from my instrumenting.
<babbageclunk> fwereade: I'm partly doing this in the expectation that it'll still be too slow.
<babbageclunk> fwereade: (I was expecting it to be easier than it has been. ;)
<dooferlad> babbageclunk: have you just tried deleting all the collections rather than deleting everything in them, then recreating them without indexes?
<fwereade> babbageclunk, do we know that a second EnsureIndex runs faster than the first one?
<babbageclunk> fwereade: Oh, hang on - do you mean the second creation of a specific index?
<babbageclunk> dooferlad: No, not yet. I tried commenting out the index creation and running the tests and it was still hella slow.
<fwereade> babbageclunk, yeah
<fwereade> babbageclunk, ok, interesting
<babbageclunk> fwereade: In mongo 2.4 creating the first index is much slower than any subsequent (like 100x).
<babbageclunk> fwereade: In 3.2 I don't see the same - they're all about the same time.
<babbageclunk> fwereade: but I haven't tried dropping and recreating the same one (which I guess would be closer to what the tests are doing).
<babbageclunk> fwereade: (oh, just looked back - in 2.4 it's 10x, not 100x for subsequent index creation)
<fwereade> babbageclunk, ok, and if we don't use indexes at all we don't actually save any significant time anyway? or is "hella slow" notably better than before? ;)
<babbageclunk> fwereade: Well, in the tests the indexes are probably having minimal effect (maybe even slightly negative).
<fwereade> babbageclunk, I was imagining that there was a heavy per-test index-creation cost but that the presence or absence of indexes wouldn't make much difference to the test cases themselves
<babbageclunk> fwereade: I think my numbers were that database teardown was also a big part of the time, but the tests themselves were also still big.
<mup> Bug #1582264 opened: remove-machine fails with false "machine X is hosting containers" <ci> <lxd> <remove-machine> <status> <juju-core:Triaged> <https://launchpad.net/bugs/1582264>
<babbageclunk> fwereade: Yeah - that's right.
<fwereade> babbageclunk, ok, cool, I'm catching up :)
<babbageclunk> fwereade: (Sorry - I'd rerun the tests to get numbers, but my timing is in a stash that won't apply after the bulldozing I've been doing.)
<fwereade> babbageclunk, no worries, I know how it is
<fwereade> babbageclunk, possible derail: have you spotted any 5s-ish waits at all?
<babbageclunk> fwereade: mmmmmmaybe? Trying to remember.
<fwereade> babbageclunk, file it for future reference -- 5s waits usually mean that the txn log watcher is chilling out on its own schedule, and something needs to goose it into activity with a StartSync
<babbageclunk> fwereade: certainly things were going from 0.05s to ~5ish s, but I don't think any one block of time was ~5s.
<fwereade> babbageclunk, or, it it happens all the time, it means StartSync is broken
<babbageclunk> fwereade: Ok, I'll keep an eye out for that.
<fwereade> babbageclunk, and it wouldn't be every test anyway, basically just watcher ones
<mattyw> fwereade, as you're around I have a quick question
<fwereade> mattyw, go on
<mattyw> fwereade, this function is far from ideal because of the panic https://github.com/juju/names/blob/master/unit.go#L26
<mattyw> I know there must be a non panicing version somewhere, but I don't see it
<mattyw> there's someway you can do it by going around the houses
<fwereade> mattyw, it would make me super happy if you were to write useful versions of those funcs
<fwereade> otherwise you're stuck assuming that every client obviously always has a valid unit name because, uh...
<mattyw> fwereade, if I was to do it in pursuit of a potential panic in the apiserver would I earn some kind of prize?
<fwereade> mattyw, my admiration and respect?
<mattyw> fwereade, hmmmm, I'll take it
<fwereade> <3
<fwereade> also beer next time we're in the same city
<babbageclunk> dooferlad: If I was dropping the collections I'd need to do something to redo the collections that need explicit creation, wouldn't I?
<dooferlad> babbageclunk: yes
<babbageclunk> dooferlad: Ok, looking at it that doesn't seem to fiddly.
<babbageclunk> dooferlad: Do you think that'd avoid the horrible transaction mess I've gotten myself into?
<babbageclunk> dooferlad: because I'd like that.
<dooferlad> babbageclunk: yes - if you delete the txn collection you will be home and dry
<dooferlad> (probably)
<babbageclunk> dooferlad: Hmm - It was deleting the txns (although not the collection itself) that got me last time.
<babbageclunk> dooferlad: Still, worth a go!
<dooferlad> babbageclunk: ask fwereade, but there must be a way of deleting basically everything and starting again.
<dooferlad> babbageclunk: see https://github.com/go-mgo/mgo/blob/v2/txn/mgo_test.go
<mup> Bug #1582268 opened: TestInstancesGathering fails <intermittent-failure> <test-failure> <juju-core:Triaged> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1582268>
<babbageclunk> dooferlad: Looks suspiciously like https://github.com/juju/testing/blob/master/mgo.go#L522
<babbageclunk> dooferlad: I think it's that stuff that I'm trying to avoid doing.
<cherylj> katco, frobware - ping?
<frobware> cherylj: pong
<cherylj> hey frobware, can I ask you and katco to help stay on top of CI bugs this week while we're all in vancouver?
<frobware> cherylj: yep, sure
<cherylj> frobware, katco - the latest run had a lot of bugs:  http://reports.vapour.ws/releases/3973
<cherylj> sinzui, abentley - could you guys help katco and frobware prioritize CI bugs?
<frobware> cherylj: who should I bug for the azure related failures?
<cherylj> frobware: i think for that one in particular, CI needs to clean up resource groups
<cherylj> frobware:  it is unclear if the expectation is that juju should be cleaning those up
<abentley> cherylj: I am kind of in the middle of submitting bugs, but I am triaging them :-)
<cherylj> abentley: thanks :)  please work with frobware and katco to get people assigned to blockers
<dooferlad> babbageclunk: sorry tea + daughter break
<babbageclunk> dooferlad: :) no worries
<dooferlad> babbageclunk: the test there does a set up suite that starts the database then has a drop all, redial step.
<sinzui> frobware: CI exhausted its resources this weekend. Old and broken jujus are the likely cause. I cleaned up a few hours ago and am retesting
<frobware> sinzui: ack
<dooferlad> babbageclunk: this is part of the txn testing
<babbageclunk> dooferlad: Yup - ours does something similar, but the server startup is before the suite setup.
<dooferlad> babbageclunk: oh, I thought we had one server per test
<babbageclunk> dooferlad: no, the server is running the whole time - it's started here: https://github.com/juju/juju/blob/master/state/package_test.go#L18
<mup> Bug #1578834 changed: update-alternatives fails to switch between juju-1 and juju-2 <cpe-sa> <packaging> <juju-core:Invalid> <juju-release-tools:Triaged> <https://launchpad.net/bugs/1578834>
<dimitern> frobware: do you know if we're having the call with rick_h_ today?
<dooferlad> dimitern: he has cancelled
<dimitern> dooferlad: ok, thanks
<dooferlad> dimitern: or, at least, he set his response to not attending for this week.
<dooferlad> dimitern: not that I got a message about it :-(
<dimitern> dooferlad: yeah, I guess I should've looked for that first :)
<frobware> dimitern: no
<dimitern> frobware: thanks for following up on the private address question
<dooferlad> frobware / dimitern: is there anything worthy of discussion before the end of day?
<dooferlad> frobware / dimitern: in a hangout that is
<frobware> dooferlad: only to scan the CI failures to see if there's stuf we can take
<dooferlad> frobware: probably better done tomorrow at start of day?
<mattyw> fwereade, you got time to talk about manifolds and charm upgrades?
<fwereade> mattyw, sure
<frobware> dimitern, voidspace, dooferlad, babbageclunk: PTAL @ http://reviews.vapour.ws/r/4844/
<dimitern> frobware: looking
<dimitern> frobware: LGTM
<frobware> dimitern: ty
<frobware> dimitern: am I correct, ... we don't have any explicit tests for machine_linklayer devices?
<dimitern> frobware: in state?
<frobware> yep
<dimitern> frobware: there is complete coverage of that code
<hoenir> v
<frobware> dimitern: through linklayer_devices_test?
<dimitern> frobware: there are white-box tests in _internal_ and black-box tests otherwise
<frobware> dimitern: ok
<dimitern> frobware: so linklayerdevices_internal_test.go and linklayerdevices_test.go
<dimitern> frobware: similarly for linklayerdevices_ipaddresses -
<frobware> dimitern: I was searching for the wrong patter; was including machine
<dimitern> frobware: yeah, machine-related tests were split across multiple files now
<babbageclunk> dooferlad: Hmm. Reusing the database actually does seem to bring the 3.2 performance into line with the original tests on 2.4. Except I can't run my updated tests against 2.4.
<voidspace> dimitern: you still around?
<dimitern> voidspace: yeah
<voidspace> dimitern: you got a minute or two spare to talk about linklayerdevices?
<dimitern> voidspace: sure - standup ho?
<voidspace> dimitern: yep
<dimitern> voidspace: i'm in there now
<mup> Bug #1488245 opened: Recurring lxc issue: failed to retrieve the template to clone  <canonical-bootstack> <kanban-cross-team> <lxc> <juju-core:New> <https://launchpad.net/bugs/1488245>
<katco> natefinch: hey any update on the bug? i think ian needs to give a demo sometime this week
<natefinch> katco: poking at it now... my wife got sick midday, so I had to take some time off, but actively working on it now and will spend time tonight on it as well, if I don't have it figured out soon.
<katco> natefinch: k, lmk if you have to get pulled off again. ian needs a fix asap
<natefinch> katco: will do
<katco> natefinch: (i.e. "today") :( lmk if you need help from anyone or another set of eyes or whatever
<natefinch> katco: lack of logging is hindering initial efforts at figuring it out, but that's easy enough to add in
<wallyworld> natefinch: katco: yeah, sorry about short turaround time, needs to be done for a schedule lightning talk
<wallyworld> natefinch: katco: and as you can imagine, given the audience here, it needs to work :-)
<natefinch> wallyworld: np, able to repro, probably a charmstore issue, but trying to narrow it down to make sure right now.
<bdx> maas-juju-networking-peeps: hey, so initially a juju deployed maas node gets bridges created on its interfaces, but if I reboot the node, /etc/network/interfaces gets stomped, and juju created bridges are wiped
<bdx> :-(
<bdx> filing a bug now
<bdx> https://github.com/juju/juju/issues/5409
<natefinch> wallyworld, katco, ericsnow:  think I see the issue.  Store isn't returning an origin
<katco> natefinch: how is our client handling that? why isn't it an error?
<natefinch> katco: trying to figure that out.  my guess is we're just retrying
<katco> natefinch: good find, ty
<natefinch> katco: wrote a tiny CLI script frontend to our API client wrapper... was way faster than trying to iterate through bootstrap etc
<katco> natefinch: very nice! love the quicker iteration :)
<natefinch> ericsnow, katco: http://pastebin.ubuntu.com/16468371/
<natefinch> I gotta run for dinner, but I'll be back on later.  pretty sure the fix is just to default the origin to store
<katco> natefinch: that would be nice if it was just a client side fix
<katco> ericsnow: do you agree with that approach? and override if the resource comes from a --resource flag?
<natefinch> katco: this is just while downloading from the store itself
<katco> natefinch: that seems sane. obviously couldn't originate from anywhere else
<natefinch> katco: in theory the store could just always return an origin of "store", but they're not, I guess on the theory that, duh it's from the store
<mup> Bug #1582408 opened: System id is listed during bootstrap and deploy of charms instead of system name <juju-core:New> <https://launchpad.net/bugs/1582408>
<ericsnow> katco: we *were* defaulting to store but that changed when we stopped working on the store/csclient code
<ericsnow> katco: so I'm on board with defaulting to that
<ericsnow> katco: gotta run for a couple hours (unexpectedly); will be back later
<katco> ericsnow: k
<davecheney> so, all the managers are away at a sprint and master hasn't been blocked for days
<davecheney> coincidence ? unlikely :)
<katco> davecheney: lol i enjoy this theory
<davecheney> science fiction > science fact
<natefinch> katco, ericsnow, wallyworld: btw, confirmed that fixes the bug.  Not really here, but I'll have a PR up in a couple hours-ish
<katco> natefinch: awesome ty
#juju-dev 2016-05-17
<davecheney> here's a quick review, https://github.com/juju/juju/pull/5410
<anastasiamac> davecheney: reviewed
<davecheney> ta
<mup> Bug #1582463 opened: juju subordinate not allocating and can't be destroyed <canonical-bootstack> <juju-core:Triaged> <juju-core 2.0:New> <https://launchpad.net/bugs/1582463>
<davecheney> it takes 16 minutes to run the state tests on my machine
<natefinch> davecheney: I have a branch where I'm adding if testing.Short(){ c.Skip() } to all the longest tests until each package takes no more than 1 seconds to test.  That should drop the time to run a smoke test dramatically.  Not that it'll help when you really want to run the full suite.
<natefinch> davecheney: it also does that to all mgosuites and jujuconn suites in the suitesetup, skipping the entire suite, because, seriously, no.
<natefinch> brb
<davecheney> natefinch: i only care about the tests taht CI runs
<mwhudson> davecheney: are you testing against mongo 3.2 now?
<mwhudson> hm, doubt it
<davecheney> mwhudson: nope
<davecheney> mwhudson: what i mean is
<davecheney> my setup has not changed since 14.04
<davecheney> so whatever was happening before i went on leave when the state tests did pass
<davecheney> is no longer happening
<mwhudson> davecheney: oh right, of course
<mwhudson> was just a stray thought anyway
<davecheney> mwhudson: fwiw, CI doesn't run mongo 3.2
<davecheney> so, there's that
<mwhudson> davecheney: yeah, i expect some tests still fail
<davecheney> could someone who's a mod on the juju-dev mailing list please approve my message that is slightly larger than the 40kb message limit
<natefinch> davecheney: but what about all those poor souls on their 2800 baud modems?
<anastasiamac_> natefinch: some ppl believe that terrible experiences enrich souls :-P
<natefinch> anastasiamac_: I think some people just can't get out of the 1999 mindset
<anastasiamac_> natefinch: 1999? when was that? :-P
<davecheney> wepl, ya'll miss out on my satorial wit
<mup> Bug #1556442 changed: juju quickstart looks for network-bridge: "lxcbr0" in local environment <bootstrap> <quickstart> <juju-core:Expired> <https://launchpad.net/bugs/1556442>
<mup> Bug #1557874 changed: juju behaviour in multi-hypervisor ec2 clouds <juju-core:Expired> <https://launchpad.net/bugs/1557874>
<davecheney> here is a simple one https://github.com/juju/juju/pull/5413
<mup> Bug #1581748 opened: [2.0b7] add-credential no longer supports maas as a cloud type <cdo-qa> <credentials> <maas> <regression> <juju-core:Triaged> <https://launchpad.net/bugs/1581748>
<thumper> o/
<thumper> davecheney: you should have an amusing email to read now
<davecheney> thumper: :)
<davecheney> are you a mod on juju-dev ?
<davecheney> can you approve my less than amused email ?
<thumper> yep
<thumper> um... not the ubuntu juju-dev list, no
<thumper> I think that is still just gustavo
<elmo> thumper: no, it's Becky^WWilliam
<thumper> elmo: oh, thanks
<elmo> the mailing list moderation is a cluster - I'm going to arbitrarily drop all the held messages; some of them date back to 2013
<elmo> the majority are spam; and I can't believe the non-spam ones are still relevant
<thumper> heh
<dimitern> thumper: heh, it seems I dodged it but frobware got on that plane after all?
<thumper> dimitern: he will be
<dimitern> thumper: ah, not yet I see
<dimitern> sometimes not having a visa might be good for a change
<mup> Bug #1582555 opened: deploy cs:trusty/ubuntu deploys Xenial charm <juju-core:New> <https://launchpad.net/bugs/1582555>
<dimitern> rogpeppe: ping
<rogpeppe> dimitern: pong
<dimitern> rogpeppe: hey, I'm seeing a consistent test failure in cmd/jujud/agent/machine_test.go:TestDyingModelCleanup - http://paste.ubuntu.com/16472327/
<rogpeppe> dimitern: and it might be because of my recent change?
<dimitern> rogpeppe: I did a git bisect and surprisingly it turned out your PR #5404, commit https://github.com/juju/juju/commit/2a731745eb2bb75f5ed20a887f23d9f198c16259 is the first time it happens
<rogpeppe> dimitern: interesting
<dimitern> rogpeppe: surprisingly, because it doesn't seem your PR touched anything near cmd/jujud/agent
<rogpeppe> dimitern: i don't think i believe that
<rogpeppe> dimitern: i don't think gce is even linked in to those tests
<dimitern> rogpeppe: well the only thing that comes to mind is ProviderSchema added in environs/interface.go, but not implemented by the dummy provider?
<rogpeppe> dimitern: it's just an interface declaration
<rogpeppe> dimitern: nothing uses it
<dimitern> rogpeppe: yeah, that's why it's a mystery..
<dimitern> rogpeppe: can you try running cmd/jujud/agent$ go test -check.v -check.f MachineSuite.TestDyingModelCleanedUp on master tip and see if it passes?
<dimitern> might be related to different go versions.. I'm on go1.6.1 linux/amd64
<rogpeppe> dimitern: ok, trying that
<dimitern> rogpeppe: hmmm.. running the test on the only commit of that PR (2a73174) passes, it fails on the merge commit itself :/ (1439ead)
<davecheney> elmo: i'm right here man
<davecheney> please wait til i sign off before calling me mesage irellevant :(
<rogpeppe> davecheney: yo!
<davecheney> rogpeppe: hey
<rogpeppe> davecheney: long time no see
<rogpeppe> davecheney: "see"
<davecheney> rogpeppe: your mate jeff hodges is looking for you
<dimitern> davecheney: hey o/
<rogpeppe> davecheney: jeff hodges... name rings a bell
<rogpeppe> davecheney: ah yes
<davecheney> i think he wants you to make godep do something
<davecheney> or godeps
<rogpeppe> davecheney: i need to spend some time on godef
<davecheney> that's the one
<rogpeppe> davecheney: the guilt is nagging at me
<rogpeppe> davecheney: but i've had no time
<rogpeppe> davecheney: well, i guess i could've not gone for bike rides at the weekend but there are limits :)
<davecheney> i think you've got your priorties set just right
<rogpeppe> davecheney: along with all the other stuff i've wanted to do (fix encoding/xml, finish up my errgo proposal doc, rewrite juju etc, etc)
<rogpeppe> dimitern: i suspect it might be some kind of race issue
<rogpeppe> dimitern: FWIW i do see that test failing
<dimitern> rogpeppe: ok, thanks for confirming!
<dimitern> rogpeppe: it might be quite intermittent and that merge commit just happen to be a false positive, will dig further back
<rogpeppe> dimitern: FWIW (showdeps -a github.com/juju/juju/cmd/jujud/agent | grep gce) prints nothing
<rogpeppe> dimitern: i.e. none of the packages i changed in that PR are linked into those tests.
<davecheney> holy fuck
<davecheney> mongo failed three of my PR's that I submitted
<davecheney> what is the story
<davecheney> why hasn't that bag of shit been taken out behind the woodshed and been shot ?
<frobware> dimitern: https://bugs.launchpad.net/juju-core/+bug/1581074
<mup> Bug #1581074: LXD container interface names don't align with parent interface names <lxd> <network> <juju-core:In Progress by frobware> <https://launchpad.net/bugs/1581074>
<frobware> dimitern: https://bugs.launchpad.net/juju-core/+bug/1566801
<mup> Bug #1566801: LXD containers /etc/network/interfaces as generated by Juju  gets overwritten by LXD container start <network> <juju-core:In Progress by frobware> <https://launchpad.net/bugs/1566801>
<frobware> dimitern: https://github.com/frobware/juju/tree/master-lp1581074
<davecheney> fwereade: https://github.com/juju/juju/pull/5415
<fwereade> davecheney, LGTM, thanks
<davecheney>     
<dimitern> voidspace: standup?
<voidspace> dimitern: morning
<mattyw> davecheney, morning dave - still up? regarding http://reviews.vapour.ws/r/4850/ ParseUnitTag is different
<mup> Bug #1582620 opened: juju-upgrade-mondo typo <juju-core:New> <https://launchpad.net/bugs/1582620>
<babbageclunk> dimitern: Ugh - any way in mongo to find out that a collection is a capped one?
<dimitern> babbageclunk: I'm sure there is a way, but I don't know off hand
<dimitern> babbageclunk: IIRC the txn collection is capped
<babbageclunk> dimitern: certainly the log collections are. I can't see any way to get CollectionInfo in the mgo docs.
<babbageclunk> dimitern: seems like I'll just have to check the error text - yay! And then guess the right size when I recreate.
<dimitern> babbageclunk: it seems Collection.Create only returns CollectionInfo
<babbageclunk> dimitern: I don't want to have to try to intercept the create calls so I can stash the infos somewhere.
<lazyPower> my new favorite thing:  juju debug-log --replay -T > bacon.log
<lazyPower> you guys/gals are killin it. <3
<lazyPower> and if this was always there, i just found it and it feels like my birthday all over again
<dimitern> lol lazyPower
<lazyPower> o/ dimitern
<dimitern> lazyPower: o/ it's always good to hear a happy user with all the issues we dealt with for 2.0 :)
<lazyPower> its been a schlog, happy to spread the cheer when I can :D
<lazyPower> I have some questions for you specific to spaces and how we can leverage them in k8s. I'd like to replace flannel with network-spaces in our kubernetes-core bundle. But we're a couple weeks out in terms of planning. I'll poke you in #juju when we're ready - prepare yourself ;)
<dimitern> lazyPower: k8s ?
<dimitern> aah :)
<dimitern> lazyPower: well spaces are well supported mostly on maas, with some support on aws
<lazyPower> ah right, its similar to storage in the fact its hamstrung by provider support
<lazyPower> good point
<lazyPower> welp thats something to think on
<dimitern> lazyPower: yeah, we plan to add support for spaces to public clouds first, but it will take some time
<mup> Bug #1582667 opened: i/o timeout when deploying/upgrading charm <juju-core:New> <https://launchpad.net/bugs/1582667>
<lazyPower> dimitern completely understood. no pressure :)
<lazyPower> i mean, networking is easy right?
<lazyPower> said no-one ever
<dimitern> lazyPower: :D indeed
<mup> Bug #1582714 opened: worker/resumer: test failure during CI <juju-core:New> <https://launchpad.net/bugs/1582714>
<mup> Bug #1582731 opened: github.com/juju/juju/state tests time out on centos <blocker> <centos> <ci> <regression> <test-failure> <unit-tests> <juju-core:Triaged> <https://launchpad.net/bugs/1582731>
<mup> Bug #1582731 changed: github.com/juju/juju/state tests time out on centos <blocker> <centos> <ci> <regression> <test-failure> <unit-tests> <juju-core:Triaged> <https://launchpad.net/bugs/1582731>
<mup> Bug #1582731 opened: github.com/juju/juju/state tests time out on centos and windows <centos> <ci> <regression> <test-failure> <unit-tests> <windows> <juju-core:Triaged> <https://launchpad.net/bugs/1582731>
<katco> natefinch: hey just wanted to say thank you for getting that bug addressed
<katco> natefinch: i'm sure ian is breathing a sigh of relief :)
<natefinch> katco: welcome, yeah, I was glad to be able to fix it in a timely manner
<natefinch> katco: trivial review of the deps change for that? http://reviews.vapour.ws/r/4852/
<katco> natefinch: tal
<katco> natefinch: ship it
 * perrito666 has sandpaper in his throat
<natefinch> perrito666: you should try eating food instead
<perrito666> natefinch: nah, I am too hardcore for that
<perrito666> I think Ill be making sign language for the next standup
<mup> Bug #1582714 changed: worker/resumer: test failure during CI <juju-core:New> <https://launchpad.net/bugs/1582714>
<natefinch> grep -r '"admin"' --include="*.go" . | wc -l
<natefinch> 231
<natefinch> screw dry, I wish we could at least manage something less than soaking wet
<natefinch> damp?  moist?
<katco> natefinch: now is your chance :) stick it somewhere sane
<natefinch> katco: yep
<thumper> histerical raisons
<thumper> there is a testing.AdminUser
<natefinch> oh, that's the best part.  Half of these are usernames, not model names
<natefinch> possibly more than half
<perrito666> natefinch: same happened with file urls
<natefinch> I don't know because THEY'RE JUST STRINGS
<perrito666> there was a bunch constructed by hand
<bdx> hows it going everyone? I feel like I'm missing something here ... is there a way around this -> https://github.com/juju/juju/issues/5411 ?
<natefinch> (â¯Â°â¡Â°ï¼â¯ï¸µ â»ââ»
 * perrito666 touches natefinch with the "well fix it" wand
<natefinch> thumper: package testing?
<perrito666> bdx: hello, sorry I dont know
<katco> bdx: we track our bugs on launchpad. here's a dupe with activity: https://bugs.launchpad.net/juju-core/+bug/1571593
<perrito666> dimitern: voidspace any of you is familiar with that error?
<mup> Bug #1571593: lxd bootstrap fails with unhelpful 'invalid config: no addresses match' <juju-release-support> <lxd-provider> <usability> <juju-core:Triaged> <https://launchpad.net/bugs/1571593>
<thumper> github.com/juju/juju/testing
<perrito666> katco: mm, we should go around closing the ones in gh every now and then
<katco> perrito666: we try. we need to turn off GH issues completely, but there always seems to be something more important to work on... :(
<perrito666> meh, I dont have supercow powers, I cant close the bug
<perrito666> I added the link to the lp one in the comments
 * katco closed the bug
<bdx> Oh my bad, I should be filing those in lp huh
<bdx> oops
<bdx> thanks
<katco> bdx: no worries, it's a common mistake. we don't make it clear at all
<dimitern> perrito666: that's lxd related
<perrito666> bdx: it is, I just saw the address part
<perrito666> sorry to disturb you :)
<dimitern> perrito666: it usually means lxdbr0 was misconfigured
<bdx> perrito666: I'm doing everything I can to not use lxdbr0
<bdx> but I guess I should of scouted out the bugs further
<bdx> shoot
<bdx> ha
<bdx> sorry
<bdx> dimitern, perrito666: is it a bug with lxd then?
<perrito666> bdx: not really, there is a previous step to be done but apparently we are not documenting it?
<perrito666> bdx: run lxd init
<perrito666> and your problem should go away after networking setup
<bdx> perrito666: yea, I've ran `lxd init` enough to no avail
<perrito666> mmm, very strange
<perrito666> try dpkg-reconfigure lxd and then restart lxd-bridge service
<bdx> perrito666: I can bootstrap lxd just fine when using lxdbr0
<perrito666> ah ok, then what do you do
<perrito666> to make it fail?
<bdx> perrito666: any host only bridge works for me ... its when I try to configure lxd to use a bridge on an external interface that it fails
<perrito666> mm, my knowledge of lxd does not go that far sorry
<perrito666> ericsnow: ^ do you know more about that?
<bdx> should the issue be raised with lxd then?
<ericsnow> perrito666: not really; perhaps tych0?
<perrito666> ericsnow: he is not here :)
<natefinch> thumper: sorry, my question was - why is a production value being defined in a testing package?
<perrito666> bdx: ill try to summon someone from lxd, otherwise, file the bug with juju since we are the ones that break in that case
<mup> Bug #1582798 opened: After bootstrapping, juju gui isn't automatically deployed <cpe-sa> <juju-core:New> <https://launchpad.net/bugs/1582798>
<mup> Bug #1582799 opened: Deploying from the cli api.jujucharms.com is not reachable <cpe-sa> <juju-core:New> <https://launchpad.net/bugs/1582799>
<babbageclunk> dimitern: I've got the state tests working for mongo3.2 now, except for TestSetAdminPassword.
<babbageclunk> thumper: ^^
<bdx> perrito666: the bug already exists .... its just not very specific to the nature of what actually happens -> https://bugs.launchpad.net/juju-core/+bug/1571593
<mup> Bug #1571593: lxd bootstrap fails with unhelpful 'invalid config: no addresses match' <juju-release-support> <lxd-provider> <usability> <juju-core:Triaged> <https://launchpad.net/bugs/1571593>
<bdx> I'll add in my bits to it
<dimitern> babbageclunk: awesome!
<dimitern> babbageclunk: is it as fast as 2.4 ?
<perrito666> bdx: the error seems to be the same but they state a different cause
<perrito666> could yolu please describe your case in that bug as a follow up?
<babbageclunk> dimitern, thumper: but this change between 2 and 3 means that I think Initialize will have to work differently: https://docs.mongodb.com/manual/core/security-users/#localhost-exception
<babbageclunk> dimitern: need to rerun the whole package again now that I've whacked all the moles - hang on.
<babbageclunk> dimitern: but within a minute of 2.4 definitely.
<babbageclunk> dimitern: which is better than 100x
<bdx> perrito666: surely
<perrito666> bdx: tx a lot
<bdx> np
<bdx> thank you
<dimitern> babbageclunk: great news then! \o/
<babbageclunk> dimitern: But so my final problem: at the moment Initialize connects to localhost without auth and creates the collections and indexes from allCollections(), and then at some point in the future sets an admin password - is that right?
<dimitern> babbageclunk: AIUI 'some point in the future' is at test(suite?) teardown/reset
<babbageclunk> dimitern: No, I mean in a real bootstrapped controller.
<babbageclunk> dimitern: almost all the tests run with auth turned off.
<dimitern> babbageclunk: ah, so the process goes - bootstrap with generated pwd, then when the controller's jujud agent starts, it resets the admin pwd once
<babbageclunk> ok - but in state.Initialize it does all of the collection and index creation before that, right? I think the admin password just needs to be done earlier.
<babbageclunk> dimitern: oh, no - I've found it in agentbootstrap.InitializeState - it's setting the password first, isn't it. Ok, I just need to fix the test then. Sweet!
<mup> Bug #1582801 opened: Juju debug-log returns error when using during bundle deployment <cpe-sa> <juju-core:New> <https://launchpad.net/bugs/1582801>
<mup> Bug #1582818 opened: SSH Key in MAAS GUI not working <maas> <ssh> <juju-core:New> <https://launchpad.net/bugs/1582818>
<elmo> davecheney: not sure what you mean; I approved your mail before flushing the queue
<bdx> perrito666, dimitern: this would explain alot -> https://github.com/juju/juju/blob/master/tools/lxdclient/client.go#L232-233
<perrito666> really? we are checking for eth0? that is quite easy to break
<perrito666> bdx: this check might be wrong https://github.com/juju/juju/blob/master/tools/lxdclient/client.go#L241-248
<natefinch> quick review anyone? http://reviews.vapour.ws/r/4854/
<bdx> yea, yea, I saw the whole part after the comments .... cry cry
<redir> fwereade: yt?
<natefinch> perrito666, katco, ericsnow: super easy, I promise: http://reviews.vapour.ws/r/4854/
<perrito666> natefinch: rviewing
<perrito666> natefinch: what prompts this change?
<ericsnow> natefinch: there, that wasn't so bad <wink>
<natefinch> perrito666: Mark
<perrito666> say no more
<natefinch> ericsnow: yeah, turns out there actually was a constant, it just was hard to find amongst all the other "admin" references
<perrito666> natefinch: reviewed
<natefinch> perrito666: good catch on that comment https://pbs.twimg.com/media/B3qIJLFCcAEJLWm.jpg
<perrito666> natefinch: I believe that I lack the etnicity to catch that joke :p
<tych0> bdx: ericsnow: i think you have to use lxdbr0 right now
<natefinch> perrito666: the label says rice, the container contains cookies
<perrito666> pass it through the I am southamerican filter
<tych0> there's no way to configure it otherwise
<natefinch> perrito666: it's about comments being out of date
<perrito666> natefinch: I assumed they where rice cookies (things that happen when you live with celiac people)
<perrito666> by default I suspect of any sort of bakery product not made/bought by me to be rice based :p
<natefinch> perrito666: fairly uncommon here
<perrito666> here, too, unless here==my house
<mup> Bug #1582841 opened: remove check for lxdbr0 <juju-core:New> <https://launchpad.net/bugs/1582841>
<bdx> tych0, perrito666, dimitern: I named the bridge on my external interface lxdbr0 .. this tricked juju, and lxd, and got me bootstrapped :-)
<perrito666> lol
<bdx> so simple, so sweet
<natefinch> just found our 15 month old in an awkward ball, face down in a chair, unresponsive.... turned out he'd just fallen asleep and kind of slumped into a pile.
<natefinch> and unresponsive only because he was so tired
<perrito666> natefinch: and how is your panic attack?
<natefinch> perrito666: fine once it was established he was sleeping, but geez
<redir> when do I want to return errors.Trace(error) vs. error ?
<redir> is there a rule of thumb?
<redir> katco: natefinch ericsnow ^^
<katco> redir: .Trace just adds stack information to the underlying object
<natefinch> redir: basically always trace
<katco> redir: really not a reason to not use it
<katco> redir: .Annotate et. al. will do it for you, so you don't need to wrap those in .Trace
<redir> OK just modifying a func that does both and wasn't sure why.
<mup> Bug #1582881 opened: destroying a subordinate returns an error but seems to work <juju-core:New> <https://launchpad.net/bugs/1582881>
<natefinch> redir: probably started being written before we had the errors library
<katco> redir: probably targeted fixes. .Trace is only ~2y old
<redir> should I .Trace it in the drive by?
<natefinch> redir: if it's not too many of them, that's fine.
<katco> redir: yeah i'd say those are easy to review, so bring the function up to code (no pun intended)
 * redir nods. just one of three...easy enough.
<natefinch> gah, why is it get-model-config and not show-model-config? :/  everything else is show :/
<tvansteenburgh> why doesn't `juju block` accept a -m arg?
<tvansteenburgh> is it an oversight? am i right to assume that the block command does indeed apply to one specific model?
<natefinch> tvansteenburgh: not sure
<natefinch> tvansteenburgh: it definitely is per model according to the comments
<tvansteenburgh> natefinch: okay, thanks
<natefinch> tvansteenburgh: must be an oversight... I think because it's built as a super command (i.e. juju block destroy-model .. destroy model is a command, not an argument)
<natefinch> tvansteenburgh: can you file a bug?
<tvansteenburgh> natefinch: sure thing
<ericsnow> anastasiamac_: ping
<anastasiamac_> ericsnow: o/
<anastasiamac_> ericsnow: m making coffee - 7.40am.. bbiab
<ericsnow> anastasiamac_: np
<ericsnow> anastasiamac_: just thinking we may want to postpone our meeting until the syslog stuff is more settled
<katco> anastasiamac_: was going to suggest the same
<anastasiamac_> katco: ericsnow: sounds good \o/
 * redir doesn't know about meeting
<anastasiamac_> i'll move the meetings
<mup> Bug #1582892 changed: `juju block` doesn't accept -m arg <juju-core:Invalid> <https://launchpad.net/bugs/1582892>
<anastasiamac_> ericsnow: katco: altho m not convinced that the user stories will actually change :D
<anastasiamac_> redir: i'll fill u in during standup
<ericsnow> anastasiamac_: yeah, probably not :)
<anastasiamac_> redir: perrito666: m happy to have a standup earlier if it suits u
<anastasiamac_> ericsnow: m still keen to talk to u if u want :D but will move the actual meeting booking
<perrito666> anastasiamac_: works for me
<anastasiamac_> redir: want to do standup now-ish?
<redir> anastasiamac_: fine by me, running tests now so I have time
<redir> :)
<perrito666> I am in the room
<mup> Bug #1582892 opened: `juju block` doesn't accept -m arg <juju-core:Invalid> <https://launchpad.net/bugs/1582892>
<anastasiamac_> redir: perrito666: m going to tanzanite now then \o/
<mup> Bug #1582799 changed: Deploying from the cli api.jujucharms.com is not reachable <cpe-sa> <juju-core:Invalid> <https://launchpad.net/bugs/1582799>
<mup> Bug #1582892 changed: `juju block` doesn't accept -m arg <juju-core:Invalid> <https://launchpad.net/bugs/1582892>
<mup> Bug #1582799 opened: Deploying from the cli api.jujucharms.com is not reachable <cpe-sa> <juju-core:Invalid> <https://launchpad.net/bugs/1582799>
<mup> Bug #1582799 changed: Deploying from the cli api.jujucharms.com is not reachable <cpe-sa> <juju-core:Invalid> <https://launchpad.net/bugs/1582799>
#juju-dev 2016-05-18
<mup> Bug #1582948 opened: juju status: base statuses of "unknown" are not instilling confidence <cdo-qa> <juju-core:New> <https://launchpad.net/bugs/1582948>
<davechen1y> yay, launchpad is having a fit and CI jobs are failing
<natefinch> wallyworld: the charmstore should just set origin to store on the resource data it gives back. If it's possible some other jazzy values could be set in the future, let's just set the right thing now and not have to worry about it later.  Having a field in the return struct that is explicitly not set is galling
<wallyworld> natefinch: that can be done in charmrepo right?
<wallyworld> natefinch: just saw the admin->controller rename - did you check with QA to see what impacts it would have on their scripts?
<natefinch> wallyworld: got a ping from cheryl to hold up, so I'm not landing it for now. It honestly didn't occur to me that it would break their scripts.... I kinda wish we didn't have all these implicit dependencies in the CI code :/
<natefinch> wallyworld: about the origin - it's the charmstore code itself that needs to return "store"
<wallyworld> natefinch: well, it's to be expected isn't it? the model name is a part of the output we need to query
<wallyworld> natefinch: the charmstore won't do that I don't think so we'll just need to do it in charmrepo for now
<natefinch> wallyworld: I'll fix it for now, but I think it's wrong.  Either the charmstore should always populate it, or never populate it.  Not populating it some of the time and expecting everyone to just understand that means origin=store is just plain bad.
<wallyworld> natefinch: not disagreeing :-) need to follow up this end. this will get us out of trouble though for now
<natefinch> wallyworld: trouble for deleting a value that isn't set that only we read....
<natefinch> http://data.whicdn.com/images/104484357/original.gif
<wallyworld> natefinch: it will be set in the future, but just not now
<natefinch> https://imgflip.com/readImage?iid=9310200
<davechen1y>         if tools.SHA256 == "" {
<davechen1y>                 logger.Warningf("no SHA-256 hash for %v", tools.SHA256)
<davechen1y> spot the bug
<voidspace> dimitern: ping
<dimitern> voidspace: pong
<voidspace> dimitern: I have a test for linklayerdevices that no longer fails, and I think the new behaviour is *correct*, but want to run it by you
<dimitern> voidspace: sure
<voidspace> dimitern: there is a test that calling SetLinkLayerDevices with a matching name and provider id to an existing linklayer device fails validation
<voidspace> dimitern: this used to fail validation because the provider id matched an existing one which was checked before everything eslse
<voidspace> dimitern: *however*, if the name matches (i.e. the docID is the same) it's treated as an update not an insert
<voidspace> dimitern: and as the providerid is already set in the original the insert doesn't attempt to change the provider id
<voidspace> dimitern: so the update works and the test *fails*
<voidspace> dimitern: however, because this is actually an update not an insert I think the new behaviour is correct
<dimitern> voidspace: well, that test won't be relevant anymore
<voidspace> dimitern: yep, just checking you agreed I could just remove the test
<voidspace> dimitern: I'm adding a new test that an update that attempts to add a duplicate provider id fails
<dimitern> voidspace: because it tests 'failing validation', whereas now we fail as a side-effect of the txn.Ops triggering ErrAborted
<dimitern> voidspace: I'd like to have a look at the code still, but so far your plan sounds good
<voidspace> dimitern: cool
<dimitern> voidspace: (when you're ready ofc)
<voidspace> dimitern: I think all tests now pass
<voidspace> dimitern: doing a run to check
<voidspace> if they pass I'll propose the branch
<dimitern> voidspace: sweet!
<voidspace> dimitern: by the way - current behaviour for an update that attempts to change ProviderID is that the change is silently ignored
<voidspace> dimitern: shall I change that to an error?
<voidspace> (this is the current *pre-existing* behaviour - not a change I've made)
<dimitern> voidspace: it should only be an error if the original prID != from the new one we're trying to set (and the org is also != "")
<voidspace> dimitern: yep, exactly
<voidspace> dimitern: currently if original != "" then the new one is just ignored
<voidspace> dimitern: ok, all state tests pass - I'll make this change and a test and then propose
<dimitern> voidspace: please make sure you also run worker/provisioner/ and apiserver/common/networkingcommon/ tests as well to double check
<voidspace> dimitern: well, the merge attempt runs everything...
<dimitern> voidspace: true :)
<davechen1y> https://github.com/juju/testing/pull/99
<voidspace> dimitern: http://reviews.vapour.ws/r/4859/
<mup> Bug #1583109 opened: error: private-address not set <juju-core:New> <https://launchpad.net/bugs/1583109>
<voidspace> dimitern: state, apiserver and provisioner tests pass
<dimitern> voidspace: otp, will look in a bit
<mup> Bug #1583109 changed: error: private-address not set <juju-core:New> <https://launchpad.net/bugs/1583109>
<mup> Bug #1583109 opened: error: private-address not set <juju-core:New> <https://launchpad.net/bugs/1583109>
<dimitern> voidspace: reviewed
<jamespage> dimitern, not sure whether you have cycles but that bug ^^ is killing our CI atm...
<dimitern> jamespage: oh, ok I'll have a look in a bit
<jamespage> dimitern, thankyou
<dimitern> jamespage: it looks like the machine hosting keystone/0 did not start ok so that's why the unit had no private address
<jamespage> dimitern, nope - the machine did start ok
<jamespage> its running the install hook when that happens
<jamespage> dimitern, I have the console output for the machine - one sec
<dimitern> jamespage: I can see machine "7" stuck in "pending" from the linked paste of juju status
<jamespage> dimitern, I think that's the effect the error has...
<jamespage> dimitern, https://openstack-ci-reports.ubuntu.com/artifacts/test_charm_pipeline_amulet_full/openstack/charm-cinder/317913/1/2016-05-18_09-29-55/test_charm_amulet_full/logs/cinder-0-nova-console-1.bz2
<jamespage> thats the console log from the machine
<dimitern> jamespage: that looks like the log for machine-1 do you have the log of machine-7 from that same run?
<jamespage> dimitern, sorry crossed tests - that was from a different failed run
<jamespage> dimitern, https://openstack-ci-reports.ubuntu.com/artifacts/test_charm_pipeline/openstack/charm-ceph/317910/1/2016-05-18_08-48-05/test_charm_amulet_smoke/logs/keystone-0-nova-console-7.bz2
<dimitern> jamespage: I'm looking at https://openstack-ci-reports.ubuntu.com/artifacts/test_charm_pipeline/openstack/charm-ceph/317910/1/2016-05-18_08-48-05/test_charm_amulet_smoke/juju-stat-yaml-collect.txt
<jamespage> dimitern, https://openstack-ci-reports.ubuntu.com/artifacts/test_charm_pipeline/openstack/charm-ceph/317910/1/2016-05-18_08-48-05/index.html
<dimitern> jamespage: ah. ok
<jamespage> for the full index of data
<jamespage> dimitern,
<jamespage> machine-7[3059]: 2016-05-18 09:13:45 INFO juju.worker runner.go:275 stopped "machiner", err: setting machine addresses: cannot set machine addresses of machine 7: state changing too quickly; try again soon
<jamespage> machine-7[3059]: 2016-05-18 09:13:45 DEBUG juju.worker runner.go:203 "machiner" done: setting machine addresses: cannot set machine addresses of machine 7: state changing too quickly; try again soon
<jamespage> machine-7[3059]: 2016-05-18 09:13:45 ERROR juju.worker runner.go:223 exited "machiner": setting machine addresses: cannot set machine addresses of machine 7: state changing too quickly; try again soon
<jamespage> machine-7[3059]: 2016-05-18 09:13:45 INFO juju.worker runner.go:261 restarting "machiner" in 3s
<jamespage> seems symptomatic of when this happens
<dimitern> jamespage: right! that I know about
<jamespage> dimitern, one might cause the other?
<dimitern> jamespage: unfortunately I wasn't able to reproduce it at will, seems quite intermittent
<jamespage> dimitern, intermittent - yes
<jamespage> dimitern, but I hit this three times today - bear in mind we're spinning 1000's of units of charms a day...
<dimitern> jamespage: indeed - that error causes the MA to bounce repeatedly, before setting status to "started", and because setting the addresses failed both the machine and unit will lack a private address
<dimitern> jamespage: well, it will help to collect the machine-0 logs with logging-config='<root>=TRACE' when it happens
<jamespage> beisner, can we turn that on?
<jamespage> ^^
<dimitern> jamespage: beisner: juju set-env logging-config='<root>=TRACE'
<dimitern> (assuming 1.25)
<beisner> dimitern, will enable that for all future jobs
<dimitern> jamespage: that will produce tons of extra logs, beware, but will also include details down to the actual mgo transactions
<beisner> we'll need to turn it back off as soon as we figure out what's going on
<dimitern> beisner: cheers! with your setup it should be easy to catch why it happens, however intermittent it might be
<beisner> dimitern, we have enough activity that we're seeing it quite often actually
<beisner> dimitern, with each deploy being 10-25 units, chances are, 1 of those units will have this happen on about half the jobs.
<beisner> so we should be able to repro with logs in short order
<dimitern> beisner, jamespage: when it happens again, machine-0.log (where the apiserver is) and machine-X.log (the one "pending") will both be very useful
<beisner> dimitern, our bot can't automatically grab the log from machine-x because the agent is awol, it has no address, and we can't ssh into it.
<beisner> so that will take a manual reproduction
<dimitern> beisner: well, can you get to the juju's machine-0.log ?
<beisner> dimitern, definitely
<dimitern> beisner: sweet! that's the important one actually (where the txns are logged)
<beisner> jamespage, dimitern - hrm.  this will be extremely tricky as we can't set-env logging until after bootstrap, but bootstrap is done by amulet, after our script has left the building.
<beisner> dimitern, is there an environments.yaml way to do this?
<dimitern> beisner: sure, add `logging-config: '<root>=TRACE'` to the env.yaml
<beisner> dimitern, ok cool  juju run sed fu for the win.  we already had that =DEBUG :-)    all set here jamespage
<dimitern> beisner: thanks!
<dimitern> beisner, jamespage: please, let me know when you repro the issue with the extra logging
 * dimitern steps out for ~1h
<mup> Bug #1583170 opened: `juju help placement` does not exist <juju-core:New> <https://launchpad.net/bugs/1583170>
<OerHeks> #1583170 seems like #1580946
<mup> Bug #1583170: `juju help placement` does not exist <juju-core:New> <https://launchpad.net/bugs/1583170>
<mup> Bug #1580946: Juju 2 help commands for constraints or  placement return ERROR unknown command <helpdocs> <juju-core:Fix Committed by cherylj> <https://launchpad.net/bugs/1580946>
<tvansteenburgh> OerHeks: definitely. i didn't see that
<OerHeks> i got distracted by juju/juju2
<mup> Bug #1583170 changed: `juju help placement` does not exist <juju-core:Invalid> <https://launchpad.net/bugs/1583170>
<alexisb> dimitern, ping
<dimitern> alexisb: hey
 * perrito666 returns from the dead
<lazyPower> wb zombie perrito666
<perrito666> lazyPower: tx, hey are those brains you have there?
<lazyPower> indeed, have some seasoning salt
<lazyPower> you're going to inherit all my charms once you eat my brains though... i setup a deadman switch. #yolo
 * perrito666 eats a cracker
<lazyPower> ;) i thought that might dissuade you
<natefinch> katco, ericsnow: oh yeah, I also did the rename admin model to controller, but it was put on hold.
<katco> natefinch: mark doesn't want it anymore?
<natefinch> katco: not sure. Cheryl posted to the PR "Please don't land this just yet. We're still getting feedback on this requested change."
<katco> natefinch: k, thanks for doing that anyway
<natefinch> katco: I should probably land all but the actually constant name, and then all we'd need to do is change the constant in another PR :)
<natefinch> katco: but I'll wait for now, see how it shakes out
<katco> natefinch: hey that's a good idea
<dimitern> babbageclunk, voidspace, dooferlad: anyone still around? I'd appreciate a review on this (mostly removals of legacy/obsolete/unused code): http://reviews.vapour.ws/r/4865/
<dimitern> that's a prerequisite to fixing bug 1574844
<mup> Bug #1574844: juju2 gives ipv6 address for one lxd, rabbit doesn't appreciate it. <conjure> <juju-release-support> <landscape> <lxd-provider> <juju-core:In Progress by dimitern> <rabbitmq-server (Juju Charms Collection):New> <https://launchpad.net/bugs/1574844>
<babbageclunk> Sure - looking now
<natefinch> katco: here you go: branched, then put controller model name back to what it was before: https://github.com/juju/juju/pull/5428
<dimitern> babbageclunk: thanks!
<natefinch> ericsnow: this is your weekly notification that reviewboard is broken
<voidspace> dimitern: I'm still around
<voidspace> dimitern: ah, babbageclunk beat me to it
<ericsnow> natefinch: looks like it's just you <wink>
<dimitern> voidspace: I'm sure you'd like it though :)
<natefinch> ericsnow: weird: https://github.com/juju/juju/pull/5428
<ericsnow> natefinch: yeah, looking at it
<babbageclunk> dimitern: reviewed, looks great!
<dimitern> babbageclunk: awesome, tyvm!
<babbageclunk> dimitern: (Well, there was one comment.)
<babbageclunk> dimitern: In exchange, can you explain to me how watchers work? :)
<dimitern> babbageclunk: sure, I can try :)
<babbageclunk> dimitern: So the remaining failures I have of my changed code against mongo2.4 are watchers.
<dimitern> babbageclunk: basically any change to a collection as a result of runing []txn.Op is reported by watchers
<dimitern> babbageclunk: and the changes (IIRC) are detect by looking into the txnLog
<dimitern> detected*
<babbageclunk> dimitern: ok, so they're goroutines that watch txns.log with specific filter criteria?
<dimitern> babbageclunk: yeah, more or less - the nitty gritty low level details are in state/watcher/ (rather than state/watcher.go)
<babbageclunk> dimitern: Hmm. I clear out txns.log (actually, since it's a capped collection I drop and recreate it).
<babbageclunk> dimitern: ...between tests I mean.
<voidspace> dimitern: hah, yeah - looks good
<dimitern> babbageclunk: there's also the "presence" thingy - which is related to watchers, but I'm less familiar with it (can't remember whether it was tracking active agent connections or life cycle changes alive->dying->dead in a collection)
<voidspace> dimitern: can you really remove stuff from the agent/format-1.18.go though?
<dimitern> babbageclunk: there's more to txns than the log, there are a few other internal collections used to track txn state, what was applied, whether it's being applied or aborted, etc (something called "stash" IIRC)
<dimitern> voidspace: yeah, I think so - don't let the name mislead you :) that's the current format we're using
<voidspace> dimitern: ah....
<babbageclunk> dimitern: Thanks, that gives me some stuff to go on with.
<voidspace> dimitern: my only worry would be that this might cause IPv6 addresses to leak out unwanted
<voidspace> dimitern: but as far as I can tell that was a risk anyway
<voidspace> dimitern: so I don't think this makes it worse
<dimitern> voidspace: there are no changes to behavior - the removed code paths deal with preferIPv6=true, but as I pointed out in the PR description, it was hard-coded to false some time ago now
<voidspace> dimitern: heh, ok
<katco> natefinch: sorry was otp. lgtm
<natefinch> katco: thanks :)
<dimitern> babbageclunk: I've fwd you a couple of ML discussions around txns and pruning logs
<babbageclunk> dimitern: Changing tack a bit - I've got a test that's failing here: https://github.com/juju/juju/blob/master/state/volume_test.go#L354
<babbageclunk> dimitern: Saying got []string{"0/0", "0/1"}, expected []string{"0/1", "0/2"}
<babbageclunk> dimitern: What are the values in the change list? Are they units?
<dimitern> babbageclunk: ah, that sounds like a sequence is reset to 0
<dimitern> babbageclunk: so some entities, e.g. machines and units, but also others rely on auto-incremented id coming from the sequences collection
<babbageclunk> dimitern: Sequences sound like some state that I might be clobbering now that wasn't before?
<babbageclunk> dimitern: Aha, that sounds like a possibility. I'm going to dump what's in that collection in successful and failing runs.
<dimitern> babbageclunk: yeah, it's either that or the test itself relies on volume entities starting from 1 rather than 0?
<babbageclunk> dimitern: Yeah, those are the values in the assertion.
<babbageclunk> dimitern: So maybe there's something that makes sure sequence is populated appropriately that I'm blowing away?
<dimitern> babbageclunk: I doubt that - but have a look at StorageStateSuiteBase and/or ConnSuite it uses for possible clues
 * dimitern hits eod
<mup> Bug #1583274 opened: Openstack base bundle 42 fails to start rabbitmq when deployed with Juju/MAAS 2.0 <cdo-qa> <deploy> <openstack> <juju-core:New> <https://launchpad.net/bugs/1583274>
<redir> I think I need another coffee before looking at your PRs ericsnow
<ericsnow> redir: k :)
<redir> fwereade__: yt?
<marcoceppi> wallyworld: problem
<marcoceppi> katco: I've tried to attach a resource
<marcoceppi> and it's not working
<katco> marcoceppi: ok. can you pastebin the steps or something?
<marcoceppi> katco: http://paste.ubuntu.com/16498534/
<katco> marcoceppi: ty
<katco> marcoceppi: i think you have to specify the --resource flag for each resource when publishing
<katco> marcoceppi: attaching just make the blob available to be referenced
<katco> marcoceppi: publishing is the act of coupling the charm in the channel with a revision of a resource that has been attached
<katco> marcoceppi: does that make sense?
<marcoceppi> katco: what's the param for --resource in publish?
<katco> marcoceppi: <resource name>-<revision>
<katco> marcoceppi: `charm list-resources ~marcoceppi/charm-svg` lists the revisions as -1. that's interesting.
<wallyworld> katco: marcoceppi: i noticed the -1 thing too and assumed it was because no resources had been published yet
<katco> wallyworld: marcoceppi: ah that's exactly what it is. but: charm list-resources ~marcoceppi/charm-svg -c development
<katco> wallyworld: marcoceppi: also lists -1. because you don't really publish to the development channel, that's just a dumping ground
<wallyworld> katco: i get a macaroon error
<katco> marcoceppi: can you try: charm publish ~marcoceppi/charm-svg-3 --resource python-jujusvg-1 --resource webapp-1
<katco> wallyworld: what version of the charm tool are you on?
<ericsnow> natefinch: FYI, looks like you already have a review request up (unpublished?  discarded?) for that commit hash
<wallyworld> katco: recent version, casey is checking
<mup> Bug #1255799 changed: juju  installing cloud-tools archive on non-bootstrap nodes <cloud-archive> <manual-provider> <juju-core:Won't Fix> <https://launchpad.net/bugs/1255799>
<mup> Bug #1258132 changed: [manual] bootstrap fails in livecd due to juju-db not starting <manual-provider> <juju-core:Won't Fix> <https://launchpad.net/bugs/1258132>
<mup> Bug #1583304 opened: upload-tools appends instead of increment version numbers <ci> <packaging> <juju-core:Triaged> <https://launchpad.net/bugs/1583304>
<marcoceppi> katco: thanks! wallyworld it's pushed
<wallyworld> marcoceppi: ty, will look. i can't log in to charm store atm though. sigh
<marcoceppi> wallyworld: sounds like a personal problem?
<wallyworld> marcoceppi: maybe, but casey also can't log out
<wallyworld> so there's something weird happening
<redir> story of my life wallyworld
<natefinch> ericsnow: thanks... I really wish reviewboard/the bot would handle that differently.  it's a different PR, it should just get a new review
<ericsnow> natefinch: agreed
 * perrito666 postpones all his meetings because he lost the ability to speak in english for long periods
<natefinch> lol
<natefinch> review anyone? http://reviews.vapour.ws/r/4801/  katco, this is the choose-a-series logic one that you already reviewed once.
<katco> natefinch: tal
<katco> natefinch: did you just move the code to different files? hard to see the diff
<natefinch> katco: yes, and added comments to the fields in series selector.  Mostly I punted on the supportedSeries changes, because it would complicate this code due to things that are really outside its purview
<katco> natefinch: understand. ship it
<natefinch> katco: thanks
<natefinch> katco: huzzah, now the change admin model name to "controller" is a single line change: https://github.com/juju/juju/pull/5419/files
<katco> natefinch: :) sometiems DRY is a good thing
<katco> ericsnow: hey, why are we registering the components in our tests? e.g. cmd/juju/service/bundle_resource_test.go ?
<ericsnow> katco: because of state and the full-stack testing
<katco> ericsnow: can you elaborate a bit? fwereade__ got me curious
<ericsnow> katco: if you try to do resource-related stuff in state and resources haven't been registered in state then it blows up
<ericsnow> katco: some of our full-stack tests do resource-related stuff (e.g. bundle_resource_test.go)
<katco> ericsnow: ah, so some of the existing tests, which are full stack, deal with state which expects resources to be there. therefore it must be registered.
<ericsnow> katco: yep
<katco> fwereade__: there is your answer. we are not in a final state ^^
<katco> fwereade__: this is a mid-step solution
<perrito666> anastasiamac_: redir hey, I can talk for more than a few mins, ill miss standup
<perrito666> I got restore working, now working on the tests, cheers
<redir> hope you feel better RSN perrito666
<anastasiamac_> perrito666: well done with restore \o/ get better :D
#juju-dev 2016-05-19
<anastasiamac_> davecheney: m a bit concerned with the work that you are doing in returning *all* errors that hav previously been logged
<anastasiamac_> davecheney: what is the bug that set u on this warpath?
<anastasiamac_> davecheney: for example, m not convinced that callback failure that meant to set the status should really fail the whole operation of container creation
<anastasiamac_> davecheney: m sure that there are other instances where encounting error should not affect the whole operation. m specifically thinking of simplestreams but thre are others...
<davecheney>                 if err != nil {
<davecheney>                         logger.Warningf("FIXME: ignoring unexpected CIDR format %q: %v", netConfig.CIDR, err)
<davecheney> anastasiamac_: here is my philosophy
<davecheney> if an error occurs one of two things happen
<davecheney> a. the error means you cannot continue processing because you are missing the requireed data
<davecheney> b. the error does not stop processing
<davecheney> if a, then we don't want to log the error asynchrnously into a log file, we want to return it to the caller synchronusly
<davecheney> if b, then it isn't an error because we can continue
<davecheney> anastasiamac_: can you point out a specific part of the change you are talking about
<anastasiamac_> davecheney: for example,  container/lxc/lxc.go, line 257... this now means that if u could not successfully callback to set the status, you'd fail container creation
<anastasiamac_> davecheney: m looking at what u've committed yesterday... and m a bit puzzled... some of the areas did not seem like they warrented to throw an error... and I recall considerable amount of logic in some areas where it was ok to get an error and continue (ur b)
<anastasiamac_> so we'd log error at another level (like warning or info) and keep going..because it's not significant enought to do anything about but might be of interest during debug
<davecheney> anastasiamac_: this line ? https://github.com/juju/juju/commit/19f0dbb069916c83007b3f7293e079cb5e450fa4#diff-edf2b984c531037601cf518c0a0b039eL256
<davecheney> if we can keep going then it isn't an error
<anastasiamac_> davecheney: yes, this line. that's the point.. it's not a show-stopper. it's might be useful for when you are diagnosing a field failure - what has happenned leading to my failure - but it's not signifiant enough to stop the operation...
<anastasiamac_> we have millions of places like this
<davecheney> yes, and they all need to be fixed
<davecheney> here is my rule of thumb
<davecheney> no warnings, ever
<anastasiamac_> a call to some function may fail but we either have other means of achieving what we want or we don't really care enough
<davecheney> it's either something the user needs to know about because they need to fix it, or we don't say anything
<davecheney> so, if we don't care if it succeeds or fails,
<davecheney> 1. why do we call it
<davecheney> 2. why do we log the result
<anastasiamac_> logs are not jsut for user.. they are also for diagnosing field failures... warning means "this fails, we may need to worry about it if something else goes worng or at a later stage or <insert condition here>"
<davecheney> no, i'm sorry, my policy on warnings is absolute
<davecheney> no warnings, ever
<davecheney> it's either an error or an info message
<anastasiamac_> i do think that this should not be tackled at a global level and cetainly not without further discussion
<davecheney> i don't think the ideas of not having warnings is contraversial
<davecheney> i'll send a PR to fix lxc/lxc.go
<anastasiamac_> sure... m not talking about log levels really \o/ my concern is that you are returning errors where they should not be propagated
<anastasiamac_> plz consider all other places where u have started throwing erros too \o/ u'd know best what was touched :D
<davecheney> what are you asking ?
<davecheney> the code was reviewed, all the tests pass, juju.fail is clear
<anastasiamac_> i there are any other places similar to https://github.com/juju/juju/commit/19f0dbb069916c83007b3f7293e079cb5e450fa4#diff-edf2b984c531037601cf518c0a0b039eL256
<davecheney> this sounds like fear that something that we don't know about might break because we don't know about it because its scarey adn we don't trust out code review or our tests
<anastasiamac_> plz revert them whenevr possible.. (i dunno if there are - i trust u to know) \o/
<anastasiamac_> as for log levels, there is a team meeting tonight at our 8pm (well, bne at least)
<anastasiamac_> let's discuss it then \o/
<anastasiamac_> davecheney: i agree that there mayb some places where we are swallowing errors..but i'd like these to be fixed on a per-need basis, prefereably with a bug backing the need
<davecheney> anastasiamac_: https://github.com/juju/juju/pull/5432
<anastasiamac_> davecheney: FWIW, all the places where we appear to swallow an error need to have a clear explanation as to why...
<davecheney> i agree
<anastasiamac_> davecheney: i have seen instances where these are explained in the review comments... but i believe explanantion needs to be in the codebase
<anastasiamac_> davecheney: \o/
<davecheney> but stil, don't log errors at warning level
<anastasiamac_> davecheney: plz come to team meeting - let's talk :D
<davecheney> anastasiamac_: all the decision makers will be asleep
<davecheney> they are all in the US timezone
<anastasiamac_> davecheney: i don't think it requires executive decision :D just ocnsensus and europe will b online
<davecheney> why do we need to have a call
<anastasiamac_> bleh.. consensus :D
<davecheney> can't we just talk about it now
<davecheney> or send an email ?
<anastasiamac_> email is just as good but f-2f may be more efficient
<anastasiamac_> personal preference, for majority of cases - errors should b logged at error-level
<anastasiamac_> i just can;t think of a places where it would not need to.. and don;t want to omit someplaces that other ppl mayb aware of :D
<davecheney> have a look at the branches i've been landing
<davecheney> most of this is s/Warningf/Errorf
<davecheney> with the exceptoins where we do something like
<davecheney> Warningf("ignore error, carrying on anyway")
<davecheney> in whcih case that is debugging information because there is nothing a user can do with this knowledge
<davecheney> that's just for us developers
<anastasiamac_> well, I think that as long as there is a good explanation in the comment and in the log message as to why an error is ignored, whether it it's logged t Warning or Error level is less important... Explanation is what really matters :D
<natefinch> FWIW... I hate errors in logs
<natefinch> unless it's a showstopper
<anastasiamac_> natefinch: warning might be better as we aer not treating it as an error ;D
<anastasiamac_> agreed \o/ all errors proper should be logged at error-level
<natefinch> nope, I'm with Dave on that one.  Warnings are dumb.  Debug, Info, Error, and error should almost never be used
<natefinch> the problem is that, to anyone who is not the specific developer who wrote that warning/error log... it's impossible to know if an ERROR is really an ERROR, or just "hey, something went wrong, that's ok"
<anastasiamac_> yeah :D i bbelieve that all traffic lights should loose yellow - u other stop or u go :)
<davecheney> anastasiamac_: there is no need to be facetious
<davecheney> here is my rule of thub
<natefinch> yellow doesn't mean "maybe it's ok, maybe it's not"
<natefinch> but that's what warning is
<davecheney> tell the user if there is something they need to do
<anastasiamac_> warning-level is like yeelow :D
<davecheney> sorry, no, that wasn't right
<anastasiamac_> m not being f** :D
<davecheney> tell the user if there is something they can do
<davecheney> if there is nothing the user can do, then don't tell them
<davecheney> either carry on, or the program quits
<davecheney> anastasiamac_: for reference, http://dave.cheney.net/2015/11/05/lets-talk-about-logging
<anastasiamac_> davecheney: m not convinced that in ideal world user should need to look in the logs (only when something went horribly wrong, the logs should be trotted)
<anastasiamac_> user should receive an intelegent feedback..
<natefinch> the logs are for developers
<natefinch> or extreme power users
<anastasiamac_> +100 \o/
<davecheney> anastasiamac_: logs are for develoeprs
<davecheney> the return value of a function is for the user
<anastasiamac_> davecheney: i hope u mean return value of an operation... our functions should not matter to user eaither
<davecheney> function/method/opertation, what'ever works for you
<anastasiamac_> davecheney: granularity is different
<davecheney> i disagree
<anastasiamac_> if as auser I want to add a machine, i don't care if u r calling 100 functions underneath (and some of the functions may not make sense to me)
<davecheney> i agree
<davecheney> that is what I meant
<davecheney> an operation either worked or it didn't
<davecheney> if it didn't it returns an error
<anastasiamac_> \o/ m glad we agree
<davecheney> it should not fail, but rturn no error while poopping out some warning messages on the side
<davecheney> this is what I am working on fixing at the moment
<natefinch> logging at ERROR level is confusing to *developers* though.  Does it mean juju is in a bad state?  What *does* it mean?  If we can ignore it, it must not really be that much of an error.  Warning is just as bad.
<natefinch> WARNING juju.worker.uniter upgrade126.go:26 no uniter state file found for unit unit-resource-0, skipping uniter upgrade step
<natefinch> is my juju broken? is it a bug?
<natefinch> I presume that is actually a perfectly fine state for juju to be in... but I don't know
<anastasiamac_> i think it's ok to say "warning: blah blah did not happen, will try bleh".. and as a user m ok to see these go by :D
<anastasiamac_> it's kind of like saying "my 1st preference is this but it did not happe, i'll try my 2nd beest"
<davecheney> natefinch: exactly
<anastasiamac_> (without the typos)
<davecheney> anastasiamac_: so in that case that's just debugging information
<anastasiamac_> not necessarily dbugging (althou it can be).. it's more of an operation progress :D
<a123> I'm seeing something very odd with juju2.0 while installing charms. A day ago, my charms were installing fine, then today one is failing in the cloud-init section when trying to run jujud-machine-xx. After connecting to the machine and running initctl reload-configuration, I can now start the job. Otherwise, the error is 'Unknown job' Any ideas?
<davecheney> anastasiamac_: here is my rule of thumb
<davecheney> when reading a log file, if you every reach for grep -v to filer out "operating in progress" informational messges
<a123> As far as I can see, the logs are identical between the charms which worked(ie. the cloud-init-output.log) and the one that doesn't. It appears upstart doesn't recognize the script.
<davecheney> they shouldn't be logged in the first place
<davecheney> every single line reported to the user must be something actionable
<davecheney> "i'm still working on this" is not actionable
<natefinch> man, so much of our logging is utter crap.  I mind it less when it's at debug level, because, well, it can be useful for debugging.  But info should be something at least useful.  important changes to state, etc.
<redir> I think warnings are reasonable for broadcasting information such as API deprecation or change when such an API or other such announcements. However, retries (my first pref didn't happen trying second pref) are a functioning codepath and shouldn't be logged to the end user IMO.
<davecheney> redir: no, sorry, no warnings ever
<mup> Bug #1583274 changed: Openstack base bundle 42 fails to start rabbitmq when deployed with Juju/MAAS 2.0 <cdo-qa> <cdo-qa-blocker> <deploy> <openstack> <juju-core:New> <https://launchpad.net/bugs/1583274>
<davecheney> it's either an error or an info
<redir> when such an api is called
<davecheney> ok, so that's an informational message "attention: this api call is deprecated and will be removed shortly"
<redir> well I guess if you could then just have it be an error when the API changes or is removed.
<davecheney> you'll get the error for free when the api method is removed :)
<redir> I usually suppress info only warn and worse when I care about logs in production
<davecheney> redir: precisely
<davecheney> which is why I loose my shit when errors are logged at warning level
<davecheney> for context: http://dave.cheney.net/2015/11/05/lets-talk-about-logging
<redir> I agree 100% errors need to be errors
<redir> been there read that
<redir> :)
<redir> API warnings are probably moot in the context of juju since end users aren't using juju as library and dont' need to know about internal deprecations. So, my bad example.
<davecheney> ping, https://github.com/juju/juju/pull/5433
<davecheney> this is a simple update to depenedncies.tsv
<natefinch> davecheney: ship it
<natefinch> honestly, I think that if we're just updating a dependency we wrote, we shouldn't need a review
<davecheney> natefinch: thanks nate
<davecheney>                 if err != nil {
<davecheney>                         logger.Warningf("FIXME: ignoring unexpected CIDR format %q: %v", netConfig.CIDR, err)
<davecheney>                         continue
<davecheney>                 }
<davecheney> ... i don't even know where to begin
<natefinch> uh, yeah
<davecheney> OH MY GOD
<davecheney> we have an apiserver/common package
<davecheney> and we have an apiserver/common/networkingcommon package
<davecheney> HOW DID THIS HAPPEN !?
<natefinch> lol
<davecheney> common, but not that common
<davecheney> sorta in the in crew, but not really
<mup> Bug #1583409 opened: help on status-history is confusing <juju-core:New> <https://launchpad.net/bugs/1583409>
<mup> Bug #1583412 opened: status-history doesn't complain about badly formatted names <juju-core:New> <https://launchpad.net/bugs/1583412>
<natefinch> is status-history supposed to work?
<davecheney> you might have to be flexbile in your definition on work
<natefinch> well, mine seems to always just return "ERROR no status history available"
<mup> Bug #1583409 changed: help on status-history is confusing <juju-core:New> <https://launchpad.net/bugs/1583409>
<mup> Bug #1583412 changed: status-history doesn't complain about badly formatted names <juju-core:New> <https://launchpad.net/bugs/1583412>
<natefinch> hmm, just updated my client and now I get ERROR json: cannot unmarshal object into Go value of type names.Tag
<mup> Bug #1583409 opened: help on status-history is confusing <juju-core:New> <https://launchpad.net/bugs/1583409>
<mup> Bug #1583412 opened: status-history doesn't complain about badly formatted names <juju-core:New> <https://launchpad.net/bugs/1583412>
<davecheney> anastasiamac_: natefinch http://reviews.vapour.ws/r/4870/
<davecheney> natefinch: urk, how are tags leaking out of the apiserver
<mup> Bug #1583409 changed: help on status-history is confusing <juju-core:New> <https://launchpad.net/bugs/1583409>
<mup> Bug #1583412 changed: status-history doesn't complain about badly formatted names <juju-core:New> <https://launchpad.net/bugs/1583412>
<natefinch> davecheney: lemme rebuild the server and make sure I haven't screwed things up somehow
<davecheney>                 logger.Debugf("coercion failed attributes: %#v, checker: %#v, %v", attrs, checker, err)
<davecheney>                 return nil, err
<davecheney> log an error, at debug, then return a different error
<mup> Bug #1583409 opened: help on status-history is confusing <juju-core:New> <https://launchpad.net/bugs/1583409>
<mup> Bug #1583412 opened: status-history doesn't complain about badly formatted names <juju-core:New> <https://launchpad.net/bugs/1583412>
<natefinch> davecheney: oops: https://github.com/juju/juju/blob/master/apiserver/params/status.go#L138
<davecheney> that'll never work
<davecheney> good think it's got a unit test
<natefinch> oh, there's even more broken there
<natefinch> also json related... the request object uses a *time.Time... then checks for nil after deserialization
<natefinch> except that it serializes as a zero time and so deserializes as a zero (but non-nil) time
<mup> Bug #1583422 opened: status-history is broken <juju-core:New> <https://launchpad.net/bugs/1583422>
<mup> Bug #1583443 opened: juju 2.0 doesn't support bundles with 'to: ["service=0"]' placement syntax <juju-core:New> <https://launchpad.net/bugs/1583443>
<mup> Bug #1583443 changed: juju 2.0 doesn't support bundles with 'to: ["service=0"]' placement syntax <juju-core:New> <https://launchpad.net/bugs/1583443>
<mup> Bug #1583443 opened: juju 2.0 doesn't support bundles with 'to: ["service=0"]' placement syntax <juju-core:Invalid> <https://launchpad.net/bugs/1583443>
<mup> Bug #1583443 changed: juju 2.0 doesn't support bundles with 'to: ["service=0"]' placement syntax <juju-core:Invalid> <https://launchpad.net/bugs/1583443>
<babbageclunk> dimitern: ping?
<dimitern> babbageclunk: pong
<babbageclunk> dimitern: So, I think I've found the immediate thing causing these tests to fail (although I don't know what it means or how it happens yet) :).
<dimitern> babbageclunk: oh, go on?
<babbageclunk> In a successful test I get volumeattachments with volumeids 0, 0/1, 0/2
<babbageclunk> but in a failing one they are 0/0, 0/1, 2
<dimitern> hmm
<babbageclunk> What's the difference between the 0/1 ones and the 0 ones? What does the / indicate?
<dimitern> babbageclunk: weird.. what's expeced format of those IDs?
<dimitern> babbageclunk: ISTM "0" is the machine ID, whereas "0/1" is the second volume ID on that machine? but might be wrong..
<babbageclunk> dimitern: well, they look more cryptic because 0 is the machine id.
<babbageclunk> ha ha yup
<babbageclunk> oops standup
<voidspace> omw
<dimitern> me 2
<babbageclunk> oh no - nothing until 11
<dimitern> technically we don't have scheduled standup today
<dimitern> we can still do it with yesterday's slot if you like?
<babbageclunk> yeah, sure - would be helpful for me!
<dimitern> babbageclunk: that comment in names/volume.go explains it: Volumes may be bound to a machine, meaning that the volume cannot exist without that machine. We encode this in the tag to allow
<dimitern> so "0" and "0/1" are both valid volume tags
<dimitern> babbageclunk: also looking at TestWatchMachineVolumes ISTM the watcher is only started after adding the service, initial unit, and the following addUnit()
<dimitern> babbageclunk: are you stopping all watchers before resetting the DB
<dimitern> babbageclunk: it looks like if the watcher keeps going while the DB reset happens, it will still report the initial events *before* it was supposed to start at line 351 in state/volumes_test.go
<babbageclunk> dimitern: No, that's probably it - thanks!
<voidspace> dimitern: heh, so I have three places marked with XXX and no failing tests
<voidspace> dimitern: moar tests
<voidspace> dimitern: to be fair - I don't think those tests were needed before, so it's not really a lack of coverage
<dimitern> voidspace: moar tests == good :)
<voidspace> dimitern: well, so long as they're not flaky...
<dimitern> voidspace: oh yeah
<voidspace> dimitern: mtg?
<dimitern> omw
<anastasiamac_> davecheney: call?
<babbageclunk> fwereade: re: logging context, I really liked the distinction between spans and baggage in http://opentracing.io/spec/
<fwereade> babbageclunk, so baggage is effectively high-level task context, and spans correspond to the various different components that might happen to be doing stuff in response?
<fwereade> babbageclunk, if so, yeah -- I'm currently thinking spans mainly, but baggage would be a fantastic addition
<fwereade> katco, worth considering in the context of audit? ^^
<babbageclunk> fwereade: yeah, that's right. At the stock exchange there was a component that stamped every message flowing through the system with an id that let you follow the flow for that message through all of the logs across lots of different subsystems.
<babbageclunk> fwereade: Was absolutely essential for tracking stuff down.
<fwereade> babbageclunk, I have some concerns about how far we can meaningfully take it in juju, because at a certain point everything is happening because of everything else
<fwereade> babbageclunk, but the useful 80% would be relatively cheap and easy, I think
<fwereade> babbageclunk, (that point is once you get down to relation settings changes, basically)
<fwereade> babbageclunk, (and we don't have any useful insight into what relation changes *actually* cause things to happen -- you could probably do something probabilistic with a suitably overarching view of the system, but that's a bit scope-creepy ;p)
<babbageclunk> fwereade: :)
<babbageclunk> fwereade: Yeah, that system was a lot less dynamic than juju - adding a machine or process while the system running was a rare, scary, fiddly task, where here it's kind of the point.
<mup> Bug #1583564 opened: failed to download URL for lxc images <landscape> <juju-core:New> <https://launchpad.net/bugs/1583564>
<mup> Bug #1583564 changed: failed to download URL for lxc images <landscape> <juju-core:New> <https://launchpad.net/bugs/1583564>
<mup> Bug #1583564 opened: failed to download URL for lxc images <landscape> <juju-core:New> <https://launchpad.net/bugs/1583564>
<dimitern> voidspace, babbageclunk: please take a look at http://reviews.vapour.ws/r/4871/, which fixes bug 1574844
<mup> Bug #1574844: juju2 gives ipv6 address for one lxd, rabbit doesn't appreciate it. <conjure> <juju-release-support> <landscape> <lxd-provider> <juju-core:In Progress by dimitern> <rabbitmq-server (Juju Charms Collection):New> <https://launchpad.net/bugs/1574844>
<dimitern> (I still need to add a few extra unit tests, but otherwise it won't change much)
 * dimitern steps out for ~30m
<mup> Bug #1583564 changed: failed to download URL for lxc images <landscape> <juju-core:New> <https://launchpad.net/bugs/1583564>
<babbageclunk> dimitern: Why have duplicate attributes and methods for IPv6 and IPv4 addresses? Why not pass in a type (or use the address.Type() where approro
<babbageclunk> Oopp
<babbageclunk> Gah. ...where appropriate?
<dimitern> babbageclunk: because of the way address selection works, you can't rely on addr.Type == network.IPv6Address when trying to set the preferred IPv6 address (e.g. when only IPv4 addresses are available)
<dimitern> babbageclunk: I'd appreciate suggestions on the review :)
<dimitern> babbageclunk: like what's unclear and possibly the need for extra comments, etc.
<dimitern> now I'm really afk for a while..
<babbageclunk> dimitern: Was doing that, but wanted to make sure I wasn't going off half-cocked.
<katco> babbageclunk: fwereade: thanks, i'll give it a read over
<voidspace> dimitern: why not just have the preferred address algorithms prefer IPv4?
<voidspace> dimitern: I don't see a need for all these extra methods
<dimitern> voidspace: because the whole point of the preferred addresses is that they don't change once set
<dimitern> voidspace: and if providerAddresses = ["public:fc00:123::/64"] the very first time SetProviderAddresses is called, both the preferred public and private IPv4 and IPv6 will be the same and they cannot change if later SetProviderAddresses is called with e.g. ["public:8.8.8.8", "public:fc00:123::/64", "local-cloud:10.0.1.2", "local-cloud:fe80::/64"]
<dimitern> that's essentially what the bug is about
<dimitern> voidspace: that's why preferred IPv4 and preferred IPv6 need to be stored separately
<voidspace> dimitern: hmmm...
<katco> natefinch: standup time
<voidspace> dimitern: you still don't need two *setters* as preferred ipv4 and ipv6 can be determined from the type of the input to SetPreferredAddresses
<dimitern> voidspace: you mean for migrations?
<voidspace> dimitern: I mean you don't need SetPreferredIPv4Addresses and SetPreferredIPv6Addresses
<dimitern> voidspace: that's for migtations only
<voidspace> dimitern: migration of what/
<voidspace> what?
<dimitern> voidspace: SetPreferredIPv4Addresses is a method of description.Machine interface in core/descriptiob
<dimitern> description
<voidspace> dimitern: I don't think it needs to be
<natefinch> you certainly don't need the word "Addresses" in there, at the very least.  This isn't java.
<voidspace> dimitern: you can SetPreferredAddresses twice, once with ipv4 addresses and once with ipv6
<voidspace> dimitern: and if there's a type switch internally it will "do the right thing" without needing two methods
<katco> ericsnow: natefinch: redir_afk: my hangouts has frozen
 * katco waits for it to unstick
<dimitern> voidspace: which SetPreferredIPv4Addresses method are you talking about/
<dimitern> ?
<voidspace> dimitern: machine
<voidspace> dimitern: and of course the interface in core descriptions
<voidspace> dimitern: have SetPreferredAddresses sort the addresses it is given by type and set both ipv4 and ipv6 preferred addresses
<voidspace> dimitern: and if it is called twice, once with ipv4 only and once with ipv6 only, it will still "do the right thing"
<dimitern> voidspace: I don't mind changing the description.Machine methods - they are less relevant anyway and will be likely called with all 4 preferred set
<dimitern> voidspace: there's no SetPreferredIPv4Addresses on state.Machine (or anything like that)
<voidspace> dimitern: ah, it's core/description/machine
<voidspace> dimitern: I care less about extra methods there I guess
<dimitern> voidspace: yeah :)
<dimitern> voidspace: my point exactly :) also I was following the pattern for existing migrations interface methods
<voidspace> dimitern: ok
<dimitern> sorry, brb again
<lazyPower> is anyone available to help troubleshoot a 1.25 controller stuck in an erroneous "upgrade", the user apparently didn't request the upgrade, but rebooted the host controller and its stuck doing an upgrade.
<lazyPower> they're over in #juju if anyone has a moment to lend a hand. i'm out of my depth on this one, i'm directing them to aggregate logs and file a proper bug
<natefinch> lazyPower: I noticed he said this was a case study and would get published.... sigh.  bad day for all the managers to be at a sprint
<natefinch> rick_h_: you around?
<lazyPower> agreed :/
<katco> i also need a volunteer to tal @ bug 1537585. this is blocking the landscape team from releasing.
<mup> Bug #1537585: machine agent failed to register IP addresses, borks agent <2.0-count> <blocker> <landscape> <network> <juju-core:Triaged by dooferlad> <juju-core 1.25:Triaged by dooferlad> <https://launchpad.net/bugs/1537585>
<katco> natefinch: you're the only one without feature work atm. are you looking at this other customer-facing issue in #juju?
<katco> perrito666: what are you up to?
<natefinch> katco: was just trying to figure out if I should help the guy in #juju... I've gotten flack for doing that in the past, so was hesitant this time.
<katco> natefinch: i was thinking the same thing. we have paid support for that reason
<katco> natefinch: i would say pick up this bug if you can. it will unblock landscape and make all of juju better
<natefinch> katco: before or after I fix status-history?
<katco> natefinch: how long do you think it will be for that fix?
<natefinch> katco: just an hour or so to tweak the tests to pass
<katco> natefinch: i'd say wrap that up first then
<natefinch> katco: yeah, my thought as well. Cool.
<natefinch> katco: then I'll hop on the landscape one
<katco> natefinch: you are a bug fixing machine
<perrito666> katco: I was in bed until about now, I am trying to wrap up the restore work that ian inherited me
<katco> perrito666: ok, ta. hope you're feeling better :(
<perrito666> katco: nope, but bed is driving me crazy so I get up and work every now and then
<katco> perrito666: sorry to hear that
<perrito666> katco: you know how these things are, you just have to wait and eat chicken soup
<katco> perrito666: yeah. i'm not a good sick person.
<mup> Bug #1583683 opened: juju thinks it is upgrading after a reboot <juju-core:New> <https://launchpad.net/bugs/1583683>
<mup> Bug #1583683 changed: juju thinks it is upgrading after a reboot <juju-core:New> <https://launchpad.net/bugs/1583683>
<mup> Bug #1583683 opened: juju thinks it is upgrading after a reboot <juju-core:New> <https://launchpad.net/bugs/1583683>
<lazyPower> kat/nate - is there anyone in particular i should ping with the bug dweaver submit for their issue? (the #juju casestudy user)
<lazyPower> katco natefinch ^  - sorry pinging you directly as you made mention. I want to route this appropriately
<katco> lazyPower: i pinged cheryl, alexis, and rick_h_
<lazyPower> ok, bugs right up there ^
<katco> lazyPower: ta
<lazyPower> thanks for the handoff
<katco> lazyPower: just want to be crystal clear: we haven't committed to investigating this yet
<lazyPower> ok, if it gets dropped it gets dropped. Theres very little i can do about it, and i know we're on a tight schedule/deadline.
<lazyPower> we've done what we can
<katco> lazyPower: curious if they can hang on until next week? half our resources are sprinting atm
<lazyPower> i made that clear that we were short handed due to a planning sprint.  Their response: [11:59:18] dweaver: lazyPower, yes, willing to be patient, thanks.  I'll ping you with a bug ID once it is submitted with all the info.  Will be most appreciative thanks.
<katco> lazyPower: awesome, ta chuck
<lazyPower> np np, good hustle
<katco> alexisb: are we still doing our 1:1? figured you were busy with sprint
<alexisb> katco, we are not
<alexisb> how are things?
<katco> alexisb: things going fine
<perrito666> did someone forget a couple of machines running in our ec2 since apirl 14?
 * perrito666 is about to pull the trigger
<alexisb> natefinch, ping
<natefinch> alexisb: pong
<alexisb> hey natefinch what are you up to?
<natefinch> alexisb: fixing status-history, which I figured out last night is completely broken
<alexisb> natefinch, how long will you be working those bugs?
<natefinch> alexisb: well, wrapping up status-history soon.  There was a bug reported by landscape guys that I was going to work on next, but what's up?
<alexisb> natefinch, please continue
<alexisb> natefinch, katco thanks
<redir> ericsnow: got a minute?
<ericsnow> redir: sure
<redir> moonstone?
<ericsnow> redir: yep
<katco> redir: spec updated
<natefinch> perrito666: you around?
<natefinch> perrito666: http://reviews.vapour.ws/r/4872/
<perrito666> natefinch: looking
<perrito666> natefinch: ship it
<perrito666> natefinch: and incidentally I think I opened a "we should not use *time.Time" bug some time ago which you just partially addressed
<natefinch> perrito666: I actually undid my addressing of it... it just propagated out too far. I was going down a rat hole and just wanted this thing fixed.
<natefinch> perrito666: it wouldn't be that hard to fix, it just touches a lot of files
<perrito666> oh, I thought you where doing that, then I noticed you didnt :)
<perrito666> i might do it in the trip to the sprint
<mup> Bug #1583771 opened: RunnerSuite.TestOneWorkerStartWhenStopping timed out <ci> <intermittent-failure> <race-condition> <regression> <unit-tests> <juju-core:Triaged> <https://launchpad.net/bugs/1583771>
<mup> Bug #1583772 opened: MachineSuite.TestDyingModelCleanedUp state.Life dead not alive <ci> <ppc64el> <regression> <s390x> <test-failure> <unit-tests> <windows> <juju-core:Triaged> <https://launchpad.net/bugs/1583772>
<natefinch> I wish we had juju add-container... I can never remember the invocation to add a container to an existing machine
<natefinch> also wish juju add-machine lxc:0 -n 2 worked :/
<natefinch> cannot use -n when specifying a placement directive.... why the hell not?
<mup> Bug #1583787 opened: get-* CLI commands should be called show-* <juju-core:New> <https://launchpad.net/bugs/1583787>
<mup> Bug #1583789 opened: juju uses wrong gpg for validating images on streams.canonical.com <centos> <ci> <simplestreams> <juju-core:Triaged> <https://launchpad.net/bugs/1583789>
<redir> katco: tx
<redir> fwereade: yt?
<katco> anastasiamac_: i'm in the hangout when you're ready
 * redir stuck
#juju-dev 2016-05-20
 * redir goes eod
<natefinch> davecheney: you around?
<mup> Bug #1583422 changed: status-history is broken <juju-core:Fix Released by natefinch> <https://launchpad.net/bugs/1583422>
<mup> Bug #1583422 opened: status-history is broken <juju-core:Fix Released by natefinch> <https://launchpad.net/bugs/1583422>
<davecheney> natefinch: ac
<davecheney> ack
<natefinch> davecheney: do you think this bug requires maas? https://bugs.launchpad.net/juju-core/+bug/1537585
 * natefinch waits for a slow mup
<natefinch> davecheney: sounds like "we're deploying a lot of machines and containers, and some contention/race in the code is blowing up if we go too fast"
<mup> Bug #1583422 changed: status-history is broken <juju-core:Fix Released by natefinch> <https://launchpad.net/bugs/1583422>
<davecheney> natefinch: no idea, never done any maas
<davecheney> why do we have a concept of connecting to the API without logging in ?
<davecheney> what operations are permitted without authentication ?
<natefinch> davecheney: not many, but a few
<davecheney> that blows
<davecheney> that means any api client method like ModelUUID has to return an error
<davecheney> because it plays double duty as a "hey, you aren't logged in yet"
<davecheney> signal
<natefinch> davecheney: it's possible we've cleaned everything up since I last looked, but I don't know for sure
<davecheney> the problem i'm trying to fix is api/service/client.go which reutrns "" if there is an error retrievin the model uuid
<davecheney> and I cannot change the api like I did for https://github.com/juju/juju/commit/682e48db28d27b8730fce3aab1a63d5260787caf
<davecheney> because of the horrid romulus mess
<davecheney> so I tried to store the model tag earlier, but apparently there is logic that expects you to be connected, but not have a model
<natefinch> ug
<davecheney> technical debt -- fuck yeah!
<mup> Bug #1558734 changed: POWER8 agent stacktraces and refuses to boot <juju-core:Expired> <https://launchpad.net/bugs/1558734>
<mup> Bug #1583893 opened: 1.25.5: goroutine panic launching container on xenial <landscape> <juju-core:New> <https://launchpad.net/bugs/1583893>
<mup> Bug #1583934 opened: revision specified in the charm, how? <juju-core:New> <https://launchpad.net/bugs/1583934>
<fwereade> hmm, do we have terminology to distinguish concisely between "agents running in a hosted model" vs "agents running in a controller model"? e.g. "controller agents" won't really work because not all agents in controller models actually run controller tasks or need controller-level privileges
<fwereade> the biggest distinction I'm aware of is whether they're migratable -- stuff running in a controller environment isn't -- but it doesn't seem quite fundamental enough
<fwereade> "hosted" vs "fixed"? [hosted unit agent, hosted machine agent] and [fixed unit agent, fixed machine agent, (implicitly fixed) controller machine agent]
<fwereade> ?
<fwereade> it's sort of nice to emphasise immobility of agents in controller models, because they can't even be rehosted... but it would be wrong to imply *mobility* of agents in hosted models, because it's not the *agents* that move, it's that they can switch to being managed by a different host
<fwereade> english is hard :/
<fwereade> if anyone sees the scrollback and has thoughts, they would be appreciated
<voidspace> wwitzel3: ping
<mup> Bug #1584059 opened: Deployment of swift-storage charms fails with Juju 2.0 - swift-storage-relation-joined KeyError: 'JUJU_ENV_UUID' <oil> <juju-core:New> <swift-storage (Juju Charms Collection):New> <https://launchpad.net/bugs/1584059>
<katco> good morning juju
<perrito666> katco: good morning katco
<katco> perrito666: feeling any better?
<perrito666> katco: yep, I transitioned into the bearable but persistent cold status
<perrito666> which is.... well bearable
<katco> perrito666: well at least that's progress
<perrito666> yep, I can swallow
<perrito666> and no longer shivering
<katco> ugh being sick is the worst
<perrito666> yes it is
<redir> fwereade: yt?
<katco> fwereade: also wondering
<redir> you're in demand
<redir> morning katco
<katco> redir: i wonder if he's thread safe
<katco> redir: morning
<redir> :)
<redir> deadlocked
<katco> redir: hopefully livelocked...
<redir> or that
<fwereade> redir, heyhey!
<ericsnow> katco, redir: I've got him right now :)
<fwereade> katco, also :)
<redir> doh
<katco> ericsnow: snooooooow!
<ericsnow> redir: we've been talking about your patch :)
 * redir backs away slowly
<ericsnow> haha
<redir> in moonstone?
<fwereade> redir, no worries, sorry I wasn't available before
<redir> np
<ericsnow> fwereade: you have time to chat with redir and me right now?
<fwereade> redir, ericsnow, sure, I'll join you there
<redir> gimme 2 minutes
<redir> moonstone?
<katco> redir: ericsnow: natefinch: we can defer the standup. this conversation with william is more important for now
<ericsnow> katco: ack
<natefinch> ok
<katco> natefinch: we're in moonstone if you're interested. basically pair programming
<natefinch> katco: cool, I'll pop in
<katco> dooferlad: ping?
<voidspace> katco: he emailed this morning saying he was still ill
<katco> voidspace: ah sorry to hear that :( do you think it's OK if natefinch picks up bug 1537585 ?
<mup> Bug #1537585: machine agent failed to register IP addresses, borks agent <2.0-count> <blocker> <landscape> <network> <juju-core:Triaged by dooferlad> <juju-core 1.25:Triaged by dooferlad> <https://launchpad.net/bugs/1537585>
<perrito666> wow, there is some virus affecting canonicalers
<voidspace> katco: I don't believe he's started on it, so it should be fine
<katco> voidspace: ok ta
<katco> natefinch: can you ping someone in landscape to understand where they need the fix first? 1.25 or 2.0-beta8?
<natefinch> katco: yep
<katco> natefinch: ta
<redir> fwereade: so you wanted two more tests there?
<redir> in aggregate
<fwereade> redir, I think we want tests that:
<fwereade> redir, one request gets sent after suitable delay (done)
<fwereade> redir, several requests in a short space of time get batched (done)
<fwereade> fwereade, that advancing delay-time.Nanosecond and then killing causes all pending reqs to fail
<fwereade> redir, sorry^
<fwereade> brb
<redir> np
<fwereade> redir, and, that having sent/advanced/received one batch, you can send/advance/receive again and that works too
<fwereade> redir, (and, in all above cases, checking that you've made the ListInstances calls you expect, once you've killed the worker)
<fwereade> redir, also nice to do a test where ListInstances errors, and one where it returns some results + ErrPartialInstances
<katco> fwereade: ty for taking the time to help redir
<fwereade> katco, always a pleasure, seriously
<fwereade> katco, it's one of the most useful things I can do
<fwereade> katco, complain about concurrency horrors to me early, I will enjoy myself :)
<fwereade> gtg
<redir> tx fwereade
 * fwereade back briefly
<fwereade> redir, yw
<fwereade> redir, (would you also separate the configs please? and test those too :))
<redir> fwereade: affirmative
<fwereade> redir, cheers
<redir> bbiab
<perrito666> Bbl
<katco> ericsnow: hey got a bit to chat?
<ericsnow> katco: sure
<mup> Bug #1584170 opened: RFE - juju status <machine-number> should show all services inside it <juju-core:New> <https://launchpad.net/bugs/1584170>
<redir> oh, yeah. back.
<mup> Bug #1584193 opened: juju deploy <bundle> is in a different from than jujucharms.com <juju-core:New> <https://launchpad.net/bugs/1584193>
<natefinch> sinzui: I'm trying to repo a bug, which might require maas. Does QA have a maas I could borrow?
<sinzui> natefinch: you probably want the 1.9 which you cna use, but is often is heavy  use
<natefinch> sinzui: yeah, 1.9 is what it was reported on
<sinzui> natefinch: I will add your keys to the munna host
<natefinch> sinzui: I just need like 2-3 machines that I can spam a bunch of containers onto
<rick_h_> natefinch: how many machines do you need?
 * natefinch points up one line ;)
<rick_h_> natefinch: sorry get with bac and or jrwren for guimaas access and see if it works for you
<natefinch> rick_h_: awesome, thanks :)
<natefinch> sinzui: I may already be on munna
<sinzui> natefinch: you weren't,  but you are now. I am sending you some ssh comfig for munna. maybe you used cloud-city in the past. that will still work
<natefinch> sinzui: yes, I think so.  Thanks.
<ericsnow> redir: FYI, I've got to take off a bit early
<sinzui> natefinch: check your email
<mup> Bug #1584212 opened: juju 2.0 doesn't allow to remove a cloud (juju remove-cloud) <juju-core:New> <https://launchpad.net/bugs/1584212>
<redir> no sweat ericsnow
<fwereade> if anyone's around, http://reviews.vapour.ws/r/4873/ is biggish but trivial (just moves + one test fix) and I'd love to get it on its way into master this weekend
<fwereade> (probably better reviewed on github given RB's usual confusion re moves) ^^
#juju-dev 2016-05-21
<mup> Bug #1451488 changed: When deploying a service, the charm is added, but the new instance is remains pending. <community> <juju-core:Expired> <https://launchpad.net/bugs/1451488>
<mup> Bug #1485071 changed: juju deploy and add-machine not installing agent <juju-core:Expired> <https://launchpad.net/bugs/1485071>
<mup> Bug #1536337 changed: juju 1.25.0: cannot initiate replica set: cannot dial mongo to initiate replicaset: no reachable servers <oil> <juju-core:Expired> <https://launchpad.net/bugs/1536337>
#juju-dev 2016-05-22
<ejat> anyone can help me with this error : http://paste.ubuntu.com/16614114/
<menn0> davecheney: howdy. how's things?
<davecheney> menn0: hey
<davecheney> u back in country ?
<menn0> davecheney: yep... got back yesterday morning
<menn0> I'm working today
<davecheney> i guess i should have come to the standup then
<menn0> it's my birthday on wednesday so i'm saving my swap days for wednesday and thursday
<davecheney> you know you get a day in lieu every time you cross the date line while travelling
<davecheney> don't come back for the rest of the week
<menn0> davecheney: the standup would have just been me and you. it seems that michael isn't around.
<davecheney> fair enough
<davecheney> could be worse, https://twitter.com/yayxw/status/734514359582363648
<menn0> davecheney: wallyworld also missed his connection and got stuck in LA
<davecheney> urgh
<davecheney> that's terrible
<blahdeblah> Ugh.  I'm on the same flight as axw this time next week :-(
<menn0> blahdeblah: hopefully you have better luck :)
<blahdeblah> Yeah - hopefully. :-\
<mup> Bug #1584548 opened: juju ssh doesn't work for containers <juju-core:New> <https://launchpad.net/bugs/1584548>
<mup> Bug #1584548 changed: juju ssh doesn't work for containers <juju-core:New> <https://launchpad.net/bugs/1584548>
<mup> Bug #1584548 opened: juju ssh doesn't work for containers <juju-core:New> <https://launchpad.net/bugs/1584548>
<mup> Bug #1584548 changed: juju ssh doesn't work for containers <juju-core:New> <https://launchpad.net/bugs/1584548>
#juju-dev 2017-05-15
<anastasiamac> menn0: just as a test, can u now see 'CAAS' on the board?
<menn0> anastasiamac: I can. thanks!
<anastasiamac> menn0: ack. i'll see if i can add joel
<anastasiamac> menn0: does he need the ability to move cards or just to view them?
<menn0> anastasiamac: thumper just explained to me how to do it :)
<anastasiamac> menn0: thumper: awesome!
<menn0> anastasiamac: it would be great if joel could move/add/update cards
<anastasiamac> menn0: k. does it mean u want me to add him or r u in control now?
<menn0> anastasiamac: sorry, otp. thumper is adding him now (he doesn't have an acccount)
<thumper> I've just added joel to leankit
<thumper> and emailed him
 * thumper afk to collect kids
<babbageclunk> wallyworld: can you take a look at this please? https://github.com/juju/juju/pull/7340
<babbageclunk> wallyworld: oh, also - I just noticed this while I was scrolling through it: https://github.com/juju/juju/pull/7340/files#diff-bad794df7c6f66424c0b9cc0961da6ccR896
<babbageclunk> wallyworld: That seems wrong to me - it's saying you don't need write permission to the model to add a relation if the other end is a remote application.
<wallyworld> babbageclunk: looking now
<babbageclunk> wallyworld: cool thanks - no rush, I'm looking at the maas thing atm
<menn0> jam: sorry :)
<jam> https://hangouts.google.com/hangouts/_/canonical.com/john-menno?authuser=1 ?
<jam> I wasn't sure if you intended to stay in the same channel or switch
<thumper> night all
<wpk> call at 7am: https://www.youtube.com/watch?v=vidNWtQeREw
<mup> Bug #1688177 changed: juju show-action-status needs more details <canonical-bootstack> <juju:Triaged> <https://launchpad.net/bugs/1688177>
<mup> Bug #1688177 opened: juju show-action-status needs more details <canonical-bootstack> <juju:Triaged> <https://launchpad.net/bugs/1688177>
<mup> Bug #1688177 changed: juju show-action-status needs more details <canonical-bootstack> <juju:Triaged> <https://launchpad.net/bugs/1688177>
<mup> Bug #1662857 changed: cannot go get the source code  <juju:Triaged by menno.smits> <https://launchpad.net/bugs/1662857>
#juju-dev 2017-05-16
<babbageclunk> wallyworld: Can you take another look at https://github.com/juju/juju/pull/7340? I think I've resolved your comments.
<wallyworld> sure
<babbageclunk> Thanks
<wallyworld> babbageclunk: done
<babbageclunk> wallyworld: cheers.
<babbageclunk> wallyworld: I've already done the migration/dump-model work! :) Although migration_import refuses to import a model with remote applications - I don't want to just enable it because it probably won't just work.
<wallyworld> sure, ok
<babbageclunk> I guess mainly because at the moment we're talking about cross-model/same-controller, and migration is inherently between controllers.
 * thumper takes dog for a walk
<babbageclunk> wallyworld, menn0: huh, haven't seen a test fail like this before: http://juju-ci.vapour.ws:8080/job/github-merge-juju/10891/artifact/artifacts/xenial.log
<babbageclunk> Do you think it's a problem?
<menn0> babbageclunk: well it's certainly a problem :p
<menn0> babbageclunk: maybe mention it to mwhudson ?
<mwhudson> eh that's just a nil pointer deference isn't it?
<wallyworld> menn0: babbageclunk: that's a know bug, let me look at the number
<mwhudson> dereference
<wallyworld> bug 1686720
<mup> Bug #1686720: worker/lease: NewDeadManager returns manager that crashes <juju:Triaged> <https://launchpad.net/bugs/1686720>
<wallyworld> it's not a go things, it's a juju npe IIANM
<babbageclunk> wallyworld: ok, if it's got a bug I'mm'a just rerun. :/
<menn0> wallyworld, babbageclunk or anastasiamac: quick help fix. https://github.com/juju/juju/pull/7343
<wallyworld> sure
<menn0> axw: ping
<axw> menn0: pong
<menn0> axw: I had a poke at this: http://reports.vapour.ws/releases/5227/job/run-unit-tests-win2012-amd64/attempt/3720
<menn0> i know what the problem is but I don't know what the correct fix is
<babbageclunk> menn0: reading now
<axw> doh
<axw> menn0: I can take it over if you like
<menn0> axw: ok, happy to hand it over (there's a LK card already)
<axw> okey dokey
<menn0> axw: i'm curious though, are those paths supposed to by unix only?
<axw> menn0: yep
<axw> menn0: storage is not currently supported on windows
<menn0> axw: ok, then the tests are slightly wrong
<menn0> axw: the tests shouldn't use filepath.FromSlash
<wallyworld> menn0: i added a suggestion, but lgtm
<menn0> axw: and BlockDevicePath shouldn't use filepath.Join
<menn0> wallyworld: cheers
<axw> menn0: yup. I'll fix that up, thanks.
<menn0> axw: cheers
<menn0> wallyworld: good call. doing that now.
<babbageclunk> menn0: D'oh, took too long with my comments.
<anastasiamac> babbageclunk: but ur comments were totally worth it :) i wondr if i could give menn0 a resources related bug for jumping the gun?... babbageclunk, want to negotiate it for me? :D
<axw> menn0: mind reviewing? https://github.com/juju/juju/pull/7344
<menn0> axw: otp but yes afterwards
<menn0> babbageclunk: good comments, i'll follow up
<babbageclunk> wallyworld: got a moment for a sanity check? Or are you also otp?
<babbageclunk> menn0: ok thanks!
<babbageclunk> menn0: especially on the diaeresis one.
<wallyworld> babbageclunk: otp, give me a little time
<babbageclunk> wallyworld: I mean, you're my second choice in this case anyway - is thumper-afk in the same call?
<axw> thanks jam
<wallyworld> babbageclunk: tim isn't on this call
<babbageclunk> ah, ok - he's actually afk then, presumably
<wallyworld> babbageclunk: free now
<menn0> babbageclunk: luckily the merge attempt failed so I can get your suggestions in
<menn0> but not the diaeresis one :p
<babbageclunk> menn0: tsk!
<menn0> pre-existing maybe?
<babbageclunk> menn0: I mean, I was just kidding with the tsk!
<babbageclunk> I'm fine with no hyphen.
<babbageclunk> wallyworld: hey, so my confusion was about this bit of code: https://github.com/juju/juju/blob/develop/worker/provisioner/provisioner_task.go#L739
<babbageclunk> I'd expect that I'd be able to see those "failed to start instance" messages from the provisioner in the log, but I don't
<babbageclunk> (Oh, this is re:that maas timeout bug btw)
<wallyworld> did you figure it out?
<babbageclunk> wallyworld: no
<wallyworld> are you sure that code is being run?
<babbageclunk> wallyworld: Well, that's the bit that thumper-afk was saying was the problem, and the thing that would be affected by changing the retry count.
<wallyworld> sure, but maybe the code path isn't hitting that line in your deployment. since when do you believe what tim says :-P
<babbageclunk> wallyworld: it makes sense that that would be the problem, but if it is I don't understand why I can't see that in the log.
<babbageclunk> wallyworld: Oh, I mean in the log file attached to the bug.
<wallyworld> in the past i've had similar issues and it did turn out the code wasn't running are you sure the right agent binary is being used
<thumper-afk> :P
<wallyworld> have you updated your source code post beta4
<wallyworld> otherwise you'll be using agent from simplestreams
<wallyworld> unless you used --build-agent
<babbageclunk> wallyworld: I'm not running anything - I don't know how to make my maas timeout in the same way.
<wallyworld> babbageclunk: does the log indicate that this error is bubbles up? "cannot start instance for machine"
<wallyworld> i'm trying to establish if we really do get int that retry loop
<babbageclunk> Right - I don't think we do, because we don't see that logging.
<babbageclunk> Which would indicate that the retry count isn't the problem. (Unless we wouldn't expect to see the message in this log for some reason.)
<wallyworld> or maybe we do and err is nil
<wallyworld> maas says it will start the instance
<wallyworld> it then goes through a lifecycle or allocating->deployed or something
<babbageclunk> wallyworld: in which case changing the retry count won't help.
<wallyworld> so juju never gets to retry as it doesn't think it needs to
<wallyworld> exaxtly
<wallyworld> it may be the wrong bit of code is being looked at here?
<wallyworld> what does juju do sfter starting the instance - doe sit poll it until it goes to deployed state
<wallyworld> doesn't look like it
<wallyworld> it just assumes it is started
<babbageclunk> wallyworld: hang on - trying to chase through the provider code.
<wallyworld> maybe that's a bad assumption. i know with openstack startinstance returns but that just means the start request is accepted
<wallyworld> the instance itself then goes through a lifecycle - building, blah....
<wallyworld> before it is ready
<babbageclunk> wallyworld: ok, thanks for confirming my thinking - still chasing then
<wallyworld> np, good luck!
<jam> axw: ping
<axw> jam: pong
<jam> axw: you have a PR #6326 that is about 8 months old
<jam> axw: azure using simplestreams
<jam> is there something we should close/unblock/???
<axw> jam: yeah, it got stalled numerous times. we need to ensure streams.canonical.com has the azure bits. probably not going to happen until 2.3 at the earliest now
<axw> jam: we were close to a resolution at barcelona, but now aaron's gone and he was handling the streams side
<jam> axw: should we close that PR and come back to it?
<axw> jam: can do I guess, though the code shouldn't change much
<axw> jam: is it harmful leaving it there? distracting?
<jam> I'd like to get us to PRs that are actionable
<jam> so when we do a scan we can know rather than having a bunch of stuff we have to ignore
<axw> jam: fair enough. no drama to recreate it later, I'll close
<jam> we're a bit far from that, but it would be nice
<axw> I agree
<jam> axw: you also have a 1.8 branch that didn't land 3 days ago?
<axw> jam: yep, I will get back to that one real soon. needs some fixes in the 1.25 branch
 * axw creates a card to get it done
<axw> wallyworld_: can you please review https://github.com/juju/juju/pull/7346 tomorrow, unless some kind soul does it overnight? the meat and potatoes are in the first two commits
<wallyworld_> axw: looking
<wpk> Any volunteers? https://github.com/juju/juju/pull/7348
<gsamfira> heya
<gsamfira> anyone want to look over a small PR? https://github.com/juju/utils/pull/279
<balloons> menn0, not sure who all else is in the tech board, but I'd appreciate a look at https://github.com/juju/juju/pull/7350
<wallyworld> babbageclunk: did you find where juju is not sufficiently retrying the provisioning?
<babbageclunk> wallyworld: the Juju log attached to that bug doesn't show the provisioning failure - I've asked for another one that does. I want to check with thumper that he's sure that's the problem - it seems likely, but it'd be good to have the log showing it.
<wallyworld> babbageclunk: it would be good yes. we could though make a preemptive fix and increase retry timeout based on knowledge that machines can take a while to provision; this will unblock the fix and if/when we get better logs we can confirm
<babbageclunk> wqll
<babbageclunk> oops
<babbageclunk> wallyworld: yeah, that's my thinking too.
<babbageclunk> wallyworld: https://github.com/juju/juju/pull/7351
<wallyworld> looking
<babbageclunk> It's pretty short
<wallyworld> babbageclunk: i could comment but i won't :-)
 * babbageclunk sniggers
<wallyworld> babbageclunk: is 10 x 10s enough?
<wallyworld> babbageclunk: i wonder also, we should surface the retry attempts in status
<wallyworld> there's an api to surface progress
<wallyworld> we could ensue the message says "Waiting for machine to be provisioned, attempt 1 or 10" or something
<babbageclunk> wallyworld: machine.SetInstanceStatus - yeah, could do. I'll add that.
<wallyworld> so the user can see stuff is happening
<wallyworld> 1 of 10
<babbageclunk> According to thumper, this happens occasionally (I think he said something like 10% of the time?), so normally 3 tries is enough. 10 seems like a reasonable number to bump it to in that case?
<babbageclunk> wallyworld: oh, it turns out it already does that: failed to start instance (%s), retrying in %v (%d more attempts)
<wallyworld> cool, ok
<wallyworld> let's land it and take a view
<babbageclunk> wallyworld: kind of an annoying amount of digging around in logs for a 1-line PR
<wallyworld> it' the old mechanic paradigm - the fix is trivial, you just have to know where to apply the hammer
<babbageclunk> sure
<babbageclunk> wallyworld: ok, I'll move onto getting rid of that annoying unknown collection "remoteApplications" message.
<wallyworld> +1 ty
<wallyworld> assuming it was the last pr to land which introduced it
<wallyworld> i think it must have been because it was all ok before then IIANM
<babbageclunk> wallyworld: I don't think it was the last PR - it's in the logs on bug 1688028 too
<mup> Bug #1688028: Juju fails to request deploy after busy node returns OK <cdo-qa> <cdo-qa-blocker> <juju:In Progress by 2-xtian> <https://launchpad.net/bugs/1688028>
<wallyworld> ok, otp, will catch up soon
<gsamfira> anybody want to take a stab at a couple of really tiny PRs? :)
<babbageclunk> gsamfira: sure!
<wallyworld> thumper: i had also pinged ante and andres in #juju to confirm that maas storage issue is fixed so hopefully we'll be able to close the issue real soon
<thumper> wallyworld: I updated the bug to incomplete :)
<wallyworld> yay :-)
<wallyworld> hopefully nothing more to do
<gsamfira> babbageclunk: https://github.com/juju/utils/pull/279 and https://github.com/juju/charm/pull/228
<gsamfira> babbageclunk: thanks! ^_^
<babbageclunk> gsamfira: Why do you think using defer might lead to leaked file handles?
<gsamfira> babbageclunk: It was an improper use of the word. The whole defer fh.Close() pattern, while I get is useful to close a file even if a panic happens along the way, can cause ulimit errors when, for example unarchiving an archive with many files.
<babbageclunk> gsamfira: ok, I thought it might be something like that - so in a function with a loop extracting many files.
<gsamfira> babbageclunk: yap
<gsamfira> babbageclunk: there is another issue with that pattern. On Windows for example, if you try something like (pseudo code follows: fh := Open("myfile"); defer fh.Close; fh.Write("hello"); io.Move("myfile", "awesome_name")
<gsamfira> it will fail
<babbageclunk> gsamfira: That said, I think the places you're changing in the utils PR would be better done by changing the deferred closes to be sync+closes. The loop problem doesn't apply there.
<gsamfira> (the move at least)
<babbageclunk> gsamfira: oh, right. Is that why you moved the sync+close to be before the call to the change func in AtomicWriteFileAndChange?
<gsamfira> would it not be useful to return any errors while doing a sync/close?
<gsamfira> yap
<gsamfira> also in zip.go. in the case of copyTo
<babbageclunk> gsamfira: for returning errors, yes, but not if we're already returning an error - we wouldn't want to clobber it.
<thumper> menn0, wallyworld: I won't be at the tech-board meeting today
<thumper> have taxi duty :-|
<menn0> thumper: ok
<wallyworld> thumper: no worries, we'll cover for you :-)
<gsamfira> babbageclunk:  not really clobbering, I think. We still return the original error if that's where it happens. But we also get an error returned if we fail to flush to disk, or close the file...which I think is an important error to know :)
<gsamfira> otherwise we cannot guarantee that the config file or state file is consistent
<babbageclunk> Oh, I mean, it would be better to make the defer do sync+close and return any error (avoiding clobbering an error already coming back) than just putting the sync+close on the happy path.
<babbageclunk> gsamfira: ^
<babbageclunk> does that make sense?
<babbageclunk> gsamfira: I'll put what I mean into the review.
<gsamfira> babbageclunk: yup. Makes sense
<babbageclunk> gsamfira: cool
<gsamfira> babbageclunk: sounds good. helps to add context :)
<gsamfira> I'll address it in the morning. Grabbing some sleep for tonight :)
<gsamfira> thanks for looking over it!
<gsamfira> babbageclunk: ^
<babbageclunk> gsamfira: no worries! I started typing it up and it's unwieldy enough that I don't think it's worth it - I think yours is fine in that case.
#juju-dev 2017-05-17
 * thumper relocates to the coffee shop for lunch
<wallyworld> axw: standup?
<axw> wallyworld: which bug did you want me to check?
<wallyworld_> axw: bug 1686696
<mup> Bug #1686696: Subordinate units won't die until all principal relations are gone <juju:Triaged> <https://launchpad.net/bugs/1686696>
<axw> okey dokey
<axw> wallyworld: also I didn't get a travel email, FYI
<wallyworld_> axw: yeah, it came to me, so maybe i need to send it on, will follow up
<thumper> who knows most about proxies right now?
<axw> wallyworld: how deep do you want me to go on this bug? it certainly seems like an issue to me
<wallyworld_> axw: not too deep - just a sanity check that we agree that it needs fixing. babbageclunk can dive in... :-)
<wallyworld_> i think it's a real issue too
<wallyworld_> thumper: what did you want to know?
<thumper> have a user behind proxies where bootstrap is getting stuck downloading agent tools
<thumper> just wondering how much testing we have done of that situation
<axw> thumper: burton-aus is having a similar issue with the vsphere provider in CI
<axw> unresolved though
<axw> so probably not helpful to you...
<thumper> :)
<thumper> balloons: something to add to our CI tests
<thumper> balloons: proxied network installs
<veebers> thumper: we currently have some proxy testing, although not sure off the top of my head the depths that it goes
<thumper> hmm..
<wallyworld_> thumper: i thought we had seen this issue a bit in the past and attempts had been made to make it work. but clearly somthing broke again
<babbageclunk> thumper: I know a bit about proxy stuff, was helping with a maas testing issue to do with it.
<balloons> thumper, add a card in the backlog, or I will tomorrow :)
<babbageclunk> wallyworld_: take a look at: https://github.com/juju/juju/pull/7352?
<wallyworld_> ok
<babbageclunk> thanks!
<wallyworld_> babbageclunk: thanks for fix, land that sucker
<babbageclunk> sweet
 * babbageclunk goes for celebratory run
<thumper> um...
<thumper> wallyworld_, babbageclunk: there is an issue there.
<thumper> or is there...
 * thumper thinks
<thumper> no
<thumper> I'm wrong
<thumper> it's all good
<wallyworld_> phew
<axw> wallyworld: PTAL, I've responded to comments on https://github.com/juju/juju/pull/7346
<wallyworld_> ok
<wallyworld_> axw: i totally forgot about the initial event for all 3 watchers. doh. could you maybe just add a comment so the next dumb person doesn't wonder also
<axw> wallyworld: sure
<axw> wallyworld: could we leave the monday standup where it was? that's sunday for eric and heather, and it's a dropoff day for me
<wallyworld_> ah right ok
<axw> sorry would've said before, just didn't occur till later
<wallyworld_> no worries
<menn0> jam: standup?
<babbageclunk> axw: did you have any thoughts about bug 1686696? I thought we couldn't remove subordinate units once they're deployed?
<mup> Bug #1686696: Subordinate units won't die until all principal relations are gone <juju:Triaged> <https://launchpad.net/bugs/1686696>
<wpk> jam: have you published your review? I don't see it..
<axw> babbageclunk: the subordinate units do get removed when you remove *all* the relations to the subordinate app
<axw> babbageclunk: ISTM that we should remove the subordinate units related to the app from which we remove the relation
<axw> burton-aus: thanks for filing the bug
<burton-aus> axw: no worries.
<rogpeppe> some juju API client refactoring and some extra fallback logic: https://github.com/juju/juju/pull/7338
<wpk>  https://github.com/juju/juju/pull/7353 trivial one, anyone?
<thumper> morning
<hml> wallyworld: hereâs the pr for the arm64 bootstrap bug https://github.com/juju/juju/pull/7354
<wallyworld> ok, thank you, looking in 5 after coffee
<wallyworld> hml: see if my comments make sense to you
<hml> wallyworld: looking now
<hml> wallyworld: working on the revisions
<wallyworld> ty
<wallyworld> hml: i forgot to comment - there should be tests for the various combinations
<hml> wallyworld: got it
<hml> wallyworld: regarding changing DefaultBaseURL = metadataDir , a lot of other code expects it not to have tools at the end and use ToolsURL() to construct it.
<hml> wallyworld: not a lot, but the users
<hml> wallyworld: iâd have to double check on what happens if tools is already there on the URL
<wallyworld> hml: right, so the check is just to see if what's passed in ends with /tools so as to see if we need to set the images path or not. the user is supposed to only pass in the top level dir but as we saw from the bug, they end up passing in /images so we just need to cater for that sort of scenario
<wallyworld> and visa versa when they pass in something with /tools
<wallyworld> we may then need to strip off the /tools before setting DefaultBaseURL
<wallyworld> if that's what the downstream code expects
<hml> wallyworld: so assume that if images or tools is that the end, the other isnât expected
<wallyworld> right
<wallyworld> because that is the basis of the bug
<wallyworld> they were passing in /images and we were setting tools dir
<wallyworld> so we're expanding the behaviour to better match user intent
<wallyworld> DWIM
<hml> wallyworld: agreed
<balloons> wallyworld, menn0, if you can have another quick look at https://github.com/juju/juju/pull/7350 and give +1 or -1?
<wallyworld> ok
<menn0> balloons: looking
<wallyworld> balloons: there are still pyc files there?
<menn0> balloons: done
<wallyworld> balloons: also, we don't need bzrignore right? should be gitignore
<menn0> balloons, wallyworld, thumper: balloons was right about trusty. we're still using MongoDB 2.4 there. if something in the controller or our tests doesn't work with 2.4 then that's a problem.
<wallyworld> hmmmm
<wallyworld> i guess CI needs to ensure we test controllers on trusty
<menn0> wallyworld: which we do. the backup/restore tests use trusty controllers and I suspect a lot more tests do.
<wallyworld> ok
<wallyworld> and we would have controllers on xenial as well
<babbageclunk> ha ha, I love the j-squad meeting names
#juju-dev 2017-05-18
<balloons> Right, we still have a bunch of trusty no worries
<balloons> Ty for review
<axw> hml: for things to do after the sprint: Australia Zoo is pretty close to the sprint location. I didn't think it was that great of a zoo, but if you want to see kangaroos and koalas, there's that
<axw> there's a bus that goes there, or you could drive pretty easily if you feel like driving on the wrong side of the road
<hml> axw: I saw a koalas santuary near Brisbane?
<axw> hml: oh yeah, I think it's near wallyworld's house actually :)
<hml> axw: iâve driven in Ireland, hopefully the roads are wider.  :-)
<axw> probably
<axw> haven't been to ireland
<wallyworld> hml: the koala place is 3 minutes away from me
<axw> but given the rest of europe...
<wallyworld> there's another place closer to the venue; the steve irwin place
<hml> axw: the roads are scarey small in the country side - and easy to find ones with grass down the middle
<wallyworld> crocodile hunter and all that
<axw> (that's Australia Zoo)
<hml> wallyworld: :-)
<wallyworld> we can organise an excursion there if people are interested; a group booking
<axw> wallyworld: if we can have the team dinner at https://www.tripadvisor.com.au/Restaurant_Review-g261638-d1745794-Reviews-Spice_Bar-Mooloolaba_Sunshine_Coast_Queensland.html I wouldn't be unhappy ;)  not sure if it's within budget
<wallyworld> axw: we'll sort something out :-) I was also thinking of Spirit House as a possibility
<axw> wallyworld: in Yandina?
<wallyworld> yeah
<axw> wallyworld: looks nice
<axw> might be nice to get off the strip
<wallyworld> it is - have been there. very good food. but your place looks nice also. degausation too
<wallyworld> we can take inpt from the group to decide :-)
<wallyworld> easy enough to organise a minibus if needed
<wallyworld> i'll organise stuff next week once things are locked in
<axw> yup
<wallyworld> babbageclunk: https://github.com/juju/juju/pull/7336 is updated. there are 2 commits - the 2nd one is the changes due to the rebase. whenever you get a chance is fine
 * thumper takes dog for a walk
<babbageclunk> wallyworld: ok, will look once I get to the bottom of this subordinate thing - I feel like I've nearly got it.
<wallyworld> \o/
<wallyworld> no rush
<wgrant> babbageclunk: Thanks for looking at the subordinate bug.
<babbageclunk> wgrant: :) I haven't fixed it yet!
<wgrant> babbageclunk: I have a suspicion that this it might be related to a couple of the remove-application issues as well, since they mostly involve subordinates.
<wgrant> https://bugs.launchpad.net/juju/+bug/1655486 is one
<mup> Bug #1655486: removal of principal ceph-osd charm stuck in 'executing' state <sts> <OpenStack ceph-osd charm:Incomplete> <juju:Triaged> <ceph-osd (Juju Charms Collection):Invalid> <https://launchpad.net/bugs/1655486>
<babbageclunk> wgrant: ok, I'll keep that in mind, thanks
<wallyworld> babbageclunk: you may get to fix 2 or 3 bugs in one go - legend
 * babbageclunk isn't counting chickens
<wallyworld> axw: babbageclunk: just off for a bit to take son to get stitches out, bbiab
<axw> ok, later
<axw> wallyworld: when you're back, please take a look at https://github.com/juju/juju/pull/7355
<babbageclunk> axw: free for a moment? I think I understand the subordinate problem but not sure how to fix it.
<babbageclunk> wallyworld: back from the hospital yet?
 * babbageclunk is lonely
<menn0> jam: I can't make the standup, or the start at least. it's chaos here and I need to do a kid pickup.
<menn0> babbageclunk: quick call?
<jam> k
<jam> menn0: I take it the CAAS call has already ended?
<menn0> jam: yes
<axw> babbageclunk: sorry went out, do you still need me?
<babbageclunk> axw: No, I talked about it with thumper, I think it makes sense.
<axw> babbageclunk: ok, cool
<babbageclunk> axw: thanks though! I added it to the bug here: https://bugs.launchpad.net/juju/+bug/1686696
<mup> Bug #1686696: Subordinate units won't die until all principal relations are gone <juju:Triaged by 2-xtian> <https://launchpad.net/bugs/1686696>
<axw> babbageclunk: sounds logical to me. maybe call it WatchUnitRelations though
<babbageclunk> axw: yeah, I am - forgot to update the comment.
<babbageclunk> axw: Cheers!
<wallyworld> axw: sorry, totally missed the ping, looking now
<axw> wallyworld: thanks
<wallyworld> np
<rogpeppe> axw, wallyworld: any chance of a review of some of this API client refactoring? https://github.com/juju/juju/pull/7338
<axw> rogpeppe: will look shortly
<rogpeppe> axw: tyvm
<axw> rogpeppe: just one trivial. good stuff, thank you
<rogpeppe> axw: thanks!
<wpk> wallyworld: re: landscape tests failing, I have a fix, I'm writing a test and will have a PR in a few minutes
<wpk> wallyworld: jam: https://github.com/juju/juju/pull/7357 short one, simple one
<jam> wpk: saw it before you advertised, lgtm
<jam> wpk: did you respond to my review of SSH? 7348
<wpk> jam: the first one? yes
<wpk> I see that all your comments are outdated
<jam> ah, I just had to reload the page
<wpk> web 2.0...
<wpk> When is RC1 scheduled to be released?
<wallyworld> wpk: sorry, i was at soccer, bck now. thanks for the fix!
<wpk> wallyworld: always reminds me of https://www.youtube.com/watch?v=2sD_8prYOxo ;)
<wallyworld> wpk: yeah, i like john cleese
<wpk> and it's merged.
<jam> wpk: I responded to your update
<wpk> k, thanks
<gsamfira> Hi! Any volunteers for a 2 line PR? :P
<mup> Bug #1662272 opened: Agents stop running hooks and are hung <canonical-is> <juju-core:New> <https://launchpad.net/bugs/1662272>
<mup> Bug #1662272 changed: Agents stop running hooks and are hung <canonical-is> <juju-core:New> <https://launchpad.net/bugs/1662272>
<mup> Bug #1662272 opened: Agents stop running hooks and are hung <canonical-is> <juju-core:New> <https://launchpad.net/bugs/1662272>
<thumper> morning
<wpk> night
<balloons> thumper, wallyworld, I believe https://github.com/juju/juju/commit/fbe29cb10097aa301fba795f449cb617c88420c8 broke backup/restore. Just confirming now, it'll be a bit
<thumper> balloons: ta
<babbageclunk> wallyworld, thumper: anyone remember the trick for creating subordinate units in tests?
<thumper> babbageclunk: can the factory do it?
<babbageclunk> thumper: not directly
<wallyworld> otp, sorry, give me a sec
<wpk> can someone take a look at https://github.com/juju/juju/pull/7353 ? I made some changes after jam approved it and I'd like to merge it before RC1 if possible
<wpk> (and if you think it's ok then $$merge$$ it)
<babbageclunk> thumper: ooh, I remember where I had to do it now - ensuring principal units get migrated before subordinates.
<babbageclunk> wpk: Looks good to me. Merged!
<thumper> wallyworld: https://github.com/juju/juju/pull/7363/files
<wallyworld> looking
<wallyworld> thumper: gret, ty
<wallyworld> great
<thumper> well poo
<thumper> my theory around logs not being queries across models is wrong
<babbageclunk> thumper: you and Ada would definitely get on.
<thumper> wallyworld: here is another datapoint
<thumper> in http://juju-ci.vapour.ws/job/github-check-merge-juju/1087/artifact/artifacts/grant.log
<thumper> 22:53:35 ERROR juju.cmd.juju.commands bootstrap.go:492 unable to contact api server after 1 attempts: unable to connect to API: x509: certificate signed by unknown authority
<wallyworld> hmmm, joy
<thumper> wallyworld: also I can't make the standup today, taking daughter to the Drs
<wallyworld> ok
<axw> wallyworld: how'd the demo go?
<wallyworld> axw: aborted - screen sharing failed
<wallyworld> going to retry next week
<axw> wallyworld: :(  I thought that was a solved problem
<wallyworld> it  worked when i shared the console with conjure-up but sharing a browser window failed. wtf
<axw> thumper: that cert error is nothing to do with ssh though. that's about the TLS cert used to connect to the API
<axw> I can believe that my changes might have broken backup/restore, but I don't think that particular error is related
<thumper> axw: I was raising the point with wallyworld because we talked earlier about cert changes that rogpeppe had been doing recently
<axw> thumper: ah ok
<thumper> but perhaps the strict host checking is breaking backup / restore
<axw> wallyworld: no online travel tool yet?
<axw> just got the email, but says to use provider
<axw> I can email sarah, just wondering ify ou know
<axw> thumper: yes, I think I did break restore. in state/backup/restore.go, the ssh command is running without having any host keys set
<axw> thumper: so we should poke them in, they'll be in the state DB
#juju-dev 2017-05-19
<wallyworld> axw: no, we use the normal provider
<thumper> axw: I don't suppose you know how to configure log forwarding?
<axw> thumper: you need to set logforward-enabled=true, syslog-host=<host>, syslog-ca-cert=<pem-encoded-ca-cert>, syslog-client-cert=<pem-encoded-client-cert>, syslog-client-key=<pem-encoded-client-key>
<axw> so easy ;)
<thumper> in the model config?
<axw> thumper: yep
<axw> thumper: in the controller model config
<axw> thumper: not to be confused with controller config...
<thumper> hazaah
<thumper> axw: I was thinking... we could make this change for log forwarding completely transparent...
<thumper> by just making the worker model dependent and not one for the controller
<thumper> and still have the tailer just deal with a single model
<axw> thumper: yes we could. we'd just need to use model config defaults to ensure all models get the same syslog-foo config
<thumper> or... transparently have that worker just get the config from the controller
<thumper> and don't worry at this stage about getting it from the model config for *that* model
<thumper> it is a bit ick, but not terrible
<axw> thumper: what I want eventually is for different models to log to the relevant cloud log sink. so a GCE model should go into the stackdriver logging for that model's project. should be able to do something similar for Azure (though I can't quite figure out the API)
 * thumper nods
<axw> thumper: that would allow JAAS users to get their model logs
<axw> without going through debug-l;og
<thumper> sounds very useful
<axw> thumper: it would be useful to have controller-wide config too though. so maybe a hierarchy.
 * thumper nods
<thumper> sounds like we should start a spec outlining the work
<axw> should also run it by IS and JAAS, I'm sure they'll have some things they'd want
<thumper> yeah
<thumper> for the future work for sure
<thumper> for the "let's not screw jaas"
<thumper> I'm all for minimal exposure to the way it works now
<axw> yup
 * thumper may have found the next piece of work for babbageclunk
<thumper> babbageclunk: call when you are around?
<axw> wallyworld: have you snapped juju recently? it wants to use golang-go, which is go-1.6...
<axw> hmm maybe it doesn't matter
<babbageclunk> thumper: back, sorry, went for a run
<thumper> gee, wouldn't want to run here today
<thumper> it is wet and cold
<thumper> getting very cold
<thumper> like 5Â° cold
<thumper> babbageclunk: hangout?
<babbageclunk> beautiful day for a run here, cold and sunny and windy
<thumper> babbageclunk: more stuff https://hangouts.google.com/hangouts/_/canonical.com/stuff
<babbageclunk> wallyworld: can a relation change from being container-scoped to global-scoped? Maybe if there's charm upgrade? Trying to decide whether it's safe to cache decisions.
<wallyworld> babbageclunk: i don't think so, no
<rogpeppe> axw: saw my name mentioned earlier - did my recent changes break anything?
<axw> rogpeppe: not sure, wallyworld said something about some cert related failures
<wallyworld> rogpeppe: i sent an email
<rogpeppe> wallyworld: ah, thanks
<wallyworld> it appears it may have
<wallyworld> not 100% sure
<rogpeppe> wallyworld: are those errors happening every time?
<wallyworld> not sure, there had only been one or two test runs post the landing that i had checked this morning
<rogpeppe> wallyworld: hmm, it definitely isn't happening every time. weird.
<rogpeppe> wallyworld: it's definitely the kind of area that *could* have been affected by my change
<rogpeppe> wallyworld: but i'd expect it to be deterministic
<wallyworld> yeah. it's plausible the pR and failures are related but not certain
<wallyworld> i looked at the test runs just prior to the landing and couldn't see the failures there
<wallyworld> but hard to draw a conclusion when it is intermittent
<rogpeppe> wallyworld: yeah
<wallyworld> i was thinking something may jump out at you
<wallyworld> it's not an area i have expert knowledge in
<rogpeppe> wallyworld: nothing's jumping out so far
<wallyworld> joy
<rogpeppe> wallyworld: we'll have to see if more of those kind of errors happen
<wallyworld> yeah, need a few runs to gauge the depth of the issue
<rogpeppe> wallyworld: in http://juju-ci.vapour.ws/job/github-check-merge-juju/1087/artifact/artifacts/grant.log there's at least one suspicious-looking error after the cert error
<rogpeppe> 22:53:50 ERROR juju.tools.lxdclient client_instance.go:267 while removing instance "juju-85ed71-0": Failed to destroy ZFS filesystem: cannot open 'lxd-pool/containers/juju-85ed71-0': dataset does not exist
<rogpeppe> wallyworld: so perhaps the cert error is usual
<wallyworld> maybe, could be a timing issue
<wallyworld> axw: a small PR, quick review? https://github.com/juju/juju/pull/7365
<axw> wallyworld: sure, just a minute
<axw> wallyworld: swap you https://github.com/juju/juju/pull/7366 ?
<wallyworld> ok
<wallyworld> axw: those pyc files were supposed to be removed already!
<axw> wallyworld: I think they were removed in one directory but not the other
<axw> anyway, added to gitignore so they won't sneak back in
<wallyworld> 2 files is better than 108 :-)
<wallyworld> axw: lgtm, will be good to see those tests passing again
<axw> wallyworld: to save a roundtrip, my reply to your Q: "Why? ssh.Client.Command documents the argument as taking the syntax [user@]host. It shouldn't be needed."
<wallyworld> axw: ok, no worries, i just thought it made it more obvious to the reader in the restore code. but i'm totally +-0 , ie no care factor either way
<axw> wallyworld: if someone gets surprised they can add it back in :)
<wallyworld> axw: i called it "cloudProviders" becuase it returns both addable and non-addable ones in 2 separate slices
<axw> wallyworld: but the result is "providers", and "unsupported"
<axw> wallyworld: cloudProviders+providers+unsupported doesn't tell me what it does
<wallyworld> yeah, i just reused the previous var names, i can change to supported and unsupported
<axw> no biggie, just not a super useful name when you're out of context
<wallyworld> yeah, i'll come up with something
<wallyworld> there's also a test isolation issue too from what was there already :-/
<wallyworld> in the credential related suites somewhere. need to fix that too
<wpk> Q: is it OK to remove API that's used only internally, by worker?
<babbageclunk> wpk: I think the problem is that the controller might be running a more recent version of jujud than the agents, so they might still try to talk to the removed API/
<babbageclunk> wpk: Oh, hang on - is it used by a worker in the unit or machine agents, or only in the model agent?
<babbageclunk> wpk: I think in the latter case it's fine.
<wpk> only in model agent
<wpk> (discoverspaces worker)
<rogpeppe> anyone know if the old juju reviews are still online? e.g. http://reviews.vapour.ws/r/1609
<babbageclunk> rogpeppe: no, I think they turned them off a few weeks ago
<rogpeppe> babbageclunk: oh
<rogpeppe> babbageclunk: i think that's a really bad idea
<rogpeppe> babbageclunk: they're actually a crucial part of the history of the project
<babbageclunk> rogpeppe: I know - just after it happened I wanted to find something that I remember discussing in a review.
<rogpeppe> babbageclunk: commit messages are often cursory at best
<rogpeppe> babbageclunk: can we try getting them turned back on again?
<babbageclunk> rogpeppe: yeah, I'll mention it to Tim
<rogpeppe> babbageclunk: thanks
<babbageclunk> (I mean, I assume they've kept the data!)
<babbageclunk> :o
<rogpeppe> babbageclunk: if they haven't, i'll be very unhappy
<babbageclunk> I'll pass that on too
<rogpeppe> babbageclunk: :)
<balloons> hml, can I get a review of https://github.com/juju/juju/pull/7362?
<hml> balloons: looking
<hml> balloons: ha - i hate assuming anythingâ¦ butâ¦ thatâs a lot of files.  :-)
<balloons> hml, :p It's akin to the PR I mention.. It's more or less dumping in the code from the old repos into juju
<balloons> hml, there's one more for packaging, once I complete it :-)
<hml> balloons: figuredâ¦ iâll go with assume this time if thatâs okay with  you?  or do you want a sanity check?
<balloons> hml, i don't just want to blind push things, hence the PR. So yes, a quick sanity check is most appreciated
<hml> balloons: sanity checking now
<balloons> I had to tweak the history on this import, so make sure it's clean for you
<hml> balloons: where is the origin repro - havenât mastered finding them in launchpad yet
<balloons> hml, ahh, right. https://code.launchpad.net/~juju-qa/juju-ci-tools/repository
<hml> balloons: ty
#juju-dev 2017-05-20
<mup> Bug #1690166 changed: Juju add-machine CentOS failed with "no tools found" <juju:Triaged> <https://launchpad.net/bugs/1690166>
<mup> Bug #1690166 opened: Juju add-machine CentOS failed with "no tools found" <juju:Triaged> <https://launchpad.net/bugs/1690166>
<mup> Bug #1690166 changed: Juju add-machine CentOS failed with "no tools found" <juju:Triaged> <https://launchpad.net/bugs/1690166>
#juju-dev 2018-05-15
<thumper> https://github.com/juju/collections/pull/1
<thumper> veebers: can I grab you for a chat?
<thumper> ugh
<thumper> I'm in the wrong channel
#juju-dev 2018-05-18
<rogpeppe> dunno if anyone's around, but does anyone know why the merge bot doesn't seem to be working in github.com/juju/cmd ?
