| veebers | wallyworld: hmm, I've never heard of that before and can't find any reference to it. Looks like jujugui bot commented on the previous PRs so perhaps handled by them? | 00:09 |
|---|---|---|
| wallyworld | veebers: could be the case, i'll follow up, thanks | 00:10 |
| veebers | wallyworld: sweet, sorry to pass it off :-\ | 00:12 |
| wallyworld | totslly ok | 00:12 |
| anastasiamac | could i get an easy review of resources cmd registration complying with the fold - https://github.com/juju/juju/pull/7686 | 00:19 |
| babbageclunk | anastasiamac: lookinh | 00:20 |
| babbageclunk | g | 00:20 |
| wallyworld | menn0: i've replied, i hope it makes sense | 00:23 |
| menn0 | wallyworld: ok thanks | 00:23 |
| anastasiamac | babbageclunk: \o/ | 00:24 |
| menn0 | wallyworld: that helps | 00:25 |
| wallyworld | menn0: still haven't decided whether we need status history etc. regardless, i think having status attribute on relation doc for the current value is useful; any history would be stored in the separate collection | 00:26 |
| wallyworld | makes the watcher much easier to write | 00:26 |
| menn0 | wallyworld: that sounds right. i'm not sure about the need for history either. | 00:26 |
| menn0 | I guess i'm not clear on what would cause the status to change | 00:26 |
| wallyworld | if someone revokes an offer for example | 00:27 |
| wallyworld | because a bill is unpaid or whatever | 00:27 |
| wallyworld | of they exceed a quota | 00:27 |
| wallyworld | *or | 00:27 |
| menn0 | ok cool | 00:27 |
| wallyworld | any relations to that offer would become revoked | 00:27 |
| wallyworld | departed hooks would run | 00:28 |
| wallyworld | but relation is still there | 00:28 |
| wallyworld | rendered somehow in gui and inactive | 00:28 |
| wallyworld | able to be re-enabled again | 00:28 |
| babbageclunk | anastasiamac: lgtm'd | 00:28 |
| menn0 | wallyworld: cool. that helps my understanding a lot. | 00:28 |
| wallyworld | menn0: sorry for brief PR description, there wasn't a lot of context there for sure | 00:29 |
| menn0 | all good | 00:29 |
| menn0 | wallyworld: review done | 00:41 |
| wallyworld | menn0: thanks for review. i considered the simpler approach with the strings watcher and followup api call. but for cross controller communication, i was trying to eliminate the chattiness. in this use case, we don't need to know anything else from the watched model apart from life/status, so making a second api call (potentially across clouds) to get a simple scalar value that is instead passed across with the initial notification seemed | 01:24 |
| wallyworld | wasteful and something that would not scale so well. what do you think? with the notify->api call approach, i'd still need to do extra code to provide the apis to get the relation life/status. so there's no real net code reduction. and it is more chatty which is bad for networked services. i'm happy to revisit though if needed | 01:24 |
| menn0 | wallyworld: np. as long as you've thought about it :) | 01:28 |
| wallyworld | menn0: the non-simple approach did bother me though. i'm still not 100% convinced it's the right thing to do to deviate from the model used elsewhere. what is your regret about the migration watcher? | 01:30 |
| menn0 | wallyworld: a couple things: if you want access to the data/logic behind the watcher *without* using a watcher you end up having to double it up | 01:33 |
| menn0 | wallyworld: and: managing the changing of data returned by a watcher API is more painful | 01:34 |
| menn0 | they're harder to version | 01:34 |
| wallyworld | menn0: the watcher events arrive in the order they are generated server side i think? in my case here, we just care about knowing the last/latest status value. there's always the chance that the relation could go active again on the other side after you get told it's revoked, but there'd still be an as yet undelivered notification to act on to correct things. and life can only go one way. so i think it works out ok? | 01:39 |
| menn0 | wallyworld: if you only need to know the latest status, then the "notify and check" pattern is probably better | 01:40 |
| menn0 | wallyworld: b/c the API call to get current state, sees the latest state | 01:41 |
| menn0 | wallyworld: where-as queued up "rich" notifications could have stale data in them | 01:41 |
| wallyworld | it does. but it's an api call that would otherwise not need to be made | 01:41 |
| menn0 | wallyworld: totally | 01:41 |
| menn0 | wallyworld: in this case, b/c of the nature of the API requests (cross-cloud), a specialised watcher certainly makes more sense | 01:42 |
| wallyworld | and multiple that uneeded api call by 1000 or however many consumers there are | 01:42 |
| wallyworld | more load on the offering controller | 01:42 |
| wallyworld | babbageclunk: did you see comment #7 on this bug 1705730? | 02:05 |
| mup | Bug #1705730: `juju migrate` fails with source prechecks failed ERROR <juju:New> <https://launchpad.net/bugs/1705730> | 02:05 |
| babbageclunk | wallyworld: no, I hadn't - thanks | 02:06 |
| wallyworld | np, i assumed you had been looking at it? | 02:06 |
| wallyworld | axw: thanks for review | 02:23 |
| axw | babbageclunk: your PR is good to land | 02:43 |
| anastasiamac | another tiny and easy review, please \o/ https://github.com/juju/juju/pull/7688 (order resources list output) | 02:43 |
| babbageclunk | axw: oh, thanks! | 02:47 |
| babbageclunk | thumper: can you merge https://github.com/juju/1.25-upgrade/pull/6 plz? | 02:48 |
| thumper | babbageclunk: you can now | 02:48 |
| babbageclunk | thumper: oh, so I can - thanks! | 02:49 |
| axw | wallyworld: can you please create a section under TODO in leankit for 1.25 upgrades? | 04:42 |
| wallyworld | sure | 04:42 |
| wallyworld | axw: done | 04:45 |
| axw | wallyworld: gracias | 04:45 |
| axw | babbageclunk: if you've got things to add ^^ | 04:45 |
| babbageclunk | axw: oh yes, good call | 04:48 |
| babbageclunk | axw: how can I find what permissions I have on a model? | 05:31 |
| babbageclunk | axw: (or what permissions some other juju user has on the model) | 05:32 |
| axw | babbageclunk: I think "juju show-model" lists users/access | 05:33 |
| axw | yep | 05:33 |
| babbageclunk | axw: ok - so as a superuser I should be able to grant access to a model to myself, I guess? | 05:34 |
| axw | babbageclunk: yep | 05:35 |
| === frankban|afk is now known as frankban | ||
| === frankban is now known as frankban|afk | ||
| menn0 | wallyworld, axw or thumper: I need to bounce some ideas off someone | 23:26 |
| wallyworld | ok | 23:27 |
| menn0 | wallyworld: quick hangout? | 23:28 |
| menn0 | wallyworld: https://hangouts.google.com/hangouts/_/canonical.com/menn0-wallyworld | 23:29 |
| wallyworld | sure | 23:29 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!