[01:50] <hazmat> davecheney, the newer samsung ssds (830?) are 7mm
[01:51] <davecheney> hazmat: yeah, i'll have to get one of those
[01:51] <davecheney> hazmat: for a moment I considered taking the metal case off my sandforce
[01:51] <davecheney> but only for a moment
[06:30] <TheMue> davecheney, fwereade, rogpeppe: Morning.
[06:30] <fwereade> TheMue, heyhey
[06:30] <fwereade> and everyone else :)
[06:32] <bigjools> fwereade: o/
[06:33] <fwereade> bigjools, heyhey
[06:33] <bigjools> who do I bug to get my branches reviewed today? :)
[06:34] <fwereade> bigjools, consider me bugged, I'll do that now :)
[06:34] <bigjools> tip top, thanks
[06:43] <fwereade> bigjools, one minor on https://code.launchpad.net/~julian-edwards/juju/maas-provider-non-mandatory-port/+merge/107577
[06:43] <bigjools> yup?
[06:43] <fwereade> bigjools, just _s for unused vars
[06:44] <fwereade> bigjools, otherwise both LGTM
[06:44] <fwereade> hazmat, ping
[06:44] <bigjools> fwereade: is that some juju convention?
[06:44] <bigjools> (for reference)
[06:45] <fwereade> bigjools, my heart says it is, but I couldn't point you to a document saying so
[06:45] <bigjools> heh
[06:45] <bigjools> fwereade: so: _s, port, _s = connect_call.args
[06:45] <bigjools> ?
[06:46] <fwereade> bigjools, soory, _
[06:46] <fwereade> bigjools, I should have said `_`s or something
[06:46] <bigjools> right, makes more sense now!
[06:47] <bigjools> fwereade: ok change pushed up, thanks muchly
[06:47] <fwereade> bigjools, also I'm not sure what the current datekeeper rules are for python; I'll have a word with hazmat when he's around and either extract more approves if required, or just merge them
[06:47] <bigjools> you will land them right?
[06:48] <fwereade> gatekeeper
[06:49] <fwereade> bigjools, (I should probably just land them but I'm reluctant to come charging back into the python without checking)
[06:49]  * bigjools nods
[06:59] <fwereade> bcsaller, ping
[07:00] <hazmat> fwereade, pong
[07:14] <davecheney> fwereade: rogpeppe TheMue does anyone have any comments about testing commands and package main_test ?
[07:15] <fwereade> hazmat, sorry: what are the current landing requirements for juju? bigjools has a couple of patches I'm happy with myself... what else should be done before landing?
[07:16] <hazmat> fwereade, the sru just landed
[07:16] <hazmat> for the connect args, i think in this case its actually more helpful to have the args documented.. its a completely mocked situation
[07:17] <fwereade> davecheney, I'm not sure my own preferences are useful... main_test seems to me like the obvious and sane thing to do but if it's flaky I guess we should do things differently
[07:17] <fwereade> hazmat, heh, sorry
[07:17] <hazmat> fwereade, and those params are never checked anywhere else in the codebase
[07:17] <TheMue> davecheney: Not yet. So far I had no main commands to test.
[07:17] <hazmat> so its completely unclear what they are if their ellidded
[07:17] <hazmat> bigjools, ^ sorry
[07:19] <hazmat> bigjools, actually i'd take the reverse notion.. and actually verify those values
[07:19] <davecheney> fwereade: for a long time gotest didn't work with main packages
[07:19] <hazmat> since their not really checked otherwise
[07:19] <hazmat> which is the root cause of this bug
[07:20] <davecheney> as they are the end of the line, dependency wise
[07:20] <davecheney> all the other code i've found that does test main, tests it inside package main
[07:20] <davecheney> i don't think there is a problem doing unit tests inside the package you are testing
[07:20]  * hazmat checks tests_auth
[07:21] <fwereade> davecheney, putting the tests in the package you're testing feels icky to me; but like I said, if main_test is flaky and not expected to be fixed any time soon, I guess we should just change them
[07:23] <davecheney> fwereade: you aren't putting them in the same package, well, only when testing, but there is no other way to test unexported functions
[07:24] <davecheney> anyway, i've got to go
[07:24] <davecheney> i'll see you on the flip side
[07:26] <hazmat> fwereade, trunk is green for this fix
[07:26] <hazmat> fwiw
[07:29] <fwereade> hazmat, ok then, I'll land them both once the change you asked for is done
[07:29] <fwereade> hazmat, cheers
[07:29] <hazmat> fwereade, thanks
[07:36] <rogpeppe> fwereade, TheMue, hazmat: mornin' all
[07:37] <fwereade> rogpeppe, heyhey
[07:37] <hazmat> g'night all
[07:45] <bigjools> hazmat: ok I'll reverse the last commit
[07:45] <bigjools> I did think it was rather odd to remove useful variable names :)
[07:46] <hazmat> when their well known and unused, we do tend to elide them.. but this is a special case.. since their effectively unknown.
[07:47] <bigjools> well they are test case logs
[07:47] <bigjools> the other ones are tested elsewhere
[07:48] <bigjools> hazmat: ok pushed up
[07:48] <hazmat> bigjools, are they? :-)
[07:48] <hazmat> bigjools, i couldn't find anywhere else where args was looked at
[07:49] <hazmat> bigjools, thanks
[07:50] <bigjools> I t hought I'd seen it somewhere
[07:50] <bigjools> my brain ceased to function 30 minutes ago, it's been a long day
[07:51] <bigjools> hazmat: ah just saw your paste, I'll poke that in too, one sec
[07:53] <hazmat> cool
[07:53]  * hazmat gives up on going back to sleep
[07:53] <bigjools> and pushed
[07:54]  * bigjools looks forward to a merge email
[08:53] <hazmat> bigjools, shouldn't this also do port 443 for https?
[08:58] <rogpeppe> fwereade: i've been looking at CL 6244060. i *think* that having multiple zk Servers sitting around in dummy isn't a good idea.
[08:59] <fwereade> rogpeppe, I'm somewhat ambivalent, but I think in practice that when one is added we will remember to defer a removal as well
[08:59] <rogpeppe> fwereade: i think we want to reuse the zk server regardless of the name that the test gives to the environment
[09:00] <rogpeppe> fwereade: how do we remove a server?
[09:00] <fwereade> rogpeppe, I guess doing it this way does effectively force us to use one dummy env name per package, which prevents us from encoding any helpful context in there
[09:00] <fwereade> rogpeppe, SetZookeeper("foo", nil)
[09:00] <rogpeppe> fwereade: that too
[09:01] <rogpeppe> fwereade: and if we're going to do that, why bother allowing multiple zk servers
[09:01] <rogpeppe> ?
[09:02] <rogpeppe> there's an alternative, actually
[09:02] <fwereade> rogpeppe, it seemed sensible to do that regardless... I think the issues are orthogonal?
[09:02] <fwereade> go on
[09:04] <rogpeppe> fwereade: hmm, another thought: why do we bother with SetZookeeper. why don't we let the dummy environ start its own zk?
[09:04] <rogpeppe> fwereade: then the dummy environ can manage the server "cache". (it could keep just one server around after a Reset)
[09:05] <fwereade> rogpeppe, hmm, how do we know when to shut the servers down?
[09:05] <rogpeppe> fwereade: oh yeah, good point. *that* was why :-)
[09:07] <rogpeppe> fwereade: anyway, i *think* we want to be able to reuse a zookeeper regardless of the name of the environ.
[09:08] <fwereade> rogpeppe, tbh that was my initial preference but we do seem to have multiple storages (right?) and consistency seems sensible
[09:09] <rogpeppe> fwereade: storage is *much* lighter weight than zk. and we trash all the storages after Reset.
[09:09] <rogpeppe> fwereade: i think the 10s startup overhead of zk means we will never want to start up two
[09:11] <fwereade> rogpeppe, my instinct says that indeed we won't, and that it will be much easier to note this and remove the capacity at some point in the future than it will to get into heavy discussions with niemeyer about it right now
[09:11] <fwereade> rogpeppe, my primary consideration, sad to say, is getting it merged so I can get to work on deploy without it being at the end of a looong pipeline of CLs under discussion ;)
[09:12] <niemeyer> Good mornings!
[09:12] <fwereade> niemeyer, heyhey!
[09:12] <rogpeppe> fwereade: i'm concerned that this kinda breaks the dummy environs model
[09:12] <rogpeppe> niemeyer: yo!
[09:12] <rogpeppe> niemeyer: just expressing mild concern about SetZookeeper taking an environ name
[09:13] <rogpeppe> niemeyer: we want the zk to be reused regardless of the name of the environment that's opened, i think.
[09:13] <niemeyer> fwereade, rogpeppe: No need to get into heavy discussions.. it was just an opinion.. happy to be shown the other side of it :)
[09:13] <niemeyer> rogpeppe: So what's the point of having environment names in the dummy provider?
[09:13] <fwereade> niemeyer, my personal view is that the cost of either approach is dwarfed by the cost of talking about it for more than 20s ;)
[09:14] <niemeyer> rogpeppe: Environment names explicitly enable talking to completely different environments
[09:14] <rogpeppe> niemeyer: so we can open multiple environments. but Reset should reset everything
[09:14] <niemeyer> rogpeppe: If we have two different environments that have different internal representations but that in fact are the same ZooKeeper state, isn't it the same environment?
[09:14] <niemeyer> rogpeppe: Agreed, but if we have a single ZooKeeper state, it's not multiple environments
[09:14] <rogpeppe> niemeyer: we weren't allowing that
[09:15] <rogpeppe> niemeyer: we weren't going to allow multiple zk environments
[09:15] <rogpeppe> niemeyer: because i don't think we'll ever actually want that
[09:15] <niemeyer> rogpeppe: There's no such thing as a "zk environment"..  an environment contains a ZooKeeper
[09:15] <rogpeppe> niemeyer: lots of tests use the dummy env without requiring zk
[09:15] <niemeyer> rogpeppe: If we have two environments with one zookeeper, we don't have two environments
[09:16] <niemeyer> rogpeppe: Yep, that sounds fine
[09:16] <rogpeppe> niemeyer: what sounds fine?
 niemeyer: lots of tests use the dummy env without requiring zk
