- openstack-discuss - lists.openstack.org

[ops] next ops meetup : London 7,8 Jan 2020 - approved!
by Chris Morgan 12 Nov '19

12 Nov '19

https://twitter.com/osopsmeetup/status/1194281816468938752?s=20 -- Chris Morgan <mihalis68(a)gmail.com>

1 0

[all][doc] Patches to add --keep-going to sphinx-build (and patches proposed to many many repositories)
by Akihiro Motoki 12 Nov '19

12 Nov '19

Hi, As you may notice, we see a lot of patches which try to add --keep-going to sphinx-build. [0] I have suggestions and questions. 1) First, when reviewing them, keep the following in your mind. * --keep-going is added even when -W option is not used in the sphinx-build command line. -W is recommended in the PTI [1], so ensure to have -W. * Some of them ignores cases where "python setup.py build_sphinx" is still used. If it is a good chance to clean them up and use "sphinx-build" consistently. 2) Why do we need to remove the build directory for releasenotes? Some of them propose to add "rm -rf releasenotes/build"? (for example [2]) I cannot understand why this needs to be added. Do we really want to call "rm -rf <build dir>"? I know it is needed in some repositories due to various reasons, but generally speaking it make the documentation build longer and they are unnecessary. I tried to get the reason from the authors in reviews but they just say it is simple and it can be added at the same time. Thus, I would like to ask it more broadly in the list. 3) What is the recommended way to get a consensus to make this kind of patches which affects many many repositories? It is not productive to ask questions in individual reviews. Some patches are approved fast and questions are pop-up in other patches. It makes it difficult to discuss the real needs and keep many repositories consistent. I am not against all of these changes, but I would like to see more organized way. Thought? Thanks, Akihiro [0] https://review.opendev.org/#/q/message:keeping [1] https://governance.openstack.org/tc/reference/project-testing-interface.htm… [2] https://review.opendev.org/#/c/690956/2/tox.ini

2 1

[nova][ptg] Resurrecting NUMA topology in Placement
by Sylvain Bauza 12 Nov '19

12 Nov '19

We discussed about a long known story https://review.openstack.org/#/c/552924/ The whole agreement during the PTG was to keep things simple with baby steps : - only supporting a few NUMA queries and defer others as unsupported (still supported by legacy NUMATopologyFilter) - The to-be-resurrected spec would be only focus on VCPU/PCPU/MEMORY_MB resource classes and not handle PCI or GPU devices (ie. level-1 tree, no children under the NUMA RPs) Agreement was also there for saying that functional tests should be enough since PlacementFixture already works perfectly. -S

2 3

[infra] Etherpad problem
by Slawek Kaplonski 12 Nov '19

12 Nov '19

Hi, Just at the end of the ptg sessions, neutron etherpad was got broken somehow. Now when I try to open [1] I see only something like: An error occurred The error was reported with the following id: 'igzOahZ6ruH0eSUAWKaj' Please press and hold Ctrl and press F5 to reload this page, if the problem persists please send this error message to your webmaster: 'ErrorId: igzOahZ6ruH0eSUAWKaj URL: https://etherpad.openstack.org/p/Shanghai-Neutron-Planning UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:70.0) Gecko/20100101 Firefox/70.0 TypeError: r.dropdowns is undefined in https://etherpad.openstack.org/javascripts/lib/ep_etherpad-lite/static/js/p… at line 18' We can open one of the previous versions which is available at [2] but I don't know how we can fix original etherpad or restore version from [2] to be original etherpad and make it working again. Can someone from infra team check that for us maybe? Thx in advance for any help. [1] https://etherpad.openstack.org/p/Shanghai-Neutron-Planning [2] https://etherpad.openstack.org/p/Shanghai-Neutron-Planning/timeslider#16117 -- Slawek Kaplonski Senior software engineer Red Hat

4 4

[ops] meetups team meeting and meetups venue for Jan 2020
by Chris Morgan 12 Nov '19

12 Nov '19

There wll be an OpenStack Ops Meetups team meeting in just under 45 minutes on #openstack-operators. The agenda is here: https://etherpad.openstack.org/p/ops-meetups-team We'd like to see if we can agree to formally accept the offer to host the next OpenStack Operators Meetup in London next January (see https://etherpad.openstack.org/p/ops-meetup-1st-2020) Please attend the meeting if you have feedback for or against this proposal. So far all feedback has been positive and there are no other offers. Note (full disclosure) that this proposal is from my employer. We'll also go over material from last week's summit in Shanghai. Chris -- Chris Morgan <mihalis68(a)gmail.com>

