Add objects to express links and relationships between graph objects.

[markllama]

The current nulecule spec appears to have objects needed to describe container objects and some resource requirements for individual containers. I do not see any elements specifically defined to express links and other relationships between containers.

The specific case is for Kubernetes nulecules where they defer the link definitions to Kubernetes "service" artifacts. This is sufficient when running in pure kuberentes, but becomes a problem if you are trying to run with a different provider, one that needs the definitions of container links but does not accept Kubernetes service JSON files as input.

This is the case if one were to try to create an OpenShift (or other PaaS) provider. The provider will need to communicate through the PaaS API rather than directly submitting Kubernetes configuration files. This means that the Nulecule specification must be explictly aware of the communications links between graph elements so that the provider plugin can generate the correct API calls to establish the links in terms that the host service can accept.

The purpose if this issue is to start a discussion of the best way to express these links between containers within a Nulecule and also possibly inbound or outbound communications links which must be established by the providers to make the resulting nulecule application operational and accessible.

[markllama]

I could be wrong. The oc create --filename CLI command allows the creation of a Kubernetes service within OpenShift. If there is a matching API object then it is possible that the kubernetes artifacts can be used as-is.

[markllama]

It appears also that OpenShift creates new services as pods are deployed, though how it knows to do that (examining the EXPOSE directives of the container images?) and how it decides to map them to selectors is unclear.

[markllama]

Well there it is: an OpenShift application template example:

https://github.com/gshipley/openshift3mlbparks/blob/master/mlbparks-template.json

[langdon]

@rtnpro and I were discussing this very thing at the the f2f, particularly in regards to supporting docker-compose in atomicapp. @rtnpro can you add some of your comments / thoughts here?

[rtnpro]

@whitel @markllama we already have a PR in atomicapp implementing docker-compose as a provider. However, I believe that the discussion here is much more than docker-comose. It's about specifying docker links equivalent info in a Nulecule file. We're also discussing on stating dependency (static and dynamic/runtime) among the components of a Nulecule app. Every component in a Nulecule app takes certain parameters to run, and on run, it exposes some parameters, which could be utilized by other components.

For example, if a db component of a nulecule app exposes the host and port info it is running on, this info could be used by the app component to make the db endpoint available in it's environment. In this way, we can achieve logical linking across Nulecule components without solely relying on the underlying providers. This approach might even work across providers.

With the kind of feature discussed above, it may seem like Nulecule will start overlapping with the orchestration domain, for which there are much better and bulkier tools out there. It's not about just linking containers one time. You have to have a service to keep monitoring the dependent containers and update the linkage info. Both docker and kubernetes are capable of doing so. I am not sure if it is in the scope of Nulecule's goals.

As far as I know, Nulecule is supposed to be just a packaging layer to ship multiple container applications. All the orchestration bit will still be handled by the underlying providers. This will help keep Nulecule lean and simple.

That said, it does not hurt to implement the above feature of exposing data from a component run to be used by other components. It will open doors for a lot of possibilities with Nulecule.

Let me know, what you think.

[langdon]

I think we are conflating two, probably, separate things. "Relationships" between containers and (for lack of a better term) config management. The relationships part (aka links) i think might be a useful addition to the spec. However, I think the config management part, which is probably something that may be useful, is probably best solved via best practice or in orchestrators. Providing the link information to an orchestrators is pretty open-ended on what they do with it and, as such, requires no "implementation" just a spec promise that the one object will be able to reach the other.

[rtnpro]

@whitel

"Providing the link information to an orchestrators is pretty open-ended on what they do with it and, as such, requires no "implementation" just a spec promise that the one object will be able to reach the other."

:+1: