- openstack-discuss - lists.openstack.org

No manila meeting 29 August 2019
by Tom Barron 28 Aug '19

28 Aug '19

We have quite a few folks unavailable this Thursday and will cancel this week's Manila community meeting. The next meeting will be the following week, 5 September, at 1500 UTC as usual.

1 0

[nova] ComputeDriver.spawn getting a power_on kwarg
by Matt Riedemann 28 Aug '19

28 Aug '19

This is just an FYI to out of tree virt driver maintainers that the ComputeDriver.spawn interface is getting a new power_on kwarg with this chnage: https://review.opendev.org/#/c/642590/ -- Thanks, Matt

1 0

FWAAS V2 doesn't work with DVR
by Salman Khan 28 Aug '19

28 Aug '19

Hi Guys, I asked this question over #openstack-neutron channel but didn't get any answer, so asking here in a hope that someone might read this email and reply. The problem is: I have enabled FWAAS_V2 with DVR and that doesn't seem to work. I debugged things down to router namespaces and it looks like iptables rules are applied to rfp-<network-id> interface which doesn't exist in that namespace. So rules are completely wrong as they are applied to an interface that doesn't exist, I mean there is rfp-* interface but the <network-id> that fwaas expecting is not what it should be. I tried applying the rules to qr-* interfaces in the namespace but that didn't work as well, packets are dropping on "invalid" state rule. That's probably because of nat rules from dvr. Can someone please help me to understand this behaviour. Is it really suppose to work or not. If there is any bug or fix pending or there is any work ongoing to support this. Regards, Salman

2 2

[scientific-sig] SIG IRC meeting today 1100 UTC
by Stig Telfer 28 Aug '19

28 Aug '19

Hi All - We have an IRC meeting today at 1100 UTC (about an hour’s time) in channel #openstack-meeting. Everyone is welcome. Today’s agenda is here: https://wiki.openstack.org/wiki/Scientific_SIG#IRC_Meeting_August_28th_2019 <https://wiki.openstack.org/wiki/Scientific_SIG#IRC_Meeting_August_28th_2019> Cheers, Stig

1 0

[glance][neutron] Glance migrations broken for postgresql; impact to Neutron periodic jobs
by Nate Johnston 28 Aug '19

28 Aug '19