1 0

[ptg][nova][glance] x-p meeting minutes
by Sylvain Bauza 12 Nov '19

12 Nov '19

We only discussed about nova snapshots to dedicated glance stores. Reference is https://review.opendev.org/#/c/641210/ We had concerns on implementing glance storage location strategies in Nova. A counter-proposal was made to only pass the original image ID when calling Glance for a snapshot so then Glance would then use any store the operator wants (eg. a location strategy like "please store the snapshot to a place close to where the original image is"). The agreement was there for the counter-proposal so the Nova change would only be to pass the original glance image ID to the new glanceclient that would support it. Glance folks will provide a new spec revision. -S

1 0

[ptg][nova][keystone] x-p meeting minutes
by Sylvain Bauza 12 Nov '19

12 Nov '19

We only discussed about the large effort needed for the new policies. https://specs.openstack.org/openstack/nova-specs/specs/ussuri/approved/poli… https://review.opendev.org/#/q/topic:bp/policy-defaults-refresh+(status:ope… We asked the Keystone team to review the first changes in the series as it's very helpful. We had concerns about completion over the Ussuri cycle since the series can be very large and we want to avoid deprecation messages for some APIs if not all the Nova APIs are touched yet. The agreement was to hold a procedural -2 on the API changes and start reviewing (for both Keystone and Nova folks) until all the changes are there. Maybe a runway could help once all the API changes are uploaded. -S

1 0

[nova][cinder] Volume-backed instance disks and some operations that do not support those yet
by Peter Penchev 12 Nov '19

12 Nov '19

Hi, First of all, thanks to everyone involved for all the work on Nova, Cinder, os-brick, and actually all the rest of OpenStack, too! So, yeah, I guess it is kind of weird that I'm asking this on the list just a couple of days after the PTG where I could have asked in person, but here goes :) There seem to still be some quirks with Nova and volume-backed instance disks; some actions on instances are not allowed, others produce somewhat weird results. From a quick look at the code it seems to me that currently these are: - taking a snapshot of an instance (produces a zero-sized file, no real data backed up) - backing an instance up (refuses outright) - rescuing an instance (refuses outright) ...and maybe there are some that I've missed. So, possibly stupid question here, but what are the project's plans about these - is there an intention to implement them at some point, or are there some very, very hard theoreitcal or practical problems (so something like "guess not for the present"), or is somebody working on something? The main reason that I am asking is that we, StorPool, have a shared-storage Cinder driver, and every now and then a customer comes up and asks about one or more of these actions. Every now and then we come back to the idea of writing a vendor-specific Nova image backend, but, first off, we are not really sure whether we want to do this, and second, we are not really sure whether it will be accepted upstream. A couple of years ago people told us "don't do that" and there was some talk about having an image backend for storage drivers supported by libvirt, but that effort seems to have stalled. Of course, we know that in all software projects, including, but certainly not limited to, the more-or-less volunteer free/libre/open-source projects, there are many tasks and many demands on the developers so that it is only natural that not everything is implemented or adapted at once; things happen, priorities shift, people get redirected, nobody else steps up to continue - it happens. With this in mind, where do things stand right now, should we consider writing an image backend, are there other options or plans? So thanks for reading through my ramblings, I guess, and keep up the great work! Best regards, Peter

4 3

[nova][ptg] Support re-configure deleted_on_termination in server
by Sylvain Bauza 12 Nov '19

12 Nov '19

Spec is https://review.opendev.org/#/c/580336/ Most people seem to think this makes sense but realize there are already other ways to do this (snapshot) and therefore it's not totally necessary. The agreement in the room was to post the code up for the change, as this will help sell people on it if it's trivial enough and document the use case (i.e. are there scenarios where this would make life 10x easier?)

1 0

BGP dynamic routing
by Volodymyr Litovka 11 Nov '19

11 Nov '19

