| hpidcock | wallyworld: noticed that cancel-action didn't become cancel-operation with the v3 rename of actions. I'll add it to the spec for operation interruption | 03:03 |
|---|---|---|
| wallyworld | hpidcock: yeah, that got missed :-( | 03:06 |
| kelvinliu_ | wallyworld: free to HO for 1min? | 03:31 |
| wallyworld | kelvinliu_: sure, give me 5 | 03:32 |
| kelvinliu_ | ok | 03:33 |
| wallyworld | kelvinliu_: or hpidcock: this PR adds a pod-spec-get command. can't land till after 2.7.0 ships so no rush https://github.com/juju/juju/pull/10953 | 04:10 |
| kelvinliu_ | wallyworld: looking now | 04:10 |
| hpidcock | sorry xwayland locked up had to reboot | 04:13 |
| wallyworld | yay wayland | 04:20 |
| hpidcock | wallyworld: when you talk about task vs operation, operation could be against multiple units? and task is against the individual unit? | 04:35 |
| wallyworld | hpidcock: yeah, operation is a top level grouping of tasks. juju call creates an operation. the actual code that runs on any given uinit is a task. there's still discussion to be had as to whether we allow a task to create a "sub" task | 04:40 |
| hpidcock | task-inception | 04:42 |
| hpidcock | wallyworld: it doesn't seem the concept of grouped "tasks" as an "operation" has been done yet. Is that planned for this cycle? | 05:15 |
| wallyworld | hpidcock: that's what the new spec is for :-) | 05:15 |
| wallyworld | in the 20.04 folder | 05:15 |
| hpidcock | ahah yep | 05:15 |
| hpidcock | wallyworld: I've updated the doc, should be simple enough to implement I think. | 07:06 |
| dosaboy | wallyworld: babbageclunk that was the problem :) | 08:56 |
| dosaboy | thank you | 08:56 |
| achilleasa | manadart: is this what you had in mind about 10942? https://github.com/juju/juju/pull/10942/commits/43d47dcd6178841e3b060200e0be84f534b1d9ec | 09:10 |
| manadart | achilleasa: Yes, that will do it. | 09:12 |
| nammn_de1 | manadart: here I only added the export steps https://github.com/juju/juju/pull/10943 so qa only has test for regression. Would you suggest adding the import steps to another PR or just in this PR as well? | 09:41 |
| wallyworld | achilleasa: hey, quick question. UniterAPIV12 comment says the LXDProfileAPI hs been removed but it's still embedded in the API struct. It's been taken out in V13. I have a PR where I am doing a V14 and as a driveby can remove from V12 if that's correct to do. or else I will move the incorrect comment. do you know what's correct? | 09:46 |
| wallyworld | PR is https://github.com/juju/juju/pull/10953 | 09:47 |
| achilleasa | wallyworld: sorry; no clue about it. however, it seems to be missing from the V12 struct: https://github.com/juju/juju/blob/b67e487e19f1835a66c7cd415c70730548c3aa57/apiserver/facades/agent/uniter/uniter.go#L88 | 09:51 |
| wallyworld | achilleasa: it is there in 2.7 so I think we can assume devel was updated but not 2.7 maybe | 09:52 |
| wallyworld | it seems like it's safe to remove | 09:52 |
| wallyworld | i didn't check develop as i've got 2.7 checkout out urrently | 09:52 |
| achilleasa | wallyworld: I think so too. Looks like it has been replaced by a different set of methods anyway | 09:53 |
| wallyworld | yeah, it has, the imlementation was reworked and the old one removed | 09:53 |
| wallyworld | thanks for the input. i just wanted to double check removing from V12 was correct, seems like it is | 09:54 |
| stickupkid | manadart, https://github.com/juju/cmd/pull/68 | 10:10 |
| manadart | stickupkid: Done. | 10:16 |
| stickupkid | manadart, let's see if this lands as you don't have a green tick :| | 10:17 |
| manadart | stickupkid: Busted down. | 10:17 |
| achilleasa | jam: I have pushed a bunch of commits to 10902 to address your comments. Can you take a look if I missed anything so I can land the PR? | 10:26 |
| stickupkid | manadart, I've brought the changes in now - https://github.com/juju/juju/pull/10955 | 10:27 |
| nammn_de1 | stickupkid: moment, when did we start having a master ? :D | 10:36 |
| nammn_de1 | oh damn i missread, nvm me | 10:50 |
| stickupkid | manadart, when processing relations (updating external controllers) and it fails after this, we'll leave the CMR in a broken state | 11:28 |
| stickupkid | manadart, trying to think how/if we can do something different, I know they're supposed to be idempotent, I'm unsure how this can be | 11:29 |
| manadart | stickupkid: Yes, jam and I spoke about this. We will have to ensure the pre-checks are tight. Then for connectivity issues *to* the external controllers during the change, we can re-try. | 11:30 |
| stickupkid | :( | 11:30 |
| manadart | stickupkid: Or roll them back, or something. We just can't break it. | 11:31 |
| stickupkid | manadart, let me see if rollback is possible | 11:31 |
| manadart | stickupkid: I haven't looked into it yet, but is it possible to be passive with regard to the consumers, let them get a re-direct from the source controller and update themselves? | 11:33 |
| stickupkid | manadart, we do have ABORT and REAPFAILED | 11:33 |
| stickupkid | manadart, thinking | 11:33 |
| jam | achilleasa: reviewd | 11:34 |
| achilleasa | jam: thanks for the review. I will apply your suggestions and push | 11:36 |
| stickupkid | manadart, i'm unsure you know, we're going to have to keep the old firewall rules around for the redirect, this doesn't seem very clever | 11:39 |
| stickupkid | manadart, if you migrate a lot of things around, you'll just have a sieve | 11:39 |
| achilleasa | manadart: any suggestions for modifying params/network.go:Network config to align with my recent changes? Presumably, the machiner worker might be running an older jujud binary prior to updating the model | 14:37 |
| achilleasa | I could add additional fields (Addresses, ShadowAddresses) and retain "Address" for backwards compatibility | 14:37 |
| nammn_de1 | manadart stickupkid: I think this is ready for a review https://github.com/juju/juju/pull/10943 QA steps are added. It migrated the rules in the Database, are there additional steps which I have missed? | 15:21 |
| nammn_de1 | QA steps describe my mind flow | 15:21 |
| stickupkid | nammn_de1, looks great | 15:26 |
| nammn_de1 | Because I thought that the responsible worker picks up the database changes (addition) somewhere and thus apply those firewall changes. Therefore no need for me to additionally check that. But maybe need to doublecheck that | 15:28 |
| stickupkid | nammn_de1, you tested on aws? | 15:29 |
| nammn_de1 | stickupkid: only lxd | 15:29 |
| nammn_de1 | stickupkid: i can spin up the same qa steps from the description in aws | 15:29 |
| nammn_de1 | to be safe | 15:29 |
| stickupkid | nammn_de1, yes please | 15:29 |
| nammn_de1 | any other qa steps needed beside the `juju list-firewall-rules` being the same on the src and dst? | 15:30 |
| stickupkid | nammn_de1, we should verify that the firewall rules are actually applied | 15:30 |
| nammn_de1 | stickupkid: makes sense | 15:30 |
| stickupkid | nammn_de1, with aws, you can check the console | 15:30 |
| nammn_de1 | stickupkid: ohhh great to know | 15:30 |
| nammn_de1 | just for understanding. Most of our juju magic works through a worker which checks the database and does something upon it, right? | 15:31 |
| nammn_de1 | like i add a firewall rule to the db and a worker picks that up and create that rule on the specific provider | 15:31 |
| stickupkid | yeah, that's the theory | 15:32 |
| nammn_de1 | stickupkid: haha okay | 15:33 |
| manadart | achilleasa: I think that will work. We just use omitempty and add a comment about retention for compatibility + removing Address in Juju 3.0. | 15:33 |
| danboid | I can't destroy a model, even when using --force | 15:42 |
| danboid | I was trying to deploy the openstack bundle, so I'm good to nuke and pave | 15:43 |
| danboid | How do you do that though? Is it enough to release all the MAAS machines and delete ~/.local/juju or is there anything else? Maybe its better to purge juju from my machine too? | 15:44 |
| danboid | I couldn't deploy the charm because the model is 'destroying' | 15:46 |
| danboid | Is it safe/correct to remove ~/.local/juju if you want to start over? | 15:48 |
| danboid | I think I fixed it | 16:07 |
| rick_h | danboid: no, just juju unregister | 16:14 |
| rick_h | danboid: and then release the MAAS machines | 16:15 |
| rick_h | danboid: let me know if you hit it and want to pull info to see if there's a bug/etc | 16:15 |
| rick_h | danboid: what juju version? | 16:15 |
| achilleasa | manadart: should we assign shadow addresses to the alpha space? | 16:21 |
| achilleasa | Since they don't really belong to a space, can we use alpha as a fallback? | 16:21 |
| manadart | achilleasa: Hmm. jam and I spoke about the notion of external spaces. | 16:22 |
| manadart | I think yes. | 16:22 |
| manadart | But they will not have a subnet to link them via that mechanism. | 16:23 |
| manadart | I think this should be OK. Let me think about it. | 16:23 |
| danboid | rick_h, The OS bundle is deploying now. We'll see how it went in the morning. I'm sure I'll be recommending a few tweaks to the docs at the end - I've already got a couple of things I think should be added | 16:27 |
| rick_h | danboid: cool | 16:27 |
| nammn_de1 | achilleasa manadart did you guys ever interact with the firewallrules of juju in aws? `juju set-firewall-rule`? | 17:10 |
| achilleasa | nammn_de1: not me; sorry | 17:11 |
| stickupkid | nammn_de1, you should see a security group inside the ec2 instance, check that has the right input/output ports | 17:13 |
| nammn_de1 | stickupkid: firewall rules does not set ports afact | 17:14 |
| nammn_de1 | so i cannot seem to find any mapping between those | 17:15 |
| nammn_de1 | on the first glance adding a firewall rule and having none shows the same sg | 17:15 |
| stickupkid | nammn_de1, https://github.com/juju/juju/blob/dca1ee163dd2f6abdc989d3580d9a56e3ec22864/provider/ec2/environ.go#L1555 | 17:16 |
| stickupkid | nammn_de1, https://github.com/juju/juju/blob/dca1ee163dd2f6abdc989d3580d9a56e3ec22864/provider/ec2/environ.go#L1626 | 17:16 |
| nammn_de1 | stickupkid: hmm | 17:23 |
| nammn_de1 | cannot find any connection to the firewallrule from state | 17:26 |
| stickupkid | nammn_de1, check the workers | 17:29 |
| nammn_de1 | this should be the responsible worker https://github.com/juju/juju/blob/52602ea0fb7b79f9fa55040dc4a817d80a4422e4/worker/firewaller/firewaller.go#L221 | 17:29 |
| stickupkid | nammn_de1, ho? | 17:29 |
| nammn_de1 | stickupkid: sure | 17:30 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!