Glance developers, I am investigating failures with the neutron-tempest-postgres-full periodic job in Zuul, and it looks like the failing step is actually a database migration for Glance that occurs during devstack setup. Pasted below is a representative example [1]. You can see the same issue causing failures for this neutron periodic job by looking at the Zuul failures [2]; the error is in logs/devstacklog.txt.gz. The last successful job was 2019-08-15T06:07:06; the next one on 2019-08-16 failed. But there were no changes merged in glance during that time period [3]. So if you could help debug the source of this issue then we can hopefully get this job - and probably whatever others depend on postgresql - back working. 2019-08-27 06:35:44.963 | INFO [alembic.runtime.migration] Running upgrade rocky_expand02 -> train_expand01, empty expand for symmetry with train_contract01 2019-08-27 06:35:44.967 | INFO [alembic.runtime.migration] Context impl PostgresqlImpl. 2019-08-27 06:35:44.967 | INFO [alembic.runtime.migration] Will assume transactional DDL. 2019-08-27 06:35:44.970 | Upgraded database to: train_expand01, current revision(s): train_expand01 2019-08-27 06:35:44.971 | INFO [alembic.runtime.migration] Context impl PostgresqlImpl. 2019-08-27 06:35:44.971 | INFO [alembic.runtime.migration] Will assume transactional DDL. 2019-08-27 06:35:44.975 | INFO [alembic.runtime.migration] Context impl PostgresqlImpl. 2019-08-27 06:35:44.975 | INFO [alembic.runtime.migration] Will assume transactional DDL. 2019-08-27 06:35:44.995 | CRITI [glance] Unhandled error 2019-08-27 06:35:44.996 | Traceback (most recent call last): 2019-08-27 06:35:44.996 | File "/usr/local/bin/glance-manage", line 10, in <module> 2019-08-27 06:35:44.996 | sys.exit(main()) 2019-08-27 06:35:44.996 | File "/opt/stack/new/glance/glance/cmd/manage.py", line 563, in main 2019-08-27 06:35:44.996 | return CONF.command.action_fn() 2019-08-27 06:35:44.996 | File "/opt/stack/new/glance/glance/cmd/manage.py", line 395, in sync 2019-08-27 06:35:44.996 | self.command_object.sync(CONF.command.version) 2019-08-27 06:35:44.996 | File "/opt/stack/new/glance/glance/cmd/manage.py", line 166, in sync 2019-08-27 06:35:44.996 | self.migrate(online_migration=False) 2019-08-27 06:35:44.996 | File "/opt/stack/new/glance/glance/cmd/manage.py", line 294, in migrate 2019-08-27 06:35:44.996 | if data_migrations.has_pending_migrations(db_api.get_engine()): 2019-08-27 06:35:44.996 | File "/opt/stack/new/glance/glance/db/sqlalchemy/alembic_migrations/data_migrations/__init__.py", line 61, in has_pending_migrations 2019-08-27 06:35:44.997 | return any([x.has_migrations(engine) for x in migrations]) 2019-08-27 06:35:44.997 | File "/opt/stack/new/glance/glance/db/sqlalchemy/alembic_migrations/data_migrations/train_migrate01_backend_to_store.py", line 28, in has_migrations 2019-08-27 06:35:44.997 | metadata_backend = con.execute(sql_query) 2019-08-27 06:35:44.997 | File "/usr/local/lib/python2.7/dist-packages/sqlalchemy/engine/base.py", line 982, in execute 2019-08-27 06:35:44.997 | return self._execute_text(object_, multiparams, params) 2019-08-27 06:35:44.997 | File "/usr/local/lib/python2.7/dist-packages/sqlalchemy/engine/base.py", line 1155, in _execute_text 2019-08-27 06:35:44.997 | parameters, 2019-08-27 06:35:44.997 | File "/usr/local/lib/python2.7/dist-packages/sqlalchemy/engine/base.py", line 1248, in _execute_context 2019-08-27 06:35:44.997 | e, statement, parameters, cursor, context 2019-08-27 06:35:44.997 | File "/usr/local/lib/python2.7/dist-packages/sqlalchemy/engine/base.py", line 1464, in _handle_dbapi_exception 2019-08-27 06:35:44.997 | util.raise_from_cause(newraise, exc_info) 2019-08-27 06:35:44.997 | File "/usr/local/lib/python2.7/dist-packages/sqlalchemy/util/compat.py", line 398, in raise_from_cause 2019-08-27 06:35:44.997 | reraise(type(exception), exception, tb=exc_tb, cause=cause) 2019-08-27 06:35:44.997 | File "/usr/local/lib/python2.7/dist-packages/sqlalchemy/engine/base.py", line 1244, in _execute_context 2019-08-27 06:35:44.998 | cursor, statement, parameters, context 2019-08-27 06:35:44.998 | File "/usr/local/lib/python2.7/dist-packages/sqlalchemy/engine/default.py", line 552, in do_execute 2019-08-27 06:35:44.998 | cursor.execute(statement, parameters) 2019-08-27 06:35:44.998 | DBError: (psycopg2.errors.UndefinedFunction) function instr(text, unknown) does not exist 2019-08-27 06:35:44.998 | LINE 1: select meta_data from image_locations where INSTR(meta_data,... 2019-08-27 06:35:44.998 | ^ 2019-08-27 06:35:44.998 | HINT: No function matches the given name and argument types. You might need to add explicit type casts. Thanks, Nate [1] also http://paste.openstack.org/show/765665/ if that is an easier view [2] http://zuul.openstack.org/builds?project=openstack%2Fneutron&job_name=neutr… [3] https://review.opendev.org/#/q/project:openstack/glance+status:merged

2 1

Re: [ops] [glance] Need to move images to a different backend
by Massimo Sgaravatto 28 Aug '19

28 Aug '19

Hi Abhishek Yes, before trying the: glance location-add --url rbd://8162f291-00b6-4b40-a8b4-1981a8c09b64/images-prod/6bcc4eab-ed35-42dc-88bd-1d45de73b628/snap 6bcc4eab-ed35-42dc-88bd-1d45de73b628 command, I uploaded the image to ceph. And indeed I can see it: [root@ceph-mon-01 ~]# rbd info images-prod/6bcc4eab-ed35-42dc-88bd-1d45de73b628 rbd image '6bcc4eab-ed35-42dc-88bd-1d45de73b628': size 10GiB in 1280 objects order 23 (8MiB objects) block_name_prefix: rbd_data.b7b56aa1e4f0bc format: 2 features: layering flags: create_timestamp: Tue Aug 27 11:42:32 2019 [root@ceph-mon-01 ~]# rbd snap ls images-prod/6bcc4eab-ed35-42dc-88bd-1d45de73b628 SNAPID NAME SIZE TIMESTAMP 455500 snap 10GiB Tue Aug 27 11:46:37 2019 [root@ceph-mon-01 ~]# Cheers, Massimo On Tue, Aug 27, 2019 at 2:41 PM Abhishek Kekane <akekane(a)redhat.com> wrote: > Hi Massimo, > > I need to reproduce this first, but pretty much sure this issue is not > because you configured multiple backends. What you are doing is downloading > existing image to your local storage and then uploading it to glance using > add-location operation. > > So before adding this using add-location operation have you manually > uploaded this image to ceph/rbd? if not then how you are building your > location url which you are mentioning in the add-location command? If this > location is not existing then it might be a problem. > > Thank you, > > Abhishek > > On Tue, 27 Aug 2019 at 5:09 PM, Massimo Sgaravatto < > massimo.sgaravatto(a)gmail.com> wrote: > >> I have a Rocky installation where glance is configured with multiple >> backends. This [*] is the relevant part of the glance configuration. >> >> I now need to dismiss the file backend and move the images-snapshots >> stored there to rbd. >> >> >> I had in mind to follow this procedure (already successfully tested with >> an older version of OpenStack): >> >> 1) download the image from the file backend (glance image-download --file >> <file> <imageid> >> 2) upload the file <file> to rbd, relying on this function: >> https://github.com/openstack/glance_store/blob/stable/rocky/glance_store/_d… >> 3) glance location-add --url rbd://xyz <imageid> >> 4) glance location-delete --url file://abc <imageid> >> >> I have problems with 3: >> >> # glance --debug location-add --url >> rbd://8162f291-00b6-4b40-a8b4-1981a8c09b64/images-prod/6bcc4eab-ed35-42dc-88bd-1d45de73b628/snap >> 6bcc4eab-ed35-42dc-88bd-1d45de73b628 >> ... >> ... >> DEBUG:keystoneauth.session:PATCH call to image for >> https://cloud-areapd.pd.infn.it:9292/v2/images/6bcc4eab-ed35-42dc-88bd-1d45… >> used request id req-6c0598cc-582c-4ce7-a14c-5d1bb6ec4f14 >> Request returned failure status 400. >> DEBUG:glanceclient.common.http:Request returned failure status 400. >> Traceback (most recent call last): >> File "/usr/lib/python2.7/site-packages/glanceclient/shell.py", line >> 687, in main >> OpenStackImagesShell().main(argv) >> File "/usr/lib/python2.7/site-packages/glanceclient/shell.py", line >> 591, in main >> args.func(client, args) >> File "/usr/lib/python2.7/site-packages/glanceclient/v2/shell.py", line >> 749, in do_location_add >> image = gc.images.add_location(args.id, args.url, metadata) >> File "/usr/lib/python2.7/site-packages/glanceclient/v2/images.py", line >> 448, in add_location >> response = self._send_image_update_request(image_id, add_patch) >> File "/usr/lib/python2.7/site-packages/glanceclient/common/utils.py", >> line 598, in inner >> return RequestIdProxy(wrapped(*args, **kwargs)) >> File "/usr/lib/python2.7/site-packages/glanceclient/v2/images.py", line >> 432, in _send_image_update_request >> data=json.dumps(patch_body)) >> File "/usr/lib/python2.7/site-packages/keystoneauth1/adapter.py", line >> 340, in patch >> return self.request(url, 'PATCH', **kwargs) >> File "/usr/lib/python2.7/site-packages/glanceclient/common/http.py", >> line 377, in request >> return self._handle_response(resp) >> File "/usr/lib/python2.7/site-packages/glanceclient/common/http.py", >> line 126, in _handle_response >> raise exc.from_response(resp, resp.content) >> HTTPBadRequest: 400 Bad Request: Invalid location (HTTP 400) >> 400 Bad Request: Invalid location (HTTP 400) >> >> >> As far as I can see with the "openstack" client there is not something to >> add/delete a location. >> So I guess it is necessary to change the 'direct_url' and 'locations' >> properties. >> >> If I try to change the direct_url property: >> >> # openstack image set --property >> direct_url='rbd://8162f291-00b6-4b40-a8b4-1981a8c09b64/images-prod/6bcc4eab-ed35-42dc-88bd-1d45de73b628/snap' >> 6bcc4eab-ed35-42dc-88bd-1d45de73b628 >> 403 Forbidden: Attribute 'direct_url' is read-only. (HTTP 403) >> >> Any hints ? >> Thanks, Massimo >> >> [*] >> >> [default] >> ... >> enabled_backends = file:file,http:http,rbd:rbd >> show_image_direct_url = true >> show_multiple_locations = true >> >> [glance_store] >> default_backend = rbd >> >> [file] >> filesystem_store_datadir = /var/lib/glance/images/ >> >> >> [rbd] >> rbd_store_chunk_size = 8 >> rbd_store_ceph_conf = /etc/ceph/ceph.conf >> rbd_store_user = glance-prod >> rbd_store_pool = images-prod >> >> -- > Thanks & Best Regards, > > Abhishek Kekane >

2 3

Zuul log location changing
by corvus＠inaugust.com 28 Aug '19

28 Aug '19

Hi, We've been working for some time[1] to retire our current static log server in favor of storing Zuul job logs in Swift. We're just about ready to do that. This means that not only do we get to use another great OpenStack project, but we also can stop worrying about fscking our 14TB log partition whenever it gets hit with a comsic ray. The change will happen in two phases, only the first of which should be readily apparent. Phase 1: On Monday August 12, 2019 we will change the URL that Zuul reports back to Gerrit. Instead of being a direct link to the log server, it will be a link to the Zuul Build page for the job. This is part of Zuul's web interface which has been around for a while, but isn't well known since we haven't linked to it yet. The build page shows a summary of information about the build, including output snippets for failed tasks. Next to the "Summary" tab, you'll find the "Logs" tab. This contains an expandable index of all the log files uploaded for the build. If they are text files, they can be rendered in-app with line-number hyperlinks and severity filtering. There are also direct links to the files on the log server. Links to preview sites (e.g., for docs builds) will show up in the "Artifacts" section. We also plan to further enhance the build page with additional features. Here are some links to sample build pages so you can see what it's like: https://zuul.opendev.org/t/openstack/build/a6e13a8098fc4a1fbff43d8f2c27ad29 https://zuul.opendev.org/t/openstack/build/75d1e8d4ffaf477db00520d7bfd77246 This step is necessary because our static log server implements a number of features as WSGI middleware in Apache. We have re-implemented the these on the Zuul build page, so there should be no loss in functionality (in fact, we think this is an improvement). Once in place, we can change the backend storage options without impacting the user interface. Phase 2: Shortly afterwards (depending on how phase 1 goes), we will configure jobs to upload logs to Swift instead of the static log server. At this point, there should be no user-visible change, since the main interface for interacting with logs is now the Zuul build page. However, you may notice that log urls have changed from our static log server to one of six different Swift instances. The Swift instance used to store the logs for any given build is chosen at random from among our providers, and is yet another really cool multi-cloud feature we get by using OpenStack. Thanks to our amazing providers and all of the folks who have helped with this effort over the years[1]. Please let us know if you have any questions or encounter any issues, either here, or in #openstack-infra on IRC. -Jim [1] Years. So. Many. Years.

5 7

[placement][plt][elections] Non-nomination for U
by Chris Dent 28 Aug '19

28 Aug '19

tl;dr: I'd prefer not to be Placement PTL for the U cycle. I've accomplished most of what I set out to do and I think we have other members of the team who would make excellent PTLs (notably tetsuro and gibi). Longer version: Getting placement standing on its own feet, with a mostly reasonable architecture, reasonable performance, and a fairly complete set of features has pretty much been my single focus since the start of 2016. From both a personal and professional standpoint I need to focus some energy elsewhere, lest the deep ruts in my brain become permanent. I think it is important to not be shy about the goal of that three and a half year process: Get placement out of nova and get nova out of placement. The architectural differences necessary to make placement work well, be maintainable, and easily deployable [1] we're difficult to do within nova (for many reasons), but once extracted took a matter of days. Nova, neutron, blazar, zun, watcher, and cyborg all use, or are in the process of starting to use, placement. Ironic is thinking about it. So: some success. But it's not all gravy, there are still some things left to do: While the fundamental concept of placement (presenting and keeping track of inventory of resources) is pretty straightforward, using it most effectively can be complicated, especially if nested resource providers are involved. There's a lot of work to be done to document how to best model data and queries. As the number of resources in the cloud grows it becomes increasingly important to "ask better questions"; knowing how to do that shouldn't require 3 years of experience. The "consumer types" feature is in flight. It will allow placement to be used to keep track of resource usage for some types of quota, which makes good sense: If we're already tracking "user X is using N VCPU" in placement it's wasteful tracking it somewhere else as well. Placement sharding, so that one placement can track multiple domains, is a feature that we've discussed in the last couple of years, thinking perhaps it could be useful to edge setups. Until the recent performance improvements it wouldn't have worked well, but now it might. However, until real users present themselves with a need for this feature, there's not much point moving forward with it. We should continue to do benchmarking and profiling. That work has done wonders to reveal unexpected areas for improvement. Being willing and able to analyse and adjust the system and the code, continuously, is key to ensuring the project does not become moribund or calcified. Thanks to everyone who has helped get placement to a healthy place. [1] For some examples: We've taken a common benchmark from 17s to .5s. It's now possible to run placement without a config file or without a manual database sync. Every module has a maintainability index of "A". Placement doesn't use eventlet (and is not accidentally infected by it) so it can benefit from whatever threading or multi-processing model whatever chosen WSGI server provides. Placement is a simple web app over a (not so simple) persistence and query layer. The web app and the associated database server(s) can be scaled independently, up and out. -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent

3 2

[octavia] Stepping down from Octavia core team
by Nir Magnezi 27 Aug '19

27 Aug '19

Hi all, As some of you already know, I'm no longer involved in Octavia development and therefore stepping down from the core team. It has been a pleasure to be a part of the Octavia (and neutron-lbaas) core team for nearly three years. I learned a lot. Octavia is an excellent project with a strong core team, and I'm sure it will continue to grow and gain more adoption. Thanks, Nir

4 3

Re: [all][tc][horizon] A web tool which helps administrators in managing openstack clusters
by Adrian Turjak 27 Aug '19

27 Aug '19

Bah, sent it via my phone and didn't hit reply all. On 26/08/19 10:55 PM, Jim Rollenhagen wrote: > Fair points. In case you didn't realize, you only sent this to me, not > the list :) > > // jim > > > On Sat, Aug 24, 2019 at 1:45 AM Adrian Turjak <adriant(a)catalyst.net.nz > <mailto:adriant@catalyst.net.nz>> wrote: > > > > On 24 Aug. 2019 00:08, Jim Rollenhagen <jim(a)jimrollenhagen.com > <mailto:jim@jimrollenhagen.com>> wrote: > > On Fri, Aug 23, 2019 at 3:21 AM Adrian Turjak > <adriant(a)catalyst.net.nz <mailto:adriant@catalyst.net.nz>> wrote: > > Hello Douglas! > > As someone who has struggled against the performance > issues in Horizon I can easily feel your pain, and an > effort to making something better is good. Sadly, this > doesn't sound like a safe direction, even if for admin > only purposes. > > The first major issue is that you connect to the databases > of the services directly. That's a major issue, both for > long term compatibility, and security. The APIs should > always be the main point of contact and the ONLY contract > that the services have to maintain. By connecting to the > database directly you are now relying on a data structure > that can, and likely will change, and any security and > sanity checking on filters and queries is now handled on > your layer rather than the application itself. Not only > that, but your dashboard also now needs passwords for all > the databases, and by the sounds of it all the message queues. > > I would highly encourage you to try and work with the > community to fix the issues at the API layers rather than > bypassing them. We can add better query and filtering to > the APIs, and we can work on improving performance if we > know the pain points, and this is likely where > contributions would be welcome. > > I think we do need an alternative to Horizon, and the > ideal solution in my mind is to make a new dashboard built > on either React or Vue, with a thin proxy app (likely in > Flask) that serves the initial javascript page, and > proxies any API requests to the services themselves. The > filter issues should made better by implementing more > complex filtering in the APIs themselves, and having the > Dashboard layer better at exposing those dynamically. > React or Vue would do a much better job of dynamically and > quickly reloading and querying the services, and it would > make the whole experience much nicer. > > Michael Krotscheck did a bunch of work to put CORS config in > many API services. Why bother with a proxy when we can > continue that? :) > > > We deploy our dashboard publically, but our APIs are behind a > whitelist only firewall. I bet we're not the only one. So we need > the proxy like nature of the dashboard API calls. > > I personally like the idea of the browser able to talk to the APIs > directly, but I have a feeling there may be other reasons to avoid > that. Not to mention you get a clearer picture of which API calls > come from the dashboard. Plus, a proxy via the dashboard app > itself (assuming it is deployed near the cluster) won't exactly > add much extra to the response time. > > But if we as a community do end up going down this route, we can > discuss if we need the app to proxy or not. If not, then really we > are just building a pure JavaScript app, but if we do need to > proxy, then the proxy layer would still be very simple with the > core logic all in the front-end. > > > The one of the best parts of Horizon was that it was a > 'dumb' dashboard built around your token. It can be > deployed anywhere, by anyone, and only needs access to the > cluster to work, no secrets to any database. > > I know this is a huge issue, and we do need to solve it, > but I hope we can work on something better that doesn't > bypass the APIs, because that isn't a safe solution. :( > > Cheers, > > Adrian Turjak > > On 20/08/19 10:14 PM, Douglas Zhang wrote: > > Hello everyone, > > To help users interact with openstack, we’re currently > developing a client-side web tool which enables > administrators to manage their openstack cluster in a > more efficient and convenient way. (Since we have not > named it officially yet, I’m going to call it > openstack-admin) > > *# Introduction* > > Some may ask, “Why do we need an extra web-based user > interface since we have horizon?” Well, although > horizon is a mature and powerful dashboard, it is far > not efficient enough on big clusters (a simple |list| > operation could take seconds to complete). What’s > more, its flexibility of searching could not match our > requirements. To overcome obstacles above, a more > efficient tool is urgently required, that’s why we > started to develop openstack-admin. > > *# Highlights* > > Comparing with the current user interface, > openstack-admin has following advantages: > > * > > *Fast*: openstack-admin gets data straightly from > SQL databases instead of calling standard > openstack API, which accelerates the querying > period to a large extent (especially when we’re > dealing with a large amount of data). > > * > > *Flexible*: openstack-admin supports the fuzzy > search for any important field(e.g. > display_name/uuid/ip_address/project_name of an > instance), which enables users to locate a > particular object in no time. > > * > > *User-friendly*: the backend of openstack-admin > gets necessary messages from the message queue > used by nova, and send them to the frontend using > websocket. This way, not only more realistic > progress bars could be implemented, but more > detailed information could be provided to users as > well. > > *# Issues* > > To make this tool more efficient and provide better > support for concurrency, we chose Golang to implement > openstack-admin. As I’ve asked before (truly > appreciate advises from Jeremy and Ghanshyam), a > project written by an unofficial language may be > accepted only if existing languages have been proven > to not meet the technical requirements, so we’re > considering re-implementing openstack-admin using > python if we can’t come to an agreement on the > language issue. > > So that’s all. How do you guys think of this project? > > Thanks, > > Douglas Zhang > >

