[09:55] manadart: I was trying to use your newly added deltaops for controllersettings (juju-ha-space ..) and realized those are in their own collection. With this, I changed the `deltaops` function. Does that make sense? https://github.com/nammn/juju/blob/48c527fba46e0c5057e1feda909ba635c957449c/state/settings.go#L536 Or did I overlook something and the [09:55] `settings` collection is still the right collection for this? [10:06] nammn_de: Sorry, I meant to reply to your question. You want something more like this: https://pastebin.canonical.com/p/H5mmbX6WKM/ [10:06] manadart: ahhh makes sense. Thanksss [10:35] manadart, looking at the integration test - I thought we fixed the issue with missing relation scope? [10:35] manadart, https://paste.ubuntu.com/p/BbZfwgqtdT/ [10:36] also "yeah boi" - I'm laughing so hard - haha === skay is now known as Guest49404 [11:04] stickupkid: Sorry, was just OTP. Is that with develop? [11:04] manadart, well your branch [11:08] stickupkid: You updated the dep and installed it? [11:08] make install'ed it [11:11] So was that migrating the offering model, or the consuming one? [11:14] offering [11:17] can ho once you're free manadart [11:34] stickupkid: Daily [11:35] manadart: To change the spaces for constraints I see the following options: get constraints for each type (applications, machine, units..) and change these OR just get all constraints as collection and edit these. What do you think makes the most sense? Im thinking about the latter because of implementation ease [11:43] manadart: hmm but if I think about it, this could potentially be a lot of docs constraints to at least check and then change.. [11:45] ahhh no it might make the most sense to just query for the space and then to change that subset =D [11:46] nammn_de: Yes. [11:53] manadart: populating modelUUID/DocID did the trick! [11:53] achilleasa: Nice. [12:12] manadart: another thing. I realized because I query the constraints collection itself and need to write them back again I need the "_id". As I don't know whether the doc is a machine, application ect. [12:12] I see the following options: [12:12] 1: add _id to constraintsDoc <-- I would prefer this [12:12] 2: use own constraintsDoc struct . What do you think? Or another suggestion in mind? [12:21] nammn_de: Just add `DocID string `bson:"_id"` like we do elsewhere. [12:21] manadart: great, will do [13:02] anyone up for a CR for https://github.com/juju/juju/pull/11156 ? [13:06] achilleasa: I can look. [15:10] manadart, if you have a relation to another CMR model, if you try and destroy the controller, it fails, is this something you ran into? [15:14] stickupkid: Yes, this is known and will not be changed (there is an LP bug). That is why the migration integration tests force-destroy the offer before teardown. [15:14] manadart, this is annoying as we can't tear down a controller if an integration test fails [15:15] manadart, i.e. the integration test doesn't know about the relation [15:15] stickupkid: Ah, yes. [15:15] manadart, this is why the integration jujus are hanging around, even if you told them to be destroyed [15:15] stickupkid: I wonder if the bash-based suites would allow us to register extra tear-down... [15:16] manadart, i'm unsure [15:16] manadart, defer but in shell [15:16] haha [15:17] stickupkid: Exactly :) [15:25] all i want is closures [15:25] manadart, i wonder if we can ask for all relations? [15:26] manadart, and just kill them all off [15:27] stickupkid: Could work I guess. [15:38] manadart, got it to work with the check, but need to work on the destroying issue [15:38] i'll update your pr [15:52] https://github.com/juju/juju/pull/11155 [17:03] manadart, got it working, not the defer thing, but cleaning up the offers [17:03] get in there [17:11] CR https://github.com/juju/juju/pull/11157