[01:44] axw: when you get back online, if you have a chance pretty please https://github.com/juju/juju/pull/7021 [01:47] wallyworld: swap you? :) https://github.com/juju/juju/pull/7015 [01:47] sure [01:50] wallyworld: not a very fair trade, except that you've reviewed most of that PR before [01:51] might be long enough ago that you've forgotten it though [01:51] wallyworld: it can wait a bit if you're busy [01:51] axw: tis ok, yours is +500/-200, mine is +700/-70, about the same really :-) [01:52] wallyworld: yeah, yours is a lot of boilerplate though :) [01:52] it is, i wish we didn't need so much of that [01:54] at least it is sturdy if not reusable:) [02:07] axw: yeah, i started to remember the code once i read the PR. LGTM, I'm just ducking out to get lunch [02:07] wallyworld: thanks [02:19] anyone https://github.com/juju/juju/pull/7022 [03:05] wallyworld - did offer-name just go away on remote applications? [03:08] 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:24] babbageclunk: nothing has changed in the last day or so [03:26] babbageclunk: the state object still has it - but it may not always get set [03:26] yet [03:29] wallyworld: but there's no offer-name field in the remoteApplicationDoc? [03:30] babbageclunk: line 34 of remoteapplication.go [03:30] in state [03:31] wallyworld: should I be working against 2.1 or develop? [03:31] develop! [03:31] 2.1 is for hosted juju beta and container networking only [03:32] wallyworld: gah, that'll be it. Sorry, was losing it there. [03:32] no wuckers [03:35] hey veebers raised bug 1667172 for adoptresources on GCE - I'll jump on that once I finish this, ok? [03:35] Bug #1667172: Migrated model fails to be removed from list-models in GCE

[03:36] sure ty [03:36] axw: i'm hopeless at names, but i sort of did have the same hesitation. Perhaps "networkmanager" or "networks" [03:38] wallyworld: remotenetworks? it's meant for access by a remote model only right? [03:38] yeah [03:38] but it could point to a local model also [03:38] wallyworld: local as in local to the controller? [03:39] yeah, it could (nothing stops it). but the intended usage is to go to a remote model [03:39] wallyworld: I don't think we need to make a distinction there, as long as they can auth [03:39] right, hence just "networks" rather than remotenetworeks [03:40] "remoterelations" is so called because the objects are remote relations [03:40] wallyworld: I meant remote as in cross-model, rather than cross-controller [03:40] i think we're in violent agreement? [03:41] "networks" reflects the semantics of the facade, not where it might point to [03:41] wallyworld: I just want the name to convey the limited scope [03:41] wallyworld: I guess networs is OK. maybe get jam's opinion later [03:41] networks* [03:42] 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:44] 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] 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:45] i agree we can tend to lump stuff together [03:46] i'll get confirmation on the name [03:46] assume "networks" for now [04:35] axw: wallyworld: 1 line trivial :D https://github.com/juju/juju/pull/7023 [04:36] anastasiamac: LGTM [04:38] axw: \o/ [04:43] axw: i'm relocating before next meeting, have pushed changes to that PR whenever you have a chance [04:44] wallyworld: thanks, looking [04:44] ta [04:44] bbiab [05:58] 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? [06:35] 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] jam: but that's not the semantics offered by the facade [06:35] 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:36] WatchSubnets() just watches subnets on a model [06:36] any model [06:36] the model it watches is defined by the connection it is given [06:36] just like any other facadde [06:38] we dure do have many other generic facade names too :-) [06:39] "charms", "machine", "spaces" [06:39] wallyworld: but the *intent* is to offer a restricted subset [06:39] else we end up with lots of things piled into the facade [06:39] because the local stuff wants it [06:39] but we shouldn't let remote stuff see it [06:39] that's what an authorizer is for [06:39] wallyworld: generally we try to group things on a Facade that act similarly [06:39] sure [06:40] wallyworld: we have followed the pattern to date that a worker matches a facade [06:40] many workers use > 1 facade [06:40] wallyworld: I'd worry about "these 2 methods are useful for this kind of thing, but these 4 are for other things" [06:40] if we expect worker to facade to be 1:1 that is plain wrong IMO [06:40] different layers [06:41] wallyworld: what workers concretely use >1 facade, we generally have merged 'common' functionality to provide facade groupings [06:41] that's why lots of facades embed some sort of "common.Lifer" etc [06:41] remote relations worker is one [06:42] enforcing worker to facade to be 1:1 romotes big ball of mud [06:42] wallyworld: so "remote" concretely *has* to use 2 facades because you're talking about 2 models [06:42] facades should be cohesive. not kitchen sink [06:42] wallyworld: "this is the collection of APIs that are useful for X" is not a ball of mud [06:42] no, it uses 2 facades because of semantics [06:42] it actually concretely splits things up for each worker [06:42] not due to which models are connected to [06:42] it is a ball of mud when the apis have no semantic grouping [06:43] wallyworld: the semantic grouping is the functionality of the worker they are providing [06:43] i guess we differ on what the layering strategy is [06:43] that's where i diagree [06:44] 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] not me :-) [06:44] i guess we've all gone down different roads [06:44] with no common direction [06:45] so other than RemoteRelations, what other workers? [06:45] i'd have to check, maybe i'm over estiating [06:45] but I don't want to add these network apis to the firewaller facade [06:45] they are for network related semantics [06:46] wallyworld: they don't belong there if they are talking about the remote side [06:46] not opening api ports etc [06:46] because you *shouldn't* have access to all the other things firewaller needs from the remote side [06:46] they don;t belong there if the semantics differnot due to the model they talk to [06:46] those re orthogonsl concerns [06:46] 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] clustered by the worker that needs them [06:46] and shared via a "common" directory that can be embedded [06:47] the remote relations facade is named after the domain object it operates on, not the type of model [06:47] just a btw [06:48] wallyworld: we *definitely* moved away from having a Machine facade and a Unit facade and everything exposed by domain object [06:49] not necessarily by domain object - IMo groupings are by semantics [06:49] which sometimes but not always correlate somewhat with domain object [06:51] deployer worker uses 2 facades [06:53] as does machiner [06:54] and upgradesteps [06:56] 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:57] i have work queued up behind this PR === frankban|afk is now known as frankban [08:22] axw: wallyworld: nice and easy one plz :D https://github.com/juju/juju/pull/7025 [08:23] anastasiamac: looking [08:51] wallyworld: I'm getting a lot of noise in my logs from the firewaller saying that RemoteRelations is not implemented [08:51] wallyworld: the worker is bouncing because I don't have the feature flag set [10:01] morning all [11:39] axw: damn, ok will fix in current pr as a driveby before landing [12:19] morning perrito666 [12:20] (bit delayed :) === 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 [16:25] morning juju-dev [16:25] morning perrito666 [16:26] redir: morning === mup_ is now known as mup [16:39] hello all. does anyone know if there's a juju command to monitor which set_states are being called in real time? === mup_ is now known as mup [16:46] anyone feel comfortable reviewing a patch against gomaasapi? [16:46] https://github.com/juju/gomaasapi/pull/63 === 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 [17:36] jam looking === frankban is now known as frankban|afk [18:17] Bug #1667419 opened: Juju 1.25.10 non-HA cpu/ram usage spike (can't apply changes to env)