1 0

Re: Re: [all][tc][horizon] A web tool which helps administrators in managing openstack clusters
by Douglas Zhang 27 Aug '19

27 Aug '19

Hello everyone, Thanks for your attention and advice for this project. We have read each reply thoroughly and the good news is that we’re able to give answers to some questions raised by them. As Lingxian Kong said: I have a few questions/suggestions: 1. It'd be great and gain more attractions if you could provide a demo about how "openstack-admin" looks like 2. What OpenStack services has "openstack-admin" already integrated? Is it easy to integrate with others? 1. We have deployed openstack-admin <http://218.205.220.13:9384/login> on a mini openstack cluster as a demo, any access would be welcomed. - Username: openstack-admin - Password: @Dem0 2. Since openstack-admin gets information it needs by querying the sql database, it’s fairly easy to integrate with all openstack services. - As the demo shows, openstack-admin has integrated *nova*(almost all GET and part of POST), *cinder*(GET and snapshot-creation), *neutron*(subnets and ports), *keystone*(projects) and *glance*(images), that’s all we need in our own working environment. - If we need to integrate more services to openstack-admin(e.g. adding a create instance button or integrating with swift), it would not be a complex task, either. As Adrian Turjak said: The first major issue is that you connect to the databases of the services directly. That's a major issue, both for long term compatibility, and security. The APIs should always be the main point of contact and the ONLY contract that the services have to maintain. By connecting to the database directly you are now relying on a data structure that can, and likely will change, and any security and sanity checking on filters and queries is now handled on your layer rather than the application itself. Not only that, but your dashboard also now needs passwords for all the databases, and by the sounds of it all the message queues. And as Mohammed Naser said: While I agree with you that querying database is much faster, this introduces two issues that I imagine for users: - Dashboards generally having direct access via SQL is a scary thing from an operators perspective - also, it will make maintaining the project quite hard because I don't think any projects expose a *stable* database API. Well, we’re not surprised that our querying approach would be challenged since it does sound unsafe. However, we have made some efforts to solve problems which have been posed: - We use a ORM library to create all queries, which ensures that only those instructions we have specified in the backend(i.e. select, order by, where and other harmless querying instructions) could be executed, protecting our databases from dangerous attacks like SQL injection. All sanity or security checkings would be automatically completed by those library functions. - All instructions that *may* change the database(e.g. start, shutoff, migrate) would be executed by calling standard openstack API, only pure GET instructions were implemented by querying databases directly. We have wrapped each API call with a go func() { ... }() to avoid the extremely long calling period. The results of API calls would be sent back to frontend by websocket asynchronously. - Passwords of databases and message queues(and many other kinds of information) are stored in a config file which would be loaded by openstack-admin. Simply by modifying this file, we could be consistent with all changes about sql databases and MQs. I hope my explanation is clear enough, and we’re willing to solve other possible issues existing. Cheers, Douglas Zhang

4 3

[Watcher] team meeting at 08:00 UTC today
by li.canwei2＠zte.com.cn 27 Aug '19

27 Aug '19

Hi, Watcher team will have a meeting at 08:00 UTC today in the #openstack-meeting-alt channel. The agenda is available on https://wiki.openstack.org/wiki/Watcher_Meeting_Agenda feel free to add any additional items. Thanks! Canwei Li

1 0

[horizon] Horizon's openstack_auth is completely broken with Django 2.2, breaking all the dashboad stack in Debian Sid/Bullseye
by Thomas Goirand 27 Aug '19

27 Aug '19

Hi, Django 2.2 was uploaded to Debian Sid/Bullseye a few days after Buster was released, removing at the same time any support for Python 2. This broke lots of packages, but I managed to upload more than 40 times to fix the situation. Though Horizon is still completely broken. There's a bunch of issues related to Django 2.2 for Horizon. I managed to patch Horizon for a few of them, but there's one bigger issue which I can't solve myself, because I'm not skilled enough in Django, and don't know enough about Horizon's internal. Let me explain. In Django 1.11, the login() function in openstack_auth/views.py was deprecated in the favor of a LoginView class. In Django 2.2, the login() function is now not supported anymore. This means that, if openstack_auth/views.py doesn't get rewritten completely, Horizon will continue to be completely broken in Debian Sid/Bullseye. Unfortunately, the Horizon team is understaffed, and the PTL told me that they don't plan anything before Train+1. As a consequence, Horizon is completely broken in Debian Sid/Bullseye, and will stay as it is if nobody steps up for the work. After a month and a half with this situation not being solved by anyone, I'm hereby calling for help. I could attempt to work on this, though I need help and pointers at some example implementation of this. It'd be nicer if someone more skilled than me in Django was working on this anyways. Cheers, Thomas Goirand (zigo)

3 4

[designate][ptl][elections] Non Candidacy for U cycle
by Graham Hayes 27 Aug '19

27 Aug '19

