Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Note: Even in case of No-Op for upgrade_retry, the device sends an Info message to the controller to update its baseos_upgrade_retry_counter.

EVE Support

  1. Eve Needs to store the status of each partition ( Success / Failure ) - This is done currently
  2. If the currently configured image is in FAILED state in the other partition, retry the image upgrade. ( Intended Use Case )
  3. ELSE Do nothing. Just update the baseos_upgrade_retry counter in the Info message and send an Info message to the Controller.

Note: Currently - Eve automatically retries Download / verify / install errors

Control Flow:

Image Added

Some Scenarios for Implementation

  1. Configured EVE image in Error State, Fall Back image Currently Active.

This is the regular scenario for the feature:

  1. Device Currently running 6.1.0 ( Partition IMGA ) ( baseos_upgrade_retry_counter = 1 )
  2. Controller configured 6.4.0 as the active image. ( baseos_upgrade_retry_counter = 1 )
  3. Eve receives new config, downloads and verifies the Image, and starts upgrading to 6.4.0 ( IMGB)
  4. Even boots up 6.4.0 and enters the Testing Phase.
  5. Testing for 6.4.0 Fails and Eve Falls back to running 6.1.0
  6. User triggers retry ( baseos_upgrade_retry_counter = 2 )
  7. As indicated in Control Flow section, this triggers booting into 6.4.0 again

 2. BaseOs Using Volumes

BaseOs config still only has only Active image name. It might download multiple volumes ( images ), but there can only be ONE ACTIVE EVE IMAGE VOLUME.

BaseOs Using Volumes with Current Partition Scheme:

Currently, Eve has the concept of partitions. Currently, it supports two partitions:

  1. Currently running Image Partition ( Lets say - PART-USED )
  2. Previous Image booted Partition ( PART-UNUSED )

Any new image installed in PART-UNUSED. It will also carry if that image was successful or errored. This is all is needed to support this feature.

In the case where Controller supports multiple volumes, and hence multiple partitions, each partition needs to maintain the state of the last Image result - SUCCESS / ERROR / UNKNOWN

This is used to answer the question "is_image_in_error_state()"