Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 6 Next »

Problem Statment

Currently, on EVE software module, ZedAgent is responsible for top level orchestration, basos upgrade validation, cloud connectivity for configuration/status.

In the whole EVE node boot up process, ZedAgent and associated modules are spawned, only after network connectivity(through nim, waitfor address) and device registration (zedclient).

For  baseos upgrade validation, this leaves a gap between node boot up and real baseos upgrade transition process invocation in zedagent. Any failure inbetween, the device boot up until zedagent starts, may lead to device being struck in some indefinite state and may turn the device to a non-functional unit. 


Proposal

The zedagent module will be broken-up. The base of validation and over all connectivity and device health will be managed by DevAgent. The DevAgent will be one of the first modules to be spawned along with ledmanager, and will be persistent for the whole lifetime of the EVE node. The ZedAgent will be only responsible for cloud connectivity and configuration parsing and status/metrics publication. The baseos upgrade validation will be covered by DevAgent module, covering all the intermediary state for the device boot up. 

EVE Node Health Monitor Function

EVE Node health check functionality, consists of the following, 

 Watchdog Time : For Pillar Agent(s) Health and responsiveness.

 Each agent's health is monitored through hardware watchdog. If an agent does not retouch the pid file, for a specified interval, the device is rebooted.

Reset Time: Cloud connectivity health in normal operation

On controller connectivity loss, the EVE node is rebooted after the reset time interval.

 Fallback Time: Controller Connectivity health during baseos upgrade validation phase

For controller connectivity loss, EVE Node falls back to fallback image, after the fallback time interval.

Current Implementation

The watchdog time handler functionality is based on hardware watchdog(wdctl), and it is part of device-steps.sh.

The reset and fallback time functionalities are currently part of ZedAgent Module.  

Proposal for Refactoring

The watchdog time functionality will remain as such. The reset and fallback time functionality will be moved into a new agent called, devagent. The whole baseos upgrade validation functionality will be moved into devagent module. Devagent will be spwaned along with ledmanager. Devagent will listen to ledmanager ledblinker config messages to determine controller connectivity status along with successful configuration pull message time stamps, to orchestrate the baseof upgrade validation functionality. Devagent will be owner for Zboot config and will publish them for usage by baseosmanager. Also on successful baseos installation and reset/fallback timer expiry, the device reboot operations will be triggered through "devagent status"  pusub topic.

Zedagent module will only be responsible for controller connectivity related functionalities, like pulling latest configuration blob from controller, and publishing status/info/metrics  tmessages to controller. And will update this information through "zedagent status" pubsub topic. Zedagent will subscribe to "devagent status" pubsub topic to execute device reboot command.

Baseosmanger will listen to devagent module, zboot config messages to handle, and update zboot status, during baseos validation orchestration.

In a nutshell, this is going to be overall,change in event handling per module.

Baseosmgr Module

 Will subscribe to the following 

      - zbootconfig topic from devagent

ZedAgent Module

 Zedagent wiill subscribe to the following topics,

     - devagent status topic from devagent

            - for executing device reboot command 

            - to publish the remaining test time, for baseos upgrade validation

  will publish the following

      - zedagent status

            - time stamp for last successful configuration pull

DevAgent Module

DevAgent  module will  subscribe to the following topics,

   - ledBlinker Config, generated by zedclient/zedagent, 

          - for EVE node registration, controller connectivity change events

   - Zboot Status, generated by baseosmgr

           - for baseos installation and upgrade validation orchestration

   - Zedagent Status

            - to know, the last successful config fetch from controller, for baseos upgrade validation and testing orchestration

DevAgent will publish to the following topics,

    - Zboot Config

              - zboot partition information

    - DevAgent Status

              - for reboot commands, in baseos installation or, reset/fallback timer expiry.

               - remaining test time, for publishing  to controller (by zedagent)


PS

For completeness and future workscope, the following items are noted, for EVE node health. This list is not exhaustive, and the nessary actions for them needs be defined. 

            - cpu usage health

            - disk space usage health

            - network usage health

            - each agent's basic functionality check


  • No labels