Hi All, As I laid out in my Train nomination[1], Train was my last cycle as PTL for Designate. Change is good for projects, and Designate is well overdue for it.[2] The 4 years (with a 6 month break[3]), 4 or 5 different companies, and 2 API versions were a real experience - we did some great work as a team. As a project Designate has come a long way from the start, and team over the years really deserves congratulations. From something that was an outsider project in Folsem and Grizzly, to having a Trademark program now, we are in completely different space, and that is a testament to the wide group of people that have contributed (in terms of code, but also in running it, reporting bugs, helping us with docs, and translating it into many different languages) The project is used by some of the largest installs of OpenStack, and provides really useful service for cloud environments. We do have some work left to do, and as "cloud native" evolves, Designate will as well. I am not going to disappear - I still will be around to work on the project, explain why we did somethings that look weird[4], and help people set it up, but just not as a PTL. If anyone has any questions on what the role entails, or are interested but want some more info, please reach out, via email, mugsie on freenode, or on the #openstack-dns channel Thanks everyone, - Graham 1 - In 7 years, we have had 3 PTLs, and one of them was for a single cycle 2 - https://opendev.org/openstack/election/raw/branch/master/candidates/train/D… 3 - thanks timsim for giving me a break :) 4 - Most of the time, its my fault

2 1

[all][elections][ptl][tc] Combined PTL/TC Nominations Kickoff
by Jeremy Stanley 27 Aug '19

27 Aug '19

Nominations for OpenStack PTLs (Project Team Leads) and TC (Technical Committee) positions (6 positions) are now open and will remain open until Sep 03, 2019 23:45 UTC. All nominations must be submitted as a text file to the openstack/election repository as explained at https://governance.openstack.org/election/#how-to-submit-a-candidacy Please make sure to follow the candidacy file naming convention: candidates/u/<Project_Name or "TC">/<email_address> (for example, "candidates/u/TC/stacker(a)example.org"). The name of the file should match an email address for your current OpenStack Foundation Individual Membership. Take this opportunity to ensure that your OSF member profile contains current information: https://www.openstack.org/profile/ Any OpenStack Foundation Individual Member can propose their candidacy for an available, directly-elected seat on the Technical Committee. In order to be an eligible candidate for PTL you must be an OpenStack Foundation Individual Member. PTL candidates must also have contributed to the corresponding team during the Stein to Train timeframe, Aug 10, 2018 00:00 UTC - Sep 03, 2019 00:00 UTC. Your Gerrit account must also have a verified email address matching the one used in your candidacy filename. Both PTL and TC elections will be held from Sep 10, 2019 23:45 UTC through to Sep 17, 2019 23:45 UTC. The electorate for the TC election are the OpenStack Foundation Individual Members who have a code contribution one of the official teams over the Stein to Train timeframe, Aug 10, 2018 00:00 UTC - Sep 03, 2019 00:00 UTC, as well as any Extra ATCs who are acknowledged by the TC. The electorate for a PTL election are the OpenStack Foundation Individual Members who have a code contribution over the Stein to Train timeframe, Aug 10, 2018 00:00 UTC - Sep 03, 2019 00:00 UTC, in a deliverable repository maintained by the team for which the PTL would lead, as well as the Extra ATCs who are acknowledged by the TC for that specific team. The list of project teams can be found at https://governance.openstack.org/tc/reference/projects/ and their individual team pages include lists of corresponding Extra ATCs. Please find below the timeline: nomination starts @ Aug 27, 2019 23:45 UTC nomination ends @ Sep 03, 2019 23:45 UTC campaigning starts @ Sep 03, 2019 23:45 UTC campaigning ends @ Sep 10, 2019 23:45 UTC elections start @ Sep 10, 2019 23:45 UTC elections end @ Sep 17, 2019 23:45 UTC Shortly after election officials approve candidates, they will be listed on the https://governance.openstack.org/election/ page. The electorate is requested to confirm their email addresses in Gerrit, prior to 2019-09-03 00:00:00+00:00 so that the emailed ballots are mailed to the correct email address. This email address should match one which was provided in your foundation member profile as well. Gerrit account information and OSF member profiles can be checked at https://review.openstack.org/#/settings/contact and https://www.openstack.org/profile/ accordingly. If you have any questions please be sure to either ask them on the mailing list or to the elections officials: https://governance.openstack.org/election/#election-officials -- Jeremy Stanley, on behalf of the technical election officials

1 0

[all[ Please Do Not Translate Etherpads ...
by Jay Bryant 27 Aug '19

27 Aug '19

All, Not sure how else to address this, but we have had Cinder's etherpads repeatedly converted into Japanese recently. Want to make a public plea here to please be careful with translation tools and ensure that you aren't changing the etherpads in the process. Rebuilding the content to its previous state is tedious. Thank you! Jay (irc: jungleboyj)

7 12

[cinder] Mid-Cycle Summary and Video Posted ...
by Jay Bryant 27 Aug '19

27 Aug '19

All, I have gotten the Summary from the Cinder Mid-Cycle that we held at Lenovo's RTP campus last week posted. [1] Please take a look at the summary and see if you have any action items. Also note that I have tagged actions without an owner with the 'HELP NEEDED' tag. If you can take any of the action items it would be greatly appreciated. Thanks to all who participated and made it another successful mid-cycle! Jay (irc: jungleboyj) [1] https://wiki.openstack.org/wiki/CinderTrainMidCycleSummary

1 0

[oslo] No meeting next week, Sep. 2
by Ben Nemec 27 Aug '19

27 Aug '19

Hi, Next Monday is a US holiday and as a result I won't be available to run the meeting. Since that affects a number of our other Oslo contributors, I propose that we just skip the meeting for that week. It's the first day after feature freeze anyway so there shouldn't be _too_ much to discuss. As always, if anything comes up in the meantime you can bring it up in #openstack-oslo or here on the list. No need to wait for the meeting. Thanks. -Ben

1 0

[tripleo] PTL non-candidacy
by Alex Schultz 27 Aug '19

27 Aug '19

Hey folks, The PTL election cycle is upon us. I will not be running again for the TripleO PTL. I think this last cycle has been fairly successful from a stability stand point. We've continued to improve the deployment process and address a decent amount of tech debt. I will still be around in the community, but I think it's time for others to step up. If anyone has any questions about the position, feel free to reach out to me. Thanks, -Alex

1 0

[all][api-sig] Update on SIG status and seeking guidance from the community
by Michael McCune 27 Aug '19

27 Aug '19

hello all, I am writing on behalf of the API-SIG to update the community on our status. We have recently learned that Ed Leafe will be leaving the membership of the SIG as his new working circumstances are pulling him away from this work. This will leave us with only 2 active members, Dmitry Tantsur and myself. Firstly, I want to extend a heartfelt thanks to Ed. thank you =) I believe that Ed is the longest standing member of the SIG, having been active from the days when it was just a smol working group. His contributions have been numerous over the years and his guidance and wisdom will be missed. Second, this change in our membership has given rise to some questions about the future of the SIG and how we might best serve the OpenStack community. We currently hold an office hour each week and see relatively low traffic during this hour. Our activities have mainly been focused on writing and maintaining the guidelines and the support structure around those guidelines. As most of the new writing has ended (there are a few still in flight), we have been paying most of our attention to maintenance and supporting the community. As our ability to maintain an active membership has diminished, and many of our initial goals met, we have started to question whether we should still maintain the "SIG" status and also how we might best serve the community going forward. We will still need core members to review and approve changes, but perhaps we should adjust our workflow to be of greater service. I don't have any answers to this more existential question about the SIG, but we as a group felt it was a good idea to reach out to the wider community for advice and guidance. So, what do you all have to say? What would you like to see from the API-SIG moving forward? Should we re-evaluate the purpose of this group and how it relates to the OpenStack community? thank you all for the wonderful spirit of openness that we build with, and thanks for listening. and lastly, thanks again to Ed. You have acted as an example of the best aspects of open collaboration. peace o/

5 8

Getting the power state
by Mauricio Tavares 27 Aug '19

27 Aug '19

2 1

[os-upstream-institute][all] Mentors for Shanghai - sign up
by Ildiko Vancsa 27 Aug '19

27 Aug '19

Hi Upstream Institute Mentors, We are having the Upstream Institute training again prior to the Shanghai Summit. The training will take place in the Lenovo office in Shanghai in the afternoon of November 2nd and all day on November 3rd. As always we are running the training as community effort and looking for mentors to help teaching new contributors how to participate in and become part of the community. If you are interested in becoming a mentor please reply to this thread or sign up on the training wiki: https://wiki.openstack.org/wiki/OpenStack_Upstream_Institute_Occasions#Shan… For further details about the training you can check out the training website: https://docs.openstack.org/upstream-training/index.html Please let me know if you have any questions. Thanks and Best Regards, Ildikó (IRC: ildikov)

1 0

[ops] [glance] Need to move images to a different backend
by Massimo Sgaravatto 27 Aug '19

27 Aug '19

I have a Rocky installation where glance is configured with multiple backends. This [*] is the relevant part of the glance configuration. I now need to dismiss the file backend and move the images-snapshots stored there to rbd. I had in mind to follow this procedure (already successfully tested with an older version of OpenStack): 1) download the image from the file backend (glance image-download --file <file> <imageid> 2) upload the file <file> to rbd, relying on this function: https://github.com/openstack/glance_store/blob/stable/rocky/glance_store/_d… 3) glance location-add --url rbd://xyz <imageid> 4) glance location-delete --url file://abc <imageid> I have problems with 3: # glance --debug location-add --url rbd://8162f291-00b6-4b40-a8b4-1981a8c09b64/images-prod/6bcc4eab-ed35-42dc-88bd-1d45de73b628/snap 6bcc4eab-ed35-42dc-88bd-1d45de73b628 ... ... DEBUG:keystoneauth.session:PATCH call to image for https://cloud-areapd.pd.infn.it:9292/v2/images/6bcc4eab-ed35-42dc-88bd-1d45… used request id req-6c0598cc-582c-4ce7-a14c-5d1bb6ec4f14 Request returned failure status 400. DEBUG:glanceclient.common.http:Request returned failure status 400. Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/glanceclient/shell.py", line 687, in main OpenStackImagesShell().main(argv) File "/usr/lib/python2.7/site-packages/glanceclient/shell.py", line 591, in main args.func(client, args) File "/usr/lib/python2.7/site-packages/glanceclient/v2/shell.py", line 749, in do_location_add image = gc.images.add_location(args.id, args.url, metadata) File "/usr/lib/python2.7/site-packages/glanceclient/v2/images.py", line 448, in add_location response = self._send_image_update_request(image_id, add_patch) File "/usr/lib/python2.7/site-packages/glanceclient/common/utils.py", line 598, in inner return RequestIdProxy(wrapped(*args, **kwargs)) File "/usr/lib/python2.7/site-packages/glanceclient/v2/images.py", line 432, in _send_image_update_request data=json.dumps(patch_body)) File "/usr/lib/python2.7/site-packages/keystoneauth1/adapter.py", line 340, in patch return self.request(url, 'PATCH', **kwargs) File "/usr/lib/python2.7/site-packages/glanceclient/common/http.py", line 377, in request return self._handle_response(resp) File "/usr/lib/python2.7/site-packages/glanceclient/common/http.py", line 126, in _handle_response raise exc.from_response(resp, resp.content) HTTPBadRequest: 400 Bad Request: Invalid location (HTTP 400) 400 Bad Request: Invalid location (HTTP 400) As far as I can see with the "openstack" client there is not something to add/delete a location. So I guess it is necessary to change the 'direct_url' and 'locations' properties. If I try to change the direct_url property: # openstack image set --property direct_url='rbd://8162f291-00b6-4b40-a8b4-1981a8c09b64/images-prod/6bcc4eab-ed35-42dc-88bd-1d45de73b628/snap' 6bcc4eab-ed35-42dc-88bd-1d45de73b628 403 Forbidden: Attribute 'direct_url' is read-only. (HTTP 403) Any hints ? Thanks, Massimo [*] [default] ... enabled_backends = file:file,http:http,rbd:rbd show_image_direct_url = true show_multiple_locations = true [glance_store] default_backend = rbd [file] filesystem_store_datadir = /var/lib/glance/images/ [rbd] rbd_store_chunk_size = 8 rbd_store_ceph_conf = /etc/ceph/ceph.conf rbd_store_user = glance-prod rbd_store_pool = images-prod

