Difference between revisions of "StarlingX/Containers/Applications"
< StarlingX | Containers
(→Page Archive) |
(→Developer Resources) |
||
Line 61: | Line 61: | ||
== Developer Resources == | == Developer Resources == | ||
* [[StarlingX/Containers/Applications/HowToAddNewFluxCDAppInSTX | Create a new application]] | * [[StarlingX/Containers/Applications/HowToAddNewFluxCDAppInSTX | Create a new application]] | ||
+ | * [[StarlingX/Containers/Applications/AppIntegration | Application Integration with the Platform]] | ||
== Page Archive == | == Page Archive == |
Revision as of 14:40, 10 January 2024
Contents
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 Starling 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.
- STX.APP.11 - StarlingX applications should maintain a StarlingX Wiki page documenting source code location, build instructions, basic functionality, limitations, and testing instructions.
- 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
Active Applications
These applications are currently under development and actively maintained
- app-dell-storage
- app-gen-tool
- 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-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
- platform-armada-app
- portieris-armada-app
- ptp-notification-armada-app
- rook-ceph
- 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