December 2018 - openstack-discuss

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

18 Dec '18

Hi everyone, We have spent some time working to get an idea of what official SDKs would look like. We had some sessions during the Berlin summit[0][1] and there was a lot of great feedback. Currently the following SDKs are generally considered usable for their respective language; there are others of course: openstacksdk (Python) gophercloud (Go) pkgcloud (JavaScript) openstack4j (Java) rust-openstack (Rust) fog-openstack (Ruby) php-opencloud (PHP) After many discussions it seems SDK validation essentially should be about confirming cloud state pre/post SDK interaction rather than API support. An example is that when I use pkgcloud and ask that a VM be created, does the VM exist, in the way I asked it exist, rather than are there specific API calls that are being hit along the way to creating my VM. I am putting this email out to keep the community informed of what has been discussed in this space but also and most importantly to get feedback and support for this work. It would be great to get a set of official and community SDKs, get them setup with CI testing for validation (not changing their current CI for unit/functional/acceptance testing; unless asked to help do this), and connect the results to the updated project navigator SDK section. A list of scenarios has been provided as a good starting point for cloud state checks.[2] Essentially the proposal is to deploy OpenStack from upstream (devstack or other), stand up a VM within the cloud, grab all the SDKs, run acceptance tests, report pass/fail results, update project navigator. Of course there are details to be worked out and I do have a few questions that I hope would help get everyone interested on the same page via this thread. 1. Does this make sense? 1. Would folks be interested in a SDK SIG or does it make more sense to request an item on the API SIG's agenda? 1. Bi-weekly discussions a good cadence? 1. Who is interested in tackling this together? [0] https://etherpad.openstack.org/p/BER-better-expose-what-we-produce [1] https://etherpad.openstack.org/p/BER-sdk-certification [2] https://docs.google.com/spreadsheets/d/1cdzFeV5I4Wk9FK57yqQmp5JJdGfKzEOdB3V… -- Kind regards, Melvin Hillsman mrhillsman(a)gmail.com mobile: (832) 264-2646

6 15

[ptl] [user survey] Cinder Superuser Article Addressing User Survey Feedback
by Allison Price 18 Dec '18

18 Dec '18

Hi everyone, I wanted to share a really helpful article [1] that Jay Bryant wrote for Superuser after receiving the Cinder feedback from the 2018 OpenStack User Survey. This is really valuable content for the users that are expressing challenges and feedback in the survey. I would like to encourage any PTLs that have the bandwidth to directly address some of the feedback they received from the user survey to draft something similar. With the publication of this article, we will reach out to users who expressed that they are running Cinder to show how their feedback has had a direct impact on the development of OpenStack. If anyone is interested, please email me directly, and we can get the process started. We have also made the 2019 OpenStack User Survey [2] live. We will be reaching out to all PTLs in the next month to make updates to the project-specific questions. If you have any questions in the meantime, please let me know. Thanks! Allison [1] http://superuser.openstack.org/articles/how-your-feedback-sparked-whats-nex… [2] https://www.openstack.org/user-survey/survey-2019 Allison Price OpenStack Foundation allison(a)openstack.org

1 0

[Oslo] End of year schedule and plans
by Ben Nemec 18 Dec '18

18 Dec '18

Hi Norwegians, As we discussed in the meeting today, there will be no Oslo meetings for the next two weeks due to the holidays. We'll resume Jan. 7. Releases will happen as normal this week, but after that I wouldn't expect any more until 2019. We generally try to avoid releasing when people aren't going to be around to deal with any fallout. Finally, I believe most of the Oslo cores will be unavailable after this week, so expect review activity to slow significantly until the new year too. I will be around for the rest of the week, so if you have any Oslo-related stuff that needs to happen in 2018 let me know. After that all bets are off for my availability. Thanks and Happy New Year in advance! -Ben

1 0

[dev] [horizon] [tc] [release] [PTI] is tox a requirement even if tox is not used?
by Akihiro Motoki 18 Dec '18

18 Dec '18

Hi, # I am not sure [tc] and [release] tags are appropriate. Horizon team maintains xstatic-* repositories [1]. We have a question on the need for tox.ini. Can we drop tox.ini completely considering the situation below? These repositories do not depend on 'tox' on testing from their nature of re-packaging JS module in a python way. In addition, there is no document provided. The current PTI mentions only "tox -e docs". # Previously PTI required "venv" tox ini but it is no longer mentioned. [1] http://git.openstack.org/cgit/?q=xstatic- Best Regards, Akihiro Motoki (IRC: amotoki)

4 3

[oslo] How to use library "oslo.messaging"
by Thành Nguyễn Bá 18 Dec '18

18 Dec '18

Dear all, I have a question about "library oslo.messaging". How can i use this librabry to write simple program listen event on Openstack (like Nova, Cinder)? I had read on docs, nova support "oslo_messaging_notifications" to send message via RabbitMQ, so I’m try to use this library but it seem very hard for me. *Nguyễn Bá Thành* *Mobile*: 0128 748 0391 *Email*: bathanhtlu(a)gmail.com

3 4

[dev] lower-constraints job moving to py36
by Chris Dent 17 Dec '18

17 Dec '18