Dear colleagues, "BGP dynamic routing" doc (https://docs.openstack.org/neutron/rocky/admin/config-bgp-dynamic-routing.h…) says only about advertisement of routes: "BGP dynamic routing enables advertisement of self-service (private) network prefixes to physical network devices that support BGP such as routers, thus removing the conventional dependency on static routes." and nothing about receiving of routes from external peers. Whether it is ever possible using Neutron to have fully dynamic routing inside the project, both advertising/receiving (and updating VRs configuration) routes to/from remote peers? Thank you. -- Volodymyr Litovka "Vision without Execution is Hallucination." -- Thomas Edison

3 5

[tacker] No IRC meeting today
by Dharmendra Kushwaha 11 Nov '19

11 Nov '19

Hello Taker team, As we have PTG in last week, lets skip today's weekly meeting. Thanks & Regards Dharmendra Kushwaha

1 0

How to set password
by zhaowx＠jxresearch.com 11 Nov '19

11 Nov '19

hello: When I use `trovestack build-image`, how to set password for the image? thanks zhaowx(a)jxresearch.com

1 0

[nova][ptg] drop the shadow table concept
by Balázs Gibizer 11 Nov '19

11 Nov '19

CERN reported two issues with archive_deleted_rows CLI: * When one record gets inserted into the shadow_instance_extra but didn't get deleted from instance_extra (I know this is in a single transaction but sometimes it happens), needs manual cleanup on the database * Also there could be two cells running this command at the same time fighting for the API db lock, TODOs: * tssurya to report bugs / improvements on archive_deleted_rows CLI based on CERN's experience with long table locking * mnaser to report a wishlist bug / specless bp about one step db purge CLI which would skip the shadow tables Cheers, gibi

4 6

[octavia][ptg] Summary of Shanghai PTG Discussion
by Adam Harwell 11 Nov '19

11 Nov '19

Fellow Octavians, We covered a lot of ground during this PTG, met a number of new folks, and got a lot of valuable feedback. I'll do my best to summarize here what was discussed. 1. Metrics 1. It would be nice to expose metrics for pools/members, though we would like to get a better understanding of the requirements / use-cases. 2. We should publish metrics using some mechanism (plugin/driver). 1. The default would be "database" and would handle the existing API-exposed metrics. 2. Additional drivers would be loaded in parallel, and might include Monasca/Ceilometer/Prometheus drivers. 3. We will switch our metrics internally to use a delta system instead of absolute values from HAProxy. This will allow us to publish in a more sane way in the future. This would not change the way metrics are exposed in the existing API. 2. Notifications 1. We will need to create a spec and gather community feedback. 2. Initial observation indicates the need for two general paths, which will most likely have their own driver systems: 1. provisioning_status changes (including all create/update/delete events) 2. operating_status changes (member up/down, etc) 3. We would provide the entire object in the notification, similar to what other services do. 4. Most likely the default driver(s) would use oslo.notify. 3. Availability Zone Support (Multi-Zone Fault Tolerance) 1. Make at least a story for tracking this, if it doesn't already exist. 2. Allow a single LB to have amphorae in multiple zones. 3. Existing patch: https://review.opendev.org/#/c/558962/ 4. Availability Zone Support (Compute AZ Awareness) 1. Make at least a story for tracking this, if it doesn't already exist. 2. Allow placing LBs in specific zones: 1. When zones are geographically separated, LBs should exist in the same zone as the members they support 2. When zones are logically separated (like PCI compliance zones, etc), users may need to place them specifically. 3. A new parameter `availability_zone` will be added to the LB create API. It will allow the user to select which Octavia AZ to use. 4. A new API section will be added for creating/configuring/listing Octavia AZs. This will allow a linkage between Compute AZs and Amphora Management Network, along with other possible options in the future. Admins can create/update, and users can list zones. 5. Update clients to support this, including further polluting the `openstack availability zone list` command to include `--loadbalancers` zones. 5. Python 2 EOL 1. Remove all jobs that test Python 2 (or update them if they're not duplicates). 2. Remove six compatibility code, which should simplify string handling significantly. 6. More Flavor Capabilities 1. Image Tag (to allow different amp images per flavor) 2. Availability Zone (to allow compute AZ pinning) 3. Management Network (to go with compute AZ) 4. Metadata (allow passing arbitrary metadata through to compute) 7. TLS Protocol/Cipher API Support 1. Allow users to select specific protocols/ciphers as a whitelist. 2. Stories: 1. Ciphers: https://storyboard.openstack.org/#!/story/2006627 2. Protocols: https://storyboard.openstack.org/#!/story/2006733 8. Performance Tuning 1. HAProxy: There are a number of knobs/dials that can be adjusted to make HAProxy behave more efficiently. Some of these that we could look at more are around TLS options, and around multiprocessing/threading. The latter will probably need to wait for us to switch to HAProxy 2.0. 2. Image Metadata: There are flags that could be added to our amphora image's metadata that might improve performance. To be further researched. 9. Testing 1. Team to evaluate existing non-voting jobs for promotion to voting. 1. Agreement was made with the Barbican team to promote both side's co-gating jobs to voting. 2. Team to evaluate merging or pruning some jobs to reduce the overall set that run on each change. 3. Grenade needs a few changes: 1. Switch to python3. 2. Upgrade to Zuul v3. 3. Test additional operations on existing LBs (old amp image), not just traffic. 4. Test more than just the most recent amphora image against the current control-plane code. Use periodic jobs for this. 5. Fix the Zuul grafana dashboard for Octavia test history. 10. Jobboard 1. This continues to be a priority for Ussuri. 2. Put together a priority list of patches specifically for jobboard. 11. HAProxy 2.0 1. A number of features are gated behind the new version, including multi-process and HTTP/2 support. 2. Need to reach out to distributions to push for backports (to cloudarchive for Ubuntu, and whatever similar thing for CentOS). 3. Possibly add an element to allow building new versions from source. 4. Perform version-based validation of options on the API-side of the amphora driver. 1. Inspect and cache Glance metadata for the LB's amphora image to get version data. 2. Provide the metadata string for the operator from our disk-image-create script. The full etherpad from the PTG including the notes I've summarized here is available at https://etherpad.openstack.org/p/octavia-shanghai-U-ptg if further review is desired. Thanks to everyone who participated, and best of luck on this (hopefully) productive new cycle! --Adam Harwell

1 0

[neutron] Bug Deputy Report Nov. 4-11
by Ryan Tidwell 11 Nov '19

11 Nov '19

Hello neutrinos, here is the bug deputy report for the week of Nov. 4th: High: * https://bugs.launchpad.net/neutron/+bug/1851659 "removing a network from a DHCP agent removes L3 rules even if it shouldn't" This was found on stable/rocky, we should obviously see if it can be reproduced on master, stein, and train as well. There does seem to be a workaround, but VM's lost connectivity for a brief period. Medium: * https://bugs.launchpad.net/neutron/+bug/1851500 ""test_show_port_chain" conflicts with Flow Classifier" This is a gate issue, with what appears to be some instability with a test. Initial triage indicates it's an intermittent issue. * https://bugs.launchpad.net/neutron/+bug/1851194 "FWaaSv2 configures iptables with invalid port name" This similar to https://bugs.launchpad.net/neutron/+bug/1798577, FWaaSv2 seems to be referencing the wrong port names. RFE: * https://bugs.launchpad.net/neutron/+bug/1851609 Add an option for graceful l3 agent shutdown -Ryan Tidwell

1 0

Change Volume Type, but in use
by Sinan Polat 11 Nov '19

11 Nov '19

Hi, I am using Ceph as the backend for Cinder. Within Ceph we have defined 2 RBD pools (ssdvolumes, sasvolumes). In OpenStack I created 2 Volume Types (ssd, sas). Each Volume Type has property "volume_backend_name='tripleo_ceph_<ssd|sas>'". In the Cinder configuration I have the following backends configured: [tripleo_ceph_ssd] backend_host=hostgroup volume_backend_name=tripleo_ceph_ssd volume_driver=cinder.volume.drivers.rbd.RBDDriver rbd_ceph_conf=/etc/ceph/ceph.conf rbd_user=openstack rbd_pool=ssdvolumes [tripleo_ceph_sas] backend_host=hostgroup volume_backend_name=tripleo_ceph_sas volume_driver=cinder.volume.drivers.rbd.RBDDriver rbd_ceph_conf=/etc/ceph/ceph.conf rbd_user=openstack rbd_pool=sasvolumes As you might have noticed, the backend name (tripleo_ceph_ssd) and the RBD pool name (ssdvolumes, not ssd) does not match. So far, we do not have any problems. But I want to correct the names and I do not want to have the mismatch anymore. So I want to change the value of key volume_backend_name for both Volume Types (tripleo_ceph_ssd => tripleo_ceph_ssdvolumes). I tried the following: $ openstack volume type show 80cb25ff-376a-4483-b4f7-d8c75839e0ce +--------------------+----------------------------------------+ | Field | Value | +--------------------+----------------------------------------+ | access_project_ids | None | | description | | | id | 80cb25ff-376a-4483-b4f7-d8c75839e0ce | | is_public | True | | name | ssd | | properties | volume_backend_name='tripleo_ceph_ssd' | | qos_specs_id | None | +--------------------+----------------------------------------+ $ $ openstack volume type set --property volume_backend_name='tripleo_ceph_ssdvolumes' 80cb25ff-376a-4483-b4f7-d8c75839e0ce Failed to set volume type property: Volume Type is currently in use. (HTTP 400) (Request-ID: req-5efaa5b7-910f-4802-8494-3115cfc4ab93) Command Failed: One or more of the operations failed $ How to solve my problem? Thanks! Sinan

4 6

[ops][glance] Quota for max number of images/snapshots per projects
by Massimo Sgaravatto 11 Nov '19

11 Nov '19

As far as I can see it is not possible to set a quota for the maximum number of images-snapshots for a given project, at least in the Rocky release If I am not wrong it is only possible to set the max size of an image or the total size of space used for glance by a project, but these settings would be the same for all projects Are there plans to implement this capability ? Thanks, Massimo

1 0

[manila][kolla-ansible] Fail to use manila with cephfs NFS share backend
by Boxiang Zhu 11 Nov '19

11 Nov '19

Hi everyone, I have deployed a OpenStack cluster with AIO mode by kolla-ansible. In my globals.yml, something is enabled as followed: ...... enable_ceph: "yes" enable_ceph_mds: "yes" enable_ceph_nfs: "yes" enable_manila: "yes" enable_manila_backend_cephfs_nfs: "yes" ....... And in my manila.conf, some configs are as followed: [DEFAULT] enabled_share_protocols = NFS,CIFS ...... [cephfsnfs1] driver_handles_share_servers = False share_backend_name = CEPHFSNFS1 share_driver = manila.share.drivers.cephfs.driver.CephFSDriver cephfs_protocol_helper_type = NFS cephfs_conf_path = /etc/ceph/ceph.conf cephfs_auth_id = manila cephfs_cluster_name = ceph cephfs_enable_snapshots = False cephfs_ganesha_server_is_remote = False cephfs_ganesha_server_ip = 172.16.60.84 ...... I use CLI to create the nfs, some commands as followed: -> manila type-create cephfsnfstype false -> manila type-key cephfsnfstype set vendor_name=Ceph storage_protocol=NFS -> manila create --share-type cephfsnfstype --name cephnfsshare1 nfs 1 -> manila share-export-location-list cephnfsshare1 +-----------------------------------------------+------------------------------------------------------------------------------------+-----------+ | ID | Path | Preferred | +-----------------------------------------------+------------------------------------------------------------------------------------+-----------+ | b101bf59-4cd7-4a09-a12e-b6dd48a5bb18 | 172.16.60.84:/volumes/_nogroup/93b1e23d-0166-41a4-a12a-51bf4c3654a5 | False | +-----------------------------------------------+------------------------------------------------------------------------------------+-----------+ -> manila access-allow cephnfsshare1 ip 172.16.60.119 But I have got some error messages from /var/lib/docker/volumes/kolla_logs/_data/manila/manila-share.log 2019-11-11 10:11:12.035 26 ERROR manila.share.drivers.ganesha.manager [req-673584f9-eaed-4464-819e-ace63dfa0f49 6f4bd93b18c546c880d5d4e526a0243e 70dba7786a8b4326a35e03d0ad8707f2 - - -] Error while executing management command on Ganesha node <no name>: dbus call exportmgr.AddExport.: ProcessExecutionError: Unexpected error while running command. 2019-11-11 10:11:14.954 26 ERROR oslo_messaging.rpc.server [req-673584f9-eaed-4464-819e-ace63dfa0f49 6f4bd93b18c546c880d5d4e526a0243e 70dba7786a8b4326a35e03d0ad8707f2 - - -] Exception during message handling: GaneshaCommandFailure: Ganesha management command failed. Command: sudo manila-rootwrap /etc/manila/rootwrap.conf dbus-send --print-reply --system --dest=org.ganesha.nfsd /org/ganesha/nfsd/ExportMgr org.ganesha.nfsd.exportmgr.AddExport string:/etc/ganesha/export.d/share-93b1e23d-0166-41a4-a12a-51bf4c3654a5.conf string:EXPORT(Export_Id=105) Exit code: 1 Stdout: u'' Stderr: u'Error org.freedesktop.DBus.Error.ServiceUnknown: The name org.ganesha.nfsd was not provided by any .service files\n' 2019-11-11 10:11:14.954 26 ERROR oslo_messaging.rpc.server Traceback (most recent call last): 2019-11-11 10:11:14.954 26 ERROR oslo_messaging.rpc.server File "/var/lib/kolla/venv/lib/python2.7/site-packages/oslo_messaging/rpc/server.py", line 165, in _process_incoming 2019-11-11 10:11:14.954 26 ERROR oslo_messaging.rpc.server res = self.dispatcher.dispatch(message) 2019-11-11 10:11:14.954 26 ERROR oslo_messaging.rpc.server File "/var/lib/kolla/venv/lib/python2.7/site-packages/oslo_messaging/rpc/dispatcher.py", line 274, in dispatch 2019-11-11 10:11:14.954 26 ERROR oslo_messaging.rpc.server return self._do_dispatch(endpoint, method, ctxt, args) 2019-11-11 10:11:14.954 26 ERROR oslo_messaging.rpc.server File "/var/lib/kolla/venv/lib/python2.7/site-packages/oslo_messaging/rpc/dispatcher.py", line 194, in _do_dispatch 2019-11-11 10:11:14.954 26 ERROR oslo_messaging.rpc.server result = func(ctxt, **new_args) 2019-11-11 10:11:14.954 26 ERROR oslo_messaging.rpc.server File "/var/lib/kolla/venv/lib/python2.7/site-packages/manila/share/manager.py", line 187, in wrapped 2019-11-11 10:11:14.954 26 ERROR oslo_messaging.rpc.server return f(self, *args, **kwargs) 2019-11-11 10:11:14.954 26 ERROR oslo_messaging.rpc.server File "/var/lib/kolla/venv/lib/python2.7/site-packages/manila/utils.py", line 568, in wrapper 2019-11-11 10:11:14.954 26 ERROR oslo_messaging.rpc.server return func(self, *args, **kwargs) 2019-11-11 10:11:14.954 26 ERROR oslo_messaging.rpc.server File "/var/lib/kolla/venv/lib/python2.7/site-packages/manila/share/manager.py", line 3554, in update_access 2019-11-11 10:11:14.954 26 ERROR oslo_messaging.rpc.server share_server=share_server) 2019-11-11 10:11:14.954 26 ERROR oslo_messaging.rpc.server File "/var/lib/kolla/venv/lib/python2.7/site-packages/manila/share/access.py", line 283, in update_access_rules 2019-11-11 10:11:14.954 26 ERROR oslo_messaging.rpc.server share_server=share_server) 2019-11-11 10:11:14.954 26 ERROR oslo_messaging.rpc.server File "/var/lib/kolla/venv/lib/python2.7/site-packages/manila/share/access.py", line 322, in _update_access_rules 2019-11-11 10:11:14.954 26 ERROR oslo_messaging.rpc.server share_server) 2019-11-11 10:11:14.954 26 ERROR oslo_messaging.rpc.server File "/var/lib/kolla/venv/lib/python2.7/site-packages/manila/share/access.py", line 390, in _update_rules_through_share_driver 2019-11-11 10:11:14.954 26 ERROR oslo_messaging.rpc.server share_server=share_server 2019-11-11 10:11:14.954 26 ERROR oslo_messaging.rpc.server File "/var/lib/kolla/venv/lib/python2.7/site-packages/manila/share/drivers/cephfs/driver.py", line 289, in update_access 2019-11-11 10:11:14.954 26 ERROR oslo_messaging.rpc.server share_server=share_server) 2019-11-11 10:11:14.954 26 ERROR oslo_messaging.rpc.server File "/var/lib/kolla/venv/lib/python2.7/site-packages/manila/share/drivers/ganesha/__init__.py", line 308, in update_access 2019-11-11 10:11:14.954 26 ERROR oslo_messaging.rpc.server self.ganesha.add_export(share['name'], confdict) 2019-11-11 10:11:14.954 26 ERROR oslo_messaging.rpc.server File "/var/lib/kolla/venv/lib/python2.7/site-packages/manila/share/drivers/ganesha/manager.py", line 491, in add_export 2019-11-11 10:11:14.954 26 ERROR oslo_messaging.rpc.server cmd=e.cmd) 2019-11-11 10:11:14.954 26 ERROR oslo_messaging.rpc.server GaneshaCommandFailure: Ganesha management command failed. 2019-11-11 10:11:14.954 26 ERROR oslo_messaging.rpc.server Command: sudo manila-rootwrap /etc/manila/rootwrap.conf dbus-send --print-reply --system --dest=org.ganesha.nfsd /org/ganesha/nfsd/ExportMgr org.ganesha.nfsd.exportmgr.AddExport string:/etc/ganesha/export.d/share-93b1e23d-0166-41a4-a12a-51bf4c3654a5.conf string:EXPORT(Export_Id=105) 2019-11-11 10:11:14.954 26 ERROR oslo_messaging.rpc.server Exit code: 1 2019-11-11 10:11:14.954 26 ERROR oslo_messaging.rpc.server Stdout: u'' 2019-11-11 10:11:14.954 26 ERROR oslo_messaging.rpc.server Stderr: u'Error org.freedesktop.DBus.Error.ServiceUnknown: The name org.ganesha.nfsd was not provided by any .service files\n' 2019-11-11 10:11:14.954 26 ERROR oslo_messaging.rpc.server I found some possible solutions[0][1][2][3] to try to fix this, but failed. Any suggestions? [0] https://github.com/nfs-ganesha/nfs-ganesha/issues/483 [1] https://github.com/nfs-ganesha/nfs-ganesha/issues/219 [2] https://github.com/gluster/storhaug/issues/14 [3] https://sourceforge.net/p/nfs-ganesha/mailman/message/32227132/ Thanks, Boxiang

