- openstack-discuss - lists.openstack.org

[neutron] [dev] ml2plugin doesn't use new security group rpc api
by Just FooBar 19 Mar '19

19 Mar '19

Hello everyone, I'm having problems with Security Group Rule updates not being applied to vms on hypervisors and I think I know why this is happening. I see that there's already a bug about that: https://bugs.launchpad.net/neutron/+bug/1814209 but there isn't much action going on there. In my case, neutron-server is also using the queue q-agent-notifier-security_group-update (as seen from neutron-server logs in debug mode). The neutron version is the same, 12.0.4. I went to check the code for my version 12.0.4 and I've found some suspicious part which might be the cause of this bug. Let me explain my understanding of the situation. I started with ovs agent code and found that it is using SecurityGroupServerAPIShim ( https://github.com/openstack/neutron/blob/12.0.4/neutron/plugins/ml2/driver…) class for, well, Security Group RPC. Comments in this class definition ( https://github.com/openstack/neutron/blob/12.0.4/neutron/api/rpc/handlers/s…) explain that it is a replacement for an older interface, SecurityGroupServerRpcApi ( https://github.com/openstack/neutron/blob/12.0.4/neutron/api/rpc/handlers/s… ). SecurityGroupServerAPIShim inherits from SecurityGroupInfoAPIMixin ( https://github.com/openstack/neutron/blob/12.0.4/neutron/db/securitygroups_…) which is also a parent of the server side Ml2Plugin ( https://github.com/openstack/neutron/blob/12.0.4/neutron/plugins/ml2/plugin…) >From this I make a conclusion that Ml2Plugin was also switched to the new SG RPC interface. Now, there are other details that suggest that Ml2Plugin wasn't switched to the new interface entirely and continues to use the old-style SG RPC classes. There's a class AgentNotifierApi ( https://github.com/openstack/neutron/blob/12.0.4/neutron/plugins/ml2/rpc.py…) used by neutron-server's Ml2Plugin ( https://github.com/openstack/neutron/blob/12.0.4/neutron/plugins/ml2/plugin…) to send notifications (to agents, I suppose). It inherits from the class SecurityGroupAgentRpcApiMixin ( https://github.com/openstack/neutron/blob/12.0.4/neutron/api/rpc/handlers/s…) which has been marked for removal starting from Pike 3 years ago in this commit: https://github.com/openstack/neutron/commit/97338258967d3b95f382f188ab2ab57…. This AgentNotifierApi class wasn't switched to a new Shim RPC interface for SG (as it was done for the ovs agent and Ml2Plugin itself). All previous links are for 12.0.4 version, the one used in my system currently. And here's the same class AgentNotifierApi from the Rocky release: https://github.com/openstack/neutron/blob/stable/rocky/neutron/plugins/ml2/… . As you can see, it still inherits from the class marked for removal and isn't using new style SG RPC API. >From all this I conclude that until AgentNotifierApi is using new style API or the way that Ml2Plugin is sending notifications isn't changed, the bug will still be present. Please let me know if I'm getting this wrong. If I'm right, I'm interested in helping to fix the bug. Thank you for your attention!

3 4

[neutron] Bug deputy report (2019-03-11 week)
by Takashi Yamamoto 19 Mar '19

19 Mar '19

This week was not too busy and LIU was quicker to triage bugs than I was. So I looked at some older bugs (mostly from the last week) as well. The following is the list of bugs I observed. High https://bugs.launchpad.net/neutron/+bug/1819477 [OVS] When cleaning min QoS, queue could be already deleted https://bugs.launchpad.net/neutron/+bug/1820744 conntrack v1.4.4 (conntrack-tools): `0' unsupported protocol Medium https://bugs.launchpad.net/neutron/+bug/1819897 Intermittent "Neutron did not start" failures in the gate https://bugs.launchpad.net/neutron/+bug/1818651 UnsupportedVersion: Endpoint does not support RPC version 1.2. Attempted method: report_state Low https://bugs.launchpad.net/neutron/+bug/1819591 Fwaas-v2 not fully suport "source_firewall_group_id" for creation of firewall_rule https://bugs.launchpad.net/neutron/+bug/1818824 When a fip is added to a vm with dvr, previous connections loss the connectivity https://bugs.launchpad.net/neutron/+bug/1818805 Conntrack rules in the qrouter are not deleted when a fip is removed with dvr https://bugs.launchpad.net/neutron/+bug/1820297 os-ken error when BGP peer goes down Incomplete https://bugs.launchpad.net/neutron/+bug/1818960 IPv6 not working with iptables https://bugs.launchpad.net/neutron/+bug/1818697 neutron fullstack frequently times out waiting on qos ports https://bugs.launchpad.net/neutron/+bug/1818696 frequent ci failures trying to delete qos port

