- openstack-discuss - lists.openstack.org

[tc] Technical Committee Status for 17 Dec 2081
by Doug Hellmann 20 Dec '18

20 Dec '18

This is the (mostly) 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 == Project updates: * Add os-resource-classes under Nova: https://review.openstack.org/#/c/621699/ Other updates: * I added a TC "house rule" for voting on updates to the release management metadata for projects, to make it easier to keep those up to date: https://review.openstack.org/#/c/622989/ * 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/622902/ ** https://review.openstack.org/#/c/622903/ ** https://review.openstack.org/#/c/622904/ ** https://review.openstack.org/#/c/624704/ ** https://review.openstack.org/#/c/624951/ ** https://review.openstack.org/#/c/624996/ * I updated the documentation of chair responsibilities to include the OSF annual report: https://review.openstack.org/#/c/624790/ * Lance proposed an update to document the process for changing PTLs in the middle of a cycle: https://review.openstack.org/#/c/620928/ * Ghanshyam proposed an update to clarify the term of TC chair, since some responsibilities include managing the election fo the next chair: https://review.openstack.org/#/c/621498/ * Zane's resolution describing how we will keep up with future Python 3 releases has been approved: https://review.openstack.org/#/c/613145/ * Thierry and Chris' work to document the role of the TC has been approved: https://review.openstack.org/#/c/622400/ * I documented the official topic tags used to designate the voting rules to apply to each governance patch: https://review.openstack.org/#/c/625004/ == TC Meetings == The next TC meeting will be 3 December @ 1400 UTC in #openstack-tc. See http://eavesdrop.openstack.org/#Technical_Committee_Meeting for details == Ongoing Discussions == Ghanshyam has proposed an enhancement to the Vision for OpenStack Clouds to cover feature discovery. * https://review.openstack.org/#/c/621516/ I have proposed an update to the TC house voting rules to cover documentation changes in the governance repository. * https://review.openstack.org/625005 Dougal Matthews is stepping down as Mistral PTL, to be replaced by Renat Akhmerov. * https://review.openstack.org/#/c/625537/ == TC member actions/focus/discussions for the coming week(s) == We need to work to approve Sean's patch with the Stein supported/testing runtimes list. * https://review.openstack.org/611080 Thierry started a thread on the mailing list about adapting our office hours times. It would be good for us to resolve that so we can make the change after the new year, so I have renewed the thread with a summary of the options. Please vote. * http://lists.openstack.org/pipermail/openstack-discuss/2018-December/001036… == 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 4

[networking-ovs-dpdk] Issue creating br-ex...
by d.lake＠surrey.ac.uk 20 Dec '18

20 Dec '18

