- openstack-discuss - lists.openstack.org

[kolla] Re: [Release-job-failures] Release of openstack/kolla for ref refs/tags/9.1.1 failed
by Sean McGinnis 19 Jun '20

19 Jun '20

On 6/19/20 5:45 AM, zuul(a)openstack.org wrote: > Build failed. > > - openstack-upload-github-mirror https://zuul.opendev.org/t/openstack/build/3bb83ca0c7344c7cac47d912a724ea07 : SUCCESS in 1m 03s > - release-openstack-python https://zuul.opendev.org/t/openstack/build/a54166b5f31340b1bdb6f28e4b4a8e61 : SUCCESS in 5m 22s > - announce-release https://zuul.opendev.org/t/openstack/build/5cee678de9b447428ca26b8b3ffd6ee7 : SUCCESS in 4m 07s > - propose-update-constraints https://zuul.opendev.org/t/openstack/build/fb96f3ad6edd43d7a611377542db95bc : SUCCESS in 3m 22s > - kolla-publish-centos-source https://zuul.opendev.org/t/openstack/build/9c7921b0b4a64641974ae616b27f03dc : RETRY_LIMIT in 3m 18s > - kolla-publish-centos-binary https://zuul.opendev.org/t/openstack/build/0388a788ca8a48949c20f48c60b2b7ba : RETRY_LIMIT in 2m 42s (non-voting) > - kolla-publish-centos8-source https://zuul.opendev.org/t/openstack/build/eac8ad3447bc49c1b3d306bffd7f905d : RETRY_LIMIT in 3m 14s > - kolla-publish-centos8-binary https://zuul.opendev.org/t/openstack/build/e68f3f687d3c452c823017a355049f5d : RETRY_LIMIT in 5m 04s (non-voting) > - kolla-publish-debian-source https://zuul.opendev.org/t/openstack/build/4c5a39b30f834bd597b167208c8cf322 : RETRY_LIMIT in 2m 51s (non-voting) > - kolla-publish-debian-source-aarch64 https://zuul.opendev.org/t/openstack/build/None : NODE_FAILURE in 0s (non-voting) > - kolla-publish-debian-binary https://zuul.opendev.org/t/openstack/build/144b9b8109804f8daa23bca8cc4a41d6 : RETRY_LIMIT in 2m 36s (non-voting) > - kolla-publish-ubuntu-source https://zuul.opendev.org/t/openstack/build/23f44f0a4ccb484c81abc76d0a7627d7 : RETRY_LIMIT in 3m 52s > - kolla-publish-ubuntu-binary https://zuul.opendev.org/t/openstack/build/a2ba0db9d974424f9f8424fef14d8e38 : RETRY_LIMIT in 3m 29s (non-voting) I haven't looks at all of these, but it looks like these kolla jobs need to be updated to have the ensure_pip role added like we've had to do for some of the other release jobs. My guess would be ensure_pip needs to be added somewhere like here: https://opendev.org/openstack/kolla/src/branch/master/tests/playbooks/pre.y… But I think someone from that team will need to look into that. Sean

3 2

[kolla] Kolla Klub meeting
by Mark Goddard 19 Jun '20

19 Jun '20

Hi, The next Kolla klub meeting is scheduled for Thursday at 15:00 UTC. We'll have a summary of the recent PTG discussions and some open discussion. Please bring ideas for discussion topics! https://docs.google.com/document/d/1EwQs2GXF-EvJZamEx9vQAOSDB5tCjsDCJyHQN5_… Thanks, Mark

1 1

[nova][oslo][rabbitmq][compute]
by Amjad Kotobi 19 Jun '20

19 Jun '20

Hi all, After trying to upgrade last piece of release Stein to Train which were all “python-oslo*” & “python2-oslo*” packages along with some others, nova computes status changed to “DOWN”, and from nova-compute.log below logs ERROR oslo.messaging._drivers.impl_rabbit [req-de95c598-8e72-46ad-aba6-1b26893ccad7 - - - - -] [739dc403-021e-4bba-a31a-3d86f3d7a908] AMQP server on controller5:5672 is unreachable: Server unexpectedly closed connection. Trying again in 1 seconds.: IOError: Server unexpectedly closed connection 2020-06-19 17:40:20.681 5518 INFO oslo.messaging._drivers.impl_rabbit [req-de95c598-8e72-46ad-aba6-1b26893ccad7 - - - - -] [739dc403-021e-4bba-a31a-3d86f3d7a908] Reconnected to AMQP server on controller5:5672 via [amqp] client with port 32894 This happened every two minutes or so. Connection between rabbitmq servers all looks fine and tested on port accessibility. Logs in rabbitmq got really nasty and after downgrading below packages(downgrade to Stein) all got to normal ############################# openvswitch.x86_64 python-openvswitch.x86_64 python-pycadf-common.noarch python2-automaton.noarch python2-barbicanclient.noarch python2-castellan.noarch python2-cliff.noarch python2-debtcollector.noarch python2-django-horizon.noarch python2-etcd3gw.noarch python2-eventlet.noarch python2-futurist.noarch python2-kombu.noarch python2-os-brick.noarch python2-os-client-config.noarch python2-os-ken.noarch python2-os-vif.noarch python2-os-win.noarch python2-osprofiler.noarch python2-ovsdbapp.noarch python2-pycadf.noarch python2-qpid-proton.x86_64 python2-simplejson.x86_64 python2-stevedore.noarch python2-swiftclient.noarch python2-taskflow.noarch python2-tenacity.noarch python2-tooz.noarch qpid-proton-c.x86_64 ########################## I’m not sure completely but suspecting in “kombu”. Also after rabbitmq got in high load and high ratio of failure “cinder” services got to DOWN too. Any idea will be great, thanks

1 0

[Neutron] Drivers meeting agenda - 19.06.2020
by Slawek Kaplonski 19 Jun '20

19 Jun '20

Hi, Here is the agenda for tomorrows drivers meeting. I want to discuss few RFEs there: - https://bugs.launchpad.net/neutron/+bug/1880532 - L3 Router should support ECMP - this is continuation of the discussion from previous meeting. There is also spec proposed for that one https://review.opendev.org/#/c/729532/ - https://bugs.launchpad.net/neutron/+bug/1751040 - Extended resources should not always calculate all attributes - old RFE but we should discuss that finally, - https://bugs.launchpad.net/neutron/+bug/1882804 - allow replacing the QoS policy of bound port - this one is follow up after nova-neutron discussion during the PTG. TBH I don't think we will need a lot of discussion about that but still it needs an approval. There are also 2 items in "On demand agenda": - (ralonsoh) [RFE] Optional NUMA affinity for neutron ports (commented in the PTG and scheduled to be commented here before). BZ: https://bugzilla.redhat.com/show_bug.cgi?id=1791834. No LP or BP created, this is just to present and discuss the idea of **using or not the QoS API** for this RFE. - (slaweq) We are deprecating neutron-fwaas. What with the API-REF? It's question from the ML http://lists.openstack.org/pipermail/openstack-discuss/2020-June/015508.html As agenda is pretty busy, I would like to start with On Demand agenda tomorrow and then continue with RFEs according to how much time we will have. See You on the meeting tomorrow. -- Slawek Kaplonski Senior software engineer Red Hat

2 2

[neutron][fwaas] Removal of neutron-fwaas projects from the neutron stadium
by Slawek Kaplonski 19 Jun '20

19 Jun '20

Hi, In Shanghai PTG we agreed that due to lack of maintainers of neutron-fwaas project we are going to deprecate it in neutron stadium in Ussuri cycle. Since then we asked couple of times about volunteers who would like to maintain this project but unfortunatelly there is still lack of such maintainers. So now, as we are already in Victoria cycle, I just proposed serie of patches [1] to remove master branch of neutron-fwaas and neutron-fwaas-dashboard from the neutron stadium. Stable branches will be still there and can be maintained but there will be no any code in master branch and there will be no new releases of those 2 projects in Victoria. If You are using this project and wants to maintain it, You can respin it in x/ namespace if needed. Feel free to ping me on IRC (slaweq) or by email if You would have any questions about that. [1] https://review.opendev.org/#/q/topic:retire-neutron-fwaas+(status:open+OR+s… -- Slawek Kaplonski Senior software engineer Red Hat

3 3

[release] Release countdown for week R-16, Jun 22 - Jun 26
by Sean McGinnis 19 Jun '20

19 Jun '20

Development Focus ----------------- We are now past the victoria-1 milestone. Teams should now be focused on feature development and completion of release cycle goals [0]. [0] https://governance.openstack.org/tc/goals/selected/victoria/index.html General Information ------------------- Our next milestone in this development cycle will be victoria-2, on July 30. This milestone is when we freeze the list of deliverables that will be included in the Victoria final release, so if you plan to introduce new deliverables in this release, please propose a change to add an empty deliverable file in the deliverables/victoria directory of the openstack/releases repository. Now is also generally a good time to look at bugfixes that were introduced in the master branch that might make sense to be backported and released in a stable release. If you have any question around the OpenStack release process, feel free to ask on this mailing-list or on the #openstack-release channel on IRC. Upcoming Deadlines & Dates -------------------------- Victoria-2 milestone: July 30 Ussuri cycle-trailing deadline: August 13

1 0

Re: [Release-job-failures] Release of openstack/puppet-nova for ref refs/tags/15.6.0 failed
by Thierry Carrez 19 Jun '20

19 Jun '20

zuul(a)openstack.org wrote: > Build failed. > > - openstack-upload-github-mirror https://zuul.opendev.org/t/openstack/build/fd8c86f9b57947239bd0273424e1d4d5 : FAILURE in 2m 30s > - release-openstack-puppet https://zuul.opendev.org/t/openstack/build/05dd9c7ffdc74af5ae4065eb16a522f9 : SUCCESS in 5m 40s > - announce-release https://zuul.opendev.org/t/openstack/build/188851ebacf9455ab50edc2101ae02bc : SUCCESS in 5m 31s Github mirroring failure as a concurrent mirror operation already synced that tag up. Can be safely ignored. -- Thierry Carrez (ttx)

1 0

[all][InteropWG] Request to review tests your Distro for 2020.06 draft guidelines
by prakash RAMCHANDRAN 18 Jun '20

18 Jun '20

Hi all, Please review your tests for Draft 2020.06 guidelines to be proposed to Board.You can do that on and should start appearing in next 24-48 hours depending on Zuulhttps://refstack.openstack.org/#/community_results Plus please register for InteropWG PTG meet on June 1 st 6AM-*AM PDT slot See etherpadsPTG eventhttps://etherpad.opendev.org/p/interop_virtual_ptg_planning_june_2020S… invite Tempest, TC members, QA/API SIG teams, Edge SIG WG , Baremetal SIG (for Ironic), K8s SIG (for OoK / KoO) & Scientific SIG teams. Other discussions https://etherpad.opendev.org/p/interop2020 Welcome to join weekly Friday Meetings (Refer NA/EU/APJ in etherpad below) https://etherpad.opendev.org/p/interop Appreciate all support from committee and special appreciation to Mark T Voelker for providing the bridge.He has been immensely valuable in bringing as Vice Chair the wealth of history to enable this Interop WG. ThanksPrakash

2 3

[cinder] impending SPECS FREEZE
by Brian Rosmaita 18 Jun '20

18 Jun '20

To all people with unmerged proposed Cinder specs: The spec freeze is less than 2 weeks away (Wed 1 July at 23:59 UTC). If you have questions or want live discussion of issues, take advantage of next week's Cinder virtual mid-cycle: DATE: 24 JUNE 2020 TIME: 1400-1600 UTC LOCATION: https://bluejeans.com/3228528973 Add your spec to the list of topics: https://etherpad.opendev.org/p/cinder-victoria-mid-cycles All proposed specs were discussed at the Victoria Virtual Midcycle; see the PTG etherpad for comments about yours: https://etherpad.opendev.org/p/victoria-ptg-cinder Additionally, the etherpad has links to recordings of the discussions. cheers, brian

