June 2020 - openstack-discuss - lists.openstack.org

[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 18 Jun '20

18 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