[01:44] <wallyworld> axw: when you get back online, if you have a chance pretty please https://github.com/juju/juju/pull/7021
[01:47] <axw> wallyworld: swap you? :) https://github.com/juju/juju/pull/7015
[01:47] <wallyworld> sure
[01:50] <axw> wallyworld: not a very fair trade, except that you've reviewed most of that PR before
[01:51] <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:52] <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:54] <redir> at least it is sturdy if not reusable:)
[02:07] <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:19] <thumper> anyone https://github.com/juju/juju/pull/7022
[03:05] <babbageclunk> wallyworld - did offer-name just go away on remote applications?
[03:08] <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:24] <wallyworld> babbageclunk: nothing has changed in the last day or so
[03:26] <wallyworld> babbageclunk: the state object still has it - but it may not always get set
[03:26] <wallyworld> yet
[03:29] <babbageclunk> wallyworld: but there's no offer-name field in the remoteApplicationDoc?
[03:30] <wallyworld> babbageclunk: line 34 of remoteapplication.go
[03:30] <wallyworld> in state
[03:31] <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:32] <babbageclunk> wallyworld: gah, that'll be it. Sorry, was losing it there.
[03:32] <wallyworld> no wuckers
[03:35] <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:36] <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:38] <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:39] <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:40] <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:41] <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:42] <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:44] <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:45] <wallyworld> i agree we can tend to lump stuff together
[03:46] <wallyworld> i'll get confirmation on the name
[03:46] <wallyworld> assume "networks" for now
[04:35] <anastasiamac> axw: wallyworld: 1 line trivial :D https://github.com/juju/juju/pull/7023
[04:36] <axw> anastasiamac: LGTM
[04:38] <anastasiamac> axw: \o/
[04:43] <wallyworld> axw: i'm relocating before next meeting, have pushed changes to that PR whenever you have a chance
[04:44] <axw> wallyworld: thanks, looking
[04:44] <wallyworld> ta
[04:44] <wallyworld> bbiab
[05:58] <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?
[06:35] <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:36] <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:38] <wallyworld> we dure do have many other generic facade names too :-)
[06:39] <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:40] <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:41] <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:42] <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:43] <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:44] <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:45] <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:46] <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:47] <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:48] <jam> wallyworld: we *definitely* moved away from having a Machine facade and a Unit facade and everything exposed by domain object
[06:49] <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:51] <wallyworld> deployer worker uses 2 facades
[06:53] <wallyworld> as does machiner
[06:54] <wallyworld> and upgradesteps
[06:56] <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:57] <wallyworld> i have work queued up behind this PR
[08:22] <anastasiamac> axw: wallyworld: nice and easy one plz :D https://github.com/juju/juju/pull/7025
[08:23] <axw> anastasiamac: looking
[08:51] <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
[10:01] <perrito666> morning all
[11:39] <wallyworld> axw: damn, ok will fix in current pr as a driveby before landing
[12:19] <jam> morning perrito666
[12:20] <jam> (bit delayed :)
[16:25] <redir> morning juju-dev
[16:25] <redir> morning perrito666
[16:26] <perrito666> redir: morning
[16:39] <joedborg> hello all.  does anyone know if there's a juju command to monitor which set_states are being called in real time?
[16:46] <jam> anyone feel comfortable reviewing a patch against gomaasapi?
[16:46] <jam> https://github.com/juju/gomaasapi/pull/63
[17:36] <redir> jam looking
[18:17] <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:39] <redir> jam done
[18:39] <redir> perrito666: does this https://pastebin.canonical.com/169528/ look falmilar? Did you do something with that?
[18:40] <perrito666> looking
[18:41] <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:42] <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:43] <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:49] <perrito666> no, its not disabled
[18:49] <perrito666> because you cant re-enable it
[18:50] <redir> hmm
[18:52] <perrito666> redir: note that there is a disable command too
[19:20] <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:21] <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:22] <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:23] <jam> (assuming you mean past rather than path)
[19:24] <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>
[20:32] <redir> jam: tx for the details.
[20:34] <redir> perrito666: yeah I'm aware of disable-user
[20:48] <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:49] <redir> which eventually calls cloudconfig/containerinit/container_userdata.go containerinit.newCloudInitConfigWithNetworks
[20:51] <thumper> morning
[20:51] <redir> morning thumper
[21:03] <redir> jam perrito666 http://paste.ubuntu.com/24055218/
[21:07] <perrito666> redir: I am sure that makes sense to you
[21:07]  * perrito666 reads backlog
[21:08] <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:50] <rick_h> perrito666: or wallyworld up for a hand?
[21:52] <perrito666> rick_h: trapped in a call vortex
[21:52] <rick_h> perrito666: understand
[22:06] <redir> whatsup rick_h ?
[22:11] <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:12] <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:13]  * 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:15] <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:16] <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:17] <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:18] <rick_h> sure
[22:20]  * redir wanders off
[22:48] <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:49] <wallyworld> babbageclunk: thumper isn't here :-)
[22:50] <babbageclunk> wallyworld: yay thanks, I'll chase thumper more assiduously
[22:51] <babbageclunk> hmm, not quite the right word but fun to say
[23:40]  * thumper ran to physio
[23:44] <perrito666> ok, I completely forgot where upgrade steps live, someone?
[23:56] <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:57] <perrito666> meh, we are still calling the state functions, how sad