1 0

[OSSN-0086] erratum: Dell EMC ScaleIO/VxFlex OS Backend Credentials Exposure
by Brian Rosmaita 18 Jun '20

18 Jun '20

As you may recall, the fix for this issue required patches for both Cinder and the os-brick library. The original patch for os-brick contained a flaw [0] that prevented the scaleio connector from operating when run under Python 2.7. Thus for OpenStack releases supporting Python 2.7 (that is, Train and earlier), a second os-brick patch is required and is listed below. (The Cinder and first os-brick patch are unchanged, but are listed below for completeness). [0] https://bugs.launchpad.net/os-brick/+bug/1883654 #### Patches #### Queens * cinder: https://review.opendev.org/733110 * os-brick: https://review.opendev.org/733104 and https://review.opendev.org/736749 Rocky * cinder: https://review.opendev.org/733109 * os-brick: https://review.opendev.org/733103 and https://review.opendev.org/736415 Stein * cinder: https://review.opendev.org/733108 * os-brick: https://review.opendev.org/733102 and https://review.opendev.org/736395 Train * cinder: https://review.opendev.org/733107 * os-brick: https://review.opendev.org/733100 and https://review.opendev.org/735989 Updated releases of os-brick incorporating the second patch are now available: Stein: os-brick 2.8.6 Train: os-brick 2.10.4 Point releases of cinder for Stein and Train will be made as soon as possible. These will be: Stein: cinder 14.1.1, requires os-brick 2.8.6 Train: cinder 15.2.1, requires os-brick 2.10.4 ### Contacts / References ### Author: Brian Rosmaita, Red Hat OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0086 Original LaunchPad Bug : https://bugs.launchpad.net/cinder/+bug/1823200 Mailing List : [Security] tag on openstack-discuss(a)lists.openstack.org OpenStack Security Project : https://launchpad.net/~openstack-ossg CVE: CVE-2020-10755

1 0

Re: [Release-job-failures] Release of openstack/puppet-nova for ref refs/tags/15.6.0 failed
by Emilien Macchi 18 Jun '20

18 Jun '20

Interesting. The tag was pushed but upload-git-mirror role failed: https://22ce6cebe995c8915d66-868b7eb6ba44b32e3b412bc5acf60e73.ssl.cf5.rackc… Is this a known issue? On Thu, Jun 18, 2020 at 2:23 PM <zuul(a)openstack.org> wrote: > Build failed. > > - openstack-upload-github-mirror > https://zuul.opendev.org/t/openstack/build/fd8c86f9b57947239bd0273424e1d4d5 > : FAILURE in 2m 30s > - release-openstack-puppet > https://zuul.opendev.org/t/openstack/build/05dd9c7ffdc74af5ae4065eb16a522f9 > : SUCCESS in 5m 40s > - announce-release > https://zuul.opendev.org/t/openstack/build/188851ebacf9455ab50edc2101ae02bc > : SUCCESS in 5m 31s > > _______________________________________________ > Release-job-failures mailing list > Release-job-failures(a)lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/release-job-failures > -- Emilien Macchi

3 4

[all][api] Service discovery guidelines moving into frozen state
by Michael McCune 18 Jun '20

18 Jun '20

hello all, this is a general advisory from the API SIG to inform the wider community that we are moving 2 guidelines[0][1] into a frozen state for final review. You can learn more about the API SIG guideline process in this document[2]. These guidelines have been in the drafting stage for quite a long time and it is with much exuberance that i send this message. I would also like to give special thanks to Monty Taylor for his continued guidance and oversight. if you are listed as a cross project liaison for the API SIG, you have automatically been added to the reviewer list for these merge requests. these guidelines will be merged in 1 week if there are no objections on the reviews. peace o/ [0] https://review.opendev.org/#/c/459710 [1] https://review.opendev.org/#/c/459405 [2] https://specs.openstack.org/openstack/api-sig/process.html

1 0

[edge] Edge summaries from the virtual PTG
by Ildiko Vancsa 18 Jun '20

18 Jun '20

Hi, It was great seeing many of you at the virtual PTG two weeks ago. I wrote up two blog posts to summarize edge related sessions at the event: * Edge Computing Group recap: https://superuser.openstack.org/articles/osf-edge-computing-group-ptg-overv… * StarlingX recap: https://www.starlingx.io/blog/starlingx-vptg-june-2020-recap/ The articles have pointers to the etherpads we used at the event and include further pointers as well in case you would like to follow up on either discussion item or missed the event and would like to get a somewhat detailed view of what was discussed. Thanks and Best Regards, Ildikó

1 0

mox3 project retirement
by Sean McGinnis 18 Jun '20

18 Jun '20

Hey everyone, Way back in Rocky, we had a cycle goal to stop using mox/mox3: https://governance.openstack.org/tc/goals/selected/rocky/mox_removal.html The mox library itself is from the broader community, but mox3 specifically was a fork we were maintaining of that lib to add Python 3.x support. Not a lot has been happening there (or luckily needed either), but it is still a repo we have had to maintain while we were transitioning away from mox to mock. There were still a few repos that had mox3 in their requirements files, even though I think in most cases the actual use was dropped awhile ago. With these recent set of patches to clean that up, and remove it from global requirements, we now no longer have any repos in the openstack/* namespace referencing mox3: https://review.opendev.org/#/q/topic:remove-mox3+(status:open+OR+status:mer… This is to announce my intent to officially retire the mox3 repo and clean things up. Of course the lib is still out there in pypi, and can be used by others. It is also possible for the repo to be restored or forked elsewhere if someone not in openstack/* has a strong need for it. But at least within the OpenStack community, I think our time is better spent elsewhere. https://docs.openstack.org/mox3/latest/ https://opendev.org/openstack/mox3 Please raise any concerns here. Thanks, Sean

2 1

no-cache-dir patch bomb
by Monty Taylor 18 Jun '20

18 Jun '20

Hi all! We’ve apparently just gotten a bazillion patches uploaded that do a global search and replace to add —no-cache-dir to all of the pip commands it can find. I have a couple of issues with this and think people should be very careful about landing them a) —no-cache-dir is NOT universally a good idea, and in many cases for interactive install using it will be a worse user experience. The linked post is specifically about reducing docker image size. b) Importantly, it’s updating all of the end-user installation docs. That is highly inappropriate and makes our docs much more user unfriendly, especially given (a) c) In some install scripts we’re going to run them potentially in devstack. While constraints SHOULD prevent a large amount of reinstalling of different versions of things over and over, we all know reality is messier. I think we want to think carefully about removing cache dir usage in devstack as it could actually lead to an increase in install time, and optimizing for docker image size is not a thing we’re attempting to do in functional tests. Regarding the docker image size optimization, for those who are building docker images, I would highly recommend either installing from bistro packages or using builder-image pattern instead. We have one implemented in opendevorg/python-builder and opendevorg/python-base - but the pattern can be implemented elsewhere. The main idea/benefit is to use a builder image to install dev tools and -dev packages with headers and things needed to build wheels, build wheels for all of the dependencies - then in a second build stage copy the wheels from the builder image and install them. We’re using a “compile” tag in binder to indicate what packages are needed for compile-time tasks. The savings from this can be substantial - obviously at the cost of greater complexity. In any case, I HIGHLY recommend not landing any of these patches as submitted. Monty

2 1

[nova] stein to train upgrade
by Amjad Kotobi 18 Jun '20

18 Jun '20

Hi all, I tried to upgrade nova-compute from stein -> train release and “openstack-nova-compute” couldn’t able to start and from log here is coming up ################### 2020-06-18 11:31:08.037 303344 ERROR oslo_service.service Traceback (most recent call last): 2020-06-18 11:31:08.037 303344 ERROR oslo_service.service File "/usr/lib/python2.7/site-packages/oslo_service/service.py", line 810, in run_service 2020-06-18 11:31:08.037 303344 ERROR oslo_service.service service.start() 2020-06-18 11:31:08.037 303344 ERROR oslo_service.service File "/usr/lib/python2.7/site-packages/nova/service.py", line 174, in start 2020-06-18 11:31:08.037 303344 ERROR oslo_service.service self.manager.init_host() 2020-06-18 11:31:08.037 303344 ERROR oslo_service.service File "/usr/lib/python2.7/site-packages/nova/compute/manager.py", line 1337, in init_host 2020-06-18 11:31:08.037 303344 ERROR oslo_service.service expected_attrs=['info_cache', 'metadata', 'numa_topology']) 2020-06-18 11:31:08.037 303344 ERROR oslo_service.service File "/usr/lib/python2.7/site-packages/oslo_versionedobjects/base.py", line 177, in wrapper 2020-06-18 11:31:08.037 303344 ERROR oslo_service.service args, kwargs) 2020-06-18 11:31:08.037 303344 ERROR oslo_service.service File "/usr/lib/python2.7/site-packages/nova/conductor/rpcapi.py", line 241, in object_class_action_versions 2020-06-18 11:31:08.037 303344 ERROR oslo_service.service args=args, kwargs=kwargs) 2020-06-18 11:31:08.037 303344 ERROR oslo_service.service File "/usr/lib/python2.7/site-packages/oslo_messaging/rpc/client.py", line 181, in call 2020-06-18 11:31:08.037 303344 ERROR oslo_service.service transport_options=self.transport_options) 2020-06-18 11:31:08.037 303344 ERROR oslo_service.service File "/usr/lib/python2.7/site-packages/oslo_messaging/transport.py", line 129, in _send 2020-06-18 11:31:08.037 303344 ERROR oslo_service.service transport_options=transport_options) 2020-06-18 11:31:08.037 303344 ERROR oslo_service.service File "/usr/lib/python2.7/site-packages/oslo_messaging/_drivers/amqpdriver.py", line 646, in send 2020-06-18 11:31:08.037 303344 ERROR oslo_service.service transport_options=transport_options) 2020-06-18 11:31:08.037 303344 ERROR oslo_service.service File "/usr/lib/python2.7/site-packages/oslo_messaging/_drivers/amqpdriver.py", line 636, in _send 2020-06-18 11:31:08.037 303344 ERROR oslo_service.service raise result 2020-06-18 11:31:08.037 303344 ERROR oslo_service.service RemoteError: Remote error: DBError (pymysql.err.InternalError) (1054, u"Unknown column 'instances.hidden' in 'field list ……. ################### I only took beginning part, the field doesn’t exist in DB, or? I also upgrade rest of the nova components[api-scheduler-conductor,…] but that didn’t go away. Any idea how to tackle this?

3 4

[all][release] One following-cycle release model to bind them all
by Thierry Carrez 18 Jun '20

18 Jun '20

Hi everyone, As you know[1] I'm trying to push toward simplification of OpenStack processes, to make them easier to navigate for new members of our community and generally remove weight. A good example of that is release models. We used to have a single model (with milestones and RCs) but over time we grew a number of alternative models to accommodate corner cases. The result is a confusing collection of release models with abstract rules for each and not much flexibility. Projects are forced to choose between those models for their deliverables, with limited guidance. And much of the rationale for those models (exercise release machinery early and often, trigger external testing...) is no longer valid. I'd like to suggest we simplify this and have a single model for things that follow the development cycle: the "follows-cycle" model. The only alternative, its nemesis, its Wario would be the "independent" release model. In the "follows-cycle" model, deliverables would be released at least once per cycle, but could be released more often. The "final" release would be marked by creating a release (stable) branch, and that would need to be done before a deadline. Like today, that deadline depends on whether that deliverable is a library, a client library, a release-trailing exception or just a regular part of the common release. The main change this proposal introduces would be to stop having release candidates at the end of the cycle. Instead we would produce a release, which would be a candidate for inclusion in the coordinated OpenStack release. New releases could be pushed to the release branch to include late bugfixes or translation updates, until final release date. So instead of doing a 14.0.0.0rc1 and then a 14.0.0.0rc2 that gets promoted to 14.0.0, we would produce a 14.0.0, then a 14.0.1 and just list that 14.0.1 in the release page at coordinated release time. I feel like this would not change that much for deliverables following the cycle-with-rc model. It would not change anything for cycle-with-intermediary, libraries or cycle-trailing deliverables. But it would simplify our processes quite a bit, and generally make our releases more consistent. Thoughts? [1] http://lists.openstack.org/pipermail/openstack-discuss/2020-March/013236.ht… -- Thierry Carrez (ttx)

