Adding a default namespace [discussion]

[cdrage]

A problem that were facing is people whom are using inherited Nuleculized applications with the Docker provider (within our atomicapp python implementation) are facing namespace issues when deploying their packaged containers.

For example, when using atomicapp run --provider=docker projectatomic/helloapache you end up with a container named atomicapp_default_HASHVALUE. If you provide a namespace within an answers.conf file, you'll end up with atomicapp_name_HASHVALUE as the container name.

Due to the way that we package Nulecule applications, we do not actually provide a default namespace for the implementation to use, we rely on the user to pass in an answers.conf file.

I propose and would like to discuss the possibility of adding a namespace variable to the Nulecule file as a default name that is used when deploying. Thus having a default name when launching multiple inherited Nulecule containers.

ex.

metadata:
  name: Hello Apache App
  namespace: helloapache
  appversion: 0.0.1
  description: Atomic app for deploying a really basic Apache HTTP server

[goern]

From the specification's point of the the namespace to which an application will get deploy seems to be a configuration, so my first guess would be to put a parameter namespace in there and let the provider evaluate that parameter. An application does not need to know that it runs in a namespaced world.

2nd option... just add it to the Nulecule files to be used with Atomic App and implement that feature for all of the Atomic App providers. This will not lead to a change of the Nulecule Specification but an extension (as we do it for builders...) Any other implementation of the Nulecule Spec may ignore it (or not). If we see adoption for this feature, lets move it to the spec.

[dustymabe]

Charlie and I had a discussion about nesting namespaces that should be interesting with regards to this subject. I believe he is going to open an issue describing this in the atomicapp issue tracker.

[goern]

@dustymabe @cdrage any update on this?

[vpavlin]

1. I agree with @goern - namespace is a part of configuration, not a specification
2. Should be part of global params if anywhere in the spec..
3. Why is this even problem? Namespace generally means you cannot run 2 mysql under the same namespace, but FWIU our problem is/was you cannot run any 2 apps under a single namespace, which is clearly broken behaviour for namespaces:)

[cdrage]

@vpavlin

The main problem and motivation for this is inherited Nulecule applications. An ISV as well as a few people on IRC had been having troubles implementing inherited applications due to not being able to pass a default names-pace to them. You can do it via a hack by leaving an answers.conf file when building a Nulecule application version 0.1.13 or below, but you can't now in 0.2.1 and above in Atomic App.

I agree with 1 and 2, if global params is implemented in atomicapp then we will be able to pass a default namespace 👍

[vpavlin]

So, why don't we just pass config here?

https://github.com/projectatomic/atomicapp/blob/master/atomicapp/nulecule/base.py#L313

So that the external component we are loading knows about namespace for existing answers_file? I think this is realy just a bug to be fixed in Atomic App rather then feature missing in Nulecule;)

[cdrage]

So after long discussion with both @goern @dustymabe and @vpavlin I've come to the conclusion that this is outside the scope of the Nulecule specification and Atomic App in regards to deploying multiple namespaces within the same Nulecule container.

If one wants to deploy a Nulecule application that uses multiple kubernetes/openshift/docker clusters, they should have multiple Nulecule applications to deploy each respective cluster with their own unique namespace.

However.. the fact that setting a default namespace was needed in the first place was actually a limitation of atomicapp not passing all external answers.conf configuration files to the inherited Nulecule applications.

Namespace should be at the root level and should name all respective inherited applications appropriately and not fail when deploying the same image name within an inherited application (for example, deploying multiple redis servers)

Atomic App and all other implementations should use the root-level answers.conf file in all inherited applications.

Closing this 👍