| babbageclunk | wallyworld: yup, looking at it now | 00:46 |
|---|---|---|
| wallyworld | \o/ | 00:50 |
| axw | menn0 wallyworld thumper: tech board? anything to talk about? | 03:32 |
| menn0 | axw: sorry I missed tech board. things got a little crazy at home. | 07:31 |
| 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 | 07:35 |
| === frankban|afk is now known as frankban | ||
| rogpeppe1 | here's a feature branch merge; anyone wanna give it the nod? https://github.com/juju/juju/pull/7099 | 09:39 |
| rogpeppe1 | jam: any chance you could approve this feature-branch merge, please? https://github.com/juju/juju/pull/7099 | 10:16 |
| rogpeppe1 | jam: i'm going to merge it anyway, as all the individual branches have been approved | 10:28 |
| perrito666 | good morning | 11:44 |
| === petevg is now known as petevg_afk | ||
| perrito666 | wpk: standup? | 13:02 |
| 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:15 |
| rogpeppe1 | stokachu: i'm not sure that there is any decent general one yet | 14:23 |
| 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 | 14:24 |
| 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:00 |
| rogpeppe1 | stokachu: personally i think that we shouldn't expect people to type their passwords into arbitrary command-line apps | 15:01 |
| 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:02 |
| 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:03 |
| 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:04 |
| 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:05 |
| rogpeppe1 | cory_fu: (which is what the password-based login provides) | 15:06 |
| 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:07 |
| stokachu | so tldr; we have to use the browser based login approach? | 15:20 |
| stokachu | rogpeppe1: ^ | 15:20 |
| 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:21 |
| 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:22 |
| 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:24 |
| 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:25 |
| 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:26 |
| Dmitrii-Sh | rogpeppe1: been driving me crazy for some time ) | 15:27 |
| Dmitrii-Sh | rogpeppe1: thx | 15:27 |
| 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:34 |
| 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:36 |
| Dmitrii-Sh | rogpeppe1: doesn't look right | 15:37 |
| rogpeppe1 | agreed | 15:37 |
| 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:44 |
| Dmitrii-Sh | rogpeppe1: np, thanks for the clarification | 15:45 |
| 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 | 15:47 |
| === frankban is now known as frankban|afk | ||
| perrito666 | bbl | 18:29 |
| rogpeppe1 | i'm looking for reviews of this, please: https://github.com/juju/juju/pull/7074 | 18:57 |
| === rogpeppe1 is now known as rogpeppe | ||
| thumper | morning | 20:32 |
| perrito666 | thumper: hi | 20:37 |
| babbageclunk | wallyworld: ping? | 21:46 |
| wallyworld | hey | 21:46 |
| babbageclunk | From this https://cloud.google.com/compute/docs/subnetworks#subnetworks_and_instances, it sounds like subnets in GCE don't have zones. | 21:47 |
| babbageclunk | wallyworld: Should I just leave zones empty in the return from the provider, or get all zones and populate it with them? | 21:48 |
| 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:49 |
| babbageclunk | ok thanks | 21:50 |
| 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:37 |
| 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. | 22:38 |
| 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:12 |
| wallyworld | rogpeppe1: just curious, why are those other seemingly non related dependencies updated? | 23:14 |
| 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:15 |
| wallyworld | i figured as much. it does seem strange though that devel branch (our tip) is not running latest deps | 23:16 |
| wallyworld | i guess those deps were updated for other branches | 23:17 |
| rogpeppe1 | wallyworld: yeah | 23:17 |
| 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:18 |
| rogpeppe1 | wallyworld: yeah, we shouldn't provide invalid URLs :) | 23:20 |
| wallyworld | +1 to that | 23:20 |
| 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:23 |
| 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:27 |
| 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:28 |
| 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:30 |
| wallyworld | ok, makes more sense now, thanks | 23:31 |
| 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:32 |
| 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:33 |
| 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:34 |
| 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:35 |
| 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:36 |
| 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:37 |
| 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:38 |
| 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:39 |
| 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 | 23:40 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!