12 31

[neutron] Tap-as-a-service releases on pypi behind
by Sam Morrison 17 Jun '20

17 Jun '20

It looks like tap-as-a-service project isn’t getting it’s latest releases pushed to pypi and this is breaking networking-midonet in train release. Source [1] has tags for releases 4.0.0, 5.0.0 and 6.0.0 but these aren’t in pypi [2] I need a fix [3] to upper-constraints to get this to work but just realised pypi is behind Can someone help me please. Thanks, Sam [1] https://opendev.org/x/tap-as-a-service/ <https://opendev.org/x/tap-as-a-service/> [2] https://pypi.org/project/tap-as-a-service/ <https://pypi.org/project/tap-as-a-service/> [3] https://review.opendev.org/#/c/735754/ <https://review.opendev.org/#/c/735754/>

4 8

[cinder] victoria virtual mid-cycle next week
by Brian Rosmaita 17 Jun '20

17 Jun '20

I know it seems early, but next week is R-16, and the spec freeze is R-15, so: Session One of the Cinder Victoria virtual mid-cycle will be held: DATE: 24 JUNE 2020 TIME: 1400-1600 UTC LOCATION: https://bluejeans.com/3228528973 The meeting will be recorded. Please add topics to the etherpad: https://etherpad.opendev.org/p/cinder-victoria-mid-cycles (Session Two will be held during the R-9 week. We'll do a poll to select the day/time around R-11.) cheers, brian

1 0

[tc] weekly update
by Mohammed Naser 17 Jun '20

17 Jun '20

Hi everyone, Here’s an update for what happened in the OpenStack TC last week. You can get more information by checking for changes in openstack/governance repository. We have some reviews that have been open for quite some time without many reviews. I’d like to kindly ask our technical committee members to review them. # OPEN REVIEWS - [draft] Add assert:supports-standalone https://review.opendev.org/#/c/722399/ [open for 42 days] - Update joining-tc.rst to be general tc-guide.rst https://review.opendev.org/#/c/732983/ - Remove grace period on resolutions https://review.opendev.org/#/c/735361/ - Deprecatre neutron-fwaas and neutron-fwaas-dashboard master branch https://review.opendev.org/#/c/735828/ - Record deprecated cycle for deprecated project https://review.opendev.org/#/c/736084/ - Add openstack-ansible-os_adjutant repo https://review.opendev.org/#/c/736140/ - Merging TC and UC into a single body https://review.opendev.org/#/c/734074/ # PROJECT UPDATES - Add whitebox-tempest-plugin under QA https://review.opendev.org/#/c/714480/ - Clarify the support for linux distro https://review.opendev.org/#/c/727238/ - Rename ansible-role-lunasa-hsm deliverable https://review.opendev.org/#/c/731313/ - Select migrate-to-focal goal for Victoria cycle https://review.opendev.org/#/c/731213/ # PROJECTS RETIRED - Remove congress project team https://review.opendev.org/#/c/728818/ # GENERAL CHANGES - Propose Kendall Nelson for vice-chair https://review.opendev.org/#/c/733141/ - Add njohnston liaison preference https://review.opendev.org/#/c/733269/ - Add diablo_rojo liaison preferences https://review.opendev.org/#/c/733284/ - Add gmann liaison preference https://review.opendev.org/#/c/734894/ - Fix Rally PTL email address https://review.opendev.org/#/c/735342/ # GOAL UPDATES - Add QA branchless projects also in py3.5 support list https://review.opendev.org/#/c/729325/ Regards, Mohammed -- Mohammed Naser VEXXHOST, Inc.

1 0

[cyborg][neutron][nova] Networking support in Cyborg
by Nadathur, Sundar 17 Jun '20

17 Jun '20

Hi all, Based on the Victoria PTG discussion [1], here's a stab at making some aspects of the Nova-Neutron-Cyborg interaction more concrete. * Background: A smart NIC may have a single 'device' that combines the accelerator and the NIC, or two (or more) components in a single PCI card, with separate accelerator and NIC components. * What we said in the PTG: We should model the smart NIC as a single RP representing the combined accelerator/NIC for the first case. For the second case, we could have a hierarchy with separate RPs for the accelerator and the NICs, and a top-level resource-less RP which aggregates all the children RPs and combines their traits. (Correspondingly, Cyborg may represent it as a single object, which we call a Deployable, or as a hierarchy of such objects. There is already support in Cyborg for creating a tree of such objects, though it may need validation for this use case.) * Who creates these RPs? I suggest Cyborg create it in all cases, to keep it uniform. Neutron creates RPs today for the bandwidth provider. But, if different services create RPs depend on which feature is enabled and whether it is a single/multi-component device, that can get complex and problematic. So, could we discuss the possibility of Neutron not creating the RP? The admin should not configure Neutron to handle such NICs. * Ideally, the admin should be able to formulate the device profile in the same way, independent of whether it is a single-component or multi-component device. For that, the device profile must have a single resource group that includes the resource, traits and Cyborg properties for both the accelerator and NIC. The device profile for a Neutron port will presumably have only one request group. So, the device profile would look something like this: { "name": "my-smartnic-dp", "groups": [{ "resources:FPGA": "1", "resources:CUSTOM_NIC_X": "1", "trait:CUSTOM_FPGA_REGION_ID_FOO": "required", "trait:CUSTOM_NIC_TRAIT_BAR": "required", "trait:CUSTOM_PHYSNET_VLAN3": "required", "accel:bitstream_id": "3AFE" }] } Having a single resource group for resources/traits for both accelerator and NIC would ensure that a single RP would provide all those resources, thus ensuring resource co-location in the same device. That single RP could be the top-level RP of a hierarchy. (If they were separate request groups, there is no way to ensure that the resources come from a single RP, even if we set group_policy to None.) * During ARQ binding, Cyborg would still get a single RP as today. In the case of a multi-component device, Cyborg would translate that to the top-level Deployable object, and figure out what constituent components are present. For this scheme to work, it is important that the resource classes and traits for the accelerator RP and the NIC RP be totally disjoint (no overlapping resource classes or traits). * We discussed the physnet trait at the PTG. My suggestion is to keep Cyborg out of this, and out of networking in general, if possible. [1] https://etherpad.opendev.org/p/nova-victoria-ptg "Cyborg-Nova" Lines 104-164 Regards, Sundar

5 7

[neutron] neutron router gateway set will waste a public ip. How to avoid it?
by Zhengyu Pan 17 Jun '20

17 Jun '20

Hi, when i set a gateway for router,(neutron router-gateway-set router external-network), it will allocate a IP address for qg interface. For me, this IP address is useless. I use floatingip to connect external network. Is there a way to avoid allocating this gateway IP for router qg interface? --

3 2

Openstack user surver - questions
by Slawek Kaplonski 17 Jun '20

17 Jun '20

Hi, First of all sorry if I didn't look for it long enough but I have couple of questions about user surver and I couldn't find answer for them anywhere. 1. I was looking at [1] for some Neutron related data and I found only one questions about used backends in "Deployment Decisions". Problem is that this graph is for me a bit unreadable due to many things on x-axis which overlaps each other. Is there any place where I can find some "raw data" to check? 2. Another question about the same chart is: is there any way to maybe change possible replies in the surver for next years? I'm asking about that becasue I have a feeling that e.g. responses "Open vSwitch" and "ML2 - Open vSwitch" may be confusing for users. My understanding is that "Open vSwitch" means simply old "Open vSwitch" core plugin instead of ML2 plugin but this old plugin was removed around "Libery" cycle so I really don't think that still 37% of users are using it. 3. Is there any way to propose new, more detailed questions about e.g Neutron? For example what service plugins they are using. [1] https://www.openstack.org/analytics -- Slawek Kaplonski Senior software engineer Red Hat

2 4

[neutron] Failed to create a duplicate DefaultSecurityGroup
by Neil Jerram 17 Jun '20

17 Jun '20

With Ussuri I'm hitting this in the neutron server: Failed to create a duplicate DefaultSecurityGroup: for attribute(s) ['PRIMARY'] with value(s) 11447be9beda4bf78dab27cdb75058e2 pymysql.err.IntegrityError: (1062, "Duplicate entry '11447be9beda4bf78dab27cdb75058e2' for key 'PRIMARY'") oslo_db.exception.DBDuplicateEntry: (pymysql.err.IntegrityError) (1062, "Duplicate entry '11447be9beda4bf78dab27cdb75058e2' for key 'PRIMARY'") [SQL: INSERT INTO default_security_group (project_id, security_group_id) VALUES (%(project_id)s, %(security_group_id)s)] [parameters: {'project_id': '11447be9beda4bf78dab27cdb75058e2', 'security_group_id': '9f3a473c-b08a-4cf2-8327-10ecc8b87301'}] neutron_lib.objects.exceptions.NeutronDbObjectDuplicateEntry: Failed to create a duplicate DefaultSecurityGroup: for attribute(s) ['PRIMARY'] with value(s) 11447be9beda4bf78dab27cdb75058e2 (Those are all, I believe, reports of the same problem, at different levels of the stack.) IIUC, this is triggered by my Neutron driver calling rules = self.db.get_security_group_rules( context, filters={'security_group_id': sgids} ) where the context has project_id 11447be9beda4bf78dab27cdb75058e2. Deep down inside that call, Neutron tries to ensure that there is a default security group for that project, and somehow that hits the reported exception. Here's the code in securitygroups_db.py: def _ensure_default_security_group(self, context, tenant_id): """Create a default security group if one doesn't exist. :returns: the default security group id for given tenant. """ default_group_id = self._get_default_sg_id(context, tenant_id) if default_group_id: return default_group_id security_group = { 'security_group': {'name': 'default', 'tenant_id': tenant_id, 'description': _('Default security group')} } return self.create_security_group(context, security_group, default_sg=True)['id'] Obviously it checks first if the default SG already exists for the project, before creating it if not. So why would that code hit the duplicate exception as shown above? Any ideas welcome! Best wishes, Neil

2 4

[manila] Summary of the Victoria Cycle Project Technical Gathering
by Goutham Pacha Ravi 16 Jun '20

16 Jun '20