Hello Trying to re-run a Queens DPDK all-in-one using devstack which I built in August and hitting issues. The local.conf is identical between the two machines except I had to take the "stable/queens" off the end of the "networking-ovs-dpdk" plugin line as that no longer appears to work. The installation seems to proceed until it gets to setting the ip mtu on br-ex. I'm not using br-ex. I've declared OVS bridge mappings in the local.conf: #Dual socket platform with 16GB RAM,3072*2048kB hugepages leaves ~4G for the system. OVS_NUM_HUGEPAGES=3072 #Dual socket platform with 64GB RAM,14336*2048kB hugepages leaves ~6G for the system. #OVS_NUM_HUGEPAGES=14336 OVS_DATAPATH_TYPE=netdev OVS_LOG_DIR=/opt/stack/logs #OVS_DPDK_PORT_MAPPINGS=p1p1:br-dpdk1,p1p2:br-dpdk2,p2p1:br-dpdk3,p2p2:br-dpdk4 OVS_DPDK_PORT_MAPPINGS=p6p1:br-dpdk1,p6p2:br-dpdk2 #OVS_BRIDGE_MAPPINGS=physnet1:br-dpdk1,physnet2:br-dpdk2,physnet3:br-dpdk3,physnet4:br-dpdk4 OVS_BRIDGE_MAPPINGS=physnet1:br-dpdk1,physnet2:br-dpdk2 [[post-config|$NOVA_CONF]] [DEFAULT] firewall_driver=nova.virt.firewall.NoopFirewallDriver scheduler_default_filters=RamFilter,ComputeFilter,AvailabilityZoneFilter,ComputeCapabilitiesFilter,ImagePropertiesFilter,PciPassthroughFilter [[post-config|/etc/neutron/plugins/ml2/ml2_conf.ini]] [OVS] datapath_type=netdev [ml2_type_flat] #flat_networks=physnet1,physnet2,physnet3,physnet4 flat_networks=physnet1,physnet2 I cannot stress again how identical these systems are - same hardware, same base OS install (CentOS 7.5). I was (maybe erroneously!) thinking that if I had it devstack working on one system, having an identical system would be a piece of cake to install. This is the installation error: +lib/neutron_plugins/ovs_base:_neutron_ovs_base_add_bridge:21 local bridge=br-ex +lib/neutron_plugins/ovs_base:_neutron_ovs_base_add_bridge:22 local 'addbr_cmd=sudo ovs-vsctl -- --may-exist add-br br-ex' +lib/neutron_plugins/ovs_base:_neutron_ovs_base_add_bridge:24 '[' netdev '!=' system ']' +lib/neutron_plugins/ovs_base:_neutron_ovs_base_add_bridge:25 addbr_cmd='sudo ovs-vsctl -- --may-exist add-br br-ex -- set Bridge br-ex datapath_type=netdev' +lib/neutron_plugins/ovs_base:_neutron_ovs_base_add_bridge:28 sudo ovs-vsctl -- --may-exist add-br br-ex -- set Bridge br-ex datapath_type=netdev +lib/neutron_plugins/ovs_base:_neutron_ovs_base_add_public_bridge:119 set_mtu br-ex 1500 +functions:set_mtu:750 local dev=br-ex +functions:set_mtu:751 local mtu=1500 +functions:set_mtu:752 sudo ip link set mtu 1500 dev br-ex Cannot find device "br-ex" +functions:set_mtu:1 exit_trap +./stack.sh:exit_trap:522 local r=1 ++./stack.sh:exit_trap:523 jobs -p +./stack.sh:exit_trap:523 jobs= +./stack.sh:exit_trap:526 [[ -n '' ]] +./stack.sh:exit_trap:532 '[' -f /tmp/tmp.Dzbqzlk2fs ']' +./stack.sh:exit_trap:533 rm /tmp/tmp.Dzbqzlk2fs +./stack.sh:exit_trap:537 kill_spinner +./stack.sh:kill_spinner:432 '[' '!' -z '' ']' +./stack.sh:exit_trap:539 [[ 1 -ne 0 ]] +./stack.sh:exit_trap:540 echo 'Error on exit' Error on exit +./stack.sh:exit_trap:542 type -p generate-subunit +./stack.sh:exit_trap:543 generate-subunit 1545230781 1747 fail +./stack.sh:exit_trap:545 [[ -z /opt/stack/logs/screen ]] +./stack.sh:exit_trap:548 /home/stack/devstack/tools/worlddump.py -d /opt/stack/logs/screen Can someone explain what is going on here please? Thanks David

3 4

[tc] Adapting office hours schedule to demand
by Thierry Carrez 20 Dec '18

20 Dec '18

Hi, A while ago, the Technical Committee designated specific hours in the week where members would make extra effort to be around on #openstack-tc on IRC, so that community members looking for answers to their questions or wanting to engage can find a time convenient for them and a critical mass of TC members around. We currently have 3 weekly spots: - 09:00 UTC on Tuesdays - 01:00 UTC on Wednesdays - 15:00 UTC on Thursdays But after a few months it appears that: 1/ nobody really comes on channel at office hour time to ask questions. We had a questions on the #openstack-tc IRC channel, but I wouldn't say people take benefit of the synced time 2/ some office hours (most notably the 01:00 UTC on Wednesdays, but also to a lesser extent the 09:00 UTC on Tuesdays) end up just being a couple of TC members present So the schedule is definitely not reaching its objectives, and as such may be a bit overkill. I was also wondering if this is not a case where the offer is hurting the demand -- by having so many office hour spots around, nobody considers them special. Should we: - Reduce office hours to one or two per week, possibly rotating times - Dump the whole idea and just encourage people to ask questions at any time on #openstack-tc, and get asynchronous answers - Keep it as-is, it still has the side benefit of triggering spikes of TC member activity Thoughts ? -- Thierry Carrez (ttx)

9 19

