61f29db061
In the unlikely event that the network agent rebalance/reschedule state machines are moving a resource from one agent to another, and something happens to the host agent, VIM, or neutron during this small window of time, it may be possible for a resource (dhcp network or router) to be left unattached to an agent. In order for these resources to be recovered and reattached to an agent, this update will turn the network_auto_schedule and router_auto_schedule neutron config parameters back on. These were originally turned off in order to prevent potential race conditions with the rebalance/reschedule algorithms, but after further review this was not considered to be an issue. They are therefore being turned back on. In addition, during host unlocks the VIM was being restarted causing the rebalance/reschedule state machines to lose configuration and potentially uncleanly aborted mid- operation. A change is made to only restart the VIM on initial application apply. Story: 652151 Task: 30561 Change-Id: I73a069e478200fa4ee9eb959eceecc2dc598eecc Signed-off-by: Kevin Smith <kevin.smith@windriver.com> |
||
|---|---|---|
| .. | ||
| applications/stx-openstack/stx-openstack-helm | ||
| helm-charts | ||
| README | ||
The expected layout for this subdirectory is as follows: kubernetes |-- applications | `-- <application> | `-- <application>-helm RPM | `-- centos | `-- build_srpm.data | `-- <application>-helm.spec | `-- <application>-helm | `-- manifests | `-- main-manifest.yaml | `-- alt-manifest-1.yaml | `-- ... | `-- alt-manifest-N.yaml | `-- custom chart 1 | `-- Chart.yaml | `-- ... | `-- ... | `-- custom chart N | `-- Chart.yaml | `-- ... |-- helm-charts | `-- chart | `-- chart `-- README The idea is that all our custom helm charts that are common across applications would go under "helm-charts". Each chart would get a subdirectory. Custom applications would generally consist of one or more armada manifest referencing multiple helm charts (both ours and upstream ones). The application is packaged as an RPM. These application RPM are used to produce the build artifacts (helm tarballs + armada manifests) but are not installed on the system. These artifacts are extracted later for proper application packaging with additional required metadata (TBD). These applications would each get their own subdirectory under "applications".