2 2

[Senlin] Splitting senlin-engine into three services
by Erik Olof Gunnar Andersson 10 Nov '19

10 Nov '19

We are looking into splitting the senlin-engine into three components (senlin-conductor, senlin-engine and senlin-health-manager) and wanted to get some feedback. The main goal here is to make the components more resilient and to reduce the number of threads per worker. Each one of the components already had it's own thread pool and in theory each worker could end up with thousands of thread. In the current version (Train) the engine process hosts these services. https://github.com/openstack/senlin/blob/stable/train/senlin/engine/dispatc… https://github.com/openstack/senlin/blob/stable/train/senlin/engine/health_… https://github.com/openstack/senlin/blob/stable/train/senlin/engine/service… In my patch we move two our of these out of the engine and into it's own service namespace. Split engine service into three services https://review.opendev.org/#/c/688784/ Please feel free to comment on the patch set, or let reply to this email with general feedback or concerns. Best Regards, Erik Olof Gunnar Andersson

1 1

[nova][neutron][ptg] Nova - Neutron cross project dicussions
by Balázs Gibizer 10 Nov '19

10 Nov '19

https://etherpad.openstack.org/p/ptg-ussuri-xproj-nova-neutron Nova-Neutron live-migration - ACTIVE/INACTIVE port bindings issue * nova needs vif plug event for inactive bindings * live migration with ml2-ovs only works by luck * agentless drivers does not support this https://bugs.launchpad.net/neutron/+bug/1834045 https://bugs.launchpad.net/neutron/+bug/1840147 Agreements: * document the nova-neutron live migration workflow to create a common base for discussion. Add ijw and sean-k-mooney to the review SR-IOV live migration utilizing kernel NET_FAILOVER feature * aim to support live migration with SRIOV nic without traffic interrupt by bonding a virtio interface to the SRIOV nic in the guest kernel with NET_FAILOVER. * https://www.kernel.org/doc/html/latest/networking/net_failover.html * There was multiple solution proposlas but no agreements about which one to pursue. * TODO: adrianc to propose a nova spec based on the discussion Correlation of Bandwidth RP with PCI RP when PCI will be tracked in Placement * Early heads up to Neutron team that Nova things about modelling PCI in Placement * Current best thinking on Nova side is to correlate BW RP with PCI RP in placement with a placement aggregate. * Nova will do the correlation * Neutron needs to prepare for possible BW RP generation conflict * Agreement: Neutron is OK with this plan. rubasov can help with the neutron impact when nova makes progress.