[09:17] <niemeyer> fwereade: Do we have a use case for opening two environments with a single ZooKeeper?
[09:17] <fwereade> niemeyer, I don't think so
[09:17] <rogpeppe> niemeyer: at the same time, you mean?
[09:17] <niemeyer> fwereade: So what's the concern?
[09:18] <niemeyer> fwereade: I'm concern we're modeling something unrealistic in the dummy environment
[09:18] <rogpeppe> niemeyer: we don't want to restart zk every time we start a test.
[09:18] <niemeyer> fwereade: But doing dummy.SetZooKeeper("name", zk) vs dummy.SetZooKeeper(zk) execute in the same amount of test
[09:18] <niemeyer> erm
[09:18] <niemeyer> of time
[09:18] <fwereade> niemeyer, from my perspective, that it's just more bookkeeping... I expect to run a bunch of sequential tests, each of which uses a dummy env, and which in practice may as well all use the same ZK
[09:18] <niemeyer> rogpeppe: Yep.. agreed
[09:19] <niemeyer> fwereade: Sounds fine too?
[09:19] <fwereade> niemeyer, doing this effectively means we either need multiple zookeepers, or to explicitly set multiple envs to use the same one, if we ever want to use different env names
[09:20] <fwereade> niemeyer, but I really have no horse in this race, I think the cost is minimal either way and I'm happy enough with either approach
[09:20] <niemeyer> fwereade: The cost is zero if we're never doing that.. and if we ever do it we can consciously choose to assign to the same ZooKeeper, right?
[09:21] <niemeyer> fwereade: I guess I'm still lacking what's the argument against making the interface of the dummy provider a bit more realistic in terms of what happens
[09:21] <niemeyer> fwereade: We're debating about SetZooKeeper(name, zk) vs. SetZooKeeper(zk), right?
[09:22] <rogpeppe> niemeyer: i like the fact that dummy.Reset forgets all environ names
[09:22] <fwereade> niemeyer, the cost is (1) a little bit of extra bookkeeping code and (2) consciously choosing to set up extra zookeepers in the package test function
[09:22] <niemeyer> rogpeppe: Sure, so continue doing that.. (?)
[09:22] <rogpeppe> niemeyer: but if we add SetZooKeeper(name, zk) that name remains around
[09:22] <rogpeppe> niemeyer: even after Reset
[09:22] <fwereade> niemeyer, like I say, not enough for me to worry about
[09:23] <niemeyer> rogpeppe: I don't get it.. are you suggesting that Reset() won't reset what SetZooKeeper does? That sounds weird
[09:23] <rogpeppe> niemeyer: if it does reset it, then we'll need to call SetZooKeeper on every test
[09:23] <fwereade> niemeyer, ah, hmm, so Reset() should clear all zookeepers and each test should explicitly set one at the start?
[09:23] <fwereade> niemeyer, that does feel heavyweight to me
[09:23] <rogpeppe> niemeyer: perhaps that's what we should be doing i guess
[09:24] <fwereade> niemeyer, having the magic test ZK in python felt like a win to me tbh
[09:24] <niemeyer> fwereade: Assigning an entry to a map sounds heavyweight?
[09:24] <niemeyer> fwereade: Reset resets everything else in Dummy.. why is it not acting on what SetZooKeeper does?
[09:24] <fwereade> niemeyer, keeping track of the zookeeper in each test package, rather than just in the package setup func
[09:25] <fwereade> niemeyer, Reset trashes the content of every active zookeeper
[09:25] <fwereade> niemeyer, what I'm trying to avoid is starting a fresh ZK for every test
[09:25] <niemeyer> fwereade: You don't have to start a fresh zookeeper.. trashing content != starting zookeeper
[09:25] <rogpeppe> niemeyer: the idea behind SetZooKeeper was "here is a zookeeper server; use it for a zk environment whenever it's opened"
[09:25] <niemeyer> fwereade: Each test *should* get a zeroed out zookeeper, right?
[09:25] <fwereade> niemeyer, agreed; and it does
[09:26] <niemeyer> fwereade: Ok, so I misunderstand your point
[09:26] <fwereade> niemeyer, what rogpeppe said^^
[09:26] <niemeyer> rogpeppe, fwereade: Sure.. how does that change what was just pointed out, thought?
[09:26] <fwereade> niemeyer, I think that allowing different ZKs for different envs is fine; I'm not sure we'll use it much in practice
[09:27] <niemeyer> fwereade: Agreed.. I'm not arguing that we use it.. I'm arguing that we don't have unrealistic scenarios for testing
[09:27] <niemeyer> fwereade: Two different environments in a configuration, with different names, will have different backing ZooKeepers
[09:28] <fwereade> niemeyer, and I can get behind that; I've proposed a CL that, I think, does make the scenario more realistic as you suggest, and I'm perfectly happy with it :)
[09:28] <rogpeppe> niemeyer: if we have Reset clear out all the zk servers too, then every test will need to call SetZooKeeper, which means that every test suite will need a zk server field. if we have just a single zk server instance, then we can do the setup exactly as we do in state.TestPackage
[09:29] <rogpeppe> niemeyer: will we ever want to have two different environments concurrently with different zookeepers?
[09:29] <rogpeppe> niemeyer: it's a heavy weight test and one i can't really see a reason for doing
[09:29] <fwereade> niemeyer, I'm not so keen on the idea of having a zkServer package var for every test package, and explicitly setting it as the dummy zookeeper in every test; is that what you're proposing?
[09:30] <rogpeppe> niemeyer: if you never want to do that (and you can make it panic if that ever happens accidentally) then the scheme is not unrealistic - it's indistinguishable, i think.
[09:30] <niemeyer> rogpeppe: <niemeyer> fwereade: Two different environments in a configuration, with different names, will have different backing ZooKeepers
[09:30] <niemeyer> rogpeppe: That's how environments work for real
[09:31] <rogpeppe> niemeyer: yes, but will we *ever* want to open two such environments *at the same time* in a test?
[09:31] <niemeyer> rogpeppe: If we're creating a dummy provider that works in a different way, it sounds like we're doing something wrong..
[09:32] <niemeyer> rogpeppe: You were the one changing the dummy package so it could take multiple environments with different names.. (!?)
[09:32] <rogpeppe> niemeyer: that's for basic tests that don't require zk.
 niemeyer: yes, but will we *ever* want to open two such environments *at the same time* in a test?
