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

[Jan Pokorný]

On 19/07/17 09:49 -0500, Ken Gaillot wrote:
> 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.

I don't think that alone would suffice, I'd expect at least (port,transport)
pair to be reasonably unique as long as you can remap TCP/UDP independently
(I am not sure, but would be no surprise) -- but hey, we have just hit
another limitation of the current schema (transport layer not being
taken into account -- is TCP silently assumed, then?).

> * 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.

Similar approach was discussed with another proposed change:
http://oss.clusterlabs.org/pipermail/users/2017-April/005552.html
(item 1., i.e., separating the pacemaker-level pseudogenerics from
the tag for a particular engine) which still might be appealing,
especially as/if the schema gets changed anyway.

Valentin, is rkt able so serve containers from one image/location
in multiple instances in parallel?

> * 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.

-- 
Jan (Poki)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.clusterlabs.org/pipermail/developers/attachments/20170719/03920d40/attachment.sig>