| elox | morning | 08:57 |
|---|---|---|
| achilleasa | manadart: still reviewing your PR. In the meantime can you double-check something for me? | 10:14 |
| manadart | achilleasa: Yep; what is it? | 10:14 |
| achilleasa | I believe that the state code does not currently handle endpoint additions/deletions when upgrading charms. For example, the `AllEndpointBindings` model method pulls the data from mongo. But if the new charm adds/removes bindings we will get back an incorrect list | 10:22 |
| nammn_de | manadart and stickupkid: mind if you could take a look again? I added some things and left some comments there https://github.com/juju/juju/pull/10652 | 10:24 |
| manadart | Righto. nammn_de's is approved. Looking at your thing now achilleasa. | 10:49 |
| achilleasa | manadart: out of curiosity, why are the slices in constraints/Value pointers? | 10:57 |
| manadart | achilleasa: So the difference between not set and set to nothing can be told. | 10:59 |
| achilleasa | manadart: I get why we want this for scalars but does it make a difference for slices (empty vs not set)? | 11:00 |
| manadart | achilleasa: It matters for Tags, but it doesn't look like it for the others. | 11:07 |
| stickupkid | migration has soo many tests :| | 11:10 |
| rick_h | stickupkid: what's the comment in your github actions PR referring to? Anything I can help out with? | 12:22 |
| rick_h | manadart: hah, I started reading that spaces bug last night but after a while had to mark it something to come back to | 12:23 |
| manadart | rick_h: There is another one along similar lines in my stack. I'm looking at that code right now. | 12:26 |
| stickupkid | rick_h, was trying one way then another, there are two ways to do github actions (nice!), but I think I've got the container started, just need to get the right location | 12:46 |
| rick_h | stickupkid: ah cool | 12:47 |
| stickupkid | rick_h, also i'm going to relax what is required for running the static analysis as we don't actually need a juju | 12:47 |
| rick_h | "need a juju"? as in building Juju? | 12:48 |
| stickupkid | rick_h, i was messing around whilst waiting for a meeting | 12:48 |
| rick_h | vs just static hitting the code? | 12:48 |
| stickupkid | rick_h, yeah, exactly | 12:48 |
| rick_h | gotcha, yea makes sense | 12:48 |
| nammn_de | manadart: could i have a quick look again? I added your points. But Azure has additional constraints, which are alias constraints, Therefore the unit tests failed (good catchup!). Added a comment for you and 2 ways to solve it. https://github.com/juju/juju/pull/10652 | 13:10 |
| stickupkid | nice got it working - finally | 13:42 |
| manadart | nammn_de: Commented. Keep the old way for Azure. I think you can go ahead and merge it. | 13:50 |
| stickupkid | manadart, what's provider id in terms of a subnet? is this maas only stuff? | 14:37 |
| manadart | stickupkid: No, other providers use it - AWS, OCI, Openstack. It's literally what's on the tin - the provider's identifier for that subnet. | 14:39 |
| stickupkid | right, ok cool | 14:39 |
| manadart | It will now be used to uniquely identify subnets (CIDR and provider ID) being the candidate key. So we can have the same CIDR from different networks. | 14:40 |
| manadart | CIDR plus provider ID will ensure uniqueness across all providers. For example on manual, provider ID will always be "", so CIDRs will have to be unique there. | 14:40 |
| stickupkid | ah, that's interesting for manual | 14:41 |
| manadart | nammn_de be landin' | 14:44 |
| nammn_de | manadart: thx for the review. juhu first pr merged 💥 | 14:46 |
| rick_h | nammn_de: woooo! congrats! | 14:48 |
| rick_h | nammn_de: what's awesome is that then you can see it in action in the edge snap that builds every 4ish hours | 14:48 |
| rick_h | nammn_de: please make sure to mark the bug fix-comitted and that the milestone is set to the 2.7 one if it was landed in develop | 14:49 |
| nammn_de | rick_h: will do :D! | 14:51 |
| stickupkid | nammn_de: congrats | 14:51 |
| nammn_de | rick_h and achilleasa: just saw this one https://bugs.launchpad.net/juju/+bug/1812980 as fix commited. In Trello it is assigned to me. Is it done? | 14:53 |
| mup | Bug #1812980: try again should not be logged as an ERROR <bitesize> <juju:Fix Committed by achilleasa> <https://launchpad.net/bugs/1812980> | 14:54 |
| rick_h | nammn_de: hmm, I guess just double check. I must have missed the fix-comitted | 14:55 |
| rick_h | and we never got it released as it wasn't set to a milestone | 14:55 |
| rick_h | nammn_de: so I guess just confirm and if it's setup the right way per the bug just mark it fix released at this point | 14:55 |
| rick_h | looks like it was done back in Jan so must be released by now :) | 14:55 |
| achilleasa | I think this was one of the first things I worked on after joining :D | 14:56 |
| rick_h | achilleasa: yea, I bet it was just a missed target to a milestone | 14:56 |
| nammn_de | achilleasa: haha okay, I will put me of the trello then | 14:56 |
| nammn_de | do we link the commited fix with a pr, to make things easier to trace? | 14:57 |
| rick_h | nammn_de: we can for sure | 14:58 |
| rick_h | nammn_de: and always note the bug in the commit in GH (the PR) | 14:58 |
| rick_h | nammn_de: so that when we go to do the changelog for a release it's easy to see if the PR that's landed ties to a bug worth highlighting | 14:59 |
| achilleasa | nammn_de: my approach is to add a comment to the bug like "PR $link_to_pr includes the fix for $branch" | 14:59 |
| aisrael | Is there a way to tell the Juju API server to advertise a different endpoint? i.e., I have a lxd controller with 17070 port forwarded from the host's address, and using the manual machine provider to it. I want to add that externally routable IP address to the api endpionts advertised by the controller. | 15:07 |
| rick_h | aisrael: setup a haproxy in front of it? | 15:07 |
| rick_h | aisrael: not really, it'll bind to all addresses on it's host but it's not proxy-nat aware | 15:08 |
| aisrael | rick_h: I've intercepted the provisioning script used through libjuju to inject the routable IP to the new machine, but when it first contacts the controller it updates the api address to the non-routable one. I think I need to make the controller itself aware of that address. | 15:09 |
| rick_h | aisrael: the main issue is that there's a generate cert that the client->controller use and that'll be locked to the ips I think? | 15:09 |
| rick_h | aisrael: hmmm, I mean on the client you can edit the list of controller addresses | 15:12 |
| manadart | achilleasa, maybe stickupkid: For bundles, if a "to" directive is supplied, is that exactly the same a "juju deploy x --to y" or is there some bundle based delay between machine and unit creation? | 15:12 |
| rick_h | aisrael: but not sure how that'll fallout to working/not | 15:12 |
| manadart | Oh, and I specifically mean "to" a container. | 15:12 |
| rick_h | manadart: so the issue with bundles is that the machines come up first and are referenced to the machines in the bundle | 15:12 |
| rick_h | manadart: right, so lxd:0 or the like? | 15:13 |
| manadart | rick_h: Yep. | 15:13 |
| rick_h | manadart: there is a delay in that the bundle path does an addCharm I think and then "addUnit" vs hitting the main deploy API call which handles that | 15:13 |
| manadart | rick_h: Just looking at this bug. There *should* be a determination of desired spaces based on units assigned to the container, but it's falling through. | 15:14 |
| manadart | Just wondering if the provisioner is racing with the bundle. | 15:15 |
| rick_h | manadart: hmmm, yea not sure tbh | 15:15 |
| rick_h | manadart: the bundles getting broken down into smaller bits might be a different path but have to chase it through | 15:15 |
| aisrael | rick_h: Okay. I'll dig in a little deeper | 15:19 |
| === dannf` is now known as dannf | ||
| stickupkid | damn, we use a different version of yaml library in description and in juju - ah fun fun fun | 16:31 |
| rick_h | stickupkid: :/ | 16:34 |
| achilleasa | stickupkid: also, check charms.v6 | 16:34 |
| stickupkid | the yaml output is different depending on the version | 16:34 |
| stickupkid | grrr | 16:34 |
| stickupkid | I'll fix it for description | 16:35 |
| stickupkid | i have no recollection of doing this https://github.com/juju/yaml/commit/2025133c382644467541934971b571f7896de32a | 16:41 |
| rick_h | stickupkid: lol the git commit doesn't lie | 16:42 |
| stickupkid | i mean i could have been drinking tbh | 16:43 |
| rick_h | lol, I don't know I should be hearing this :P | 16:43 |
| stickupkid | haha | 16:43 |
| nammn_de | would love to get some input. Working on a better error message for the cli on some occasions. https://bugs.launchpad.net/juju/+bug/1843456 | 17:08 |
| mup | Bug #1843456: [2.6.8] model-config prints a cryptic error message if a file was not found <bitesize> <cdo-qa> <juju:Triaged by nammn> <https://launchpad.net/bugs/1843456> | 17:08 |
| rick_h | nammn_de: what's up? | 17:08 |
| * rick_h sees a comment and reads up | 17:08 | |
| nammn_de | rick_h: was just looking into the issue and wasnt sure which way to solve would be preferred | 17:09 |
| nammn_de | so just added a comment with possible solutions in my mind. But maybe someone has something better in mind | 17:10 |
| rick_h | nammn_de: so a couple of things. First, I think that if the key isn't found as a model-config key we can provide a better error message. "ERROR key "bundles/k8s-model-config.yaml" not found in model's config" | 17:13 |
| rick_h | nammn_de: and second, if the thing is file-like (e.g. ends in yaml...I wonder if there's a pattern we've got for that already) we can check the file is resolveable/exists and error cleanly in that case "File "bunxles/k8s-model-config.yaml" is not found" | 17:14 |
| nammn_de | rick_h: so the code does the following right now. If the file cannot be resolved we take it as a key and parse it like that. Before I can implement a proper file-like parser I need to know if a key can actually look like a path? Can a Key e.g contain an ending? key.yaml? | 17:16 |
| rick_h | nammn_de: right, so my question is can we reverse that. e.g. "does this match one of the model-config keys?" | 17:17 |
| rick_h | nammn_de: and if not, "does it look like a file?" and finally "if it looks like a file can I see it" | 17:17 |
| nammn_de | rick_h: let me look, makes totally sense! | 17:18 |
| rick_h | nammn_de: k, updated the bug with my notes in line with that | 17:19 |
| nammn_de | rick_h: great, thansk! | 17:20 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!