Hello Zorillas and other friendly animals of the OpenStack universe, The manila project community met virtually between 1st June and 5th June and discussed project plans for the Victoria cycle. The detailed meeting notes are in [1] and the recordings were published [2]. A short summary of the discussions and the action items is below: *== Ussuri Retrospective ==* - We lauded the work that Vida Haririan and Jason Grosso have put into making bug tracking and triaging a whole lot easier, and systematic. At the beginning of the cycle, we had roughly 250 bugs, and this was brought down to under 130 by the end of the cycle. As a community, we acted upon many multi-release bugs and made backports as appropriate. We've now automated the expiry of invalid and incomplete bugs thereby reducing noise. Vida's our current Bug Czar, and is interested in mentoring anyone that wants to contribute to this role. Please reach out to her if you're interested. - We also had two successful Outreachy internships (Soledad Kuczala/solkz, Maari Tamm/maaritamm) thanks to Outreachy, their sponsors, mentors (Sofia Enriquez/enriquetaso, Victoria Martinez de la Cruz/vkmc) and the OpenStack Foundation; and a successful Google Summer of Code internship (Robert Vasek/gman0) - many thanks to the mentor (Tomas Smetana/tsmetana), Google, Red Hat and other sponsoring organizations. The team learned a lot, and vkmc encouraged all of us to consider submitting a mentorship application for upcoming cycles and increase our involvement. Through the interns' collective efforts in Train and Ussuri development cycles: - manila CSI driver was built [3] - manilaclient now provides a plugin to the OpenStackClient - manila-ui has support for newer microversions of the manila API and, - manila documentation has gotten a whole lot better! - We made good core team improvements and want to continue to mentor new contributors to become maintainers, and folks felt their PTL was doing a good job (:D) - The community loved the idea of PTL docs (thanks Kendall Nelson/diablo_rojo) - a lot of tribal knowledge was documented for the first time! - We felt that "low-hanging-fruit" bugs [4] were lingering too long in some cases, and must have a "resolve-by" date. These are farmed for new contributors, and if they turn out to be annoying issues, the team may set a resolve-by date and close them out. However, we'll continue to make a concerted effort to triage "bugs that are tolerable" with nice-to-have fixes and keep them handy for anyone looking to make an initial contribution. *== Optimize query speed for share snapshots ==* Haixin (haixin) discovered that not all APIs are taking advantage of filtering and pagination via sqlalchemy. There's a list of APIs that he's compiled and would like to work on them; the team agreed that this is a valuable bug fix; and can be made available to Ussuri when the fixes land in this cycle. *== TC Goals for Victoria cycle ==* - We discussed a long list of items that were proposed for inclusion as TC goals [5]. The TC has officially picked two of them for this cycle [6]. - For gating manila project repos, we make heavy use of "legacy" DSVM jobs. We hadn't invested time and effort in converting these jobs in the past cycles; however, we have a plan [7] and have started porting jobs to "native" zuulv3 format already in the manila-tempest-plugin repository. Once these jobs are complete there, we'll switch over to using them on the main branch of manila. Older branches will get opportunistic updates beyond milestone-2. - Luigi Toscano (tosky) joined us for this discussion and asked us for the status of third party CI systems. The team hasn't mandated that third party CI systems move their testing to zuulv3-native in this cycle. However, the OpenStack community may drop support for devstack-gate in the Victoria release, and making things work with it will get harder - so it's strongly encouraged that third party vendor systems that are using the community testing infrastructure projects: zuul, nodepool and devstack-gate move away from devstack-gate in this cycle. An option to adopt Zuulv3 in third party CI systems could be via the Software Factory project [8]. The RDO community runs some third party jobs and votes on OpenStack upstream projects - so they've created a wealth of jobs and documentation that can be of help. Maintainers of this project hang out in #softwarefactory on FreeNode. - All of the new zuulv3 style tempest jobs inherit from devstack-tempest from the tempest repository, and changing the node-set in the parent would affect all our jobs as well - this would make the transition to Ubuntu 20.04 LTS/Focal Fossa easier. *== Secure default policies and granular policies ==* - Raildo Mascena (raildo) joined us and presented an overview this cross-community effort [9] - Manila has many assumptions of what project roles should be - and over time, we seem to have blended the idea of a deployer administrator and a project administrator - so there are inconsistencies when, even to perform project level administration, one needs excessive permissions across the cloud. This is undesirable - so, a precursor to supporting the new scoped policies from Keystone seems to be to: - eliminate hard coded checks in the code requiring an "admin" role and switch to performing policy checks - eliminating empty defaults which allow anyone to execute an API - manila has very few of these - supporting a "reader" role with the APIs - We can then re-calibrate the defaults to ensure a separation between cross-tenant administration (system scope) and per-tenant administration - following the work in oslo.policy and in keystone - gouthamr will be leading this in the Victoria cycle - other contributors are welcome to join this effort! *== Oslo.privsep and other manila TODOs ==* - We discussed another cross-community effort around transitioning all sudo actions from rootwrap to privsep - Currently no one in the manila team has the bandwidth to investigate and commit to this effort, so we're happy to ask for help! - If you are interested, please join us during one of the team meetings or start submitting patches and we can discuss with you via code reviews. - The team also compiled a list of backlog items in an etherpad [10]. These are great areas for new project contributors to help manila, so please get in touch with us if you would like to work on any of these items *== OSC Status/Completion ==* - Victoria Martinez de la Cruz and Maari Tamm compiled the status for the completion of the OSC plugin work in manilaclient [11] - There's still a lot of ground to cover to get complete parity with the manila command line client, and we need contributors - Maari Tamm (maaritamm) will continue to work on this as time permits. Spyros Trigazis (strigazi) and his team at CERN are interested to work on this as well. Thank you, Maari and Spyros! - On Friday, we were joined by Artem Goncharov (gtema) to discuss the issue of "common commands" - quotas, services, availability zones, limits are common concepts that apply to other projects as well - OSC has support to show you these resources for compute, volume and networking - gtema suggested we should approach this via the OpenStackSDK rather than the plugin since plugins are slow as is, and adding anything more to that interface is not desirable at the moment - There's planned work in the OpenStackClient project to work on the plugin loading mechanisms to make things faster *== Graduation of Experimental Features ==* - Last cycle Carlos Eduardo (carloss) committed the work to graduate Share Groups APIs from their "Experimental API" status - We have two more features behind experimental APIs: share replication and share migration - This cycle, carloss will work on graduating the share replication APIs to fully supported - Generic Share Migration still needs some work, but we've fleshed out the API and it has stayed pretty constant in the past few releases - we might consider graduating the API for share migration in the Wallaby release. *== CephFS Updates ==* - Victoria (vkmc) took us through the updates planned for the Victoria cycle (heh) - Currently all dsvm/tempest based testing in OpenStack (cinder, nova, manila) is happening on ceph luminous and older releases (hammer and jewel) - Victoria has a patch up [12] to update the ceph cluster to using Nautilus by default - This patch moves to using the packages built by the ceph community via their shaman build system [13] - shaman does not support building nautilus on CentOS 8, or on Ubuntu Xenial - so if older branches of the projects are tested with Ubuntu Xenial, we'll fall back to testing with Luminous - The Manila CephFS driver wants to take advantage of the "ceph-mgr" daemon in the Nautilus release and beyond - Maintaining support for "ceph-mgr" and "ceph-volume" clients in the driver will make things messy - so, the manila driver will not support Ceph versions prior to Nautilus in the Victoria cycle - If you're using manila with cephfs, please upgrade your ceph clusters to Nautilus or newer - We're not opposed to supporting versions prior to nautilus, but the community members cannot invest in maintaining support for these older releases of ceph for future releases of manila - With the ceph-mgr interface, we intend to support asynchronous create-share-from-snapshot with manila - Ramana Raja (rraja) provided us an update regarding the ceph-mgr and upcoming support for nfs-ganesha interactions via that interface (ceph pacific release) - Currently there's a ganesha interface driver in manila, and that can switch to using the ceph-mgr interface - Manila provides an "ensure_shares" mechanism to migrate share export locations when the NAS host changes - We'll need to work on that if we want to make it easier to switch ganesha hosts. - We also briefly discussed supporting manage and unmanage operations with the ceph drivers - that should greatly assist day 2 operations, and migration of shared file systems from the native cephfs protocol to nfs and vice-versa. *== Add/Delete/Update security services for in-use share networks ==* - Douglas Viroel (dviroel) discussed a change to manila to support share server modifications wrt security services - Security services are project visible and tenant driven - however, share servers are hidden away from project users by virtue of default policy - dviroel's idea is that, If a share network has multiple share servers, the share manager will enumerate and communicate with all share servers on the share network to update a security service - We need to make sure that all conflicting operations (such as creating new shares, changing access rules on existing shares) are fenced off when a share server security service is being updated - dviroel has a spec that he's working on - and would like feedback on his proposal [14] *== Create shares with two (or more) subnets ==* - dviroel proposed a design allowing a share network having multiple subnets in a given AZ (currently you can have utmost 1 subnet in an AZ for a given share network) - Allowing multiple NICs on a share server may be something most drivers can easily support - This change is identical to the one to update security services on existing share networks - in terms of user experience and expectations - The use cases here include dual IP support, share server network maintenance and migration, simultaneous access from disparate subnets - Feedback from this discussion was to treat this as two separate concerns for easier implementation - Supporting multiple subnets per AZ per share network - Supporting adding/removing subnets to/from a share network that is in-use - Currently, there's no way to modify an in-use share server - so adding that would be a precursor to allowing modification of share networks/subnets and security services *== Technical Committee Tags ==* - In the last cycle, the manila team worked with OpenStack VMT to perform a vulnerability disclosure and coordinate a fix across distributions that included manila. - The experience was valuable in gaining control of our own "coresec" team that had gone wayward on launchpad; and learning about VMT - Jeremy Stanley (fungi) and other members of the VMT have been supportive of having manila apply to the "vulnerability-managed" tag. We'll follow up on this soon - While we're on the subject, with Ghanshyam Mann (gmann) in the room, we discussed other potential tags that we can assert as the project team: - "supports-accessible-upgrade" - manila allows control plane upgrade without disrupting the accessibility of shares, snapshots, ACLs, groups, replicas, share servers, networks and all other resources [15] - "supports-api-interoperability" - manila's API is microversioned and we have hard tests that enforce backwards compatibility [16] - We discussed "tc:approved-release" tag a bit, and felt that we needed to bring it up in a TC meeting, and we did that with Ghanshyam's help - The view from the manila team is that we'd like to eliminate any misconception that the project is not mature, or ready for production use or that it isn't a part of a "core OpenStack" - At the TC meeting, Thierry Carrez (ttx), Graham Hayes (mugsie) and the others provided historic context for this tag: the tag was for a section from the OpenStack foundation bylaws that states that the Technical Committee must define what an approved release is (Article 4, section 4.1 (b) i) [17] - The TC's view was that this tag has outlived its purpose and core-vs-non-core discussions have happened a lot of times. Dropping this tag might require speaking with the Foundation and amending the bylaws and exploring what this implies. It's a good effort to get started on though. - For the moment, The TC was not opposed to the manila team requesting this change to include manila in the list of projects in "tc-approved-release". *== Share and share size quotas/limits per share server ==* - carloss shared his design for allowing share server limits being enforced via the quotas system where administrators could define project share server quotas that the share manager would enforce these by provisioning new servers when the quotas are hit - the quotas system is ill suited for this sort of enforcement, specially given that the share manager allows the share drivers to control what share server can be used to provision a share - it's possible to look for a global solution, like the one proposed for the generic driver in [18], or implement this at a backend level agnostic to the rest of manila - another reason not to use quotas is that manila may eventually do away with this home grown quota system in favor of oslo.limit enforced via keystone - another alternative to doing this is via share types, but, this really fits as a per-share-network limit rather than a global one *== Optimize the quota processing logic for 'manage share' ==* - haixin ran into a bug where quota operations are incorrectly applied for during a share import/manage operation such that a failed manage operation would cause incorrect quota deductions - we discussed possible solutions for the bug, but mostly, this can definitely be fixed - he opened a bug for this [19] *== Share server migration ==* - dviroel presented his thoughts around this new feature [20] which would be helpful for day 2 operations - he suggested that we should not provide for a generic mechanism to perform this migration, given that users would not need it especially if it is not 100% reliable - though there is a generic framework for provisioning share servers, it is only being used by the reference driver (Generic driver) and the Windows SMB driver - shooting for a generic solution would require us to solve SPOF issues that we currently have with the reference driver - and there is not much investment in doing so - dviroel's solution involves a multi-step migration, however relying on the share drivers to perform atomic migration of all the shares - you can think of this wrt the Generic driver as multi-attaching all the underlying cinder volumes and deleting the older nova instance. - manila's share migration is multi-step allowing for a data copy and a cutover phase - and is cancelable through the data copy phase and before the cutover phase is invoked - so there were some concerns if that two phased approach is required here, given that the operation may not be cancelable always, generically *== Manila Container Storage Interface ==* - Tom Barron (tbarron) presented a summary and demo of using the Manila CSI driver on OpenShift to provide RWX storage to containerized applications - Robert Vasek (gman0) explained the core design and the reasoning behind the architecture - Mikhail Fedosin (mfedosin) spoke about the OpenShift operator for Manila CSI and the ease of install and day two operations [21] - the CSI driver has support for snapshots, cloning of snapshots (nfs only at the moment) and topology aside from provisioning, access control and deprovisioning - the team's prioritizing supporting cephfs snapshots and creating shares from cephfs snapshots via subvolume clones in the Victoria cycle Thanks for reading this far! Should you have any questions, don't hesitate to pop into #openstack-manila on freenode.net. [1] https://etherpad.opendev.org/p/victoria-ptg-manila (Minutes of the PTG) [2] https://www.youtube.com/playlist?list=PLnpzT0InFrqBKkyIAQdA9RFJnx-geS3lp (YouTube playlist of the PTG recordings) [3] https://github.com/kubernetes/cloud-provider-openstack/blob/master/docs/usi… (Manila CSI driver docs) [4] https://bugs.launchpad.net/manila/+bugs?field.tag=low-hanging-fruit (Low hanging fruit bugs in Manila) [5] https://etherpad.opendev.org/p/community-goals (Community goal proposals) [6] http://lists.openstack.org/pipermail/openstack-discuss/2020-June/015459.html (Chosen TC Community Goals for Victoria cycle) [7] https://tree.taiga.io/project/gouthampacha-manila-ci-zuul-v3-migration/kanb… (Zuulv3-native CI migrations tracker) [8] https://www.softwarefactory-project.io/ (Software Factory project) [9] https://wiki.openstack.org/wiki/Consistent_and_Secure_Default_Policies_Popu… (Policy effort across OpenStack) [10] https://etherpad.opendev.org/p/manila-todos (ToDo list for manila) [11] https://etherpad.opendev.org/p/manila-openstackclient-updates (OSC CLI catchup tracker) [12] https://review.opendev.org/#/c/676722/ (devstack-plugin-ceph support for Ceph Nautilus) [13] https://shaman.ceph.com (Shaman build system for Ceph) [14] https://review.opendev.org/#/c/729292/ (Specification to allow security service updates) [15] https://governance.openstack.org/tc/reference/tags/assert_supports-accessib… (TC tag for accessible upgrades) [16] https://governance.openstack.org/tc/reference/tags/assert_supports-api-inte… (TC tag for API interoperability) [17] https://www.openstack.org/legal/bylaws-of-the-openstack-foundation#ARTICLE_… (TC bylaws requiring "approved release") [18] https://review.opendev.org/#/c/510542/ (Limitting the number of shares per Share server) [19] https://bugs.launchpad.net/manila/+bug/1883506 (delete manage_error share will lead to quota error) [20] https://review.opendev.org/#/c/735970/ (specification for share server migration) [21] https://github.com/openshift/csi-driver-manila-operator

