I tend to agree; if the snap refresh code determines that the snap needs to be refreshed (changed version), then stop the service and then refresh the snap. This will result in a sealed unit, but is more correct behaviour than the charm going into an error state.
Other options such as blocking just means that the operator will need to take another action just as pausing the charm, which would then allow the unit to snap refresh, which would then restart the service and seal the unit, making it a two step process.
Therefore, we have two options in the snap refresh code:
1. detect if the process is running, stop it, and then allow the refresh to continue.
2. detect if the process is running, don't stop it, and go into a blocked state showing that the process is running and that the snap would be refreshed due to configuration differences. Then, when the unit is paused, the refresh and seal would then happen.
2. may be preferable, but is more complicated to communication and understand, I think.
I tend to agree; if the snap refresh code determines that the snap needs to be refreshed (changed version), then stop the service and then refresh the snap. This will result in a sealed unit, but is more correct behaviour than the charm going into an error state.
Other options such as blocking just means that the operator will need to take another action just as pausing the charm, which would then allow the unit to snap refresh, which would then restart the service and seal the unit, making it a two step process.
Therefore, we have two options in the snap refresh code:
1. detect if the process is running, stop it, and then allow the refresh to continue.
2. detect if the process is running, don't stop it, and go into a blocked state showing that the process is running and that the snap would be refreshed due to configuration differences. Then, when the unit is paused, the refresh and seal would then happen.
2. may be preferable, but is more complicated to communication and understand, I think.