March 2019 - openstack-discuss - lists.openstack.org

[networking-ovs-dpdk
by Elanchezian Settu 08 Mar '19

08 Mar '19

Hi All, Trying to install devstack along with OVS-DPDK. But it fails at the below step during installation of OVS DPDK process. Herewith attached the logs and local.conf file used for installing. Kindly help me to resolve this issue. depbase=`echo lib/heap.lo | sed 's|[^/]*$|.deps/&|;s|\.lo$||'`;\ /bin/bash ./libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I ./include -I ./include -I ./lib -I ./lib -Wstrict-prototypes -Wall -Wextra -Wno-sign-compare -Wpointer-arith -Wformat -Wformat-security -Wswitch-enum -Wunused-parameter -Wbad-function-cast -Wcast-align -Wstrict-prototypes -Wold-style-definition -Wmissing-prototypes -Wmissing-field-initializers -fno-strict-aliasing -Wswitch-bool -Wlogical-not-parentheses -Wsizeof-array-argument -Wbool-compare -mssse3 -I/opt/stack/DPDK-v17.11/x86_ Thanks & Regards, Elan This message may contain confidential and privileged information. If it has been sent to you in error, please reply to advise the sender of the error and then immediately delete it. If you are not the intended recipient, do not read, copy, disclose or otherwise use this message. The sender disclaims any liability for such unauthorized use. NOTE that all incoming emails sent to Gigamon email accounts will be archived and may be scanned by us and/or by external service providers to detect and prevent threats to our systems, investigate illegal or inappropriate behavior, and/or eliminate unsolicited promotional emails ("spam").

1 0

[Interop-wg] [dev] [cinder] [qa] Strict Validation for Volume API using JSON Schema
by Ghanshyam Mann 08 Mar '19

08 Mar '19

Hello everyone, Tempest is planning to add the strict API validation using JSON schema for Volume test [1]. We do the same for all the compute test. With *Strict* JSON schema validation, all the API response will be validated with predefined schema with additionalProperties=False. additionalProperties=False will not allow any additional attribute in API response than what upstream APIs has in their current version. For example: If any vendor has modified the API response and returning additional attributes then Tempest tests going to fail. This will help: - To improve the OpenStack interoperability. Strict validation of API response is always helpful to maintain the interoperability. - To improve the volume API testing to avoid the backward compatible changes. Sometime we accidentally change the API in backward incompatible way and strict validation with JSON schema help to block those. We want to hear from cinder and interop team about any impact of this change to them. [1] https://blueprints.launchpad.net/tempest/+spec/volume-response-schema-valid… -gmann

4 6

[nova] nova-live-migration gate failure - hold rechecks
by Eric Fried 08 Mar '19

08 Mar '19

Please hold off rechecking in nova until [1] merges. The failure is in nova-live-migration with an error that looks like [2]. Thanks, Eric [1] https://review.openstack.org/641986 [2] http://logs.openstack.org/79/640879/7/check/nova-live-migration/f6c3653/job…

1 0

[interop] Restarting Interop WG Meeting this Wed. 10:00 AM CST/ 16:00 UTC
by Egle Sigler 08 Mar '19

08 Mar '19

Hello Everyone, We will be restarting Interop WG meetings this Wednesday, at 1600 UTC in #openstack-meeting-3, everyone welcome. Last year we discussed moving to once a year interop guidelines, and we need community’s input on the frequency. Etherpad for Wednesday’s meeting: https://etherpad.openstack.org/p/InteropWhistler.22 Please add items to the agenda. Meetings will be held every other week. Web IRC link if you are not using IRC client: http://webchat.freenode.net/?channels=openstack-meeting-3 Meetbot quick reference guide: http://meetbot.debian.net/Manual.html#user-reference If you have general interop questions, please ask in #openstack-interop IRC channel. Thank you, Egle

2 2

[requirements] freeze
by Matthew Thode 08 Mar '19

08 Mar '19

No puns this time With R-5 done this week requirements is now in a freeze. If you want to seek an exception please email this list (openstack-discuss) with '[requirements][FFE]' prepended to your subject line. In the body please explain why you need this exception and any projects that the change will impact that you know. -- Matthew Thode

1 0

[tc] forum planning
by Doug Hellmann 08 Mar '19

08 Mar '19

It's time to start planning the forum. We need a volunteer (or 2) to set up the etherpad and start collecting ideas for sessions the TC should be running. Who wants to handle that? -- Doug

2 3

[election][openstack-ansible] candidacy
by Mohammed Naser 08 Mar '19

08 Mar '19

I'd like to announce my candidacy for OpenStack Ansible PTL. Over the past cycle, we've made a lot of forward progress in improving the stability of our gate, aiming at making our roles much more linear and improving deploy times. There's still a lot more work to be done, and there's a lot less resources available to get the work done with. Therefore, I think the upcoming cycle should be strongly focused on increasing stability, this would be done by looking at the following - Simplifying scenarios for usage and testing - Using integrated repository for testing and dropping role tests - Progress on switching all deployments to use Python3 - Eventual addition of CentOS 8 option - Reduction in number of config variables (encouraging overrides) - Increase cooperation with other deployment projects (i.e. TripleO) I would like us to aim at a cycle where we stabilize things and make sure that things chug along smoothly. This will help reduce our overhead and allow us to focus on the stability and robustness of the deployment project as I believe that at this point, there's not much more 'features' to be added in the deployment tool. In doing this, we should hopefully drive down the time of deployment and increase the reliability of the deployment. Thank you for your consideration. -- Mohammed Naser — vexxhost ----------------------------------------------------- D. 514-316-8872 D. 800-910-1726 ext. 200 E. mnaser(a)vexxhost.com W. http://vexxhost.com

2 1

[ptl][barbican][election]
by Douglas Mendizabal 08 Mar '19

08 Mar '19

I would like to announce my candidacy to serve as Barbican PTL for the Train cycle. I've been involved in the Barbican project since its inception, and I have previously had the opportunity to serve as PTL for the Kilo through Newton cycles. With Ade Lee stepping down as PTL at the end of the Stein cycle, I think it is a good time for me to serve as PTL once again. My goals for the Train cycle are to continue to improve the usability of the various projects under the Barbican umbrella (especially python- barbicanclient) as well as continue to improve quality through more and better testing. Thank you, Douglas Mendizábal

1 0

[puppet] PTL non-candidacy
by Tobias Urdin 08 Mar '19

08 Mar '19

Hello, I'm announcing that I won't be running for PTL of the Train release cycle for the Puppet OpenStack project. Due to changes at work I cannot facilitate having my mind exclusively on OpenStack for the upcoming six months and I would love to see more involvement and new perspectives surrounding the Puppet OpenStack project. I won't go nowhere though! My personal (and professional) involvement in OpenStack is bigger than ever and I'm looking forward to another cycle with more existing work. I will keep being a core and review and commit changes as much as I can. I feel proud of our achivements this cycle, my personal feeling is that we've got more momentum and it's been really great seeing people stepping up and commiting new features, improvements, bug fixes and all the cleanup of removed configuration options and technical depth that we've had for so many releases. I would love to come back to the PTL role in the future, if you would have me. Thanks to all of the people that I've interacted with, and not least all of you out there doing any work in the OpenStack scope. Remember that you are all awesome :) If you've read this far, please bare with me. I just wanted to give a brief recap on what we've achieved, together, this cycle. * Remove and/or deprecated hundreds of configuration options that either did nothing or was already removed from projects * Removed the keystone related auth_uri option for www_authenticate_uri * Started work to minimize the dependencies between classes that is the main cause for duplicate declarations * Fixed structure of all modules to conform with Puppet standards * Added Ubuntu Stein support (python3 only!) * Publishing all modules to Puppetforge automatically (shoutout for Infra and release team for the huge help here!) * Moved keystone to port 5000 only, changed all v2.0 to v3 references, deprecated all paste and PKI related code * Move almost all testing to rspec-puppet-facts (only puppet-keystone left) * Started work moving away from non-Apache licensed Puppet modules * Added new puppet-placement module, deprecated deploying placement from puppet-nova * Converted all Puppet parser functions to Puppet 4 API functions * puppet-nova deprecated cells v1, Support native TLS for migration and disks over NBD * Apache WSGI support for Sahara, Octavia, Nova metadata API * Deprecated Puppet 4 support, added Puppet 6 support * All testing uses Ubuntu Bionic or CentOS 7 And a lot more! Lastly, to anybody that is considering running for PTL I stongly encourage you to run. To anybody; I'm always available on IRC for feedback, questions or if you just want to say hello or chat about something. Best regards Tobias (tobias-urdin on IRC)