1 0

[Tacker] No weekly meeting today.
by Dharmendra Kushwaha 27 Aug '19

27 Aug '19

Hi Team, I am not available for meeting today. So let's skip it or you can make it without my presence. Thanks & Regards Dharmendra Kushwaha ________________________________ The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or NECTI or its affiliates. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect the opinions of NECTI or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately.

1 0

答复: [nova] Specify availability_zone to unshelve
by Brin Zhang(张百林) 26 Aug '19

26 Aug '19

> Hi all, “Specify availability_zone to unshelve” in nova runway is active now, the ends date is 2019-08-29, > it’s active and ready to review, I hope to complete this patch before the deadline, please review > https://review.opendev.org/#/q/topic:bp/support-specifying-az-when-restore-… > > Thanks everyone. This patch already reviewed by Matt and gmann, and Alex many times. Brin

1 0

[nova] Specify availability_zone to unshelve
by Brin Zhang(张百林) 26 Aug '19

26 Aug '19

Hi all, “Specify availability_zone to unshelve” in nova runway is active now, the ends date is 2019-08-29, it’s active and ready to review, I hope to complete this patch before the deadline, please review. https://review.opendev.org/#/q/topic:bp/support-specifying-az-when-restore-… Thanks everyone. Brin

1 0

[ansible-sig] meetings!
by Mohammed Naser 26 Aug '19

26 Aug '19

Hi everyone, I'd like to schedule a meeting every week so we can discuss the details of what we can do together.. You'll find the link to the meeting and time slots available below. If you're interested in being involved, please go and select the day and time that would work best for you, this way we can find a time that works for everyone. Link: https://doodle.com/poll/6f9qdddk6icw92iq Looking forward to discussing with all of you! Regards, Mohammed -- Mohammed Naser — vexxhost ----------------------------------------------------- D. 514-316-8872 D. 800-910-1726 ext. 200 E. mnaser(a)vexxhost.com W. http://vexxhost.com

1 1

Shanghai PTG remote participation
by Miguel Lavalle 26 Aug '19

26 Aug '19

Hi, Some members of the Neutron team won't make it to Shanghai. They are interested, though, to participate remotely. Is the Foundation making any arrangements to facilitate this?. Or is each team on its own to address this requirement? Regards Miguel

2 1

[tc] weekly update
by Mohammed Naser 26 Aug '19

26 Aug '19

Hi everyone, Here’s the update for what happened in the OpenStack TC this week. You can get more information by checking for changes in openstack/governance repository. # New projects - ansible-role-uwsgi (under openstack-ansible-roles): https://review.opendev.org/#/c/676193/ # General changes - Updated list of extra-atcs for Train (I18n): https://review.opendev.org/#/c/674049/ - Update of goal selection retrospective (unowned goals in etherpad and owned goals in repository): https://review.opendev.org/#/c/667932/ Thanks for tuning in! Regards, Mohammed -- Mohammed Naser — vexxhost ----------------------------------------------------- D. 514-316-8872 D. 800-910-1726 ext. 200 E. mnaser(a)vexxhost.com W. http://vexxhost.com

1 0

[all][tc] A web tool which helps administrators in managing openstack clusters
by Douglas Zhang 26 Aug '19

26 Aug '19

Hello everyone, To help users interact with openstack, we’re currently developing a client-side web tool which enables administrators to manage their openstack cluster in a more efficient and convenient way. (Since we have not named it officially yet, I’m going to call it openstack-admin) *# Introduction* Some may ask, “Why do we need an extra web-based user interface since we have horizon?” Well, although horizon is a mature and powerful dashboard, it is far not efficient enough on big clusters (a simple list operation could take seconds to complete). What’s more, its flexibility of searching could not match our requirements. To overcome obstacles above, a more efficient tool is urgently required, that’s why we started to develop openstack-admin. *# Highlights* Comparing with the current user interface, openstack-admin has following advantages: - *Fast*: openstack-admin gets data straightly from SQL databases instead of calling standard openstack API, which accelerates the querying period to a large extent (especially when we’re dealing with a large amount of data). - *Flexible*: openstack-admin supports the fuzzy search for any important field(e.g. display_name/uuid/ip_address/project_name of an instance), which enables users to locate a particular object in no time. - *User-friendly*: the backend of openstack-admin gets necessary messages from the message queue used by nova, and send them to the frontend using websocket. This way, not only more realistic progress bars could be implemented, but more detailed information could be provided to users as well. *# Issues* To make this tool more efficient and provide better support for concurrency, we chose Golang to implement openstack-admin. As I’ve asked before (truly appreciate advises from Jeremy and Ghanshyam), a project written by an unofficial language may be accepted only if existing languages have been proven to not meet the technical requirements, so we’re considering re-implementing openstack-admin using python if we can’t come to an agreement on the language issue. So that’s all. How do you guys think of this project? Thanks, Douglas Zhang

10 9

[horizon] No meeting this week
by Ivan Kolodyazhny 26 Aug '19

26 Aug '19

Hi team, As mentioned during the last meeting, I can't chair the meeting this week. Let's skip it or you can make it without my presence. Regards, Ivan Kolodyazhny, http://blog.e0ne.info/

1 0

[uc]The UC Special Election Nomination Period is now open!
by Ed Leafe 26 Aug '19

26 Aug '19

The recent election for the two open seats on the User Committee had only one nomination, so one seat remains open. The UC decided to hold a second, special election to fill that seat. The nomination period for this special election is now open, and will remain open until August 30 at 05:59 UTC. If there is more than one candidate, the voting period will begin September 1 at 11:59 UTC, and close on September 4 at 11:59 UTC. Any individual member of the Foundation who is an Active User Contributor (AUC) can propose their candidacy (except the 4 sitting UC members). Self-nomination is common; no third party nomination is required. They do so by sending an email to the user-committee(a)lists.openstack.orgmailing-list, with the subject: “UC candidacy” by August 30, 05:59 UTC. Please note that you must be a subscriber to the user-committee list for your nomination to be posted. Subscribing is free, and can be done on this page [0]. The email can include a description of the candidate platform. The candidacy is then confirmed by one of the election officials, after verification of the electorate status of the candidate. [0] http://lists.openstack.org/cgi-bin/mailman/listinfo/user-committee -- Ed Leafe

1 0

[Telemetry][PTL]Lingxian Kong & Zhu Rong as co-PTLs for U release
by Trinh Nguyen 26 Aug '19

26 Aug '19

Hi team, As the PTL election period is coming up. I would like to discuss the PTL role for Telemetry in the U cycle. As I changed job recently, I don't think I have enough time budget for the 2 projects (Searchlight and Telemetry) so I talked to Lingxinan Kong (lxkong) and Zhu Rong (zhurong) and they agreed to share the responsibility as co-PTLs for Telemetry for next release. lxkong and zhurong has been very actively contributing to Telemetry in Train and being very helpful as core-reviewers. So I would like to endorse and nominate the two as co-PTLs for Telemetry for the U release. Though I will not be the PTL for Telemetry in the next cycle, I will still be around helping when needed. The next step for lxkong and zhurong is submitting a patchset nominating for the PTLs. Bests, -- *Trinh Nguyen* *www.edlab.xyz <https://www.edlab.xyz>*

2 2