1 0

[nova][ptg] Ussuri cycle themes
by Balázs Gibizer 10 Nov '19

10 Nov '19

Ussuri themes proposal: * Policy work Note for the operators that this work only provides value after the whole work is ready and it is pretty possible that this will not finish in the current cycle. * Unified limits Discuss on the ML how can we help oslo to progress with the oslo-limits work. If we can help with that then, make unified limits as a cycle Goal. * Cyborg - Nova integration (bauzas) I'm OK with making Cyborg a priority for this cycle provided we don't hold any attempt to start thinking on fixing PCI tracking. We definitely needs to discuss this further with the whole team. Cheers, gibi

1 0

[nova][ironic][ptg] reconfigure the baremetal node through the resize API
by Balázs Gibizer 10 Nov '19

10 Nov '19

ironic spec https://review.opendev.org/#/c/672252/ TODOs: * alex_xu (?) to create a nova spec to list possible alternatives about which nova REST API could be used to trigger reconfigure (resize, reboot, new api) * A potential way forward would be Ironic supporting resize (confirm/revert) as well with some magical autodetection of an Ironic instance *or* some magical flavor-based solution Cheers, gibi

1 0

[nova][ptg] Other small discussions
by Balázs Gibizer 10 Nov '19

10 Nov '19

image precache support * aarents (OVH?) interested in the feauter * TODO: aarents to talk to dansmith about future improvements like rate limiting nova implications of a starlingx bug: https://bugs.launchpad.net/starlingx/+bug/1850834 * TODO: yawang to file a nova bug if reproducible * TODO: yawang to propose a patch in nova based on the starlingx fix https://gist.github.com/VictorRodriguez/e137a8cd87cf821f8076e9acc02ce195 vm scoped sriov numa affinity * spec: https://review.opendev.org/#/c/683174/4 * there was not enough knowledge in the room to really discuss * TODO: gibi to read and comment the spec midcylce * stephenfin will propose a midcycle disussion on the ML

