summaryrefslogtreecommitdiffstats
path: root/kubernetes/modeling
AgeCommit message (Collapse)AuthorFilesLines
2020-05-15update release version of modeling-etsicatalogdyh1-1/+1
Issue-ID: MODELING-349 Change-Id: I52bb7f5f560fa3af6ece968b9c1e8ebc5331b813 Signed-off-by: dyh <dengyuanhong@chinamobile.com> (cherry picked from commit 238a0ea1f83b64c1d5a4258fb8741542ac1fbf49)
2020-04-21Register API to MSB via HTTPSdyh3-1/+11
Issue-ID: MODELING-291 Change-Id: Ic1472b5263768bdfcae333c75bb37e43d776b538 Signed-off-by: dyh <dengyuanhong@chinamobile.com>
2020-04-02Bump chart versionSylvain Desbureaux4-5/+5
Use 6.0.0 in preparation for Frankfurt release Issue-ID: OOM-2320 Signed-off-by: Sylvain Desbureaux <sylvain.desbureaux@orange.com> Change-Id: I8ad82dfdf48b56c38c0e85d640b18cc13c8d9e67
2020-03-31update release version of modeling-etsicatalogdyh1-1/+1
Change-Id: I24bc6a57b4d67883f6d26d2112b9573fc632b58b Issue-ID: MODELING-349 Signed-off-by: dyh <dengyuanhong@chinamobile.com>
2020-03-25[MODELING] Use faster version of common secret templateKrzysztof Opasiak2-2/+2
Issue-ID: OOM-2051 Signed-off-by: Krzysztof Opasiak <k.opasiak@samsung.com> Change-Id: I78da9c8786642531ce57475869eaeb6c21fd0376
2020-02-20update msbPortdyh1-1/+1
Change-Id: Iff0251e5ccd432985d9b25ea80f004d7e772a652 Issue-ID: MODELING-317 Signed-off-by: dyh <dengyuanhong@chinamobile.com>
2020-02-05Removed use of vfc-redis from etsicatalog componenthongyuzhao2-4/+0
Change-Id: Ie00783e0e55136aa40a8c3cf266ebc486240e308 Issue-ID: MODELING-307 Signed-off-by: hongyuzhao <zhao.hongyu@zte.com.cn>
2020-02-02[Modeling] Use common secret template for mariadb root passwordKrzysztof Opasiak3-16/+37
Remove hardcoded root password from the modeling chart. Because of huge number of issues in modeling docker image (see onap-discuss for details) I don't want to touch it. That's why I just made an awful hack to concatenate DB username and password before the entrypoint script. Please keep in mind that this eliminates only hardcoded root password but there is plenty of other credentials that are boiled into container image (DB, SDC, VCF-REDIS(!) etc). Issue-ID: OOM-2286 Signed-off-by: Krzysztof Opasiak <k.opasiak@samsung.com> Change-Id: Id85a03ec7f55885b606179d10e8b6528c6cb6947
2020-02-01[Modeling] Move mariadb-galera to etsicatalogKrzysztof Opasiak6-39/+74
etsicatalog is the only component inside modeling which use this DB thus there is no point to keep it outside of this component. Passwords and other bad stuff is left intentionally as this is just a first patch for this transition. Issue-ID: OOM-2286 Signed-off-by: Krzysztof Opasiak <k.opasiak@samsung.com> Change-Id: I4f592b736a86c7acf9ee43b0f6e136e5f1506847
2020-02-01[ONAP-wide] Replace .Release.Name with common.releaseKrzysztof Opasiak5-9/+9
ONAP is too big to be deployed using helm install so we need to use a custom helm plugin helm deploy. This script deloys onap component by component instead of deploying evrything at once. Unfortunately this script also modifies the helm release by appending component name to it. As a result of this behavior our objects are called for example: onap-mariadb-galera-mariadb-galera-0 instead of just being called onap-mariadb-galera-0. This patch simplifies this naming convention by replacing all direct usages of .Release.Name with common.release macro which strips the component specific part from the release name. Issue-ID: OOM-2275 Signed-off-by: Krzysztof Opasiak <k.opasiak@samsung.com> Change-Id: Ia8cead50d305adb00eef666d0a1ace74479b5183
2019-12-09[Modeling] Use global storage templates for PVCSylvain Desbureaux2-12/+6
OOM has now templates in order to create the needed PVC, using: * a PV with a specific class when using a common nfs mount path between nodes (sames as today use) --> is the default behavior today * or a storage class if we want to use dynamic PV. On this case, we use (in order of priority): - persistence.storageClassOverride if set on the chart - global.persistence.storageClass if set globally - persistence.storageClass if set on the chart Change-Id: I337e760ea71ec57c4f593e068c3cf6ea548a3cfc Issue-ID: OOM-1227 Signed-off-by: Sylvain Desbureaux <sylvain.desbureaux@orange.com>
2019-10-07Fixing Basic Modeling genericparser API Health Check Failingafenner1-3/+3
Change-Id: If2cf110e0387acaff61d996435efdedf41561b60 Issue-ID: OOM-2126 Signed-off-by: afenner <andrew.fenner@est.tech>
2019-10-02update OOM configuration for modeling/etsicatalogdyh9-16/+28
Change-Id: Ie6f18487961bc7de723f5dc69e37abfd5006f550 Issue-ID: MODELING-222 Signed-off-by: dyh <dengyuanhong@chinamobile.com>
2019-09-02Move Modeling Storage to RWOSylvain Desbureaux1-1/+1
Today when deploying Policy with OOM, the PersistentVolumeClaim needs the "ReadWriteMany" (or "RWX") capability. According to Kubernetes Documentation (https://kubernetes.io/docs/concepts/storage/persistent-volumes/#access-modes), ReadWriteMany stands for "the volume can be mounted as read-write by many nodes". That means that a particular PVC needs to be read and written from many pods. That also means that your code takes that into account and do the work to avoid write at the same place at the same time. An issue on RWX mode is that most "official" storage driver from Kubernetes doesn't support it (13 over the 19 drivers doesn't support it, espacially OpenStack, Amazon and Google storage classes). Modeling PVC for is used only for one POD. Thus we don't need RWX. Change-Id: Ic4b8f5a336f2b9edfdf25ef3cc549b389f9b6f65 Issue-ID: MODELING-213 Signed-off-by: Sylvain Desbureaux <sylvain.desbureaux@orange.com>
2019-07-11Moving Helm Chart version for El AltoMike Elliott3-4/+4
Updating all helm chart versions to 5.0.0 for the El Alto release. Merge will be co-ordinated with the merge of a separate aai/oom patch. Please do not merge until this coordination has completed. Issue-ID: OOM-1980 Signed-off-by: Mike Elliott <mike.elliott@amdocs.com> Change-Id: I31daaebeacea33565f13affd2fa28fb15fe948ba
2019-05-24update oom versionyangyan1-1/+1
Change-Id: Ic723624865b200ea025602aee0ec60efb4b9a09f Issue-ID: VFC-1373 Signed-off-by: yangyan <yangyanyj@chinamobile.com>
2019-05-10Add modeling parser chartyangyanyj14-0/+664
Issue-ID: MODELING-165 Change-Id: I46419561fdc3f1b4fb7a7bcf19185ac6cbd99c1d Signed-off-by: yangyanyj <yangyanyj@chinamobile.com>