[nova][glance][cinder] How to do consistent snapshots with quemu-guest-agent
by Teckelmann, Ralf, NMU-OIP 26 Aug '19

26 Aug '19

Hello, Working me through documentation and articles I am totally lost on the matter. All I want to know is: - if issueing "openstack snapshot create ...." - if klicking "create Snaphost" in Horizon for an instance will secure a consistent snapshot (of all volumes in question). With "consistent", I mean that all the data in memory are written to the disc before starting a snapshot. I hope someone can clear up, if using the setup described in the following is sufficient to achieve this goal or if I have to do something in addition. If you have any question I am eager to answer as fast as possible. Setup: We have a Stein-based OpenStack deployment with cinder backed by ceph. Instances are created with cinder volumes. Boot volumes are based on an image having the properties: - hw_qemu_guest_agent='yes' - os_require_quiesce='yes' The image is ubuntu 16.04 or 18.04 with quemu-guest-agent package installed and service running (no additional configuration besides distro-default): qemu-guest-agent.service - LSB: QEMU Guest Agent startup script Loaded: loaded (/etc/init.d/qemu-guest-agent; bad; vendor preset: enabled) Active: active (running) since Wed 2019-08-14 07:42:21 UTC; 9min ago Docs: man:systemd-sysv-generator(8) CGroup: /system.slice/qemu-guest-agent.service └─2300 /usr/sbin/qemu-ga --daemonize -m virtio-serial -p /dev/virtio-ports/org.qemu.guest_agent.0 Aug 14 07:42:21 ulthwe systemd[1]: Starting LSB: QEMU Guest Agent startup script... Aug 14 07:42:21 ulthwe systemd[1]: Started LSB: QEMU Guest Agent startup script. I can see the socket on the compute node and send pings successfully: ~# ls /var/lib/libvirt/qemu/*.sock /var/lib/libvirt/qemu/org.qemu.guest_agent.0.instance-0000248e.sock root@pcevh2404:~# virsh qemu-agent-command instance-0000248e '{"execute":"guest-ping"}' {"return":{}} I can also send freeze and thaw successfully: ~# virsh qemu-agent-command instance-0000248e '{"execute":"guest-fsfreeze-freeze"}' {"return":1} ~# virsh qemu-agent-command instance-0000248e '{"execute":"guest-fsfreeze-thaw"}' {"return":1} Sending a simple write (echo "bla" > blub.file) in the "frozen" state will be blocked until "thaw" as expected. Best regards Ralf T.

2 3

[tc] Release naming process
by corvus＠inaugust.com 25 Aug '19

25 Aug '19

Hi, In the previous thread about the U release name, we discussed how the actual process for selecting the name has diverged from the written process. I think it's important that we follow our own processes, so we should reconcile those. We should change our actions or change the process. Based on the previous discussion, I've proposed 6 changes to openstack/governance for some initial feedback. We can, of course, tweak these options, eliminate them, or add new ones. Ultimately, we're aiming for the TC to formally vote on one or a small number of changes similar to these. I'd like for anyone interested in this to review these options and leave feedback on the changes themselves, or here on the mailing list. Either is fine, and all will be considered. Leaving "code-review" votes on the changes themselves will help us gauge relative support for the different options. In a week, I'll collect the feedback and propose a next step. https://review.opendev.org/675788 - Stop naming releases https://review.opendev.org/677745 - Name releases after major cities https://review.opendev.org/677746 - Name releases after the ICAO alphabet https://review.opendev.org/677747 - Ask the Foundation to name releases https://review.opendev.org/677748 - Name releases after random words https://review.opendev.org/677749 - Clarify the existing release naming process The last one is worth particular mention -- it keeps the current process with some minor clarifications. -Jim

6 6

[ops] technical agenda for upcoming ops meetup, NYC
by Chris Morgan 25 Aug '19

25 Aug '19

We are still looking for topics and topic feebdack for the ops meetup. The planning sheet is here https://etherpad.openstack.org/p/NYC19-OPS-MEETUP Please if you are coming +1 topics you like or add more. More detail on this such as links and descriptions of the sessions we've already planned is tweeted on the ops meetups notification twitter account : https://twitter.com/osopsmeetup Chris -- Chris Morgan <mihalis68(a)gmail.com>

1 0

[all] PTG Attendance
by Kendall Nelson 25 Aug '19

25 Aug '19

Hello Everyone! This is the list of groups that are plannning on attending the PTG. Thank you PTLs/Chairs/Leads that responded on time :) I hesitate to say it's the 'final' list since I had a few groups respond with a 'Maybe', but it's probably pretty close. Please also note that the tentative activities at the PTG vary by group. Some groups are planning on only doing onboarding for example. Without further ado, here is the list! Airship Auto-Scaling SIG Barbican Blazar CInder Cyborg Edge Computing Group Fenix First Contact SIG Gitea Glance Heat Horizon I18n Ironic K8s SIG Karbor Kata Containers Keystone Loci Manila Meta SIG Monasca Neutron Nova Octavia OpenStack Charms OpenStack Infra / OpenDev OpenStack TC Openstack-helm OpenStack Operators (Ops Docs SIG and Meetup group) Oslo Public Cloud SIG Quality Assurance Release Management Scientific SIG Self-healing SIG Storlets StoryBoard Swift Tacker StarlingX If your team is missing from the list, please let me know ASAP as we are starting to put together a draft schedule. -Kendall Nelson(diablo_rojo)

2 3

[ansible] 2.9 feature freeze is on 2019-08-29
by Sorin Sbarnea 25 Aug '19

25 Aug '19

I just wanted to note for those using Ansible that the feature freeze is in 2019-08-29 which means that if you have any changes you want to make, that's the last date when you will be able to merge them. After this date there will be only be bugfixes and the Ansible team policy is very strict about what counts as a feature. For example not passing some arguments counts as new feature, not a bug fix. https://docs.ansible.com/ansible/latest/roadmap/ROADMAP_2_9.html I wanted to highlight this because recently I wanted to add support for etc_hosts on docker_image (build) (it was only on docker_container / run) and the change got merged into 2.8 but backporting the fix was denied as it counted as new feature. If you are aware about other similar changes that do affect openstack, lets try to make them happen now, or we will be delayed 4 months for sure. Thanks Sorin Sbarnea

1 0

[goals][IPv6-Only Deployments and Testing] Week R-8 Update
by Ghanshyam Mann 25 Aug '19

25 Aug '19

Hello Everyone, Below is the progress on Ipv6 goal during R8 week. I have finished with the project having zuulv3 jobs. The projects having zuulv2 jobs will be my next take (I have not explored the difficulties/complexity yet). Summary: * Number of Ipv6 jobs proposed Projects: 28 * Number of pass projects: 17 ** Number of project merged out of pass project: 11 * Number of failing projects: 11 Storyboard: ========= - https://storyboard.openstack.org/#!/story/2005477 Current status: ============ 1. Cinder fix is merged[1], Thanks Gorka. We need to merge the devstack patch now. 2. Configuring the tempest test regex to run only smoke tests which can be extended to include future IPv6 tests also. Running all test is not actually required as such in IPv6 job but if any project wants to run all then also fine. Example: [1] 3. Murano, zun, solumn, cloudkitty are merged. 4. Murano default dns is also on IPv6 env. 5. For Monasca, kafka was not working for IPv6 but witek is upgrading the Kafka version in Monasca. I will rebase IPv6 job patch on top of that and check the result. 6. This week new projects ipv6 jobs patch and status: - Zun: link: https://review.opendev.org/#/c/677496/ status: job is passed with few devstack plugin fixes and patch is merged. - Searchlight: links: https://review.opendev.org/#/c/678391/ status: There are no integration tests in searchlight as of now so after talking to Trinh (PTL), I am just adding a no-test job to verify that searchlight can be deployed on IPv6 or not. Later when we will have tests then those can be added in this job. IPv6 missing support found: ===================== 1. https://review.opendev.org/#/c/673397/ 2. https://review.opendev.org/#/c/673449/ 3. https://review.opendev.org/#/c/677524/ How you can help: ============== - Each project needs to look for and review the ipv6 job patch. - Verify it works fine on ipv6 and no ipv4 used in conf etc - Any other specific scenario needs to be added as part of project IPv6 verification. - Help on debugging and fix the bug in IPv6 job is failing. Everything related to this goal can be found under this topic: Topic: https://review.opendev.org/#/q/topic:ipv6-only-deployment-and-testing+(stat… How to define and run new IPv6 Job on project side: ======================================= - I prepared a wiki page to describe this section - https://wiki.openstack.org/wiki/Goal-IPv6-only-deployments-and-testing Review suggestion: ============== - Main goal of these jobs will be whether your service is able to listen on IPv6 and can communicate to any other services either OpenStack or DB or rabbitmq etc on IPv6 or not. So check your proposed job with that point of view. If anything missing, comment on patch. - One example was - I missed to configure novnc address to IPv6- https://review.opendev.org/#/c/672493/ - base script as part of 'devstack-tempest-ipv6' will do basic checks for endpoints on IPv6 and some devstack var setting. But if your project needs more specific verification then it can be added in project side job as post-run playbooks as described in wiki page[3]. [1] https://review.opendev.org/#/c/677524/ [1] https://zuul.opendev.org/t/openstack/build/5b7b823d6faa4f5393b4c46d36e15d80… [2] https://review.opendev.org/#/c/676857/ [3] https://review.opendev.org/#/c/676900/ [4] https://wiki.openstack.org/wiki/Goal-IPv6-only-deployments-and-testing -gmann

1 0

[nova] critical bug around reload/upgrades
by Mohammed Naser 23 Aug '19

23 Aug '19

