Open Stack

I would suggest considering docker port mapping as a creation of an
apropriate security group's rule and also creation of something which was
never exist in Neutron before which will be responsible for port
forwarding. This feature could be useful for VMs also instead of/jointly
with using floating IPs.
What do you think?
On Aug 14, 2015 6:12 PM, "Gal Sagie" <gal.sagie at gmail.com> wrote:

> Hi Adrian,
>
> Thanks for the explanation, i agree with you that we shouldn't break
> anything useful in docker, but from what i understand
> (and please correct me if i am wrong) you are describing an implementation
> detail of docker networking (at its default current state).
>
> Kuryr is not an implementation of containers networking, it is meant to
> allow docker networking to be
> constructed using Neutron plugins and solutions.
>
> For the point i was trying to make, lets take the simple case of
> connecting containers in a host (not the nested VM case), assuming
> we use with Kuryr the L2 OVS agent and L3 agent (Neutron reference
> implementation) and we are able to plug
> containers to a neutron network and define a floating ip to it, why would
> we need port mapping? (the iptables
> translation is already happening as we have NAT)
>
> Hope that make sense, and please correct me if i am saying nonsense or i
> didn't grasp the full
> use case of port mapping.
> But none the less, we will need to allow anything that docker allows and
> keep compatibility with all the available tooling
> that depends on it as you mention (and of course be flexible to use Kuryr
> in the same environment with other
> docker remote drivers)
>
> Gal
>
> On Fri, Aug 14, 2015 at 5:26 PM, Adrian Otto <adrian.otto at rackspace.com>
> wrote:
>
>> The port mapping feature is the -p flag on the "docker run" command. It
>> determines which ports in the network namespace of the container are
>> exposed to the root namespace. It configures iptables rules and docker
>> proxy capabilities to achieve the desired result. This feature is
>> essential, so we must not break it.
>>
>> In other words, this feature is what allows a network port within a
>> container to be externally accessed, and on what IP address(es) and port
>> number(s) on the host.
>>
>> Example:
>>
>> docker run -d -p 12.34.56.7:8000:80 nginx:latest
>>
>> This runs the nginx container and exposes top port 80 from inside the
>> container to tcp port 8000 on 12.34.56.7 on the host. Without this feature
>> docker is rather useless for running network services unless you use -net
>> host or an equivalent workaround. This could break a lot of tooling that
>> depends on -p.
>>
>> --
>> Adrian
>>
>> On Aug 14, 2015, at 6:57 AM, Gal Sagie <gal.sagie at gmail.com> wrote:
>>
>> Hi feisky,
>>
>> I think thats a great question, not because of port-mapping in particular
>> :) but because
>> we need to think on a feature by feature basis and map all the features
>> the dockers API allow which
>> we cannot support directly with Neutron API or its services sub-projects
>> API.
>> (apuimedo, maybe we need to set this as a future task for us)
>>
>> But we also need to understand the use cases for supporting these API's
>> so we can address them
>> and give them priorities (and this is something we as a community need to
>> decide how to handle).
>>
>> For your question, given that we have network isolation and security from
>> neutron API's and given
>> we have NAT support (by Neutron API and the plugins implementing the
>> network) , what do you see as a use case to use the port-mapping ?
>>
>> I welcome you and everyone else to raise and describe these use cases so
>> the Neutron/Kuryr community can think
>> how to solve and help, and if needed also adjust or add extensions for
>> support.
>>
>> Thanks
>> Gal.
>>
>>
>> On Fri, Aug 14, 2015 at 7:28 AM, feisky <feiskyer at gmail.com> wrote:
>>
>>> Will Kuryr supports docker's port-mapping?
>>>
>>>
>>>
>>> --
>>> View this message in context:
>>> http://openstack.10931.n7.nabble.com/neutron-kuryr-magnum-Design-Specification-for-Kuryr-tp82256p82299.html
>>> Sent from the Developer mailing list archive at Nabble.com.
>>>
>>>
>>> __________________________________________________________________________
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
>>
>>
>> --
>> Best Regards ,
>>
>> The G.
>>
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at lists.openstack.org
>> ?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
>
> --
> Best Regards ,
>
> The G.
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150814/b9b07f29/attachment-0001.html>