[openstack-dev] [neutron] [dhcp] DHCP Agent resync
Hi DHCP Agent SMEs We are reviewing the DHCP Agent in Icehouse, specifically for an issue where the dnsmasq host file has multiple stale or replicated (IP address) entries (as compared to the DB allocations for the subnet). We also checked the other HA dnsmasq instance and it is correctly sync’d with the DB. Right now we can only guess that the network cache of the DHCP Agent has somehow gotten out of sync with the DB due to Rabbit message loss of port_create_end or port_update_end (but there might be other reasons), which then results in a stales agent cache. A DHCP Agent restart will, of course, clear the problem. Historically speaking, we are wondering what the reasoning / thoughts might have been at that time as to why a cache refresh on the DHCP Agent was not implemented. Our thoughts were that it could generate a lot of messaging traffic across Rabbit, but are there other reasons? NOTE: We can see that the code could support it under some exception handling cases, but it seems the “agent_updated” method is not triggered. Does anyone have the history on this, and is there any thought on enabling such a sync? Thanks for any insights, Randy __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [neutron][dhcp] DHCP Agent resync
Hi DHCP agent SMEs We are reviewing the DHCP Agent in Icehouse, specifically for an issue where the dnsmasq host file has multiple stale or replicated (IP address) entries (as compared to the DB allocations for the subnet). We also checked the other HA dnsmasq instance and it is correctly sync’d with the DB. Right now we can only guess that the network cache of the DHCP Agent has somehow gotten out of sync with the DB due to Rabbit message loss of port_create_end or port_update_end (but there might be other reasons). A DHCP Agent restart will, of course, clear the problem. Historically speaking, we are wondering what the reasoning / thoughts might have been as to why a cache refresh on the DHCP Agent was not implemented. Our thoughts were that it could generate a lot of messaging traffic across Rabbit, but are there other reasons? NOTE: We can see that the code could support it under some exception handling cases, but it seems the “agent_updated” method is not triggered. Does anyone have the history on this, and is there any thought on enabling such a sync? Thanks for any insights, Randy __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [kolla][kubernetes] Mirantis participation in kolla-mesos project and shift towards Kubernetes
Sergey This is very interesting and exciting In fact, a few colleagues and myself actually plan to present at the Austin OS summit [1] around with the self-healing OpenStack Control Plane, a taste of which can be found here [2]. It’s a fully clustered, HA control plane PoC that we’ve put together using community OpenStack. Would be nice to connect with you at the Summit. [1] https://www.openstack.org/summit/austin-2016/summit-schedule/events/8766 [2] https://youtu.be/lihNUrKOf3g -- Cheers, Randy Tuttle From: Sergey Lukjanov Reply-To: "OpenStack Development Mailing List (not for usage questions)" Date: Friday, April 22, 2016 at 2:17 PM To: OpenStack Development Mailing List Subject: [openstack-dev] [kolla][kubernetes] Mirantis participation in kolla-mesos project and shift towards Kubernetes Hi folks, I’ve been approached by multiple people asking questions about what is happening with Mirantis engineers activity around the kolla-mesos project we started and I do feel that I owe an explanation to the community. Indeed during the last few months we significantly reduced the amount of contribution. Jumping straight to the point, I would like to say right away that we will have to abandon the kolla-mesos initiative. If anybody would like to pick it up and continue moving forward, Mirantis will do everything we can to help with the ownership transition including sharing what we learned along the way. Now please let me explain the reasons behind this decision which I hope will turn into an active discussion in the OpenStack community. When we started work on the containerization of OpenStack we did not have a clear picture of the design choices and decisions that would need to be made. What we knew there is a community project around the effort - Kolla, and we decided to try and explore the opportunity to join these efforts. First let me express my gratitude towards the Kolla community for their willingness to help and support our efforts. The way the Kolla project accepted and helped new people join the project is one of the fundamental behaviours that makes me really proud to be a part of the OpenStack community. During the journey working in Kolla, we discovered that there are quite a few fundamental mismatches between where we believe we need to arrive running OpenStack containers inside orchestration framework like Mesos and Kubernetes and the Kolla direction of running containers using Ansible. While there is nothing wrong with either approach, there are some technical difficulties which lead to conflicting requirements, for example: * Containers definition should be easy readable and maintainable, it should provide meta information such as list of the packages to be installed in the container, etc (container image building DSL is one of the options to implement it); * It should be possible to implement containers layering, naming and versioning in a way to support upgradability and patching, especially in terms of shipping security updates and upgrades to the users; * Containers implementation should be clear from the bootstrap and init scripts; * Repository per OpenStack and Infra component, e.g. one from nova, one for neutron and etc. - to contain all needed container images for running corresponding services in different topologies; * It should be possible to use other containers, not just docker, for example - rkt. Since we believed Kolla would likely have to change direction to support what we needed but we still were not sure in the exact technical direction needed to take, Mirantis decided to take a pause to prevent unnecessary churn to project and run a number of research initiative to experiment with different concepts. While the above work was happening, Mirantis was also tracking how the Kubernetes project and community were developing. We were very glad to see significant progress made over a short period of time and community momentum build similar to how OpenStack grew in the early days. As part of our exploration activities we decided to give Kubernetes a try to see if we could make containerized OpenStack work on Kubernetes and better understand what changes to OpenStack itself would be needed to best support this approach. At this point I’m glad to announce that I was able to do a very simple PoC (~1.5 weeks) with the core OpenStack control plane services running on top of Kubernetes. I’ve recorded a demo showing how it’s working [1]. Based on our research activities and rapid growth of the Kubernetes community, which shares many parallels to the OpenStack community, we are switching our efforts to focus on running OpenStack on Kubernetes. We are going to do the development work upstream and as part of that share and contribute results of prototyping and research work we have done so far. We are considering multiple options on what is the right place in community for this work to happen: re-joi
Re: [openstack-dev] [Neutron][IPv6]
Hi Harm It’s highly unlikely that it would work with a current version of Neutron (Icehouse was where the original effort went). I’ve just run out of cycles to work on this. I know Sean Collins continues to drive this effort, and the roadmap may have this BP (or a similar one) targeted for Kilo. Check with Sean. Randy On Aug 15, 2014, at 3:25 PM, Harm Weites wrote: > Hi Randy, > > I was reading throught your blueprint [1] and figured it was exactly > what I'm after to get dualstack v4/v6 in my cloud. Sadly, the review has > it's current state set to abandoned. > > Are there any plans to get back to it and get it into trunk? > > Furthermore, does it still apply (and work) on a recent checkout of > Neutron, or should I just go ahead and give it a go? > > [1] > https://blueprints.launchpad.net/neutron/+spec/allow-multiple-subnets-on-gateway-port > [2] https://review.openstack.org/#/c/77471/ > > Thanks, > Harm ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron][IPv6] Code review: bp/allow-multiple-subnets-on-gateway-port
Resending as I realized I had omitted a subject Sorry for blasting again. Hi all. Just submitted the code[1] for supporting dual-stack (IPv6 and IPv4) on an external gateway port of a tenant's router (l3_agent). It implements [2]. Please, if you would, have a look and provide any feedback. I would be grateful. Cheers, Randy [1]. https://review.openstack.org/#/c/77471/ [2]. https://blueprints.launchpad.net/neutron/+spec/allow-multiple-subnets-on-gateway-port ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][IPv6]
Hi Yuhan I am a bit familiar with this change as we tried it in out POC [1] for IPv6 dual-stack. It achieves a similar function, as best as I understand, by allowing multiple external bridges (and, therefore, external interfaces). The feature I am providing here achieves approximately the same thing (explicitly, a dual-stack arrangement) on the *same* interface, thereby requiring only a *single* external bridge (and *single* external interface). I think it just gives more flexibility. We can surely discuss. Thanks for your comments!! Good discussion. Randy [1] http://www.nephos6.com/pdf/OpenStack-Havana-on-IPv6.pdf On Mon, Mar 3, 2014 at 2:33 AM, Xuhan Peng wrote: > Randy, > > I haven't checked the code detail yet, but I have a general question about > this blueprint. Considering multiple external networks on L3 agent is > supported [1]. Do you think it's still necessary to use separate subnets on > one external network for IPv4 and IPv6 instead of using two external > networks? > > [1] https://review.openstack.org/#/c/59359/ > > Thanks! > Xuhan > > > > On Mon, Mar 3, 2014 at 10:47 AM, Randy Tuttle wrote: > >> Hi all. >> >> Just submitted the code[1] for supporting dual-stack (IPv6 and IPv4) on >> an external gateway port of a tenant's router (l3_agent). It implements [2]. >> >> Please, if you would, have a look and provide any feedback. I would be >> grateful. >> >> Cheers, >> Randy >> >> [1]. https://review.openstack.org/#/c/77471/ >> [2]. >> https://blueprints.launchpad.net/neutron/+spec/allow-multiple-subnets-on-gateway-port >> >> ___ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][IPv6] BP:Store both IPv6 LLA and GUA address on router interface port
Hi Yuhan Sorry I am slow to respond, but I was catching up on some emails and found this one from you. Regarding your comments on the RA from the router gateway port... I disagree that the LLA for the qg- interface is (or should be) the gateway for the tenant's subnet. On the contrary, it should be the LLA of the qr- to which the dnsmasq binds [2]. Using [1] as a starting point, packets arriving on the qr- interface are routed across (via linux) in the qrouter-namespace, taking the default route (gateway-ip) as specified in [1] to unknown destinations. In a future release, we may need to consider implementing support for accepting RA from service providers' upstream routers on the qg- interface, but whether we allow a SLAAC address on the external gateway port needs further discussion (perhaps a topic for the IPv6 sub-team IRC). SLAAC requires a /64 subnet which might be considered a bit of overkill for what's typically a point-to-point connection. Let's see about adding it to the topics to discuss. Cheers, Randy [1] https://blueprints.launchpad.net/neutron/+spec/allow-multiple-subnets-on-gateway-port [2] https://blueprints.launchpad.net/neutron/+spec/dnsmasq-bind-into-qrouter-namespace On Thu, Feb 27, 2014 at 12:49 AM, Xuhan Peng wrote: > As the follow up action of IPv6 sub-team meeting [1], I created a new > blueprint [2] to store both IPv6 LLA and GUA address on router interface > port. > > Here is what it's about: > > Based on the two modes (ipv6-ra-mode and ipv6-address-mode) design[3], RA > can be sent from both openstack controlled dnsmasq or existing devices. > > RA From dnsmasq: gateway ip that dnsmasq binds into should be link local > address (LLA) according to [4]. This means we need to pass the LLA of the > created router internal port (i.e. qr-) to dnsmasq spawned by openstack > dhcp agent. In the mean while, we need to assign an GUA to the created > router port so that the traffic from external network can be routed back > using the GUA of the router port as the next hop into the internal subnet. > Therefore, we will need some change to the current logic to leverage both > LLA and GUA on router port. > > RA from existing device on the same link which is not controlled by > openstack: dnsmasq will not send RA in this case. RA is sending from > subnet's gateway address which should also be LLA according to [4]. > Allowing subnet's gateway IP to be LLA is enough in this case. Current code > works when force_gateway_on_subnet = False. > > RA from router gateway port (i.e. qg-): the LLA of the gateway port > (qg-) should be set as the gateway of tenant subnet to get the RA from > that. This could be potentially calculated by [5] or by other methods in > the future considering privacy extension. However, this will make the > tenant network gateway port qr- useless. Therefore, we also need code > change to current router interface attach logic. > If you have any comments on this, please let me know. > > [1] > http://eavesdrop.openstack.org/meetings/neutron_ipv6/2014/neutron_ipv6.2014-02-25-14.02.html > [2] > https://blueprints.launchpad.net/neutron/+spec/ipv6-lla-gua-router-interface > [3] https://blueprints.launchpad.net/neutron/+spec/ipv6-two-attributes > [4] http://tools.ietf.org/html/rfc4861 > [5] https://review.openstack.org/#/c/56184/ > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron][IPv6]
Hi all. Just submitted the code[1] for supporting dual-stack (IPv6 and IPv4) on an external gateway port of a tenant's router (l3_agent). It implements [2]. Please, if you would, have a look and provide any feedback. I would be grateful. Cheers, Randy [1]. https://review.openstack.org/#/c/77471/ [2]. https://blueprints.launchpad.net/neutron/+spec/allow-multiple-subnets-on-gateway-port ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][IPv6] tox error
Clark/Sean/Shixiong... I have the same error, and tried to import neutron.tests.unit.linuxbridge.test_lb_neutron_agent (no error4 prefix). I get the following (py27)rantuttl-mac:bin rtuttle$ python Python 2.7.5 (v2.7.5:ab05e7dd2788, May 13 2013, 13:18:45) [GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import neutron.tests.unit.linuxbridge.test_lb_neutron_agent Traceback (most recent call last): File "", line 1, in File "/Users/rtuttle/projects/neutron/neutron/tests/unit/linuxbridge/test_lb_neutron_agent.py", line 29, in from neutron.plugins.linuxbridge.agent import linuxbridge_neutron_agent File "/Users/rtuttle/projects/neutron/neutron/plugins/linuxbridge/agent/linuxbridge_neutron_agent.py", line 33, in import pyudev ImportError: No module named pyudev >>> Looks like it wants pyudev, which is not anywhere that I can find, and is not in requirements.txt. Code slice. import distutils.version as dist_version import os import platform import sys import time import eventlet from oslo.config import cfg import pyudev from neutron.agent import l2population_rpc as l2pop_rpc from neutron.agent.linux import ip_lib Still digging into it... Randy On Thu, Feb 27, 2014 at 3:10 PM, Clark Boylan wrote: > On Thu, Feb 27, 2014 at 11:39 AM, Collins, Sean > wrote: > > Shixiong Shang and I ran into this problem with Tox today while we were > > pair programming, and I've also seen similar barfs on my DevStack lab > > boxes - it's quite a mess. Frankly I've moved to using nosetests as a > > workaround, and have added it to the developer docs. > > > > We really do need to figure out how to make Tox and Testr give more > > useful failure output - it's so huge it makes my iTerm2 window lock up > > when I try and do an incremental search on the output. > > > > Help from a Testr / Tox guru would be appreciated. > > > > -- > > Sean M. Collins > > ___ > > OpenStack-dev mailing list > > OpenStack-dev@lists.openstack.org > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > These failures are a result of testr or discover (depending on the > step in the test process, discovery happens first) running into python > import failures. In the example above it looks like > neutron.tests.unit. > linuxbridge.test_lb_neutron_agent failed to import. You can spin up a > python interpreter and try importing that to debug (note that is what > you tried to do but I believe errors4 is part of the error message and > not the thing that couldn't be imported). Flake8 may also catch the > problem. Lifeless has laid the groundwork to fix this upstream in > testtools [0], but I don't think the corresponding testrepository > improvements have been released yet. You can however install > testrepository from source [1] and see if that solves your problem. > > Without seeing the code in question it is really hard to debug any > further. If nosetests does work that would indicate a possible > intertest dependency that nose resolves by running tests in a > particular order which is different than the order used by testr. > Finally, when using the python executable from a virtualenv you don't > want to be in the virtualenv's bin dir. To do a proper import test you > want to be in the root dir of the repository `cd ~/github/neutron` the > either activate the virtualenv and run python or skip activation and > do `.tox/py27/bin/python` to run the virtualenv's python binary. > > [0] > https://github.com/testing-cabal/testtools/commit/6da4893939c6fd2d732bb20a4ac50db2fe639132 > [1] https://launchpad.net/testrepository/ > > Hope this helps, > Clark > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][IPv6] tox error
When I see a fox, it is usually running b-( = )) Sent from my iPhone > On Feb 24, 2014, at 6:08 PM, Shixiong Shang > wrote: > > Hi, guys: > > I run into this error while running fox…..but it gave me this error…Seems > like it is related to Neutron LB. Did you see this issue before? If so, how > to fix it? > > Thanks! > > Shixiong > > > shshang@net-ubuntu2:~/github/neutron$ tox -v -e py27 > ……... > tests.unit.test_wsgi.XMLDictSerializerTest.test_xml_with_utf8\xa2\xbe\xf7u\xb3 > `@d\x17text/plain;charset=utf8\rimport > errors4neutron.tests.unit.linuxbridge.test_lb_neutron_agent\x85\xc5\x1a\\', > stderr=None > error: testr failed (3) > ERROR: InvocationError: '/home/shshang/github/neutron/.tox/py27/bin/python -m > neutron.openstack.common.lockutils python setup.py testr --slowest > --testr-args=' > > summary > > ERROR: py27: commands failed > > > (py27)shshang@net-ubuntu2:~/github/neutron/.tox/py27/bin$ python > Python 2.7.5+ (default, Sep 19 2013, 13:48:49) > [GCC 4.8.1] on linux2 > Type "help", "copyright", "credits" or "license" for more information. import errors4neutron.tests.unit.linuxbridge.test_lb_neutron_agent > Traceback (most recent call last): > File "", line 1, in > ImportError: No module named > errors4neutron.tests.unit.linuxbridge.test_lb_neutron_agent > > > > > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] ERROR: InvocationError: when running tox
Thanks guys. Yes, Ben, I can see oslo.config installed in tox sub-directory. I will try to wipe tox out and try again. You are right though, the tox.ini only has site-packages for Jenkins noted. Sean, I think your first email response might be right. I am running on a Mac instead of Ubuntu box. I think, based on my research on this, that the last module (or even a series of them) may not have loaded, and this is proven when I try with import. Here's the thread I've been reading. https://bugs.launchpad.net/nova/+bug/1271097 Cheers On Mon, Feb 24, 2014 at 1:05 PM, Ben Nemec wrote: > On 2014-02-24 09:02, Randy Tuttle wrote: > >Has anyone experienced this issue when running tox. I'm trying to > figure if this is some limit of tox environment or something else. I've > seen this referenced in other projects, but can't seem to zero in on a > proper fix. > > tox -e py27 > > [...8><...snip a lot] > > neutron.tests.unit.test_routerserviceinsertion\nneutron.tests.unit.test_security_groups_rpc\nneutron.tests.unit.test_servicetype=\xc1\xf1\x19', > stderr=None > error: testr failed (3) > ERROR: InvocationError: > '/Users/rtuttle/projects/neutron/.tox/py27/bin/python -m > neutron.openstack.common.lockutils python setup.py testr --slowest > --testr-args=' > __ summary > __ > ERROR: py27: commands failed > > It seems that what it may be complaining about is a missing oslo.config. > If I try to load the final module noted from above (i.e., > neutron.tests.unit.test_servicetype), I get an error about the missing > module. > > Python 2.7.5 (v2.7.5:ab05e7dd2788, May 13 2013, 13:18:45) > [GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import neutron.tests.unit.test_servicetype > Traceback (most recent call last): > File "", line 1, in > File "neutron/tests/unit/__init__.py", line 20, in > from oslo.config import cfg > ImportError: No module named oslo.config > > Cheers, > Randy > > We hit a similar problem in some of the other projects recently, but it > doesn't look like that applies to Neutron because it isn't using > site-packages in its tox runs anyway. The first thing I would check is > whether oslo.config is installed in the py27 tox venv. It might be a good > idea to just wipe your .tox directory and start fresh if you haven't done > that recently. > > -Ben > > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron] ERROR: InvocationError: when running tox
Has anyone experienced this issue when running tox. I'm trying to figure if this is some limit of tox environment or something else. I've seen this referenced in other projects, but can't seem to zero in on a proper fix. tox -e py27 [...8><...snip a lot] neutron.tests.unit.test_routerserviceinsertion\nneutron.tests.unit.test_security_groups_rpc\nneutron.tests.unit.test_servicetype=\xc1\xf1\x19', stderr=None error: testr failed (3) ERROR: InvocationError: '/Users/rtuttle/projects/neutron/.tox/py27/bin/python -m neutron.openstack.common.lockutils python setup.py testr --slowest --testr-args=' __ summary __ ERROR: py27: commands failed It seems that what it may be complaining about is a missing oslo.config. If I try to load the final module noted from above (i.e., neutron.tests.unit.test_servicetype), I get an error about the missing module. Python 2.7.5 (v2.7.5:ab05e7dd2788, May 13 2013, 13:18:45) [GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import neutron.tests.unit.test_servicetype Traceback (most recent call last): File "", line 1, in File "neutron/tests/unit/__init__.py", line 20, in from oslo.config import cfg ImportError: No module named oslo.config Cheers, Randy ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Allow multiple subnets on gateway port for router
-- (rebroadcast to dev community from prior unicast discussion) --
Hi Nir
Sorry if the description is misleading. Didn't want a large title, and
hoped that the description would provide those additional details to
clarify the real goal of what's included and what's not included.
#1. Yes, it's only the gateway port. With that said, there are a series of
BP that are being worked to support the dual-stack use case (although not
necessarily dependent on each other) across Neutron, including internal
ports facing the tenant.
https://blueprints.launchpad.net/neutron/+spec/allow-multiple-subnets-on-gateway-port
https://blueprints.launchpad.net/neutron/+spec/dnsmasq-mode-keyword
https://blueprints.launchpad.net/neutron/+spec/neutronclient-support-dnsmasq-mode-keyword
https://blueprints.launchpad.net/neutron/+spec/dnsmasq-bind-into-qrouter-namespace
https://blueprints.launchpad.net/neutron/+spec/dnsmasq-ipv6-slaac
https://blueprints.launchpad.net/neutron/+spec/dnsmasq-ipv6-dhcpv6-relay-agent
https://blueprints.launchpad.net/neutron/+spec/dnsmasq-ipv6-dhcpv6-stateful
https://blueprints.launchpad.net/neutron/+spec/dnsmasq-ipv6-dhcpv6-stateless
#2. Surely it's possible to have multiple v4 and v6 [global] addresses on
the interface, but for the gateway port, I don't have a specific use case.
To remain consistent with current feature capability (single v4 IP), I
continue to restrict a single IP from each flavor. With that said, there's
nothing technically preventing this. It can be done; however, the CLI and
Horizon would likely need significant changes. Right now, the code is
written such that it explicitly prevents it. As I mentioned before, I
actually had to add code in to disallow multiple addresses of the same
flavor and send back an error to the user. Of course, we can evolve it in
the future if a use-case warrants it.
Thanks
Randy
On Thu, Jan 9, 2014 at 4:16 AM, Nir Yechiel wrote:
> Hi Randy,
>
> I don't have a specific use case. I just wanted to understand the scope
> here as the name of this blueprint ("allow multiple subnets on gateway port
> for router") could be a bit misleading.
>
> Two questions I have though:
>
> 1. Is this talking specifically about the gateway port to the provider's
> next-hop router or relevant for all ports in virtual routers as well?
> 2. There is a fundamental difference between v4 and v6 address assignment.
> With IPv4 I agree that one IP address per port is usually enough (there is
> the concept of secondary IP, but I am not sure it's really common). With
> IPv6 however you can sure have more then one (global) IPv6 on an interface.
> Shouldn't we support this?
>
>
> Thanks,
> Nir
>
> --
> *From: *"Randy Tuttle"
> *To: *"OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> *Cc: *rantu...@cisco.com
> *Sent: *Tuesday, December 31, 2013 6:43:50 PM
> *Subject: *Re: [openstack-dev] [Neutron] Allow multiple subnets on
> gateway port for router
>
>
> Hi Nir
>
> Good question. There's absolutely no reason not to allow more than 2
> subnets, or even 2 of the same IP versions on the gateway port. In fact, in
> our POC we allowed this (or, more specifically, we did not disallow it).
> However, for the gateway port to the provider's next-hop router, we did not
> have a specific use case beyond an IPv4 and an IPv6. Moreover, in Neutron
> today, only a single subnet is allowed per interface (either v4 or v6). So
> all we are doing is opening up the gateway port to support what it does
> today (i.e., v4 or v6) plus allow IPv4 and IPv6 subnets to co-exist on the
> gateway port (and same network/vlan). Our principle use case is to enable
> IPv6 in an existing IPv4 environment.
>
> Do you have a specific use case requiring 2 or more of the same
> IP-versioned subnets on a gateway port?
>
> Thanks
> Randy
>
>
> On Tue, Dec 31, 2013 at 4:59 AM, Nir Yechiel wrote:
>
>> Hi,
>>
>> With regards to
>> https://blueprints.launchpad.net/neutron/+spec/allow-multiple-subnets-on-gateway-port,can
>> you please clarify this statement: "We will disallow more that two
>> subnets, and exclude allowing 2 IPv4 or 2 IPv6 subnets".
>> The use case for dual-stack with one IPv4 and one IPv6 address associated
>> to the same port is clear, but what is the reason to disallow more than two
>> IPv4/IPv6 subnets to a port?
>>
>> Thanks and happy holidays!
>> Nir
>>
>>
>>
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-
Re: [openstack-dev] [Neutron] Allow multiple subnets on gateway port for router
Hi Nir Good question. There's absolutely no reason not to allow more than 2 subnets, or even 2 of the same IP versions on the gateway port. In fact, in our POC we allowed this (or, more specifically, we did not disallow it). However, for the gateway port to the provider's next-hop router, we did not have a specific use case beyond an IPv4 and an IPv6. Moreover, in Neutron today, only a single subnet is allowed per interface (either v4 or v6). So all we are doing is opening up the gateway port to support what it does today (i.e., v4 or v6) plus allow IPv4 and IPv6 subnets to co-exist on the gateway port (and same network/vlan). Our principle use case is to enable IPv6 in an existing IPv4 environment. Do you have a specific use case requiring 2 or more of the same IP-versioned subnets on a gateway port? Thanks Randy On Tue, Dec 31, 2013 at 4:59 AM, Nir Yechiel wrote: > Hi, > > With regards to > https://blueprints.launchpad.net/neutron/+spec/allow-multiple-subnets-on-gateway-port,can > you please clarify this statement: "We will disallow more that two > subnets, and exclude allowing 2 IPv4 or 2 IPv6 subnets". > The use case for dual-stack with one IPv4 and one IPv6 address associated > to the same port is clear, but what is the reason to disallow more than two > IPv4/IPv6 subnets to a port? > > Thanks and happy holidays! > Nir > > > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] packet forwarding
In general, you'd need a router to pass from one VLAN to another, and that is still true in OS. However, for your case where you have a VM running some routing software, it's quite possible (likely) that the iptable rules on the host machine are stopping your VM from forwarding out since the source address of the packet is not that of the guest that it knows about. Randy On Fri, Dec 20, 2013 at 11:50 AM, Abbass MAROUNI < abbass.maro...@virtualscale.fr> wrote: > Hello, > > Is it true that a traffic from one OpenStack virtual network to another > have to pass by an OpenStack router ? (using an OpenVirtual switch as the > L2 ). > > I'm trying ti use a VM as a router between 2 OpenStack virtual networks > but for some reason I'm not able. > > Appreciate any insights, > > > Best regards, > Abbass > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][IPv6] Blueprint Bind dnsmasq in qrouter- namespace
Shixiong, I know you must have a typo in the 3rd paragraph. I think maybe you mean to include the ns- interface in that list. So why not have qg- qr- and ns- interfaces in the same namespace. Am I right? Rnady On Thu, Dec 19, 2013 at 8:31 PM, Shixiong Shang < sparkofwisdom.cl...@gmail.com> wrote: > Hi, Ian: > > The use case brought by Comcast team today during the ipv6 sub-team > meeting actually proved the point I made here, instead of against it. If I > didn’t explain it clearly in my previous email, here it is. > > I was questioning the design with two namespaces and I believe we can use > a SINGLE namespace as the common container to host two services, i.e. DHCP > and ROUTING. If your use case needs DHCP instance, but not ROUTING, then > just launch dnsmasq in THE namespace with qr- interface; If your use case > needs default GW, then add qg- interface in THE namespace. Whether it is > called qdhcp or qrouter, I don’t care. It is just a label. > > People follow the routine to use it, simply because this is what OpenStack > offers. But my question is, why? And why NOT we design the system in the > way that qg- and qr- interface collocate in the same namespace? > > It is because we intentionally separate the service, now the system become > clumsy and less efficient. As you can see in IPv6 cases, we are forced to > deal with two namespaces now. It just doesn’t make any sense. > > Shixiong > > > > > > > On Dec 19, 2013, at 7:27 PM, Ian Wells wrote: > > Per the discussions this evening, we did identify a reason why you might > need a dhcp namespace for v6 - because networks don't actually have to have > routers. It's clear you need an agent in the router namespace for RAs and > another one in the DHCP namespace for when the network's not connected to a > router, though. > > We've not pinned down all the API details yet, but the plan is to > implement an RA agent first, responding to subnets that router is attached > to (which is very close to what Randy and Shixiong have already done). > -- > Ian. > > > On 19 December 2013 14:01, Randy Tuttle wrote: > >> First, dnsmasq is not being "moved". Instead, it's a different instance >> for the attached subnet in the qrouter namespace. If it's not in the >> qrouter namespace, the default gateway (the local router interface) will be >> the interface of qdhcp namespace interface. That will cause blackhole for >> traffic from VM. As you know, routing tables and NAT all occur in qrouter >> namespace. So we want the RA to contain the local interface as default >> gateway in qrouter namespace >> >> Randy >> >> Sent from my iPhone >> >> On Dec 19, 2013, at 4:05 AM, Xuhan Peng wrote: >> >> I am reading through the blueprint created by Randy to bind dnsmasq into >> qrouter- namespace: >> >> >> https://blueprints.launchpad.net/neutron/+spec/dnsmasq-bind-into-qrouter-namespace >> >> I don't think I can follow the reason that we need to change the >> namespace which contains dnsmasq process and the device it listens to from >> qdhcp- to qrouter-. Why the original namespace design conflicts with the >> Router Advertisement sending from dnsmasq for SLAAC? >> >> From the attached POC result link, the reason is stated as: >> >> "Even if the dnsmasq process could send Router Advertisement, the default >> gateway would bind to its own link-local address in the qdhcp- namespace. >> As a result, traffic leaving tenant network will be drawn to DHCP >> interface, instead of gateway port on router. That is not desirable! " >> >> Can Randy or Shixiong explain this more? Thanks! >> >> Xuhan >> >> ___ >> >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> >> ___ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][IPv6] Meeting time - change to 1300 UTC or 1500 UTC?
Any of those times suit me. Sent from my iPhone On Dec 19, 2013, at 5:12 PM, "Collins, Sean" wrote: > Thoughts? I know we have people who are not able to attend at our > current time. > > -- > Sean M. Collins > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][IPv6] Blueprint Bind dnsmasq in qrouter- namespace
First, dnsmasq is not being "moved". Instead, it's a different instance for the attached subnet in the qrouter namespace. If it's not in the qrouter namespace, the default gateway (the local router interface) will be the interface of qdhcp namespace interface. That will cause blackhole for traffic from VM. As you know, routing tables and NAT all occur in qrouter namespace. So we want the RA to contain the local interface as default gateway in qrouter namespace Randy Sent from my iPhone On Dec 19, 2013, at 4:05 AM, Xuhan Peng wrote: > I am reading through the blueprint created by Randy to bind dnsmasq into > qrouter- namespace: > > https://blueprints.launchpad.net/neutron/+spec/dnsmasq-bind-into-qrouter-namespace > > I don't think I can follow the reason that we need to change the namespace > which contains dnsmasq process and the device it listens to from qdhcp- to > qrouter-. Why the original namespace design conflicts with the Router > Advertisement sending from dnsmasq for SLAAC? > > From the attached POC result link, the reason is stated as: > > "Even if the dnsmasq process could send Router Advertisement, the default > gateway would bind to its own link-local address in the qdhcp- namespace. As > a result, traffic leaving tenant network will be drawn to DHCP interface, > instead of gateway port on router. That is not desirable! " > > Can Randy or Shixiong explain this more? Thanks! > > Xuhan > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][IPv6] Three SLAAC and DHCPv6 related blueprints
Great Shixiong. I can see that we have BPs from Sean / Da Zhao for providing the modes via the neutron client cli, but have we seen how those modes are provided through the dashboard? Randy Sent from my iPhone On Dec 17, 2013, at 9:07 PM, Shixiong Shang wrote: > Hi, team: > > I created a new blueprint to reflect the work we accomplished in the previous > POC to enable dnsmasq in SLAAC mode. In addition, I took the action item two > weeks ago from weekly sub-team meeting to explore DHCPv6 options. The goal > was to run dnsmasq as DHCPv6 server and provide both optional information > and/or IPv6 address to VM in the tenant network. Below you can find the link > to the new blueprints, which are all related to the mid-term goal in Sean’s > original proposal. > > https://blueprints.launchpad.net/neutron/+spec/dnsmasq-ipv6-slaac > https://blueprints.launchpad.net/neutron/+spec/dnsmasq-ipv6-dhcpv6-stateful > https://blueprints.launchpad.net/neutron/+spec/dnsmasq-ipv6-dhcpv6-stateless > > Please let me know if you have any questions. Thanks! > > Shixiong > > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
