summaryrefslogtreecommitdiffstats
path: root/kubernetes/onap/values.yaml
AgeCommit message (Collapse)AuthorFilesLines
2018-04-27Fix SDNC DMaaP connectivity issuesjmac1-4/+0
DMaaP listener was not trying to connect to the right service name, so it was failing. In addition, the pod doesn't wait for the dmaap pod to be up and running before starting, so I've added that dependency. Lastly, I removed the config of the DMaaP port from the top level values.yaml files, as out of the box it's very unlikely this would be changed. Change-Id: I5a190b39f4f163b020189ac9dd178040f80125cd Signed-off-by: jmac <james.macnider@amdocs.com> Issue-ID: SDNC-293
2018-04-19fix nfs-provisioner for appc and sdncJerome Doucerain1-1/+1
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>
2018-04-16Fix SDN-C bundles that don't come up properlyjmac1-0/+9
Change-Id: Ieccbd863e45bb68d76f4f1f066433276c9adf3cd Signed-off-by: jmac <james.macnider@amdocs.com> Issue-ID: OOM-945
2018-04-12VFC Communication fails because MSB service namemahendrr1-1/+1
Change-Id: I26e27cfb3b973bbffd0a94e3ec8411f5218cdf4f Issue-ID: OOM-804 Signed-off-by: mahendrr <mahendra.raghuwanshi@amdocs.com>
2018-04-10Standardized Config for VFCMike Elliott1-1/+1
Change-Id: Ie7064b59032c6cd81ee37466c89a5dee74530939 Issue-ID: OOM-750 Signed-off-by: Mike Elliott <mike.elliott@amdocs.com>
2018-04-04Message Router Helm Chart Standardizationpramod1-1/+1
Issue-ID: OOM-731 Change-Id: I2137b9dbe7c7a320094c13779e8e43dadef964c7 Signed-off-by: pramod <pramod.kumarsharma@amdocs.com> Signed-off-by: Mike Elliott <mike.elliott@amdocs.com>
2018-04-03Remove global repository from onap chartMike Elliott1-11/+15
See description in linked issue id. Change-Id: I3bcec1214875cb318dc45162013aec8957443dc8 Issue-ID: OOM-845 Signed-off-by: Mike Elliott <mike.elliott@amdocs.com>
2018-04-02Add Standardized Configuration to SDN-C Chartjmac1-0/+5
Change-Id: I9f4d43c2a3f0766b9c8477a180f5a0bd45fde243 Signed-off-by: jmac <james.macnider@amdocs.com> Issue-ID: OOM-748
2018-03-27Add standardized helm chart for logBorislavG1-1/+1
Change-Id: Ic9f0eb567716224893955d9379e9ed9308b9ea79 Issue-ID: OOM-740 Signed-off-by: BorislavG <Borislav.Glozman@amdocs.com>
2018-03-23Enable all helm charts by default in parent chartMike Elliott1-21/+21
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>
2018-03-22License addition in all yamlsvaibhav_16dec1-0/+14
Issue-ID: OOM-821 Change-Id: I627ac962afe8cd6bf2859a30a0e88f6c9ac89d34 Signed-off-by: vaibhav_16dec <vaibhav.chopra@amdocs.com>
2018-03-19Robot Helm Chart Standardizationvaibhav_16dec1-1/+1
Issue-ID: OOM-728 Change-Id: I2e6b298a78e7d10c47ce1d531bf089c928a40284 Signed-off-by: vaibhav_16dec <vaibhav.chopra@amdocs.com>
2018-03-12Deploy kube2msb along with msb containersHuabingZhao1-3/+1
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>
2018-03-09iterating on new helm structure for SOMandeep Khinda1-0/+1
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>
2018-02-23Add onap parent chartMike Elliott1-0/+105
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>