May 2019 - openstack-discuss - lists.openstack.org

[placement][ptg] Open Questions
by Chris Dent 06 May '19

06 May '19

A few questions we failed to resolve during the PTG that we should work out over the next couple of weeks. * There are two specs in progress related to more flexible ways to filter traits: * any trait in allocation candidates https://review.opendev.org/#/c/649992/ * support mixing required traits with any traits https://review.opendev.org/#/c/649368/ Do we have pending non-placement features which depend on the above being completed? I got the impression during the nova-placement xproj session that maybe they were, but it's not clear. Anyone willing to state one way or another? * We had several RFE stories already in progress, and have added a few more during the PTG. We have not done much in the way of prioritizing these. We certainly can't do them all. Here's a link to the current RFE stories in the placement group (this includes placement, osc-placement and os-*). https://storyboard.openstack.org/#!/worklist/594 I've made a simple list of those on an etherpad, please register you +1 or -1 (or nothing) on each of those. Keep in mind that there are several features in "Update nested provider support to address train requirements" and that we've already committed to them. Please let me know what I've forgotten. -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent tw: @anticdent

2 2

[blazar] Scheduling a new Blazar IRC meeting for the Americas
by Pierre Riteau 06 May '19

06 May '19

Hello, Contributors to the Blazar project are currently mostly from Europe or Asia. Our weekly IRC meeting at 0900 UTC is a good match for this group. To foster more contributions, I would like to schedule another IRC meeting in the morning for American timezones, probably every two weeks to start with. I am thinking of proposing 1600 UTC on either Monday, Tuesday, or Thursday, which doesn't appear to conflict with closely related projects (Nova, Placement, Ironic). If there is anyone who would like to join but cannot make this time, or has a preference on which day, please let me know. I will wait for a few days before requesting a meeting slot. Thanks, Pierre

1 1

[neutron] Unable to configure multiple external networks
by valleru＠cbio.mskcc.org 06 May '19

06 May '19