There is a review in progress to change the lower-constraints CI job to explicitly use python 3.6 [1]. This is part of an ongoing migration to 3.6 throughout all the jobs. This has some small potential to break some projects, so in the review it was decided that making an announcement here would be best so that projects that run the lower-constraints job could have a chance to try it out before we make the switch: When we do, it will switch everyone, all at once. If you would like to try it out, please submit a null-change that depends-on the review [1]. [1] https://review.openstack.org/#/c/623229/ -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent tw: @anticdent

1 0

[tripleo] undercloud / standalone have switched to podman by default
by Emilien Macchi 17 Dec '18

17 Dec '18

For your information, default deployment of Undercloud and Standalone are now using Podman instead of Docker by default. The switch doesn't affect the Overcloud yet but we also aim to change the default before the end of Stein release. If you still want to use docker: * For Undercloud: undercloud.conf : container_cli = docker * For Standalone: in your environment: ContainerCli: docker Please let us know any problem regarding that change. -- Emilien Macchi

2 1

[neutron] Bug deputy report, December 10 - December 16
by Bernard Cafarelli 17 Dec '18

17 Dec '18

Hi neutron folks, we started a new rotation of bug deputies, which means it was my turn to watch over new bugs. Here is the list of reported bugs, I highlighted those worth another look (other high bugs already have pending patches) *Undecided* * https://bugs.launchpad.net/neutron/+bug/1808731 - Needs the method to stop metadata proxy Latest bug, discussion in progress - feedback welcome *High* * https://bugs.launchpad.net/neutron/+bug/1808136 - l2 pop doesn't always provide the whole list of fdb entries on OVS restart A follow-up to https://bugs.launchpad.net/neutron/+bug/1804842, patch proposed at https://review.openstack.org/#/c/624669/ * https://bugs.launchpad.net/neutron/+bug/1808595 - fullstack test neutron.tests.fullstack.test_l3_agent.TestHAL3Agent.test_gateway_ip_changed failed intermittently Gate failure with patch proposed at https://review.openstack.org/#/c/625359/ * https://bugs.launchpad.net/neutron/+bug/1808541 - Openflow entries are not totally removed for stopped VM OVS flows issue (possible race condition?) - Has reproducer, details and logs but needs another pair of eyes *Medium* * https://bugs.launchpad.net/neutron/+bug/1808112 - rule:shared is not respected in port/subnet create waiting for feedback from policy experts * https://bugs.launchpad.net/neutron/+bug/1808171 - TaggedBootDevicesTest.test_tagged_boot_devices intermittently fails waiting for network-vif-plugged event which neutron does not send Intermittent gate failure in nova * https://bugs.launchpad.net/python-neutronclient/+bug/1808451 - Add Support for Querying Quotas with Usage CLI support for quotas detail, patch proposed at https://review.openstack.org/#/c/621507/ *RFE* * https://bugs.launchpad.net/neutron/+bug/1808062 - Limit VXLAN to within Neutron availability zones * https://bugs.launchpad.net/neutron/+bug/1808594 - Limit Geneve to within Neutron availability zones Clone of the previous one, for OVN (I added networking-ovn in affected projects) *Low* * https://bugs.launchpad.net/neutron/+bug/1807673 - Networking (neutron) concepts in neutron Easy doc fix ("facets" term use explanation) *Incomplete* * https://bugs.launchpad.net/neutron/+bug/1807483 - networksegments table in neutron can not be cleared automatically * https://bugs.launchpad.net/bugs/1808504 - the ip of port which device type is dhcp is null -- Bernard Cafarelli

1 0

[mistral] Standing down as PTL
by Dougal Matthews 17 Dec '18

17 Dec '18

Hey everyone, I am announcing that I am going to stand down as Mistral PTL. Due to a change in priorities I am no longer able to give the project the time it needs and deserves. This change will come into effect immediately. Being PTL has been a pleasure and a great learning experience for me. I have had the chance to work with a number of great folks and I am saddened to hang up the hat, particularly mid-cycle. However, I don't plan on going anywhere, I'll still be around and hope to remain an active member of the core team. Renat Akhmerov will be taking the role on again[1]. It is likely you will all know him as the previous Mistral PTL and therefore know the project will be in safe hands. Thanks everyone, Dougal [1]: https://review.openstack.org/#/c/625537/

2 1

[dev] [neutron] policy-in-code status update
by Akihiro Motoki 17 Dec '18

17 Dec '18

Hi neutrinos, I am working on policy-in-code support in neutron and have a good progress these weeks. [Progress] - The basic policy-in-code in neutron repo was merged. Several follow-up improvements and cleanup will be coming in the neutron repo. - policy-in-code support in several neutron related projects are proposed. There are found at https://review.openstack.org/#/q/topic:bp/neutron-policy-in-code+(status:op… [Request to neutron related project maintainers] neutron-dynamic-routing, neutron-fwaas,neutron-vpnaas, networking-bgpvpn, networking-sfc and vmware-nsx: I proposed patches. Review and testing from each team would be appreciated. networking-midonet and networking-cisco In my understanding, they defines its own resources and attributes, so their own policies exists. My bandwidth cannot cover them. Could you take over policy-in-code support? I belileve the above gerrit link would provide good examples. networking-ovn, networking-odl and networking-bagpipe In my understanding, they defines no extra resources and attributes, so there is no policies specific to them and policy-in-code support is unnecessary. Could you confirm my understanding is correct. If you need some policy definition, it means you need some work on policy-in-code. If you have questions, feel free to ask me. Best Regards, Akihiro Motoki (IRC: amotoki)

1 0