We need to use hookenv.atstart() to get flags set before the main reactive loop kicks off. However, I see no reason the refresh has to run every update-status hook; it is setting the snap.refresh-available.* flags, but they can just as easily be several hours out of date as they can be 5 minutes out of date. I suspect these flags are just a bad idea and not being used.
We do want to do an unconditional refresh in the upgrade-charm hook, in case channels etc. defined in layer.yaml have changed.
I'm thinking the way forward is a layer.yaml option, enable_refresh_flags, defaulting to False, which simply causes check_refresh_available to do nothing. While backwards incompatible, it is a simple enough tweak by the charm author to turn back on if they are actually using the feature.
We need to use hookenv.atstart() to get flags set before the main reactive loop kicks off. However, I see no reason the refresh has to run every update-status hook; it is setting the snap.refresh- available. * flags, but they can just as easily be several hours out of date as they can be 5 minutes out of date. I suspect these flags are just a bad idea and not being used.
We do want to do an unconditional refresh in the upgrade-charm hook, in case channels etc. defined in layer.yaml have changed.
I'm thinking the way forward is a layer.yaml option, enable_ refresh_ flags, defaulting to False, which simply causes check_refresh_ available to do nothing. While backwards incompatible, it is a simple enough tweak by the charm author to turn back on if they are actually using the feature.