Age | Commit message (Collapse) | Author | Files | Lines |
|
change in common/mysql/templates/pvc.yaml to allow pvc use
when persistence is required
change in common/mysql/templates/storageclass.yaml to be
led by the disableNfsprovisioner variable
change in appc/values to default the disableNfsprovisioner
to false as it is in sdnc
changing the default disableNfsprovisioner to true for both appc and sdnc
changing the stateful set avoid volumeclaimtemplates.
When used in helm, the volumeclaimtemplates is causing pvc to be left
after the helm delete --purge. I guess this is due to the fact the pvc
are not directly created by the helm install by indirectly by kubernetes
Now the tests are working in both cases (nfsprovisioner disabled or not)
The only piece remaining after a helm delete is pv in released state
in case we are using nfsprovisioner. That makes sense again because this
are objects created by the provisioner and not by helm.
removed some leftover
Issue-ID: OOM-787
Change-Id: Ieb1f1c482217aeb1b89be39a437bb891a299db71
Signed-off-by: Jerome Doucerain <jerome.doucerain@bell.ca>
|
|
Change-Id: Ieccbd863e45bb68d76f4f1f066433276c9adf3cd
Signed-off-by: jmac <james.macnider@amdocs.com>
Issue-ID: OOM-945
|
|
Change-Id: I26e27cfb3b973bbffd0a94e3ec8411f5218cdf4f
Issue-ID: OOM-804
Signed-off-by: mahendrr <mahendra.raghuwanshi@amdocs.com>
|
|
Change-Id: Ie7064b59032c6cd81ee37466c89a5dee74530939
Issue-ID: OOM-750
Signed-off-by: Mike Elliott <mike.elliott@amdocs.com>
|
|
Issue-ID: OOM-731
Change-Id: I2137b9dbe7c7a320094c13779e8e43dadef964c7
Signed-off-by: pramod <pramod.kumarsharma@amdocs.com>
Signed-off-by: Mike Elliott <mike.elliott@amdocs.com>
|
|
See description in linked issue id.
Change-Id: I3bcec1214875cb318dc45162013aec8957443dc8
Issue-ID: OOM-845
Signed-off-by: Mike Elliott <mike.elliott@amdocs.com>
|
|
Change-Id: I9f4d43c2a3f0766b9c8477a180f5a0bd45fde243
Signed-off-by: jmac <james.macnider@amdocs.com>
Issue-ID: OOM-748
|
|
Change-Id: Ic9f0eb567716224893955d9379e9ed9308b9ea79
Issue-ID: OOM-740
Signed-off-by: BorislavG <Borislav.Glozman@amdocs.com>
|
|
This is as a means towards obsoleting the oneclick scripts
from the Beijing release, in favour of directly using Helm.
From this point on, users of onap should use the follow
command:
helm install local/onap -n onap --namespace onap
Please refer to the official documentation for all the steps
required to deploy onap. Currently as a patched to be
merged: https://gerrit.onap.org/r/#/c/37871/
Change-Id: I75e5dbc9a79fec86a9b7c0cff487b10ec9df9a20
Issue-ID: OOM-816
Signed-off-by: Mike Elliott <mike.elliott@amdocs.com>
|
|
Issue-ID: OOM-821
Change-Id: I627ac962afe8cd6bf2859a30a0e88f6c9ac89d34
Signed-off-by: vaibhav_16dec <vaibhav.chopra@amdocs.com>
|
|
Issue-ID: OOM-728
Change-Id: I2e6b298a78e7d10c47ce1d531bf089c928a40284
Signed-off-by: vaibhav_16dec <vaibhav.chopra@amdocs.com>
|
|
Issue-ID: OOM-280
Deploy kube2msb along with msb contianers, so the ONAP services can be sync to MSB after MSB is restarted
Change-Id: I408e27c72c4b2169c0babe2562e74d4a645683de
Signed-off-by: HuabingZhao <zhao.huabing@zte.com.cn>
|
|
with this change we can now do the following:
can deploy umbrella chart with currently working components:
helm install local/onap --name onap --namespace onap-all
helm install local/onap --name onap-2 --namespace onap-all-2 \
--set global.nodePortPrefix=303
- umbrella includes setup chart
can deploy a-la-carte component by component into a single namespace
- Need to deploy a setup chart first. cannot be made a helm dependency
as there will be conflicts if each app chart has the same setup dependency.
helm install local/setup --name onap-setup --namespace onap-apps
helm install local/so --name so1 --namespace onap-apps \
--set global.nodePortPrefix=304
helm list
NAME REVISION STATUS CHART NAMESPACE
onap 1 DEPLOYED onap-2.0.0 onap-all
onap-2 1 DEPLOYED onap-2.0.0 onap-all-2
onap-setup 1 DEPLOYED setup-2.0.0 onap-apps
so1 1 DEPLOYED so-2.0.0 onap-apps
Unfortunately, the config maps all have fixed names, so installing
the same app in the a-la-carte fashion will fail due to a collision.
Not worrying about this as I'm not sure we want to support this.
-made the common and setup charts standalone to remove relative file paths
from requirements.yaml
This will help when there are different levels of subcharts that
need to include common
Issue-ID: OOM-786
Issue-ID: OOM-789
Issue-ID: OOM-788
Change-Id: I20bacae6f0f20e8f3bb1527af1e7e53f187341d5
Signed-off-by: Mandeep Khinda <mandeep.khinda@amdocs.com>
|
|
This is a top-level parent helm chart which deploys customizations
of the ONAP platform.
The parent ONAP chart represents the start of OOM's move away from
the oneclick bash scripts and towards the direct use of Helm to
manage configuration and deployment of ONAP.
How to deploy onap chart from local oom/kubernetes codebase.
** need to create/update dependencies defined in the chart's
** requirements.yaml
helm dep update onap/
** deploy the onap parent chart (and all referenced subcharts)
** with the "release" name of 'onap'
helm install onap/ -n onap
Change-Id: I71bee25770bdce82a47bfabb04946bb4fad069a2
Issue-ID: OOM-265
Signed-off-by: Mike Elliott <mike.elliott@amdocs.com>
|