1 0

[cyborg]Cyborg Victoria Release Schedule and storyboard update for Contributors
by yumeng bao 16 Jun '20

16 Jun '20

Hi team and interested contributors! A detailed release schedule[1] is proposed according to all the goals[2] we've confirmed at Virtual PTG. These two materials will form the basis for our development throughout this cycle release. Goals with tag [open-to-all] are open to everyone to take, if you are interested, please feel free to ask questions directly here or ping Yumeng at IRC Channel #openstack-cyborg ! Another thing is about the storyboard. After Rocky, Cyborg has migrated from cyborg-launchpad to cyborg-storyboard to track bugs and features. But we were not using it very well. From Victoria, we will use it, use it well, and use it often. So please take some time to get familiar with the cyborg specific storyboard usage guide[3]. [1]https://wiki.openstack.org/wiki/Cyborg/Victoria_Release_Schedule#Blueprin… [2]https://etherpad.opendev.org/p/cyborg-victoria-goals [3]https://wiki.openstack.org/wiki/Cyborg/CyborgStoryboard Regards， Yumeng

1 0

[ironic] advanced partitioning discussion
by Dmitry Tantsur 16 Jun '20

16 Jun '20

Hi folks, As a follow up to the PTG discussion, I'd like to schedule a call about advanced partitioning in ironic. Please vote for the date and time next week: https://doodle.com/poll/5yg93gv7casu3ate Dmitry

2 3

[scientific-sig] IRC Meeting Wednesday 1100UTC - Supporting COVID workloads on OpenStack
by Stig Telfer 16 Jun '20

16 Jun '20

Hi all - We have a Scientific SIG meeting coming up on Wednesday at 1100 UTC in IRC channel #openstack-meeting. Everyone is welcome. In this week's agenda we are hoping to gather experiences from people working to support COVID-19 workloads on their OpenStack systems. This could be biochemistry simulations, or supporting contact tracing, or whatever. It would be interesting to hear what people are doing and share experiences if we can. The full agenda is available here: https://wiki.openstack.org/wiki/Scientific_SIG#IRC_Meeting_June_17th_2020 Cheers, Stig

1 0

[all] oslotest removing mock as a dependency
by Ben Nemec 16 Jun '20

16 Jun '20

Hi all, In keeping with the move from the third-party mock library to the built-in unittest.mock module, oslotest is removing mock as a dependency (again). We tried this at the end of the last cycle, but it turned out a number of projects were relying on oslotest to pull in mock for them so in order to not hold up the release we reverted the change. We've un-reverted it and the release request is now merged, so if you were previously relying on oslotest to install mock in your tests you will now need to do one of the following: 1) Migrate to unittest.mock (preferred) or 2) Explicitly depend on mock in your test-requirements.txt. If you have any questions about this, let us know. Thanks. -Ben

1 0

RE: python-dracclient
by Christopher.Dearborn＠dell.com 16 Jun '20

16 Jun '20

My apologies if this email is a duplicate. Resending because I had some issues with my subscription and can’t tell if the original was actually delivered to the list or not. Thanks, Chris From: Dearborn, Chris Sent: Monday, June 15, 2020 4:52 PM To: 'Ewan Hamilton' Cc: 'openstack-discuss(a)lists.openstack.org' Subject: RE: python-dracclient Hey Ewan, Good to meet you! We’re thrilled that you are looking at using python-dracclient to work with your Dell EMC servers. Python-dracclient was originally developed for use by the iDRAC driver in the Ironic project. The iDRAC driver documentation needed quite a bit of work as well, and I’m happy to say that we did overhaul it in a recent release. Since python-dracclient has been a library primarily used by Ironic, the documentation for it has been overlooked up to this point. We instead have focused on adding new features and functionality, as well as fixing the occasional bug in both python-dracclient and the Ironic iDRAC driver. As a result of your email, we’re looking at updating the documentation for python-dracclient in our upcoming release. In the meantime, there are some great opensource examples that use python-dracclient, which will hopefully be helpful to you: * This is a simple utility that checks to see if the iDRAC is ready to receive commands: * https://github.com/dsp-jetpack/JetPack/blob/master/src/pilot/is_idrac_ready… * Note that this “is ready?” check is built into python-dracclient, so it’s not something you will need to do in your code. You could replace the call to is_idrac_ready() in the example with another call though. * This is a utility that resets the iDRAC, clears the job queue, then configures the boot mode, boot device, iDRAC settings, and it will even optionally change the iDRAC password. Note that this script works in a tripleo environment, so it will need some tweaking if you want to use it stand-alone: * https://github.com/dsp-jetpack/JetPack/blob/master/src/pilot/config_idrac.py * This is a utility that discovers iDRACs in an IP range that you provide including discovering the service tag and server model: * https://github.com/dsp-jetpack/JetPack/blob/master/src/pilot/discover_nodes… * And finally, the Ironic iDRAC driver makes extensive use of python-dracclient, but it is also probably the most complicated example: * https://github.com/openstack/ironic/tree/master/ironic/drivers/modules/drac As far as how python-dracclient originally got it’s name, I’m not really sure about that as we inherited the original repo from other developers who no longer work on the project. I suspect it was picked because it followed the naming conventions of at least some other library repos in OpenStack at that time. The WSManClient class is defined in https://github.com/openstack/python-dracclient/blob/master/dracclient/clien…, and it is a class that is only used internally to python-dracclient. To use python-dracclient, you should only have to: from dracclient import client Then, you can call any method in the DRACClient class here: https://github.com/openstack/python-dracclient/blob/master/dracclient/clien… If you want to view the python-dracclient code in a development environment editor, then you would need to modify the PYTHONPATH or equivalent in the dev environment to include the path to the directory containing python-dracclient/dracclient/client.py, and then it should be able to resolve everything. Feel free to reply on this list if you need a hand, or you can always email me directly. Thanks and happy hacking! Chris Dearborn Software Sr Principal Engr Dell EMC | Service Provider Engineering Christopher.Dearborn(a)Dell.com<mailto:Christopher.Dearborn@Dell.com> From: Ewan Hamilton <ewan.hamilton(a)managed.co.uk<mailto:ewan.hamilton@managed.co.uk>> Sent: Monday, June 15, 2020 1:43 PM To: openstack-discuss(a)lists.openstack.org<mailto:openstack-discuss@lists.openstack.org> Subject: python-dracclient [EXTERNAL EMAIL] Hi guys, Your documentation for python-dracclient begins here: https://docs.openstack.org/python-dracclient/latest/usage.html with Usage Create a client object by providing the connection details of the DRAC card: client = wsmanclient.client.DRACClient('1.2.3.4', 'username', 's3cr3t') There is no import statement – and when I have searched google and found “import dracclient” because the assumed “import python-dracclient” doesn’t work due to a hyphen (why would you name your module with a hyphen in the first place?!), it doesn’t recognise “wsmanclient” in the editor still. Can you see just how frustrating this is for someone who expects documentation that actually works and explains how to actually use the module?

1 0

[neutron][qos] Meeting cancelled
by Rodolfo Alonso Hernandez 16 Jun '20

16 Jun '20

Hello: Due to the lack of agenda, I'll cancel today's meeting. Regards.

1 0

Ceph Integration on Openstack Platform
by Merve ASLAN 15 Jun '20

15 Jun '20

Hi, I've wanted to use ceph storage as a backend for nova, glance and cinder. I've succeded to use ceph for cinder and glance but I couldn't at nova. I have seen this bug for "Stein" version ---> https://bugs.launchpad.net/nova/stein/+bug/1860990 Bug #1860990 “RBD image backend tries to flatten images even if ...” : Series stein : Bugs : OpenStack Compute (nova)<https://bugs.launchpad.net/nova/stein/+bug/1860990> bugs.launchpad.net When [DEFAULT]show_multiple_locations option is not set in glance, and both glance and nova use ceph as their backend, with properly configured accesses, nova will fail with the following exception: 2020-01-23 14:36:43.617 8647 ERROR nova.compute.manager [req-8021fd76-d5ab-4a9b-bd17-f5eb4d4faf62 0e96a04f360644818632b7e46fe8d3e7 ac01daacc7424a40b8b464a163902dcb - default default] [instance: fa9e4118-1bb1-4d52-a2e1-9f61b0e20dc6] Instance failed to spawn: rbd.InvalidArgument: [errno 22] error f... After that, I've entered the nova-compute pod and I've run below commands; apt install python-rbd apt install python3-rbd But it didn't work. I've gotten same error. A solution must be on the K8s side. error; 2020-06-15 12:34:23.617 21543 ERROR nova.compute.manager File "/var/lib/openstack/lib/python3.6/site-packages/nova/virt/libvirt/driver.py", line 1216, in _get_rbd_driver 2020-06-15 12:34:23.617 21543 ERROR nova.compute.manager rbd_user=CONF.libvirt.rbd_user) 2020-06-15 12:34:23.617 21543 ERROR nova.compute.manager File "/var/lib/openstack/lib/python3.6/site-packages/nova/virt/libvirt/storage/rbd_utils.py", line 128, in __init__ 2020-06-15 12:34:23.617 21543 ERROR nova.compute.manager raise RuntimeError(_('rbd python libraries not found')) 2020-06-15 12:34:23.617 21543 ERROR nova.compute.manager RuntimeError: rbd python libraries not found Nova compute image; [cid:e78156d8-4edf-4abd-8585-7e346fb1f879] Do you have any of ideas about that? Best Regards, [cid:image100503.PNG@466e127b.4087c56f]<http://www.havelsan.com.tr> [cid:image9bdac0.JPG@2b00e707.4cb2e69f] Merve ASLAN SİSTEM MÜHENDİSİ Mustafa Kemal Mahallesi 2120 Cad. No:39 06510 Çankaya Ankara TÜRKİYE [cid:imagea7e2da.PNG@49bdc19b.4eabdf05] +90 312 219 57 87 [cid:imaged072fc.PNG@50ceb928.4cb632fd] +90 312 219 57 97 [cid:image987ca6.JPG@943a32e9.4ebc9425] YASAL UYARI: Bu elektronik posta işbu linki kullanarak ulaşabileceğiniz Koşul ve Şartlar dokümanına tabidir. <https://havelsan.com.tr/sabit-sayfalar/eposta-yasal-uyari> LEGAL NOTICE: This e-mail is subject to the Terms and Conditions document which can be accessed with this link. <https://havelsan.com.tr/sabit-sayfalar/eposta-yasal-uyari> Lütfen gerekmedikçe bu sayfa ve eklerini yazdırmayınız / Please consider the environment before printing this email

