[ClusterLabs Developers] bundle/rkt: port-mapping numbers/names

[Ken Gaillot]

On 07/19/2017 01:20 AM, Valentin Vidic wrote:
> Another issue with the rkt containers is the port-mapping.  Each container
> defines exposed ports:
> 
> 	"ports": [
> 		{
> 			"name": "http",
> 			"protocol": "tcp",
> 			"port": 80,
> 			"count": 1,
> 			"socketActivated": false
> 		},
> 	]
> 
> These are than mapped using the "name" from the definition:
> 
>       --port=                   ports to expose on the host (requires contained network). Syntax: --port=NAME:[HOSTIP:]HOSTPORT
> 
> The problem now is that the xml defines the port to be a number:
> 
>       <attribute name="port"><data type="integer"/></attribute>
> 
> Workaround is to use "80" as a port name, but perhaps we could allow
> port to be a string or introduce a new attribute:
> 
>       <port-mapping id="httpd-port" port-name="http"/>
> 
> What do you think?

Hmm, this was a questionable design choice on our part. There was some
question as to what to include in the docker tag (and thus could be
different under different container technologies) and what to put
outside of it (and thus should be supported by all technologies).

I'm guessing the situation is that your code needs to do something about
the port mapping (otherwise you could just omit port-mapping with rkt),
and the rkt "ports" configuration is pre-existing (otherwise your code
could generate it with an arbitrary name).

I would think this would also affect the control-port attribute.

I see these alternatives, from simplest to most complicated:

* Just document the issue and require rkt configurations to have name
equal to port number.

* Is it possible for the code to take the port number from port-mapping
and query the rkt configuration to find the appropriate name?

* Is it possible for the code to generate a duplicate/override "ports"
configuration with a generated name?

* Relax the port attribute to <text/> and let the container
implementation validate it further as needed. A downside is that some
Docker config errors wouldn't be caught in the schema validation phase.
(I think I prefer this over a separate port-name attribute.)

* Restructure the RNG so that the choice is between
<docker.../><network...><port-mapping ...integer/> and
<rkt.../><network...><port-mapping...text/>. It would be ugly and
involve some duplication, but it would satisfy both implementations.

* Modify the schema so <network> is enclosed within the technology tag,
and provide an XSL transform for existing configurations.

The last two options have the advantage of letting us move the <docker>
"network" attribute to the <network> tag.