Hello: I've discussed this for quite sometime with Dan over IRC and a bit with Zane as well, but basically, Nova thinks that when it gets a reload (aka SIGHUP), nothing else has occurred. However, oslo.service actually calls stop(), reload() then start() again, which potentially kills all RPC. This has caused a pretty big issue in our gates and it also means that the whole idea behind 'reload nova-compute while upgrading to refresh info' concept is fundamentally broken. I tried to do some work on this here, however, I wasn't really able to get to the bottom of it. There seems to be a decision that needs to be taken in terms of .. do we change what reload() actually means in oslo_service (it actually is more like a restart, not a reload) or does Nova (and other projects) change their implementation in assuming what reload() does? https://review.openstack.org/#/c/641907/ This seems to have been floating around for a really long time, so I'd be happy to work with someone to find the fix (and we can totally test it inside OpenStack Ansible by reloading instead of restarting). Thanks! Mohammed -- Mohammed Naser — vexxhost ----------------------------------------------------- D. 514-316-8872 D. 800-910-1726 ext. 200 E. mnaser(a)vexxhost.com W. http://vexxhost.com

4 4

[keystone] Keystone Team Update - Week of 19 August 2019
by Colleen Murphy 23 Aug '19

23 Aug '19

# Keystone Team Update - Week of 19 August 2019 ## News ### Development focus Feature freeze as well as a number of other deadlines are fast approaching. The development focus for the next three weeks should be: * reviews for changes implementing specs: - app cred access rules[1] - resource options for all resources[2] - immutable resources[3] - renewable group membership[4] * finish implementing and reviewing remaining system-scope[5]/default roles[6] migrations (deadline is feature freeze, Sept 9-13) * reviews for keystonemiddleware and keystoneauth[7] (final release Sept 2-6) * reviews for python-keystoneclient[8] (final release Sept 9-13) * helping the requirements team with any requirements issues[9] before requirements freeze (Sept 9-13) * completing community goals (follow the PDF generation news[10]) Additionally, we're still facing issues with instability of our unit test jobs. Improving the efficiency of our unit tests in order to avoid frequent timeouts would go a long way to helping avoid the feature freeze gate crunch. [1] https://review.opendev.org/#/q/is:open+topic:bp/whitelist-extension-for-app… [2] https://review.opendev.org/678322 [3] https://review.opendev.org/#/q/is:open+topic:immutable-resources [4] https://review.opendev.org/677469 [5] https://bugs.launchpad.net/keystone/+bugs?field.tag=system-scope [6] https://bugs.launchpad.net/keystone/+bugs?field.tag=default-roles [7] https://review.opendev.org/#/q/is:open+(project:openstack/keystoneauth+OR+p… [8] https://review.opendev.org/#/q/is:open+project:openstack/python-keystonecli… [9] https://bugs.launchpad.net/keystone/+bug/1839393 [10] http://lists.openstack.org/pipermail/openstack-discuss/2019-August/008506.h… ### keystoneauth session retries The heat team reported an issue in keystoneauth[11] where the way in which heat currently uses keystoneauth sessions is unable to take advantage of the request retry logic that is currently exposed only in the adapter. The proposal to fix the issue[12] exposes one of the retry options (connect_retries) in the session object. We've been in discussions on the bug report, on the patch, and in IRC[13][14] about whether this is the best approach and whether it would be better to change the way heat uses keystoneauth (would require a massive rewrite) or to expose the request retry options on the auth plugin in order to localize it to keystone requests (but that's an awkward home for it too). We've also been in disagreement about whether this change constitutes a feature or a bugfix with regards to backportability. [11] https://bugs.launchpad.net/keystoneauth/+bug/1840235 [12] https://review.opendev.org/676648 [13] http://eavesdrop.openstack.org/irclogs/%23openstack-sdks/%23openstack-sdks.… [14] http://eavesdrop.openstack.org/irclogs/%23openstack-keystone/%23openstack-k… ## Action Items * Vishakha to look into oauthlib requirements issue[15] * Kristi to propose spec to backlog about merging federation and identity backends [16] https://bugs.launchpad.net/keystone/+bug/1839393 ## Office Hours When there are topics to cover, the keystone team holds office hours on Tuesdays at 17:00 UTC. There will be no office hours this week or next week. Add topics you would like to see covered during office hours to the etherpad: https://etherpad.openstack.org/p/keystone-office-hours-topics ## Open Specs Train specs: https://bit.ly/2uZ2tRl Ongoing specs: https://bit.ly/2OyDLTh ## Recently Merged Changes Search query: https://bit.ly/2pquOwT We merged 13 changes this week, including changes to implement system scope for the endpoint groups API. ## Changes that need Attention Search query: https://bit.ly/2tymTje There are 68 changes that are passing CI, not in merge conflict, have no negative reviews and aren't proposed by bots. ### Priority Reviews * Train Roadmap Stories - System scope/default roles (https://trello.com/c/ERo50T7r , https://trello.com/c/RlYyb4DU) + https://review.opendev.org/#/q/status:open+topic:implement-default-roles+la… + https://review.opendev.org/#/q/status:open+topic:trust-policies + https://review.opendev.org/#/q/topic:bug/1805409 - Federated attributes for users (https://trello.com/c/dEmSumDQ) + https://review.opendev.org/#/q/status:open+topic:bp/support-federated-attr - Application credential access rules (https://trello.com/c/dJsWMI4W) + https://review.opendev.org/#/q/status:open+topic:bp/whitelist-extension-for… - Immutable resources (https://trello.com/c/clIb4qMq) + https://review.opendev.org/#/q/topic:immutable-resources - Resource options for all (https://trello.com/c/8ML6kvig) + https://review.opendev.org/678322 * Needs Discussion - Allow initializing session with connection retries https://review.opendev.org/676648 * Oldest - OpenID Connect improved support (spec) https://review.opendev.org/373983 * Closes bugs - Cleanup session on delete https://review.opendev.org/674139 ## Bugs This week we opened 1 new bugs and closed 2. Bugs opened (1) Bug #1840647 (keystone:Undecided) opened by Nikita Kalyanov https://bugs.launchpad.net/keystone/+bug/1840647 ) Bugs fixed (2) Bug #1840291 (keystone:Medium) fixed by Rabi Mishra https://bugs.launchpad.net/keystone/+bug/1840291 Bug #1818734 (keystone:Low) fixed by Colleen Murphy https://bugs.launchpad.net/keystone/+bug/1818734 ## Milestone Outlook https://releases.openstack.org/train/schedule.html Final release for non-client libraries (keystoneauth, keystonemiddleware) is in two weeks. Feature freeze and final client release is in three weeks. ## Help with this newsletter Help contribute to this newsletter by editing the etherpad: https://etherpad.openstack.org/p/keystone-team-newsletter

1 0

[goal][python3] Train unit tests weekly update (goal-3)
by Corey Bryant 23 Aug '19

23 Aug '19

This is the goal-3 weekly update for the "Update Python 3 test runtimes for Train" goal [1]. There are 3 weeks remaining for completion of Train community goals [2]. == How can you help? == If your project has failing tests please take a look and help fix. Python 3.7 unit tests will be self-testing in Zuul. Failing patches: https://review.openstack.org/#/q/topic:python3-train +status:open+(+label:Verified-1+OR+label:Verified-2+) If your project has patches with successful tests please help get them merged. Open patches needing reviews: https://review.openstack.org/#/q/topic:python3 -train+is:open Patch automation scripts needing review: https://review.opendev.org/#/c/666934 == Ongoing Work == Thank you to all who have contributed their time and fixes to enable patches to land. We're down to 15 projects with failing tests. == Completed Work == All patches have been submitted to all applicable projects for this goal. Merged patches: https://review.openstack.org/#/q/topic:python3-train +is:merged == What's the Goal? == To ensure (in the Train cycle) that all official OpenStack repositories with Python 3 unit tests are exclusively using the 'openstack-python3-train-jobs' Zuul template or one of its variants (e.g. 'openstack-python3-train-jobs-neutron') to run unit tests, and that tests are passing. This will ensure that all official projects are running py36 and py37 unit tests in Train. For complete details please see [1]. == Reference Material == [1] Goal description: https://governance.openstack.org/tc/goals/train/ python3-updates.html [2] Train release schedule: https://releases.openstack.org/train /schedule.html (see R-5 for "Train Community Goals Completed") Storyboard: https://storyboard.openstack.org/#!/story/2005924 Porting to Python 3.7: https://docs.python.org/3/whatsnew/3.7.html#porting-to-python-3-7 Python Update Process: https://opendev.org/openstack/governance/src/branch/master/resolutions/2018… Train runtimes: https://opendev.org/openstack/governance/src/branch/master/reference/runtim… train.rst Thanks,

1 0

[nova] The pros/cons for libvirt persistent assignment and DB persistent assignment.
by Alex Xu 23 Aug '19

23 Aug '19