1 0

Re: [nova][ptg] Flavor explosion
by Brin Zhang(张百林) 10 Nov '19

10 Nov '19

Gibi: The summary on the ML write in the nova ptg etherpad line 245 cannot open, raised a 404 error. Etherpad: https://etherpad.openstack.org/p/nova-shanghai-ptg Thanks. Brin Zhang items: [lists.openstack.org代发][nova][ptg] Flavor explosion original spec: https://review.opendev.org/#/c/663563 with -2s The first round of discussion was resulted in no agreement. Then on Friday we revisited the issue based on mdbooth's proposal about composability. Agreement in the room: * Do not try to change the model of the flavor in nova code and in the db. * Define a "ComposableFlavorBit" (bikeshed on the name please) REST API entity that can hold any kind of flavor bits (extra specs, normal flavor fields), propose some format in the spec for it. This entity can only be created by the admin by default * Extend the server create REST API to allow the end user to specify what "ComposableFlavorBit"s she wants to add to the "base" flavor she used in the create request. * The nova api then merges the "ComposableFalvorBit"s with the base flavor and embed the resulted flavor object into the instance. * Do a similar thing for resize TODOs: * brinzhang (with possible help from yawang) to re-write the spec Cheers, gibi

3 2

[nova][ptg] Flavor explosion
by Balázs Gibizer 10 Nov '19

10 Nov '19

original spec: https://review.opendev.org/#/c/663563 with -2s The first round of discussion was resulted in no agreement. Then on Friday we revisited the issue based on mdbooth's proposal about composability. Agreement in the room: * Do not try to change the model of the flavor in nova code and in the db. * Define a "ComposableFlavorBit" (bikeshed on the name please) REST API entity that can hold any kind of flavor bits (extra specs, normal flavor fields), propose some format in the spec for it. This entity can only be created by the admin by default * Extend the server create REST API to allow the end user to specify what "ComposableFlavorBit"s she wants to add to the "base" flavor she used in the create request. * The nova api then merges the "ComposableFalvorBit"s with the base flavor and embed the resulted flavor object into the instance. * Do a similar thing for resize TODOs: * brinzhang (with possible help from yawang) to re-write the spec Cheers, gibi

1 0