Package com.tccc.kos.core.primary.service.nodemgr

Class NodeMgrService

java.lang.Object
com.tccc.kos.commons.util.ready.ReadyBean
com.tccc.kos.commons.core.service.AbstractService
com.tccc.kos.core.primary.service.nodemgr.NodeMgrService
All Implemented Interfaces:
CtxEventListener, ContextHandleAware, HandleAware, Ready, ReadyListener
public final class NodeMgrService extends AbstractService
Service for interacting with nodeMgr clients within the cluster. NodeMgr clients only connect to the primary node so this service only exists on the primary node.
Version:
2022-11-02

  • Method Details

    • reboot

      public void reboot()
      Reboot all the nodes and then the primary node.

    • setTime

      public void setTime(int hour, int min, int sec)
      Set the time on all nodes.

    • setDate

      public void setDate(int month, int day, int year)
      Set the date on all nodes.

    • setTimeZone

      public void setTimeZone(String timezone)
      Set the timezone on all nodes. This only sets the timezone in linux, not the jvm.

    • pauseTimeSync

      public void pauseTimeSync()
      Pause external time synchronization. This only lasts until resumed or the device is rebooted. This allows the time/date to be changed without time sync changing it back immediately.

    • resumeTimeSync

      public void resumeTimeSync()
      Resume external time synchronization.

    • getInstallBuilder

      public DeviceInstallBuilder getInstallBuilder()
      Return an instance of InstallBuilder which can be used to build an update that can be installed onto the device. While this can be used directly, it is recommended to use ManifestServer which also tracks the target manifestId and has listener support to trigger agent action.

    • deviceInstall

      public FutureWork deviceInstall(DeviceInstallBuilder installBuilder, boolean activate)
      Install the specified builder onto the device. There are two methods of installation depending on the data in the builder:
      • Feature install: This is a typical install. The manifests in the builder will be further examined and validated based on the details of the particular manifest versions the installation is a made up of. This means a builder that has no errors before this call may still fail with validation errors. As each manifest version may introduce additional features and validations, the results of this type of install are a combination of the currently running software and the data provided in the manifest chain that makes up the release.
      • Generic install: This is the install process used in the event that the currently running software does not understand the format of the manifest that make up the release. The manifest infrastructure provides a baseline that allows the install process to identify all the kabs required for a full install regardless of details of how the chained manifests work. Since this release does not understand the details, all the kabs will be installed and during the next boot cycle, the newer software will perform these validations as part of the standard boot process and if errors are found, a rollback will be triggered. This feature is intended to allow any older version of kOS to install a newer version without being blocked by forward incompatibility.

      The install process can be followed by an activation step or not based on the activate flag. If not activated, the software will be installed but will not be runnable even if rebooted. This allows a release to be pre-installed and then activated at a given time of day or by some other user defined process which calls activate() with the manifestId of the installed chain. A typical usb install would set the activate flag to true to ensure the system switches to the new release on the next boot cycle, where as OTA may set the flag false to avoid accidentally switching to new software until a known quiet time of day.

      Installation always occurs on the primary node. When the primary is rebooted, secondary nodes will try to reconnect and update from the primary automatically.

      The install process performs garbage collection of previous releases in order to free up space for the new release.

      Parameters:
      installBuilder - the builder that defines what to install
      activate - if true, make software active on next reboot

    • activateManifest

      public void activateManifest(String manifestId) throws IOException
      Activate a given manifestId on the primary node. If still installed on the node, this will make the manifest active, causing the next reboot to run this software release. If the manifest is no longer available, this does nothing.
      Throws:
      IOException

    • deactivateManifest

      public void deactivateManifest(String manifestId) throws IOException
      Deactivate a given manifestId on the primary node. If this is the currently active manifest then the node will effectively roll back to the previous active manifest on the next reboot. The deactivated manifest is still available to be activated until garbage collected by a future install, but will never be run unless explicitly activated again.
      Throws:
      IOException

    • rollback

      public void rollback() throws IOException
      Rollback the currently running manifest. This will deactivate the manifest and reboot immediately.
      Throws:
      IOException

    • rollback

      public void rollback(String manifestId) throws IOException
      Rollback the specified manifestId. This will deactivate the specified manifestId which will make it unusable. If this is the currently running manifest then the device will also reboot into the next available manifest.
      Parameters:
      manifestId - the manifestId to disable
      Throws:
      IOException

    • bounce

      public void bounce() throws IOException
      Bounce the primary node. This may reboot the device or may just restart user space depending on the state of nodeMgr.
      Throws:
      IOException

    • addBlockedManifestId

      public void addBlockedManifestId(String manifestId, String source)
      Add a manifestId to the blocked list on the primary node. This will trigger a BlockedManifestsListener event if the manifest isn't already in the list.
      Parameters:
      manifestId - the manifestId to add to the blocked list
      source - where the manifestId is coming from for logging

    • removeBlockedManifestId

      public void removeBlockedManifestId(String manifestId)
      Remove a manifestId from the blocked list on the primary node. This will trigger a BlockedManifestsListeter event if the manifest is in the list.
      Parameters:
      manifestId - the manifestId to remove from the blocked list