[00:00] <davecheney> all: master is not passing the tests for me
[00:00] <davecheney> uniter, api client, worker/uniter
[00:00] <davecheney> all fail
[00:00] <perrito666> anastasiamac: I actually added anothe rcomment but apparently did not go trough reviewboard
[00:01] <perrito666> anastasiamac: try to change the uses of fmt.Errorf for errors.Annotate
[00:02] <anastasiamac> perrito666:of course! thnx :-) will do
[00:03] <anastasiamac> perrito666: constructive suggestions r an amazing feedback, especially atm ;-)
[00:04] <anastasiamac> perrito666: english hard atm too...
[00:06] <perrito666> anastasiamac: I am south american I am certainly in no position to criticize anyone's english
[00:08] <anastasiamac> perrito666: :-)
[00:22] <thumper> davecheney: master as of 9am this morning passed for me
[00:22] <thumper> davecheney: what is your last commit?
[00:23] <davecheney> thumper: i just pulled master
[00:23] <davecheney> i was trying to get my branch up to date and the tests were all failing
[00:23] <davecheney> so i switch to master
[00:23] <davecheney> and they are still failing
[00:23] <thumper> davecheney: let me try
[00:24] <thumper> davecheney: running now
[00:29] <davecheney> thumper: eg, http://paste.ubuntu.com/8726080/
[00:30] <davecheney> http://paste.ubuntu.com/8726089/
[00:31] <thumper> works here
[00:32] <thumper> smells of timing issue
[00:32] <davecheney> well shit
[00:32] <davecheney> ok, i'll break out my tools
[00:33] <davecheney> oh hang on
[00:33] <davecheney> these are the actions
[00:33] <davecheney> tests
[00:33] <davecheney> i raised bugs about this before
[00:34] <thumper> I thought this was parallel charm upload?
[00:35] <davecheney> thumper: what rev of charm.v2 do you have ?
[00:35] <davecheney> i don't trust godeps any more
[00:35] <thumper> um...
[00:35] <thumper> it should be charm.v4
[00:35] <thumper> I think
[00:36]  * thumper looks
[00:36] <waigani> menn0_: added another step for the migrations. state/watcher.go update <coll>Watcher.merge() - change.Id -> localID
[00:36] <thumper> davecheney: yeah, I'm using charm.v4
[00:36] <davecheney> thumper: can you tell me the exact rev
[00:36] <bigjools> hey axw, can you remind me what causes juju to try and release twice when bootstrap goes awry?
[00:36] <waigani> menn0_: I think that one is a bug that will bite a few more times
[00:36] <davecheney> charm.v4, for all of the promise of gopkg.in
[00:37] <davecheney> doesn't ensure we're running the same code
[00:37] <menn0_> waigani: yeah, that's one that I catch while looking for transactions that touch the collection, but it's good to mention it explicitly
[00:38] <thumper> davecheney: 8b3cc836f54c2c78ce73d198100a30bb31d28392
[00:38] <thumper> davecheney: I have godeps working fine
[00:38] <davecheney> same
[00:38] <davecheney> ok
[00:38] <davecheney> scratch that
[00:39] <davecheney> thumper: could you run
[00:39] <thumper> davecheney: if you have "export JUJU_MAKE_GODEPS=true" and use "make check"
[00:39] <davecheney> thumper: i don't trust godeps
[00:39] <thumper> it makes sure your deps are up to date and runs the tests
[00:39] <davecheney> i know how to run the command
[00:39] <waigani> menn0_: yeah, saves some brain power. the change.Id being passed in will always be a DocID but needs to be a localID. I misunderstood that during the transaction sweep.
[00:39] <davecheney> i just don't trust it to work
[00:39] <davecheney> thumper: can you please try
[00:39] <thumper> it fails for me when I have different origins and upstreams
[00:39] <davecheney> env GOMAXPROCS=42 go test github.com/juju/juju/api/uniter
[00:39] <thumper> so I have to fetch upstream manually
[00:39] <thumper> davecheney: sure
[00:41] <thumper> davecheney: test passed here
[00:44] <menn0_> waigani, thumper: i'm currently trying to figure out a regression with the relation/relationscopes branch.
[00:44] <waigani> menn0_: want to pair?
[00:45] <menn0_> waigani: not at this stage thanks
[00:45] <menn0> waigani: I'm slowly making progress
[00:46] <waigani> menn0: cool. If you need a rubber duck let me know
[00:46] <menn0> waigani, thumper: when I destroy a service some relations aren't being deleted
[00:46] <menn0> waigani, thumper: i'll get there but it's painful
[00:47] <waigani> menn0: makes sense if it's looking for the wrong id right?
[00:47] <thumper> menn0: hmm... interesting
[00:47] <menn0> waigani: yes. i'm sure it's something like that but it's not obvious. it could be a watcher problem.
[00:48] <menn0> it only seems to affect subordinate relations AFAICT
[00:48] <waigani> menn0: checked the merge func? ;)
[00:49] <menn0> waigani: no but I think I just found it. missed a change in WatchRelations
[00:49] <waigani> nice
[00:50] <menn0> stupid prefix matching crap
[00:50] <waigani> ah right
[00:58]  * thumper heads off to see specialist
[00:58] <thumper> bbl
[01:01] <menn0> waigani: the unit tests didn't notice by fluke
[01:01] <menn0> waigani: with an _id like this "60d7b1b0-4fea-452f-8748-70c05cf489ec:wp0:db mysql:server"
[01:02] <menn0> waigani: WatchRelations was matching on _ids starting with "mysql:" or containing " mysql:"
[01:02] <axw> bigjools: if bootstrap fails after acquiring, it'll release the bootstrap node; juju will then destroy the environment. whether it releases again depends on whether it's possible for MAAS to report that the bootstrap node still has the agent_name we gave it
[01:02] <waigani> ah fuck
[01:02] <axw> bigjools: now that I write that out in full, it probably never happens
[01:03] <waigani> menn0: is it a regex match?
[01:03] <menn0> waigani: it just happened to always match with the "containing" case in the test but the prefix match is no longer correct
[01:03] <bigjools> axw: heh, ok :)
[01:03] <menn0> waigani: no just a simple bit of string matching
[01:03] <menn0> waigani: I'll update the test and then fix
[01:03] <bigjools> axw: it's just that we have observed this behaviour but now we can't make it happen again
[01:03] <menn0> waigani: it's a bit of a fluke that I found it
[01:04] <menn0> waigani: which is worrying
[01:04] <bigjools> axw: in here: https://bugs.launchpad.net/maas/+bug/1386327
[01:04] <mup> Bug #1386327: Juju fails to destroy-environment with wipe enabled: Node cannot be released in its current state ('Disk erasing'). <MAAS:Incomplete> <https://launchpad.net/bugs/1386327>
[01:04] <waigani> menn0: might be worth while searching all the transactions
[01:04] <axw> bigjools: if the first release failed, then it would attempt again (just the once)
[01:04] <waigani> menn0: or at least adding it to the doc for something to check
[01:04] <bigjools> axw: right
[01:04] <menn0> waigani: yeah, I'll add it to the doc
[01:04] <waigani> MESS doc that is
[01:05] <waigani> menn0: you drew the short straw on that one
[01:06] <waigani> but good you spotted the problem, we can now keep an eye out for it
[01:06] <axw> bigjools: is it possible for release to return before agent_name is removed from a node?
[01:06] <bigjools> axw: yes
[01:07] <bigjools> in the bug, it has to wipe the disk before it returns, so sits (internally) at a different state.  The extra state is swallowed in the API to avoid confusing unaware API clients
[01:07] <waigani> menn0: how did you notice relations were left behind after a service was destroyed?
[01:07] <bigjools> axw: so you end up seeing what looks like a node that didn't start releasing, but it really is
[01:08] <menn0> waigani: the service wasn't completely being removed
[01:09] <menn0> waigani: the units and machines were but the service was being left behind in a Dying state with one relation intact
[01:10] <menn0> waigani: I've just updated the manual test instructions to include testing of service removal
[01:10] <waigani> menn0: ah right, fair call
[01:17] <davecheney> thumper: solved it
[01:17] <davecheney> out of date names dependency
[01:17] <davecheney> godeps didn't detect it
[01:22] <waigani> menn0: does mediawiki take ages to install for you?
[01:22] <waigani> it's been sitting on pending for well over 5min
[01:23] <menn0> waigani: I'm not sure exactly how long but that seems on the long side. also depends on you machine and how busy it is of course.
[01:23] <menn0> waigani: or, you've broken something :)
[01:23] <waigani> yeah...
[01:24] <waigani> might be time for a restart
[01:29] <davecheney> ok, now I have some other failing tests
[01:29] <davecheney> christ
[01:43] <perrito666> :| gmail now adds a button "view issue" and "view pull request" on the email list for PRs
[01:43] <perrito666> davecheney: want me to try?
[01:47] <thumper> davecheney: have you updated godeps recently?
[01:50] <perrito666> nite ppl
[01:51] <perrito666> thumper: btw, for that heat you wanted, near 30° its 22:51 and has been night for 3hs :p
[01:52] <thumper> perrito666: it is about 15 here
[01:52] <waigani> and has been day for more hours
[01:54] <menn0> waigani: I'm adding State.strictLocalID as part of this
[01:54] <menn0> it's like localID() but errors if the prefix isn't there
[01:55] <waigani> menn0: okay...
[01:55] <waigani> menn0: used when we assume the id passed in is a DocID
[01:56] <menn0> waigani: it's useful in cases where ids for multiple envs could be seen but you just want to deal with the ones for the State's environment
[01:56] <menn0> waigani: for example in the watchers
[01:57] <waigani> menn0: oh I see
[01:57] <menn0> waigani: i'll push this branch soon so you can see
[02:14] <thumper> arse
[02:14]  * thumper needs git help
[02:14] <thumper> menn0: around?
[02:15] <menn0> thumper: yep
[02:15] <rick_h_> thumper: what'd you break?
[02:15] <thumper> my branch
[02:15] <rick_h_> stop doing that :P
[02:15] <thumper> my branch was 5 commits behind master
[02:15] <thumper> and I did "git reset master" without "git merge master"
[02:15] <thumper> and now I have a bunch of changes I didn't make
[02:16] <thumper> was trying the other rebase options
[02:16] <thumper> forgot it only really works when you have all of the master revisions
[02:16] <thumper> bugger
[02:16] <thumper> so I have some dangling head somewhere
[02:16] <thumper> that I want back
[02:16] <thumper> as the tip of the branch
[02:16] <thumper> how do I find it?
[02:16]  * menn0 googles
[02:17] <rick_h_> oops
[02:17] <rick_h_> trying to think if you can get it without reflog'ing it
[02:17] <rick_h_> reset's not something I ever do except for git reset --hard HEAD when I want to really kill some work
[02:18] <rick_h_> thumper: highly recommend https://github.com/juju/juju-gui/blob/develop/HACKING.rst#syncing-your-feature-branch-with-develop-trunk for the whole 'sync with master to my feature branch' just s/develop/master for your use.
[02:18] <thumper> I blame menn0
[02:18] <rick_h_> hah
[02:18] <rick_h_> good call, find a scape goat
[02:18] <thumper> I'm just going to revert everything I know isn't mine
[02:19] <thumper> i looks like it will be quicker
[02:19] <menn0> thumper: i'm not sure why I get the blame. I don't think I encouraged you to use reset did I?
[02:19] <thumper> menn0: if you had never mentioned reset, I'd still be happily rebasing :P
[02:19] <thumper> menn0: and you fit my need of a scapegoat
[02:22] <menn0> thumper: ok, to get back to where you were
[02:22] <menn0> thumper: git reflog | head
[02:22] <thumper> I'm there already
[02:22] <thumper> :)
[02:22] <menn0> thumper: ok
[02:22] <thumper> however...
[02:22] <thumper> for future me
[02:22] <thumper> what does that do?
[02:22] <menn0> thumper: shows you the history of what you've been doing
[02:22] <thumper> ok, I see the commit I care about
[02:22] <menn0> thumper: to recover you find the hash from when you last committed to the branch
[02:22] <menn0> thumper: and then git reset --hard <hash>
[02:23] <thumper> huh
[02:23] <menn0> thumper: I just tried it out to be sure
[02:23] <thumper> is that all?
[02:23] <menn0> thumper: yep
[02:23] <rick_h_> reflog ftw
[02:23] <thumper> ok, will remember that for next time I screw up
[02:23] <menn0> thumper: the thing is that dangling references will eventually get garbage collected by git
[02:23] <menn0> thumper: so you don't want to leave it too long
[02:23] <menn0> thumper: after the screwup to recover
[02:24] <menn0> thumper: this link is helpful: http://effectif.com/git/recovering-lost-git-commits
[02:24]  * thumper bookmarks
[02:24] <menn0> thumper: best quote: "it's like time travel, only cheaper" :)
[02:42] <davecheney> thumper: no i have not updated godeps
[02:42] <davecheney> i think the last time I did was when we were on that sprint in NZ
[02:47] <menn0> waigani, thumper: finally! http://reviews.vapour.ws/r/284/
[02:48] <menn0> waigani: reviewing your charms branch now
[02:48] <waigani> menn0: thanks, I've got minUnits up too
[02:48] <waigani> menn0: let me nut out this problem then I'll get onto your branch
[02:49] <menn0> waigani: np
[02:53] <menn0> waigani: I think we need to a EnvUUID method to state to avoid repeating "st.EnvironTag().Id()" all over the place
[02:53] <waigani> menn0: agreed
[02:57] <ericsnow> menn0: when you get a chance, I'd love to get your feedback on http://reviews.vapour.ws/r/243.
[02:58] <menn0> ericsnow: will do. I had seen that review request - just hadn't gotten there yet.
[02:58] <ericsnow> menn0: no worries, I appreciate your time :)
[03:05] <davecheney> can someone help please
[03:05] <davecheney> http://paste.ubuntu.com/8727429/
[03:05] <davecheney> ^ this goes into stress.bash
[03:06] <davecheney> cd $GOPATH/src/github.com/juju/juju/apiserver/client
[03:06] <davecheney> bash stress.bash
[03:06]  * menn0 will run
[03:06] <davecheney> ta
[03:06] <davecheney> there is a logical race between uploading the charm and whatever the test is doing
[03:10] <menn0> davecheney: it's still running but I see a clientSuite.TestAddCharmConcurrently failure
[03:10] <menn0> davecheney: done now
[03:10] <davecheney> http://paste.ubuntu.com/8727454/
[03:10] <davecheney> failing hiallriously
[03:10] <menn0> davecheney: that's what I see
[03:10] <davecheney> i have anothe rfailure
[03:11] <menn0> davecheney: actually, on closer inspection my failure is different
[03:12] <menn0> davecheney: http://paste.ubuntu.com/8727496/
[03:14] <davecheney> https://bugs.launchpad.net/juju-core/+bug/1386968
[03:14] <mup> Bug #1386968: apiserver/client: clientSuite.TestAddCharmConcurrently failure do to local race <juju-core:New> <https://launchpad.net/bugs/1386968>
[03:16] <waigani> ugh
[03:18] <menn0> ericsnow: ping
[03:19] <ericsnow> menn0: hey
[03:19] <menn0> ericsnow: so doesn't option 2 involve using --oplog
[03:19] <menn0> ericsnow: ?
[03:19] <ericsnow> menn0: yeah
[03:19] <menn0> ericsnow: but it looks like it's not being used when specific dbs are backed up
[03:19] <ericsnow> menn0: correct
[03:20] <menn0> ericsnow: so what's the plan?
[03:20] <ericsnow> menn0: with option 2 we don't dump specific DBs
[03:20] <menn0> ericsnow: ok. so why leave the support in there for backing up individual dbs?
[03:20] <ericsnow> menn0: I'm hopeful that we will be able to stick to option 2
[03:21] <ericsnow> menn0: in case option 2 doesn't pan out :)
[03:21] <menn0> menn0: right. got it.
[03:22] <waigani> menn0: started looking but Bella will be here in 10min, I'll be doing the dad thing
[03:22] <menn0> waigani: np
[03:23] <menn0> waigani: i have an errand to run shortly myself
[03:23] <waigani> menn0: btw cleanup docs has an id type of bson.ObjectId - which screws up our upgrade step assumtions
[03:24] <waigani> menn0: not a huge problem, but I'll have to do some rejigging tomorrow
[03:24] <thumper> owwie...
[03:24]  * thumper goes to lie down
[03:24] <thumper> shoulder is really starting to ache now
[03:24] <menn0> waigani: yeah, I've seen that. let's discuss tomorrow. there's a few ways we could tackle that.
[03:24] <thumper> go an injection in it this afternoon
[03:24] <thumper> hopefully should settle down in the next two weeks
[03:24] <thumper> here's hoping
[03:25] <waigani> menn0: sounds like a plan
[03:26] <menn0> ericsnow: are you sure this branch even compiles?
[03:27] <menn0> ericsnow: mongoDumper.Dump looks incomplete with both unused and undeclared variables
[03:27] <menn0> ericsnow: and mongoDumper.strip() has no code
[03:27] <ericsnow> menn0: yeah, I created the review request thinking I'd wrapped things up
[03:27] <ericsnow> menn0: I have it fixed up and will be updating momentarily
[03:28] <menn0> ericsnow: ok
[03:33] <waigani> menn0: shouldn't we always use strictLocalID unless we have a reason not to?
[03:36] <davecheney> tada, data race http://paste.ubuntu.com/8727559/
[03:37] <davecheney> func (s *MockCharmStore) WithTestMode(testMode bool) charm.Repository { s.TestMode = testMode return s
[03:37] <davecheney> }
[03:37] <davecheney> man
[03:37] <davecheney> we have _SO MANY_ of these races
[03:38] <menn0> :(
[03:40] <davecheney> oh wow
[03:40] <davecheney> that methods is pants on head retarded
[03:40] <davecheney> it doens't return you a _new_ repository with a test flag set
[03:41] <davecheney> it updates the repo that you passed to it ...
[03:41] <davecheney> oh, and fantastic, the callers of that expect this behavior
[03:43] <davecheney> fml, https://bugs.launchpad.net/juju-core/+bug/1386968/comments/2
[03:43] <mup> Bug #1386968: apiserver/client: clientSuite.TestAddCharmConcurrently failure do to local race <juju-core:Confirmed> <https://launchpad.net/bugs/1386968>
[04:04] <ericsnow> menn0: I've updated that patch
[04:04] <ericsnow> menn0: and am signing off
[04:04] <menn0> ericsnow: ok. i'm looking at your other one now
[04:05] <ericsnow> menn0: cool
[04:05] <menn0> ericsnow: I'll try to finish reviewing both
[04:05] <ericsnow> menn0: thanks again
[04:05] <menn0> ericsnow: np.
[04:08] <wallyworld_> axw: i've found a problem with the recent work to validate credentials, and the use of Open vs Prepare - it does break validate-tools
[04:09] <wallyworld_> you want to run validate-tools before deploying an environment
[04:09] <wallyworld_> to see where the tools will come from
[04:09] <wallyworld_> but that's not possible now, since the environment is not prepared, and hence is missing derived attrs
[04:09] <wallyworld_> like control-bucket for ec2
[04:12] <wallyworld_> in any case, control-bucket should now be obsolete for deploying new environments
[04:24] <axw> wallyworld_: yuck, that's a problem. I want to be able to change the manual provider so we can specify the bootstrap host in placement directives, but that involves restricting Prepare to bootstrap
[04:26] <davecheney> menn0: if you read this and are not filled with dredd, http://reviews.vapour.ws/r/286/diff/#
[04:26] <davecheney> let me know
[04:26] <wallyworld_> axw: yeah. the environment is created in order to get parameters specific to the environment to use to search
[04:27] <menn0> davecheney: I have to stop for a bit soon so I won't be able to get to this for a few hours
[04:27] <wallyworld_> axw: given the validation commands are now broken, short term to get alpha3 released, we'll need a fix that works with what we have
[04:28] <wallyworld_> i have not raised a bug yet
[04:28] <davecheney> menn0: that's ok
[04:28] <davecheney> you don't need to review it
[04:28] <axw> wallyworld_: revert to using Prepare for now I guess, will just need to change the metadata tests to set up a mock ec2 endpoint
[04:28] <wallyworld_> axw: will that revert affect the credentials validation
[04:29] <axw> nope
[04:29] <wallyworld_> i can change to using Prepare in my current redo of the tools stream stuff
[04:29] <wallyworld_> i found this issue by testing that work
[04:30] <axw> wallyworld_: if it's not too much hassle. otherwise let me know and I'll fix it
[04:30] <wallyworld_> it's no problem
[04:30] <wallyworld_> i'm in the area anyway
[04:31] <menn0> davecheney: i've just had a quick look and although it's not pretty it does look reasonable
[04:32] <davecheney> hey
[04:32] <davecheney> it's much better
[04:32] <davecheney> the caller doesn't need to remember to defer this magic cleanup function
[04:32] <davecheney> that's something the test suite should do
[04:32] <davecheney> and more improtantly
[04:32] <davecheney> it highlights just how horrible that test is
[04:32] <davecheney> updating a shared mutable package level variable
[04:33] <menn0> davecheney: you know that CleanupSuite (embedded in BaseSuite) already provides something very similar to what you've done with afterFunc?
[04:33] <menn0> davecheney: there's an AddCleanup method
[04:33] <davecheney> menn0: cool
[04:33] <davecheney> i was going to use that
[04:34] <davecheney> but for some reason I thought it was only on the suites that had something to do with mongo
[04:34] <davecheney> i'll fix the patch to use AddCleanup
[04:34] <menn0> davecheney: ok
[04:34] <menn0> davecheney: I'll be back on later but I need to go know
[04:34] <menn0> now
[04:35] <davecheney> thanks for pointing me to the place it lives
[05:05] <wallyworld_> axw: sadly, the metadata commands fail with an access credentials check error - i wonder if the verifyCredentials calls could be moved to Open() instead of Prepare(). I wonder if that's too late in the bootstrap process
[05:22] <axw> wallyworld_: the bug (raised by mark) requested that we do this ASAP in the bootstrap process - and it is kinda necessary to ensure we get the error message early on
[05:22] <axw> wallyworld_: what is going wrong with the metadata commands?
[05:23] <wallyworld_> axw: yeah, i understand the context. the metadata commands can be run without env credentials, so that verify check fails
[05:23] <axw> ah.
[05:23] <wallyworld_> we could add a method to the BootstrapContext
[05:23] <axw> wallyworld_: can we do this some other way? without opening an environment? cos really, we're not exactly opening a fully defined environment
[05:24] <wallyworld_> right now, an env instance is needed to ask for things from
[05:24] <axw> yes... can we change that.
[05:24] <wallyworld_> not that easily, but yes
[05:25] <wallyworld_> because creating an env manipulates config
[05:26] <wallyworld_> i'll have a poke around, but there's potentially a fair bit to unpick
[05:26] <axw> yeah I took a look, doesn't look like something we can do easily
[05:27] <wallyworld_> axw: could add a method to BootstrapContext - ValidateCredentials() bool
[05:27] <wallyworld_> would work for now
[05:28] <wallyworld_> so that we can get alpha3 out
[05:28] <wallyworld_> i also gotta make sync-tools backwards compatible, bit of a pita
[05:29] <axw> wallyworld_: we can make it bootstrap only I suppose, would be nice not to but it'll do for now
[05:29] <wallyworld_> yeah, agreed it's not nice :-(
[05:30] <wallyworld_> i'll try it after fixing sync tools
[05:30] <wallyworld_> lots of touch points there
[07:24] <dimitern> morning all
[07:54] <axw> wallyworld_: FYI I've not sent a PR with my metadata changes yet, because I want to explore the usage of it a bit first. I would like to avoid churning packages
[07:54] <wallyworld_> axw: +1
[07:55] <wallyworld_> axw: i'm almost finished the tools rework, including credentials verification fix. keep getting mongo replicaset errors testing sadly
[07:55] <wallyworld_> timeouts mainly
[08:04] <axw> okey dokey
[08:04] <axw> gotta make dinner shortly, ping when it's ready and I'll take a look
[08:07] <dimitern> wallyworld_, hey
[08:07] <wallyworld_> hi
[08:07] <dimitern> wallyworld_, so re that network-bridge-related bugs
[08:07] <dimitern> wallyworld_, that guy probably misread or misunderstood what the code he pasted does
[08:08] <wallyworld_> likely
[08:08] <wallyworld_> i'm not 100% either
[08:08] <dimitern> wallyworld_, but seeing lxcbr0 in there *at all* is wrong and should be fixed
[08:09] <wallyworld_> dimitern: which bit?
[08:09] <dimitern> wallyworld_, in fact I'm thinking of doing that today, as this is likely the 15th bug report related to that piece of code in the maas provider
[08:09] <fwereade> ok, uniter tests passing again, popping out to shops, bbs
[08:10] <wallyworld_> dimitern: that would be awesome
[08:10] <wallyworld_> i don't know enough about networking
[08:10] <dimitern> wallyworld_, there is some code in there that aims to "restore" /etc/network/interfaces the way they *should* look like in a stock trusty install, but that's really not the point - we shouldn't be using the bridge at all, but first we should respect the network-bridge setting
[08:11] <dimitern> at least
[08:11] <wallyworld_> sounds reasonable
[08:12] <TheMue> morning
[08:12] <dimitern> wallyworld_, cool, thanks
[08:12] <dimitern> TheMue, morning
[08:12] <wallyworld_> dimitern: no, thank you, i have no idea really
[08:14] <dimitern> wallyworld_, well, I have to admit the simple solution of just using "network-bridge" in there as a temporary fix (so at least it's configurable) simply didn't occur to me earlier, and we can't just remove the bridge creation until we've implemented the static ip reservation api maas 1.7 gives us; so tl;dr - thanks for pointing that out :)
[08:15] <wallyworld_> np, it was an educated guess :-)
[08:51] <mattyw> morning all
[09:01] <voidspace> morning all
[09:03] <TheMue> mattyw, voidspace: heya
[09:03] <mattyw> TheMue, morning morning
[09:13] <fwereade> voidspace, would you be free to take a look at a couple of gsamfira's PRs? https://github.com/juju/juju/pull/782 https://github.com/juju/juju/pull/833
[09:13] <fwereade> voidspace, gsamfira: I should be able to get to them later, but I realised I broke something in the uniter and I'm focused on unbreaking it
[09:14] <gsamfira> fwereade: heh, no worries
[09:14] <fwereade> and if anyone *else* is free -- jam, dimitern maybe? -- http://reviews.vapour.ws/r/288/diff/# is the code, on which I'd really a appreciate a logic/style pre-review, but I haven't yet fixed all the tests (sigh)
[09:15] <jam> fwereade: looking
[09:17] <jam> fwereade: is "State().Members" a map and you want the keys to be in the member name slice ?
[09:17] <jam> (I wonder if memberName, _ :=  would be an obvious way to write that)
[09:18] <jam> at least, I first read it as "Members is a slice" and we just want to copy the slice, but then iteration doesn't work like that :)
[09:20] <jam> fwereade: I also thought: "contextRelations := map[int]*ContextRelation{}" was bad form because you end up with a nil map, you actually want make() there, don't you?
[09:21] <jam> hmm. play.golang says I'm wrong
[09:21] <jam> var x map[int]string is a nil map, but x := map[int]string{} is an empty map
[09:24] <voidspace> jam: have you picked up both PRs or should I look at one?
[09:25] <jam> voidspace: I'm looking at fwereade's not gsamfira's
[09:25] <voidspace> jam: ah, cool
[09:25] <voidspace> fwereade: sure, I'll look at the gsamfira reviews
[09:26] <fwereade> jam, yeah, I've never understood the preference for make()ing maps over just using a literal
[09:27] <jam> fwereade: well, because "var foo map" doesn't work
[09:27] <jam> fwereade: so it would seem that the way to create a map is with "make"
[09:29] <fwereade> jam, sure, but the literal syntax works fine, so I'm not sure why people prefer to avoid it
[09:30] <jam> fwereade: in *my* case, not knowing (or expecting) it to wokr
[09:30] <jam> work
[09:30] <fwereade> jam, it's essentially just the same as slices
[09:31] <fwereade> jam, var gives nil, type{} gives empty
[09:31] <jam> fwereade: except empty slice lets you append as well as a nil slice
[09:31] <jam> and call len
[09:31] <fwereade> jam, indeed, *that*'s the reason people use var foo string{} :)
[09:31] <jam> and iterate
[09:31] <jam> etc
[09:31] <fwereade> jam, len and range work on nil maps too
[09:31] <fwereade> jam, it's just insertion
[09:31] <jam> fwereade: right, but you can't add stuff
[09:31] <jam> which is why it is odd
[09:32] <jam> "the things I want to do with a slice" function the same with nil or empty
[09:32] <jam> "the things I want to do with a map" all work the same except for, ya know, adding stuff
[09:32] <fwereade> jam, it's always felt a bit warty to me
[09:32] <fwereade> jam, defensible ofc but a bit inelegant
[09:42] <jam> fwereade: question about "members" cache vs "others" cache
[09:43] <jam> why do we clean out others here and there, does that effect our transactionality ?
[09:43] <jam> (things which we touch are never refreshed
[09:44] <voidspace> dimitern: the network id that AllocateAddress will take, is that a "provider specific" id (i.e. one we can pass directly to ec2)
[09:44] <dimitern> voidspace, that's the idea, yes
[09:44] <dimitern> voidspace, for ec2 it probably will be a subnet-id
[09:45] <fwereade> jam, so, the idea is that you *can* always get settings for remote units that aren't currently part of the relation
[09:45] <dimitern> voidspace, but it's unused for now - intended to be future-proof :)
[09:45] <fwereade> jam, but that we expect that to be "rare"
[09:45] <jam> fwereade: I don't disagree on either of those points
[09:45] <fwereade> jam, so we persist them only for the lifetime of the context
[09:46] <jam> is this a lifetime of data cached in memory issue ?
[09:46] <fwereade> jam, it doesn't affect the guarantees we make
[09:46] <fwereade> jam, yeah
[09:46] <fwereade> jam, it's always been, and always will be, possible to see relation data "from the future"
[09:46] <fwereade> jam, but within a given context, once you've asked for some settings, they won't change
[09:47] <jam> fwereade: sure, but what causes Prune() to be called
[09:47] <jam> as if you do "relation-get NOT_A_MEMBER" and then trigger a Prune and then another "relation-get NOT_A_MEMBER" you will get different data
[09:48] <jam> (*can* get different data)
[09:48] <voidspace> dimitern: ah, we're designing in imaginary future use cases...
[09:48] <dimitern> voidspace, it's not imaginary, it's in the draft model :)
[09:49] <voidspace> dimitern: :-p
[09:49] <jam> fwereade: also "relation-get A_MEMBER" and then mark that as no longer a member and "relation-get WAS_A_MEMBER" will give different data
[09:50] <fwereade> jam, we Prune to the current membership list at context creation time
[09:51] <fwereade> jam, calling prune/remove/invalidate while a context is in play will not have happy consequenes, I agree
[09:51] <jam> fwereade: so I do see one possible bug, which is if you do "context.Settings("x/2"), then context.InvalidateMember("x/2"), and then context.Settings("x/2") it won't reread the data
[09:52] <jam> because it will pull it out of "other"
[09:53] <fwereade> jam, how would it get into "other" in the first place?
[09:53] <jam> fwereade: the first Settings call
[09:53] <fwereade> jam, TestInvalidateMemberUncachesMemberSettings
[09:53] <jam> fwereade: but it isn't a member
[09:53] <jam> until you call InvalidateMember
[09:53] <fwereade> ah!
[09:53] <fwereade> wait
[09:53] <fwereade> surely it will
[09:54] <jam> fwereade: I think it is just a "delete self.other[memberName]" in InvalidateMember
[09:54] <fwereade> ah yes I see
[09:54] <jam> fwereade: RelationCache.Settings unconditionally falls back to other
[09:54] <fwereade> jam, thanks, well spotted
[09:54] <jam> if settings is nil
[09:54] <fwereade> jam, yeah
[09:56] <fwereade> jam, I think I'd prefer:
[09:56] <fwereade> TestInvalidateMemberUncachesMemberSettings
[09:56] <fwereade>         if !isMember {
[09:56] <fwereade>             settings = cache.others[unitName]
[09:56] <fwereade>         }
[09:56] <fwereade>         if settings == nil {
[09:56] <fwereade>             var err error
[09:56] <fwereade>             settings, err = cache.readSettings(unitName)
[09:56] <fwereade>             if err != nil {
[09:56] <fwereade>                 return nil, err
[09:56] <fwereade>             }
[09:56] <fwereade>         }
[09:56] <jam> fwereade: lgtm
[09:56] <fwereade> jam, cheers
[09:57] <jam> it still seems a bit odd that you might have the data sitting around
[09:57] <jam> fwereade: but still test-worthy however it is solved
[09:58] <fwereade> jam, agreed
[09:58] <jam> fwereade: so going back to understand the lifetime of these objects
[09:59] <fwereade> jam, I think the fundamental problem is an assumption that I'll always call Prune before Remove or Invalidate
[10:00] <jam> fwereade: I'm more thinking about when does the cache actually get invalidated
[10:00] <voidspace> dimitern: is the default-vpc represented as a network interface in ec2?
[10:00] <fwereade> jam, expand please?
[10:01] <jam> so we have this data which is cached, which if you explicitly call InvalidateMember will refresh the cache
[10:01] <jam> but otherwise the cache has unbounded lifetime
[10:01] <jam> it is created when you start a context
[10:01] <jam> (and pruned at that point)
[10:01] <jam> I would have thought a cache would only exist for the lifetime of a contextx
[10:02] <dimitern> voidspace, no, it's an account attribute containing a vpc id in the form "vpc-xxxx" an interface would have id like "eni-xxxx"
[10:03] <fwereade> jam, consider charms which real the full state of a given relation to determine their config
[10:03] <fwereade> jam, they enter a relation with 10 remote units
[10:03] <voidspace> dimitern: ok, so we need to tell ec2 which network interface to assign the ip address to
[10:03] <fwereade> jam, even if they don't have a -joined hook implemented, they'll run 10 -changed hooks
[10:04] <voidspace> dimitern: do we have to get all of them and work out which subnet the address belongs to and which interface the subnet is on?
[10:04] <fwereade> jam, and in the Nth hook they'll grab N sets of settings
[10:04] <fwereade> jam, despite N-1 of them being ones they got just a second or so ago
[10:05] <jam> fwereade: sure. though when the hooks trigger tomorrow won't they want updated data ?
[10:05] <jam> Is this just live until the current set of hooks finish ?
[10:06] <fwereade> jam, they *might*, but we're guaranteed to run a -changed hook, at some point, for any that have changed their data
[10:06] <fwereade> jam, so we invalidate just before running the -changed hook and call it good
[10:07] <jam> fwereade: but if you do so, then isn't that still true for the case of running 10 changed hooks ?
[10:07] <jam> anyway, otp now, I'll need to context switch, but I want to discuss it with you just to get an understanding.
[10:07] <fwereade> jam, ok, I will quickly dump in here, ping me when you want
[10:08] <fwereade> 10 units in scope with cached settings
[10:08] <fwereade> all 10 remote units change their settings
[10:08] <fwereade> we trigger a changed for the first one, and invalidate its settings
[10:09] <fwereade> that changed hook asks for all settings, downloads exactly one (the invalidated one)
[10:09] <fwereade> changed for the second one, with invalidated settings
[10:09] <fwereade> again asks for all settings, only needs to hit the api for one set

