- openstack-discuss - lists.openstack.org

[k8s] K8s-SIG-OpenStack Update
by Chris Hoge 10 Dec '18

10 Dec '18

Hi everyone, a quick update on SIG-OpenStack/K8s as we head into KubeCon. To start with, today David and I are at the contributors summit and will be available to catch up on any topics you're interested in personally. The only other event we have scheduled for KubeCon is the SIG Intro session[1], Tuesday at 2:35 PM in room 3A/B. Given the smaller turnout for the deep-dive session in Copenhagen, we opted to skip the deep dive session this time around. As such, the first half of the intro will serve as the official SIG-Update, then we will reserve the end of the time for collaboration and planning. If you're involved or interested in SIG-OpenStack at all, please be sure to make this session. Following up from the OpenStack Summit, we had a productive planning session and set a number of goals and tasks[2]. Top at the list is the rotation of the SIG leadership. We're currently accepting nominations to replace David Lyle and Robert Morse. Many thanks to both for serving this last year. Currently we have nominations for * Flavio Percoco * Melvin Hillsman If you would like to be considered for SIG leadership, or would like to nominate someone, please do so in this thread or personally to me. Another item on the agenda is the rebooting of the SIG-OpenStack/K8s meetings. We will return the previously scheduled time of Wednesdays at 4 PM PT, starting January 9. I'll be sending out agendas and reminders as we get closer to the date, and will be asking some sub-project owners to attend and contribute updates. Work on the cloud provider and associated code has been moving well, and the external provider has moved well beyond the capabilities of the now-deprecated in-tree provider. If you haven't started your migration plan off of the in-tree code, please start doing so now. We're targeting full removal in 2019. The OpenStack provider for the new Cluster API has started, and we are looking for more developers to get involved. This, and a possible Ironic provider, are important for the SIG to be involved with in the coming year. If SIG-Cluster-Lifecycle reaches its goals, the Cluster API will be one of the most valuable developments for operators and users in 2019. Finally, I continue to engage with SIG-Cloud-Provider as a co-lead to advocate for consistent provider development. One of the original goals was to wind down all provider SIGS. However, as the SIGs move beyond just provider code to larger support of a user and developer community, this plan is being reconsidered. I'll keep you updated on the developments. Thanks to everyone for your ongoing contributions, and I'm looking forward to seeing the folks who are attending KubeCon in Seattle. -Chris [1] Intro OpenStack SIG: https://sched.co/Grbk [2] SIG-K8s Berlin Summit Session: https://etherpad.openstack.org/p/sig-k8s-2018-berlin-summit

1 0

Re: [openstack-dev] [nova][cinder][qa] Should we enable multiattach in tempest-full?
by Ghanshyam Mann 10 Dec '18

10 Dec '18

---- On Tue, 02 Oct 2018 00:28:51 +0900 Matt Riedemann <mriedemos(a)gmail.com> wrote ---- > On 10/1/2018 8:37 AM, Ghanshyam Mann wrote: > > +1 on adding multiattach on integrated job. It is always good to cover more features in integrate-gate instead of separate jobs. These tests does not take much time, it should be ok to add in tempest-full [1]. We should make only really slow test as 'slow' otherwise it should be fine to run in tempest-full. > > > > I thought adding tempest-slow on cinder was merged but it is not[2] > > > > [1]http://logs.openstack.org/80/606880/2/check/nova-multiattach/7f8681e/job-… > > [2]https://review.openstack.org/#/c/591354/2 > > Actually it will be enabled in both tempest-full and tempest-slow, > because there is also a multiattach test marked as 'slow': > TestMultiAttachVolumeSwap. > > I'll push patches today. While reviewing your patch and checking multiattach slow test on stable branch as part of tempest-slow job, I found that tempest-slow (tempest-multinode-full) job does not run on nova stable branches (even nova .zuul.yaml has that job to run for stable branch) which we can say bug on Tempest side because tempest-slow job definition is to run only on master [1]. I am trying to enable that for all stable branches[2]. I am getting few failure on tempest-slow (tempest-multinode-full) for stable branches which might take time to fix and till then let's keep nova-multiattach on stable branches and remove only for master. [1] https://github.com/openstack/tempest/blob/a32467c4c515dff325e6b4b5ce7af24a0… [2] https://review.openstack.org/#/q/topic:tempest-multinode-slow-stable+(statu… -gmann > > -- > > Thanks, > > Matt > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >

2 2

Openstacl magnum Queens api error
by Ignazio Cassano 10 Dec '18

10 Dec '18

Hi All, I installed magnum in queens with Centos 7 and I am facing with the same issue descrive here: https://bugs.launchpad.net/magnum/+bug/1701381 Please, anyone solved it? Regards Ignazio

1 1

[charms] No meetings until January 7th
by Frode Nordahl 10 Dec '18

10 Dec '18

Dear charmers and community at large, We will be taking a break from our weekly meetings and will reconvene after the holidays. First weekly meeting will be Monday January 7th. In the meantime, do not hesitate to contact us in #openstack-charmers on Freenode or by sending e-mail to the OpenStack Discuss mailinglist using the [charms] tag in the subject line. Cheers all! -- Frode Nordahl

2 1

[openstack-dev] [Neutron] Propose Hongbin Lu for Neutron core
by Miguel Lavalle 10 Dec '18

10 Dec '18

Hi Stackers, I want to nominate Hongbin Lu (irc: hongbin) as a member of the Neutron core team. Hongbin started contributing to the OpenStack community in the Liberty cycle. Over time, he made great contributions in helping the community to better support containers by being core team member and / or PTL in projects such as Zun and Magnum. An then, fortune played in our favor and Hongbin joined the Neutron team in the Queens cycle. Since then, he has made great contributions such as filters validation in the ReST API, PF status propagation to to VFs (ports) in SR-IOV environments and leading the forking of RYU into the os-ken OpenStack project, which provides key foundational functionality for openflow. He is not a man who wastes words, but when he speaks up, his opinions are full of insight. This is reflected in the quality of his code reviews, which in number are on par with the leading members of the core team: http://stackalytics.com/?module=neutron-group. Even though Hongbin leaves in Toronto, he speaks Mandarin Chinese and was born and raised in China. This is a big asset in helping the Neutron team to incorporate use cases from that part of the world. Hongbin spent the past few months being mentored by Slawek Kaplonski, who has reported that Hongbin is ready for the challenge of being a core team member. I (and other core team members) concur. I will keep this nomination open for a week as customary. Thank you Miguel

5 6

[openstack-dev] [Neutron] Propose Nate Johnston for Neutron core
by Miguel Lavalle 10 Dec '18

10 Dec '18