[18:39] jam done [18:39] perrito666: does this https://pastebin.canonical.com/169528/ look falmilar? Did you do something with that? [18:40] looking [18:41] I did not do anything about it, it is not a bug except for the bad error message [18:41] the error message shouhld say that the user used to be there but is no more [18:42] perrito666: the error on line 7? [18:42] and 43? [18:42] or one of the other error messages? [18:42] both [18:43] permission denied? [18:43] also that should perhaps not be permission denied but user deleted [18:43] OK [18:43] perrito666: or diabled if that is the case, yes? [18:43] s/disabled [18:49] no, its not disabled [18:49] because you cant re-enable it [18:50] hmm [18:52] redir: note that there is a disable command too [19:20] 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] Bug #1666198: Juju doesn't disable dhclient in KVMs [19:20] or at least give some advice [19:21] 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] but it appears that we still have dhclient running [19:21] meaning it only keeps its static address until the lease times out [19:22] jam: we had that issue with lxd in the path as well I thought [19:22] rick_h: we inject /e/n/i before lxd containers are up via the "push file" api [19:23] (assuming you mean past rather than path) [19:24] jam: ah, I might be thinking of https://bugs.launchpad.net/juju-core/+bug/1579148 [19:24] 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] Bug #1579148: dhclient needs reconfiguring after bridge set up

[20:32] jam: tx for the details. [20:34] perrito666: yeah I'm aware of disable-user [20:48] 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:49] which eventually calls cloudconfig/containerinit/container_userdata.go containerinit.newCloudInitConfigWithNetworks [20:51] morning [20:51] morning thumper [21:03] jam perrito666 http://paste.ubuntu.com/24055218/ [21:07] redir: I am sure that makes sense to you [21:07] * perrito666 reads backlog [21:08] perrito666: sorry that is the generated cloud-init for a kvm container [21:08] which is created in the above noted locations [21:08] hopefully that is helpful [21:08] :) [21:08] redir: tx man [21:08] np [21:50] perrito666: or wallyworld up for a hand? [21:52] rick_h: trapped in a call vortex [21:52] perrito666: understand [22:06] whatsup rick_h ? [22:11] redir: I'm trying to figure out some api-isms [22:11] redir: I've gotten part way but not happy with what I've got [22:12] rick_h: which api? [22:12] redir: things around the ModelManager apis [22:12] redir: especially around uuids vs model names and such [22:13] * redir puts on his rubber duck hat [22:13] hah [22:13] and [22:13] 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:15] so you have a model name and you want to get a uuid for it [22:15] ? [22:15] redir: yes [22:15] is this from the gui or in core? [22:16] redir: this is in python against the core ai [22:16] api [22:16] redir: e.g. atm I'm calling ModelList, looping through the results, and loading the uuid when the name matches something I found [22:17] rick_h: hey, sorry, was making coffee [22:17] wallyworld: all good, very important coffee [22:17] wallyworld: want to have our chat today? [22:17] sure [22:17] now? [22:18] sure [22:20] * redir wanders off [22:48] thumper, wallyworld: could you guys look at https://github.com/juju/description/pull/1 ? [22:48] babbageclunk: in release call, will look soon [22:48] wallyworld: Oh, I guess you're both in there. Ok, thanks [22:49] babbageclunk: thumper isn't here :-) [22:50] wallyworld: yay thanks, I'll chase thumper more assiduously [22:51] hmm, not quite the right word but fun to say [23:40] * thumper ran to physio [23:44] ok, I completely forgot where upgrade steps live, someone? [23:56] perrito666: "upgrades" [23:56] github.com/juju/juju/upgrades [23:56] found it [23:56] its nice and clean, only 3 versions [23:57] meh, we are still calling the state functions, how sad