[10:10] <fwereade> total impact: 10 settings gets over the 10 hooks; unit saw a consistent -- if not strictly accurate -- view of the changes, and is now fully up to date
[10:11] <fwereade> (and next week, when just one of them changes settings, we again just download one set of changed settings)
[10:11] <fwereade> jam, see above
[10:12] <jam> fwereade: as long as the jujud daemon wasn't restarted
[10:12] <fwereade> jam, so, yes, it would be nice to cache them on disk
[10:12] <fwereade> jam, I'm not doing that right now
[10:12] <jam> fwereade: well, our API shouldn't be so expensive that that is necessary, should it?
[10:13] <fwereade> jam, depends how big the services get
[10:13] <fwereade> jam, all data is big data when you have enough of it ;p
[10:13] <fwereade> jam, but, yes, I don't see a strong need to cache it on disk
[10:14] <jam> fwereade: I'm personally more in favor of less caching until you know that it will help
[10:14] <fwereade> jam, I think people have asked for it once or twice
[10:14] <jam> as cache invalidation is hard
[10:14] <fwereade> jam, agreed :)
[10:15] <fwereade> jam, I think this case is well-understood, though
[10:15] <jam> and tends to do well on benchmarks but when you have real load hit rates may be low
[10:15] <fwereade> jam., not to mention pre-existing ;)
[10:15] <fwereade> jam, quite so
[10:15] <jam> IIRC some of launchpad spend up when they stopped caching some stuff because the extra cached data had low hit rates and was pushing out good data
[10:16] <jam> very different use acse
[10:16] <jam> case, though.
[10:16] <fwereade> jam, however, given that the gimme-all-the-relation-data tool is a pretty frequent request
[10:16] <fwereade> jam, and seems to be the first thing people write when doing helpers for a new language
[10:16] <fwereade> jam, I'm reasonably confident that it maps well to many use cases
[10:22] <natefinch> fwereade: Have you looked at the output variables spec? https://docs.google.com/a/canonical.com/document/d/1Bz8YGJL7OcVgcK-K47MEH7-vlJVPvm34wKUPWO8FQko/edit
[10:23] <natefinch> fwereade: I'm supposed to be sizing this for alexis for this cycle, and I want to make sure the spec actually describes the thing we want to build
[10:25] <natefinch> fwereade: ahh, hmm, hazmat left a comment on that one about there being a new document from brussels, but I can't seem to find it.  Fun.
[10:27] <fwereade> natefinch, dammit
[10:28] <fwereade> natefinch, nor can I
[10:28] <fwereade> natefinch, niemeyer put it together, would you ask him when he comes online?
[10:28] <natefinch> fwereade: sure
[10:29] <wallyworld_> axw: finally got it sorted after having dinner, if you have time, or else it can wait till tomorrow https://github.com/juju/juju/pull/988 just the 2nd commit really
[10:30] <natefinch> fwereade: also - charm level constraints have container and architecture blacklists..... how would those actually work, from a user's point of view?  we don't generally put things in containers automatically, so the only time we do is when a user specifically tells us to, at which point, do we just warn them that the charm probably won't work there?  That doesn't seem like the best UX, but I'm not sure how else to implem
[10:30] <natefinch> ent it
[10:30] <wallyworld_> fwereade: i'd love 5 mins of your time if you have it
[10:31] <fwereade> wallyworld_, sure, start a hangout? natefinch, with you properly in 5?
[10:31] <natefinch> fwereade: sure sure
[10:31] <wallyworld_> fwereade: yeah, our 1:1
[10:32] <fwereade> wallyworld_, regular-catchup?
[10:32] <wallyworld_> yup
[10:33] <fwereade> wallyworld_, I think I'm in there
[10:33] <wallyworld_> https://plus.google.com/hangouts/_/canonical.com/ian-william
[10:33] <fwereade> natefinch, fwiw, I would be treating it like series
[10:35] <hazmat> natefinch, re output variables?
[10:36] <hazmat> natefinch, https://docs.google.com/a/canonical.com/document/d/1JcWkE4SNxXuFClZGBcwnU3w13IpRU1yxMhddQG6mKyE/edit#heading=h.swixk07ju5hq
[10:37] <natefinch> hazmat: thanks.... google docs couldn't find that one for some reason
[10:37] <hazmat> natefinch, odd.. its setup for find and edit by everyone @ canonical
[10:37] <natefinch> hazmat: yeah, I don't know why search wasn't finding it
[10:38] <natefinch> hazmat: of course now that I've opened it, search finds it just fine :/
[10:39] <natefinch> hazmat: great, this looks much more like what I was expecting than the old spec
[10:48] <fwereade> natefinch, I think there are some things to worry about with that spec -- the concept of a "schema" is so tortured as to be a positive impediment to understanding
[10:48] <fwereade> natefinch, but I will make my comments on the doc (and try to talk to gustavo about it tomorrow)
[10:48] <fwereade> natefinch, anyway, re blacklists
[10:49] <fwereade> natefinch, IMO we shouldn't even try to deploy things in places they declare they won't work
[10:49] <natefinch> fwereade: that seems to make sense
[10:49] <fwereade> natefinch, in particular I don't think arch/container blacklists are even constraints
[10:50] <fwereade> natefinch, for constraints in charms, I think there's more wiggle room -- the constraints in charms are *recommendations*, that we will follow if we can but deploy anyway and warn if we can't meet them
[10:50] <fwereade> natefinch, and they are ofc just suggestions, and completely ignored if the service has real constraints
[10:50] <fwereade> natefinch, indicating that the administrator knows he knows better
[10:51] <fwereade> natefinch, that said
[10:51] <fwereade> natefinch, constraints in charms are not currently a thing AFAIK?
[10:51] <natefinch> fwereade: my thought was that charm constraints would turn into real constraints during deploy, but get overridden by any other constraints specified by the CLI etc.
[10:51] <natefinch> fwereade: correct
[10:51] <natefinch> fwereade: it is a thing I am being tasked with writing :)
[10:51] <natefinch> fwereade: well, my team :)
[10:52] <hazmat> fwereade, unrelated.. but was curious.. what's the status on leader election?
[10:52] <fwereade> hazmat, ramping up
[10:52] <fwereade> hazmat, I'm churning on the uniter
[10:52] <hazmat> fwereade, k, thanks
[10:53] <fwereade> hazmat, it's taking a bit of time to actually get us to having a global sense of hook ordering
[10:53] <fwereade> hazmat, and katco is about to make a start on the server side
[10:54] <fwereade> natefinch, given that container type and arch are already constraints though
[10:55] <fwereade> natefinch, probably it makes sense to draw a distinction between preferred and required constraints in a charm
[10:55] <natefinch> fwereade: *nod* there's RAM and rootdisk charm-level constraints in the spec as well
[10:56] <natefinch> fwereade: those are a little easier to grok than the arch and container blacklists, since blacklists are the opposite of what we do with constraints now
[10:56] <fwereade> natefinch, provider-specific constraints are gonna be fun, too
[10:56] <fwereade> natefinch, do you overlap with thumper?
[10:56] <natefinch> fwereade: yeah, late in the day for a couple hours
[10:57] <fwereade> natefinch, please talk to him about the upcoming distinctions between provider/account/environment, and think through the implications
[10:57] <fwereade> natefinch, I will hopefully be in a position to pop on late tonight so I will join you if I can
[10:58] <fwereade> natefinch, I would suggest it's something to write into the spec but explicitly carve out as a "phase 2" task
[10:58] <natefinch> fwereade: cool.  I was hoping to push off provider-specific constraints until v2, but not sure if everyone will agree with that. :)   there's just instance-type and cloud-blacklist
[10:58] <natefinch> (v2 of charm level constraints that is)
[10:58] <fwereade> natefinch, ah, didn't know about cloud-blacklist
[10:59] <fwereade> natefinch, to my mind, that implies you need to think it through properly for v1
[10:59] <natefinch> yeah....
[10:59] <fwereade> natefinch, the big issue os how we identify clouds
[10:59] <natefinch> I can think it through for v1, I just don't want to write it for v1 ;)
[10:59] <natefinch> fwereade: yes, since right now openstack is openstack, not HP vs. canonistack
[11:00] <fwereade> natefinch, the core question is "what is a cloud" :) ...and how do we clearly identify them
[11:00] <fwereade> natefinch, exactly
[11:00] <fwereade> natefinch, not to mention that azure != azure-in-china
[11:00] <natefinch> bleh
[11:00] <fwereade> natefinch, and that in some ways that matters (does an account bind to a cloud?)
[11:01] <fwereade> natefinch, and in some ways it doesn't (instance sizes are probably the same in the azure case at least)
[11:01] <fwereade> natefinch, (although, yeah, instance types across openstacks will surely vary)
[11:01] <fwereade> natefinch, I think it's about "provider" as a concept distinct from "provider *type*"
[11:02] <fwereade> natefinch, anyway thumper is at the sharp end re providers/accounts, and your notions of "what is a cloud" will need to align
[11:02] <fwereade> natefinch, is that enough context for you to have a useful chat with him, do you think?
[11:02] <natefinch> fwereade: yep, thanks, that's very helpful.
[11:03] <fwereade> natefinch, cool
[11:05] <jam> fwereade: so I think I've covered the logic question and aside from that one bug, lgtm
[11:08]  * TheMue has to step out, yesterday mentioned appointment in garage. bbiab
[11:16] <perrito666> morning all btw
[11:17] <natefinch> morning perrito666
[11:22] <fwereade> jam, lovely, thanks
[11:24] <natefinch> The longer I spend trying to come up with  estimates for work items, the larger the estimates get
[11:26] <perrito666> natefinch: it usually is the other way around
[11:27] <natefinch> perrito666: no way... the longer I spend on it, the more paranoid I get that I'm not estimating enough time.  I don't think anyone in the history of programming has ever over-estimated the amount of time something will take to implement.
[11:33] <perrito666> a truck full of oxygen tanks just took a speedbump at 40-60 ... I am still trying to have my blood unfreeze.
[11:33] <perrito666> that is km not miles
[11:34] <natefinch> heh
[12:15] <perrito666> anyone feels like reviewing this overly trivial change? http://reviews.vapour.ws/r/289/diff/#
[12:16] <perrito666> brb, mechanic
[12:26] <voidspace> fwereade: ping
[12:26] <fwereade> voidspace, pong
[12:27] <voidspace> fwereade: are you up to date with the latest strategy for reboot and the clearing of the reboot flag?
[12:27] <voidspace> fwereade: the latest strategy is to clear the flag *immediately before* reboot
[12:28] <voidspace> fwereade: so there is still a very small window for jujud to die and the reboot not to happen
[12:28] <fwereade> voidspace, I think so, yeah -- so long as we schedule a delayed reboot before clearing the flag, and then do an immediate reboot afterwards to save time, I'm ok with it
[12:28] <voidspace> fwereade: cool
[12:29] <voidspace> fwereade: some of your comments on the PR, from a while back,  haven't been replied to since discussions
[12:29] <voidspace> but they're now out of date
[12:29] <fwereade> voidspace, it leaves the possibility that someone will cancel the reboot but I can live with that
[12:29] <voidspace> right
[12:29] <voidspace> fwereade: by "someone", you mean a user logged into a machine?
[12:30] <fwereade> voidspace, yeah
[12:30] <voidspace> heh
[12:30] <voidspace> they get the mess they asked for then
[12:30] <fwereade> voidspace, or, y'know, just any old manifestation of the universe's desire to teach us humility
[12:30] <voidspace> :-)
[12:30] <voidspace> I have quite a few friends like that
[12:31] <voidspace> or in fact, just juju itself...
[12:42] <kwmonroe> kv7tbgks
[12:42] <kwmonroe> welp.. that's the berries
[12:54] <jam> kwmonroe: that won't be the first password that this irc channel has voided  :)
[12:55] <kwmonroe> ugh.  just got good at typing it too.
[12:55] <jam> kwmonroe: if it had been longer lived, I would just say "you probably needed to rotate your passwords anyway"x
[13:16] <ashipika> Hello… could somebody help me out with the lxc provider?
[13:16] <jam> ashipika: what's up ?
[13:17] <ashipika> my question is: is there a performance benefit to reusing existing containers for new units instead of creating new ones.. especially in the case of lxc-clone-aufs being defined in the environments.yaml
[13:18] <ashipika> jam: i'm trying to fix a really annoying bug..
[13:18] <ashipika> jam: where there's a leftover container that fails to start in a previous deploy and is not cleaned up during destroy-envrionment
[13:20] <ashipika> jam: so when i bootstrap a new environment and try to add a unit, it reuses the leftover container.. and of course, fails to start again
[13:20] <ashipika> jam: a workaround i wrote is to retry by starting a new container.. and it works.. but the questions is why reuse containers in the first place..
[13:31] <sinzui> natefinch, :(  the two restore tests are failing. I thought they would be fixed with the other fixes landed yesterday. Can you arrange for someone to look into bug 1387172
[13:31] <mup> Bug #1387172: restore consistently fails <backup-restore> <ci> <regression> <test-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1387172>
[13:33] <perrito666> sinzui: looking
[13:33] <bac> sinzui, mgz: jenkins-github-lander has been updated.  bin/lander-check-pulls now accepts a --debug flag to be a little less mysterious about what it is doing.
[13:35] <mgz> bac: I'll have a look
[13:37] <natefinch> sinzui: sure
[13:37] <perrito666> natefinch: o/
[13:38] <sinzui> perrito666, sorry, I know restore code didn't change
[13:38] <perrito666> sinzui: worry not, I am pretty sure I know what changed
[13:46] <perrito666> natefinch: sinzui I am pretty sure this is because of the changes on _id field for machines
[13:46] <marcoceppi> what's the default scope?
[13:46] <marcoceppi> on a relation
[13:47] <mattyw> has anyone seen/ is fixing this failure? http://paste.ubuntu.com/8733212/. It's very intermittent
[13:47] <mgz> mattyw: that one is new to me
[13:48] <mattyw> mgz, I'm being lucky today, It happened here: http://juju-ci.vapour.ws:8080/job/github-merge-juju/1053/console
[13:48] <mgz> I saw another one of yours on that too
[13:48] <mattyw> mgz, and I got a different failure here http://juju-ci.vapour.ws:8080/job/github-merge-juju/1052/console
[13:48] <mattyw> mgz, yup, pretty* sure it's not my change doing it
[13:49] <mgz> seems worth a bug with intermittent-failure tag
[13:49] <perrito666> mattyw: mgz devecheney was complaining of the same last night iirc
[13:49] <perrito666> mattyw: updated dependencies later?
[13:49] <perrito666> lately?
[13:50] <mgz> perrito666: he got it in a landing job, which should always have deps as specified
[13:50] <mattyw> perrito666, yep, I've not actually seen the test fail locally though
[13:50] <natefinch> perrito666: yeah, that id change seems like it screwed up a bunch of stuff
[13:50] <perrito666> natefinch: it did
[13:51] <perrito666> I am also not sure if my fix is right, I am for the moment just trying to figure if I got the issue right
[13:51] <natefinch> perrito666: this is why you don't encode metadata into an id field
[13:51] <mgz> backup/restore on ci is currently very unhappy
[13:52] <perrito666> mgz: I know I know, working on it
[13:53] <mgz> perrito666: <3
[14:10] <perrito666> man, testing old restore requires some patience
[14:36] <katco> hey everyone, i'm ocr today, but i've been directed to try and fix a bug before our cut tomorrow, so i'll be working on that. sorry for any inconvenience.
[14:39] <perrito666> its ok we can optically recognize characters for you
[14:39] <natefinch> fwereade: you have any time to talk about exposing zones to charms? There's a spec, but it's huge and not super-focused
[14:42] <perrito666> this is how waiting for the old restore to finish feels :p https://www.youtube.com/watch?v=qLlUgilKqms
[14:44] <natefinch> hehh
[14:48] <perrito666> who wants to be the hero to unlock CI with a mighy review? http://reviews.vapour.ws/r/292/
[14:50] <mgz> perrito666: done
[14:50] <perrito666> tx
[15:03] <fwereade> natefinch, probably in an hour?
[15:03] <natefinch> fwereade: sure
[15:22] <perrito666> sinzui: mgz how far are we from a new run of functional-backup-restore* ?
[15:22] <sinzui> perrito666, 1h
[15:23]  * perrito666 cries
[15:23] <sinzui> perrito666, this is a rebuild of the last rev
[15:23] <perrito666> sinzui: tx
[15:31] <voidspace> and back...
[15:40] <TheMue> voidspace: made a knot into your internet wire?
[15:40] <voidspace> TheMue: they actually fixed it!
[15:40] <voidspace> TheMue: I'm back up to 15mbs
[15:40] <voidspace> after six months...
[15:41] <voidspace> TheMue: only 1mbps upstream, but it's still double yesterday...
[15:42] <TheMue> voidspace: is this the promised bandwidth?
[15:44] <voidspace> TheMue: yep
[15:45] <TheMue> voidspace: that's good. for a longer time I only had about a half of the promised bandwidth, the backend has been too slow for all who ordererd a higher bandwidth
[15:46] <TheMue> voidspace: now I'm at 80 to 90% downstream and 100% upstream most of the times
[15:46] <TheMue> voidspace: means 40 to 45 mbits down and 10 up
[15:47] <voidspace> TheMue: yeah, that's pretty normal to get much less than the "maximum" you pay for
[15:47] <TheMue> voidspace: exactly
[15:47] <voidspace> TheMue: in theory this should be a 12mbit line - it's currently 15mbit and I'm actually getting 12
[15:47] <voidspace> TheMue: 4045mbits
[15:47] <voidspace> TheMue: lucky man :-)
[15:48] <TheMue> voidspace: I am, yeah. but you know, it never can be enough *lol*
[15:51] <voidspace> right
[15:51] <voidspace> true enough
[15:52] <voidspace> gsamfira: ping
[15:58] <voidspace> networkInterface := instancesResp.Reservation.Instances[0].Interfaces[0]
[15:58] <voidspace> heh :-)
[15:59] <gsamfira> voidspace pong
[15:59] <voidspace> actually I want
[15:59] <voidspace> networkInterfaceId := instancesResp.Reservation.Instances[0].Interfaces[0].Id
[16:00] <natefinch> fwereade: in moonstone whenever you're ready: https://plus.google.com/hangouts/_/canonical.com/moonstone?authuser=1
[17:01] <perrito666> sinzui: mm, something is odd in the test run its failing even before getting to the test per se
[17:13] <sinzui> perrito666, :( Hp might be having issues. Your rev is still queued to be tested
[17:18] <natefinch> hazmat: do you have time in the next hour to talk about exposing zones to charms?  It's on my list of stuff to do this cycle and I want to make sure I understand what needs to be implemented
[17:18] <hazmat> natefinch, i have time now for 12m
[17:18] <natefinch> hazmat: https://plus.google.com/hangouts/_/canonical.com/moonstone?authuser=1
[18:13] <perrito666> can I get a second review on http://reviews.vapour.ws/r/289/? its one line
[18:14] <natefinch> perrito666: I guess there's no test for that?
[18:14] <natefinch> perrito666: maybe there should be?
[18:15]  * natefinch gives more work to Horacio, as usual.
[18:15] <perrito666> natefinch: yes, good idea
[18:15] <perrito666> natefinch: its my job to do the work you give me :p not that I am going to complain
[18:16] <natefinch> :D
[18:17] <natefinch> gah, why the hell can't people document their friggin' features?
[18:18] <natefinch> latest offender:  zone placements   evidently juju deploy zone=foo is a thing, but you wouldn't know it from juju help deploy
[18:19] <perrito666> natefinch: well it wouldnt be fair, if they did I would be the only one with more work
[18:19] <perrito666> ;)
[18:19] <perrito666> dont we have tests that check that all flags are documented?
[18:19] <natefinch> probably not.... that's a little hard to do
[18:20] <perrito666> natefinch: well you know the flags you just need to call help and check that they at least appear there
[18:22] <natefinch> perrito666: well, in this case, zone is a placement directive, which means it's not actually a flag
[18:22] <perrito666> bu
[18:23] <natefinch> it's 'juju deploy mysql zone=us-east-1b'
[18:24] <natefinch> (not -zone=us-east-1b)
[18:30] <natefinch> perrito666: er, I guess it's only add-machine
[18:30] <natefinch> https://juju.ubuntu.com/docs/charms-ha.html
[19:03] <perrito666> natefinch: tested
[19:03] <mfoord> g'night all
[19:10] <natefinch> perrito666: looking
[19:12] <natefinch> perrito666: reviewed, couple minor things in the test
[19:18] <perrito666> natefinch: did you notice that you can actually select blocks of code and comment on that?
[19:21] <sebas5384> hi o/
[19:21] <sebas5384> i was wondering if I still need swift in openstack in order to bootstrap an openstack environment
[19:24] <natefinch> sebas5384: we're working on removing the storage requirement for juju, but I'm not sure it's in stable code yet
[19:25] <perrito666> natefinch: fixed
[19:25] <sebas5384> natefinch: yeah, think I sow that in a release notes somewhere
[19:25] <natefinch> sinzui: the storage requirement for juju was removed recently, but I presume that's in 1.21, which isn't a stable release, right?
[19:27] <sinzui> natefinch, that is right
[19:28] <natefinch> sebas5384: so if you want to do some testing with 1.21 alpha, you're welcome to.  We're pushing to get it to stable in the next few weeks
[19:28] <sebas5384> ahh great, I'm going to download it to test it :)
[19:29] <sebas5384> thanks!! :D
[19:31] <natefinch> perrito666: ship it!
[19:35] <perrito666> utils dont have a bot right?
[19:35]  * perrito666 feels a bit silly
[19:35] <natefinch> I think that's correct
[19:37] <perrito666> man do I feel dumb :p
[19:38] <perrito666> reminds me of an european guy I found in a public restroom at a party on the weekend he was making all kind of gestures to the water tap until I passed and just turned the handle on and he stood looking at it and said "oh, one of those"
[19:38] <natefinch> haha, I do that
[19:44] <perrito666> sinzui: natefinch mgz aaand we have a pass http://juju-ci.vapour.ws:8080/job/functional-ha-backup-restore/963/
[19:45] <natefinch> perrito666: yay!
[19:45] <sinzui> yep I was just marking the bug fix released
[19:45] <perrito666> sinzui: tx
[19:45] <sinzui> there is something a miss in the unittest runs. both an instance and a real machine disappeared. I am rerunning the tests
[19:49] <perrito666> sinzui: I  have my finger ready to trigger a $$merge$$ :p
[19:49] <sinzui> perrito666, go ahead, you are unblocked
[19:49] <perrito666> davecheney: could you tell me a bit more about http://reviews.vapour.ws/r/275/#comment1666 ?
[20:33] <davecheney> perrito666: it's better to write code that doesn't need that bit of boiler plate
[20:33] <davecheney> 'cos if that method gets refactored and that code lost
[20:33] <davecheney> all hell will break loose
[20:41] <natefinch> I agree...   foo := foo is cute for language nerds, but it's never a good idea in production code.
[21:25] <thumper> menn0: change pwd code updated
[21:25] <menn0> thumper: ok, i'll have a look shortly
[21:25] <thumper> cheers
[21:39] <perrito666> davecheney: I guessed so much, then I git blamed and suddenly I doubted myself
[21:49] <menn0> thumper: done
[21:50] <menn0> thumper: if you have a chance could you look at http://reviews.vapour.ws/r/284/ pls?
[21:57] <katco> is there a way to specify an ec2 availability zone when bootstrapping?
[22:00] <perrito666> katco: having ec2 complaining of no more machines?
[22:00] <katco> perrito666: i am =/
[22:00] <perrito666> katco: change region, goes faster
[22:00] <katco> perrito666: you sound like you've run into this before :)
[22:01] <katco> perrito666: tyvm, sir. i'm unblocked :)
[22:02] <perrito666> katco: backup and restore testing makes me bump into this often :p
[22:02] <katco> perrito666: hehe
[22:14] <wwitzel3> menn0: ping
[22:14] <menn0> wwitzel3: hi
[22:15] <wwitzel3> menn0: I am unable to replicate that bug, can you try destroying your lxc template and see if you run in to the same issue?
[22:15] <menn0> wwitzel3: will do
[22:16] <perrito666> davecheney: natefinch if I understand correctly that is done because the member from the for declaration is always the same var but the one inside is subject to the scope of that loop right?
[22:16] <wwitzel3> menn0: I tried with both trusty and precise and I'm not getting any of those errors, what i think is likely the cause is the lxc-template we generate for machine-0 probably has the old "anything" certs
[22:17] <menn0> wwitzel3: that's quite likely. I think I've had these templates for ages.
[22:17] <wwitzel3> menn0: I'm testing out ec2 right now just to be sure.
[22:18] <menn0> wwitzel3: if that is the problem (I'm bootstrapping again now) how do avoid it biting other people?
[22:18] <menn0> wwitzel3: should we have an upgrade step for alpha2 or 3 that deletes the templates?
[22:19] <wwitzel3> menn0: good question, lets see if removing the template indeed fixes it for you, and if so, I'll defer to thumper or jam on what they want to do.
[22:19] <menn0> wwitzel3: sounds good
[22:19] <wwitzel3> menn0: and then what ever they tell me to do, I'll do :)
[22:20] <wwitzel3> menn0: we could always go with the olde, "local provider isn't production"
[22:20] <menn0> wwitzel3: true
[22:20] <wwitzel3> menn0: but that isn't very friendl ;)
[22:20] <menn0> wwitzel3: no it's not and deleting the templates probably isn't that hard
[22:21] <menn0> wwitzel3: although I guess it's not an upgrade problem actually
[22:21] <menn0> wwitzel3: this happens even with a fresh bootstrap
[22:21] <menn0> wwitzel3: I wonder if there's a way that Juju could detect that the certs are bad
[22:22] <wwitzel3> menn0: maybe, I don't know enough about how that template is generated .. I think we won't that the machine-0 certs are bad until another machine attempts to connect.
[22:27] <menn0> waigani: since thumper doesn't appear to be around could you have a look at http://reviews.vapour.ws/r/284/ please?
[22:27] <waigani> menn0: half way through
[22:27] <menn0> waigani: ok cheers :)
[22:29] <wwitzel3> menn0: ec2 is good
[22:30] <menn0> wwitzel3: my bootstrap just finished here and I still see the problem
[22:30] <menn0> wwitzel3: :(
[22:31] <menn0> wwitzel3: the template was definitely re-created from scratch. I watched Juju do that by monitoring lxc-ls --fancy
[22:33] <davecheney> perrito666: https://golang.org/doc/faq#closures_and_goroutines
[22:35] <perrito666> davecheney: tx
[22:35] <davecheney> talks about a different problem, but the underlying cause is the same
[22:35] <davecheney> for _, x := range A_SLICE_OF_VALUES {
[22:36] <davecheney>         go something(x)
[22:36] <davecheney> }
[22:36] <davecheney> in this case it was
[22:36] <davecheney> for _, x := range A_SLICE_OF_VALUES {
[22:36] <davecheney> append(something, &x)
[22:38] <wwitzel3> menn0: hrmm, i've got nothing .. all clean http://paste.ubuntu.com/8738740/ (machine-0), http://paste.ubuntu.com/8738764/ (unit-mysql)
[22:38] <perrito666> davecheney: that is why it does x:=x to get a non shared x I assume
[22:38] <wwitzel3> menn0: all-machines is aggregating .. machine-1 and machine-2 are good .. not even one occurance of that error you are seeing :/
[22:39] <menn0> wwitzel3: well I'm seeing the same as what I reported on the ticket. All machine logs except machine-0 and and all unit logs are reporting the rsyslog worker continually restarting
[22:39] <menn0> wwitzel3: so you've tried it with the local provider on your machine?
[22:39] <perrito666> and yes, it is waiting for someone to not know this to delete that line thinking its useless
[22:40] <davecheney> perrito666: yup
[22:40] <davecheney> but that nastyness can be avoided by changing the type of the slice being iterated over
[22:40] <wwitzel3> menn0: yeah those logs are local provider
[22:40] <perrito666> well since I am refactoring, why not
[22:40]  * thumper is back
[22:40] <thumper> physio again
[22:40] <menn0> wwitzel3: and you're using current master not 1.20?
[22:40]  * davecheney pops champaign 
[22:41]  * thumper is somewhat broken
[22:41] <perrito666> davecheney: or, I could delete that line and let the hell break loose and then go to sleep :p
[22:41] <davecheney> perrito666: whatever works for you
[22:41] <wwitzel3> menn0: yep, current master, 4e078f90b7d31b80feac167197679ad67a59650c
[22:42] <menn0> wwitzel3: that's what i'm using
[22:42] <menn0> wwitzel3: wtf!
[22:42] <menn0> wwitzel3: there must be some difference between our machines
[22:42] <wwitzel3> yeah :/
[22:43] <menn0> wwitzel3: go version? I'm using 1.2.1 linux/amd64
[22:43] <wwitzel3> menn0: go version go1.2.1 linux/amd64
[22:43] <wwitzel3> menn0: Linux wwitzel3-ThinkPad-W540 3.16.0-23-generic #31-Ubuntu SMP Tue Oct 21 17:56:17 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
[22:44] <davecheney> perrito666: i thought this was matty's change anyway ?
[22:45] <menn0> wwitzel3: remind me how to get that?
[22:45] <perrito666> nope, I refactored the tests for peergrouper because it was causing me an import cycle
[22:46] <wwitzel3> menn0: uname -a
[22:46] <menn0> wwitzel3: Linux bazhou 3.13.0-37-generic #64-Ubuntu SMP Mon Sep 22 21:28:38 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
[22:47] <waigani> menn0: done http://reviews.vapour.ws/r/284/
[22:47] <menn0> wwitzel3: your kernel is a little ahead but I don't see how this would affect this problem
[22:47] <wwitzel3> menn0: yeah, me either
[22:48] <menn0> wwitzel3: are you on utopic or trusty
[22:48] <menn0> wwitzel3: i'm still on trusty?
[22:48] <menn0> s/\?//
[22:48] <wwitzel3> menn0: utopic, deploying trusty
[22:48] <wwitzel3> menn0: but my ec2 was all trusty
[22:49] <menn0> wwitzel3: but juju was built on utopic right?
[22:49] <menn0> wwitzel3: that might be the difference
[22:50] <menn0> wwitzel3: I think we need to try on some other people's machines to narrow this down
[22:51] <anastasiamac> katco: morning :-) saw ur email
[22:51] <wwitzel3> menn0: maybe .. we need to draw some straws
[22:51] <wwitzel3> exactly :)
[22:51] <katco> anastasiamac: good morning :)
[22:51] <anastasiamac> katco: makes sense to me but what do i know
[22:51] <menn0> thumper: what distro is your machine running?
[22:51] <thumper> menn0: ubuntu :-)
[22:51] <menn0> thumper: which series I mean
[22:51] <thumper> trusty
[22:52] <wwitzel3> thumper wins!
[22:52] <menn0> can you follow the repro instructions for bug 1387388 with current master please?
[22:52] <mup> Bug #1387388: rsyslog worker broken due to certificate signing problem <juju-core:New> <https://launchpad.net/bugs/1387388>
[22:53] <menn0> thumper: it happens consistently for me but never for wwitzel3 but I'm on trusty and he's building on utopic
[22:53] <menn0> thumper: we're trying to establish if that's the difference
[22:54] <thumper> kk
[22:55]  * thumper grabs upstream
[22:55] <thumper> :-(
[22:55] <thumper> WARNING unknown config field "tools-url"
[22:55] <thumper> I get that six times
[22:56] <thumper> just destroying the local environment
[22:56] <wwitzel3> yeah, I got that too
[22:56] <menn0> that happens when you mix Juju versions
[22:56] <menn0> I think what's happening is that tools-url is no longer a known config option
[22:57] <menn0> everything still works but it is annoying
[22:57] <thumper> is there an upgrade step that fixes the config?
[22:57] <menn0> I don't think that will help
[22:57] <menn0> it's the client
[22:57] <thumper> no it isn't
[22:57] <thumper> um...
[22:57] <thumper> wat?
[22:57] <menn0> perhaps i'm wrong...
[22:58] <thumper> where is that warning coming from
[22:58] <thumper> ?
[22:58] <thumper> oh...
[22:58] <thumper> I bet it is the bootstrap-config stored in the JENV
[22:58] <menn0> that sounds right
[22:59] <wwitzel3> menn0: oh, the certs are stored in the local.jenv .. so if that was stale, that might also impact the rsyslog clients.
[23:00] <wwitzel3> menn0: but we remove that with destroy-environment right?
[23:00] <menn0> wwitzel3: the .jenv is certainly supposed to get removed on destroy
[23:01] <wwitzel3> menn0: yeah, I thought so
[23:01] <wwitzel3> menn0: brb,grabbing some food
[23:05] <thumper> menn0: what should I see?
[23:06] <menn0> thumper: check the logs of any of the machines except 0, or any of the units
[23:06] <thumper> seems to work here
[23:06] <menn0> thumper: do you see the rsyslog worker restarting
[23:06] <thumper> although I have different logging issues
[23:06] <thumper> but I think that is an older currently running local provider for another user
[23:10] <perrito666> oh I see why this change was not made before
[23:10] <anastasiamac> thumper: wallyworld assured me that noone in the world has "tools-url" anymore
[23:10] <anastasiamac> thumper: and if they do, they will change it :-)
[23:11] <wallyworld_> tools-url was deprecated post 1.16
[23:12] <anastasiamac> wallyworld_: yes and removed now-ish ;-)
[23:12] <menn0> waigani: thanks for the review. looks like you weren't looking at the latest version as the first thing you picked up was fixed in rev 2 (pushed last night)
[23:13] <thumper> wallyworld_: so where did it come from?
[23:13] <rick_h_> thumper: just looking at the title, admin can see other user's passwords?
[23:13] <thumper> rick_h_: not see, but change
[23:13] <rick_h_> thumper: ah ok /me goes back to reviews
[23:13]  * wallyworld_ reads backscroll
[23:13] <thumper> rick_h_: juju only stores a salted hash of the password
[23:13] <thumper> rick_h_: so if you forget or lose it, we have to have a way to generate another
[23:14] <rick_h_> thumper: ok cool, sorry. Later in my day so misread that as admin could see it
[23:14] <perrito666> davecheney: sorry mate, making the change to a pointer slice goes all the end to replica set public API and replicaset.Config document it is not worth it, Ill make it cleaner so it is obvious to someone that plays go by the ear
[23:14] <thumper> rick_h_: np
[23:14] <wallyworld_> thumper: i'm guessing you have an environments.yaml that is old, one which had a tools-url config attribute specified perhaps
[23:14]  * thumper just hit two different intermittent test failures
[23:14] <thumper> wallyworld_: there is no tools-url in my environments.yaml
[23:14] <thumper> I looked
[23:15] <thumper> and the environment I created was a few days ago
[23:15] <thumper> wallyworld_: it is possible that the tools-url was populated but empty
[23:15] <thumper> so it existed as a value, but empty
[23:15] <wallyworld_> in that case i'm not sure, will look into it
[23:15] <wallyworld_> it should have been totally deleted
[23:15] <wallyworld_> from the code
[23:16] <wallyworld_> so should not be present, empty or not
[23:16] <anastasiamac> wallyworld_,thumper: tools-url is not in current codebase
[23:17]  * anastasiamac thinks
[23:17] <wallyworld_> thumper: maybe you have an older jenv file which is being used?
[23:17] <thumper> wallyworld_: nope
[23:18] <thumper> anastasiamac: yes, but when I created the environment a few days ago, was it there?
[23:18] <wallyworld_> it could have been
[23:18] <anastasiamac> thumper: can u do a search in ur codebase?...
[23:18] <thumper> anastasiamac: I have master :)
[23:18] <thumper> I expect it to be the same as your master
[23:18] <thumper> dvcs ftw
[23:19] <anastasiamac> thumper: my master is the same as urs
[23:19] <thumper> not there
[23:19] <menn0> wwitzel3, thumper: I'll do some more experimentation to see if I can figure out the rsyslog issue
[23:20] <thumper> wallyworld_: tools-url was in the 1.20 branch
[23:20] <wallyworld_> yes, it was processed as a deprecated attribute
[23:20] <menn0> thumper, wallyworld_, anastasiamac: I certainly see this warning when I've bootstrapped with 1.20 and then upgrade to 1.21
[23:20] <menn0> when I later destroy the environment with the 1.21
[23:20] <wallyworld_> what we should do in 1.21 is add an upgrade step to delete it
[23:20] <menn0> client
[23:21] <anastasiamac> menn0: could u paste the warning u get?
[23:21] <wallyworld_> i think because it is defined in the config schema, an empty value is inserted
[23:21] <wallyworld_> we already have an upgrade step to delete old values
[23:21] <thumper> wallyworld_: 1.20 branch, environs/config/config.go:852
[23:21] <waigani> menn0: just the first comment if from rev 1. The rest are rev 2.
[23:21] <wallyworld_> we just need to add tools-url to that existing step
[23:21] <thumper> wallyworld_: it always added a blank "tools-url" to the config
[23:22] <menn0> waigani: yep. got it
[23:22] <wallyworld_> right, that explains it
[23:22] <wallyworld_> we'll add the upgrade step to delete it
[23:22] <thumper> wallyworld_: also, bootstrap-config in the jenv on the user's machine will still have it
[23:22] <thumper> wallyworld_: which means they will still get the warning
[23:22] <thumper> every time they use the environment
[23:22] <thumper> unless you update the bootstrap config in the jenv file
[23:22] <wallyworld_> maybe we should only emit that warning if the value is not ""
[23:23]  * thumper nods
[23:23] <thumper> that would reduce the likelihood of false errors
[23:23] <wallyworld_> cause changing jenv = yuk
[23:23] <thumper> ack
[23:23]  * wallyworld_ looks at anastasiamac :-)
[23:23] <thumper> alexisb: ping
[23:23] <thumper> ha, it is only 4:23pm for alexisb
[23:24] <thumper> so close
[23:24] <thumper> alexisb: last part of first iteration of user management has landed for 1.21
[23:24] <thumper> \o/
[23:24] <thumper> it is DONE DONE
[23:24] <wallyworld_> about time :-P
[23:24] <thumper> yeah
[23:24] <thumper> true that
[23:24]  * anastasiamac looks back at wallyworld
[23:24] <thumper> now... on to this messy things
[23:25] <anastasiamac> wallyworld_: m onto it ;-)
[23:25] <rick_h_> thumper: and this means the remote auth stuff is there to hook into?
[23:25] <thumper> anastasiamac: wallyworld_ is looking at you with the not so subtle suggestion that you do all the work
[23:25] <thumper> rick_h_: no
[23:25] <rick_h_> thumper: but but but :P
[23:25] <thumper> rick_h_: this means that juju has users and environments have users
[23:25] <wallyworld_> anastasiamac: awesome - you need to add to the existing upgrade step, and also not emit a warning if an unknown alue is empty
[23:25] <thumper> rick_h_: and they can log in
[23:25] <thumper> rick_h_: cmars is working on the remote identity stuff
[23:25] <thumper> rick_h_: and making good progress
[23:25] <wallyworld_> thumper: it's called delegation :-)
[23:25] <rick_h_> thumper: so how long before until we need the GUI to be speaking this stuff?
[23:26] <thumper> rick_h_: so this remote identity stuff is not blocked on us at all
[23:26] <cmars> rick_h_, we can stub out the GUI until you're ready :)
[23:26] <thumper> rick_h_: not sure what you mean there
[23:26] <rick_h_> thumper: cmars I mean when will someone bootstrap with these users and want to type that username/password into a GUI?
[23:26] <thumper> rick_h_: the GUI doesn't need to do any of this
[23:27] <thumper> rick_h_: so, this isn't the boostrap user being different
[23:27] <cmars> rick_h_, ah, that's not remote identity
[23:27] <rick_h_> thumper: so if I juju deploy juju-gui into an environment as user XXXX, I don't have the secret, but need too login with user/password?
[23:27] <thumper> rick_h_: that will come in 1.22
[23:27] <rick_h_> thumper: ah ok
[23:27] <rick_h_> thumper: yea, that's whaat I'm tring to track when we need to start updating our login box
[23:27] <rick_h_> thumper: ok, but we do need to update the username box
[23:27] <ericsnow> menn0: when you have a sec, take a look at the latest revision revision of those two review requests (243, 268)
[23:27] <thumper> rick_h_: you can use "juju api-info user password"
[23:27] <rick_h_> because logging in with the secret as 'admin' might not be true
[23:27] <thumper> rick_h_: and that will give you the username and password to log into the gui
[23:28] <rick_h_> thumper: ok, is this documented so we can poke at it?
[23:28] <thumper> rick_h_: I added it to the 1.21 release notes
[23:28] <thumper> rick_h_: poke away
[23:28] <thumper> rick_h_: it is in 1.21-alpha2
[23:28] <menn0> ericsnow: I will try. juggling a bunch of stuff right now
[23:28] <rick_h_> thumper: ok, so this will be in 1.21 mid-month it sounds like
[23:28] <ericsnow> menn0: no worries :)
[23:28] <thumper> rick_h_: ack
[23:29] <rick_h_> thumper: ok
[23:29] <thumper> rick_h_: but for now, the initial user is still "admin"
[23:29] <thumper> rick_h_: and the password is still stored in the same place
[23:29] <rick_h_> thumper: right, but they can create more
[23:29] <thumper> rick_h_: ack
[23:29] <rick_h_> thumper: and those new ones the user will not be able to login to the GUI without updating it
[23:29] <thumper> rick_h_: when you add a user, it gives you a jenv file
[23:29] <rick_h_> thumper: so sounds like I need to get some work items down
[23:30] <thumper> rick_h_: ah... wat?
[23:30] <thumper> rick_h_: why would they not be able to log in?
[23:30] <rick_h_> thumper: I bootstrap env as admin.
[23:30] <rick_h_> thumper: I create rick user with password
[23:30] <thumper> rick_h_: call me
[23:30] <rick_h_> thumper: k, sec
[23:30] <ericsnow> menn0: can I give you a hand?
[23:31] <alexisb> thumper, AWESOME!!!!!!
[23:31]  * thumper runs to let the dog out
[23:31] <rick_h_> thumper: https://plus.google.com/hangouts/_/canonical.com/daily-standup?authuser=1
[23:32]  * fwereade also cheers at thumper
[23:33] <menn0> ericsnow: thanks but I don't think so. I need to get a branch landed and narrow down a rsyslog worker problem that only seems to happen on my machine
[23:33] <ericsnow> menn0: k, let me know if that changes (I should be on a little longer at least)
[23:46] <thumper> wallyworld_: I need to put our 1:1 off for 30 minutes
[23:46] <thumper> wallyworld_: is that ok with you
[23:46] <thumper> ?
[23:46] <thumper> just found something I was supposed to do an hour ago :-(
[23:46]  * thumper waits for 15s for a response
[23:47] <wallyworld_> thumper: sure, np
[23:47] <menn0> waigani: i've responded to your review
[23:57] <waigani> menn0: done
[23:58] <menn0> waigani: thank you
[23:59] <waigani> alexisb: ready when you are