feat: emit UpgradeGrantedEvent if unit is flagged as ready
Removed state=waiting from the design, as I forgot that Leader units can't set other Units' peer data. Instead all units set state=ready on upgrade-charm event
feat: set available states to DataUpgrade class attr
Ordered by severity and expected execution order
cluster_state grabs the lowest ordinal state from all unit states, i.e:
if ANY unit is failed, cluster_state will be failed
if ANY unit is idle, cluster_state will be `idle
and so on...
This helps with getting an overall picture of how far the cluster has progressed during an upgrade, or if it has failed
feat: add substrate attr to DataUpgrade
Takes arguments k8s or vm
If k8s, default upgrade_stack to all application unit.ids, ordered in increasing order. This is needed as proposed upgrade process for K8s charms will not include custom ordering of units in the StatefulSet
As such, build_upgrade_state now not an @abstractmethod, raises NotImplementedError if vm
feat: lazy-load upgrade-stack attr
When first called, will load from relation data and persist to object attr
When popped from during handling of upgrade-relation-changed to get the next unit+state to upgrade, after re-setting it back to DataUpgrade, the lib persists the popped list to relation data
In case the leader is the next unit after popping, the lib recurses on_upgrade_changed after doing this to ensure it gets the next event (as relation-changed events don't re-emit to the unit that changed it)
feat: convenience methods for setting failed and completed unit upgrade state
Charm-authors should not be able to modify unit upgrade states that are used for coordinating events (idle, ready, upgrading)
They can use the above methods during handling of pre_upgrade_check and UpgradeGranted event handlers to inform other units of their final states, triggering upgrade-relation-changed events on all other units to wake them up
If any unit state is set to failed, all units will get upgrade-relation-changed, and set their own state to failed
If a unit sets it's state to completed, all units will get upgrade-relation-changed, and the leader will pop the completed unit from the stack
feat: add can_upgrade method to DependencyModel
Compares two dependency models for base upgradability by comparing old version to new upgrade_supported
Called implicitly on the application leader during upgrade-charm event handling through the _upgrade_supported_check method, which loops over all specified dependencies (e.g snap, service, deb...) and validates
feat: Add VersionError and DependencyError exceptions
VersionError raised if can_upgrade fails for 'internal' versions (Snap --> Snap, Service --> Service etc)
DependencyError can be raised by charm-authors during handling of upgrade-granted event if related applications do not meet requirements
docs: various docstring tweaks to fit reStructuredText patterns
Added detailed usage instructions for UpgradeGrantedEvent for charm-authors to include in their handler implementations
TODO
Changes Made
feat: emit UpgradeGrantedEvent if unit is flagged as readystate=waitingfrom the design, as I forgot that Leader units can't set other Units' peer data. Instead all units setstate=readyonupgrade-charmeventfeat: set available states to DataUpgrade class attrcluster_stategrabs the lowest ordinal state from all unit states, i.e:failed,cluster_statewill befailedidle,cluster_statewill be `idlefeat: add substrate attr to DataUpgradek8sorvmk8s, defaultupgrade_stackto all application unit.ids, ordered in increasing order. This is needed as proposed upgrade process for K8s charms will not include custom ordering of units in the StatefulSetbuild_upgrade_statenow not an@abstractmethod, raisesNotImplementedErrorifvmfeat: lazy-load upgrade-stack attrupgrade-relation-changedto get the next unit+state to upgrade, after re-setting it back toDataUpgrade, the lib persists the popped list to relation dataon_upgrade_changedafter doing this to ensure it gets the next event (asrelation-changedevents don't re-emit to the unit that changed it)feat: convenience methods for setting failed and completed unit upgrade stateidle,ready,upgrading)pre_upgrade_checkandUpgradeGrantedevent handlers to inform other units of their final states, triggeringupgrade-relation-changedevents on all other units to wake them upfailed, all units will getupgrade-relation-changed, and set their own state tofailedcompleted, all units will getupgrade-relation-changed, and the leader will pop the completed unit from the stackfeat: add can_upgrade method to DependencyModelversionto newupgrade_supportedupgrade-charmevent handling through the_upgrade_supported_checkmethod, which loops over all specified dependencies (e.gsnap,service,deb...) and validatesfeat: Add VersionError and DependencyError exceptionsVersionErrorraised ifcan_upgradefails for 'internal' versions (Snap --> Snap, Service --> Service etc)DependencyErrorcan be raised by charm-authors during handling ofupgrade-grantedevent if related applications do not meet requirementsdocs: various docstring tweaks to fit reStructuredText patternsUpgradeGrantedEventfor charm-authors to include in their handler implementations