[09:33] <niemeyer> rogpeppe: That does answer your own question
[09:33] <rogpeppe> niemeyer: by "such environments" i meant environments with a backing zk instance
[09:34] <niemeyer> rogpeppe: We're going in circles. I've already pointed out the reasoning behind that. You can agree or disagree.
[09:34] <rogpeppe> niemeyer: the approach i'm suggesting is the same one taken by state, for instance - we have a single zk instance that is reused in each test.
[09:34] <niemeyer> rogpeppe: That's where our conversation started.
[09:35] <rogpeppe> niemeyer: so... should Reset forget the servers registered with SetZooKeeper?
[09:36] <niemeyer> rogpeppe: That was my expectation, but I guess the dummy package is being used in a different way than what I expected
[09:37] <rogpeppe> niemeyer: if so, i could live with that. it's another line in each test or suite that opens a zk environ, but the zookeeper.Server could live in a global var just like state.TestingZkAddr.
[09:37] <niemeyer> rogpeppe, fwereade: So far we set up the dummy package on each suite, I think
[09:38] <fwereade> niemeyer, ATM we set it up per package
[09:38] <fwereade> niemeyer, following the model in state
[09:39] <niemeyer> fwereade: The dummy package?  Do you have an example where we set it up per package I could look at in the current source?
[09:40] <rogpeppe> cmd/juju/cmd_test.go sets it up per test
[09:41] <niemeyer> Right, I meant an example where we use the dummy provider on a package context, rather than per test or suite
[09:41] <fwereade> niemeyer, only in https://codereview.appspot.com/6243067/ which technically doesn't exist yet
[09:42] <fwereade> niemeyer, (that's calling SetZookeeper in the package test func; did you mean something different?)
[09:42] <niemeyer> fwereade: Right, so that's why I was assuming a given way of using it, which doesn't match what you had in mind.. not saying either is right or wrong, but part of the argument originates there
[09:42] <fwereade> niemeyer, I'm just monkey-see-monkey-doing what we did for state wrt zookeepers; seems to work ok ;)
[09:43]  * fwereade wonders whether "following established conventions" is a better way of putting that ;)
[09:43] <niemeyer> fwereade: Yeah, you could have monkey-see-monkey-done what the dummy package currently do now as well, though :-)
[09:44] <fwereade> niemeyer, so it seems; state is the one I already knew :0
[09:44] <rogpeppe> fwereade: "blindly following over a cliff"?
[09:44] <fwereade> rogpeppe, if all your friends jumped off a cliff and it all seemed to be going just fine...
[09:45] <rogpeppe> fwereade: come on in, the water's lovely!
[09:46] <niemeyer> fwereade: Ok, let's just move back to the SetZooKeeper you had then.. it's very straightforward and will get you going
[09:46] <fwereade> niemeyer, the cost of setting up a ZK was a contributing factor... if that weren't a consideration I'd happily do everything per-suite
[09:46] <rogpeppe> anyway, to get back to the point. i think i'd be happy with either: one zk instance, reused automatically, as originally; or an explicit SetZookeeper required after Reset
[09:46] <fwereade> niemeyer, ok, cool
[09:46] <fwereade> niemeyer, cheers :)
[09:46] <niemeyer> fwereade: I'm happy to delay my preciousism in the design (if that's even a word) to a second moment
[09:46] <fwereade> niemeyer, and a panic if anyone tries to SetZookeeper while one is already set?
[09:47] <niemeyer> fwereade: The fact it matches what's being done with zookeeper now in terms of the test suite is what makes me more comfortable
[09:47] <rogpeppe> niemeyer, fwereade: thanks for bearing with me. i feel like i've been the precious one :-)
[09:47] <rogpeppe> fwereade: i don't see why we shouldn't allow SetZookeeper twice.
[09:48] <niemeyer> fwereade: Not sure.. how do you plan to reset the zk?
[09:48] <fwereade> rogpeppe, ah ok, perhaps I misremembered an earlier comment of yours
[09:48] <niemeyer> fwereade: as in, how do you plan to unset the package variable
[09:48] <fwereade> niemeyer, `defer SetZookeeper(nil)` in the package test func; clear contents on Reset() or Destroy()
[09:48] <niemeyer> fwereade: Ah, ok.. so accept nil, but not another zk
[09:48] <niemeyer> Anyway, I have to move rooms
[09:48] <fwereade> niemeyer, yeah
[09:49] <niemeyer> Which means I have to shutdown
[09:49] <niemeyer> :(
[09:49] <niemeyer> brb
[09:50] <rogpeppe> fwereade: what bad thing might happen if you allowed setting another zk?
[09:50] <fwereade> rogpeppe, having two zookeepers around :p
[09:50] <fwereade> rogpeppe, if someone comes up with a legitimate use case removing the panic is not hard
[09:51] <fwereade> rogpeppe, but trying to do so indicates to me that something is likely to be being Done Wrong
[09:52] <rogpeppe> fwereade: i'm not sure i see the big difference between { SetZookeeper(nil); SetZookeeper(anotherZk)} and SetZookeeper(anotherZk)
[09:53] <rogpeppe> fwereade: but i don't mind actually. require the SetZookeeper(nil) if you prefer.
[09:53] <fwereade> rogpeppe, in either case, assuming package-level setup, either you need to keep track of the original package ZK *or* someone has failed to clear it out from a previous package
[09:54] <rogpeppe> fwereade: i can't see how that would happen. we only test one package at a time, right?
[09:55] <fwereade> rogpeppe, and if a server from a previous package is still there, someone's ballsed something up
[09:55] <rogpeppe> fwereade: so it would only happen if we happened to call SetZookeeper twice in the same package. which could happen, i guess, but i don't see it as an easy-to-find failure mode.
[09:55] <fwereade> rogpeppe, fair enough :)
[09:55] <rogpeppe> fwereade: how could a server from a previous package still be there? they're different programs?
[09:55] <rogpeppe> s/\?$//
[09:56]  * fwereade waves his hands vaguely, then runs out of steam and slinks off lokking embarrassed
[09:56] <rogpeppe> :-)
[10:06] <fwereade> rogpeppe, should Destroy be clearing out the appropriate key in providerInstance.state (and closing the listener)?
[10:07] <rogpeppe> fwereade: erm, zookeeper.Server.Destroy?
[10:07] <fwereade> rogpeppe, sorry, dummy.environ.Destroy
[10:08] <rogpeppe> fwereade: i don't see that method. do you mean Reset?
[10:08] <rogpeppe> oh!
[10:08] <fwereade> rogpeppe, Reset clears them all
[10:08] <rogpeppe> just grepped the wrong dir
[10:09] <rogpeppe> i don't *think* so
[10:09] <rogpeppe> fwereade: it's not like s3 goes away when you destroy an environment
[10:10] <rogpeppe> fwereade: i think it's ok for Reset to do that job
[10:11] <rogpeppe> Aram: yo!
[10:11] <Aram> morni g all.
[10:11] <fwereade> rogpeppe, I'll read some more, see if I can figure out why your proposed tweak to open panics... that was just a half-formed hypothesis
[10:12] <TheMue> Aram: Hi
[10:12] <rogpeppe> fwereade: it could be that something's not calling Reset
[10:12] <fwereade> Aram, heyhey
[10:14] <fwereade> rogpeppe, HAHA DISREGARD THAT I wrote the code in the wrong place :/
[10:14]  * rogpeppe disregards it
[10:50] <rogpeppe> fwereade, TheMue, niemeyer: i'm wondering about the way that we manage the state with watchers. if i'm watching something, i'll get a notification that something has happened to it (because its config node changed, for example) but then i have to re-read the same info from zk if i want to find out attributes of the object. but the info might have changed - the info i see might not be consistent with what i'm told
[10:51] <rogpeppe> i'm wondering if a model where each kind of thing (Unit, Service, Machine) caches the info that was known when it was created.
[10:51] <rogpeppe> s/if a/about a/
[10:51] <TheMue> rogpeppe: Typically the specialized watchers return the needed info.
[10:52] <TheMue> rogpeppe: So in your case a watcher returns an info but you need a different one depending on it?
[10:52] <rogpeppe> TheMue: i'm looking at doing a unit watcher. the obvious thing to do is have the channel sending *Units that have been added or removed.
[10:52] <niemeyer> rogpeppe: That's what the machine watcher does..
[10:53] <rogpeppe> TheMue: but if i want to get any info out of those units, i have to reread it
[10:53] <rogpeppe> niemeyer: yeah, and i'm a bit concerned about it
[10:53] <niemeyer> rogpeppe: No, you're not re-reading.. you're reading.. the information out of those units wasn't read before
[10:53] <niemeyer> rogpeppe: There are different ways to model that problem for sure
[10:54] <niemeyer> rogpeppe: And perhaps the model we have in place today isn't the best one, but changing it will incur in other issues
[10:54] <rogpeppe> niemeyer: ah, that's true. the info *about* the units is in the topology, but the info *of* the units is in the unit's config node, right?
[10:54] <niemeyer> rogpeppe: Yep
[10:54] <niemeyer> rogpeppe: So, in either case, I suggest not modifying that today so that we can move forward
[10:54] <TheMue> rogpeppe: Nice description, yes.
[10:56] <niemeyer> rogpeppe: I do think eventually we'll want to cache more than we do, but that can't be done without pondering further about the algorithms
[10:56] <rogpeppe> niemeyer: it doesn't seem that that's entirely true. i'm looking at AssignedMachineId and it reads the topology. to find new units, i'm going to need to watch the toplogy. so i'll be reading the toplogy for every unit as well.
[10:57] <TheMue> niemeyer: The test of store fails for me due to a not matching error message in lpad_test.go:42:. Is that only here or well known?
[10:57] <niemeyer> rogpeppe: Yeah, it's a mix of both
[10:59] <niemeyer> TheMue: Certainly not well known by me.. trunk should never be broken
[11:00] <rogpeppe> a possible model to consider for the future: each object acts as a local cache of some state. it only goes to zk when it doesn't already hold that state. an Update method could be implemented on each type to fetch new values from zk.
[11:00] <niemeyer> rogpeppe: Yeah
[11:00] <rogpeppe> TheMue: tests all pass for me
[11:01] <TheMue> niemeyer: Ah, found the error. It's the locale. So bzr returns a German message here while an English one is expected in the test. (sigh)
[11:01] <rogpeppe> niemeyer: that way most methods could lose their error return perhaps - the only place returning an error would be on Update.
[11:01] <TheMue> rogpeppe: See above, it's my locale.
[11:02] <rogpeppe> TheMue: ah. useful to have someone in a different language locale!
[11:02] <TheMue> rogpeppe: Yes. While our own messages are all English the ones of external tools may vary.
[11:03] <niemeyer> rogpeppe: and then all writes have to be cached as well?  That would mean the flush operation could fail, and we wouldn't know why.. which means we'd have to implement retry points that don't really know what is being retried
[11:03] <niemeyer> rogpeppe: etc
[11:04] <rogpeppe> niemeyer: no, i think writes would just write through
[11:04] <niemeyer> rogpeppe: It's a different model.. worth thinking about at some point.. not obviously better
[11:05] <TheMue> rogpeppe: As long as we don't have any problem with re-reading I won't do an application based caching. This may be task of the backend (like ZK, Mongo, whatelse).
[11:09] <rogpeppe> niemeyer: it's this kind of thing that concerns me: client A watches units. client B changes unit 1 to X. client A observes change X. client B changes unit 1 to Y. client A reads Y. client A observes change Y. client A reads Y.
[11:10] <niemeyer> rogpeppe: How's that an issue?
[11:11] <rogpeppe> niemeyer: it's very inefficient, particular when we're observing the topology and it's getting large.
[11:11] <rogpeppe> niemeyer: maybe i shouldn't worry about efficiency here though.
[11:12] <niemeyer> rogpeppe: Yeah, let's make it work first
[11:12] <niemeyer> rogpeppe: Reliably
[11:13] <niemeyer> rogpeppe: Note that, in your example, even if we cached the data and client B read X instead, there would be a second notification
[11:13] <rogpeppe> niemeyer: it's reliability i'm concerned about too. working on a slightly newer version than we've just been told about. maybe it's not an issue, but it seems potentially problematic.
[11:13] <niemeyer> rogpeppe: We haven't been told about anything.. we have simply been notified that a changed happened
[11:13] <rogpeppe> niemeyer: yeah, there are two changes, so there would be two notifications
[11:14] <rogpeppe> niemeyer: we've been told that some new units have been created, for example.
[11:14] <niemeyer> rogpeppe: Yes, we have, but that's unrelated to your example
[11:14] <rogpeppe> niemeyer: and we *did* know some info about those units, but we've thrown it away
[11:14] <niemeyer> rogpeppe: Yes, but that's unrelated to reliability
[11:16] <rogpeppe> the caching model seems to me like it has less potential for odd race conditions.
[11:18] <rogpeppe> niemeyer: anyway, food for thought.
[11:18] <hazmat> rogpeppe,  agreed it is inefficient
[11:19] <hazmat> rogpeppe, the other options are to have some notion of logical transactions that the topology records for
[11:19] <hazmat> not nesc. the 3.4 multi-node txn, but a logical  one where we carry the topology across multiple ops
[11:19] <hazmat> just to be clear its not a race condition per se that its avoiding, its the spurious notifications caused by every state change, that may actually compose a larger logical op
[11:20] <hazmat> but really the largest source of spurious notifies, is everything listening to the topology, getting hit by notifications they don't care about
[11:20] <rogpeppe> hazmat: yeah that's true
[11:21] <niemeyer> rogpeppe: Indeed, I do think those are good ideas, and that there's something there for us to evolve towards
[11:21] <rogpeppe> hazmat: but it doesn't help when we've been listening to the topology, we're told that it's changed and what it changed to, and then we do a round trip just to fetch it again.
[11:22] <niemeyer> rogpeppe: We quickly did that when we started.. but didn't quite work well
[11:22] <niemeyer> Luncnh time
[11:22] <rogpeppe> niemeyer: did what, sorry?
[11:23] <hazmat> as an alternative i think we either need to carefully devolve into multiple topo indexes, and/or starting using multi-node transactions..
[11:23] <hazmat> rogpeppe, that's the nature of watches
[11:24] <hazmat> rogpeppe, oh.. we got told what it changed to?
[11:24] <rogpeppe> hazmat: ah, no, of course. in this case we're doing a round trip to fetch it. and then another round trip to fetch it again.
[11:25] <hazmat> rogpeppe, ah
[11:26] <hazmat> rogpeppe, we did briefly experiment with an up to date object cache, but lacking transactions or pub/sub events (from watches), it ended up just being more complexity imo.
[11:27] <hazmat> rogpeppe, but if you could interject into the watch channel to an object cache invalidation protocol it might have some value, but effectively anything in cache would need to be watched
[11:27] <hazmat> else it could be stale
[11:27] <rogpeppe> hazmat: i wasn't thinking of a global cache, just a local cache for an object when you read it.
[11:27] <hazmat> alternatively work with an operation context, like a transaction scope
[11:27] <hazmat> er. scoped cache
[11:28] <rogpeppe> hazmat: and a way of saying "please update"
[11:28] <hazmat> rogpeppe, yeah.. that makes sense, but speaking of race conditions ;-)
[11:28] <hazmat> its unavoidable i suppose, the local cache gives a consistent view at least
[11:28] <rogpeppe> hazmat: yeah, that's my thought
[11:28] <hazmat> we always have to consider the possibility of state change
[11:29] <rogpeppe> hazmat: indeed.
[11:29] <hazmat> but if we go to modify a cached obj, we have to reconcile current state and modifications, not cache state and mods
[11:29] <rogpeppe> hazmat: but it can change when we ask it to
[11:29] <hazmat> ie. capture versions
[11:29] <hazmat> at a min or use retry change utilities
[11:29] <rogpeppe> hazmat: i'd be happy with a write-through cache
[11:30] <rogpeppe> hazmat: it doesn't solve all the problems, but it alleviates the worst
[11:30] <hazmat> niemeyer, are you in uk?
[11:30] <rogpeppe> hazmat: he is
[11:30]  * hazmat notes its not lunch time yet ;-)
[11:30] <hazmat> rogpeppe, cool, is there a gojuju sprint going on?
[11:30] <rogpeppe> hazmat: nope
[11:31] <rogpeppe> hazmat: niemeyer's at some sprint in london
[11:31] <hazmat> we should get a juju sprint  going on
[11:31] <hazmat> i can't even remember the last sprint we had
[11:31] <hazmat> like august of last year maybe..
[11:31] <rogpeppe> hazmat: +1
[11:32] <rogpeppe> hazmat: i haven't done a sprint yet
[11:32] <hazmat> we should fix that..
[11:32] <TheMue> rogpeppe, hazmat: Isn't something planned when Mark is on board?
[11:32] <hazmat> i dunno
[12:52] <niemeyer> rogpeppe: ping
[12:53] <rogpeppe> niemeyer: pong
[12:53] <niemeyer> rogpeppe: Yo
[12:53] <niemeyer> rogpeppe: Are you game to come tomorrow and return on Friday?
[12:53] <rogpeppe> niemeyer: i think so
[12:53] <niemeyer> rogpeppe: Awesome, sorting out hotel
[12:53] <rogpeppe> niemeyer: will just have a word with carmen
[12:53] <niemeyer> rogpeppe: Cheers
[12:57] <fwereade> rogpeppe, any particular reason StorageReader.URL doesn't return a url.URL?
[12:58] <Aram> niemeyer: eager to meet you tomorrow!
[12:58] <Aram> anyone else there?
[12:58] <niemeyer> Aram: Looking forward too
[12:58] <niemeyer> Aram: Lots of people, but no jujuers unfortunately
[12:59] <niemeyer> Aram: rog should come, thogh
[12:59] <niemeyer> though
[12:59] <Aram> great.
[13:35] <niemeyer> rogpeppe: Are we good to go?
[13:51] <fwereade> niemeyer, do I recall you saying we should revisit the way we handle unit placement in python?
[13:51] <fwereade> niemeyer, because we're aproaching the point at which we should be considering it :)
[13:51] <niemeyer> fwereade: Hmm.. not that I remember off hand
[13:52] <fwereade> niemeyer, jolly good then -- if it crosses your mind again, do let me know (I didn't see anything wrong with it myself, but...)
[14:04] <TheMue> niemeyer: I now start the go test with a temporary locale en_US. But now I've got this error: http://paste.ubuntu.com/1014818/
[14:06] <rogpeppe> niemeyer: yes.
[14:06] <rogpeppe> niemeyer: sorry about the wait. got into an involved discussio.n
[14:07] <niemeyer> rogpeppe: COol, thanks
[14:07] <niemeyer> rogpeppe: Moving forward then
[14:07] <rogpeppe> fwereade: there's no need for it to be a parsed URL. http.Get doesn't take a url.URL as an argument.
[14:07] <niemeyer> TheMue: Sorry, can't look at that now
[14:08] <TheMue> niemeyer: OK, no problem so far and doesn't hinder state development. ;)
[14:08] <rogpeppe> fwereade: a string seems a fine representation of a URL to me if you don't need to be looking inside it.
[14:09] <fwereade> rogpeppe, ah, ok; in that case the question becomes: TheMue, is there any particular reason AddCharm takes a url.URL?
[14:10] <TheMue> fwereade: Have to think back. IMHO because I'm getting it from an API call. One moment, I'll take a look.
[14:10] <fwereade> TheMue, thanks
[14:10] <rogpeppe> fwereade, TheMue: it looks like it could as well be a string, as all it does is call String on it...
[14:11] <rogpeppe> fwereade, TheMue: and charmData.BundleURL is a string
[14:11] <fwereade> rogpeppe, concur
[14:15] <TheMue> fwereade: Don't know the reason anymore, it became a URL during the discussion.
[14:16] <fwereade> TheMue, rogpeppe: any reason not to make it a string again?
[14:16] <TheMue> fwereade: Are there any problems with URL?
[14:16] <rogpeppe> TheMue: it's worth using the same representation for the same thing throughout, i'd say
[14:16] <fwereade> TheMue, just that it seems kinda silly to turn a string into a url just to turn it back into a string a few us later :)
[14:17] <rogpeppe> fwereade: +1
[14:18] <TheMue> rogpeppe: Same representation for the same thing: yes. A URL is a URL. ;)
[14:18] <TheMue> rogpeppe: But it's ok for me.
[14:19] <TheMue> rogpeppe: Can parse it to URL if access to the parts is needed.
[14:19] <rogpeppe> TheMue: yeah
[14:19] <TheMue> rogpeppe: The only thing is: URL verifies the URL to have a valid scheme.
[14:21] <rogpeppe> TheMue: i don't think so
[14:21] <rogpeppe> TheMue: it just verifies that the scheme matches [a-zA-Z][a-zA-Z0-9+-.]*
[14:22] <TheMue> rogpeppe: OK, not much (but even more than a pure string).
[14:24] <TheMue> rogpeppe: So AddCharm() gets a charm URL as charm.URL but the bundle URL as string. Hmm.
[14:27] <rogpeppe> TheMue: assuming we're expecting to have got the charm URL from the charm package, i don't think that's an issue
[14:28] <TheMue> rogpeppe: Yes, no issue, it only 'smells' a bit when reading the function signature.
[14:38] <rogpeppe> TheMue: can you enlighten me as to the role of unit names?
[14:38] <rogpeppe> TheMue: i can't quite see a unit has both a name and a sequence number
[14:38] <rogpeppe> TheMue: and a key
[14:39] <TheMue> rogpeppe: One moment.
[14:41] <TheMue> rogpeppe: The name is build by service name and sequence number.
[14:41] <TheMue> rogpeppe: The key is the internal key in ZK, like unit-0000000001.
[14:43] <rogpeppe> TheMue: i don't quite see why key and sequence number aren't pretty much the same thing in different forms
[14:43] <rogpeppe> ah! i see it, i think
[14:44] <rogpeppe> TheMue: i *think* it's because a unit is built in two operations; make unit directory, then add the newly made name to the topology.
[14:44] <rogpeppe> TheMue: i'm still not quite sure why we can't just take the unit number from the unit directory name.
[14:45] <TheMue> rogpeppe: Yes
[14:45] <rogpeppe> TheMue: and live with the fact that unit numbers might sometimes skip
[14:45] <rogpeppe> fwereade: any idea?
[14:46] <TheMue> rogpeppe: Do you have any trouble with it?
[14:46] <rogpeppe> TheMue: yeah, it's awkward because i'm implementing topology.UnitsForMachine and i'm not sure what to return from it
[14:46] <fwereade> rogpeppe, TheMue: I'm torn
[14:47] <rogpeppe> TheMue: i can't return []*zkUnit because that doesn't include the service name
[14:47] <rogpeppe> TheMue: i can't return *Unit because that's outside the purview of topology.go
[14:47] <TheMue> rogpeppe: The unit stuff is almost a 1:1 of the Py code.
[14:47] <fwereade> rogpeppe, TheMue: smoothly increasing ids throughout would obviously be nicest, and not represent a clear encapsulation breakdown
[14:48] <TheMue> rogpeppe: So I would investigate there.
[14:48] <rogpeppe> TheMue: i don't want to define *another* type representing a unit
[14:48] <rogpeppe> fwereade: that's what we've got now, i think.
[14:48] <rogpeppe> fwereade: at least, smoothly increasing *external* ids
[14:48] <fwereade> rogpeppe, TheMue: cool, because that's what we have with machines for sure
[14:49] <rogpeppe> fwereade: exactly.
[14:49] <fwereade> rogpeppe, TheMue: and in this I favour consistency
[14:49] <rogpeppe> fwereade: i'm thinking that machines is doing a very similar thing, and there (i *think) we have a 1-1 correspondence between key and machine id
[14:49] <fwereade> rogpeppe, yep, I think so too
[14:50] <TheMue> rogpeppe: The sequence no is increasing per service, the unit key over all units.
[14:50] <rogpeppe> fwereade, TheMue: doing this would also mean we could get rid of all the UnitSequence logic in topology.go
[14:50] <rogpeppe> TheMue: i don't think so, but let me check
[14:51] <rogpeppe> TheMue: oh yeah
[14:51] <TheMue> rogpeppe: It is, just checkt. It increases a counter per service name in topology.
[14:51] <rogpeppe> TheMue: that's a bit odd.
[14:51] <rogpeppe> TheMue: i'm surprised it's not a directory inside the service.
[14:51] <fwereade> rogpeppe, hmm, yeah, that might be nicer indeed
[14:52] <TheMue> rogpeppe: It's a value of topology, maybe because of the 'tranctional' behavior.
[14:52] <rogpeppe> TheMue: it's both actually
[14:52] <rogpeppe> TheMue: well... it's a directory and a node inside the topology
[14:52] <TheMue> rogpeppe: The increment only happens when the topology change succeeds.
[14:52] <rogpeppe> TheMue: the directory is inside /units though
[14:53] <TheMue> rogpeppe: The unit node is below units, yes.
[14:53] <rogpeppe> TheMue: yeah. but if the directory was inside the service, we could use a zk auto-increment to do the counting for us
[14:54] <rogpeppe> TheMue: but perhaps there's another reason for having units in a global namespace
[14:54] <TheMue> rogpeppe: We can do a lot. Do we have the need while the state isn't even completed?
[14:55] <rogpeppe> TheMue: probably not. it would simplify the code a bit though.
[14:55] <hazmat> its to give a semantic useful number
[14:55] <hazmat> zk sequence numbers can have gaps if an op fails
[14:56] <rogpeppe> hazmat: that's true. machine ids can do that.
[14:56] <hazmat> and there global
[14:56] <rogpeppe> hazmat: do gaps matter?
[14:56] <hazmat> across all services, where as we want the service unit increments
[14:56] <hazmat> rogpeppe, its rather disconcerting to see wordpress/5 and  wordpress/222
[14:57] <hazmat> as sequential units
[14:57] <hazmat> er.. sequentially allocated taht is
[14:57] <hazmat> ie.. the zk sequence is across all units
[14:57] <TheMue> hazmat: So while the key is purely internal the name containing the sequence no is also external visible?
[14:57] <hazmat> TheMue, yup
[14:58] <TheMue> hazmat: Makes sense, thx.
[14:58] <hazmat> TheMue, the python code base distinguishes between names and internal_ids
[14:58] <rogpeppe> hazmat: doesn't the same logic apply to machine ids?
[14:58] <hazmat> names being visible, and internal ids being the impl detail
[14:58] <TheMue> hazmat: Yes, in Go the internal ids are now keys, but have the same role.
[14:59] <hazmat> rogpeppe, to some extent, its commutes, but its not really something we ever really care about per se, a) juju cares about presenting the services not the machines b) the machine global sequence is correct for machine allocation
[14:59] <rogpeppe> hazmat: i guess i wonder if it's worth putting logic and code behind something that is a) very rare and b) only mildly disconcerting if it does happen.
[14:59] <hazmat> where as the units want service namespace'd sequences
[14:59] <hazmat> rogpeppe, i doubt it re machines
[15:00] <hazmat> rogpeppe, for service units its important, unless you have another impl of per service unit sequences
[15:00] <rogpeppe> hazmat: do we rely on the sequentiality anywhere?
[15:01] <hazmat> rogpeppe, never
[15:01] <hazmat> rogpeppe, its a user interface question
[15:01] <rogpeppe> hazmat: or is it just the fact that someone might see 1 followed by 3 and wonder what's going on.
[15:02] <hazmat> rogpeppe, its not about the 1 and 3, its about 1 and 25..
[15:02] <hazmat> rogpeppe, the unit sequence in zk is global to all units across all services
[15:02] <rogpeppe> hazmat: if we put unit directories inside service directories, that wouldn't be a problem
[15:02] <rogpeppe> hazmat: but maybe there's a good reason why that is a bad idea
[15:02] <hazmat> rogpeppe, right.. if you have another impl of per service unit sequences
[15:02] <rogpeppe> hazmat: ah, i see what you mean by that now
[15:02]  * hazmat loves repetition
[15:03] <hazmat> rogpeppe, that sounds fine to me
[15:04] <rogpeppe> TheMue: a reason for doing this is that it means i can map directly from a unit name e.g. wordpress/0 to its directory, without needing to consult the topology.
[15:04] <rogpeppe> TheMue: so unit name, sequence number and key are all derivable from each other.
[15:05] <TheMue> rogpeppe: Do we have problems so far consulting the topology?
[15:06] <TheMue> rogpeppe: Or asking it differently: When do we get scaling probs due to the top size?
[15:06] <rogpeppe> TheMue: what should UnitsForMachine return?
[15:06] <hazmat> it hasn't been a problem at scale, but we haven't been measuring the network traffic to get a better understanding of the outflow
[15:06] <rogpeppe> TheMue: it's not really a performance issue, but one of neatness.
[15:07] <hazmat> and from a size of topology, its really a non issue with any compression
[15:07] <hazmat> the sequence numbers that is
[15:07] <hazmat> we can get about 15k machines/services/service units in atm without blowing 1mb, without compression
[15:07] <rogpeppe> TheMue: i'll have a play and see how it looks
[15:07] <TheMue> rogpeppe: So both solutions have to be compared.
[15:08] <rogpeppe> TheMue: yeah
[15:08] <TheMue> rogpeppe: Breaking todays top concept could lead to a larger redesign, stop by step. Let's do it here, oh, and there.
[15:09] <hazmat> rogpeppe, its not clear thats its meanigful though, you need the topology for most anything.. and units to service name lookups aren't common
[15:09] <TheMue> rogpeppe: I only see the risk of changing too much of what we reached before the rest is done. 12.10 is coming. ;)
[15:09] <hazmat> rogpeppe, ie. that translation is pretty rare in practice for the runtime
[15:09] <hazmat> rogpeppe, because typically its holding onto a service unit state which has both values captured
[15:09] <rogpeppe> hazmat, TheMue: ok, i'll leave as is. it should be fairly easy to refactor later actually.
[15:10] <hazmat> yes.. avoid.. premature optimization ;-)
[15:10] <TheMue> hazmat: Hehe, yes.
[15:11] <hazmat> rogpeppe, i agree though that we can better about the topology slinging, i just don't think that particular case is particularly relevant.
[15:11] <TheMue> rogpeppe: Maybe we get a better solution when the layer around ZK is done and we change the backend in a second step.
[15:11] <rogpeppe> hazmat: as always. although i wasn't really considering this in performance terms.
[15:11] <rogpeppe> hazmat: just that we could reduce the number of entities w.l.o.g.
[15:11] <hazmat> isn't neatness is an eye of the beholder thing isn't it?
[15:12] <hazmat> and is the neatness you defined avoiding fetching the topology?
[15:12] <rogpeppe> hazmat: no, that was another thing.
[15:12] <hazmat> nm.. i should move on.. silly deadlines
[15:12] <rogpeppe> hazmat: in this case we've already got the topology
[15:12] <hazmat> gotcha
[15:14] <rogpeppe> TheMue, hazmat: my impulse to change things stemmed from my "so why does a unit need two names" question. and the answer is "it doesn't, but that's the way it's been done" AFAICS.
[15:15] <hazmat> rogpeppe, then you've ignored the discussion to this point.. its two fold, to present a nice interface, and to separate interface from impl
[15:15] <TheMue> rogpeppe: So let's keep it as long as there's no real need. There are still enough tasks to do.
[15:16] <rogpeppe> hazmat: putting unit directories inside their service directories solves both of those issues, i think.
[15:17] <hazmat> rogpeppe, agreed
[15:18] <hazmat> rogpeppe, but that's solving those two issues in a different way, that doesn't obviate the reasons
[15:18] <rogpeppe> hazmat: if we did that, then a unit would only have one name
[15:19] <rogpeppe> hazmat: or at least, the different categories of names would map 1-1
[15:19]  * hazmat nods
[15:25] <niemeyer> rogpeppe: Did you get the hotel confirmation?
[15:25] <rogpeppe> niemeyer: yes thanks
[15:26] <rogpeppe> niemeyer: should i organise my own travel?
[15:26] <rogpeppe> niemeyer: (if so, what time should i plan to arrive/leave?)
[15:26] <niemeyer> rogpeppe: Yeah, I think that's simpler in your case
[15:27] <niemeyer> rogpeppe: Arriving around noonish or early afternoon sounds fine.. I expect Aram will be arriving around that time as well
[15:29] <rogpeppe> niemeyer: ok, that's easy enough. leaving?
[15:29] <niemeyer> rogpeppe: Planning for end of afternoon/early night on Friday should work well
[15:31] <rogpeppe> niemeyer: not cheap, those train tickets!
[15:34] <rogpeppe> niemeyer: looks like minimum price is around £230.
[15:34] <rogpeppe> niemeyer: i bet Aram's flight isn't far off that
[15:35] <niemeyer> rogpeppe: Ugh.. a bit unfortunate indeed
[15:36] <niemeyer> rogpeppe: Still a lot cheaper than flying you to Brazil, though ;)
[15:36] <rogpeppe> niemeyer: very true
[15:38] <rogpeppe> niemeyer: if i want a flexible return time, the price is £301 !
[15:42] <rogpeppe> niemeyer: so i think i'll plan to leave at 1700 on friday, which should get me home by 2100, if that sounds ok
[15:42] <niemeyer> rogpeppe: Yep, sounds good
[15:43] <rogpeppe> niemeyer: that's the train leaving at 1700, so i guess i'd be leaving millbank (which is presumably where we'd be?) at 1600.
[15:43] <niemeyer> rogpeppe: No, we'll actually not have a room on Friday afternoon.. so we'll be meeting somewhere more open
[15:44] <niemeyer> rogpeppe: We have a room for the morning rented somewhere, though
[15:44] <rogpeppe> niemeyer: just as long as it's not too far away from king's cross, that'd be good
[15:44] <niemeyer> rogpeppe: Everybody is leaving EOD.. so won't be an issue
[15:45] <rogpeppe> niemeyer: cool. will book tickets now.
[16:18] <rogpeppe> niemeyer: all booked.
[17:07] <niemeyer> rogpeppe: Woohay
[17:07] <niemeyer> Aram: Do you have the new flight confirmation?
[17:07] <niemeyer> Aram: For real Thursday?
[17:08] <Aram> niemeyer: yes, I printed my boarding pass.
[17:09] <niemeyer> Aram: Cool, just to be sure, you noticed that the flight was booked wrong and then re-booked, right?
[17:09] <Aram> yes, yes, got a funny email why wasn't I present in today's flight.
[17:09] <niemeyer> Aram: Cool
[17:10] <niemeyer> Aram: It was half my mistake.. I was silly to assume they would actually book in the day I asked for
[17:10] <Aram> heh.
[17:10] <niemeyer> Rather than double checking the confirmation
[17:13] <rogpeppe> niemeyer, fwereade, TheMue: first step towards the unit-assignment watcher: https://codereview.appspot.com/6256070/
[17:13] <niemeyer> Aram: I'm not being ironic.. that's why they send the flights for confirmation
[17:14] <rogpeppe> i'm off for the night
[17:14] <rogpeppe> Aram, niemeyer: see ya tomorrow!
[17:14] <Aram> have fun.
[17:14] <niemeyer> rogpeppe: Awesome, have a good one
[17:15] <niemeyer> I shouldn't take too long either
[17:24] <niemeyer> Aram: I assume you have address and all?
[17:25] <Aram> 27th Floor, Millbank Tower
[17:25] <Aram> 21-24 Millbank
[17:25] <Aram> it's good, right?
[17:28] <niemeyer> Yep!
[17:28] <niemeyer> Aram: So if we don't talk again today, I'll see you here tomorrow
[17:28] <niemeyer> Stepping out for dinner
[17:28] <niemeyer> Cheers all
[17:28] <Aram> yes, great!
[17:28] <Aram> enjoy!
[17:29] <niemeyer> Thanks!
[22:30] <davecheney> niemeyer: are you happy for me to extend, go-cmd-jujud-fix-testing, to include the other commands then submit ?
[22:31] <davecheney> or should I do another round of reviews ?
[22:53] <davecheney> is schema_test.go failing for anyone else ?


[14:05] <cmaloney> Good morning
[14:47] <rick_h_> morn
[15:05] <cmaloney> How goes the morning?
[15:23] <rick_h_> filling dumpster with construction trash
[15:23] <rick_h_> working on getting the house back to normal yay
[15:23] <cmaloney> Just in time for the holiday
[15:24] <rick_h_> yea hosting christmas day
[15:37] <cmaloney> Very cool
[15:54] <rick_h_> how goes prep on your end?
[17:44] <cmaloney> We're not doing a Christmas thinge here
[17:44] <cmaloney> bro-in-law is hosting his family
[17:45] <cmaloney> think JoDee and her sister are going to have Chinese food
[17:45] <cmaloney> I'm heading to my parents to be with my aunt and uncle for a bit
[18:55] <rick_h_> heh good plan


[00:35] <jono> have fun jcastro!
[02:22] <cjohnston> maco: you around?
[02:22] <maco> cjohnston: yep
[02:22] <cjohnston> Got time to give something on loco dir a try for me please?
[02:24] <maco> sure
[02:24] <cjohnston> http://loco.ubuntu.com/teams/ubuntu-districtofcolumbia/edit
[02:24] <cjohnston> what is in the field date approved?
[02:24] <cjohnston> nothing?
[02:26] <cjohnston> G50
[02:26] <cjohnston> uggh
[02:27] <maco> djnone
[02:27] <maco> cjohnston: None
[02:28] <cjohnston> how about in the date expired?
[02:28] <cjohnston> its not an editable field.. just curious whats there
[02:30] <maco> 2012-01-01
[02:31] <cjohnston> no time?
[02:32] <nhandler> Does anyone know of a good video hosting site that would allow me to upload a private video for free and share it with someone?
[02:33] <maco> 00:00:00
[02:34] <cjohnston> ok.. so it does have a time..
[02:34] <cjohnston> hmm
[02:34] <cjohnston> I'm guessing its stored in the db
[02:34] <cjohnston> you cant edit it correctly right?
[02:35] <cjohnston> lol
[02:35] <cjohnston> you can't edit it correct?
[02:35] <nhandler> cjohnston: I can't edit mine
[02:35] <cjohnston> ok..
[02:36] <cjohnston> I'm thinking the db will need to be edited
[02:36] <cjohnston> Thanks pleia2 maco and nhandler!
[02:36] <nhandler> :)
[02:36] <pleia2> sure
[02:38] <cjohnston> g'nite all!
[02:38] <Pendulum> g'night cjohnston
[04:07] <paultag> jcastro: any chance at all you're awake?
[09:23] <vish>  jcastro: maybe we can mention stack exchange in the installer itself! ?
[09:43] <duanedesign> morning vish
[09:44] <vish> duanedesign: o/
[09:44] <vish> hehe , now i remembered what i was planning to do on the forums!
[09:48] <duanedesign> vish: :)
[10:09] <duanedesign> vish: i thought this blog post was pretty inspirational
[10:09] <duanedesign> http://brunogirin.blogspot.com/2010/08/contributing-to-shotwell.html
[10:12]  * vish reads.. :)
[10:14] <vish> duanedesign: whoa! papercuts thread had more than 2000 views! neat!
[19:24] <vish> jussi: google's video chat works! :D
[19:24] <vish> if it doesnt it might be problematic webcam drivers ;p
[19:25] <vish> it works fine from one acer aspire one , but totally doesnt work in my acer laptop!
[19:25] <jcastro> vish: someday in the installer, that would be cool
[19:25] <jcastro> vish: I am hoping to map it to ask.ubuntu.com
[19:25] <jcastro> very tshirt-able
[19:25] <vish> hehe!
[19:48] <doctormo> jcastro: Map which to ask?
[19:49] <doctormo> pleia2: How did the picnic go?
[20:03] <pleia2> doctormo: ongoing :)
[20:04] <pleia2> it's great!
[20:06] <vish> watching the "View change over time" in : http://is.gd/euQdt , is quite interesting ;)
[20:49] <Pendulum> hiya
[21:48] <jcastro> doctormo: I was referring to the stackexchange
[21:48] <jcastro> hi Pendulum
[22:10] <czajkowski> aloha
[22:24] <duanedesign> vish: that is interesting
[22:26] <czajkowski> jcastro: you loon what are you doing on here over the weekend
[22:27] <jcastro> avoiding family commitments. :D
[22:27] <czajkowski> heh
[22:28] <czajkowski> I've spent the weekend so far reading, non techie stuff and catching up with a mate. very nice
[22:32] <duanedesign> jcastro: you work on the ubuntu developers netowrk channel on blip.tv?
[22:32] <AlanBell> hello from rainy wales o/
[22:32] <jcastro> duanedesign: yep
[22:32] <jcastro> duanedesign: what do you need?
[22:33] <duanedesign> jcastro: well i recieved an email about updating screencasts.ubuntu.com with the new branding
[22:34] <jcastro> that one belongs to popey iirc
[22:35] <czajkowski> and popey is on hols
[22:35] <czajkowski> AlanBell: aloha
[22:36] <duanedesign> jcastro: yeah i have been steering that boat lately. Popey was having trouble finding the time for the team
[22:37] <duanedesign> jcastro: looks like you have a lot more than screencasts on the developer bliip site
[22:37] <jussi> I hate flies!
[22:37] <jcastro> duanedesign: iirc there was ubuntuscreencasts or something like that on blip
[22:38] <jussi> ooh, does anyone know if todays xserver update will fix all of lifes problems? :D
[22:38] <jussi> except the flies of course :P
[22:38] <jcastro> duanedesign: feel free to steal them
[22:38] <duanedesign> jcastro: yeah their is...which kind of leads me too my vague question :) I was wondering if the screencast site is still necessary
[22:39] <jcastro> duanedesign: I've always been of the opinion to point people to youtube and use the other ones to feed the youtube channel
[22:39] <jcastro> it's got the most amount of people
[22:39] <AlanBell> czajkowski: popey seems to have wifi though
[22:40] <czajkowski> he's tweeting
[22:40] <AlanBell> I have just had to drive 10 miles to get a signal
[22:40] <AlanBell> What kind of idiot builds an area of outstanding natural beauty smack in the middle of a mobile broadband dead spot?
[22:42] <duanedesign> jcastro: thanks. Was just trying to get some opinons. I appreciate the offer on sharing screencasts.
[22:51] <czajkowski> AlanBell: but Wales is sooo pretty and they have lovely accents
[22:53] <AlanBell> not as lovely as the irish accent of course
[22:53] <AlanBell> anyhow, batteries running low, might have to head back to the desolate area of no signal
[22:59] <czajkowski> toodles
[23:41] <czajkowski> there are some rude people out there, I dont modeate rude comments on my blog. enough rudeness out there in the world


