[00:35] <veebers> wallyworld: I'm just about to head out for lunch, but I notice when running the grant/revoke test that the outpu of list-users seems to have changed again
[00:35] <veebers> I don't see display-name for users that are added in the output
[00:35] <wallyworld> display name is only displayed if there is one
[00:36] <wallyworld> extrernal users don't have a display name
[00:36] <wallyworld> otherwise the output is filled with empty attributes
[00:36] <wallyworld> the test should not be fragile though to break on such changes
[00:36] <wallyworld> it needs simply to parse the json or yaml
[00:37] <wallyworld> whether display name attribute is in the output should be immaterial
[00:37] <wallyworld> the parsed data will be the same
[00:37] <veebers> wallyworld: To be clear  it's expected to not show an empty display name?
[00:38] <wallyworld> in which type of output? json? yaml? tabular?
[00:38] <wallyworld> for json or yaml, it is immaterial whther empty displyaname is there or not, and the test should not depend on it
[00:39] <wallyworld> the parsed data is the same either way
[00:41] <veebers> wallyworld: json output, currently the test compares predefined datastructures against the resulting output.
[00:42] <veebers> I'm confident that this was working with the current assumptions (i.e. display-name: "") on Friday, is this a recent change?
[00:42] <wallyworld> yeah, can't recall exactly when it landed
[00:43] <veebers> wallyworld: Ok. I'll make the change to the test to not expect display-name when not set
[00:43] <wallyworld> that will be good, thanks
[01:40] <thumper> veebers: ping me when you are back
[01:50] <veebers> thumper: hey o/
[01:50] <thumper> veebers: hey ehy
[01:50] <veebers> thumper: sorry I left for the gym later than originally intended
[01:50] <thumper> that's fine
[01:50] <thumper> hangout?
[01:51] <veebers> sure thign
[01:51] <veebers> thumper: which one/
[01:52] <thumper> veebers: https://hangouts.google.com/hangouts/_/canonical.com/lxd?v=1471979335&clid=FD6B1EDF18B181C1&authuser=0
[01:52] <veebers> omw
[02:21] <veebers> wallyworld: would it take you less then 2 minutes to find the commit id for when empty display name was removed from juju output? Would be nice to include in the MP for this test :-)
[02:22] <wallyworld> probably, i'll look
[02:26] <wallyworld> veebers: it also omits last login time and date create if empty, but those will only be empty for external users. i assume the CI tests are not doing anything with eternal users yet (but they should at some point) edc0b5324b2a110eb838852f2c7bc5f26d627efd
[02:28] <veebers> wallyworld: awesome thanks. Yeah already ignores login/date stuff. We have a task for the external testing (that needs some fleshing out)
[02:28] <wallyworld> great
[02:31] <thumper> menn0: with you in a minute
[02:32] <menn0> ok
[02:33] <wallyworld> menn0: you going to add QA steps to your PR?
[02:33] <menn0> wallyworld: yes, working on that now
[02:33] <wallyworld> ok, awesome
[02:33] <menn0> wallyworld: turns out it's harder to QA than I realised
[02:33] <wallyworld> i can imagine
[02:45] <veebers> thumper: just saw the email response. I should be able to get the db dump, but not sure about access, that's more of a sinzui,balloons,tbaumann thing
[02:46] <thumper> veebers: just replied, apt install tmate
[02:46] <thumper> really cool
[02:47] <veebers> thumper: it's not really my machine to install or give access too :-\
[02:47] <veebers> thumper: although we can always ask for forgiveness
[02:51] <menn0> wallyworld: trying to do the QA steps for this PR has made me realise that I probably need to do the prechecks before waiting for agents to report that they're in readonly mode
[02:52] <wallyworld> hmmm, seems reasonable
[02:52] <menn0> wallyworld: otherwise when you have machines that are being provisioned or down, they'll never report that they're in readonly mode and it takes 15 mins before the migration is aborted
[02:53] <wallyworld> ouch
[02:53] <menn0> wallyworld: so ignore my PR for now. I'm going to do another one which swaps the phases around
[02:53] <wallyworld> i haven't read the PR yet :-)
[02:54] <menn0> wallyworld: ok np. that PR won't actually change, but it'll be easier to QA once I swap the phases
[02:54] <wallyworld> sgtm
[03:23] <thumper> menn0: big problem was out of date lxd container
[03:23] <thumper> had an old lxd package
[03:23] <thumper> which blocked on things
[03:23] <thumper> updating containers fixed the CI test
[03:23] <menn0> thumper: how did you update the containers?
[03:24] <thumper> apt update && apt upgrade
[03:25] <wallyworld> thumper: why the fark wouldn't CI ensure it pulled the latest packages to test with ie what our customers are actually going to use?
[03:25] <thumper> wallyworld: these are long standing lxd machines that are just stopped / started for the ci tests
[03:25] <thumper> they just got out of date
[03:26] <wallyworld> hmpf. they should be kept up to date :-)
[03:26] <thumper> yes, they should
[03:42] <natefinch> wallyworld: I have some questions about the certupdater, got few minutes?
[03:42] <wallyworld> ok
[03:43] <natefinch> wallyworld: so, the certupdater has a watcher that watches the addresses of the machine it's on.... which seem to be different than the addresses in APIHostPorts.... shouldn't it watch APIHostPorts?
[03:44] <wallyworld> not sure tbh. it needs to update the cert SAN list with whatever wget on the instance nodes connects back to
[03:44] <wallyworld> i can't remember where wget gets it's info from
[03:45] <wallyworld> how is APIHostPors different to the machine addresses?
[03:45] <natefinch> wallyworld: the issue seems to be that the machine's list of addresses for manual provider don't include the cloud-local address, but the APIHostPorts does include that address
[03:45] <natefinch> wallyworld: I guess the other question is.. where does the machine's address list get populated?
[03:46] <wallyworld> i know there's an instance poller on clouds
[03:46] <wallyworld> and i think there's somewhere else that queries any machine NICs
[03:48] <wallyworld> natefinch: i looked at the code - it does use apihost ports initially
[03:48] <natefinch> wallyworld: yeah, the apihostports initially don't have the cloud-local, but they get updated
[03:49] <wallyworld> so why wouldn't the updated addresses get populated in the machine addresses
[03:49] <natefinch> not sure if that's a race condition or what, but they get updated with cloud local later... but since the certupdater isn't watching apihostports, it doesn't get the new address
[03:49] <natefinch> good question.  I don't know
[03:49] <wallyworld> i think the assumption is that they would. i'd have to go through the code to see what's happening
[03:50] <wallyworld> trace what is updaing apihostports
[03:52] <natefinch> ok, I'll try that and see why it's not also updating the machine addresses
[03:54] <wallyworld> that's a good starting point
[04:43] <natefinch> it's turtles all the way down :/
[04:50] <thumper> menn0: http://pastebin.ubuntu.com/23106006/
[04:50]  * thumper sighs
[04:50] <thumper> menn0:  http://reviews.vapour.ws/r/5552/
[04:51] <thumper> menn0: as discussed, moved the introspection worker out of the engine
[04:53] <menn0> thumper: give me a sec
[04:53] <thumper> no worries
[04:54] <menn0> thumper: swap you: http://reviews.vapour.ws/r/5551/
[04:55] <thumper> ok
[04:55] <menn0> thumper: I was initially going to swap PRECHECK and QUIESCE but then it occurred to me that we didn't actually need both phases
[04:55] <thumper> ok...
[04:56] <menn0> thumper: the prechecks are now just done at the start of the QUIESCE phase, at the same time as the agents are going to readonly mode
[04:56] <thumper> menn0: why all the phase changes from "PRECHECK" to "IMPORT"?
[04:56] <thumper> in the first file
[04:57] <menn0> thumper: because PRECHECK no longer exists. IMPORT is now next phase after QUIESCE
[04:57] <thumper> ok
[04:57] <menn0> thumper: so you didn't mean to show me juju-engine-report ?
[04:57] <menn0> looks pretty useful
[04:57] <thumper> menn0: well, that is in the review QA
[04:57] <thumper> but pasted the wrong buffer
[04:59] <menn0> got it
[05:13] <menn0> thumper: review done. just little things.
[05:14] <thumper> menn0: ta
[05:24] <thumper> menn0: replied, would like your thoughts before I do much else
[05:24] <menn0> thumper: looking
[05:26] <menn0> thumper: where does the contents of introspectionWorkerBashFuncs get put by cloud-init?
[05:29] <menn0> thumper: never mind... I checked myself
[05:34] <menn0> thumper: replies done.
[05:35] <thumper> ta
[05:35]  * thumper is off now
[05:35] <thumper> see y'all tomorrow
[05:37] <menn0> wallyworld, thumper: presence doesn't appear to be working at all... I shut down a machine agent 20 mins ago and it still has a status of "started"
[05:37] <wallyworld> awesome
[05:39] <menn0> wallyworld: it works for unit agents but doesn't appear to work for machines
[05:43] <menn0> I have a terrible theory...
[05:44]  * menn0 checks
[08:13] <wallyworld> axw: if you have a moment, not urgent, i have a PR which tweaks some bootatrap messages http://reviews.vapour.ws/r/5553/
[08:14] <axw> wallyworld: looking
[08:14] <axw> wallyworld: " - juju-b01da0-0 ted"   <- what is ted?
[08:16] <wallyworld> axw: damn. there was some code to move the cursor to start of line line and it looks like a message has changed in length
[08:16] <wallyworld> i'll have to add padding or something
[08:17] <wallyworld> looks like we just got lucky before
[08:17] <wallyworld> i didn't even notice :-)
[08:29] <wallyworld> axw: added padding to width of 40, seems reasonable to me as other messages printed are a bit more than that
[08:29] <wallyworld> other messages during bootstrap i mean
[08:29] <wallyworld> not other messages on that line that is overritten
[08:34] <axw> wallyworld: there are terminal escape codes for clearing lines, but I'm not sure about portability. seems reasonable.
[08:34] <axw> (what you've done; LGTM)
[08:35] <wallyworld> axw: yeah, i was afraid to mess with such things and screw up on windows etc
[08:35] <wallyworld> or when we pipe etc
[12:02] <perrito666> morning
[12:32] <wallyworld> fwereade: you around?
[12:32] <fwereade> wallyworld, o/
[12:33] <wallyworld> hey
[12:33] <wallyworld> fwereade: question for you
[12:33] <fwereade> wallyworld, sure
[12:33] <fwereade> wallyworld, (it's quiet today... uk bank holiday... maybe more?)
[12:35] <wallyworld> i think you were starting to look at refactoring state a bit. perrito666 has an issue where there's the mdel manager facade which has a controller connection, hence it's state has the controller model uuid. but beng a model manager facade, it needs to operate on mulitple models. so the facade needs to use a state with a given model uuid assigned to it so that the correct model uuid is automatocally used with the doc ids. but state.
[12:35] <wallyworld> ForModel() starts all the listeners etc. what's needed is just the newState() bit which constrcuts a state without all the other stuff just to allow collections to be correctly read and written
[12:35] <wallyworld> does that make sense?
[12:36] <fwereade> wallyworld, perrito666: I think the abstraction you are looking for is a state.Database
[12:36] <perrito666> actually we should actually refactor some endpoints, the split of facades into controller or models was a bit careless, some facades needed a bit of split
[12:36] <wallyworld> one option discussed with menno is to use the state pool
[12:37] <wallyworld> i've not come across the state database, will need to look
[12:37] <fwereade> wallyworld, perrito666: in particular if you sometimes want a collection to be global and sometimes not, I think the RTTD is to create databases with different schemas and use those
[12:37] <wallyworld> all that's needed is a state object without all the listener stuff, but which does the model uuid thing
[12:37] <fwereade> wallyworld, perrito666: yes
[12:37] <fwereade> wallyworld, perrito666: that is what Database does
[12:38] <wallyworld> ah ok, that's what we want then :-)
[12:38]  * perrito666 goes reading
[12:38] <perrito666> why didn't I know of this before?
[12:38] <fwereade> wallyworld, perrito666: it's still internal to state but I'm 99% sure it's the piece closest to what you need
[12:38] <wallyworld> if it does what i stat above, then awesome
[12:39] <fwereade> perrito666, not sure, but if you've used allcollections.go the Database is the thing whose operation/structure is defined by it
[12:39] <fwereade> perrito666, well, the database, which happens to implement Database
[12:39] <wallyworld> i'll leave you guys to it, need to go get my son from work
[12:39] <fwereade> wallyworld, o/
[12:40]  * wallyworld the match maker :-)
[12:40] <fwereade> <3
[13:22] <rock__> Hi. I have juju openstack depolyed setup on LXD. Unfortunately I did #juju logout --force. Now I am not able to see #juju status. i tried to do #juju login  but it was asking username and password. In  username and password.  username and password. It has default credentials?
[13:22] <rock__> .
[13:23] <rock__> In .local/share/juju/accounts.yaml is empty
[13:24] <rock__> How can I get my previous setup?
[13:24] <rock__> please help me in this.
[13:51] <mup> Bug #1617526 changed: cmd/juju: no help available for common flags <help> <ui> <juju:New> <https://launchpad.net/bugs/1617526>
[13:51] <mup> Bug #1617602 changed: juju status <service-name> stuck <status> <juju:New> <juju-utils:New> <https://launchpad.net/bugs/1617602>
[13:51] <mup> Bug #1617820 changed: JUJU fails in bootstrapping used with openstack <conjure-up:New> <juju:New> <https://launchpad.net/bugs/1617820>
[14:03] <natefinch> standup for rick's juju core team standup thing  (do we have a standup?)
[14:04] <natefinch> I mean, we do have a standup.. but it's kinda barren
[14:06] <natefinch> oh, public holiday in the UK kinda decimates our standup
[14:15] <beisner> hi juju devs - is there a way to recover the credentials if a user --forces logout before changing the initial account password?  (fyi rock__ ^)
[14:19] <perrito666> beisner: I honestly dont know
[14:19] <beisner> it seems like 'no' given the warning http://pastebin.ubuntu.com/23107425/
[14:53] <rock__> beisner: I got the same as  http://pastebin.ubuntu.com/23107425/. then I ran #juju logout --force.  From that onwards I am not able to see #juju status. And I am not able do #juju login back due to loss of account password.
[14:54] <mup> Bug #1617602 opened: juju status <service-name> stuck <status> <juju-core:Incomplete> <juju-utils:New> <https://launchpad.net/bugs/1617602>
[15:03] <beisner> rock__, right, i think it is expected that you set the password to a known-value before logging out.
[15:04] <rock__> beisner: Now we can't do anything right.
[15:35] <beisner> rock__, as far as i know, the creds are required in order to interact with the existing model
[15:35] <rock__> beisner: OK. thank you.
[15:36] <beisner> rock__, yw.  sorry i don't have a better answer on that.
[15:37] <natefinch> There's probably a way to hack it if you can log into the controller machine and then twiddle with the database directly.  I don't have a concrete list of steps to do that, though
[15:38] <rock__> beisner: It is Ok. You provided me good info.
[15:42] <rock__> When I run #juju status. It was giving : ERROR No controller.  Please either create your own new controller using "juju bootstrap" or connect to another controller that you have been given access to using "juju register".
[15:44] <redir> morning
[18:10] <natefinch> mental note: bootstrapping to a pre-existing machine with manual is faster than even lxd
[19:46] <thumper> morning folks
[20:00] <katco> heya thumper
[20:01] <thumper> katco: morning
[20:13] <alexisb> morning thumper
[20:38] <sinzui> ses_: https://hangouts.google.com/hangouts/_/canonical.com/curtis
[20:48] <natefinch> thumper: is there a way to make loggo print out milliseconds in the timestamp?  it would help when using grep during busy periods in the log
[20:49] <thumper> natefinch: with debug-log, yes
[20:49] <thumper> --ms
[20:49] <thumper> not for the default file writers
[20:49] <thumper> but the logs in the db have full time precision
[20:49] <thumper> and debug-log can now show that
[20:50] <natefinch> thumper: ahh, that's too bad
[20:50] <thumper> actually...
[20:50] <thumper> I added an environment variable for the default logger
[20:50] <thumper> which is to the terminal
[20:50] <thumper> but not for the file writers
[20:51] <natefinch> thumper: this is 1.25... looks like no --ms on debug-log there
[20:52] <thumper> natefinch: export LOGGO_TIME_FORMAT="15:04:05.000"
[20:52] <thumper> natefinch: see if that helps :)
[20:54]  * natefinch just hacks the loggo source...
[20:57] <redir> use the source nate
[20:57] <katco> anyone have an opinion of where this should live? https://github.com/juju/juju/blob/master/cmd/juju/application/store.go#L155-L166
[20:58] <katco> candidates i have found are: github.com/juju/juju/charmstore gopkg.in/juju/charmrepo
[20:58] <thumper> katco: I think it would be nice to have some package that encapsulates juju's interaction with the charmstore
[20:58] <thumper> but no idea where
[20:58] <thumper> perhaps your first choice?
[20:58] <katco> thumper: i think that might be github.com/juju/juju/charmstore?
[20:58] <thumper> but I don't know what is in there now
[20:58] <thumper> seems reasonable to me from a distance :)
[20:59] <katco> thumper: i will consider that an affirmation from a verified expert whose word is ironclad and whom i can blame when this blows up.
[21:01] <thumper> haha
[21:03] <alexisb> thumper, do you ahve time to run through bugs with me?
[21:03] <alexisb> or are you on other tasks
[21:03] <thumper> alexisb: I'm trying to finish off a branch from yesterday
[21:03] <thumper> if you can live without me
[21:03] <alexisb> thumper, sure
[21:49] <perrito666> k running a long test, bbl
[21:57] <alexisb> redir, menn0 did the fix in mgo needed for this bug land yet? : https://bugs.launchpad.net/juju/+bug/1604817
[21:57] <mup> Bug #1604817: Race in mgo Stats implementation <ci> <intermittent-failure> <race-condition> <regression> <unit-tests> <juju:In Progress by reedobrien> <https://launchpad.net/bugs/1604817>
[21:57] <redir> alexisb: I haven't seen anything on the upstream PR
[21:57]  * menn0 double checks
[21:58] <menn0> alexisb: nope, no response on that one
[21:58] <alexisb> k
[21:59] <alexisb> wallyworld, is this still a valid bug: https://bugs.launchpad.net/juju/+bug/1612717
[21:59] <mup> Bug #1612717: Pinger facade not implemented on controller websocket connection <juju:Triaged> <https://launchpad.net/bugs/1612717>
[21:59] <wallyworld> not sure, hasn't seen it
[21:59] <wallyworld> probably it could be
[22:00] <wallyworld> seems like fallout from rog's work
[22:02] <alexisb> thanks wallyworld; following up with that team
[22:32] <wallyworld> alexisb: thumper: are we having this meeting?
[23:16] <alexisb> redir, menn0 ping
[23:17] <redir> alexisb: ack
[23:17] <redir> pong
[23:17] <redir> whatever
[23:17] <alexisb> redir, standup
[23:17] <redir> doh!
[23:17] <redir> brt
[23:39] <wallyworld> redir: looking at your branch now
[23:39] <redir> wallyworld: tx
[23:46] <wallyworld> redir: lgtm with a couple of small things
[23:47] <redir> wallyworld: tx