Hello All, I am trying to install Openstack Stein on a single node, with multiple external networks (both networks are also shared). However, i keep getting the following error in the logs, and the router interfaces show as down. 2019-05-06 02:19:45.046 52175 ERROR neutron.agent.l3.agent 2019-05-06 02:19:45.048 52175 INFO neutron.agent.l3.agent [-] Starting router update for a2ec6c99-944e-408a-945a-dffbe09f65ce, action 3, priority 2 2019-05-06 02:19:46.249 52175 ERROR neutron.agent.l3.agent [-] Failed to process compatible router: a2ec6c99-944e-408a-945a-dffbe09f65ce: Exception: The 'gateway_external_network_id' option must be configured for this agent as Neutron has more than one external network. 2019-05-06 02:19:46.249 52175 ERROR neutron.agent.l3.agent Traceback (most recent call last): 2019-05-06 02:19:46.249 52175 ERROR neutron.agent.l3.agent File "/usr/lib/python2.7/site-packages/neutron/agent/l3/agent.py", line 701, in _process_routers_if_compatible 2019-05-06 02:19:46.249 52175 ERROR neutron.agent.l3.agent self._process_router_if_compatible(router) 2019-05-06 02:19:46.249 52175 ERROR neutron.agent.l3.agent File "/usr/lib/python2.7/site-packages/neutron/agent/l3/agent.py", line 548, in _process_router_if_compatible 2019-05-06 02:19:46.249 52175 ERROR neutron.agent.l3.agent target_ex_net_id = self._fetch_external_net_id() 2019-05-06 02:19:46.249 52175 ERROR neutron.agent.l3.agent File "/usr/lib/python2.7/site-packages/neutron/agent/l3/agent.py", line 376, in _fetch_external_net_id 2019-05-06 02:19:46.249 52175 ERROR neutron.agent.l3.agent raise Exception(msg) 2019-05-06 02:19:46.249 52175 ERROR neutron.agent.l3.agent Exception: The 'gateway_external_network_id' option must be configured for this agent as Neutron has more than one external network. 2019-05-06 02:19:46.249 52175 ERROR neutron.agent.l3.agent 2019-05-06 02:19:46.252 52175 WARNING neutron.agent.l3.agent [-] Hit retry limit with router update for a2ec6c99-944e-408a-945a-dffbe09f65ce, action 3 2019-05-06 02:19:46.253 52175 WARNING neutron.agent.l3.agent [-] Info for router a2ec6c99-944e-408a-945a-dffbe09f65ce was not found. Performing router cleanup I have set these parameters to empty, as mentioned in the docs. /etc/neutron/l3_agent.ini gateway_external_network_id = external_network_bridge = interface_driver = openvswitch I tried linuxbridge-agent too,but i could not get rid of the above error. openstack port list --router router1 +--------------------------------------+------+-------------------+----------------------------------------------------------------------------+--------+ | ID | Name | MAC Address | Fixed IP Addresses | Status | +--------------------------------------+------+-------------------+----------------------------------------------------------------------------+--------+ | 1bcaad17-17ed-4383-9206-34417f8fd2df | | fa:16:3e:c1:b1:1f | ip_address='192.168.1.1', subnet_id='b00cb3bf-ca89-4e00-8bd7-83a75dbb6080' | DOWN | | f49d976f-b733-4360-9d1f-cdd35ecf54e6 | | fa:16:3e:54:82:4b | ip_address='10.0.10.11', subnet_id='7cc01a33-f078-494d-9b0b-e988f5b4915d' | DOWN | +--------------------------------------+------+-------------------+----------------------------------------------------------------------------+————+ However it does work when i have just one external network openstack port list --router router1 +--------------------------------------+------+-------------------+--------------------------------------------------------------------------------+--------+ | ID | Name | MAC Address | Fixed IP Addresses | Status | +--------------------------------------+------+-------------------+--------------------------------------------------------------------------------+--------+ | cdb06cf7-7492-4275-bd93-88a46b9769a8 | | fa:16:3e:7c:ea:55 | ip_address='192.168.1.1', subnet_id='b00cb3bf-ca89-4e00-8bd7-83a75dbb6080' | ACTIVE | | fc9b06d7-d377-451b-9af5-07e1fab072dc | | fa:16:3e:d0:6d:7c | ip_address='140.163.188.149', subnet_id='4a2bf30a-e7f8-44c1-8b08-4de01b2b1296' | ACTIVE | +--------------------------------------+------+-------------------+--------------------------------------------------------------------------------+--------+ May i please know, how to get the above working. I have seen multiple articles online that mention that this should be working, however i am unable to get this to work. It is really important for us to have to have 2 external networks in the environment, and be able to route to both of them if possible. Thank you, Lohit

2 3

OpenStack Kubernetes uninitialized taint on minion nodes
by Pawel Konczalski 06 May '19

06 May '19

Hi, i try to deploy a Kubernetes cluster with OpenStack Magnum. So far the deployment works fine except for the uninitialized taints attribute on the worker / minion nodes. This has to be removed manually, only after that is it possible to deploy containers in the cluster. Any idea how to fix / automate this that Magnum automaticaly deploy functional cluster? openstack coe cluster template create kubernetes-cluster-template \ --image Fedora-AtomicHost-29-20190429.0.x86_64 \ --external-network public \ --dns-nameserver 8.8.8.8 \ --master-flavor m1.kubernetes \ --flavor m1.kubernetes \ --coe kubernetes \ --volume-driver cinder \ --network-driver flannel \ --docker-volume-size 25 openstack coe cluster create kubernetes-cluster \ --cluster-template kubernetes-cluster-template \ --master-count 1 \ --node-count 2 \ --keypair mykey kubectl describe nodes | grep Taints [fedora@kubernetes-cluster9-efikj2wr5lsi-master-0 ~]$ kubectl describe nodes | grep Taints Taints: CriticalAddonsOnly=True:NoSchedule Taints: node.cloudprovider.kubernetes.io/uninitialized=true:NoSchedule Taints: node.cloudprovider.kubernetes.io/uninitialized=true:NoSchedule kubectl taint nodes --all node.cloudprovider.kubernetes.io/uninitialized- [root@kubernetes-cluster31-vrmbz6yjvuvd-master-0 /]# kubectl describe nodes | grep Taints Taints: dedicated=master:NoSchedule Taints: <none> Taints: <none> BR Pawel