[01:54] <Bashing-om> I be back, playing catch up now.
[05:40] <lotuspsychje> good morning to all
[05:42] <lotuspsychje> agent_white: hello :p
[05:42] <agent_white> Heya! \o
[05:42] <agent_white> What's this all about?
[05:42] <lotuspsychje> agent_white: the idea is, we offer alot of support, but never have a chance to talk to each other
[05:43] <lotuspsychje> agent_white: so this way we can support and chat on ubuntu topics to each other
[05:43] <agent_white> Oh neat! How did you... find me out? :P
[05:43] <lotuspsychje> agent_white: you have been spotted as active volunteer :p
[05:43] <lotuspsychje> we see you alot in #ubuntu right
[05:44] <agent_white> Oh wow... I'm honored haha. Thank you for extending the invite here :)  Never figured it was noticed.
[05:44] <lotuspsychje> agent_white: feel free to add this channel to favs
[05:45] <agent_white> lotuspsychje: Already done :)
[05:45] <lotuspsychje> tnx mate
[05:45] <agent_white> Is this a recent channel then?
[05:45] <lotuspsychje> well it was a rather non-active channel
[05:45] <lotuspsychje> as i had this idea, to gather most nicest ppl
[05:46] <lotuspsychje> we all like a cool ubuntu discussion, and offtopic channel can be so crowdy
[05:48] <lotuspsychje> TJ-: good morning :p
[05:48] <TJ-> Morning :)
[05:49] <agent_white> lotuspsychje: Sounds good to me!  Again, happy/honored to hear I was 'spotted'... even though I wonder more how I was! :P
[05:50] <TJ-> 2nd task of the morning - pack up and return to CA, USA, one dead-on-arrival PCIe SSD .... grrrr. Spent a week diagnosing the failure and confirming its not a counterfeit!
[05:50] <lotuspsychje> agent_white: well its easy to seperate the active,friendly volunteers from angry, ego-minded supporters
[05:51] <lotuspsychje> TJ-: whats wrong with it?
[05:51] <TJ-> It's dead Jim!
[05:51] <lotuspsychje> lol
[05:51] <lotuspsychje> TJ-: thats the hardest thing, ive spent a week on a mobo once that was dead too
[05:52] <TJ-> It's a mini-PCIe device (direct, not mSATA etc) and it caused all the laptops to lock up during POST
[05:52] <lotuspsychje> and keeping thinking it was my fault lol
[05:52] <TJ-> So I tested it in a PCIe <> mini-PCIe adapter in an ATX desktop motherboard... and it prevented the PSU from turning on
[05:52] <lotuspsychje> sort of a hardware loop?
[05:52] <agent_white> Ah I see :)  Luckily I maybe have seen an angered-one only a few times... I just feel it's easy to put myself into the shoes of one with a question and remember when I had that same question.
[05:53] <lotuspsychje> agent_white: ive seen you alot in support, and never seen you angry so.. :p
[05:53] <agent_white> :D Haha never will!
[05:53] <lotuspsychje> keep up the spirit :p
[05:54] <TJ-> I contacted Super Talent support and they hinted it might be counterfeit so I sent them some macro photos of the PCB .. confirmed this morning it is genuine and they'll RMA it it. I've got the option of 2 RMAs now, them or the original retailer
[05:54] <lotuspsychje> TJ-: got an url on that device?
[05:55] <TJ-> Core Store Plus:   http://www.supertalent.com/products/ssd_category_detail.php?type=CoreStore&category=others
[05:57] <lotuspsychje> hmm cant find much error threads on it
[06:01] <TJ-> They beat the SATA speed bottleneck can transfer at the speed of the PCIe bus
[06:01] <lotuspsychje> nice
[06:02] <TJ-> SATA + SSD is a silly combination in many cases now, SATA is OK for spinning disk but not memory devices
[06:03] <lotuspsychje> TJ-: so take msata ssd?
[06:04] <TJ-> mSATA is just SATA on a mini-PCIe interface edge connector
[06:05] <TJ-> NGFF aka m.2 is the follow on from mSATA, but has yet another different bus and edge connector
[06:06] <lotuspsychje> TJ-: so your saying that ssd's should only be plugged on pcie?
[06:13] <TJ-> I'm saying connecting most disk-replacement flash memory devices via SATA is going to cause an access bottleneck and is a waste of money and electronics
[06:13] <lotuspsychje> bottleneck of 550mb/sec?
[06:17] <TJ-> But internally, it requires PCIe <> SATA controller <> connector <> SATA controller <> Address Decoder <> Memory
[06:17] <TJ-> As opposed to PCIe <> connector <> Address Decoder <> Memory
[06:18] <lotuspsychje> true its more direct
[06:18] <TJ-> So, especially for after-market upgrades of older PCs especially, (mini)-PCIe will often be much better than SATA, if available.
[06:21] <lotuspsychje> ok
[06:21] <TJ-> E.g., the laptop fleet we have here are all identical models (allows fast hot-swap), and have 3 mini-PCIe slots each plus the 2.5" SATA disk interface. That allows them to have 750GB SHD (SSD cache combined with spinning disk), WLAN 802.11a/b/g/n, WWAN 3/4G modem, *and* a full flash 'SSD'
[06:22] <lotuspsychje> sounds nice
[06:25] <TJ-> and they still have the ExpressCard interface - another PCIe port - which I have connected to an external full sized PCIe enclosure with an Nvidia NVS420 dual-GPU PCIe  adapter, which allows me 3 GPUs and 6 screens in total.
[06:25] <lotuspsychje> lol
[06:25] <lotuspsychje> for the heavy workers
[06:25] <TJ-> more expandable than most desktops :)
[06:26] <lotuspsychje> well the customers i will have will do fine on sata+ samsung pro 850 ssd with ubuntu64bit
[06:26] <lotuspsychje> but if i see available mini pcie ill think of you
[06:27] <TJ-> :)
[06:28] <lotuspsychje> TJ-: http://www.fastestssd.com/featured/ssd-rankings-the-fastest-solid-state-drives/#pcie
[06:29] <agent_white> lotuspsychje: You laying down these factoids has lead me to read about ubottu's factoids and aliases of them.  Good to know :)
[06:29] <lotuspsychje> Up to 3200MB/s read
[06:29] <lotuspsychje> Up to 1900MB/s write
[06:29] <lotuspsychje> impressive that first one
[06:30] <TJ-> Yes, those are commonly used in database servers
[06:30] <lotuspsychje> agent_white: :p
[06:31] <TJ-> It's the IOPS that's most important in that class
[06:32] <lotuspsychje> TJ-: Random 4K Write: Up to 205,000 IOPS (700GB)
[06:32] <lotuspsychje> crazy
[06:32] <TJ-> That's pretty typical of the demands for that class of device
[06:32] <TJ-> it's not about throughput so much as the number of I/O operations the device can handle
[06:34] <TJ-> In virtualised servers that can be much more important, if you've got 30-100 guests all needing to access their disk images in the routine way that OS and applications do
[06:35] <agent_white> lotuspsychje: Time to write factoids on flashcards... I've been wanting to learn more of them.
[06:35] <agent_white> ;)
[06:36] <lotuspsychje> TJ-: yeah alot of servers use ssd these days
[06:42] <TJ-> Won't be long until we have more RAM-SSDs making it down to the consumer level
[06:45] <lotuspsychje> that would be nice
[06:57] <TJ-> Is it irony that when I start xSANE it reports "Scanning for devices" :)
[06:57] <lotuspsychje> lol
[06:58] <lotuspsychje> linux jokes :p
[07:06] <lotuspsychje> lotuspsychje@R00TB0X:~$ cowsay Scanning for devices mooo
[07:06] <lotuspsychje>  ___________________________
[07:06] <lotuspsychje> < Scanning for devices mooo >
[07:06] <lotuspsychje>  ---------------------------
[07:06] <lotuspsychje>         \   ^__^
[07:06] <lotuspsychje>          \  (oo)\_______
[07:06] <lotuspsychje>             (__)\       )\/\
[07:06] <lotuspsychje>                 ||----w |
[07:06] <lotuspsychje>                 ||     ||
[07:23] <histo> lol
[07:23] <lotuspsychje> :p
[07:23] <histo> wasn't there owlsay aslo
[07:24] <lotuspsychje> TJ- started it!
[07:24] <lotuspsychje> !info owlsay
[07:28] <lotuspsychje> histo: i found cowsay -f duck or sheep :p
[07:29] <histo> nice
[07:29] <histo>   ____ _____        __
[07:29] <histo>  / ___/ _ \ \      / /
[07:29] <histo> | |  | | | \ \ /\ / /
[07:29] <histo> | |__| |_| |\ V  V /
[07:29] <histo>  \____\___/  \_/\_/
[07:29] <histo>
[07:29] <lotuspsychje> histo: lol
[07:29] <lotuspsychje> http://smashingtips.com/linux/cool-terminal-commands-for-linux
[07:30] <histo> stegasaurus
[07:30] <lotuspsychje> haha
[08:16] <TJ-> histo: You might want to read the back-log on SashaGrey's issue; TLDR: remote headless dedicated server, failing to mount /home/ file-system at boot and drops to initrd. No remote KVM, no IPMI, only 'remote hands' via email. see http://paste.ubuntu.com/11854634/
[08:17] <TJ-> I let it go once I found out there's no remote ability, and no data back-ups
[10:26] <agent_white> Sounds like Ben64 and k1l_ should be here! I've seen them around quite a bit.
[10:47] <lordievader> Good afternoon.
[10:49] <BluesKaj> G'Day folks
[11:24] <BluesKaj> Hi again
[13:23] <ExecSlim> If I found a bug in ubuntu and I found the bug on launchpad but the bug is for a different machine type (a lenovo), would it be appropriate for me to comment about my issue on my computer and attach what errors I'm getting?
[13:24] <ExecSlim> found it on launchpad*
[13:40] <daftykins> still not a support channel
[13:58] <lordievader> ExecSlim: Even though this ain't support I'd add your comment if the bug matches.
[14:39] <lotuspsychje> good afternoon
[14:41] <lordievader> o/
[14:42] <lotuspsychje> hello lordievader
[16:52] <ExecSlim> Out of curiosity, has anyone dual booted windows and ubuntu on a macbook pro, and erased the "mac" partition? If that's possible is it possible to reinstall mac?
[17:04] <daftykins> this is NOT a support channel
[17:04] <daftykins> it's in the topic! leave and ask in #ubuntu if you want support.
[17:55] <daftykins> got the rest of my lovely new bike part snaps - http://imgur.com/a/mVMyQ
[17:57] <OerHeks> You might as well buy a new bike man
[17:58] <daftykins> ;) hell no
[17:58] <daftykins> £90 of parts on a £1900 bike :)
[17:59] <OerHeks> :-O
[17:59] <daftykins> did well for 7 years old!
[18:00] <OerHeks> Sure, after 5+ years you need to do maintanance on the chain. On that point i buy a new bike
[18:01] <ExecSlim> daftykins, oops! For future reference, how does #ubuntu-discuss differ from #ubuntu-offtopic?
[18:01] <daftykins> ExecSlim: read the damn topic
[18:01] <lordievader> ExecSlim: I'm not in #ubuntu-offtopic ;)
[18:01] <OerHeks> ExecSlim, your Q is suitable for #ubuntu support i guess
[18:02] <ExecSlim> Okay sounds good, sorry about that
[18:02] <ExecSlim> just posted it into #ubuntu
[18:03] <OerHeks> I cannot tell what the osx installer wants from your hdd, freedom to partition or guided.
[18:06] <ExecSlim> OerHeks right now I am just dual booting ubuntu and mac, but I want to erase mac and replace it with windows.