[magnum] Magnum missing project ID for octavia client
by Zufar Dhiyaulhaq 20 Dec '18

20 Dec '18

Hi, I am trying to create Kubenetes multi-master with Magnum. I get 'Create Failed error` in etcd_lb and api_lb and the log is : OctaviaClientException: resources.etcd_lb.resources.loadbalancer: Validation failure: Missing project ID in requea-8cce-27a3c49b9d28) full log from /var/log/magnum/magnum-conductor.api : 2018-12-20 22:41:33.362 9733 ERROR magnum.drivers.heat.driver [req-98498689-f584-47ab-b500-839a9e0d07cc - - - - -] Cluster error, stack staton: Resource CREATE failed: OctaviaClientException: resources.etcd_lb.resources.loadbalancer: Validation failure: Missing project ID in requ2a-8cce-27a3c49b9d28) I have working Octavia and magnum (only with 1 master, kubernetes or docker), this is my magnum configuration : [api] host = 10.111.111.10 [certificates] cert_manager_type = x509keypair [database] connection = mysql+pymysql:// magnum:556a8c5002cce3d8933@10.111.111.100/magnum [keystone_authtoken] memcached_servers = 10.111.111.10:11211,10.111.111.20:11211, 10.111.111.30:11211 auth_version = v3 auth_uri = http://10.111.111.100:5000/v3 project_domain_id = default project_name = service user_domain_id = default password = a13dfbbac5a0e03754773 username = magnum auth_url = http://10.111.111.100:35357 auth_type = password admin_user = magnum admin_password = a13dfbbac5a0e03754773 admin_tenant_name = service [trust] trustee_domain_name = magnum trustee_domain_admin_name = magnum_domain_admin trustee_domain_admin_password = b13dfbbac5a0e03754773 trustee_keystone_interface = public [oslo_messaging_notifications] driver = messaging [DEFAULT] transport_url=rabbit://openstack:5e81fb9286a573a1e4e33@10.111.111.10:5672, openstack:5e81fb9286a573a1e4e3@10.111.111.20:5672, openstack:5e81fb9286a573a1e4e3@10.111.111.30:5672 log_dir=/var/log/magnum [cinder_client] region_name = RegionOne [octavia_client] region_name = RegionOne Anyone know what is the problem? Thank you. Best Regards, Zufar Dhiyaulhaq

1 0

[openstack-ansible][cinder] Multiple backends for Cinder
by Cecilia Di Maulo 20 Dec '18

20 Dec '18

Dear all, I currently have a NFS backend for Cinder and I would like to add an iSCSI (hpmsa) backend. However I was wondering where should the cinder services run? For now cinder-api.service and cinder-scheduler.service run in a lxc while cinder-volume.service runs in bare metal on the controllers. I also would like to separate as much as possible the 2 backend types to be able to remove 'easily' my NFS backend once the other one has proved it really works. I was thinking to have the services related to the NFS backend in a lxc and the services related to the HPMSA backend on metal. Is this even possible? How should I do it? Should I name 2 different services in the container_skel or..? Thank you for your help, Best Regards, Cecilia

2 1

[IRONIC] vif attached to baremetal node DOWN
by Manuel Sopena Ballesteros 20 Dec '18

20 Dec '18