2 1

python-dracclient
by Ewan Hamilton 15 Jun '20

15 Jun '20

Hi guys, Your documentation for python-dracclient begins here: https://docs.openstack.org/python-dracclient/latest/usage.html with Usage Create a client object by providing the connection details of the DRAC card: client = wsmanclient.client.DRACClient('1.2.3.4', 'username', 's3cr3t') There is no import statement - and when I have searched google and found "import dracclient" because the assumed "import python-dracclient" doesn't work due to a hyphen (why would you name your module with a hyphen in the first place?!), it doesn't recognise "wsmanclient" in the editor still. Can you see just how frustrating this is for someone who expects documentation that actually works and explains how to actually use the module? This is a pathetic job here. Ewan Hamilton 3rd Line Networks Analyst t: 0800 033 4800 ext. 2212 | m: 07772 001 625 Technology House, 151 Silbury Boulevard, Milton Keynes, MK9 1LH managed. is a trading name of Managed247 Ltd Managed247 Ltd is a company registered in England and Wales under number 7019261

4 4

[tc][uc][all] Starting community-wide goals ideas for V series
by Ghanshyam Mann 15 Jun '20

15 Jun '20

Hello everyone, We are in R14 week of Ussuri cycle which means It's time to start the discussions about community-wide goals ideas for the V series. Community-wide goals are important in term of solving and improving a technical area across OpenStack as a whole. It has lot more benefits to be considered from users as well from a developers perspective. See [1] for more details about community-wide goals and process. We have the Zuulv3 migration goal already accepted and pre-selected for v cycle. If you are interested in proposing a goal, please write down the idea on this etherpad[2] - https://etherpad.openstack.org/p/YVR-v-series-goals Accordingly, we will start the separate ML discussion over each goal idea. Also, you can refer to the backlogs of community-wide goals from this[3] and ussuri cycle goals[4]. NOTE: TC has defined the goal process schedule[5] to streamlined the process and ready with goals for projects to plan/implement at the start of the cycle. I am hoping to start that schedule for W cycle goals. [1] https://governance.openstack.org/tc/goals/index.html [2] https://etherpad.openstack.org/p/YVR-v-series-goals [3] https://etherpad.openstack.org/p/community-goals [4] https://etherpad.openstack.org/p/PVG-u-series-goals [5] https://governance.openstack.org/tc/goals/#goal-selection-schedule -gmann

10 22

Fw: nova compute rbd backend error
by Nazan CENGİZ 15 Jun '20

15 Jun '20

I've wanted to use ceph storage as a backend for nova, glance and cinder. I've succeded to use ceph for cinder and glance but I couldn't at nova. I have saw this bug for "Stein" version ---> https://bugs.launchpad.net/nova/stein/+bug/1860990 After that, I've entered the nova-compute pod and I've run below commands; apt install python-rbd apt install python3-rbd But it didn't work. I've gotten same error. A solution must be on the K8s side. Do you have any of ideas about that? error; 2020-06-15 12:34:23.617 21543 ERROR nova.compute.manager File "/var/lib/openstack/lib/python3.6/site-packages/nova/virt/libvirt/driver.py", line 1216, in _get_rbd_driver 2020-06-15 12:34:23.617 21543 ERROR nova.compute.manager rbd_user=CONF.libvirt.rbd_user) 2020-06-15 12:34:23.617 21543 ERROR nova.compute.manager File "/var/lib/openstack/lib/python3.6/site-packages/nova/virt/libvirt/storage/rbd_utils.py", line 128, in __init__ 2020-06-15 12:34:23.617 21543 ERROR nova.compute.manager raise RuntimeError(_('rbd python libraries not found')) 2020-06-15 12:34:23.617 21543 ERROR nova.compute.manager RuntimeError: rbd python libraries not found Nova compute image; [cid:e78156d8-4edf-4abd-8585-7e346fb1f879] Best Regards, Nazan [cid:image179c53.PNG@04e4c522.47980262]<http://www.havelsan.com.tr> [cid:imagebda6b1.JPG@83e469a0.4b8f3b2e] Nazan CENGİZ AR-GE MÜHENDİSİ Mustafa Kemal Mahallesi 2120 Cad. No:39 06510 Çankaya Ankara TÜRKİYE [cid:image0a77f4.PNG@7b7ae2c0.4489d17b] +90 312 219 57 87 [cid:image1bd9c3.PNG@4ea6bc72.42af5879] +90 312 219 57 97 [cid:image7abae9.JPG@fff6a90f.4d8b49ff] YASAL UYARI: Bu elektronik posta işbu linki kullanarak ulaşabileceğiniz Koşul ve Şartlar dokümanına tabidir. <https://havelsan.com.tr/sabit-sayfalar/eposta-yasal-uyari> LEGAL NOTICE: This e-mail is subject to the Terms and Conditions document which can be accessed with this link. <https://havelsan.com.tr/sabit-sayfalar/eposta-yasal-uyari> Lütfen gerekmedikçe bu sayfa ve eklerini yazdırmayınız / Please consider the environment before printing this email

1 5

[kolla] Ussuri release
by Mark Goddard 15 Jun '20

15 Jun '20

Hi, I think it's time we made our Ussuri release. I've been through open bugs and patches to try to work out what are our release blockers. Remember that we can and will follow up with fixes, let's keep it to actual release blockers and release some code for people to use. I've started a list on the whiteboard [1] line 105. Please add items there that you think are release critical. [1] https://etherpad.opendev.org/p/KollaWhiteBoard Thanks, Mark

1 0

[ironic] code review jam - Thursday @ 4 PM UTC
by Julia Kreger 15 Jun '20

15 Jun '20

Greetings everyone, Ironic has a bit of a review backlog to work through, and in order to help facilitate getting through the backlog we're going to hold a review jam on Thursday of this week at 4 PM UTC. Everyone is welcome, but we're likely going to focus on the items needing review or quick discussion that are inside our review queue. For this, we will use meetpad [0]. Thanks everyone! -Julia 0: https://meetpad.opendev.org/ironic

1 0

Upstream Openstack Stein + Octavia - why is the installation procedure so different than other projects ?
by Alfia, Zion 15 Jun '20

15 Jun '20

Hello, Opposed to other Openstack Stein projects' installation procedure documentation - Octavia is no less than ... vague. https://docs.openstack.org/octavia/stein/contributor/guides/dev-quick-start… Why is that ? Kind Regards, Zion ________________________________ PRIVILEGED AND CONFIDENTIAL PLEASE NOTE: The information contained in this message is privileged and confidential, and is intended only for the use of the individual to whom it is addressed and others who have been specifically authorized to receive it. If you are not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, or if any problems occur with transmission, please contact sender. Thank you.

2 2

nova compute rbd backend error
by Nazan CENGİZ 15 Jun '20

15 Jun '20

I've wanted to use ceph storage as a backend for nova, glance and cinder. I've succeded to use ceph for cinder and glance but I couldn't at nova. I have saw this bug for "Stein" version ---> https://bugs.launchpad.net/nova/stein/+bug/1860990 After that, I've entered the nova-compute pod and I've run below commands; apt install python-rbd apt install python3-rbd But it didn't work. I've gotten same error. A solution must be on the K8s side. Do you have any of ideas about that? Nova compute image; [cid:3132c647-854a-4414-b04c-d40d6637cfc3] Best Regards, Nazan [cid:image65cb84.PNG@b431e523.428f4649]<http://www.havelsan.com.tr> [cid:imagea0344c.JPG@58751da3.4a9c82d4] Nazan CENGİZ AR-GE MÜHENDİSİ Mustafa Kemal Mahallesi 2120 Cad. No:39 06510 Çankaya Ankara TÜRKİYE [cid:imageee2c6d.PNG@1c63e1af.47be051b] +90 312 219 57 87 [cid:image8666e0.PNG@d175d91d.47bf87e0] +90 312 219 57 97 [cid:image84a401.JPG@9630949c.47a4f234] YASAL UYARI: Bu elektronik posta işbu linki kullanarak ulaşabileceğiniz Koşul ve Şartlar dokümanına tabidir. <https://havelsan.com.tr/sabit-sayfalar/eposta-yasal-uyari> LEGAL NOTICE: This e-mail is subject to the Terms and Conditions document which can be accessed with this link. <https://havelsan.com.tr/sabit-sayfalar/eposta-yasal-uyari> Lütfen gerekmedikçe bu sayfa ve eklerini yazdırmayınız / Please consider the environment before printing this email

1 3

[openstack-ansible] Upstream contributions
by Dmitriy Rabotyagov 15 Jun '20

15 Jun '20

Hi there! We've accidentally noticed, that you have forked some of the openstack-ansible repositories and do have some fixes and commits to the forked versions. Additionally, you have adjutant role, which we don't have but was talking about creating it one day. We would really love to get your patches merged upstream and work together on making OSA better and that it would satisfy your requirements as well. As it's really better to work together on fixing things or implementing features, than doing exact same things on our own. I think that all parties would benefit from it. As a plus, in upstream we have CI resources, which means that we can test all patches, which should make them work for you as well in case of some updates or changes. So we'd really love to work with you and getting changes and features from your cloned repos to be implemented upstream. You can join us on IRC at #openstack-ansible channel on Freenode for further conversation and cooperation. -- Kind regards, Dmitriy Rabotyagov

1 0

[cyborg][kolla] OPAE & CentOS 8
by Mark Goddard 15 Jun '20

15 Jun '20

Hi, I asked in another thread, but didn't get a response. In the kolla cyborg-agent image we install OPAE. There is a comment claiming this is a required dependency. It doesn't seem to be available for CentOS 8. If that is the case, we will need to drop support for the cyborg-agent image from Ussuri. Could someone confirm if OPAE is a hard dependency or not? Thanks, Mark

4 5

[openstackl][cinder][nova] attacched volume retype error
by Ignazio Cassano 15 Jun '20

15 Jun '20

Hello All, I am facing an issue when I retype a volume attached to a vm from netapp nfs to ceph on stein. It work fron nfs to iscsi but not from nfs to ceph. It seems a nova issue. I got an error in nova compute log: Failed to swap volume 26add23f-d643-4020-9935-9e856a0e9d93 for 1a2edc3a-cc3e-4a92-9488-6e6fabd01825: NotImplementedError: Swap only supports host devices I read there is an old blueprint for this but I do know if it has been implemented. Any help, please? Ignazio

2 2

[ironic][centos]grubaa64.efi request different filename
by Jeffrey Zhang 15 Jun '20

15 Jun '20

