- openstack-discuss - lists.openstack.org

[tc][elections] TC candidacy
by Alexandra Settle 19 Feb '19

19 Feb '19

Hi all, I am announcing my candidacy for a position on the OpenStack Technical Committee. I have been an active contributor to OpenStack manuals since the beginning of 2014, and have been a core member since early 2015. I am currently employed by SUSE to work on SUSE OpenStack Cloud and OpenStack. You may know me better as asettle on IRC. Over these last 3 years, I have been privileged to be a part of this community focusing primarily on OpenStack documentation and have been vocal about treating documentation as a first-class citizen [0]. My key achievement was working as the elected PTL for documentation in 2017 [1] where I initiated moving the documentation out of the OpenStack-manuals repository and into the individual project repositories. My announcement may be considered quite brazen, as I have just returned to the community after a year-long hiatus working on the virtualization side of the world in a product operations role, however I am keen to support and work for this community with a renewed sense of enthusiasm. My experience in the OpenStack sphere has revolved around documentation, making me a traditionally unlikely candidate for the position on the TC. My role as documentation core and PTL has provided me with a broad view of OpenStack projects, how they work, and who you all are. I believe the perspective I will bring to the TC will be unique and helpful, as my time with OpenStack has been primarily focused on the integration and communication of all projects. The technical committee is designed to provide technical leadership for OpenStack as a whole [2] and I believe this to be true. Over the years, there has been an unspoken consensus that we are all aiming for the success of OpenStack as free and open software, fully developed and used by a welcoming and supportive community. I hope to stand as a member of the TC and further promote this statement. Drawing on my past experience as a communicator, documentor, collaborator, breaker of (my own) feet, and all round cool person, I am aiming to focus on the following three things: breaking down barriers between projects (new and old) and contributors (new and old); the openness of the community and maintaining that focus; and embracing change. Thank you for your consideration, Alex p.s - Tony: https://review.openstack.org/637972 [0] https://en.wikipedia.org/wiki/First-class_citizen [1] https://github.com/openstack/election/blob/master/candidates/pike/Documenta… [2] https://www.openstack.org/foundation/tech-committee/

1 0

[oslo] Single approve py37 patches
by Ben Nemec 19 Feb '19

19 Feb '19

As the subject says, let's single approve the py37 job addition patches. They're machine-generated and part of a broader effort that has already been agreed upon, so as long as they're passing CI they should be fine. -Ben

3 3

[tc][election] TC candidacy
by Sylvain Bauza 19 Feb '19

19 Feb '19

Howdy folks, I wasn't thinking to provide my name for the TC election but unfortunately I only see a very few proposals that makes me a bit afraid. Given I love OpenStack and I think the Technical Comittee is more important than my personal values, I throw my hat now in the ring. In case you don't know me, I'm Sylvain Bauza (bauzas on IRC), working on OpenStack since... wow, 6 years already ? In 2013, I was an operator for a SME company when I wanted to use some cloud for our CI and our developers and I discovered OpenStack. After 6 months working on it as an operator, I knew it would be my new life for more than what I know. I moved to another company and became a developer creating a new project which was named Climate. You probably know about this project if I tell you the new name : Blazar. Yeah, Blazar is 6 years old too and I'm super happy to see this project be now important with new companies and developers on it. After 1 year on it, I changed again my position and became a Nova developer, eventually becoming nova-core. Time flies and now I'm still there, happy with what OpenStack became. Of course, it changed. Of course, we have less. But honestly, I haven't seen more operators using it previously than now, which means that we succeeded as a team to make OpenStack useful for our users. I will be honest and say that I now work more on downstream for our customers than upstream with the Nova community. If you see my upstream involment, it slowly decreased from the last cycles but don't think I'm out of the band. After all, that means that people use our code, right? Also, that doesn't necessarly mean that I'll stop working upstream, it's just a balance that needs to be challenged, and be sure that if I'm a TC member, I'll take care of this balance. Enough words about me. I guess you're more interested in knowing about what I think is important for a TC membership. Well, I have a few opinions. - first, OpenStack is used from startups with a few servers to large cloud providers with +200K hosts. That's where we succeeded as projects. I think it's very important to make sure that service projects run from 0 to X smoothly and make it a priority if not. - secondly, the user experience is very important when it comes to talk to service projects. Having consistent and versioned APIs is important, albeit also client usage. We have microversions in place, but the story isn't fully done yet. - thirdly, I think we won the complexity game. Deploying OpenStack is now smoothier than before, but there are still bumps on the road, and I think the TC is the place to arbitrate between the understandable will of having more and the reasonable concern about upgrades and deployment concerns. Those three items aren't exhaustive of course. We all have opinions and I'm just one of the many. By the way, if you read up to here, ask yourself : if you care about OpenStack, why wouldn't you propose your name too ? Thanks, -Sylvain