Dear Openstack community, I am having huge problems setting up baremetal port group: PROBLEM: VIF DOWN Environment: Openstack Rocky Deployment: kolla-ansible 7.0.0 Provider network # SERVER AND NEUTRON PORTS ########################## [root@openstack-deployment ~]# openstack server list +--------------------------------------+------------+--------+-----------------+-------------------+---------------------+ | ID | Name | Status | Networks | Image | Flavor | +--------------------------------------+------------+--------+-----------------+-------------------+---------------------+ | ce8e10ab-12b4-476e-8990-b2aeda8510a0 | demo1 | ACTIVE | hpc=10.0.32.103 | centos7.5-image | my-baremetal-flavor | ... +--------------------------------------+------------+--------+-----------------+-------------------+---------------------+ [root@openstack-deployment ~]# openstack port list +--------------------------------------+------+-------------------+----------------------------------------------------------------------------+--------+ | ID | Name | MAC Address | Fixed IP Addresses | Status | +--------------------------------------+------+-------------------+----------------------------------------------------------------------------+--------+ | 1e1c3f40-1ee0-46d1-8e38-0b0617893ccf | | 7c:fe:90:12:1f:f0 | ip_address='10.0.32.103', subnet_id='506af593-659b-4c58-a180-897dd0b04957' | DOWN | ... +--------------------------------------+------+-------------------+----------------------------------------------------------------------------+--------+ # BAREMETAL PORT GROUP ###################### [root@openstack-deployment ~]# openstack baremetal port group show 2de8c1ae-a5bf-418e-b07a-1c0fbf676f36 +----------------------------+------------------------------------------------------------------------------------+ | Field | Value | +----------------------------+------------------------------------------------------------------------------------+ | address | 7c:fe:90:12:1f:f0 | | created_at | 2018-12-20T14:27:53+00:00 | | extra | {} | | internal_info | {u'tenant_vif_port_id': u'1e1c3f40-1ee0-46d1-8e38-0b0617893ccf'} | | mode | 802.3ad | | name | zeus-54-hpc-bond | | node_uuid | e30e76a4-a39e-4560-9bff-d3d9af66c503 | | properties | {u'downdelay': 0, u'miimon': 110, u'xmit_hash_policy': u'layer2+3', u'updelay': 0} | | standalone_ports_supported | False | | updated_at | 2018-12-20T14:28:57+00:00 | | uuid | 2de8c1ae-a5bf-418e-b07a-1c0fbf676f36 | +----------------------------+------------------------------------------------------------------------------------+ # BAREMETAL PORTS ################## [root@openstack-deployment ~]# openstack baremetal port show 4a00e6fa-a7c1-4916-b540-01fef95c90c1 +-----------------------+--------------------------------------+ | Field | Value | +-----------------------+--------------------------------------+ | address | 7c:fe:90:12:1f:f0 | | created_at | 2018-12-20T14:28:09+00:00 | | extra | {} | | internal_info | {} | | local_link_connection | {} | | node_uuid | e30e76a4-a39e-4560-9bff-d3d9af66c503 | | physical_network | physnet1 | | portgroup_uuid | 2de8c1ae-a5bf-418e-b07a-1c0fbf676f36 | | pxe_enabled | True | | updated_at | None | | uuid | 4a00e6fa-a7c1-4916-b540-01fef95c90c1 | +-----------------------+--------------------------------------+ [root@openstack-deployment ~]# openstack baremetal port show 4510e849-ed21-46f8-bf4c-ca91c7e6b648 +-----------------------+--------------------------------------+ | Field | Value | +-----------------------+--------------------------------------+ | address | 7c:fe:90:12:1f:f1 | | created_at | 2018-12-20T14:28:14+00:00 | | extra | {} | | internal_info | {} | | local_link_connection | {} | | node_uuid | e30e76a4-a39e-4560-9bff-d3d9af66c503 | | physical_network | physnet1 | | portgroup_uuid | 2de8c1ae-a5bf-418e-b07a-1c0fbf676f36 | | pxe_enabled | True | | updated_at | None | | uuid | 4510e849-ed21-46f8-bf4c-ca91c7e6b648 | +-----------------------+--------------------------------------+ # NETWORK AND SUBNET CONFIG ############################### [root@openstack-deployment ~]# openstack network show hpc +---------------------------+--------------------------------------+ | Field | Value | +---------------------------+--------------------------------------+ | admin_state_up | UP | | availability_zone_hints | | | availability_zones | nova | | created_at | 2018-12-17T02:07:46Z | | description | | | dns_domain | None | | id | f630b54b-2b07-44a3-8196-5a0ea9cc7969 | | ipv4_address_scope | None | | ipv6_address_scope | None | | is_default | None | | is_vlan_transparent | None | | location | None | | mtu | 1500 | | name | hpc | | port_security_enabled | True | | project_id | b91520cff5bd45c59a8de07c38641582 | | provider:network_type | flat | | provider:physical_network | physnet1 | | provider:segmentation_id | None | | qos_policy_id | None | | revision_number | 3 | | router:external | Internal | | segments | None | | shared | True | | status | ACTIVE | | subnets | 506af593-659b-4c58-a180-897dd0b04957 | | tags | | | updated_at | 2018-12-20T12:21:09Z | +---------------------------+--------------------------------------+ [root@openstack-deployment ~]# openstack subnet show hpc_subnet +-------------------+--------------------------------------+ | Field | Value | +-------------------+--------------------------------------+ | allocation_pools | 10.0.32.100-10.0.32.150 | | cidr | 10.0.0.0/16 | | created_at | 2018-12-17T02:07:49Z | | description | | | dns_nameservers | 8.8.8.8 | | enable_dhcp | True | | gateway_ip | 10.0.32.1 | | host_routes | | | id | 506af593-659b-4c58-a180-897dd0b04957 | | ip_version | 4 | | ipv6_address_mode | None | | ipv6_ra_mode | None | | location | None | | name | hpc_subnet | | network_id | f630b54b-2b07-44a3-8196-5a0ea9cc7969 | | project_id | b91520cff5bd45c59a8de07c38641582 | | revision_number | 2 | | segment_id | None | | service_types | | | subnetpool_id | None | | tags | | | updated_at | 2018-12-20T12:21:09Z | +-------------------+--------------------------------------+ # BONUS: THIS IS THE NIC CONFIGURATION THAT WORKS ON A SERVER ############################################################## [root@zeus-52 ~]# cat /etc/sysconfig/network-scripts/ifcfg-Bond_connection_1 BONDING_OPTS="downdelay=0 miimon=110 mode=802.3ad updelay=0" TYPE=Bond BONDING_MASTER=yes MTU=9000 PROXY_METHOD=none BROWSER_ONLY=no BOOTPROTO=none IPADDR=10.0.32.52 PREFIX=16 GATEWAY=10.0.32.1 DNS1=8.8.8.8 DEFROUTE=yes IPV4_FAILURE_FATAL=no IPV6INIT=yes IPV6_AUTOCONF=yes IPV6_DEFROUTE=yes IPV6_FAILURE_FATAL=no IPV6_PRIVACY=no IPV6_ADDR_GEN_MODE=stable-privacy NAME="Bond connection 1" UUID=5153a698-46ca-4234-a71b-7c88e4c92b91 DEVICE=bond0 ONBOOT=yes Any thought about what am I doing wrong or what to do next? Thank you very much NOTICE Please consider the environment before printing this email. This message and any attachments are intended for the addressee named and may contain legally privileged/confidential/copyright information. If you are not the intended recipient, you should not read, use, disclose, copy or distribute this communication. If you have received this message in error please notify us at once by return email and then delete both messages. We accept no liability for the distribution of viruses or similar in electronic communications. This notice should not be removed.

