Namespaces

Namespaces allow users to create objects with the same name in different naming spaces.

The <namespace>/<kind>/<name> notation is called a path.

The object selector (--service option for svcmgr and svcmon, first argument for om) accepts the path notation.

Namespaced objects have their config stored in /etc/opensvc/namespaces/<namespace>/<kind>/.

This feature is available since version 1.9-2748.

Operations with namespaces

The object path

The namespace is part of the path, so naming the object names its namespace. This is the way to create an object in a namespace, and it works for every command:

om test/svc/svc1 create
om test/svc/svc1 start
om 'test/**' ls

OSVC_NAMESPACE environment variable

OSVC_NAMESPACE narrows which objects a command sees, so a selector that would match the whole cluster is confined to one namespace:

$ export OSVC_NAMESPACE=test
$ om '**' ls
test/svc/svc1
test/svc/svc2

$ unset OSVC_NAMESPACE
$ om '**' ls
svc0
test/svc/svc1
test/svc/svc2

It selects among the objects that exist. It does not decide where a new one is created: with OSVC_NAMESPACE=test exported, om svc1 create still creates svc1 in the root namespace, because the path it was given says root. Name the namespace in the path instead.

Cloning into a namespace

When creating an object from another one, --namespace overrides the destination namespace, which saves rewriting the path:

om svc2 create --config=svc1 --namespace=test

This creates test/svc/svc2 from the configuration of svc1.

A configuration that refers to other objects survives the clone only if those references are relative. See Relative object paths.

References

A {namespace} reference is available in service configuration.

Cgroups

Services in an explicit namespace have the namespace name inserted in their cgroup path:

opensvc.slice/<namespace>.slice/<name>.slice

The “root” pseudo namespace

Services created before namespace support, and services created without an explicit namespace, are assigned to a pseudo namespace named root. Their configs are stored in /etc/opensvc/.

The root pseudo namespace name is used in cluster DNS names (<name>.root.svc.<clustername>) and DNS search paths, but is not embedded in Docker container names or cgroup paths.

The {namespace} reference evaluates to root.

Select objects in the root namespace

$ om 'root/**' ls
$ OSVC_NAMESPACE=root om '**' ls

Create objects in the root namespace

$ unset OSVC_NAMESPACE
$ om svc1 create

Relative object paths

An object referring to another one can name it with a path relative to its own namespace, by replacing the namespace with a .:

[DEFAULT]
parents = ./svc/db

[fs#1]
install = /etc/app.conf from ./cfg/app key app.conf

./svc/db reads as “the db service, in whatever namespace I am in”. For test/svc/app it resolves to test/svc/db, and for prod/svc/app to prod/svc/db, with no change to the configuration.

That is the point of the notation: a set of objects designed together can be cloned from a development namespace to a production one, and keeps referring to its own members rather than reaching back into the namespace it came from. A fully qualified test/svc/db would follow the clone and still point at test.

Node configuration is not namespaced, so the same notation in node.conf resolves in the system namespace: ./sec/relays is system/sec/relays.

Relations

Children and parents relations use object paths or object names.

• If a name is declared in the parents, slaves, or children lists, the related objects are searched in the same namespace. svc2 and ./svc/svc2 are the same relation, the second stating it explicitly.
• A relation to an object in another namespace must be declared using its path instead of its name.
• Relations to objects in the root pseudo namespace must be defined as root/<kind>/<name> to avoid ambiguity.