hey guys, I am testing a standalone ironic node on arm64 node through centos 7. Then dnsmasq is configured as following ``` enable-tftp tftp-root=/var/lib/ironic/public/boot/tftp # dhcp-option=option:router,192.168.122.1 # use static dhcp-range=10.0.0.167,static,60s log-queries log-dhcp dhcp-match=set:efi-arm64,option:client-arch,11 dhcp-boot=tag:efi-arm64,grubaa64.efi ``` the grubaa64.efi file come from `/boot/efi/EFI/centos/grubaa64.efi` on centos 7 But seems grubaa64.efi file are trying different grub.cfg filename like `grub.cfg-xx-xx-xx-xx`( check bellow) Whereas ironic generate filename like `xx:xx:xx:xx:xx.conf`. Is this a bug in ironic? or I made something wrong? ``` dnsmasq-dhcp[1]: 140425456 vendor class: PXEClient:Arch:00011:UNDI:003000 dnsmasq-dhcp[1]: 140425456 DHCPREQUEST(eth1) 10.0.0.171 52:54:00:ea:56:f2 dnsmasq-dhcp[1]: 140425456 tags: known, efi-arm64, eth1 dnsmasq-dhcp[1]: 140425456 DHCPACK(eth1) 10.0.0.171 52:54:00:ea:56:f2 pxe-uefi dnsmasq-dhcp[1]: 140425456 requested options: 1:netmask, 2:time-offset, 3:router, 4, 5, dnsmasq-dhcp[1]: 140425456 requested options: 6:dns-server, 12:hostname, 13:boot-file-size, dnsmasq-dhcp[1]: 140425456 requested options: 15:domain-name, 17:root-path, 18:extension-path, dnsmasq-dhcp[1]: 140425456 requested options: 22:max-datagram-reassembly, 23:default-ttl, dnsmasq-dhcp[1]: 140425456 requested options: 28:broadcast, 40:nis-domain, 41:nis-server, dnsmasq-dhcp[1]: 140425456 requested options: 42:ntp-server, 43:vendor-encap, 50:requested-address, dnsmasq-dhcp[1]: 140425456 requested options: 51:lease-time, 54:server-identifier, 58:T1, dnsmasq-dhcp[1]: 140425456 requested options: 59:T2, 60:vendor-class, 66:tftp-server, 67:bootfile-name, dnsmasq-dhcp[1]: 140425456 requested options: 97:client-machine-id, 128, 129, 130, 131, dnsmasq-dhcp[1]: 140425456 requested options: 132, 133, 134, 135 dnsmasq-dhcp[1]: 140425456 next server: 10.0.0.167 dnsmasq-dhcp[1]: 140425456 broadcast response dnsmasq-dhcp[1]: 140425456 sent size: 1 option: 53 message-type 5 dnsmasq-dhcp[1]: 140425456 sent size: 4 option: 54 server-identifier 10.0.0.167 dnsmasq-dhcp[1]: 140425456 sent size: 4 option: 51 lease-time 2m dnsmasq-dhcp[1]: 140425456 sent size: 13 option: 67 bootfile-name grubaa64.efi dnsmasq-dhcp[1]: 140425456 sent size: 4 option: 58 T1 1m dnsmasq-dhcp[1]: 140425456 sent size: 4 option: 59 T2 1m45s dnsmasq-dhcp[1]: 140425456 sent size: 4 option: 1 netmask 255.255.255.0 dnsmasq-dhcp[1]: 140425456 sent size: 4 option: 28 broadcast 10.0.0.255 dnsmasq-dhcp[1]: 140425456 sent size: 4 option: 3 router 10.0.0.167 dnsmasq-dhcp[1]: 140425456 sent size: 4 option: 6 dns-server 10.0.0.167 dnsmasq-dhcp[1]: 140425456 sent size: 8 option: 12 hostname pxe-uefi dnsmasq-tftp[1]: error 8 User aborted the transfer received from 10.0.0.171 dnsmasq-tftp[1]: failed sending /var/lib/ironic/public/boot/tftp/grubaa64.efi to 10.0.0.171 dnsmasq-tftp[1]: sent /var/lib/ironic/public/boot/tftp/grubaa64.efi to 10.0.0.171 dnsmasq-tftp[1]: file /var/lib/ironic/public/boot/tftp/grub.cfg-01-52-54-00-ea-56-f2 not found dnsmasq-tftp[1]: file /var/lib/ironic/public/boot/tftp/grub.cfg-0A0000AB not found dnsmasq-tftp[1]: file /var/lib/ironic/public/boot/tftp/grub.cfg-0A0000A not found dnsmasq-tftp[1]: file /var/lib/ironic/public/boot/tftp/grub.cfg-0A0000 not found dnsmasq-tftp[1]: file /var/lib/ironic/public/boot/tftp/grub.cfg-0A000 not found dnsmasq-tftp[1]: file /var/lib/ironic/public/boot/tftp/grub.cfg-0A00 not found dnsmasq-tftp[1]: file /var/lib/ironic/public/boot/tftp/grub.cfg-0A0 not found dnsmasq-tftp[1]: file /var/lib/ironic/public/boot/tftp/grub.cfg-0A not found dnsmasq-tftp[1]: file /var/lib/ironic/public/boot/tftp/grub.cfg-0 not found dnsmasq-tftp[1]: file /var/lib/ironic/public/boot/tftp/grub.cfg not found dnsmasq-tftp[1]: file /var/lib/ironic/public/boot/tftp/EFI/centos/grub.cfg-01-52-54-00-ea-56-f2 not found dnsmasq-tftp[1]: file /var/lib/ironic/public/boot/tftp/EFI/centos/grub.cfg-0A0000AB not found dnsmasq-tftp[1]: file /var/lib/ironic/public/boot/tftp/EFI/centos/grub.cfg-0A0000A not found dnsmasq-tftp[1]: file /var/lib/ironic/public/boot/tftp/EFI/centos/grub.cfg-0A0000 not found dnsmasq-tftp[1]: file /var/lib/ironic/public/boot/tftp/EFI/centos/grub.cfg-0A000 not found dnsmasq-tftp[1]: file /var/lib/ironic/public/boot/tftp/EFI/centos/grub.cfg-0A00 not found dnsmasq-tftp[1]: file /var/lib/ironic/public/boot/tftp/EFI/centos/grub.cfg-0A0 not found dnsmasq-tftp[1]: file /var/lib/ironic/public/boot/tftp/EFI/centos/grub.cfg-0A not found dnsmasq-tftp[1]: file /var/lib/ironic/public/boot/tftp/EFI/centos/grub.cfg-0 not found dnsmasq-tftp[1]: file /var/lib/ironic/public/boot/tftp/EFI/centos/grub.cfg not found dnsmasq-tftp[1]: file /var/lib/ironic/public/boot/tftp/EFI/centos/arm64-efi/command.lst not found dnsmasq-tftp[1]: file /var/lib/ironic/public/boot/tftp/EFI/centos/arm64-efi/fs.lst not found dnsmasq-tftp[1]: file /var/lib/ironic/public/boot/tftp/EFI/centos/arm64-efi/crypto.lst not found dnsmasq-tftp[1]: file /var/lib/ironic/public/boot/tftp/EFI/centos/arm64-efi/terminal.lst not found ``` --- Regards, Jeffrey Zhang Blog: http://xcodest.me

2 2

[Neutron] Neutron Bug Deputy report Jun 8-15
by Jakub Libosvar 15 Jun '20

15 Jun '20

Hi, I was bug deputy for the week of June 8, there are no critical bugs, which is good 🙂 Here is the summary: * Needs further triage * Improper routing between private networks * https://bugs.launchpad.net/neutron/+bug/1883288 * Needs more investigation * after FIP is assigned vm lost network connection * https://bugs.launchpad.net/neutron/+bug/1882860 * may be related to https://github.com/ovn-org/ovn/commit/fda9a1dd3c995f25cad9e828e701f8b41d347… * or DVR + VLAN provider network * internal server error on updating no-gateway on the dhcpv6 subnet * https://bugs.launchpad.net/neutron/+bug/1882873 * needs more info about reproducer * High * Fix flows l2 population related on br-tun being cleaned after RabbitMQ cluster has experienced a network partition * https://bugs.launchpad.net/neutron/+bug/1883071 * Triaged as High as it has an impact on tenant traffic because sometimes the flows related to tunnels in L2 pop gets cleaned * bagpipe: bagpipe-bgp does not start with EVPN and OVS driver * https://bugs.launchpad.net/neutron/+bug/1883102 * More options need to be passed to OVS in EVPN * Neutron OpenvSwitch DVR - connection problem * https://bugs.launchpad.net/neutron/+bug/1883321 * traffic of one VM on a compute node influences traffic of other VM, only on DVR ml2/ovs * Medium * [L3] floating IP failed to bind due to no agent gateway port(fip-ns) * https://bugs.launchpad.net/neutron/+bug/1883089 * Marked as Medium by reporter * Has a fix on review https://review.opendev.org/#/c/735432/ * Low * [neutron-tempest-plugin] "wait_for_interface_status" only retrieves the Nova server information, not the VM network * https://bugs.launchpad.net/neutron/+bug/1883095 * Fix proposed: https://review.opendev.org/#/c/735117/ * RFE * RFE: allow replacing the QoS policy of bound port * https://bugs.launchpad.net/neutron/+bug/1882804 * needs to be triaged by the drivers team

1 0

[glance] Victoria Virtual PTG
by Abhishek Kekane 14 Jun '20

14 Jun '20

Hi All, We had our first virtual summit last week from 1st June to 5th June 2020. Using meetpad we had lots of discussion around different topics for glance and glance + cinder. I have created etherpad [1] with Notes from session and which also includes the recordings of each discussion. Below is the list of what we discussed during PTG. 1. Image encryption (glance side work) 2. Unified Limits Integration with Glance 3. Calculate virtual_size during image creation 4. Remove usage of six library 5. Remove single store configuration from glance_store 6. Cluster awareness 7. Cache-API 8. Improve performance of ceph/rbd store of glance (multi-threaded rbd driver) 9. Duplicate downloads 10. Code cleanup, enhancements 11. Cinder/Glance creating image from volume with Ceph 12. Make a cinder store of glance compatible with multiple stores 13. Gate job for glance cinder store 14. Support for sparse image upload to ceph 15. Victoria priorities Kindly let me know if you have any questions about the same. [1] https://etherpad.opendev.org/p/glance-victoria-ptg Thank you, Abhishek

1 0

[all][infra] Upcoming removal of preinstalled pip and virtualenv from base images
by Ian Wienand 14 Jun '20

14 Jun '20

