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: <> on behalf of "LUNANUOVA, DOMINIC 
Date: Friday, April 6, 2018 at 3:30 PM
To: "''" <>
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?
[MK] Yes

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 
parent chart)?

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 
onap-discuss mailing list

Reply via email to