Skip to main content
Version: Next

Update items dependencies

Creating Aos update entities

Definitions

Aos contains 3 main update entities:

EntityDescription
aosServiceOCI complaint Service created by Service Provider
aosComponentAos update component that can be installed on a Unit
aosLayerAos layer for aosService entities

Update item development lifecycle

DeveloperaosNamedObjectAosCloudDeveloperDeveloperaosNamedObjectaosNamedObjectAosCloudAosCloudCreate update item =create new object project and metafileset "codename" for the entityopt[optional metadata]set "description" and other for the entityopt[Verify on cloud]execute verify requestalt[verify success]"codename" is available"codename" is usedexecute create requestalt[verify failed]"urn" for entities is assigned"codename" is usedCreate update item version =opt[priority need to be changed]update priorityupdate version in metadataupdate codebuild entityexecute create new version requestalt[upload success]okerror infointernal repack, sign and encrypt entity

Main changes:

  • All entities (services, layers, components) get the same identification schema. identification includes codename, id (uuid), URN, etc. Described in ontology.
  • All entities get priority property (component didn't have previously). Question: But layers have priority in service metadata. Cloud should ignore this property in layers? Proposal: priority for layers have to be checked by AosCore (install/delete layers from cache according to their priority)
  • All entities get runtime dependencies. TODO: it's necessary to specify valid dependencies (e.g. layers can depend on other layers only). Proposal: do not check, allow all from all
  • All entities get architecture property. Question: can component have different architecture. Proposal: yes, to have same behavior as layers and services

Unit ontology representation

Unit ontology

Main changes in the Unit object

  • Remove NodeType as a standalone entity. It's necessary to have grouping possibility for the similar nodes in units. Introduce Subject to replace it. Also, to this group subject will be attached aosComponents.
  • Devices, Resources and Runners are reported by AosUnit as a part of NodeInfo in the UnitStatus message. This allows having different items for any Units (e.g. this list can be changed during update)
  • TargetSystem (former UnitModel) contains limits and settings only. E.g.: ResourceRatio, AlertRules per NodeType Subject
  • AosServices, AosLayers, AosComponents will get priority to be able to suppress low priority update items (e.g. to replace default component/service with new one)
  • AosServices and AosComponent have "suppressItems" property (to notify AosCloud that only one of service/component can be installed)

UnitStatus message sequence

AosUnitAosNodeAosCloudAosUnitAosUnitAosNodeAosNodeAosCloudAosCloudneed to send UnitStatus (startup or status changed)loop[over all nodes]request infogeneral info (NodeGroupSubject codename, etc)list of unit identified Subjectslist of Services, Layers, Componentslist of Runnerslist of Deviceslist of Resourceloop[over all update items with non-nodeTypeSubject]marshal Components+Subjectmarshal Service+Subjectloop[over all update items with nodeTypeSubject]marshal Components+NodeTypeGroupSubjectmarshal Service+NodeTypeGroupSubjectmarshal other infosend UnitStatus message

DesiredStatus message sequence

AosCloudAosUnitAosCloudAosCloudAosUnitAosUnitneed to send DesiredStatus (startup or status changed)collect all Subjects (group, attached, reported) and sort them by priorityloop[over all subjects]get all Components for subject in "ready to deploy state" and sort them by priorityget all Services for subject in "ready to deploy state" and sort them by priorityexclude all services and components by suppressItems propertyrun ConflictDetector procedure over all servicescollect all dependent layerscollect all other nessesary info (envars, etc)marshal DesiredStatus messagesend DesiredStatus message