3 2

[kolla][magnum] Unable to create a PersistentVolumeClaim with Cinder backend
by Giuseppe Sannino 08 Mar '19

08 Mar '19

Hi all, I would need your help. As per the subject, I'm trying to create a PersistentVolumeClaim using Cinder as backend on a K8S cluster I deployed via Magnum, but I'm not able to. I think I'm hitting one or two issues (not sure if the second depends on the first). Here is the story. *>Background<* I managed to deploy a K8S cluster using Magnum and I can also create POD or any other K8S "entity" except persisten volumes and/or claims. Configuration: kolla-ansible: 7.0.1 OS Release: Rocky Base Distro: CentOS I applied the WA as per https://review.openstack.org/#/c/638400/ (a previous issue I found) so K8S cluster is working fine. *> PROBLEM <* I've created the following storageClass: kind: StorageClass apiVersion: storage.k8s.io/v1 metadata: name: standard provisioner: kubernetes.io/cinder parameters: type: fast availability: nova NOTE: I'm trying to use Cinder as backend. NOTE2: I tried with an hostPath and I have no issue. I then tried to create a PersistentVolumeClaim linking the above StorageClass. kind: PersistentVolumeClaim apiVersion: v1 metadata: name: cinder-claim spec: accessModes: - ReadWriteOnce resources: requests: storage: 1Gi storageClassName: standard2 It stays in "Pending" state forever. I had a look at the "kube-controller-manager.service" log and found the following: -------- Mar 08 14:25:21 kube-cluster-march-ppqfakx76wsm-master-0.novalocal runc[3013]: I0308 14:25:21.017065 1 event.go:221] Event(v1.ObjectReference{Kind:"PersistentVolumeClaim", Namespace:"default", Name:"cinder-claim", UID:"ea41e0ac-41ad-11e9-8ffc-fa163e9b393f", APIVersion:"v1", ResourceVersion:"112059", FieldPath:""}): type: 'Warning' reason: 'ProvisioningFailed' Failed to provision volume with StorageClass "standard2": OpenStack cloud provider was not initialized properly : stat /etc/kubernetes/cloud-config: no such file or directory -------- *>>> ISSUE 1 <<<* It seems like that service expects the cloud provider configuration to be in the "cloud-config" file which does not exist. As *workaround*, I created that file and copied the content of "kube_openstack_config" which is: [Global] auth-url=http://10.1.7.201:5000/v3 user-id=eed8ce6dd9734268810f3c23ca91cb19 password=M3rE6Wx9sTB94BQD2m trust-id= ca-file=/etc/kubernetes/ca-bundle.crt region=RegionOne [LoadBalancer] use-octavia=False subnet-id=8c9e0448-2d40-449f-a971-e3acde193678 create-monitor=yes monitor-delay=1m monitor-timeout=30s monitor-max-retries=3 [BlockStorage] bs-version=v2 *>>> ISSUE 2 <<<* Checking again the log of the "kube-controller-manager.service" service I can see this time: Mar 08 14:29:21 kube-cluster-march-ppqfakx76wsm-master-0.novalocal runc[3013]: I0308 14:29:21.403038 1 event.go:221] Event(v1.ObjectReference{Kind:"PersistentVolumeClaim", Namespace:"default", Name:"cinder-claim", UID:"ea41e0ac-41ad-11e9-8ffc-fa163e9b393f", APIVersion:"v1", ResourceVersion:"112059", FieldPath:""}): type: 'Warning' reason: 'ProvisioningFailed' Failed to provision volume with StorageClass "standard2": unable to initialize cinder client for region: RegionOne, err: unable to initialize cinder v2 client for region RegionOne: No suitable endpoint could be found in the service catalog. >From Openstack I see: root@hce03:~# openstack endpoint list | grep keystone | 011e5905a4a04e348b3fd1d3d1a1ab09 | RegionOne | keystone | identity | True | public | http://10.1.7.201:5000 | | 0fb51c8e0edb45839162a1afe412f9f7 | RegionOne | keystone | identity | True | internal | http://10.1.7.200:5000 | | 34c269a31260459fbd2c0967fda55b1d | RegionOne | keystone | identity | True | admin | http://10.1.7.200:35357 | root@hce03:~# openstack endpoint list | grep cinder | 55b109ed383c4705b71c589bdb0da697 | RegionOne | cinderv3 | volumev3 | True | admin | http://10.1.7.200:8776/v3/%(tenant_id)s | | 6386e4f41af94c25ac8c305c7dbc1af4 | RegionOne | cinderv3 | volumev3 | True | public | http://10.1.7.201:8776/v3/%(tenant_id)s | | 78e706cd0cd74a42b43adc051100b0bc | RegionOne | cinderv2 | volumev2 | True | admin | http://10.1.7.200:8776/v2/%(tenant_id)s | | 83a7da1e426f4aa4b5cac3f4a564f480 | RegionOne | cinderv3 | volumev3 | True | internal | http://10.1.7.200:8776/v3/%(tenant_id)s | | a322b3442a62418098554d23ae6a1061 | RegionOne | cinder | volume | True | public | http://10.1.7.201:8776/v1/%(tenant_id)s | | c82a65eb60cc49348397085233882ba1 | RegionOne | cinder | volume | True | internal | http://10.1.7.200:8776/v1/%(tenant_id)s | | cf2e6d9cb6b640ea876c9f5fe16123d3 | RegionOne | cinderv2 | volumev2 | True | public | http://10.1.7.201:8776/v2/%(tenant_id)s | | e71733a7dbb94a69a44d03ee14389eb5 | RegionOne | cinderv2 | volumev2 | True | internal | http://10.1.7.200:8776/v2/%(tenant_id)s | | e9add20fea3c4d57b2a752832455f6f1 | RegionOne | cinder | volume | True | admin | http://10.1.7.200:8776/v1/%(tenant_id)s | >From the Kube Master I checked whether or not the auth_url, as per the cloud-config is reachable, and it is: [root@kube-cluster-march-ppqfakx76wsm-master-0 kubernetes]# curl http://10.1.7.201:5000/v3 {"version": {"status": "stable", "updated": "2018-10-15T00:00:00Z", "media-types": [{"base": "application/json", "type": "application/vnd.openstack.identity-v3+json"}], "id": "v3.11", "links": [{"href": "http://10.1.7.201:5000/v3/", "rel": "self"}]}} I also tried to change the block storage version from "v2" to "v1" or "v3". Again the same error. May I ask some support on this ? Many thanks! BR /Giuseppe

1 0