1 0

[infra] Patch submitters can remove core reviewer votes?
by Ben Nemec 19 Feb '19

19 Feb '19

See https://review.openstack.org/#/c/637703/ I'm assuming in that case it was an accident, but it doesn't seem like this should be possible at all. For example, if I had -2'd would it still have allowed the removal? Maybe you can only remove positive votes? Anyway, seemed weird to me so I thought I would bring it up. -Ben

3 4

[openstack-helm] would like to discuss review turnaround time
by Jaesuk Ahn 19 Feb '19

19 Feb '19

Dear all, There has been several patch sets getting sparse reviews. Since some of authors wrote these patch sets are difficult to join IRC meeting due to time and language constraints, I would like to pass some of their voice, and get more detail feedback from core reviewers and other devs via ML. I fully understand core reviewers are quite busy and believe they are doing their best efforts. period! However, I sometimes feel that turnaround time for some of patch sets are really long. I would like to hear opinion from others and suggestions on how to improve this. It can be either/both something each patch set owner need to do more, or/and it could be something we as a openstack-helm project can improve. For instance, it could be influenced by time differences, lack of irc presence, or anything else. etc. I really would like to find out there are anything we can improve together. I would like to get any kind of advise on the following. - sometimes, it is really difficult to get core reviewers' comments or reviews. I routinely put the list of patch sets on irc meeting agenda, however, there still be a long turnaround time between comments. As a result, it usually takes a long time to process a patch set, does sometimes cause rebase as well. - Having said that, I would like to have any advise on what we need to do more, for instance, do we need to be in irc directly asking each patch set to core reviewers? do we need to put core reviewers' name when we push patch set? etc. - Some of patch sets are being reviewed and merged quickly, and some of patch sets are not. I would like to know what makes this difference so that I can tell my developers how to do better job writing and communicating patch sets. There are just some example patch sets currently under review stage. 1. https://review.openstack.org/#/c/603971/ >> this ps has been discussed for its contents and scope. Cloud you please add if there is anything else we need to do other than wrapping some of commit message? 2. https://review.openstack.org/#/c/633456/ >> this is simple fix. how can we make core reviewer notice this patch set so that they can quickly view? 3. https://review.openstack.org/#/c/625803/ >> we have been getting feedbacks and questions on this patch set, that has been good. but round-trip time for the recent comments takes a week or more. because of that delay (?), the owner of this patch set needed to rebase this one often. Will this kind of case be improved if author engages more on irc channel or via mailing list to get feedback rather than relying on gerrit reviews? Frankly speaking, I don't know if this is a real issue or just way it is. I just want to pass some of voice from our developers, and really would like to hear what others think and find a better way to communicate. Thanks you. -- *Jaesuk Ahn*, Ph.D. Software Labs, SK Telecom

2 3

how to define multiple aliases
by Manuel Sopena Ballesteros 19 Feb '19

19 Feb '19

