Open Stack

On 08/02/2016 08:15 AM, huangdenghui wrote:
> hi john and brain
>    thanks for your information, if we get patch[1],patch[2] merged,then fg can
> allocate private ip address. after that, we need consider floating ip dataplane,
> in current dvr implementation, fg is used to reachment testing for floating ip,
> now,with subnet types bp,fg has different subnet than floating ip address, from
> fg'subnet gateway point view, to reach floating ip, it need a routes entry,
> destination is some floating ip address, fg'ip address is the nexthop, and this
> routes entry need be populated at the event of floating ip creating, deleting
> when floating ip is dissociated. any comments?

Yes, there could be a small change necessary to the l3-agent in order to route 
packets with DVR enabled, but I don't see it being a blocker.

-Brian


> On 2016-08-01 23:38 , John Davidge <mailto:John.Davidge at rackspace.com> Wrote:
>
>     Yes, as Brian says this will be covered by the follow-up patch to [2]
>     which I¹m currently working on. Thanks for the question.
>
>     John
>
>
>     On 8/1/16, 3:17 PM, "Brian Haley" <brian.haley at hpe.com> wrote:
>
>     >On 07/31/2016 06:27 AM, huangdenghui wrote:
>     >> Hi
>     >>    Now we have spec named subnet service types, which provides a
>     >>capability of
>     >> allowing different port of a network to allocate ip address from
>     >>different
>     >> subnet. In current implementation of DVR, fip also is distributed on
>     >>every
>     >> compute node, floating ip and fg's ip are both allocated from external
>     >>network's
>     >> subnets. In large public cloud deployment, current implementation will
>     >>consume
>     >> lots of public ip address. Do we need a RFE to apply subnet service
>     >>types spec
>     >> to resolve this problem. Any thoughts?
>     >
>     >Hi,
>     >
>     >This is going to be covered in the existing RFE for subnet service types
>     >[1].
>     >We currently have two reviews in progress for CRUD [2] and CLI [3], the
>     >IPAM
>     >changes are next.
>     >
>     >-Brian
>     >
>     >[1] https://review.openstack.org/#/c/300207/
>     >[2] https://review.openstack.org/#/c/337851/
>     >[3] https://review.openstack.org/#/c/342976/
>     >
>     >__________________________________________________________________________
>     >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
>
>
>     ________________________________
>     Rackspace Limited is a company registered in England & Wales (company
>     registered number 03897010) whose registered office is at 5 Millington Road,
>     Hyde Park Hayes, Middlesex UB3 4AZ. Rackspace Limited privacy policy can be
>     viewed at www.rackspace.co.uk/legal/privacy-policy - This e-mail message may
>     contain confidential or privileged information intended for the recipient.
>     Any dissemination, distribution or copying of the enclosed material is
>     prohibited. If you receive this transmission in error, please notify us
>     immediately by e-mail at abuse at rackspace.com and delete the original
>     message. Your cooperation is appreciated.
>
>     __________________________________________________________________________
>     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
>