1 0

[octavia] Amphora agent returned unexpected result code 500
by Volodymyr Litovka 06 May '19

06 May '19

Dear colleagues, trying to launch Amphorae, getting the following error in logs: Amphora agent returned unexpected result code 500 with response {'message': 'Error plugging VIP', 'details': 'SIOCADDRT: Network is unreachable\nFailed to bring up eth1.\n'} While details below, questions are here: - whether it's enough to assign roles as explained below to special project for Octavia? - whether it can be issue with image, created by diskimage_create.sh? - any recommendation on where to search for the problem. Thank you. My environment is: - Openstack Rocky - Octavia 4.0 - amphora instance runs in special project "octavia", where users octavia, nova and neutron have admin role - amphora image prepared using original git repo process and elements without modification: * git clone <octavia> * cd octavia * diskimage-create/diskimage-create.sh * openstack image create [ ... ] --tag amphora After created, amphora instance successfully connects to management network and can be accessed by controller: 2019-05-05 20:46:06.851 18234 DEBUG octavia.amphorae.drivers.haproxy.rest_api_driver [-] Connected to amphora. Response: <Response [200]> request /opt/openstack/lib/python3.6/site-packages/octavia/amphorae/drivers/haproxy/rest_api_driver.py:486 2019-05-05 20:46:06.852 18234 DEBUG octavia.controller.worker.tasks.amphora_driver_tasks [-] Successfuly connected to amphora 5bec4c09-a209-4e73-a66e-e4fc0fb8ded5: {'ipvsadm_version': '1:1.28-3', 'api_version': '0.5', 'haproxy_version': '1.6.3-1ubuntu0.2', 'hostname': 'amphora-5bec4c09-a209-4e73-a66e-e4fc0fb8ded5', 'keepalived_version': '1:1.2.24-1ubuntu0.16.04.1'} execute /opt/openstack/lib/python3.6/site-packages/octavia/controller/worker/tasks/amphora_driver_tasks.py:372 [ ... ] 2019-05-05 20:46:06.990 18234 DEBUG octavia.controller.worker.tasks.network_tasks [-] Plumbing VIP for amphora id: 5bec4c09-a209-4e73-a66e-e4fc0fb8ded5 execute /opt/openstack/lib/python3.6/site-packages/octavia/controller/worker/tasks/network_tasks.py:382 2019-05-05 20:46:07.003 18234 DEBUG octavia.network.drivers.neutron.base [-] Neutron extension security-group found enabled _check_extension_enabled /opt/openstack/lib/python3.6/site-packages/octavia/network/drivers/neutron/base.py:66 2019-05-05 20:46:07.013 18234 DEBUG octavia.network.drivers.neutron.base [-] Neutron extension dns-integration found enabled _check_extension_enabled /opt/openstack/lib/python3.6/site-packages/octavia/network/drivers/neutron/base.py:66 2019-05-05 20:46:07.025 18234 DEBUG octavia.network.drivers.neutron.base [-] Neutron extension qos found enabled _check_extension_enabled /opt/openstack/lib/python3.6/site-packages/octavia/network/drivers/neutron/base.py:66 2019-05-05 20:46:07.044 18234 DEBUG octavia.network.drivers.neutron.base [-] Neutron extension allowed-address-pairs found enabled _check_extension_enabled /opt/openstack/lib/python3.6/site-packages/octavia/network/drivers/neutron/base.py:66 2019-05-05 20:46:08.406 18234 DEBUG octavia.network.drivers.neutron.allowed_address_pairs [-] Created vip port: b0398cc8-6d52-4f12-9f1f-1141b0f10751 for amphora: 5bec4c09-a209-4e73-a66e-e4fc0fb8ded5 _plug_amphora_vip /opt/openstack/lib/python3.6/site-packages/octavia/network/drivers/neutron/allowed_address_pairs.py:97 [ ... ] 2019-05-05 20:46:15.405 18234 DEBUG octavia.network.drivers.neutron.allowed_address_pairs [-] Retrieving network details for amphora 5bec4c09-a209-4e73-a66e-e4fc0fb8ded5 _get_amp_net_configs /opt/openstack/lib/python3.6/site-packages/octavia/network/drivers/neutron/allowed_address_pairs.py:596 [ ... ] 2019-05-05 20:46:15.837 18234 DEBUG octavia.amphorae.drivers.haproxy.rest_api_driver [-] Post-VIP-Plugging with vrrp_ip 10.0.2.13 vrrp_port b0398cc8-6d52-4f12-9f1f-1141b0f10751 post_vip_plug /opt/openstack/lib/python3.6/site-packages/octavia/amphorae/drivers/haproxy/rest_api_driver.py:233 2019-05-05 20:46:15.838 18234 DEBUG octavia.amphorae.drivers.haproxy.rest_api_driver [-] request url plug/vip/10.0.2.24 request /opt/openstack/lib/python3.6/site-packages/octavia/amphorae/drivers/haproxy/rest_api_driver.py:462 2019-05-05 20:46:15.838 18234 DEBUG octavia.amphorae.drivers.haproxy.rest_api_driver [-] request url https://172.16.252.35:9443/0.5/plug/vip/10.0.2.24 request /opt/openstack/lib/python3.6/site-packages/octavia/amphorae/drivers/haproxy/rest_api_driver.py:465 2019-05-05 20:46:16.089 18234 DEBUG octavia.amphorae.drivers.haproxy.rest_api_driver [-] Connected to amphora. Response: <Response [500]> request /opt/openstack/lib/python3.6/site-packages/octavia/amphorae/drivers/haproxy/rest_api_driver.py:486 2019-05-05 20:46:16.090 18234 ERROR octavia.amphorae.drivers.haproxy.exceptions [-] Amphora agent returned unexpected result code 500 with response {'message': 'Error plugging VIP', 'details': 'SIOCADDRT: Network is unreachable\nFailed to bring up eth1.\n'} During the process, NEUTRON logs contains the following records that indicate the following (note "status=DOWN" in neutron-dhcp-agent; later immediately before to be deleted, it will shed 'ACTIVE'): May 5 20:46:13 ardbeg neutron-dhcp-agent: 2019-05-05 20:46:13.857 1804 INFO neutron.agent.dhcp.agent [req-07833602-9579-403b-a264-76fd3ee408ee a18f38c780074c6280dde5edad159666 41a02a69918849509f4102b04f8a7de9 - - -] Trigger reload_allocations for port admin_state_up=True, allowed_address_pairs=[{u'ip_address': u'10.0.2.24', u'mac_address': u'72:d0:1c:4c:94:91'}], binding:host_id=ardbeg, binding:profile=, binding:vif_details=datapath_type=system, ovs_hybrid_plug=False, port_filter=True, binding:vif_type=ovs, binding:vnic_type=normal, created_at=2019-05-05T20:46:07Z, description=, device_id=f1bce6e9-be5b-464b-8f64-686f36e9de1f, device_owner=compute:nova, dns_assignment=[{u'hostname': u'amphora-5bec4c09-a209-4e73-a66e-e4fc0fb8ded5', u'ip_address': u'10.0.2.13', u'fqdn': u'amphora-5bec4c09-a209-4e73-a66e-e4fc0fb8ded5.loqal.'}], dns_domain=, dns_name=amphora-5bec4c09-a209-4e73-a66e-e4fc0fb8ded5, extra_dhcp_opts=[], fixed_ips=[{u'subnet_id': u'24b10886-3d53-4aee-bdc6-f165b242ae4f', u'ip_address': u'10.0.2.13'}], id=b0398cc8-6d52-4f12-9f1f-1141b0f10751, mac_address=72:d0:1c:4c:94:91, name=octavia-lb-vrrp-5bec4c09-a209-4e73-a66e-e4fc0fb8ded5, network_id=b24d2830-eec6-4abd-82f2-ac71c8ecbf40, port_security_enabled=True, project_id=41a02a69918849509f4102b04f8a7de9, qos_policy_id=None, revision_number=5, security_groups=[u'6df53a15-6afc-4c99-b464-03de4f546b4f'], status=DOWN, tags=[], tenant_id=41a02a69918849509f4102b04f8a7de9, updated_at=2019-05-05T20:46:13Z May 5 20:46:14 ardbeg neutron-openvswitch-agent: 2019-05-05 20:46:14.185 31542 INFO neutron.plugins.ml2.drivers.openvswitch.agent.ovs_neutron_agent [req-a4425cdb-afc1-4f6a-9ef9-c8706e3285d6 - - - - -] Port b0398cc8-6d52-4f12-9f1f-1141b0f10751 updated. Details: {'profile': {}, 'network_qos_policy_id': None, 'qos_policy_id': None, 'allowed_address_pairs': [{'ip_address': AuthenticIPNetwork('10.0.2.24'), 'mac_address': EUI('72:d0:1c:4c:94:91')}], 'admin_state_up': True, 'network_id': 'b24d2830-eec6-4abd-82f2-ac71c8ecbf40', 'segmentation_id': 437, 'fixed_ips': [{'subnet_id': '24b10886-3d53-4aee-bdc6-f165b242ae4f', 'ip_address': '10.0.2.13'}], 'device_owner': u'compute:nova', 'physical_network': None, 'mac_address': '72:d0:1c:4c:94:91', 'device': u'b0398cc8-6d52-4f12-9f1f-1141b0f10751', 'port_security_enabled': True, 'port_id': 'b0398cc8-6d52-4f12-9f1f-1141b0f10751', 'network_type': u'vxlan', 'security_groups': [u'6df53a15-6afc-4c99-b464-03de4f546b4f']} May 5 20:46:14 ardbeg neutron-openvswitch-agent: 2019-05-05 20:46:14.197 31542 INFO neutron.agent.securitygroups_rpc [req-a4425cdb-afc1-4f6a-9ef9-c8706e3285d6 - - - - -] Preparing filters for devices set([u'b0398cc8-6d52-4f12-9f1f-1141b0f10751']) Note Nova returns response 200/completed: May 5 20:46:14 controller-l neutron-server: 2019-05-05 20:46:14.326 20981 INFO neutron.notifiers.nova [-] Nova event response: {u'status': u'completed', u'tag': u'b0398cc8-6d52-4f12-9f1f-1141b0f10751', u'name': u'network-changed', u'server_uuid': u'f1bce6e9-be5b-464b-8f64-686f36e9de1f', u'code': 200} and "openstack server show" shows both NICs are attached to the amphorae: $ openstack server show f1bce6e9-be5b-464b-8f64-686f36e9de1f +-------------------------------------+------------------------------------------------------------+ | Field | Value | +-------------------------------------+------------------------------------------------------------+ [ ... ] | addresses | octavia-net=172.16.252.35; u1000-p1000-xbone=10.0.2.13 | +-------------------------------------+------------------------------------------------------------+ Later Octavia worker reports the following: 2019-05-05 20:46:16.124 18234 DEBUG octavia.controller.worker.controller_worker [-] Task 'STANDALONE-octavia-plug-net-subflow-octavia-amp-post-vip-plug' (f105ced1-72c6-4116-b582-599a21cdee36) transitioned into state 'REVERTING' from state 'FAILURE' _task_receiver /opt/openstack/lib/python3.6/site-packages/taskflow/listeners/logging.py:194 2019-05-05 20:46:16.127 18234 WARNING octavia.controller.worker.controller_worker [-] Task 'STANDALONE-octavia-plug-net-subflow-octavia-amp-post-vip-plug' (f105ced1-72c6-4116-b582-599a21cdee36) transitioned into state 'REVERTED' from state 'REVERTING' with result 'None' 2019-05-05 20:46:16.141 18234 DEBUG octavia.controller.worker.controller_worker [-] Task 'STANDALONE-octavia-plug-net-subflow-reload-amp-after-plug-vip' (c4d6222e-2508-4a9c-9514-e7f9bcf84e31) transitioned into state 'REVERTING' from state 'SUCCESS' _task_receiver /opt/openstack/lib/python3.6/site-packages/taskflow/listeners/logging.py:194 2019-05-05 20:46:16.142 18234 WARNING octavia.controller.worker.controller_worker [-] Task 'STANDALONE-octavia-plug-net-subflow-reload-amp-after-plug-vip' (c4d6222e-2508-4a9c-9514-e7f9bcf84e31) transitioned into state 'REVERTED' from state 'REVERTING' with result 'None' 2019-05-05 20:46:16.146 18234 DEBUG octavia.controller.worker.controller_worker [-] Task 'STANDALONE-octavia-plug-net-subflow-ocatvia-amp-update-vip-data' (2e1d1a04-282d-43b7-8c4f-fe31e75804ea) transitioned into state 'REVERTING' from state 'SUCCESS' _task_receiver /opt/openstack/lib/python3.6/site-packages/taskflow/listeners/logging.py:194 2019-05-05 20:46:16.148 18234 WARNING octavia.controller.worker.controller_worker [-] Task 'STANDALONE-octavia-plug-net-subflow-ocatvia-amp-update-vip-data' (2e1d1a04-282d-43b7-8c4f-fe31e75804ea) transitioned into state 'REVERTED' from state 'REVERTING' with result 'None' 2019-05-05 20:46:16.173 18234 DEBUG octavia.controller.worker.controller_worker [-] Task 'STANDALONE-octavia-plug-net-subflow-octavia-amp-plug-vip' (c63a5bed-f531-4ed3-83d2-bce72e835932) transitioned into state 'REVERTING' from state 'SUCCESS' _task_receiver /opt/openstack/lib/python3.6/site-packages/taskflow/listeners/logging.py:194 2019-05-05 20:46:16.174 18234 WARNING octavia.controller.worker.tasks.network_tasks [-] Unable to plug VIP for amphora id 5bec4c09-a209-4e73-a66e-e4fc0fb8ded5 load balancer id e01c6ff5-179a-4ed5-ae5d-1d00d6c584b8 and Neutron then deletes port but NOTE that immediately before deletion port reported by neutron-dhcp-agent as ACTIVE: May 5 20:46:17 ardbeg neutron-dhcp-agent: 2019-05-05 20:46:17.080 1804 INFO neutron.agent.dhcp.agent [req-835e5b91-28e5-44b9-a463-d04a0323294f a18f38c780074c6280dde5edad159666 41a02a69918849509f4102b04f8a7de9 - - -] Trigger reload_allocations for port admin_state_up=True, allowed_address_pairs=[], binding:host_id=ardbeg, binding:profile=, binding:vif_details=datapath_type=system, ovs_hybrid_plug=False, port_filter=True, binding:vif_type=ovs, binding:vnic_type=normal, created_at=2019-05-05T20:46:07Z, description=, device_id=f1bce6e9-be5b-464b-8f64-686f36e9de1f, device_owner=compute:nova, dns_assignment=[{u'hostname': u'amphora-5bec4c09-a209-4e73-a66e-e4fc0fb8ded5', u'ip_address': u'10.0.2.13', u'fqdn': u'amphora-5bec4c09-a209-4e73-a66e-e4fc0fb8ded5.loqal.'}], dns_domain=, dns_name=amphora-5bec4c09-a209-4e73-a66e-e4fc0fb8ded5, extra_dhcp_opts=[], fixed_ips=[{u'subnet_id': u'24b10886-3d53-4aee-bdc6-f165b242ae4f', u'ip_address': u'10.0.2.13'}], id=b0398cc8-6d52-4f12-9f1f-1141b0f10751, mac_address=72:d0:1c:4c:94:91, name=octavia-lb-vrrp-5bec4c09-a209-4e73-a66e-e4fc0fb8ded5, network_id=b24d2830-eec6-4abd-82f2-ac71c8ecbf40, port_security_enabled=True, project_id=41a02a69918849509f4102b04f8a7de9, qos_policy_id=None, revision_number=8, security_groups=[u'ba20352e-95b9-4c97-a688-59d44e3aa8cf'], status=ACTIVE, tags=[], tenant_id=41a02a69918849509f4102b04f8a7de9, updated_at=2019-05-05T20:46:16Z May 5 20:46:17 controller-l neutron-server: 2019-05-05 20:46:17.086 20981 INFO neutron.wsgi [req-835e5b91-28e5-44b9-a463-d04a0323294f a18f38c780074c6280dde5edad159666 41a02a69918849509f4102b04f8a7de9 - default default] 10.0.10.31 "PUT /v2.0/ports/b0398cc8-6d52-4f12-9f1f-1141b0f10751 HTTP/1.1" status: 200 len: 1395 time: 0.6318841 May 5 20:46:17 controller-l neutron-server: 2019-05-05 20:46:17.153 20981 INFO neutron.wsgi [req-37ee0da3-8dcc-4fb8-9cd3-91c5a8dcedef a18f38c780074c6280dde5edad159666 41a02a69918849509f4102b04f8a7de9 - default default] 10.0.10.31 "GET /v2.0/ports/b0398cc8-6d52-4f12-9f1f-1141b0f10751 HTTP/1.1" status: 200 len: 1395 time: 0.0616651 May 5 20:46:18 controller-l neutron-server: 2019-05-05 20:46:18.179 20981 INFO neutron.wsgi [req-8896542e-5dcb-4e6d-9379-04cd88c4035b a18f38c780074c6280dde5edad159666 41a02a69918849509f4102b04f8a7de9 - default default] 10.0.10.31 "DELETE /v2.0/ports/b0398cc8-6d52-4f12-9f1f-1141b0f10751 HTTP/1.1" status: 204 len: 149 time: 1.0199890 Thank you. -- Volodymyr Litovka "Vision without Execution is Hallucination." -- Thomas Edison