Dear openstack community, I am trying to setup pci passthrough for multiple devices types but I am getting an error while creating a new vm. This is my pci section in nova.conf compute node [pci] passthrough_whitelist = [{ "vendor_id": "10de", "product_id": "1db1" }, { "vendor_id": "15b3", "product_id": "1016" }] alias = { "vendor_id":"10de", "product_id":"1db1", "device_type":"type-PCI", "name":"nv_v100" } alias = { "vendor_id":"15b3", "product_id":"1016", "device_type":"type-VF", "name":"mlnx_connectx4" } I also tried this [pci] passthrough_whitelist = [{ "vendor_id": "10de", "product_id": "1db1" }, { "vendor_id": "15b3", "product_id": "1016" }] alias = [{ "vendor_id":"10de", "product_id":"1db1", "device_type":"type-PCI", "name":"nv_v100" }, { "vendor_id":"15b3", "product_id":"1016", "device_type":"type-VF", "name":"mlnx_connectx4" }] And this is the error I am getting when I try to create a new vm: # openstack server create --flavor sriov.small --image centos7.5-image --availability-zone nova:zeus-59.localdomain vm-sriov-test PCI alias mlnx_connectx4 is not defined (HTTP 400) (Request-ID: req-aebb2d05-a557-428b-b2c6-090c16dc7c76) how can I setup multiple aliases for different devices? 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.

3 3

Last day for TC candidate nominations
by Jeremy Stanley 19 Feb '19

19 Feb '19

A quick reminder that we are in the last hours for TC candidate announcements. Nominations are open until Feb 19, 2019 23:45 UTC. If you want to stand for TC, don't delay, follow the instructions at [1] to make sure the community knows your intentions. Make sure your nomination has been submitted to the openstack/election repository and approved by election officials. Thank you, [1] http://governance.openstack.org/election/#how-to-submit-a-candidacy -- Jeremy Stanley

1 1

[tripleo][openstack-ansible] collaboration on os_tempest role update XI - Feb 19, 2019
by Chandan kumar 19 Feb '19

19 Feb '19