[23:00] <Eickmeyer> o/
[23:00] <toddy> o/
[23:01] <Eickmeyer> 2 more for quorum.
[23:02]  * Eickmeyer pokes jose and teward with a 4x4.
[23:02] <jose> give me a minute
[23:02] <Eickmeyer> haha k
[23:02] <jose> I'm finishing cooking a mugcake
[23:02] <toddy> :)
[23:02] <Eickmeyer> Ooooo! You and your sugary treats.
[23:03] <jose> sugar-free though :P it's a keto mugcake
[23:03] <Eickmeyer> Ohhh... you and your sweet yet weight-loss treats.
[23:03] <toddy> cake is cake. nice :)
[23:03] <Eickmeyer> ^ Facts.
[23:03] <jose> ^ true
[23:03] <jose> I'm ready now
[23:04] <Eickmeyer> Still missing 1 of teward, nhaines, or lina.
[23:04]  * Eickmeyer just tried pinging teward using other channels
[23:05] <teward> i am around but feeling a tiny bit bleh
[23:05] <Eickmeyer> Ah.
[23:05] <Eickmeyer> Well, there's quorum.
[23:05] <teward> ate waaaaay too much at lunch...
[23:05] <Eickmeyer> wxl: Are you here?
[23:06]  * Eickmeyer guesses no wxl
[23:07] <jose> we have quorum
[23:07] <Eickmeyer> Who wants to chair?
[23:07]  * Eickmeyer not it
[23:07] <teward> notme today
[23:07] <teward> *points at jose* they need to :P
[23:07] <jose> #startmeeting
[23:07] <meetingology> Meeting started Wed Nov 18 23:07:26 2020 UTC.  The chair is jose. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
[23:07] <meetingology> Available commands: action commands idea info link nick
[23:07] <jose> Welcome to the CC meeting
[23:07] <jose> #chair Eickmeyer teward toddy
[23:07] <meetingology> Current chairs: Eickmeyer jose teward toddy
[23:08] <jose> so, what's up
[23:08] <jose> any topics y'all would like to discuss today?
[23:08] <jose> I do have one but would like to open the floor to all of you first
[23:08] <wxl> sorry it's been a day
[23:08] <teward> #topic Technical Board
[23:08] <jose> wxl you joining us for now?
[23:09] <wxl> i'm here
[23:09] <teward> nothing from Mark on the nominees so we'll have to extend existing TB through End of Year
[23:09] <jose> #chair Eickmeyer teward toddy wxl
[23:09] <meetingology> Current chairs: Eickmeyer jose teward toddy wxl
[23:09] <jose> I did send him a reminder another way
[23:09] <teward> Is there any objection with extending the existing TB members anyways until End of Year so that we have a TB in the interim?  We don't know when Mark'll get his nominees list in.
[23:10] <jose> none from me
[23:10] <Eickmeyer> Yeah, I'm all for extending TB through EOY. I doubt we'll be able to get through elections before EOY.
[23:10] <wxl> fine with me
[23:10] <jose> however
[23:10] <toddy> for me also fine
[23:10] <jose> I do suggest we reach out to them proactively and make sure that they're aware of the decision
[23:10] <jose> and if anyone wants to resign, they have the opportunity to do so gracefully
[23:10] <wxl> i say we continue to approach mark about it and perhaps suggest some other alternative, such as taking nominees as normal and allowing himm to confirm them as with the cc
[23:10] <Eickmeyer> ^ Yes, I agree.
[23:10] <jose> what do you think
[23:11] <Eickmeyer> So nominations curated by Mark? That could work.
[23:11] <teward> nominations have always been curated by Mark for TB
[23:11] <wxl> we make a call for nominations and then pass that to him to confirm
[23:12] <wxl> that at least eliminates some of the work required
[23:12] <Eickmeyer> True, that would be less onMark's plate.
[23:12] <jose> I have made sure that he gets the message though
[23:12] <jose> so we'll have an answer before EOY :)
[23:13] <Eickmeyer> So, let's let it sit for another two weeks with existing TB extended to EOY then.
[23:13] <Eickmeyer> If nothing, then we get more proactive.
[23:13] <jose> I agree that's a good choice.
[23:13] <wxl> i mean i can imagine sorting through all of the ubuntu developers to find appropriate candidates that want to sit on the board is a rather tiring situation
[23:13] <teward> I'm not opposed to discussing changing how TB is staffed, but I think we need, for now, to keep the process as is, and propose any changes to that to Mark
[23:14] <teward> and simply keep existing TB members through EOY given our proximity to the end of the year
[23:14] <Eickmeyer> wxl: I agree, but I think, considering *how* jose got through to him, that we need to sit this out a little longer.
[23:14] <wxl> works for me
[23:14] <jose> any objections about the proposals above?
[23:15] <toddy> hi linaporras
[23:15] <linaporras> Hi, sorry for the late
[23:15] <jose> #chair Eickmeyer teward toddy wxl linaporras
[23:15] <meetingology> Current chairs: Eickmeyer jose linaporras teward toddy wxl
[23:15] <teward> #action teward to extend current TB members roles through EOY and notify TB about it as well.
[23:15] <meetingology> ACTION: teward to extend current TB members roles through EOY and notify TB about it as well.
[23:15] <teward> because we at least agreed on THAT
[23:15] <jose> and don't forget to document it in the bug please :)
[23:15] <teward> thats a given ;)
[23:15] <jose> :partyparrot:
[23:16] <wxl> what's next?
[23:16] <jose> good then
[23:16] <jose> I was just going to ask that :)
[23:16] <toddy> #topic LoCo Council nomination
[23:16] <wxl> since we're all chairs, i'm not who the actual one running the show is XD
[23:17] <jose> I am, but any of you can run commands :)
[23:17] <Eickmeyer> jose is *the* chair.
[23:17] <jose> :tada:
[23:17] <toddy> We have not received enough nominations for the LoCo council after our call.
[23:17] <wxl> Eickmeyer: does that make you the stool?
[23:17] <teward> wxl: jose's in the hotseat today, we just have perms to run the commands now lol.
[23:17] <toddy> hi nhaines
[23:17] <Eickmeyer> wxl: Usually. Because I'm always the butt of the joke when tsimonq2 isn't around (shameless ping because reasons)
[23:17] <linaporras> I  have a commment on that
[23:18] <linaporras> #idea
[23:18] <teward> not a command.  just make your comment RE: LoCo Council
[23:18] <teward> since that's the item we're looking at now
[23:18] <linaporras> RE: LoCo Council
[23:19] <wxl> Eickmeyer: fair point https://phab.lubuntu.me/file/data/vcfkt6x656czh7ao52u5/PHID-FILE-p7x4hnakcjuzjrp4nqey/simon_s_fault.jpg
[23:19] <Eickmeyer> ^ Yep. I know that reference, wxl! haha
[23:19] <jose> #chair Eickmeyer teward toddy wxl linaporras nhaines
[23:19] <meetingology> Current chairs: Eickmeyer jose linaporras nhaines teward toddy wxl
[23:19] <toddy> wxl: :D
[23:20] <wxl> linaporras: what are you thinking
[23:20] <wxl> ?
[23:20] <Eickmeyer> Wow, not only quorum, but FULL COUNCIL!!!
[23:20] <toddy> yes
[23:20] <nhaines> \o/
[23:20] <linaporras> RE: LoCo Council   I think that before an election we should take a look on the current status of the LoCos, which are active, how many members, and review the pending approvals of ubuntu members. Also I propose that with an initial status, we also see if is prudent to elect, or just empower the LoCos, and after that go to elections
[23:21] <linaporras> I was writing, sorry for the delay..... since been a long time not using IRC also... but, that's the idea for that topic!
[23:21] <toddy> how do we get a current status of the LoCos?
[23:21] <jose> we'd have to email loco contacts with an announcement and poll ourselves
[23:22] <wxl> this sounds a little bit like what i was thinking but i do know that one of the things that we've kind of always needed is a way for canonical to verify the validity of some indvidual or individuals to represent ubuntu at conferences and to get funding and resources related to that
[23:22] <jose> toddy, could you please mention some of the ideas that were mentioned today in the mailing list
[23:22] <wxl> which is why there is the whole loco verification thing
[23:22] <jose> as the mailing list is private
[23:22] <jose> and then I do have a comment, after toddy has debriefed :)
[23:23] <linaporras> That's a task, start reviewing Launchpad... and look for another way to contact people, in my LoCo there is active people, but we a fe years ago were discussing about the tools... because for many people was difficult to complete the process, so we were in real bigger thant the launchpad team...
[23:23] <toddy> We have discussed at the mailing list if we make a second call.
[23:24] <toddy> Or if we change the focus of the candidates
[23:24] <Eickmeyer> Another idea was to change the idea of LoCos altogether.
[23:24] <toddy> so that we are maybe should search for people who wants to change the process
[23:25] <linaporras> I am reading the list... maybe a meeting with the people that is still active, and listen what's going on, what are the barriers, coudl be a good idea...
[23:26] <jose> so, what about this
[23:26] <Eickmeyer> In the US, LoCos are pretty much dead. I, for one, have never been verified by a LoCo.
[23:26] <linaporras> I suggest this before thinkin in changing the process... or calling again to elections...
[23:27] <wxl> i think it's safe to say that the lack of interested candidates is probably a sign for concern
[23:27] <Eickmeyer> ^ Agreed.
[23:27] <nhaines> I agree.
[23:27] <jose> since we've been having difficulties, we convoke for a transition committee, who will help us in making that assessment and providing conclusions about the current status of the LoCo teams
[23:27] <toddy> I like the idea to discuss this topic with the loco contacts
[23:27] <wxl> perhaps we should reach out to previous council members and see if there are interested parties
[23:27] <linaporras> (talk with people not limited to people that is launchpad)
[23:27] <jose> peeps, I want to finish my idea without messages getting lost, one at a time?
[23:27] <linaporras> agree with wxl
[23:27] <jose> since we've been having difficulties, we convoke for a transition committee, who will help us in making that assessment and providing conclusions about the current status of the LoCo teams
[23:28] <wxl> jose: convoke?! i have never heard that word before and i'm the one who is actually from an english speaking country! go you.
[23:28] <jose> they can do whatever they deem necessary in order to analyze the status of loco teams
[23:28] <jose> emailing the mailing list, holding interviews
[23:28] <jose> maybe analyzing "the market"
[23:28] <jose> and then, they come up with a report saying
[23:28] <jose> 1.- what is the current status
[23:29] <jose> 2.- how can we improve participation
[23:29] <jose> 3.- any and all recommendations they have in order to improve the experience of loco teams (or if they wanna revamp them)
[23:29] <jose> that's it
[23:29] <jose> what do y'all think
[23:29] <teward> I'm just going to put this out there though in the interim:
[23:29] <linaporras> I am not a fan of comittees, prefer a meeting as wxl suggest and also... inviting more people... and maybe this is daring but evalutin not necessary this channel as the channel for that meeting.
[23:29] <teward> LoCo Teams are currently going to be impacted globally by the Pandemic
[23:30] <wxl> i assume you think that committee would be a subset of the cc?
[23:30] <teward> so that's one factor to consider in any way we move forward.
[23:30] <linaporras> *evaluating...
[23:30] <jose> I suggess the committee be a group of 3-5 people who we delegate to make this decision
[23:31] <jose> overseen by the community council, of course
[23:31] <wxl> i interpret teward's thought two ways:
[23:31] <wxl>  1. the need for people to get verified for funds and resources are going to be small, if at all
[23:31] <wxl>   (meaning we have some time)
[23:31] <linaporras> I think that for start this task we should all get involved, and having this meeting then plan a strategy...
[23:32] <wxl>  2. the activity may be decreased (so our investigations may not be indicative of "normal" activity)
[23:32] <jose> we would have to analyze historical data
[23:32] <jose> I can tell you for a fact the big decline happened in 2017ish
[23:32] <jose> we can mark 2020 with an asterisk, but the current level of participation is mostly an indicator of previous participation
[23:33] <jose> we could even give it a 50% handicap
[23:33] <jose> Eickmeyer, toddy, would love to hear your thoughts on the proposal
[23:34] <jose> nhaines too
[23:34] <Eickmeyer> I honestly don't know. I feel as though the historical verification reason for the LoCos might not exist at all.
[23:34] <wxl> right. so maybe for now we say that the cc will be responsibile for any verification that needs to happen. there aren't a lot of these happening, so that's probably not a big deal. i do like the idea of getting some more data together before making further decisions. and having a delegated group to do this is something i like (we've got a bunch of stuff on our plates so we probably don't want to go
[23:34] <wxl> crazy)
[23:34] <jose> yeah of course, we can take the verification responsibilities in the meantime, but I would like to get that committee together to analyze what we have
[23:35] <jose> I know of teams like US-AZ, for example, that still hold meetings :)
[23:35] <Eickmeyer> But are they functioning as a LoCo or a LUG?
[23:36] <jose> I haven't checked, but as meetingology's owner, I get messages saying they have ended a meeting :)
[23:36] <toddy> we can try it out with a committee. I think we should have in there some of active members of the locos
[23:36] <nhaines> I think contacting the teams that are verified or became unruffled I'm the last two years would be a good start.
[23:36] <nhaines> *unverified in the last two years
[23:36] <jose> right, but that in and of itself is a huge task. which is why I think a committee is a good idea
[23:36] <jose> be it verified or unverified
[23:37] <nhaines> Oh no, I see autocorrect has decided to sabotage me today! :)
[23:37] <Eickmeyer> I can also think of a few teams that need to be dissolved, if they aren't already.
[23:37] <wxl> i would like to see the committee include members of locos that are active and excited, even if they aren't verified
[23:37] <jose> totally!
[23:37] <Eickmeyer> Yep.
[23:37] <toddy> +1
[23:38] <nhaines> +1
[23:38] <jose> I would, however, require these people be ubuntu members.
[23:38] <wxl> and preferably, across a wide geographical makeup
[23:38] <jose> ^
[23:38] <Eickmeyer> wb linaporras
[23:38] <wxl> we can't just have people from asia or just from europe and certainly not just from north america
[23:38] <jose> if they are not ubuntu members but we feel like they have had enough participation like to become an ubuntu member, we can always ask them to go through the process
[23:38] <linaporras> I lost my connection :'(
[23:38] <jose> totally believe in diversity
[23:39] <jose> welcome back!
[23:39] <wxl> agree with the ubuntu members thing
[23:39] <wxl> the reason i want to see the wide grographical makeup is not because of diversity but because i think truly each location has different needs and it would be nice to see those represented as well as they can be
[23:39] <jose> Lina, I'm going to send you all the conversation we just had via PM so you can review
[23:40] <jose> and we're going to give you a couple minutes to catch up in case you surface any concerns, risks, or questions
[23:40] <teward> agree with wxl on the wide needs dispersion and representation of different areas' needs.
[23:40] <linaporras> thank u jose
[23:40] <teward> And point #3 that was not seen by wxl in my regard of COVID was this:
[23:41] <teward> if LoCo teams need funding for events, etc. we can't reliably approve/etc. any of that because of the nature of the current Pandemic
[23:41] <jose> +1 to the globality, diversity, and inclusion part
[23:41] <teward> therefore #1 and #2 that wxl said is accurate.
[23:41] <jose> unless they're in a covid-free country :)
[23:42] <teward> but also that we need to keep this pandemic in mind with anything LoCo related because of local issues with the various issues this ongoing chaos year is bringing to regions and areas.
[23:42] <teward> jose: you mean Antarctica right?  :P
[23:42] <jose> New Zealand!
[23:42] <jose> or Australia!
[23:42] <linaporras> jajaja, some African countries reports low cases of COVID...
[23:42] <jose> The pandemic, however, is also forcing us to re-think our strategies
[23:42] <linaporras> Well... I have a question... form my ignorance... the membership board is having the meetings for new members approval... jus to verify... because I am not sure
[23:43] <wxl> yes linaporras
[23:43] <jose> Yes, they are.
[23:43] <jose> And I got the list of nominations
[23:43] <linaporras> thank u!
[23:43] <jose> I just need to make it pretty, officially present it to you, and we can go from there
[23:43] <wxl> the membership board overall is doing pretty good. there's still interest in helping with the board, people still want to be members, etc.
[23:44] <wxl> i will also say that the past few boards have done some heavy lifting to improve documentation and such, so that's a pretty healthy project
[23:44] <toddy> wxl: yes, I agree
[23:45] <teward> unrelated FYI I have a hard-stop at 19:00 my time (15 minutes) as i have another meeting for work I *must* be in (IT Security related heavy discussionss)
[23:45] <teward> so if I just die in 15 minutes that's why ^
[23:45] <Eickmeyer> ^ Same, hard-stop at 16:00 my time, work meeting.
[23:45] <wxl> ok let's move forward
[23:45] <jose> toddy, nhaines, linaporras, Eickmeyer, wxl: last call for concerns and queries about the committee project
[23:45] <toddy> my bed is waiting in 15 min
[23:45] <wxl> it sounds like we're in agreement here. so how do we form this committee?
[23:46] <linaporras> I want ot participate in that mission
[23:46] <linaporras> *to
[23:46] <jose> I would prefer if we act in observation
[23:46] <nhaines> I feel like we have a good plan to start getting things going again.
[23:46] <jose> So, next steps for the committee:
[23:46] <wxl> i would be open to letting lina suggest candidates
[23:47] <jose> oh, totally
[23:47] <jose> so, next steps:
[23:47] <linaporras> I disagree.... I think that we need to be active in this... and thats the reason I want to participate..
[23:47] <jose> 1.- Define the criteria to form the committee and the number of members it'll have based on our diversity expectations
[23:47] <linaporras> Diverse...
[23:47] <linaporras> 3 to 5 members
[23:47] <jose> 2.- Put out a call for nominations for the committee
[23:48] <jose> 3.- Vote, select, give a timeframe and scope of work
[23:48] <jose> and then they can get rolling
[23:48] <jose> I think we should discuss and draft the criteria in the ML and then come back here in two weeks to report results
[23:48] <jose> Lina, I don't say that you won't be able to participate, but rather that we shouldn't be direct members of the committee
[23:49] <jose> We would oversee the committee and the work that they do, but we have bigger and other varied responsibilities here
[23:49] <wxl> i agree
[23:49] <toddy> ok
[23:49] <jose> So, of course we can get involved with the work, but we should delegate this work
[23:49] <wxl> that said, if one or more of us wants to actively participate, i don't think that's a bad idea
[23:49] <wxl> echo
[23:49] <jose> right, but as outside members providing feedback to this independent entity
[23:50] <jose> and super valuable feedback considering our experience
[23:50] <linaporras> Could be... If I have luck, I will have reach some people from locos to listen them separetly and se the intentions to participate... I think that is an important point...   I will try to reach the ubuntu members and the information from locos... to see how we can achieve representativeness, and how can we start moving people
[23:50] <linaporras> *see
[23:50] <linaporras> is that ok for u all?
[23:51] <jose> of course, if you have any recommendations they're more than welcome to nominate themselves for the committee
[23:51] <jose> and if they're not yet an Ubuntu Member, they can apply for membership
[23:51] <linaporras> Yes!
[23:51] <linaporras> That's an excellent point!
[23:51] <toddy> fine
[23:51] <jose> or you can also nominate them yourself
[23:52] <jose> anyone wants to put this to a vote, or are we all good to go with what's been listed so far?
[23:52] <wxl> so jose you going to send something to the ML about criteria and such?
[23:52] <jose> unless toddy wants to inherit it
[23:52] <wxl> i'm not hearing much in the way of dissention so it sounds like we should move forward
[23:52] <jose> but I'd be happy to own it
[23:52] <toddy> I think, we don't need a vote
[23:52] <jose> Eickmeyer, teward, nhaines?
[23:52] <Eickmeyer> No objection.
[23:52] <teward> no objections here
[23:52] <jose> I'll give them 30 secs before I move to the other topic
[23:53] <teward> *salts jose for delay*
[23:53] <wxl> ok any takers for defining the criteria? else it goes to jose
[23:53] <nhaines> I think we're good so far.
[23:53] <teward> not it :P
[23:53] <wxl> not it
[23:53] <Eickmeyer> not it
[23:53] <jose> >.>
[23:53] <jose> okay, in the interest of time I'll take it and then we can discuss if it needs to shift around
[23:53] <wxl> (this is not representative of my interest in the subject, just trying to be wise with my time)
[23:53]  * Eickmeyer started a new job and has a bit of a full plate now
[23:53] <jose> congrats!
[23:54] <jose> does anyone have aob they'd like to bring to the meeting?
[23:54] <wxl> yes congrats indeed
[23:54] <jose> otherwise I'll go with mine
[23:54] <wxl> i think those were the two big hot things
[23:54] <Eickmeyer> In the interest of time, Go jose.
[23:54] <jose> #topic Membership Board Elections
[23:54] <teward> RE: TB we all knew going into today we might have toget that extended so :P
[23:54] <jose> things are moving forward with the MB elections
[23:54] <jose> they've sent over a list of 7-8 nominations
[23:55] <wxl> we have all the nominees yes?
[23:55] <jose> yes
[23:55] <jose> I just need to put it in a nice list for you to just see and we can take a peek
[23:55] <wxl> yes that would be preferable
[23:55] <jose> I *think* we'll have a quorum
[23:55] <jose> does anyone have any questions about that?
[23:55] <jose> I'd say it's all smooth sailing for now
[23:55] <wxl> yes i think that will go rather quick and easy
[23:56] <wxl> i will say something about elections: i found more than a few bugs in our script to generate emails, if anyone is bored and wants something to do :)
[23:56] <jose> I don't think this one needs a general vote
[23:56] <teward> once I see the list of nominations I'll provide my 2 cents if we need to reject a nominee - I haven't seen the list yet due to chaotic workplace
[23:56] <jose> just outs
[23:56] <jose> no prob
[23:56] <jose> I'll make sure that we get all of your perspectives
[23:57] <jose> #topic Any other business?
[23:57] <jose> anything else anyone wants to bring to the table?
[23:57] <teward> yeah where's my coffee you promised me :P
[23:57] <teward> (jk)
[23:57] <jose> I'll send you a starbucks gift card shortly
[23:57] <nhaines> I'll have a tea, please!
[23:57] <wxl> anyone else from the general public?
[23:57] <wxl> tea for me, too, please.
[23:57] <wxl> and not from starbucks XD
[23:57] <teward> just send me $20 via Venmo, i'll call it even xD  (yes myself and jose and everyone joke around a lot, it's just us being kind)
[23:57] <linaporras> jajaja
[23:57] <teward> (and friendly)
[23:57] <teward> oh right
[23:58] <teward> one note on the TB thing
[23:58]  * wxl never jokes and is always incredibly serious, including right now
[23:58] <teward> I already sent the email to the TB and cc'd the CC about the extension and updated the bug
[23:58] <teward> just for awareness :)
[23:58] <jose> thanks a lot for your proactiveness :)
[23:58] <jose> Eickmeyer, toddy, any other business you'd like to discuss?
[23:58] <toddy> jose: no
[23:58] <wxl> oh
[23:58] <Eickmeyer> I've got nothing.
[23:58] <jose> wxl, got something?
[23:58] <wxl> did we make any progress getting access to discourse?
[23:59] <jose> thanks for reminding me
[23:59] <jose> no
[23:59] <jose> I was going to ping IS today and then got swamped by meetings
[23:59] <wxl> and what was it you were contacting rt about yesterday toddy?
[23:59] <jose> I'll set a reminder to do it at 9am my time tomorrow
[23:59] <toddy> the pad, wxl
[23:59] <teward> jose: I think IS got swamped with issues with security.u.c today
[23:59] <wxl> oh right
[23:59] <toddy> the pad was broken
[23:59] <nhaines> I think I might have elevated rights on Discourse.
[23:59] <teward> so today would've been a bad poke day anyways
[23:59] <toddy> so they have restore the etherpad
[23:59] <jose> just pinged them regardless


[16:20] <axisys> when I run my laptop with wifi, it gets very slow after running for few hrs.. i have to reboot to fix it..
[16:20] <axisys> is this a know bug?
[21:23] <mdke> no one with a T43 by any chance?
[21:24] <mdke> I've just had mine back from the repairer, and I've discovered that Ubuntu doesn't detect my hard disk anymore... Windows boots ok. They have done a bios update, could that cause it?
[21:24] <mdke> I've tried feisty and gutsy live cds
[21:27] <mdke> dmesg is at http://paste.ubuntu.com/2009/