1 1

[tripleo] deprecating keepalived support
by Emilien Macchi 06 May '19

06 May '19

We introduced Keepalived a long time ago when we wanted to manage virtual IPs (VIPs) on the Undercloud when SSL is enabled and also for an HA alternative to Pacemaker on the overcloud, The multi-node undercloud with more than once instance of Keepalived never got attraction (so VRRP hasn't been useful for us), and Pacemaker is the de-facto tool to control HA VIPs on the Overcloud. Therefore, let's continue to trim-down our services and deprecate Keepalived. https://blueprints.launchpad.net/tripleo/+spec/replace-keepalived-undercloud The creation of control plane IP & public host IP can be done with os-net-config, and the upgrade path is simple. I've been working on 2 patches: # Introduce tripleo-container-rpm role https://review.opendev.org/#/c/657279/ Deprecate tripleo-docker-rm and add a generic role which supports both Docker & Podman. In the case of Podman, we cleanup the systemd services and container. # Deprecate Keepalived https://review.opendev.org/#/c/657067/ Remove Keepalived from all the roles, deprecate the service, tear-down Keepalived from the HAproxy service (if it was running), and use os-net-config to configure the interfaces previously managed by Keepalived service. I've tested the upgrade and it seems to work fine: https://asciinema.org/a/MpKBYU1PFvXcYai7aHUwy79LK Please let us know any concern and we'll address it. Thanks, -- Emilien Macchi

1 0

[vitrage] No IRC meeting this week
by Ifat Afek 06 May '19

06 May '19

Hi, The IRC meeting this week is canceled, since most of Vitrage contributors will be on vacation. We will meet again on Wednesday, May 15. Thanks, Ifat

1 0

[I18n] Translation plan Train
by Frank Kloeker 05 May '19

05 May '19

Hello Stackers, hopefully you enjoyed the time during the Open Infra Summit and the PTG in Denver - onsite or remotely. Maybe you inspired also the spirit from something new which will start from now on. As usually we at I18n after release we merge translations back from stable branch to master and starting with a new translation plan [1]. Without a simple copy of the last one I investigated project status under the help of commits and the OpenStack Health Tracker. That's very helpful to see which projects are active and which one have a break, so we can adjust translation priority. At the end the translation plan will be a little bit shorter and we have enough space to onboard new stuff. Additional project docs are not decided yet. But we have the new projects outside OpenStack like Airship, StarlingX and Zuul and if you think on the next Summit in Shanghai and the target downstream users, a translated version of user interfaces or documentation might be useful. If you have questions or remarks, let me know, or Ian, or the list :) Frank [1] https://translate.openstack.org/version-group/view/Train-dashboard-translat…

1 0

[placement][ironic][blazar] Summary: Placment + Ironic and Blazar
by Chris Dent 05 May '19

05 May '19

There were a few different discussions about Ironic using placement in various ways. On line 117 (for now) of the placement PTG etherpad [1] there are some notes about things that Ironic and Blazar could do for reservations. These are not expected to require any changes in placement. Dmitry and Tetsuro may have more to say about this. There was also a separate discussion about the options for using Placement do granular/detailed expression of available resources but full/chunky consumption of resources in a context where Ironic is running without Nova. That is: * record inventory for baremental nodes that say the inventory of node1 is CPU:24,DISK_GB:1048576,MEMORY_MB=1073741824 (and whatever else). * query something smaller (eg CPU:8,DISK_GB:524288,MEMORY_MB:536870912) in a GET /allocation_candidates * include node1 in the results along with others, let the client side sort using provider summaries * send back some mode of allocation that consumes the entire inventory of node1 There were a few different ideas on how to do that last step. One idea would have required different resource providers have an attribute that caused a change in behavior when allocated to. This was dismissed as "too much business logic in the guts". Another option was a flag on PUT /allocations that says "consume everything, despite what I've said". However, the option that was most favored was a new endpoint (name to be determined later if we ever do this) that is for the purpose of "fullly consuming the named resource provider". Clearly this is something that fairly contrary to how Nova imagines baremetal instances, but makes pretty good sense outside of the context where people want to be able to use placement to simultaneously get a flexible view of their baremetal resources and also track them accurately. There are no immediate plans to do this, but there are plans for Dmitry to continue investigating the options and seeing what can or cannot work. Having the feature described above would make things cleaner. I have made a placeholder (and low priority) story [2] that will link back to this email. [1] https://etherpad.openstack.org/p/placement-ptg-train [2] https://storyboard.openstack.org/#!/story/2005575 -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent tw: @anticdent

1 0

[sahara][all] Sahara virtual PTG reminder (approaching quickly!)
by Jeremy Freudberg 05 May '19

05 May '19

The Sahara virtual PTG will take place Monday, May 6, at 15:00 UTC. All are welcome. Etherpad link: https://etherpad.openstack.org/p/sahara-train-ptg Bluejeans link: https://bluejeans.com/6304900378

1 0