Hello, Here is the 11th update (Feb 13 to Feb 19, 2019) on collaboration on os_tempest[1] role between TripleO and OpenStack-Ansible projects. Summary: This week was still a calm week. we unblocked the os_heat CI, thanks to mnaser, odyssey4me and guilhermesp. In os_tempest we can also disable the router ping and run mistral tempest tests. Default zero disk flavor to RULE_ADMIN_API in Stein [https://review.openstack.org/#/c/603910/] patch in nova broke python-tempestconf, but os_tempest was working fine as it has already using DISK=1. Now everything is fixed Things got merged: os_tempest * Add tempest_service_available_mistral with distro packages - https://review.openstack.org/635180 * Add option to disable router ping - https://review.openstack.org/636211 python-tempestconf * Update image flavor to have some disk - https://review.openstack.org/637679 os_heat * Fixed the egg name of heat to openstack_heat - https://review.openstack.org/635518 Things in progress: os_tempest * Ensure stackviz wheel build is isolated - https://review.openstack.org/637503 * Added tempest.conf for heat_plugin - https://review.openstack.org/632021 * Use the correct heat tests - https://review.openstack.org/630695 * Added dependency of os_tempest role - https://review.openstack.org/632726 * Revert "Only init a workspace if doesn't exists" - https://review.openstack.org/637801 TripleO: * Reuse the validate-tempest skip list in os_tempest - https://review.openstack.org/634380 Note: os_tempest tripleo CI got broken, we are working on fixing this bug https://bugs.launchpad.net/tripleo/+bug/1816552 Upcoming week: * Complete heat support in os_tempest Here is the 10th update [2]. Have queries, Feel free to ping us on #tripleo or #openstack-ansible channel. Links: [1.] http://git.openstack.org/cgit/openstack/openstack-ansible-os_tempest [2.] http://lists.openstack.org/pipermail/openstack-discuss/2019-February/002608… Thanks, Chandan Kumar

1 0

[Openstack][Heat] service times out 504
by Florian Engelmann 19 Feb '19

19 Feb '19

Hi all, - Version: heat-base-archive-stable-rocky - Commit: Ica99cec6765d22d7ee2262e2d402b2e98cb5bd5e I have a fresh openstack deployment (kolla-Ansible). Everything but Heat is working fine. When I do a webrequest (either horizon or curl) on the openstack heat endpoint (internal or public), I just get nothing and after a while, it times out with a 500 http error. root@xxxx-kolla-xxxx:~# curl -vvv http://10.10.10.10:8004/v1/e7f405fb2b7b4b029dfc48e06920eb92 * Trying 10.x.y.z * Connected to heat.xxxxxxxx (10.x.x.x.) port 8004 (#0) > GET /v1/e7f405fb2b7b4b029dfc48e06920eb92 HTTP/1.1 > Host: heat.xxxxxxxxx:8004 > User-Agent: curl/7.47.0 > Accept: */* > < HTTP/1.1 500 Internal Server Error < Content-Type: application/json < Content-Length: 4338 < X-Openstack-Request-Id: req-46afc474-682b-4938-8777-b3b4b6fcb973 < Date: Fri, 15 Feb 2019 13:08:04 GMT < {"explanation": "The server has either erred or is incapable of performing the requested operation.", "code": 500, In the heat_api log I see the request coming through, but it seems that there is just no reply. 2019-02-15 14:16:40.047 25 DEBUG heat.api.middleware.version_negotiation [-] Processing request: GET / Accept: <no header in request> process_request /var/lib/kolla/venv/lib/python2.7/site-packages/heat/api/middleware/version_negotiation.py:50 2019-02-15 14:16:40.048 25 INFO eventlet.wsgi.server [-] 10.x.y.z - - [15/Feb/2019 14:16:40] "GET / HTTP/1.0" 300 327 0.001106 Should the api give some output when I do a http request? Any hints? Thanks a lot, its quite urgent.. Built 11.0.0 and current rocky-stable (11.0.0.1dev), same on both versions. ## with a horizon request (just click on Project -> Compute -> Orchestration -> Stacks 2019-02-15 14:22:22.250 22 DEBUG heat.api.middleware.version_negotiation [-] Processing request: GET /v1/beb568af3781471d94c3623805946ca3/stacks Accept: application/json process_request /var/lib/kolla/venv/lib/python2.7/site-packages/heat/api/middleware/version_negotiation.py:50 2019-02-15 14:22:22.250 22 DEBUG heat.api.middleware.version_negotiation [-] Matched versioned URI. Version: 1.0 process_request /var/lib/kolla/venv/lib/python2.7/site-packages/heat/api/middleware/version_negotiation.py:65 2019-02-15 14:22:23.003 22 DEBUG eventlet.wsgi.server [req-663d17e3-7e41-4c9e-a30a-a43ef18cf056 - - - - -] (22) accepted ('10.xxx.xxx.xxx', 51084) server /var/lib/kolla/venv/lib/python2.7/site-packages/eventlet/wsgi.py:883 2019-02-15 14:22:23.004 22 DEBUG heat.api.middleware.version_negotiation [-] Processing request: GET / Accept: <no header in request> process_request /var/lib/kolla/venv/lib/python2.7/site-packages/heat/api/middleware/version_negotiation.py:50 Best regards, Flo

2 1

[cinder] questions about release cycles
by Kulazhenkov, Yury 19 Feb '19

19 Feb '19

Hi all, I'm currently maintain VxFlex OS(ScaleIO) cinder driver. Driver require some changes to support future VxFlex OS release. We want to add this changes to Stein release and if it possible backport them to old supported releases. I have couple questions: 1. Is it still possible to submit patches which extend driver functionality in Stein release cycle? If such changes are still possible, then I have another question: I already submitted patch that renames ScaleIO driver to VxFlex OS (https://review.openstack.org/#/c/634397/) Is it possible that this patch will be merged during Stein release cycle? In other words, I'm interesting, should I prepare "new feature" patch based on this "renaming" patch (as patch chain) or it will be better to prepare separate patch based on master branch state? 2. Is it possible to add new driver features (changes for compatibility, to be more accurate) for currently supported Openstack releases? Any rules, policy or special workflow for that? Thanks, Yury

2 1