#juju-dev 2013-02-04
<jam> wallyworld: poke
<wallyworld> hi
<rogpeppe> mornin' all
<TheMue> rogpeppe: Hiya
<mramm> morning all
<TheMue> lunchtime
<rogpeppe> lunmch
<rogpeppe> lunch, even :-)
<niemeyer> Lunch here as well
<rogpeppe> jam: i'd appreciate a final look at https://codereview.appspot.com/7231080/ to make sure your concerns have been addressed
<rogpeppe> jtv: would also appreciate your comments, as it's an alternative to your CL
<dimitern> rogpeppe: PTAL https://codereview.appspot.com/7265043
<jtv> rogpeppe: I've been meaning to ask... what does CL stand for?
<rogpeppe> jtv: change list
<jtv> Ah.
<jtv> Anyway, I could have a look tomorrow.
<rogpeppe> jtv: i can't remember its origins exactly.
<rogpeppe> jtv: ok, thanks.
<dimitern> fwereade: possibly you too? ^^
<jtv> (Bedtime now, really :)
<fwereade> dimitern, I'll take a look -- sent some comments on fridays, what I can remember of our discussion
<dimitern> fwereade: that's odd i cannot see them
<fwereade> dimitern, literally just now -- i saw i'd left them in draft
<rogpeppe> dimitern: LGTM
<dimitern> rogpeppe: tyvm
<rogpeppe> jtv: what's your time zone?
<dimitern> fwereade: ah, ok
<fwereade> dimitern, this one LGTM though :)
<dimitern> fwereade: great, I'm landing it then
<dimitern> 10x
<dimitern> jam, mgz, wallyworld: ping
<fwereade> dimitern, er, looked like I actually didn't send them, did now
<dimitern> fwereade: aha yeah,  that's for the other CL though
<fwereade> dimitern, yeah, sorry I wasn't clear
 * dimitern got bitten by the goose bot
<dimitern> now that goose trunk is protected it gets a bit more complicated to land a goose CL
<fwereade> dimitern, fwiw https://codereview.appspot.com/7227045/ and https://codereview.appspot.com/7227063/ are lying around a bit
<dimitern> fwereade: cheers, will take a look in 5m
<jam> dimitern: what did you get bit by? (I don't see any rejected MPs for you, but maybe I missed it)
<jam> (mgz is still at FOSDEM and wallyworld should be sleeping)
<dimitern> jam: I tried lbox submit, but then found your mail and figured out how to merge it with the bot
<fwereade> need to buy tea, bbiab
<jam> k
<dimitern> fwereade: both reviewed
<fwereade> dimitern, excellent, thanks
<dimitern> fwereade, rogpeppe: i'd appreciate one last check of https://codereview.appspot.com/7226068
<rogpeppe> dimitern: looking
<rogpeppe> dimitern: reviewed
<dimitern> rogpeppe: thanks!
<dimitern> fwereade: ping?
<dimitern> btw going out, will be back in 30m
<rogpeppe> i'm off for the night.
<rogpeppe> cheers all.
<dimitern> rogpeppe: g'night
#juju-dev 2013-02-05
<hazmat> i'm trying to debug why the charm store doesn't have a particular charm.. specifically landscape-client none of the personal versions or the 'official' version are available
<hazmat> i wrote a quick go program and verified that the charm loads correct, and that the its in the ls getBranchTips output..
<hazmat> i'm stumped as to why its not in the store then.. any suggestions?
<hazmat> hmm.. i did find one personal archive in the store.. cs:~therve/precise/landscape-client ( but none of the 4 others seems to have made it)
<jtv> Is the schema package documented anywhere?
<jtv> This is driving me nuts.  Getting a strange error in my tests:
<jtv> Panic: runtime error: invalid memory address or nil pointer dereference (PC=0x8057A45)
<jtv> Weird thing is, this is the third of a series or near-identical lookups.
<dimitern> jtv: what are the first couple of lines at the end of the panic dump?
<jtv> I'm trying to test an environs/*/config module.
<dimitern> paste?
<jtv> Hi dimitern!  Coming up.
<dimitern> hi :)
<jtv> dimitern: https://pastebin.canonical.com/83822/
<jtv> Part of the weirdness is that I see no reason why that configuration string shouldn't be there.
<dimitern> jtv: so do you have admin-secret defined in the config attrs?
<jtv> I thought I did.
<dimitern> jtv: can I look at the module that fails? have you proposed the branch?
<jtv> Not yet.  I'll put it up for you somewhere.  Thanks.
<jtv> dimitern: try lp:~jtv/juju-core/mpv-config
<dimitern> jtv: np, I know how it is with these pesky go errors - it took me some time to start getting what's actually was wrong
 * dimitern looking
<jtv> I made _some_ progress: I converted a c.Check(err, IsNil) to an assertion and now at least I'm not getting the segfault.
<jtv> Just a failure I can't explain.
<jtv> I could see how the checks for all 3 config items would fail.  But what did I do to break just the last one?
<dimitern> jtv: so the difference between Check and Assert is only in that the latter fails the test immediately, while the former still marks it as failed, but continues to run it, so there's something going on after that Check you changed
<jtv> Yes...  and I'm not even so worried about that.
<jtv> What I'm worried about is how the error comes back non-nil in the first place.
<jtv> (The check that fails looks a bit different from the others right now, but that's from experimentation with the problem.)
<dimitern> jtv: so I can see a potential problem in newConfig
<dimitern> jtv: cfg should be := make(map[string]interface{})
<dimitern> jtv: but since you're initializing it, probably should be ok - but try separating the making and init
<jtv> Yeah.  I've just been doing that for new().
<jtv> I haven't been able to find any explanation as to why make() is needed if returning the address of a local is guaranteed to be OK.
<dimitern> jtv: try: cfg := map[string]interface{}{values} - can skip the loop
<dimitern> make is needed for maps
<dimitern> or slices
 * jtv tries
<jtv> dimitern: I'm not so sure I can skip the loop... "values" is meant to complement (and override) the existing "cfg."
<jtv> dimitern: no change.  :(
<dimitern> jtv: hmm
<dimitern> jtv: let me try you branch locally
<jtv> Thanks again for helping out.  I really appreciate it.
<dimitern> np
<jtv> dimitern: I just updated my branch to avoid stack allocation of persistent objects.
<dimitern> jtv: so as far as I can see, admin-secret is not set for some reason by the time it's validated in config:Validate()
<jtv> Yes... but how is it different from the other items?  Wait...  maybe it has a special meaning to juju.
<jtv> Yup.
<jtv> I guess attrs only receives the "unknown" attributes, and the juju-standard ones go somewhere else.
<dimitern> hmm shouldn't be
<dimitern> I'm comparing it with openstack provider to see what could be wrong
<jtv> Yup.  That's part of what I cargo--culted.
<dimitern> I think the map is structured wrong
<dimitern> see, the attrs should match the environments.yaml
<dimitern> i.e. tree-based, not flat
<dimitern> type attrs map[string]interface{}
<dimitern> cfg := attrs{"environments":attrs{"testenv":attrs{"type":"maas"}}}
<dimitern> something like this
<jtv> Well this is related to rogpeppe's ongoing work tighten up those tests.
<jtv> When you don't need to do the round-trip, you don't need that tree above the environ config.
<dimitern> hmm
<dimitern> yes it seems if you're using tree-based cfg, you need to marshal it to yaml and use ReadEnvironBytes, otherwise NewFromAttrs
<dimitern> sorry I couldn't help more, but ask rogpeppe when he's around
<jtv> I will.  Thanks.
<jtv> (What you see is copied from his proposed test change :)
<dimitern> I see :) yeah, definitely he's the man then
<rogpeppe> jtv, dimitern: hi
<dimitern> rogpeppe: hiya
<rogpeppe> jtv: are you still around?
<rogpeppe> dimitern: what's the name of jtv's branch? i'll take a look at what's going on.
<dimitern> rogpeppe: lp:~jtv/juju-core/mpv-config
<rogpeppe> dimitern: ta
<jtv> Hi rogpeppe
<rogpeppe> jtv: hiya
<rogpeppe> jtv: i'm just having a look at your branch now
<jtv> My problem is now that I'm not seeing my admin-secret in my test config.
<jtv> Thanks.
<rogpeppe> jtv: nearly worked it out. it's being lost in maasEnvironProvider.Validate
<jtv> Is it?  I wrote it, but I have no idea what most of it means.  It's just stuff that seems to be needed based on other implementations.
<rogpeppe> jtv: yes, i'm afraid the config stuff is not ideal. it's been through a fair few iterations, but we're still not entirely happy with it.
<rogpeppe> jtv: well, i'm not anyway :-)
<rogpeppe> jtv: i think you're right about making the round trip test separate BTW
<jtv> Thanks.
<jtv> I don't mind a bit of legacy complexity, but it'd be so nice to know what's going on!  :)
<jtv> Hmmm mango from my own tree.
<fwereade> hey all
<rogpeppe> fwereade: yo!
<dimitern> fwereade: hey!
<fwereade> jam, dimitern, mgz: if you want to talk about last night's braindump let me know
<dimitern> fwereade: what's that?
<fwereade> hum, did I just send it to mramm?
<fwereade> dimitern, about get/set and upgrade-charm
<dimitern> fwereade: ah, this one, yeah
<dimitern> fwereade: sounds interesting
<dimitern> fwereade: I have a couple of things in line on the provider, which I hope to land today and then I can look into get/set or charm upgrades
<fwereade> dimitern, I strongly favour all of us having a chat about them before anyone gets too deep into implementing them, there are probably assumptions that  I have failed to capture that a chat could smoke out
<dimitern> fwereade: sure, we'll talk first, I have no idea where to begin anyway :)
<rogpeppe> jtv: ah, i've found your problem
<rogpeppe> jtv: at least, i think i have; let me check.
<rogpeppe> jtv: yup.
<rogpeppe> jtv: the problem is you've included "admin-secret" in the maasConfigChecker schema fields
<dimitern> rogpeppe: that's odd - so what does this cause?
<rogpeppe> jtv: but you need to put only fields that are unknown to the config package in there, otherwise they'll override the known attributes when you do the Apply at the end of Validate.
<rogpeppe> jtv: the fact that you needed to put admin-secret in the schema defaults, despite it being a required field, was probably a hint.
<jtv> I see.  Thanks for finding that!
<rogpeppe> jtv: it's easy stuff to get wrong though. i'd love to find a nice way to factor out a lot of this stuff.
<jtv> I wasn't aware that I needed to put it in the schema defaults, really.
<dimitern> rogpeppe: so schema defaults is only for fields which are not required and should have defaults?
<rogpeppe> dimitern: if you don't have a schema default, the field is required
<dimitern> rogpeppe: I see!
<rogpeppe> dimitern: but in this case the schema is used to validate only fields returned by config.Config.UnknownAttrs
<dimitern> rogpeppe: I get it now
<dimitern> 10x
<jtv> Oh, so if I want these fields to be required, I can just leave them out of the schema instead of checking for them.
<jtv> I mean, out of the defaults.
<jtv> Not out of the schema, obviously.
<rogpeppe> jtv: out of the defaults, yes
<jtv> Yayy that gets rid of some code.
<rogpeppe> jtv: that's kinda the point of the schema - it does quite a few checks for you so you know it's in a certain form before you start checking
<jtv> Yeah, it's just that I couldn't find any documentation whatsoever for it.
<jtv> So I had no idea what it did that I could rely on.
<dimitern> it's probably worth a comment somewhere then!
<jtv> It would be, definitely!
<rogpeppe> jtv: have you tried "go doc launchpad.net/juju-core/schema" ?
<jtv> Nope.
<rogpeppe> jtv: if in doubt, read the docs :-)
<jtv> Hmm... that just produced the stuff I'd already read.
<rogpeppe> jtv: although they're not great there, it's true
<jtv> Not documentation, just implementation notes.
<jtv> What is a Checker?  A Checker is called recursively etc.  Now you know, so the rest can be explained in terms of Checkers!
<rogpeppe> jtv: yeah
<rogpeppe> jtv: one of gustavo's earlier efforts :-)
<jtv> I find one of the hardest things to imagine is not knowing something that you do know.
<jtv> The ability to grasp something complicated and to explain it don't really fit comfortably into one brain at the same time.  :(
<rogpeppe> jtv: there should be a package-level comment that explains how things work
<jtv> Definitely, yes!
<rogpeppe> jtv: one small remark: usually we name error values starting with "err", so your "noMaasServer" would be errNoMaasServer.
<rogpeppe> jtv: another one: there's not much point in putting a "maas" prefix on types/variables that are local to the maas package, so i'd define "environProvider", not "maasEnvironProvider", etc, thus saving quite a bit of typing :-)
<jtv> Ah OK, I'll patch that up quickly, thanks.
<rogpeppe> jtv: ah, and error messages generally don't start with capital letters (they usually form part of a longer "sentence")
<jtv> Well I found the environProvider slowed me down a lot because it sounds just like EnvironProvider, and because it's relative to the package you're in.
<jtv> Ah, yes, back to K&R times.  :)
<jtv> When Bearded Dinosaurs Roamed the Earth.
<dimitern> :D
<jtv> Can I punctuate?
<rogpeppe> jtv: sure, but there's generally no full stop. an error message isn't the full message that will be printed to the user.
<jtv> Ah.
<jtv> Good thing most of those error messages are no longer needed!
<rogpeppe> jtv: environProvider is supposed to sound like EnvironProvider BTW - it's a provider-specific implementation of the EnvironProvider interface.
<rogpeppe> jtv: all types in Go are relative to their package - it's common to define names that make sense in the context of the package itself.
<rogpeppe> jtv: so if you think of it as "maas.environProvider" it perhaps makes sense. rather than "maas.maasEnvironProvider", which has a certain amount of redundancy.
<jtv> I understand that they're supposed to sound similar, but they sound _too_ similar!  And I'm fully aware of the whole idea of nested namespaces.  I myself thought that was a good idea, back in the 20th century.  The real world taught me otherwise!
<TheMue> The best way to use a language is to use the idioms of that language. Java in Java, Smalltalk in Smalltalk, Go in Go.
<rogpeppe> jtv: namespaces aren't nested - they're two llevel. package.name
<rogpeppe> jtv: well, three level if you count structs and interfaces.
<rogpeppe> jtv: what TheMue says - this are just standard Go idioms. they seem to work pretty well most of the time.
<jtv> Film at eleven!
<rogpeppe> jtv: :-)
<jtv> I mean, this stuff we all know.  I'm not saying it's new to me, but that it's stuff I found to be bad ideas.
<rogpeppe> jtv: what made you think that nested namespaces weren't a good idea BTW?
<jtv> It increases the overhead of finding out what's going on.  If I see package.Name, I need to find out which package that actually is.
<jtv> It's an extra step of indirection in an inner loop.
<jtv> Increases the overhead of understanding new code tremendously.
<rogpeppe> jtv: luckily it's possible to do that mechanically and instantly.
<jtv> But tools like grep won't know about that.
<rogpeppe> jtv: there are tools that do.
<dimitern> i think what's confusing at first is that modules and files are not orthogonal in go
<rogpeppe> jtv: making all names unique takes us back to the pre-K&R days of having a shared struct field namespace
<rogpeppe> jtv: i mean pre-ANSI C of course
<dimitern> you can have module X, which is spread across several files and all of them define it, so finding X.Y is not as straightforward as in other langs
<TheMue> dimitern: Thankfully packages and files aren't the same. It would be a hard limitation.
<dimitern> but has it's advantages too ("silent" scope membership) and access in-module
<rogpeppe> dimitern: yeah, i rely heavily on godef (http://godoc.org/code.google.com/p/rog-go/exp/cmd/godef)
<rogpeppe> dimitern: which takes me straight to the definition of any name.
<dimitern> rogpeppe: sweet! I didn't know this
<dimitern> rogpeppe: thanks, I'll definitely use this
<dimitern> beats rgrep by a margin :)
<rogpeppe> dimitern: i believe there's perhaps similar functionality in some of the Go-modes for other editors.
<dimitern> rogpeppe: not for emacs, AFAIK
<rogpeppe> dimitern: BTW godef is a not-too-thick layer on top of http://godoc.org/code.google.com/p/rog-go/exp/go/types
<rogpeppe> dimitern: so you might want to customise it for your situation
<rogpeppe> dimitern: (it's nice when a single click takes you to the definition.
<dimitern> rogpeppe: yeah, I could try to automate it somehow from the editor when I have some time
<rogpeppe> )
<rogpeppe> dimitern: it's particularly good when you've got something like: x.foo.Bar().Arble, in the middle of a loop where is the loop variable etc, and you can click on Arble and it'll do all the type inference (through embedded fields too) and go straight there.
<dimitern> rogpeppe: so not only X.Y, but even more complex expressions are supported
<rogpeppe> dimitern: yeah - it supports almost everything. one notable limitation is it doesn't support import to "."
<rogpeppe> dimitern: i need to fix that
<dimitern> rogpeppe: ah, yeah, I see how this can be tricky
<rogpeppe> dimitern: it's not actually too tricky - it's just not as efficient as i wanted it to be. i thought . imports would be very rare, but gocheck is a sadly common exception.
<dimitern> yeah
<rogpeppe> jtv: as for grep, i have an experimental command which covers some of the same ground, and makes it possible to grep for particular symbols even if they don't have a unique name: http://godoc.org/code.google.com/p/rog-go/exp/cmd/gosym
<jtv> Argh, more tools, more cognitive load!
<rogpeppe> jtv: that's the unix way :)
<rogpeppe> jtv: BTW a grep pattern i use quite a bit: grep for ' Foo(' finds functions and method names named Foo, with surprisingly little redundancy.
<jam> w7z: /wave
<jam> morning
<w7z> hey!
<jam> w7z: good to have you back. how was fosdem?
<w7z> good! I'm feeling a little fluish as an after effect, but not as ropey as I was last night, just ignore the coffing
<jtv> rogpeppe: sorry for being quiet â in meetings!
<dimitern> rogpeppe: can you take a look at a couple of related trivials? https://codereview.appspot.com/7307046/ and https://codereview.appspot.com/7299045/
<rogpeppe> jtv: np
<dimitern> jam, w7z: morning
<jtv> rogpeppe: would you be up for reviewing that branch?  It's for our feature branch.
<rogpeppe> jtv: sure
<rogpeppe> jtv: did you see my comments on gomaas BTW?
<jtv> Oh, yes...  still have to go into details with those.
<jtv> Too many tabs open!
<rogpeppe> jtv: i have that problem
<jtv> The Launchpad+Rietveld split makes me worse at it.  :)
<jtv> Found it.
<rvba> rogpeppe: I just saw your review on gomaasapi, thanks a lot for that, I'll work on it today.
<rogpeppe> rvba: cool, thanks.
<dimitern> rogpeppe: ^^ it's what we discussed last week
<jtv> In particular, we did talk about the idea of representing a higher abstraction level.
<rogpeppe> dimitern: am on it
<dimitern> rogpeppe: thanks
<jtv> We didn't want to mirror the whole MAAS API on that side manually â so our hope is that at some point we can generate a native API representation in some automated fashion.
<jtv> Until then, given time constraints, we kept it very basic.
<rogpeppe> jtv: perhaps, to start with, you could restrict the provided API to the things that juju needs.
<rogpeppe> jtv: and build it up from there.
<jtv> That option came up, but it's still mirroring the API details manually...  plus it increases the risk of moving to an automated API.
<jtv> Because it may require changes in approach.
<jtv> For now we don't need to make very  intensive use of the API yet, so we went with something highly generic that'll do for what we need.
<jtv> Time pressure is a big thing for us.  :)
<rogpeppe> jtv: as it is, the gomaasapi package is pretty incomprehensible without a deep understanding of how the maas client-server interaction works, which seems to lose the point of the package.
<jtv> Yes, but bear in mind that the package's immediate reason for existence is the work we're doing now, immediately after.
<jtv> So see this more as laying the foundations for an independent front-end, rather than providing a full front-end for general use.
<jtv> (Also the MAAS API is extensively documented, so though it's not easy, it should be possible to figure out)
<rogpeppe> jtv: i'd be happier if the surface area was much smaller.
<jtv> Measured in what terms?
<dimitern> jam: why you think it'll be tricky to land my change? what ordering?
<jam> dimitern: you can't just mark it approved, because it won't past the juju-core test suite
<jam> I mentioned it in my email
<dimitern> jam: yes, so how then
<dimitern> jam: juju-core first?
<rogpeppe> jtv: the number of artifacts exported from the package
<rogpeppe> jtv: most of the functions and methods in the package feel like http utility functions.
<jtv> Well to be honest some of those things probably just shouldn't be exported â but those things are subject to change and Go makes it a bit harder to streamline them.
<jam> dimitern: so you can, at the risk that if there was something you didn't catch, you've broken the juju-core suite until your goose patch lands.
<jam> The manual way is to do the merges locally, make sure everything passes, and then push them up to the right location.
<rogpeppe> jtv: what do mean by "Go makes it a bit harder to streamline them." ?
<jtv> rogpeppe: all you really need to know, I think, is JSONObject, MAASObject, and a constructor.
<jtv> Un-exporting an item means changing its name everywhere.
<dimitern> jam: can you explain the manual way in more detail?
<rogpeppe> jtv: luckily the compiler will tell you exactly where you need to change the name...
<jtv> Yes, but you have to go ask it.
<jtv> And make the changes.
<jtv> Being told by a computer what work you need to do is not the same as not having to do it.  :)
<rogpeppe> jtv: sure, but it's not more than a minute or so's work.
<jam> dimitern: cd $GOPATH/src/launchpad.net/juju-core; bzr merge MY_JUJU_PATCH; cd ../goose; bzr merge $MY_GOOSE_PATCH; py test.py (-live); cd ../juju-core; go test ./...; bzr commit -m "?"; cd ../goose; bzr commit -m "?"; bzr push bzr+ssh://goose-bot@bazaar.launchpad.net/~goose-bot/goose/trunk; cd ../juju-core; lbox submit
<jtv> rogpeppe: I'm sure it is.  But so is everything else!
<rogpeppe> jtv: (BTW i did write that gosym command to try and make it easy to make bulk changes like that automatically; it needs some work though)
<jtv> Oh, it helps automate that?  That'd be very helpful for something like this.
<rogpeppe> jtv: can you explain the rationale behind JSONObject, BTW?
<jam> rogpeppe: does 'go fmt' take a regex, or do you use go fix?
<jam> (can you use go fix?)
<rogpeppe> jam: gofmt can do expression rewriting, but it's not type-aware.
<rogpeppe> jam: go fix is only used for go core API changes
<jam> rogpeppe: sure, I wasn't sure if you could pass it your own transformations.
<dimitern> jam: and if I do it the usual way - first submitting the juju patch, and immediately after coping the commit msg in the MP in LP and marking it as Approved?
<jtv> rogpeppe: JSONObject is there to provide an abstraction layer that lets us provide (and test) dynamic data types including MAAS object types.
<rogpeppe> jam: no. i think that coming up with a language that can express sufficiently transformations is a hard problem
<dimitern> dimitern: juju-core will be broken for like less than 10m
<jam> dimitern: if juju lands first, it should work, but you just open the risk that you've broken the test suite until goose lands.
<jtv> rogpeppe: I know the caller could just do everything with casts, but that takes aware our room to explore the problem and make changes.
<dimitern> jam: ok, I'll try that - it seems simpler
<jam> dimitern: it is the "wrong" order, but I'm pretty sure it is what wallyworld did earlier, and it certainly is easier :)
<wallyworld> jam: i tried the "right" way, but no luck
<jam> dimitern: it will stop working once commits t ojuju-core actually have to pass their test suite.
<jam> wallyworld: what step didn't work for you?
<rogpeppe> jtv: i'm not sure i see how GetString is better than a cast
<dimitern> jam: but that'll be fixed once the goose patch lands, right? so it's just a few minutes of breakage
<rogpeppe> jtv: i think it would be better to simply return the object as unmarshalled json
<jtv> rogpeppe: we still need to think about things like what is an error and what is a panic.
<wallyworld> jam: longish  story, bzr push to goose-bot trunk returned AppendRevisionsOnlyViolation error
<dimitern> rogpeppe: I'll land https://codereview.appspot.com/7299045/ - if you don't mind
<wallyworld> jam: plus manually approving mp didn't trigger tarmac
<wallyworld> jam: or maybe it did, but i couldn't ssh in to the machine to seer the logs
<rogpeppe> dimitern: yes sorry, LGTM
<dimitern> rogpeppe: tyvm
<rogpeppe> jtv: in general if you're checking something coming from an external source, it's an error not a panic
<wallyworld> jam: so i ended up merging to trunk locally and pushing that
<jtv> rogpeppe: does an impossible cast always panic?
<rogpeppe> jtv: no
<jtv> Or does it have that weird optional-second-output thing?
<rogpeppe> jtv: yup
<jam> wallyworld: so you need to merge your change into trunk ,rather than merging trunk into your changes (that is the AppendRevisionsOnly thing).
<wallyworld> jam: yeah, finally figured that out :-)
<rogpeppe> jtv: i'd be happier to see: type Object struct {Data interface{}} and methods on it to retrieve maas-specific things.
<jam> wallyworld: I'm checking the tarmac logs, it seems to think there is a ghost revision in your branch ancestry... thats a bit strange.
<rogpeppe> jtv: possibly with Data as an unexported field.
<wallyworld> yeah
<jtv> rogpeppe: what kind of maas-specific thing do you mean there?  Attributes?  Or would this also wrap numbers, arrays etc?
<rogpeppe> jtv: the methods that are currently available on MAASObject
<jam> wallyworld: it seems to be complaining about: $ bzr log -r revid:ian.booth@canonical.com-20130204235315-18qtwkohjlb8403u
<jam> "history_db_path" not set for BzrBranch7(file:///D:/dev/go/goose/trunk/)
<jam>      60.1.3 Ian Booth   2013-02-05 [merge]
<jam>             Merge trunk
<jam> which doesn't make a lot of sense. maybe something with pushing and then it not completing properly because of ARO ?
<wallyworld> jam: i never had a d:/dev/go/goose/trunk anything
<wallyworld> i don't do windows
<jam> wallyworld: don't worry about the history_db_path part.
<jam> the actual failure is different, I was just logging the rev
<wallyworld> i did pull to my loval copy of trunk and merge that at some point
<jam> wallyworld: it looks like tarmac doesn't do the nice thing and tell you what branch it is trying to merge.
<jam> :(
<wallyworld> i'll have to figure out how to ssh in
<jam> wallyworld: I probably need to add your ssh-keys. juju doesn't default to adding the shared ssh key I set up (I think)
<wallyworld> ok
<jtv> rogpeppe: then you're talking about casting your way around everything.  One thing that's very important to us is that code's intent be explicit, and especially with this being our first Go project, we don't pick up intent as easily from casts as we do from function names.
<jam> wallyworld: I just added the goose-bot pub key, I'll look for yours next
<jam> I thought there was a simple command to import keys from LP, but I don't remember what it is
<wallyworld> ok
<wallyworld> me either
<jam> wallyworld: your key should be added
<wallyworld> ok, will try and ssh
<wallyworld> jam: ssh_exchange_identification: Connection closed by remote host
<wallyworld> when i tried ssh  tarmac@10.55.60.11
<jam> wallyworld: so it looks like tarmac was trying to land your branch for about 10 minutes before it stopped (but it never posted to Launchpad unfortunately)
<rogpeppe> jtv: i really don't see a significant difference between. s, err := o.GetString() and s, ok := o.(string)
<wallyworld> i'm not that familiar with ssh to know inmmediately ehat that error means
<jam> wallyworld: ubuntu@10.55.60.94
<jam> not sure where you got .11
<wallyworld> ok, i think i did a nova list
<jtv> rogpeppe: that's why I said it's _our_ first Go, not yours!
<wallyworld> and picked a server, can't recall now
<jam> wallyworld: right, instance 0 is the juju state server
<jam> instance 1 is the bot
<jam> which is running as "tarmac" but ssh access is via "ubuntu"
<jam> you can sudo su - tarmac if you need to.
<jtv> rogpeppe: We do see a significant difference there.  And that may well change, and we're trying to do everything the Go way here, but we do also need to be comfortable with what we're writing.
<wallyworld> jam: ok, i'm in, thanks
<dimitern> rogpeppe: sorry about missing you comment, here's the fix: https://codereview.appspot.com/7308044
<jam> dimitern: why the intermediate variable?
<dimitern> jam: because I need to deref it
<jam> ah, pointer stuff, sure
<dimitern> jam: btw the usual way worked smoothly :)
<jam> dimitern: yeah,it usually works quite quickly, I'm not sure what the problem was for Ian. It looks like one of his branches on LP wasn't complete. wallyworld did you happen to try to push to lp:goose *before* you pushed up your own branch for review?
<wallyworld> jam: i don't believe so but can't say for 100% sure
<rogpeppe> jtv: i'm aware it's your first Go - i'm just trying to gently suggest ways of doing things that are more "go-like". JSONObject seems to be duplicating the go type system without any particular reason (all the information in the maasify'd object is present in the original interface{} value)
<dimitern> jam: actually I did just that - tried pushing to lp:goose, got bitten and went with what you said in the mail about the bot
<jam> wallyworld: what is weird is that it is claiming it failed to merge goose's trunk, but the revision it is complaining about should have only been in your branch.
<jam> dimitern: you shouldn't have direct commit access to 'lp:goose' to keep us all honest, but I do outline in the email how to get around it.
<wallyworld> hmmm. that is weird
<jam> wallyworld: my guess is it was having trouble with your branch, but giving a bad error message.
<wallyworld> could be. let's see what happens next time i guess
<jam> which *might* have been that your branch tip had a revision, which bzr didn't copy to your branch's local repository, because it was stacked on a repository that already had it.
<jam> (which should work, but tarmac might be trying something special under the covers)
<jam> I know it uses a lightweight checkout for trunk
<jtv> rogpeppe: Yes and I appreciate that, but to us there _is_ a real difference between having the caller cast their way around and hiding that detail from them â including an apparent bug in the json package where you don't know if a number is going to be an int or a float64.
<wallyworld> i use lightweight checkouts also
<jam> and using remote lightweight checkouts has had some edge cases in bzr in the past.
<rogpeppe> jtv: numbers are always float64 when unmarshalled into an interface{}
<jtv> That's what I thought too.
<rogpeppe> jtv: unless you've found a counter-example...
<jtv> Yeah.  :(
<jam> jtv: http://golang.org/pkg/encoding/json/#Unmarshal claims that. Were you unmarshalling into a map?
<rogpeppe> jtv: if so, sounds like a bug. have you got something that demos the problem?
 * jtv looks
<jtv> jam, rogpeppe: wouldn't you know it â can't reproduce that now.  I must have been wrong.
<jtv> Yes, I was unmarshaling into a map.
<jam> jtv: my guess is while discovering it, you were probably trying out "what if it is an int" and got an int back.
<jtv> Nope.
<jtv> Not *consciously*.  But I do wonder if somehow I got an int in there that I didn't first serialize.
<jtv> Could easily have happened.
<jam> dimitern: care to come join us in mumble?
<dimitern> jam: sure
<TheMue> lunchtime
<dimitern> yay! so nova list server/detail filters support regex matching by name!
<dimitern> filtering current env's machines will be a breeze
<jam> wallyworld: I use local lightweight checkouts, but not lightweight checkouts of lp: branches.
<jam> dimitern: nice
<wallyworld> ok
<jam> (and remote lightweight checkouts have had some rough edges)
<wallyworld> i can't get by without
<niemeyer> Goood morning all
<rogpeppe> niemeyer: hiya
<niemeyer> rogpeppe: Yo!
<dimitern> weird.. it tells me I cannot join the weekly hangout
<dimitern> jam: how did you get in?
<jam> dimitern: I just joined
<jam> https://plus.google.com/hangouts/_/calendar/bWFyay5yYW1tLWNocmlzdGVuc2VuQGNhbm9uaWNhbC5jb20.pjo9s0ubrlo7fudfdu3bkivq34
<jam> https://plus.google.com/hangouts/_/33acfc2c8af8792568274fa110371db956f9fde7
<dimitern> You are not allowed to join this hangout.
<dimitern> why?!
<jam> dimitern: are you connecting with an @canonical account?
<jam> just a thoguht
<dimitern> jam: yeah it seemed like that's the issue
<jam> dimitern: I think you can try the last link, and just go directly to the hangout, rather than via the calendar
<dimitern> yeah, I tried them all, switched to @canonical account ...a few times, no cigar
<dimitern> i'm switching the account, but somehow the link switches it back to the other (non canonical) one :(
<dimitern> can somebody invite me or something?
<hazmat> niemeyer, good morning
<rogpeppe> luunch
<hazmat> niemeyer, i'm trying to debug an issue with the charm store, the landscape-client charm isn't showing up on either the alias or most of the personal addresses
<niemeyer> hazmat: Heya
<hazmat> i wrote a small go program and verifies that the charm loads correctly, and one of the personal charm branches (out of 4) does appear in the store
<hazmat> i'm a bit stumped as to causes or how to debug further
<niemeyer> hazmat: Worth asking mthaddon for the logs to see if it's breaking on import
<hazmat> niemeyer, cool, i'll do that, thanks
<niemeyer> hazmat: np
<hazmat> mthaddon, fwereade, niemeyer so the issue is that the landscape-client has a required relation named 'juju-info' which per previous discussion i believe is resolved on trunk. is there a procedure in place re updating the charm store code. (charm store log - https://pastebin.canonical.com/83865/)
<niemeyer> hazmat: We just have to ask Tom to bump it
<mthaddon> hazmat: we have deployment instructions (anyone from webops, not just me)
<hazmat> mthaddon, cool, should i have someone put in an RT put in for this?
<fwereade> hazmat, AIUI we agreed that that that name would only be accepted for container-scoped require relations
<mthaddon> hazmat: that'd be great, thanks
<fwereade> hazmat, without that restriction relation specifiers become potentially ambiguous
<hazmat> fwereade, in this case it is container scoped (its a sub)
<hazmat> fwereade, yup
<fwereade> hazmat, hmm, so it is, I do apologise
<hazmat> fwereade, no worries, nothing wrong with being precise
<niemeyer> hazmat: Even then
<niemeyer> hazmat: We want to obsolete that eventually
<niemeyer> hazmat: So I recommend fixing the charm
<niemeyer> hazmat: Even more considering that charm is ourrs
<niemeyer> ours
<niemeyer> fwereade: ^
<fwereade> niemeyer, hazmat, I am +1 on this
<fwereade> niemeyer, hazmat: there's a bug in juju-core to deprecate and complain about use of that exception
<hazmat> niemeyer, understood, and i can file a bug against the ls charm, but there are a large number of subordinates that do this in the wild, its not clear if they all have maintainers. i had thought we had resolved the ambiguity in a tight way. the problem with deprecations is that it hits the users not the authors.
<niemeyer> hazmat: How's that in disagreement with what I just said?
<niemeyer> hazmat: You are not "in the wild".. you are a juju developer.. I recommend fixing the charm. That's all.
<hazmat> niemeyer, its not clear what the timeline is for eventually, realistically it may be never. there are roughly 50 charms extant that have this behavior (http://jujucharms.com/search?search_text=juju-info). afaik no juju devs do charm maintenance/reviews. for this particular charm as i already said yes we can do it, but we don't have access to update personal charms everywhere.. the rest of my comment was directed to fwereade's suggestion of deprecations/com
<hazmat> plaints
<niemeyer> hazmat: I think we covered that topic pretty well in the ML thread.
<fwereade> hazmat, it is true that if they're never going to be fixed then adding the warnings will have no net effect other than to increase the quantity of spam in the world, but I'm not quite ready to give up on the dream
<niemeyer> hazmat: If you don't want to fix the charm, nobody will force you to right now. Be happy.
<rogpeppe> mramm: i can't join the usual kanban hangout
<rogpeppe> dimitern: how did you fix your hangout issue?
<mramm> rogpeppe: I think you need to use a canonical G+ account
<mramm> no idea how to fix that though
<mramm> let me poke around...
<TheMue> same problem here
<rogpeppe> mramm: i am.
<dimitern> rogpeppe: logged out of the other account and left the canonical one only
<dimitern> sign out of all accounts and log in to the canonical first (then the others, if needed) - your default account is the one you first logged in
<dimitern> http://webapps.stackexchange.com/questions/6862/how-do-i-change-my-default-account-with-google-multiple-sign-in
<dimitern> I'd appreciate 2 quick related reviews: https://codereview.appspot.com/7299047/ (juju-core) and https://codereview.appspot.com/7309045/ (goose)
<hazmat> niemeyer, i'm not sure why you feel the need to make a technical discussion  personal, but i'll take the advice.
<niemeyer> hazmat: Because there wasn't any technical discussion.. we've already talked about that. I've made a trivial suggestion.. if you don't want to follow, just ignore me.
<dimitern> fwereade: ping
<fwereade> dimitern, in a call, expect slow responses
<dimitern> fwereade: sure, when done if you have some time, can you take a look at these 2 CLs? ^^
<hazmat> niemeyer, afiacs the discussion had evolved past the suggestion of fix the charm into discussion of the merits of deprecation, which you tried to shut down by making it personal. anyways.. bug filed against ls charm.
<niemeyer> hazmat: That's your reading. My reading is that we already covered that topic in the mailing list thread. I'm not willing to explain everything again here.
<niemeyer> hazmat: and you're pulling it into a personal argument for no good reason.
<niemeyer> hazmat: In fact, you do that pretty often. Please stop. Thank you.
<hazmat> niemeyer, i'll raise my comments on the thread then, and yes i'm calling you out for what your doing because its not appropriate.
<niemeyer> hazmat: What you are doing is what is not appropriate. Yes, considering the points previously made in a conversation is a terrific plan.
<niemeyer> hazmat: No, bugging people to say what you want is not okay.
<niemeyer> hazmat: You don't have to follow my suggestions, but you can't force me to cover the subjects of your will whenever you please, and then call that a personal argument when I say no.
<hazmat> niemeyer, i'm fine with that, but there are much better ways to say no
<niemeyer> hazmat: The thread has a good assessment of the situation as I've pointed out repeatedly. Basic home work.
<niemeyer> hazmat: It's easy to say what other people should do. It's harder to do what is appropriate.
<niemeyer> rogpeppe: ping
<rogpeppe> niemeyer: in a meeting. be with you in a bit
<niemeyer> rogpeppe: Thanks
<rogpeppe> niemeyer: meeting finished, but i've got another one now...
<niemeyer> ... obtained string = "goamz-us-east-1-AKIAJK3W/multi1"
<niemeyer> ... expected string = "multi1"
<niemeyer> Something is seriously busted in S3.. :(
<dimitern> jam: we can spin 3 machines in canonistack to test regexp filtering, but the test will be awfully slow
<rogpeppe> niemeyer: pong
<fwereade> rogpeppe, TheMue: can we call it a day please? that's been 2.5h solid of talking for me and rogpeppe...
<rogpeppe> fwereade: +1
<rogpeppe> fwereade: tomorrow morning?
<fwereade> rogpeppe, TheMue: +1
<TheMue> fwereade: +1
<jam> dimitern: it is the sort of thing where I'm reasonably ok with passing multiple regex's against 1 server name
<TheMue> rogpeppe, fwereade, mramm2: I appreciated the talk.
<jam> but we have done a manual test across multiple names
<dimitern> jam: actually, it won't take that much time on second though - I'm already half through a test spinning up 3 machines (and not waiting for them - no need to do anything to them)
<dimitern> jam: but i'll continue tomorrow and call it a day now
<jam> dimitern: k
<niemeyer> rogpeppe: Yo
<niemeyer> rogpeppe: Sorry, was on a call with Robbie
<rogpeppe> niemeyer: hiya
<niemeyer> rogpeppe: I just wanted to ping you about the comment, but I think I already sorted out
<niemeyer> rogpeppe: "overview of" is fine, right?
<rogpeppe> niemeyer: yeah
<rogpeppe> niemeyer: depending on the context of course :-)
<niemeyer> rogpeppe: The intent of mentioning that it was an overview of multipart uploads is that saying "See an overview at foo." would pass a wrong impression that this was about Multi.
<niemeyer> rogpeppe: Yeah
<rogpeppe> niemeyer: ah yes.
<niemeyer> rogpeppe: Supe
<niemeyer> r
<rogpeppe> i've gotta go.
<rogpeppe> g'night all
<niemeyer> rogpeppe: Night
#juju-dev 2013-02-06
<rogpeppe> davecheney: ping
<mramm> rogpeppe: hey, you still around?
<rogpeppe> no
<rogpeppe> mramm: not really. it's late and i'm summoned.
<mramm> ahh
<mramm> ok
<mramm> have a great evening
<TheMue> Morning.
<fwereade_> heya TheMue
<TheMue> fwereade_: Hi William
<TheMue> fwereade_: You know http://hackingdistributed.com/2013/01/29/mongo-ft/?
<fwereade_> TheMue, haven't read that one tbh
<TheMue> fwereade_: It's about MongoDB replication and how this can lead to problems.
<fwereade_> TheMue, it does not look unfamiliar though
<fwereade_> TheMue, most of it seems to be the usual whining about default settings
<fwereade_> TheMue, maybe I should read more closely?
<TheMue> fwereade_: I'm also not through with it. It only attracted my attention due to mongo.
<fwereade_> TheMue, it kinda seems that there's a bit of a backlash against mongo going on at the moment, which is fine, it's the usual cycle of new tech
<fwereade_> TheMue, 1) it's the greatest thing ever and it solves all your problems! nosql!!!!!11!1!
<fwereade_> TheMue, 2) it's the worst thing ever and will destroy your life!!!!11!1!
<fwereade_> TheMue, 3) it's a tool and choosing to use it involves tradeoffs
<TheMue> fwereade_: Well known as Gardner hype cycle ;)
<fwereade_> TheMue, yeah, indeed -- I just think we're in phase 2 re mongo at the moment
<fwereade_> TheMue, this is not to say that there will not be challenges wrtreplication
<TheMue> fwereade_: I'm only interested in well known traps we can avoid in our further mongo usage.
<fwereade_> TheMue, yeah, it will be interesting trying to tune it as our needs grow
<TheMue> fwereade_: If others detected probs and discovered ways to avoid them why not use their knowledge. ;) One way of re-use.
<fwereade_> TheMue, at the moment I mostly have the worst-case characteristics of mgo/txn on my mind :)
<TheMue> fwereade_: Sure, wrt to scaling and HA it will get interesting.
<TheMue> fwereade_: Yeah, you yesterday mentioned it.
<TheMue> fwereade_: Would like to see a little paper with your current thoughts of possible probs, so that we can investigate in parallel and put our discoveries, thoughts etc into that paper.
<fwereade_> TheMue, wrt that particular article I look forward to his followup where he talks about subtle problems with replication
<TheMue> fwereade_: Yeo
<TheMue> Yep
<fwereade_> TheMue, my own concerns remain somewhat theoretical
<TheMue> fwereade_: But still interesting as they exist.
<TheMue> fwereade_: I would like to see my technical lead w/o concerns. :D
<fwereade_> TheMue, it's basically concern over precisley how txn sync points can propagate across the collections
<fwereade_> TheMue, I think the really interesting problem is service destruction
<fwereade_> TheMue, the way it's written now has some good properties and some bad ones and I don't know which will predominate in real usage scenarios
<TheMue> fwereade_: So maybe we should start use case oriented. First UC: service destruction, below a short description on how on high level it works and then drilling down into how the DB is involved and which probs you might expect.
<fwereade_> TheMue, that is not an unreasonable request
<TheMue> fwereade_: If the result shows that there's no problem that's the best we can get. ;)
<fwereade_> TheMue, well, just because I can't think of a problem doesn't mean it won't exist ;p
<fwereade_> TheMue, the trouble with documenting things is that the cost/benefit calulation is really simple
<fwereade_> TheMue, s/really/rarely/
<fwereade_> TheMue, writing good docs is expensive re time; the docs quickly become out of date anyway; and there is also a strong tendency for developer docs to be write-only for some reason
<fwereade_> TheMue, I am firmly +1 on writing design specs
<rogpeppe> fwereade_, TheMue: do you want to continue that meeting?
<rogpeppe> (morning, BTW!)
<TheMue> rogpeppe: Morning
<fwereade_> rogpeppe, TheMue: yeah, we probably should, would one of you start a hangout? I'll be there in 5
<TheMue> rogpeppe: Yep
<rogpeppe> ok
<TheMue> fwereade_: You read my mail about docs this morning?
<rogpeppe> https://plus.google.com/hangouts/_/ba4d2795ce2498036f225614a2b0a488040d635f?authuser=0&hl=en-GB
<fwereade_> TheMue, yeah, the things I was just saying are closely connected
<fwereade_> TheMue, we could maybe touch on it live as well
<fwereade_> rogpeppe, TheMue, omw back
<dimitern> https://plus.google.com/hangouts/_/8fe5a151e983bdd6459913720de0cc4817216bc5
 * niemeyer joins
<niemeyer> dimitern: I assume this is the constraint discussion?
<dimitern> niemeyer: yes it is
<fwereade_> niemeyer, dimitern: I hope so
<niemeyer> Mornings, btw! :-)
<niemeyer> fwereade_, dimitern: Can you please invite the other me
 * fwereade_ seems to be the only one in there
<dimitern> niemeyer: morning
<dimitern> so that's not the one
<dimitern> jam's creating a new one and will post a link
<jam> https://plus.google.com/hangouts/_/1b96582d8713f383ef4b1477073f236fa504e77d?authuser=2&hl=en
<niemeyer> jam: Can you please invite the other me?
<TheMue> jam: Same here
<jam> If I missed anyone, please just poke me, if the above link doesn't work automatically
<rogpeppe> darn, i missed all the above reminders
<rogpeppe> fwereade_: can you point me to the original constraints discussion document (where the constraint semantics were laid out)
<rogpeppe> ?
<rogpeppe> fwereade_: i'm relying on possibly dubious memory of what was arrived at
<fwereade_> rogpeppe, I think it's in the juju-doc project somewhere, let me poke around a bit
<rogpeppe> fwereade_: ah! this one: https://juju.ubuntu.com/docs/constraints.html
<fwereade_> rogpeppe, that's not the spec I remember, it's the polished-up-for-users docs
<fwereade_> rogpeppe, but maybe that's what it evolved into
<rogpeppe> fwereade_: yeah, i remember a different document too
<rogpeppe> fwereade_: but that's good for going on with - it documents the user expectations which is probably the most important thing
<fwereade_> rogpeppe, actually, I think it is roughly the same
<fwereade_> rogpeppe, if you do a deep dive in deleted bits of the juju source itself you'll find earlier versions
<rogpeppe> fwereade_: ok, cool
<rogpeppe> fwereade_: are there any constraints that, when added, *increase* the number of machines available for allocation, rather than narrowing down the selection?
<fwereade_> rogpeppe, hmm, not according to my mental model -- wrt machines you just filter out the ones that don;t match
<rogpeppe> fwereade_: that is, given a set of constraints C, and another set D, can i assume that availMachines(C) is a non-strict superset of availMachines(C+D) ?
<rogpeppe> fwereade_: the example that brought this to mind was ec2-zone=any
<fwereade_> rogpeppe, I think the answer is in general no, but keep talking
<fwereade_> rogpeppe, but I'm not actually sure exactly what you're referring to when yu say "machines"
<rogpeppe> fwereade_: s/machines/instances/
<rogpeppe> fwereade_: 'cos if you have C=(ec2-zone=us-east-1a) and D=(ec2-zone=any) then it seems that the above supposition is violated
<fwereade_> rogpeppe, what does "+" mean then?
<rogpeppe> fwereade_: combined, as with environment-level and service-level constraints
<fwereade_> rogpeppe, ah, ok -- then I think the answer is "mu"
<fwereade_> rogpeppe, combining two sets of constraints can make them tighter than the original or looser than the original, and makes no difference wrt instances which always just match a single bunch of constraints
<rogpeppe> fwereade_: yeah, that's true. but is that true even if you're combining constraints with no overlapping attributes?
<fwereade_> rogpeppe, so forget about combining sets then
<fwereade_> rogpeppe, or maybe not -- I'm sorry, I think I need a bit more context on what you're thinking about before I can answer with confidence
<rogpeppe> fwereade_: more time required to think :-)
<fwereade_> rogpeppe, in general, I think that if a given constraint is not set it will not particpate in matches
<fwereade_> rogpeppe, and that the effect of every constraint check is to exclude some images/instances/instance-types from consideration
<fwereade_> rogpeppe, so adding a new check can only further narrow down the list and cannot grow it
<fwereade_> rogpeppe, but that it is not sane to filter first by env constraints and then by service constraints, because that will exclude machines that should not be if the service specifies things that overlap or conflict with the env
<rogpeppe> fwereade_: i was wondering if there's a machine that has been started with constraint 'a=1 b=2', then we can be sure that the machine so allocated will also match a desired constraint 'a=1'
<rogpeppe> fwereade_: yes, i agree with that
<fwereade_> rogpeppe, if it does not, then we should probably have words with whoever did the provider that reported that instance info
<rogpeppe> fwereade_: yeah
<rogpeppe> fwereade_: it could happen if the default value for a constraint was restrictive
<rogpeppe> fwereade_: but i think that would be wrong.
<fwereade_> rogpeppe, I'm +-0 on the idea of defaults anyway, I don't want to introduce them unless I'm sure about them
<rogpeppe> fwereade_: +1
<fwereade_> rogpeppe, it may make more sense to charge the environ with doing sane things in response to empty constraints
<fwereade_> rogpeppe, figuring out a sane thing for all openstacks is not easy, but it's easier than doing so across all possible providers
<rogpeppe> fwereade_: can you specify constraints on a subordinate service?
<fwereade_> rogpeppe, I'm inclined to say no for now
<TheMue> fwereade_, rogpeppe: When talking about constraints with numbers, are they meant as an exact value, as an upper limit or as a lower limit?
<fwereade_> TheMue, in every case so far, lower limit
<fwereade_> TheMue, if we had a "cost" that would make sense as an upper limit
<TheMue> fwereade_: So what if I want to limit it to a maximum, e.g. for cost control reasons?
<TheMue> fwereade_: Yep.
<fwereade_> TheMue, nobody's actually expressed a desire for that
<fwereade_> TheMue, if they do we can figure something out -- say, "mem<=2G"
<TheMue> fwereade_: What we're defining is a kind of DSL for constraints. "cpu > 4000 MIPS && ram > 2 GB || cpu < 4000 MIPS && ram > 4 GB".
<fwereade_> TheMue, I think I am trying hard not to do that
<fwereade_> ;)
<TheMue> fwereade_: Hehe, can understand.
<TheMue> fwereade_: But the discussion in some points reminds me of it.
<fwereade_> TheMue, although what you said is also perfectly correct -- that is what we are doing, we just don't want it to look like that
<fwereade_> TheMue, yet ;p
<TheMue> fwereade_: From a user perspective, what are the demands? More than just say "tiny, small, medium, large, xxl"?
<fwereade_> TheMue, I think that those words are meaningless in a global context
<TheMue> fwereade_: Together with a map what they mean for a given provider?
<fwereade_> TheMue, I think it will be rare for an environment to have instance types that map remotely neatly onto those things
<TheMue> fwereade_: They don't have to map between providers IMHO. So tiny in EC2 isn't tiny in an OpenStack environment. But tiny is defined per environment. And the op can so choose the best matching one instead of fiddling with details.
<fwereade_> TheMue, if they don't map to something roughly equivalent across providers they're worthless
<TheMue> fwereade_: Only some constraints may be hard due to software dependencies, like arch or gpu.
<fwereade_> TheMue, yeah, arch is an interesting one, we didn't hit that one in the call
<TheMue> fwereade_: Why do you think they are worthless?
<fwereade_> TheMue, because their purpose is to enable sane cross-environment scripting
<fwereade_> TheMue, if you can't say "this should run on at least a medium" and have that mean something coherent regardless of provider, it's no help at all
<TheMue> fwereade_: Ah, forgot the charm perspective. :/
<rogpeppe> fwereade_: RFC http://paste.ubuntu.com/1616827/
<fwereade_> rogpeppe, looking
<fwereade_> rogpeppe, can't match against instance constraints
<fwereade_> rogpeppe, well we could, but it would be crap
<fwereade_> rogpeppe, we need to match against the properties of the actual instance
<rogpeppe> fwereade_: i agree with that - see the 3rd last para
<rogpeppe> fwereade_: in fact, yes, we can't do any matching *until* that's occurred, yeah
<fwereade_> rogpeppe, I guess I'm not seeing how this actually solves a problem though
<rogpeppe> fwereade_: it seems like a reasonably simple scheme that means we can have provider-specific constraints in a coherent way
<fwereade_> rogpeppe, how does it address the problem of specifying "instance-type=m1.small" against an openstack environment?
<fwereade_> rogpeppe, it doesn't address the social problem
<fwereade_> rogpeppe, people will script them anyway
<fwereade_> rogpeppe, if the social problem is not a problem, we don't need to separate them at the UI level
<fwereade_> rogpeppe, and if it is, we still don't because it won;t help -- it's just layered complexity to no benefit
<rogpeppe> fwereade_: in that case, you'd either get an error when you tried to specify that constrain (the juju command can check), or the constraint would fail
<fwereade_> rogpeppe, right, just as they would if the division didn't exist
<rogpeppe> fwereade_: break for kanban?
<rogpeppe> fwereade_: one advantage of the divide is that lots of the awkward logic (e.g. combining constraints) can be implemented in the state, and each provider only has to deal with it in one specific place (Environ.Constraints)
<rogpeppe> fwereade_: also, from a user-facing point of view, the rules are more straightforward, i think - they don't have to worry about overlapping constraints
<rogpeppe> fwereade_: also, it's easy to tell if someone is using provider-specific constraints, because they're tagged as such.
<fwereade_> rogpeppe, a question: is "arch" provider-specific?
<rogpeppe> fwereade_: we would provide arch in the portable constraints
<fwereade_> rogpeppe, so you can't start an instance with a specific arch?
<rogpeppe> fwereade_: sure you can
<fwereade_> rogpeppe, s/instance/instance type/
<fwereade_> rogpeppe, how so? I thought you can't specify both
<rogpeppe> fwereade_: the provider constraints could provide arch too, if it was appropriate
<rogpeppe> fwereade_: the idea is that the provider-specific constraints embody exactly the constraint capabilities of that provider
<fwereade_> rogpeppe, having two ways of specifying arch does not seem to be a win simplicity-wise
<rogpeppe> fwereade_: i think it's reasonable actually.
<rogpeppe> fwereade_: the portable constraints and the provider-specific constraints live in different semantic spaces
<rogpeppe> fwereade_: one provider might provide a more detailed level of "arch"
<rogpeppe> fwereade_: whereas portable constraints might only understand amd64, i386, arm
<fwereade_> rogpeppe, then their portability is at best suspect
<rogpeppe> fwereade_: in some providers, arch might not be orthogonal to instance type.
<fwereade_> rogpeppe, in some, it's already not
<rogpeppe> fwereade_: quite so
<rogpeppe> fwereade_: so we only have another way to specify "arch" if it's a concept that makes direct sense to a provider.
<fwereade_> rogpeppe, if the provider's expected to understand the portable arch as well, which surely it must, then it is always a concept that makes direct sense to the provider
<rogpeppe> fwereade_: i think that almost all our difficulties when thinking about constraints come from trying to combine provider-specific and portable constraints.
<rogpeppe> fwereade_: the only parts of the provider that understands the portable arch would be the Environ.Constraints method (mapping from portable to provider-specific) and Instance.Constraints (mapping the other way); this localises the necessary knowledge.
<rogpeppe> fwereade_: and at no point does the provider have to decide how its constraints work *alongside* portable constraints
<rogpeppe> fwereade_: it can choose a semantic model that fits the domain it has to work with
<rogpeppe> fwereade_: i *think* this will produce a system where the results are more predictable and the model to the user is clearer, but i may well be wrong!
<fwereade_> rogpeppe, I still feel like we haven't had an answer to the question of what happens when you specify nonsensical provider constraints
<rogpeppe> fwereade_: well, in the first instance, we can have the juju command call Constraints on the local environ to make sure it understands them
<fwereade_> rogpeppe, so we error out when incompatible constraints are specified?
<fwereade_> rogpeppe, just like would would anyway?
<fwereade_> rogpeppe, is this not the problem we are trying to resolve>
<rogpeppe> fwereade_: using portable constraints, there are no incompatible constraints, right?
<fwereade_> rogpeppe, yes, if that's all you're using
<rogpeppe> fwereade_: so we could make the environ give an error for incompatible provider-specific constraints (so that the user knows in advance that no machine will ever satisfy the constraint), but i don't *think* that's the essence of the problem we're trying to resolve
<fwereade_> rogpeppe, or we could just treat it as no-constraint-at-all, and then we'd do something useful to the best of our ability
<rogpeppe> fwereade_: i'd prefer not to do that. if we have a constraint, i think it should be binding.
<rogpeppe> fwereade_: but i think we should make it obvious in the status when a constraint cannot be satisfied.
<fwereade_> rogpeppe, +0, +1
<fwereade_> rogpeppe, it depends chiefly on how you phrase it
<fwereade_> rogpeppe, what's your position on the prefer-near/prefer-far concept?
<rogpeppe> fwereade_: remind me of that concept, please
<rogpeppe> fwereade_: are you talking about placement?
<fwereade_> rogpeppe, it's a rough suggestion I made in response to the os-scheduler-hints business
<fwereade_> rogpeppe, no more than we have been already (in that constraints is about "placement" of machines on instances)
<rogpeppe> fwereade_: ah, i'm not sure i saw it.
<fwereade_> rogpeppe, I think we had a discussion about the thread
<fwereade_> rogpeppe, maybe it was in a followup
<rogpeppe> fwereade_: constraints, to me, is about constraining the capabilities of a given machine, irrespective of any other entities in the system.
<fwereade_> rogpeppe, tldr: it was confirmed that the use case that prompted os-scheduler-hints was "I want my instances to be exposed to different risks"
<rogpeppe> fwereade_: placement, to me, is about constraining *where* a machine goes relative to some other machine
<fwereade_> rogpeppe, so what is your plan for expressing this use case?
<rogpeppe> fwereade_: i think i wouldn't try to abuse the constraint syntax to do it
<rogpeppe> fwereade_: currently the constraint language is entirely separate from the juju state namespace. with prefer-near etc, i don't think we'd want it to be.
<rogpeppe> fwereade_: because you'd want to talk about these things in terms of juju concepts like units or services.
<fwereade_> rogpeppe, yes, exactly
<fwereade_> rogpeppe, of course we want to be able to express this use case in a clear and succinct way
<rogpeppe> fwereade_: so i'd suggest that we don't try to shoehorn it into constraints, but design a specific feature to do it
<fwereade_> rogpeppe, it is your personal definition of constraints that makes the shoehorn necessary
<fwereade_> rogpeppe, constraints are the feature by which we expose the differing capabilities of the places where services' code is actually run
<rogpeppe> fwereade_: we have nice simple rules for constraints: "this machine satisfies that constraint"; "this machine does not". with prefer-near etc, we're breaking that model.
<fwereade_> rogpeppe, so if people want to specify placement, we should expose a separate provider-specific vocabulary in order to do so?
<rogpeppe> fwereade_: nope. i think we should have some portable syntax, e.g. deploy --near other-service
<fwereade_> rogpeppe, and new verbs for changing affinity and suchlike?
<rogpeppe> fwereade_: that kind of thing, yes
<fwereade_> rogpeppe, so, from a user point of view, how is that different to a constraint other than in tedious difference in specification?
<rogpeppe> fwereade_: it's a preference rather than a constraint
<rogpeppe> fwereade_: and... does it make sense to have these attributes at an environment level?
<fwereade_> rogpeppe, probably not settable at, no
<fwereade_> rogpeppe, unsettable constraints are nothing new though
<fwereade_> rogpeppe, specifically, series
<fwereade_> rogpeppe, (apart from anything else, that is not a hardware constraint ;p)
<rogpeppe> fwereade_: how is series unsettable?
<fwereade_> rogpeppe, how would you go about setting it?
<fwereade_> rogpeppe, it is determined by the charm, full stop
<rogpeppe> fwereade_: ah, so it wouldn't be a constraint attribute at all, right?
<rogpeppe> fwereade_: hmm, except when resolved in an actual instance.
<fwereade_> rogpeppe, ok, it's a separate thing that requires matching etc but is not a constraint
<fwereade_> rogpeppe, so far you have proposed two kinds of constraint that can share names, and two new mechanisms that look and smell very much like constraints to the average user
<fwereade_> rogpeppe, I do not think this is moving towards simplicity
<rogpeppe> fwereade_: i think it is actually simpler, because responsibilities are clearly delineated
<rogpeppe> fwereade_: and we don't need to try to understand what it means to combine m1.small with mem=32G
<fwereade_> rogpeppe, the user's goal AIUI is to specify things that are important to them about how their service is deployed, and to have those things happen
<rogpeppe> fwereade_: yup
<fwereade_> rogpeppe, I do not believe that in the average user's mind there is a pre-existing crisp partition of these concepts
<rogpeppe> fwereade_: the average user will never need to use provider-constraint
<rogpeppe> fwereade_: it's a gateway for the more provider-savvy user
<fwereade_> rogpeppe, but what people actually do, AIUI, is to specify instance-type=m1.small and forget about cpu/mem
<rogpeppe> fwereade_: i worry that if we include provider-specific constraints in the normal constraints, that people won't see the difference and will use non-portable constraints as a matter of course.
<fwereade_> rogpeppe, I don't think your suggestion does anything to solve that problem
<rogpeppe> fwereade_: if they do that, i think they should be made aware that they're doing something non-portable
<rogpeppe> fwereade_: i dunno. it's just a straw man. i'd like to see a counter proposal.
<fwereade_> rogpeppe, ok, opposing strawman: constraints that may have provider-specific meaning are prefixed "hint-", and are not guaranteed to work on all providers; invalid values for a particular provider are just ignored
<fwereade_> rogpeppe, hint-instance-type=m1.medium
<rogpeppe> fwereade_: "hint" seems wrong there - it's a genuine constraint if we're running on ec2, not just a hint.
<fwereade_> rogpeppe, ok, hint-instance-type=m1.mdeium ;p
<rogpeppe> fwereade_: ?
<rogpeppe> fwereade_: ec2-instance-type=m1.medium ?
<rogpeppe> fwereade_: and in general, <environ-type>-attr=val ?
<fwereade_> rogpeppe, ec2 is special
<fwereade_> rogpeppe, openstack-instance-type is no better off
<rogpeppe> fwereade_: i don't understand, sorry
<fwereade_> rogpeppe, the hintiness is in that if you ask ec2 for crack, it ignores you
<rogpeppe> fwereade_: hmm. i don't think that's right. i think that if you ask ec2 for crack, and it knows it, it should tell you asap
<fwereade_> rogpeppe, "hint-instance-type=m1.more-obvious-typo" will cause the provider to pick one and run with it
<rogpeppe> fwereade_: but if i really have mistyped m1.medium, i don't want that to happen
<fwereade_> rogpeppe, ok, then the same applies for openstack, right?
<rogpeppe> fwereade_: yup
<fwereade_> rogpeppe, so openstack-instance-type is non-portable across openstacks
<rogpeppe> fwereade_: you can't always resolve all attributes in the client.
<fwereade_> rogpeppe, and does not fulfil the goal of gracefully ignoring irrelevant constraints -- it doesn't have the context to know that such a constraint is irrelevant rather than malformed
<rogpeppe> fwereade_: and in the general case, the client can't resolve *anything*, because it doesn't have access to an Environ
 * TheMue thinks about constraints for the local provider or colocation ...
<rogpeppe> fwereade_: if we had some way of telling provider-specific constraints, that would be possible
<rogpeppe> fwereade_: e.g. a prefix that indicates a provider-specific constraint
<fwereade_> rogpeppe, they're really environ-specific, though, right?
<rogpeppe> fwereade_: no, i don't think they are.
<fwereade_> rogpeppe, even in ec2 -- environs in different regions have different instance types available
<rogpeppe> fwereade_: i think that a given provider should always provide the same set of attributes.
<rogpeppe> fwereade_: the set of possible *values* is another matter
 * fwereade_ approves of TheMue's thoughts, and observes that we must also be able to have a provider that coherently exposes no constraints at all, and still works without crazy special-casing everywhere
<fwereade_> rogpeppe, yeah, the set of possible values is the question ;)
<fwereade_> rogpeppe, hum
<fwereade_> rogpeppe, a thought
<fwereade_> rogpeppe, *any* constraint could probably be usefully prefixed with a "hint-" prefix
<rogpeppe> fwereade_: to impose some preference ordering on available instances?
<fwereade_> rogpeppe, or ignore it if it's hard to do in some specific case
<fwereade_> ;p
<rogpeppe> fwereade_: i think it's awkward. if two different instances satisfy different "hint-" constraints, which one do you choose? it seems... arbitrary.
<rogpeppe> fwereade_: and i don't really see the use case
<rogpeppe> fwereade_: when would you want to use hints?
<fwereade_> rogpeppe, please state for me the problem you think we are trying to solve
<rogpeppe> fwereade_: i have a service i want to run and each unit has certain requirements, then i want units of that service to run on sufficiently capable machines.
<rogpeppe> fwereade_: meeting break - got a 1-1
<rogpeppe> fwereade_: back
<fwereade_> rogpeppe, heyhey
<fwereade_> rogpeppe, I think that it is unhelpful to restrict the scope of to "sufficiently capable machines" -- you're actually trying to specify the properties of your service
<rogpeppe> fwereade_: you're trying to specify *sufficient* properties, no? otherwise it wouldn't be constraint, it would be specification
<fwereade_> rogpeppe, "always running with 4G of RAM" is one property, "distributed as widely as possible" is another
<rogpeppe> fwereade_: that's an interesting take on it. that's not how i was thinking about constraints (i was thinking in terms of constraining potential machines)
<fwereade_> rogpeppe, I'm not sure I see a significant distinction between specifying that a solution must have X properties and constraining matters such that things without X properties are excluded
<fwereade_> rogpeppe, it is all still in service of manipulating precisely how the units of a service are deployed, because that is the clay we have to work with
<rogpeppe> fwereade_: "distributed as widely as possible" isn't a property that's possible to check for on a machine in isolation
<fwereade_> rogpeppe, yeah, that is why I suggested *prefer*-near/far -- it is because I think it is a concept that maps clearly to a valuable feature, that different providers can and will interpret differently
<rogpeppe> fwereade_: it seems to me that that's a fundamentally different kind of constraint
<dimitern> is there in go a fast way to check if a key is within a map, without for range loop?
<fwereade_> rogpeppe, soft vs hard?
<fwereade_> dimitern, _, ok := m[k]
<rogpeppe> dimitern: if x, ok := m[key]; ok { ... }
<rogpeppe> fwereade_: i don't really know what a "soft" constraint means.
<dimitern> of course! :) I must need a brake already :)
<rogpeppe> fwereade_: does it mean some kind of preference-ordering?
<fwereade_> rogpeppe, The aim of constraint optimization is to find a solution to the problem whose cost, evaluated as the sum of the cost functions, is maximized or minimized. The regular constraints are called hard constraints, while the cost functions are called soft constraints.
<rogpeppe> fwereade_: so each provider implements its own constraint optimiser?
<fwereade_> rogpeppe, well, no... just a cost function, surely?
<dimitern> and given x, ok := m[k]; will changing x change m[k], assuming m is map[string][]T ? i.e. x = append(x, y) <=> m[k] = append(m[k], y) ?
<rogpeppe> dimitern: no
<rogpeppe> dimitern: same as slice range or function calls, the variable is a copy of the original
<dimitern> rogpeppe: ok, tyvm
<fwereade_> rogpeppe, not even that, actually
<fwereade_> rogpeppe, Distance(inst1, inst2 Instance) float
<rogpeppe> fwereade_: so the provider has to do an n^2 algorithm through all instances to find a result?
<rogpeppe> fwereade_: istm that if we leave out soft constraints, we have a very simple system that's sufficient for a great many needs (and certainly for 13.04)
<fwereade_> rogpeppe, when would we want to do that?
<rogpeppe> fwereade_: when optimising, no?
<fwereade_> rogpeppe, m*n where each of m and n will already be constrained, I think
<fwereade_> rogpeppe, I probably wouldn't recommend using them at serious scale
<fwereade_> rogpeppe, but I think it solves a problem that people are already having at a small scale
<fwereade_> rogpeppe, and it expresses it in a useful language
<rogpeppe> fwereade_: could you put together some text that describes the same scenarios that my straw-man above did, (i.e. the flow of information from deploy specification to actual provider deployment)?
<rogpeppe> fwereade_: i have a very concrete idea of how my idea would work, but am quite unclear about how your thoughts might pan out
<fwereade_> rogpeppe, sorry, for what scenario? this one right now?
<fwereade_> rogpeppe, of the flow of the whole thing?
<fwereade_> s/of the/or the/
<rogpeppe> fwereade_: the same kind of structure that i had in the above paste
<rogpeppe> fwereade_: except that it should probably mention how prefer-near etc would work too
<rogpeppe> fwereade_: i might post my straw man to juju-dev for all to knock down
<fwereade_> rogpeppe, ok -- I have to stop now, but I will try to write something :)
<rogpeppe> fwereade_: thanks
<rogpeppe1> davecheney: yo!
<rogpeppe1> davecheney: ping
<davecheney> hey
<davecheney> ack
<davecheney> two secs
<davecheney> rogpeppe1: sorry, have to go afk for a bit (family stuff)
<rogpeppe1> davecheney: ok. any chance you'll be around for a chat in the next hour?
#juju-dev 2013-02-07
<rogpeppe1> davecheney: ping
<davecheney> hey
<davecheney> sorry, is it too late ?
<rogpeppe1> davecheney: no, it's good
<jam> hi rogpeppe2
<jam> wallyworld: poke
<wallyworld> jam: hi
<jam> wallyworld: looks like you accidentally broke a test when your generate-config patch landed
<wallyworld> oh :-(
<jam> cmd/juju/main_test.go
<jam> tests what commands are listed by 'juju help'
<jam> and you added one.
<wallyworld> ah bugger. ok, i'll fix it
<jam> Pretty easy to fix, but you'll want to make sure you run "go test ./..." when landing to juju-core. (No bot to help us there)
<wallyworld> i tried to but it hung
<wallyworld> so i ran stuff by hand
<jam> wallyworld: because of the mongo stuff?
<wallyworld> yeah
<jam> wallyworld: https://code.launchpad.net/~jameinel/juju-core/main-test/+merge/147023
<jam> (I still can't get lbox to work without giving unsupported protocol)
<jam> wallyworld: do you have bigjools's ppa ?
<wallyworld> no
<jam> (I personally just put the mongo files into $GOPATH/bin, but the ppa is a good idea too)
<jam> technically, it doesn't hang forever, it just takes 5min to timeout and FAIL :)
<wallyworld> ok, i'll have to get all that working i think
<jam> but that is for each test package that uses mongo, which is about 5-6, so it takes a pretty long time to run the whole suite.
<jam> wallyworld: anyway, it is clear that dimitern didn't run the full test suite after merging either, since he landed code after you did. But it is something we need to remember as long as we are manual gatekeepers.
<wallyworld> yeah
<jam> (lbox submit *doesn't* run the test suite as near as I can see, which might be a reasonable way around it?)
<wallyworld> if they didn't hang i would have
<jam> wallyworld: install newer mongo :)
<jam> then it won't hang
<wallyworld> i'll have to get mongo sorted
<jam> wallyworld: on the list bigjools mentioned how to disable it (echoing the right disable into a file in /etc), but it isn't something I know offhand.
<jam> I'm personally happier not installing mongo and just having the binary in my $PATH
<wallyworld> i'll search for it
<jam> but I can appreciate the chain-of-authentication stuff
<bigjools> echo ENABLE_MONGODB=no | sudo tee -a /etc/default/mongodb
<wallyworld> thanks
<bigjools> part payment for the cricket tickets to Australia C on Weds
<jam> wallyworld: "Mongo packaging" is the thread on juju-dev if you need any of his other bits of wisdom.
<wallyworld> ok, thanks
<bigjools> how are you managing package versions?
<jam> bigjools: how do we package juju-core? dave cheney :)
<jam> He mentioned he just set up a daily build of juju-core
<jam> I don't know much more than that for his final releases.
<bigjools> well, I was thinking of go get
<jam> bigjools: have you seen mythreads on it? Poorly
<bigjools> I read them but that was before I starting understanding Go :)
<bigjools> I got the impression it was bad
<jam> bigjools: essentially "trunk always passes because we manage the race condition of updating the dependency and the master project at the same time"
<jam> but old versions of trunk aren't guaranteed to pass (are expected not to build because we can't trivially rollback the version of the deps)
<jam> once we are stable, we will probably go with a version number in the import string
<jam> with the cost that if we have to bump stability, the branch we land on will change location.
<bigjools> yeah, I was thinking about how to handle rollbacks etc
<bigjools> I guess it will come when the language matures
<jam> bigjools: essentially, we cannot do it easily, the tools don't support it, the powers that be don't want to write new tools.
<jam> though I might be jaded in my interpretation of the situation.
<jam> https://docs.google.com/a/canonical.com/document/d/1HaVHWyERiPOJgcIQ2W2jc9I7MZQ5OAVNB7m0nMr0oPw/edit#heading=h.dez8xb2t49nj was my attempt at trying to document it all
<jam> I petered out a bit rather than just living with the status quo
<bigjools> that's a recipe to have other tools reinvent the wheel and do it
<bigjools> yeah I can understand
<jam> bigjools: "Handling Active Dependencies in Go" is the rather large thread about it. https://groups.google.com/d/topic/golang-nuts/0avuiWURSQk/discussion is the only link I could find on golang-nuts
<bigjools> thanks
<jam> which is still "we could put the version in the import string"
<jam> which breaks lots of other bits
<jam> bigjools: specifically, the big problem with the import string, is that the *library* needs to also use the same import string
<jam> otherwise they are 2 different packages
<bigjools> yeah
<jam> so when you do a release, you now have a different URL, and different library source code.
<jam> and different place in your local dir
<jam> so all your tools need to move over there, etc.
<jam> so doing it for *every* bump of a lib that lands in juju-core
<bigjools> this is the price for putting it in the import
<jam> is too painful for devs
<jam> bigjools: right, and there isn't an abstraction point in go
<jam> They conflated them with probably some good intent (try not to repeat yourself)
<jam> but then end up mixing essentially runtime information with build time information.
<bigjools> yes
<bigjools> but it's great if you want to work on trunk :)
<jam> One proposal I mentioned was a tool that does the build-time information, and configures GOPATH (which is close to how LP does it with eggs and site.py)
<bigjools> right
<jam> bigjools: except for landing change to goose's trunk breaks juju-core from building.
<jam> unless you land patches "simultaneously"
<jam> we need to add 2-phase-commit to bzr :)
<bigjools> incompatible goose changes or some other reason?
<jam> bigjools: change anything that isn't directly source compatible.
<jam> 'go get' always grabs the latest tip of both branches.
<jam> so, rename a public variable, etc.
<bigjools> right - I was wondering if it was some language internal to do with compiling it
<jam> which truly isn't "stable"
<jam> but is very much in the "we don't know what the ideal API is yet, so let us not have cruft *before* we hit 1.0"
<bigjools> do we know how Google manages this problem?
<jam> bigjools: the thread above mentions 'goven' which is the CVS "vendor" model.
<jam> Track an upstream branch in your own repository
<jam> and use a tool to rename all of your "import launchpad.net/goose" code to be "import launchpad.net/juju-core/launchpad.net/goose"
<bigjools> I guess repository revnos become super important
<jam> bigjools: not quite sure I follow
<jam> Essentially you just put all possibly-unstable dependencies into your source tree.
<bigjools> if the packages don't have inherent versioning, you need to rely on repo versions to know what you have
<jam> with some tool helpers to make it a bit easier to update them to newer versions when you choose.
<bigjools> or am I missing something?
<jam> bigjools: go get doesn't have repo versions, it has repo locations.
<jam> So while *I* would have a tool more like launchpad's sourcedeps which lets you say "use launchpad.net/foobar@1234"
<bigjools> yes, but can you not fix the revno?
<jam> bigjools: you cannot put the revno into go get
<bigjools> yes, I mean pulling manually
<jam> bigjools: you can do your branches manually and not use 'go get -u'
<bigjools> or does it always refresh the branches?
<jam> bigjools: -u always refreshes the branches, but you could do all the work yourself
<bigjools> ok
<jam> with the major caveat that nobody else would do that until everything broke
<bigjools> this is messy :(
<jam> so you certainly can make your local development "work"
<jam> if I grab your code, it will break until I find your magic sauce.
<jam> which was the objection to writing a tool that did it
<jam> because then you need this new tool.
<jam> So version numbers in the import paths is sort of the way to go, except we aren't stable enough to pay the cost of creating a new branch for every change we want to land in juju-core.
<bigjools> right
<wallyworld> but even with version numbers in imports, you still pull from tip :-(
<bigjools> ok, EOD here. Bye all.
<jam> wallyworld: which is why you have to only use 1 branch per version you want to land
<jam> essentially, make a full release for anything you want to pull into juju-core
<wallyworld> which sucks :-(
<jam> Which is heavyweight but feasible once we are stable.
<wallyworld> but anyway, we've had that discussion
 * wallyworld late for soccer, back later
<jam> wallyworld: good luck!
<TheMue> fwereade_: Hiya and thx for the review. Regarding the non-existing path my solution creates nothing, so maybe less cost. But your is more elegant so that I'll take it.
<fwereade_> note also that your solution doesn't address the possibility that a file might be created after you check but before you run the test
<fwereade_> TheMue, thanks :)
<TheMue> fwereade_: Yeah, the little rest risk would exist, you're right. Even if the chance would be very low. ;)
<fwereade_> TheMue, million-to-one chances come up most days ;)
<TheMue> fwereade_: If one is running the tests each day and every minute, yes. :D
<fwereade_> TheMue, forgive my professional paranoia ;)
<TheMue> fwereade_: I appreciate it.
<TheMue> fwereade_: So I will now take your feedback and submit afterwards, so that we don't have those two parallel branches.
<fwereade_> TheMue, great -- tyvm, and thank you for bearing with me on these
<TheMue> fwereade_: I've got to thank you, great results need good reviews.
 * fwereade_ blushes
<TheMue> :D
<fwereade_> TheMue, rogpeppe2, jam, mgz: is juju-core also failing to build for you? I think I have the latest goose; it's complaining about identity.AuthMode and fip.InstanceId
<jam> fwereade_: the failure wasn't related to that. I'm pretty sure you need to cd ../goose; bzr pull --remember lp:goose
<jam> We moved where trunk was, so refreshing it should get you the latest goose.
<jam> "lp:goose" didn't change
<jam> but the exact branch it mapped to did, and "go get" expands the branch (I think)
<fwereade_> jam, thanks, that seems to have sorted it; I did try a go get -u, (and also tried a bzr update) then came complaining here
<wallyworld> jam: what problem were you having with reitveld - for some reason it all of a sudden won't authorise me anymore when I use lbox. is this what you saw?
<dimitern> wallyworld: the authorization expires after 30 days I think - it happened to me before
<wallyworld> i typed in my password and user id
<dimitern> wallyworld: just sign in in rietveld again and authorize your google account to use it
<dimitern> wallyworld: and then use lbox again
<wallyworld> i signed in via the command line but didn;'t authorise google
<wallyworld> i'll try that thanks
<dimitern> jam, mgz: standup?
<mgz> ne\rly there...
<TheMue> lunchtime
<rogpeppe2> fwereade_: does this error just imply that the charm isn't in the charm store?
<rogpeppe2> 2013/02/07 12:37:35 JUJU juju deploy command failed: cannot get latest charm revision: charm info errors for "cs:precise/logall-subordinate": entry not found
<rogpeppe> fwereade_: hmm, scratch that, i'm not using the right url.
<rogpeppe> fwereade_: it's interesting, the charm store doesn't print urls that are acceptable to go juju
<rogpeppe> go juju rejects this as invalid:  ~ju-jistics-hackers:precise/logall-subordinate
<rogpeppe> it also rejects  cs:~ju-jistics-hackers:precise/logall-subordinate
<niemeyer> Hello world!
<rogpeppe> niemeyer: yo!
<rogpeppe> niemeyer: i just discovered that the charm URLs printed by the charm store aren't valid for use with go juju. is that a problem on our side or theirs?
<niemeyer> rogpeppe: Slightly hard to tell given that summary :-)
<rogpeppe> niemeyer: here's an example of a URL shown by the charm store web site: ~ju-jistics-hackers:precise/logall-subordinate
<niemeyer> rogpeppe: That's not a valid URL
<rogpeppe> niemeyer: that's what i thought
<rogpeppe> niemeyer: i wonder if py juju is accepting it though
<niemeyer> rogpeppe: I don't think so
<niemeyer> rogpeppe: This is unlikely anything else we've ever talked about
<niemeyer> rogpeppe: URLs are prefixed by lp:
<niemeyer> Erm, sorry
<niemeyer> cs:
<rogpeppe> niemeyer: yeah, but it's invalid even when prefixed by cs:
<niemeyer> rogpeppe: Yeah, the : there should be /
<rogpeppe> niemeyer: yup
<rogpeppe> niemeyer: i'll try to find the appropriate place to raise an issue
<niemeyer> rogpeppe: Thanks
<niemeyer> rogpeppe: Good catch
<jam> wallyworld: note that the types will now have methods on them that they didn't before, so it isn't that much 'less' poluted (imo). If I could, I would make them private, but then JSON couldn't unmarshal into them.
<jam> I wasn't worried about pollution, because I thought these were supposed to be the types-for-json objects not the public-api objects.
<wallyworld> jam: the state that the user can access though is cleaner
<wallyworld> at  the moment, the objects eg Entity, ServerDetail etc are used in juju-core
<wallyworld> so they are being used as the public api objects for better or worse
<rogpeppe> niemeyer: https://bugs.launchpad.net/charmworld/+bug/1118351
<_mup_> Bug #1118351: Charm URLs shown with invalid URLs in search <charmworld:New> < https://launchpad.net/bugs/1118351 >
<Pavel_> Hi guys. Is there a way that I can add a local repository to juju-gui so I will be able to deploy my local charms directly from it?
<hazmat> Pavel_, not yet
<hazmat> Pavel_, we've been thinking to support local charms, we'll have the user run a program on their machine to expose the local repo via api on localhost that the gui can connect back to
<Pavel_> Can't it just accept e.g. git repo as an setting and fetch it to it's own instance and then look through it?
<hazmat> Pavel_, that's much less generic.. we'd have to support arbitrary numbers of arbitrary vcs, and authenticated access to those..
<hazmat> to get to equiv functionality
<Pavel_> yeah seems like it's not best option
<Pavel_> but still if you want to run juju on the same node as juju bootstrap, then you already have this local repo available
<Pavel_> *juju gui
<Pavel_> but of course it's not common case
<mramm> oops, lost track of time writing
<Pavel_> And isn't "juju scp" an another option? Can't you copy local repo from juju bootstrap node to juju GUI node?
<Pavel_> Sorry if I get something wrong
<hazmat> Pavel_, there isn't a local repo per se on disk for either the bootstrap or gui node. the gui is searching through rest api endpoints of a charm store frontend, which is what we should replicate in the locally run program. the env has a cache of deployed service charms, but those are in provider storage, not on any given machine. ie there is no repo on disk to simply copy files to.
<Pavel_> Yes, I understand. But do you think that replicating API is easier then reading repo from a local storage?
<hazmat> Pavel_, simple answer yes.. what's local storage in a  multi-node ha system?
<Pavel_> but juju bootstrap is always one node, isn't it?
<hazmat> Pavel_, that's being worked on
<Pavel_> hazmat, hot it
<Pavel_> *got )
<hazmat> i agree though at some point we'll have to explore answering questions from what local charms the environment has deployed .. but even then wouldn't be answering questions from disk. its not simply reading the charms on disk.. not just because there not on disk, but because its quite a rich search interface.. ie you can do full text and fielded queries like requires:mysql and conjunctions.
<hazmat> speaking of which i was looking around for full text solutions for golang.. i found some n-gram/codesearch content.. but afaics there isn't any equivalent to xapian/lucene in golang.. best i could find was sqlite fts.
<Pavel_> hazmat, I think that usually all you want is just to run more instances of existing services or deploy one which name you already know.
<hazmat> Pavel_, that's fair.. but the search also helps drive richer ui interfaces, suggested relations, discovery, etc.
<Pavel_> hazmat, but for local repo you could have simplier version of this
<Pavel_> hazmat, actually you already know what is there and what you want to deploy
<Pavel_> Generally I'm newbie in using juju, but my vision is that it can really play well for deploying domain based charms written for particular service.
<hazmat> Pavel_, yes it could be simpler and likely will be, but local doesn't mean the deployer wrote it  or that the repo doesn't contain lots of charms, ie. search is still useful. hmmm.. i think i see what your saying for the use case though and why the local program for local charms doesn't suffice for it
<hazmat> effectively you want to put local charms to the env, and have them available for deploy in the gui
<Pavel_> yep
<hazmat> Pavel_, sounds good
<Pavel_> I really miss this feature
<Pavel_> one more question, is there a way to set user name when run juju debug-hooks ?
<Pavel_> I get ssh error when try doing this
<hazmat> Pavel_, no.. it should be using the same key used to populate the env.. default it sniffs and injects the public key, but it can be specificied explicitly in environments.yaml as well .. it always goes to the ubuntu user which juju injects the public key as authorized key.. also this sort of question is better on #juju
<Pavel_> ah, ok
<rogpeppe> afk for a little
<rogpeppe> back
<dimitern> rogpeppe: quick question?
<rogpeppe> dimitern: ask away!
<dimitern> rogpeppe: what do I need to support for := range over my own type?
<rogpeppe> dimitern: you can't do that
<rogpeppe> dimitern: range always ranges over maps, slices or channels
<dimitern> rogpeppe: really? damn..
<rogpeppe> dimitern: what kind of type is it?
<dimitern> rogpeppe: so I need something like a while loop with Next()
<rogpeppe> dimitern: there are various possibilities for iteration
<rogpeppe> dimitern: it totally depends what the semantics of your type are
<dimitern> rogpeppe: well I'm trying to replace an embedded url.Values and provide the same interface - Add, Del, Set, Encode, etc. and still be able to iterate over
<rogpeppe> dimitern: do you know in advance how many elements there are?
<rogpeppe> dimitern: what semantics do you want to add?
<dimitern> rogpeppe: because I need range to iterate in the order added and url.Values is map[string][]string
<rogpeppe> dimitern: why not just provide a method that returns a sorted slice of all the entries in the map?
<dimitern> rogpeppe: i.e. f.Add(x, ..); f.Add(y, ..) -> range x, then y
<dimitern> rogpeppe: hmm yeah, that could work
<rogpeppe> dimitern: you could just return the keys
<rogpeppe> dimitern: and leave your type as a map
<dimitern> rogpeppe: but not good enough - I don't need them sorted, but in the order added
<rogpeppe> dimitern: out of interest, what's this to be used for?
<dimitern> rogpeppe: maybe leave the embedded and override Add to keep ordered slice of keys aside and a method Keys() to return them in proper order
<dimitern> rogpeppe: because openstack is sensitive with the order in which you specify multiple value filters
<dimitern> rogpeppe: so status=A&status=B is not the same as status=B&status=A
<rogpeppe> dimitern: ah
<rogpeppe> dimitern: so it's not like ec2 that numbers all attributes sequentially?
<dimitern> rogpeppe: no, it's a weird lax url encoded stuff with duplicates, but some logic to parse them in order
<rogpeppe> dimitern: hmm, so for the double you won't be able to use any of the stock form parsing stuff
<rogpeppe> dimitern: that's quite bad
<rogpeppe> dimitern: what a shitty interface
<rogpeppe> dimitern: so what *is* the difference between status=A&status=B and status=B&status=A ?
<dimitern> wow, my machine died on me
<rogpeppe> dimitern: :-|
<rogpeppe> dimitern: what was the last message you saw from me?
<dimitern> rogpeppe: can't see - had to cold boot
<rogpeppe> dimitern: you need a better irc client :-)
<rogpeppe> here are the last few things is said
<rogpeppe> i said!
<rogpeppe> 18:22:37] <rogpeppe> dimitern: hmm, so for the double you won't be able to use any of the stock form parsing stuff
<rogpeppe> [18:23:36] <rogpeppe> dimitern: that's quite bad
<rogpeppe> [18:23:49] <rogpeppe> dimitern: what a shitty interface
<rogpeppe> [18:24:46] <rogpeppe> dimitern: so what *is* the difference between status=A&status=B and status=B&status=A ?
<dimitern> rogpeppe: right, so the difference is this
<dimitern> rogpeppe: I'll paste my code to see
<dimitern> rogpeppe: http://paste.ubuntu.com/1621741/
<rogpeppe> dimitern: oh BTW, there shouldn't be a problem with status=A&status=B - the same attribute is used both times
<dimitern> rogpeppe: the problem is they are combined
<dimitern> rogpeppe: oh... you know what, I think you're right - it's simpler
<rogpeppe> dimitern: yeah, i don't think you're ranging over a map there
<dimitern> rogpeppe: I managed to debug the name gets replaced by the last value specified, but for status wasn't that obvious
<rogpeppe> dimitern: all the names are still available
<rogpeppe> dimitern: that's why it's map[string][]string
<dimitern> rogpeppe: my original thought was specifying status twice will get me both statuses
<rogpeppe> dimitern: (note the []string)
<rogpeppe> dimitern: it should do, yes
<dimitern> rogpeppe: but my tests so far show:
<rogpeppe> dimitern: i mean... what?
<rogpeppe> dimitern: it depends what level you're talking about
<dimitern> rogpeppe: S=A&S=B -> 0 (assuming 3 servers in A)
<dimitern> rogpeppe: S=B&S=A -> 3; S=X&S=Y&S=A -> 3; S=X&S=A&S=Y -> 0
<rogpeppe> dimitern: those are the semantics that openstack gives you?
<dimitern> rogpeppe: it's very frustrating to actually create several machines with different status to test this properly
<dimitern> rogpeppe: those are my findings after running a lot of queries with filters against canonistack
<rogpeppe> dimitern: so it's just ignoring all but the last value for a given attribute, right?
<dimitern> rogpeppe: and the problem is, in juju you'd like to get all machines in either build or active, but this seems impossible with as single API call
<dimitern> rogpeppe: seems so yes
<rogpeppe> dimitern: they could've learned something from ec2's filtering semantics
<dimitern> rogpeppe: i tried to replicate ec2 way, but i guess we'll have to get only active machines and until the status changes from build to active, Instances() won't return anything
<rogpeppe> dimitern: yeah, sounds like you need two queries
<rogpeppe> dimitern: and combine the results of both
<rogpeppe> dimitern: you can run 'em both concurrently though, so it shouldn't be much slower
<dimitern> rogpeppe: yes, unless getting only active suffices
<rogpeppe> dimitern: so... i don't see that there's any particular difficulty here
<rogpeppe> dimitern: we don't care about map ordering
<dimitern> rogpeppe: yeah
<dimitern> rogpeppe: I wish I could've seen that yesterday more clearly :)
<dimitern> rogpeppe: and to actually test whether in fact multiple status filters work at all
<rogpeppe> dimitern: to implement the double you can just have a function: func GetLastValue(v url.Values, attr string) string {x := v[attr]; if len(x) > 0 {return x[len(x)-1]}; return ""}
<dimitern> rogpeppe: is it important to get pending machines from the provider as well? even with the eventual consistency attempts/retries?
<rogpeppe> dimitern: yes
<dimitern> rogpeppe: why?
<rogpeppe> dimitern: because we assume that if we've called StartInstance we can retrieve information about it soon afterwards
<rogpeppe> dimitern: if openstack is anything like ec2, pending machines can remain pending for quite a long time
<dimitern> rogpeppe: if it's only about getting result out of StartInstance, you always get this
<rogpeppe> dimitern: what's the significance of "build" and "active" with regard to juju, BTW?
<dimitern> rogpeppe: and it's correct, the problem could be if you want to list them later
<rogpeppe> dimitern: exactly
<rogpeppe> dimitern: or get an Instance
<rogpeppe> dimitern: from the instance id
<rogpeppe> dimitern: what's the issue you have with returning pending instances?
<dimitern> rogpeppe: build means basically booting, setting up network, etc., which becomes available shortly before the machine switches to active
<dimitern> rogpeppe: getting instance by id is again not a problem
<dimitern> rogpeppe: only Instances() and AllInstances() are affected
<dimitern> rogpeppe: which will use the filtering and ideally do it with a single API call, filtering by inst name (environment) and active status
<dimitern> rogpeppe: if you need a specific instance and you know it's id you can get it directly, no filtering involved
<rogpeppe> dimitern: i think only AllInstances is affected
<dimitern> rogpeppe: the idea of filtering arose from the need to get only this environment's machines (by name) - so both Instances() and AllInstances() use it
<rogpeppe> dimitern: Instances only does it so it doesn't return machines which have been stopped
<dimitern> rogpeppe: but how about the ones about to become active?
<rogpeppe> dimitern: yeah, it needs to return those
<rogpeppe> dimitern: as far as juju is concerned, they're active already, just not ready.
<dimitern> rogpeppe: ok I can do it in 2 goroutines then, fetching both active and build and returning the merged
<dimitern> rogpeppe: the thing is, machines in build state cannot be tackled the same as active ones
<rogpeppe> dimitern: yup. or, even better, just don't filter by status at all
<rogpeppe> dimitern: and filter that client side
<dimitern> rogpeppe: some things fail (like assigning a floating IP)
<dimitern> rogpeppe: that's even better actually - I'll just filter out the ones with bad status
<rogpeppe> dimitern: yup
<dimitern> rogpeppe: the problem is you can have 100K machines to process there
<rogpeppe> dimitern: we only do the filtering server-side in ec2 'cos it's easy to do
<rogpeppe> dimitern: that's true of AllInstances in general
<rogpeppe> dimitern: i don't think returning dead machines is going to add too much load
<dimitern> rogpeppe: actually the machines that need filtering will be a lot less than the active ones
<rogpeppe> dimitern: exactly
<dimitern> rogpeppe: ok then, I'll filter client-side for status
<rogpeppe> dimitern: +1
<dimitern> rogpeppe: thanks :) it really helped me clear it up for myself
<rogpeppe> dimitern: then you can ignore the whole url.Values thing :-)
<rogpeppe> dimitern: np, it's a pleasure to help
<dimitern> rogpeppe: yeah, or at least make it much simpler
#juju-dev 2013-02-08
<wallyworld_> davecheney: hi, any chance of a quick 2 line code review? improved boilerplate for 1.9.8 release https://code.launchpad.net/~wallyworld/juju-core/improve-boilerplate-config/+merge/147279
<davecheney> sure
<wallyworld_> thanks
<davecheney> have you guys stopped using lbox ?
<wallyworld_> i can't login
<wallyworld_> it won't auth
<wallyworld_> trying to debug it now - it seems the login response returns no cookies
<wallyworld_> even though it nominally succeeds
<davecheney> LGTM
<davecheney> afk for a bit - hangout
<wallyworld_> thanks
<thumper> hi wallyworld_
<thumper> I'm just about to sign off
<wallyworld_> g'day
<thumper> busy getting my head around juju
<wallyworld_> hah
<wallyworld_> have a good weekend
 * thumper waves at davecheney too
<thumper> you too
 * wallyworld_ wishes it would stop raining so soccer isn't cancelled tonight
<davecheney> 013/02/08 17:34:22 JUJU juju bootstrap command failed: cannot start bootstrap instance: cannot allocate a public IP as needed
<davecheney> any ideas ?
<davecheney> this is on canonistack
<TheMue> Morning
<rogpeppe> davecheney: i think public IPs are few and far between in canonistack
<rogpeppe> davecheney: istr there was some talk of making getting a public IP optional
<rogpeppe> TheMue, fwereade_, all: mornin'
<TheMue> rogpeppe: Hello Mr Peppe ;)
<TheMue> davecheney, fwereade_: And also a hello to you.
 * rogpeppe loves it when tests find obvious mistakes that you've looked at many times without seeing.
<rogpeppe> fwereade_: ping
<rogpeppe> if anyone wants to take a look, here's the CL that implements API authentication: https://codereview.appspot.com/7299066/
<TheMue> rogpeppe: *click*
<TheMue> rogpeppe: You've got a +1.
<rogpeppe> TheMue: thanks
<TheMue> rogpeppe: yw
<rogpeppe> "
<rogpeppe> Name "stm" has been a bit misleading because we mostly talk about state.Machine
<rogpeppe> here.
<rogpeppe> "
<rogpeppe> TheMue: the point of naming it stm there is because it *is* a state.Machine
<rogpeppe> TheMue: an alternative would be to call all the api-specific variables apist, apim, etc
<rogpeppe> TheMue: rather than st, m
<TheMue> rogpeppe: All m's in there are state.Machines. And in the same method you also mad a pure m. In that case the M(achine) has a special semantic. That's why I proposed a different prefix.
<rogpeppe> TheMue: "pam" is not great, because it doesn't say anything about why that machine is special (the machine returned by the api.State.Machine call is a representation of that machine too)
<rogpeppe> TheMue: perhaps i should just call it apim
<TheMue> rogpeppe: +1 on that, yep.
<TheMue> rogpeppe: But even w/o a change it would be ok for me, it only has been a minor.
<rogpeppe> TheMue: ok, cool
<TheMue> rogpeppe: One look into the according function and it has been clear.
<TheMue> rogpeppe: But your func() func() (func(), error) is nice. *bg*
<rogpeppe> TheMue: closures are great :-)
<TheMue> rogpeppe: Indeed.
<TheMue> rogpeppe: Only missed a func() as arg of that func. *rofl*
<rogpeppe> TheMue: higher-order tests, yay!
<TheMue> rogpeppe: Or a func, getting a func, producing a func which has a func as arg to produce a func.
<rogpeppe> TheMue: now now, then, we're not using haskell :-)
<TheMue> rogpeppe: Hehe, and it would look weird. Smalltalk closures are pretty short. [:a :b | a doSomethingWith: b]
<TheMue> rogpeppe: But the call is ugly.
<TheMue> rogpeppe: In case that one is stored in c it has to be "c value: something value: anotherThing."
<TheMue> Oh, just called for lunchtime.
<TheMue> biab
<rogpeppe> TheMue: of course, no unnamed params in smalltalk
<fwereade_> rogpeppe, pong, sorry I missed you
<dimitern> fwereade_: fancy a quick review? :)
<fwereade_> dimitern, sure :)
<dimitern> fwereade_: https://codereview.appspot.com/7299047/ - should be simple enough
<dimitern> fwereade_: 10x
<rogpeppe> mgz: i'm interested to know what you thought was particularly bad about the ec2 port handling code. nothing seems to stand out for me, but i'm certainly biased :-)
<rogpeppe> fwereade_: just thought you might wanna have a look at the API authentication CL: : https://codereview.appspot.com/7299066/
<rogpeppe> dimitern: looking
<fwereade_> rogpeppe, ah, cheers
<mgz> rogpeppe: which particular frustration I feel with it varies :)
<rogpeppe> fwereade_: it's a bit bigger than i intended, but hopefully still not *too* bad
<rogpeppe> mgz: top 3 frustrations?
<mgz> so, currently,
<mgz> the copy code between ec2/openstack (need to learn go trick for sharing code without making something public interface)
<rogpeppe> mgz: the difficulty there is that openstack and ec2 interfaces are very similar but not the same...
<rogpeppe> mgz: if there was any code you wanted to factor out, it could go into another package, say environs/ec2like
<rogpeppe> mgz: it has always been the intention to factor out common code between providers - but before we had multiple providers, it was hard to say which code was appropriate.
<mgz> batch rule handling where it doesn't make sense for openstack, magic-name lookup and unclear behaviour on individual errors
<mgz> and the long-standing but less current one of security group per-machine and cleanup of resources
<rogpeppe> mgz: yeah, the magic name lookup was a legacy from the python port
<rogpeppe> mgz: in openstack, can you change the security groups assigned to a machine?
<mgz> yup.
<rogpeppe> mgz: ah, then you can avoid the one-security-group-per machine issue
<mgz> though, there are caveats that make that less promising that it sounds.
<rogpeppe> mgz: in ec2 you can't
<dimitern> rogpeppe, mgz: you can change the secgroups of a machine, but you need to reboot it to take effect
<mgz> in that, I think deployment variable, you can't trust rules on a new group to apply unless the vm is rebooted
<rogpeppe> mgz: cleanup of resources is an issue - the main problem is when you kill the instances but never run destroy-environment.
<rogpeppe> mgz: ah, that makes it pretty useless
<mgz> in openstack cleanup can be done properly, if careful, because you can delete groups on terminate machine
<rogpeppe> mgz: "i'll call juju expose - oops, all my machines have just rebooted!"
<mgz> anyway, the port batching is annoying
<mgz> especially given it's still port-at-a-time
<mgz> and range ignorant
<rogpeppe> mgz: at one time, i did have the ec2 provider delete security groups on instance termination, but it failed all the time, because the instance takes a while to relinquish its security groups
<mgz> right, I know that code
<mgz> it can be done safely with openstack because you can remove the group from the server first
<rogpeppe> mgz: the port batching means you do at least have the capability to do it as a batch. but i agree it's not entirely clear what to do about partial errors.
<mgz> leads to some slightly-complicated deferred chaining with twisted though :)
<rogpeppe> mgz: but that issue applies to the agent too - what should the agent do if it can't remove a given port?
<rogpeppe> mgz: hopefully not so complicated under Go :-)
<mgz> clearly report that one part failed and continue, probably
<mgz> the fun has tended to be that things get logged somewhere far from what cares about it so it's hard to tell why something hasn't worked
<rogpeppe> mgz: yeah, logging is an issue we need to think hard about
<rogpeppe> mgz: i'd be happy to see the batch operations return an error that summarises all the ports that couldn't be closed, rather than just stop at the first.
<rogpeppe> lunchtime
<dimitern> what does it mean `json:"-"` as a tag?
<dimitern> on a struct field
<TheMue> dimitern: The field is ignored in serialization.
<dimitern> TheMue: ignored only on marshaling, but not unmarshaling?
<TheMue> dimitern: Oh, would have to test. IMHO only marshalling.
<dimitern> TheMue: ok, thanks
<dimitern> fwereade_, rogpeppe: any thoughts on the CL?
<fwereade_> dimitern, reviewed, let me know your thoughts; I might be missing some subtleties
<dimitern> fwereade_: cheers, I'll take a look
<dimitern> fwereade_: I'm not sure I get your idea with simplifying the matching loop - can you elaborate a bit?
<fwereade_> dimitern, say I ask for the following ids: "", "a", "b", "c", "d" (hope that's enough)
<dimitern> fwereade_: so, you propose to take the API calls out of the function and pass the result as a map
<fwereade_> dimitern, "a" is missing due to eventual consistency, "b" is in the wrong env, "c" is terminated, and "d" actually works correctly
<fwereade_> dimitern, gatherInstances would put an instance in the map under "d"
<fwereade_> dimitern, and return only {"a"}
<fwereade_> dimitern, because it has enough information after the first call to eliminate all the others from consideration
<dimitern> fwereade_: ah, so the API calls stay there
<fwereade_> dimitern, yeah
<rogpeppe> TheMue, dimitern: json:"-" means it's ignored for both marshalling and unmarshalling
<rogpeppe> http://play.golang.org/p/QdPfN_Dv4Z
<dimitern> rogpeppe: got it, thanks
<dimitern> fwereade_: so gather will return only the ones it cannot find
<dimitern> fwereade_: but that'll change Instances and make it more complex it seems
<fwereade_> dimitern, maybe I'm missing something, because it seemed it would become simpler, I'll try to sketch what I'm imagining
<dimitern> fwereade_: quite a lot is happening there - handling all of these cases: empty ids passed, multiple ids, single ids with empty ones (essentially a single id), servers with errors/missing
<dimitern> rogpeppe: Add() is there because we reuse url.Values and its methods
<dimitern> rogpeppe: I don't know how to override an inherited method so it's not public any more and cannot be called
<rogpeppe> dimitern: i hadn't seen that. i'm not sure it's entirely appropriate to embed url.Values there
<dimitern> rogpeppe: we need it because of the Encode() method mostly, but also Get and Set
<rogpeppe> dimitern: do nova clients need to call Encode on it?
<TheMue> rogpeppe: tThx for the info.
<dimitern> rogpeppe: yes, to pass it to nova in the url
<dimitern> rogpeppe: it happens internally in ListServers/Detail
<rogpeppe> dimitern: but that's an implementation detail, right. nothing external to nova needs to see that the underlying representation is a url.Values, does it?
<rogpeppe> s/right./right?/
<dimitern> rogpeppe: right
<rogpeppe> dimitern: i'd be much happier to see type Filter struct {v url.Values}
<rogpeppe> dimitern: implementing only the single method Add
<dimitern> rogpeppe: I see you point, and I was wondering so myself
<fwereade_> dimitern, ahh, I see the problem -- you can't tell whether something missing from ListServersDetail is because it's not there, or because it is there but in in the wrong environment
<rogpeppe> dimitern: a mean the single method *Set* of course :-)
<rogpeppe> s/a mean/i mean/
<dimitern> rogpeppe: I should propose a follow-up changing this, so we only have explicit methods on Filter
<rogpeppe> dimitern: +1
<dimitern> fwereade_: exactlty
<dimitern> fwereade_: exactly even :)
<dimitern> rogpeppe: I'm on it - it should be trivial
<fwereade_> dimitern, ok, but that is very much an edge case indicating that things are seriously wrong elsewhere, right?
<dimitern> fwereade_: not necessarily, why?
<fwereade_> dimitern, because for that value to have been passed in, something must have some reason to believe that instance is part of the environment, right?
<dimitern> fwereade_: right
<fwereade_> dimitern, I'm not saying it *can't* happen, but it certainly shouldn't ;p
<rogpeppe> fwereade_, dimitern: i'm not sure whether a map will help, but it does appear to me that the code could be simpler
<dimitern> I'd appreciate a short example how, because I spent all day yesterday trying to make it as good and fast as I can, but probably failed it seems
<fwereade_> dimitern, how about http://paste.ubuntu.com/1624792/ ?
<fwereade_> dimitern, I appreciate that it's a bit of a gnarly problem and I've probably missed something
<dimitern> fwereade_: looking
<dimitern> rogpeppe: here's the follow-up - I think it should be trivial enough - https://codereview.appspot.com/7301064
<dimitern> fwereade_: is x := map[T]Y{} equivalent to x := make(map[T]Y) ?
<fwereade_> dimitern, yeah, as far as I'm aware
<dimitern> fwereade_: cool, I'll remember that :)
<fwereade_> dimitern, yeah, I prefer it myself usually
 * rogpeppe prefers make when appropriate :-)
<dimitern> rogpeppe: because it's more explicit?
<rogpeppe> dimitern: yeah - i often have to look twice for the {} at the end
<dimitern> rogpeppe: yes, I can see how it could be confusing - I missed it at first
<rogpeppe> dimitern: the difference between var x map[T]Y and x := map[T]Y{} is subtle :-)
<rogpeppe> dimitern: i don't mind either form though tbh
<dimitern> rogpeppe: but var x map[X]Y is not the same, right? you still need to make() it before using?
<rogpeppe> dimitern: exactly. that's why it's a subtle difference to spot.
<dimitern> rogpeppe: yeah
<dimitern> i'll go grab some food, bbiab
<rogpeppe> in limbo if you used a type expression as a normal expression, it made something of that type. so you could say x := chan of int, and it was equivalent to x := make(chan int)
<rogpeppe> that was nice but syntactically limiting
<rogpeppe> fwereade_: +1 to your collectInstances
<fwereade_> rogpeppe, cheers :)
<rogpeppe> fwereade_: although an approach similar to ec2's can also work fine there i think. it's got an n^2 loop, but n is always 1 in our code...
<fwereade_> rogpeppe, I think ec2 gathers more than it needs to, but it's a simple fix: n++ at :504 before continuing
<rogpeppe> fwereade_: omg you're right. that's a bug.
<rogpeppe> fwereade_: and i think that it cause errors actually
<rogpeppe> s/cause/could cause/
<fwereade_> rogpeppe, glad we saw it then :)
<rogpeppe> fwereade_: ah, i see why the tests don't catch it - it can only happen if a request fails first time, then succeeds the next.
<fwereade_> rogpeppe, yeah, think so
<rogpeppe> fwereade_: we should probably add something to ec2test to enable particular failure modes
<fwereade_> rogpeppe, +100
<rogpeppe> fwereade_: perhaps like the hook feature in the openstack double
<fwereade_> rogpeppe, yeah, given that it doesn't seem to be causing too much pain, I think it's a solid model
<rogpeppe> fwereade_: i didn't do it before because i wasn't sure of a nice way to do it.
<dimitern> fwereade_: right :) that pesky n++ :)
<fwereade_> rogpeppe, I completely understand that :)
<dimitern> fwereade_: but the other thing - removing the for loop checking if any(insts) is nil should stay as is
<rogpeppe> fwereade_: have you had a glance at the api auth CL, by any chance? i'm interested how you think it's turning out.
<fwereade_> rogpeppe, was just starting to when I got distracted by this discussion :)
<rogpeppe> fwereade_: lol
<fwereade_> dimitern, ah, I thought I'd handled that -- what scenario did I miss?
<dimitern> fwereade_: collectInstances won't work correctly with [id0, ""] or [id0, "", ""] for that mater, needs an extra check to avoid doing List when you can do Get
<dimitern> fwereade_: no I meant ec2 Instances()
<fwereade_> dimitern, ahok
<fwereade_> dimitern, yeah, I guess we could start by just filtering ""s out in Instances
<dimitern> fwereade_: sure, we can filter them, but we need to still return ErrPartialInstances whenever there are empty ids
<fwereade_> dimitern, that'll happen anyway, won;t it?
<dimitern> fwereade_: that's what a lot of the code and tests expect (why though, it beats me)
<fwereade_> dimitern, we just construct missing by filtering ids at the start
<dimitern> fwereade_: yes, but len(ids) == 1 is not enough, we should scan through it until we find one or more ids to check
<dimitern> fwereade_: imagine ["",id0] or ["", "", id0], etc.
<dimitern> fwereade_: in this case all we need is Get(id0)
<fwereade_> dimitern, if we pre-filter ids to missing in Instances, we'll just pass ["id0"] up to collectInstances, right?
<dimitern> fwereade_: that'll work, but despite filtering, we still have to return ErrPartialInstances in Instances() when there are empty ones
<fwereade_> dimitern, I assert that it will work correctly, because the final loop won't find any Instance for ""
<dimitern> fwereade_: you're right, so just a filtering before collect should be enough
<dimitern> fwereade_: and not calling it at all if after filtering len == 0
<dimitern> fwereade_: i.e. ["", ""] was passed
<fwereade_> dimitern, yeah, +1
<dimitern> fwereade_: great, I'll give it a go then
<dimitern> fwereade_: tyvm
<rogpeppe> dimitern: reviewed https://codereview.appspot.com/7301064/
<rogpeppe> dimitern: i don't think you should worry if we call ListInstances when the user passes in blank instances
<rogpeppe> dimitern: it should never happen, and the code should work correctly even when it does
<rogpeppe> dimitern: so i wouldn't bother doing any initial filtering - it complicates the code for no gain
<dimitern> rogpeppe: thanks for the review
<dimitern> rogpeppe: it happens a lot in tests
<rogpeppe> dimitern: do we care?
<rogpeppe> dimitern: the performance will be almost exactly the same
<dimitern> rogpeppe: hmm.. since we're not actually trying to pass any ids to nova, but rather filter them later, this will affect only the single id - Get case, we shouldn't call Get("")
<rogpeppe> dimitern: i don't even care if we do that
<rogpeppe> dimitern: the tests should probably use "somerandomthing" rather than "" as an invalid id
<rogpeppe> dimitern: but the result is probably the same tbh
<rogpeppe> dimitern: there's nothing special about ""
<rogpeppe> dimitern: in this case
<dimitern> rogpeppe: not exactly, passing "" will try to fetch /servers/ rather than /servers/id and till return 404
<rogpeppe> dimitern: that seems like a bug in goose to me
<dimitern> rogpeppe: s/till/will/, but this is the same really
<rogpeppe> dimitern: it should error out if the id is empty
<dimitern> rogpeppe: this makes sense
<dimitern> rogpeppe: anyway - I only added the Get() single id case as jam suggested
<dimitern> rogpeppe: but now it seems more of an overkill to support this case will all its subtleties
<rogpeppe> dimitern: i think using Get when appropriate is good
<rogpeppe> dimitern: but i don't think that you need to worry about the case where some ids are invalid
<rogpeppe> dimitern: the only difficulty is that the server might return an "invalid id" error.
<dimitern> rogpeppe: yes, and having List only will solve any issues
<dimitern> rogpeppe: and frankly, he performance benefit of get escapes me now
<dimitern> rogpeppe: when we have to handle all those extra cases so it won't blow unexpectedly
<dimitern> rogpeppe: changes applied - https://codereview.appspot.com/7301064/
<dimitern> my irc client behaves odd
<dimitern> not sure I managed so send anything in the last 10m
<rogpeppe> dimitern: last messages i've seen from you:
<rogpeppe> [15:10:11] <dimitern> rogpeppe: changes applied - https://codereview.appspot.com/7301064/
<rogpeppe> [15:20:20] <dimitern> my irc client behaves odd
<rogpeppe> [15:20:42] <dimitern> not sure I managed so send anything in the last 10m
<dimitern> rogpeppe: so I didn't miss anything, cheers
<dimitern> fwereade_: fresh from the oven - https://codereview.appspot.com/7299047/ :)
<fwereade_> dimitern, cheers -- I'm just going through rog's API stuff now
<dimitern> fwereade_: no worries
<dimitern> rogpeppe: refactored filters, as discussed: https://codereview.appspot.com/7301064
<dimitern> fwereade_: when you can, can you look at this too please? ^^
<fwereade_> dimitern, ack
<dimitern> fwereade_: thanks
<rogpeppe> fwereade_: i still see Get and Del methods on nova.Filter
<dimitern> rogpeppe: oops, sorry they're unused now, but forgot to remove them
<dimitern> rogpeppe: fixed now, 10x
 * dimitern afk 10m
<rogpeppe> dimitern: reviewed
<dimitern> back
<dimitern> rogpeppe: tyvm
<dimitern> is a map always passed by reference?
<rogpeppe> dimitern: yes
<dimitern> func f(m *map[X]Y) <=> func f(m map[X]Y) ?
<rogpeppe> nope
<rogpeppe> dimitern: a pointer to a map is a pointer to a map
<rogpeppe> dimitern: the first form of the function there is redundant
<dimitern> but i suppose having a pointer here no longer makes sense
<mgz> dimitern: so, just to double check with you, to land things on goose now I should set a commit message on lp and mark approved?
<rogpeppe> dimitern: yup
<dimitern> mgz: yes
<dimitern> rogpeppe: cheers
<mgz> dimitern: ta
<dimitern> rogpeppe: so LGTM? :)
<dimitern> mgz: so the release is today?
<mgz> well, by monday we assume
<rogpeppe> dimitern: LGTM
<dimitern> rogpeppe: great, 10x
<fwereade_> rogpeppe, I'm not going to finish it today, but I think I'm comfortable with what I've seen so far
<fwereade_> dimitern, I won't get to yours tonight I'm afraid
<dimitern> fwereade_: no problem
<dimitern> mgz: can you take a look then? https://codereview.appspot.com/7299047/
<mgz> sure
<dimitern> cheers
<rogpeppe> fwereade_: great, thanks
<rogpeppe> fwereade_: any chance of publishing any comments you have so far?
<dimitern> rogpeppe: can i bug you one last time (for today)? :) https://codereview.appspot.com/7299047/
<rogpeppe> dimitern: i preferred william's version that used GetServer most of the time
<dimitern> rogpeppe: the round-trip is still the same actually
<rogpeppe> dimitern: because we really don't want to be downloading all server details when we're after just a single instance (which is actually the only way we use Instances currently)
<rogpeppe> dimitern: the amount of traffic is not though
<mgz> right, there are a few slightly complex things there dimitern that I'm not certain of
<dimitern> rogpeppe: so it's certain we're using mostly Instances([]{id}) ?
<rogpeppe> dimitern: if you've got 10000 servers, you're going to get details for all of them, even though you're just interested in one.
<mgz> I don't mind landing it if we actually get a chance to revisit though
<rogpeppe> dimitern: yup. grep for it yourself...
<rogpeppe> dimitern: we never actually call Instances with more than one instance, except in tests.
<dimitern> rogpeppe: and how about passing empty ids ? is this just for tests for it actually happens often?
<rogpeppe> dimitern: that's just for tests.
<rogpeppe> dimitern: i have another idea actually
<rogpeppe> dimitern: you could just spawn off n concurrent GetServer requests
<dimitern> rogpeppe: ok, so that's easy enough to fix - i'll just test the len() == 1 case and leave the rest
<rogpeppe> dimitern: and avoid using List at all
<rogpeppe> dimitern: sounds good.
<dimitern> rogpeppe: wow! that's seems an overkill
<dimitern> rogpeppe: how it would be better?
<rogpeppe> dimitern: yeah, ignore that. although it's probably not much code.
<dimitern> rogpeppe: no, i can see it in like 5 lines, but I'm curious about the merits
<rogpeppe> dimitern: it would mean that if you're fetching only 2 instances out of 1000, you only get info for those two instances.
<rogpeppe> dimitern: and the round-trip time would be similar
<dimitern> rogpeppe: exactly, it'll effectively increase in fact - n*GetServer >> m*ListServers, and now ISTM m is usually 1
<rogpeppe> dimitern: i dunno; it's not n*GetServer because we're doing them all concurrently.
<dimitern> rogpeppe: the traffic I mean, not the time
<dimitern> rogpeppe: with n=100k it makes a huge difference to use 1 getserver if possible
<rogpeppe> dimitern: yeah. and even 2 getservers when n is two.
<rogpeppe> dimitern:  if you've got 1000 servers but you're only requesting two instances, the traffic for ListServers is proportional to 1000, but the traffic for GetServer is proportional to 2.
<rogpeppe> dimitern: but tbh the 1-instance case is the only one i care about.
<dimitern> rogpeppe: i didn't quite get that 1-instance? you mean optimize both len == 1 and len == 2 cases?
<dimitern> rogpeppe: going even further, we can estimate how many getserver calls we can make and still be better of than a single listservers if we know N :)
<rogpeppe> dimitern: you mean if we know M, presumably?
<dimitern> rogpeppe: and of course, we parallelize the getserver calls
<rogpeppe> dimitern: yeah
<dimitern> rogpeppe: yeah
<dimitern> rogpeppe: but perhaps that's going a bit too far now
<rogpeppe> actually, we didn't have a variable name for overall number of instances...
<rogpeppe> dimitern: yeah. just implement the n=1 case, and that will work fine for now.
<dimitern> rogpeppe: we can assume len == 1 case is special and simple enough to optimize for
<rogpeppe> dimitern: +1
<dimitern> rogpeppe: we can cache len(AllInstances)
<rogpeppe> dimitern: not worth it
<rogpeppe> dimitern: in the cases we're concerned about, there might be huge churn, and our cache is likely worthless.
<rogpeppe> dimitern: and the number of instances we're requesting is always likely to be small, i think.
<dimitern> rogpeppe: well, if we have metering about traffic per cloud API call we can easily estimate such dynamic run-time optimizations
<rogpeppe> dimitern: there are many optimisation possibilities :-)
<dimitern> rogpeppe: juju will achieve some level of consciousness
<dimitern> :)
<rogpeppe> dimitern: it's gonna happen :-)
<dimitern> rogpeppe: great book btw - born to run, fwereade_gave it to me and I few through it
<rogpeppe> dimitern: isn't it fascinating?
<rogpeppe> dimitern: glad you like it
<rogpeppe> dimitern: do you run at all?
<dimitern> rogpeppe: great for running motivation, i already ordered a pair of thin sole sandals :)
<rogpeppe> dimitern: cool!
<rogpeppe> dimitern: i think the main take-away is "strike toe first"
<dimitern> rogpeppe: i started a few weeks ago, but it's tough to get out
<dimitern> rogpeppe: oh yeah, easy, light, smooth, fast, etc.
<rogpeppe> dimitern: and most importantly easier on the joints
<dimitern> rogpeppe: this week i did like 10m and i'm still recovering my gait :)
<rogpeppe> dimitern: i used the couch-to-5k routine for a while
<dimitern> rogpeppe: very easy to overdo it, but as they suggest - watch your breathing
<rogpeppe> http://www.c25k.com/
<rogpeppe> which is very good for not overdoing it
<dimitern> rogpeppe: cool! I can use something handy like that
<dimitern> 10x
<rogpeppe> right, that's me for the night
<rogpeppe> dimitern: see ya monday
<rogpeppe> g'night all!
<dimitern> happy weekend :)
<dimitern> mgz: ping
<mgz> dimitern:  hey
<dimitern> mgz: so you think is LGTM, assuming I complete rogpeppe's suggestion?
<mgz> I'll leave some kind of comment to that effect, yeah
<dimitern> thanks
<davecheney> the 1.9.8 packages are in the gophers PPA
<davecheney> if anyone feels like testing them before I hit the send button on the announcement
<davecheney> that would be helpful
<hazmat> davecheney, isn't terminate-machines implemented (ic destroy-machine) in revno876
<hazmat> davecheney, it would be good to tag release revnos (via bzr tag)
<hazmat> davecheney, there's some useful tools for releng management in landscape-devel  .. moving unclosed bugs to next milestone, etc
<davecheney> hazmat: well that sucks
<davecheney> i did remind people who were merging features on friday to update the release notes
<davecheney> consider it a bonus
<davecheney> hazmat: ta, haven't needed them recently because mostof the development is being tracked in leankit
<davecheney> but *hopefully* now this is a public release, we'll get lots of wonderful feedback
#juju-dev 2014-02-03
<rogpeppe2> mornin' all
<rogpeppe> can anyone else bootstrap the local environment using trunk?
<rogpeppe> i get "restart: Unknown job: rsyslog" in /home/rog/.juju/local/log/cloud-init-output.log
<rogpeppe> _thumper_: hiya
<_thumper_> oh hai
<rogpeppe> _thumper_: the local provider seems broken for me currently on trunk BTW
<_thumper_> awesome
<rogpeppe> _thumper_: i can't get it to bootstrap at all
<_thumper_> wasn't me
<thumper> how are you bootstrapping?
<rogpeppe> thumper: juju bootstrap -e local --debug
<thumper> that should work
<rogpeppe> thumper: indeed :-)
<thumper> what's the error?
<rogpeppe> thumper: 2014-02-03 14:10:34 ERROR juju.cmd supercommand.go:294 exit status 1
<rogpeppe> :-)
<thumper> that sounds very familiar
<thumper> I think I hit that too
 * thumper thinks
<rogpeppe> thumper: looking in cloud-init-output.log, i see this:
<rogpeppe> restart: Unknown job: rsyslog
<rogpeppe> thumper: which i think is probably the cause
<thumper> wat?
<thumper> you should have rsyslog running
<thumper> it is part of the OS
<thumper> sudo status rsyslog
<rogpeppe> thumper: status: Unknown job: rsyslog
<natefinch> well there's you're problem
<natefinch> your
<thumper> haha
<thumper> rogpeppe: go
<thumper> sudo start rsyslog
<thumper> unknown job
<thumper> ?
<rogpeppe> thumper: yeah
<thumper> do you have rsyslog installed?
<rogpeppe> start: Unknown job: rsyslog
<rogpeppe> thumper: yes
<rogpeppe> thumper: and there's a /etc/rsyslog.d directory
<rogpeppe> thumper: containing a 25-juju-rog-local.conf file
<thumper> rogpeppe: is there /etc/init/rsyslog.conf?
<rogpeppe> thumper: yes
<thumper> plz run rsyslog
<thumper> sudo start rsyslog
<rogpeppe> thumper: that doesn't work, as i pasted above
<thumper> um...
<thumper> bollocks
<thumper> it is lying
<rogpeppe> thumper: i could try running rsyslogd directly, i suppose
<thumper> I wouldn't
<thumper> upstart should start it
<thumper> actually
<thumper> yes
<thumper> run it manually
<thumper> if it is failing to start, it should tell you why
<thumper> but rsyslog should be running
<rogpeppe> thumper: rsyslogd is already running
<thumper> but upstart doesn't think so?
<thumper> that's problematic
<rogpeppe> thumper: initctl --list doesn't list it
<rogpeppe> thumper: but service --status-all does
<thumper> you need help from someone that understands
 * rogpeppe doesn't know how initctl (upstart) and service interact
<thumper> the fundamental problem is that "sudo restart rsyslog" fails
<rogpeppe> thumper: yeah
 * rogpeppe straces start rsyslog
<rogpeppe> i suppose it might just be trusty brokenness
<natefinch> rogpeppe: works for me on trusty, but maybe there's something else going on
<rogpeppe> ha, this is interesting:
<rogpeppe> % sudo initctl --system start rsyslog
<rogpeppe> initctl: Job is already running: rsyslog
<rogpeppe> % sudo initctl start rsyslog
<rogpeppe> initctl: Unknown job: rsyslog
<natefinch> *twilight zone music*
<rogpeppe> "initctl --system list" prints loads more jobs
<rogpeppe> i wonder what the default, without --system, is doing
<rogpeppe> perhaps i've got two /etc/init instances running
<rogpeppe> hmm, i have
<rogpeppe> /sbin/init and init --user
<rogpeppe> i bet that's the issue here
<rogpeppe> the init --user is started by lightdm, whatever that is
 * rogpeppe googles it
<rogpeppe> i wonder if it's related to this: http://lwn.net/Articles/547422/
<rogpeppe> natefinch: have you also got an "init --user" process running?
<natefinch> rogpeppe:  looking
<natefinch> rogpeppe: how can I see what the actually command line was?
<rogpeppe> natefinch: i did "ps alxw | grep init"
<natefinch> rogpeppe: yep, I have both
<rogpeppe> natefinch: hmm, and "initctl list" and "initctl --system list" print the same thing for you?
<natefinch> rogpeppe: the --system one lists a hell of a lot more, if that's what you mean
<rogpeppe> natefinch: right
<rogpeppe> natefinch: what's the output of "initctl list" for you?
<natefinch> rogpeppe: http://pastebin.ubuntu.com/6867463/
<rogpeppe> natefinch: and "initctl start rsyslog" works for you?
<rogpeppe> natefinch: sorry, sudo initctl start rsyslog, of course
<natefinch> rogpeppe:  I was gonna say, not without sudo.... yes, with sudo it works fine
<rogpeppe> natefinch: weird
<rogpeppe> natefinch: what's the output of "sudo strace initctl start rsyslog" for you?
<natefinch> rogpeppe: http://pastebin.ubuntu.com/6867473/
<rogpeppe> natefinch: thanks
<natefinch> rogpeppe: welcome.  Gotta step away from the keyboard for a bit.
<rogpeppe> natefinch: k
<rogpeppe> natefinch: interesting, yours is opening a different unix socket from mine
<rogpeppe> natefinch: yours opens /com/ubuntu/upstart; mine opens /com/ubuntu/upstart-session/1000/3730
<rogpeppe> natefinch: issue solved
<rogpeppe> local environment bootstrapped, phew
 * rogpeppe gets lunch
<rogpeppe> natefinch: does the local provider work for you (on tip) ?
<rogpeppe> natefinch: i can bootstrap, but not call juju status after that
<natefinch> rogpeppe:  lemme try
<rogpeppe> natefinch: thanks
<natefinch> rogpeppe: ug, annoying.... evidently we now have a check to make sure mongod is in /usr/bin/mongod?  That's not where my mongo is :/
<rogpeppe> natefinch: ha ha
<natefinch> rogpeppe: I can symlink it, but still, annoying
<rogpeppe> natefinch: does it work if you symlink it
<rogpeppe> ?
<natefinch> rogpeppe: we'll see
<natefinch> rogpeppe: sonofa.... man, we gotta fix the local provider.  It's so so so configuration specific.  I forgot it always has problems building jujud because root doesn't have go in its path
<rogpeppe> natefinch: you shouldn't run it with sudo now
<natefinch> rogpeppe: tried that first - ERROR juju supercommand.go:282 bootstrapping a local environment must be done as root
<rogpeppe> natefinch: what revision are you using?
<natefinch> rogpeppe: tip.. just pulled and everything
<rogpeppe> natefinch: i suspect you haven't go installed everything
<rogpeppe> natefinch: because on my machine (rev 2291) it works ok
<natefinch> rogpeppe: what besides juju do I need to go install?
<natefinch> cmd/juju tha tis
<rogpeppe> natefinch: i generally do go install ./cmd/...
<rogpeppe> natefinch: or everything
<natefinch> rogpeppe: ok, good to know
<natefinch> rogpeppe: that'll probably fix the "can't build jujud" thing
<rogpeppe> natefinch: maybe
<rogpeppe> natefinch: the local provider has a very weird way of finding jujud
<rogpeppe> natefinch: it finds juju and then looks in the same directory as that for jujud
<rogpeppe> natefinch: so unless they're in the same directory, it won't work
<natefinch> rogpeppe: yeah that fixed the "need sudo" problem and thus it was able to build jujud, even though it shouldn't have needed to, since it's in the path
<natefinch> rogpeppe: spoke too soon... still ends with needs root
<rogpeppe> natefinch: so... can you run "juju status" successfully now?
<natefinch> rogpeppe: I can't bootstrap still
<rogpeppe> natefinch: are you absolutely sure you're running the right juju binary? (perhaps put a logger.Infof in localEnviron.Bootstrap to make sure)
<rogpeppe> natefinch: in the code i see, it calls ensureNotRoot to make sure that you are not running as root
<natefinch> rogpeppe: ahh, no, there's a juju in /bin/juju somehow
<rogpeppe> natefinch: right
<natefinch> rogpeppe: I don't know how that got there
<rogpeppe> natefinch: when was it created?
<rogpeppe> natefinch: hmm, /bin, not /usr/bin ?
<natefinch> rogpeppe: yeah, just /bin/juju  .... created Dec 5th
<rogpeppe> natefinch: weird.
<natefinch> yep
<rogpeppe> natefinch: well, remove it :-)
<natefinch> wtf?  Why is bash still trying to run juju from /bin/juju if which juju returns $GOPATH/bin/juju?
<rogpeppe> natefinch: run hash -r
<rogpeppe> natefinch: it's an ancient (and fucked up) shell misfeature
<natefinch> rogpeppe: yeah, I just made a new terminal and it's fine
<rogpeppe> natefinch: and the source of endless wtfs in the past
<rogpeppe> natefinch: it's a premature optimisation
<natefinch> man, that is dumb
<natefinch> rogpeppe: I mean, I get it, but.... yeah
<rogpeppe> natefinch: blame csh back in the 80s
<natefinch> rog ERROR juju.cmd supercommand.go:294 Get http://10.0.3.1:8040/provider-state: dial tcp 10.0.3.1:8040: connection refused
<rogpeppe> natefinch: you're best deleting any existing stuff. rm -r ~/.juju/environments/local.jenv ~/.juju/local
<rogpeppe> natefinch: that behaviour will get better, hopefully
<rogpeppe> natefinch: axw has a CL waiting
<natefinch> rogpeppe: and finally... it seems to work fine
<natefinch> rogpeppe: juju status that is .... er, agent state is down, hmm
<rogpeppe> natefinch: juju status works ok, not running as root?
<natefinch> rogpeppe: I was too quick for it, now it's up.   Yes, not running as root
<rogpeppe> natefinch: i get this: ERROR failed getting all instances: error executing "lxc-ls": lxc: Permission denied - opendir on lxcpath; Traceback (most recent call last):;   File "/usr/bin/lxc-ls", line 200, in <module>;     for container_name in lxc.list_containers(config_path=lxcpath):;   File "/usr/lib/python3/dist-packages/lxc/__init__.py", line 390, in list_containers;     config_path=config_path); ValueError: failure to list containers
<natefinch> rogpeppe: what happens if you just run lxc-ls?
<rogpeppe> natefinch: yeah, just tried that - that fails too
<natefinch> rogpeppe: that works for me (well, returns with no output, since I have no containers yet)
<rogpeppe> natefinch: it would be wonderful if it actually printed the path in question :-)
<natefinch> rogpeppe: that's one of the things I like best about go... all those type of errors actually include the path
<rogpeppe> natefinch: ah, i guess i've found the reason
<rogpeppe> natefinch: /var/lib/lxc is mode 700
<natefinch> rogpeppe: uhh.... that does seem like a problem :)
<rogpeppe> natefinch: and... now it works
<rogpeppe> natefinch: i wonder how that happened
<natefinch> rogpeppe: actually, mine is also 700
<rogpeppe> natefinch: oh, maybe i shouldn't have chmodded mine then
<rogpeppe> sigh
<rogpeppe> WTFs/minute is running rather high currently
<natefinch> rogpeppe: got a second? I have a question about the simpleworker that you wrote...
<rogpeppe> natefinch: sure
 * rogpeppe tries to remember what "simpleworker" was
<natefinch> rogpeppe:  I can pastbin
<rogpeppe> natefinch: please
<natefinch> rogpeppe: http://pastebin.ubuntu.com/6868675/
<rogpeppe> natefinch: ah yes, i remember now
<rogpeppe> natefinch: it is perhaps a little over-simplistic
<rogpeppe> natefinch: it might need to cache the error, for example
<natefinch> rogpeppe: the kill function, as written, doesn't compile, but I'm not clear on what is supposed to be there
<rogpeppe> natefinch: close(w.stopc)
<natefinch> rogpeppe: ok... I was trying to follow it, but it was all a little too self-referential and relying on the behavior of outside stuff that I didn't understand
<rogpeppe> natefinch: it's just a way of writing a lightweight worker without making a new type
<rogpeppe> natefinch: i should probably have written some comments :-)
<natefinch> rogpeppe: heh...
<rogpeppe> natefinch: this is probably a little better: http://play.golang.org/p/zGQUsdR5Yy
<rogpeppe> natefinch: (it makes both Wait and Kill idempotent)
<natefinch> rogpeppe: so in that code, the fact that done is a channel doesn't really matter, right?  Since nothing is ever sent on it, it just makes Wait() block until done is closed
<rogpeppe> natefinch: that's right
<rogpeppe> natefinch: it's a fairly idiomatic use of a chan struct{}
<natefinch> rogpeppe: yeah. I
<natefinch> rogpeppe: I'm a little confused, because stopc is never used
<natefinch> rogpeppe: I mean, we send it to the function, but we don't send or receive on it ourselves
<rogpeppe> natefinch: that's the point
<rogpeppe> natefinch: the function can use it to find out when it's being stopped
<natefinch> rogpeppe: oh, I see, I missed that we're still closing it.  ok
<rogpeppe> natefinch: and ISTR that the code i pasted to did
<rogpeppe> s/pasted to did/pasted did that/
<natefinch> rogpeppe: yeah.... ok. It's making more sense now.  your new code is a little easier for me to follow
<rogpeppe> natefinch: the comments help, right?
<rogpeppe> natefinch: (the code is actually more complex than it was before)
<natefinch> rogpeppe: I think it was mostly the    w.done <- start(w.stopc)      line of the old code that was confusing me... calling a function passed into this function in a goroutine, passing it a channel and sending what that function returns into another channel....
<natefinch> rogpeppe: cognitively dense
<natefinch> rogpeppe: knowing that I can just ignore the channels except as signaling devices also helped
<rogpeppe> natefinch: good thing we're not using haskell :-)
<natefinch> rogpeppe: I'd be working somewhere else if we did :)
 * rogpeppe finishes for the day
<rogpeppe> natefinch: g'night
<natefinch> rogpeppe: g'night.  Thanks for the help.
#juju-dev 2014-02-04
<axw> waigani: hey. if you didn't notice, your shared storage branch needs fixing as there are merge conflicts
<waigani> thanks axw I'll get onto that now
<wallyworld> axw: standup?
<axw> wallyworld: can you please take a look at https://codereview.appspot.com/57690049/ some time today? should fix the critical issue blocking CI
<wallyworld> sure
<axw> wallyworld: sorry, but can you please poke the bot?
<wallyworld> sure
<thumper> o/
<axw> hey thumper
<axw> how's it going in SA?
 * bigjools enjoyed axw's gwacl bug
<_thumper_> axw: hey
<thumper> axw: going well, but long hours
<thumper> while jet lagged :)
<dimitern> thumper, hey
<thumper> o/ dimitern
<dimitern> thumper, is gustavo with you guys?
<thumper> dimitern: we may try to get you to join us in a hangout later today to talk about network stuff
<thumper> dimitern: he is here, but not in the same room right now
<dimitern> thumper, ok, just ping me
<thumper> dimitern: ack
<thumper> dimitern: are you ok to do it now?
<dimitern> thumper, will it be long?
<dimitern> thumper, i'm just having a bite
<hazmat> dimitern, networking discusssion
<hazmat> https://plus.google.com/hangouts/_/7ecpjkn2k7ch2dhtuqn9h0vrqs?authuser=1&hl=en
<hazmat> dimitern, ping x 5 (five people waiting)
<dimitern> hazmat, coming, 10s
<rogpeppe> dimitern: right, that's better
<rogpeppe> dimitern: i'm guessing it's a fall out from yesterdays DOS
<dimitern> rogpeppe, most likely
<natefinch> rogpeppe, dimitern: standup?
<dimitern> natefinch, sorry, coming
<rogpeppe> lunch
<rogpeppe> natefinch: when you have a moment, let me know, and we'll have that chat
<natefinch> rogpeppe: cool, how about in 45 mins?
<rogpeppe> natefinch: sounds good
<rogpeppe> natefinch: hangout?
<natefinch> rogpeppe: yep - https://plus.google.com/hangouts/_/7ecpjraogrb319ail5kfegr8og?authuser=2&hl=en
<rogpeppe> natefinch: one mo, gimme a minute while this tools upload finishes
<rogpeppe> natefinch: no point in sharing the bandwidth
<natefinch> rogpeppe: no problem
<rogpeppe> natefinch: apparently i am not allowed to join that video call
<natefinch> rogpeppe: think I did it through my canonical account, I'll redo it through non-canonical
<natefinch> rogpeppe:  https://plus.google.com/hangouts/_/7ecpjepb36cm6ooihhaqn5b8jk?hl=en
<rogpeppe> natefinch: it's weird that it doesn't give you the capability to change user
<bac> hi marcoceppi_ are you around this week?
<marcoceppi_> bac: I'm in brussels right now, I'll be flying home tomorrow afternoon
<bac> marcoceppi_: ok, will talk later then.  have a good time1
<bac> s/1/!/
<natefinch> rogpeppe: where's that plugin of yours that does go to definition for methods?
<rogpeppe> natefinch: http://godoc.org/code.google.com/p/rog-go/exp/cmd/godef
<rogpeppe> natefinch: most of the functionality is implemented by code.google.com/p/rog-go/exp/go/types
<natefinch> rogpeppe: how stable is go types at this point?
<rogpeppe> natefinch: the go.tools package?
<rogpeppe> natefinch: (note that the one i mentioned above is no relation of code.google.com/p/go.tools/go/types
<natefinch> rogpeppe: sorry, reading fail.... I thought the second line referenced the go tools go/types package... nevermind
<rogpeppe> )
<natefinch> rogpeppe: that's what I get for only looking at the beginning and end of the URL ;)
<rogpeppe> natefinch: the main unfortunate thing about the godef command is that it's based on an ancient fork of go/parser and friends
<rogpeppe> natefinch: so there are a few things that it doesn't do. but it works for me 98% of the time
<natefinch> rogpeppe: that's cool.  That's better than the 0% I get with methods :)
<rogpeppe> natefinch: here's an example of a vim plugin using it: https://github.com/dgryski/vim-godef
<rogpeppe> natefinch: and this post describes the emacs go-mode that uses it: http://dominik.honnef.co/posts/2013/03/writing_go_in_emacs/
<natefinch> rogpeppe:  nice.  yeah, I think it'll be trivial to make it work for sublime text.
<rogpeppe> natefinch: cool
<rogpeppe> i'm done. g'night all.
#juju-dev 2014-02-05
<axw> wallyworld_:  I think the bot might need a poke again? waigani 's branch looks stuck (https://code.launchpad.net/~waigani/juju-core/expand-config-variable-names/+merge/204412)
<wallyworld_> ok
<axw> and my MP is attached to the bug here: https://bugs.launchpad.net/gwacl/+bug/1276019
<_mup_> Bug #1276019: 307s are not followed other than for GET/HEAD, and headers are dropped from those <Go Windows Azure Client Library:In Progress by axwalk> <https://launchpad.net/bugs/1276019>
<wallyworld_> axw: bot seems ok actually
<axw> hm ok
<wallyworld_> it's running a test now
<wallyworld_> axw: ah error
<wallyworld_> erging https://code.launchpad.net/~waigani/juju-core/expand-config-variable-names into https://code.launchpad.net/~go-bot/juju-core/trunk would be pointless
<axw> ah. 6 hours just seemed like a long time :)
<axw> oh
<wallyworld_> so there's a problem with the branch
<wallyworld_> it could be that trunk already has the changes
<wallyworld_> yes
<wallyworld_> it does
<axw> okey dokey
<wallyworld_> so i'd say another merge accidentally has these changes in it
<wallyworld_> i set the mp to merged
<axw> wallyworld_: FYI, I have Thursday/Friday off
<wallyworld_> lucky bugger
<wallyworld_> enjoy
<axw> ta :)
<axw> wallyworld_: I have pushed another change to the gwacl MP. Tested live - works better now.
<wallyworld_> ok, looking
<wallyworld_> axw: to be consistent and simplify the code, should we always just check the response code and avoid needed to return a httpredirect error for some calls and not others
<axw> wallyworld_: the error must be returned to prevent net/http from following redirects at all
<wallyworld_> ah right
<wallyworld_> in that case, looks good
<axw> cheers
<hazmat> axw, out of curiosity, what do you think about add-machine ssh: supporting instance id on the cli?
<axw> hazmat: yeah, could be useful for manually provisioning into existing environments, e.g. on ec2
<axw> so the instance becomes managed by juju
<hazmat> i'm writing a cli plugin, and could avoid the use of the api entirely, if i could just set the instance id i could just use the cli.
<hazmat> its mostly so i can correlate directly back to the underlying provider instance easily without doing ip addr matching.
<axw> right
<axw> I think it would have to be encoded into the address somehow
<axw> to avoid further special casing of add-machine
<hazmat> axw, ssh:user@ipaddress:instance_id ?
<axw> we might want : for non-standard ssh ports later. I'd say something like / or =
<axw> but anyway, yeah it could work
<hazmat> sounds good, i'll file a bug
<davecheney> axw: i was thinking about what could be done to make the gccgo detection work
<davecheney> it would be abomonation, but could proabably be done
<axw> davecheney: yup. I was thinking the same thing, i.e. a known caller name
<axw> I wouldn't bother changing it now though, maybe if it needs to be changed again...
<davecheney> axw: i think we're goig to be flapping between 4.8 and 4.9 for some time
<davecheney> it might be worth the effort to gold plate it
<axw> heh ok :)
<davecheney> axw: it might also be possible to cheat
<davecheney> gccgo 4.8 implements go 1.1
<davecheney> maybe I can use a +build tag
<axw> 1.1? :(
<axw> I thought we had moved to 1.2 now
<davecheney> gccgo 4.8 implements the 1.1 spec
<rogpeppe> davecheney, axw: mornin'
<axw> morning rogpeppe
<dimitern> morning all
<dimitern> rogpeppe, i have some questions re goamz, and since gustavo is not around, do you have some time?
<rogpeppe> dimitern: sure
<dimitern> rogpeppe, so, i've tried (hard) yesterday to construct a sophisticated multi-part test that runs both on the test double and live
<dimitern> rogpeppe, but i've run into issues like eventual consistency and such (i.e. i'd really like to have something similar to Long/ShortAttempt in goamz)
<rogpeppe> dimitern: i think goamz already has the attempt stuff in
<dimitern> rogpeppe, am I to take from this such tests are not needed inside goamz itself, but just simpler ones that focus on response parsing is ok etc.
<rogpeppe> dimitern: yeah, aws.AttemptStrategy
<dimitern> rogpeppe, ah, I've missed that
<dimitern> rogpeppe, also i found the ec2test package a bit inflexible
<dimitern> rogpeppe, i.e. you cannot easily setup the same case and make sure it'll run the same on both local and live servers
<rogpeppe> dimitern: yeah, it was as simple as i could come up with
<rogpeppe> dimitern: i'm not sure what you mean by that though
<dimitern> rogpeppe, like state changes over time in instances / other entities
<rogpeppe> dimitern: there are quite a few existing tests that work both live and against ec2test
<dimitern> rogpeppe, there's an SetInitialInstanceState
<dimitern> rogpeppe, yeah, and I've done mine similarly, but for more complex cases it's much too difficult
<rogpeppe> dimitern: what would you like to be able to do?
<dimitern> rogpeppe, like "i need to test network interface ops", but for that i need: 1) a vpc, 2) a subnet, 3) a *running* instance in that subnet, 4) a security group for that vpc, 5) the net interface itself
<dimitern> rogpeppe, i.e. the set up is heavy, slow when run live and not very reliable
<rogpeppe> dimitern: i think that it's going to be hard to have ec2test actually run a live instance
<dimitern> rogpeppe, apart from errors due to my assumptions, sometimes i get errors like "503 unavailable" or some random error
<rogpeppe> dimitern: and the heavy & slow setup applies to ec2 live tests, not ec2test, right?
<dimitern> rogpeppe, so it's best to separate the local and live test cases for more complex scenarios
<rogpeppe> dimitern: and the reliability problems too, i'd guess
<dimitern> rogpeppe, 2x yep
<rogpeppe> dimitern: why do you need a running instance?
<dimitern> rogpeppe, because you can't attach a NIC on a instance that's not in running state
<dimitern> rogpeppe, unless you've done it at runinstances time, but that's another test
<rogpeppe> dimitern: ok, so you don't actually need it to be running something, just for it to report the state as running
<dimitern> rogpeppe, yes
<rogpeppe> dimitern: i'm not sure that particular case matters too much to test. is it that important to check all error states?
<dimitern> rogpeppe, take a look at what i've came up with after several hours of trial-and-frustration yesterday: http://paste.ubuntu.com/6877862/
<rogpeppe> dimitern: BTW it's good to at least have the live tests, because then you get to know just how it's likely to fail for real
<dimitern> it's not ready yet, i'll split it up, etc. but it works 60% of the time up to the last Check() which fails with "NIC cannot be deleted because it's in use" (but got detached ok)
<rogpeppe> dimitern: presumably you'll need to do a retry loop around the DeleteNetworkInterface call
<rogpeppe> dimitern: i'm still not quite seeing how the ec2test package isn't flexible enough for your needs here
<rogpeppe> dimitern: ISTM that the real difficulty is writing reliable live tests
<dimitern> rogpeppe, yes, but i was too tired yesterday already - i'll also replace my jury rigged loop with attemptstrategy if possible
<dimitern> rogpeppe, isn't because it's not simulating the "eventual consistency" of certain features
<dimitern> rogpeppe, like "make the instance state change slowly" or "do not delete X immediately, but say you did, and report it in use for some time after"
<rogpeppe> dimitern: it's true, it doesn't, because it's hard to see how to get it right. but surely your tests will work ok if ec2test is always consistent?
<davecheney> rogpeppe: morning -- sorry, missed your thinggy
<rogpeppe> davecheney: hiya
<dimitern> rogpeppe, yes, I started with a far easier test that worked on ec2test like charm
<dimitern> rogpeppe, the problem was to achieve the same live using the same steps, which turned into this
<rogpeppe> dimitern: i don't see why ec2test is making things harder here
<rogpeppe> s/why/how/
<rogpeppe> dimitern: BTW, rather than polling by calling Instances repeatedly, might it not be better to just call CreateNetworkInterface repeatedly until it doesn't return the expected error?
<rogpeppe> dimitern: then you won't need to worry about the fact that ec2test instances don't transition to running state
<dimitern> rogpeppe, that's a good point, thanks
<dimitern> rogpeppe, and then there are 2 more things i've been wondering about
<dimitern> rogpeppe, 1) how detailed should be the tests checking for errors (i.e. how good the ec2test package should simulate all cases)
<rogpeppe> dimitern: it's not that important
<dimitern> rogpeppe, and 2) right now goamz uses a fairly outdated api version - 2011-12-15, but some features we need are in later versions
<dimitern> rogpeppe, should we support mixed versions?
<rogpeppe> dimitern: ec2test is a test double for the ec2 provider - it doesn't need to simulate all errors; getting the happy path right is what we've done so far
<rogpeppe> dimitern: i think we should use the earliest version that supports the features we need
<rogpeppe> dimitern: or... perhaps just update the whole thing to use the latest version
<rogpeppe> dimitern: there might not actually be too much in the way of changes
<dimitern> rogpeppe, upgrading everything is less than trivial
<dimitern> rogpeppe, but perhaps worth it
<rogpeppe> dimitern: yeah, i'm not entirely sure.
<rogpeppe> dimitern: the version is per-request though, right?
<dimitern> rogpeppe, right
<dimitern> rogpeppe, so far the least intrusive approach would be to change the version only for the new calls and only for the old ones if it's unavoidable
<rogpeppe> dimitern: yeah, i think that's a good approach to start with
<dimitern> rogpeppe, how about supporting different filters in ec2test?
<rogpeppe> dimitern: is there a problem with just adding the new filters?
<dimitern> rogpeppe, some are quite broad, like 25 cases
<dimitern> rogpeppe, so ec2test should support all filters for the new entities
<rogpeppe> dimitern: ec2test does not have to support everything, but it should support the things that are being used
<dimitern> rogpeppe, by whom?
<rogpeppe> dimitern: by your live test and by provider/ec2
<dimitern> rogpeppe, yep, but on one hand i'm not sure what we'll need in the provider, on the other - it's a generic library after all and it has other users that might benefit from fuller implementation
<rogpeppe> dimitern: i'd err on the "do less" side to start with
<rogpeppe> dimitern: that's been my approach since the start - the amazon API is much larger than we need to entirely support
<dimitern> rogpeppe, ok then, i'll try to be minimalistic in the implementation :)
<rogpeppe> dimitern: so, pending actual code in the provider that uses the stuff, i'd just add the functionality in ec2test that's needed by the live tests, so that they can run on ec2test as well as live
<rogpeppe> dimitern: that's always a good thing in my book :-)
<dimitern> rogpeppe, :) ok, thanks for the suggestions
<rogpeppe> dimitern: np
<dimitern> rogpeppe, can you take a look at this please? https://codereview.appspot.com/49930045/ re what we just discussed
<dimitern> (i.e. could it be simplified)
<rogpeppe> dimitern: looking
<mgz> standup all?
<natefinch> dimitern, rogpeppe: standup?
<mgz> totally forgot to mention in standup, landing bot will be down shortly, I'll give you guys a heads up when it's online again
<jam> mgz: poke, i'd like to tweak some of the bot stuff, but I'd appreciate your help
<mgz> jam: sure, remember it's all going down in ~15 mins
<jam> mgz: sorry about the delay. I'd like to see us add "go test -test.timeout 2m" to the test suite, so that instead of getting the 10m test-took-too-long, we'll get a panic if any individual test takes more than 2min
<jam> we shouldn't take longer than that for a test we're writing anyway
<jam> and it might help us debug WTF for the provisioner
<mgz> jam: that sounds reasonable
<jam> mgz: good. I just saw the "maintenance starting now" which reminded me I wanted to poke you about the bot for when it comes back up
<jam> we need to change that stuff in the juju conf, otherwise the bot will overwrite it all when it comes up
<mgz> we can just set the tarmac-conf value when we have the state server back, right?
<jam> mgz: well, and deal with any fallout of stuff that didn't actually get put into conf properly.
<jam> but we have to do that anyway
<dimitern> mgz, hey, i've just updated all the CLs and proposed the NIC one: 1 https://codereview.appspot.com/49930045/ 2 https://codereview.appspot.com/54690048/ 3 https://codereview.appspot.com/54570048/
<dimitern> rogpeppe, ^^ if you can take a look as well would be nice
<rogpeppe> dimitern: will do
<mgz> dimitern: thanks
<rogpeppe> dimitern: you've got one review
<dimitern> rogpeppe, cheers!
<dimitern> rogpeppe, the "you" phrasing is copied from aws docs :)
<rogpeppe> dimitern: yeah, but it's not idiomatic in the goamz docs (no other occurrences of "You" AFAICS)
<dimitern> rogpeppe, sure, thanks for spotting
<rogpeppe> dimitern: you've got another review
<dimitern> rogpeppe, ta
<rogpeppe> dimitern: all reviewed :-)
<dimitern> rogpeppe, tyvm!
<rogpeppe> dimitern: thanks for all that work
<dimitern> rogpeppe, there's even more coming :)
<rogpeppe> dimitern: presumably the live tests pass?
<dimitern> rogpeppe, but i'm fast now, it should be easier
<dimitern> rogpeppe, yep, ran them several times in a row
<rogpeppe> dimitern: cool
<mgz> what's a safe way to stop and restart jujud on a state server?
<natefinch> mgz: sudo restart juju possibly?
<mgz> jujud-machine-0 it seems
<natefinch> rogpeppe: is there a way to compile all regular and test code at the same time, but not run the tests?
<natefinch> (or if anyone else knows)
<rogpeppe> natefinch: go test -c
<rogpeppe> natefinch: except that unfortunately you can't run "go test -c ./..."
<natefinch> rogpeppe: Tried that, but it does't work across packages, though.  I want go test ./... -c
<natefinch> right
<rogpeppe> natefinch: i have a script that does that
<rogpeppe> natefinch: i call it "gotest-c"
<natefinch> rogpeppe: nice
<rogpeppe> natefinch: http://paste.ubuntu.com/6879643/
<rogpeppe> natefinch: i should probably change it to use bash so other people can use it :-)
<natefinch> rogpeppe: haha yeah I was thinking that
<rogpeppe> natefinch: you can get pxargs with go get code.google.com/p/rog-go/cmd/pxargs
<rogpeppe> natefinch: (it's similar to xargs except runs commands in parallel)
<rogpeppe> natefinch: http://paste.ubuntu.com/6879677/
<mgz> hm, so the real issue is I can't get the juju-db service to stick, comes up with no error, nothing in upstart log, but no mongodb process survives
<mgz> probably just the out of disk thing, will restart and watch syslog more closely
<jam> mgz: this is the tarmac machine-0? (vs the actual tarmac machine-1 that runs the bot?)
<mgz> yeah, playing with machine-0
<mgz> looks in better state at attempt #2
<mgz> hm, I say that, it's spamming machine-0.log still
<mgz> well, that sucked
<mgz> had to manually fix the provider-state file, and clean up spammed out logs for disk space
<mgz> logging ever 2s a state connection can't be made is pretty disk filling too
<rogpeppe> lunch
<jam> have a good night, we're heading off to dinner
<rogpeppe> dimitern: does this look reasonable to you? http://paste.ubuntu.com/6880125/
<rogpeppe> dimitern: i'm trying to check if a field is either false or not present
<rogpeppe> dimitern: (the hasvote clause)
<rogpeppe> dimitern: but it doesn't appear to be working
<dimitern> rogpeppe, shouldn't it be more like {"$or", []D{{{"hasvote", D{{"$ne", true}}}}}} ?
<rogpeppe> dimitern: ah, that's a much better idea
<rogpeppe> dimitern: (and no need for the $or then)
<rogpeppe> dimitern: solved, thanks!
 * rogpeppe feels a bit stupid :-)
<dimitern> rogpeppe, ;) np
<natefinch> Man that mgo code kills me
<rogpeppe> natefinch: it's the subtle distinctions between maps and arrays that i always forget
<rogpeppe> dimitern, natefinch: fairly trivial review? https://codereview.appspot.com/50590045/
<rogpeppe> dimitern, natefinch: and an even more trivial one: https://codereview.appspot.com/54690051
<dimitern> rogpeppe, looking at both in order
<rogpeppe> dimitern: thanks!
<natefinch> rogpeppe: looking at both in reverse order
<dimitern> rogpeppe, both reviewed
<rogpeppe> dimitern: thanks a lot
<rogpeppe> dimitern, natefinch: and one last one, also trivial: https://codereview.appspot.com/59740049
<dimitern> rogpeppe, LGTM
<rogpeppe> dimitern:
<rogpeppe> dimitern: ta!
<rogpeppe> oh dear, the gobot seems to be broken
<rogpeppe> flag provided but not defined: -test.timeout
<rogpeppe> mgz: do you know why that was changed?
<mgz> jam asked earlier
<mgz> I'll get back to fixing it if I manage to recover juju, which is pretty severly borked
<rogpeppe> mgz: ok, thanks
<rogpeppe> i'm done for the day. g'night all.
<mgz> night!
<natefinch> rogpeppe: g'night
<mgz> okay, I might have un-stuck it
<mgz> but we're kind of in a bad spot
<mgz> the juju version for the landing bot is still 1.11.0 and because of all the tools and config changes, it actually not upgradable
<mgz> or at least, I'd need to refer back to each old version to find the correct tools config to pass both client and remote side lookup of tools, then walk it up the versions
<mgz> which... I don't want to do
<natefinch> mgz: can we not just kill it and redeploy with a new juju?
<mgz> natefinch: I think that would be the sanest option, but the tarmac charm needs work first
<natefinch> mgz: so is this because we didn't keep up with upgrades, or what?  What do we expect users to do in this situation?
<mgz> roll over and die I think...
<natefinch> mgz: that seems to not be the most user friendly decision... :/
<mgz> seriously though, we should probably make sure any one who runs juju for semi-production stuff does an upgrade at each major version
<mgz> though we should be less churny than we were last year
<mgz> going through three config settings and a bunch of different layouts for tools stuff was pretty nuts
<natefinch> mgz: we really just need to review our upgrade story.... there's no reason you shouldn't be able to upgrade directly from 1.11 to 1.17 (or whatever).  You just run the code that does 1.11->1.12, then run the code that does 1.12->1.13, etc (or whatever... I know we do that wacky even odd thing)
#juju-dev 2014-02-06
<sparkiegeek> hi, if I SetAnnotations with a Tag pointing at unit X and then juju destroy-unit X, it seems the annotation "survives". Is that expected?
<sparkiegeek> my expectation was that the annotation would die along with the unit
<sparkiegeek> but it seems immortal :)
<dimitern> sparkiegeek, annotations are kept in a separate mongo collection, but it should be indeed removed when the unit is destroyed
<dimitern> sparkiegeek, there's code for that, and if the unit's not in state anymore this is a bug worth reporting
<sparkiegeek> dimitern: what do you mean by  "unit's not in state"?
<dimitern> sparkiegeek, i mean can you access the unit somehow or it reports not found?
<dimitern> (does it show up somewhere, perhaps with an error in status?)
<sparkiegeek> dimitern: doesn't show anywhere. I'll file a bug?
<dimitern> sparkiegeek, thanks!
<sparkiegeek> dimitern: https://bugs.launchpad.net/juju-core/+bug/1276976 for reference
<_mup_> Bug #1276976: Juju annotations are immortal <landscape> <juju-core:New> <https://launchpad.net/bugs/1276976>
<dimitern> sparkiegeek, cheers :)
<mgz> rogpeppe: (and anyone else around) weekly standup?
<rogpeppe> mgz: thanks
<mattyw> rogpeppe, would you have a moment now or later to discuss the api and juju destroy-environment?
<rogpeppe> in a call right now, but in a little bit, sure
<rogpeppe> mattyw: ^
<mattyw> rogpeppe, ok cool
<mattyw> rogpeppe, thanks
<rogpeppe> mattyw: just finished
<rogpeppe> mattyw: hangout?
<rogpeppe> mgz, dimitern, natefinch: review of these fixes to juju restore would be appreciated: https://codereview.appspot.com/60580043
<mgz> rogpeppe: sure
<dimitern> rogpeppe, looking
<rogpeppe> mgz, dimitern: thanks
<rogpeppe> mgz, dimitern: i just verified it live, BTW
<dimitern> rogpeppe, reviewed
<dimitern> rogpeppe, can you look at this? https://codereview.appspot.com/59620043/
<rogpeppe> dimitern: thanks, will do
<rogpeppe> dimitern: i don't quite understand how TestInstanceInfo ever passed
<rogpeppe> dimitern: was a branch pushed without running the tests, do you think?
<dimitern> rogpeppe, there's some trickery with initially setting the dns name
<dimitern> rogpeppe, that's likely yes
<rogpeppe> dimitern: ah yes, looks like i am the culprit, oops
<dimitern> rogpeppe, ;)
<rogpeppe> dimitern: LGTM, and i'd suggest that you could submit it now, as it fixes trunk
<dimitern> rogpeppe, I don't have rights to submit it
<rogpeppe> dimitern: ok, i could probably do that
<dimitern> rogpeppe, wait!
<dimitern> rogpeppe, won't that screw up my whole pipeline?
<rogpeppe> dimitern: how so?
<dimitern> rogpeppe, well, this is the first CL, and the others depend on it
<dimitern> rogpeppe, if you land it how can i land the rest?
<dimitern> rogpeppe, hmm.. I suppose we can set it to Merged once you land it
<rogpeppe> dimitern: are you using bzr pipelines?
<dimitern> rogpeppe, and ohh.. there's no bot to check the order, so it should be fine
<rogpeppe> dimitern: yeah, i don't think there should be a problem
<dimitern> rogpeppe, yep, they are indispensable!
<dimitern> rogpeppe, esp. with the case of goamz where the trunk rarely changes, so I can line up a whole bunch of related pipes and don't care about making it too long and having to merge trunk all the way
<rogpeppe> dimitern: yeah
<adeuring> could somebody please have a look here: https://codereview.appspot.com/60630043
<natefinch> adeuring: reviewed
<adeuring> natefinch: thanks
<natefinch> adeuring: np
<dimitern> rogpeppe, https://codereview.appspot.com/60620043 - last CL so far, if you can take a look
<dimitern> mgz, ^^
<rogpeppe> dimitern: looking
<dimitern> rogpeppe, mgz, also I'd appreciate one last look at the previous CLs, after I changed the live tests to be more resilient: https://codereview.appspot.com/49930045/  https://codereview.appspot.com/54690048/  https://codereview.appspot.com/54570048/
<dimitern> rogpeppe, cheers!
<mgz> dimitern: I'll go through the series again now
<dimitern> mgz, thanks
<dimitern> mgz, rogpeppe, final one, I promise :) - it's simpler than the rest https://codereview.appspot.com/54210047/
<mgz> dimitern: :)
<marcoceppi> can anyone answer questions about juju set-env and ssh keys?
<dimitern> marcoceppi, there's an authorized keys plugin to manage ssh keys now
<marcoceppi> dimitern: ohohoh! link?
<dimitern> marcoceppi, sorry, it's not a plugin, it's a command: juju authorized-keys
<marcoceppi> dimitern: amazing, thank you
<dimitern> marcoceppi, http://paste.ubuntu.com/6886194/
<rogpeppe> 		notify: make(chan struct{}, 1),
<rogpeppe> 	}
<rogpeppe> natefinch: any chance you could propose utils/voyeur as its own CL? i've got a test suite i quite want to use it in
<natefinch> rogpeppe: sure
<rogpeppe> natefinch: oh yes, you wanted another chat about stuff, didn't you
<rogpeppe> natefinch: have you got a moment now?
<natefinch> rogpeppe: yeah
<rogpeppe> natefinch: https://plus.google.com/hangouts/_/calendar/am9obi5tZWluZWxAY2Fub25pY2FsLmNvbQ.mf0d8r5pfb44m16v9b2n5i29ig?authuser=1
<hazmat> anybody know why we install bridge-utils?
<hazmat> for every machine
<natefinch> hazmat: I believe to support networking between lxc containers
<hazmat> natefinch, seems like a bug then.. we should only be installing it when we're using lxc containers.. like we do for lxc itself
<natefinch> hazmat: we install lxc only after you request deploying an lxc container to a machine?
<hazmat> natefinch, yes.. else its just waste of time/space
<natefinch> hazmat:  true.  Then, yes, probably it's a bug, unless there's some other use that we need it for.  Not really my area of expertise.  I know there was some work being done about supporting multiple networks, no idea if that might have something to do with it.
<hazmat> hmm.. looks like the log for 2297 (committed yesterday) has it
<hazmat> maas-specific hack
<hazmat> seems like that should only be installed if provider == maas
<natefinch> hazmat: ahh yeah, the commit message says why it's always installed when lxc isn't... but still should only be done if we're on maas.
<rogpeppe> hazmat: yeah, that's my fault
<rogpeppe> hazmat: but it isn't necessarily a maas-specific hack
<rogpeppe> hatch: (except for the fact that networking between lxc containers only works under maas currently)
<rogpeppe> hazmat: ^
<ahasenack> guys, any idea what's up with this error on 1.16.5? I'm getting it frequently now, to the point I can't bootstrap
<ahasenack> WARNING failed to write bootstrap-verify file: cannot make S3 control bucket: A conflicting conditional operation is currently in progress against this resource. Please try again.
<ahasenack> I trashed all jenv files i could find, then changed my control bucket name, and still can't bootstrap
<ahasenack> this is aws on us-west-2
#juju-dev 2014-02-07
<wallyworld_> ahasenack: i think that's an ec2 issue from what i understand. i got the same error but can bootstrap fine on hp cloud etc.
<wallyworld_> i did do a successful bootstrap just recently on ec2 and then it just stopped working
<ahasenack> my env was bootstrapped, and then juju deploy started to fail with that error
<ahasenack> I then destroyed the environment and then bootstrap started to fail too
<wallyworld_> i'm not sure if there's some place that can be checked for known ec2 outages
<ahasenack> you think it's a s3 outage?
<wallyworld_> it appears so. it's nothing to do with juju in my opinion
<wallyworld_> maybe not an outage per se but an issue outside of juju's control
<ahasenack> wallyworld_: that actually sounds reasonable, I'm trying some s3 operations via aws's console, and they are failing
<wallyworld_> :-(
<wallyworld_> i hope it's fixed soon
<bradm> anyone about who can talk about LP#1241674 ?
<_mup_> Bug #1241674: juju-core broken with OpenStack Havana for tenants with multiple networks <cts-cloud-review> <openstack-provider> <juju-core:Fix Released by gz> <https://launchpad.net/bugs/1241674>
<hazmat> what's the timeout on bootsttrap?
<wallyworld_> hazmat: default 10 minutes but now can be changed
<wallyworld_> if you run trunk
<hazmat> wallyworld_, cool, how? i'm on a crappy net connection, and mongodb times me out.. i'm on trunk
<wallyworld_> let me check
<hazmat> wallyworld_, thanks
<wallyworld_> hazmat: run bootstrap --help
<wallyworld_>     # How long to wait for a connection to the state server.
<wallyworld_>     bootstrap-timeout: 600 # default: 10 minutes
<wallyworld_>     # How long to wait between connection attempts to a state server address.
<wallyworld_>     bootstrap-retry-delay: 5 # default: 5 seconds
<wallyworld_>     # How often to refresh state server addresses from the API server.
<wallyworld_>     bootstrap-addresses-delay: 10 # default: 10 seconds
<wallyworld_> the above go in your env.yaml
<hazmat> wallyworld_, got it thanks.
<bradm> anyone about who can talk about LP#1241674 ?
<_mup_> Bug #1241674: juju-core broken with OpenStack Havana for tenants with multiple networks <cts-cloud-review> <openstack-provider> <juju-core:Fix Released by gz> <https://launchpad.net/bugs/1241674>
<wallyworld_> bradm: mgz  is your best bet
<wallyworld_> bradm: is says fix released - is it now working?
<wallyworld_> not
<bradm> wallyworld_: well, I'm on the verge of testing it, I have an openstack setup deployed using maas that gets that error - but I had some questions about what happens if it does work - ie, will the fix be backported to 1.16, or do we have to wait for 1.18?  and timeframes around that happening
<bradm> wallyworld_: at this rate I should have it tested and confirmed next week
<bradm> wallyworld_: but this is for the new prodstack for Canonical - I can't see us going live with a dev juju for that :)
<wallyworld_> bradm: i personally am hopeful 1.18 will be out real soon now
<wallyworld_> but we may need to consider a backport if 1.18 drags on a bit
<bradm> wallyworld_: if we're talking a couple of weeks, great - if its months, we'll have issues
<wallyworld_> it will be weeks but maybe a few rather than a couple if i had to guess
<wallyworld_> we need to get some critical stuff in place for upgrades and other things before we release
<bradm> right, so if I said a couple to a few weeks, that could be reasonable?
<bradm> we have other things that need to be done too, so this isn't the only blocker
<bradm> just means everything will have to be done using 1.17 until its released
<bradm> fun things like if you reboot a swift storage node, the charm hasn't setup fstab entries so swift doesn't work so well anymore. :)
<wallyworld_> bradm: i'd have to take a closer look at the bugs against 1.18 milestone. i really wouldn't like to guess without more knowledge
<bradm> wallyworld_: ok, but you're thinking weeks rather than months, and if it blows out we could hope for a backport?
<wallyworld_> yes, that is my view :-)
<wallyworld_> if i were king for a day
<bradm> I'll put a comment on the ticket after I've tested all this, and mention our concerns
<wallyworld_> bradm: it depends a bit perhaps on what comes out of the mid-cycle sprint currently underway in SA
<bradm> wallyworld_: there's a lot of people waiting on this openstack setup :-/
<wallyworld_> sure. make sure we are aware and then stuff can be looked at
<wallyworld_> i can imagine. to me it is quite critical
<wallyworld_> but i'm only one voice
<wallyworld_> maybe a backport would be feasible, then that relieves the pressure somewhat
<bradm> yeah, that would be sufficient even.
<bradm> we'll see - I should be able to get final testing done next week, its been a lot of waiting on hardware, and getting that into place
<wallyworld_> ok. let us know how it goes and what you need
<bradm> will do, I pretty much have all the pieces in place now for at least some preliminary testing, so I should know pretty quickly next week if it works
<wallyworld_> good luck :-)
<bradm> thanks.
<hazmat> hmm.. just got a report from a user.. is juju replacing authorized keys on machines? or just augmenting?
<hazmat> their claiming their iaas api provided keys stopped working once juju agents started running on the systems.
<wallyworld_> hazmat: juju augments (appends) to any keys already existing the the ~/.ssh/authorised_keys file
<dimitern> rogpeppe, wallyworld_, mgz, standup
<dimitern> waigani, your connection could be better :)
<adeuring> natefinch: cold you have another look here: https://codereview.appspot.com/60630043 ?
<natefinch> adeuring: sure
<natefinch> adeuring: reviewed.  Thanks for looking into the OS-specific stuff. I just wanted to make sure we were being careful to not be too linux specific.
<adeuring> natefinch: thanks
<natefinch> sweet... now there's 2 waiganis... wonder if we'll end the day with 20 or something
<dimitern> adeuring, just so you know - when you push more revisions after the MP is approved, (i.e. fixing test failures the bot found) you'll need to self-approve it first with a comment, and then mark it as approved again, so the bot will be happy to land it
<adeuring> dimitern: thanks, i really tend to forget the comment ...
<dimitern> adeuring, yep, i did too, but the bot never forgets :)
<adeuring> dimitern: yeah, that's non-human bureaucracy ;)
<rogpeppe> i'm seeing test failures on trunk (running tests on the state package): http://paste.ubuntu.com/6891504/
<rogpeppe> anyone else see the same thing?
<rogpeppe> (i'm seeing it every time currently)
<rogpeppe> dimitern, natefinch, mgz: ^
<mgz> rogpeppe: will see
<dimitern> rogpeppe, i'm pulling trunk to try
<rogpeppe> mgz, dimitern: thanks
<mgz> (cd state&& go test) enouhg?
<rogpeppe> mgz: should be
<dimitern> rogpeppe, OK: 395 passed
<rogpeppe> dimitern: hmm. still fails every time for me
<mgz> I got one of them
<mgz> the second only
<dimitern> rogpeppe, are you sure you have all the deps right? i needed to go get error and do godeps -u, which failed for gwacl (rev tarmac something not found), otherwise all good
<rogpeppe> mgz: ok, that's useful
<mgz> same failure (bar the random port)
<rogpeppe> dimitern: yeah, that was the first thing i did
<rogpeppe> unfortunately i don't get the same failure when running individual suites or tests
<dimitern> rogpeppe, i'm running them now several times to make sure
<dimitern> rogpeppe, i'm running go test -gocheck.v in state/
<dimitern> rogpeppe, what's the panic in relationsuite?
<rogpeppe> hmm, i've just seen another error
<rogpeppe> dimitern: when a fixture setup method fails, gocheck counts it as a panic
<dimitern> rogpeppe, ah, i see
<rogpeppe> this time i got this: http://paste.ubuntu.com/6891545/
<rogpeppe> (ignore the timestamps)
<dimitern> rogpeppe, hm, i got 2 failures on the third run: http://paste.ubuntu.com/6891551/
<rogpeppe> dimitern: ah, that looks like the same thing
<rogpeppe> well at least it's not just me
<mgz> I ayou're just best at hitting the races for some reason rog :)
<dimitern> rogpeppe, it seems mongo couldn't handle the stress
<dimitern> rogpeppe, it's not properly shutting down and cleaning up stuff, or it lags
<rogpeppe> dimitern, mgz: looks like it's a consequence of changes to mgo between rev 240 and now
<rogpeppe> (and there do seem to be some relevant changes there)
<dimitern> rogpeppe, oh yeah? what changes?
<rogpeppe> dimitern: i'm still bisecting
<rogpeppe> dimitern: somewhere between r240 and r243
<dimitern> rogpeppe, how are you bisecting? i haven't used the more advanced vcs forensics like that
<rogpeppe> dimitern: manually :-)
<mgz> ah, interesting
<rogpeppe> dimitern: bzr update -r xxx; go install
<dimitern> rogpeppe, ah :)
<mgz> we took that mgo bump for a gcc fix
<dimitern> rogpeppe, there are commands like bisect (for git or hg i think) that supposedly takes a lot away from the manual checking
<rogpeppe> dimitern: i know, but i can never figure out how to use them well
<mgz> which was trivial, butpresumably picked up a bunch of other things, despite me being conserative with it
<rogpeppe> dimitern: i've started to try
<rogpeppe> dimitern: but never got very far. manual is quite easy anyway
<mgz> r241 looks the most suspect
<rogpeppe> mgz: yup, if my current run fails, that's where the finger points
<rogpeppe> mgz: yeah, that's it
<natefinch> rogpeppe: voyeur code: https://codereview.appspot.com/57700044
<dimitern> rogpeppe, yeah, me too
<mgz> it flat adds a timeout in a bunch of places that had none before
<rogpeppe> mgz: there were later fixes to that code, but i guess they didn't work
<rogpeppe> mgz: i'll try with r248 and see if it still fails
<rogpeppe> natefinch: thanks. looking
<mgz> probably we need to SetTimeout to something longer in the context of our tests
<mgz> 5 seconds should be okay, but is probably pushing it for some of our testing
<rogpeppe> natefinch: reviewed
<rogpeppe> mgz: i'm not quite sure what it's a timeout for anyway
<rogpeppe> pwd
<natefinch> rogpeppe: thanks'
<rogpeppe> mgz: it still fails for me if i change pingDelay to 30 seconds
<rogpeppe> mgz: so that may not be the issue
<mgz> yeah, that was the one that already existed, the new one is syncSocketTimeout
<rogpeppe> mgz: ah, i traced the code wrongly without looking at the diffs. foolish.
<mgz> (pingDelay did get lowered... but seems less impactful anyway)
<rogpeppe> mgz: doesn't look like it was syncSocketTimeout either
<rogpeppe> mgz: (i still see failures when it's 100 seconds)
<mgz> hm, that's no fun.
<rogpeppe> mgz: i'm just experimenting by printing out the deadlines as they're set
<rogpeppe> mgz: hmm, it seems like sometimes the timeout is only 100ms
<rogpeppe> mgz: ha, variously 10m, 100s, 15s and 100ms
<mgz> o_O
<rogpeppe> mgz: ah ha, i think i have it - the initial dial timeout is also used for the socket timeout
<rogpeppe> mgz: and we use 100 milliseconds in TestingDialOpts
<mgz> doh!
<rogpeppe> mgz: it's kind of odd that that value is used for two very different things actually
<rogpeppe> mgz: ha, i was wondering why it was being a little slow to read the file that i'd sent the output of go test to. turned out that wasn't too surprising because it was 271MB!
<rogpeppe> mgz: good thing my editor copes fine with that...
<mgz> I actually managed to make vim choke on a juju log file the other day
<mgz> giant log on a hobbling along m1.tiny... time for less
<rogpeppe> mgz, dimitern, natefinch: simple review for a fix to the above issues: https://codereview.appspot.com/61010043/
<rogpeppe> mgz: doesn't vim store the whole file in memory?
<dimitern> rogpeppe, looking
<dimitern> rogpeppe, no it doesn't - you can open a multigigabyte file almost instantly - emacs does the same :P
<rogpeppe> dimitern: ah, i thought it did, interesting
<rogpeppe> dimitern: presumably it does have to copy the file when opening it though
<dimitern> rogpeppe, reviewed
<rogpeppe> dimitern: thanks
<dimitern> rogpeppe, why copy?
<rogpeppe> dimitern: because there's usually an assumption that if i'm editing a file, i can remove it or move it, and still write it out as it is in the editor buffer
<dimitern> rogpeppe, even if you delete it, the file handle that the editor opened is still readable some time after (perhaps up to the amount that got cached in the kernel)
<rogpeppe> dimitern: and a quick experiment persuades me that vim *does* copy the data (although i can't tell if it's to memory or disk)
<rogpeppe> dimitern: what if you overwrite it?
<dimitern> rogpeppe, the contents will be in the kernel file cache for some time at least
<dimitern> rogpeppe, if you open it again after overwriting you'll see the change
<rogpeppe> dimitern: i just confirmed: vim does not keep the original file open
<dimitern> rogpeppe, hmm good to know
<rogpeppe> dimitern: also, it does look like vim stores everything in memory
<rogpeppe> dimitern: (not that's too much of an issue now, with enormous memories, but worth being aware of)
<dimitern> rogpeppe, perhaps up to certain size
<rogpeppe> dimitern: i'd have thought that 180MB was probably larger than that size
<dimitern> rogpeppe, i doubt you can put 4GB file so quickly in memory, judging by the speed it opens it
<dimitern> rogpeppe, i think it uses memory mapped view of the file, using the kernel file cache
<rogpeppe> dimitern: it doesn't seem to
<rogpeppe> dimitern: but maybe it's different for truly enormous files
<dimitern> rogpeppe, yep
 * dimitern reached eod
<dimitern> happy weekends everyone!
<rogpeppe> dimitern: and you!
<mgz> later dimitern!
<rogpeppe> dimitern: BTW vi definitely seems to read it all into memory, even for GB-sized files
<rogpeppe> that's me for the day
<rogpeppe> g'night all
#juju-dev 2014-02-09
<JoshStrobl> Hey guys, I've been trying to debug my install hook for a while now, changed the set -e to set -x to do line-by-line debugging and aside from the usual running commands not as root (I'm under the impression the charm install hook will run as root to download packages), can't really figure out the issue (juju status states the service agent-state-info: 'hook failed: "install"'. Someone mind taking a look at the script?
<JoshStrobl> http://pastebin.com/MHV91wKQ
<JoshStrobl> charm proof only provides a copyright and maintainer warning, no errors.
<bradm> anyone about?  having troubles trying to generate the juju metadata image data on 1.17.2
#juju-dev 2015-02-02
<davecheney> thumper: waigini: can you give me a review on https://github.com/juju/juju/pull/1516
<davecheney> ta
<axw_> anastasiamac: I don't think I told you before, I'm on leave today
<anastasiamac> axw_: yes i saw :D have fun!
<axw_> thanks, cya tomorrow
<anastasiamac> axw_: sure thing!
<dimitern> morning folks :)
<fwereade> axw_, ping
<anastasiamac> fwereade: axw is off today :D
<fwereade> anastasiamac, thanks
<fwereade> and axw_, don't worry about it, resolved :)
<dimitern> voidspace, o/
<aznashwan> ericsnow: you there?
<eagles0513875> hey dimitern i can confirm thta the version of windows juju is bugged as mac with 1.21 works fine for deployment manually
<eagles0513875> dimitern: im managed just fine to bootstrap manually on mac
<voidspace> dimitern: ah, you're back
<voidspace> dimitern: I got your messages earlier, thanks
<dimitern> eagles0513875, hmm that sounds like a bug, please report it
<dimitern> voidspace, ah, great
<voidspace> dimitern: so there *is* some code in proxyupdateworker that is supposed to change the environment variables
<eagles0513875> dimitern: any chance at getting a 1.21 windows build?
<voidspace> dimitern: I'm changing it to be called unconditionally (it currently tries to only run on first call) and see if that helps
<voidspace> dimitern: and I'm updating the bug as I go...
<dimitern> mgz, ping
<mgz> dimitern: hey!
<dimitern> voidspace, sgtm, thank you!
<dimitern> mgz, any idea about when we'll have a windows release for 1.21 to fix the issues eagles0513875 is having?
<eagles0513875> mgz: basically on windows using manual provider it was complaining about an ssh key and user and in the environments.yaml there was no ssh keys or user variables to provide credentials for
<mgz> wat's the bug #?
<eagles0513875> mgz: havent filed one yet
<eagles0513875> will do it once im home from work
<eagles0513875> cuz i then tried on mac and 1.21 doesnt seem to have this issue
<mgz> is that because it's a mac or because it's 1.21 though? :)
<eagles0513875> dunno tbh
<mgz> ssh is much simpler on unix-like environs
<eagles0513875> mgz: agreed, but there are also windows solutions available but im wondering if its an issue with 1.20 on windows or if there is something in 1.21 which fixes said issue.
<mgz> I can link you a 1.21.1 windows binary
<eagles0513875> want to do a bit more testing before i file a bug to ensure that its actually the version of juju or not
<mgz> eagles0513875: https://launchpad.net/juju-core/+milestone/1.21.1
<eagles0513875> mgz: there is no mention of windows
<eagles0513875> also how do i view juju status on a machine which is already bootstrapped from another laptop do i need to rebootstrap it or there is another way
<eagles0513875> nm i know whats happening
<mgz> that page, under downloads, has a juju-setup-1.21.1.exe
<mgz> use that
<eagles0513875> oh ok
<eagles0513875> mgz: how can i run juju status on a machine which is already bootstrapped
<mgz> eagles0513875: you need the .jenv file from when you did the bootstrap
<mgz> otherwise your client on the other machine doesn't know the keys to talk to the juju state server
<eagles0513875> damn ok.
<mgz> so, you need to copy the ~/.juju/environments/{ENVNAME}.jenv from the laptop
<eagles0513875> that would be useful to have it check if the system has already been bootstrapped
<mgz> if you want to access that environ from another machine
<eagles0513875> wil have to do that later.
<eagles0513875> mgz:  if the system is already bootstrapped cant it recreate it when for example one tries to run juju status it sees if the system has been bootstrapped and creates teh jenv file on the other system which one tries to run juju on?
<eagles0513875> mgz: how can i start contributing code wise?
<mgz> eagles0513875: that would not be secure - you need the credentials, otherwise anyone with the ip address of your machine could take over your juju environment
<mgz> the manual provider is a bit special - with that you can probably just ssh in, clean up the juju bits, then rebootstrap
<eagles0513875> mgz: agreed i provided the ip of the remote machine but manually there are no options for anything else besides user no ssh key etc
<eagles0513875> humm ok
<mgz> on contributing, start by reading some of the docs in tree - github.com/juju/juju - get it building locally, and then maybe look for an easy bug or nit you want to fix
<eagles0513875> ok probably should do the golang tutorial too no mgz?
<mgz> yeah, if you've not done any go yet, that's a good way to get started on that
<eagles0513875> mgz: is golang linux only or can it be run on any platform?
<mgz> it's reasonably cross platform
<eagles0513875> kool :)
<eagles0513875> fwereade: good time to learn golang can use the linux instance I have on ec2
<perrito666> morning
<wwitzel3> perrito666: morning
 * perrito666 has a food hangover
<bac> hi tvansteenburgh1
<bac> jcastro: we need to get a bundle promulgated.  who in eco can do that and is most available?
<tvansteenburgh> bac: hi
<bac> tvansteenburgh: can you do promulgation of bundles?
<tvansteenburgh> bac: technically yes, although i never have. where's the bundle?
<bac> tvansteenburgh: https://code.launchpad.net/~openstack-charmers/charms/bundles/openstack/bundle
<jcastro> bac, we're at a sprint, but if you can find mbruzek, dpb, or tvansteenburgh they could help you out.
<jcastro> bac, jose can help as well
<bac> jcastro: thanks
<aisrael> Is it possible to execute juju-run from within a hook context?
<wwitzel3> aisrael: yes, you can specifiy --relation (r) and --remote-unit .. you can also use --force-remote-unit if you have a scenario where a remote unit might have gone away
<wwitzel3> aisrael: the help output from your juju-run should give you the details as well
<aisrael> wwitzel3: Thanks, I'll give that a try!
<sinzui> dimitern, I an struggling to understand bug 1416928. Is this issue just about apiaddress ? is this a regression that needs to be fixed in 1.21.2?
<mup> Bug #1416928: juju agent using lxcbr0 address as apiaddress instead of juju-br0 breaks agents <api> <lxc> <network> <juju-core:New> <https://launchpad.net/bugs/1416928>
<dimitern> sinzui, I'll have a look
<wwitzel3> aisrael: cool, let me know how it works out, I implemented it and it hasn't had much use yet
<marcoceppi> wwitzel3: -r and --remote-unit are not in trunk for cmd
<marcoceppi> wwitzel3: at least not in help output
<wwitzel3> marcoceppi: for juju-run? or juju run?
<marcoceppi> juju run
<wwitzel3> marcoceppi: right, not there yet
<wwitzel3> marcoceppi: fwereade wasn't sure we wanted to expose those specifics via juju run, so for now, we expose them to charms, but only via juju-run
<aisrael> wwitzel3: The error I keep coming around to is error: juju-run cannot be called from within a hook, have context "collectd/3-upgrade-charm-1414101190250335867"
<wwitzel3> aisrael: interesting, ok, so JUJU_CONTEXT_ID might be set?
<wwitzel3> aisrael: the way the command works right now is you would run it outside of a context, passing in relation / remote-unit and then it would step in to that context
<aisrael> wwitzel3: Yes, it is. I don't know if I've ever seen it not set
<aznashwan> ericsnow: ping
<ericsnow> aznashwan: OTP
<sinzui> dimitern, natefinch : I think I will release https://launchpad.net/juju-core/+milestone/1.22-beta2 today. The licensing issues don't block our beta, just the final releases.
<dimitern> sinzui, great!
<dimitern> sinzui, re bug
<dimitern> sinzui, sorry; re bug 1416928
<mup> Bug #1416928: juju agent using lxcbr0 address as apiaddress instead of juju-br0 breaks agents <api> <lxc> <network> <juju-core:New> <https://launchpad.net/bugs/1416928>
<ericsnow> aznashwan: what's up?
<dimitern> sinzui, aiui it's about a very specific scenario where a manually provisioned node with 2 nics can initially connect to the apiserver, but after reboot the IP addresses are reassigned(?) or something, so it can't reconnect to the apiserver
<dimitern> pretty weird setup, but needs more investigating
<sinzui> dimitern, fab. that sounds familiar, but I couldn't find a bug that described the issue as the reporter
 * sinzui looks for other bug again
<sinzui> dimitern, I see bug 1414710 as related or the master issue
<mup> Bug #1414710: Manually provisioned machines with multiple networks cannot connect to API server after reboot <manual-provider> <network> <juju-core:Triaged> <https://launchpad.net/bugs/1414710>
<aznashwan> ericsnow: hey, sorry, did I miss you? D:
<ericsnow> aznashwan: I'm here
<aznashwan> ericsnow: hey
<aznashwan> ericsnow: so, i've just re-vamped the PR
<aznashwan> ericsnow: still waiting for an OK to get to the tests
<aznashwan> ericsnow: and also, I still hadn't sadly figured out a way to get the enabled/disabled status of a service through the dbus api
<aznashwan> ericsnow: if you really want to avoid exec calls (which is a good choice considering how wonky systemctl ststus seems to be), I suggest we simply look for the symlink in default.target
<ericsnow> aznashwan: thanks for the update
<aznashwan> ericsnow: i'll be awaiting your blessing and get to the tests later today then :D
<sinzui> natefinch, di you have time to review http://reviews.vapour.ws/r/842/
<natefinch> sinzui: ship it
<voidspace> yay, 5pm and *finally* I have juju bootstrapping
<voidspace> hopefully with diagnostic code in place...
<voidspace> oh, and the way we're creating apt-proxy settings (from http-proxy) is incorrect.
<voidspace> or at least, it *can be* incorrect
<voidspace> dimitern: hey, hi
<voidspace> dimitern: so you got enough for a demo working? awesome.
<dimitern> voidspace, hey, yeah!
<voidspace> dimitern: I just sent you an email a minute ago
<voidspace> dimitern: I've made progress
<dimitern> voidspace, most of the things already done worked, just a few tweaks needed
<dimitern> voidspace, yep, thanks - just got it
<voidspace> dimitern: slightly hampered along the way by the fact that we can set the apt-proxy settings incorrectly
<voidspace> dimitern: that's great news
<dimitern> voidspace, it certainly is! :) I was just talking to ian how his storage update seems to me a lot cooler than my networking status update, but I'll work on this this evening, to make it as great :)
<voidspace> dimitern: no rest for the wicked
<voidspace> dimitern: anyway, good stuff. I'm really pleased. I hope the demo goes well.
<dimitern> voidspace, me too :)
<dimitern> voidspace, btw just confirmed - with ian about unconditionally setting the proxy env vars - let's do it
<dimitern> voidspace, I'll reply to your mail as well
<voidspace> dimitern: cool
<dimitern> voidspace, can you just clarify a bit the part about the charm revision updater?
<voidspace> dimitern: I'm watching debug-log. After the deploy I see:
<voidspace> machine-0: 2015-02-02 17:02:52 ERROR juju.worker.charmrevisionworker revisionupdater.go:75 cannot process charms: finding charm revision info: Cannot access the charm store. Are you connected to the internet? Error details: Get https://store.juju.ubuntu.com/charm-info: dial tcp 91.189.95.66:443: connection timed out
<voidspace> dimitern: so the charm deploy worked, "juju status" shows the charm "started"
<dimitern> voidspace, right, that's exactly the same problem
<voidspace> right
<voidspace> but in a different place
<dimitern> voidspace, so the revision updater works "retroactively" i.e. downloads and caches revisions for already deployed charms
<voidspace> dimitern: I'm looking into it
<dimitern> voidspace, you rock! :)
<voidspace> heh, thanks
<voidspace> dimitern: so if I change the place we set the environment variables no tests fail (at least not for proxyupdater...)
<dimitern> voidspace, great, it will be even better if you manage to add a test that confirms the proxy settings are set in the env after they change
<voidspace> dimitern: I'll look at it
<voidspace> dimitern: I'll see if I can find this other bug *first* though
<dimitern> voidspace, cheers, sounds good
<dimitern> voidspace, what was the other bug you've discovered around setting apt-proxy settings btw?
<voidspace> dimitern: so http-proxy or https-proxy can be in the form 192.168.178.103:3128
<voidspace> for example
<voidspace> dimitern: however, a valid apt-proxy setting *must* be in the form
<voidspace> http://192.168.178.103:3128/
<voidspace> dimitern: and we use http-proxy as a fallback for apt-proxy, so if you specify http-proxy in a way that doesn't work with apt then it just gets set "as is"
<voidspace> dimitern: and redeploying to a machine that you've already deployed to will see the existing config file for apt-proxy and not write a new one
<voidspace> dimitern: even if you've changed the settings
<voidspace> dimitern: so apt-proxy didn't work - once I'd worked out why changing the http-proxy to the correct format didn't help as the new values weren't written out
<voidspace> blowing away the juju apt-proxy conf file caused it to be rewritten (correctly) on bootstrap though
<voidspace> but that cost me some time
<voidspace> and as far as I can tell both the unit agent and the machine agent are starting a proxyupdaterworker and (now) setting the environment variables
<voidspace> so either the charmrevisionworker runs before this happens (possible) or there's some other interaction
<voidspace> I'll put the proxyupdater first in the list to start
<voidspace> dimitern: that appears to work (starting the proxyupdater before other workers)
<dimitern> voidspace, sorry, was afk for a bit - catching up on what you've said so far
<voidspace> np
<voidspace> dimitern: I think I have a fix, not very easily testable though
<dimitern> voidspace, sounds like you're already onto the correct path
<voidspace> dimitern: basically proxy settings need to be in place before we start workers that need access to the internet...
<dimitern> voidspace, please, file a bug about the apt-proxy not using the expected format though
<voidspace> dimitern: moving the proxyupdater to be the first worker will probably "mostly" fix the problem
<voidspace> dimitern: yep
<dimitern> voidspace, that's sounds sensible, yeah
<natefinch> axw_: let me know when you get online, I have some questions about ssh keys for juju
<voidspace> right, g'night all
<voidspace> EOD
<natefinch> thumper: hey, when you get a chance, I'd like to talk about that joyent ssh key bug
<thumper> hi natefinch
<thumper> natefinch: sprinting this week, but I'm here early
<thumper> whazzup?
<natefinch> thumper: not sure what the right fix is... do we default to something like $JUJU_HOME/ssh/joyent_id   and generate that if it doesn't exist?   Or default to generating a key that gets directly embedded in the config file?
<thumper> hmm...
<thumper> I think the first
<thumper> if I have multiple joyent environments, I think it is fine to have just one key
<natefinch> Yeah that was going to be my next question.
<natefinch> thumper: any idea what happens if we were using the user's id_rsa key and then this code is deployed and we switch to a generated key?  Would it break their environment?
<sinzui> perrito666, natefinch, thumper juju-ci3 is in upgrade hell to 1.21.1 state server upgraded in a few minutes, after an hour it fell over. I restarted the agents and can see it, but all the other machines are down. They are trying to contact 10.0.3.1...which is not where the state server is
<sinzui> perrito666, natefinch, thumper, I think I can fix the apiaddress by editing each agent.conf. Is there something more graceful than editing 36 agents?
<sinzui> Can I trigger juju to reset the apiaddress
<perrito666> sinzui: afaik no
<natefinch> perrito666, sinzui: juju run maybe?
<perrito666> natefinch: will that work with the agents down?
<sinzui> natefinch, indeed I was thinking of just a trunk to sed the apiaddress
<thumper> as long as the addresses of the remote machines haven't changed
<natefinch> perrito666: I think if you use --all it just basically does an ssh
<thumper> juju run asks the state server for the remote address
<thumper> and then just ssh'es to it
<thumper> unless you have the "ssh through api server" flag set
<thumper> which I think is the default on azure
<thumper> which is where I think your machines are...
<thumper> however, that should still work
<thumper> sinzui: would love to grab the logs from the failed upgrades
 * perrito666 hears a few shots in the distance and wonders if he should perhaps postpone hist afternoon walk
<natefinch> perrito666: seems wise
<sinzui> thumper, I have plenty of those. I am just trying to get the juju-reports agent back by manual intervention. I can then collect logs and explore automated fixes
<natefinch> hopefully we can figure out what went wrong... that's a pretty nasty bug
<jw4> perrito666: literal shots?  what's going on over there?
<perrito666> jw4: police exchanging opinions with certain fellows
<natefinch> lol
<jw4> perrito666: heh
<sinzui> thumper, natefinch : I confirmed I can edit the agent files to restore contact. I will start gathering logs
<thumper> awesome
<natefinch> cool
<perrito666> k going for a walk, if you dont see me here tomorrow google for local newspapers :p
<jw4> perrito666:  :-(
* ChanServ changed the topic of #juju-dev to: https://juju.ubuntu.com | On-call reviewer: see calendar | Open critical bugs:  1417178
<sinzui> thumper, I reported https://bugs.launchpad.net/juju-core/+bug/1417308
<mup> Bug #1417308: Juju-ci3 cannot upgrade to 1.21.1 <api> <ci> <upgrade-juju> <juju-core:Triaged> <https://launchpad.net/bugs/1417308>
<perrito666> I am alive
<jw4> perrito666: yay!
<jw4> perrito666: any extra holes?
#juju-dev 2015-02-03
<thumper> waigani: http://reviews.vapour.ws/r/844/diff/#
<thumper> axw: hello there
<axw> thumper: ahoy
<thumper> axw: I have a couple of small interesting reviews if you can have your rubber stamp handy :)
<thumper> this one I'm almost ashamed to ask: https://github.com/juju/utils/pull/109/files
<axw> sure
<thumper> edict, remove mess
<thumper> we're not entirely sure what we will call it
<thumper> but SSS seems a bit weird
<thumper> shared state server
<thumper> I'm inclined to go with:
<thumper> SES: Shared Environment Server
<thumper> the other is slightly more interesting
<axw> heh, that's State Emergency Services over here :)
<thumper> what does that do?
<thumper> this one fell out of a branch I was developing, http://reviews.vapour.ws/r/846/diff/#
<thumper> and it looked useful enough to keep around
<axw> assistance during storms, floods, etc.
<axw> thumper: both LGTM
<thumper> ta
<thumper> perrito666: still alive?
<perrito666> thumper: yup
<thumper> perrito666: what's up with the critical bug?
<perrito666> thumper: azure is being a PITA
<thumper> no surprise there?
<thumper> do you know what is wrong?
<perrito666> I am not managing to reproduce that because I get other kinds of failures yet I am looking into the output and trying to deduct it, ill be back to you in a moment
<perrito666> thumper:  there you got my +1 on the mail
<thumper> :)
<thumper> cheers
<perrito666> man how can these runs take so much to run, even though I am running it on a dedicated machine
<perrito666> abentley: are you really here?
<waigani> thumper: http://reviews.vapour.ws/r/819/
<perrito666> axw: are you around
<axw> perrito666: hey. yes, I am
<perrito666> axw: could you lend me a bit of your azure knowledge?
<axw> perrito666: you can have it all and keep it ;)
<axw> how can I help?
<perrito666> I am trying to discern the email conversation you had with abentley
<perrito666> axw: what did you suggest him to do exactly? to delete the whole env or just the machine?
<axw> perrito666: neither
<axw> perrito666: he was deleting the deployment from a cloud service
<axw> perrito666: but leaving the cloud service intact... I suggested he delete the cloud service altogether
<axw> (as a workaround)
<perrito666> mmm, I wonder if there is a limitation in azure that is preventing us from determining if the "machine" for machine 0 is there
<thumper> anyone... http://reviews.vapour.ws/r/848/
<axw> perrito666: isn't the point that machine-0 is dead?
<perrito666> axw: it is, but restore plugin is dumb
<axw> perrito666: so, looking at the azure code, if there are no live state servers it returns "ErrNotBootstrapped"
<axw> in StateServerInstances
<perrito666> mmm, that is a bug, it is inconsistent with the other providers
<axw> perrito666: IMO, the *other* providers are buggy. they return spurious results from StateServerInstances
<axw> i.e. instance IDs for things which don't exist
<axw> perrito666: it possibly shouldn't be returning ErrNotBootstrapped though
<axw> maybe just ErrNoInstances
<perrito666> axw: the env is bootstraped
<perrito666> exactly
<axw> even still, restore would fail
<perrito666> axw: 2 things there
<perrito666> 1) it should be consistent, if we are going to correct that behavior we should do it in all providers at once :)
<perrito666> 2) ErrNoInstances is waaaay les ambiguous than ErrNotbootstrapped
<axw> perrito666: agreed on both counts
<perrito666> axw: so it does check that the instances are alive
<axw> perrito666: what does?
<perrito666> axw: srry was ruberducking and your nick was on the prompt
<axw> perrito666: if you mean restore, yeah I know; that's fine but StateServerInstances shouldn't be expected to return non-empty if there are no live state server instances
<perrito666> agree, i was realizing we have a bug, another one, where  no provider is checking if the instances are live when returning them
<perrito666> is it possible that dependencies.tsv is out of date?
<axw> perrito666: out of date with what?
<perrito666> axw: well master is not building in my machine :
<perrito666> with what seems to be an out of date golxc issue
<axw> perrito666: the bot should fail if dependencies.tsv is out of date
<perrito666> axw: i know, but it has been known to eff up :p
<perrito666> also I see an odd error in hooks about storage
<perrito666> could anyone confirm if its just me or what?
<perrito666> I have two machines failing with the same issue here
<perrito666> ok there is this https://github.com/juju/juju/pull/1524 which I am pretty sure it fixes the thing although I did not compile it, for obvious reasons
<perrito666> i really need to go to bed before sleeping on my computer and/or being eaten by mosquitoes if anyone (axw i am looking at you) wants to take a peak at it and perhaps merge it I would be thankful otherwise ill take a look in the morning
 * perrito666 looks at axw
 * axw looks at perrito666
<axw> will look :)
<axw> good night
<perrito666> tx a lot, good... day?
<axw> yes, midday :)
<perrito666> :D cheers then, enjoy the rest of the day, if it compiles, that patch is quite safe and most likely the fix
<perrito666> cheers
<mattyw> morning folks
<mattyw> I just go this error on almost tip ec2: ERROR cannot remove recorded state instance-id: Get : 301 response missing Location header
<mattyw> anyone seen that?
<mattyw> davecheney, still around? looks like you've seen this before: https://bugs.launchpad.net/juju-core/+bug/1083017
<mup> Bug #1083017: Cannot bootstrap with public-tools in non us-east-1 region <ec2> <juju-core:Fix Released by dave-cheney> <https://launchpad.net/bugs/1083017>
<TheMue> Morning
<jamestunnicliffe> TheMue: Morning!
<dimitern> TheMue, jamestunnicliffe, voidspace, hey guys!
<jamestunnicliffe> hi dimitern
<TheMue> dimitern: heya
<dimitern> I'll chat with you this afternoon (~2-3h) for what's on for this week, just in case you might be wondering :)
<dimitern> didn't quite manage to prepare a mail with work items to pick up
<TheMue> dimitern: chat is fine. how is capetown?
<dimitern> nothing critical though
<TheMue> dimitern: hehe
<dimitern> TheMue, so far so good - we'll see after lunch after the demo :)
<TheMue> dimitern: ah
<dimitern> yeah, forgot to mention - I managed to get it working by integrating all your changes and applying some fixes I found while live testing
<dimitern> if you're curious - here's the branch I'm using https://github.com/dimitern/juju/tree/wip-containers-demo
<TheMue> dimitern: fine, you've got it in a branch I can branch now?
<TheMue> dimitern: there's the answer ;)
<voidspace> dimitern: hey, hi
<dimitern> :)
<TheMue> dimitern: btw, alexis and you will get a mail today. due to signal troubles at kings cross the picadilly line to heathrow has been delayed so that I missed my flight (had already checked in and there still have been 40 minutes left until start, but they said no)
<voidspace> dimitern: TheMue: jamestunnicliffe: shall we wait for you (dimitern) for standup?
<dimitern> TheMue, oh, sorry to hear that :/
<jamestunnicliffe> voidspace: apparently I can't join the call anyway...
<jamestunnicliffe> will try logging out of other accounts...
<TheMue> dimitern: so I took the next one and stayed the night on Amsterdam airport :/
<dimitern> voidspace, nope, please go ahead - I'm in a discussion now
<voidspace> jamestunnicliffe: you have to use your canonical account
<TheMue> dimitern: interesting experience :)
<dimitern> TheMue, oh boy, well - at least I'm glad you got home alright
<TheMue> dimitern: yep, all went well
<dimitern> TheMue, nice, don't worry, we'll sort it out
<TheMue> dimitern: thx
<voidspace> dimitern: we're doing standup - speak later
<dimitern> +1
<axw> perrito666: you should surely be asleep still.. :)  do I need another review, or are you "senior"?
<davecheney> axw: your comment on the issue desn't make sense
<davecheney> could you double check the description
<davecheney> lease
<axw> davecheney: wich issue?
<axw> davecheney: are you talking about the critical blocker? I haven't commented on the bug... does the description on the PR not make sense?
<davecheney> the description doens't make sense
<axw> davecheney: hopefully clearer now, going through your comments. thanks for the review
<davecheney> no probs
<davecheney> i'm off to bed
<davecheney> it's ++bloody late here
<axw> no worries, good night
<perrito666> axw: I wish I was still sleeping
<perrito666> axw I like the new description
<wwitzel3> ericsnow: ping me when you're online
<wwitzel3> ericsnow: I just need to know which branch of yours I should base my systemd branch off
<voidspace> tools from https://192.168.178.177:17070/tools/1.23-alpha1.1-trusty-amd64 downloaded: HTTP 000; time 0.000s; size 0 bytes; speed 0.000 bytes/s sha256sum: /var/lib/juju/tools/1.23-alpha1.1-trusty-amd64/tools.tar.gz: No such file or directory
<wwitzel3> voidspace: that doesn't seem very useful
<wwitzel3> ;)
<voidspace> wwitzel3: my state server (manually provisioned) doesn't have a tools.tar.gz
<voidspace> wwitzel3: so I can't manually add a new machine - it tries to download tools.tar.gz
<wwitzel3> voidspace: hrmmm that is odd
<voidspace> wwitzel3: part of the problem is that "destroy-environment" with the manual provider doesn't seem to remove everything it puts on the machine
<voidspace> and re-provisioning the machine then sees some things already in place
<voidspace> wwitzel3: what do I do with a service in an error state, how do I get it to retry?
<voidspace> so long since I've done that
<wwitzel3> voidspace: resolved --retry
<voidspace> wwitzel3: thanks
<wwitzel3> voidspace: np
<dimitern> voidspace, TheMue, jamestunnicliffe, FYI the demo went great guys
<jamestunnicliffe> dimitern: awesome!
<dimitern> voidspace, TheMue, jamestunnicliffe, let me thank you again for all the hard work to make this possible!
<TheMue> bfl
<voidspace> dimitern: hey, great
<TheMue> dimitern: wow, great news. thanks to you for driving it forward and doing this presentation.
<dimitern> I have some news as well - we'll switch the networking work due to deliver in april from maas to openstack (aws is still a focus though)
<dimitern> thanks! :) that's a great beginning
<voidspace> dimitern: so we'll complete the maas stuff we've done and add openstack as well?
<voidspace> dimitern: and going forward focus on openstack and aws
<dimitern> voidspace, we'll complete the addressable containers stuff for maas only, then switch to openstack
<voidspace> dimitern: cool
<dimitern> voidspace, it's a pretty tight schedule, but I'm sure we can make it
<voidspace> dimitern: :-)
<dimitern> :)
<voidspace> dimitern: I want to go to lunch, is that ok or do you want to talk to us?
<TheMue> openstack is fine, many interests here in germany, for private clouds.
<dimitern> voidspace, no, it can wait, go ahead
<voidspace> dimitern: ok
<voidspace> thanks
<dimitern> voidspace, I'll compose my thoughts and send a mail to you guys later
<voidspace> great
<voidspace> I've been fighting the manual provisioner
<voidspace> not had a clean deploy with my new code
<voidspace> hampered by the fact that "destroy-environment" doesn't fully clean up the machine
<voidspace> I might want to switch to docker
<voidspace> as I really ought to re-provision these kvm images from scratch every time
<dimitern> voidspace, oh,  too bad :/
<dimitern> voidspace, can you use snapshots?
<dimitern> from a clean kvm, before bootstrapping
<voidspace> dimitern: virt-manager doesn't seem to ahve snapshots
<voidspace> dimitern: it has clone, which maybe the same thing
<dimitern> voidspace, try virsh maybe?
<voidspace> dimitern: I'll look into it
<voidspace> dimitern: I wanted to deploy to a separate unit, also behind the proxy, but add-machine failed because tools.tar.gz didn't exist on the state server machine
<voidspace> but anyway :-)
<voidspace> ok, I'm still seeing an "are you connected to the internet?" error for the charmrevisionworker
<voidspace> so my changes are *not* sufficient
<dimitern> voidspace, :) I'm sure you'll find a way - jamestunnicliffe can help perhaps?
<jamestunnicliffe> dimitern: voidspace: sure
<voidspace> nothing concrete to ask for help with yet
<voidspace> dimitern: I have a successful deploy, just with that error still in the logs
<voidspace> so it's definitely an improvement
<dimitern> cool +!
<voidspace> I'll probably propose this as is and continue to work on it
<dimitern> voidspace, the apt-proxy format error?
<dimitern> voidspace, or the charm revision updater
<dimitern> voidspace, I'd suggest proposing the fix for the proxy updater to get it out of the way first
<voidspace> dimitern: you want me to work on that too?
<voidspace> dimitern: I can fix that. Just when we fall back actually parse the url and construct the new one correctly.
<voidspace> dimitern: I was just going to file the issue. Happy to fix it as well.
<voidspace> anyway, I'm taking a break
<dimitern> voidspace, I think that's a good candidate for jamestunnicliffe perhaps? you guys can sync up on it
<voidspace> dimitern: ok, cool
<voidspace> jamestunnicliffe: I'll sync up with you later if that's ok
<jamestunnicliffe> voidspace: sounds good
<voidspace> jamestunnicliffe: I'll file the issue describing the problem and point you to the place in the code to fix it
<jamestunnicliffe> voidspace: great
<voidspace> jamestunnicliffe: but basically it's valid to specify http-proxy as "<ip addr>:port" but apt-proxy must be "http://<ip addr>:<port>/"
<voidspace> jamestunnicliffe: and if http-proxy is specified but apt-proxy isn't we use http-proxy for apt-proxy
<voidspace> jamestunnicliffe: so we have to ensure the format is correct
<voidspace> jamestunnicliffe: environs/config/config.go I believe
<voidspace> jamestunnicliffe: plus in proxyupdater there's a bug where an updated apt-proxy setting may not be written out to the apt config file if the file exists (but is out of date)
<voidspace> jamestunnicliffe: I haven't looked too closely at the cause of that one yet
<jamestunnicliffe> voidspace: thanks. Have your lunch though!
<TheMue> jamestunnicliffe: I have to reconfigure my chat client because of your nick, it's indeed very looooong. :D
<jamestunnicliffe> TheMue: :p
<TheMue> jamestunnicliffe: it brakes the alignement here
<TheMue> jamestunnicliffe: so, fixed ;)
<perrito666> axw: :D
<jw4> axw: so your fix merged... which tests are we waiting for to remove the blocker?
<perrito666> jw4: you should ask abentley about that
<jw4> perrito666: I see - it looked like your PR changes were in axw's PR
<perrito666> they are
<perrito666> I had a broken env last night and was unable to test them so I left the unpleasant task to axw since he had experience with azure
<jw4> heh
<jw4> nice
<jw4> what time zone is abentley?
<jw4> are we going to have to wait a day to begin merging again?
<perrito666> nah, he is in some of the US tzs
<jw4> perrito666: oh, good
<jw4> morning abentley :)
<abentley> jw4: Morning.
<jw4> abentley: I see axw's fix for the blocker was merged... which tests are we waiting for before we can remove the blocker?
<abentley> jw4: I guess industrial_test.  Where was it merged?  I see it marked as "Triaged" for 1.21 and 1.22, but "In progress" (not fix committed) for master.
<jw4> abentley: hmm - maybe axw forgot to update the bug? https://github.com/juju/juju/pull/1526
<jw4> maybe he was expecting perrito666 to update the bug? :)
<perrito666> abentley: jw4 there, fix commited for master
<jw4> abentley: interesting - industrial_test and industrial_test_azure look sunny to me, but no tests have run for a couple days on either
<abentley> jw4: industrial-test is our weekly reliability test, used for this: http://reports.vapour.ws/reliability
<jw4> abentley: ah, I see
<jw4> abentley: I assume we won't wait for the weekly test to unblock?
<abentley> jw4: No, we wont.
 * jw4 thinks he wouldn't have done well with the marshmallow test as a kid
<sinzui> perrito666, I am trying to resurrect juju-ci3' juju env. All agent confs have apiaddress: 10.0.3.1:17070. Editing the machines doesn't help because the insane value gets restored. Is this because the state-server has the wrong value? Do we assume the state server have the private dns name for the apiaddress?
<perrito666> sinzui: otp, brb
<alexisb> ericsnow, wwitzel3, you guys available tomorrow morning for a call with me?
<alexisb> I need to chat with you guys re providers
<voidspace> jamestunnicliffe: FYI https://bugs.launchpad.net/juju-core/+bug/1417617
<mup> Bug #1417617: apt-proxy can be incorrectly set when the fallback from http-proxy is used <juju-core:New> <https://launchpad.net/bugs/1417617>
<ericsnow> alexisb: sure, what time?
<alexisb> I sent an invite
<alexisb> ericsnow, I will need you on a call with altoros on thursday too
<alexisb> I will send an invite
<ericsnow> alexisb: sounds good
<wwitzel3> alexisb: yep, sounds good
<alexisb> thanks guys
<jamestunnicliffe> voidspace: does the URL require the trailing slash, or just the scheme?
<perrito666> sinzui: yes, most likely state server has the wrong addr
<sinzui> perrito666, indeed bootstrap has the insane adresss. I edited the agent.conf and restarted. I got juju status working by the restart, but the confs were rewritten with the bad address
<perrito666> sinzui: we really need a command to fix that
<aznashwan> ericsnow: I just pushed a new version which has been slightly refactored to make testing possible and am getting to updating the tests, which should go quickly
<aznashwan> ericsnow: mind re-having a look sometimes please: http://reviews.vapour.ws/r/671/
<ericsnow> aznashwan: I'll have a look today
<perrito666> sinzui: so, I know you hate restore :) but in the old version of restore you can actually see what you need to change in the state server to have the right address
<voidspace> jamestunnicliffe: the scheme
<sinzui> perrito666, ericsnow We know what the apiaddresses were for juju-ci3. I don't know how to force juju to use them. Since editing the agent.conf fixes juju for 1 second, I think I need to edit something else to get rid of the lxcbr0 address as the apiaddress.
<sinzui> perrito666, ericsnow Is the address in juju-db? Do I need to update the juju collection in the db with the old address?
<perrito666> sinzui: exactly, or else peergrouper will just keep updating the agent.cof
 * sinzui looks for collection and key
<sinzui> perrito666, do you know the collection and key I need to edit?
<perrito666> sinzui: indeed, gimme a sec
<perrito666> sinzui: gimme something more like a couple of mins
<sinzui> thank you perrito666
<perrito666> I am fetching a person that actually had the exact same issue the other day and figured all collections that needed to be tweaked
<perrito666> well he is here niedbalski meet sinzui you both break juju in similar ways :p
<sinzui> perrito666, and possibly this person https://bugs.launchpad.net/juju-core/+bug/1416928
<mup> Bug #1416928: juju agent using lxcbr0 address as apiaddress instead of juju-br0 breaks agents <api> <lxc> <network> <juju-core:Triaged> <juju-core 1.21:Triaged> <juju-core 1.22:Triaged> <https://launchpad.net/bugs/1416928>
<perrito666> man we really need a "update api server" command
<niedbalski> perrito666, uhmm afaik is not the same issue, the one we faced was related to a wrongly commissioned node in MAAS, that returned an incorrect private ip address as primary. Thus the only 'fix' was to manually alter it on the machine collection.
<niedbalski> perrito666, i am not aware on the specific collections that needs to be altered when you change the apiaddresses
<perrito666> niedbalski: ouch :( sad
<sinzui> oh, how do I fix values in the db when the js is not available
<sinzui> perrito666, +1 for a new command.
<niedbalski> sinzui, O am afraid that will not be persistent after reboot
<sinzui> niedbalski, my env has 36 jujuds, each breaks seconds after I fix a conf file. Just getting an env that stays up long enough to allow me to update the services would be a big improvement
<abentley> perrito666, jw4: after manually re-running industrial-test against the lastest master build, I've marked the issue fix released on master.  Fixes for 1.21 and 1.22 are pending, right?
<perrito666> abentley: correct Ill try to backport them asap
<abentley> perrito666: Thanks!
* ChanServ changed the topic of #juju-dev to: https://juju.ubuntu.com | On-call reviewer: see calendar | Open critical bugs:  None
<sinzui> bogdanteleaga, How do I install/use that mongod.exe on the win-slave? Do I place it in the syspath?
<bogdanteleaga> sinzui, yeah just place it somewhere in path
<sinzui> thank you bogdanteleaga
<voidspace> perrito666: as OCR, if you have a chance
<voidspace> perrito666: http://reviews.vapour.ws/r/853/
<TheMue> voidspace: *click*
<voidspace> TheMue: thanks
<voidspace> TheMue: note that moving the proxyupdater to be started first doesn't fix all problems when deploying behind a proxy
<voidspace> TheMue: so I'm doing "further investigations"
<voidspace> TheMue: all tests pass though, and it seems like a *wise* change
<TheMue> voidspace: yes, I've seen and already thought that it is a little risky race with now better chances for the proxyupdater
<voidspace> TheMue: it might need us to wait on the first change
<voidspace> TheMue: I'll investigate if that actually fixes the remaining issue I'm seeing or if there's something else going on
<TheMue> voidspace: yep
<perrito666> voidspace:  I dont see how that solves anything
<voidspace> perrito666: which bit - the whole thing?
<perrito666> voidspace: sorry
<voidspace> perrito666: it solves not being able to deploy charms behind a proxy for one thing...
<perrito666> worker/proxyupdater/proxyupdater.go
<perrito666> l 148
<perrito666> voidspace: I believe you :) what I say is I dont see how it does
<voidspace> perrito666: we set the new proxySettings as environment variables unconditionally
<voidspace> perrito666: essentially the logic determining first run is wrong - and there's no downside to just always setting them
<perrito666> I mean, before that the proxy settings where updated if a given condition was met right?
<voidspace> perrito666: correct
<voidspace> perrito666: that condition meant that they weren't set at all
<perrito666> if I get it right, what it does is setting the proxy settings if they are somehow different than the current ones
<voidspace> perrito666: what do you refer to by "it"? the original code or the new code
<perrito666> the original code
<voidspace> perrito666: that was the idea, yes
<perrito666> so it seems there is a different problem there, you just hid it
<voidspace> perrito666: I solved the immediate problem
<voidspace> of the environment variables not getting set
<voidspace> what's the downside to that?
<voidspace> perrito666: this approach was discussed with wallyworld and fwreade
<voidspace> perrito666: if that helps :-)
<voidspace> perrito666: I left the "first" logic in place as it's still used for writing system files
<perrito666> for starters, what is inside the if is not being executed (and I am guessing it was supposed to ) and seccond if that assumption was made there  (that, if the incoming settings are equal to existing ones, env vars should already be set) is invalid and therefore something that is expected to happen somewhere else is not happening
<voidspace> and mysteriously enough that seems to work
<perrito666> voidspace:  anyway, that is the only part which doesn't convince me I would ship it with an issue to check why was that assumption made in the first place. At least because this immediate problem seems to be causing problems
<voidspace> perrito666: it's not obvious why it wouldn't work from reading the code
<voidspace> perrito666: proxyupdater.New starts the worker with first set to true. SetUp calls onChange and then sets first to false
<perrito666> voidspace: well if it where the bug wouldn't be there in the first place :p
<voidspace> perrito666: so when the worker is started "first" should be true and that code should be executed
<voidspace> but the environment variables were *not* being set, and now they are
<voidspace> so I'm happy to look into it further, but in the meantime I think this is a good fix we should ship
<voidspace> as it resolves an actual problem leaving merely theoretical ones behind...
<perrito666> voidspace: is it possible that there is a call to handleProxyValues with empty values and these are being unset?
<voidspace> perrito666: hmmm, well onChange fetches them from api.EnvironConfig
<voidspace> perrito666: so indeed they *could* be empty on first run (I suppose - they shouldn't be though)
<voidspace> perrito666: but then the next change would match the first part of the clause (the actual values wouldn't equal the empty values)
<voidspace> so that shouldn't be the cause either
<voidspace> perrito666: I will put some tracing code in to see what values we're getting called with and what "first" is set to
<perrito666> voidspace: I sense a race where those cases are reverted, but anyway, remember my shipt it is meaningless :(
<voidspace> still?
<voidspace> perrito666: shouldn't you ask to graduate?
<perrito666> voidspace: there I explained to you in priv
<aznashwan> ericsnow: ping?
<ericsnow> aznashwan: hi
<aznashwan> ericsnow: so, just pushed the updated tests
<aznashwan> ericsnow: apart from the InitDir constant, everything is done on my end, and I would love to finally see it merge :D
<aznashwan> ericsnow: how are you guys doing?
<ericsnow> aznashwan: making progress
<aznashwan> ericsnow: if you need any help, do feel free to ask
<ericsnow> aznashwan: we've been working on incorporating your systemd patch into the new services approach
<ericsnow> aznashwan: will do
<aznashwan> eriscnow: awesome, thanks. seeing as though everything was very well abstracted I suspect things should go smoothly
<aznashwan> ericsnow: thanks again, and as always, awaiting any feedback :D
<ericsnow> aznashwan: I should be able to take a look a few hours from now
<ericsnow> aznashwan: we're pairing until then
<aznashwan> ericsnow: now hurries, my workday has come to an end anyhow
<ericsnow> aznashwan: something to look forward to then :)
<aznashwan> ericsnow: have a nice day, get back tomorrow :D
<perrito666> so, who where has ship powers and can look at  http://reviews.vapour.ws/r/854/
<natefinch> perrito666: looking
<perrito666> gh ui to PR to something other than master has become a bit confusing
<natefinch> yeah, it's a pain in the ass
<perrito666> and the exact same for 1.22 http://reviews.vapour.ws/r/855/
<natefinch> sigh... this is a backport that's already been approved on trunk, right?
<voidspace> TheMue: perrito666: thanks for the reviews
<natefinch> So if I have issues with the code, it would need to change on trunk as well?
<TheMue> voidspace: yw, we could tomorrow talk a bit more about it
<natefinch> perrito666:  ^^
<perrito666> natefinch: ?
<natefinch> perrito666: that review you wanted me to look at, the backport... this is just a straight backport of code on trunk, right?
<perrito666> true
<perrito666> natefinch: the code is actually landed on trunk
<natefinch> ok, I won't nitpick the code then...a couple very minor things just bugged me as confusing
<perrito666> it is what unlocked this AMs CI lockdown
<jw4> abentley: thanks!
<voidspace> TheMue: I'm continuing to investigate
<voidspace> TheMue: so I'm merging this branch but not closing the issue
<TheMue> voidspace: +1
<voidspace> TheMue: and I've added a comment to the issue about the faulty first logic and the charmrevision worker issue
<natefinch> perrito666: I gave it a shipit
<perrito666> natefinch: can you do that for the exact same pr for 1.22? :)
<natefinch> perrito666: just did
 * perrito666 wonders why his phone did not tell anything
 * perrito666 looks at landing bot 
<voidspace> jamestunnicliffe: I added a comment to your issue
<voidspace> jamestunnicliffe: hopefully the repro instructions are comprehensible, if not I can help you out further
<voidspace> jamestunnicliffe: probably tomorrow now though...
<voidspace> as I'm EOD
<voidspace> g'night all
<perrito666> bye
<perrito666> ericsnow: 837 is long :)
<ericsnow> perrito666: tell me about it :)
<perrito666> I think we could benefit from making the "fixes-#####" expression a bit more permissive
<natefinch>  TheMue - added bodie_ to the gojson* repos (and basically everyone else)
<jw4> natefinch: thanks
<TheMue> natefinch: great, thank you
<bodie_> sweet, thanks
<natefinch> just changed      if field, ok := myMap[foo]; !ok || field == "" {     to   if myMap[foo] == "" {      .... I love that maps return the zero value for the type in Go
<perrito666> ericsnow: I did a review of one of your patches, I could go more in depth but my head is not in shape
<ericsnow> perrito666: no worries; thanks for the review
<ericsnow> perrito666: regarding the year, the code was copyrighted in that year (I just copied it into a new file)
<ericsnow> perrito666: perhaps I've misunderstood
<natefinch> I don't really think the year on the copyright really matters
<perrito666> ericsnow: I have been following the rule: New file, new year, but I dont think we are being consistent on it
<perrito666> because of the copyright being on the file and its contents
<ericsnow> perrito666: that's probably the best way to go
<perrito666> also its a great exercise to remember we are in 2015
<thumper> o/
<perrito666> ericsnow: to make it short, you could add apt-add-repository to the apt package :)
<perrito666> thumper: hi
<perrito666> abentley: just FYI https://bugs.launchpad.net/juju-core/1.22/+bug/1417178 is fix committed for all versions
<mup> Bug #1417178: juju restore no longer works with Azure: error: cannot re-bootstrap environment: cannot determine state server instances: environment is not bootstrapped <azure-provider> <backup-restore> <ci> <regression> <juju-core:Fix Released by hduran-8> <juju-core 1.21:Fix Committed by hduran-8>
<mup> <juju-core 1.22:Fix Committed by hduran-8> <https://launchpad.net/bugs/1417178>
<thumper> I see axw's branch landed, are we unblocked now?
<perrito666> thumper: we are for master
<perrito666> and on our way there for 1.21 and 1.22
<perrito666> and after a couple of hours of sleep I figured out why my master was not building
<perrito666> bbl
<davecheney> anyone for a simple review ? https://github.com/juju/juju/pull/1531
<jw4> davecheney: shipit
<perrito666> davecheney: you got a review and a recursion problem
<perrito666> :p
<jw4> perrito666: lol
<davecheney> http://reviews.vapour.ws/r/857/
<davecheney> trivial change
<davecheney> "it's raining innovation" -- thumper
<jw4> davecheney: we have four groups now? or is that a mistake in a couple of your files in 857?
<jw4> davecheney: import groups
* ChanServ changed the topic of #juju-dev to: https://juju.ubuntu.com | On-call reviewer: see calendar | Open critical bugs:  1417790
<sinzui> thumper, we natefinchL we need someone to look into bug 1417790
<mup> Bug #1417790: manual ppc64el units cannot download agents <ci> <maas-provider> <ppc64el> <regression> <juju-core:Triaged> <https://launchpad.net/bugs/1417790>
<thumper> sinzui: we are sprinting right now... anyone else around?
<sinzui> thumper, I am hoping you can find people on your teams, not that you will personally fix the issue
<thumper> sinzui: my team is all with me
<thumper> sinzui: I'm not in cape town
<sinzui> I suppose we need to wait for axw to wake
<sinzui> or anastasiamac
<jw4> sinzui: what *should* the state server ip address be for that ppc64el bug?  voidspaces pr just moved the proxy settings to before the upgrader which seems plausibly connected to me?
<jw4> sinzui: is it that the 10.0.3.1 address is private not public?
<jw4> s/connected to me/connected to the issue/    (???)
<sinzui> jw4,  10.0.3.1 is from the lxcbr0 interface. The machines are on the eth0 interface: 10.245.67.135 10.245.67.136 10.245.67.137. 135 is the bootstrap server in the test
<jw4> sinzui: I see
<sinzui> jw4,  and bug 1417308 and bug 1416928 are other examples of the wrong network being selected
<mup> Bug #1417308: Juju-ci3 cannot upgrade to 1.21.1 <api> <ci> <upgrade-juju> <juju-core:Triaged> <https://launchpad.net/bugs/1417308>
<mup> Bug #1416928: juju agent using lxcbr0 address as apiaddress instead of juju-br0 breaks agents <api> <lxc> <network> <juju-core:Triaged> <juju-core 1.21:Triaged> <juju-core 1.22:Triaged> <https://launchpad.net/bugs/1416928>
<jw4> sinzui: the logs seem to indicate that the state server is listening on *both* networks?
<jw4> sinzui: that seemed to have changed specifically with voidspace's commit
<jw4> sinzui: maybe the unconditional proxy settings caused the state server to identify both networks
<jw4> sinzui: and then the source and sink units are just picking the wrong one
 * jw4 will brb
<perrito666> and for a brief moment reviewboard forced me to communicate with pictures, I am back to the caves or ancient egypt
<jw4> sinzui: is 10.0.31 ever a usable IP for the state server? Only when using local provider?
<jw4> s/10.0.31/10.0.3.1/
<sinzui> jw4, I don't think so. except to local-provider the state server needs an address visible to other machines. but if the unit is deployed to a container on the state-server, like juju-gui, maybe that is the address the container needs to see....
<sinzui> OMG
<jw4> sinzui: OMG?
<sinzui> LXC is an anagram for CuXuLu and I suspect both the juju-ci3 upgrade bug and the manual provider bugs is cause by recent installations of lxc on those machines...
<sinzui> jw4. I think I can revert the manual machine. If the test passes...then the bug will be downgraded and master re-opened.
<jw4> sinzui: woot
<jw4> sinzui: I think there will still need to be work obviously to fix this - either filtering out 10.0.3.1 as an unusable IP (network/hostport.go:182) with some jiggery for local provider - or improving the sorting of IP's so that 10.[^0].*.* is preferred to 10.0.3.*
<sinzui> jw4, agreed, Those other bugs imply the state-server does something stupid if lxc (lxcbr0) is installed.
<sinzui> jw4, I am watching http://juju-ci.vapour.ws:8080/view/Juju%20Revisions/job/manual-deploy-trusty-ppc64/1076/console which is now run without lxc on the bootstrap machine
<sinzui> and I predict quick pass
<anastasiamac> sinzui: morning! were u after me?
<jw4> sinzui: as I'm looking at the SetAPIHostPorts and related code I'm not finding any distinction between 10.0.3.x IP addresses and other 10.0.0.0 addresses
<jw4> sinzui: not sure if that should change... should we assume 10.0.3.x is a 'magic' range?
<sinzui> anastasiamac, I was but I got new glasses and jw4's question made me realise that a regression isn't the regression I thought it was
#juju-dev 2015-02-04
<sinzui> jw4, I think that is a question for dimitern. I think the rule is lxcbr0 is not for general consumption.
<sinzui> PASS.
<jw4> woot
<anastasiamac> sinzui: jw4: great!
<jw4> sinzui: yeah - most of thi scode seems to be dimitern related
<sinzui> jw4, anastasiamac I am down grading the bug and re-describing the madness
<jw4> sinzui: lol
* ChanServ changed the topic of #juju-dev to: https://juju.ubuntu.com | On-call reviewer: see calendar | Open critical bugs: None
<anastasiamac> sinzui: jw4: looks i missed all the fun!
<jw4> anastasiamac: o/
<anastasiamac> sinzui: great find and thank u for master
<anastasiamac> jw4: o/
<anastasiamac> jw4: thnx for being so efficient today  :D
<sinzui> all is open
<perrito666> davecheney:
<jw4> anastasiamac: hehe
<perrito666> github says the same than reviewboard
<perrito666> davecheney: for instance https://github.com/juju/juju/pull/1532/files#diff-a722ce6455c045798bd7ef9db08e0ceaR11
<sinzui> oh, now I need to rethink how we fix the the vivid ppc64el packaging bug without my stilson-07
<perrito666> davecheney: ah but the empty lines are not there
<perrito666> ok, rb shows garbage for your change
<anastasiamac> axw: standup
<axw> doh, thanks
<waigani> thumper: when your ready, destory env: http://reviews.vapour.ws/r/627/
<bradm> anyone about?  we're having a weird juju machine agent issue where its dying with "panic: runtime error: slice bounds out of range"
<TheMue> morning
<dimitern> TheMue, morning
<TheMue> dimitern: hey, how is your time in the warm southern sun so far? ;)
<TheMue> dimitern: here we've right now -3Â° and I'm happy I not have to leave home
<dimitern> TheMue, not so warm today :) it's raining lightly and it's cloudy, but yesterday it was hot
<dimitern> TheMue, it still is 18 degrees though
<TheMue> dimitern: cloudy is good, right environment for juju. but juju is also hot, hmm? :D
<eagles0513875_> dimitern: hey :) hows the sprint
<TheMue> dimitern: thanks for your info on the refactoring btw, good to know. I'm already continuing and wanted to make sure that it isn't useless
<dimitern> eagles0513875_, hey :) it goes swimmingly so far
<dimitern> TheMue, :)
<dimitern> TheMue, cheers
<dimitern> voidspace, o/
<dimitern> voidspace, did you say you're to file a swap day for friday?
<voidspace> dimitern: I'll be taking a swap day Friday, yes
<voidspace> dimitern: o/
<voidspace> dimitern: read through your email, all sounds good
<lazyPower> dimitern, are you present?
<dimitern> lazyPower, i am indeed
<dimitern> voidspace, cheers, please file a request so I can approve it ;)
<lazyPower> dimitern: can you poke your head in #juju on canonirc? I'm starting to traverse into juju core territory that I dont understand while helping debug a customer deploy (this shouludn't take long - as its basically a "i know or dont know" situation)
<dimitern> lazyPower, sure
<voidspace> dimitern: ok, will do
<voidspace> dimitern: I'm currently still looking at the proxyupdater issues
<voidspace> dimitern: a condition of the LGTM I got was to investigate *why* the current "first run" logic (that used to set environment variables) is faulty
<voidspace> dimitern: it *looks* sound, like it should have worked
<voidspace> dimitern: "first" is set to "true" in proxyupdater.New() when the worker is created
<dimitern> voidspace, I can confirm that the "first run" logic is pure bs - out of omission
<voidspace> dimitern: in SetUp onChange is called ("first" should be true) and *then* "first" is set to false
<voidspace> dimitern: omission?
<voidspace> SetUp is called in loop() of the NotifyWorker
<voidspace> on that call "first" should be true, and the proxy settings are fetched from api.EnvConfig
<eagles0513875_> dimitern: glad to hear it :)
<dimitern> voidspace, yeah - it was overlooked
<dimitern> eagles0513875_, :)
<voidspace> dimitern: I've read through the code, it seems sound enough on a casual reading
<voidspace> dimitern: I'm going to put some tracing code and work out what's happening
<voidspace> dimitern: shouldn't take long
<dimitern> voidspace, sgtm, sorry I'm a bit distracted on multiple fronts right now
<voidspace> dimitern: I'm going to create a docker image for the manual provider though - so I can repeat experiments
<voidspace> dimitern: no problem
<voidspace> dimitern: and I'd also like to fix the charmrevision worker so we don't see that error in the logs
<voidspace> dimitern: that may mean moving where the proxyupdater is started
<voidspace> dimitern: just letting you know, so long as you're happy with me working on this no need to internalise the details
<voidspace> dimitern: and then I'll switch to the work you suggested
<dimitern> voidspace, thanks, it seems to me you have all under control there
<voidspace> heh
<voidspace> dimitern: being in control of yourself is always the first step...
<dimitern> :D indeed
<perrito666> morning
<voidspace> jamestunnicliffe: here
<voidspace> jamestunnicliffe: ubuntu image pulled
<jamestunnicliffe> great. Hangout in https://plus.google.com/hangouts/_/canonical.com/juju-sapphire?authuser=0 ?
<voidspace> jamestunnicliffe: sure
<voidspace> jamestunnicliffe: http://pastebin.ubuntu.com/10051327/
<voidspace> jamestunnicliffe: http://pastebin.ubuntu.com/10051372/
<dimitern> voidspace, hey, I've backported your fix for 1.22 http://reviews.vapour.ws/r/859/ - nothing's changed, but I'd appreciate if you can have a look, test it and approve it if it passes, but it can wait for tomorrow - no need to switch to it now
<voidspace> dimitern: ok
<dimitern> voidspace, thanks!
<voidspace> dimitern: just setting up docker images for easy testing of manual provisioning
<dimitern> voidspace, does it make it easier to deploy/debug/redeploy?
<voidspace> dimitern: yes
<voidspace> dimitern: because "destroy-environment" with manual provider doesn't leave a clean environment for a re-deploy
<voidspace> dimitern: which is probably worth a bug report
<dimitern> voidspace, sweet, I'd like to hear about it next week so I can try it out
<voidspace> dimitern: the docker image should make it very easy to repeat a manual deploy
<dimitern> voidspace, that indeed seems worthy of a bug report
<voidspace> dimitern: but creating a new kvm image for manual provisioning is heavyweight and docker should be easier
<jamestunnicliffe> voidspace: http://pastebin.ubuntu.com/10051436/
<jamestunnicliffe> voidspace: docker build -t juju-thing .
<dimitern> voidspace, +1
<dimitern> voidspace, we can try using snappy for the same process at some point as well
<voidspace> dimitern: heh, cool
<dimitern> ;)
<dimitern> ok, gtg for now
<TheMue> dimitern: have you seen snappy in action in capetown?
<voidspace> jamestunnicliffe: what should that file be called?
<jamestunnicliffe> voidspace: Dockerfile
<voidspace> jamestunnicliffe: thanks
<voidspace> well, it's running...
<voidspace> jamestunnicliffe: ah yes, ufw issues
<jamestunnicliffe> voidspace: looks like it is best to do the firewall stuff outside of Dockerfile by telling docker itself what to allow in/out. Will let you know how soon.
<voidspace> jamestunnicliffe: http://askubuntu.com/questions/28215/how-can-i-fix-the-iptables-error-message-unable-to-initialize-table-filter
<jamestunnicliffe> voidspace: https://docs.docker.com/articles/networking/#between-containers should have the answers
<voidspace> You need to load a kernel module for enabling the filter table. Run the next command as root:
<voidspace> modprobe /lib/modules/$(uname -r)/kernel/net/ipv4/netfilter/iptable_filter.ko
<voidspace> jamestunnicliffe: ok
<voidspace> jamestunnicliffe: cool
<jamestunnicliffe> voidspace: the container is running on the host kernel, so you can't just insert stuff into the kernel :-)
<voidspace> right
<voidspace> jamestunnicliffe: https://github.com/docker/docker/issues/1251
<voidspace> ah, that's using ufw on the host
<jamestunnicliffe> voidspace: you may be best off, for now, creating a KVM / VirtualBox / whatever machine and setting up everything but Juju, then snapshotting it.
<jamestunnicliffe> voidspace: that way you can always restore to the snapshot after playing
<jamestunnicliffe> voidspace: this stuff with Docker is possible, but a headache.
<mgz> voidspace: have you got a moment to triage a rsyslog cert issue? bug 1417875
<mup> Bug #1417875: ERROR juju.worker runner.go:219 exited "rsyslog": x509: certificate signed by unknown authority <canonical-bootstack> <regression> <juju-core:New> <https://launchpad.net/bugs/1417875>
 * jamestunnicliffe goes for lunch
<voidspace> mgz: I can look, sorry for the delay - midwife visit
<voidspace> jamestunnicliffe: ok, cool - thanks
<voidspace> jamestunnicliffe: virt-manager has cloning but not snapshotting
<voidspace> jamestunnicliffe: I'll read up on it to check if I need to keep a "clonable" image around, probably...
<voidspace> mgz: you're probably better off with wwitzel3 on that one
<voidspace> mgz: he worked on x509 certs for rsyslog not-that-long-ago
<voidspace> bug 1417875
<mup> Bug #1417875: ERROR juju.worker runner.go:219 exited "rsyslog": x509: certificate signed by unknown authority <canonical-bootstack> <regression> <juju-core:New> <https://launchpad.net/bugs/1417875>
<mgz> voidspace: I figured just thought I'd try you before he was on :)
<voidspace> mgz: it looks like a serious regression if it's reproducible
<mgz> voidspace: pretty sure there has to be something else going on, logging in general in 1.21 has worked
<voidspace> mgz: right
<voidspace> mgz: I'm not familiar with the moving parts (except vaguely) around the certificate generation
<aznashwan1> hey guys; I'm currently working on the systemd support and have a question:
<aznashwan1> in your opinion, which would be the based place to place the unit file (bonus thanks if you also point me to how I could get that path :D
<aznashwan1> best*
<sinzui> bogdanteleaga, gsamfira: I have placed mongod.exe in the sys path and run the win unit tests. The job could complete. What do I need to setup in the env/go env to get the tests to match your experience? http://juju-ci.vapour.ws:8080/view/Juju%20Revisions/job/run-unit-tests-win2012-amd64/29/consoleText
<bogdanteleaga> sinzui: first of all you should probably use one of my branches to test it since not everything is merged
<sinzui> bogdanteleaga, I can arrange that
<bogdanteleaga> sinzui: https://github.com/bogdanteleaga/juju/tree/try-ci
<bogdanteleaga> sinzui: try this one for now, it should work
<sinzui> bogdanteleaga, work as in pass?
<bogdanteleaga> sinzui: yes
<sinzui> bogdanteleaga, fab!
<bogdanteleaga> sinzui: actually, I think you need a branch in juju/testing as well
<bogdanteleaga> sinzui: that might be a bit harder to do
<sinzui> bogdanteleaga, I assume goarch is amd64. but what is CGO_ENABLED in yours?
<sinzui> me sees conflicting info on the windows machine
<sinzui> bogdanteleaga, I will use the make-release-tarball script to make a go tree to test with
<bogdanteleaga> sinzui: yes, it's 64bit, no modifications to go
<perrito666> natefinch: wwitzel3 standup?
<sinzui> thank you bogdanteleaga
<bogdanteleaga> sinzui: this is the one in testing I was talking about https://github.com/bogdanteleaga/testing/tree/skip-chmod
<sinzui> thank you bogdanteleaga
<bogdanteleaga> sinzui np, tell me how it goes
<aznashwan1> ericsnow: you there?
<ericsnow> aznashwan1: OTP
<aznashwan1> for the love of me I have no idea what OTP means :))
<natefinch> on the phone
<aznashwan1> natefinch: thanks, you're better than google :D
<natefinch> haha
<natefinch> took me a while to figure it out too
<perrito666> ericsnow: nice changes on the patch
<ericsnow> perrito666: oh good
<ericsnow> perrito666: wish I'd known about juju/paths when writing backups
<ericsnow> aznashwan1: back
<aznashwan1> ericsnow: so, I had a couple of quick heads-up's
 * perrito666 running the whole suite to have a fully passing one in more than a week
<ericsnow> aznashwan1: k
<aznashwan1> ericsnow: firstly, I used the go-systemd unit to create the service file and, just as an observation, the order of the options is not consistent from one serialization to another
<ericsnow> aznashwan1: ah, good to know
<aznashwan1> ericsnow: secondly, doing a dbus.Conn.ListUnits() only lists running/stopped/idle etc.. units, and does not help at all in determining whether a unit is enabled or not...
<aznashwan1> ericsnow: [stopped as in they actively ran and are now done]
<aznashwan1> ericsnow: i've asked the coreos guys for some help, and am waiting for their response on this...
<ericsnow> aznashwan1: ah
<ericsnow> aznashwan1: however, aren't those the units we want?
<ericsnow> aznashwan1: glad you got in touch with the coreos guys
<aznashwan1> ericsnow: not in the context I was indenting on using it sadly D:
<aznashwan1> ericsnow: anyhow, on a brighter note, I've only just seen your PR on the init systems, and think it's looking great
<aznashwan1> ericsnow: was gonna' ask if you wanted me to get to putting my work over yours, so as to converge eventually
<aznashwan1> ericsnow: because what I was doing up to today would not fit too cleanly there as is D:
<ericsnow> aznashwan1: wwitzel3 and I did something like that yesterday (based on your patch)
<ericsnow> aznashwan1: we should sync up on this
<aznashwan1> ericsnow: well I'll get to putting it on top of yours then to spare you guys of the extra work
<aznashwan1> ericsnow: last couple of questions:
<aznashwan1> ericsnow: from what i've seen the old interface is not preserved (so the confusing Exists() and Matches() functions are gone), do you have any intention to still have both (and by the same definitions?)?
<ericsnow> aznashwan1: there is just IsEnabled
<ericsnow> aznashwan1: the equivalent to Exists is the service.Services.Check method
<ericsnow> aznashwan1: but an InitSystem implementation doesn't have to worry about that
<aznashwan1> ericsnow: good, will be getting to adapting IsEnabled with go-systemd the minute I find out how
<aznashwan1> ericsnow: and I'll be doing the InitSystem implementation of systemd tomorrow
<ericsnow> aznashwan1: check out what wwitzel3 and I did yesterday: https://github.com/wwitzel3/juju/compare/ww3-systemd
<aznashwan1> ericsnow: last thing, I swear: could you please tell me where I may get the place where you want me to put the .service (and ExtraScript optionally) (ideally point me to the actual package/function where I may get it)
<ericsnow> aznashwan1: that was the motivator for the code in service/managed.go :)
<aznashwan1> ericsnow: i see
<ericsnow> aznashwan1: the service.Services implementation takes care of that so the InitSystem implementations don't have to know about it (other than as the second argument to Enable)
<aznashwan1> ericsnow: great, well then I hope to get initsystem/systemd adapted tomorrow
<ericsnow> aznashwan1: awesome
<aznashwan1> ericsnow: shall I keep rebasing over the branch the PR was created on, or this there some other one you are actively working?
<aznashwan1> ericsnow: [your* PR]
<ericsnow> aznashwan1: for the init system stuff it's my init-service-cleanup-local branch
<aznashwan1> ericsnow: gotcha'. thanks for everything and see you soon :D
<ericsnow> aznashwan1: keep in mind that it depends on https://github.com/juju/testing/pull/48/ and https://github.com/juju/utils/pull/108
<ericsnow> aznashwan1: np, thanks for working on this
<mgz> wwitzel3: are you around? can you triage bug 1417875 or ask for any more information we'll need
<mup> Bug #1417875: ERROR juju.worker runner.go:219 exited "rsyslog": x509: certificate signed by unknown authority <canonical-bootstack> <regression> <juju-core:New> <https://launchpad.net/bugs/1417875>
<wwitzel3> mgz: ok, taking a look
<perrito666> how do you determine a backend facade version from api calls?
<mgz> wwitzel3: thanks
<natefinch> if your export_test file is over 200 lines... maybe you should just make your tests internal :/
<jw4> natefinch: lol
<perrito666> I hate export_test pattern :(
<natefinch> perrito666: me too
<natefinch> perrito666: the only time I think it's valid is when it's needed to avoid circular imports.
<katco> perrito666: natefinch: i will just +1 that sentiment
<katco> natefinch: if unit tests are really what we're going for, it becomes busy-work
<katco> natefinch: ps, are you alive up there in boston? yeesh!
<natefinch> katco: haha yeah... gotten 44" of snow in the last week and more on the way.  Looks like we moved to northern Canada or something
<katco> natefinch: craziness
<katco> natefinch: i love snow, but i understand it's causing a few issues =/
<natefinch> katco: at least we're (mostly) set up to deal with it.  The roads are ok, the main problem is where to put all the snow that you clear off the roads.  It's not too bad in the country, but in downtown, there's just no place to put it all
<katco> natefinch: shovel it into trains and ship it to the west coast!
<natefinch> katco: yeah. definitely glad I don't have to commute into Boston anymore... heard other people's commutes that were like 2.5 hours longer than normal (each way!)
<katco> natefinch: yeah i saw that. commuting = largest waste of ones life.
<natefinch> yep
<perrito666> dont you people cancel work for commuters on excessive snow days?
<katco> perrito666: yes, but companies vary
<katco> perrito666: it's usually individual managers who make the call for their team unless it's clearly unsafe and then the company might issue a site-wide communication
<perrito666> well, its a good thing I decided to go for a career in CS
<voidspace> g'night all
<perrito666> voidspace: night
<katco> voidspace: sleep well
<voidspace> perrito666: o/
<voidspace> katco: plenty to do before sleep time :-)
<voidspace> but thanks, and I will...
<katco> voidspace: fair enough!
<natefinch> perrito666: when it's really bad they do call for travel bans.... but that's usually just during the storm.
<perrito666> that wonderful feeling when all tests pass
<perrito666> man I get so much mail from prs that my phone sounds like mario bros on steroids
<thumper> sinzui: sha'ping
<mgz> thumper: does that mean he has to hash himself?
<thumper> haha
<thumper> nah
<thumper> sinzui: I have been thinking about the manual provider and ci upgrade bug with the 10.0.3.1 address issue
<thumper> I'm pretty sure I know what is going on
<thumper> I mentioned it in the bug
<thumper> however
<thumper> the new networking code from Dimiter's team has started enumerating all the network devices
<thumper> to get their ip addresses
<thumper> lxcbr0 by default gives 10.0.3.1
<thumper> this is classified as  a class A private network
<thumper> and then considered cloud private
<sinzui> and juju prefers A private networks?
<thumper> and then the 'best address' to give out
<thumper> well, there are two class A ones
<thumper> I guess it picks the first?
<thumper> or last?
 * thumper shrugs
<thumper> I think the solution is to blacklist some nic names
<thumper> like 'lxcbr0' and 'virbr0'
<thumper> neither of those will ever be useful addresses
<thumper> probably lo* too
<sinzui> thumper, think this issue is the cause of bug 1417308 and bug 1416928
<mup> Bug #1417308: Juju-ci3 cannot upgrade to 1.21.1 <api> <ci> <upgrade-juju> <juju-core:Triaged> <https://launchpad.net/bugs/1417308>
<mup> Bug #1416928: juju agent using lxcbr0 address as apiaddress instead of juju-br0 breaks agents <api> <lxc> <network> <juju-core:Triaged> <juju-core 1.21:Triaged> <juju-core 1.22:Triaged> <https://launchpad.net/bugs/1416928>
<thumper> yup
<thumper> I believe this worker was added in 1.21
<sinzui> It certainly was
<thumper> dave suggests that we look at network properties on the adapter rather than names
<sinzui> thumper, So I hope core cna provide a fix. I can make all these bugs a dup of a new bug based on your insight
<thumper> so look for the loopback flag
<thumper> or bridge
<thumper> sinzui: we need to fix it, but I'm not entirely sure how
<thumper> I'd like william and dimiter and john to talk about it in cape town
<sinzui> thumper, agreed
<mgz> wwitzel3: did you have a chance to look at bug 1417875 yet?
<mup> Bug #1417875: ERROR juju.worker runner.go:219 exited "rsyslog": x509: certificate signed by unknown authority <canonical-bootstack> <regression> <juju-core:New> <https://launchpad.net/bugs/1417875>
<hatch> can someone tell me if the existence of the JUJU_ENV_UUID env attribute is an indicator of the api supporting it in the path?
<natefinch> hatch: it looks like it's only set as hookvars ... charms can read it, but none of the rest of juju's code seems to read it
<natefinch> hatch: not sure if that answers the question
<hatch> natefinch: hmm I was under the impression that the api will require it soon so I was implementing it in the GUI
<natefinch> hatch: the API will require it, yes, but that's different than the environment variable
<hatch> right - but we need to grab the uuid from the charm to supply it to the GUI
<natefinch> hatch: maybe I misunderstood the question
<hatch> so I was wondering if I can use the existance of that attribute to be a flag to the GUI that it's now supported in juju
<hatch> the gui can be deployed to many different juju versions
<hatch> natefinch: basically something needs to say to the GUI 'use the uuid' or 'dont use the uuid'
<hatch> the uuid environment variable has been defined for at least 5 months according to the source - I'm not sure if the API support follows the same
<natefinch> hatch: that sounds kind of a hackish way to determine the api version... can't you just query the API for what version it is?
<hatch> ehh feature testing > version testing
<natefinch> version testing > depending on some random env variable and assuming you know what its existence or non-existence means :)
<natefinch> hatch: thumper would probably be the guy to ask about the best way to go about this
<hatch> well I was just hoping to avoid writing the code to test with the uuid then fall back to w/o if it errors :)
<natefinch> hatch: understood.... there's probably a check you can do, I'm just not sure what it is, but checking for that env var does not seem like the most reliable thing to use
<hatch> yeah - unfortunately the api doesn't tell us what features it supports
<hatch> YET!
<hatch> :)
<hatch> granted we'd need to know that it supported the uuid to get that list first :P
<natefinch> haha
<natefinch> I was going to say - how do you know if it supports asking what features it supports? :)
<hatch> damn egg/chicken
<hatch> I prefer a chicken omlet anyways
<natefinch> somewhat harder to stir up, though
 * thumper looks up
<thumper> hi hatch
<thumper> hatch: if there is an env-uuid in the .jenv file, use it
<hatch> thumper: I am in the gui charm's start hook so I have access to the environment variables
<hatch> is that an indicator that the api supports requests with it?
<thumper> hmm...
<thumper> yes?
<hatch> haha
<hatch> I can't find in the code where that url structure was added
<hatch> so I can't compare to when the uuid env variable was
<hatch> and then cross reference to some release # :)
<thumper> hatch: I think it was 1.18 or 1.20
<hatch> you guys just do too much work
<thumper> 1.20 has it
<thumper> and 1.21 is stable
<thumper> you can ask the version right?
<hatch> wait....so even is unstable?
<thumper> hatch: we don't do that now
<rick_h_> hatch: you know what, we can just startif version > 1.20
<rick_h_> no need to go back all the way to the first origin of it
<hatch> that works for me!
<thumper> rick_h_: oh hai
<thumper> rick_h_: how's cape town?
<rick_h_> thumper: good stuff,   but crazy
<rick_h_> thumper: missing you to drink with after the day :P
<thumper> we'll drink here for you
<thumper> that's ok right?
<rick_h_> :)
<thumper> rick_h_: you should be sleeping now right?
<hatch> it's only 9:30
<rick_h_> thumper: yea, should be.../me goes to bed
<hatch> lol
<rick_h_> just taking care of the team. reminding them to do reviews
<thumper> that's nice of you :)
<rick_h_> hatch: hmm, add 2hrs
<hatch> oh woops, timezone fail
<rick_h_> night all, ty thumper for helping hatch out
<hatch> ^ and natefinch :)
<wwitzel3> mgz: I hadn't fired up my maas in a while so I'm just working out some issues in it so I can reproduce
<thumper> wwitzel3: I misread 'maas' for 'ass'
<lazyPower> thumper: how'd the mess demo go?
<wwitzel3> thumper: lol
<thumper> lazyPower: I heard it went real well
<hatch> haha
<mgz> wwitzel3: ehehe
<lazyPower> gooooooooood
 * lazyPower hi5's thumper
 * lazyPower resumes lurking now
<wwitzel3> mgz: I'm wondering if somehow the permission of the issuer cert is off
<wwitzel3> mgz: or if it is even there, soon as I get my setup bootstrapping again, I'll take steps to verify and reproduce and update the ticket. In the meantime I'll get it assigned to me, forgot to do that/
<mgz> wwitzel3: thanks!
<jillr> got an HA juju deployment that was unplanned rebooted by the customer. been fighting with mongo corruption, respawns, and SocketExceptions. menn0 and gustavo had helped with a recovery earlier today, but it's gone bad again, member in FATAL.
<natefinch> thumper: if you have time, I made a fix for the joyent issue you saw: http://reviews.vapour.ws/r/861/
<natefinch> jillr: is it just a single member that's down?  If so, can you just kill it and then rerun juju ensure-availability to get back up to 3 state servers?
<jillr> natefinch: it has not been consistently just one node, no. also we are colocating other services on the machines so I'd have to dig thru the relations
<jillr> restarts of jujud-machine-# and juju-db have at times restored things, but only briefly
<jillr> there was a missing record it was barfing on earlier but we thought that was resolved
<jillr> or I suppose it'd be a missing transaction, sorry
<natefinch> jillr: I'm at EOD, but thumper, axw, waigani, and davecheney are all near the beginning of their days, so hopefully they can help out.
<jillr> natefinch: cool, ta
#juju-dev 2015-02-05
<axw> jillr: I don't have much experience diagnosing such things, but I can try. do you have any logs from the unhappy mongod that I can peruse?
<axw> and the jujud agent on that machine
<jillr> axw: thanks. I have an IR with a bunch of pastes of logs and stats, I can upload new logs, I can also provide shell access
<jillr> what's the best route to get you fresh logs?
<axw> jillr: I don't know what an IR is. if you can give me shell access then I can just dig around directly
<jillr> oh, and since it's HA, which machine? the one with the FATAL mongo member?
<jillr> sorry, incident report
<axw> jillr: yes please, the FATAL one
<perrito666> ericsnow: wwitzel3 ?
<axw> thumper: possibly sorted, the machine is NUMA and juju 1.20 doesn't run mongod on NUMA properly
<thumper> what's NUMA?
<axw> which can lead to periodic slow downs
<axw> non uniform memory architecture
<axw> err, access
<thumper> and this caused some of the transaction log failures?
<thumper> maybe the transaction log was being written to /dev/null because it is web scale?
<axw> thumper: sorry brb
<axw> thumper: so I noticed in the the mongo log that it was timing out getting replset info from the master
<axw> and googled that
<axw> and after much sifting, found someone who had that on a NUMA machine, and it was fixed when they used the recommended settings
<axw> anyway, it's been applied on 1/3 machines, status will be monitored and applied to others as necessary
<axw> bbs
<thumper> hmm
<thumper> very simple review for someone: http://reviews.vapour.ws/r/864/diff/#
<anastasiamac> thumper: wouldn't u want to check info.created in the test?
<anastasiamac> thumper: otherwise, lgtm but u'd need someone with power to 'shipit'
<thumper> anastasiamac: it is an internal implementation detail, and the secondary write fails without it
<anastasiamac> thumper: i understand why u'd set it to false on failure (disk.go) but why is it still false on success (mem.go)?
<anastasiamac> thumper: just a point of interest really... did not feel too intuitive to me :D
<thumper> anastasiamac: because mem.go supports the same behaviour as disk.go
<thumper> but just stores in memory
<thumper> and without it, it fails the test :)
<thumper> and it isn't false on failure in disk.go
<thumper> it is on success
<thumper> anastasiamac: oh... yeah, it is a bit ick
<thumper> I just noticed what you were looking at
<thumper> errors.Annotate returns nil if err is nil
<anastasiamac> thumper: yes, i forgot Annotate returns nil
<anastasiamac> thumper: in other words, u r just resetting .created for the next write
<thumper> aye
<anastasiamac> thumper: thnx for patiently explaining stuff :D lgtm
<thumper> anastasiamac: you have a few minutes while I propose this branch, then I'm heading home
<thumper> so... go
<anastasiamac> thumper: thnx :)
<anastasiamac> thumper: i want to test some db operations (annotations specifically)
<anastasiamac> thumper: they r performed on some entities
<anastasiamac> thumper: that comply with an interface
<anastasiamac> thumper: any problems for me to test using a mock entity
<anastasiamac> thumper: rather than our existing juju entity?
<anastasiamac> thumper: since m testing operations rather than entity behaviour...
<thumper> as long as functions aren't writing to the db with the expectation that the entity exists
<thumper> then, yes, sure use a mock
<thumper> here's another one: http://reviews.vapour.ws/r/870/
<anastasiamac> thumper: well, i can't write my test entity to db for tests?
<anastasiamac> thumper: don't we clean db after tests run?
<thumper> is this thing still on...?
<thumper> why can't you write your entity to the db?
<thumper> sure you can
<thumper> use the Factory to create an entity
<thumper> it is reset after every test
<thumper> in tear down
<thumper> my network connection was dropped
<anastasiamac> thumper: s/well/why
<anastasiamac> thumper: yes, it was my intention :D thnx
<anastasiamac> thumper: maybe
<jw4> axw: thanks.  That was fast :)
<axw> jw4: nps, that was easy :)
<jw4> :)
<jw4> axw: great feedback - thanks!
<axw> nps
<TheMue> morning
<anastasiamac> TheMue: hi :D
<TheMue> anastasiamac: heya o/
<dimitern> voidspace, ping
<dimitern> morning TheMue
<dimitern> how goes the testing? :)
<TheMue> dimitern: heya, we're in our hangout
<TheMue> dimitern: morning btw
<dimitern> ah, ok
<voidspace> dimitern: pong
<TheMue> dimitern: tests currently fail due to non-provisioned machines inside the containers, InstanceId() needs it. so I'll add it next.
<voidspace> TheMue: jamestunnicliffe: browser crash! Sorry.
<dimitern> voidspace, so just a quick sync up - when you're done about would you manage to setup docker etc. to test the proxy fix backport for bug 1403225
<mup> Bug #1403225: charm download behind the enterprise proxy fails <cloud-installer> <deploy> <proxy> <sync-tools> <cloud-installer:Confirmed for adam-stokes> <juju-core:Fix Committed by mfoord> <juju-core 1.21:Triaged> <juju-core 1.22:In Progress by dimitern> <https://launchpad.net/bugs/1403225>
<TheMue> dimitern: the rest of your changes are now in my refactoring
<voidspace> dimitern: docker experiment was a fail
<dimitern> TheMue, ok, that's progress, thanks
<voidspace> dimitern: oh, oops
<voidspace> dimitern: I forgot your backport
<voidspace> dimitern: I have clonable kvm images though instead
<voidspace> dimitern: will get on it
<dimitern> voidspace, sweet! even better imo
<dimitern> voidspace, cheers
<dimitern> jamestunnicliffe, and morning to you as well :)
<dimitern> jamestunnicliffe, did you manage to look into bug 1417617?
<mup> Bug #1417617: apt-proxy can be incorrectly set when the fallback from http-proxy is used <juju-core:In Progress by dooferlad> <https://launchpad.net/bugs/1417617>
<voidspace> dimitern: he has a fix for it...
<jamestunnicliffe> dimitern: Indeed, fix on its way. Just in hangout.
<dimitern> jamestunnicliffe, awesome!
<dimitern> ok, i'll leave you guys alone now :)
<dimitern> just a reminder - please add cards for what you're doing on the kanban board if you haven't done it
<TheMue> oops :D
<voidspace> ok
<dimitern> and if you want your expenses for the sprint reimbursed this month file a claim today
<dimitern> cheers ;)
<jamestunnicliffe> dimitern: do we add cards for bug work?
<jamestunnicliffe> dimitern: never mind, seen one of yours - will copy :-)
<dimitern> jamestunnicliffe, yes - there's a card type "defect" and a field on the right to fill in the LP bug#
<dimitern> so it's linked automatically
<perrito666> morning
<voidspace> perrito666: morning
<wwitzel3> morning
<voidspace> wwitzel3: morning
<wwitzel3> hey voidspace, how's it going?
<voidspace> wwitzel3: not bad
<voidspace> wwitzel3: a huge stack of paperwork to sign alongside my regular work
<voidspace> wwitzel3: (house paperwork)
<voidspace> wwitzel3: current status: cloning, destroying, and cloning again kvm images for testing race conditions around setting up proxy environment variables
<wwitzel3> voidspace: that's great!
<voidspace> wwitzel3: it's quite fun
<voidspace> wwitzel3: yeah, it's good news
<voidspace> wwitzel3: I'm really hoping we can complete next week
<voidspace> wwitzel3: and we're now officially in the "safe for home birth period"
<voidspace> wwitzel3: as of midnight last night, if Delia goes into labour we can have the birth at home
<wwitzel3> voidspace: wonderful
<voidspace> wwitzel3: two weeks early is common, which would be next week
<voidspace> wwitzel3: probably at the same time as we're trying to move... :-)
<wwitzel3> voidspace: hah, yeah
<wwitzel3> voidspace: at least it is close, worst case is you are two houses away from one of the houses :)
<voidspace> wwitzel3: indeed :-)
<voidspace> wwitzel3: during the crossover period wouldn't be too bad. At least we'd have a choice of houses...
<voidspace> perrito666: ok, so whenever the proxyupdater onChange is called "first" is always false. I'm continuing to track down why...
<TheMue> ah, test passes now again
<perrito666> voidspace: I see, that might by why there is an || in the if
<perrito666> someone trying to bypass that issue in the wrong way
<voidspace> perrito666: sure, but the proxy settings aren't different on first run
<voidspace> perrito666: no, the || is so that system files are only written if they've changed *or* on the first run
<voidspace> perrito666: but "first" is always false - so they're not written out
<voidspace> perrito666: I'm tracking down why "first" is false when it's clearly initialised to true
<voidspace> well, clearly *looks like* it's initialised to true at any rate...
<perrito666> heheh #DEFINE False True
<perrito666> or the other way around :p
<voidspace> :-)
<dimitern> voidspace, needs to block perhaps, but only inside the unit agent
<dimitern> voidspace, I started implementing the suggestion katco gave, but this really blew up the size of the patch with all the testing required
<voidspace> dimitern: ah, ok
<voidspace> dimitern: it's only an intermittent issue :-)
<dimitern> voidspace, yeah - inside the machine agent there's no charm revision updater
<dimitern> voidspace, however, hmm..
<voidspace> dimitern: yes there is
 * dimitern takes a deeper look
<voidspace> dimitern: charmrevisonworker is started inside newStateStarterWorker
<voidspace> dimitern: see my latest comment on the bug
<dimitern> voidspace, ok, I stand corrected :)
<dimitern> sorry
<voidspace> np of course
<voidspace> dimitern: will the worker retry
<voidspace> dimitern: if so, does a transient error matter?
<dimitern> voidspace, var interval = 24 * time.Hour
<dimitern> it does retry daily
<dimitern> which is perhaps too long it should retry more often on connection errors I think
<voidspace> dimitern: any reason I shouldn't see error logging from when notify watchers are starting in the logs?
<dimitern> voidspace, but that should happen in the apiserver charmrevisionupdater I think
<voidspace> dimitern: right
<voidspace> dimitern: what do you think is the *right* fix?
<voidspace> dimitern: have charmrevisionworker retry on failure or have the agents block until proxy settings are in place
<voidspace> or both :-)
<voidspace> ok, so I *am* seeing "handleProxyValues" being called with "first" true
<voidspace> and I was seeing the logging - I just had to grep through all-machines.log
<voidspace> it wasn't recent enough for "juju debug-log"
<dimitern> voidspace, well :) first off, I think the charmrevisionupdater should retry a few times on download failures with exponential backoff
<voidspace> dimitern: so should I do that *now* or should I file a bug for it and go to the lxc-broker
<dimitern> voidspace, this is definitely more resilient than the current "fire-and-forget" approach
<dimitern> voidspace, don't worry about it, I'm on it already - will file a bug
<voidspace> dimitern: I'm spending a little bit more time on the "first" logic
<voidspace> dimitern: it *really* looks to me like the old code should have worked... unless, hang on...
<voidspace> nope
<voidspace> mysterious
<wwitzel3> mgz: so on my maas juju doesn't write the syslog or cert files at all .. so I am not able to reproduce the error
<mgz> wwitzel3: that... does not sound good?
<wwitzel3> mgz: re https://bugs.launchpad.net/juju-core/+bug/1417875
<mup> Bug #1417875: ERROR juju.worker runner.go:219 exited "rsyslog": x509: certificate signed by unknown authority <canonical-bootstack> <regression> <juju-core:New for wwitzel3> <https://launchpad.net/bugs/1417875>
<mgz> not writing the syslog would be a ug, no?
<mgz> *bug
<wwitzel3> mgz: well it might just be my setup *shrug* I haven't actually confirmed what is happening yet
<wwitzel3> mgz: will open a bug for it once I confirm
<mgz> it must write something, you mean the all-machines.log on the state server doesn't exist at all? or what?
<dimitern> voidspace, it seems to me this is indeed a racy situation between the CRU and PU workers
<wwitzel3> mgz: the state server is fine, the units don't have juju-*.conf files for syslog or any of the certs
<voidspace> dimitern: indeed, that's my conclusion
<dimitern> voidspace, one question though - when you see the errors from CRU failing to download, do you also see right after the CRU worker existing and getting restarted?
<dimitern> voidspace, I've just answered my own question looking at the code :) sorry - ruw.updateVersions just *logs* the error, rather than returning it out of the loop
<voidspace> right
<dimitern> voidspace, which is *wrong*
<wwitzel3> mgz: but a ca-cert.pem is getting written, which is odd since ensureCertificates does that part *last* ..anyway, investigating further :)
<dimitern> voidspace, because, if it *did* return an error, that would've caused its runner to kill it and restart it 3secs later, and retrying so - even with a race it will be resolved in seconds, not 24h
<voidspace> dimitern: how many times will it retry?
<voidspace> dimitern: maybe that's the right fix then
<dimitern> voidspace, just consulted william and that seems like the easiest fix to do for 1.22 and 1.22, for 1.23 however, we should do better
<voidspace> dimitern: as far as I can tell the existing "first" logic is correct
<voidspace> dimitern: William will be interested in this
<voidspace> dimitern: and putting the SetEnvironmentVariables call *back* where it was, but leaving in place starting the proxyupdaterworker first
<voidspace> dimitern: I can successfully deploy charms
<dimitern> voidspace, it will keep restarting it
<voidspace> dimitern: so I think it was the race condition that was the problem all along...
<voidspace> dimitern: and the first logic is fine
<dimitern> voidspace, wow :)
<voidspace> dimitern: I've just successfully deployed a charm this way and my logging confirms that "first" is set correctly and the environment variables are set
<dimitern> voidspace, great job on finding it then!
<dimitern> voidspace, however to fix the race we'll need a lot more code and testing than to make it virtually irrelevant
<voidspace> dimitern: right
<voidspace> dimitern: so I'll change the charmrevisionworker to return the error
<dimitern> voidspace, for 1.23 we should fix it properly, as william also suggested we should take advantage of nesting runners to define the order things start
<voidspace> dimitern: is there an example of this I can look at?
<dimitern> voidspace, it should return an error yes, in addition to leaving your original fix in place for 1.21 and 1.22
<voidspace> dimitern: we didn't backport to 1.21
<voidspace> dimitern: want me to look at that?
<dimitern> voidspace, it's as easy as return errors.Annotate(err-from-updateVersions, "failed updating charm versions")
<voidspace> dimitern: but the main fix will need backporting too
<voidspace> dimitern: I meant an example of nesting workers to define the order
<dimitern> voidspace, that has to happen in the CRU loop each time when we call updateVersions
<voidspace> dimitern: returning an error I can probably work out for myself...
<dimitern> voidspace, ah, well a worker.Runner is itself a worker.Worker
<dimitern> voidspace, sorry :)
<voidspace> dimitern: so let's do this in order of things to do
<dimitern> voidspace, I got confused trying to follow 3 separate topics we're having
<voidspace> dimitern: backport the existing fix to 1.21
<voidspace> dimitern: change charm revision worker to return the error in trunk, 1.22 and 1.21
<voidspace> dimitern: then look at a proper fix for trunk
<voidspace> dimitern: sound good?
<voidspace> perrito666: FYI, the existing "first" logic works fine
<dimitern> voidspace, yeah, if you don't mind fixing CRU for 1.21 first, *without* four PU fix
<dimitern> s/four/your/
<voidspace> dimitern: so you're saying no to "backport the existing fix to 1.21" then
<voidspace> dimitern: that's fine
<dimitern> voidspace, and then as i backported your PU fix in 1.22, just forward port it CRU fix for 1.22 and 1.23
<voidspace> perrito666: the actual bug was a race condition and fixed (mostly) by the other part of the PR
<voidspace> perrito666: but unconditionally setting environment variables is harmless and can be left in place
<voidspace> perrito666: as there's still plenty of other things to fix
<voidspace> dimitern: ok
<voidspace> dimitern: will do
<voidspace> dimitern: later... lunch first
<perrito666> voidspace: agreed, as long as we know what was the other problem
<dimitern> voidspace, the reason not to backport the CRU fix for 1.21 is because I believe it's a lot messier to do and we really need to get 1.21.2 out the door tomorrow
<voidspace> dimitern: you mean "not to backport the PU fix for 1.21"
<dimitern> voidspace, while the other fixes are less critical and also trivial to transplant
<voidspace> dimitern: but ok
<voidspace> yep
<dimitern> voidspace, ofc :) sorry
<dimitern> voidspace, and having the CRU fix in 1.21 will make the issue a minor annoyance rather than a blocker
<voidspace> dimitern: the CRU wasn't the main problem I don't think
<voidspace> dimitern: only a side issue
<voidspace> dimitern: I still don't think you'll be able to deploy charms with 1.21
<voidspace> dimitern: I'd be happy to be wrong about that...
<voidspace> dimitern: and I can try it
<dimitern> voidspace, hmm..
<voidspace> dimitern: it's downloading the charm that fails
<dimitern> voidspace, that's likely to be correct, but I'd rather tackle it myself so you can return to the CA work
<dimitern> :)
<voidspace> dimitern: heh, ok
<voidspace> dimitern: really going on lunch
<voidspace> o/
<dimitern> voidspace, enjoy! :)
<perrito666> dimitern: sorry to botter, what is stopping https://bugs.launchpad.net/juju-core/+bug/1416425 from being in 1.21?
<mup> Bug #1416425: src/bitbucket.org/kardianos/osext/LICENSE is wrong <licensing> <packaging> <juju-core:Fix Committed by dimitern> <juju-core 1.21:Fix Committed by dimitern> <juju-core 1.22:Fix Released by dimitern> <https://launchpad.net/bugs/1416425>
<dimitern> perrito666, let me have a look
<perrito666> dimitern:  says you committed the fix
<dimitern> perrito666, you mean why it's not Fix Released for 1.21?\
<perrito666> yup
<dimitern> perrito666, because 1.21.2 is not released yet (due tomorrow)
<dimitern> perrito666, and since it's a release issue, unlike a blocker or other..
<perrito666> I see, yup
<dimitern> sinzui, do you know when 1.22-beta3 is due for release?
<sinzui> dimitern, I was hoping for a few more fixes given the large list of issues https://launchpad.net/juju-core/+milestone/1.22-beta3
<sinzui> dimitern, we can release tomorrow if we have stakeholders that need to test a fix
<dimitern> sinzui, sgtm to sync 1.21.2 with 1.22-beta3 release
<dimitern> sinzui, and how about 1.22 proper? what's the plan?
<sinzui> dimitern, when all bugs are fixed and stakeholders find no other bugs, we propose 1.22.0. That could be next week
<perrito666> anyone would be so nice? http://reviews.vapour.ws/r/873/ its trivial and urgent
<dimitern> sinzui, that sounds great, thank you
<sinzui> np
<jw4> sinzui: helpful? https://github.com/juju/testing/pull/49  to address bug 1416430 from the 1.22-beta3 milestone
<mup> Bug #1416430: Some files refer to an include license file that is not included <licensing> <packaging> <juju-core:Triaged> <juju-core 1.21:Triaged> <juju-core 1.22:Triaged> <https://launchpad.net/bugs/1416430>
<sinzui> jw4, yes please
<dimitern> TheMue, can you approve this backport please? http://reviews.vapour.ws/r/877/
<TheMue> dimitern: yes, will do.
<jw4> sinzui: kk - does that version have to actually be referenced in the dependencies.tsv or is it sufficient for it to be merged into master?
<jw4> (of the testing repo)
<perrito666> ericsnow: are you a full reviewer?
<ericsnow> perrito666: net yet
 * perrito666 needs a bureaucratic LGTM
<TheMue> dimitern: +1
<ericsnow> perrito666: OCR though
<perrito666> ericsnow: http://reviews.vapour.ws/r/873/
<jw4> perrito666: maybe TheMue can stamp it - it looks good to me
<TheMue> jw4: perrito666: already looking
<jw4> TheMue: cool
<perrito666> yeah we all know frank is getting free beer for that in april
<TheMue> perrito666: go for it, you've got a ship-it. and I'll remind you for the beer :D
<sinzui> jw4, yes, dependencies.tsv must be updated in juju/juju if you need a fixed package.
<jw4> sinzui: kk
<jw4> sinzui: fixes for the 1.22-beta3 milestone should be based on 1.22 branch I presume...
<sinzui> jw4, we need to fix 1.23, then fix 1.22 and 1.21. Each is a separate PR :(
<jw4> sinzui: lol - okay - so 1.23 --> master right? and I should do that first and then backport?
<TheMue> jw4: hangout?
<sinzui> jw4, yep
<jw4> TheMue: sorry - thought we were just doing irc today
<perrito666> and since we are on it https://github.com/juju/syslog/pull/1
<jw4> yeah, OCR PTAL https://github.com/juju/testing/pull/49 -- just a licensing update pr
<dimitern> TheMue, thanks!
<TheMue> dimitern: btw, I thought we already had feature freeze for 1.22, don't we? asking because of requirements for actions.
<TheMue> dimitern: and did you seen my question about the travel back I mailed to you and Alexis?
<dimitern> TheMue, yeah, but that's a potential critical issue fix
<TheMue> dimitern: finally btw the tests are working again and I'm now working on the exhausting of the available addresses :D
<dimitern> TheMue, yes, I'll ping her today for a response
<TheMue> dimitern: great, thanks
<dimitern> TheMue, sweet!
<perrito666> who owns juju/syslog ?
<dimitern> perrito666, cloudbase I think
<perrito666> dimitern: I doubt it, its in our repo :p
<dimitern> perrito666, it's forked from  gabriel-samfira/syslog
<dimitern> which is a bit weird
<dimitern> I haven't see this for other juju/* projects
<dimitern> seen* even
<perrito666> dimitern: it was made by cloudbase and added to our repo when we began merging windows
<dimitern> perrito666, right
<perrito666> dimitern: but whoever added this repo did not make us (the team) owners
<dimitern> perrito666, hmm
<dimitern> curious copyright line Copyright (c) 2014, Gabriel. All rights reserved. but it appears to be BSD/MIT
<perrito666> dimitern: what I am trying to commit fixes that
<perrito666> actually :p
<perrito666> that was github filling in the license when he created the repo
<dimitern> perrito666, ah :) I suspected
<perrito666> it now has the proper licence
<perrito666> dimitern: if you want to merge my pr is good enough for me
<dimitern> seriously? *lol* GH *is* too smart for its own good
<perrito666> you should be owner since you are part of the powers that be
<perrito666> dimitern: well it has a sort of a wizard when you create a repo
<dimitern> :)
<perrito666> mm, let me guess, the bot is still not on utils
<perrito666> I feel like an idiot
<TheMue> dimitern: do you know anybody in cape town able to help Aram with a kernel problem? asking on the standard canonical channels brought now response, only a hint to cape town
<dimitern> TheMue, ok, I'll ask
<TheMue> dimitern: great, thanks, will help him. his machine doesn't boot anymore after installing a new kernel
<TheMue> dimitern: as a hint => http://sprunge.us/OfFV
<natefinch> katco: you around?
<katco> natefinch: yup
<natefinch> katco: evidently there's a problem with goamz in the china north region, where it needs to use V4 for S3, but it's not: https://bugs.launchpad.net/juju-core/+bug/1415693
<mup> Bug #1415693: Unable to bootstrap on cn-north-1 <bootstrap> <ec2-provider> <online-services> <juju-core:Triaged> <https://launchpad.net/bugs/1415693>
 * katco looking
<natefinch> katco: note the linked github issue
<katco> natefinch: ah yes i remember now; the work was supposed to target aws specifically
<katco> natefinch: i remember being a little confused why we were using different signing everywhere
<katco> natefinch: so we made no effort to support s3 at the time i wrote that, do we now need to do that?
<natefinch> katco: sounds like we do. Some of our people are testing in China and need that to work there... they're supposed to go live by end of month, so sooner is better than later
<katco> natefinch: i will have to get clarification from ian on priorities, but if i remember, it shouldn't be too hard
<katco> natefinch: kind of a "redirect to master signing package" type thing
<natefinch> katco: I'll send an email to canonical-juju and make sure to ping Ian about it.  This sounds like it should probably be pretty high priority
<perrito666> mm, we should start branching things like utils when we branch juju for revs
<perrito666> backporting licence fixes is going to be an interesting PITA
<katco> natefinch: ok cool ty for the heads-up
<ericsnow> natefinch, perrito666, wwitzel3: standup?
<perrito666> natefinch: standup?
<perrito666> jw4: ?
<perrito666> https://github.com/juju/testing/pull/49 <-- why this patch changes the LICENCE file to AGPL?
<alexisb> natefinch, ericsnow we are having some iffy networking issues
<alexisb> I am hoping I can get into the hangout at the top of the hour but may not be able to
<alexisb> if I cant get in we may have to reschedule just fyi
<natefinch> alexisb: ok
<ericsnow> alexisb: k
<perrito666> jw4: ?
<sinzui> ericsnow, we will need to redeploy reviewboard. The current one will be kept alive, but you cannot change it
<sinzui> ericsnow, We will need to config you used to deploy it, or you can redploy it when juju-ci4 is ready
<ericsnow> sinzui: I should have some time for that today so just let me know when it's ready
<perrito666> mm, bad day for hardware
<perrito666> jw4: ping?
<TheMue> jamestunnicliffe: seen your PR. golang convention for function/method comments is in case of func Foo() { ... } starting the comment with the name: // Foo does this and that.
<jamestunnicliffe> TheMue: Ah, yes
<TheMue> jamestunnicliffe: you'v got a review
<alexisb> thank you ericsnow and natefinch !!
<ericsnow> alexisb: no, thank you :)
<wwitzel3> yeah, how'd that go?
<natefinch> went well I think.  Basically just clarifying expectations etc
<wwitzel3> nice
<TheMue> jamestunnicliffe: did you test your latest change? the renaming to the expected values isn't used, you use the old name in the assert
<jamestunnicliffe> TheMue: Sorry about that, enthusiastic push
<jamestunnicliffe> TheMue: Just running tests now
<TheMue> jamestunnicliffe: *lol* cool, np, it's a good feeling to get the first fix in
<jamestunnicliffe> TheMue: For some reason I can't swash the changes into one commit. Works locally, then github complains.
<jamestunnicliffe> TheMue: I guess you will cope!
<TheMue> jamestunnicliffe: how does it complain?
<jamestunnicliffe> TheMue: Updates were rejected because the tip of your current branch is behind its remote counterpart...
<jamestunnicliffe> TheMue: The usual fast forward error. Though after a pull, merge, squash the problem remains.
<jamestunnicliffe> TheMue: I can pull, merge, push. That is fine. Very odd.
<TheMue> jamespage: because of MY current branch?
<jamestunnicliffe> TheMue: no.
<TheMue> oh, addressed wrong james
<jamestunnicliffe> TheMue: It really isn't a problem. Just a bit untidy.
<TheMue> jamestunnicliffe: one of the weird situations when using git. sometimes I don't really understand it
<jamestunnicliffe> TheMue: About that comment about spacing, I used the same as the section above, so it may be strange, but it passes go fmt and is consistent :-)
<TheMue> jamestunnicliffe: go fmt won't complain, it's inside of the string. "http//http proxy" looks interesting. would have to look how it is used.
<TheMue> http://...
<jamestunnicliffe> TheMue: Oh, that. The previous test writers used "http proxy" and I stuck with it, though the http:// is added.
<TheMue> jamestunnicliffe:  yes, that's how I understood it too. the format containing a space isn't part of this change.
<voidspace> anyone know about the worker/runner infrastructure and care to answer a question?
<TheMue> it works and runs *duck* *scnr*
<voidspace> heh
<voidspace> TheMue: dimitern said that I need to change a worker to "return an error out of the loop" instead of just logging it
<voidspace> to do this do I have the method that gets the error call  ruw.tomb.Kill(err)
<voidspace> where ruw is the worker in question
<voidspace> ah no, the loop needs to actually return
<voidspace> so updateVersions returns the error
<voidspace> and the call in the loop returns that
<voidspace> easy-peasy
<voidspace> :-)
<TheMue> voidspace: this would kill it, yes
<voidspace> TheMue: once again, in the process of explaining the question I work out the answer :-)
<voidspace> TheMue: thanks for being my rubber ducky...
<TheMue> voidspace: has been a pleasure :)
<voidspace> :-)
<jamestunnicliffe> TheMue: Think I am ready for a re-review if you can. Then I have a daughter to cuddle :-)
<ericsnow> bogdanteleaga: I've left a lot of review comments, but many of them are there just to mark all the spots where previous comments apply
<ericsnow> bogdanteleaga: each one isn't some separate kind of problem that needs to be addressed :)
<TheMue> jamestunnicliffe: I'll take a look
<bogdanteleaga> ericsnow: I'm trying to find the syscall thing, but no luck :(
<TheMue> jamestunnicliffe: look good, ship-it
<bogdanteleaga> ericsnow: oh, now I see what you mean
<jamestunnicliffe> TheMue, voidspace: Have a good weekend! I'm off for the evening. See you Monday/Tuesday.
<TheMue> jamestunnicliffe: enjoy your evening and weekend too, see you then
<jw4> perrito666: back
<jw4> perrito666: there was no clear license
<perrito666> jw4: github says you removed lgpl and added agpl
<jw4> perrito666: the existing file 'LICENSE' was lgpl, but all the source files referenced 'LICENCE'
<jw4> perrito666: the two files from the bug referenced LICENSE
<jw4> but, the LICENSE file wasn't the golang license
<jw4> perrito666: since the testing files were moved out of juju-core, I figured the right license was the one from juju core (especially since the name in all the source files was LICENCE like the juju-core one
<perrito666> jw4: I can positively say you just confused me
<jw4> the file I removed was not being referenced by any of the source files
<jw4> perrito666: except the two referenced in the bug
<jw4> perrito666: and the file I removed was wrong per the bug for those two files
<jw4> perrito666: all of the source files referenced a non-existent 'LICENCE' (spelled with a C) file
<jw4> perrito666: which used to point to the LICENCE file in juju-core before testing was split to it's own repo
<jw4> perrito666: any better ? :)
<perrito666> jw4: I see
<perrito666> so the part of go licence is good
<perrito666> but, you removed the mispelled license and added licence
<perrito666> and those have different licence texts inside
<perrito666> the thing is
<perrito666> if you look at the files
<perrito666> https://github.com/juju/testing/blob/master/cleanup.go
<perrito666> they expect that licence file to be lgplv3
<jw4> perrito666: I see
<jw4> perrito666: I assumed that was part of the big re-licensing change a few months ago
<jw4> perrito666: my understanding was that testing was split out before core was cleaned up
<perrito666> natefinch: care to weight on that?
<jw4> perrito666, natefinch it looks like LICENCE in core has always been affero
<jw4> perrito666: so maybe the fix is to update all the testing files to point to the LICENCE file and revert the changes in that file
<jw4> perrito666: er, not updating the testing files, just moving LICENSE to LICENCE
<perrito666> yep
<jw4> perrito666: look better now? https://github.com/juju/testing/pull/49
<perrito666> jw4: totally
<jw4> perrito666: w00t
<perrito666> could you be a sport and make sure that all files have either go or lgpl licences?
<jw4> perrito666: heh - yes I'll be a sport
<perrito666> sorry there is a brittish fellow living inside me :p
<jw4> perrito666: yeah, me too
<mgz> sillies :)
<jw4> perrito666: yep all licensed
<perrito666> sweeet
<perrito666> mgz: oh, just in time to lgtm jw4 proposal
<jw4> mgz: jolly good show
<jw4> here now mgz; popping in with a bit of wit and then disappearing is not cricket!
<jw4> mgz: if you come back you can make fun of Americans? Or South Africans? Or Argentinians?
<mgz> you really can't, you can only mock in the reverse of colonial history, otherwise it's just picking on people :0
<jw4> mgz: hehe
<natefinch> perrito666, jw4: license for juju core itself is agpl.. the license for "libraries" outside of core should be lgpl... where exactly we draw the line between what is and is not core is kinda fuzzy
<jw4> natefinch: cool
<jw4> natefinch: that's where this PR ended up so that's good
<natefinch> (also note, lgpl is actually lgpl with Canonical's special static linking exception, which is required since Go always static links)
<jw4> natefinch: interesting.
<jw4> natefinch: do you care to review and possibly stamp https://github.com/juju/testing/pull/49
<jw4> natefinch: it's work for one of the bugs sinzui is hoping to be addressed for 1.22-beta3 release
<jw4> perrito666: woot :)
<perrito666> jw4: I say LGTM, given the hurry that is enough
<perrito666> :p
<natefinch> jw4: right.  I do wish we'd just put these files in a separate repo or something.... but I think this is good enough for now.
<jw4> natefinch: cool, tx
<jw4> natefinch: (perrito666) http://reviews.vapour.ws/r/880/ <-- dependencies update with change
<perrito666> jw4: I am superseeding you  with a patch including several of those licencing fixes
<jw4> perrito666: score
<jw4> I'll close mine
<perrito666> just running the whole test suite before
<perrito666> to make sure the version jump didnt break anything
<jw4> perrito666: I ran the tests on my change already
<perrito666> jw4: well I am packing other two :D
<jw4> perrito666: overachiever
<perrito666> jw4: I have a dedicated machine for that nevertheless
<perrito666> that makes things faster
<jw4> perrito666: my change has to be backported to 1.22 and 1.21 - will you bundle that too?
<perrito666> jw4: yup, all of those have to
<perrito666> sinzui: natefinch question
<jw4> perrito666: I have a m3.2xlarge instance on ec2 that kicks the tests out in about 8 minutes
<perrito666> when we create a release branch
<perrito666> why dont we create a branch for the dep libraries that are ours?
<perrito666> jw4: I have a corei5 with 8 gigs of ram downstairs :p
<jw4> yeah - I was nervous about that too
<perrito666> as a laptop it sucks because It is bulky but as a compile machine it rocks
<jw4> perrito666: sweet
 * TheMue likes his i7 / 16 Gig / SSD combination ;)
<jw4> TheMue: show-off
<jw4> ;)
<perrito666> TheMue: try to get one of those in argentina :p
<voidspace> right EOW
<voidspace> see you all on Monday
<TheMue> perrito666: why not? not available or too expensive
<TheMue> voidspace: me too, only cannot close chat *lol*
<voidspace> heh
<TheMue> voidspace: but have already wine beside me
<voidspace> switch off the computer...
<voidspace> nice
<voidspace> TheMue: enjoy, see you on Tuesday
<perrito666> TheMue: both, but the first specially
<TheMue> voidspace: yess, see you then. enjoy your weekend too
<sinzui> perrito666, a branch for each dep? or a branch that included a dependencies.tsv of what we officially use?
<TheMue> perrito666: interesting, didn't expected this
<perrito666> sinzui: a branch for each dep, like utils should have a 1.21 branch/tag
<perrito666> when backporting fixes to our own deps that poses an interesting problem
<sinzui> perrito666, That might have bad consequences from Ubuntu's perspective, but worth talking about
<jw4> sinzui: you mean maintenance costs?
<perrito666> sinzui: well if I have to, say backport a fix for something that is in utils, because it is broken in 1.21 and 1.21 is using an old rev of utils, I will need to do a branch anyway
<ericsnow> jw4: what does "darwin" use for an init system?  something cooked up by Apple?
<sinzui> perrito666, I think you suggest that dependencies.tsv points to a tag instead of a hash. We update the tag when we want to change the rev that godeps will select
<perrito666> sinzui: yes, that works
<jw4> ericsnow: good question - I don't know the official answer, but on my machine it seems to be a custom launchd thing
<ericsnow> jw4: yeah I figured as much :)
<jw4> ericsnow: :)
<sinzui> perrito666, but since we are not tracking the exact revision used to make the release tarball. that means it is not possible to recreate an older juju rev in the same series
<sinzui> perrito666, 1.21 build 5 works, but the tag is changed. I do a rebuild to test (build 6) and I get a different package with possibly different results
<sinzui> perrito666, I will see the dep changed if I diffed the tarball, but I wouldn't know why juju choose the change.
<sinzui> perrito666, so while I like your idea for its convenience, it undermines our need to repeatability.
<perrito666> sinzui: well right now I have to push a change to 1.21 that fixes deps, lets see how easy to do this is
<jw4> perrito666: basically as long as there are no breaking changes in the updated deps we'll get lucky - otherwise a real hassel
<perrito666> jw4: yes, that is the thing, I dont like to rely on luck
<jw4> ditto
<jw4> (but I'll take it if it comes!)
<sinzui> perrito666, I would argue that core is branching too early. There are too many branches. I think unstable and stable are enough.
<perrito666> sinzui: the thing is, we have, lets say 1.21, which depends on utils 1, syslog 3 and whatever 4
<perrito666> and I need to fix something on utils that breaks 1.21
<perrito666> but utils is now in version 5
<perrito666> so, I really dont want to include 2,3 and 4 into 1.21
<sinzui> perrito666, ah
<sinzui> perrito666, that is a nasty combination. We need a lot of branches in that scenario
<perrito666> sinzui: that is our current combination
<perrito666> sinzui: right now I need to backport a licence change in serveral deps to 1.21
<perrito666> that should be fun for non functional changes
<perrito666> anyone http://reviews.vapour.ws/r/881/ >?
<perrito666> I will take lgtm even from mup at this stage
 * jw4 impersonates mup
<jw4> <mup>: LGTM
<perrito666> ericsnow: tx
<perrito666> mm this makes no sense, in github the current commit for 1.21 for utils is not marked as being part of master but in my local version it does
<perrito666> sinzui: natefinch so, the issue now, 1.21 is pointing to a rev of utils from dec 11, and I need to apply my changes to 1.21 (the changes are in utils licencing) so is it ok if I create a 1.21 brach, apply them there and then point 1.21 to that?
<perrito666> I hear alternatives
<sinzui> perrito666, I think the 1.21 branch is the best option
<sinzui> perrito666, sorry. It is work, but at least the branch clearly indicated why it exists
<perrito666> no prob, I inteded to do that
<perrito666> sinzui: flaky test? http://juju-ci.vapour.ws:8080/job/github-merge-juju/2045/console
<sinzui> perrito666, I think it is a flaky test.
<natefinch> perrito666: I think sinzui answered your question?  Sorry, was snowblowing (yes, again... only 4" today, but enough to turn into ice after I drive over it).  Mother nature is making up for not giving us any snow until the end of January, evidently
<sinzui> natefinch, Surely you will be getting show into March.
<perrito666> natefinch: isnt snowblowing something you do often enough to be worthy of automation?
<sinzui> natefinch, Do you hands hurt now?
<natefinch> perrito666: like a roomba for the snow in the driveway?  Brilliant
<sinzui> Oh, I like hat idea. I would like that for my sidewalks too
<natefinch> sinzui: nah... sweaty and tired, but no pain.  Ironically, overheating is way more of a problem than getting cold when I snowblow, unless it's near 0 F
<thumper> o/
<jw4> thumper: \o
<perrito666> natefinch: seems like something you could fix by making the driveway floor a trapdoor over a big hole with salt
 * perrito666 just broke his bread machine so did the bread by hand... I am much better than the machine
<natefinch> perrito666: kudos
<perrito666> who will rubberstamp this? http://reviews.vapour.ws/r/882/
<perrito666> natefinch: although I prefer the machine in terms of not having to do anything else than adding ingredients into a bowl
<natefinch> perrito666: haha yeah... it's weird, ours used to work well, and then suddenly the bread started not to rise enough.... far as I can tell, we didn't do anything different.  Made me sad, I love fresh baked bread.... though now that I've used my stand mixer to make bread a few times, I don't think it's actually that much more work.
<perrito666> I made mine by hand
<perrito666> so it is some degree of work
<perrito666> I just hate having to remember that my bread is raising and that it needs to raise a second time
<perrito666> my machine died in an odd manner, apparently the cogs (plastic) got too dry and they disintegrated
<perrito666> cmooon, who wants this 3 line change? http://reviews.vapour.ws/r/882/ its a great oportunity to review without much effort
<natefinch> ooh ooh, credit without effort, I'm all over it
<perrito666> god boy, here have a slice of bread
<natefinch> updating the libraries didn't require changing core at all?
<perrito666> nope, I actually only added licence changes
<perrito666> I sent an email about that
<natefinch> email, who reads that crap?
<natefinch> ship it!
<perrito666> ericsnow: dependencies.tsv for 1.21 did not have the stamps apparently
<ericsnow> perrito666: ah, I totally missed that it was for 1.21 :)
 * perrito666 looks at juju bot while tapping his fingers on the desk
<perrito666> this is bad, https://www.techdirt.com/articles/20150205/11373529920/worlds-email-encryption-software-relies-one-guy-who-is-going-broke.shtml
<perrito666> we should donate to the poor guy
<perrito666> sinzui: my changes have been committed to 1.21, it as no more licencing issues
<perrito666> I need to step out for a moment, upon returning, 1.22
<natefinch> perrito666: yeah, it's a damn shame that there's so many companies and governments that rely on this kind of software and can't be bothered to spend .0000001% of their budget to give money to the people that maintain it
<perrito666> well this particular software we use A LOT
<natefinch> perrito666:  â@stripe 6 minutes ago: Stripe and Facebook are going to sponsor @gnupg development with $50k/year each.
<hatch> natefinch: just saw that - that's great news, I was really surprised that it wasn't already sponsored by a group of companies
<natefinch> hatch: totally
<waigani> thumper: http://reviews.vapour.ws/r/883
#juju-dev 2015-02-06
<mattyw> morning folks, I get the following error in the tip of juju/errors - is it just me or can someone else see it?
<mattyw> ^^ not gccgo
<anastasiamac> mattyw: what error?
<mattyw> anastasiamac, ah - dammit - sorry forgot to past the paste :/
<mattyw> anastasiamac, http://paste.ubuntu.com/10085832/
<mattyw> anastasiamac, sorry - it's still early (1:44pm)
<anastasiamac> mattyw: m running with juju/errors that juju/juju depended on yesterday
<anastasiamac> mattyw: and get
<anastasiamac> mattyw: ok      github.com/juju/errors  0.008s
<mattyw> anastasiamac, what version of go?
<mattyw> anastasiamac, (starting to clutch at straws now :) )
<anastasiamac> mattyw: go version go1.2.1 linux/amd64
<mattyw> anastasiamac, ok - I might try running an earlier version and see what happens, it's not blocking me,  just an observation
<mattyw> I'll keep an eye on it though
<anastasiamac> :D
<mattyw> davecheney, done https://github.com/juju/errors/pull/16
<axw> dimitern: nice logo :)
<dimitern> axw, :) it took 15m
<dimitern> axw, yeah I think goose deserves a logo now heh
<axw> katco: FYI, https://github.com/go-goose/goose
<axw> dimitern: katco has some Cinder support in the works
<axw> dimitern: and what she's doing is auto-generating bindings off WADL provided by OpenStack. may be useful to use more generally
<dimitern> axw, oh, ok - I'll sync up with her next week then
<dimitern> my current plan is to just migrate existing trunk to GH and change imports to use gopkg.in
<dimitern> axw, katco ^^
<axw> dimitern: no worries, that's what I expected
<dimitern> axw, ok, cheers
<dimitern> we'll use gated merges as well with the bot like for juju/juju
<axw> dimitern: not using Travis?
<dimitern> axw, nope, I really don't want to, if it can be avoided
<axw> okey dokey
<dimitern> axw, our merge bot does a more consistent job I think
<dimitern> (a bit of handwavyiness here ofc.. :)
<axw> dimitern: I'm happy with that, was just wondering if this would be handled the same as go-amz
<dimitern> axw, I got bashed a bit for taking this decision frankly (travis over our bot) and want to do it "properly" this time :)
<axw> dimitern: I see :)
<frankban> dimitern: morning, I was looking at this regression we have on the GUI: bug 1418433
<mup> Bug #1418433: unit information pane lost port information <juju-gui:Triaged> <https://launchpad.net/bugs/1418433>
<frankban> dimitern: it seems that newer versions of juju-core no longer populate the unit ports in the mega-watcher. unitDoc.Ports is also marked as no-longer used, but it's still used by the mega-watcher
<frankban> dimitern: note that this breaks API backward compatibility
<dimitern> frankban, hey, I was afk for a while, reading back
<dimitern> frankban, unitDoc.Ports is no longer there (or at least no longer used)
<dimitern> frankban, but i'll have a look to recall what should've be used instead
<frankban> dimitern: it's no longer populated, and assumed to be no longer used, but instead it's still used by the megawatcher for units
<frankban> dimitern: and therefore it's always empty
<frankban> dimitern: I guess we should use unit.OpenedPorts(), but that would still be a backward incompatible API change
<frankban> dimitern: because the ports are now ranges (FromPort/ToPort) while before they were just numbers (Number)
<dimitern> frankban, fair point
<dimitern> frankban, we should fix this to be wire-format-compatible
<dimitern> frankban, but by doing this we'll lose some precision - if from=to port, that's fine, if not - what?
<frankban> dimitern: we could make the mega-watcher use an ad-hoc function that return a slightly different slice of port ranges, in which we have both the From/To and the Number, in the case From==To
<dimitern> frankban, and the gui should definitely use unit.OpenedPorts to get them
<dimitern> frankban, I mean .. it should expect port ranges at least
<frankban> dimitern: the GUI uses the mega-watcher to get them, so we need to modify the mega-watcher to call OpenedPorts, and then maybe modify the result as I described
<dimitern> frankban, ah, that's a good idea - adding PortRanges to the MW changes struct for units
<frankban> dimitern: yes, we need a fix to the GUI too, but introducing a Number in the struct returned by the mega-watcher would make it easy for the GUI to be backward compatible, i.e. if there is a number, use that, otherwise handle the range
<dimitern> frankban, so the Ports *can* be wrong, but PortRanges slice won't be
<dimitern> frankban, thanks for the heads up, I'll tackle this with priority
<frankban> dimitern: I can help if you want
<dimitern> frankban, I need to have a chat with william first, but I'll get back to you
<frankban> dimitern: ok thanks
<frankban> dimitern: anyway, something like this prototype would work, with a subsequent change to the GUI: https://github.com/frankban/juju/compare/restore-megawatcher-unit-ports?expand=1
<perrito666> hi, anyone in for a trivial text only rev https://github.com/juju/testing/pull/50 ?
<dimitern> frankban, ok, so I'm filing a bug about it first, then I have a clear plan how to fix it in a backwards compatible way
<dimitern> perrito666, reviewed
<dimitern> frankban, unfortunately what you're suggesting is not sufficient, as it introduces another change into the struct format
<perrito666> dimitern: tx done
<frankban> dimitern: I know it's still backward incompatible, but it can be good enough for the GUI, which is your main API consumer
<dimitern> frankban, I'd rather have a new PortRanges slice field and revert Ports to how it was, while having a piece of code that converts from=to ranges to ports and drops the rest
<frankban> dimitern: sounds good, at that point no change is required GUI side
<dimitern> frankban, exactly; ok, cheers
<frankban> dimitern: thanks for looking at that, could you ping when you have a fix?
<perrito666> dimitern: same thing for utils?
<dimitern> perrito666, what thing?
<perrito666> dimitern: If I where a smarter person, I would not have forgotten to paste the link
<perrito666> https://github.com/juju/utils/pull/113
<dimitern> perrito666, :)
<dimitern> perrito666, lgtm
<perrito666> ta
<perrito666> lool, did yo see what shows in github when you say :shipit:  ?
<dimitern> perrito666, I saw but couldn't quite get it
<dimitern> is it a mob-frog of some sort?
<perrito666> looks like a squirrel with a hat
<perrito666> oh is it a frog?
<dimitern> ha, could be :)
<dimitern> ok, gtg - CPT sprint is officially over
<perrito666> dimitern: cheers
<dimitern> ta ;)
<jw4> perrito666, dimitern: Ship It Squirrel - added to github - https://github.com/github/hubot-scripts/commit/247310f83e8f0a33230c4a2ceb5e68ca86006e18
<perrito666> ok, las licencing fix, I promisse http://reviews.vapour.ws/r/889/
<hazmat> anyone around with mongodb knowledge jujuer on #juju has an interesting bootstrap error http://paste.ubuntu.com/10092884/ please come over there
<perrito666> rogpeppe: I didnt parse half of your mail
<rogpeppe> perrito666: sorry, my fault, i've had beer :)
<perrito666> I do agree though that we could/should move to gopkg.in yet that does not change the fact that our internal repo should branch when this happens (as I did)
<perrito666> rogpeppe: I envy you, I had wather only
<rogpeppe> perrito666: is wather low alcohol?
<rogpeppe> perrito666: ( :-) )
<perrito666> dont try wather, is terrible, produces oxidation :p
<rogpeppe> perrito666: what do you mean by "our internal repo"?
<perrito666> well, see, when we tag juju for release, lets say 1.21
<perrito666> we deppend on a set of versions of ilbraries
<perrito666> that we support ourselves
<perrito666> like juju/utils or juju/testing
<rogpeppe> perrito666: ok
<perrito666> so, as development advances for new versions, these all grow in code but we keep maintaining 1.21
<rogpeppe> perrito666: ok
<perrito666> so at some point we will neet to backport a dependency fix to 1.21, say a licence issue
<perrito666> and there you have two options, you add that fix on top of the dependency and make 1.21 deppend on that, with a subset of unknown/unwanted changes in the dependency
<rogpeppe> perrito666: is that a problem?
<perrito666> or, branch the dependency at the point that is used in 1.21 and apply changes there
<rogpeppe> perrito666: (option 2, that is)
<perrito666> rogpeppe: exactly that
<rogpeppe> perrito666: the only time i can think it would be a problem is if the dep hasn't changed in a backwardly compatible way
<perrito666> that was the case
<rogpeppe> perrito666: right
<rogpeppe> perrito666: that's why i'm suggesting the use of gopkg.in
<perrito666> but if it wherent and the distance is too big, you are adding a lot of unwilling changes to a minor release which is a bit icky
<rogpeppe> perrito666: i don't think it should be
<rogpeppe> perrito666: backwardly compatible should be backwardly compatible
<rogpeppe> perrito666: and maintaining forks is a significant use of time and resources
<perrito666> well, they are called maintenance branches for something, you just add whatever fix you backport to those or close them :p
 * perrito666 ponders having beer to stop mosquitoes from bitting him
 * rogpeppe accepts another beer
<rogpeppe> IPA is dead: citra
<rogpeppe> mmm
 * perrito666 settles for mosquito repellent
<rogpeppe> perrito666: the more branches the more effort and the more likelihood of getting things wrong between branches, in my experience anyway.
<perrito666> rogpeppe: Â¯\_(ã)_/Â¯
<rogpeppe> perrito666: that looks rude to me
 * perrito666 suspects that the fonts dont translate the message too well :(
<perrito666> rogpeppe: its a very strange not really ascii face for "yup, what to do about it"
<perrito666> I now realize I only know the expression in spanish :p which means it might not go past local boundaries
<rogpeppe> perrito666: ah, it's a face! i thought it looked like legs... :)
<perrito666> rogpeppe: the face seems to be a pretty odd unicode character
<perrito666> rogpeppe: something that, thinking of it, most people not having a language that needs of it might not have installed
<rogpeppe> perrito666: my suggestion is that we move to gopkg.in and always update to the latest branch of any package whenever possible
<rogpeppe> perrito666: no, the character worked
<perrito666> rogpeppe: even though we might be backporting a load of changes as a collateral?
<rogpeppe> perrito666: yes
<rogpeppe> perrito666: because we should guarantee backward compatibility
<perrito666> its a bit like: hey I fixed the typo on the kernel, lets release a minor... and you might have a news scheduler too
<rogpeppe> perrito666: for gopkg.in branches
<rogpeppe> perrito666: we're talking about deps here, not core functionaliryt
<rogpeppe> ity
<rogpeppe> perrito666: if deps implement extra (backwardly compatible) core functionality, then why not?
<rogpeppe> perrito666: i don't really understand what your real concern is here? increased binary size?
<perrito666> rogpeppe: not really, I think my concern is mostly bureaucratic so I should drop it
<rogpeppe> perrito666: if using the latest version turns out to be a problem in practice, we always have the *option* of forking it
<perrito666> about bugs and the probability of those being added when adding code there
<perrito666> rogpeppe: agreed there
<perrito666> rogpeppe: btw, the icon -> http://s3-ec.buzzfed.com/static/2014-05/enhanced/webdr07/21/15/enhanced-29943-1400699227-1.jpg
<rogpeppe> perrito666: hopefully, later versions of the same package should remove bugs, not add them...
<rogpeppe> perrito666: :)
<rogpeppe> perrito666: the emoticon looked correct in my IRC client
<perrito666> rogpeppe: then your internal emoticon interpreter does not really work :p
<rogpeppe> perrito666: yeah, i think i need an upgrade
<perrito666> I have seen some machines render a square for some of those
<perrito666> rogpeppe: I meant to ask in brusselles, what was the editor you where using, at first it seemed like a heaviy customized vi, but then I doubted
<rogpeppe> perrito666: http://en.wikipedia.org/wiki/Acme_%28text_editor%29
<rogpeppe> perrito666: this is a nice intro: https://www.youtube.com/watch?v=dP1xVpMPn8M
<rogpeppe> perrito666: there is a small but select group of people that use it :)
<perrito666> Well Ill take you on the small :p
<rogpeppe> perrito666: it's actually kind of the opposte of vi
<perrito666> do you use a linux port or run plan9?
<rogpeppe> opposite
<rogpeppe> perrito666: i'm currently using trusty
<perrito666> rogpeppe: the opposite of vi is emacs :p I have been in countless flamewars about the subject
<rogpeppe> perrito666: actually the reason vi and emacs inspire flamewars is that they are similar
<rogpeppe> perrito666: like how the worst religious wars are between related faiths
<perrito666> I attribute the amount of flame on those to the fact that they attract people who like to flame
 * perrito666 goes for the intro on video
<wwitzel3> when you combine rogpeppe with beer it gives him great power and he will attempt to lure you to the darkside, don't fall for it perrito666
<rogpeppe> lol
<perrito666> wwitzel3: lool, well for starters that editor seems to require for me to use a mouse
<rogpeppe> actually, lololololol
<perrito666> which sits at more than an arms lenght from where I sit
<perrito666> so no chance :p
<rogpeppe> perrito666: the mouse is an instrument of the Force
<perrito666> rogpeppe: the xbox kinect is an instrument of the force, the mouse is too far
<rogpeppe> perrito666: but seriously, the mouse transmits more information than a keyboard
<perrito666> rogpeppe: I could do with a touchpad :p
<perrito666> rogpeppe: well I do have a layout set for keyboard mostly, which makes  the mouse a bit irrelevant, I only use it when using things like inkscape or gimp
<rogpeppe> perrito666: i use it quite successfully with a thinkpad nipple
<rogpeppe> perrito666: i know people that use it successfully with a touchpad (and some keys set up for button chording)
<perrito666> rogpeppe: yup, I like the thinkpads thinguie, but all of my thinkpads kbs are in es_ES which sucks for coding, next trip to an english speaking country ill get a thinkpad wireless kb
<rogpeppe> perrito666: but the mouse power is probably the essence of acme
<rogpeppe> perrito666: just change the keyboard layout and don't look at your fingers
<perrito666> rogpeppe: the shape is different sadly
<rogpeppe> perrito666: orly?
<perrito666> spanish kb lacks |\
<perrito666> it has a large return instead
<rogpeppe> perrito666: that's a bit rubbish
<perrito666> I currently use an apple blueetooth kb
<perrito666> not wonderful but light and en_US
<rogpeppe> perrito666: well, that's a reasonable option
<rogpeppe> perrito666: anyway, acme is the embodiment of mouse-is-faster-than-keyboard. http://www.asktog.com/TOI/toi06KeyboardVMouse1.html
<perrito666> yup, borrowed from a friend that became a full time manager and suddenly lost need for his coding station :p
<rogpeppe> perrito666: and it really does seem to work (for me anyway :-])
<perrito666> I wont counter a man that can succesfully climb a palm tree while drunk
<rogpeppe> success is in the eye of the beholder
<perrito666> rogpeppe: well you did not fall or get arrested, that is success
<rogpeppe> perrito666: in which case i am succeeding all the time, wa hay!
<perrito666> I cant believe you do that often and not get arrested of fall
<rogpeppe> perrito666: i am not falling or getting arrested
 * rogpeppe wonders why the video is a query parameter on the youtube video url
<perrito666> rogpeppe: it is a curious choice
<rogpeppe> perrito666: it makes a mockery of REST :)
<perrito666> well, they never said it was restful :p
<rogpeppe> perrito666: and in the end, who cares?
<perrito666> rogpeppe: well I do, I like nice urls :)
<rogpeppe> perrito666: "?" "/" ... what's the difference in the end?
#juju-dev 2015-02-08
<bodie_> "unexpose" doesn't seem to be doing anything on digitalocean via JuDO; is this a known issue?
<bodie_> ah, according to the doc it looks like expose triggers a hook which is expected to implement the desired effect
#juju-dev 2016-02-08
<cherylj> hey wallyworld, looks like there's a windows unit test failure on master from the new xdg home dir work:  http://reports.vapour.ws/releases/3580/job/run-unit-tests-win2012-amd64/attempt/1891#highlight
<wallyworld> cherylj: ok, will look. we really need to gate on windows unit tests. not sure why we don't yet
<cherylj> yeah, would be nice
<wallyworld> we have been talking about it for months and months
<cherylj> just hasn't made it to the top of their list of priorities, I guess
<wallyworld> yeah. seems like a small change for a big win though
<wallyworld> axw: a small tweak to fix windows unit tests http://reviews.vapour.ws/r/3763/
<axw> wallyworld: are we trying to use XDG things on Windows? :/
<wallyworld> axw: no, there's a separate func to get the right location, but the tests have always been linux specific
<axw> ok
<wallyworld> axw: on windows, it's %APPDATA%/juju
<axw> wallyworld: done
<wallyworld> ty
<axw> wallyworld: ok, thanks
<cherylj> oh god, so many test failures.  My eyes!  MY EYES!!
<cherylj> wallyworld, perrito666, so did the new juju home stuff break out JUJU_HOME into JUJU_DATA and something else?
<cherylj> because it looks like CI wasn't
<wallyworld> cherylj: JUJU_DATA replaces JUJU_HOME, but it will default to something sensible. if CI uses JUJU_HOME, then i'll need to back out that change
<wallyworld> or i might set JUJU_DATA to JUJU_HOME till CI is updated
<cherylj> wallyworld: that sounds like a good compromise.  I'll bring it up to the QA guys in the morning
<wallyworld> ok. i'll do that now
<cherylj> thanks, wallyworld!
<wallyworld> sure, sorry about the breakage
<wallyworld> axw: another small one http://reviews.vapour.ws/r/3764/
<axw> wallyworld: done
<wallyworld> ty
<axw> wallyworld: whenever you're ready: http://reviews.vapour.ws/r/3765/
<wallyworld> sure
<wallyworld> axw: how much smaller is asn encoding vs json?
<wallyworld> did it make much of a difference?
<axw> wallyworld: it was reasonably significant. I can't recall the overhead exactly. I can measure again if you like
<wallyworld> no need, just curious
<wallyworld> axw: a couple of small things
<wallyworld> axw: when you are free, another trivial http://reviews.vapour.ws/r/3767/
<davecheney> what's changed now ? https://bugs.launchpad.net/juju-core/+bug/1542985
<mup> Bug #1542985: Juju won't switch environments <juju-core:New> <https://launchpad.net/bugs/1542985>
<davecheney> axw: wallyworld what has juju switch been renamed to ?
<wallyworld> davecheney: that one stays the same
<wallyworld> let me double check
<davecheney> see linked bug
<wallyworld> yup, stays as switch
<davecheney> why can't I change to ap-southeast-2 anymore
<wallyworld> hmmm, haven't see that bug till now
<davecheney> it's there in juju/environemnts.yam
<davecheney> it's there in juju/environemnts.yam
<davecheney> it's there in juju/environemnts.yaml
<wallyworld> it's supposed to work
<wallyworld> something broke :-(
<davecheney> lucky(~/src/github.com/juju/juju) % juju bootstrap -v --debug
<davecheney> 2016-02-08 06:15:41 INFO juju.cmd supercommand.go:59 running juju [2.0-alpha2 gc devel +fa5e547 Sun Feb 7 03:18:28 2016 +0000]
<davecheney> 2016-02-08 06:15:41 ERROR cmd supercommand.go:448 the name of the model must be specified
<davecheney> lucky(~/src/github.com/juju/juju) % juju bootstrap -v --debug ap-southeast-2
<davecheney> we really hate our users
<davecheney> error: unrecognized args: ["ap-southeast-2"]
<davecheney> lucky(~/src/github.com/juju/juju) % juju bootstrap -v --debug -m dev
<davecheney> 2016-02-08 06:16:36 INFO juju.cmd supercommand.go:59 running juju [2.0-alpha2 gc devel +fa5e547 Sun Feb 7 03:18:28 2016 +0000]
<davecheney> 2016-02-08 06:16:36 ERROR cmd supercommand.go:448 open /home/dfc/.local/share/juju/environments.yaml: no such file or directory
<wallyworld> juju home has changed
<wallyworld> i'm in the process of updating release notes
<wallyworld> it only landed on the weekend i think
<axw> davecheney: FYI, in the near future we will completely ignore environments.yaml
<wallyworld> just copy ~/.juju to ~/.local/share/juju
<axw> more info later
<davecheney> lucky(~/.local/share) % ls -al . | grep juju
<davecheney> lrwxrwxrwx  1 dfc dfc    15 Feb  8 17:18 juju -> /home/dfc/.juju
<davecheney> problem solved
<wallyworld> ~/.juju will be ignored in a day or so
<wallyworld> as soon as CI is updated
<wallyworld> then it will be ~/.local/share/juju
<davecheney> looks like it's being ignore now
<wallyworld> i landed a change maybe 2 hours ago to temporarily use it
<wallyworld> until CI is fixed
<wallyworld> so just copy stuff to ~/.local/share/juju to be future proof
<davecheney> commit fd9cd4bc60d55571ce2db8562462703ed3baa228
<davecheney> Author: Ian Booth <ian.booth@canonical.com>
<davecheney> Date:   Mon Feb 8 14:41:59 2016 +1000
<davecheney> Fall back to JUJU_HOME if JUJU_DATA not set
<davecheney> yup, i have that rev
<wallyworld> you need $JUJU_HOME set
<wallyworld> that's what it falls back to
<davecheney> 2016-02-08 06:20:42 DEBUG juju.provider.common bootstrap.go:318 connection attempt for 54.79.164.245 failed: Warning: Permanently added '54.79.164.245' (ECDSA) to the list of known hosts.
<davecheney> /var/lib/juju/nonce.txt does not exist
<davecheney> 2016-02-08 06:20:48 DEBUG juju.provider.common bootstrap.go:318 connection attempt for 54.79.164.245 failed: /var/lib/juju/nonce.txt does not exist
<davecheney> ^ these won't exist
<davecheney> my user has no permission to write to those locations
<wallyworld> right, but that's not what we're taling about
<wallyworld> it's the XDG data home
<davecheney> ok
<wallyworld> as opposed to XDG config home
<wallyworld> or XDG runtime home etc
<mup> Bug #1542985 opened: Juju won't switch environments <juju-core:New> <https://launchpad.net/bugs/1542985>
<mup> Bug #1542988 opened: bootstrap tries to write to /var/lib/juju on local machine <juju-core:New> <https://launchpad.net/bugs/1542988>
<wallyworld> oh yuk
<wallyworld> really?
<wallyworld> what provider
<davecheney> ec2
<wallyworld> the nonce.txt is written by cloud init i believe
<wallyworld> the bootstrap client has never used that file
<axw> yes, written by cloud-init. bootstrap looks for it to check that cloud-init has finished
<wallyworld> how the fark it is getting written locally i'm not sure
<davecheney> maybe that error is leaking through from the remote side
<axw> wallyworld: PTAL
<wallyworld> sure
<wallyworld> axw: lgtm. we need to double check that a newly added user on a controller only has access to the models they create or are shared with them. i can't recall whether in the initial poc done with the initial jes work all users had admin access on the controller or not
<mup> Bug #1542990 opened: tools version checker restarts every 3 seconds <juju-core:New> <https://launchpad.net/bugs/1542990>
<mup> Bug #1542992 opened: ec2: destroy-controller causes rate limiting failure <juju-core:New> <https://launchpad.net/bugs/1542992>
<axw> wallyworld: yep. I did test, but not very rigorously, and it appeared to be checking access
<wallyworld> axw: ok, we'll need to ensure going forward it works as we hope
<wallyworld> axw: if you get a chance at some point, could you take a another pass at http://reviews.vapour.ws/r/3737/ now that it's been updated?
<axw> wallyworld: yup, was about to, just fixing my branch
<wallyworld> awesome ty
<axw> wallyworld: what would you call the combination of controllers.yaml, accounts.yaml, models.yaml (sic), etc.? currently called "Cache" in that branch, but it doesn't sit well with me
<axw> wallyworld: only the model info is really a cache
<wallyworld> axw: agreed
<wallyworld> um
<wallyworld> LocalControllerState  ?
<wallyworld> it's local to that machine, it's related to controllers (and accounts for those), and it's state cached in memory or on disk
<wallyworld> naming is hard :-)
<axw> wallyworld: a bit better, but I'm not completely sold on that either. I'll think about it for a bit.
<wallyworld> yeah, i wasn't that happy with that suggestion
<axw> wallyworld: I'm thinking ControllerStore, NewFileControllerStore, NewMemControllerStore, DefaultControllerStore
<wallyworld> hmmm, that works
<axw> wallyworld: along the lines of existing configstore
<wallyworld> it's similar to what's there
<wallyworld> yup
<anastasiamac_> wallyworld: axw: my problem with "store" is that its prime meaning is not "storehouse, warehouse" but actually is closer related to "retail"
<anastasiamac_> apart from that - i'm phased at all.. whatever
<wallyworld> disagree :-)
<wallyworld> in computer terms, store ahas a well defined meaning
<anastasiamac_> m not*
<dimitern> wallyworld, hey there
<wallyworld> hey
<dimitern> wallyworld, re that juju home 2.0 change
<wallyworld> should i brace?
<dimitern> wallyworld, how is going to work with non-public clouds - i.e. maas ?
<dimitern> wallyworld, juju bootstrap mymaas maas/?
<dimitern> assuming the lack of environments.yaml
<axw> dimitern: there's a new clouds.yaml for private clouds
<wallyworld> dimitern: hop onto #juju
<dimitern> omw
<frobware> dimitern, morning!
<frobware> dimitern, are merging master -> maas-spaces?  I started but need to decide whether I should continue.
<dimitern> frobware, morning
<dimitern> frobware, yeah, I think it's good to do it often until we can merge
<frobware> dimitern, I didn't finish resolving all the conflicts
<dimitern> frobware, the bigger merge landed on friday
<dimitern> frobware, so this morning it was much easier - only 1 test to fix
<frobware> dimitern, ah - that's the one I'm talking about. I started on Friday, but didn't complete.
<dimitern> frobware, I've run make check after the merge on friday and did a quick live test to be sure
<frobware> dimitern, and that's now landed in maas-spaces?
<dimitern> frobware, this morning's merge is landing now
<dimitern> frobware, and the friday's one is already in
<dimitern> frobware, I have a few tasks planned to unblock maas-spaces merging into master
<dimitern> frobware, so we can then concentrate on the remaining tasks
<voidspace> frobware: we had a CI run on Friday, on maas-spaces, that never completed
<voidspace> frobware: http://reports.vapour.ws/releases/3578
<voidspace> frobware: but there was a xenial unit test failure which isn't good - featuretests
<voidspace> frobware: that maybe looks space discovery related, which is unexpected
<dimitern> voidspace, 2 of those attempts where due to issues with the cloud archive getting the wrong package
<voidspace> frobware: however they pass locally
<voidspace> dimitern: ah right, infrastructure problem then?
<voidspace> dimitern: the featuretests pass locally for me (wily), but I get a cmd/status failure
<dimitern> voidspace, and the last one is flaky due to the controller space not getting handled
<voidspace> yeah, we're still expecting that to fail
<voidspace> I believe
<voidspace> cmd/juju/status fails consistently for me
<voidspace> checking master
<dimitern> voidspace, how does it fail?
<voidspace> dimitern: six failures, unexpected number of machines in some of them
<voidspace> dimitern: same failure for me on master
<voidspace> dimitern: huuuuge amounts of logging so hard to summarise the failures, I'll pick one of the tests and investigate
<voidspace> dimitern: it could be an oddity with my machine
<voidspace> hah, latest run of master on CI failed to build
<voidspace> Wily unit tests passed on Friday on CI though
<dimitern> voidspace, I see both master and maas-spaces-merge-master-7* pass here, although I did see the LoginsDuringUpgrade test failing once
<voidspace> dimitern: how did it fail?
<dimitern> voidspace, something like can login as machine expected IsTrue, got false
<voidspace> ah
<voidspace> with status test, I'm getting five machines when only one was expected
<voidspace> digging into it
<voidspace> dimitern: http://pastebin.ubuntu.com/14992568/
<wallyworld> dimitern: here's a trivial one line fix for a failing windows unit test (i hope), can you take a quick look? http://reviews.vapour.ws/r/3771/
<dimitern> wallyworld, looking
<wallyworld> ty
<dimitern> wallyworld, LGTM
<wallyworld> tyvm
<dimitern> wallyworld, and I assume a better fix will be done there once possible, right?
<wallyworld> dimitern: that whole line will be deleted
<wallyworld> since JUJU_HOME won't be supported and the fallback in the code will be gome
<wallyworld> but CI scripts need to be updated
<dimitern> wallyworld, right
<wallyworld> the test fails because of a temporary fallback in the code
<voidspace> wallyworld: hey, you know anything about status tests?
<wallyworld> a littlw
<wallyworld> i do know i hate them
<voidspace> wallyworld: there's a few that fail consistently on my machine (but not anywhere else)
<voidspace> wallyworld: here's one http://pastebin.ubuntu.com/14992568/
<wallyworld> looking
<voidspace> wallyworld: the test is trying to limit status to an exposed service but gets five machines instead of one
<voidspace> wallyworld: that's running just that test with the preceding tests in the loop removed (so line numbers won't match yours) to eradicate state leakage between tests as a cause
<wallyworld> and it's intermittent?
<wallyworld> not on your machine
<voidspace> wallyworld: consistent on my machine, not seen elsewhere yet I believe
<voidspace> wallyworld: but in means I can't do a full unit test run without failures on my machine - so I'd like to find out the cause
<wallyworld> indeed
<wallyworld> i get mongo failures quite regularly :-(
<wallyworld> voidspace: i don't see anything obvious, how long has it been doing this?
<voidspace> wallyworld: new today
<voidspace> wallyworld: thanks for looking anyway
<wallyworld> voidspace: i do notice what appears to be old agent-state values in the yaml output. those are gone from master. you could try rebasing
<voidspace> wallyworld: I've just had a thought - I copied environments.yaml from CI
<voidspace> I wonder if that is screwing with things
<voidspace> wallyworld: I'm on current master head
<wallyworld> probably not, but yoy could try without, i'd have to see what's in it i guess
<wallyworld> shouldn't affect the tests
<voidspace> nah, doesn't affect it - still 6 failures
<wallyworld> hmmm, there must be something unique to your setup, but i can't think of what
<voidspace> updated version of go as well, no difference
<dimitern> voidspace, check if you have cache.yaml in ~/.juju/environments/
<dimitern> voidspace, and delete it if it's there before retrying
<voidspace> dimitern: I blew away .juju and did a fresh init
<dimitern> voidspace, hmm - well, then check ~/.local/share/juju ?
<voidspace> dimitern: I blew that away before the init too :-)
<voidspace> I'll check though
<voidspace> just reinstalling lxc to fix (hopefuly) another test failure on my machine
<voidspace> dimitern: no cache.yaml there
<dimitern> voidspace, what do you have in ~/.local/share/juju ? I only have ssh/ with juju_id_rsa + juju_id_rsa.pub
<voidspace> dimitern: I have an environments.yaml too
<voidspace> dimitern: which was created by juju init
<dimitern> voidspace, in ~/.local/share/juju/ ?
<dimitern> voidspace, I don't have this fwiw
<voidspace> yep
<voidspace> this is a fresh build with go 1.5, no preexisting juju home directory, then juju init
<voidspace> which created environments.yaml
<voidspace> it's just the boilerplate one
<dimitern> voidspace, juju init shouldn't be necessary anymore AIUI
<voidspace> dimitern: it certainly shouldn't cause tests to fail though!
<voidspace> I'll get rid of the environments.yaml and see
<dimitern> voidspace, yeah
<voidspace> go rid of canonistack and ec2 credentials from my environment - that didn't fix it either
<voidspace> removing environments.yaml didn't help
<dimitern> voidspace, try rm -fr $GOPATH/pkg/ followed by go install github.com/juju/juju/... ?
<voidspace> dimitern: heh, ok
<voidspace> I just updated go version which I think did the same thing
<voidspace> (effectively)
<voidspace> nope, same problem
<voidspace> back to digging into the code
<dimitern> voidspace, hmm ok, I hope you find it
<bdx> hey whats going on everyone??? Can someone give an example of provisioning storage using the openstack provider? Thanks!
<natefinch> ericsnow: ready when you are.
<mup> Bug #1543178 opened: TestBlankJujuXDGDataHomeEnvVar fails because widows isn't looking at xdg location <ci> <regression> <test-failure> <windows> <juju-core:Triaged> <https://launchpad.net/bugs/1543178>
<mup> Bug #1543189 opened: testing_test.go: fakeHome declared and not used <ci> <go1.5> <go1.6> <regression> <test-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1543189>
<mup> Bug #1543193 opened: TestConfig fails on windows because of wrong dir <ci> <regression> <test-failure> <windows> <juju-core:Triaged> <https://launchpad.net/bugs/1543193>
<mup> Bug #1542992 changed: ec2: destroy-controller causes rate limiting failure <juju-core:New> <https://launchpad.net/bugs/1542992>
<dimitern> voidspace, any luck with those test failures btw?
<frobware> voidspace, dooferlad: sync with rick
<mup> Bug #1542990 changed: tools version checker restarts every 3 seconds <juju-core:New> <https://launchpad.net/bugs/1542990>
<cherylj> fwereade: did you see waigani's email about moving the state workers to use the dependency engine?
<voidspace> frobware: omw
<voidspace> dimitern: buried in predicate matchers in the apiserver at the moment :-)
<voidspace> frobware: can't join
<dimitern> voidspace, right, np
<voidspace> worked
<mup> Bug #1543216 opened: EOF uploading charm <charm> <ci> <deploy> <intermittent-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1543216>
<mup> Bug #1543216 changed: EOF uploading charm <charm> <ci> <deploy> <intermittent-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1543216>
<fwereade> cherylj, dammit, I did, it looked broadly sensible/correct but I haven't done it properly yet
<mup> Bug #1543216 opened: EOF uploading charm <charm> <ci> <deploy> <intermittent-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1543216>
<mup> Bug #1543223 opened: kill-controller fails on missing volume <ci> <kill-controller> <juju-core:Triaged> <https://launchpad.net/bugs/1543223>
<mup> Bug #1543223 changed: kill-controller fails on missing volume <ci> <juju-release-support> <kill-controller> <juju-core:Triaged> <https://launchpad.net/bugs/1543223>
<mup> Bug #1543223 opened: kill-controller fails on missing volume <ci> <juju-release-support> <kill-controller> <juju-core:Triaged> <https://launchpad.net/bugs/1543223>
<voidspace> unitMatchSubnet returns true for match when it gets an error!
<voidspace> which seems very odd
<voidspace> however, if there's an error - match shouldn't be checked
<voidspace> I think we've got a double-nil error here - the error is != nil but errors.Trace is still returning nil
<voidspace> something like this
<voidspace> no, not the problem
<tych0> cherylj: looks like i finally got #4314 to work :)
<voidspace> dimitern: frobware: ah, it's matching on the subnet - now to work out why
<mup> Bug #1543235 opened: UniterSuite.TestUniterRelations again fails <ci> <i386> <intermittent-failure> <ppc64el> <regression> <juju-core:Triaged> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1543235>
<voidspace> dimitern: frobware: it's fucking BT dns
<frobware> voidspace, been there.
<voidspace> dimitern: frobware: BT causes net.ResolveIPAddr("started") to work...
<voidspace> fsking bollox
<voidspace> ok, at least I found it
<frobware> voidspace, this is the problem I had with "testing.invalid"
<voidspace> now to see if I can fix it
<voidspace> frobware: yeah, I will have that problem too...
<voidspace> so matchSubnet returns true for the "started" status filter
<voidspace> hah!
<dimitern> voidspace, wow! that really sucks for BT :)
<cherylj> tych0: yay!!
<cherylj> tych0: CI should pick up your branch to run now since you've updated it.
<cherylj> tych0: I see unit test failures, though, now that it's gotten through the build.
<cherylj> tych0: http://juju-ci.vapour.ws:8080/job/github-merge-juju/6271/console
<tych0> cherylj: i think that's the last build
<tych0> er
<tych0> the n-1th build
<tych0> i fixed those and the jujubot actually merged it
<cherylj> ah!
<cherylj> ok :)
<tych0> cherylj: what i don't remember is how to go to the fancy web page you sent me to
<tych0> cherylj: and if jujubot merged that, are the additonal tests that are going to be run now that i need to check that fancy web page for, or not?
<cherylj> tych0: http://reports.vapour.ws/releases#lxd-container-type
<cherylj> tych0: there are also reports emailed out from CI with summaries.
<tych0> ah, reports.vapour.ws :)
<cherylj> tych0: I can keep an eye out for yours and let you know if there are any failures seen there that are unique to your branch.
<tych0> cherylj: oh, that would be swell, thanks!
<cherylj> np!
<tych0> cherylj: is there anything else you need from me right now? (modulo any fixes, of course)
<cherylj> tych0: nope, not until your branch runs through CI
<tych0> cherylj: ok, cool. thanks!
<mup> Bug #1542985 changed: Juju won't switch environments <juju-core:Invalid> <https://launchpad.net/bugs/1542985>
<natefinch> ericsnow: trivial review?
<natefinch> http://reviews.vapour.ws/r/3772/
<dimitern> voidspace, dooferlad, frobware, http://reviews.vapour.ws/r/3773/ please have a look when you can
<natefinch> ericsnow: should I just remove the existing show-charm-resources command (currently called "resources")?  It conflicts with the card I'm working on that wants list-resources to have an alias of "resources"
<ericsnow> natefinch: sure
<ericsnow> natefinch: I'll be removing it in my patch as well
<natefinch> ericsnow: figured.
<natefinch> ericsnow: cool
<natefinch> rick_h__ or rick_h___: we have a task to change push-resource to only accept a single resource at a time, in anticipation of adding a --comment flag... in that case, does it make sense to keep the format push-resource service name=file, or should we just make it push-resource service name file  (i.e. drop the equals and make the name and file separate arguments)?
<mup> Bug #1538241 opened: 2.0-alpha2 stabilization <blocker> <juju-core:Triaged> <https://launchpad.net/bugs/1538241>
<mup> Bug #1538241 changed: 2.0-alpha2 stabilization <blocker> <juju-core:Triaged> <https://launchpad.net/bugs/1538241>
<mup> Bug #1538241 opened: 2.0-alpha2 stabilization <blocker> <juju-core:Triaged> <https://launchpad.net/bugs/1538241>
<natefinch> ericsnow: any idea whay this PR didn't get a review on reviewboard?
<natefinch> ericsnow: https://github.com/juju/juju/pull/4332
 * ericsnow takes a look
<ericsnow> natefinch: also, be sure to take a look at the tasks for that card (there's more to it than the rename)
<natefinch> ericsnow: ahh, I missed the tasks, thanks
<ericsnow> natefinch: it looks like you already have a review request up for revision 968fb37
<ericsnow> natefinch: perhaps you have a draft up? an old PR?
<ericsnow> natefinch: in either case you have to completely delete (rather than discard) the old review request
<mup> Bug #1356500 changed: Lost relation data after juju killing upgrader/uniter on state connection lost. <sts> <juju-core:Invalid> <https://launchpad.net/bugs/1356500>
<mup> Bug #1433336 changed: juju deploy tags are persistent accross juju deploys <juju-core:Invalid> <https://launchpad.net/bugs/1433336>
<mup> Bug #1543262 opened: keystone V3 support needed <uosci> <Go OpenStack Exchange:New> <juju-core:New> <https://launchpad.net/bugs/1543262>
<thumper> morning peeps
<natefinch> ericsnow: weird
<mup> Bug #1543262 changed: keystone V3 support needed <uosci> <Go OpenStack Exchange:New> <juju-core:New> <https://launchpad.net/bugs/1543262>
<mup> Bug #1356500 opened: Lost relation data after juju killing upgrader/uniter on state connection lost. <sts> <juju-core:Invalid> <https://launchpad.net/bugs/1356500>
<mup> Bug #1433336 opened: juju deploy tags are persistent accross juju deploys <juju-core:Invalid> <https://launchpad.net/bugs/1433336>
<natefinch> ericsnow: yeah, there's a draft up.... no idea how that got there.  it has no contents, though.
<natefinch> ericsnow: how do I delete it?
<ericsnow> natefinch: under the "Close" tab click on "Delete Permanently"
<natefinch> ericsnow: I don't have that, must be admin only?
<ericsnow> natefinch: weird, I thought you could do that for your own requests
<ericsnow> natefinch: I'll clean it up
<natefinch> ericsnow: thanks
<ericsnow> natefinch: what's the URL to the request
<ericsnow> ?
<natefinch> http://reviews.vapour.ws/r/3774/
<mup> Bug #1356500 changed: Lost relation data after juju killing upgrader/uniter on state connection lost. <sts> <juju-core:Invalid> <https://launchpad.net/bugs/1356500>
<mup> Bug #1433336 changed: juju deploy tags are persistent accross juju deploys <juju-core:Invalid> <https://launchpad.net/bugs/1433336>
<mup> Bug #1543262 opened: keystone V3 support needed <uosci> <Go OpenStack Exchange:New> <juju-core:New> <https://launchpad.net/bugs/1543262>
<ericsnow> natefinch: kill that PR and and try again
<natefinch> ericsnow: worked, thanks
<natefinch> ericsnow: I have a couple of merges going.  Gotta go snowblow again.  I'll finished up the tasks on that show-service-resources patch when I get back in... I should be able to get that and the change to push-resource done tonight
<ericsnow> natefinch: cool
<mup> Bug #1543283 opened: [Joyent] 4k ssh key can not be used: "cannot create credentials: An error occurred while parsing the key: asn1: structure error: length too large" <juju-core:New> <https://launchpad.net/bugs/1543283>
<rick_h___> natefinch-afk: I think name=file is worthwhile as it's explicit.
<rick_h___> wallyworld: can you bump that until after your standup please?
<wallyworld> rick_h___: the cli meeting?
<rick_h___> wallyworld: yes please. I'm flying back in that window but will in a layover after your standup
<rick_h___> wallyworld: or do you want to chat now?
<wallyworld> rick_h___: if alexisb is free we could
<wallyworld> rick_h___: ah, but she has monday off, that's right, so i'll bump
<rick_h___> wallyworld: ah right, she's on holiday today
<wallyworld> it tuesday here so i forgot what day it was
<wallyworld> over there
<rick_h___> heh
<rick_h___> ty wallyworld
<wallyworld> np. you sre a busy, busy man
<wallyworld> are
<rick_h___> wallyworld: wheeeee
<rick_h___> wallyworld: "livin the dream"
<wallyworld> living the dream :-D
<rick_h___> :P
<wallyworld> yup :-)
<wallyworld> me too!
<rick_h___> wallyworld is my role model
<wallyworld> for some value of "role model"
<wallyworld> the mind boggles
<wallyworld> i am good at livin the dream :-)
<rick_h___> wallyworld: ooh, can I ask a favor? I'm trying to figure out something.
<wallyworld> sure
<rick_h___> wallyworld: if an ubuntu user isn't on a guest ubuntu image, does juju create one?
<rick_h___> wallyworld: someone thinks this is true but unsure how to check it out
<wallyworld> afair, we expect an ubuntu user on our public cloud images, i think we create one for manual provider
<wallyworld> i'd have to check to be sure
<wallyworld> thumper: can you recall?
<rick_h___> wallyworld: if you get a sec can you dbl check? We're talking about providing images for someone and they want a non-ubuntu user ootb and I'm worrked about charms not working if there's no ubuntu user
<thumper> eh?
<rick_h___> wallyworld: or hint me on how to dbl check
<wallyworld> thumper: do you know for sure or not if we create an ubuntu user if one doesn't exist?
<thumper> I think we do now
<thumper> not for sure, but 85%
<wallyworld> rick_h___: i'll find out and get back to you
<rick_h___> wallyworld: ty
<rick_h___> I'd like to tell them "no" but wanted to make sure I had grounds first :)
<wallyworld> ok, maybe you can say yes :-)
<rick_h___> no, I'm not good at giving people what they want. I like it my way :P
<wallyworld> rick_h___:
<wallyworld> / SetUbuntuUser creates an "ubuntu" use for unix systems so the juju client
<wallyworld> / can access the machine using ssh with the configuration we expect.
<wallyworld> so we create the ubuntu user in cloud init
<rick_h___> ah ok coolio ty
<davechen1y> https://github.com/juju/juju/pull/4335
<davechen1y> can I get a review pls
<davechen1y> oh dear
<davechen1y> i have a horrible feeling about the api server
<thumper> davechen1y: shipit
<thumper> what is this feeling?
<davechen1y> every api server "conection" is a http conneciton
<davechen1y> which is pooled on the client
<davechen1y> there is no "session for a client"
<davechen1y> it's just a bag of http connections
<davechen1y> so "counting the number of outstanding connections" is complicated
<davechen1y> do we want the number of http requests in fly
<davechen1y> the number of http connections connectde (but possibly inactive)
<davechen1y> etc
<thumper> hmm...
<thumper> tricky
<davechen1y> i think the safest thing is always send Connection: closed after every API request
<davechen1y> disabling pooling on the client
<davechen1y> althought, this probably isn't the root issue that Cheryl is chasing
<davechen1y> hmm
<davechen1y> althgouth
<davechen1y> isnt it web sockets over http ?
<davechen1y> so actaully there _is_ a long lived connection
<davechen1y> why did it have to be web sockets
<davechen1y> ?!?
<davechen1y> ok, so back in the day we had the gui
<davechen1y> but now we have more clients that are _not_ browsers
<davechen1y>                         modelUUID := req.URL.Query().Get(":modeluuid")
<davechen1y>                         logger.Tracef("got a request for model %q", modelUUID)
<davechen1y> ^ left over debugging ?
<wallyworld> anastasiamac_: axw: a minute late
<anastasiamac_> wallyworld: k. let us know when
<wallyworld> here now
<davechen1y> cherylj: what was the issue # we talked about at standup ?
<davechen1y> thumper: i think I figured out a way around it
<cherylj> davechen1y: https://bugs.launchpad.net/juju-core/+bug/1543216
<mup> Bug #1543216: EOF uploading charm <charm> <ci> <deploy> <intermittent-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1543216>
<mup> Bug #1543362 opened: juju debug-log returns error if run too early in bootstrap <juju-core:New> <https://launchpad.net/bugs/1543362>
<davechen1y> ta
#juju-dev 2016-02-09
<davechen1y> thumper: cherylj
<davechen1y> machine-0: 2016-02-09 00:36:41 INFO juju.apiserver apiserver.go:302 [9] user-admin@local API connection terminated after 7.391830549s, active connections: 5
<davechen1y> machine-0: 2016-02-09 00:36:41 INFO juju.apiserver apiserver.go:302 [A] user-admin@local API connection terminated after 2.046902769s, active connections: 4
<davechen1y> machine-0: 2016-02-09 00:36:41 INFO juju.apiserver apiserver.go:302 [C] user-admin@local API connection terminated after 91.680242ms, active connections: 3
<davechen1y> ^ this is what I can do
<thumper> davechen1y: active connections is new current count?
<davechen1y> yup
<davechen1y> cherylj: 2016-02-08 22:30:16 ERROR Command '('juju', '--debug', 'deploy', '-m', 'maas-1_9-deploy-trusty-amd64', 'local:trusty/dummy-sink')' returned non-zero exit status 1
<davechen1y> where can I find the source for this charm ? assuming the charm matters
<cherylj> davechen1y: https://private-fileshare.canonical.com/~cherylj/dummy-charms/
<cherylj> There's a tar file there, and some copied commands that the CI test uses
<davechen1y> ta
<davechen1y> is this environement a ha environment ?
<cherylj> but I imagine the charm doesn't matter
<cherylj> davechen1y: probably not, but you can double check by looking at the test run
<davechen1y> yeah, i deployed some of my usual favorites
<davechen1y> i'm bloody sick of the tools versino checker
<davechen1y> is that on the top of a list for someone to fix ?
<davechen1y> checking every 3 seconds is stupid
<davechen1y> 15 minutes would be sufficient
<cherylj> davechen1y: no, there are other more serious failures that everyone's working on
<cherylj> unfortunatley
<cherylj> unfortunately, even.   Because that one is darn annoying
<cherylj> davechen1y: no, the env is not HA
<davechen1y> juju debug-log pauses if you run it after calling enable-ha
<davechen1y> brilliant
<davechen1y> so does juju ssh
<davechen1y> that's wonderful
<davechen1y> juju enable-ha
<davechen1y> puts your environment into catatonia until that process finishes
<cherylj> doesn't surprise me.  everything dies / pauses when you enable-ha
<davechen1y> cherylj: so what's happened is
<davechen1y> the addresses of the additional mongo servers have been added to the list of state servers
<davechen1y> but those additional mongos are up
<davechen1y> sorry, not up
<davechen1y> they are still going through the cloud=init dance
<davechen1y> so you have a 2/3 chance that the apiserver running on machine-0 will try to connect to those
<davechen1y> 2016-02-09 00:56:04 DEBUG juju.worker.peergrouper desired.go:116 machine "0" is already voting
<davechen1y> 2016-02-09 00:56:04 DEBUG juju.worker.peergrouper desired.go:123 machine "2" is not ready (has status: true)
<davechen1y> 2016-02-09 00:56:04 DEBUG juju.worker.peergrouper desired.go:123 machine "3" is not ready (has status: true)
<davechen1y> yet the api server still tries to dial it :)
<davechen1y> 2016-02-09 00:55:49 DEBUG juju.mongo open.go:117 connection failed, will retry: dial tcp 10.251.20.20:37017: getsockopt: connection refused
<davechen1y> 2016-02-09 00:55:49 DEBUG juju.mongo open.go:117 connection failed, will retry: dial tcp 10.241.59.50:37017: getsockopt: connection refused
<davechen1y> 2016-02-09 00:55:50 DEBUG juju.mongo open.go:117 connection failed, will retry: dial tcp 10.251.20.20:37017: getsockopt: connection refused
<davechen1y> 2016-02-09 00:55:50 DEBUG juju.mongo open.go:117 connection failed, will retry: dial tcp 10.241.59.50:37017: getsockopt: connection refused
<davechen1y> 2016-02-09 00:55:50 DEBUG juju.mongo open.go:117 connection failed, will retry: dial tcp 10.251.20.20:37017: getsockopt: connection refused
<davechen1y> 2016-02-09 00:55:50 DEBUG juju.mongo open.go:117 connection failed, will retry: dial tcp 10.241.59.50:37017: getsockopt: connection refused
<cherylj> davechen1y: but the two bugs that you're looking at aren't using ha
<davechen1y> right
<davechen1y> i won't get distracted
<davechen1y> i was just using enable-ha to try to get the apiserver to explode
<davechen1y> and enter it's restart behaviour
<cherylj> davechen1y: ah, I was confused
<davechen1y> i shouldn't go poking around in juju
<davechen1y> there be dragons
<cherylj> ain't that the truth.
<davechen1y> and it's failed
<davechen1y> you'll love this
<davechen1y> Attempt 63 to download tools from https://10.251.11.185:17070/tools/2.0-alpha2.1-precise-amd64...
<davechen1y> + curl -sSfw tools from %{url_effective} downloaded: HTTP %{http_code}; time %{time_total}s; size %{size_download} bytes; speed %{speed_download} bytes/s  --noproxy * --insecure -o /var/lib/juju/tools/2.0-alpha2.1-precise-amd64/tools.tar.gz https://10.251.11.185:17070/tools/2.0-alpha2.1-precise-amd64
<davechen1y> curl: (7) couldn't connect to host
<davechen1y> tools from https://10.251.11.185:17070/tools/2.0-alpha2.1-precise-amd64 downloaded: HTTP 000; time 0.001s; size 0 bytes; speed 0.000 bytes/s + echo Download failed, retrying in 15s
<davechen1y> Download failed, retrying in 15s
<davechen1y> machine-2 is trying to bootstrap
<davechen1y> it needs tools from machine-0
<davechen1y> machine-0's agent is trying to connect to the replica set
<davechen1y> the replica set is down because it's trying to ensure ha
<davechen1y> so, no tools
<davechen1y> no bootstrap
<davechen1y> no ha
<davechen1y> no tools
<davechen1y> etc
<davechen1y> hmm
<davechen1y> this is even weirder
<davechen1y> this is another case of machine-0 not listening on port 17017
<davechen1y> 17070
<davechen1y> I need to look into this
<davechen1y> if that port is not open, no api server
<davechen1y> 2016-02-09 01:36:02 INFO juju.apiserver apiserver.go:302 [1] machine-0 API connection terminated after 3m35.591602712s, active connections: 0
<davechen1y> 2016-02-09 01:36:02 INFO juju.apiserver apiserver.go:325 closed listening socket "[::]:17070" with final error: <nil>
<davechen1y> gets more and more interesting
<davechen1y> the api server shuts down, but never starts back up again
<davechen1y> OH MY GODS
<davechen1y> the bit where we send data to bash via ssh
<davechen1y> after this line
<davechen1y> 2016-02-09 01:43:36 DEBUG juju.utils.ssh ssh.go:249 using OpenSSH ssh client
<davechen1y> we're sending ONE CHARACTER AT A TIME
<davechen1y> axw: ping
<axw> davechen1y: pong
<axw> say whaaat
<axw> davechen1y: where's hte code that's doing that?
<davechen1y> https://bugs.launchpad.net/juju-core/+bug/1543388
<mup> Bug #1543388: bootstrapping talks to the remote machine one character at a time <juju-core:New> <https://launchpad.net/bugs/1543388>
<davechen1y> i was watching the bootstrap
<davechen1y> and i'm like why is top using 48% cpu
<davechen1y> so I straced it
<davechen1y> read(0, "e", 1)                         = 1
<davechen1y> read(0, "H", 1)                         = 1
<davechen1y> read(0, "t", 1)                         = 1
<davechen1y> read(0, "D", 1)                         = 1
<davechen1y> read(0, "N", 1)                         = 1
<davechen1y> read(0, "y", 1)                         = 1
<davechen1y> read(0, "q", 1)                         = 1
<davechen1y> read(0, "5", 1)                         = 1
<davechen1y> read(0, "g", 1)                         = 1
<davechen1y> read(0, "H", 1)                         = 1
<davechen1y> read(0, "/", 1)                         = 1
<davechen1y> read(0, "S", 1)                         = 1
<davechen1y> read(0, "o", 1)                         = 1
<davechen1y> read(0, "5", 1)                         = 1
<davechen1y> read(0, "t", 1)                         = 1
<davechen1y> read(0, "6", 1)                         = 1
<davechen1y> read(0, "C", 1)                         = 1
<axw> :/
<mup> Bug #1543388 opened: bootstrapping talks to the remote machine one character at a time <juju-core:New> <https://launchpad.net/bugs/1543388>
<mup> Bug #1543388 changed: bootstrapping talks to the remote machine one character at a time <juju-core:New> <https://launchpad.net/bugs/1543388>
<mup> Bug #1543388 opened: bootstrapping talks to the remote machine one character at a time <juju-core:New> <https://launchpad.net/bugs/1543388>
<davechen1y> can tomb.Kill block ?
<natefinch> davechen1y: it does acquire a lock, so, in theory, yes.
<natefinch> davechen1y: but otherwise, it just closes the dying channel
 * thumper takes a deep breath and dives into importing units
 * natefinch looks up the time formatting date for the 1000th time
<davechen1y> natefinch: https://github.com/juju/juju/blob/master/apiserver/apiserver.go#L96
<davechen1y> so here's the thing
<davechen1y> the only way processCertChanges can exit is if someone called tomb.Kill
<davechen1y> and hte only thing that can is cl.Close
<davechen1y> so this code calls tomb.Kill twice, then tomb.Done for good measure ...
<davechen1y> seems like overkill
<cherylj> wallyworld: can you take a look at my enable-ha change:  http://reviews.vapour.ws/r/3782/
<wallyworld> sure
<cherylj> thanks!
<wallyworld> cherylj: did axw ping you about possibly making a non blocking channel send?
<natefinch> davechen1y: yep... also, it doubly bad, because someone might see cl.tomb.Kill(cl.processCertChanges()) and think they don't need those other lines, but that line won't ever kill the tomb
<cherylj> wallyworld: no, not yet
<wallyworld> was maybe an alternative to increasing the channel buffer size
<wallyworld> but the buffer size increase might be acceptable for now until manifolds are done for those workers
<cherylj> okay, can take a look later.   I'm going to be afk for ~40 mins or so, but I'll be back
<wallyworld> ok
<axw> cherylj: wallyworld: wasn't going to bother, since we need to change it again. non-blocking send wouldn't work here anyway, it's not just a notify chan
<wallyworld> ok, just wanted to double check, ty :-)
<natefinch> channels with buffers that are not 0 or 1 are pretty suspect, in my experience
<axw> unless it's directly next to the things populating the channel, I tend to agree
<natefinch> this sounds like one of those cases where you could have an arbitrary number of sends on the channel before any reads from the channel, in which case any buffer size could be insufficient
<wallyworld> not arbitrary - is equal to the number of allowed controllers (7) plus a known number of local addresses
<natefinch> rick_h___: noted, about the name=file for resources.
<wallyworld> it's a short term fix until workers migrated to dep engine
<natefinch> wallyworld: ahh, the fact that it's a short term fix makes a big difference.
<wallyworld> for 2.0, sadly dep engine not going into 1.25
<wallyworld> so not sure what to do there
<natefinch> wallyworld: well, we're not going to support 1.25 for very long, right? ;)
<wallyworld> 2 years :-(
<davechen1y> natefinch: wahhahahahahaha
<natefinch> wallyworld: I know, I was joking
<wallyworld> but 1.25 is blocked right now, so need to get 1.25.4 out
<davechen1y> o/ gallows humor
<natefinch> wallyworld: just make the channel buffer 128... larger powers of 2 are always better
<wallyworld> ok
<wallyworld> i'll add a comment
<natefinch> wallyworld: definitely comment why the 10 is 10.
<davechen1y> axw: 2016-02-09 02:27:09 DEBUG juju.utils.ssh ssh.go:249 using OpenSSH ssh client
<davechen1y> what happens after this line
<davechen1y> somethign in bootstrap
<davechen1y> but it's mute until the other side starts to output things
<axw> davechen1y: umm. could be one of a few things, that debug message gets printed whenever an ssh client is created
<axw> davechen1y: first we ssh to each of the possible controller addresses
<axw> davechen1y: then (if you're uploading tools), copy tools across via ssh
<axw> davechen1y: then run the cloud-config rendered as a bash script
<axw> I think that's it
<axw> davechen1y: AFAICR, we just open "ssh" with the script as a bytes.Buffer piped to the ssh process's stdin
<axw> davechen1y: could be that ssh is in an interactive mode? looking for escape codes?
<davechen1y> 13:34 < axw> davechen1y: then (if you're uploading tools), copy tools across via ssh
<davechen1y> ^ it'll be this
<davechen1y> i'm spelunking in the code now
<davechen1y> short version is the openssh impl doens't buffer stdout/stdin
<davechen1y> or something
<axw> davechen1y: actually, gross as it is, we just add the contents of the tools to the bash script (base64 encoded or something)
<axw> so the 2nd and 3rd steps are just one
<natefinch> rick_h___: you around?
<davechen1y> axw: that's fine
<davechen1y> i knew we bas64'd them
<davechen1y> the problem is something is unbuffered there and it's sending one character at at time over ssh
<davechen1y> which is going to turn each byte into about 400
<davechen1y> mabye 200
<davechen1y> but it's a lot
<davechen1y> and the cpu on both sides is non trivial
<axw> davechen1y: yep. I had a look, nothing obvious. what were you stracing exactly? bash on the remote side? ssh on the client?
<davechen1y> remote side
<davechen1y> bash is hitting 50% cpu
<davechen1y> results are in that ticket
<axw> davechen1y: ok, will take another look later
<davechen1y> umm, https://github.com/juju/juju/blob/master/api/apiclient.go#L554
<davechen1y> natefinch: axw https://github.com/juju/juju/blob/master/api/apiclient.go#L554
<davechen1y> this construction is unsafe
<axw> davechen1y: you mean because two calls could race?
<axw> davechen1y: if so yeah.. pretty sure it's always one thing's responsibility to close though.
<axw> so in theory, but not in practice (unless we're doing something dumb, which I wouldn't rule out)
<davechen1y> this would have to be hit way harder than we could
<davechen1y> but it's entirely possible to hit this
<davechen1y> https://bugs.launchpad.net/juju-core/+bug/1543404
<mup> Bug #1543404: unsafe double channel close idiom <juju-core:New> <https://launchpad.net/bugs/1543404>
<natefinch> that code in apiclient doesn't look like it's intended to be threadsafe, so hopefully we're not trying to use it from multiple goroutines
<natefinch> lol panics
<natefinch> https://github.com/juju/juju/blob/master/api/apiclient.go#L435
<davechen1y> sooo, http://paste.ubuntu.com/14999670/
<davechen1y> no matter what logging I add, i cannot get line 71 to output something
<davechen1y> all I can think of is somehow tools are being cached
<davechen1y> and i'm not pushing up what I think i'm pushig up
<natefinch> davechen1y: log.Infof, not logger?
<davechen1y> OH FOR FUCKS SAKE
<davechen1y> thanks
 * davechen1y wonders what log was in this scope ...
<natefinch> heh, np.  One of those things your brain just can't see if you were the one that wrote it.
<davechen1y> sooo, amazong just gave me a machien without a public ip
<davechen1y> has that ever happened to anyone ?
<davechen1y> it has no public ip or public dns
<cherylj> natefinch, wallyworld, so should I do 10 or 128?
<cherylj> :)
<mup> Bug #1543404 opened: unsafe double channel close idiom <juju-core:New> <https://launchpad.net/bugs/1543404>
<wallyworld> 128 according to nate
<natefinch> cherylj: I was joking
<cherylj> ha, ok :)
<natefinch> cherylj: I do fear that 10 will just error out less often... but *shrug* Seems better than 1 :/
<cherylj> natefinch: in practice, I see it firing twice
<cherylj> if that helps :)
<wallyworld> 10 has some science behnd it
<cherylj> no, not science, it's http://i.imgur.com/24Jw4gM.gif
<wallyworld> lol, educate dguess then
<davechen1y> cherylj: 1 should be enough
<wallyworld> based on knowledge of the system
<cherylj> hehe.  I love that gif
<cherylj> davechen1y: I've seen that it's not
<davechen1y> if you just want to hand off the value between producer and consumer without either blocking
<cherylj> it was 1 before
<cherylj> and that was the problem
<davechen1y> cherylj: shit
<davechen1y> that's more serious
<cherylj> it was sending twice
<davechen1y> if it was already buffered
<cherylj> yeah
<davechen1y> what about making the recieve side timeout
<cherylj> I'm not sure I see how we would do that.   The receiver is blocked waiting on a lock that the sender is holding
<natefinch> davechen1y: it's a clusterfuck that is getting rewritten soonish
<natefinch> davechen1y: thus, the bigger buffer is just a stopgap
<cherylj> and a band aid for 1.25 :)
<davechen1y> whee 1.25 cluserfuck, keeps for 2 years even under adverse conditions
<cherylj> but, we should explore the other option menn0 suggested for 1.25 - where there's some other synchronization between certupdater and apiserver
<thumper> natefinch: still around?
<thumper> wanting to verify that the assign units collection is a transitory collection
<thumper> meaning that once all units have been assigned to machines, the length of that collection should be zero
<davechen1y> thumper: cherylj http://reviews.vapour.ws/r/3784/
<axw> thumper: that is correct.
<thumper> axw: ta
<mup> Bug #1543408 opened: WatchControllerStatusChanges needs unit tests <juju-core:Triaged by cherylj> <https://launchpad.net/bugs/1543408>
<natefinch> thumper: yes it should be zero
<natefinch> thumper: when we assign a unit to a machine we also remove that unit from the unit assignment collection
<thumper> saw that, just wanted to confirm
<thumper> ta
<axw> wallyworld: :/  I've been working on credentials support for the clouds
<wallyworld> oh, damn
<wallyworld> sorry, i thought you were doing --config
<axw> wallyworld: I did, then th other. never mind. I've done other clouds as well
<wallyworld> i started adding joyent support and noticed we needed to do a bit of work
<anastasiamac_> wallyworld: axw: PTAL http://reviews.vapour.ws/r/3787/
<wallyworld> axw: so mine just does maas and joyent. with maas, i made the maas-server come from the cloud endpoint attribute in clouds.yaml
<axw> wallyworld: yeah, I did the same in my branch. reviewing now
<wallyworld> axw: i'm just resolving a conflict and pushing
<axw> anastasiamac_: not sure why you would move controllerserver to jujuclient. it's not a client-side thing.
<wallyworld> axw: that's my fault, i misread a question and thought we were renaming controllerserver to just controller at the top lovel to hold server side controller stuff
<wallyworld> i don't like the name controllerserver
<axw> nor do I
<axw> environmentserver made some sense, controllerserver does not
<wallyworld> it was the best i could think of at the time :-/
<wallyworld> i don't really like environmentserver either
<axw> wallyworld: not suggesting we go back, but there was some connection to the two words before
<wallyworld> axw: atm we have controller and controllerserver at the top level. we choose just one i think
<axw> a controller's a controller, adding server to the end doesn't change anything
<axw> wallyworld: I think go with "controller". the things that *were* in controller have been moved to jujuclient
<wallyworld> oh, ok, we'll fix that
<wallyworld> i like controller also
<wallyworld> not sure if it should stay a top level package, but ok for now
<axw> wallyworld: reviewed
<wallyworld> ty, noticed your config one, looking at that
<axw> wallyworld: I'll do azure, cloudsigma, and vsphere now
<wallyworld> ok, i promise i won't :-)
<axw> :)
<wallyworld> axw: with the manta url - that's going away as soon as storage is gone
<axw> wallyworld: yep, as per comment
<wallyworld> fair enough, i'll leave in comment till then, i was hoping storage would be gone this week or next
<axw> wallyworld: replied to comment about Apply
<wallyworld> ok
<wallyworld> axw: fair point, i think, seems like the tests need updating which i'll look at. are you happy with the modified todo for the private key stuff?
<axw> wallyworld: didn't read yet, one sec
<axw> wallyworld: yep. you probably wouldn't want to enter it interactively, but we can read the file during interactive entry of the filename, and add the value
<axw> wallyworld: then your credentials.yaml is protected from changes on disk.
<axw> maybe not obvious though
<axw> not sure, we can leave it for now
<axw> covered the 99% case I think
<wallyworld> i think the key on disk will be pretty static
<wallyworld> yeah, all uses use file path afaik
<wallyworld> axw: that should be good to go now
<axw> wallyworld: thanks, shipit
<wallyworld> tyvm
<axw> wallyworld: just testing azure, should be ready to propose the rest very shortly
<wallyworld> awesome
<axw> wallyworld: there's still an issue with azure, another case where we need to be able to specify multiple endpoints
<axw> wallyworld: in azure there's separate endpoints for storage and everything else, and they're not necessarily derivable
<wallyworld> damn
<axw> wallyworld: pretty sure we're going to have to extend the clouds.yaml format
<wallyworld> seems so
<wallyworld> do we *need* azure storage long term?
<axw> wallyworld: yes. for volume support, and also some more basic operations like specifying where the VM image should live
<wallyworld> storage-endpoint then i guess
<wallyworld> axw: are the storage endpoints well know like the auth ones?
<wallyworld> can we add them to publoc cloud.yaml
<axw> wallyworld: yes, for azure public cloud. for azure stack you'd specify your own
<wallyworld> axw: well seems like we should just update our public cloud yaml and cloud metadata struct them
<axw> wallyworld: you mean with a new storage-endpoint field?
<wallyworld> yeah
<wallyworld> if it's not derivable
<axw> wallyworld: I'm on the fence as to whether it should be specific to storage, rather than having a flexible map of <service>:<service-endpoint>. storage-endpoint is probably fine though
<wallyworld> given it's optional, it keeps the default yaml nice and simple
<wallyworld> for other clouds that don't need it
<wallyworld> we can always get feedback and tweak
<axw> wallyworld: ok, sounds fine
<cherylj> can someone help me figure out why go test isn't actually testing anything in a particular directory?  http://paste.ubuntu.com/15000293/
<axw> wallyworld: added a card to Next
<wallyworld> no suite registered?
<cherylj> the test ran in the merge bot, and failed, obviously
<cherylj> but not when I do it locally
<wallyworld> sigh, hate that
<axw> cherylj: have you changed anything? changed a test file from package to package_test perhaps?
<cherylj> axw: no, I didn't change any test files
<anastasiamac_> wallyworld: axw: updated move \o/ PTAL?
<cherylj> looks like even on master I see the same issue
<cherylj> I change a test to fail, and it happily thinks there's nothing to test
<axw> anastasiamac_: one sec
 * anastasiamac_ waiting :D
<cherylj> ugh, the suite_test.go was for peergrouper_test, and nothing else was
<anastasiamac_> cherylj: m blind but where is package_test.go?
<cherylj> wonder how long it's been like that
<anastasiamac_> in worker/peergrouper...
<cherylj> anastasiamac_: guess they're using suite_test.go, rather than package_test
<anastasiamac_> could be the problem?..
<axw> anastasiamac_: LGTM, thanks
<anastasiamac_> axw: \o/
<anastasiamac_> wow - 2 in one day!!
<axw> wallyworld: http://reviews.vapour.ws/r/3790/ -- here's the rest
<wallyworld> ta, looking
<wallyworld> axw: reviewed, you may want to rebase first as my branch is almost landed and it will probably conflict in fallback public clouds yaml
<axw> wallyworld: thanks, yep, will do
<wallyworld> bbiab, school pickup
<cherylj> wallyworld, axw can one of you review the test changes I had to make?  http://reviews.vapour.ws/r/3782/
<cherylj> I'm going to add in the unit tests for the change and am tracking that work via bug 1543408
<mup> Bug #1543408: WatchControllerStatusChanges needs unit tests <juju-core:Triaged by cherylj> <https://launchpad.net/bugs/1543408>
<axw> cherylj: just the last diff?
<axw> or all of it?
<cherylj> axw: yes, the last diff
<cherylj> I copied the mock watcher that was there and modified it to be a strings watcher
<cherylj> had to pull suite_test.go into the peergrouper package.  I'll see about making the tests all external when I write the tests for the functional change.
<cherylj> it wasn't a no-op this time, so I skipped it
<axw> cherylj: ignoring the error from ControllerInfo in state watcher seems a bit alarming. why not just error out there?
<axw> (sorry, couldn't help myself and looked at the rest)
<cherylj> axw: if we're getting an error there, we'll get that error elsewhere and things will get restarted
<cherylj> that was my thinking anyway
<axw> cherylj: so it's not harmful to error out there as well right?
<cherylj> there's not really a way to return an error there, from what I saw.
<axw> oh. /me looks again
<blahdeblah> cherylj: have you moved to Australia, or do you just hate sleep? :-)
<cherylj> I miss sleep
<cherylj> we used to be buddies
<cherylj> now he's all emaciated because I don't feed him
<blahdeblah> That's no way to treat your buddies. :-)
<axw> cherylj: right, there's not, sorry.
<axw> cherylj: LGTM
<cherylj> thanks, axw!
<cherylj> and now, SLEEEEEP
<blahdeblah> be nice to your buddies!
<blahdeblah> cherylj: BTW, thanks for some of those recent bug fixes.
<davechen1y> cherylj: i have a strong suspcion that bootstrap is not making it to waitForInitalisatin
<davechen1y> I think it's bombing out _WAY_ earlier
<anastasiamac_> davechen1y: shh... cherylj is sleeping \o/
<axw> the new bootstrap syntax has already infected my brain. switching back and forth between 1.25 and 2.0 is going to be fun
<wallyworld> anastasiamac_: looks like the controller.yaml file isn't quite right - it looks like it is storing model information as well as controllers
<wallyworld> it also doesn't have the local. prefix
<wallyworld> for the controller name
<axw> davechen1y: it appears that piping stuff to bash causes bash to read a character at a time
<axw> davechen1y: as in, piping commands
<davechen1y> oh wow
<davechen1y> that's rubbish
<axw> wallyworld: would you like me to look at updating "switch", or are you doing that?
<davechen1y> only in juju would our rpc layer have a field called "Code", that was a string ...
<anastasiamac_> axw: RB is not picking this up.. Could you PTAL on github? https://github.com/juju/juju/pull/4347
<anastasiamac_> wallyworld: so... according to the spec, "local" is a prefix that is added to model name at bootstrap.
<anastasiamac_> wallyworld: to me, this reads as a separte PR unrelated to my controllers.yaml work
<anastasiamac_> wallyworld: model name will be transformed before the file is written, hence, my work will just pick it automatically
<anastasiamac_> wallyworld: ping me when u r back \o/
<anastasiamac_> wallyworld: why there is model info in the file now, is probably an "oversight" :D i'll look
<axw> anastasiamac_: done
<anastasiamac_> axw: awesome \o/
<anastasiamac_> axw: would we want to differntiate btw "controllers.lock", "models.lock", "accounts.lock" for different files?
<axw> anastasiamac_: probably not. models and accounts are both related to controllers
<anastasiamac_> axw: k. thnx
<axw> anastasiamac_: meaning: removing a controller should remove related info
<axw> anastasiamac_: so you can't not lock the controllers file if you're modifying models file
<axw> and vice versa
<anastasiamac_> axw: to what m observing, we lock a dir not a file...
<axw> anastasiamac_: for now, yes
<dimitern> frobware, voidspace, dooferlad, I've updated the PR to make the diff a bit easier to follow and included a fix after live testing on maas:
<dimitern> frobware, voidspace, dooferlad, so please have a look when you can http://reviews.vapour.ws/r/3773/
<voidspace> dimitern: ok
<axw> davechen1y: would appreciate if you could test https://github.com/juju/juju/pull/4349 tomorrow, and see if it resolves the issue for you. fairly sure it does, but need to get on with other things
<dimitern> axw, I think this should be applied to AddScripts as well - specifically in maas now we push a whole lot of python code to set up the bridge script
<dimitern> ..or perhaps that includes all runcmd / bootcmd scripts already
<axw> dimitern: is that going to pipe commands to bash? I don't think so
<axw> dimitern: yeah, this is the entire cloud-config script
<dimitern> axw, right, I've just noticed in maas we do a similar thing for the bridge script - put it in /tmp, trap exit and run it
<kjackal> Hey everyone, does any one know if/how is it possible to access relation/conversation data from within an action?
<voidspace> jam: dooferlad: dimitern: sorry, screwed my network temporarily
<dimitern> jam, sorry I was too quick - what were you about to say?
<jam> dimitern: just wanted to check if anyone has heard from alexisb today. Usually I have a 1:1 with her last night, but she missed it, and didn't reply to my email, which is unlike her
<dimitern> jam, nope - but according to the calendar she was off yesterday
<jam> dimitern: sigh. I had turned of "Juju Team Calendar" when I was at the Cape Town sprint, so that's why I didn't see it.
<jam> dimitern: thanks for noticing and checking. team calendar is back on.
<mup> Bug #1543517 opened: status command tests fail when you have dns spoofing <juju-core:New> <https://launchpad.net/bugs/1543517>
<dimitern> :) np
<voidspace> dimitern: when a user specifies multiple spaces for deployment constraints are we still only using the first?
<voidspace> dimitern: apiserver/provisioner/provisioninginfo.go line 224
<voidspace> dimitern: we should fix that soon I think
<mup> Bug #1543517 changed: status command tests fail when you have dns spoofing <juju-core:New> <https://launchpad.net/bugs/1543517>
<mup> Bug #1543517 opened: status command tests fail when you have dns spoofing <juju-core:New> <https://launchpad.net/bugs/1543517>
<voidspace> dimitern: LGTM on your PR
<voidspace> dimitern: the basic approach seems sound and I have no specific suggestions for it
<voidspace> dimitern: there's a lot of context on the code this touches I'm missing, so you may want someone else to look at it too
<dimitern> voidspace, sure, the more sets of eyes the better
<dimitern> voidspace, cheers
<dimitern> voidspace, yeah, that's due to aws
<dimitern> voidspace, (ignoring all but the first space)
<dimitern> voidspace, but in maas we actually use the spaces constraints for a machine directly
<wallyworld> anastasiamac_: hey. yes it will be a separate PR, just wanted to let you know that it needed looking at as part of the overall work
<wallyworld> voidspace: you found the problem, jeez what a strange issue
<anastasiamac_> wallyworld: \o/ added card
<wallyworld> ty
<voidspace> wallyworld: yeah, took most of the day
<wallyworld> voidspace: you may be interested in https://bugs.launchpad.net/bugs/1539428
<mup> Bug #1539428: cmd/juju/status: status filtering performs IP resolution of patterns <status> <unit-tests> <juju-core:Triaged> <https://launchpad.net/bugs/1539428>
<wallyworld> related to your issue
<voidspace> wallyworld: indeed
<voidspace> wallyworld: so getting rid of the resolution would be a double win.
<wallyworld> yes :-)
<wallyworld> it will have to be fixed for 2.0 i think
<dimitern> dooferlad, replied to your mail
<dimitern> dooferlad, let me know if that helps
<voidspace> frobware:  dimitern: trivial one for you http://reviews.vapour.ws/r/3796/
<dimitern> voidspace, looking
<dimitern> voidspace, reviewed
<dimitern> dooferlad, ping
<dooferlad> dimitern, voidspace: is the MAAS meeting happening? I am the only person in there...
<dimitern> dooferlad, sorry got distracted - is it still going?
<dooferlad> dimitern: just starting
<dimitern> dooferlad, omw
<voidspace> omw too
<dimitern> dooferlad, did you had a chance to look at my PR #4331 ?
<dooferlad> dimitern: I thought voidspace had
<dooferlad> dimitern: happy to if it needs more eyes
<dimitern> dooferlad, I'd appreciate it, thanks
<dimitern> dooferlad, as I'd like to get it in today, if possible and have another one almost ready to propose
<voidspace> dooferlad: I did review it and it looks sound to me, but I have a lot of missing context so I think another pair of eyes would be useful
<dooferlad> dimitern: LGTM. I would appreciate some card/bug links, but I didn't require them because it is in old code.
<dimitern> dooferlad, thank you
<mup> Bug #1497301 opened: mongodb3  SASL authentication failure <ci> <mongodb> <regression> <unit-tests> <juju-core:Triaged> <juju-core upgrade-mongodb3:Triaged> <https://launchpad.net/bugs/1497301>
<cherylj> hey perrito666, looks like a couple bugs on the mongo3 branch need some love:  bug 1534620 and bug 1497301
<mup> Bug #1534620: TestMongo26UpgradeStep fails on windows because of dos paths <ci> <regression> <test-failure> <windows> <juju-core:Incomplete> <juju-core update-mongodb3:Triaged> <https://launchpad.net/bugs/1534620>
<mup> Bug #1497301: mongodb3  SASL authentication failure <ci> <mongodb> <regression> <unit-tests> <juju-core:Triaged> <juju-core upgrade-mongodb3:Triaged> <https://launchpad.net/bugs/1497301>
<mup> Bug #1497301 changed: mongodb3  SASL authentication failure <ci> <mongodb> <regression> <unit-tests> <juju-core:Triaged> <juju-core upgrade-mongodb3:Triaged> <https://launchpad.net/bugs/1497301>
<cherylj> hey dimitern, how are things going with maas-spaces?
<mup> Bug #1497301 opened: mongodb3  SASL authentication failure <ci> <mongodb> <regression> <unit-tests> <juju-core:Triaged> <juju-core upgrade-mongodb3:Triaged> <https://launchpad.net/bugs/1497301>
<dimitern> cherylj, hey
<dimitern> cherylj, we're tracking master daily and wait for some CI feedback from the changes we pushed in maas-spaces so far (4 days we had no CI run of maas-spaces)
<dimitern> cherylj, we're also ~2d way from having a hopefully blessed maas-spaces
<voidspace> dimitern: ping
<dimitern> voidspace, pong
<voidspace> dimitern: the card I'm working on is "provider/maas: Addresses() to set SpaceProviderId not SpaceName"
<voidspace> dimitern: there is no provider/maas Addresses method
<voidspace> dimitern: and in fact "SpaceName" doesn't appear at all in provider/maas/environ.go
<dimitern> voidspace, it's in instance.go or interfaces.go IIRC
<voidspace> dimitern: ah yes it is
<voidspace> dimitern: better use of grep just found it in instance.go
<voidspace> dimitern: sorry for the noise :-)
<alexisb> dimitern, are there still changes the team needs to push to the maas spaces branch for a CI bless?
<voidspace> regex for the win
<voidspace> alexisb: yes
<voidspace> alexisb: proper handling of controller space
<alexisb> voidspace, and we are looking at 2 days for those fixes?
<voidspace> alexisb: the failures related to "Default Space" actually highlighted an important problem which we've nearly fixed
<voidspace> alexisb: yes
<alexisb> ok
<voidspace> we shouldn't have been using the default space at all and we *must* know the space to deploy controllers too
<alexisb> voidspace, dimitern would a CI run on maas-spaces now be useful to validate landed fixes?
<voidspace> alexisb: yes
<alexisb> voidspace, thank you
<dimitern> alexisb, yes, absolutely - we didn't have one for 4 days
<voidspace> alexisb: space discovery problems should be completely fixed and we haven't had a full run since those fixes landed
<alexisb> we need to stay in daily contact regarding progress on this branch
<alexisb> voidspace, ack
<dimitern> alexisb, we're hopefully down to 2-3 failures now compared to master, but still need to get a CI run to be sure
<alexisb> sinzui, mgz, can we please get a run on the maas spaces branch
<sinzui> alexisb: it is running
<voidspace> alexisb: FYI  the three yellow cards in our "In Progress" kanban lane are tracking progress
<voidspace> alexisb: https://canonical.leankit.com/Boards/View/101652562#workflow-view
<voidspace> sinzui: thanks
<alexisb> voidspace, awesome thank you
<mup> Bug #1543660 opened: juju needs to fix the yaml parser <customer> <juju-core:New> <https://launchpad.net/bugs/1543660>
<dooferlad> dimitern, voidspace: EOD for me. Still watching email.
<cherylj> hey tych0, looks like CI on your branch had more build failures:  http://reports.vapour.ws/releases/3586  (non-trusty build failures)
<dimitern> dooferlad, cheers, but I need to go soon as well
<natefinch> katco: can you double check with rick_h__ that we're dropping comment for now?
<rick_h__> natefinch: yes
<katco> natefinch: doh, sorry i did. we are.
<natefinch> oh good :)
<katco> natefinch: sorry, forgot to include that in the email. ericsnow fyi ^^^
<natefinch> ericsnow: did you have something you needed reviewed?
<ericsnow> natefinch: http://reviews.vapour.ws/r/3778/
<natefinch> ericsnow: how much of cmd/juju/charmcmd/store.go is copied from elsewhere?
<ericsnow> natefinch: nearly all of it
<natefinch> ericsnow: I thought so.  Can you put in comments as to that effect?  Then I don't have to try so hard to figure out why it's doing all this stuff.
<natefinch> ericsnow: like directly in the function bodies that have been copied
<ericsnow> natefinch: sure
<ericsnow> natefinch: oh, and internal tests are making my life miserable
<natefinch> ericsnow: how are internal tests making your life miserable?
<ericsnow> natefinch: import cycles, and fixing them is a ton of work :(
<natefinch> ericsnow: ahh boo.... well, import cycles are a valid reason to use external tests
<ericsnow> natefinch: that doen't help me now though
<natefinch> ericsnow: sorry :/
<natefinch> ericsnow: is this because of existing internal tests?  If so, I'd definitely like to hear details at some point, so we can try to avoid this in the future.
<natefinch> ericsnow, katco: trivial rename in charm metadata: https://github.com/juju/charm/pull/190
<katco> natefinch: +1 from me!
<ericsnow> natefinch: same here
<natefinch> ericsnow, katco: I have the s/comment/description patch for juju ready, but it's dependent on my other patch that's up for review, and I can't make rbt show the right diff.... so I'll just leave it until the other one lands.  It's another trivial diff anyway.
<katco> natefinch: ok that sounds fine
<natefinch> katco: so, should I grab the --debug card?  or should we point the upgrade-charm card?
<katco> natefinch: grab the --debug card since that's the last user-facing bit
<natefinch> katco: ok
<katco> natefinch: is this something specific to resources? https://github.com/juju/juju/commit/2910afceacca26dc1d880cedaa5d7560b249ebbe#diff-5c78256455800f538886c2beef98045aR66
<katco> natefinch: doesn't seem to be in master at any point
<mup> Bug #1543770 opened: Juju 2.0alpha1.1 does not assign a proper IP address for LXC containers <dhcp> <lxc> <maas> <network> <juju-core:New> <https://launchpad.net/bugs/1543770>
<natefinch> katco: you mean the arguments struct?
<katco> natefinch: specifically "toMachineSpec"
<natefinch> katco: it is there on the left side of the diff... that's what juju deploy foo --to 3  gets turned into
<natefinch> katco: possible that it's been changed in master?
<katco> natefinch: it has; trying to resolve the diff
<katco> natefinch: i was mistaken, just found it's lineage in master
<katco> *its
<natefinch> katco: certainly, it doesn't have anything to do with resources.. I was just refactoring the args into a struct.
<katco> natefinch: thx that makes the merge much easier :)
<natefinch> katco: cool
<natefinch> is there a function to get the unit number from the unitID?
<natefinch> like, I can certainly write one, but I'd rather reusing someone else's
<menn0_> thumper: when you have a chance, could you look at my replies to your comments on http://reviews.vapour.ws/r/3745/ ?
<aznashwan> any charm-tools people I could bother with a couple of reviews?
<thumper> menn0: ok
<natefinch> rick_h__, ericsnow, katco:  should we support juju resources foo/0 --debug, and only show detailed information about that particular unit's resources?
<natefinch> (currently the spec only talks about juju resources foo --debug)
<rick_h__> natefinch: yes, I think it should be able to go into per unit as well
<natefinch> rick_h__: ok. luckily, that's not much more work
<rick_h__> :)
<thumper> menn0: I'm tempted to call yagni and just use user tags
<natefinch> rick_h__: what should we show if the unit hasn't called resource-get for a resource?
<natefinch> revision "-" or something?
<rick_h__> natefinch: otp atm
<natefinch> thumper, menn0: If yagni is an option, it's almost always the right choice.  "Just in case" just makes your code confusing when it can really only be one thing right now. (IMO)
<menn0> thumper: i'm fine with that. The facade can always be bumped later.
<menn0> natefinch: I generally agree with that too. In this case the cost difference between either approach is nominal so it wasn't clear which way to go.
<natefinch> menn0: yeah. I generally prefer more specific types, so they convey the right information.  Seeing an API that takes a names.Tag, but really only one type of tag ever gets passed in, can easily make someone write the wrong code, trying to support a bunch of arguments that they don't really even need to worry about.
<menn0> natefinch: yep, agreed.
<menn0> natefinch: I'm going with the more specific type.
<tych0> cherylj: ok, i'll take a look now. was distracted by some other stuff this morning
<tych0> cherylj: https://github.com/juju/juju/pull/4355
<tych0> looks like somehow that commit got dropped in all the shuffling. anyway, I think that should fix at least the problems you're seeing now.
<tych0> (assuming the i18n stuff was the only issue, that's what i saw in my monte carlo sampling :)
<menn0> thumper: can you pls take another look at https://github.com/juju/juju/pull/4303 ?
<menn0> thumper: also http://reviews.vapour.ws/r/3746/ pls (tiny)
<davecheney> here is a simple review https://github.com/juju/juju/pull/4357
<davecheney> anyone ?
<mup> Bug #1543839 opened: juju/service: test fixture panics if SetUpSuite fails <juju-core:New> <https://launchpad.net/bugs/1543839>
<mup> Bug #1543839 changed: juju/service: test fixture panics if SetUpSuite fails <juju-core:New> <https://launchpad.net/bugs/1543839>
<mup> Bug #1543839 opened: juju/service: test fixture panics if SetUpSuite fails <juju-core:New> <https://launchpad.net/bugs/1543839>
#juju-dev 2016-02-10
<wallyworld> axw: anastasiamac: may be delayed for standup, will ping
<menn0> thumper: another trivial PR, as discussed via email http://reviews.vapour.ws/r/3803
 * thumper looks
<thumper> shipit
<axw> menn0: what magic did you use to get RB to recognise you renamed a file, rather than delete/add?
<menn0> axw: I did nothing
<menn0> axw: I think if the file is exactly the same and only moved RB does the right thing
<menn0> axw: if you move it and then change it, RB gets confused
<menn0> axw: that's my guess anyway
<axw> menn0: yeah, sounds plausible
<menn0> axw: this is the first time I've seen RB do that too
<menn0> axw: that PR is just a single "git mv"
 * axw nods
<davecheney> thumper: cherylj sooo, master and 1.25 are blocked
<davecheney> yet my JFDI is third in the queue, hmmmm
<thumper> landing bot does non master/12.5 branches too remember
<davecheney> ok
<davecheney> for review, https://github.com/juju/juju/pull/4361
<wallyworld> axw: anastasiamac: free now if you are
<axw> wallyworld: coming
<thumper> cherylj: still around?
<cherylj> thumper: yeah, what's up?
<thumper> cherylj: davecheney suggested that we have a quick hangout to sync about client side api error retries
<davecheney> meet in the standup hangout ?
<cherylj> thumper: sure, give me a minute
<thumper> davecheney: ack
<axw> anastasiamac: FYI, I can bootstrap/destroy/bootstrap lxd on cloud-credentials without any problems
<anastasiamac> axw: i was afraid u'd say that...
<anastasiamac> i'll dismiss it as "it's just me" :D
<axw> wallyworld: did we discuss dropping the no-args variant of "juju switch"? currently "juju switch" will show the active model name, which feels like a weird command to have to use
<axw> wallyworld: IMO we should have a more obvious command specifically for that purpose
<axw> wallyworld: "juju current-model", or something like that
<axw> maybe just "juju current"
<wallyworld> axw: that has come up before, with external stakeholders, and it had traction at one stage. i do agree but had thought we had reverted to accepting juju switch with no args as showing what's current. i'll ask around
<anastasiamac> wallyworld: axw: don't we show "current" in list- commands?
<anastasiamac> spec says mark them with *
<axw> anastasiamac: we do, but we shouldn't have to make an API call to show the current controller/model
<axw> anastasiamac: which the list commands require
<wallyworld> list-controllers is not an api call
<axw> wallyworld: list-models is though
<wallyworld> yes
<axw> wallyworld: "juju current" would print the current model, not controller
<wallyworld> just being clear wrt controllers to avoid potential confusion
<axw> ok, sure
<anastasiamac> wallyworld: axw: m putting the card for injecting store into command off in favour of list-controllers...
<anastasiamac> will get back to it when I (we/anyone) get a chance...
<axw> anastasiamac: sure. I was thinking I *might* do that one while I'm working on switch
<wallyworld> ok. i think you'll need placeholders for some columns
<anastasiamac> axw: sounds awesome - it'll b a fun one to do \o/
<thumper> axw: +1 on removing no args juju switch
<natefinch-afk> nick natefinch
<natefinch> heh
<natefinch> so.... what's the command to see what controller my commands will be working against?
<axw> natefinch: undecided
<natefinch> axw: ok :)
<axw> natefinch: you'll be able to see with "juju list-controllers" which are available, and which is active
<axw> natefinch: what's undecided is whether there'll be another command to show the current controller/model
<axw> one htat's not "juju switch"
<natefinch> definitely juju switch was a terribly unintuitive way of seeing what environment you were on
<natefinch> ericsnow: thanks for the fixes to those bugs. I was just running into that
<ericsnow> natefinch: yep :)
<natefinch> ericsnow: lemme see if I can review it real quick so we can get it in
<natefinch> ericsnow:  reviewed... a few things to think about, but I think it can land as-is (maybe remove one unneeded log statement)
<ericsnow> natefinch: thanks
<natefinch> ericsnow: ship it!
<natefinch> ericsnow: nvm, I see it's already been shipped.
<ericsnow> natefinch: :)
<thumper> laters...
<axw> wallyworld anastasiamac: just to confirm your changes don't involve adding models to ControllerStore, right?
<axw> later
<wallyworld> axw: no, i don't want to do that, i think controllers.yaml is judt for controllersd
<wallyworld> agree?
<wallyworld> axw: but i'm having an issue where i now can't map from model->controller because the info is missing from cache.yaml
<axw> wallyworld: right... but ControllerStore will have methods for accessing model info too. because they're related to controllers
<wallyworld> i may need a temp solution
<axw> wallyworld: what info is that?
<wallyworld> axw: given a model name, i need to know the controller name that hosts that model
<wallyworld> we used to get that from cache.yaml
<axw> wallyworld: you should be using the UUIDs I think?
<axw> wallyworld: is your branch on github yet? can I look?
<wallyworld> axw: yes, that's what used to happen under the covers. the cli knows the name of it's model; from there it looked up the model uuid, and then got the controller uuid, and from there the api info
<wallyworld> but now we don't store controller or model stuff in cache.yaml
<wallyworld> we only have controller by name from controller.yaml
<wallyworld> my branch is very much wip, lots of stuff commented out
<wallyworld> i may have to go back to storing controller and model stuff in cache.yaml for now
<wallyworld> but removing that allowed the code to be  lot cleaner
<axw> wallyworld: I think it's necessary until we have a model store
<wallyworld> sadly so
<axw> wallyworld: I'll work on that now, since it's needed for switching
<wallyworld> the code to persist controller stuff is much cleaner without having to cater for both cache.yaml and controller.yaml
<wallyworld> yep
<wallyworld> axw: at least i'll remove the bootstrap config stuff etc
<wallyworld> or try to, until i hot the next roadblock
<axw> anastasiamac wallyworld: any objections to the name jujuclient.ClientStore as an amalgamation of ControllerStore, ModelStore, etc.?
<axw> wallyworld: SGTM
<wallyworld> nope, sounds good
<wallyworld> my branch is all f*cked up, got to replace stuff back to how it was, sigh
<anastasiamac> axw: r we likely to have other stores in jujuclient?
<axw> anastasiamac: accounts
<axw> anastasiamac: not sure if there's anything else
<anastasiamac> axw: so ClientStore is for controllers and models; and AccountStore for accounts?
<axw> anastasiamac: ClientStore will be for all of them
<axw> anastasiamac: but you can still get specific ones
<axw> anastasiamac: i.e. ClientStore is just the combination of all the others
<anastasiamac> axw: ClientStore sounds great then \o/
<axw> wallyworld: also need accounts.yaml before we can get rid of cache.yaml, because that's where user/pass is
<axw> I suppose I'll do that at the same time/directly after
<wallyworld> axw: exactly, so i'm adding todos around where we'd use accounts.yaml
<wallyworld> it's all a bit of a mess atm
<wallyworld> axw: luckily api-info, api-endpoints commands are obsolete so that's a whole world of migration pain i can avoid \o/
<axw> wallyworld: really? what are the alternatives?
<wallyworld> axw: i need to check the specs, i think we'll work it into the list-controllers cli or something like that
<axw> wallyworld: that would make sense. probably just have it in the YAML for scripts to pull out
<wallyworld> more or less
<axw> wallyworld: I suspect we're going to have a lot of overlap. when are you likely to propose?
<wallyworld> axw: i have a shittonne of tests to fix, just got it compiling. i have introduced a temporary ControllerModel struct to hold controller and model uuid stored in the existing cache.yaml file
<axw> wallyworld: mmkay
<wallyworld> the ControllerModle struct is used in place of the old APIEndpoints struct which contained addresses etc as well as the model and controller uuid
<wallyworld> so it's a way of retaining the current recording of association between controller and model using the existing files
<axw> O
<wallyworld> does that make sense?
<axw> wallyworld: that's just temporary tho? what's the long term plan?
<wallyworld> to use the stuff you're working on
<axw> wallyworld: I was planning to pass controller name, model name, and store
<axw> wallyworld: to NewAPI... functions
<wallyworld> sometimes we only have the uuid, but i think that will go away
<wallyworld> axw: quick chat in standup hangout?
<axw> wallyworld: sorry was afk, one minute
<dooferlad> frobware:hangout?
<voidspace> dimitern: did you see the maas-spaces CI run(s)?
<voidspace> dimitern: still a couple of errors " gomaasapi: got error back from server: 400 BAD REQUEST ({"distro_series": ["'trusty' is not a valid distro_series]"
<voidspace> dimitern: a bunch of known issues that aren't our fault
<voidspace> dimitern: plus another maas one, unrecognised architecture for the centos test
<dimitern> voidspace, yeah, it's getting close
<dimitern> voidspace, I've merged latest master and set it to land btw
<dimitern> voidspace, that should clear the know issues already fixed on master
<dimitern> voidspace, and .. oh joy :/ another discovery from yesterday: https://bugs.launchpad.net/maas/+bug/1543968
<mup> Bug #1543968: MAAS 1.9.0 allows non-unique space names and shows no space id in a subnet <MAAS:New> <https://launchpad.net/bugs/1543968>
<dimitern> dooferlad, you'd love that I'm sure ^^ :)
<dooferlad> dimitern: yea...
<voidspace> dimitern: cool about master
<voidspace> dimitern: to make it worse, when they reference spaces (for example on subnets) - they do it by *name* not by id
<dimitern> maas is making really hard for juju to accept its imposed spaces management
<voidspace> dimitern: so if we want to use provider id we have to look them up by name to find the id
<voidspace> dimitern: and if the names are duplicated that's then impossible :-)
<dooferlad> dimitern: I think we just have to say that we can't support spaces on the current MAAS.
<dimitern> voidspace, nope, that's not unambiguous - we need to list all spaces and get the ids from there
<dimitern> dooferlad, only if ..
<voidspace> dimitern: unless they have two spaces with the same name and a different id as your bug report says
<voidspace> dimitern: so if it's space "foo", which "foo" is it?
<dimitern> voidspace, when you do discovery do you list the spaces or only subnets?
<voidspace> dimitern: list spaces which have all subnets
<dimitern> voidspace, so you then have all ids and names - duplicates or not
<voidspace> dimitern: but when we look up the links on an interface, the referenced subnet tells us the space *name*
<dooferlad> dimitern: what else can we do? It is broken. If they fix this and change the restriction on whitespace in a point release then we can just use a minimum MAAS version of 1.9.1
<voidspace> dimitern: and this is in provider code, so we can't just ask state
<dooferlad> dimitern: without fixing your bug we can't use names that match their names.
<voidspace> dimitern: we could list all spaces and subnets and get the id from there
<dimitern> voidspace, that's unavoidable I'm afraid
<dimitern> we can only do damage control atm
<dooferlad> dimitern, voidspace: We can't work around this in a user friendly way. We haven't released yet. Isn't it reasonable to get MAAS fixed and require the fixed version?
<voidspace> dooferlad: sounds reasonable to me
<dimitern> voidspace, dooferlad, I bet it will still land on us eventually
<voidspace> dooferlad: their space naming model doesn't match what we need and I'm sure it's an oversight on their part
<dimitern> i.e. "you are not talking - why did you discover this that late" ?
<dooferlad> dimitern: we are talking. It is a bug. We didn't notice it because it isn't our job to validate MAAS.
<dimitern> dooferlad, I know, but that's what will come to - all I'm saying
<dimitern> dooferlad, voidspace, which means our approach with renaming spaces on discovery was the only thing we can do now
<dooferlad> dimitern: if we take that attitude we are screwed anyway. We are better off being positive. We found the problem before any Juju + MAAS deployment suffered and it can be fixed before that point.
<voidspace> dooferlad: yep, +1 to that
<dimitern> let's chat in 10m
<dooferlad> dimitern: +1
<dooferlad> (no, not 11 minutes)
<dimitern> I think the issue stems from the attitude "we don't care how you set up your spaces or name them - you're the admin, you should know (no matter there's juju to care about)"
<dimitern> voidspace, dooferlad, I've rebased https://github.com/juju/juju/pull/4354 after the merge btw - still needs a review
<voidspace> dimitern: ok
<dimitern> voidspace, dooferlad, I hate to be a pest, but did you had a chance to look at that PR?
<voidspace> dimitern: I'm looking at it now
<dimitern> voidspace, tyvm!
<dimitern> voidspace, btw at least I found maas does not allow deleting a space a subnet is using: this: http://paste.ubuntu.com/15008282/
<voidspace> dimitern: right, I thought that was the case
<voidspace> dimitern: good
<dimitern> voidspace, haha! see the comment in bug 1543968: Critical for the lack of uniqueness on space names. That's close to unforgivable
<mup> Bug #1543968: MAAS 1.9.0 allows non-unique space names and shows no space id in a subnet <MAAS:Triaged> <https://launchpad.net/bugs/1543968>
<dimitern> dooferlad, ^^
<voidspace> dimitern: yeah, oops...
<voidspace> dimitern: the basic changes all look sound
<voidspace> plus the tests
<dimitern> voidspace, awesome, thanks!
<voidspace> dimitern: lots of "tinkering" with the code makes the diff harder to read (moving stuff around without semantic changes)
<voidspace> dimitern: nearly at the end
<voidspace> dimitern: alright, LGTM
<dimitern> voidspace, yeah, sorry about that churn, but at least makes the tests easier to follow I believe
<natefinch> ericsnow, katco: trivial patch for renaming comment to description - http://reviews.vapour.ws/r/3813/
<ericsnow> natefinch: ship-it
<natefinch> ericsnow: thanks
<natefinch> fwereade__: we have a card to fire the upgrade-charm hook when a new resource is uploaded... how do we do that?
<perrito666> omg unable to determine the series is like a bad dream that keeps returning
<alexisb> wake up perrito666, wake up!
<perrito666> honestly, how can we be panicking on the latest stable version of ubuntu, it is insane
<natefinch> gah, we talked about that in oakland... we gotta get rid of that stupid line in the version stuff
<voidspace> dimitern: ping
<dimitern> voidspace, pong
<voidspace> dimitern: just to confirm with you - at the moment we are using MAAS space *name* as the provider id
<voidspace> dimitern: (see maasEnviron.subnetFromJson)
<voidspace> dimitern: in fact we never call the spaces api directly - we fetch all subnets and build the spaces information from the subnets (because we only care about spaces that actually have subnets)
<dimitern> voidspace, yeah, we need to fix this soon
<voidspace> dimitern: and the subnets api doessn't give us a space id - only the name
<dimitern> voidspace, we're already using provider ids in acquireNode though
<dimitern> voidspace, yeah, we need to call spaces read in ListSpaces
<voidspace> dimitern: where does that id come from?
<voidspace> dimitern: for the endpoint bindings for acquireNode ?
<voidspace> dimitern: if we take it from the provider id from space in *state* then you have a name
<dimitern> voidspace, yeah
<dimitern> voidspace, I know :)
<dimitern> voidspace, but at least we pass it correctly
<dimitern> voidspace, to acquireNode, so once we fix what we store in state, we'll be a step closer
<voidspace> dimitern: you mean it's currently broken
<voidspace> dimitern: so a maasInstance is a created with a maasObject representing the node
<voidspace> dimitern: if the instance needs to call an api method not on the node that may not be possible
<voidspace> dimitern: I may need to change the way the instance is created
<voidspace> dimitern: just checking if I can get back to the client from the maasObject I have
<dimitern> voidspace, sorry, in a call - will get back to you soon
<mbruzek> Has anyone here bootstrapped a xenial image?  I am getting a juju error on amazon about the nonce.txt file not being found, and it aborts my bootstrap: http://paste.ubuntu.com/15009092/
<natefinch> dimitern: we're trying to look into how the upgrade-charm hook gets fired... we want to have that hook fired when we upload a new resource for a service... it looks like that means we should change the uniter's remotewatcher to watch for resources as well?
<natefinch> (when you're done your call)
<mbruzek> natefinch: Have you ever seen this nonce.txt error ?
<natefinch> mbruzek: hmm.... it definitely sounds familiar, though not something I've experienced personally
<natefinch> mbruzek: that's supposed to be created by our cloudinit script
<katco> mbruzek: isn't that created when you do --upload-tools ?
<katco> or am i remembering something completely different...
<mbruzek> natefinch: katco: Yeah it probably is, the cpc team said this was a core issue, but I can ask them again
<dooferlad> dimitern, voidspace: one failure on the latest run: http://reports.vapour.ws/releases/3594/job/run-unit-tests-trusty-ppc64el/attempt/4563
<dooferlad> allwatcher_internal_test.go:844: TestStateWatcherTwoModels.pN47_github_com_juju_juju_state.allWatcherStateSuite
<dimitern> dooferlad, voidspace, yay!
<dimitern> natefinch, hey
<dimitern> natefinch, so there's definitely a need for a watcher for resources, like for config settings etc.
<katco> ericsnow: ^^^
<dimitern> natefinch, depending on how the resources of a service are stored in state, it might be a simple notify watcher
<dimitern> natefinch, katco, ericsnow, however, it's been *some* time since I was around the uniter code, so where those changes need to go I'm not sure - fwereade__  should be a better source
<dimitern> cherylj, ping
 * ericsnow girds himself to enter the labyrinth
<cherylj> dimitern: pong.  in a standup so responses will be slow
<dimitern> cherylj, np, I just had a chat with alexisb about the state of maas-spaces
<dimitern> cherylj, and it looks like with the yesterday's changes we're down to 1 failure now (ppc64), and 2 CI issues causing container-networking and aws-deploy-xenial to fail
<dimitern> cherylj, so I suggested to wait for another run with today's changes and if it's not worse off tomorrow - do the merge
<dimitern> cherylj, since it looks like our best chance this week
<dimitern> voidspace, dooferlad ^^
<voidspace> great
<dimitern> cherylj, if you think that's acceptable, we can do it tomorrow
<dimitern> voidspace, btw can you have a look at that TestLoginsDuringUpgrade failure btw
<voidspace> dimitern: where?
<dimitern> voidspace, it's flaky and connected to spaces discovery
<voidspace> dimitern: ah, ok
<dimitern> voidspace, in cmd/juju somewhere.. let me have a look
<cherylj> dimitern: that's good news.  I know there's one fix I need to get into master
<voidspace> dimitern: if it gets a login failure it probably needs to wait and retry
<cherylj> dimitern: and I'll probably want your review on it :)
<voidspace> dimitern: as if discovery hasn't yet completed it will block temporarily
<dimitern> cherylj, awesome! sure - I'll have a look
<voidspace> dimitern: either that, or the test can patch discovery to complete immediately
<dimitern> voidspace, I tried both of those suggestions, up to the point of patching the worker creation
<voidspace> dimitern: well, it was worker creation I was suggesting patching
<voidspace> dimitern: to return a dummy worker and a closed channel
<dimitern> voidspace, but the test itself is a bit poorly written - it assumes that if it patches the upgrade steps block, it should be able to login almost immediately
<voidspace> dimitern: I don't understand that, I'd have to look at the test
<voidspace> dimitern: I'll do it after this
<voidspace> dimitern: so, another question - the maasInstance can't call the spaces api method because it only has a node maasObject
<voidspace> dimitern: and you can't go back from a node object to the client
<voidspace> dimitern: so a maasInstance will need either a reference to the maas client or to the environ itself
<voidspace> dimitern: which do you prefer?
<voidspace> dimitern: a maas instance having a reference to the environ (the provider substrate) seems reasonable
<dimitern> voidspace, it's there: ./featuretests/upgrade_test.go:86:func (s *upgradeSuite) TestLoginsDuringUpgrade(c *gc.C) {
<voidspace> dimitern: thanks
<dimitern> voidspace, ah, let me think for a sec..
<dooferlad> dimitern, voidspace: have made progress but am going to call it a day. If I get the urge I will do more hacking later, but I think I have at least solved my current problems.
<dimitern> dooferlad, sure, get some rest :)
<dooferlad> dimitern: thanks. Hope you get some too at some point!
<dimitern> voidspace, so if you have an instance of maasEnviron, you can get the client from there
<natefinch> ericsnow, katco: I think making a new watcher shouldn't be a big deal.  We can model it after the unitassigner, which works much the same way... just fires an event when there's a new item in a specific collection
<voidspace> dimitern: right
<dimitern> dooferlad, :) ta
<voidspace> dimitern: the maasInstance doesn't have that - my suggestion is to add it
<cherylj> dimitern: http://reviews.vapour.ws/r/3816/
<voidspace> dooferlad: o/
<natefinch> ericsnow, katco: also, unitassigner is very easy to grep for.  The watcher created in state/watcher.go  WatchForUnitAssignment
<katco> natefinch: that may be so. i think we should have a plan and then query wallyworld_, axw for validity
<natefinch> katco: sounds like a good idea'
<dimitern> voidspace, I've tried that before and I had to change quite a lot of code and tests
<dimitern> cherylj, will have a look shortly
<katco> natefinch: ericsnow: (or fwereade__ if he's available)
<cherylj> thanks, dimitern!
<ericsnow> katco: agreed
<voidspace> dimitern: it doesn't need to be set, it can be nil - so it shouldn't need to change any tests
<voidspace> dimitern: except new tests that *use* it
<dimitern> voidspace, yeah I suppose - give it a try
<voidspace> dimitern: ok, cool - thanks
<dimitern> voidspace, it will be easier to implement a helper taking *MAASObject and extracting the information from there
<voidspace> dimitern: you can't get there from an arbitrary *MAASObject
<dimitern> voidspace, like I did for maasObjectNetworkInterfaces fwiw
<voidspace> dimitern: oh, I see - to actually get the spaces
<dimitern> voidspace, yeah - the parsing
<voidspace> dimitern: I was thinking of implementing it on the environ, because we'll need it there anyway - and then have the instance just call the environ method
<dimitern> voidspace, as for getting it - sure, with the client.GetSubObject("spaces") I guess
<dimitern> voidspace, also works, yeah - I'd leave you to it then :)
<voidspace> dimitern: not if the MAASObject represents a node - which is how the instance is created
<dimitern> cherylj, ah, fwiw we have a better solution in progress for selecting the correct controller addresses and mongo peers
<cherylj> dimitern: does it happen at bootstrap?
<dimitern> cherylj, but it will get improved in steps
<dimitern> cherylj, right after the node boots as one of the first few things the MA will do
<cherylj> dimitern: it's good to know, but we need something to fix CI failures we're seeing now :)
<dimitern> cherylj, yeah, sure - just a heads up :)
<cherylj> thanks :)
<dimitern> cherylj, ship it
<cherylj> thanks, dimitern!
<dimitern> :) np
<dimitern> ok folks, eod of me
<mup> Bug #1544158 opened: add explicit unit tests for network.MergedAddresses <juju-core:Triaged by cherylj> <https://launchpad.net/bugs/1544158>
<cherylj> ehmagerd scp'ing to private fileshare is so slow
<perrito666> cherylj: off course it is, for some reason compunting never tried to solve the issue of sharing files decently
 * perrito666 found a supplier that will deliver hardware replacement to him on the day... I have never felt more firstworldish
<tych0> cherylj: do i need to have anyone's approval to merge https://github.com/juju/juju/pull/4355 ?
<cherylj> ericsnow, natefinch can one of you guys review tych0's PR?  ^^
<ericsnow> cherylj: I'll take a look
<katco> tych0: you know about the whole $$merge$$ thing right?
<ericsnow> cherylj, tych0: this one? http://reviews.vapour.ws/r/3800
<tych0> katco: yeah, but i don't know about what the rules are about when i can merge and can't :)
<tych0> ericsnow: yes, at least the numbers match up :)
<katco> tych0: just need a +1 on the reviews.vapour.ws site, and then you can do a $$merge$$ :)
<tych0> katco: right. i don't have a +1 yet :(
<cherylj> tych0: have you tried building on a clean wily system?  That will let you know if there will be build failures in CI
<tych0> cherylj: i have not
<tych0> i just deleted gosexy and built
<tych0> and it worked
<ericsnow> tych0: LGTM with one thing to fix
<tych0> ericsnow: ah, there isn't an implementation of it
<tych0> ericsnow: there's a lot of those stubs that are unimplemented actually
<ericsnow> tych0: oh, I bet we are embedding the interface (if so you can drop that review comment)
<tych0> ok
<tych0> ericsnow: ok. i just clicked drop. safe to $$merge$$ now?
<ericsnow> tych0: yep
<tych0> cool, thanks
<bogdanteleaga> anybody here using xenial?
<jcastro> xenial here
<katco> ericsnow: whatcha working on?
<katco> natefinch: how's your card coming? anything i can do to help?
<ericsnow> katco: oops, forgot to grab the card
<katco> ericsnow: np, why i asked :)
<natefinch> katco: lotta busywork writing tests.... the functionality is all there, just writing out a million struct literals for tests is a pain (since this thing needs a list of resources for the service and then a list for each unit)
<natefinch> katco: getting close though
<katco> natefinch: yeah, understand that is a pain =/
<katco> natefinch: still think you'll have it done today? hopefully before demo walkthrough?
<natefinch> katco: definitely by EOD, but possibly not by demo walkthrough.  I can certainly demo it as-is, it's just the tests left to do
<katco> natefinch: cool, i don't think that's a huge deal. still have till friday to clean up demo, so it's fine if that 1 aspect is working
<katco> natefinch: thx for the update
<natefinch> gah... I don't know what is up with list_charm_resource.go and it's test file... but git really doesn't like rebasing them
<katco> natefinch: meeting time
<perrito666> you know what is funnier? refactring those kind of tests :p
<tych0> hi cherylj, do i need to do anything to trigger the CI here? http://reports.vapour.ws/releases#lxd-container-type
<tych0> looks like it hasn't run after my last commit to lxd-container-type
<cherylj> tych0: it may take several hours as branches are tested one at a time
<tych0> ah, ok
<alexisb> wallyworld_, non urgent ping when you are in
<marcoceppi> in alpha2, do I still need to use an environments.yaml?
<marcoceppi> I ran init and it create .local/share/juju, etc
<marcoceppi> but if I try to create-model after "bootstrapping" I get some odd errors
<perrito666> marcoceppi: oh, can you pastebin it?
<marcoceppi> perrito666: http://paste.ubuntu.com/15011429/
<rick_h___> marcoceppi: create model requires passing a yaml -c option currently for the auth tokens and such to use
<rick_h___> marcoceppi: the idea being you can change the credentials used for different models
<rick_h___> marcoceppi: we've got a request in to wallyworld_ to have it default sanely to the ones used to bootstrap/etc
<rick_h___> marcoceppi: but I don't know that's hit yet
<marcoceppi> rick_h___: so this goes away when credentials/clouds are the way to roll out instead of environments.yaml ?
<rick_h___> marcoceppi: yes
<rick_h___> marcoceppi: but it will turn into an option
<perrito666> marcoceppi: checking
<marcoceppi> rick_h___: cool
 * marcoceppi tries
<rick_h___> marcoceppi: so for now, create a 'aws.yaml' with the settings it's fussing about and pass iot into create-model with a -c flag
 * wallyworld_ in meeting, will read backscroll in a bit
 * marcoceppi tries
<perrito666> marcoceppi: well those errors are incredibly unhelpful
<marcoceppi> rick_h___ perrito666 weee
<rick_h___> marcoceppi: woot
<marcoceppi> rick_h___: I got tripped up
<marcoceppi> rick_h___: because I was doing -c /path/to/file
<marcoceppi> but that was not the right thing
<marcoceppi> and I was about to make :( at you all
<marcoceppi> but then I checked myself
<marcoceppi> prior to wrecking myself
<marcoceppi> and I created a model
<marcoceppi> it's glorious
<rick_h___> marcoceppi: good to hear
<marcoceppi> rick_h___: will nu gui see these models?
<rick_h___> marcoceppi: yes, juju deploy the gui into the admin/first model
<rick_h___> marcoceppi: and it'll see them, list the models, and you can switch between them
<rick_h___> marcoceppi: I've been using that for demos recently
<marcoceppi> it was totally worth installing golang on this computer
<rick_h___> marcoceppi: :)
<perrito666> marcoceppi: it is always worth to install golang ;)
<marcoceppi> I really wanted to just get a new svg.juju.solutions out but I kind of got sidetracked
<marcoceppi> Makyo: you around?
<rick_h___> marcoceppi: they're just coming back from team dinner tonight at the sprint
<rick_h___> marcoceppi: I'd not count on it, maybe email instead
<marcoceppi> rick_h___: no worries, I got it sorted
<marcoceppi> rick_h___: http://svg.juju.solutions/?bundle-file=https://raw.githubusercontent.com/whitmo/bundle-kubernetes/master/bundles.yaml
<rick_h___> ah cool
<axw> katco: sorry I didn't respond to the invite, I was asleep: )
<rick_h___> marcoceppi: sexy
<katco> axw: no worries at all; you were optional
<perrito666> thats a cruel thing to say to axw
<perrito666> you are so optional mate
<axw> heh :)
<axw> job title: superfluous
<axw> anastasiamac: accounts.yaml marshal/unmarshal is assigned to you; ok if I assign to myself?
<anastasiamac> axw: yes but i was going tos tart on it today
<anastasiamac> axw: i have list- and show- proposed
<anastasiamac> but want to clean it a bit today too
<anastasiamac> it=them*
<axw> anastasiamac: only reason I was going to look at it was to complete what we were talking about in mini-meeting yesterday
<axw> anastasiamac: so we have the correct final approach for opening API connections
<anastasiamac> axw: go ahead if it's buringin then \o/
<anastasiamac> sounds good
<davecheney> cherylj: what's the status of 1.25.4 ?
<davecheney> i'm building up a lot of chagnes on master that should be backported to 1.25
<anastasiamac> axw: but if u r lookiing for things to do, I'd love to see what u'd do with file locks :D
<axw> anastasiamac: that's fairly low priority atm. important, but we can change it behind the scenes without impacting any other code
<perrito666> ok seems that compiling the tests and running hangout might be a bit too much for the laptop
<davecheney> whee, just looked at the org chart, i have 6 manager above me
<davecheney> only 4 more and we'll be microsoft class
<wallyworld_> alexisb: standup if you are free
<perrito666> davecheney: I wish, they have lovely cafeterias
<davecheney> https://twitter.com/Stephenitis/status/697560639657680896
<davecheney> ^ this is good news
#juju-dev 2016-02-11
<davecheney> cherylj: ping
<davecheney> 10:03 < davecheney> cherylj: what's the status of 1.25.4 ?
<davecheney> 10:04 < davecheney> i'm building up a lot of chagnes on master that should be backported to 1.25
<thumper> davecheney: I think you should prepare the changes for 1.25 branch
<thumper> the question becomes whether to do one or many
<thumper> davecheney: I hear zfs works real well with lxd
<davecheney> thumper: should I land what I have now?
<davecheney> when is 1.25.4 coming out ?
<thumper> davecheney: I think some of these connection type issues are needing to be fixed in 1.25 too
<thumper> so yes, I think you should be landing these changes on 1.25 too
<axw> anastasiamac: thanks for review, please see my response to your issue before I go ahead
<perrito666> sweeet master is bless
<axw> perrito666: I hope you kicked off all your merges before you announced that
<perrito666> axw: no pending merges from me :)
<axw> perrito666: :p
<alexisb> davecheney, cherylj is out for the evening
<mup> Bug #1491399 changed: TestInstallMongodServiceExists fails on centos <centos> <ci> <precise> <regression> <test-failure> <juju-core:Fix Released> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1491399>
<mup> Bug #1494726 changed: TestGetUsesCache different mime-type centos <centos> <ci> <test-failure> <unit-tests> <juju-core:Fix Released by cherylj> <juju-core 1.25:Fix Released by cherylj> <https://launchpad.net/bugs/1494726>
<mup> Bug #1491399 opened: TestInstallMongodServiceExists fails on centos <centos> <ci> <precise> <regression> <test-failure> <juju-core:Fix Released> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1491399>
<mup> Bug #1494726 opened: TestGetUsesCache different mime-type centos <centos> <ci> <test-failure> <unit-tests> <juju-core:Fix Released by cherylj> <juju-core 1.25:Fix Released by cherylj> <https://launchpad.net/bugs/1494726>
<mup> Bug #1491399 changed: TestInstallMongodServiceExists fails on centos <centos> <ci> <precise> <regression> <test-failure> <juju-core:Fix Released> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1491399>
<mup> Bug #1494726 changed: TestGetUsesCache different mime-type centos <centos> <ci> <test-failure> <unit-tests> <juju-core:Fix Released by cherylj> <juju-core 1.25:Fix Released by cherylj> <https://launchpad.net/bugs/1494726>
<davecheney> alexisb-afk: ahh, thanks
<davecheney> thumper: do we have a error.Causes checker ?
<davecheney> ie, rather than writing
<davecheney> errors.Cause(err), gc.Equals, ....)
<davecheney> can wr write
<thumper> I don't think so...
<davecheney> err, gc.Causes, expected
<davecheney> i thought you were talking about adding htat way back when
<thumper> there is jc.Satisfies
<davecheney> that checks type
<thumper> I'm not sure if that looks at the cause
<davecheney> which isn't close enough
<thumper> pretty sure we don't
<thumper> but could be useful
<davecheney> anyway, i have got my branch to the point that we dont' have to add all that 'request error: ' prefix nonsense
<thumper> cool
<davecheney> which is the whole reason params.ClientError existed -- to filter that out
<davecheney> now we have *rpc.RequestError as a type, properly annotated all the way back out to the caller
<thumper> :)
<davecheney> thumper:
<davecheney> -               c.Assert(err, gc.ErrorMatches, "permission denied")
<davecheney> +               c.Assert(errors.Cause(err), gc.Equals, &rpc.RequestError{
<davecheney> +                       Message: "permission denied",
<davecheney> +                       Code:    "unauthorized access",
<davecheney> +               })
<thumper> nice
<thumper> ...
<thumper> but begs for some new checkers
<thumper> c.Assert(err, blah.IsUnauthorized)
<davecheney> lets see how big the diff is
<davecheney> i dont want to change more than I have to to backport this to 1.2
<davecheney> i dont want to change more than I have to to backport this to 1.25
<thumper> k
<davecheney> yeah, this attempt is generating a much smaller diff
<mup> Bug # changed: 1497355, 1508585, 1510951, 1514877, 1534201, 1536425, 1536426, 1539656, 1542336, 1543178, 1543189, 1543193
<mup> Bug # opened: 1497355, 1508585, 1510951, 1514877, 1534201, 1536425, 1536426, 1539656, 1542336, 1543178, 1543189, 1543193
<mup> Bug # changed: 1497355, 1508585, 1510951, 1514877, 1534201, 1536425, 1536426, 1539656, 1542336, 1543178, 1543189, 1543193
<mup> Bug #1538868 changed: kill-controller failed: sudo: switch: command not found <ci> <kill-controller> <local-provider> <regression> <juju-core:Invalid> <juju-core api-command-rename:Fix Released by cherylj> <https://launchpad.net/bugs/1538868>
<mup> Bug #1541473 changed: ensure-availability brings down the state-server <ci> <ensure-availability> <regression> <tech-debt> <juju-core:Fix Released by cherylj> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1541473>
<mup> Bug #1543216 changed: EOF uploading charm <charm> <ci> <deploy> <intermittent-failure> <tech-debt> <juju-core:Fix Released by cherylj> <https://launchpad.net/bugs/1543216>
<tych0> cherylj: hrm. still hasn't run :(
<tych0> cherylj: is there a queue somewhere i can look at?
<mup> Bug #1538868 opened: kill-controller failed: sudo: switch: command not found <ci> <kill-controller> <local-provider> <regression> <juju-core:Invalid> <juju-core api-command-rename:Fix Released by cherylj> <https://launchpad.net/bugs/1538868>
<mup> Bug #1541473 opened: ensure-availability brings down the state-server <ci> <ensure-availability> <regression> <tech-debt> <juju-core:Fix Released by cherylj> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1541473>
<mup> Bug #1543216 opened: EOF uploading charm <charm> <ci> <deploy> <intermittent-failure> <tech-debt> <juju-core:Fix Released by cherylj> <https://launchpad.net/bugs/1543216>
<cherylj> tych0: we've been busy testing master
<axw> wallyworld_: sorry, I forgot to look at your branch earlier. it's ready to ship now
<cherylj> tych0: now that we're releasing alpha2, CI should pick up other branches
<wallyworld_> axw: np, ty. i've been caught up in other things
<tych0> cherylj: ah, ok, cool.
<cherylj> davecheney: we will probably be doing 1.25.4 after 2.0-beta1.  So, sometime the week of Feb-22
<mup> Bug #1538868 changed: kill-controller failed: sudo: switch: command not found <ci> <kill-controller> <local-provider> <regression> <juju-core:Invalid> <juju-core api-command-rename:Fix Released by cherylj> <https://launchpad.net/bugs/1538868>
<mup> Bug #1541473 changed: ensure-availability brings down the state-server <ci> <ensure-availability> <regression> <tech-debt> <juju-core:Fix Released by cherylj> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1541473>
<mup> Bug #1543216 changed: EOF uploading charm <charm> <ci> <deploy> <intermittent-failure> <tech-debt> <juju-core:Fix Released by cherylj> <https://launchpad.net/bugs/1543216>
<anastasiamac> axw: u r all good to go! HUGE thank you for this PR \o/
<axw> anastasiamac: thanks, accounts.yaml on its way (basically just a sed command, for real)
<axw> anastasiamac: also, your PRs are reviewed
<anastasiamac> axw: u r amazing \o/ tyvm!
<mup> Bug #1538868 opened: kill-controller failed: sudo: switch: command not found <ci> <kill-controller> <local-provider> <regression> <juju-core:Invalid> <juju-core api-command-rename:Fix Released by cherylj> <https://launchpad.net/bugs/1538868>
<mup> Bug #1541473 opened: ensure-availability brings down the state-server <ci> <ensure-availability> <regression> <tech-debt> <juju-core:Fix Released by cherylj> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1541473>
<mup> Bug #1543216 opened: EOF uploading charm <charm> <ci> <deploy> <intermittent-failure> <tech-debt> <juju-core:Fix Released by cherylj> <https://launchpad.net/bugs/1543216>
<anastasiamac> axw: about show-contoller not showing last model... would be nicer to show all models for this controller with indication of current?
<axw> anastasiamac: I think both would be good actually
<anastasiamac> axw: excellent \o/ i agree :D
<mup> Bug #1538868 changed: kill-controller failed: sudo: switch: command not found <ci> <kill-controller> <local-provider> <regression> <juju-core:Invalid> <juju-core api-command-rename:Fix Released by cherylj> <https://launchpad.net/bugs/1538868>
<mup> Bug #1541473 changed: ensure-availability brings down the state-server <ci> <ensure-availability> <regression> <tech-debt> <juju-core:Fix Released by cherylj> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1541473>
<mup> Bug #1543216 changed: EOF uploading charm <charm> <ci> <deploy> <intermittent-failure> <tech-debt> <juju-core:Fix Released by cherylj> <https://launchpad.net/bugs/1543216>
<axw> wallyworld_: I'll fix your comments in my next branch for accounts
<axw> fix/address
<wallyworld_> np ata ll
<axw> wallyworld_: when you remove the api-info command, can you please remove ModelCommandBase.ConnectionEndpoint (if you haven't already)
<wallyworld_> yup
<wallyworld_> axw: i'm waiting to merge your work and then will deal with the inevitable conflicts etc
<axw> wallyworld_: ok
<davecheney> cherylj: ok, i'll work hard to get all my fixes backported before then
<anastasiamac> wallyworld_: axw: list-controllers output in spec shows "-" for not-currently-logged-in... AFAIK there is no precedence, can I just leave the column cell empty or is "-" highly desired?
 * wallyworld_ checks the spec
<anastasiamac> p 9 (of 13)
<axw> anastasiamac: I kinda like "-", but prefer consistency
<anastasiamac> axw: we can start consistency from here, if it's preferred :D
<wallyworld_> "-" is for currently logged in
<wallyworld_> not not currently logged in
<wallyworld_> right?
<wallyworld_> and * is for default
<anastasiamac> wallyworld_: USER and MODEL columns
<wallyworld_> ah
<anastasiamac> wallyworld_: the prefix - is not consistent
<anastasiamac> wallyworld_: and list-model uses * suffix to indicate current
<wallyworld_> "-" is for the active controller
<wallyworld_> you can be logged into more than one
<wallyworld_> but only one is active
<anastasiamac> wallyworld_: axw and I *thought* *suffix would be nice for active controller too
<wallyworld_> how to we denote the default one in that case?
<wallyworld_> i agree that  we should be consistent
<axw> wallyworld_: we're talking about the "-" in columns that have no value
<axw> wallyworld_: separately, there is some inconsistency in the spec w.r.t. using - vs * for active
<axw> I think we settled on using * as a suffix
<wallyworld_> yes :-(
<wallyworld_> ok
<anastasiamac> wallyworld_: axw: http://pastebin.ubuntu.com/15013438/
<wallyworld_> i must admit, i would like to see "-" for empty region too :-)
<wallyworld_> when in doubt, i think we adhere to spec (use "-" for model/user) and ask for feedback
<anastasiamac> wallyworld_: yes, I think we should b consistent from now on to show "-" for empty in cmd output :D
<anastasiamac> wallyworld_: axw: from the pastebin above, *suffix may be obscured by long names...
<axw> wallyworld_ anastasiamac: added AccountStore
<axw> https://github.com/juju/juju/pull/4379/
<wallyworld_> \o/
<anastasiamac> axw: u r powering thru this \o/
<axw> anastasiamac: a simple sed command
<axw> :)
<anastasiamac> axw: all simple things r ingenious :P
<mup> Bug # changed: 1382274, 1468972, 1497802, 1511659, 1515289, 1533275, 1533896, 1535165, 1536378, 1537717, 1540701, 1542510
<wallyworld_> in your current work, we are moving away from separate current-controller and current-model files right?
<anastasiamac> wallyworld_: this is what it looks like form axw's recent PRs \o/
<axw> wallyworld_: for now we still have current-controller, but current-model will be no more
<wallyworld_> great, i only skimmed, just wanted to check :-)
<axw> anastasiamac: ^
<axw> we can add current-controller to controllers.yaml too though?
<wallyworld_> i think so
<mup> Bug # opened: 1382274, 1468972, 1497802, 1511659, 1515289, 1533275, 1533896, 1535165, 1536378, 1537717, 1540701, 1542510
<wallyworld_> axw: although, that embeds user state in that file
<wallyworld_> so not sure. makes sense for models file as that's a cache
<axw> wallyworld_: true. and you'd (probably) never share accounts.yaml.
<wallyworld_> yes, i was thinking about accounts.yaml too and think i came to the same conclusion that it's ok to put current account in there, but still am not 100%
<wallyworld_> i can see a case for a current-ccount file
<axw> wallyworld_: it'll need to be a per-controller file
<wallyworld_> true, so in that case, ok as is probably
<mup> Bug # changed: 1382274, 1468972, 1497802, 1511659, 1515289, 1533275, 1533896, 1535165, 1536378, 1537717, 1540701, 1542510
<anastasiamac> axw: wallyworld_: could we plz update blueprint with all files we are unravelling? :P
<wallyworld_> one day
<wallyworld_> the files are in the spec
<wallyworld_> i don't want to duplicate info
<wallyworld_> the blueprint should just refer to the spec
<wallyworld_> we should have separate as-built doco
<wallyworld_> but that's not for the blueprint, we should have that stuff elsewhere
<wallyworld_> we're not good at doing that though :-(
<wallyworld_> the blue print can refer to the as-built doc
<wallyworld_> the blueprint is more to track progess the way we're using it
<anastasiamac> wallyworld_: also to communicate with QA
<anastasiamac> wallyworld_: this info can b the backbone of Release Notes
<wallyworld_> there needs to be separate doc for that IMO - a proper test plan
<anastasiamac> wallyworld_: that we tend to write *after* the effect
<wallyworld_> file implementation detail is not for release notes
<anastasiamac> wallyworld_: \o/ proper test plan would b amazing!
<anastasiamac> when and who would do it?
<wallyworld_> all the people we don't have :-(
<wallyworld_> should be done as the feature is planned, post one page spec
<anastasiamac> file implementation detail is not but what files to expect may b of interest to QA
<wallyworld_> sure, but that's not what we are using blueprints for
<wallyworld_> the spec in this case has the file detail
<wallyworld_> but it's not detailed enough for QA - we need a test plan
<wallyworld_> wish there were more hours in a day
<anastasiamac> wallyworld_: i agree, jeez, a lot of planning and definition needs to happen after one pager :D Test Plans, Acceptance Criteria, Task break down
<wallyworld_> indeed
<wallyworld_> we do the task breakdown
<anastasiamac> wish we had a dedicated resource... :)))
<wallyworld_> yes :-(
<anastasiamac> wallyworld_: https://www.youtube.com/watch?v=Dj3GH5myc3M
<wallyworld_> rotflmao
<wallyworld_> you look nothing like a donkey
<wallyworld_> are you saying i am an ogre
<anastasiamac> wallyworld_: not everything needs to be read literally (just btw the lines) :P
<wallyworld_> i know, just going along with the theme
<anastasiamac> :)) i know u know
<axw> wallyworld_: a smaller, easier one: http://reviews.vapour.ws/r/3823/
<wallyworld_> looking
<axw> so we don't need to change crap that can just be deleted
<wallyworld_> +1 to that
<anastasiamac> +2
<wallyworld_> axw: there may be some nuggets in api_test that need to be retain i suspect?
<wallyworld_> or at least re-homed
<axw> wallyworld_: the file's not gone, the branch is conflicted so it doesn't show up on RB
<axw> wallyworld_: will fix in a sec, look on GitHub in the mean time please
<wallyworld_> ok
<axw> wallyworld_: so once controllers, models, accounts are all in, what else are you waiting on?
<axw> wallyworld_: are you doing the changes to pass controller/model name through, or am I?
<axw> pass through to API conn opening code that is
<wallyworld_> i was working to eliminate cache.yaml
<wallyworld_> remove bootstrap config etc
<wallyworld_> and not write controller addresses, accounts etc
<wallyworld_> you could do the work to pass in controller/model first
<wallyworld_> i am currently adding private-key to joyent
 * thumper headdesks
<wallyworld_> but the credentials stuff needs to pass in the optional attr
<axw> wallyworld_: seems like something you'd do at the same time
<wallyworld_> ok, np, i can do do, need to look at the code again
<axw> wallyworld_: that's why I don't want it to be a separate attr, but a flag on the attr that allows you to specify a file
<axw> wallyworld_: I'm happy to do it, just not sure how far into it you are
<wallyworld_> the joyent stuff?
<wallyworld_> just started looking
<wallyworld_> so you can do that if you want
<axw> wallyworld_: no, the API stuff
<wallyworld_> i have a branch that i started that has a shit tonne of changes, but many will be conflicting with your recent work; i think it just needs to be discarded
<wallyworld_> so you could look to do that next bit while you're on a roll in the area
<axw> wallyworld_: ok. if I can, I'll leave stuff to be done in parallel
<wallyworld_> axw: what i can do first if you want is remove the bootstrap config stuff
<wallyworld_> that won't conflict too much
<axw> wallyworld_: that would be good
<wallyworld_> axw: in the interim, did you want to add that fromfile attr to credentials schema? CI needs it
<wallyworld_> as they like to use the private-key directly
<axw> wallyworld_: ok, I'll take a lok
<axw> look*
<wallyworld_> ok, ty
<wallyworld_> axw: damn, such a long queue waiting to land, hopefully your account store is not at the end
<axw> wallyworld_: maybe just pull my branch down and work off that?
<axw> wallyworld_: actually you shouldn't need it
<axw> if you're just removing bootstrap bits
<wallyworld_> might go a bit further depending. wil grab a bite to eat
<anastasiamac>  /me is surprised thumper's desk is still standing
<davecheney> thumper: PTAL
<davecheney> https://github.com/juju/juju/pull/4361
<davecheney> totally redone and made much simpler
<davecheney> no reviewboard link im afraid
<thumper> hmm... I wonder why no reviewboard
<davecheney> 'cos I closed the old review
<davecheney> removed the link from the description
<davecheney> but rb didn't add a new one
<davecheney> bootstrapping
<davecheney> is
<davecheney> soooo
<davecheney> slow
 * davecheney drums fingers while some huge file is uuencoded, sent to the remote bash at a few kb / sec
<davecheney> thumper: if this bootstrap works
<davecheney> are you find with me to JFDI this fix onto master
<davecheney> then I'll roll up a big backport patch for 1.25
<thumper> which fix is this?
<thumper> the error stuff?
<davecheney> https://github.com/juju/juju/pull/4361
<davecheney> this is all the groudnwork I think we need to implement retrying on all API requests
<thumper> davecheney: yes
<wallyworld_> axw: the preferIPv6 flag is used to sort the host api addresses so that ipv6 appear first because we start at the top of the list and try each in turn
 * thumper is off now
<axw> wallyworld_: I understand how, but not why
<axw> wallyworld_: if we're trying them all, why does it matter...?
<wallyworld_> because we will take the first one we connect to i think
<wallyworld_> connect to successfully
<axw> wallyworld_: yep... why does that matter? :)
<wallyworld_> not sure, but i assume this has come from stakeholders who want juju to connect to ipv6 if at all possible
<axw> wallyworld_: I *think* it might be because api-endpoints prints out the last-connected-to address,  and someone was relying on that being v4/v6
<wallyworld_> yeah, not sure either
<axw> wallyworld_: no rush, but joyent change is here: http://reviews.vapour.ws/r/3827/
<axw> wallyworld_: not tested because I have no account, but there's a unit test un the cloud package
<wallyworld_> axw: awesome, ty. have almost finished unpicking the change from my conflicted branch that i want to keep, have tests to fix. btw you can get joyent creds from cloud-city repo
<wallyworld_> changes
<axw> wallyworld_: cool
<axw> wallyworld_: yeah, being lazy. I'm pretty sure it's ok.
<wallyworld_> axw: lgtm
<axw> wallyworld_: ta
<axw> wallyworld_: it's a bit more than immediately necessary, but my intention is to add things like this into environschema
<wallyworld_> yep, i like it
<wallyworld_> fark so many failing tests to fix :-( i hate tests that compare log lines
<wallyworld_> axw: remind me - restore will be broken with the current cloud-credentials branch i think you said?
<axw> wallyworld_: correct
<wallyworld_> axw: we'll need to fix that if we want to get this branch into master for beta1. is that something you could look at next rather than the next round of feature work
<axw> wallyworld_: ok
<wallyworld_> ta, i can't recall the scope of the problem offhand
<wallyworld_> hopefully not too major
<axw> wallyworld_: https://github.com/juju/juju/blob/cloud-credentials/cmd/juju/backups/restore.go#L133
<wallyworld_> ah yes that's right
<axw> wallyworld_: I'm assigning 5 points to that, sound reasonable?
<wallyworld_> think so, or 8 if it turn ulgy
<wallyworld_> axw: as a drive by, could you also change the version to "delta1" so that the QA guys can target the new scripts
<axw> wallyworld_: delta? not beta?
<wallyworld_> axw: master is beta1, we need something different for this feature branch just as the new scripts are being tested
<axw> wallyworld_: ok
<wallyworld_> we will change back to beta1 prior to merge
<davecheney> wat?
<davecheney>         "github.com/juju/juju/apiserver/testing"
<davecheney>         apiservertesting "github.com/juju/juju/apiserver/testing"
<dimitern> :) my fav so far is "gitjujutesting"
<davecheney> why do we have juju/api, the client
<davecheney> and
<davecheney> juju/apiserver/client ... ?
<axw> wallyworld_: the restore-rebootstrap code is broken in general. I propose we delete it.
<axw> wallyworld_: ... and just require people to bootstrap-then-restore
<axw> wallyworld_: (BTW, CI is not using this code path AFAICS)
<frobware> dimitern, voidspace, dooferlad: I'm back in the land of the living \o/
<frobware> dimitern, voidspace, dooferlad: and this (http://reports.vapour.ws/releases/3596) tells me maas-spaces is blessed. \o/ \o/ \o/
<frobware> dimitern, voidspace, dooferlad: nice work!
<voidspace> frobware: double yay!
<voidspace> \o/
<dimitern> frobware, hey! welcome back! :)
<dimitern> frobware, oh yeah! we're merging today
<jamespage> dimitern, frobware: some comments on the extra bindings stuff but I think it will fulfill our requirements
<dimitern> jamespage, awesome! tyvm
<frobware> jamespage, thanks. I think your "is this a list" can be answered by the "Future extensions" section
<jamespage> frobware, ack - i see
<dimitern> frobware, you can't hear me apparently
<frobware> jamespage, I was just typing that when your ^ message arrived. :)
<jamespage> one comment on the network-get use for extra-bindings - feels odd with just the name but that might be just me
<frobware> dimitern, nope. problem is definitely at my end.
<dimitern> frobware, I can hear you fine though
<TheMue> morning folks o/
<voidspace> TheMue: o/
<voidspace> dimitern: so, I'm building a function that builds a map of spaces from maas name -> SpaceInfo
<voidspace> dimitern: we *could* use that in maasEnviron.Spaces to set ProviderId as well as Name
<voidspace> dimitern: shall I do that in my branch or leave it for a follow up?
<voidspace> dimitern: (we still need the space name from MAAS here so we can generate a juju name)
<dimitern> voidspace, let's chat during standup
<voidspace> dimitern: kk
<dimitern> frobware, fyi, here's how I tested: http://paste.ubuntu.com/15015446/
<frobware> dimitern, do you currently see any failures with what's on maas-spaces now?
<dimitern> frobware, yes, that's the base line - about 10 out of 50, the one with the patch is running now
<frobware> dimitern, can you pastebin the patch
<dimitern> frobware, http://paste.ubuntu.com/15015467/
<dimitern> voidspace, ^^ that's what you meant, right?
<frobware> dimitern, ty
<dimitern> frobware, with the patch I can see the forked processes running almost in sync
<frobware> dimitern, and which version of Go are you using?
<dimitern> frobware, on first glance - fewer failures: 7 out of 50, but in reality less than 5 due to TestLoginsDuringUpgrade - the rest are mongo panics and other similar
<dimitern> frobware, go version go1.6rc2 linux/amd64
<frobware> dimitern, so I initially tried with loop(1..5). I got one failure. What's the failure message to look for without the patch?
<frobware> dimitern, upgradeSuite.TestLoginsDuringUpgrade?
<dimitern> frobware, usually upgrade_test.go:316:
<dimitern> frobware, actually with the patch it's always that same line - without it occasionally lines 138 or 129 fail as well
<frobware> dimitern, so it fails with the patch too?
<dimitern> frobware, it does, but about less than half of the unpatched runs
<dimitern> s/of/compared to
<frobware> dimitern, so not a slam dunk in terms of landing this before merging maas-spaces back into master...
<frobware> dimitern, just trying to assess the risk of landing this change vis-a-vis merging what we have
<dimitern> frobware, I still think landing as is ok atm
<wallyworld_> axw: sounds ok to me, sorry i was at soccer. if it didn't work anyway, then no point keeping it
<voidspace> dimitern: not really
<voidspace> dimitern: just the changes lines 28-29 in that diff are sufficient
<voidspace> dimitern: the other changes are fine too I guess
<dimitern> voidspace, cheers
 * dimitern just realized we haven't tried maas-spaces on maas 1.10 - yet another maas to setup (mostly done anyway)
<frobware> dimitern, voidspace, dooferlad: I plan to postpone the release note sync. any objections?
<dimitern> frobware, +1
<voidspace> cool
<voidspace> dimitern: heh, so the spaces endpoint isn't implemented in the gomaasapi test server
<voidspace> dimitern: so looks like I'm diverting into that
<dimitern> voidspace, yeah, unfortunately, but it can be worked around
<dimitern> voidspace, like what I did for the interfaces
<voidspace> dimitern: well, I can patch out the function - but then that code isn't tested
<dimitern> voidspace, the parsing can be tested given a maasObject
<voidspace> dimitern: well yes, but it still leaves untested code
<dimitern> voidspace, but at this point it's better to do it properly and start tackling the piling gomaasapi changes we need
<voidspace> dimitern: so you're saying I should implement spaces for gomaasapi?
<voidspace> it's not hard
<dimitern> voidspace, yeah, exactly
<voidspace> dimitern: cool
<frobware> dimitern, so I tested a bit, with/without the patch and looping(1..5) - failure rate seems identical.
<frobware> voidspace, ^^
<voidspace> frobware: dimitern: The change is still good, but may not be the root issue for this test.
<frobware> voidspace, yeah, we should separate the two. patch good, but there's something else too.
<voidspace> frobware: dimitern: I haven't had a chance to look at the test, but I suspect if it's just trying to login after upgrade and it hits a discovery in progress error it need to try again (in a short attempt loop)
<voidspace> frobware: hmm, it's in a LongAttemptLoop
<voidspace> frobware: what's the full failure message please
<frobware> voidspace, bear with - I'll pastebin a failure.
<voidspace> frobware: ah, during discovery api.Open will fail - so line 316 should be "return err" not an Assert
<voidspace> dimitern: ^^
<voidspace> dimitern: that should fix it
<dimitern> voidspace, hmm possibly, yeah
<voidspace> dimitern: I'm pretty sure  - I hit that in writing the code/tests for limitLogins
<voidspace> because we're preventing login, not returning a restricted api
<voidspace> you should see very similar code in the machine_test.go for limited logins during space discovery
<voidspace> api.Open returns an error until discovery is completed
<voidspace> and it's intermittent because it's timing related - there's only an error if the login attempt is in the short window whilst discovery is in progress
<dimitern> voidspace, sounds good
<dimitern> voidspace, and we do have another test to check that client logins are blocked while agent logins are not?
<voidspace> dimitern: yes
<voidspace> dimitern: the test tries to login as a user - that fails with the right error message
<voidspace> dimitern: then it checks it *can* login as the local machine and that succeeds
<voidspace> dimitern: then after discovery completes the client login succeeds
<dimitern> voidspace, sweet!
<frobware> voidspace, http://pastebin.ubuntu.com/15016031/
<voidspace> frobware: in featuretest/upgrade_test.go change line 316 from c.Assert to "if err != nil { return err}"
<voidspace> frobware: it *should* pass more reliably then
<voidspace> the real commit should have a comment too I guess that api.Open can fail if discovery is still in progress
<voidspace> and it should be *with* dimitern's fix to prevent deadlock
<frobware> voidspace, ok - funnily enough I just got 3 successful runs ... hence why it took a while to pastebin. :)
<frobware> voidspace, oh-la-la. I'm now out of disk space, so the tests are failing... Grrr.
<frobware> voidspace, looks like mongo is leaving stuff in /tmp. Approximately 5GBs worth. :(
<voidspace> nice
 * voidspace lunch
<frobware> voidspace, I need to go eat too. bbiab.
<dimitern> frobware, dooferlad, voidspace, guys, I've prepared the merge PR: https://github.com/juju/juju/pull/4392 and I'll leave you to your judgment, but now's the best time to get it in
 * dimitern goes to get some rest (off tomorrow btw)
<katco> ericsnow: standup time
<voidspace> frobware: I say ShipIt
<frobware> voidspace, sure? ;)
<frobware> voidspace, the err check instead of assert makes a diff.
<voidspace> frobware: does?
<voidspace> cherylj: ping
<frobware> voidspace, yes. just double-checking because the tests leave /tmp/test-mgo* files around so can't run it for a long time. Just working around that atm.
<voidspace> frobware: cool
<voidspace> frobware: I can do that on master with the potential deadlock fix
<voidspace> after maas-spaces lands
<frobware> voidspace, agreed. but give me 20 mins, as I'm part way through this already.
<voidspace> frobware: it will take that long to land maas-spaces anyway I think, waiting on cherylj to give the ndo
<frobware> voidspace, btw, we just got a maas-spaces cursed build.
<voidspace> *nod even
<frobware> cherylj, we have a both a blessed and cursed maas-spaces build. Choose your poison. :)
<voidspace> cherylj:  frobware: leadership (uniter) tests failed in attempt 291 but succeeded in 292
<voidspace> (trusty unit tests)
<voidspace> that was the only failure
<alexisb> frobware, cherylj are we need a CI on MAAS Spaces?
<voidspace> alexisb: we had a bless
<frobware> alexisb, we've had two results today. 1 blessed, and just recently 1 cursed.
<voidspace> alexisb: then a curse due to a flakey test
<alexisb> SWEET!
<frobware> :)
<frobware> alexisb, personally, I'm big fan of the first result.
<alexisb> cherylj, sinzui are there any high priority branches we are needed to test asap?
<alexisb> frobware, heh
<sinzui> alexisb: upgrade-mongodb3
<alexisb> sinzui, past that run can we queue up lxd-container-type for tych0 ?
<sinzui> alexisb: we are retesting maas-spaces which had i386 and ppc64el failures.
<sinzui> alexisb: oh, well, it is actually in the priority list after mongo3
<alexisb> sweet, thanks
<frobware> alexisb, sinzui: am I hearing we're waiting for another blessed build?
<sinzui> frobware: yes.
<frobware> boo said the crowd
<frobware> sinzui, is this some form of majority vote?
<sinzui> frobware: no. there are voters and non-voters. ppc64el unit tests vote. Ci will willing to test 3 times...juju is that bad on ppc64el. But maas-spaces might need 5 or 6 tries to pass
<frobware> sinzui, I meant in terms of status overall. this morning maas-spaces was blessed.
<dooferlad> voidspace: can I pick your brains for a moment?
<voidspace> dooferlad: sure
<sinzui> frobware: yes, but dimitern merged another change and now we don't have a bless. also. I forced a retest of ppc as you were waking up to get that bless
<dooferlad> voidspace: hangout?
<voidspace> dooferlad: sure
<voidspace> dooferlad: give me ten minutes!
<voidspace> dooferlad: send me a hangout link - just about to phone the bank
<dooferlad> voidspace: no problem. Ping me when you are ready. Was going to use https://plus.google.com/hangouts/_/canonical.com/juju-sapphire?authuser=0
<frobware> sinzui, which change? this one? http://reviews.vapour.ws/r/3829/
<sinzui> maybe http://reports.vapour.ws/releases/3597 points to https://github.com/juju/juju/commit/f4de48d033ce30be495756492ba3ab726a3ec68f
<sinzui> frobware: I am going to restart the host and retest
<frobware> sinzui, ack
<frobware> sinzui, is ppc64 using gc or gccgo?
<sinzui> frobware: gccgo-go
<frobware> sinzui, ok I temporarily have access to h/w - will try running the unit tests.
<sinzui> frobware: you have permanent access to the stilsons CI uses.
<voidspace> dooferlad: frobware: alexisb: my daughter just had a fit (febrile convulsion - she's had them before)
<frobware> sinzui, heh. yes, I keep forgetting about that...
<voidspace> dooferlad: frobware: alexisb: need to sign out for a bit
<sinzui> frobware: you have access to every CI host you need to do you job.
<voidspace> alexisb: I'll probably miss our meeting tonight :-(
<alexisb> voidspace, take the time you need
<voidspace> just called for ambulance
<alexisb> not a problem
<dooferlad> voidspace: sure.
<alexisb> my thoughts are with you guys
<frobware> sinzui, so... what can I do on those machines? clone my juju repo, build, et al?
<sinzui> frobware: those machines are on canonical's network. they are very restricted. I scp files up and run them on the host.
<natefinch> good luck voidspace
<frobware> sinzui, and cross-compile from x86?
<sinzui> frobware: no cross-compile. the compiler on ppc64el is not the compiler you have on amd64. We do everythign native. debs are created on the ppc. in the case of the unit-tests. we make a release tarfile, untar it on the host and run the unit-tests. the host has go ready or it can be installed. I think we need to use stilson-07 now because 08 is dedicated to go1.5 testing
<frobware> sinzui, ok. on the h/w I'm using I was using gcc-go-4.9
<sinzui> go version
<sinzui> go version xgcc (Ubuntu 4.9.3-0ubuntu4) 4.9.3 linux/ppc64le
<voidspace> natefinch: thanks
<frobware> sinzui, I have:
<frobware> go version go1.4.2 gccgo (Ubuntu 5.2.1-22ubuntu2) 5.2.1 20151010 linux/ppc64le
<voidspace> frobware: alexisb: dooferlad: she's ok, she has these fits when she gets a high temperature (inherited from her mother unfortunately)
<frobware> voidspace, all resolved? hope so...
<voidspace> frobware: alexisb: dooferlad: but I have to go to hospital with her now (they always take her in after them)
<voidspace> frobware: she's fine, she won't stay overnight
<voidspace> but I have to go :-(
<natefinch> voidspace: go go!
<frobware> voidspace, sure
<alexisb> voidspace, I am glad it sounds like she is ok, take care
<frobware> sinzui, are the CI machines running wily?
<frobware> sinzui, for ppc64
<sinzui> frobware: trusty except for one wily that is not running any unit tests
<frobware> sinzui, ok, I suspect that explains the gcc go version difference.
<perrito666> Bbl lunch
<mup> Bug #1544662 opened: cannot bootstrap with mongodb3 and manual-provider <bootstrap> <manual-provider> <mongodb> <juju-core:Incomplete> <juju-core upgrade-mongodb3:Triaged> <https://launchpad.net/bugs/1544662>
<mup> Bug #1544662 changed: cannot bootstrap with mongodb3 and manual-provider <bootstrap> <manual-provider> <mongodb> <juju-core:Incomplete> <juju-core upgrade-mongodb3:Triaged> <https://launchpad.net/bugs/1544662>
<mup> Bug #1544662 opened: cannot bootstrap with mongodb3 and manual-provider <bootstrap> <manual-provider> <mongodb> <juju-core:Incomplete> <juju-core upgrade-mongodb3:Triaged> <https://launchpad.net/bugs/1544662>
<mup> Bug #1544662 changed: cannot bootstrap with mongodb3 and manual-provider <bootstrap> <manual-provider> <mongodb> <juju-core:Incomplete> <juju-core upgrade-mongodb3:Triaged> <https://launchpad.net/bugs/1544662>
<benji> goo/quit
<mup> Bug #1544662 opened: cannot bootstrap with mongodb3 and manual-provider <bootstrap> <manual-provider> <mongodb> <juju-core:Incomplete> <juju-core upgrade-mongodb3:Triaged> <https://launchpad.net/bugs/1544662>
<mup> Bug #1526063 changed: TestNoContextWithLock <ci> <intermittent-failure> <test-failure> <juju-core:Invalid> <juju-core maas-spaces:Fix Released> <https://launchpad.net/bugs/1526063>
<mup> Bug #1544694 opened: [maas-provider] Juju is incorrectly  configuring os bridge interfaces <juju-core:New> <MAAS:Invalid> <https://launchpad.net/bugs/1544694>
<natefinch> man, our pseudo transactions make separating the business logic from the persistence layer nearly impossible.
<natefinch> ericsnow: did you have ideas on how to increment the CharmModifiedVersion in the same transaction as SetResource?  I can do it the horrible hacky way, where resource persistence now has intimate knowledge of the service collection's info... not sure what my other options are, besides not having them in the same transaction, which seems very likely to cause bugs if something only half-succeeds.
<ericsnow> natefinch: gah, yet again mongo transactions are making us leak persistence info into state :(
<ericsnow> natefinch: I do have a plan
<natefinch> ericsnow: yeah, I hate that about our transactions....
<ericsnow> natefinch: consider adding a "NewServiceCharmModifiedOps()" method to resource/persistence.PersistenceBase
<ericsnow> natefinch: then the adapter in component/all/resource.go must provide that, exposing a similarly named helper in corestate
<ericsnow> natefinch: or just in state/resources.go, since that is the point of that file :)
<ericsnow> natefinch: (the point: avoid exporting more persistence concerns out of the state package)
<natefinch> ericsnow: ahh, yeah, ok.  I was trying to figure out how to get the left hand to talk to the right hand.  I was looking at state/resources.go and trying to figure out how to do it there.  Iget it.
<ericsnow> natefinch: cool
<ericsnow> natefinch: let me know if you get stuck on that or have any other questions
<katco> ericsnow: natefinch: merge of master into the feature-branch just succeeded. may want to rebase
<ericsnow> katco: nice!
<natefinch> katco: huzzah!
<natefinch> katco: thanks so much for taking that on.
<katco> natefinch: happy to so you guys can keep kickin arse :)
<ericsnow> natefinch, katco: +1
<katco> ericsnow: natefinch: cherylj: we should see if we can get a CI run through by tomorrow so we can merge INTO master
<cherylj> katco: well, we're trying to merge maas-spaces now, so there will be one less branch to compete with for CI runs :)
<katco> cherylj: :) is there any way to guarantee a run?
<cherylj> let me send you my paypal link
<cherylj> ;)
<natefinch> lol
<katco> cherylj: oh man if i had known this is how this works...
<cherylj> we were mostly focusing on master until we got the bless yesterday.
<cherylj> mongo3 was up next, then lxd-container-type, then I think your branch
<mup> Bug #1544694 changed: [maas-provider] Juju is incorrectly  configuring os bridge interfaces <juju-core:New> <MAAS:Invalid> <https://launchpad.net/bugs/1544694>
<natefinch> katco, cherylj, alexisb: team meeting?  Or should we skip it?
<katco> cherylj: sweet! is there somewhere i can view the queue?
<katco> natefinch: in another meeting atm, so i can't attend
<cherylj> MAAS SPACES HAS MERGED
<cherylj> I repeat
<cherylj> MAAS SPACES HAS MERGED!!!
<cherylj> alexisb, frobware ^^
<alexisb> :)
 * natefinch gets the feeling from the all caps, that this is a big deal.
<cherylj> YES IT IS
<cherylj> heh
 * lazyPower throws confetti
<lazyPower> natefinch i have to confetti if you have fanfare under control :D
<lazyPower> so/to/the/
<katco> cherylj: woo! grats to everyone
 * katco has a sinking feeling that she had better merge master again
<cherylj> katco: yes :)
 * katco cries into her coffee
<katco> 9 conflicts. here we go again.
<lazyPower> heyyyy cherylj
<lazyPower> does juju 2.0 alpha bidniss work with maas 1.8? or do i need to upgrade to 1.9?
<alexisb> lazyPower, you will need to upgrade to 1.9
<lazyPower> ah, well that explains the weird issue i'm seeing about series mismatches
 * lazyPower grabs a pick and returns to the maas saltmines
<natefinch> ericsnow: am I correct in assuming that a staged resource that is being activated will never be pending?
 * ericsnow thinks about it
<ericsnow> natefinch: pending resources should be staged as well, for exactly the same reason we stage non-pending resources
<ericsnow> natefinch: however, I think the staging code isn't doing it right (there's a slight race)
<ericsnow> natefinch: in resource/persistence/mongo.go, stagedID() should accommodate pending IDs
<ericsnow> natefinch: that isn't a problem now, but could be in the future
<katco> ericsnow: hey can you hop into moonstone?
 * frobware looks through the scrollback and HEADS TO THE BAR! :-D
 * frobware ponders... maas-spaces has landed. Gravitational waves breakthrough. Surely just a coincidence.
<mup> Bug #1544724 opened: repeatedly checks /dev/fd0 when it doesnt even exist <juju-core:New> <https://launchpad.net/bugs/1544724>
<perrito666> well, that was something from the past
<mup> Bug #1544724 changed: repeatedly checks /dev/fd0 when it doesnt even exist <juju-core:New> <https://launchpad.net/bugs/1544724>
<katco> frobware: you need to keep these jokes coming.
<mup> Bug #1544724 opened: repeatedly checks /dev/fd0 when it doesnt even exist <juju-core:New> <https://launchpad.net/bugs/1544724>
<natefinch> man, I am terrible at bash
<perrito666> natefinch: good that ensures you are not going around embedding bash in go
<natefinch> ericsnow: btw, I think there's a bug in how we load resource information... when you deploy a local charm, the resource info defaults to says it's a charmstore resource, which is not correct
<ericsnow> natefinch: yep
<natefinch> ahh man, the uniter tests are so slow.....
<natefinch> sigh... that feeling when I forget to filter out all the logging, so I can't even tell what failed...
<natefinch> OMG these tests are so bad
<thumper> fwereade: ping?
<tych0> sinzui: alexisb: ok. i think i've updated. i basically just merged master and cherry picked a bunch of old commits on top because git didn't figure it out. i'd prefer a rebase, but it's not obvious to me how to accomplish that with juju's feature branch setup. https://github.com/juju/juju/pull/4396 is the PR
<katco> ericsnow: can you please review natefinch-afk 's branch so we can possibly land that tonight before the ci run?
<ericsnow> katco: sure
<katco> ericsnow: ty... i'll try and weigh in if i can get this merge through, but feel free to give it a ship it w/o me
<alexisb> tycho, you can just merge the rebase into your feature branch
<alexisb> once it is merged we can just re-queue for CI
<katco> tych0: generally you don't need a review for merging master into your feature branch
<katco> tych0: rebases are nice, but rebasing a feature branch on top of master is a headache, so most people just merge master in
<tych0> ok. so nobody will be offended if i $$merge$$ myself?
<katco> tych0: nope, not if it's a feature branch
<tych0> ok.
<katco> tych0: and it's just a merge from master
<tych0> well, it's a merge from master + some fixups
<tych0> which are mostly just cherry-picks of previously reviewed commits because git sucks :)
<katco> tych0: were the fixups reviewed at one point?
<katco> tych0: yeah, you're fine :)
<tych0> katco: cool, thanks.
<katco> tych0: maybe do those in a separate pr next time, but not a huge deal
 * katco is currently merging from master as well
<tych0> well, i can't because the resulting merge won't build without them
<katco> ah i see
<menn0> thumper: "juju migrate" is here: http://reviews.vapour.ws/r/3839/
<katco> ericsnow: natefinch-afk: merge from master just landed
<ericsnow> katco: k, thanks!
<katco> ericsnow: natefinch-afk: we're also last in the queue to get a ci bless, so have a bit of time to land patches.
<tych0> looks like my merge failed, but i'm not entirely convinced the errors are mine: http://juju-ci.vapour.ws:8080/job/github-merge-juju/6362/console
<tych0> katco: cherylj: thoughts? ^
<cherylj> looking
<cherylj> ah, the dreaded bad record MAC
<cherylj> just retry the $$merge$$
<davecheney> cherylj: was there a successful CI run last night ?
<cherylj> davecheney: yes, we got a bless on master
<davecheney> i want to make sure the logging and rpc changes I have made so far are blessed before I backport them to 1.25
<davecheney> excellent, excellent, chrry-pick coming right up
<cherylj> tych0: yeah, looks like the bad record MAC was the only problem, just retry the $$merge$$
<davecheney> just the uusual mongodb is web scale problem
<davecheney> ignore it
<tych0> ok :)
<davecheney> oh my god
<davecheney> why is the apiserver code base like an episde of hoarders
<davecheney> it's got every line of code ever written in thre
<davecheney> nothing is every thrown away
<davecheney> even the apiserver has a client, even though there is another client in another package
<davecheney> this is like buying one of every color in the store so they don't feel lonely
#juju-dev 2016-02-12
<mup> Bug #1544796 opened: Backup restore fails: upgrade in progress <backup-restore> <blocker> <ci> <regression> <juju-core:Triaged> <https://launchpad.net/bugs/1544796>
<perrito666> sinzui: when did that start?
<sinzui> perrito666: in the past hour, and niether master or maas-spaces ever exhibted this
<perrito666> sinzui: tried another provider?
<sinzui> perrito666: I haven't yet
<perrito666> I believe juju declares "upgrading" while checking for upgrades, if machine is slow this could be the cause
<sinzui> perrito666: cherylj: think we lost commits in master!!  Our last success on master, earlyier today points to a commit I don't see in https://github.com/juju/juju/commits/master?page=1, but  http://reports.vapour.ws/releases/3595 does link the the last good version of master.
<sinzui> nm, fins failure
<davecheney> cherylj: https://bugs.launchpad.net/juju-core/+bug/1544796 is another manifestation of the issue that you and thumper were talking about yesterday
<mup> Bug #1544796: Backup restore fails: upgrade in progress <backup-restore> <blocker> <ci> <regression> <juju-core:Triaged> <https://launchpad.net/bugs/1544796>
<davecheney> almost certainly the same underlying cause as https://bugs.launchpad.net/juju-core/+bug/1543362
<mup> Bug #1543362: juju debug-log returns error if run too early in bootstrap <juju-core:Triaged> <https://launchpad.net/bugs/1543362>
<perrito666> sinzui: eod, if there is anything urgent mail me
<sinzui> perrito666: have a good evening
<menn0> thumper: I'ved replied to your comments for http://reviews.vapour.ws/r/3839/. Can you PTAL?
<thumper> just done
<menn0> thumper: thanks
<menn0> thumper: another look at http://reviews.vapour.ws/r/3839/ please
<thumper> looking
<davecheney> juju bootstrap -> https://likelockedrooms.files.wordpress.com/2013/03/mad-as-hell.jpg
<thumper> :)
<thumper> davecheney: take a deep breath, and think to yourself "it is Friday..."
<natefinch> ug, I think my displayport cable died... using HDMI->DVI instead, but it can't push the native res, so everything's fuzzy.  and of course it's my center monitor, so I can't just stop using it.  Feh.
<axw> anastasiamac: would you be so kind to review http://reviews.vapour.ws/r/3841/ for me?
<anastasiamac> axw: of course!
<anastasiamac> axw: anything to have a break from fighting import cycle :D
<anastasiamac> axw: LGTM
<axw> anastasiamac: thanks
<axw> anastasiamac: that range-over-map thing is only ok if there's one element in the map
<anastasiamac> oh :(
<axw> anastasiamac: the order is is non-deterministic
<anastasiamac> but i can have a break in there \o/
<axw> anastasiamac: (unless there's only one element, obviously)
<axw> anastasiamac: sure, just as long as you don't expect a particular order to the range
<anastasiamac> axw: awesome \o/
<davecheney> thumper: it takes 33 minutes to bootstrap
<davecheney> i'm using the sydney ec2 datacenter
<thumper> wow
<thumper> that is slow
<axw> unusually slow, I use ap-southeast-2, never that slow
<davecheney> it sits there for minutes at a time squeezing data up to the client
<davecheney> s/client/bootstrap
<davecheney> lucky(~) % ls -lah $(!!)
<davecheney> ls -lah $(which jujud)
<davecheney> -rwxrwxr-x 1 dfc dfc 82M Feb 12 13:43 /home/dfc/bin/jujud
<davecheney> this probably isn't helping
<axw> I've got a PR up for the ssh thing, might help?
<davecheney> https://www.youtube.com/watch?v=q_qgVn-Op7Q
<davecheney> https://www.youtube.com/watch?v=q_qgVn-Op7Q
<davecheney> danit
<davecheney> https://youtu.be/q_qgVn-Op7Q?t=1m9s
<davecheney> oh, this time it was WAY faster
<thumper> heh
<thumper> watched that mad has hell thing
<davecheney> that was 1976, the same year I was born
<davecheney> can you tell me it couldn't apply to today ?
<thumper> heh
<thumper> ok... time to go
<thumper> laters
<thumper> have a good weekend folks
<axw> anastasiamac: another small one please: http://reviews.vapour.ws/r/3843/
<mup> Bug #1544838 opened: suite.TestPprofStartWithExistingSocketFile unit test failure <ci> <test-failure> <unit-tests> <juju-core:New> <https://launchpad.net/bugs/1544838>
<mup> Bug #1544838 changed: suite.TestPprofStartWithExistingSocketFile unit test failure <ci> <test-failure> <unit-tests> <juju-core:New> <https://launchpad.net/bugs/1544838>
<mup> Bug #1544838 opened: suite.TestPprofStartWithExistingSocketFile unit test failure <ci> <test-failure> <unit-tests> <juju-core:New> <https://launchpad.net/bugs/1544838>
<anastasiamac> axw: looking now
<mup> Bug #1544846 opened: restore fails with could not exit restoring status <nil> <backup-restore> <ci> <test-failure> <juju-core:New> <https://launchpad.net/bugs/1544846>
<mup> Bug #1544846 changed: restore fails with could not exit restoring status <nil> <backup-restore> <ci> <test-failure> <juju-core:New> <https://launchpad.net/bugs/1544846>
<mup> Bug #1544846 opened: restore fails with could not exit restoring status <nil> <backup-restore> <ci> <test-failure> <juju-core:New> <https://launchpad.net/bugs/1544846>
<mup> Bug #1544853 opened: unit-test failure MachineSuite.TestManageModelRunsInstancePoller <ci> <intermittent-failure> <test-failure> <unit-tests> <juju-core:New> <https://launchpad.net/bugs/1544853>
<mup> Bug #1544855 opened: unit-test failure ClientOperationSuite.TestCannotExpireUnheldLease <ci> <intermittent-failure> <test-failure> <unit-tests> <juju-core:New> <https://launchpad.net/bugs/1544855>
<mup> Bug #1544890 opened: "ERROR the name of the model must be specified" when 'juju init' required <juju-core:New> <https://launchpad.net/bugs/1544890>
<frobware> voidspace, dooferlad: might miss standup/planning. helping out with customer issue and otp atm
<voidspace> frobware: ok
<voidspace> dooferlad: my parents are paying a surprise visit (driving past on their way up north)
<voidspace> dooferlad: so we can have a short standup
<dooferlad> voidspace: am in the hangout now
<voidspace> cherylj: ping
<voidspace> dooferlad: gah, gomaasapi test server *does* support spaces endpoint
<voidspace> dooferlad: so long as you've registered some spaces...
<voidspace> dooferlad: if there aren't any spaces registered it pretends not to support it to mimic older versions of maas
<voidspace> dooferlad: and my tests don't register any spaces
<voidspace> dooferlad: well, the preexisting tests don't - because they didn't need to
<voidspace> ah well, less work
<voidspace> dooferlad: cherylj merged maas-spaces yesterday by the way
<frobware> dooferlad, ping
<voidspace> dooferlad: hmm... not convinced there is a way to populate spaces now, may still need to implement it
<dooferlad> frobware: hi
<frobware> dooferlad, see email. sorry! :)
<voidspace> dooferlad: looks like the spaces stuff is untested and there's no way to add a space! Probably because you started implementing it and then we decided we didn't need that endpoint after all
<dooferlad> voidspace: sounds about right
<voidspace> We were doing everything space related through the subnets endpoints
<voidspace> Ah well, so I need to add a new test server method for adding spaces and some tests.
<dooferlad> voidspace: I hope it is at least clear code and won't take long to do.
<cherylj> voidspace: pong
<voidspace> cherylj: I wanted to ask about maas-spaces
<voidspace> cherylj: but I see you merged it last night
<voidspace> cherylj: \o/
<cherylj> ah, yes :)
<voidspace> thanks
<dooferlad> frobware: bug #1543770 is a bit light on details. Doesn't help that the network tests are spitting out 'The old local provider is not supported by 2.0-alpha2' and saying they passed!
<mup> Bug #1543770: Juju 2.0alpha1 does not assign a proper netmask for LXC containers <cpe-critsit> <cpe-sa> <dhcp> <lxc> <maas> <network> <juju-core:Triaged> <https://launchpad.net/bugs/1543770>
<frobware> dooferlad, you read what I read. :)
<frobware> dooferlad, this is in alpah1 - not sure whether we should say use beta1.
<frobware> dooferlad, but /32 seems the right netmask to me
<dooferlad> frobware: Yea, it is fine.
<frobware> dooferlad, otp
<dooferlad> frobware: sure.
<cherylj> frobware, dooferlad, if it's not clear what the issue is in the bug, definitely press for more details
<frobware> voidspace, http://pastebin.ubuntu.com/15024080/
<voidspace> frobware: thanks
<dooferlad> frobware, cherylj: Just so you know, I would expect container networking to work in the beta if it was this build: http://reports.vapour.ws/releases/3595/job/functional-container-networking/attempt/170
<dooferlad> i.e. the maas-spaces branch being merged in
<axw> wallyworld
<axw> oops
 * voidspace lunches
<cherylj> dooferlad: so, it's expected that it doesn't work in alpha1?
<cherylj> brb
<frobware> cherylj, not sure about that. I'm sure I tried alpha1 this morning and it was OK. but I got sidetracked with the other issue...
<dooferlad> cherylj: http://reports.vapour.ws/releases/3525 didn't run the container networking tests, so I don't know if it would have worked or not.
<cherylj> ok, thanks
<katco> cherylj: sinzui: what do i need to do to bootstrap a beta1 controller? i'm setting the agent-metadata-url to "https://streams.canonical.com/juju/tools" and agent-stream to "devel". no bueno
<sinzui> katco: beta1 is not released. use --upload-tools or publish your own streams
<katco> k ty
<mup> Bug #1544847 opened: unit-test failure: configSuite.TestNewModelConfig test failure <ci> <regression> <test-failure> <unit-tests> <juju-core:Incomplete> <juju-core lxd-container-type:Triaged> <https://launchpad.net/bugs/1544847>
<mup> Bug #1544849 opened: unit-test loop with juju.worker.uniter.remotestate retry hook timer triggered <ci> <intermittent-failure> <ppc64el> <unit-tests> <juju-core:Incomplete> <juju-core maas-spaces:Triaged> <https://launchpad.net/bugs/1544849>
<mup> Bug #1544850 opened: unit-test failure: cloudImageMetadataSuite.TestFindMetadata <ci> <intermittent-failure> <test-failure> <unit-tests> <juju-core:Incomplete> <juju-core upgrade-mongodb3:Triaged> <https://launchpad.net/bugs/1544850>
<mup> Bug #1544847 changed: unit-test failure: configSuite.TestNewModelConfig test failure <ci> <regression> <test-failure> <unit-tests> <juju-core:Incomplete> <juju-core lxd-container-type:Triaged> <https://launchpad.net/bugs/1544847>
<mup> Bug #1544849 changed: unit-test loop with juju.worker.uniter.remotestate retry hook timer triggered <ci> <intermittent-failure> <ppc64el> <unit-tests> <juju-core:Incomplete> <juju-core maas-spaces:Triaged> <https://launchpad.net/bugs/1544849>
<mup> Bug #1544850 changed: unit-test failure: cloudImageMetadataSuite.TestFindMetadata <ci> <intermittent-failure> <test-failure> <unit-tests> <juju-core:Incomplete> <juju-core upgrade-mongodb3:Triaged> <https://launchpad.net/bugs/1544850>
<mup> Bug #1544847 opened: unit-test failure: configSuite.TestNewModelConfig test failure <ci> <regression> <test-failure> <unit-tests> <juju-core:Incomplete> <juju-core lxd-container-type:Triaged> <https://launchpad.net/bugs/1544847>
<mup> Bug #1544849 opened: unit-test loop with juju.worker.uniter.remotestate retry hook timer triggered <ci> <intermittent-failure> <ppc64el> <unit-tests> <juju-core:Incomplete> <juju-core maas-spaces:Triaged> <https://launchpad.net/bugs/1544849>
<mup> Bug #1544850 opened: unit-test failure: cloudImageMetadataSuite.TestFindMetadata <ci> <intermittent-failure> <test-failure> <unit-tests> <juju-core:Incomplete> <juju-core upgrade-mongodb3:Triaged> <https://launchpad.net/bugs/1544850>
<mup> Bug #1545040 opened: TestLoginsDuringUpgrade fails on go1.5/6 <ci> <gccgo> <go1.5> <test-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1545040>
<mup> Bug #1545045 opened: TestNotAllContainersAreDeleted: can't get info for image <ci> <lxd> <regression> <juju-core:Incomplete> <juju-core lxd-container-type:Triaged> <https://launchpad.net/bugs/1545045>
<mup> Bug #1545046 opened: TestNewContainerManage executed but not supported by gccgo-go <ci> <gccgo> <ppc64el> <regression> <test-failure> <juju-core:Incomplete> <juju-core lxd-container-type:Triaged> <https://launchpad.net/bugs/1545046>
<mup> Bug #1545040 changed: TestLoginsDuringUpgrade fails on go1.5/6 <ci> <gccgo> <go1.5> <test-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1545040>
<mup> Bug #1545045 changed: TestNotAllContainersAreDeleted: can't get info for image <ci> <lxd> <regression> <juju-core:Incomplete> <juju-core lxd-container-type:Triaged> <https://launchpad.net/bugs/1545045>
<mup> Bug #1545046 changed: TestNewContainerManage executed but not supported by gccgo-go <ci> <gccgo> <ppc64el> <regression> <test-failure> <juju-core:Incomplete> <juju-core lxd-container-type:Triaged> <https://launchpad.net/bugs/1545046>
<mup> Bug #1545040 opened: TestLoginsDuringUpgrade fails on go1.5/6 <ci> <gccgo> <go1.5> <test-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1545040>
<mup> Bug #1545045 opened: TestNotAllContainersAreDeleted: can't get info for image <ci> <lxd> <regression> <juju-core:Incomplete> <juju-core lxd-container-type:Triaged> <https://launchpad.net/bugs/1545045>
<mup> Bug #1545046 opened: TestNewContainerManage executed but not supported by gccgo-go <ci> <gccgo> <ppc64el> <regression> <test-failure> <juju-core:Incomplete> <juju-core lxd-container-type:Triaged> <https://launchpad.net/bugs/1545046>
<mup> Bug #1545050 opened: TestSubordinateDying is not dying <ci> <intermittent-failure> <ppc64el> <juju-core:Triaged> <https://launchpad.net/bugs/1545050>
<mup> Bug #1545055 opened: TestManageModelRunsUndertaker timed out <ci> <intermittent-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1545055>
<mup> Bug #1545057 opened: TestWorkerDiscoversSpaces no subnets found <ci> <go1.5> <intermittent-failure> <race-condition> <juju-core:Triaged> <https://launchpad.net/bugs/1545057>
<cherylj> hey tych0!  Looks like we got on run on your branch and the results are in!  The bugs opened are here: https://bugs.launchpad.net/juju-core/lxd-container-type
<natefinch> katco, ericsnow: tests added, tweaks made, rebase successful with minimal problems... code is merging
<katco> natefinch: rock!
<ericsnow> natefinch: great!
<katco> natefinch: we're still in moonstone
<natefinch> katco: ok, coming
<dooferlad> frobware, voidspace: calling it a day. It has been a long week and thinking straight has become an issue!
<frobware> dooferlad, did you come to any conclusion on the netmask bug?
<dooferlad> frobware: only that I need more information.
<frobware> dooferlad, did you ask in the bug?
<dooferlad> frobware: yes
<frobware> dooferlad, ah...sorry I see it now.
<voidspace> natefinch: question - if I want to test a synchronous function that may deadlock (block) what's the right way to test it without blocking the test
<voidspace> natefinch: just fire it off on a goroutine with a signal method and wait for a LongAttempt for the signal?
<voidspace> ShortAttempt would do actually
<voidspace> given that my current synchronous test - without the fix in place - hasn't returned after about five minutes
<voidspace> I think I can safely say I've found the deadlock...
<natefinch> voidspace: leaving dead goroutines hanging around in your tests is bad, but I guess as long as that's the failure condition, I guess that's ok
<voidspace> natefinch: yeah, it shouldn't fail!
<natefinch> voidspace: yeah, a simple goroutine that sends on a channel when it's finished and then you can do a select on that channel and time.After(shortwait)
<katco> sinzui: cherylj: hey, i aborted a merge job w/o thinking... will that leave cruft around?
<sinzui> katco: thanks for pinging me I will check for an instance
<katco> sinzui: sorry =|
<sinzui> katco: I have done the same
<katco> sinzui: can natefinch do another $$merge$$ in the meantime?
<voidspace> nope, no way to test without a failing deadlock - the call that actually deadlocks does asserts so can't be on a different goroutine
<voidspace> dammit
<voidspace> at least a deadlocking test will tell us something is wrong
<voidspace> hmmm... we shouldn't be deadlocked, it should timeout after LongAttempt
<voidspace> weird
<voidspace> dammit, the test is nonsense
<voidspace> but it shouldn't pass
<voidspace> and it does
<cherylj> katco: are there any other commits coming for your resources branch?
<katco> cherylj: we're just tryinf to land the 1 more now
<katco> cherylj: but we received a time-out and that's when i aborted the job
<katco> cherylj: trying to re-$$merge$$ but natefinch says the bot isn't picking it up yet
<sinzui> perrito666: Your upgrade-mongo3 branch needs the latest master for CI to test. There is no rush. CI will be starting a test of the cloud-credentials branch first
<frobware> interesting! - https://medium.com/vijay-pandurangan/linux-kernel-bug-delivers-corrupt-tcp-ip-data-to-mesos-kubernetes-docker-containers-4986f88f7a19#.ojo3f9ww3
<natefinch> sinzui: can you help my branch? I think katco aborting the merge meant that it won't pick up me re-$$merge$$ing it
<natefinch> sinzui: https://github.com/juju/juju/pull/4374
<sinzui> natefinch: oh. I will attempt a delete of the aborted job
<sinzui> natefinch: I will check back in 5 minutes to see if it is accepted
<sinzui> katco: natefinch: the only reason feature-resouces didn't get a bless from CI is that it has a regression from master.
<sinzui> natefinch: I have a cunning plan to hand type the aborted build into jenkins to run the tests and hopefully convice the lander to send to the results back to the PR.
<voidspace> frobware: http://reviews.vapour.ws/r/3848/
<katco> sinzui: nice! we still need to run ci 1 more time with the branch natefinch is trying to land
<katco> sinzui: tbh i'd be fine merging w/o a bless because it's just a new command-flag
<frobware> voidspace, otp
<voidspace> frobware: ok
<frobware> voidspace, so the first part of that diff is what we were trying yesterday?
<voidspace> frobware: yes, I got bogged down trying to construct a test
<voidspace> frobware: in the end I concluded it was already tested and the existing tests pass
<katco> cherylj: ok, the feature-resources branch is ready for another ci run
<katco> cherylj: or if you're ok with it, we can just merge into master. only patch not tested is a new command flag
 * cherylj looks
<sinzui> katco: natefinch: the aborted merge is now merged. It is okay to abort, but if we do want to merge, we can use the rebuild link on the aborted job to try again.
<katco> sinzui: tyvm
<katco> cherylj: here's the diff to help you make the call: https://github.com/juju/juju/commit/f0e1848aca595b35d6483f75a909c38b204eee5a
<cherylj> sinzui: did you want to prepare the PR to merge their branch?
<katco> cherylj: sinzui: i can do it if you like; it's just a few clicks
<sinzui> cherylj: I will do it and explain the two faiures are from the master.
<katco> sinzui: cherylj: great, cheers to both of you :)
<cherylj> katco: thanks to you and your team for pulling off this amazing feat!
<cherylj> katco: now can someone look at the restore failures being seen on master?  :)
<katco> cherylj: surely you jest! ;)
<katco> cherylj: this doesn't mean the feature is done lol
<cherylj> heh, well I can hope right?  I mean, we do need it fixed to ship beta1
<perrito666> sinzui: ok, ill merge it
<sinzui> cherylj: http://reviews.vapour.ws/r/3849/
<cherylj> shipit!
<lazyPower> cherylj - question for you regarding https://bugs.launchpad.net/juju-core/+bug/1535165 - is this fix present in 2.0-alpha1?
<mup> Bug #1535165: Unable to create hosted models with MAAS provider <juju-release-support> <maas-provider> <juju-core:Fix Released by waigani> <https://launchpad.net/bugs/1535165>
<cherylj> lazyPower: no, just alpha2
<lazyPower> its tagged alpha2 - but i've got fingers crossed
<lazyPower> wah wahhhh
<lazyPower> ok :D thanks for confirmation
<cherylj> sorry :(
<cherylj> np :)
<lazyPower> not even upset :D i'll be patient
<lazyPower> or i'll build a container w/ nightly
<lazyPower> either way
<rick_h__> lazyPower: alpha2 is out though?
<rick_h__> lazyPower: /me is missing the wah wahhhhh
<lazyPower> rick_h__ - wait it is?
 * lazyPower pulls latest charmbox:devel
<rick_h__> lazyPower: https://launchpad.net/~juju/+archive/ubuntu/devel
<lazyPower> woo hot diggity dog, i'm behind the times
<rick_h__> lazyPower: turn that frown upside down
<rick_h__> and run along the razor's edge
<katco> ericsnow: natefinch: babam https://github.com/juju/juju/pull/4408
<katco> .
<ericsnow> katco: sweet!
<lazyPower> katco great success!
<lazyPower> devops borat approves of this PR
<katco> lol
<natefinch> dayum
<natefinch> nice
<rick_h__> katco: natefinch ericsnow <3
<rick_h__> katco: natefinch ericsnow looking forward to demo time
<lazyPower> rick_h__ you beautiful man you - that release snuck by me, and was available in the latest devel image. man i love automation
<katco> rick_h__: demo/status update to follow
<katco> ericsnow: natefinch: i'm just in moonstone w/e you're ready
<lazyPower> katco can i be a fly on the wall?
<katco> lazyPower: for?
<lazyPower> demo / status
<katco> lazyPower: you want to watch the demo you mean?
<lazyPower> yes :D
<katco> lazyPower: sure i'll ping you when we're recording
<lazyPower> huzzahhhh
<mup> Bug #1545116 opened: When I run "juju resources <service>" after a service is destroyed, resources are still listed. <resources> <juju-core:Confirmed> <https://launchpad.net/bugs/1545116>
<mup> Bug #1545126 opened: juju/maas do not create ptr reccords for bare metal servers with multiple networks <juju-core:New> <https://launchpad.net/bugs/1545126>
<mup> Bug #1545126 changed: juju/maas do not create ptr reccords for bare metal servers with multiple networks <juju-core:New> <https://launchpad.net/bugs/1545126>
<mup> Bug #1545126 opened: juju/maas do not create ptr reccords for bare metal servers with multiple networks <juju-core:New> <https://launchpad.net/bugs/1545126>
<lazyPower> omg relations in tabular status? you really DO love us! <3
<perrito666> lazyPower: :)
<lazyPower> perrito666 best valentines day gift ever
<perrito666> lazyPower: I am romantic like that
<katco> for anyone who's interested, going to be demoing resources here in a bit: http://youtu.be/SS3AQO3ZN9Y
<TheMue>  did I miss something?
<marcoceppi> ericsnow:  list-resources --details is awesome
<marcoceppi> I like that you all took into consideration resource delivery mismatch
<ericsnow> marcoceppi: glad you noticed :)
<marcoceppi> ericsnow: is there a resource-updated hook?
<ericsnow> marcoceppi: definitely something we could have easily missed
<ericsnow> marcoceppi: nope
<marcoceppi> so we have to use update-status to check if a new resources is available?
<ericsnow> marcoceppi: we're using upgrade-charm
<marcoceppi> oh, okay
<ericsnow> marcoceppi: (the hoook)
<marcoceppi> so an upload-resource call will invoke an upgrade-charm event?
<ericsnow> marcoceppi: yeah, both "juju push-resource" and "juju upgrade-charm"
<marcoceppi> interesting. is there a way to tell what verion of a resource I have in a charm without running resource-get?
<rick_h__> marcoceppi: e.g. if you publish a new combo of charm revision, resource revision, etc in the charmstore. Upgrade charm will get triggered for all of them since they're published as one working set
<marcoceppi> I guess upgrade-charm would basically just trigger an "upgrade"
<ericsnow> marcoceppi: juju charm list-resources <charm>
<marcoceppi> ericsnow: from within the charm
<ericsnow> marcoceppi: not really
<ericsnow> marcoceppi: you either have the one of the controller or you don't (and resource-get fixes that)
<rick_h__> ericsnow: it is interseting in that I don't want to rerun the code that comes after a resource-get if that resource hasn't been updated
<ericsnow> marcoceppi: there is no concept of multiple revisions of the same resource (for a given service) on the controller
<rick_h__> ericsnow: we'll have to think of how to tell resource-get it's not changed ?
<ericsnow> marcoceppi: it's binary
<marcoceppi> ericsnow: well, there is implicitly, if a unit needs to know that it needs to do somethign because it has a new resource
<ericsnow> rick_h__: good point
<ericsnow> rick_h__: I suppose you could compare checksums
<marcoceppi> something like resource-list inside a hook
<marcoceppi> or resource-get --checksum
<rick_h__> marcoceppi: I think as it stands it reruns and expects the charms to be idempotent, but you're right we should enable an effeciency bump there
<ericsnow> rick_h__: but having juju do that for the charm may be good
<rick_h__> ericsnow: right, the charm author may want to rerun, we should enable them to handle it how they wish
<marcoceppi> that way a charm could just track the checksum it's got
<rick_h__> yep
<rick_h__> ericsnow: can you take that feedback back to the team please?
<ericsnow> rick_h__: will do
<rick_h__> ty and ty for the feedback marcoceppi, good stuff
<ericsnow> rick_h__, marcoceppi: +100
<marcoceppi> love it so far, compiling from master now to update a few charms
<perrito666> weeee I did it, I didi it, I finally removed the status duplication :D
<perrito666> just took me 3 days :p
 * perrito666 dances
<marcoceppi> hey party people
<marcoceppi> anyone around to answer a quick question about the new juju deploy in 2.0?>
<marcoceppi> I guess it is pretty late
<perrito666> what is juju romulus??
<rick_h__> marcoceppi: maybe?
<mup> Bug #1545196 opened: Juju claims AWS ap-northeast-2 not found <ec2-provider> <juju-core:Incomplete> <juju-core cloud-credentials:Triaged> <https://launchpad.net/bugs/1545196>
<mup> Bug #1545196 changed: Juju claims AWS ap-northeast-2 not found <ec2-provider> <juju-core:Incomplete> <juju-core cloud-credentials:Triaged> <https://launchpad.net/bugs/1545196>
<mup> Bug #1545196 opened: Juju claims AWS ap-northeast-2 not found <ec2-provider> <juju-core:Incomplete> <juju-core cloud-credentials:Triaged> <https://launchpad.net/bugs/1545196>
#juju-dev 2016-02-13
<mup> Bug #1545207 opened: Rackspace os-security-groups not found <bootstrap> <ci> <rackspace> <regression> <juju-core:New> <juju-core cloud-credentials:Triaged> <https://launchpad.net/bugs/1545207>
<mup> Bug #1545207 changed: Rackspace os-security-groups not found <bootstrap> <ci> <rackspace> <regression> <juju-core:New> <juju-core cloud-credentials:Triaged> <https://launchpad.net/bugs/1545207>
<mup> Bug #1545207 opened: Rackspace os-security-groups not found <bootstrap> <ci> <rackspace> <regression> <juju-core:New> <juju-core cloud-credentials:Triaged> <https://launchpad.net/bugs/1545207>
<marcoceppi> rick_h__: in 2.0 - when I juju deploy local - how will that work when $JUJU_REPOSITORY is set?
<rick_h__> marcoceppi: hmm...not sure. Right now I don't know if that's used at all tbh. Will have to file a bug/check the code
<marcoceppi> rick_h__: what's used? JUJU_REPOSITORY?
<rick_h__> marcoceppi: yea
<rick_h__> marcoceppi: you mean to tell it where to find a local charm right?
<marcoceppi> rick_h__: well, 2.0-alpha2 and 1.X use it to find $JUJU_REPOSITORY/trusty/<charm>
<marcoceppi> but with series in metadata will it just be $JUJU_REPOSITORY/<charm>
<marcoceppi> we'll need to know in order to make decisions on how charm build works in 2.0
<mup> Bug #1545216 opened: upgrade-mongo panic: juju home hasn't been initialized <ci> <mongodb> <test-failure> <upgrade-mongo> <juju-core:New> <juju-core upgrade-mongodb3:Triaged> <https://launchpad.net/bugs/1545216>
#juju-dev 2016-02-14
<cherylj> why is restore so broken?
 * cherylj sighs
<anastasiamac> cherylj: coz it's meant to be weekend?..
<anastasiamac> and public holidays on monday in US...
<cherylj> I see what's causing the failure in CI, and it's an easy fix
<cherylj> but it turns out that restore hasn't been working as the code thinks it should
<thumper> morning folks
<rick_h__> howdy thumper
<thumper> o/ rick_h__
<rick_h__> thumper: got a sec?
<thumper> yeah... call?
<rick_h__> thumper: yea, real fast https://plus.google.com/hangouts/_/canonical.com/rick?authuser=1
<axw> wallyworld: apparently I never sent a PR for this, thought I did the other day: http://reviews.vapour.ws/r/3855/
<axw> some time after standup...
<wallyworld> sure
<rick_h__> wallyworld: axw I'm trying to create a model on rax for a demo in alpha2 and getting "ERROR provider validation failed: got default value for unknown field "control-bucket""
<rick_h__> but I've got no defined field there in the config yaml for the control-bucket?
<wallyworld> rick_h__: when you say config.yaml, you mean environments.yaml?
<rick_h__> wallyworld: well both. when running create-model I pass the --config= for the creds/etc
<rick_h__> wallyworld: and control-bucket appears in neither file
<wallyworld> and the controller was bootstrapped without a control-bucket also?
<rick_h__> yes
<wallyworld> does juju get-env have control bucket?
<rick_h__> ERROR unrecognized command: juju get-env
<wallyworld> oh, doh, that's the old cli, sorry, i can't remember wht the new one is
<wallyworld> i'll check
<rick_h__> no tab complete for my zsh :(
<wallyworld> get-config
<rick_h__> that's for a service though?
<wallyworld> get-model-config
<rick_h__> yea, got it, looking
<rick_h__> no control bucket there
<rick_h__> "set-numa-control-policy" is only hit for for control in thats
<wallyworld> hmmm
<wallyworld> let me check the code
<rick_h__> wallyworld: k, let me know if I should file a bug
#juju-dev 2017-02-06
<anastasiamac> wallyworld: btw, plz tag with "eda" whichever bug u decide is primary for "application in error, can't destroy model" to allow QA the ooportunity to add functional test for this scenario
<anastasiamac> opportunity even :D
<anastasiamac> wallyworld: also in addition to bug # 1654928, there is possibly related bug # 1661930
<anastasiamac> wallyworld: patience is not on this monday :) I have updated the bugs as per ^^
<axw> wallyworld: can you please review https://github.com/juju/juju/pull/6924
<axw> wallyworld: ping? did you see my message?
<wallyworld> axw: sorry, missed it, i had my sound turned down so missed the ping
<wallyworld> wtf, i already reviewed that pr and hit approve
<wallyworld> must have timed out, it does that when i bootstrap on aws and it floods by connection uploading agents
<axw> wallyworld: thanks
<wallyworld> anastasiamac: bug 1465317 isn't critical, the 2.1 binary works fine with current windows/macos and we will have released 2.2 before win 11 or macos 10.13 are close to being released. it's a fairly large fix so should be targetted at 2.2
<mup> Bug #1465317: ubutu devel macos win: panic: osVersion reported an error: Could not determine series <osx> <packaging> <wily> <windows> <juju:Triaged> <juju-core:Won't
<mup> Fix> <juju-core 1.24:Won't Fix> <juju-core 1.25:Won't Fix> <juju-release-tools:Fix Released by sinzui> <https://launchpad.net/bugs/1465317>
<anastasiamac> wallyworld: sure. plz adjust
 * wallyworld wishes bug reporters would assign bugs to the correct series
<anastasiamac> wallyworld: if u r looking for bugs to do, this one is awesome - bug 1654116
<mup> Bug #1654116: Attempts to write leadership settings when not the leader during relation-changed hooks <cdo-qa-blocker> <landscape> <uosci> <Autopilot Log Analyser:Fix Committed> <Charm Helpers:Invalid> <juju:Triaged by menno.smits> <Landscape Server:Confirmed for fginther> <juju (Ubuntu):Invalid>
<mup> <ceilometer (Juju Charms Collection):Invalid> <rabbitmq-server (Juju Charms Collection):Invalid> <https://launchpad.net/bugs/1654116>
<wallyworld> tis ok, i've found one
<anastasiamac> wallyworld: did u test ur fix in https://github.com/juju/juju/pull/6906 for bug 1643430 with subordinate in error?
<mup> Bug #1643430: Unassigned units in an error state cannot be removed <juju:Fix Committed by wallyworld> <juju 2.1:Fix Committed by wallyworld> <https://launchpad.net/bugs/1643430>
<anastasiamac> wallyworld: bug 1662018 seems to be in the same area
<mup> Bug #1662018: Cannot remove a deployed subordinate charm in a failed hook status <juju:Incomplete> <https://launchpad.net/bugs/1662018>
<mup> Bug #1661576 changed: show-status-log formatting contains unwanted pad lines <usability> <juju:Triaged> <juju 2.0:Won't Fix> <https://launchpad.net/bugs/1661576>
<mup> Bug #1661624 changed: show-status-log bogus timeline <usability> <juju:Triaged by hduran-8> <juju 2.0:Won't Fix> <https://launchpad.net/bugs/1661624>
<wallyworld> anastasiamac: i didn't test with subordiante, fix should be same
<anastasiamac> wallyworld: plz either comment on the bug with ur assertive conclusion or add a test \o/ thnx!
<rogpeppe> anastasiamac: hiya
<rogpeppe> here's a backport of the api dial spurious message fix to juju 2.1: https://github.com/juju/juju/pull/6926
<rogpeppe> reviews appreciated
<perrito666> morning
<perrito666> jam: tx for the review on the ipv6 fix
<perrito666> jam: does cheking on the glibc part of the error seems like enough to you?
<jam> perrito666: "protocol not supported" ?
<perrito666> "socket: address family not supported by protocol"
 * perrito666 is working at a bar and thinks people look weird at him because he is not using a mac
<jam> perrito666: I'd be much happier if we had a ENOADDRSUPPORT with an official value rather than a random string that someone is going to think could be  better worded differently
<jam> perrito666: but I can't think of anything better vs that
<perrito666> jam: I dont think lxd library is going ot grace us with said code :p
<perrito666> jam: also I would appreciate your input on how you think this should be tested other than actually invoking lxd (which seems like the wrong thing to do on a test)
<jam> perrito666: can we mock out the thing we are calling SetServerConfig and have it return a custom error?
<perrito666> jam: mot likely, but that woul not test what you want to test which is the fact that the string is still valid
<anastasiamac> rogpeppe: hi \o/ m neck-deep in bootstrap failures but there is light \o/ m OCR tomorrow (it'll start here in couple of hrs), if noone else gets to it, I'll look then :D
<anastasiamac> rogpeppe: i'll review in about 10hrs? :)
<rogpeppe> anastasiamac: np - jam already hit $$merge$$ on it...
<anastasiamac> rogpeppe: jam is awesome \o/
<jam> rogpeppe: IIRC I approved it for 2.2, happy to rubber stamp it for 2.1
<rogpeppe> jam: you added a $$merge$$ comment to https://github.com/juju/juju/pull/6926 which targets 2.1
<rogpeppe> jam: and it's now merged
<jam> rogpeppe: I mean I approved the work when you targetted develop a week or two ago
<rogpeppe> jam: i see a comment from an hour ago
<jam> rogpeppe: and thus I approved the one you proposed today
<rogpeppe> jam: ah, ok great, i thought perhaps you hadn't realised what you were doing
<jam> well, I generally don't :). but this time I did'
<rogpeppe> jam: i'd read the future tense into "happy to rubber stamp it for 2.1" but it was actually the past tense :)
<rogpeppe> jam: :)
<jam> I left off the "was" and "is" is a perfectly acceptable word to put in ther.
<anastasiamac> rogpeppe: we tend to only approve one copy. thus back-ports and forward-ports r good to self-approve unless there r vast differences with original :D
<rogpeppe> anastasiamac: ah, ok. i thought it's worth getting approval that it's worth backporting though.
<perrito666> jam:  ptal https://github.com/juju/juju/pull/6916 ill add a pr to  2.1 too once this one is lgtmed
<hoenir> Hi, I'm tring to direct the juju client to insepct the index2.json but I'm keep getting this error in bootstrap invalid URL "file:///var/www/html/toolsdir/tools/streams/v1/index.sjson" not found
<hoenir> in v1 i have just 2 json filex inde2.json and com.ubuntu.juju-devel-tools.json
<hoenir> also I'm runing juju with like this
<hoenir> https://paste.ubuntu.com/23940708/
<hoenir> any thoughts?
<perrito666> abentley: could you shed some light on hoenir's problem?  I am not sure what --metadata-source expects
<hoenir> I'm working on the cloud provider and in the process of the actual bootstrap the bootstrap config searches for images and tools in the default ubuntu sources and I specify the --metadata-source and customise it to pick the correct juju agent and image definitions.
<hoenir> on the cloud provider I mean oracle cloud provider.
<hoenir> So I don't know why the simplestreams/tools are looking into index.sjson and not looking into index2.json
<hoenir> also when tring to validate the tools with the juju metadata validate-tools -d /var/www/html/toolsdir --debug I get the following errors/warnings.
<hoenir> 14:28:05 DEBUG juju.environs.simplestreams simplestreams.go:457 skipping index "file:///var/www/html/toolsdir/tools/streams/v1/index2.json" because of missing information: "content-download" data not found
<hoenir> 14:28:05 ERROR cmd supercommand.go:458 "content-download" data not found
<hoenir> why?
<perrito666> do you have said key?
<hoenir> https://paste.ubuntu.com/23940769/ index2.json
<hoenir> and the ubuntu.com one.
<hoenir> https://paste.ubuntu.com/23940770/
<hoenir> perrito666, what key?
<perrito666> hoenir: I misinterpreted the error
<perrito666> that error is really not informative :( we should fix that
<hoenir> Also I generate the tools with this cmd juju-metadata generate-tools --debug --stream devel
<perrito666> jam: rogpeppe ever heard of it?
<rogpeppe> perrito666: heard of what?
<hoenir> And the documentation about the juju metadata is quite awful on the official site.
<perrito666> rogpeppe: 14:28:05 DEBUG juju.environs.simplestreams simplestreams.go:457 skipping index "file:///var/www/html/toolsdir/tools/streams/v1/index2.json" because of missing information: "content-download" data not found
<perrito666> never bumped into it
<perrito666> hoenir: that is why I asked abentley or eve balloons they are more likely to have tinkered with simplestreams
<perrito666> brb, need to relocate
<rogpeppe> hoenir, perrito666: is it actually allowed to give a file: URL as a metadata source?
<hoenir> also I'm on the tip of the develop branch
<rogpeppe> hoenir: have you done this kind of thing before?
<hoenir> yeah you can spiecify the directory or you cand specify the url in the --config like --agent-metadata-url
<rogpeppe> hoenir: what files are inside that /var/www/html/toolsdir directory?
<jam> hoenir: 'content-download' sounds like the image files, not the tools files
<jam> maybe not, one sec
<hoenir> Yeah, when I was using the mass in conjunction with juju
<jam> hoenir: http://streams.canonical.com/juju/tools/streams/v1/index2.json clearly has 'content-download'. I was thinking about the image binaries, but agent binaries also need content-download
<jam> (vs AMI, etc)
<hoenir> Also when you guys will update the provider documentation in the juju/juju repo ? It's pretty outdated.
<hoenir> I posted above pastes with my jsons.
<jam> hoenir: offhand I'm wondering if your juju client isn't looking for 'devel' tools
<jam> try setting 'agent-stream: devel'
<hoenir> also the bootstrap --debug file https://pastebin.ubuntu.com/23940814/
<jam> I see you are passing that in config
<rogpeppe> jam: if that is the case, then that error message should really be improved
<hoenir> After the err returned I os.Exit(1) to stop the execution .. If you have better ways to debug the code/inspect analyze other tha fmt.Printf("%+v\n", that_var), fmt.Println(err), os.Exit(1) please tell me.
<hoenir> like?
<hoenir> --config agent-stream: devel
<hoenir> ?
<hoenir> like this?
<rogpeppe> jam: to something like 'no appropriate tools found'
<jam> hoenir: your bootstrap has --config agent-stream=devel which is the correct syntax for CLI (if you put it in a .yaml file it is : vs =)
<hoenir> ok I will try now with agent-stream thing.
<hoenir> but what about the --config development=true ?
<hoenir> still the same thing.
<hoenir> "no tools available"
<hoenir> can anyone point me into some friendly doc on how to generate the tools and images correctly? and what's the best method to point the juju config to it? Also keep in mind this is very experimental and I'm woking to add a new provider.
<hoenir> Also this is how I generated the images and escaped that "no oracle cloud found in default images error" juju metadata generate-image -a "amd64"  -r "us6" --stream "devel" -u "https://api-z52.compute.us6.oraclecloud.com" --debug -i 20160356
<hoenir> Is this the correct way?
<hoenir> this is the tree structure https://pastebin.ubuntu.com/23940870/
<hoenir> how my metadata is laid out
<hoenir> anyone?
<perrito666> Hoenir I am one of the only ones online now and I don't know the answer sadly
<hoenir> :(
<perrito666> If you get a handle of sinzui he will know it
<hoenir> perrito 666, I don't know why but this should have a simple solution but clearly the lack of documentation really bothers me.
<hoenir> At this point I don't have any solution to just fmt.Println() os.Exit(1) step line by line and know what is the problem.
<hoenir> and it's painful but someone gotta do it.
<hoenir> Also I hate that the golang dosen't have a standardized compile like C has(gdb).
<hoenir> debugger*
<hoenir> anyway perrito666 thanks.
<perrito666> Hoenir I'll make sure to fwd your problem to the right people when they come online
<abentley> perrito666: I am not certain what it accepts, either.  Probably a path to a directory containing streams is permitted.  When I tinker with that, I use the agent-metadata-url config setting.
<perrito666> Hey I just went through one of these eye exams where they dilate your pupils a lot in one eye so don't expect me to answer chats for an hour or so
<perrito666> I'll use my good eye to answer emails though
<frobware> perrito666: I have these regualarly. in both eyes. It makes getting back from the hospital an interesting exercise...
<perrito666> frobware: I feel like someone messed up with my white balance and my focus
<redir> morning juju-dev
<perrito666> morning redir
 * perrito666 is starting to see again
<perrito666> frobware: how long does this last?
 * perrito666 should have asked before leaving
<hoenir> morning.
<frobware> perrito666: for me around 4 hours.
<frobware> perrito666: but also complicated as my pupils are overly dilated due to RP.
<perrito666> ghaaa 4 hs?
<perrito666> it has been 2 and still dont see very well so its possible that for me its going to be 3
<perrito666> I have the fantastic convo of swollen eye and change in necessary correction
<mup> Bug #1662272 opened: Agents stuck with "dependency not available" <juju-core:New> <https://launchpad.net/bugs/1662272>
<mup> Bug #1662272 changed: Agents stuck with "dependency not available" <juju-core:New> <https://launchpad.net/bugs/1662272>
<mup> Bug #1662272 opened: Agents stuck with "dependency not available" <juju-core:New> <https://launchpad.net/bugs/1662272>
<thumper> morning
<alexisb> morning thumper
<thumper> hey
<babbageclunk> thumper: do you know who needs to say $$merge$$ on this pr? https://github.com/go-goose/goose/pull/39
<babbageclunk> thumper: can you do it?
<thumper> babbageclunk: I'll check
<babbageclunk> thumper: clicking through some old PRs I only see axw and bz2
<thumper> I think the person needs write access to the repo
<thumper> and I don't have that either
<thumper> babbageclunk: I have been told of three sprints this year, the next one next month.
<thumper> hmm
<thumper> that isn't what I meant to paste
<thumper> babbageclunk: https://hangouts.google.com/hangouts/_/canonical.com/morning-chit-chat
<thumper> nope
<thumper> not that either
<thumper> where did all my clipboards go
<babbageclunk> lol
<thumper> pleased I didn't have anything bad in there
<babbageclunk> klajklj83jkhjs
<thumper> babbageclunk: https://github.com/orgs/go-goose/people
<thumper> babbageclunk: spicer's twitter password
<babbageclunk> oh man, now I have to change all my passwords
<babbageclunk> wallyworld: Can you merge this please? (or add me to the organisation I guess) https://github.com/go-goose/goose/pull/39
<redir> do we realy support puma, jaguar, panther?
<perrito666> redir: ???
<redir> perrito666: looking at series/supportedseries
<wallyworld> babbageclunk: you should have an invite to goose, see if you can now merge
<babbageclunk> wallyworld: awesome, thanks
<thumper> wallyworld: did you add babbageclunk to the go-goose org in github? doesn't look like it to me
<thumper> https://github.com/orgs/go-goose/people
<wallyworld> thumper: it said an invite was sent
<thumper> babbageclunk: did you accept invite?
<babbageclunk> thumper: yeah, but I forgot that I needed to make my memebership public.
<thumper> babbageclunk: ah...
<wallyworld> thumper: since at the moment you are looking at memory issues, it makes sense to assign bug 1660087 to you from menno - its probably already fixed in an earlier beta; easier to keep such things under the ine umbrella?
<mup> Bug #1660087: Controller and all models unresponsive <canonical-is> <juju:Triaged> <juju 2.1:Triaged by menno.smits> <https://launchpad.net/bugs/1660087>
#juju-dev 2017-02-07
<stokachu> wallyworld, should i be doing a PR against staging branch on GH?
<stokachu> it's a small change to the bash completion so nothing major
<anastasiamac> stokachu: what release is it for?
<wallyworld> stokachu: propose against develop. that will get into staging automatically after each blessed CI tun
<anastasiamac> stokachu: develop is essentially 2.2
<stokachu> ok cool
<anastasiamac> stokachu: if u need it in 2.1, propose against 2.1
<wallyworld> good point if it's for 2.1 then PR gainst 2.1
<anastasiamac> stokachu: which will b merged in develop and then eventually staging
<stokachu> ok so propose against 2.1 branch and it will go into develop/staging?
<anastasiamac> stokachu: yes
<stokachu> anastasiamac, great, thanks
<anastasiamac> stokachu: here to help \o/
<stokachu> ok lets see how this looks https://github.com/juju/juju/pull/6927
 * anastasiamac looking
<stokachu> anastasiamac, when you say flag do you just have to mention them and thats it?
<stokachu> or do i need to do anything
<anastasiamac> stokachu: I have "flagged" them by virtue of @ on github :) hipefully they'll notice and will know what to do with it ;)
<stokachu> anastasiamac, ok cool thanks
<anastasiamac> stokachu: ideally, we'd ove to have QA tests for this to ensure that code behaves but also that priorites are respected
<anastasiamac> love*
<stokachu> anastasiamac, yea maybe some expect tests would be nice
<wallyworld> perrito666: did you test your mongo tuning work when the server rebooted? it seems the values as set in mongo.go are not sticky
<perrito666> I did I even upgraded
<perrito666> You mean the cache size one?
<stokachu> wallyworld, do you guys want a force push to squish additional commits into one?
<stokachu> anastasiamac, ^
<wallyworld> stokachu: many folks do that, some don't
<wallyworld> us bzr refugees hate throwing away history
<stokachu> is there a preference?
<wallyworld> depends who you ask :-)
<stokachu> haha
<anastasiamac> stokachu: no preference here, but history is nice \o/
<stokachu> ok cool ill stick to that
<anastasiamac> world would b better place if history was remembered :D
<wallyworld> except git discourages that :-(
<perrito666> stokachu: in my opinion history is good while each commit compiles
<perrito666> wallyworld: btw, did you see my answer to the mongo tuning?
<wallyworld> which answer?
<wallyworld> oh, that one
<wallyworld> perrito666: i mean a server reboot
<perrito666> wallyworld: but by tuning you mean the mongo cache size?
<wallyworld> the hugepage values are not applied again
<perrito666> ahh I see, that is odd
<wallyworld> well ensure mongo is not run every agent start yo
<wallyworld> up
<perrito666> wallyworld: it should
<wallyworld> unless i tested wrong
<wallyworld> which i could have done
<perrito666> wallyworld: mm, you might be right
<wallyworld> did you test it?
<wallyworld> enesure mongo only runs at bootstrap i am almost certain
<perrito666> wallyworld: I did, but I might have got confused by the syslog output
<wallyworld> and hence the hugpage values are no reapplied
<wallyworld> i can't see a way of adding those to sysctl.conf so will find another way
<perrito666> wallyworld: I believe ensuremongoserver IS called upon restart but cant be sure because its inside a convoluted network of manifold nonsense
<perrito666> this code looks like javascript spaghetti
<wallyworld> EnsureMongo is called from jujud/bootstrap.go
<wallyworld> that is only run once at bootstrap time
<perrito666> becaise its called by MachineAgent.initState which is passed as OpenState in machine.ManifoldsConfig
<perrito666> wallyworld: EnsureMongoServer
<perrito666> wallyworld: for reasons completely unknown to me: cmd/jujud/util/util.go:	EnsureMongoServer = mongo.EnsureServer
<wallyworld> right, called from func (c *BootstrapCommand) startMongo
<perrito666> wallyworld: then cmd/jujud/agent/machine.go:	if err := cmdutil.EnsureMongoServer(ensureServerParams); err != nil {
<perrito666> wallyworld: that is eventually called by MachineAgent.ensureMongoServer
<wallyworld> is that in 2.1?
<perrito666> wallyworld: ghaa, that fix is not applied to 2.1 of course,
<perrito666> it is though
<perrito666> if you look at cmd/jujud/agent/machine.go line 1352
<wallyworld> ok, i'll dig into it a bit
<perrito666> the only difference is that a fix removing the if !mongoInstalled has not been applied
<wallyworld> right, i do not want to remove that
<wallyworld> that check is there for a reason
<perrito666> wallyworld: no, it isnt
<wallyworld> removing it would be wrong
<perrito666> wallyworld: its wrong
<wallyworld> if we have already installed mongo, there's no need to go through the work of doing it again
<perrito666> wallyworld: that check means "if there is a service file for mongo dont make sure its there"
<perrito666> wallyworld: its just por wording
<perrito666> wallyworld: what it actually checks is that systemd/upstart file is there
<perrito666> if not it re-generates it
<perrito666> you want to re-generate it in case mongo parameters have changed
<wallyworld> but it all installs mongod all over again etc
<wallyworld> EnsureMongo does a lot more than just mess with conf files
<perrito666> wallyworld: it should be idempotent, if its not, something is effed up
<wallyworld> is is of course. but it's unnecessary work
<wallyworld> overhead to starting up the agent
<wallyworld> messing with packaging etc
<wallyworld> maybe we don't care
<perrito666> wallyworld: you are not restarting 1k times per second
<wallyworld> still potentially hits repos etc
<perrito666> its an unnecessary optimization and, incidentally, also a bug :p
<wallyworld> slow network would cause agent startup to hang for a bit
<wallyworld> i disagree it's unnecessary
<perrito666> wallyworld: allow me to quote william on that one: show me numbers
<wallyworld> there's a difference between applying new config and installing mongo
<perrito666> apt will not hit repos for installed packages
<perrito666> apt will just say "all this is installed" since the dependency resolution is done offline
<wallyworld> i'll backport from develop then since it's already landed there
<perrito666> wallyworld: :) see, all it takes is some civiliced conversation and quoting william
<wallyworld> i still think we should have separated cfg management from othe rthings
<wallyworld> it's just too hard to do anything else right now
<perrito666> wallyworld: sure, also we should not have used mongo but we are too late to fix things done 2 years ago
<wallyworld> well changing this behaviour wasn't done 2 years ago
<thumper> ugh
<perrito666> wallyworld: EnsureMongo is at least 2 years old
<wallyworld> we don't for example attempt to install over and over all of our other packages
<thumper> fixing the conflicts in this branch is *awesome*
<wallyworld> perrito666: sure ENsureMongo is 2 years old, but calling it every time unnecessarily isn't
<perrito666> wallyworld: we dont install other packages, juju is not installed using apt
<wallyworld> juju install dependencies
<wallyworld> using apt as part of bootstrap
<perrito666> wallyworld: perhaps we should
<wallyworld> disagree
<perrito666> wallyworld: apt-get install on an already intalled package takes:
<perrito666> real	0m0.807s
<perrito666> user	0m0.768s
<perrito666> sys	0m0.028s
<wallyworld> it's not just that - it's the inconsistent behaviour
<perrito666> we install mongo separately from the other packages, its not entirely inconsistent
<wallyworld> some packages are reinstalled each agent start up, others aren't
<wallyworld> anyways, looks like there's only one way forward
<perrito666> wallyworld: there are not reisntalled, its a no-op they are never going to be reinstalled
<wallyworld> i didn't mean that literally
<perrito666> wallyworld: you are free to add an EnsureServerParams field that avoids the apt call if it makes you happy
<perrito666> it should be trivial and harmless
<wallyworld> not for 2.1, i'll just stick to what was done for develop
<wallyworld> we haven't got time to change all that at the moment
<perrito666> wallyworld: suit yourself, for me the apt call is free and harmless and consistent with a gazillion other idempotent behaviors and keeps mongo startup encapsulated
<perrito666> leverage the tools at hand, no need to re-implement checks that the package manager does for free
<wallyworld> nothing is ever "free" :-) but will stick to that
<perrito666> wallyworld: we should have a discussion about marginal costs some day :p
<perrito666> also my eye drops just stopped making effect so I am going to sleep
<wallyworld> ttyl
<wallyworld> axw: remind me, do we support controllers on redhat? or just ubuntu
<axw> wallyworld: just ubuntu
<wallyworld> ok, ta. the kernal tweaks to disable hug pages are potentially different on redhat
<thumper> hug pages?
 * thumper needs a hug
<anastasiamac> thumper: potentially different hug, like redhat?
<thumper> :)
<anastasiamac> looks like we are disabling hugs per above :D
<wallyworld> sigh
<axw> thumper: can you please take a look at https://github.com/juju/cmd/pull/46?
 * thumper looks
<thumper> axw: we don't need to do it this way... I don't think
<thumper> axw: we have other places that do special output for a single value
<thumper> you just don't call the format method
<thumper> but write the output
<axw> thumper: we have a broken version in "model-config", which isn't honouring --output
<axw> thumper: fixed in my upcoming PR
<thumper> ok
<axw> thumper: the alternative would be to expose the io.WriteCloser to the command, but then it needs to close the file. seems a bit safer/neater this way to me
 * thumper nods
<thumper> axw: lgtm
<axw> thumper: thanks
 * thumper out... 
<axw> anastasiamac and/or wallyworld: when you can, please take a look at https://github.com/juju/juju/pull/6928
<wallyworld> ok
<wallyworld> axw: what was the dep change?
<axw> wallyworld: https://github.com/juju/cmd/pull/46
<wallyworld> lgtm, thNK
<axw> anastasiamac: what is "eda" ?
<anastasiamac> axw: Escaped Defect Analysis
<axw> anastasiamac: okey dokey. thanks
<anastasiamac> axw: means it got out into the wild, should have been caught in QA by functional test (possibly)
 * axw nods
<anastasiamac> axw: QA specifically monitor bugs with this tag :) so it's a means of us flagging the bug to their attention...
<anastasiamac> for us*
<axw> anastasiamac: ah ok
<pranav_> Hi. I have a question regarding Cinder charm.
<pranav_> If i locally modify the cinder.conf through the shell and then modify config through the juju-gui
<pranav_> the local changes get overridden. Any workaround this?
<wallyworld> pranav_: you may be better asking in #juju where likely to be folks with more direct experience on that issue
<blahdeblah> Anything I can do to get new regions available in GCE on 2.0.2?
<anastasiamac> axw: m looking at ur 6929 pr :)
<pranav_> wallyworld: doing it in parallel on both :)
<wallyworld> if you don't what you need, an email to the juju list normally gets answers as well
<wallyworld> blahdeblah: is the region in public clouds yaml? if so, update-clouds should do it
<blahdeblah> wallyworld: I did an upgrade-clouds, and the regions closest to us (US West & Asia East) weren't there.
<wallyworld> blahdeblah: hmmm, it may be the publoc clouds yaml needs updating
<wallyworld> blahdeblah: yeah, the public clouds yaml file oooks out of date to me http://streams.canonical.com/juju/public-clouds.syaml
<wallyworld> blahdeblah: you can for now edit your own clouds.yaml file with the new regions
 * blahdeblah looks for clouds.yaml
<wallyworld> it won't be there unless you create it
<wallyworld> you can use juju add-cloud
<blahdeblah> I've got a ~/.local/share/juju/clouds.yaml with canonistack & maas in it.
<wallyworld> that CLI command takes a cloud name and an optional yaml file
<wallyworld> ok, so you can copy the gce cloud info from public clouds and edit it
<blahdeblah> OK - thanks; will give that a try
<wallyworld> put it in your local file
<wallyworld> keep the cloud name the same - it will override the upstream
<wallyworld> we'll haveto organise to get publoc clouds yaml updated
<blahdeblah> thanks wallyworld
<wallyworld> i'm off to soccer soon, but let me know if you still have issues with the workaround
<blahdeblah> that seemed to work fine; much appreciated, wallyworld
<wallyworld> yay, great
<wallyworld> blahdeblah: i raised bug 1662449. no need to target to 2.1 since fixing the yaml will alllow 2.1 and 2.0.2 to get the latest regions with upload-clouds
<mup> Bug #1662449: public clouds missing google regions <juju:Triaged> <https://launchpad.net/bugs/1662449>
<blahdeblah> I had it wrong; it was US West & Asia Northeast which were missing
<blahdeblah> I'll update bug
<axw> protip: reboot -h does not mean reboot --help
<axw> anastasiamac: if you're still around, here's another one: https://github.com/juju/juju/pull/6930
<anastasiamac> axw: have soccer but m happy to look when/if m back
<axw> anastasiamac: I hope you don't stay at soccer forever... thanks :p it can wait till tomorrow
<anastasiamac> axw: \o/ soccer forever... nice :D
<jam> axw: yeah, same for shutdown -h
<axw> jam: yeah I knew that one, didn't realise reboot did the same
<axw> reboot --halt seems weird
<axw> poweroff rather
<jam> axw: I have a feeling it is the sort of 'everything is linked to the same object'
<anastasiamac> axw: good one \o/ i hope it did not cause u too much pain ;(
<axw> jam: yup. -> systemctl
<axw> anastasiamac: nah, just annoying
<jam> axw: or ultimately "busybox" :)
<anastasiamac> axw: i imagine :)
<axw> jam: can you bind an endpoint to a space after deployment?
<jam> axw: no, we don't have moving things
<jam> axw: we'd probably like to get there, but there are the risks around "not all units are in the same space"
<jam> axw: would you mind if we set up a regular "standup" like call together? I'm finding that without a team around it can be hard for me to organize my next steps sometimes.
<axw> jam: sure, no worries
<axw> jam: what time would be best for you? you're +4 right?
<jam> yeah. start-of-my-day would be good, which is around UTC 5, but I'm open for whatever time
<axw> jam: that'll work
 * axw bbl
<anastasiamac_> axw: (I hope u r afk but) LGTM :)
<axw> anastasiamac_: thanks
<anastasiamac_> axw: my pleasure \o/ awlways amazingly nice to see ur code ;)
<perrito666> morning all
<anastasiamac_> perrito666: o/
<perrito666> jam: would you stamp the backport? https://github.com/juju/juju/pull/6931
<jam> perrito666: submitted
<perrito666> jam: tx
<anastasiamac_> perrito666: backports only need stamps if there is significant difference... if it's exactly the same as the originally reviewed code, feel free to self-stamp :) why re-invent the wheeel and re-stamp?
<jam> perrito666 is probably worried that he'll accidentally get a tramp-stamp
<perrito666> I am sure there is ajoke there
<jam> but perrito666, I agree with anastasiamac_ that backports/forward ports can be self-stamped if there isn't any significant changes. With the caveat that 2.1 is in prep-for-RC mode so we should be careful what we want to put in it
<perrito666> but it requires for me to google
<jam> perrito666: any chance you could look at https://github.com/juju/juju/pull/6933
<perrito666> jam: certainly, any chance you can jump into the outage channel on the other irc? :) need a second opinion
<jam> outage?
<cory_fu> Was credentials support added for lxd in the latest beta?  It has started prompting me for a credential when working with a shared lxd controller where it did not previously, and I have no credential to supply it with.
<perrito666> jam: ship it
<jam> cory_fu: axw was the one making some of those changes. I'm not sure how it interacts with existing LXD deployments. I think there is an upgrade step to fix that sort of thing, but that would be a 2.0=>2.1x upgrade
<jam> vs a 2.1b4 => 2.1b5
<cory_fu> jam: I don't understand.  This is a freshly bootstrapped 2.1b5 localhost controller.  I used add-user + grant, then registered the controller with another juju and tried to add model from there and it said "no controller specified."  This worked in the last beta.  I could add a credential for the controller like I have to do for aws, etc, but I don't have a credential to add
<cory_fu> jam, axw: So, I tried upgrading a juju 2.0.2 to the latest beta and then registering the controller, and I got a new error about an invalid credential: http://pastebin.ubuntu.com/23948469/
<jam> cory_fu: sounds like a bug we need to address in 2.1b5, can you submit one and we'll poke axw to look into it
<cory_fu> Sure
<jam> cory_fu: I know we were doing bad things with credentials and LXD before, it looks like fixing credentials may have broken multi-user
<cory_fu> jam: I'm currently testing whether how I bootstrapped it has an effect.  I don't recall if I bootstrapped it as lxd or localhost.  Testing with localhost to be sure
<cory_fu> jam, axw: Filed https://bugs.launchpad.net/juju/+bug/1662587  Thanks
<mup> Bug #1662587: 2.1beta5 breaks lxd shared controller <juju:New> <https://launchpad.net/bugs/1662587>
<redir> morning juju-dev (almost forgot!)
<alexisb> morning redir
<perrito666> redir: morning
<redir> :)
<mup> Bug #1662599 opened: Change maas api and password controller in model already created <juju-core:New> <https://launchpad.net/bugs/1662599>
<perrito666> hey Ill step out for a moment and return later, cheers
<redir> intermittent internet today
<redir> lots of rains
<redir> and winds
<redir> easy PR: https://github.com/juju/juju/pull/6935
<perrito666> redir: ship it
<redir> tx
<redir> perrito666:
<redir> wallyworld: yt?
<redir> me steps away shortly to run a couple errands.
<kwmonroe> cory_fu!  i'm so l33t.  i shared a lxd controller and added a localhost stanza to the credentials.yaml on the remote user (jenkins in your case). it needs the contents of server.crt, client.crt, and client.key from the remote lxd host.  then a set-default-credential for jenkins, and bingo bango, add-model for days.
<kwmonroe> i'll expand on the workaround in https://bugs.launchpad.net/juju/+bug/1662587, but wanted to let you know in case you were stuck.
<mup> Bug #1662587: 2.1beta5 breaks lxd shared controller <juju:New> <https://launchpad.net/bugs/1662587>
<cory_fu> kwmonroe: Awesome!
<cory_fu> kwmonroe: Is that with beta5 on both the sharer and sharee?
<kwmonroe> you made up some of those words cory_fu
<kwmonroe> yes, b5 all around
<cory_fu> :)  Ok
<balloons> perrito666, you on-call reviewer?
<balloons> cory_fu, ouch that bug
<perrito666> balloons: no, but I am keen to review things if you need
<balloons> perrito666, ohh, well then; https://github.com/juju/juju/pull/6936
<babbageclunk> ugh, who decided that using dashes as the separator between items that have dashes in them was a good idea?
<balloons> not sure how much you've played around with snaps, so this is your chance to vet
<perrito666> balloons: build-packages: [gcc] ?
<perrito666> balloons: I have snapped things, go things to be accurate :)
<balloons> perrito666, that was requested by snapcraft upstream for there builder. It's no-change from the previou
<perrito666> k then, lgtm, let me stamp it
<balloons> perrito666, mind trying out a build; I'm keen to make sure it's easy for developers to snap up there local repo
<kwmonroe> cory_fu: bug 1662587 updated if you need the steps..
<mup> Bug #1662587: 2.1beta5 breaks lxd shared controller <juju:New> <https://launchpad.net/bugs/1662587>
<balloons> not sure how much you've tried to to that. snap, and then push to the store
<perrito666> balloons: let me see if this computer has the snapcraft things
<balloons> perrito666, ahh, no worries if not
<perrito666> balloons: building
<cory_fu> kwmonroe: Thanks.  Does set-default-credential actually work with beta5 on an imported controller?
<kwmonroe> $ juju set-default-credential localhost hamburgalar
<kwmonroe> Default credential for localhost set to "hamburgalar".
<kwmonroe> yeah, looks to work for me.. subsequent "juju add-model blah" don't need a --credential flag
<kwmonroe> $ juju add-model see-cory-fu
<kwmonroe> Uploading credential 'localhost/cwr-ci/hamburgalar' to controller
<kwmonroe> Added 'see-cory-fu' model on localhost/localhost with credential 'hamburgalar' for user 'cwr-ci'
<kwmonroe> and now i need to google how to spell hamburgalar.. i think it probably hamburgler
<kwmonroe> i'm sure that's not a special case in the juju code though, so you should be fine.
<cory_fu> kwmonroe: Ok, so they fixed that, so that's nice.  Not sure how we'll handle the transition, though
<cory_fu> kwmonroe: Interesting.  Doing `juju add-credential localhost` in 2.0.2 creates a cred with "auth-type: empty" and no other props, like we tried to create before
<kwmonroe> it's hamburglar
<perrito666> balloons: interesting, I have time to take a shower while snap builds juju
<perrito666> actually I could take two since it has not finished yet and I am already back
<balloons> perrito666, :p
<cory_fu> kwmonroe: Good to know
<kwmonroe> :)
<balloons> wallyworld, perrito666, anastasiamac_, abentley, sinzui, https://github.com/juju/juju/pull/6936 is the PR. I have pushed 2.1-beta5 to the beta channel, and 2.0.2 to the stable channel. Check them out. snap install juju --classic and snap install juju --classic --beta
<balloons> they should all "just work" as you expect
<sinzui> thank you balloons
<wallyworld> awesome
<balloons> wallyworld, you'll note btw it uses your local tree by default, but there's a few options to specify tags, commits or branches as well as location. Should make dev builds easy
<wallyworld> ok, i'll check it out
#juju-dev 2017-02-08
<menn0> perrito666: ping
<redir> uh, https://github.com/juju/juju/pull/6938
<redir> tough one there, I might self review
 * anastasiamac_ looking
<anastasiamac_> redir: LGTM \o/
<redir> tx anastasiamac_
<axw> wallyworld: re https://bugs.launchpad.net/juju/+bug/1662587, any thoughts on what we can do that doesn't involve going back to what we were doing?
<mup> Bug #1662587: 2.1beta5 breaks lxd shared controller <juju:Triaged> <juju 2.1:Triaged by axwalk> <https://launchpad.net/bugs/1662587>
<wallyworld> axw: so the bug is saying that adding a user, and then having someone else register doesn't work? because that new person doesn't have the credentials cached?
<seyeongkim> hello, what can i do if i want to merge 163a221,773fb90 to 2.0.x? lp said only 2.1 and 2.2 https://bugs.launchpad.net/juju/+bug/1622024
<mup> Bug #1622024: destroy-unit help text mentions nonexistent remove-services <sts> <usability> <juju:Fix Committed by wallyworld> <juju 2.1:Fix Committed by jameinel> <https://launchpad.net/bugs/1622024>
<wallyworld> seyeongkim: if you have 2.0.x checked out, you can cherry-pick the commit
<seyeongkim> i see wallyworld , will try
<wallyworld> seyeongkim: it's a rather cosmetic bug fix though. do you need the CLI help text changed urgently?
<wallyworld> 2.1 will be out within a couple of weeks
<seyeongkim> no urgent
<seyeongkim> thanks wallyworld
<wallyworld> sure, anytime
<axw> wallyworld: basically yeah. it works if you're the same $USER, because it'll pull the certs out of your $HOME/.config/lxc dir. but in their case, it's an entirely different $USER
<axw> wallyworld: I don't think we can support what they were doing without going backwards...
<wallyworld> axw: should we consider a controller endpoint where cched creds in controller can be checked?
 * wallyworld waves hands
<axw> wallyworld: sorry, don't understand
<axw> wallyworld: what creds, checked for what?
<wallyworld> HO? may be easier to discuss
<axw> wallyworld: ok, in 5-10 mins; just preparing lunch
<wallyworld> sure no rush
 * redir eods
<axw> wallyworld: are you free now? 1:1?
<wallyworld> yep
<axw> wallyworld: it will work, but only if they're using the 2.1-beta5 client. I suspect they're not
<wallyworld> axw: good pickup, sounds like it can be closed as "use the current client"
<axw> wallyworld: it's not great that it will fail with the old client, but I think it's better than reverting?
<wallyworld> axw: i think we can justify it (IMO). there's a work around we can document and it's not a super common use case i don't think
<axw> wallyworld: actually I think what they're doing is running from within a container, or some other machine on the same network; not on the host itself
<axw> wallyworld: so might need to just make "autoload-credentials" a bit easier
<wallyworld> axw: yeah, autoload creds does need some polish in a few places
<wallyworld> it was all rushed at last minute to get 2.0 out
<wallyworld> axw: could you validate my choice of new skew value on this small PR? https://github.com/juju/juju/pull/6940
<axw> wallyworld: seeing as this is only run on linux, can we just bite the bullet and use a monotonic clock?
<wallyworld> axw: i didn't realise there was such a thing
<axw> wallyworld: man clock_gettime
<wallyworld> axw: so how would that work clustered?
<wallyworld> all machines need the same idea of time
<wallyworld> ntp achieves that
<wallyworld> but it needs make -ve corrections potentially
<axw> wallyworld: it's for measuring elapsed time
<axw> wallyworld: which IIANM is what we're doing in that code
<axw> elapsed time local only
<wallyworld> ok, i'll take a look
<axw> wallyworld: https://github.com/davecheney/junk/blob/master/clock/clock_linux.go -- just need to include the LICENSE if you use that
<wallyworld> axw: MonotonicClock "but is affected by the incremental adjustments performed by adjtime(3) and NTP"
<wallyworld> i guess it only goes foreard though
<axw> wallyworld: http://stackoverflow.com/questions/14270300/what-is-the-difference-between-clock-monotonic-clock-monotonic-raw
<axw> explains it better than I could
<wallyworld> axw: so it seems monotonic changes frequency to adjust for NTP and eventually syncs up
<axw> wallyworld: yep, but it won't jump around
<axw> it just adjusts rate of change
<wallyworld> thumper: menn0: jam: tech board?
<menn0> we are still dealing with the fallout from this prod issue
<wallyworld> ok
<blahdeblah> axw: That was a nice link
<blahdeblah> FTR, I would be very nervous about juju attempting to go the CLOCK_MONOTONIC_RAW route, given some of the bad clocks I've seen around, esp. in Azure.
<axw> blahdeblah: yeah, I don't think it's appropriate for our use case
<mup> Bug #1662599 changed: Change maas api and password controller in model already created <juju:Incomplete> <https://launchpad.net/bugs/1662599>
<mup> Bug #1662599 opened: Change maas api and password controller in model already created <juju:Incomplete> <https://launchpad.net/bugs/1662599>
<mup> Bug #1662599 changed: Change maas api and password controller in model already created <juju:Incomplete> <https://launchpad.net/bugs/1662599>
<blahdeblah> Hi all, when logging into mongodb shell per https://github.com/juju/juju/wiki/Login-into-MongoDB, I get a number of recommendations: https://pastebin.canonical.com/178617/
<blahdeblah> Is it worth creating a bug for that?
<blahdeblah> I wonder some of those things mightn't be contributing causes for our mongodb syncing issues (bug 1647238)
<anastasiamac> blahdeblah: axw and wallyworld were talking about disabling huge pages yesterday... maybe they can help?
<axw> anastasiamac: I believe wallyworld was talking about *hug* pages, and I was merely a an absent target ;p
<anastasiamac> axw: :)
<blahdeblah> axw: I can think of better things to hug, personally. :-)
<blahdeblah> axw: (Than pages, I mean.  I'm sure you're a great huggee.)
<axw> blahdeblah: :p
<mup> Bug #1510787 changed: juju upgrade-charm errors when it shouldn't <canonical-is> <juju:Triaged> <juju-core:Won't Fix> <postgresql (Juju Charms Collection):Won't Fix> <https://launchpad.net/bugs/1510787>
<babbageclunk> axw: Could you take a look at my openstack provider changes, pretty please? https://github.com/juju/juju/pull/6943
<axw> babbageclunk: sure
<babbageclunk> axw: thanks!
<mup> Bug #1632909 changed: ceilometer-api fails to start on xenial-newton (maas + lxd) <maas-provider> <uosci> <OpenStack AODH Charm:Triaged> <juju:Incomplete> <juju-core:Won't Fix> <ceilometer (Juju Charms Collection):Triaged> <https://launchpad.net/bugs/1632909>
<axw> babbageclunk: don't worry about that VolumeSource thing too much. the API design is a bit broken, I will fix it at some point
<axw> what you have is fine
<babbageclunk> axw: great, thanks
<wallyworld> axw: i've pushed up a juju/utils PR and also tweaked the juju PR for clock skew. got to fix a few tests and add deps change, but have to head out for a bit. i also need to live test etc but the basis should be there. the monotonic clock implementation doesn't return a true time.Time but it does work cross platform
<wallyworld> axw: oh saw your comment - i just didn't want the hassle of 2 implementstions, or an implementation on linux and a no-op elsewhere
<wallyworld> nanotine() is implemented cross platform in the run time isn't it?
<axw> wallyworld: I think so. but there's more than one compiler, and more than one runtime...
<wallyworld> seems to be a popular approach to the problem
<wallyworld> ok, i do the linux only thing then
<axw> wallyworld: never mind, it's probably academic
<axw> wallyworld: just leave it and we'll change it if necessary
<wallyworld> ok
<axw> wallyworld: utils PR is approved
<axw> looking at other one now
<wallyworld> ty, am late bbiab, will fix test setc then
<hoenir> Hi guys
<hoenir> So for a day I'm trying to make the oracle provider add custom cloud definitions. In order to communicate with the oracle rest api the client needs to specify the Identity Domain name and I'm trying to make the add-cloud command add this yaml field.
<hoenir> So I've tried to write the CloudSchema return the correct pointer to jsonsmecham.Smecha struct
<hoenir> https://paste.ubuntu.com/23953504/
<hoenir> What I'm I missing here?
<hoenir> When I launch the add-cloud command it's printing me to add the identity domain and after the commands finished writing the clouds.yaml it does not add this attribute.
<hoenir> Also I found this https://github.com/juju/juju/blob/staging/cloud/clouds.go#L106
<hoenir> Is there a way how to write in this attribute when the provider reads the clouds definition on bootstrap?
<hoenir> Is there anyone that knows or can point me into the right direction?
<hoenir> here is an example interacting with the add-cloud cmd
<hoenir> https://paste.ubuntu.com/23953549/
<hoenir> sorry for the spelling issues. As you can see these does not write the identity-domain provided in the cmd interaction.
<hoenir> It is because the CloudSchema definition provided is somehow off?
<hoenir> Or there is now wat to do this and I should add some custom interactive code into the FinalizeCredential?
<hoenir> like in the azure provider?
<mup> Bug #1662857 opened: cannot go get the source code  <juju-core:New> <https://launchpad.net/bugs/1662857>
<mup> Bug #1662857 changed: cannot go get the source code  <juju-core:Incomplete> <https://launchpad.net/bugs/1662857>
<mup> Bug #1662857 opened: cannot go get the source code  <juju-core:Incomplete> <https://launchpad.net/bugs/1662857>
<perrito666> morning
<jam> morning perrito666
<SimonKLB> is there a problem when a normal machine and the controller machine are on different addresses?
<SimonKLB> im unable to ssh into a machine that is on a different ip-range using GCE as provider
<SimonKLB> with `juju ssh` that is, ssh:ing into the machine normally works fine
<SimonKLB> nvm, that wasnt the problem, now i cant ssh into a machine on the same range - really odd because other machines in the same model works fine
<SimonKLB> http://paste.ubuntu.com/23954247/
<SimonKLB> any ideas?
<deanman> SimonKLB, cloud provider?
<SimonKLB> deanman: google
<deanman> SimonKLB, can you access any app on that model ?
<deanman> SimonKLB, i had almost a similar problem with openstack where additional units of the same app weren't assigned a public IP, which resulted only being able to ssh into only one at a time.
<SimonKLB> deanman: that shouldnt be the problem, i can see the public ips fine
<SimonKLB> deanman: not sure what you mean by accessing the app though?
<deanman> SimonKLB, this was my issue, https://bugs.launchpad.net/juju/+bug/1655383, seems though unrelated to yours
<mup> Bug #1655383: When deploying multiple units of the same charm on top of openstack mitaka only one is assigned a floating IP <eda> <network> <juju:Triaged> <juju 2.1:Incomplete> <https://launchpad.net/bugs/1655383>
<SimonKLB> deanman: might be related, but in my case i all the machines get assigned a floating/external ip
<SimonKLB> im also able to ssh to them via the GCE console without any issue
<deanman> SimonKLB, next thing i could think is that somehow "security groups" are different for machine #3 and #4
<deanman> could it be that #4 has different security groups and somehow the ssh port is blocked? Can you ssh from #3 to #4 ?
<SimonKLB> deanman: i have no idea why, but now, an hour later they are all accessable
<SimonKLB> havent changed a thing
<SimonKLB> have even worked in a different provider since then
<deanman> maybe infra glitch ;-)
<SimonKLB> haha, let's hope so :)
<SimonKLB> i'll re-run the tests
<deanman> Got a question for the devs, I'm running juju agent inside corporate network and i have to go through proxy. I'm using nc for most of my ssh needs but don't know how to make it work with juju so i can access my aws models. Any hints?
<hoenir> can anyone advice me, If I have a constrains let's say cpu-power and the provider does not support passing constraints like cpu how can I manage with the constraints.Validator methods this issue? I've already used the Unsupported methods but it seems this does not do anything to alert the client in someway if the constraint passed is valid or not for the provider
<hoenir> constraint*
<hoenir> can anyone provide some insight in this situation?
<perrito666> hoenir: I believe we are currently silent if a constraint is ignored with a provider
<perrito666> sinzui: you have tried all providers, what can you tell about this?
<hoenir> So informing the user with warningf is bad technique?
<sinzui> perrito666: your are correct, juju siltenly ignore constraints that are not relavant.
<hoenir> so it's ok if I inform the user?
<hoenir> of this?
<hoenir> in the bootstrap process
<hoenir> ?
<hoenir> with warningf?
<perrito666> hoenir: yes, absolutely
<perrito666> but we wont stop juju for it
<hoenir> yeah:)
<perrito666> just warn or even info about
<hoenir> thanks !
<hoenir> I think warn is better suited for this situation
<perrito666> hoenir: mm, I think you are correct, if the user is dealing with constraints its most likely watching warn
<perrito666> sorry for the delay I was afk
<hoenir> thanks !
<hoenir> smt like this.
<hoenir> https://paste.ubuntu.com/23954775/
<jam> perrito666: if you get a chance, a review of https://github.com/juju/juju/pull/6944
<perrito666> postponing the air conditioning in my office was the worse idea I had In my life
<perrito666> jam: ship it
<perrito666> jam: special kudos for the doc in NewLXDBroker
<redir> morning juju-dev o/
<perrito666> redir: morning
<alexisb> morning redir
<redir> \o
<cory_fu> Does Juju (2.1-beta5) support running lxd on a port other than 8443?
<cory_fu> Specifically, I'm trying to use the snap to run beta5 alongside stable (via apt), and am hitting a bind conflict: http://pastebin.ubuntu.com/23955676/
<redir> cory_fu: sorry, I am unfamiliar with the lxd code.
<babbageclunk> morning people!
<thumper> o/
<perrito666> morning thumper
<alexisb> morning thumper
<perrito666> thumper: btw, I addressed your comments in https://github.com/juju/juju/pull/6763 and mentioned you to re check it, could you take a look when you are not working on urgent stuff?
 * perrito666 knows he just wrote a blank check to thumper
<thumper> perrito666: ok, will try to look shortly
 * perrito666 is fighting to take his PR queue to 0
<alexisb> perrito666, ping
<perrito666> alexisb: pong
<alexisb> release call
<perrito666> ah sorry was concentrated on a critical I just introduced
<perrito666> going
<redir> anyone https://github.com/juju/juju/pull/6947
<cory_fu> Are old revisions of a resource cleaned up ever?  I'm revving on a charm with a fairly sizable resource and after a couple of times updating the resource, the controller seems to run out disk
<menn0> perrito666: if you're not EOD after you finish your HO can you please ping me about this migration issue. I have some thoughts.
<perrito666> menn0: certainly, I foresee that my EOD is far :)
<perrito666> menn0: I might ask you to HO , I am a bit sick of writing :p[
<menn0> perrito666: sure
<menn0> perrito666: now
<menn0> ?
<perrito666> menn0: this is the cause https://github.com/juju/juju/commit/49316b2 I am running this test to try to understand how this change caused this
<perrito666> menn0: no, still on a call
<menn0> perrito666: let me know when you're off
<perrito666> menn0: I will <cries in spanish>
<perrito666> menn0: standup call?
<menn0> perrito666: yep
<wallyworld> cory_fu: there may have been an issue at one point.... what version of juju are you running? menn0 do you know if we fixed tht?
<cory_fu> wallyworld: 2.0.2  I can re-test on 2.1-beta5 tomorrow if it's likely to have been fixed
<wallyworld> cory_fu: I *think* so but will need confirmation as I didn't work on it myself
<cory_fu> Ok.  Thanks
<wallyworld> menn0 is on a call, he will respond soon
<axw> wallyworld: reviewed your PR
<wallyworld> ty
<wallyworld> axw: end-beginning check should never fail now - i just thought defensively best to keep it?
<wallyworld> axw: standup?
<axw> wallyworld: oops, coming
<axw> wallyworld: feel free to leave it, just my preference
#juju-dev 2017-02-09
<axw> redir: ping
<redir> axw
<axw> redir: I zoned out, what did you want to talk to me about?
<axw> redir: was it about the ec2 region?
<redir> yesa
<redir> axw: https://hangouts.google.com/hangouts/_/canonical.com/axw-redir
<perrito666> menn0: priv
<redir> anastasiamac: https://github.com/juju/juju/pull/6948
<anastasiamac> redir: \o/
<axw> menn0 thumper: when you migrate, you're expected to have a cloud definition in the target controller already right?
<thumper> axw: yes
<axw> thumper: ok, thanks
<thumper> axw: the user initiating the migration has to have access to both controllers
 * axw nods
<axw> thumper: there's a bug about not being able to change cloud endpoints. one current workaround (for 2.1) would be to bootstrap a new controller with the updated endpoints, and migrate to it
<thumper> axw: what do you mean?
<axw> thumper: https://bugs.launchpad.net/juju/+bug/1662599
<mup> Bug #1662599: Change maas api and password controller in model already created <juju:Incomplete> <https://launchpad.net/bugs/1662599>
<axw> thumper: we currently lack an API/command to update a cloud definition within a controller
<thumper> ah... right
<axw> not sure if migration would succeed if the source controller's environs can't be opened though?
<thumper> we don't do model renaming on moving yet
<thumper> the model config for the maas endpoint is set when the model is created right?
<axw> thumper: it's not in model config any more
<thumper> hmm..
<thumper> I recall now
<thumper> axw: side issue, any idea how to ask the go runtime who is holding references to an object?
<axw> thumper: anyway doesn't matter, that person is on 2.0 and probably can't use the feature flag
<axw> thumper: heap profile for in-use objects will show you that
<thumper> hmm...
<axw> thumper: go tool pprof -inuse_objects
<thumper> I thought the heap profile was sampling
<axw> thumper: yeah, no good if you want every single ref
<thumper> yeah...
<thumper> veebers: ping
 * redir eods
<veebers> thumper: hey, I'm just heading out the door for a little bit
<axw> thumper: what in particular do you want to track?
<thumper> veebers: ack
<thumper> axw: I have some *state.State objects that have been closed but not GCed
<thumper> wondering why...
<thumper> perhaps just not busy enough
<thumper> although
<thumper> I cheekily added a runtime.GC to see
<thumper> but they aren't being cleaned up
<thumper> could be a real problem
<babbageclunk> thumper: I guess as long as all the goroutines for them are stopped they probably aren't taking up much memory
<thumper> well... that is a question isn't it
<thumper> I'm not convinced they are stopped
<babbageclunk> uhoh
<thumper> hence the continued increase memory and db load
<axw> thumper: if we use https://golang.org/pkg/runtime/pprof/#NewProfile and https://golang.org/pkg/runtime/pprof/#Profile.Add, should be able to track what's creating the State objects at least. or do you already know that from the state pool modifications you made?
<thumper> axw: I've just added a state tracker
<thumper> :)
<thumper> which captures the stack for all new state instances
<axw> thumper: ok. I think if you use the runtime/pprof things you can use "go tool pprof" to generate pretty pictures. but whatever works
<thumper> hmm...
<thumper> I was just about to propose for review
<thumper> I'll take a quick look first
<thumper> not sure this will do what I want unfortunately
 * thumper goes to make coffee
<axw> wallyworld: I just pushed a change to https://github.com/juju/juju/pull/6941 so that DetectCredentials returns a fully formed credential for localhost
<axw> wallyworld: can you PTAL?
<wallyworld> sure
<axw> wallyworld: the reason for the change is so to make cred loaded by autoload-credentials immediately usable
<wallyworld> i was wondering about that
<wallyworld> but thought i was missing something
<axw> wallyworld: it was intentional but misguided. the idea was that the partial cred would be finalized against a specific cloud later, which would give you a chance to be prompted for the fingerprint/password
<axw> wallyworld: but there's an interactive auth type for that now, and the partial cert breaks autoload
<wallyworld> right, makes sense
<wallyworld> axw: i think there's a slight ambiguity. "If you're not on the LXD host, you can use juju add-credential localhost..."  <--- maybe "If you intend to interact with the LXd cloud from a host other than the one running LXD, you need to run from the LXD host 'juju add-credential ....'
<wallyworld> or something like that
<wallyworld> just to be really clear what needs to be run on what machine
<axw> wallyworld: you talking about the docs link?
<wallyworld> yeah
<wallyworld> axw: i'd also leave out the lxd trust reference in the juju message.... i think we want to guide people to using juju tooling?
<wallyworld> so maybe just mention the need to export the credential from the LXD host to the machine from where the user wants to gain access
<wallyworld> and provide the link to the docs to show them how
<axw> wallyworld: ok. I've updated the docs issue
<axw> wallyworld: is this better for the command output? http://paste.ubuntu.com/23958386/
<wallyworld> axw: thanks, i added a small change "..... you must add credentials to that other machine manually."
<axw> wallyworld: sounds good
<wallyworld> axw: yeah, reads much nicer. but i think "add-credential lxd" might work instead of "localhost"? not sure. but "localhost" could be confusing as they are adding a credential for a cloud "other there" not on localhost
<wallyworld> if "lxd"works, they can name the credential after the host
 * axw tests
<wallyworld> the host running lxd
<axw> wallyworld: I think it depends on the cloud name, which will be localhost
<wallyworld> i think our code supports both lxd or localhost for the lxd provider?
<wallyworld> ie we use add-credential google or add-credential aws
<axw> wallyworld: for bootstrapping yes, but I don't think so for add-model.. will see
<axw> wallyworld: those are the names of the clouds, not the providers
<wallyworld> right, but i *think* we special case lxd, but as you say, maybe only for bootstrap
<wallyworld> i think we need to tweak add-model if it isn't suported there
<axw> wallyworld: the UX for creds is still a bit rough I think
<wallyworld> yeah
<wallyworld> but so is the lxd/localhost handling
<wallyworld> axw: we can land as is but i do think we need a followup to avoid falsely add creds for a cloud on another machine and using the cloud name "localhost"
<axw> wallyworld: it's pretty low priority I think. this is an edge case
<wallyworld> that's IMHO. i would prefer "lxd" as we say things like we are running a "maas" cloud or an "lxd" cloud. or at least i do
<axw> so yes, but probably not today
<axw> wallyworld: it would probably be reasonable to fall back to the provider name when looking for creds
<wallyworld> ok. if we ship with it as "localhost", so long as both then still work if a changeis made. maybe we can fix before 2.1 final
<wallyworld> yeah, i think so
<wallyworld> axw: so are you intending to followup with the docs guys to get the new doc link up before the rc goes out tomorrow? might be worth an email to nick or peter?
<axw> wallyworld: will do
<wallyworld> ta
<axw> wallyworld: not much point actually, it's not going to go into the stable docs until the final release is it?
<wallyworld> final release is within a week - can we add it but not link to it from anywhere. then the only way you see it is via the juju cli output
<axw> wallyworld: it's not going to go on its own page, it'll be on the LXD cloud page
<axw> wallyworld: which is linked from the main page, and has stable vs. devel in the URL
<axw> wallyworld: it's an edge case, is it really worth all this energy? we can mention it in the release notes and link to the issue or devel docs if it makes it in there
<wallyworld> hmmmm. can we land in the devel docs
<wallyworld> ok
<thumper> WTF? why is 2.1 version updated?
<thumper> we haven't done the rc1 release yet
<anastasiamac> thumper: according to sinzui's mention in release call: "versions must be numbers and dots to get into proposed and released"
<sinzui> thumper: that is true.
 * thumper isn't happy
<thumper> it isn't a .0 release
<thumper> it is an rc release
<sinzui> thumper: some juju that read streams with letters in the version fall over
<sinzui> thumper: I think you can recall that
<thumper> sinzui: pre 1.20
<sinzui> thumper: so to prevent breakage, there are controls that will abort if you put an "rc" in them
<sinzui> thumper: I also brought this up with the release of 2.0 and no onw made a fuse (they should have)
<sinzui> thumper: by putting the rc in *proposed* stream, we are commited to burn numbers. We can put rc1 in the devel stream...but we cannot promote it to proposed
 * sinzui wished we could decouple the client's build from the inteded version
<sinzui> thumper: consider this if we rename juju to 2.1-rc1 again, and publish the agents to devel. The client will automatically look for agent in devel. The client package could be manually copied to the proposed ppa. The snapped client can also go to the candidate. The only problem is testers that need to adjust streams in scripts will need to set agent-stream=devel
<thumper> ick
<thumper> we need to fix this
 * thumper out
<wallyworld> axw: this PR is a lot of noise (fake auth field name as driveby), but fixes keymanager facade permissions https://github.com/juju/juju/pull/6951
<axw> wallyworld: ok, looking
<wallyworld> ta
<axw> wallyworld: next time can you please separate the drive by into a separate commit, so it can be reviewed with unfocused eyes :)
<wallyworld> yeah, fiar point
<wallyworld> sorry
<wallyworld> the changes if noe are in apiserver/keymanager
<wallyworld> *of note
<blahdeblah> Hi folks - is there going to be a similar fix for 1.25.x as will be in 2.0.3 for the memory leaking?  Just discovered that on of our main production environments on 1.25.6 has been getting OOM killed as well.
<axw> wallyworld: left a bunch of comments, will look at tests after you respond
<axw> blahdeblah: I don't think the one that affected 2.0.3 applies to 1.25.x
<wallyworld> sure ty
<axw> blahdeblah: we're up to 1.25.9 now, which does include some leak fixes
<axw> (I hear there are still issues in 1.25.9, but it'd be good to rule out hte bugs that have already been fixed)
<blahdeblah> axw: In our production deployments, we've found post-1.25.6 releases less stable, and so froze them there.
<axw> blahdeblah: I see
<blahdeblah> I upgraded two small Canonistack envs to 1.25.10 (in proposed) late last week/early this week, in response to a request in lp:1587644, and they're still experiencing similar symptoms, although without the obvious memory leak.
<blahdeblah> But still need jujud-machine-0 restarts every day or two
<axw> blahdeblah: ok, well I don't know when a new 1.25 will come. we're all focused on getting 2.1 out the door right now
<blahdeblah> yeah - fair enough
<axw> blahdeblah: apart from dealing with fallout from the odd prodstack explosion :o
<blahdeblah> :-)
<blahdeblah> I might poke around for any 1.25 bugs which match the symptoms
<babbageclunk> menn0: around? min reviewing this for me? https://github.com/juju/juju/pull/6952
<babbageclunk> menn0: It's short!
<axw> wallyworld: still reading responses, check my comment about controller tag again please
<wallyworld> axw: i'm missing something i think - it looks ok to me. the controller tag is only used in the mothod to check for superuser
<wallyworld> the model is passed in separately
<axw> wallyworld: the comment was next to the call to common.HasPermission
<axw> wallyworld: which does not take a model
<wallyworld> oh, i am dyslexic
<wallyworld> should be ok now
<babbageclunk> or axw? https://github.com/juju/juju/pull/6952
<axw> babbageclunk: looking
<axw> babbageclunk: you have run the QA for all those clouds right?
<axw> or do we have CI tests set up for this?
<axw> babbageclunk: LGTM
<wallyworld> axw: yeah, i don't think it's possible to have a model owner that's not an admin, hence no test was added. mayber it is with some convoluted test setup, i'll have a look
<wallyworld> might be doable with fake authenticator
<axw> wallyworld: I can imagine that someone might want to create a model and then hand it off, but IMO that would be transfer of ownership. or we should call it "creator" rather than owner
<wallyworld> yeah
<wallyworld> people have asked for that
<axw> wallyworld: I just replied again. while writing I realised that checkCanRead also will need to be updated if we're going to stick with the existing behaviour around system identity key
<wallyworld> yeah, i'm going to review the logic again
<axw> wallyworld: I added an RC1 section to the release notes, with a blurb about LXD creds. would you please have a read when you have a chance?
<wallyworld> sure ty
<babbageclunk> axw: Sorry, bathtime
<axw> babbageclunk: oh, all clean now? ;)
<babbageclunk> axw: I've done a couple (lxd and ec2)
<babbageclunk> axw: yes thanks!
<axw> babbageclunk: do you know if CI is testing this already? we should make sure it's tested on all the clouds
<babbageclunk> axw: I think veebers has CI for all clouds
<axw> babbageclunk: ok cool
<babbageclunk> axw: I'll confirm with him tomorrow
<wallyworld> axw: release notes look ok, they can tidy formatting. i've pushed changes also. got to rush to school pickuo, bbiab
<axw> wallyworld: thanks. looking
<wallyworld> axw: thanks for review. i didn't see the harm in users reading the public bit of the system key?
<axw> wallyworld: that's the existing behaviour. I don't have a sproblem with us changing it in this case, but I want to know that it's intentional and tested
<jam> wallyworld: thumper: I'm trying to reconcile 2.1 vs develop
<jam> it looks like thumper added a signature to stateForRequestAuthenticade to return a "releaser" funct
<jam> but wallyworld added a modelRestHandler.stateAuthFunc
<wallyworld> axw: ok, best to stick with existing behaviour. i was being strict about that for write
<jam> wallyworld: but modelRestHandler.stateAuthFunc is never called
<jam> it has a hard-conded stateForRequestAuthenticated in ServeGet
<axw> wallyworld: SGTM
<wallyworld> jam: i'll have a look, give me a few minutes
<jam> wallyworld: k
<jam> I'm trying to get my fixes in 2.1 into 2.2, and bringing some of Tim's along for the ride.
<jam> wallyworld: ping me when you're available so I can go through it with you
<wallyworld> ok
<axw> wallyworld jam: I just noticed that the version was already bumped to 2.1.0. did we already cut a release? stuff landed today won't make it?
<wallyworld> axw: they did that in preparation
<jam> axw: i don't know. I just saw the version bump myself.
<jam> wallyworld: but wouldn't it be 2.1rc1 ?
<wallyworld> the rc will have 2.1.0 as thge version
<wallyworld> i would have thought so
<wallyworld> bu tthey want to take the binary and release unchanged as final
<wallyworld> i don't agree with that myself
<wallyworld> what if we need a rc2
<axw> that sounds crack
<wallyworld> yep
<wallyworld> jam: free to talk now
<jam> wallyworld: HO or IRC?
<wallyworld> HO easier, standup one?]
<anastasiamac> wallyworld: axw: jam: earlier conv with sinzui re:version https://pastebin.canonical.com/178735/
<anastasiamac> wallyworld: u were in the release call, if u disagreed, it'd b more constructive to have do so there
<wallyworld> anastasiamac: i tried to but the call ended
<anastasiamac> wallyworld: call ppl back :D
<wallyworld> honestly, the proposal is crack, john will send an email to get it fixed
<anastasiamac> jam: axw: for reference not a new issue. we hit it at every release
<wallyworld> anastasiamac: not any more
<wallyworld> the only juju versions that had issues were < 1.20
<jam> needing to set agent-streams=devel seems better than not being able to make an rc2, or have a 2.1.0 final that can identify itself as different.
<wallyworld> we don't support those any more
<jam> wallyworld: well, we'd have to actually test that 1.25 doesn't crap itself with 'rc' in the proposed stream
<wallyworld> it doesn't
<wallyworld> that was fixed for 1.20
<wallyworld> or 1.19 even
<anastasiamac> wallyworld: jam: great discussion to have with release team \o/
<wallyworld> we shouldn't need to - the policy is clear
<anastasiamac> who r coming online *shortly*
<wallyworld> this change was done on a whime
<anastasiamac> wallyworld: obviously not if they made a request and approved it
<wallyworld> as can be seen from all the wtf
<wallyworld> it wasn't approved
<wallyworld> not by us
<wallyworld> and there was nothing in writing etc
<anastasiamac> it was done on request from sinzui directly
<wallyworld> if it were approved tim, andrew, john and i would not be going etf etf
<wallyworld> *wtf
<anastasiamac> nothing inwritng, except in releas call minutes... did u need it in blood?
<wallyworld> for such a major change to policy, it needs proper discussion, not a btw at the end of the release call
<anastasiamac> it was not at the end
<anastasiamac> anyway, nothing was released yet and now is ur chance to fix
<wallyworld> yep, that is good
<wallyworld> jam will follow up
<anastasiamac> obviously, communication failure since 1.20
<wallyworld> don't buy that
<anastasiamac> what do u ever?
<wallyworld> axw: i'm having trouble booting lxd. i've cleared ~/.config/lxc and there's nothing in credentials.yaml..... but at end of bootstrap
<wallyworld> 2017-02-09 07:27:51 INFO juju.cmd supercommand.go:63 running jujud [2.1.0.1 gc go1.6.3]
<wallyworld> 2017-02-09 07:27:51 ERROR cmd supercommand.go:458 new environ: Get https://10.132.22.1:8443/1.0: x509: certificate signed by unknown authority (possibly because of "crypto/rsa: verification error" while trying to verify candidate authority certificate "root@wallyworld")
<wallyworld> this is on 2.1 branch
<wallyworld> i'll dig in a bit after soccer, not sure if you've seen that issue
<axw> wallyworld: ehhh? I have not seen that, no
<wallyworld> yeah weird
<wallyworld> i did apt remove and then apt install lxd yesterday
<wallyworld> to test a snap issue
<wallyworld> maybe time for lxd init again
<axw> wallyworld: oh, you probably need to remove any credentials you have stored for lxd in credentials.yaml then
<wallyworld> axw: yeah i checked, none there
<axw> hm, dunno then
<wallyworld> yeah, me either
<axw> wallyworld: did you see that I reviewed your PR?
<axw> ah, soccer
<balloons> redir, not sure what the thought is on pushing PR's against 2.1 and develop. But here's one if you don't mind having a look: https://github.com/juju/juju/pull/6956 and https://github.com/juju/juju/pull/6957
<redir> balloons: looking
<redir> balloons: I don't know about 2.1
<redir> develop LGTM though.
<balloons> redir, as in, you don't know if they want things to land or ?
<redir> balloons: correct
<balloons> ahh. I want it to land in 2.1 to help us toward that bless :-)
<redir> OK.
<redir> shipit
<redir> just saying I don't know, but some blesses would be greatly celebrated I'm sure:)
<balloons> redir, lol.. :-) Ok,
<redir> Looks great to me balloons
<redir> another easy review; https://github.com/juju/juju/pull/6958
<redir> anyone ^^
<redir> juju-dev ^^
<babbageclunk> redir: yay, easy review! Looking!
<babbageclunk> redir: this doesn't sound that easy
<redir> hehe it's small
<babbageclunk> redir: LGTM'd
<redir> babbageclunk: tx
<babbageclunk> redir: also I'm OCR for me, but not for your timezone
 * redir blinks
<redir> thanks for the review in my timezone:)
<babbageclunk> redir: :)
<alexisb> anastasiamac, ping
<anastasiamac> alexisb: pong
<thumper> babbageclunk: https://github.com/juju/juju/pull/6959
<babbageclunk> thumper: reviewed - lgtm
<babbageclunk> special OCR deal today - any PR that's more deletions than additions is auto-approved!
<babbageclunk> (offer not valid where void)
<babbageclunk> I mean, offer void where prohibited
<thumper> :)
<axw> thumper: there is quite a lot of awesome for such a small amount of code with custom pprof profiles :)
<thumper> axw: yeah
<thumper> when I realised that we needed to hook into close and not use a finalizer
<thumper> it made sense to go with pprof
<thumper> so nice to look at too
<thumper> and less things to hook up
<thumper> thanks for pointing that out to me
<thumper> it's good
<axw> thumper: does the tool just work? i.e. can you use go tool pprof --svg ?
<axw> thumper: no worries
<thumper> haven't tried that actually
<redir> babbageclunk: this should look familiar: https://github.com/juju/juju/pull/6960
<babbageclunk> redir: looking
<babbageclunk> redir: net negative lines! Approved!
<babbageclunk> redir: Also a legitimate change.
<axw> anastasiamac thumper: standup?
<babbageclunk> thumper/axw: review this? https://github.com/juju/juju/pull/6961
<babbageclunk> unfortunately adds lines.
<axw> babbageclunk: will do after standup, maybe after taking kids to school
#juju-dev 2017-02-10
<babbageclunk> axw: hold off - it turns out you can't sent ProvisioningState in the update - trying out my fix for the fix now.
<axw> babbageclunk: ok
<axw> let me know when
<wallyworld> axw: you free to catch up now?
<axw> wallyworld: sure
<axw> babbageclunk: I see you pushed an update, ready for review now?
<babbageclunk> axw: I think so - doing one last test now
<babbageclunk> axw: (sorry, went for a run)
<axw> babbageclunk: ok, I'll review optimistically
<babbageclunk> axw: testing looks good
<axw> babbageclunk: LGTM
<babbageclunk> axw: great, thanks
<axw> veebers: is http://people.canonical.com/~leecj2/perfscalemem/ from running perfscale_longrunning.py ?
 * veebers looks
<veebers> axw: yes, from ages ago. (Note, the perfscale tests no longer generate standalone report html pages like the one shown here)
<axw> veebers: ah right that's from october last year :)  ok, thanks
<axw> veebers: are the long running ones not part of normal QA? don't see it on qa.jujucharms.com/perfscale
<axw> normal CI I mean...
<veebers> axw: there are no long running tests that run at the moment. We should be getting something in place in the near future
<veebers> the parts are largely there , just need to set things up
<axw> veebers: okey dokey
 * axw nods
 * menn0 is EOD
<menn0> have a good weekend all
<wallyworld> axw: oh btw, i thought i had, but i hadn't. deleting the certs in ~/.local/share/juju/lxd fixed the issue with certificate validation
<axw> wallyworld: hrm. that's a bit odd. the client should upload them to LXD
<wallyworld> yeah, not sure what's happening there
<axw> wallyworld: will look into it next week
<wallyworld> sure, it appears it's just me anyway
<axw> wallyworld: may well affect anyone that removes/reinstalls LXD though
<wallyworld> i'm also having weird lxd snap issue, so might be related
<axw> hm, ok
<wallyworld> axw: i think this explains things a bit. i juju bootstrapped and the snap lxd was used unexpectedly. http://pastebin.ubuntu.com/23965584/
<wallyworld> not sure what's going on
<wallyworld> the snap juju was also used unexpectedly
<axw> wallyworld: juju was connecting to the wrong lxd?
<wallyworld> axw: that's my guess. but i have NFI why the wrong juju binary s being run
<wallyworld> which juju should indicate what binary is used right
<wallyworld> doesn't seem to be for some reason
<axw> wallyworld: ah, I bet the snapped lxd is being told to run on the same HTTPS port. juju will open the unix socket owned by the non-snapped lxd
<wallyworld> right, but why is the snapped juju being used
<axw> wallyworld: so we'll upload the cert to the non-snapped lxd, then try to connect to the snapped one?
<axw> hrm, doesn't explain why it starts working after removing the certs
<wallyworld> i didn't ask for it and my juju is in the path first
<axw> I don't know
<wallyworld> i'll remove the snap and that will "fix" it
<wallyworld> i'll ask adam and nicolas for advice
<wallyworld> axw: yeah, something is screwed http://pastebin.ubuntu.com/23965626/
<wallyworld> awesome
<axw> jam: I think it might be a bit risky to land this now, but wanted to get it in front of your eyes for review: https://github.com/juju/juju/pull/6962
<jam> axw: reviewed
<axw> jam: thanks. would you like me to change `"bond-" in` to startswith? it did seem odd, but didn't seem worth changing
<anastasiamac_> axw: if it fixes refered bug, why do you think it'd be risky to land it?
<axw> anastasiamac_: there was enough change that it might break something else
<axw> anastasiamac_: but it's rc1 for a reason, to catch bugs
<axw> so landed it
<anastasiamac_> axw: \o/
<anastasiamac_> axw: so shall i move the bug to rc1 milestone and mark at Fix committed?
<anastasiamac_> axw: or is ther more changes anticipated?
<axw> anastasiamac_: I know that it fixes the issue on rackspace, but I don't know about MAAS - and that was the reported one
<axw> anastasiamac_: so without knowing that they're the root cause I can't say that it fixes the issue with any certainty
<anastasiamac_> axw: k, will keep it as is for now
 * axw disappears into the night
<perrito666> morning all
<frobware> last PR for me folks - https://github.com/juju/juju/pull/6963
<perrito666> frobware: it has been a pleasure working with you man
<frobware> perrito666: you too!!!
<rick_h> frobware: <3
<frobware> rick_h: adios dude!
<mup> Bug #1663633 opened: Juju 1.2.10: Conversation scope is missing sometimes - causes relation hook failure <juju-core:New> <https://launchpad.net/bugs/1663633>
<redir> adios frobware
<frobware> redir: adios && take care! Hope all goes well for you over the next few months and enjoy the break before all hell breaks loose. :-D
<redir> frobware: :) you too
<redir> morning juju-dev
<alexisb> morning redir
<redir> alexisb: o/
<perrito666> elho redir
<redir> Â¡Buenas! perrito666
#juju-dev 2017-02-11
<redir> ERROR permission denied (unauthorized access)
 * redir forgot
 * redir eods and see you all on the 22nd
#juju-dev 2017-02-12
<thumper> wallyworld: may be late to standup, got a delivery
<wallyworld> ok
<thumper> all good
<thumper> simple delivery
<axw> anastasiamac: standup?
<axw> menn0: ^
<anastasiamac> axw: m standing
#juju-dev 2018-02-06
<zeestrat> thumper: Regarding your last question in #1746265, it is a blocker as we haven't been able to get our controllers upgraded at all due to hitting this bug in our staging environment after multiple tries in clean environments. I can reproduce it again with some more logging if you'd like, but then I need to know which flags you want.
<mup> Bug #1746265: juju-upgrade from 2.2.9 to 2.3.2 fails with state changing too quickly <upgrade-juju> <juju:Triaged> <juju 2.2:Won't Fix> <juju 2.3:Triaged> <https://launchpad.net/bugs/1746265>
<thumper> zeestrat: every time?
<thumper> FFS
<thumper> zeestrat: which TZ is best for you?
<zeestrat> Unfortunately, yes. After the 3rd try I figured it was better to ask you all.
<zeestrat> I'm CET though I can get in an hour or two during these hours if you give me a heads up which days work for you.
<thumper> zeestrat: I may have to pass this off to someone closer to you
<thumper> zeestrat: he is UTC+4
<zeestrat> thumper: Sure thing. Appreciate any help. Just to confirm, is it alright to wipe the bug environment if it can be reproduced later?
<thumper> zeestrat: yep
<thumper> all good
<zeestrat> thumper: Great. Got some nasty OpenStack bugs to nail. Thanks again.
#juju-dev 2018-02-08
<jam> zeestrat: hi, I'm John from the bug list, and just wanted to reach out about your upgrade issues.
<zeestrat> jam: hey John. Thanks for reaching out. How can I help.
<jam> zeestrat: hi. If you can describe the steps you do to reproduce it, ideally we'd get a local reproduction and then be able to fold it into our ongoing testing infrastructure
<zeestrat> jam: all the steps are in the bug besides the bundle and maas setup. You want those too?
<zeestrat> Hey folks, does juju support upgrading straight from 2.1.2 to 2.3.2 by setting --agent-version, or does it only support step-wise upgrades such as 2.1.2 -> 2.2.x -> 2.3.x?
<rick_h> zeestrat: go in one jump
<zeestrat> rick_h: Thanks. Not working too great here in staging on MAAS and LXD when upgrading HA controllers. Let me do my homework and make sure I can reproduce it before I bother y'all more.
<rick_h> zeestrat: ok, yea let us know. I know we agreed long ago that going step by step was madness
<zeestrat> rick_h: Cool. Nice opportunity to test out that snippet of yours to build 2.1.2 :)
<rick_h> zeestrat: :) but also might try that snap route cory_fu mentioned at the end there
<rick_h> might be fewer steps but haven't tried it yet
<zeestrat> Yeah, that sounded very nice.
<ryebot> hml expected to be around today?
<ryebot> hml o/
<ryebot> thanks for your help yesterday
<hml> ryebot: so it worked?
<ryebot> hml partly! 2.3.1 controller was part of my problem
<ryebot> I can get packages to work now :)
<ryebot> here's what I'm hitting now: https://gist.github.com/wwwtyro/6afde641c5c3db038b6b28106345251a
<hml> ryebot: iâll have to double check and maybe adjust some data, i thought that all of the code was in 2.3.1
<ryebot> hml: sounds good; packages was just a test for me though, if that makes a difference. What I'm really driving towards is ca-certs.
<hml> ryebot: hmmâ¦
<hml> ryebot: can you ssh to the machine?
<ryebot> hml the one stuck in pending?
<ryebot> hml or the controller?
<hml> ryebot: brain fart, sorry, i doubt itâs up.
<ryebot> np
<hml> ryebot: let me look at something.
<ryebot> hml great, thanks!
<hml> ryebot: i had a heck of a time getting the darn yaml files correct when working on this.  :-/
<ryebot> hml: yeah, I'm hoping I'm just getting the yaml wrong. it does seem pretty persnickety.
<hml> ryebot: trying to reproduce, youâre at juju 2.3.2 and the new machines are using xenial correct?
<ryebot> hml: yes
<hml> ryebot: I was able to reproduce, now to find out why :-)
<ryebot> hml: awesome thankyou. if it's the yaml, let's fork juju and do everything in http://haml.info :D
<hml> ha
<hml> ryebot: part of the challenge here, is that weâre reading the yaml is as a string, then converting to yaml later.
<ryebot> alright
<ryebot> hml: if it helps, here's one way I validated that yaml: https://gist.github.com/wwwtyro/38a5d94179fa31fd2c54a54f652260c2
<hml> ryebot: I think I have the config.yaml correctâ¦ but something isnât working as expected
<ryebot> hml: I hear you. really glad I don't have to deal with yaml and a static language!
 * ryebot shivers
<hml> ryebot: small progress, https://paste.ubuntu.com/26542164/, this at least gets by the EOF failureâ¦ but the write_files doesnât happenâ¦ not sure about the ca-certs, though both end up in ls /var/lib/cloud/instance/user-data.txt.i
<ryebot> \o/
<hml> ryebot: the two packages do get installed, so half battle perhaps?
<hml> Dmitrii-Sh: ping
<Dmitrii-Sh> hml: 1
<ryebot> hml yeah this looks promising :)
<hml> Dmitrii-Sh: have you had good luck formating the config.yaml for cloudinit-userdata?  ryebot  is having fun trying to get ca-certs formatted for that model-config var
<Dmitrii-Sh> cat userdata.yaml
<Dmitrii-Sh> cloudinit-userdata: |
<Dmitrii-Sh>   apt_proxy: http://10.10.10.88:3128
<Dmitrii-Sh> juju model-config userdata.yaml
<Dmitrii-Sh> it works like that
<Dmitrii-Sh> as a PoC
<Dmitrii-Sh> haven't tried certs though
<hml> Dmitrii-Sh: weâve gotten a few easy things working, but ca-certs were giving and EOF
<hml> and wouldnât provision
<Dmitrii-Sh> hmm, let me check some yaml example I had for bundles
<Dmitrii-Sh> https://gist.github.com/dshcherb/a5f8dd27af74b38d483c1715994caed3
<hml> Dmitrii-Sh: i think the challenge is formatting the yaml such that juju can read as a string, then, spit back out as yaml
<Dmitrii-Sh> hml: try the install-keys example from the gist above
<hml> Dmitrii-Sh: that doesnât work,
<Dmitrii-Sh> hml: hmm
<Dmitrii-Sh> hml: could also try
<Dmitrii-Sh> https://www.irccloud.com/pastebin/Rf96y0FC/
<hml> Dmitrii-Sh:  the contents of cloudinit-userdata isnât real yaml to juju, itâs a stringâ¦.
<Dmitrii-Sh> hml: this should be treated as a multi-line string
<Dmitrii-Sh> well, at least by a yaml parser
<hml> Dmitrii-Sh: thatâs the problem, itâs not seen by a yaml parser first
<hml> Dmitrii-Sh: I got it to work by adding a | to âvariables: |â
<hml> Dmitrii-Sh: where can i verify the installed key on the new machine?
<Dmitrii-Sh> hml: just a CA cert or a gpg key?
<hml> gpg key?
<Dmitrii-Sh> for packages
<Dmitrii-Sh> I think you are talking about ca certs though
<Dmitrii-Sh> I'll create a gist
<hml> what ever was done by adding the variable: thing   :-)
<Dmitrii-Sh> ah, wait
<Dmitrii-Sh> hml: let me give you a better example
<Dmitrii-Sh> those were not for cloud-init - just yaml examples with complex content
<Dmitrii-Sh> hml: https://gist.github.com/dshcherb/c03d080f9f721d16050a65210f3a05e2 - first, this
<Dmitrii-Sh> hml: /etc/ssl/certs mainly
<hml> Dmitrii-Sh: k - thx
<Dmitrii-Sh> hml: http://cloudinit.readthedocs.io/en/latest/topics/examples.html#configure-an-instances-trusted-ca-certificates
<Dmitrii-Sh> and this is for ca certs
<Dmitrii-Sh> hml: another example is pgp keys for apt packages: http://cloudinit.readthedocs.io/en/latest/topics/modules.html http://cloudinit.readthedocs.io/en/latest/topics/examples.html?highlight=pgp#install-and-run-chef-recipes
<ryebot> hml I'm starting to suspect some copy paste character encoding mistake on my part
<ryebot> I have what appears to be two identical bodies of text, one works and one doesn't
<ryebot> still investigating
<hml> ryebot: itâs tricky
<hml> ryebot: we may be able to make it simplier in the near future
<Dmitrii-Sh> hml, ryebot: I think it's safe to assume that we need to treat this option as yaml, parse it, do a transformation for pre- and post- and then render that as yaml again
<Dmitrii-Sh> that way we can also validate that this is valid yaml
<ryebot> hml ah, here's the diff between yours and mine: line 10 from your paste has a | that maybe shouldn't be there?
<hml> ryebot: i think it has to beâ¦
<hml> ryebot: but try without.
<hml> Dmitrii-Sh: itâs yaml, but that yaml must be read as a stringâ¦. no so straight forward
<ryebot> hml I did, which is when I get the eof - wait, are you saying ca-certs is also a string that is converted to yaml?
<ryebot> ahhhh
<ryebot> sorry, a little slow on the uptake there
<ryebot> okay, I think I finally get this :)
<hml> ryebot: everything after âcloudinit-userdata:â Is read as a string, that we parse to yaml
<hml> itâs confusing,
<hml> so some yaml works, some doesnât depending on whether juju canât read it all as 1 string
<hml> a pita
<Dmitrii-Sh> hml: ah, right. So if you have config.yaml that option is then nested yaml
<Dmitrii-Sh> read config.yaml, parse it, read that option, parse it as yaml
<ryebot> except for some, like packages, which is processed elsewhere?
<hml> Dmitrii-Sh: yes - though everything after the key is read as a stringâ¦. not yaml, itâs a string thatâs parsed to yaml later
<Dmitrii-Sh> hml: I think I used it somewhere like that
<Dmitrii-Sh> well, in LXD
<Dmitrii-Sh> for user-data it's the same problem
<hml> ryebot: not sure what youâre asking
<ryebot> hml for example in your paste, packages is presented as a raw list (it's not packages: |)
<Dmitrii-Sh> here's an example of nested yaml, albeit simple https://dshcherb.github.io/2017/12/04/qemu-kvm-virtual-machines-in-unprivileged-lxd.html#breaking-ground
<Dmitrii-Sh> user.user-data option
<hml> ryebot: iâm not sure why it works, but it doesâ¦ from packages to the end of the file is read as 1 string
<hml> ryebot: the glories of yaml perhaps?  :-)
<ryebot> hahaha
<ryebot> alright, I'm gonna try again with this new information - thanks!
<ryebot> hml: https://paste.ubuntu.com/26542336/ line 23, gets passed in as a string and not yaml
<ryebot> results in traceback on line 630 here: https://paste.ubuntu.com/26542344/
 * ryebot snaps fingers
<hml> ryebot: thereâs a trick to using the pipe, iâm just not sure of the rules
<ryebot> hml: I think I'm going to throw in the towel for now. I've opened a bug here: https://bugs.launchpad.net/juju/+bug/1748283
<mup> Bug #1748283: Unable to pass ca-certs field in cloudinit-userdata model config <juju:New> <https://launchpad.net/bugs/1748283>
<ryebot> hml: thanks for looking at that with me!
<hml> ryebot: k
<thumper> morning
<thumper> hml: wanna chat about that?
<thumper> hml: there is a function we probably need to use :)
<hml> thumper: sure
<thumper> hml: 1:1 HO
<hml> thumper: omw
<zeestrat> rick_h: here's that upgrade issue in case you'd like to give it a spin yourself. #1748294
<mup> Bug #1748294: juju-upgrade from 2.1.2 to 2.3.2 fails <juju:New> <https://launchpad.net/bugs/1748294>
<hml> thumper: you called it, ConformYAML did it - and ca-certs were good on the other end too .  TY.  :-)
<thumper> sweet
<hml> small PR review anyone?  https://github.com/juju/juju/pull/8354
#juju-dev 2018-02-09
<anastasiamac> thumper: https://github.com/juju/juju/pull/8350
<ejat> hi
<ejat> <ejat> anyone can help me with this : https://paste.ubuntu.com/26543884/
<ejat> <ejat> is it related to this : https://bugs.launchpad.net/charm-ceph-osd/+bug/1731639
<mup> Bug #1731639: get_partition_list fails <OpenStack ceph-osd charm:Triaged> <charms.ceph:Fix Released by james-page> <https://launchpad.net/bugs/1731639>
<thumper> it appears that things aren't as bad as I thought
<anastasiamac> thumper: \o/ great thought for friday
<thumper> we are broken from 2.1.2 -> 2.3.2 though
<anastasiamac> thumper: my day is getting not so great as m not sure where to display this spaces info now in a sensible manner... mayb somethign will come to me over the wekend ... do we have good reasons for not having 'show-application' command, btw?
<thumper> no, probably no good reason
<thumper> just no need... so far
<anastasiamac> thumper: ha :) i have just discovered the need then :) but will talk more about it next week....
<wallyworld> thumper: just saw the bug update, so 2.2.x -> 2.3.x works? that would have been what was tested in CI etc hence it all seemed ok. it becomes a matter of how far back do we test
<thumper> yeah...
<wallyworld> 2.1 is quite old, may be out of the support window? not sure
<thumper> but also, we need to take more care when updating state functions that are used for upgrade steps
<wallyworld> ideally it would just work, but maybe theres a case for old versions to step through
<wallyworld> that too yeah
<wallyworld> it's not always obvious
<wallyworld> as it maybe a transitive thing
<thumper> anyone... https://github.com/juju/juju/pull/8356
<wallyworld> thumper: lgtm, ty
<wallyworld_> anastasiamac: hey, can haz review? https://github.com/juju/juju/pull/8357
<wallyworld_> no one else around to ask - normally andrew is here :-(
 * anastasiamac looking
<anastasiamac> :(
<zeestrat> thumper: am I reading you right on that last upgrade bug that upgrading via 2.3.0 should work or do I need some more coffee?
<wallyworld_> anastasiamac: thank you
<anastasiamac> \o/
<wallyworld_> zeestrat: i think you need to upgrade via 2.2.x first
<wallyworld_> is my understanding
<wallyworld_> and then once you're on 2.2.x you can go to 2.3.x
<wallyworld_> but that assumes everything in the db is valid which may not be the case if some agents got stuck and wrote old data
<wallyworld_> i'm not fully across the issue, just recounting what i know of it
<zeestrat> Well that's not working so great. (Not nagging, just looking for all exit strategies) #1746265
<mup> Bug #1746265: juju-upgrade from 2.2.9 to 2.3.2 fails with state changing too quickly <upgrade-juju> <juju:Triaged> <juju 2.2:Won't Fix> <juju 2.3:Triaged> <https://launchpad.net/bugs/1746265>
<wallyworld_> zeestrat: yeah, i'll have to catch up with tim to see where things are at with that one. i know people are looking at it
<anastasiamac> wallyworld_: could u PTAL https://github.com/juju/juju/pull/8358 for the reasons u've stated :)
<ktcharlie> ââââââââââ  âââââââ   âââââââââââ   ââââââââââ âââââââââââââââ ââââ   ââââââââââââââââââââââââââââ    âââââââ âââââââ  âââââââ
<ktcharlie> ââââââââââ  âââââââ   âââââââââââ   ââââââââââ âââââââââââââââ ââââ   ââââââââââââââââââââââââââââ    âââââââ âââââââ  âââââââ
<ktcharlie> âââââââââââââââââââ   âââââââââââ   ââââââââââââââââââââââââââââââââ  ââââââââââââââââââââââââââââ   âââââââââââââââââââââââââ
<ktcharlie> âââââââââââââââââââ   âââââââââââ   ââââââââââââââââââââââââââââââââ  ââââââââââââââââââââââââââââ   âââââââââââââââââââââââââ
<ktcharlie> ââââââââââââââ        âââââââââââ   âââââââââââââââââ  ââââââââââââââ âââââââââ     âââ   ââââââââ   âââ   ââââââââââââââ  ââââ
<ktcharlie> ââââââââââââââ        âââââââââââ   âââââââââââââââââ  ââââââââââââââ âââââââââ     âââ   ââââââââ   âââ   ââââââââââââââ  ââââ
<ktcharlie> ââââââââââââââ        âââââââââââ   ââââââââââ ââââââ  ââââââââââââââââââââââââ     âââ   ââââââââ   âââ   ââââââââââââââ   âââ
<ktcharlie> ââââââââââââââ        âââââââââââ   ââââââââââ ââââââ  ââââââââââââââââââââââââ     âââ   ââââââââ   âââ   ââââââââââââââ   âââ
<ktcharlie> ââââââ  ââââââââââââââââââââââââââââââââââ     âââââââââââ  ââââââ ââââââââââââââ   âââ   âââââââââââââââââââââââ  ââââââââââââ
<ktcharlie> ââââââ  ââââââââââââââââââââââââââââââââââ     âââââââââââ  ââââââ ââââââââââââââ   âââ   âââââââââââââââââââââââ  ââââââââââââ
<ktcharlie> ââââââ  âââ ââââââââââââââââââ âââââââ âââ     âââââââââââ  ââââââ  âââââââââââââ   âââ   âââââââââââ âââââââ âââ  âââ âââââââ
<ktcharlie> ââââââ  âââ ââââââââââââââââââ âââââââ âââ     âââââââââââ  ââââââ  âââââââââââââ   âââ   âââââââââââ âââââââ âââ  âââ âââââââ
<ktcharlie> mattyw_ Spads kjackal akhavr junaidali wallyworld_ blahdeblah thumper mpontillo ryebot cory_fu jog_ niemeyer rogpeppe1 LiftedKilt mup tvansteenburgh tinwood mhorlanchuk babbageclunk beisner icey redir higgins admcleod jcsackett elmo jam aluria anthonyf petevg ejat freyes wpk chrome0 cassiocassio
<ktcharlie> D m i t r i i - S h   r i c k _ h   j a m e s p a g e   v e r n   d p b 1   k j a c k a l _ b o t   r h a r p e r   f r a n k b a n   c h a o l o g y   m e e t i n g o l o g y   a x i n o   j o s e   M a k y o   a i s r a e l   b o g d a n t e l e a g a   c o r e y c b   O d d _ B l o k e   p j d c
<hml> ryebot: ping
<ryebot> hml: o/
<hml> ryebot: i useded the cloud.yaml from the bug - works as is - no funny string stuff
<ryebot> hml: Yeah I was following your progress, thanks for fixing that so quickly :)
<hml> ryebot: thumper pointed me in the correct direction, so it was easy  :-)  he hit something similar recently
<ryebot> hml: dynamic data structures in statically typed languages are no joke!
<hml> ryebot: the problem was related to sending the complex data structure over the apiserver
<hml> ryebot: you can try it out with either the candidate or edge juju snap
<hml> ryebot: wait a few hours for the edge version
<ryebot> hml: awesome, I'll probably give it a shot monday morning and let you know how it pans out
<hml> ryebot: sounds good
<ryebot> thanks again :)