Hello, This is to notify the community of the planned upcoming removal of the "pip-and-virtualenv" element from our infra image builds. This is part of the "cleanup test node python" spec documented at [1]. tl;dr ----- - pip and virtualenv tools will no longer be pre-installed on the base images we use for testing, but will be installed by jobs themselves. - most current jobs will depend on common Zuul base jobs that have been updated to install these tools already *i.e. in most cases there should be nothing to do* - in general, jobs should ensure they depend on roles that install these tools if they require them - if you do find your job failing due to the lack of either of these tools, use the ensure-pip or ensure-virtualenv roles provided in zuul-jobs - we have "-plain" node types that implement this now. If you think there might be a problem, switch the job to run run against one of these node types described below for testing. History ------- The "pip-and-virtualenv" element is part of diskimage-builder [2] and installs the latest version of pip and virtualenv, and related tools like setuptools, into the system environment for the daily builds. This has a long history of working around various issues, but has become increasingly problematic to maintain. One of the more noticable effects is that to prevent the distribution packages overwriting the upstream installs, we put various pip, setuptools and virtualenv packages on "hold" in CI images. This prevents tests resinstalling packaged tools which can create, in short, a big mess. Both destroying the extant environment and having the tools on hold have been problems for various projects at various times. Another other problem is what happens when you call "pip" or "virtualenv" has diverged. It used to be that "pip" would install the package under Python2, while pip3 would install under python3. However, modern distributions now have "pip" installing under Python 3. To keep having "pip" install Python 2 packages on these platforms is not just wrong, but drags in Python 2 dependences to our images that aren't required. The addition of Python 3's venv and the split with virtualenv makes things even more confusing again. Future ------ As famously said "the only winning move is not to play". [3] By dropping this element, images will not have non-packaged pip/virtualenv/setuptools/etc. pre-installed. No packages will be on hold. The "ensure-pip" role [4] will ensure that dependencies for "pip:" commands will work. Because of the way base jobs are setup, it is most likely that this role has already run. If you wish to use a virtual environment to install a tool, I would suggest using the "ensure_pip_virtualenv_cmd" this role exports. This will default to "python3 -m venv". An example is [5]. In a Python 3 word, you probably do not *need* virtualenv; "python3 -m venv" is available and works after the "ensure-pip" role is run. However, if you require some of the features that virtualenv provides that venv does not (explained at [6]) there is a role "ensure-virtualenv" [7]. For example, we do this on the devstack branches because it is common to use "virtualenv" there due to the long history [8]. If you need specific versions of pip or virtualenv, etc. beyond the system-packaged versions installed with the above, you should have your job configure these. There is absolutely no problem with jobs installing differing versions of pip/virtuatlenv/etc in any way they want -- we just don't want the base images to have any of that by default. Of course, you should consider if you're building/testing something that is actually useful outside the gate, but that is a global concern. Testing ------- We have built parallel nodes with the suffix "-plain" where you can test any jobs in the new environment. For example [9] speculatively tests devstack. The node types available are centos-7-plain centos-8-plain ubuntu-xenial-plain ubuntu-bionic-plain The newer focal images do not have pip pre-installed, neither do the faster moving Fedora images, any SUSE images, or any ARM64 images. Rollout ------- We would like to make the switch soon, to shake out any issues early in the cycle. This would mean on or about the 8th June. Thanks, -i [1] https://docs.opendev.org/opendev/infra-specs/latest/specs/cleanup-test-node… [2] https://opendev.org/openstack/diskimage-builder/src/branch/master/diskimage… [3] https://en.wikipedia.org/wiki/WarGames [4] https://zuul-ci.org/docs/zuul-jobs/python-roles.html#role-ensure-pip [5] https://opendev.org/zuul/zuul-jobs/src/branch/master/roles/bindep/tasks/ins… [6] https://virtualenv.pypa.io/en/latest/ [7] https://zuul-ci.org/docs/zuul-jobs/python-roles.html#role-ensure-virtualenv [8] https://opendev.org/openstack/devstack/commit/23cfb9e6ebc63a4da4577c0ef9e34… [9] https://review.opendev.org/#/c/712211/11/.zuul.yaml

3 3

[announce] [debian] New deb-status page and extrepo configuration available for OpenStack on Debian
by Thomas Goirand 14 Jun '20

14 Jun '20

Hi! We've just setup online a new deb-status system [2] to compare what's been released in OpenStack upstream and what has been packaged in Debian. This is an effort to keep each stable branch up-to-date in Debian. This has been possible thanks to Michal Arbet from ultimum.io who wrote os-version-checker [1]. So, a big up to him and ultimum technologies. Note that the Rocky page may not reflect reality, since most of the components are available directly in Debian Buster. Browsing this page, you will notice that both Train and Ussuri are pretty much in an up-to-date shape! :) Note that this page is updated every hours. Also, the Debian packages are now available using extrepo, to make it easier to install. Extrepo is an initiative from Wouter Verhelst to have something comparable to PPA, at least in the way to install the repositories (ie: super easy now...). For example, to install Ussuri in Buster, one can do: apt-get install -t buster-backports extrepo extrepo enable openstack_ussuri This will install the repository as: /etc/apt/sources.list.d/extrepo_openstack_train.sources then you can start using Ussuri using apt as usual. Last, we're searching for volunteers to mirror the osbpo.debian.net Buster backport repositories (to make sure it isn't only on the hands of me and my employer). The only thing that shall be done is to setup an rsync mirroring of the repositories. Best would be to have a mirror in north-America and in Asia. If you're volunteering for this, especially if you are administering a CDN, please get in touch. Hoping this will improve the OpenStack on Debian experience, Cheers, Thomas Goirand (zigo) [1] https://salsa.debian.org/openstack-team/debian/os-version-checker [2] http://osbpo.debian.net/deb-status/

1 0

[nova][doc] nova pdf building failing on new sphinx 3.1.0
by Ghanshyam Mann 12 Jun '20

12 Jun '20

Hello Everyone, With the new release of Sphinx 3.1.0, nova pdf-docs building started failing due to TeX memory issue (maybe this one - https://github.com/sphinx-doc/sphinx/issues/3099) I could not find the related changes in 3.1.0 which can cause this issue. The issue is to include the giant sample files(policy for now) in pdf doc. I am sure that was discussed previously also when we started pdf building in the Train cycle but do not know what was the solution? Luckily neutron is not facing this as their config sample files are as large as nova. I have logged bug[1] and provided the workaround[2] to unblock the nova gate. Workaround is to include the link to the sample file instead if its full content. Any thoughts on how to fix this? [1] https://bugs.launchpad.net/nova/+bug/1883200 [2] https://review.opendev.org/#/c/735279/ -gmann

1 1

Re: [Interop_WG] Today Fiday 6th June 10 AM PDT call
by prakash RAMCHANDRAN 12 Jun '20

12 Jun '20

Hi all, Can you help me on irc, should we be using #openstack-interop or #openstack-interopwgWHich of this we will be able to use the bit to record meetings besides the call? #topic 1 - Review of content for "OpenStack Powered DNS" and "OpenStack Powered Orchestration"#info We need to update the site https://www.openstack.org/brand/openstack-powered/ #topic 2 - Marketplace Vendors to validate their OpenStack Powered offers for Ussuri This can be tested on https://refstack.openstack.org/#/community_results I don't see any tests being made by any one on 11th or 12 th June, any reasons, is there a transition goin on or there is some issue with refstack-client? #action Prakash to follow up with Mark & Ghanshyam on both web site update for Logo add-on programs and refstack-client working wrt Refstack portal #topic 3 - Follow ups to close for Usuri actions items #action Seek help from Staff to update the formality to make "one or more co-chairs" in B192#link https://review.opendev.org/gitweb?p=openstack/interop.git;a=blob;f=doc/sour…... #info updated the googledocs for interops on CinderV2 apis being removed , correction it should have appeared as deprecated in 2019.11 , no issues as we have now dropped it out in 2020.11 approval#link https://docs.google.com/document/d/1vf8rxKxuFoXmZCxfMIIfHm4TzK1kuANktXyUHiu…... topic 4 - Formation new committee for Future Interop work - we discuss this before OpenDev June 29 and help get approvals next Board meeting #info consider Conformance vs Compliance to keep off legal part for new certifications or Logo programs Q1. Data points from MarketPlace?Please educate us how we collect Marketplace data - How customers use the Marketplace? Can we get Data points from Marketplace? If so How? Any answers from TC community or Users Community folks? Q2. Does Tempest testing Infra provider/Vendors offerings occur in real time or you run a batch and send report to interop and who receives this test results? Appreciate all the help from especially Mark, Ghanshyam and we like to have all support for community for interop continuation. ThanksPrakash On Thursday, June 11, 2020, 06:31:21 AM PDT, Ghanshyam Mann <gmann(a)ghanshyammann.com> wrote: Thanks Prakash for all your effort and energy. I can definitely help with guidelines and their testing part from Tempest point of view or you can count that as help from the community side. My concern is almost the same as Mark, I am involved in multiple areas so if interop requires more time then it might be an issue. As of now, I am ok to help to handle some code side part or as 2nd vice-chair hoping that would not take much bandwidth (i think we do not need 2nd vice-chair things as such :) but no strong opinion ). But the main issue for interop (i mentioned earlier also) is the maintainer for refstack and other repo. We really need some developers for that. -gmann ---- On Wed, 10 Jun 2020 21:07:13 -0500 prakash RAMCHANDRAN <pramchan(a)yahoo.com> wrote ---- > Mark, > OK let me handle it as chair, but let's refer or nominate Ghanshyam too as second vice chair and if needs to vote it lets do that. > I have submitted the change of irc channel to #openstack-interop as tested last week. and try pile all logs therein with startmeeting and endmeeting weekly to debate and arrive at how we proceed on this after tomorrows presentation which I like both of you to attend. > https://review.opendev.org/#/c/735034/1 > If we need anything to merge the above go ahead. > Arkady as usual is with me on Board is there to help us all, so we do have two from Board and two from TC and community. > So let me answer your latest email, and revise the presentation and web link for Board accordingly. > ThanksPrakash > > > > On Friday, June 5, 2020, 12:32:07 PM PDT, Mark Voelker <mvoelker(a)vmware.com> wrote: > > > So let us wait and check with OpenStack staff how they can help us if they can fix the web irc/time links, if not I will try fix it over week end. > Well, that’s sort of the point of having the meeting info housed in public repository: community members actually don’t need to go through the Foundation staff for things like this, they can just fix them with a few lines of text submitted via git! =) > If you’re not sure how to do that, let me know…it’ll only take a moment to submit a patch so I’m happy to help. > At Your Service, > Mark T. Voelker > > > On Jun 5, 2020, at 3:17 PM, prakash RAMCHANDRAN <pramchan(a)yahoo.com> wrote: > Mark, > I see that using irc does help take notes for weekly meetings, especially if there is frequent meetings weekly alternate week etc. > So let us wait and check with OpenStack staff how they can help us if they can fix the web irc/time links, if not I will try fix it over week end. > ThanksPrakash > On Friday, June 5, 2020, 11:49:22 AM PDT, Mark Voelker <mvoelker(a)vmware.com> wrote: > > Prakash, > Quick suggestion: since it looks you’re running these meetings on Zoom going forward, you may want to add the Zoom information to the upstream meetings calendar or alternately at least remove the old IRC meeting entry. See the "IRC meetings schedule” section here for information: > http://eavesdrop.openstack.org/ > The file that you’d want to submit a patch for is: > https://opendev.org/opendev/irc-meetings/src/branch/master/meetings/interop… > (Note that the times presented in the these files are in UTC rather than a local timezone.) > At Your Service, > Mark T. Voelker > > > On Jun 5, 2020, at 11:06 AM, prakash RAMCHANDRAN <pramchan(a)yahoo.com> wrote: > Hi all, > Prakash Ramchandran is inviting you to a scheduled Zoom meeting.To keep reliable zoom link have updated the weekly call to this one and see if you can join inspite of our ongoin PTG at 10 AM PDT. > Join from a browser: https://Dell.zoom.com/wc/join/99829924353 > Password: 101045 > Trying to consolidate what we got from PTG interactions to close the Draft updates. > https://etherpad.opendev.org/p/victoria-ptg-interop-wg > > > Closure in next week for Interop Guidline? > > What is the suggession for Board presentaion from team for Prakash on June 11th? > Anything you like to add on the call, we can keep it short and try close after PTG next week. > ThanksPrakash > > > > > > >

1 1

[release] Release countdown for week R-17, Jun 15 - Jun 19
by Sean McGinnis 12 Jun '20

12 Jun '20

Development Focus ----------------- The victoria-1 milestone is next week, on June 18! Project team plans for the Victoria cycle should now be solidified. General Information ------------------- If you planned to change the release model for any of your deliverables this cycle, please remember to do so ASAP, before milestone-1. Libraries need to be released at least once per milestone period. Next week, the release team will propose releases for any library which had changes but has not been otherwise released since the Ussuri release. PTL's or release liaisons, please watch for these and give a +1 to acknowledge them. If there is some reason to hold off on a release, let us know that as well, by posting a -1. If we do not hear anything at all by the end of the week, we will assume things are OK to proceed. NB: If one of your libraries is still releasing 0.x versions, start thinking about when it will be appropriate to do a 1.0 version. The version number does signal the state, real or perceived, of the library, so we strongly encourage going to a full major version once things are in a good and usable state. Upcoming Deadlines & Dates -------------------------- Victoria-1 milestone: June 18 Victoria-2 milestone: July 30

1 0