- openstack-discuss - lists.openstack.org

[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

[Neutron][ovs-dpdk]
by Zilhazur Rahman 10 Dec '18

10 Dec '18

Hi I am writing for the first time to the mailing list of openstack, I am trying to deploy ovs-dpdk to have better traffic throughput for NFV. Could you please share any tutorial link for standard ovs-dpdk deployment. On the other hand, openstack site says this " Expect performance degradation of services using tap devices: these devices do not support DPDK. Example services include DVR, FWaaS, or LBaaS. " but I need to have LBaaS and DVR ( to have direct external connectivity on compute) , what could be done in this case? Regards Zilhaz

2 1

[vitrage] Removing the static-physical datasource
by Ifat Afek 10 Dec '18

10 Dec '18

Hi, Just wanted to give you a heads-up that we are about to remove the static-physical datasource [1][2] that was deprecated in Queens [3]. Please use the static datasource [4] instead. Thanks, Ifat [1] https://review.openstack.org/#/c/624033/ [2] https://review.openstack.org/#/c/624031/ [3] https://docs.openstack.org/releasenotes/vitrage/queens.html [4] https://docs.openstack.org/vitrage/latest/contributor/static-config.html

1 0

[horizon]Javascript files contains "conf" in their file name
by Rikimaru Honjo 10 Dec '18

10 Dec '18

Hello, I have a question about configuration of horizon. There are some javascript files contains "conf" in their file name in horizon repository.[1] Are they configuration files like local_settings.py for panels implemented in Angular? Sometimes, should I edit these files if I'd like to customize my horizon? [1] e.g. horizon/static/framework/conf/conf.js, openstack_dashboard/static/app/core/conf/conf.module.js Best Regards, -- _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ Rikimaru Honjo E-mail:honjo.rikimaru@po.ntt-tx.co.jp

1 0

[Neutron]
by Bino Oetomo 10 Dec '18

10 Dec '18

Dear All. I have no problem configuring network via Hosrizon-dasboard. I start playing with python for some task. I got succsess in creating network. I create a router, with one interface connected to existing 'ext-network' .. success. But I fail when I try to add a port to that router for connecting to existing internal network. Here is part of my python shell. -------------------- body_value = { 'port': { 'admin_state_up': True, 'device_owner': 'network:router_interface', 'device_id': 'a616dcc0-1f72-4424-9494-4d13b42445ee', 'name': 'Bino-net-01-02', 'network_id': 'dfc8ed54-106d-48d0-8b45-cbd3cf0fbb79', 'binding:host_id': 'rocky-controller.mynet.net', 'binding:profile': {}, 'binding:vnic_type': 'normal', 'fixed_ips': [{ 'subnet_id': 'c71a86a3-f9a8-4e60-828e-5d6f87e58ac9', 'ip_address': '192.168.202.254' }], }} response = nt.create_port(body=body_value) response {'port': {'allowed_address_pairs': [], 'extra_dhcp_opts': [], 'updated_at': '2018-12-07T08:10:24Z', 'device_owner': 'network:router_interface', 'revision_number': 1, 'port_security_enabled': False, 'binding:profile': {}, 'fixed_ips': [{'subnet_id': 'c71a86a3-f9a8-4e60-828e-5d6f87e58ac9', 'ip_address': '192.168.202.254'}], 'id': 'd02eb0f0-663f-423f-af4e-c969ccb9dc25', 'security_groups': [], 'binding:vif_details': {'port_filter': True, 'datapath_type': 'system', 'ovs_hybrid_plug': True}, 'binding:vif_type': 'ovs', 'mac_address': 'fa:16:3e:e2:9d:8f', 'project_id': 'c0b89f614b5a457cb5acef8fe8c2b320', 'status': 'DOWN', 'binding:host_id': 'rocky-controller.mynet.net', 'description': '', 'tags': [], 'device_id': 'a616dcc0-1f72-4424-9494-4d13b42445ee', 'name': 'Bino-net-01-02', 'admin_state_up': True, 'network_id': 'dfc8ed54-106d-48d0-8b45-cbd3cf0fbb79', 'tenant_id': 'c0b89f614b5a457cb5acef8fe8c2b320', 'created_at': '2018-12-07T08:10:24Z', 'binding:vnic_type': 'normal'}} -------------------- 'status' always 'DOWN'. Kindly please give me some clue to fix this problem Note : Actualy I post same question on stackexchange : https://stackoverflow.com/questions/53665795/openstack-python-neutronclient… Sincerely -bino-

2 5

apologize
by Bino Oetomo 09 Dec '18

09 Dec '18

Dear All. I apologize for my double post. I just realize after I write the second one. The first one is posted before I joint the list, it's http://lists.openstack.org/pipermail/openstack-discuss/2018-December/000745… And the second one is : http://lists.openstack.org/pipermail/openstack-discuss/2018-December/000760… Sincerely -bino-

1 0

Add port to router using python
by Bino Oetomo 09 Dec '18

09 Dec '18

Dear All. My openstack installation version is 'rocky'. I tried to create a new port and add it to existing router. Got no error messages, but the port status always 'DOWN'. -------------------------------------- >>> myrouter {'status': 'ACTIVE', 'external_gateway_info': {'network_id': 'd10dd06a-0425-49eb-a8ba-85abf55ac0f5', 'enable_snat': True, 'external_fixed_ips': [{'subnet_id': '4639e018-1cc1-49cc-89d4-4cad49bd4b89', 'ip_address': '10.10.10.2'}]}, 'availability_zone_hints': [], 'availability_zones': ['nova'], 'description': '', 'tags': [], 'tenant_id': 'c0b89f614b5a457cb5acef8fe8c2b320', 'created_at': '2018-12-07T07:24:41Z', 'admin_state_up': True, 'distributed': False, 'updated_at': '2018-12-07T07:58:02Z', 'project_id': 'c0b89f614b5a457cb5acef8fe8c2b320', 'flavor_id': None, 'revision_number': 10, 'routes': [], 'ha': False, 'id': 'a616dcc0-1f72-4424-9494-4d13b42445ee', 'name': 'Bino-rtr-01'} ```>>> mynetworks=[n for n in netlist['networks'] if n['name'].startswith('Bino')] >>> mynetworks [{'provider:physical_network': 'viavlan', 'ipv6_address_scope': None, 'revision_number': 7, 'port_security_enabled': True, 'mtu': 1500, 'id': '942675f6-fd5e-4bb2-ba43-487be992ff4e', 'router:external': False, 'availability_zone_hints': [], 'availability_zones': ['nova'], 'ipv4_address_scope': None, 'shared': False, 'project_id': 'c0b89f614b5a457cb5acef8fe8c2b320', 'status': 'ACTIVE', 'subnets': ['5373bc35-a90f-4793-a912-801920e47769'], 'description': '', 'tags': [], 'updated_at': '2018-12-07T07:50:27Z', 'provider:segmentation_id': 2037, 'name': 'Bino-net-01', 'admin_state_up': True, 'tenant_id': 'c0b89f614b5a457cb5acef8fe8c2b320', 'created_at': '2018-12-07T07:28:00Z', 'provider:network_type': 'vlan'}, {'provider:physical_network': 'viavlan', 'ipv6_address_scope': None, 'revision_number': 6, 'port_security_enabled': True, 'mtu': 1500, 'id': 'dfc8ed54-106d-48d0-8b45-cbd3cf0fbb79', 'router:external': False, 'availability_zone_hints': [], 'availability_zones': ['nova'], 'ipv4_address_scope': None, 'shared': False, 'project_id': 'c0b89f614b5a457cb5acef8fe8c2b320', 'status': 'ACTIVE', 'subnets': ['c71a86a3-f9a8-4e60-828e-5d6f87e58ac9'], 'description': '', 'tags': [], 'updated_at': '2018-12-07T07:49:59Z', 'provider:segmentation_id': 2002, 'name': 'Bino-net-02', 'admin_state_up': True, 'tenant_id': 'c0b89f614b5a457cb5acef8fe8c2b320', 'created_at': '2018-12-07T07:29:52Z', 'provider:network_type': 'vlan'}] >>> print([n['name'] for n in mynetworks]) ['Bino-net-01', 'Bino-net-02'] >>> mynetwork=mynetworks[1] >>> mynetwork['name'] 'Bino-net-02' >>> body_value = { ... 'port': { ... 'admin_state_up': True, ... 'device_id': myrouter['id'], ... 'name': 'Bino-rtr-01-02', ... 'network_id': mynetwork['id'], ... } ... } >>> response = nt.create_port(body=body_value) >>> response {'port': {'allowed_address_pairs': [], 'extra_dhcp_opts': [], 'updated_at': '2018-12-10T01:44:10Z', 'device_owner': '', 'revision_number': 1, 'binding:profile': {}, 'port_security_enabled': True, 'fixed_ips': [{'subnet_id': 'c71a86a3-f9a8-4e60-828e-5d6f87e58ac9', 'ip_address': '192.168.202.6'}], 'id': 'a2a337af-3a37-4a9a-a4f1-ffaacdf9f881', 'security_groups': ['4bed540c-266d-4cc2-8225-3e02ccd89ff1'], 'binding:vif_details': {}, 'binding:vif_type': 'unbound', 'mac_address': 'fa:16:3e:05:aa:b5', 'project_id': 'c0b89f614b5a457cb5acef8fe8c2b320', 'status': 'DOWN', 'binding:host_id': '', 'description': '', 'tags': [], 'device_id': 'a616dcc0-1f72-4424-9494-4d13b42445ee', 'name': 'Bino-rtr-01-02', 'admin_state_up': True, 'network_id': 'dfc8ed54-106d-48d0-8b45-cbd3cf0fbb79', 'tenant_id': 'c0b89f614b5a457cb5acef8fe8c2b320', 'created_at': '2018-12-10T01:44:10Z', 'binding:vnic_type': 'normal'}} >>> response['port']['status'] 'DOWN' -------------------------------------- Kindly please give me some clues to fic this problem Sincerely -bino-

1 0

[neutron] [octavia] Manual deployment step for octavia on packstack
by Vikrant Aggarwal 09 Dec '18

09 Dec '18

Hello Team, Do we have the steps documented somewhere to install octavia manually like we have for zun [1]? I have done the openstack deployment using packstack and now I want to install the octavia manually on it. I have done the following steps: # groupadd --system octavia # useradd --home-dir "/var/lib/octavia" --create-home --system --shell /bin/false -g octavia octavia # cd /var/lib/octavia/ # git clone https://github.com/openstack/octavia.git # chown -R octavia:octavia * # pip install -r requirements.txt # python setup.py install # openstack user create --domain default --password-prompt octavia # openstack role add --project service --user octavia admin # openstack service create --name octavia --description "Octavia Service" " Octavia Load Balancing Servic" # openstack endpoint create --region RegionOne "Octavia Load Balancing Servic" public http://10.121.19.50:9876/v1 # openstack endpoint create --region RegionOne "Octavia Load Balancing Servic" admin http://10.121.19.50:9876/v1 # openstack endpoint create --region RegionOne "Octavia Load Balancing Servic" internal http://10.121.19.50:9876/v1 Made the following changes in the configuration file. [root@packstack1 octavia(keystone_admin)]# diff etc/octavia.conf /etc/ octavia/octavia.conf 20,21c20,21 < # bind_host = 127.0.0.1 < # bind_port = 9876 --- > bind_host = 10.121.19.50 > bind_port = 9876 38c38 < # api_v2_enabled = True --- > # api_v2_enabled = False 64c64 < # connection = mysql+pymysql:// --- > connection = mysql+pymysql://octavia:octavia@10.121.19.50/octavia 109c109 < # www_authenticate_uri = https://localhost:5000/v3 --- > www_authenticate_uri = https://10.121.19.50:5000/v3 111,114c111,114 < # auth_url = https://localhost:5000/v3 < # username = octavia < # password = password < # project_name = service --- > auth_url = https://10.121.19.50:35357/v3 > username = octavia > password = octavia > project_name = service 117,118c117,118 < # project_domain_name = Default < # user_domain_name = Default --- > project_domain_name = default > user_domain_name = default Generated the certificates using the script and copy the following certificates in octavia: [root@packstack1 octavia(keystone_admin)]# cd /etc/octavia/ [root@packstack1 octavia(keystone_admin)]# ls -lhrt total 28K -rw-r--r--. 1 octavia octavia 14K Dec 4 05:50 octavia.conf -rw-r--r--. 1 octavia octavia 1.7K Dec 4 05:55 client.key -rw-r--r--. 1 octavia octavia 989 Dec 4 05:55 client.csr -rw-r--r--. 1 octavia octavia 1.7K Dec 4 05:55 client.pem Can anyone please guide me about the further configuration? [1] https://docs.openstack.org/zun/latest/install/controller-install.html Thanks & Regards, Vikrant Aggarwal

1 0

[infra] A change to Zuul's queuing behavior
by corvus＠inaugust.com 09 Dec '18

09 Dec '18

Hi, We recently made a change to how Zuul and Nodepool prioritize node requests. Cloud resources are the major constraint in how long it takes Zuul to run test jobs on proposed changes. Because we're using more resources than ever before (but not necessarily because we're doing more work -- Clark has been helping to identify inefficiencies in other mailing list threads), the amount of time it takes to receive results on a change has been increasing. Since some larger projects consume the bulk of cloud resources in our system, this can be especially frustrating for smaller projects. To be sure, it impacts everyone, but while larger projects receive a continuous stream of results (even if delayed) smaller projects may wait hours before seeing results on a single change. In order to help all projects maintain a minimal velocity, we've begun dynamically prioritizing node requests based on the number of changes a project has in a given pipeline. This means that the first change for every project in the check pipeline has the same priority. The same is true for the second change of each project in the pipeline. The result is that if a project has 50 changes in check, and another project has a single change in check, the second project won't have to wait for all 50 changes ahead before it gets nodes allocated. As conditions change (requests are fulfilled, changes are added and removed) the priorities of any unfulfilled requests are adjusted accordingly. In the gate pipeline, the grouping is by shared change queue. But the gate pipeline still has a higher overall precedence than check. We hope that this will make for a significant improvement in the experience for smaller projects without causing undue hardship for larger ones. We will be closely observing the new behavior and make any necessary tuning adjustments over the next few weeks. Please let us know if you see any adverse impacts, but don't be surprised if you notice node requests being filled "out of order". -Jim

6 6

[infra] Update on test throughput and Zuul backlogs
by Clark Boylan 09 Dec '18

09 Dec '18

Hello everyone, I was asked to write another one of these in the Nova meeting today so here goes. TripleO has done a good job of reducing resource consumption and now represents about 42% of the total resource usage for the last month down from over 50% when we first started tracking this info. Generating the report requires access to Zuul's scheduler logs so I've pasted a copy at http://paste.openstack.org/show/736797/. There is a change, https://review.openstack.org/#/c/616306/, to report this data via statsd which will allow anyone to generate it off of our graphite server once deployed. Another piece of exciting (good) news is that we've changed the way the Zuul resource allocation scheme prioritizes requests. In the check pipeline a change's relative priority is based on how many changes for that project are already in check and in the gate pipeline it is relative to the number of changes in the shared gate queue. What this means is that less active projects shouldn't need to wait as long for their changes to be tested, but more active projects like tripleo-heat-templates, nova, and neutron may see other changes being tested ahead of their changes. More details on this thread, http://lists.openstack.org/pipermail/openstack-discuss/2018-December/000482…. One side effect of this change is that our Zuul is now running more jobs per hour than in the past (because it can more quickly churn through changes for "cheap" projects). Unfortunately, this has increased the memory demands on the zuul-executors and we've found that we are using far more swap than we'd like. We'll be applying https://review.openstack.org/#/c/623245/ to reduce the amount of memory required by each job during the course of its run which we hope helps. We've also added one new executor with plans to add a second if this change doesn't help. All that said flaky tests are still an issue. One set of problems seems related to slower than expected/before test nodes in the BHS1 region. We've been debugging these with OVH (thank you amorin!) and think we've managed to make some improvements though so far the problems persist. Current theory is that we are acting as our own noisy neighbors starving the hypervisors of disk IO throughput. In order to test that we've halved the total number of resources we'll use there. More details at https://etherpad.openstack.org/p/bhs1-test-node-slowness including a list of e-r bugs that may be tied to this issue. One thing to keep in mind is that while the test nodes are slower than we'd like, they have also exposed some situations where our software is less efficient than we'd like. At least one bug, https://bugs.launchpad.net/nova/+bug/1807219, has been identified through this. I would encourage people debugging these slow tests to look to see if this exposes a deficiency in our software that can be fixed. CentOS 7.6 released this last Monday. Fallout from that has included needing to update ansible playbooks that ensure the latest version of a centos distro package without setting become: yes. Previously the package was installed at the latest version on our images which ansible could verify without root privileges. Additionally golang is no longer a valid package on the base OS as it was on 7.5 (side note, this doesn't feel incredibly stable for users if anyone from rhel is listening). If your jobs depend on golang on centos and were getting that from the distro packages on 7.5 you'll need to find somewhere else to get golang now. With the distro updates come broken nested virt. Unfortunately nested virt continues to be a back and forth of working today, not working tomorrow. It seem that our test node kernels play a big impact on that then a few days later the various clouds apply new hypervisor kernel updates and things work again. If your jobs attempt to use nested virt and you've seen odd behavior from them (like reboots) recently this may be the cause. These are the big issues that affect large numbers of projects (or even all of them), but there are still many project specific problems floating around as well. Unfortunately I haven't had much time to help dig into those recently (see broader issues above), but I think it would be helpful if projects can do some of that digging themselves. Also, a friendly reminder that we try to provide in cloud region mirrors and caches for commonly used resources like distro packages, pypi packages, dockerhub images, and so on. If your jobs aren't using these and you find they fail occasionally due to the Internet being flaky we'll be happy to help you update the jobs to use the in region resources instead. We'll keep pushing to fix the broader issues and are more than happy to help debug failures you hit within your projects as well. Hopefully this was helpful despite its length. Clark

5 7

[OpenStack][Neutron] WARNING neutron.pecan_wsgi.controllers.root
by Soheil Pourbafrani 08 Dec '18

08 Dec '18

Hi, I defined an external flat network and the Instances' network functionality is OK but the neutron logs continusly on the file server.log: *2018-12-04 03:21:22.206 2218 WARNING neutron.pecan_wsgi.controllers.root [req-0ac40043-ec93-490d-8770-5f4c49a11ea6 539929ca1549436cb4c4171e037e8df7 0a26c316d0d143229f7420cf7fa35bdc - default default] No controller found for: floatingips - returning response code 404: PecanNotFound* 2018-12-04 03:21:22.208 2218 INFO neutron.pecan_wsgi.hooks.translation [req-0ac40043-ec93-490d-8770-5f4c49a11ea6 539929ca1549436cb4c4171e037e8df7 0a26c316d0d143229f7420cf7fa35bdc - default default] GET failed (client error): The resource could not be found. 2018-12-04 03:21:22.209 2218 INFO neutron.wsgi [req-0ac40043-ec93-490d-8770-5f4c49a11ea6 539929ca1549436cb4c4171e037e8df7 0a26c316d0d143229f7420cf7fa35bdc - default default] 192.168.0.31 "GET /v2.0/floatingips?fixed_ip_address=192.168.0.205&port_id=15251089-950a-4a4b-998b-e7412350b8bc HTTP/1.1" status: 404 len: 309 time: 0.0077560 2018-12-04 03:21:22.284 2218 INFO neutron.wsgi [req-1177939c-e304-439a-a6bf-1a3d216a2336 539929ca1549436cb4c4171e037e8df7 0a26c316d0d143229f7420cf7fa35bdc - default default] 192.168.0.31 "GET /v2.0/subnets?id=9771f7f2-12f8-46bd-aca3-f1d26e0b9768 HTTP/1.1" status: 200 len: 835 time: 0.0708778 2018-12-04 03:21:22.368 2218 INFO neutron.wsgi [req-12dce42d-f6a0-4deb-902d-c46d95621013 539929ca1549436cb4c4171e037e8df7 0a26c316d0d143229f7420cf7fa35bdc - default default] 192.168.0.31 "GET /v2.0/ports?network_id=a90d7d71-1ff4-4a98-b2b9-68adaea7d1c4&device_owner=network%3Adhcp HTTP/1.1" status: 200 len: 1085 time: 0.0782819 2018-12-04 03:21:22.569 2218 INFO neutron.wsgi [req-e73d9ad4-4e70-4fb6-91a5-9bd02c606284 539929ca1549436cb4c4171e037e8df7 0a26c316d0d143229f7420cf7fa35bdc - default default] 192.168.0.31 "GET /v2.0/networks/a90d7d71-1ff4-4a98-b2b9-68adaea7d1c4?fields=segments HTTP/1.1" status: 200 len: 212 time: 0.1933858 2018-12-04 03:21:22.751 2218 INFO neutron.wsgi [req-79921bc1-7f1a-4eee-aeca-3b660aab0522 539929ca1549436cb4c4171e037e8df7 0a26c316d0d143229f7420cf7fa35bdc - default default] 192.168.0.31 "GET /v2.0/networks/a90d7d71-1ff4-4a98-b2b9-68adaea7d1c4?fields=provider%3Aphysical_network&fields=provider%3Anetwork_type HTTP/1.1" status: 200 len: 281 time: 0.1775169 2018-12-04 03:21:34.957 2218 INFO neutron.wsgi [req-50877132-2c57-4220-9689-5c739d415aa8 539929ca1549436cb4c4171e037e8df7 0a26c316d0d143229f7420cf7fa35bdc - default default] 192.168.0.32 "GET /v2.0/ports?tenant_id=8cd6e51308894e119d2ad90ed15e71d2&device_id=882901a0-e518-4b4b-bf08-e998c4c0c875 HTTP/1.1" status: 200 len: 1094 time: 0.1096959 2018-12-04 03:21:35.116 2218 INFO neutron.wsgi [req-0305018f-b085-46c2-86cd-1769432cda91 539929ca1549436cb4c4171e037e8df7 0a26c316d0d143229f7420cf7fa35bdc - default default] 192.168.0.32 "GET /v2.0/networks?id=a90d7d71-1ff4-4a98-b2b9-68adaea7d1c4 HTTP/1.1" status: 200 len: 877 time: 0.1516771 I checked the neutron.conf and there was not any web_framework attribute under the [Default] section. >From OpenStack forum, someone suggest to set *web_framework = legacy *in neutron.conf. I did but it had no effect and neutron still is logging the so-called warning. Is this a bug or I miss something in configuration? I use the OpenStack Rocky.

1 0

[dev] quick report on microstack
by Pete Vander Giessen 07 Dec '18

07 Dec '18

Hi All, On Tue, Nov 20, 2018, 8:30 AM Chris Morgan <mihalis68 at gmail.com wrote: > Mark Shuttleworth introduced 'microstack' at the conference last week. > It's a snap based openstack install suitable for getting a quick instance > up for playing with. > ... On Tue Nov 20 14:37:35 UTC 2018 Melvin Hillsman <mrhillsman at gmail.com> wrote: > I tried it as well, as a one off it seems useful, but after about an hour > and looking at some of the issues on GitHub it is definitely in need of > some TLC. Restarting and reconfiguring is a pickle to say the least. For > example, if you want to access it from other than localhost. I do however > like the simplicity of it out the gate. Thank you both for taking a look and raising bugs :-) We've spent our time after returning from the U.S. Thanksgiving Break hammering bits and pieces into shape. I just pushed a release to the candidate channel that should fix some of the hiccups on install and restart. (Instances you've spun up will still be stopped after a system reboot, but you should be able to start them up manually and continue using them without any issues.) You can install it with: sudo snap install microstack --classic --candidate And if you've already got microstack installed, you can do: sudo snap refresh microstack @Chris Morgan: I left a comment on the bug relating to theme switching that you raised (https://github.com/CanonicalLtd/microstack/issues/39) It looks like something is broken in the pathing for the scss around the roboto font face, but I'm not sure whether it's an issue with the way that the snap lays out the files (a missing symlink, maybe?), or if it's a more general issue when installing from a Rocky release tarball. We're troubleshooting, but if you'd weigh in with an opinion, I'd appreciate it. Thanks again! ~ PeteVG

1 0

[ops][docs] The Contributor Guide: Ops Feedback Session Summary
by Kendall Nelson 07 Dec '18

07 Dec '18

Hello! For the long version, feel free to look over the etherpad[1]. It should be noted that this session was in relation to the operator section of the contributor guide, not the operations guide, though they should be closely related and link to one another. Basically the changes requested can be boiled down to two types of changes: cosmetic and missing content. Cosmetic Changes: - Timestamps so people can know when the last change was made to a given doc (dhellmann volunteered to help here)[2] - Floating bug report button and some mechanism for auto populating which page a bug is on so that the reader doesn’t have to know what rst file in what repo has the issue to file a bug[3] - Maybe not cosmetic exactly, but it was requested that the entirety of the contributor guide be translated into as many languages as possible (stevenK volunteered to help get the framework setup so that things could be imported into Zanata for translation)[4] - Link to source somewhere on the page so those interested in fixing issues that don’t know the repo structure can find and fix issues right away[5] Missing Content: - Links to the docs in the Operator guide (HA guide, etc)[6] - A guide to ‘I fixed this bug locally, how do I get it upstream?’[7] If there are any unclaimed items you are interested in working on, please do! The contributor guide work items are tracked in StoryBoard here[8]! -Kendall (diablo_rojo) [1] https://etherpad.openstack.org/p/BER-Contrib-Guide-Ops [2] https://storyboard.openstack.org/#!/story/2004436 [3] https://storyboard.openstack.org/#!/story/2004437 [4] https://storyboard.openstack.org/#!/story/2004438 [5] https://storyboard.openstack.org/#!/story/2004439 [6] https://storyboard.openstack.org/#!/story/2004441 [7] https://storyboard.openstack.org/#!/story/2004442 [8]https://storyboard.openstack.org/#!/project/openstack/contributor-guide

5 7

[octavia] Routing between lb-mgmt-net and amphora
by Paul Bourke 07 Dec '18

07 Dec '18

Hi, This is mostly a follow on to the thread at[0], though due to the mailing list transition it was easier to start a new thread. I've been attempting to get Octavia setup according to the dev-quick-start guide[1], but have been struggling with the following piece: "Add appropriate routing to / from the ‘lb-mgmt-net’ such that egress is allowed, and the controller (to be created later) can talk to hosts on this network." In mranga's reply, they say: > -- Create an ovs port on br-int > -- Create a neutron port using the ovs port that you just created. > -- Assign the ip address of the neutron port to the ovs port > -- Use ip netns exec to assign a route in the router namespace of the LoadBalancer network. I have enough of an understanding of Neutron/OVS for this to mostly make sense, but not enough to actually put it into practice it seems. My environment: 3 x control nodes 2 x network nodes 1 x compute All nodes have two interfaces, eth0 being the management network - 192.168.5.0/24, and eth1 being used for the provider network. I then create the Octavia lb-mgmt-net on 172.18.2.0/24. I've read the devstack script[2] and have the following questions: * Should I add the OVS port to br-int on the compute, network nodes, or both? * What is the purpose of creating a neutron port in this scenario If anyone is able to explain this a bit further or can even point to some good material to flesh out the underlying concepts it would be much appreciated, I feel the 'Neutron 101' videos I've done so far are not quite getting me there :) Cheers, -Paul [0] http://lists.openstack.org/pipermail/openstack-discuss/2018-December/000544… [1] https://docs.openstack.org/octavia/latest/contributor/guides/dev-quick-star… [2] https://github.com/openstack/octavia/blob/master/devstack/plugin.sh

2 3

[nova] slides now available for project update and project onboarding sessions
by melanie witt 07 Dec '18

07 Dec '18

Howdy all, This is just a FYI that slides are now attached to the summit events for the Nova - Project Update and the Nova - Project Onboarding sessions: https://www.openstack.org/summit/berlin-2018/summit-schedule/events/22861/n… https://www.openstack.org/summit/berlin-2018/summit-schedule/events/22860/n… Cheers, -melanie

1 0

[placement] update 18-49
by Chris Dent 07 Dec '18

07 Dec '18

HTML: https://anticdent.org/placement-update-18-49.html This will be the last placement update of the year. I'll be travelling next Friday and after that we'll be deep in the December lull. I'll catch us up next on January 4th. # Most Important As last week, progress continues on the work in ansible, puppet/tripleo, kolla, loci to package placement up and establish upgrade processes. All of these things need review (see below). Work on GPU reshaping in virt drivers is getting close. # What's Changed * The perfload jobs which used to run in the nova-next job now has its [own job](https://review.openstack.org/#/c/619248/), running on each change. This may be of general interest because it runs placement "live" but without devstack. Results in job runs that are less than 4 minutes. * We've decided to go ahead with the simple os-resource-classes idea, so a repo is [being created](https://review.openstack.org/#/c/621666/). # Slow Reviews (Reviews which need additional attention because they have unresolved questions.) * <https://review.openstack.org/#/c/619126/> Set root_provider_id in the database This has some indecision because it does a data migration within schema migrations. For this particular case this is safe and quick, but there's concern that it softens a potentially useful boundary between schema and data migrations. # Bugs * Placement related [bugs not yet in progress](https://goo.gl/TgiPXb): 17. -2. * [In progress placement bugs](https://goo.gl/vzGGDQ) 13. -1 ## Interesting Bugs (Bugs that are sneaky and interesting and need someone to pick them up.) * <https://bugs.launchpad.net/nova/+bug/1805858> placement/objects/resource_provider.py missing test coverage for several methods This is likely the result of the extraction. Tests in nova's test_servers and friends probably covered some of this stuff, but now we need placement-specific tests. * <https://bugs.launchpad.net/nova/+bug/1804453> maximum recursion possible while setting aggregates in placement This can only happen under very heavy load with a very low number of placement processes, but the code that fails should probably change anyway: it's a potentially infinite loop with no safety breakout. # Specs Spec freeze is milestone 2, the week of January 7th. There was going to be a spec review sprint next week but it was agreed that people are already sufficiently busy. This will certainly mean that some of these specs do not get accepted for this cycle. None of the specs listed last week have merged. * <https://review.openstack.org/#/c/544683/> Account for host agg allocation ratio in placement (Still in rocky/) * <https://review.openstack.org/#/c/595236/> Add subtree filter for GET /resource_providers * <https://review.openstack.org/#/c/597601/> Resource provider - request group mapping in allocation candidate * <https://review.openstack.org/#/c/549067/> VMware: place instances on resource pool (still in rocky/) * <https://review.openstack.org/#/c/555081/> Standardize CPU resource tracking * <https://review.openstack.org/#/c/599957/> Allow overcommit of dedicated CPU (Has an alternative which changes allocations to a float) * <https://review.openstack.org/#/c/591037/> Modelling passthrough devices for report to placement * <https://review.openstack.org/#/c/603955/> Nova Cyborg interaction specification. * <https://review.openstack.org/#/c/601596/> supporting virtual NVDIMM devices * <https://review.openstack.org/#/c/603352/> Spec: Support filtering by forbidden aggregate * <https://review.openstack.org/#/c/552924/> Proposes NUMA topology with RPs * <https://review.openstack.org/#/c/569011/> Count quota based on resource class * <https://review.openstack.org/#/c/141219/> Adds spec for instance live resize * <https://review.openstack.org/#/c/612497/> Provider config YAML file * <https://review.openstack.org/#/c/509042/> Propose counting quota usage from placement and API database * <https://review.openstack.org/603545> Resource modeling in cyborg. * <https://review.openstack.org/#/c/609960/> Support filtering of allocation_candidates by forbidden aggregates # Main Themes ## Making Nested Useful Progress continues on gpu-reshaping for libvirt and xen: * <https://review.openstack.org/#/q/topic:bp/reshape-provider-tree+status:open> Also making use of nested is bandwidth-resource-provider: * <https://review.openstack.org/#/q/topic:bp/bandwidth-resource-provider> Eric's in the process of doing lots of cleanups to how often the ProviderTree in the resource tracker is checked against placement, and a variety of other "let's make this more right" changes in the same neighborhood: * Stack at: <https://review.openstack.org/#/c/615677> ## Extraction The [extraction etherpad](https://etherpad.openstack.org/p/placement-extract-stein-4) is starting to contain more strikethrough text than not. Progress is being made. The main tasks are the reshaper work mentioned above and the work to get deployment tools operating with an extracted placement: * [TripleO](https://review.openstack.org/#/q/topic:tripleo-placement-extractio… * [OpenStack Ansible](https://review.openstack.org/#/q/project:openstack/openstack-ansib… * [Kolla](https://review.openstack.org/#/c/613589/) * [Kolla Ansible](https://review.openstack.org/#/c/613629/) * [Loci](https://review.openstack.org/#/c/617273/) Documentation tuneups: * Release-notes: <https://review.openstack.org/#/c/618708/> This is blocked until we refactor the release notes to reflect _now_ better. * The main remaining task here is participating in [openstack-manuals](https://docs.openstack.org/doc-contrib-guide/doc-index.h…. The functional tests in nova that use [extracted placement](https://review.openstack.org/#/c/617941/) are working but not yet merged. A child of that patch [removes the placement code](https://review.openstack.org/#/c/618215/). Further work will be required to tune up the various pieces of documentation in nova that reference placement. # Other There are currently only 8 [open changes](https://review.openstack.org/#/q/project:openstack/placement+statu… in placement itself. Most of the time critical work is happening elsewhere (notably the deployment tool changes listed above). Of those placement changes the [database-related](https://review.openstack.org/#/q/owner:nakamura.tetsuro%2… ones from Tetsuro are the most important. Outside of placement: * <https://review.openstack.org/#/q/topic:bp/initial-allocation-ratios> Improve handling of default allocation ratios * <https://review.openstack.org/#/q/topic:minimum-bandwidth-allocation-placeme…> Neutron minimum bandwidth implementation * <https://review.openstack.org/#/c/602160/> Add OWNERSHIP $SERVICE traits * <https://review.openstack.org/#/c/586960/> zun: Use placement for unified resource management * <https://review.openstack.org/#/q/project:openstack/blazar+topic:bp/placemen…> Blazar using the placement-api * <https://review.openstack.org/619626> Tenks doing some node management, with a bit of optional placement. * <https://review.openstack.org/#/c/620485/> Sync placement database to the current version (in grenade) * <https://review.openstack.org/#/c/621645/> WIP: add Placement aggregates tests (in tempest) # End In case it hasn't been clear: things being listed here is an explicit invitation (even plea) for _you_ to help out by reviewing or fixing. Thank you. -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent tw: @anticdent

2 1

[dev][keystone] Keystone Team Update - Week of 3 December 2018
by Colleen Murphy 07 Dec '18

07 Dec '18

# Keystone Team Update - Week of 3 December 2018 ## News ### New Outreachy Interns The keystone team is lucky enough to have two Outreachy interns this round: welcome to Erus (erus) and Islam (imus)! Erus will be helping us with our federation implementation and Islam will be working on improving our API unit tests. We're happy to have you! ### Keystone as IdP Proxy (Broker) Morgan started working on a diagram to explain the proposed architecture for keystone as an identity provider proxy/broker[1][2]. It is a good starting point for understanding the general idea of what the proposed design is. Please have a look at it and bring your questions to Morgan. [1] https://usercontent.irccloud-cdn.com/file/Au4e3DXb/Keystone%20IDP%20(initia… [2] http://eavesdrop.openstack.org/meetings/keystone/2018/keystone.2018-12-04-1… ## Open Specs Stein specs: https://bit.ly/2Pi6dGj Ongoing specs: https://bit.ly/2OyDLTh ## Recently Merged Changes Search query: https://bit.ly/2pquOwT We merged 25 changes this week. ## Changes that need Attention Search query: https://bit.ly/2RLApdA There are 91 changes that are passing CI, not in merge conflict, have no negative reviews and aren't proposed by bots. ## Bugs This week we opened 5 new bugs and closed 4. Bugs opened (5) Bug #1806713 (keystone:Medium) opened by Lance Bragstad https://bugs.launchpad.net/keystone/+bug/1806713 Bug #1806762 (keystone:Medium) opened by Lance Bragstad https://bugs.launchpad.net/keystone/+bug/1806762 Bug #1806195 (keystone:Undecided) opened by nigel cook https://bugs.launchpad.net/keystone/+bug/1806195 Bug #1806377 (keystone:Undecided) opened by kirandevraaj https://bugs.launchpad.net/keystone/+bug/1806377 Bug #1807184 (oslo.policy:Medium) opened by Brian Rosmaita https://bugs.launchpad.net/oslo.policy/+bug/1807184 Bugs fixed (4) Bug #1806109 (keystoneauth:Medium) fixed by Monty Taylor https://bugs.launchpad.net/keystoneauth/+bug/1806109 Bug #1800259 (oslo.policy:Undecided) fixed by Lance Bragstad https://bugs.launchpad.net/oslo.policy/+bug/1800259 Bug #1803722 (oslo.policy:Undecided) fixed by Corey Bryant https://bugs.launchpad.net/oslo.policy/+bug/1803722 Bug #1804073 (oslo.policy:Undecided) fixed by John Dennis https://bugs.launchpad.net/oslo.policy/+bug/1804073 ## Milestone Outlook https://releases.openstack.org/stein/schedule.html We have just a month left until our spec freeze. A month after that is our feature proposal freeze, so if you are planning significant feature work, best to get started on it soon. ## Help with this newsletter Help contribute to this newsletter by editing the etherpad: https://etherpad.openstack.org/p/keystone-team-newsletter Dashboard generated using gerrit-dash-creator and https://gist.github.com/lbragstad/9b0477289177743d1ebfc276d1697b67

1 0

[nova] Moving nova-cells-v1 job to the experimental queue
by Matt Riedemann 07 Dec '18

07 Dec '18

I have changes up which move the nova-cells-v1 CI job to the experimental queue: https://review.openstack.org/#/q/topic:bug/1807407 We continue to see intermittent failures in that job and given the deprecated nature of cells v1, CERN is using cells v2, the job no longer runs nova-network, and its flakiness (plus the general state of the gate lately), it is time to move this further out of our daily lives and down the road to its eventual removal. Keeping it as an option to run on-demand in the experimental queue at least allows us to leverage it if needed should some major cells v1 fix be needed, but that is doubtful (we haven't had a cells v1 specific bug fix in a long time). -- Thanks, Matt

1 0

[ironic] Time to discuss clean/deploy steps
by Julia Kreger 07 Dec '18

07 Dec '18

All, I've looked at the doodle poll results and it looks like the best available time is 3:00 PM UTC on Friday December 7th. I suggest we use bluejeans[2] as that has worked fairly well for us thus far. The specification documented related to the discussion can be found in review[3]. Thanks, -Julia [1] https://doodle.com/poll/yan4wyvztf7mpq46 [2] https://bluejeans.com/u/jkreger/ [3] https://review.openstack.org/#/c/606199/

2 2

[nova] What to do with the legacy notification interface?
by Balázs Gibizer 07 Dec '18

07 Dec '18

Hi, Last decision from the Denver PTG [1] was to * finish the remaining transformations [2] * change the default value of notification_format conf option from 'both' to 'versioned' * communicate that the legacy notification interface has been deprecated, unsupported but the code will not be removed Since the PTG the last two transformation patches [2] has been approved and the deprecation patch has been prepared [3]. However recently we got a bug report [4] where the performance impact of emiting both legacy and versioned notification caused unnecessary load on the message bus. (Btw this performance impact was raised in the original spec [5]). The original reason we emited both type of notifications was to keep backward compatibility with consumers only understanding legacy notifications. It worked so well that most of the consumers still depend on the legacy notifications (detailed status is in [1]). I see three options to move forward: A) Do nothing. By default, emit both type of notifications. This means that deployers seeing the performance impact of [4] needs to reconfigure nova. Also this is agains our decision to move away from supporting legacy notifications. B) Follow the plan from the PTG and change the default value of the config to emit only versioned notifications. This solves the immediate effect of the bug [4]. This is following our original plan. BUT this is backward incompatible change which in the current situation means most of the deployments (e.g. those, deploying notification consumer modules like ceilometer) need to change this config to 'unversioned' or 'both'. There was discussion about helping out notification consumers to convert their code using the new versioned interface but I have no spare time at the moment and I failed to drum up resources internally for this work. Also I don't see others volunteering for such work. C) Change the default to 'legacy'. This solves the bug [4]. BUT sends a really mixed message. As our original goal was to stop supporting the legacy notification interface of nova. Matt stated on IRC recently, there is no real bug inflow for the legacy code. Also looking at changes in the code I see that last cycle we had couple of blueprints extending the new versioned notifications with extra fields but that inflow stopped in this cycle too. So we most probably can keep the legacy code in place and supported forever without too much pain and too much divergence from the versioned interface. -- Personally, I spent enough time implementing and reviewing the versioned interface that I'm biased towards option B). But I do understand that our original goals setting in 2015 was made in such environment that changed significantly in the past cycles. So I can accept option C) as well if we can agree. Cheers, gibi [1] https://etherpad.openstack.org/p/nova-ptg-stein L765 [2] https://review.openstack.org/#/q/topic:bp/versioned-notification-transforma… [3] https://review.openstack.org/#/c/603079/ [4] https://bugs.launchpad.net/nova/+bug/1805659 [5] https://review.openstack.org/#/c/224755/11/specs/mitaka/approved/versioned-…

2 2

[tc] Technical Committee status update for 6 December
by Doug Hellmann 06 Dec '18

06 Dec '18

This is the (alegedly) weekly summary of work being done by the Technical Committee members. The full list of active items is managed in the wiki: https://wiki.openstack.org/wiki/Technical_Committee_Tracker We also track TC objectives for the cycle using StoryBoard at: https://storyboard.openstack.org/#!/project/923 == Recent Activity == It has been 4 weeks since the last update email, in part due to the Summit, then a holiday, then my absense due to illness. Project updates: * Add tenks under Ironic: https://review.openstack.org/#/c/600411/ * Add os_placement role to OpenStack Ansible: https://review.openstack.org/#/c/615187/ * Retired openstack-ansible-os_monasca-ui https://review.openstack.org/#/c/617322/ * Chris Hoge was made the new Loci team PTL https://review.openstack.org/#/c/620370/ Other updates: * Thierry has been working on a series of changes on behalf of the release management team to record the release management style used for each deliverable listed in the governance repository. https://review.openstack.org/#/c/613268/ * Zane updated our guidelines for new projects to clarify the scoping requirements: https://review.openstack.org/#/c/614799/ * Zane also added a Vision for OpenStack Clouds document, describing what we see as the scope of OpenStack overall: https://review.openstack.org/#/c/592205/ * I copied some code we had in a couple of other places into the governance repository to make it easier for the release, goal, and election tools to consume the governance data using the new openstack-governance library from PyPI. https://review.openstack.org/#/c/614599/ * I started a document describing the responsibilities of the TC chair. https://review.openstack.org/#/c/618810/ == TC Meetings == In order to fulfill our obligations under the OpenStack Foundation bylaws, the TC needs to hold meetings at least once each quarter. We agreed to meet monthly, and to emphasize agenda items that help us move initiatives forward while leaving most of the discussion of those topics to the mailing list. The agendas for all of our meetings will be sent to the openstack-dev mailing list in advance, and links to the logs and summary will be sent as a follow up after the meeting. Our most recent meeting was held on 6 Dec 2018. * http://lists.openstack.org/pipermail/openstack-discuss/2018-December/000696… The next meeting will be 3 December @ 1400 UTC in #openstack-tc == Ongoing Discussions == We have several governance changes up for review related to deciding how we will manage future Python 3 upgrades (including adding 3.7 and possibly dropping 3.5 during Stein). These are close to being approved, with some final wording adjustments being made now. * Explicitly declare stein supported runtimes: https://review.openstack.org/#/c/611080/ * Resolution on keeping up with Python 3 releases: https://review.openstack.org/#/c/613145/ I proposed an update to our house rules to allow faster approval of release management metadata maintained in the governance repository. * https://review.openstack.org/#/c/622989/ Thierry and Chris have been working on a description of the role of the TC. * https://review.openstack.org/#/c/622400/ Ghanshyam has proposed an enhancement to the Vision for OpenStack Clouds to cover feature discovery. * https://review.openstack.org/#/c/621516/ Lance has proposed an update to the charter to clarify how we will handle PTL transitions in the middle of a development cycle. * https://review.openstack.org/#/c/620928/ == TC member actions/focus/discussions for the coming week(s) == We have several significant changes up for review. Please take time to consider all of the open patches, then comment and vote on them. It's very difficult to tell if we have reached consensus if everyone waits for the conversation to settle before commenting. == Contacting the TC == The Technical Committee uses a series of weekly "office hour" time slots for synchronous communication. We hope that by having several such times scheduled, we will have more opportunities to engage with members of the community from different timezones. Office hour times in #openstack-tc: - 09:00 UTC on Tuesdays - 01:00 UTC on Wednesdays - 15:00 UTC on Thursdays If you have something you would like the TC to discuss, you can add it to our office hour conversation starter etherpad at: https://etherpad.openstack.org/p/tc-office-hour-conversation-starters Many of us also run IRC bouncers which stay in #openstack-tc most of the time, so please do not feel that you need to wait for an office hour time to pose a question or offer a suggestion. You can use the string "tc-members" to alert the members to your question. You will find channel logs with past conversations at http://eavesdrop.openstack.org/irclogs/%23openstack-tc/ If you expect your topic to require significant discussion or to need input from members of the community other than the TC, please start a mailing list discussion on openstack-discuss at lists.openstack.org and use the subject tag "[tc]" to bring it to the attention of TC members. -- Doug

3 3

Re: [sdk] Establishing SDK Validation Baseline
by Melvin Hillsman 06 Dec '18

06 Dec '18

On Thu, Dec 6, 2018 at 12:30 PM Artem Goncharov <artem.goncharov(a)gmail.com> wrote: > > > On Thu, 6 Dec 2018, 19:12 Melvin Hillsman, <mrhillsman(a)gmail.com> wrote: > >> Hi everyone, >> >> We have spent some time working to get an idea of what official SDKs >> would look like. We had some sessions during the Berlin summit[0][1] and >> there was a lot of great feedback. >> >> Currently the following SDKs are generally considered usable for their >> respective language; there are others of course: >> >> openstacksdk (Python) >> gophercloud (Go) >> pkgcloud (JavaScript) >> openstack4j (Java) >> rust-openstack (Rust) >> fog-openstack (Ruby) >> php-opencloud (PHP) >> >> After many discussions it seems SDK validation essentially should be >> about confirming cloud state pre/post SDK interaction rather than API >> support. An example is that when I use pkgcloud and ask that a VM be >> created, does the VM exist, in the way I asked it exist, rather than are >> there specific API calls that are being hit along the way to creating my VM. >> >> I am putting this email out to keep the community informed of what has >> been discussed in this space but also and most importantly to get feedback >> and support for this work. It would be great to get a set of official and >> community SDKs, get them setup with CI testing for validation (not changing >> their current CI for unit/functional/acceptance testing; unless asked to >> help do this), and connect the results to the updated project navigator SDK >> section. A list of scenarios has been provided as a good starting point for >> cloud state checks.[2] >> >> Essentially the proposal is to deploy OpenStack from upstream (devstack >> or other), stand up a VM within the cloud, grab all the SDKs, run >> acceptance tests, report pass/fail results, update project navigator. Of >> course there are details to be worked out and I do have a few questions >> that I hope would help get everyone interested on the same page via this >> thread. >> >> >> 1. Does this make sense? >> >> > As a representative of a public cloud operator I say yes. It definitely > makes sense to let users know, which SDKs are certified to work to have > understanding what they can use. However then comes the question, that each > public operator has own "tricks" and possibly even extension services, > which make SDK behave not as expected. I do really see a need to provide a > regular way in each of those SDKs to add and (I really don't want this, but > need unfortunately) sometimes override services implementation if those are > changed in some way. > So the certification make sense, but the CI question probably goes in the > direction of OpenLab > Yes this is definitely something to consider; public cloud tricks and extensions. An idea that was floated is to have an upstream cloud to run against that passes all interop powered programs to run the SDKs against. Even though SDKs provide more coverage an SDK that works against a service that is certified should work in any cloud that is certified? > >> 1. Would folks be interested in a SDK SIG or does it make more sense >> to request an item on the API SIG's agenda? >> >> Both has pro and cons, but I am neutral here > > Same, just wanted to get it out there and hopefully get API SIG members feedback so as not to hijack any of their agendas or creep on their scope without consent. > > >> 1. Bi-weekly discussions a good cadence? >> >> Yes. The regular communication is a requirement. > > > >> 1. Who is interested in tackling this together? >> >> > I do, but not alone > Haha, agreed, but we definitely should work on it and be consistent even if the initial set of folks is small. We have a large community to lean on and should rather than simply going at it alone. > > >> >> >> [0] https://etherpad.openstack.org/p/BER-better-expose-what-we-produce >> [1] https://etherpad.openstack.org/p/BER-sdk-certification >> [2] >> https://docs.google.com/spreadsheets/d/1cdzFeV5I4Wk9FK57yqQmp5JJdGfKzEOdB3V… >> >> >> -- >> Kind regards, >> >> Melvin Hillsman >> mrhillsman(a)gmail.com >> mobile: (832) 264-2646 >> > > Regards, > Artem Goncharov > gtema > OpenTelekomCloud > >> -- Kind regards, Melvin Hillsman mrhillsman(a)gmail.com mobile: (832) 264-2646

1 0

[openstack-dev] [puppet] [stable] Deprecation of newton branches
by Tobias Urdin 06 Dec '18

06 Dec '18

Hello, We've been talking for a while about the deprecation and removal of the stable/newton branches. I think it's time now that we get rid of them, we have no open patches and Newton is considered EOL. Could cores get back with a quick feedback and then the stable team can get rid of those whenever they have time. Best regards Tobias __________________________________________________________________________ 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

6 8

[dev][nova] time for another spec review day?
by melanie witt 06 Dec '18

06 Dec '18

Hi All, Our spec freeze is milestone 2 January 10 and I was thinking, because of holiday time coming up, it might be a good idea to have another spec review day ahead of the freeze early next year. I was thinking maybe Tuesday next week December 11, to allow the most amount of time before holiday PTO starts. Please let me know what you think. Cheers, -melanie

1 1

[ops] Disk QoS in Cinder and Nova flavour
by Jean-Philippe Méthot 06 Dec '18

06 Dec '18

Hi, This is something that’s not exactly clear in the documentation and so I thought I’d ask here. There are currently two ways to set disk IO limits, or QoS: through Cinder QoS values or through Nova flavours. My question is, what’s the difference exactly? I assume that Cinder QoS only applies on Cinder volume, but is the same true for flavour QoS? In other words, is QoS through flavour supposed to apply to both Cinder volumes and ephemeral storage or is it only for ephemeral storage? Additionally, I'm under the assumption that once you provision a block device of a certain type with QoS associated to it, it becomes impossible to modify the values afterwards. Is that correct? This is a strange behaviour, considering that technically, you should be able to change QoS when it’s set through flavour using a simple resize. Please correct me if I’m wrong. I feel that this could be better explained in the current documentation. Jean-Philippe Méthot Openstack system administrator Administrateur système Openstack PlanetHoster inc.

1 0

[tc] agenda for Technical Committee Meeting 6 Dec 2018 @ 1400 UTC
by Doug Hellmann 06 Dec '18

06 Dec '18

TC Members, Our next meeting will be this Thursday, 6 Dec at 1400 UTC in #openstack-tc. This email contains the agenda for the meeting, based on the content of the wiki [0]. If you will not be able to attend, please include your name in the "Apologies for Absence" section of the wiki page [0]. [0] https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee * Follow up on past action items ** dhellmann complete liaison assignments using the random generator I have updated the team liaisons in the wiki [1]. Please review the list of projects to which you are assigned. [1] https://wiki.openstack.org/wiki/OpenStack_health_tracker#Project_Teams ** tc-members review the chair duties document The draft document from [2] has been merged and is now available in the governance repo as CHAIR.rst [3]. Please come prepared to discuss any remaining questions about the list of chair duties. [2] https://etherpad.openstack.org/p/tc-chair-responsibilities [3] http://git.openstack.org/cgit/openstack/governance/tree/CHAIR.rst * active initiatives ** keeping up with python 3 releases We are ready to approve Zane's resolution for a process for tracking python 3 versions [4]. There is one wording update [5] that we should prepare for approval as well. The next step will be to approve Sean's patch describing the runtimes supported for Stein [6]. Please come prepared to discuss any issues with those patches so we can resolve them and move forward. [4] https://review.openstack.org/613145 [5] https://review.openstack.org/#/c/621461/1 [6] https://review.openstack.org/#/c/611080/ * follow-up from Berlin Forum ** Vision for OpenStack clouds Zane has summarized the forum session on the mailing list [7], including listing several potential updates to the vision based on our discussion there. Please come prepared to discuss next steps for making those changes. [7] http://lists.openstack.org/pipermail/openstack-discuss/2018-December/000431… ** Train cycle goals I posted my summary of the forum session [8]. Each of the candidate goals have work to be done before they could be selected, so we will need to work with the sponsors and champions to see where enough progress is made to let us choose from among the proposals. Lance has agreed to lead the selection process for the Train goals, and will be looking for someone to pair up with on that. [8] http://lists.openstack.org/pipermail/openstack-discuss/2018-November/000055… ** Other TC outcomes from Forum We had several other forum sessions, and should make sure we have a good list of any promised actions that came from those discussions. Please come prepared to discuss any sessions you moderated -- having summaries on the mailing list before the meeting would be very helpful. -- Doug

1 1

[senlin] Cancelling this week's meeting
by Duc Truong 06 Dec '18

06 Dec '18

Everyone, The new odd week meeting time has just been approved but due to the short notice and also since there are no important updates since last week, I will cancel the Senlin meeting for this week. Next week the meeting will be on Friday at 530 UTC. Regards, Duc

1 0

[barbican][nova] booting instance from snapshot or unshelve with image signature verification enabled
by Pavlo Shchelokovskyy 06 Dec '18

06 Dec '18

Hi all, I am looking at how Nova is integrated with Barbican and am wondering how the user workflow when booting instance from snapshot should work (including unshelving a shelved instance) when Nova is set to strictly verify Glance images' signatures. Currently Nova strips by default all signature-related image metadata of original image when creating snapshot and for good reason - as the hash of the snapshot is definitely not the same as that of the image it was booted from, the signature of the original image is no longer valid for snapshot. Effectively that means that when strict image signature validation is enabled in Nova, the user can no longer simply boot from that snapshot, and even less obvious, can not unshelve instances the same way as without signature validation enabled. So is it expected that user manually signs her instance snapshots or is there some automagic way to do it? Or is it a known issue / limitation? Unfortunately I couldn't find any existing bugs or mentions in docs on that. Best regards, -- Dr. Pavlo Shchelokovskyy Principal Software Engineer Mirantis Inc www.mirantis.com

1 0

Anyone using ScaleIO block storage?
by Kimball (US), Conrad 06 Dec '18

06 Dec '18

Is anyone using ScaleIO (from Dell EMC) as a Cinder storage provider? What has been your experience with it, and at what scale? Our enterprise storage team is moving to ScaleIO and wants our OpenStack deployments to use it, so I'm looking for real life experiences to calibrate vendor stories of wonderfulness. One concern I do have is that it uses a proprietary protocol that in turn requires a proprietary "data client". For VM hosting this data client can be installed in the compute node host OS, but seems like we wouldn't be able to boot a bare-metal instance from a ScaleIO-backed Cinder volume. Conrad Kimball Associate Technical Fellow Enterprise Architecture Chief Architect, Enterprise Cloud Services conrad.kimball(a)boeing.com<mailto:conrad.kimball@boeing.com>

6 7

[dev][nova][glance] Interesting bug about deleting shelved server snapshot
by Matt Riedemann 06 Dec '18

06 Dec '18

I came across this bug during triage today: https://bugs.launchpad.net/nova/+bug/1807110 They are advocating that nova/glance somehow keep a shelved server snapshot image from being inadvertently deleted by the user since it could result in data loss as they can't unshelve the server later (there is metadata in nova that links the shelved server to the snapshot image in glance which is used during unshelve). I don't see a base description field on images but I suppose nova could write a description property that explains what the snapshot is and warn against deleting it. Going a step further, nova could potentially set the protected flag to true so the image cannot be deleted, but I have two concerns about that: 1. I don't see any way to force delete a protected image in glance - does that exist or has it been discussed before? 2. Would the user be able to PATCH the image to change the protected value to false and then delete the image if they really wanted to? The other problem with nova marking the image as protected is that if the user deletes the server, the compute API tries to delete the snapshot image [1] which would fail if it's still protected, and then we could see snapshot images getting orphaned in glance. Arguably nova could detect this situation, update the protected field to false, and then delete the image. Other thoughts? Has this come up before? [1] https://github.com/openstack/nova/blob/c9dca64fa64005e5bea327f06a7a3f4821ab… -- Thanks, Matt

3 4

Networking-sfc Installation on Openstack Queens
by Navdeep Uniyal 06 Dec '18

06 Dec '18

Dear all, I would like to use the networking-sfc in my multi-node openstack (Queens) vanilla installation. All the guides I found focussed on devstack. Please let me know if there is a proper documentation/guide to install the sfc service on my controller and compute nodes including the prerequisites. Please note: as of now I am using linuxbridge agent only. Please state if openVSwitch agent is required and how to install it. Kind Regards, Navdeep

2 1

Networking-sfc Installation on Openstack Queens
by Navdeep Uniyal 06 Dec '18

06 Dec '18

Dear all, I would like to use the networking-sfc in my multi-node openstack (Queens) vanilla installation. All the guides I found focussed on devstack. Please let me know if there is a proper documentation/guide to install the sfc service on my controller and compute nodes including the prerequisites. Please note: as of now I am using linuxbridge agent only. Please state if openVSwitch agent is required and how to install it. Kind Regards, Navdeep

1 0

Re: Anyone using ScaleIO block storage?
by Burak Hoban 06 Dec '18

06 Dec '18

We've been using ScaleIO alongside OpenStack for about 2 years now. From a stability point of view, no issues... we're still running on Mitaka so some of the integration isn't great but with the upgrade cycle coming up for us all of that should be solved. We only utilise (VM) instances on OpenStack though, not bare metal. _____________________________________________________________________ The information transmitted in this message and its attachments (if any) is intended only for the person or entity to which it is addressed. The message may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information, by persons or entities other than the intended recipient is prohibited. If you have received this in error, please contact the sender and delete this e-mail and associated material from any computer. The intended recipient of this e-mail may only use, reproduce, disclose or distribute the information contained in this e-mail and any attached files, with the permission of the sender. This message has been scanned for viruses. _____________________________________________________________________

2 4

[openstack-dev] [tripleo] Workflows Squad changes
by Jiri Tomasek 06 Dec '18

06 Dec '18

Hi all, Recently, the workflows squad has been reorganized and people from the squad are joining different squads. I would like to discuss how we are going to adjust to this situation to make sure that tripleo-common development is not going to be blocked in terms of feature work and reviews. With this change, most of the tripleo-common maintenance work goes naturally to UI & Validations squad as CLI and GUI are the consumers of the API provided by tripleo-common. Adriano Petrich from workflows squad has joined UI squad to take on this work. As a possible solution, I would like to propose Adriano as a core reviewer to tripleo-common and adding tripleo-ui cores right to +2 tripleo-common patches. It would be great to hear opinions especially former members of Workflows squad and regular contributors to tripleo-common on these changes and in general on how to establish regular reviews and maintenance to ensure that tripleo-common codebase is moved towards converging the CLI and GUI deployment workflow. Thanks __________________________________________________________________________ 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

4 3

[glance] is glance-cache deprecated
by Sumit Jamgade 06 Dec '18

06 Dec '18

Hello, $subject or are there any plans to migrate it to v2 ? I see Ia086230cc8c92f7b7dfd5b001923110d5bc55d4d removed the underlying entrypoint for glanace-cache-manage entrypoint -- thanks Sumit

2 2

Re: [TripleO] Configure SR-IOV VFs in tripleo
by sairam 05 Dec '18

05 Dec '18

we deployed overcloud rhosp10 through sriov but i am not able to create instance through please help me -- Sent from: http://openstack.10931.n7.nabble.com/Developer-f2.html

1 0

[release] Release countdown for week R-17, Dec 10-14
by Sean McGinnis 05 Dec '18

05 Dec '18

Development Focus ----------------- We are coming up on end of year holiday's, so the next few weeks will probably go by fast. Teams should be focused on development plans, but please be aware if there are any project specific milestone 2 deadlines you need to be aware of. General Information ------------------- Just a reminder about the changes this cycle with library deliverables that follow the cycle-with-milestones release model. As announced, we will be automatically proposing releases for these libraries at milestone 2 if there have been any functional changes since the last release to help ensure those changes are picked up by consumers with plenty of time to identify and correct issues. More detail can be found in the original mailing list post describing the changes: http://lists.openstack.org/pipermail/openstack-dev/2018-October/135689.html There are also a set of deliverables following the cycle-with-intermediary model that are not considered libraries. These are services and other somewhat different deliverables. We want to make sure the cycle-with-intermediary release model is not being used as a way to just perform one final release. The intent of this release model is to have multiple releases throughout a development cycle. If you own one of these deliverables, please think about performing a release if one has not already been done for Stein, or decide if the updated cycle-with-rc release model is more appropriate for your needs. More information can be found here: http://lists.openstack.org/pipermail/openstack-discuss/2018-December/000465… Upcoming Deadlines & Dates -------------------------- Stein-2 Milestone: January 10 -- Sean McGinnis (smcginnis)

1 0

[nova][dev] Bug about disabled compute during scheduling
by Matt Riedemann 05 Dec '18

05 Dec '18

Belmiro/Surya, I'm trying to follow up on something Belmiro mentioned at the summit before I forget about it. CERN sets this value low: https://docs.openstack.org/nova/latest/configuration/config.html#scheduler.… And as a result, when disabling nova-computes during maintenance, you can fail during scheduling because placement only returns resource providers for disabled computes. I believe Dan and I kicked around some ideas on how we could deal with this, like either via a periodic in the compute service or when the compute service is disabled in the API, we would set the 'reserved' inventory value equal to the total to take those computes out of scheduling. I think Belmiro said this is what CERN is doing today as a workaround? For the latter solution, I don't know if we'd proxy that change directly from nova-api to placement, or make an RPC cast/call to nova-compute to do it, but that's an implementation detail. I mostly just want to make sure we get a bug reported for this so we don't lose track of it. Can one of you open a bug with your scenario and current workaround? -- Thanks, Matt

2 1

[tripleo] No weekly meeting on December 25
by Juan Antonio Osorio Robles 05 Dec '18

05 Dec '18

Enjoy the holidays!

1 0

[tripleo] PTL on vacations
by Juan Antonio Osorio Robles 05 Dec '18

05 Dec '18

Hello folks! I'll be on vacations from December 10th to January 2nd. For this reason, I won't be hosting the weekly meetings until I'm back. Best regards

1 0

Octavia Production Deployment Confused
by Zufar Dhiyaulhaq 05 Dec '18

05 Dec '18

Hi, I want to implement Octavia service in OpenStack Queens. I am stuck on two-step : 1. Create Octavia User I am trying to create Octavia user with this command, is this the right way? openstack user create octavia --domain default --password octavia openstack role add --user octavia --project services admin openstack service create --name octavia --description "OpenStack Octavia" load-balancer openstack endpoint create --region RegionOne octavia public http://10.60.60.10:9876 openstack endpoint create --region RegionOne octavia internal http://10.60.60.10:9876 openstack endpoint create --region RegionOne octavia admin http://10.60.60.10:9876 2. Load Balancer Network Configuration "Add appropriate routing to/from the ‘lb-mgmt-net’ such that egress is allowed, and the controller (to be created later) can talk to hosts on this network." I don't know how to route from controller host into a private network, is any specific command for doing that? following tutorial from https://docs.openstack.org/octavia/latest/contributor/guides/dev-quick-star… . Thank You Best Regards, Zufar Dhiyaulhaq

5 5

[goals][upgrade-checkers] Week R-18 Update
by Matt Riedemann 05 Dec '18

05 Dec '18

First, I'm sorry about the big gap in updates, the last one being before the summit. Things have been busy elsewhere. Second, I'm happy to report the majority of projects have merged the initial framework patch for the "$project-status upgrade check" command. There are a few outstanding patches for projects which need core review (I went through this list today and +1 on them): https://review.openstack.org/#/q/topic:upgrade-checkers+status:open There are a few projects adding real upgrade checks as well, like designate and cloudkitty, which is good to see. For projects that have already merged the framework check, please talk in your meetings about what "real" upgrade check you could add in stein to replace the placeholder/sample check that came with the framework patch. Note that checks added in stein don't necessarily need to be for stein upgrade issues, they could be for something that was an upgrade impact in rocky, queens, etc, because with fast-forward upgrades people will be rolling through and might have missed something in the release notes. If you have questions, feel free to reach out to me in #openstack-dev (mriedem) or reply to this thread. -- Thanks, Matt

1 0

What's Happening in the Open Infrastructure Community
by Allison Price 05 Dec '18

05 Dec '18

Hi everyone, This week, we distributed the first Open Infrastructure Community Newsletter. Our goal with the bi-weekly newsletter is to provide a digest of the latest developments and activities across open infrastructure projects, events and users. This week, we highlighted the Berlin Summit as well as brief updates from OpenStack as well as the OSF's four pilot projects: Airship, Kata Containers, StarlingX and Zuul. You can checkout the full newsletter on Superuser [1], and if you are interested in receiving the upcoming newsletters, you can subscribe here [2]. If you would like to contribute or have feedback, please reach out to community(a)openstack.org. Thanks! Allison Allison Price OpenStack Foundation allison(a)openstack.org [1] http://superuser.openstack.org/articles/inside-open-infrastructure-newslett… [2] https://www.openstack.org/community/email-signup

1 0

Proposing KaiFeng Wang for ironic-core
by Julia Kreger 05 Dec '18

05 Dec '18

I'd like to propose adding KaiFeng to the ironic-core reviewer group. Previously, we had granted KaiFeng rights on ironic-inspector-core and I personally think they have done a great job there. Kaifeng has also been reviewing other repositories in ironic's scope[1]. Their reviews and feedback have been insightful and meaningful. They have also been very active[2] at reviewing which is an asset for any project. I believe they will be an awesome addition to the team. -Julia [1]: http://stackalytics.com/?module=ironic-group&user_id=kaifeng [2]: http://stackalytics.com/report/contribution/ironic-group/90

5 4

[TC] Forum TC Vision Retrospective summary
by Julia Kreger 05 Dec '18

05 Dec '18

During the Forum in Berlin, the Technical Committee along with interested community members took some time to look back at the vision that written in early 2017. We had three simple questions: * What went well? * What needs improvement? * What should the next steps be? To summarize, the group thought the vision helped guide some thoughts and decisions. Helped provide validation on what was thought to be important. We have seen adjacent communities fostered. We didn't solely focus on the vision which was viewed as a positive as things do change over time. It helped us contrast, and in the process of writing the vision we reached the use of the same words. Most importantly, we learned that we took on too much work. As with most retrospectives, the list of things that needed improvement was a bit longer. There was some perception that it fell off the map, and that not every item received work. Possibly that we even took the vision too literally and too detailed as opposed to use it as more a guiding document to help us evolve as time goes on. There was consensus that there was still room to improve and that we could have done a better at conveying context to express how, what, and why. For next steps, we feel that it is time to revise the vision, albeit in a shorter form. We also felt that there could be a vision for the TC itself, which led to the discussion of providing clarity to the role of the Technical Committee. As for action items and next steps that we reached consensus on: * To refine the technical vision document. * That it was time to compose a new vision for the community. * Consensus was reached that there should be a vision of the TC itself, and as part of this have a living document that describes the "Role of the TC". ** ttx, cdent, and TheJulia have volunteered to continue those discussions. ** mnaser would start a discussion with the community as to what the TC should and shouldn't do. For those reading this, please remember that the TC's role is defined in the foundation bylaws, so this would be more of a collection of perceptions. * TheJulia to propose a governance update to suggest that people proposing TC candidacy go ahead and preemptively seek to answer the question of what the candidate perceives as the role of the TC. The etherpad that followed the discussion can be found at: https://etherpad.openstack.org/p/BER-tc-vision-retrospective -Julia

3 3