Hi Stackers, I want to nominate Nate Johnston (irc:njohnston) as a member of the Neutron core team. Nate started contributing to Neutron back in the Liberty cycle. One of the highlight contributions of that early period is his collaboration with others to implement DSCP QoS rules ( https://review.openstack.org/#/c/251738/) After a hiatus of a few cycles, we were lucky to have Nate come back to the community during the Rocky cycle. Since then, he has been a driving force in the adoption in Neutron of Oslo Versioned Objects, the "Run under Python 3 by default" community wide initiative and the optimization of ports creation in bulk to better support containerized workloads. He is a man with a wide range of interests, who is not afraid of expressing his opinions in any of them. The quality and number of his code reviews during the Stein cycle is on par with the leading members of the core team: http://stackalytics.com/?module=neutron-group. I especially admire his ability to forcefully handle disagreement in a friendly and easy going manner. On top of all that, he graciously endured me as his mentor over the past few months. For all these reasons, I think he is ready to join the team and we will be very lucky to have him as a fully voting core. I will keep this nomination open for a week as customary. Thank you Miguel

4 4

[ironic] Meetings cancelled for the holdiays, Resuming January 7th
by Julia Kreger 10 Dec '18

10 Dec '18

Greetings ironic folks and all of those interested in ironic! As discussed in this week's meeting[1], we are cancelling our next three meetings and resuming our weekly meeting on January 7th. This time of year, the ironic community tends to enter a bit of a quiet period. Starting next week, contributor availability will begin to wind down for the holidays. Those of us that will be hanging around tend to shift gears to focused feature work and often pay a little less attention to IRC and the mailing list. If core reviewers are needed, the `ironic-cores` tag can be used in the #openstack-ironic channel, and we will do our best to marshal reviewers in the event of an emergency. During this time, our weekly priority review list[1] will go into autopilot. Contributors are welcome to add items they feel need review visibility and we will prune merged items out as needed. If there are any questions, please feel free to reach out to me or post to the mailing list. Thanks, -Julia [1] http://eavesdrop.openstack.org/meetings/ironic/2018/ironic.2018-12-10-15.00… [2] https://etherpad.openstack.org/p/IronicWhiteBoard starting at line 112.

1 0

Re: [Release-job-failures] Tag of openstack/freezer failed
by Tony Breeds 10 Dec '18

10 Dec '18

On Mon, Dec 10, 2018 at 04:49:47AM +0000, zuul(a)openstack.org wrote: > Build failed. > > - publish-openstack-releasenotes-python3 http://logs.openstack.org/31/31314e5e707bfe4933e1046dd0a18f1daa8cca6c/tag/p… : POST_FAILURE in 2m 31s Looking at the logs I think this failed in create-afs-token[1]. If I Understand correctly this means the releasenotes weren't published but they will upon the next successful publish run. Yours Tony. [1] http://logs.openstack.org/31/31314e5e707bfe4933e1046dd0a18f1daa8cca6c/tag/p…

3 2

[nova] Fail to detach vhostuser vif type from VM
by Arches, Maria (Nokia - HU/Budapest) 10 Dec '18

10 Dec '18

Hello all, I tried to detach a vhostuser vif from VM. My network setup is neutron+ ovs dpdk and using Libvirt/KVM. I'm using Openstack Queens. Network interface was unplugged but was not removed from libvirt/VM. I also created a bug for this in Launchpad. Wrote here to find/discuss possible solutions. https://bugs.launchpad.net/nova/+bug/1807340 I got the following logs from nova-compute: 2018-12-10 12:29:49.008 3223 INFO os_vif [req-ffd43a33-b0b9-4b4d-a7ce-700b7aee2822 7f6d35b7b85042daa470658debca14c3 b8668325f4fa4b9085fd2ac43170dd42 - default default] Successfully unplugged vif VIFVHostUser(active=True,address=fa:16:3e:ca:4e:16,has_traffic_filtering=False,id=90ca01ab-9a43-4d5f-b0bd-cb334d07e22b,mode='server',network=Network(e108697b-f031-45cb-bf47-6031c69afd4b),path='/var/run/openvswitch/vhu90ca01ab-9a',plugin='ovs',port_profile=VIFPortProfileOpenVSwitch,preserve_on_delete=False,vif_name='vhu90ca01ab-9a') 2018-12-10 12:29:49.011 3223 WARNING nova.virt.libvirt.driver [req-ffd43a33-b0b9-4b4d-a7ce-700b7aee2822 7f6d35b7b85042daa470658debca14c3 b8668325f4fa4b9085fd2ac43170dd42 - default default] [instance: a4dd7fb5-d234-4b2a-9ebd-b1e3f657ac3e] Detaching interface fa:16:3e:ca:4e:16 failed because the device is no longer found on the guest. Tried to investigate further the code and it seems that get_interface_cfg() does not find any interface that matches because target_dev is not the same. https://github.com/openstack/nova/blob/0f4cecb70c2d11593f18818523a61059c019… vhostuser backend does not set any value for target_dev, while LibvirtGuestInterface does. https://github.com/openstack/nova/blob/0f4cecb70c2d11593f18818523a61059c019… https://github.com/openstack/nova/blob/0f4cecb70c2d11593f18818523a61059c019… First question is, is it on purpose that vhostuser vif does not set any target_dev? Possible solution that I can think of: 1. Add setting of target_dev in set_vif_host_backend_vhostuser_config() 2. Skipping target_dev check when vif type is vhostuser. I also noticed, that when a vhostuser interface type is attached to VM during run-time there was no target dev present in the virsh dumpxml. First interface is created during creation. Second one, was attached run-time. <interface type='vhostuser'> <mac address='fa:16:3e:d8:47:73'/> <source type='unix' path='/var/run/openvswitch/vhu5b00f2b1-02' mode='server'/> <target dev='vhu5b00f2b1-02'/> <model type='virtio'/> <alias name='net0'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> </interface> <interface type='vhostuser'> <mac address='fa:16:3e:9c:93:db'/> <source type='unix' path='/var/run/openvswitch/vhu70a4f277-36' mode='server'/> <model type='virtio'/> <alias name='net1'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/> </interface>

1 0

[neutron] bug deputy report for week of December 3
by Bence Romsics 10 Dec '18

10 Dec '18

Hi Neutrinos, As I was the bug deputy, here comes the report for last week. (undecided) https://bugs.launchpad.net/neutron/+bug/1807153 Race condition in metering agent when creating iptable managers for router namespaces. In need of attention from experts of metering and dvr. haleyb volunteered in irc. https://bugs.launchpad.net/neutron/+bug/1807157 Metering doesn't work for DVR routers on compute nodes. In need of attention from experts of metering and dvr. haleyb volunteered in irc. (critical) https://bugs.launchpad.net/neutron/+bug/1807239 Race condition with DPDK + trunk ports when instance port is deleted then quickly recreated. Fix proposed: https://review.openstack.org/623275 (high) none (medium) https://bugs.launchpad.net/neutron/+bug/1806770 DHCP Agent should not release DHCP lease when client ID is not set on port. Fix proposed: https://review.openstack.org/623066 https://bugs.launchpad.net/neutron/+bug/1807396 With many VMs on the same tenant, the L3 ip neigh add is too slow. Fix proposed: https://review.openstack.org/581360. Change owner is asking for help with (ie. takeover of) the change. (low) https://bugs.launchpad.net/neutron/+bug/1805991 IP Route: subnet's host_houtes attribute and router's routes accept the invalidate subnets. Fix proposed: https://review.openstack.org/623420 https://bugs.launchpad.net/neutron/+bug/1806032 neutron doesn't prevent the network update from external to internal when floatingIPs present. First fix proposal was abandoned. Bence Romsics will propose another fix. https://bugs.launchpad.net/neutron/+bug/1807128 Table name in "add_ip_rule" can be a string. Fix proposed: https://review.openstack.org/623182 https://bugs.launchpad.net/neutron/+bug/1807421 Open vSwitch hardware offloading in neutron updates. Fishing for a new contributor over doc improvement. :-) https://bugs.launchpad.net/neutron/+bug/1805132 bulk creation of security group rules fails StaleDataError. Confirmed, but not yet analyzed. (incomplete) https://bugs.launchpad.net/neutron/+bug/1807382 DNSMASQ wrong addresses allocated after changing DHCP Clients between Neutron vRouters NET https://bugs.launchpad.net/neutron/+bug/1807483 networksegments table in neutron can not be cleared automatically https://bugs.launchpad.net/neutron/+bug/1807673 Networking (neutron) concepts in neutron (rfe) https://bugs.launchpad.net/neutron/+bug/1806052 Changing segmentation_id of existing network should be allowed https://bugs.launchpad.net/neutron/+bug/1806316 Add RPC query API to l2pop for FDB resync https://bugs.launchpad.net/neutron/+bug/1806390 Distributed DHCP agent Cheers, Bence Romsics irc: rubasov

1 0