| wallyworld | axw: when you get back online, if you have a chance pretty please https://github.com/juju/juju/pull/7021 | 01:44 |
|---|---|---|
| axw | wallyworld: swap you? :) https://github.com/juju/juju/pull/7015 | 01:47 |
| wallyworld | sure | 01:47 |
| axw | wallyworld: not a very fair trade, except that you've reviewed most of that PR before | 01:50 |
| axw | might be long enough ago that you've forgotten it though | 01:51 |
| axw | wallyworld: it can wait a bit if you're busy | 01:51 |
| wallyworld | axw: tis ok, yours is +500/-200, mine is +700/-70, about the same really :-) | 01:51 |
| axw | wallyworld: yeah, yours is a lot of boilerplate though :) | 01:52 |
| wallyworld | it is, i wish we didn't need so much of that | 01:52 |
| redir | at least it is sturdy if not reusable:) | 01:54 |
| wallyworld | axw: yeah, i started to remember the code once i read the PR. LGTM, I'm just ducking out to get lunch | 02:07 |
| axw | wallyworld: thanks | 02:07 |
| thumper | anyone https://github.com/juju/juju/pull/7022 | 02:19 |
| babbageclunk | wallyworld - did offer-name just go away on remote applications? | 03:05 |
| babbageclunk | wallyworld: (Where "just" = in the last day or so.) I have it on my description and now can't see why I added it. | 03:08 |
| wallyworld | babbageclunk: nothing has changed in the last day or so | 03:24 |
| wallyworld | babbageclunk: the state object still has it - but it may not always get set | 03:26 |
| wallyworld | yet | 03:26 |
| babbageclunk | wallyworld: but there's no offer-name field in the remoteApplicationDoc? | 03:29 |
| wallyworld | babbageclunk: line 34 of remoteapplication.go | 03:30 |
| wallyworld | in state | 03:30 |
| babbageclunk | wallyworld: should I be working against 2.1 or develop? | 03:31 |
| wallyworld | develop! | 03:31 |
| wallyworld | 2.1 is for hosted juju beta and container networking only | 03:31 |
| babbageclunk | wallyworld: gah, that'll be it. Sorry, was losing it there. | 03:32 |
| wallyworld | no wuckers | 03:32 |
| babbageclunk | hey veebers raised bug 1667172 for adoptresources on GCE - I'll jump on that once I finish this, ok? | 03:35 |
| mup | Bug #1667172: Migrated model fails to be removed from list-models in GCE <ci> <gce-provider> <model-migration> <juju:Confirmed for 2-xtian> <https://launchpad.net/bugs/1667172> | 03:35 |
| wallyworld | sure ty | 03:36 |
| wallyworld | axw: i'm hopeless at names, but i sort of did have the same hesitation. Perhaps "networkmanager" or "networks" | 03:36 |
| axw | wallyworld: remotenetworks? it's meant for access by a remote model only right? | 03:38 |
| wallyworld | yeah | 03:38 |
| wallyworld | but it could point to a local model also | 03:38 |
| axw | wallyworld: local as in local to the controller? | 03:38 |
| wallyworld | yeah, it could (nothing stops it). but the intended usage is to go to a remote model | 03:39 |
| axw | wallyworld: I don't think we need to make a distinction there, as long as they can auth | 03:39 |
| wallyworld | right, hence just "networks" rather than remotenetworeks | 03:39 |
| wallyworld | "remoterelations" is so called because the objects are remote relations | 03:40 |
| axw | wallyworld: I meant remote as in cross-model, rather than cross-controller | 03:40 |
| wallyworld | i think we're in violent agreement? | 03:40 |
| wallyworld | "networks" reflects the semantics of the facade, not where it might point to | 03:41 |
| axw | wallyworld: I just want the name to convey the limited scope | 03:41 |
| axw | wallyworld: I guess networs is OK. maybe get jam's opinion later | 03:41 |
| axw | networks* | 03:41 |
| wallyworld | ok. you can give the a facade any model api connection and it will operate against that model (in any given controller) regardless of the model against which the worker is running | 03:42 |
| axw | wallyworld: yes, I know. but the name we give might suggest that you could do more than you should be able to. people have a tendency to chuck unrelated functionality together, and an uninformative name makes that more likely to happen | 03:44 |
| wallyworld | in the remoterelations worker, we define an RemoteRelationChangePublisher interface - the semantics is that it publishes changes to a remote relation entity, and just so happens to do so to the model connection which it is given, which will be a different model to the worker | 03:44 |
| wallyworld | i agree we can tend to lump stuff together | 03:45 |
| wallyworld | i'll get confirmation on the name | 03:46 |
| wallyworld | assume "networks" for now | 03:46 |
| anastasiamac | axw: wallyworld: 1 line trivial :D https://github.com/juju/juju/pull/7023 | 04:35 |
| axw | anastasiamac: LGTM | 04:36 |
| anastasiamac | axw: \o/ | 04:38 |
| wallyworld | axw: i'm relocating before next meeting, have pushed changes to that PR whenever you have a chance | 04:43 |
| axw | wallyworld: thanks, looking | 04:44 |
| wallyworld | ta | 04:44 |
| wallyworld | bbiab | 04:44 |
| wallyworld | jam: with a new facade to provide WatchSubnets(), and also IngressSubnetsForRelation() which I will be moving off the RemoteRelationFacade, do you like the name "Networks" for the facade? | 05:58 |
| jam | wallyworld: hi. offhand "Networks" seems way to generic. I like having it have "Remote" in the name, to mean "these are the type of queries something that is not 'native' to this model can access" | 06:35 |
| wallyworld | jam: but that's not the semantics offered by the facade | 06:35 |
| jam | it wouldn't have to be Remote, but we certainly do consider CMR to have workers that think about their "own" model and a "different" model | 06:35 |
| wallyworld | WatchSubnets() just watches subnets on a model | 06:36 |
| wallyworld | any model | 06:36 |
| wallyworld | the model it watches is defined by the connection it is given | 06:36 |
| wallyworld | just like any other facadde | 06:36 |
| wallyworld | we dure do have many other generic facade names too :-) | 06:38 |
| wallyworld | "charms", "machine", "spaces" | 06:39 |
| jam | wallyworld: but the *intent* is to offer a restricted subset | 06:39 |
| jam | else we end up with lots of things piled into the facade | 06:39 |
| jam | because the local stuff wants it | 06:39 |
| jam | but we shouldn't let remote stuff see it | 06:39 |
| wallyworld | that's what an authorizer is for | 06:39 |
| jam | wallyworld: generally we try to group things on a Facade that act similarly | 06:39 |
| wallyworld | sure | 06:39 |
| jam | wallyworld: we have followed the pattern to date that a worker matches a facade | 06:40 |
| wallyworld | many workers use > 1 facade | 06:40 |
| jam | wallyworld: I'd worry about "these 2 methods are useful for this kind of thing, but these 4 are for other things" | 06:40 |
| wallyworld | if we expect worker to facade to be 1:1 that is plain wrong IMO | 06:40 |
| wallyworld | different layers | 06:40 |
| jam | wallyworld: what workers concretely use >1 facade, we generally have merged 'common' functionality to provide facade groupings | 06:41 |
| jam | that's why lots of facades embed some sort of "common.Lifer" etc | 06:41 |
| wallyworld | remote relations worker is one | 06:41 |
| wallyworld | enforcing worker to facade to be 1:1 romotes big ball of mud | 06:42 |
| jam | wallyworld: so "remote" concretely *has* to use 2 facades because you're talking about 2 models | 06:42 |
| wallyworld | facades should be cohesive. not kitchen sink | 06:42 |
| jam | wallyworld: "this is the collection of APIs that are useful for X" is not a ball of mud | 06:42 |
| wallyworld | no, it uses 2 facades because of semantics | 06:42 |
| jam | it actually concretely splits things up for each worker | 06:42 |
| wallyworld | not due to which models are connected to | 06:42 |
| wallyworld | it is a ball of mud when the apis have no semantic grouping | 06:42 |
| jam | wallyworld: the semantic grouping is the functionality of the worker they are providing | 06:43 |
| wallyworld | i guess we differ on what the layering strategy is | 06:43 |
| wallyworld | that's where i diagree | 06:43 |
| jam | wallyworld: so, by all means we can discuss it at Tech Board level, but I *do* think its how we've done the code to date | 06:44 |
| wallyworld | not me :-) | 06:44 |
| wallyworld | i guess we've all gone down different roads | 06:44 |
| wallyworld | with no common direction | 06:44 |
| jam | so other than RemoteRelations, what other workers? | 06:45 |
| wallyworld | i'd have to check, maybe i'm over estiating | 06:45 |
| wallyworld | but I don't want to add these network apis to the firewaller facade | 06:45 |
| wallyworld | they are for network related semantics | 06:45 |
| jam | wallyworld: they don't belong there if they are talking about the remote side | 06:46 |
| wallyworld | not opening api ports etc | 06:46 |
| jam | because you *shouldn't* have access to all the other things firewaller needs from the remote side | 06:46 |
| wallyworld | they don;t belong there if the semantics differnot due to the model they talk to | 06:46 |
| wallyworld | those re orthogonsl concerns | 06:46 |
| jam | wallyworld: IMO, there should be the group of things that you talk about to your local model, and a group of things that you talk about to the remote model | 06:46 |
| jam | clustered by the worker that needs them | 06:46 |
| jam | and shared via a "common" directory that can be embedded | 06:46 |
| wallyworld | the remote relations facade is named after the domain object it operates on, not the type of model | 06:47 |
| wallyworld | just a btw | 06:47 |
| jam | wallyworld: we *definitely* moved away from having a Machine facade and a Unit facade and everything exposed by domain object | 06:48 |
| wallyworld | not necessarily by domain object - IMo groupings are by semantics | 06:49 |
| wallyworld | which sometimes but not always correlate somewhat with domain object | 06:49 |
| wallyworld | deployer worker uses 2 facades | 06:51 |
| wallyworld | as does machiner | 06:53 |
| wallyworld | and upgradesteps | 06:54 |
| wallyworld | jam: so i don't get blocked with arguing about names, if I used the name "remotenetworks" for now, I could land and also fix later if needed? | 06:56 |
| wallyworld | i have work queued up behind this PR | 06:57 |
| === frankban|afk is now known as frankban | ||
| anastasiamac | axw: wallyworld: nice and easy one plz :D https://github.com/juju/juju/pull/7025 | 08:22 |
| axw | anastasiamac: looking | 08:23 |
| axw | wallyworld: I'm getting a lot of noise in my logs from the firewaller saying that RemoteRelations is not implemented | 08:51 |
| axw | wallyworld: the worker is bouncing because I don't have the feature flag set | 08:51 |
| perrito666 | morning all | 10:01 |
| wallyworld | axw: damn, ok will fix in current pr as a driveby before landing | 11:39 |
| jam | morning perrito666 | 12:19 |
| jam | (bit delayed :) | 12:20 |
| === mup_ is now known as mup | ||
| === mup_ is now known as mup | ||
| === mup_ is now known as mup | ||
| === mup_ is now known as mup | ||
| === mup_ is now known as mup | ||
| === mup_ is now known as mup | ||
| redir | morning juju-dev | 16:25 |
| redir | morning perrito666 | 16:25 |
| perrito666 | redir: morning | 16:26 |
| === mup_ is now known as mup | ||
| joedborg | hello all. does anyone know if there's a juju command to monitor which set_states are being called in real time? | 16:39 |
| === mup_ is now known as mup | ||
| jam | anyone feel comfortable reviewing a patch against gomaasapi? | 16:46 |
| jam | https://github.com/juju/gomaasapi/pull/63 | 16:46 |
| === mup_ is now known as mup | ||
| === mup_ is now known as mup | ||
| === mup_ is now known as mup | ||
| === mup_ is now known as mup | ||
| === mup_ is now known as mup | ||
| redir | jam looking | 17:36 |
| === frankban is now known as frankban|afk | ||
| mup | Bug #1667419 opened: Juju 1.25.10 non-HA cpu/ram usage spike (can't apply changes to env) <canonical-bootstack> <juju-core:New> <https://launchpad.net/bugs/1667419> | 18:17 |
| redir | jam done | 18:39 |
| redir | perrito666: does this https://pastebin.canonical.com/169528/ look falmilar? Did you do something with that? | 18:39 |
| perrito666 | looking | 18:40 |
| perrito666 | I did not do anything about it, it is not a bug except for the bad error message | 18:41 |
| perrito666 | the error message shouhld say that the user used to be there but is no more | 18:41 |
| redir | perrito666: the error on line 7? | 18:42 |
| redir | and 43? | 18:42 |
| redir | or one of the other error messages? | 18:42 |
| perrito666 | both | 18:42 |
| redir | permission denied? | 18:43 |
| perrito666 | also that should perhaps not be permission denied but user deleted | 18:43 |
| redir | OK | 18:43 |
| redir | perrito666: or diabled if that is the case, yes? | 18:43 |
| redir | s/disabled | 18:43 |
| perrito666 | no, its not disabled | 18:49 |
| perrito666 | because you cant re-enable it | 18:49 |
| redir | hmm | 18:50 |
| perrito666 | redir: note that there is a disable command too | 18:52 |
| jam | perrito666: btw, redir has been active working with KVM and might be another person who could investigate https://bugs.launchpad.net/juju/+bug/1666198 | 19:20 |
| mup | Bug #1666198: Juju doesn't disable dhclient in KVMs <juju:Triaged> <https://launchpad.net/bugs/1666198> | 19:20 |
| jam | or at least give some advice | 19:20 |
| jam | redir: for context, when we deploy a KVM container, we allocate a static address from maas, and get it configured for the interface in the container | 19:21 |
| jam | but it appears that we still have dhclient running | 19:21 |
| jam | meaning it only keeps its static address until the lease times out | 19:21 |
| rick_h | jam: we had that issue with lxd in the path as well I thought | 19:22 |
| jam | rick_h: we inject /e/n/i before lxd containers are up via the "push file" api | 19:22 |
| jam | (assuming you mean past rather than path) | 19:23 |
| rick_h | jam: ah, I might be thinking of https://bugs.launchpad.net/juju-core/+bug/1579148 | 19:24 |
| jam | rick_h: so they come up first time with the right settings (AFAIK), certainly ante concretely didn't have problems with lxd containers, and did with kvm | 19:24 |
| mup | Bug #1579148: dhclient needs reconfiguring after bridge set up <network> <juju:Fix Released by dooferlad> <juju-core:Fix Released by dooferlad> <juju-core 1.25:Fix Released by dooferlad> <https://launchpad.net/bugs/1579148> | 19:24 |
| redir | jam: tx for the details. | 20:32 |
| redir | perrito666: yeah I'm aware of disable-user | 20:34 |
| redir | perrito666 jam I never had to go too deep into the network bits, but I think that happens at container/kvm/kvm.go:CreateContainer where we call containerinit.WriteUserData | 20:48 |
| redir | which eventually calls cloudconfig/containerinit/container_userdata.go containerinit.newCloudInitConfigWithNetworks | 20:49 |
| thumper | morning | 20:51 |
| redir | morning thumper | 20:51 |
| redir | jam perrito666 http://paste.ubuntu.com/24055218/ | 21:03 |
| perrito666 | redir: I am sure that makes sense to you | 21:07 |
| * perrito666 reads backlog | 21:07 | |
| redir | perrito666: sorry that is the generated cloud-init for a kvm container | 21:08 |
| redir | which is created in the above noted locations | 21:08 |
| redir | hopefully that is helpful | 21:08 |
| redir | :) | 21:08 |
| perrito666 | redir: tx man | 21:08 |
| redir | np | 21:08 |
| rick_h | perrito666: or wallyworld up for a hand? | 21:50 |
| perrito666 | rick_h: trapped in a call vortex | 21:52 |
| rick_h | perrito666: understand | 21:52 |
| redir | whatsup rick_h ? | 22:06 |
| rick_h | redir: I'm trying to figure out some api-isms | 22:11 |
| rick_h | redir: I've gotten part way but not happy with what I've got | 22:11 |
| redir | rick_h: which api? | 22:12 |
| rick_h | redir: things around the ModelManager apis | 22:12 |
| rick_h | redir: especially around uuids vs model names and such | 22:12 |
| * redir puts on his rubber duck hat | 22:13 | |
| rick_h | hah | 22:13 |
| redir | and | 22:13 |
| rick_h | I want to deal with model names but can't figure out how to get a uuid from that w/o making an api call that needs a model tag which is a uuid-based tag | 22:13 |
| redir | so you have a model name and you want to get a uuid for it | 22:15 |
| redir | ? | 22:15 |
| rick_h | redir: yes | 22:15 |
| redir | is this from the gui or in core? | 22:15 |
| rick_h | redir: this is in python against the core ai | 22:16 |
| rick_h | api | 22:16 |
| rick_h | redir: e.g. atm I'm calling ModelList, looping through the results, and loading the uuid when the name matches something I found | 22:16 |
| wallyworld | rick_h: hey, sorry, was making coffee | 22:17 |
| rick_h | wallyworld: all good, very important coffee | 22:17 |
| rick_h | wallyworld: want to have our chat today? | 22:17 |
| wallyworld | sure | 22:17 |
| wallyworld | now? | 22:17 |
| rick_h | sure | 22:18 |
| * redir wanders off | 22:20 | |
| babbageclunk | thumper, wallyworld: could you guys look at https://github.com/juju/description/pull/1 ? | 22:48 |
| wallyworld | babbageclunk: in release call, will look soon | 22:48 |
| babbageclunk | wallyworld: Oh, I guess you're both in there. Ok, thanks | 22:48 |
| wallyworld | babbageclunk: thumper isn't here :-) | 22:49 |
| babbageclunk | wallyworld: yay thanks, I'll chase thumper more assiduously | 22:50 |
| babbageclunk | hmm, not quite the right word but fun to say | 22:51 |
| * thumper ran to physio | 23:40 | |
| perrito666 | ok, I completely forgot where upgrade steps live, someone? | 23:44 |
| axw | perrito666: "upgrades" | 23:56 |
| axw | github.com/juju/juju/upgrades | 23:56 |
| perrito666 | found it | 23:56 |
| perrito666 | its nice and clean, only 3 versions | 23:56 |
| perrito666 | meh, we are still calling the state functions, how sad | 23:57 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!