1 0

[tc] weekly update
by Mohammed Naser 19 Mar '19

19 Mar '19

Hi everyone! Thanks fo reading this, if you are :) This is a weekly email update on the current state of the TC. Over the last week, there hasn't been much activity over the governance repository other than a change we merged today to declare the Train supported runtimes for Python and Golang, this has officially been published here: https://governance.openstack.org/tc/reference/runtimes/train.html There was a few emails that were sent out by Zane with regards on how we're going to go about this, the versions we're going to use for testing, etc. Ghanshyam also worked alongside the infrastructure team to get our CI jobs to move to bionic to help with the Python 3 bits as well: http://lists.openstack.org/pipermail/openstack-discuss/2019-March/003610.ht… http://lists.openstack.org/pipermail/openstack-discuss/2019-March/003584.ht… Other than that, we've started working a document to provide feedback for the board regarding the upcoming confirmation of OIPs, the effort in setting up the etherpads and reaching out was started by Jeremy: http://lists.openstack.org/pipermail/openstack-discuss/2019-March/003938.ht… We also have a few on-going discussions with the introduction of OpenDev, however those are still very early discussions. Jim is the point of contact of the OpenStack community within the transition process so he's provided some questions to be answered from our community: http://lists.openstack.org/pipermail/openstack-discuss/2019-March/003943.ht… The process to get grab our goals is also about to wrap up, we have an upcoming few office hours and we're trying to pick the best one to find to discuss the upcoming cycle goals, please join if you're interested! http://lists.openstack.org/pipermail/openstack-discuss/2019-March/003932.ht… We've got our space at the PTG setup for us for all Saturday thanks to the foundation, we're getting the Etherpads slowly up and going and I think it would be great to solicit subjects for discussion in the PTG that involve the community as well: http://lists.openstack.org/pipermail/openstack-discuss/2019-March/003916.ht… With the summit comes a joint leadership meeting, we are looking for subjects to bring up to the board, so please chime in there if that interests you: http://lists.openstack.org/pipermail/openstack-discuss/2019-March/003810.ht… Finally, I hope you forgive my long email. I'm trying different formats to make it more digestable and/or consumable and/or interesting. If you have feedback on those emails, positive or negative, please send them out (feel free to do that personally) so that we can make those updates more meaningful to our community. Thanks, Mohammed

1 0

[ironic][neutron] nf_conntrack_helper now disabled by default
by Derek Higgins 18 Mar '19

18 Mar '19

Hi All, Shortly before the holidays CI jobs moved from xenial to bionic, for Ironic this meant a bunch failures[1], all have now been dealt with, with the exception of the UEFI job. It turns out that during this job our (virtual) baremetal nodes use tftp to download a ipxe image. In order to track these tftp connections we have been making use of the fact that nf_conntrack_helper has been enabled by default. In newer kernel versions[2] this is no longer the case and I'm now trying to figure out the best way to deal with the new behaviour. I've put together some possible solutions along with some details on why they are not ideal and would appreciate some opinions 1. Why not enable the conntrack helper with echo 1 > /proc/sys/net/netfilter/nf_conntrack_helper The router namespace is still created with nf_conntrack_helper==0 as it follows the default the nf_conntrack module was loaded with 2. Enable it in modprobe.d # cat /etc/modprobe.d/conntrack.conf options nf_conntrack nf_conntrack_helper=1 This works but requires the nf_conntrack module to be unloaded if it has already been loaded, for devstack and I guess in the majority of cases (including CI nodes) this means a reboot stage or a potentially error prone sequence of stopping the firewall and unloading nf_conntrack modules. This also globally turns on the helper on the host reintroducing the security concerns it comes with 3. Enable the contrack helper in the router network namespace when it is created[3] This works for ironic CI, but there may be better solutions that can be worked within neutron that I'm not aware of. Of the 3 options above this would be most transparent to other operators as the original behaviour would be maintained. thoughts on any of the above? or better solutions? 1 - https://storyboard.openstack.org/#!/story/2004604 2 - https://kernel.googlesource.com/pub/scm/linux/kernel/git/horms/ipvs-next/+/… 3 - https://review.openstack.org/#/c/628493/1

6 10

[nova][openstack-charms] One day until PTL elections end
by Jeremy Stanley 18 Mar '19

18 Mar '19

Hello Nova, OpenStack_Charms contributors, Just a quick reminder that elections are closing soon, if you haven't already you should use your right to vote and pick your favourite candidate! You have until Mar 19, 2019 23:45 UTC. Thanks for your time! -- Jeremy Stanley

2 1

senlin 7.0.0.0rc1 (stein)
by no-reply＠openstack.org 18 Mar '19