We get a lot of discussion on how to do the claim for the vpmem. There are a few points we are trying to match: * Avoid race problem. (the current VGPU assignment has been found having race issue https://launchpad.net/bugs/1836204) * Avoid the device assignment management to be virt driver and platform-specific. * Keep it simple. Currently, we go through two solutions here. This email is going to summary the pros/cons of these two solutions. #1 Without Nova DB persistent for the assignment info, depends on hypervisor persistent it. The idea is adding VirtDriver.claim/unclaim_for_instance(instance_uuid, flavor_id) interface. The assignment info is populated from hypervisor when nova-compute startup. And keep in the memory of VirtDriver. The instance_uuid is used to distinguish the claim from the different instance. The flavor_id is used for the same host resize, to distinguish the claim for source and target. This virt driver method is being invoked inside ResourceTracker to avoid the race problem. There is no any nova DB persistent for the assignment info. https://review.opendev.org/#/q/status:open+project:openstack/nova+branch:ma… pros: * Hidden all the device detail and virt driver detail inside the virt driver. * Less upgrade issue in the future since it doesn't involve any nova DB model change * Expecting as simple implementation since everything inside virt driver. cons: * Two cases are being found, the domain XML being lost for Libvirt virt driver. And we don't know other hypervisor behavior yet. * For the same host resize, the source and target instance are sharing single one domain XML. After the libvirt virt driver updated the domain XML to the target instance, the source instance's assignment information will be lost when a nova-compute restart happened. That means the resized instance can't be revert, the only choice for the user is to confirm the resize. * For live migration, the target host's domain XML will be cleanup by libvirt after a host restart. The assignment information is lost before nova-compute startup and doing a cleanup. * Can not support the same host cold migration. Since we need a way to identify the source and target instance's assignment in memory. But the same host cold migration means the same instance UUID and same flavor ID, there isn't another else can be used to distinguish the assignment. * There are workarounds added for above points, the code becomes fragile. #2 With nova DB persistent, but using virt driver specific blob to store virt driver specific info. The idea is persistent the assignment for instance into DB. The resource tracker gets available resources from virt driver. The resource tracker will calculate on the fly based on available resources and assigned resources from instance DB. The new field ·instance.resources· is designed for supporting virt driver specific metadata, then hidden the virt driver and platform detail from RT. https://etherpad.openstack.org/p/vpmems-non-virt-driver-specific-new pros: * Persistent assignment into instance object. Avoid the corner case we lost the assignment. * The ResourceTracker is responsible for doing the claim job. This is more reliable and no race problem, since ResourceTracker works very well for a long time. * The virt driver specific json-blob hidden the virt driver/platform detail from the ResourceTracker. * The free resource is calculated on the fly, keeping the implementation simple. Actually, the RT just provides a point to do the claim, needn't involve the complex of RT.update_available_resources cons: * Doesn't like PCIManager which has both instance side and host side persistent info. On the fly calculation should take care of the orphaned instance(the instance is deleted from DB, but still existing on the host), so actually, it isn't unresolvable issue. And it isn't too hard to upgrade to have host side persistent info in the future if we want. * Data model change for the original proposal. Need review to decide the data model enough generic Currently, Sean, Eric and I prefer the #2 now since the #1 has flaws for the same host resize and live migration can't be skipped by design. Looking for more feedback, and will appreciate it! Thanks Alex

4 5

[openstack-helm] k8s endpoints disappear sometimes
by 김하건 23 Aug '19

23 Aug '19

1 0

[openstack-dev][magnum] Nominating brtknr for Magnum core
by Feilong Wang 23 Aug '19

23 Aug '19

Hi team, I would like to propose adding Bharat Kunwar(brtknr) for the Magnum core team. He has been an awesome contributor since joining the Magnum team. And now he is currently the most active non-core reviewer on Magnum projects for the last 180 days[1]. Bharat has great technical expertise and contributed many high quality patches/reviews. I'm sure he would be an excellent addition to the team. If no one objects, I'll proceed and add him in a week from now. Thanks. [1] https://www.stackalytics.com/report/contribution/magnum-group/180 -- Cheers & Best regards, Feilong Wang (王飞龙) -------------------------------------------------------------------------- Head of R&D Catalyst Cloud - Cloud Native New Zealand Tel: +64-48032246 Email: flwang(a)catalyst.net.nz Level 6, Catalyst House, 150 Willis Street, Wellington --------------------------------------------------------------------------

2 1

[all][elections] Combined PTL/TC Election Season
by Jeremy Stanley 22 Aug '19

22 Aug '19

Election details: https://governance.openstack.org/election/ The nomination period officially begins Aug 27, 2019 23:45 UTC. Please read the stipulations and timelines for candidates and electorate contained in this governance documentation. Due to circumstances of timing, PTL and TC elections for the coming cycle will run concurrently; deadlines for their nomination and voting activities are synchronized but will still use separate ballots. Please note, if only one candidate is nominated as PTL for a project team during the PTL nomination period, that candidate will win by acclaim, and there will be no poll. There will only be a poll if there is more than one candidate stepping forward for a project team's PTL position. There will be further announcements posted to the mailing list as action is required from the electorate or candidates. This email is for information purposes only. If you have any questions which you feel affect others please reply to this email thread. If you have any questions that you which to discuss in private please email any of the election officials[1] so that we may address your concerns. Thank you, [1] https://governance.openstack.org/election/#election-officials -- Jeremy Stanley, on behalf of the technical election officials

1 0

Nova causes MySQL timeouts
by Albert Braden 22 Aug '19

22 Aug '19

It looks like nova is keeping mysql connections open until they time out. Is there a way to stop these error messages? Aborted connection 10726 to db: 'nova' user: 'nova' host: 'asdf' (Got timeout reading communication packets)

1 0

[nova][ops] What should the compute service delete behavior be wrt resource providers with allocations?
by Matt Riedemann 22 Aug '19

22 Aug '19

Before [1] when deleting a compute service in the API we did not check to see if the compute service was hosting any instances and just blindly deleted the service and related compute_node(s) records which orphaned the resource provider(s) for those nodes. With [2] we built on that and would cleanup the (first [3]) compute node resource provider by first deleting any allocations for instances still on that host - which because of the check in [1] should be none - and then deleted the resource provider itself. [2] forgot about ironic where a single compute service can be managing multiple (hundreds or even thousands) of baremetal compute nodes so I wrote [3] to delete *all* resource providers for compute nodes tied to the service - again barring there being any instances running on the service because of the check added in [1]. What we've failed to realize until recently is that there are cases where deleting the resource provider can still fail because there are allocations we haven't cleaned up, namely: 1. Residual allocations for evacuated instances from a source host. 2. Allocations held by a migration record for an unconfirmed (or not yet complete) migration. Because the delete_resource_provider method isn't checking for those, we can get ResourceProviderInUse errors which are then ignored [4]. Since that error is ignored, we continue on to delete the compute service record [5], effectively orphaning the providers (which is what [2] was meant to fix). I have recreated the evacuate scenario in a functional test here [6]. The question is what should we do about the fix? I'm getting lost thinking about this in a vacuum so trying to get some others to help think about it. Clearly with [1] we said you shouldn't be able to delete a compute service that has instances on it because that corrupts our resource tracking system. If we extend that to any allocations held against providers for that compute service, then the fix might be as simple as not ignoring the ResourceProviderInUse error and fail if we can't delete the provider(s). The question I'm struggling with is what does an operator do for the two cases mentioned above, not-yet-complete migrations and evacuated instances? For migrations, that seems pretty simple - wait for the migration to complete and confirm it (reverting a cold migration or resize would put the instance back on the compute service host you're trying to delete). The nastier thing is the allocations tied to an evacuated instance since those don't get cleaned up until the compute service is restarted [7]. If the operator never intends on restarting that compute service and just wants to clear the data, then they have to manually delete the allocations for the resource providers associated with that host before they can delete the compute service, which kind of sucks. What are our options? 1. Don't delete the compute service if we can't cleanup all resource providers - make sure to not orphan any providers. Manual cleanup may be necessary by the operator. 2. Change delete_resource_provider cascade=True logic to remove all allocations for the provider before deleting it, i.e. for not-yet-complete migrations and evacuated instances. For the evacuated instance allocations this is likely OK since restarting the source compute service is going to do that cleanup anyway. Also, if you delete the source compute service during a migration, confirming or reverting the resize later will likely fail since we'd be casting to something that is gone (and we'd orphan those allocations). Maybe we need a functional recreate test for the unconfirmed migration scenario before deciding on this? 3. Other things I'm not thinking of? Should we add a force parameter to the API to allow the operator to forcefully delete (#2 above) if #1 fails? Force parameters are hacky and usually seem to cause more problems than they solve, but it does put the control in the operators hands. If we did remove allocations for an instance when deleting it's compute service host, the operator should be able to get them back by running the "nova-manage placement heal_allocations" CLI - assuming they restart the compute service on that host. This would have to be tested of course. Help me Obi-Wan Kenobi. You're my only hope. [1] https://review.opendev.org/#/q/I0bd63b655ad3d3d39af8d15c781ce0a45efc8e3a [2] https://review.opendev.org/#/q/I7b8622b178d5043ed1556d7bdceaf60f47e5ac80 [3] https://review.opendev.org/#/c/657016/ [4] https://github.com/openstack/nova/blob/cb0cfc90e1e03e82c42187ec60f46fb8fd59… [5] https://github.com/openstack/nova/blob/cb0cfc90e1e03e82c42187ec60f46fb8fd59… [6] https://review.opendev.org/#/c/663737/ [7] https://github.com/openstack/nova/blob/cb0cfc90e1e03e82c42187ec60f46fb8fd59… -- Thanks, Matt

6 16

[research][code-review][software-dev] Design Discussions During OpenStack Code Reviews
by farida el-zanaty 22 Aug '19

22 Aug '19

Hi! I am Farida El-Zanaty from McGill University. Under the supervision of Prof. Shane McIntosh, my research aims to study design discussions that occur between developers during code reviews. Last year, we published a study about the frequency and types of such discussions that occur in OpenStack Nova and Neutron (http://rebels.ece.mcgill.ca/papers/esem2018_elzanaty.pdf) We are reaching out to OpenStack developers to better understand their perspectives on design discussions during code reviews. Those who are interested can start by participating in our 10-minute survey about their experiences as both the code reviewer and author. Survey participants will be entered into a raffle for a $50 Amazon gift card. Survey: https://forms.gle/Hhn191f6cxF5hVgG8 Thanks for your time, Farida El-Zanaty

1 0

[openstack-dev] [neutron] Cancelling Neutron Drivers meeting on August 23rd
by Miguel Lavalle 22 Aug '19

22 Aug '19

Dear Neutrinos, 3 out of 5 members of the drivers team are off on vacation this week, so we won't have quorum for the meeting. As a consequence, I am cancelling it this week. We will resume next week. Best regards Miguel

1 0