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)
pgpFCzmKCQDpS.pgp
Description: PGP signature
_______________________________________________ Developers mailing list [email protected] http://lists.clusterlabs.org/mailman/listinfo/developers