18 Mar '19

Hello everyone, A new release candidate for senlin for the end of the Stein cycle is available! You can find the source code tarball at: https://tarballs.openstack.org/senlin/ Unless release-critical issues are found that warrant a release candidate respin, this candidate will be formally released as the final Stein release. You are therefore strongly encouraged to test and validate this tarball! Alternatively, you can directly test the stable/stein release branch at: https://git.openstack.org/cgit/openstack/senlin/log/?h=stable/stein Release notes for senlin can be found at: https://docs.openstack.org/releasenotes/senlin/ If you find an issue that could be considered release-critical, please file it at: https://bugs.launchpad.net/senlin-tempest-plugin and tag it *stein-rc-potential* to bring it to the senlin release crew's attention.

1 0

[ptl][release]Cycle Highlights Reminder-- Due This Week
by Kendall Nelson 18 Mar '19

18 Mar '19

Hello! Friendly reminder that cycle-highlights are due with your rc1. I realize there was a mix up with the stein schedule saying that they were due with your final rc's so there is a patch out to fix that now and I figured an email reminder couldn't hurt either way :) cycle-highlights are important because they are what the Foundation Marketing team (as well as other journalists,marketing folks, and industry outside the Foundation) processes into the press release that they will do for the Stein release. If you have any questions feel free to ask in the #openstack-release channel and we will be able to help you. There's also documentation here[1] that shows how they should be formatted. -Kendall Nelson (diablo_rojo) [1]https://docs.openstack.org/project-team-guide/release-management.html

1 0

[nova][dev] Train PTG etherpad available
by melanie witt 18 Mar '19

18 Mar '19

Hey all, We have an etherpad going for the Train PTG located here: https://etherpad.openstack.org/p/nova-ptg-train Please add topics you'd like to discuss in-person at the PTG, along with your IRC nick, to the topic list. If you're unable to attend the PTG but have a topic you'd like feedback about, you can add it with a note that you're unable to attend, and we can take notes on the etherpad for you to review after we go over the topic. Cheers, -melanie

1 0

[os-brick] Fix multipathd support when 'find_multipaths' is set to 'yes'
by Sahid Orentino Ferdjaoui 18 Mar '19

18 Mar '19

There is an issue in os-brick related to multipath support for iSCSI connector. Basically when multipathd is configured with feature 'find_multipaths' set to 'yes' #1815844 [0]. In this situation, multipathd automatically generate multipath device when it discovers: - There are at least two non-blacklisted paths with the same WWID. - The user manually forces the creation of the device by specifying a device with the multipath command. - A path has the same WWID as a multipath device that was previously created (even if that multipath device does not currently exist). Whenever a multipath device is created, multipath remembers the WWID of the device so that it will automatically create the device again as soon as it sees a path with that WWID. This situation happens as described in bug #1815844 [0] when we attach a volume, detach it and then re-attach it again. openstack volume create pure2 --size 10 --type pure openstack server add volume T1 pure2 openstack server remove volume T1 pure2 openstack server add volume T1 pure2 A patch has been proposed to fix the support [1]. Since we have workaround when 'find_multipaths' is set to 'no'. The question is: do we want to fix it? If not, I suggest to document it, that this feature from multipathd should be disabled. Probably a side-note in the config option 'volume_use_multipath' can help. We could also add a log warning in os-brick when we detect the issue. Thanks, s. [0] https://bugs.launchpad.net/charm-nova-compute/+bug/1815844 [1] https://review.openstack.org/#/c/638639/ [2] https://docs.openstack.org/nova/rocky/configuration/config.html#libvirt.vol…

2 1

[openstack-ansible] updating cores
by Mohammed Naser 18 Mar '19

18 Mar '19

Hi everyone, I wanted to thank the following cores for their service to the project, however, they don't seem to be active anymore and therefore I'd like to propose to remove them. However, should they decide to come back to the project, we'd be happy to fast track them in: - Alexandra Settle - Andy McCrae - Jimmy McCrory - Major Hayden - Robb Romans I'd like to propose to add Guilherme Steinmuller for core, he has done quite a lot of code reviews recently, worked on helping fix our upgrade jobs, did the initial work to help add placement and integrate Mistral into OpenStack Ansible. https://review.openstack.org/#/q/reviewedby:%22Guilherme++Steinmuller+Pimen… With the recent shrink of the OpenStack Ansible team, he'll help increase the bandwidth of getting code merged. Thanks, Mohammed -- Mohammed Naser — vexxhost ----------------------------------------------------- D. 514-316-8872 D. 800-910-1726 ext. 200 E. mnaser(a)vexxhost.com W. http://vexxhost.com

8 8