Currently, the charts in common that are intended to be “shared” are meant to
be referenced by charts that would make use of them. It reduced redundancy.
Appc will reference the dgbuilder chart in the common dir.
Sdnc will reference the same dgbuilder chart.
Each will tune configuration so that they are named differently and talk to
their respective DBs.
All containers will be grouped under a helm release and in a single namespace.
As we move towards DbaaS’s I think the ONAP umbrella chart would include a
requirement.yaml entry for postgres, maria-galera, etc.. so if you spin up ONAP
as a whole, it will deploy each DB as a Service container for other
applications to make use of.
I added some more notes below in red.
From: <onap-discuss-boun...@lists.onap.org> on behalf of "LUNANUOVA, DOMINIC
Date: Friday, April 6, 2018 at 3:30 PM
To: "'email@example.com'" <firstname.lastname@example.org>
Subject: [onap-discuss] [OOM] common Helm Chart conventions
I played a bit with the common/postgres chart, and understand it is a WIP.
But have some questions:
* Should we expect a common chart to deploy in the same namespace as the
app requiring it?
Specifically, I found postgres deploys to default namespace, while my pod
deployed in onap namespace.
[MK] helm install will use the namespace you specify with the “--namespace”
parameter. If you leave this out, your helm release name will use the
namespace “default” which is where K8s installs is pods for the kubernetes
system. I don’t think we want to mix onap pods with the k8s pods. Ideally
if you leave it out it will use a namespace called “onap”. We have had this
idea but it hasn’t been flushed out or implemented yet.
* Should a service ever deploy to default namespace? And if this is
allowed, does it imply that it is a “shared” service (i.e. used by more than 1
When I attempted helm install local/onap I observed several (non-common)
services, secrets and configmaps all in default namespace.
[MK] – I don’t believe onap apps should deploy to a mix of namespaces. All in
a namespace of the users choosing or the pre-existing one provided by the K8s
cluster which is called “default”
* Are there any access rule in Kubernetes that impact the naming convention
for locating a service in another namespace?
Specifically, I discovered my pod in onap namespace could not connect to host
“pgset” but it could connect to “pgset.default”. Yet when I asked others if
this should be necessary, they said no.
[MK] Namespaces are like a bubble for an ONAP helm release. While we haven’t
had a use case for this yet, If something in your bubble wants to talk to a
component in somebody else’s bubble it will need to use the FQDN Kube-DNS entry
which is the K8s service specification suffixed by the other bubbles namespace
This is what we used to have. Each app had its own namespace and had to use
the FQDN to communicate across each bubble. We abolished this and everything
is in a single bubble.
This message and the information contained herein is proprietary and
confidential and subject to the Amdocs policy statement,
you may review at https://www.amdocs.com/about/email-disclaimer
onap-discuss mailing list