[00:46] <babbageclunk> wallyworld: yup, looking at it now
[00:50] <wallyworld> \o/
[03:32] <axw> menn0 wallyworld thumper: tech board? anything to talk about?
[07:31] <menn0> axw: sorry I missed tech board. things got a little crazy at home.
[07:35] <axw> menn0: no worries
[07:35] <menn0> axw: did the meeting end up happening
[07:35] <menn0> ?
[07:35] <axw> menn0: nah, just had a chat with ian about the sprint last week. john's out, and tim's sick
[09:39] <rogpeppe1> here's a feature branch merge; anyone wanna give it the nod? https://github.com/juju/juju/pull/7099
[10:16] <rogpeppe1> jam: any chance you could approve this feature-branch merge, please? https://github.com/juju/juju/pull/7099
[10:28] <rogpeppe1> jam: i'm going to merge it anyway, as all the individual branches have been approved
[11:44] <perrito666> good morning
[13:02] <perrito666> wpk: standup?
[14:15] <stokachu> rogpeppe1: what python library should we be using if we wanted to look into adding macaroon support?
[14:15] <stokachu> rogpeppe1: apparently go is the only one with these bindings anywhere...
[14:15] <stokachu> sorry, bakery support
[14:23] <rogpeppe1> stokachu: i'm not sure that there is any decent general one yet
[14:24] <rogpeppe1> stokachu: people have been talking about it for a while
[14:24] <rogpeppe1> stokachu: it also depends whether you want to do server support too, or just client support
[15:00] <stokachu> rogpeppe1: we just need a seamless experience from conjure-up's ui to be able to connect to jaas controller
[15:00] <stokachu> without sending them to the browser
[15:01] <rogpeppe1> stokachu: personally i think that we shouldn't expect people to type their passwords into arbitrary command-line apps
[15:02] <rogpeppe1> stokachu: and AFAIK using a browser login is the only reasonable way to avoid that
[15:02] <stokachu> rogpeppe1: ok, lemme go back to the boss man and see what we want to do
[15:02] <rogpeppe1> stokachu: juju has supported entering a password on the command line
[15:02] <rogpeppe1> stokachu: but it's flawed
[15:03] <rogpeppe1> stokachu: because it doesn't work the first time (it relies on the user having used the browser-based login previously)
[15:03] <cory_fu> rogpeppe1, stokachu: What about the case where the user is running conjure-up on a machine that isn't running a gui, or if they're ssh'd in?  I thought that's why we were using a terminal UI instead of the GUI in the first place?
[15:03] <rogpeppe1> cory_fu: you can still use the browser-based login in that case
[15:03] <cory_fu> rogpeppe1: I should also note that `charm login` prompts for user and password
[15:04] <rogpeppe1> cory_fu: just as long as you have access to a browser and can copy/paste the URI
[15:04] <rogpeppe1> cory_fu: yes, the charm command is also problematic in that respect
[15:04] <cory_fu> rogpeppe1: Why is a browser-based login required before CLI login will work?  That seems very odd to me.
[15:05] <rogpeppe1> cory_fu: because only the browser-based login provides the idm server with the user details it needs
[15:05] <rogpeppe1> cory_fu: it can't get those from an oauth token
[15:06] <rogpeppe1> cory_fu: (which is what the password-based login provides)
[15:07] <rogpeppe1> cory_fu: in the future, i'd like us to be able provide private-key-based login (also known as "agent" login) to arbitrary users.
[15:07] <rogpeppe1> cory_fu: so if you want non-interactive login, you associate a private key with your account and use that to log in.
[15:20] <stokachu> so tldr; we have to use the browser based login approach?
[15:20] <stokachu> rogpeppe1: ^
[15:21] <rogpeppe1> stokachu: well, you *can* use the user-password approach, but i'd suggest leaving that until last, as we don't have a decent answer to that yet.
[15:21] <stokachu> rogpeppe1: im talking about we need this done in the next week or so
[15:21] <stokachu> :D
[15:21] <rogpeppe1> stokachu: and it will always be necessary to support at least the browser-based approach
[15:22] <stokachu> i see, ok
[15:22] <rogpeppe1> stokachu: because you can't do password-based login to non-usso domains
[15:22] <stokachu> ok thank you
[15:24] <Dmitrii-Sh> Hi, does anybody know a good way to specify series when upgrading a charm to a local version? https://paste.ubuntu.com/24183189/
[15:25] <Dmitrii-Sh> right now xenial is picked while I need trusty. I don't see any switch to manually select a version
[15:25] <rogpeppe1> Dmitrii-Sh: you can't change the series of a deployed application
[15:25] <Dmitrii-Sh> rogpeppe1: I don't need to change it - that's the thing
[15:26] <Dmitrii-Sh> rogpeppe1: the problem here is that it thinks that I want to deploy a xenial charm
[15:26] <rogpeppe1> Dmitrii-Sh: oh yes, that does seem odd
[15:26] <rogpeppe1> Dmitrii-Sh: is this with juju 2?
[15:26] <Dmitrii-Sh> rogpeppe1: if I remove xenial and yakkety from the yaml it deploys just fine
[15:26] <Dmitrii-Sh> 2.1.1-xenial-amd64
[15:26] <Dmitrii-Sh> rogpeppe1: yes
[15:26] <rogpeppe1> Dmitrii-Sh: looks like a bug to me
[15:26] <Dmitrii-Sh> rogpeppe1: ok, will file it now
[15:27] <Dmitrii-Sh> rogpeppe1: been driving me crazy for some time )
[15:27] <Dmitrii-Sh> rogpeppe1: thx
[15:34] <rogpeppe1> Dmitrii-Sh: try using --force-series
[15:34] <Dmitrii-Sh> rogpeppe1: I can try that but that's still a bug, right?
[15:34] <rogpeppe1> Dmitrii-Sh: but even if that works, it still seems like a bug, yeah
[15:36] <Dmitrii-Sh> rogpeppe1:
[15:36] <Dmitrii-Sh> ubuntu@maas:~⟫ juju upgrade-charm keystone --force-series --path ~/build/charm-keystone
[15:36] <Dmitrii-Sh> Added charm "local:xenial/keystone-4" to the model.
[15:36] <Dmitrii-Sh> ERROR cannot upgrade application "keystone" to charm "local:xenial/keystone-4": cannot change an application's series
[15:37] <Dmitrii-Sh> rogpeppe1: doesn't look right
[15:37] <rogpeppe1> agreed
[15:44] <Dmitrii-Sh> rogpeppe1: https://bugs.launchpad.net/juju/+bug/1673122
[15:44] <mup> Bug #1673122: Incorrect series used during upgrade to a local charm and no way to specify it manually <juju:New> <https://launchpad.net/bugs/1673122>
[15:44] <Dmitrii-Sh> rogpeppe1: the order of items in a list matters
[15:44] <Dmitrii-Sh> rogpeppe1: so yakkety at the bottom didn't trigger an error )
[15:44] <rogpeppe1> Dmitrii-Sh: yeah, i see
[15:44] <rogpeppe1> Dmitrii-Sh: nice report, thanks
[15:45] <Dmitrii-Sh> rogpeppe1: np, thanks for the clarification
[15:47] <rogpeppe1> Dmitrii-Sh: thanks for the report.
[15:47] <rogpeppe1> Dmitrii-Sh: and discovering the issue
[15:47] <rogpeppe1> Dmitrii-Sh: i suspect it might be fairly simple to fix
[18:29] <perrito666> bbl
[18:57] <rogpeppe1> i'm looking for reviews of this, please: https://github.com/juju/juju/pull/7074
[20:32] <thumper> morning
[20:37] <perrito666> thumper: hi
[21:46] <babbageclunk> wallyworld: ping?
[21:46] <wallyworld> hey
[21:47] <babbageclunk> From this https://cloud.google.com/compute/docs/subnetworks#subnetworks_and_instances, it sounds like subnets in GCE don't have zones.
[21:48] <babbageclunk> wallyworld: Should I just leave zones empty in the return from the provider, or get all zones and populate it with them?
[21:49] <wallyworld> not sure offhand. i'm not overtly familiar with the underlying juju network model
[21:49] <wallyworld> i'll look into it nd we can discuss
[21:50] <babbageclunk> ok thanks
[22:37] <babbageclunk> wallyworld: also, for our purposes we don't need the instance or subnet filtering of the Subnets method. Should I still implement them now? (Probably, right?)
[22:38] <wallyworld> babbageclunk: would be good to have that method properly implemented
[22:38] <wallyworld> let's try and avoid tech debt
[22:38] <babbageclunk> wallyworld: yeah, that's what I was figuring.
[23:12] <rogpeppe1> wallyworld: hiya
[23:12] <wallyworld> hey
[23:12] <rogpeppe1> wallyworld: i've addressed the initial points you made here... fancy taking another look? https://github.com/juju/juju/pull/7074
[23:12] <wallyworld> sure
[23:12] <rogpeppe1> wallyworld: thanks!
[23:14] <wallyworld> rogpeppe1: just curious, why are those other seemingly non related dependencies updated?
[23:15] <rogpeppe1> wallyworld: mostly because there were some newer dependencies available, i think. i think it's worth keeping up with dependency versions when reasonable.
[23:16] <wallyworld> i figured as much. it does seem strange though that devel branch (our tip) is not running latest deps
[23:17] <wallyworld> i guess those deps were updated for other branches
[23:17] <rogpeppe1> wallyworld: yeah
[23:18] <rogpeppe1> wallyworld: BTW the odd-looking AddDate calls are to make some of the tests pass under >go1.8 (which has monotonic clock readings in time.Time)
[23:18] <wallyworld> cool, i'm running 1.8
[23:18] <wallyworld> we need to fix the url parsing issues also
[23:20] <rogpeppe1> wallyworld: yeah, we shouldn't provide invalid URLs :)
[23:20] <wallyworld> +1 to that
[23:23] <wallyworld> rogpeppe1: i just saw the AddDate() stuff - it would be worth a comment. without your explanation, I had NFI why that was there
[23:23] <rogpeppe1> wallyworld: yeah, agreed. please add a comment to remind me for the morning
[23:23] <wallyworld> maybe even a todo to use the clock.Clock
[23:23] <wallyworld> will do
[23:27] <wallyworld> rogpeppe1: why remove our clock.Clock from lease manager?
[23:27] <wallyworld> and replace with state.clock
[23:27] <wallyworld> that's the opposite of what we are trying to do
[23:28] <rogpeppe1> wallyworld: file, line?
[23:28] <wallyworld> 76 of state/workers.go
[23:28] <wallyworld> the "github.com/juju/utils/clock" import is deleted alsdo
[23:30] <rogpeppe1> wallyworld: the lease manager still takes a clock as a parameter
[23:30] <wallyworld> the comment applies to all of those workers
[23:30] <rogpeppe1> wallyworld: why would wouldn't you want them all to use the same clock?
[23:30] <wallyworld> right, but the state.clock is being passed in, has that been changed to a clock.Clock?
[23:30] <rogpeppe1> wallyworld: state.clock has always been a clock.Clock
[23:31] <wallyworld> ok, makes more sense now, thanks
[23:32] <wallyworld> so the removal of workerFactory means we can get the clock from st
[23:32] <rogpeppe1> wallyworld: BTW i think that except for low level, "i know everything that's going on" testing, mocking clocks is probably an anti-pattern, as it can make for extremely fragile tests.
[23:33] <wallyworld> it's been the exact opposite for us
[23:33] <wallyworld> we've needed to do it to *fix* fragile tests
[23:33] <wallyworld> any tests based on wall clock are just plain wrong for us
[23:34] <wallyworld> we need to step through known time increments
[23:34] <wallyworld> to trigger various events
[23:34] <wallyworld> that's a pretty standard pattern i would have thought?
[23:35] <wallyworld> many devs on core have certainly commonly used it elsewhere outside canonical
[23:35] <wallyworld> eg if something triggers every 30 minutes, you can't use a wall clock for that
[23:35] <wallyworld> in a unit test
[23:36] <wallyworld> we've also been victim to waiting say 10ms for something fails on loaded substrates
[23:36] <rogpeppe1> wallyworld: yeah, for low level unit tests, it's very useful
[23:36] <wallyworld> we need control of the clock ticks
[23:36] <rogpeppe1> wallyworld: but when you've got a bunch of components together, you end up needing to know exactly how many actors there are in the system and when you expect them to wait
[23:37] <rogpeppe1> wallyworld: and even then you're vulnerable to races
[23:37] <wallyworld> isn't that the point of detailed unit tests :-)
[23:37] <rogpeppe1> wallyworld: definitely
[23:37] <rogpeppe1> wallyworld: but i'm talking about somewhat higher level tests
[23:37] <wallyworld> ok, so we're in violent agreement :-)
[23:38] <wallyworld> too many of our juju core tests should be unit tests but are not :-(
[23:38] <rogpeppe1> wallyworld: so where we're using clock in state with all those workers - that for me is probably too far.
[23:38] <wallyworld> we've been actively trying to fix that
[23:38] <wallyworld> how then would you test the interaction between workers?
[23:39] <wallyworld> if you don't control the clock in tests?
[23:39] <rogpeppe1> wallyworld: i don't like the distinction between unit tests and integration tests. i prefer the distinction they tend to use in google - quick tests and slow tests.
[23:39] <rogpeppe1> wallyworld: i'd set the worker timing parameters and poll. And try and have less dependencies in general.
[23:39] <wallyworld> unit tests are needed to give coverage; intergration tests more for "does it really work"
[23:40] <rogpeppe1> wallyworld: for me, it's all about confidence in the code.
[23:40] <rogpeppe1> wallyworld: anyway, gotta run! i am called to bed.
[23:40] <wallyworld> lucky you
[23:40] <wallyworld> have fun :-)
[23:40] <rogpeppe1> ttfn