[openstack-dev] [qa] [neutron] check-grenade-dsvm-neutron failure due to javelin/floating-ip
Hi everyone, I wrote a patch in Javelin which aims to support floating IPs [1] testing, so we can also validate external network connectivity during an upgrade with Grenade. I also wanted this feature to be able to run Javelin in multi-node environment. For some reasons, my patch passed Jenkins, has been reviewed and merged. Unfortunately, it broke devstack and Neutron gate which both run check-grenade-dsvm-neutron job. Armando sent a first patch [2] and I sent 2 patches [3] to fix it; one of them is not merged, please have a look. It's obvious we miss unit testing here, but I would also suggest to run check-grenade-dsvm-neutron job in tempest jobs [4]. I also wanted to apologize for my mistakes in this patch. [1] https://review.openstack.org/#/c/163622/ (merged) [2] https://review.openstack.org/#/c/164388/ (merged) [3] https://review.openstack.org/#/c/164436/ (merged) and https://review.openstack.org/#/c/164464/ (not merged yet) [4] https://review.openstack.org/#/c/164451/ -- Emilien Macchi signature.asc Description: OpenPGP digital signature __ 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] [neutron] Generic question about synchronizing neutron agent on compute node with DB
Hello Rossella, I meant to something different, to less conventional changes. Right now, the network topology state is stored in neutron DB and each compute node knows about it by using neutron API per-request. Node knows means that neutron agents have this data stored in in-memory structures. In a case this synchronization is broken due a bug in software or (un)intentional change in neutron DB, I'd like to understand if the re-synchronization is possible. Right now, I know that L3 agent (I'm not sure if its working for all L3 agents) has periodic task that refreshes NIC information from neutron server. However, L2 agents don't have this mechanic. I don't know about agents that implement SDN. So, I'm looking to learn how the current neutron implementation deals with that problem. On Fri, Mar 13, 2015 at 10:52 AM, Rossella Sblendido rsblend...@suse.com wrote: On 03/07/2015 01:10 PM, Leo Y wrote: What happens when neutron DB is updated to change network settings (e.g. via Dashboard or manually) when there are communication sessions opened in compute nodes. Does it influence those sessions? When the update is propagated to compute nodes? Hi Leo, when you say change network settings I think you mean a change in the security group, is my assumption correct? In that case the Neutron server will notify all the L2 agent (they reside on each compute node) about the change. There are different kind of messages that the Neutron server sends depending on the type of the update, security_groups_rule_updated, security_groups_member_updated, security_groups_provider_updated. Each L2 agent will process the message and apply the required modification on the host. In the default implementation we use iptables to implement security group, so the update consists in some modifications of the iptables rules. Regarding the existing connections in the compute nodes they might not be affected by the change, which is a problem already discussed in this mail thread [1] and there's a patch in review to fix that [2]. Hope that answers your question. cheers, Rossella [1] http://lists.openstack.org/pipermail/openstack-dev/2014-October/049055.html [2] https://review.openstack.org/#/c/147713/ On 03/13/2015 04:10 AM, Kevin Benton wrote: Yeah, I was making a bad assumption for the l2 and l3. Sorry about that. It sounds like we don't have any protection against servers failing to send notifications. On Mar 12, 2015 7:41 PM, Assaf Muller amul...@redhat.com mailto:amul...@redhat.com wrote: - Original Message - However, I briefly looked through the L2 agent code and didn't see a periodic task to resync the port information to protect from a neutron server that failed to send a notification because it crashed or lost its amqp connection. The L3 agent has a period sync routers task that helps in this regard. The L3 agent periodic sync is only if the full_sync flag was turned on, which is a result of an error. Maybe another neutron developer more familiar with the L2 agent can chime in here if I'm missing anything. i don't think you are missing anything. periodic sync would be a good improvement. YAMAMAOTO Takashi __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://openstack-dev-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Regards, Leo - I enjoy the massacre of ads. This sentence will slaughter ads without a messy bloodbath __ OpenStack Development Mailing List (not for
Re: [openstack-dev] [neutron] Generic question about synchronizing neutron agent on compute node with DB
Hello, I'm using ovs agents with L2 population mechanism in ML2 plugin. I noticed that sometimes agents don't receive proper RPC to add new vxlan tunnel openflow rules and then vxlan network between some compute nodes not working. I'm now using still havana release but want to upgrade to Juno. I was checking Juno code in l2 population mech driver and ovs plugin and I didn't find anything like periodic check if openflow rules are proper set or maybe resynced. Maybe it would be also good idea to add something like that to ovs agent? -- Pozdrawiam / Best regards Sławek Kapłoński sla...@kaplonski.pl Dnia piątek, 13 marca 2015 11:18:28 YAMAMOTO Takashi pisze: However, I briefly looked through the L2 agent code and didn't see a periodic task to resync the port information to protect from a neutron server that failed to send a notification because it crashed or lost its amqp connection. The L3 agent has a period sync routers task that helps in this regard. Maybe another neutron developer more familiar with the L2 agent can chime in here if I'm missing anything. i don't think you are missing anything. periodic sync would be a good improvement. YAMAMAOTO Takashi __ 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 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] IPAM reference driver status and other stuff
Here is an update from our discussion this morning in IRC [1]. The discussion involved mainly Pavel, Salvatore, and me. We first discussed testing the integration of Salvatore's work [2] on the reference driver with Pavel's work to load a driver [3] and refactor the db_base_plugin [4]. Pavel will continue the integration efforts which he has already begun. The final patch [4] makes the reference driver the default IPAM in Neutron so that it is being run in the check queue. At some point before this patch merges, that will be moved to a new patch so that merging this patch will not make the new IPAM driver the default in Neutron. Pavel's final patch [4] will merge when the tests pass with the driver as default. We hope to hit this point soon. At that point, we will create a non-voting job to run the new IPAM driver as default on all new patches. This will give us many more test runs to work out bugs for the Kilo release and will help us to gauge the eventual readiness of the new driver to become the default IPAM in Neutron. This latter step will not happen until the Liberty time frame. In Kilo, the new IPAM driver will only support greenfield deployments and will not support using multiple drivers simultaneously. There will be no migration from the old to the new until Liberty. However, a migration plan is required in order to eventually deprecate and remove the baked-in IPAM solution. We will continue to evaluate use cases around using multiple drivers in the same deployment (e.g. ability to set the driver per subnet or support some sort of flavors). At the point that the non-voting check job is stable, it will be moved to voting. When the new driver graduates to be the default driver in Neutron, the separate gate check job will no longer be necessary and will be removed. Please let me know if I left out any significant detail. Carl [1]http://eavesdrop.openstack.org/irclogs/%23openstack-neutron/%23openstack-neutron.2015-03-13.log at 2015-03-13T15:08:15 [2] https://review.openstack.org/#/c/150485/ [3] https://review.openstack.org/#/c/147479/ [4] https://review.openstack.org/#/c/153236/ On Mon, Mar 9, 2015 at 4:44 AM, Salvatore Orlando sorla...@nicira.com wrote: Aloha everybody! This is another long email, so here's the summary for people with 5-minute or less attention span: The IPAM reference driver is almost ready [1]. Unfortunately letting the driver doing allocation pools required a few major changes, so the latest patchset is rather big. I would like reviewers to advice on how they prefer to split it out in multiple patches. I also had to add an additional method to the subnet interface [2] However, I am not sure we are doing the right thing wrt the introduction of the driver. I think we might need to think about it more thoroughly, and possibly introduce a concept of allocator. Otherwise if we switch an existing deployment to the driver, it's very likely things will just break. So here's the detailed part. There are only a few bits needed to complete the IPAM reference driver: - A thorough unit test case for the newly introduced subnet manager, which provides db apis. - Some more unit tests for driver behaviour - Logic for handling allocation pools update (which pretty much needs to be copied over from db base plugin with minor changes) - Rework the synchronisation between the ipam object and the neutron db object. The current one is very error prone. While dealing with management of allocation pools, I found out that it's not convenient for the IPAM driver to rely on Neutron's DB allocation pools. This is a bit of a chicken and egg problem, since: A) Neutron needs to call the driver to define allocation pools B) The driver needs neutron to define allocation pools before creating availability ranges C) Neutron cannot create allocation pools if the driver has not defined them I therefore decided, reluctantly, to add more data duplication - introducing IPAM tables for allocation pools and availability ranges. The latter is meant to replace Neutron's one when the IPAM driver is enabled, whereas the former is pure data duplication. There is also an association table between neutron subnets and ipam objects for the same subnet; I decided to do so to not do further duplication. I dislike this data separation; on the other hand the only viable alternative would be to give the IPAM driver full control over neutron's database tables for IP Allocation and Subnet allocation pools. While this is feasible, I think it would be even worse to give code which can potentially be 3rd party control over data structures used by the Neutron API. As a result, the patch is different and larger. I would like to split it to make it simpler to review, but rather than just doing that of my own accord I would like to ask reviewers how they would prefer to have it split. At the end of the day I'm not the one who has to spend a lot of time reviewing that code.
