| wallyworld | thumper: everyone is busy fixing CI issues, or away on leave... i'd love to land this today https://github.com/juju/juju/pull/11058 | 00:09 |
|---|---|---|
| thumper | wallyworld: I'll look | 01:20 |
| thumper | wallyworld: I've got a question for ya | 01:41 |
| thumper | apiserver/facades/agent/uniter/uniter.go:1478 | 01:42 |
| thumper | if err is nil, we still log | 01:42 |
| thumper | we got a lot of those error logs during my scale testing | 01:42 |
| thumper | it seems that we should log if err != nil, but not if there is no error | 01:42 |
| thumper | does that sound right? | 01:43 |
| wallyworld | thumper: looking at code | 02:00 |
| hpidcock | wallyworld: looks like the jujud-versions.yaml works fine with build number https://www.irccloud.com/pastebin/aCgSCcrp/ | 02:05 |
| wallyworld | thumper: so in theory, we should always know the address of the machine the unit is running on, so we should always be able to set the address info. for k8s, that's not always the case. for iaas, we either use the public address for cmr or fall back to the private one if needed. so if we are logging that we need to understand why | 02:06 |
| thumper | wallyworld: I saw it a huge number of times in my scale testing | 02:07 |
| thumper | there was no error | 02:07 |
| wallyworld | which i think means we don't have a unit private address whic seems weird | 02:07 |
| wallyworld | we could drop to debug but we'd want to understand what's happening, hence it was done a sa warning | 02:08 |
| thumper | well, the message gives us no info | 02:09 |
| thumper | it just says : can't do it: <nil> | 02:09 |
| wallyworld | it can't - all it knows is that there's no unit address | 02:09 |
| thumper | so not really useful | 02:09 |
| wallyworld | it may be that the unit enters scope before the address is know | 02:10 |
| wallyworld | in which case the default relation data will be unpopulated | 02:10 |
| wallyworld | it may be that only old charms relay on that default data | 02:11 |
| wallyworld | as new charms should be using network-get | 02:11 |
| wallyworld | so dropping the severity may be ok | 02:11 |
| wallyworld | hpidcock: it looks like you created a build yaml by hand with the correct sha? | 02:12 |
| hpidcock | yeah, testing what the snap would do | 02:13 |
| wallyworld | look ok then | 02:14 |
| wallyworld | i think | 02:14 |
| hpidcock | yep, just testing without build number as well now | 02:14 |
| wallyworld | thumper: so charms should be resiliant to delayed address info - they need to handle it when the address info is not known up front, especially for k8s charms. it's just that historically they haven't catered for this and expected juju to always seed the relation data with private-address | 02:15 |
| wallyworld | so i think we can consider this as not something worth a warning | 02:15 |
| wallyworld | and if charms break that's on them to fix | 02:15 |
| thumper | hmm, ok | 02:15 |
| wallyworld | i mean, it is possible a relation can be formed and the address info is not yet known | 02:16 |
| wallyworld | there's not much we can do about that | 02:16 |
| wallyworld | especially for say k8s charms like gitlab | 02:16 |
| wallyworld | where the relation comes up and then that triggers the pod starting | 02:17 |
| wallyworld | and then we get the address | 02:17 |
| wallyworld | thumper: ta for review. were you going to drop the warning to a debug or something given for many k8s charms it will just be noise, and even for iaas charms, they could aguably not expect to rely on that info | 02:25 |
| thumper | wallyworld: I'm just prepping the PR | 02:26 |
| thumper | wallyworld: https://github.com/juju/juju/pull/11064 | 02:27 |
| wallyworld | looking | 02:27 |
| wallyworld | thumper: lgtm, we have found in a few places stuff hitting not found during teardown. whack-o-mole | 02:36 |
| thumper | wallyworld: yeah | 02:36 |
| thumper | wallyworld: I keep filing bugs thinking tlm could fix this... | 02:43 |
| wallyworld | perhaps he could, tag them as bitesize or something | 02:44 |
| tlm | I only want big ones :) | 03:43 |
| wallyworld | hpidcock: have you managed to check all the build num fix scenarios? | 04:17 |
| hpidcock | wallyworld: I've found a snag, the versioned tools dir | 04:18 |
| hpidcock | testing just having SharedToolsDir return the dir without buildnumber | 04:19 |
| wallyworld | ah yes | 04:19 |
| hpidcock | I'm not sure how the uploaded tools are unpacked. Does the bootstrapping client scp them over and untar it? | 04:21 |
| wallyworld | essentially yeah | 04:21 |
| hpidcock | including simplestreams? | 04:22 |
| hpidcock | or does simplestreams just get wget'd onto the machine? | 04:22 |
| wallyworld | see github.com/juju/juju/cloudconfig/userdatacfg_unix.go | 04:23 |
| wallyworld | line 346 | 04:23 |
| wallyworld | that's where the dir is first created | 04:23 |
| wallyworld | and just underneath is where the tools are downloaded | 04:24 |
| wallyworld | the url in the tools struct is i think streams.c.c | 04:24 |
| wallyworld | at bootstrap anyway | 04:25 |
| wallyworld | after that the controller caches them | 04:25 |
| stickupkid | manadart, https://github.com/juju/description/pull/70 | 12:29 |
| stickupkid | manadart, this should prevent the panic when migrating consumers | 12:29 |
| manadart | stickupkid: Looking. | 12:30 |
| stickupkid | ta | 12:33 |
| stickupkid | This is blocking me from testing the migration error, so hopefully I'll be able to see what's the cause soon | 12:33 |
| Laney | hey jujuers | 13:39 |
| rick_h | hey Laney | 13:40 |
| Laney | got a question for you! | 13:40 |
| Laney | Is there a way to check if an application has an upgrade available? I've got a `set -e` shell script which is running `juju upgrade-charm` over all of them, but it bails out if there is no update available because that causes an exit 1. | 13:40 |
| rick_h | Laney: juju status shows that there's an upgrade available | 13:41 |
| rick_h | Laney: the controller checks once a day | 13:42 |
| Laney | ah, can I make it check in that script then? | 13:42 |
| rick_h | yea, I'm just trying to dbl check where that shows up | 13:42 |
| Laney | it's usually that I release a new version of the charm and want to run this upgrade-all-the-things script to roll it out | 13:42 |
| Laney | once a day wouldn't be great given that :-) | 13:43 |
| Laney | or maybe there's a better way of doing all of this | 13:43 |
| rick_h | Laney: so juju status --format=yaml and can-upgrade-to: cs:haproxy-55 | 13:43 |
| rick_h | Laney: so I'd update your script to run that once a day, iterate the applications in the YAML, and check for the "can-upgrade-to" | 13:44 |
| Laney | alright, thanks! | 13:46 |
| rick_h | Laney: no problem, let me know how it goes maybe if you've got a cool script drop it in discourse for folks to see | 13:47 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!