StarlingX/Containers/Applications

Containerized Applications

This page serves a launch pad for all StarlingX Containerized application bundles

Requirements

• STX.APP.01 - StarlingX shall provide application compatibility for all k8s releases supported in the planned StarlingX Release
  • Currently supported versions can be seen here: https://opendev.org/starlingx/integ/src/branch/master/kubernetes
• STX.APP.02 - StarlingX shall use the latest helm chart(s) and container image release(s) in an effort to stay current from a feature perspective and to include the latest CVE fixes available upstream.
• STX.APP.03 - StarlingX applications shall support all application framework lifecycle operations exercised with the system application-xxx API/CLI.
• STX.APP.04 - StarlingX applications shall support all application framework lifecycle operations exercised with the system system helm-override-xxx API/CLI.
• STX.APP.05 - StarlingX applications shall support all application framework lifecycle operations exercised with the system helm-chart-attribute-modify API/CLI.
• STX.APP.06 - StarlingX applications shall be updatable without operator intervention from one application version to another.
• STX.APP.07 - StarlingX applications shall support automatic updates when a new version is delivered to the platform via a platform patch.
  • This is controlled via the application metatdata packaged with each version of the application
• STX.APP.08 - StarlingX applications shall support orchestrated updates over a platform release if a new version of the application is provided in the new release.
  • Currently this is automated via a platform upgrade-activation script (corresponding repo)
• STX.APP.09 - StarlingX applications shall support orchestrated updates over a k8s upgrade if a new version of the application is available on the platform and when a specific version k8s is enabled.
  • This is controlled via the application metatdata packaged with each version of the application
• STX.APP.10 - StarlingX applications should be documented in the StarlingX Documentation explaining the basic purpose, functionality, limitations, and tested use cases for each version of the application available.
  • Based on the current limited documentation, application documentation should be added here (code repo)
• STX.APP.11 - StarlingX applications should maintain a StarlingX Wiki page documenting source code location, build instructions, basic functionality, limitations, and testing instructions. The content of the Wiki page should track to the latest content delivered to the master branch.
• STX.APP.12 - StarlingX applications should strive to use unmodified upstream helm charts and integrate into StarlingX with only static/dynamic helm overrides.
• STX.APP.13 - StarlingX applications that need helm chart modifications to properly integrate into StarlingX should upstream those helm chart modifications so that in the future these customizations can be dropped from the product.
• STX.APP.14 - StarlingX applications should be tested in simplex and multi-node environments to ensure the pods/replicas are deployed as desired
• STX.APP.15 - StarlingX applications should be tested in multi-personality environments to ensure the pods/replicas are deployed as as desired on k8s master+worker(AIO) and master(STD controller) + worker(worker) nodes
• STX.APP.16 - StarlingX applications should be tested over all MTC operations ensure the pods/replicas are operational/scaled/recovered as as desired on all nodes. MTC operations include: install/reinstall/lock/unlock/swact/power-off/reboot
• STX.APP.17 - To support proper CPU affining StarlingX application pods/namespaces should be labeled with app.starlingx.io/component=platform or app.starlingx.io/component=application
• STX.APP.18 - StarlingX applications should be compliant with our use of the Pod Security Admission Controller
• STX.APP.19 - StarlingX follows the Four Opens and must provide software this is appropriately licensed. Applications that rely on and integrate upstream technologies (helm charts/images), must have a compatible license for inclusion in StarlingX. This implies that as applications are maintained and updated, licenses must be re-checked for compliance.
  • Known list of issues that have impacted applications
    • Redis Adopts Dual Source-Available Licensing | Redis

Active Applications

These applications are currently under development and actively maintained

• app-dell-storage
• app-harbor
• app-intel-device-plugins
• app-intel-ethernet-operator
• app-istio
• app-kubernetes-power-manager
• app-kubevirt
• app-node-feature-discovery
• app-node-interface-metrics-exporter
• app-oran-o2
• app-power-metrics
• app-rook-ceph
• app-security-profiles-operator
• app-sriov-fec-operator
• app-sts-silicom
• audit-armada-app
• cert-manager-armada-app
• metrics-server-armada-app
• nginx-ingress-controller-armada-app
• oidc-auth-armada-app
• openstack-armada-app
• platform-armada-app
• portieris-armada-app
• ptp-notification-armada-app
• rook-ceph (migration)
• snmp-armada-app
• vault-armada-app

Inactive Applications

These applications are currently NOT maintained and their functionality/usability is unknown

• monitor-armada-app
• SDO-rv-service

Developer Resources

• Create a new application
• Application Integration with the Platform

Page Archive

• How To Add an Armada App
• Armada App Code Structure
• Armada to FluxCD Conversion