1 0

[Cinder] cinder-volume connection problem when creating the instance
by Minjun Hong 20 Dec '18

20 Dec '18

Hi. I'm installing Cinder service in an storage server of my laboratory and I need you guys' help about Cinder. I'm installing Cinder by referring 'Cinder Installation Guide for Ubuntu' ( https://docs.openstack.org/cinder/queens/install/index-ubuntu.html) However, when I request creating an instance, it seems that Openstack cannot receive the volume which the instance needs from the storage server. And seeing status message of tgt service for iSCSI, it seems that the service needs certain kernel module. Status of tgt service is following: > ● tgt.service - (i)SCSI target daemon > Loaded: loaded (/lib/systemd/system/tgt.service; enabled; vendor > preset: enabled) > Active: active (running) since Wed 2018-12-19 22:05:55 KST; 26min ago > Docs: man:tgtd(8) > Process: 2249 ExecStartPost=/usr/sbin/tgtadm --op update --mode sys > --name State -v ready (code=exited, status=0/SUCCESS) > Process: 2230 ExecStartPost=/usr/sbin/tgt-admin -e -c > /etc/tgt/targets.conf (code=exited, status=0/SUCCESS) > Process: 2206 ExecStartPost=/usr/sbin/tgtadm --op update --mode sys > --name State -v offline (code=exited, status=0/SUCCESS) > Main PID: 2170 (tgtd) > Status: "Starting event loop..." > Tasks: 1 > Memory: 2.7M > CPU: 87ms > CGroup: /system.slice/tgt.service > └─2170 /usr/sbin/tgtd -f > Dec 19 22:05:55 node0 systemd[1]: Starting (i)SCSI target daemon... > Dec 19 22:05:55 node0 tgtd[2170]: tgtd: iser_ib_init(3434) Failed to > initialize RDMA; load kernel modules? > Dec 19 22:05:55 node0 tgtd[2170]: tgtd: work_timer_start(150) use signal > based scheduler > Dec 19 22:05:55 node0 tgtd[2170]: tgtd: bs_init(387) use signalfd > notification > Dec 19 22:05:55 node0 systemd[1]: Started (i)SCSI target daemon. And the status of Cinder-volume service as follows: > ● cinder-volume.service - OpenStack Cinder Volume > Loaded: loaded (/lib/systemd/system/cinder-volume.service; enabled; > vendor preset: enabled) > Active: active (running) since Wed 2018-12-19 22:05:55 KST; 45min ago > Main PID: 2110 (cinder-volume) > Tasks: 2 > Memory: 210.2M > CPU: 1min 23.649s > CGroup: /system.slice/cinder-volume.service > ├─2110 /usr/bin/python2 /usr/bin/cinder-volume > --config-file=/etc/cinder/cinder.conf > --log-file=/var/log/cinder/cinder-volume.log > └─2657 /usr/bin/python2 /usr/bin/cinder-volume > --config-file=/etc/cinder/cinder.conf > --log-file=/var/log/cinder/cinder-volume.log > Dec 19 22:05:55 node0 systemd[1]: Started OpenStack Cinder Volume. > Dec 19 22:06:00 node0 sudo[2658]: pam_unix(sudo:auth): auth could not > identify password for [cinder] Log message of Cinder-volume service continuously complains that the service cannot communicate with the internal driver (maybe, LVM?). In other words, when Cinder-volume is accessed (e.g. instance creation), an error message is printed and after that, the same message is repeated every second as follows: 2018-12-19 22:04:00.747 35996 INFO oslo_service.service > [req-bcc39e60-531e-4484-ab4b-bab085d112c4 - - - - -] Caught SIGTERM, > stopping children > 2018-12-19 22:04:00.784 35996 INFO oslo_service.service > [req-bcc39e60-531e-4484-ab4b-bab085d112c4 - - - - -] Waiting on 1 children > to exit > 2018-12-19 22:04:00.809 35996 INFO oslo_service.service > [req-bcc39e60-531e-4484-ab4b-bab085d112c4 - - - - -] Child 36039 killed by > signal 15 > 2018-12-19 22:05:58.378 2110 INFO root [-] Generating grammar tables from > /usr/lib/python2.7/lib2to3/Grammar.txt > 2018-12-19 22:05:58.403 2110 INFO root [-] Generating grammar tables from > /usr/lib/python2.7/lib2to3/PatternGrammar.txt > 2018-12-19 22:05:59.820 2110 INFO cinder.rpc > [req-b3178448-4e17-489b-8267-2fd7992bc876 - - - - -] Automatically selected > cinder-scheduler objects version 1.35 as minimum service version. > 2018-12-19 22:05:59.826 2110 INFO cinder.rpc > [req-b3178448-4e17-489b-8267-2fd7992bc876 - - - - -] Automatically selected > cinder-scheduler RPC version 3.10 as minimum service version. > 2018-12-19 22:05:59.875 2110 INFO cinder.volume.manager > [req-b3178448-4e17-489b-8267-2fd7992bc876 - - - - -] Determined volume DB > was empty at startup. > 2018-12-19 22:05:59.908 2110 WARNING oslo_config.cfg > [req-b3178448-4e17-489b-8267-2fd7992bc876 - - - - -] Option "iscsi_helper" > from group "lvm" is deprecated. Use option "target_helper" from group "lvm". > 2018-12-19 22:05:59.914 2110 WARNING oslo_config.cfg > [req-b3178448-4e17-489b-8267-2fd7992bc876 - - - - -] Option > "iscsi_protocol" from group "lvm" is deprecated. Use option > "target_protocol" from group "lvm". > 2018-12-19 22:05:59.916 2110 INFO cinder.volume.manager > [req-b3178448-4e17-489b-8267-2fd7992bc876 - - - - -] Image-volume cache > disabled for host node0@lvm. > 2018-12-19 22:05:59.932 2110 INFO oslo_service.service > [req-b3178448-4e17-489b-8267-2fd7992bc876 - - - - -] Starting 1 workers > 2018-12-19 22:05:59.940 2657 INFO cinder.service > [req-b3178448-4e17-489b-8267-2fd7992bc876 - - - - -] Starting cinder-volume > node (version 13.0.0) > 2018-12-19 22:05:59.942 2110 WARNING oslo_config.cfg > [req-b3178448-4e17-489b-8267-2fd7992bc876 - - - - -] Option "iscsi_helper" > from group "DEFAULT" is deprecated. Use option "target_helper" from group > "DEFAULT". > 2018-12-19 22:05:59.952 2110 WARNING oslo_config.cfg > [req-b3178448-4e17-489b-8267-2fd7992bc876 - - - - -] Option "auth_uri" from > group "keystone_authtoken" is deprecated for removal (The auth_uri option > is deprecated in favor of www_authenticate_uri and will be removed in the > S release.). Its value may be silently ignored in the future. > 2018-12-19 22:05:59.953 2110 WARNING oslo_config.cfg > [req-b3178448-4e17-489b-8267-2fd7992bc876 - - - - -] Option "auth_uri" from > group "keystone_authtoken" is deprecated. Use option "www_authenticate_uri" > from group "keystone_authtoken". > 2018-12-19 22:05:59.961 2657 INFO cinder.volume.manager > [req-b3178448-4e17-489b-8267-2fd7992bc876 - - - - -] Starting volume driver > LVMVolumeDriver (3.0.0) > 2018-12-19 22:06:00.007 2657 ERROR cinder.volume.manager > [req-b3178448-4e17-489b-8267-2fd7992bc876 - - - - -] Failed to initialize > driver.: ProcessExecutionError: Unexpected error while running command. > Command: sudo cinder-rootwrap /etc/cinder/rootwrap.conf env LC_ALL=C vgs > --version > Exit code: 1 > Stdout: u'' > Stderr: u'sudo: no tty present and no askpass program specified\n' > 2018-12-19 22:06:00.007 2657 ERROR cinder.volume.manager Traceback (most > recent call last): > 2018-12-19 22:06:00.007 2657 ERROR cinder.volume.manager File > "/opt/stack/cinder/cinder/volume/manager.py", line 433, in init_host > 2018-12-19 22:06:00.007 2657 ERROR cinder.volume.manager > self.driver.check_for_setup_error() > 2018-12-19 22:06:00.007 2657 ERROR cinder.volume.manager File > "/opt/stack/cinder/cinder/volume/drivers/lvm.py", line 286, in > check_for_setup_error > 2018-12-19 22:06:00.007 2657 ERROR cinder.volume.manager if > volutils.supports_thin_provisioning(): > 2018-12-19 22:06:00.007 2657 ERROR cinder.volume.manager File > "/opt/stack/cinder/cinder/volume/utils.py", line 628, in > supports_thin_provisioning > 2018-12-19 22:06:00.007 2657 ERROR cinder.volume.manager > utils.get_root_helper()) > 2018-12-19 22:06:00.007 2657 ERROR cinder.volume.manager File > "/opt/stack/cinder/cinder/brick/local_dev/lvm.py", line 225, in > supports_thin_provisioning > 2018-12-19 22:06:00.007 2657 ERROR cinder.volume.manager return > LVM.get_lvm_version(root_helper) >= (2, 2, 95) > 2018-12-19 22:06:00.007 2657 ERROR cinder.volume.manager File > "/opt/stack/cinder/cinder/brick/local_dev/lvm.py", line 202, in > get_lvm_version > 2018-12-19 22:06:00.007 2657 ERROR cinder.volume.manager > run_as_root=True) > 2018-12-19 22:06:00.007 2657 ERROR cinder.volume.manager File > "/usr/local/lib/python2.7/dist-packages/oslo_concurrency/processutils.py", > line 424, in execute > 2018-12-19 22:06:00.007 2657 ERROR cinder.volume.manager > cmd=sanitized_cmd) > 2018-12-19 22:06:00.007 2657 ERROR cinder.volume.manager > ProcessExecutionError: Unexpected error while running command. > 2018-12-19 22:06:00.007 2657 ERROR cinder.volume.manager Command: sudo > cinder-rootwrap /etc/cinder/rootwrap.conf env LC_ALL=C vgs --version > 2018-12-19 22:06:00.007 2657 ERROR cinder.volume.manager Exit code: 1 > 2018-12-19 22:06:00.007 2657 ERROR cinder.volume.manager Stdout: u'' > 2018-12-19 22:06:00.007 2657 ERROR cinder.volume.manager Stderr: u'sudo: > no tty present and no askpass program specified\n' > 2018-12-19 22:06:00.007 2657 ERROR cinder.volume.manager > 2018-12-19 22:06:00.075 2657 INFO cinder.volume.manager > [req-b3178448-4e17-489b-8267-2fd7992bc876 - - - - -] Initializing RPC > dependent components of volume driver LVMVolumeDriver (3.0.0) > 2018-12-19 22:06:00.076 2657 ERROR cinder.utils > [req-b3178448-4e17-489b-8267-2fd7992bc876 - - - - -] Volume driver > LVMVolumeDriver not initialized > 2018-12-19 22:06:00.076 2657 ERROR cinder.volume.manager > [req-b3178448-4e17-489b-8267-2fd7992bc876 - - - - -] Cannot complete RPC > initialization because driver isn't initialized properly.: > DriverNotInitialized: Volume driver not ready. > 2018-12-19 22:06:10.077 2657 ERROR cinder.service > [req-b3178448-4e17-489b-8267-2fd7992bc876 - - - - -] Manager for service > cinder-volume node0@lvm is reporting problems, not sending heartbeat. > Service will appear "down". > 2018-12-19 22:06:20.077 2657 ERROR cinder.service > [req-b3178448-4e17-489b-8267-2fd7992bc876 - - - - -] Manager for service > cinder-volume node0@lvm is reporting problems, not sending heartbeat. > Service will appear "down". > 2018-12-19 22:06:30.078 2657 ERROR cinder.service > [req-b3178448-4e17-489b-8267-2fd7992bc876 - - - - -] Manager for service > cinder-volume node0@lvm is reporting problems, not sending heartbeat. > Service will appear "down". > 2018-12-19 22:06:40.078 2657 ERROR cinder.service > [req-b3178448-4e17-489b-8267-2fd7992bc876 - - - - -] Manager for service > cinder-volume node0@lvm is reporting problems, not sending heartbeat. > Service will appear "down". > 2018-12-19 22:06:50.079 2657 ERROR cinder.service > [req-b3178448-4e17-489b-8267-2fd7992bc876 - - - - -] Manager for service > cinder-volume node0@lvm is reporting problems, not sending heartbeat. > Service will appear "down". > 2018-12-19 22:07:00.079 2657 ERROR cinder.service > [req-b3178448-4e17-489b-8267-2fd7992bc876 - - - - -] Manager for service > cinder-volume node0@lvm is reporting problems, not sending heartbeat. > Service will appear "down". > 2018-12-19 22:07:10.078 2657 WARNING cinder.volume.manager > [req-b3178448-4e17-489b-8267-2fd7992bc876 - - - - -] Update driver status > failed: (config name lvm) is uninitialized. In above log, 'Manage for service cinder -volume node0@lvm is ...' is the repeated part. If there is anyone who has experienced this kind of problem, please give me any advice. Thanks!

2 2

[neutron] [upgrade] No meeting on Dec. 27th
by Lujin Luo 20 Dec '18

20 Dec '18

Hi everyone, We will not have the next subteam meeting on Dec. 27th. Thank you for all of your work this year, and let's resume in next year, Jan. 3rd. Happy Holidays! Best regards, Lujin

1 0

[nova][vitrage] Nova extended server attributes
by Ifat Afek 20 Dec '18

20 Dec '18

Hi, Is there a way to get Nova extended server attributes (and specifically, OS-EXT-SRV-ATTR:instance_name) as part of the notification that is sent upon instance creation? In Vitrage we are using the immediate notifications from Nova, but this specific information is missing. Thanks, Ifat

2 2

[watcher] core reviewers update
by Чадин Александр Сергеевич 20 Dec '18

20 Dec '18

Hello Watcher team, Some of core contributors are inactive for a year or more and their priorities have been changed. I suggest to remove the following contributors from core reviewers of Watcher: - Joe Cropper - Prashanth Hari - Prudhvi Rao Shedimbi - Susanne Balle - Vincent Francoise - David Tardivel If some of them would like to get back to work on Watcher, I see no barriers for that. Best Regards, ____ Alex

1 0