Closed cdrage closed 8 years ago
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.
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.
@dustymabe @cdrage any update on this?
namespace
is a part of configuration, not a specificationparams
if anywhere in the spec..@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 :+1:
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;)
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 :+1:
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 namedatomicapp_default_HASHVALUE
. If you provide a namespace within an answers.conf file, you'll end up withatomicapp_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.