| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-10-03 | |||
| 21:25:29 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Add prep_snapshot_based_resize_at_dest compute method https://review.opendev.org/633293 | |
| 21:25:29 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Add PrepResizeAtDestTask https://review.opendev.org/627890 | |
| 21:25:30 | openstackgerrit | Matt Riedemann proposed openstack/nova master: FUP for I66d8f06f19c5c631e33208580428aa843abb38d2 https://review.opendev.org/678951 | |
| 21:25:30 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Add prep_snapshot_based_resize_at_source compute method https://review.opendev.org/634832 | |
| 21:25:31 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Add PrepResizeAtSourceTask https://review.opendev.org/627891 | |
| 21:25:31 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Add finish_snapshot_based_resize_at_dest compute method https://review.opendev.org/635080 | |
| 21:25:32 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Add FinishResizeAtDestTask https://review.opendev.org/635646 | |
| 21:25:33 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Execute CrossCellMigrationTask from MigrationTask https://review.opendev.org/635668 | |
| 21:25:33 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Plumb allow_cross_cell_resize into compute API resize() https://review.opendev.org/635684 | |
| 21:25:34 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Filter duplicates from compute API get_migrations_sorted() https://review.opendev.org/636224 | |
| 21:25:34 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Start functional testing for cross-cell resize https://review.opendev.org/636253 | |
| 21:25:34 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Handle target host cross-cell cold migration in conductor https://review.opendev.org/642591 | |
| 21:25:35 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Validate image/create during cross-cell resize functional testing https://review.opendev.org/642592 | |
| 21:25:36 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Add zones wrinkle to TestMultiCellMigrate https://review.opendev.org/643450 | |
| 21:25:36 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Add negative test for cross-cell finish_resize failing https://review.opendev.org/643451 | |
| 21:25:37 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Refresh instance in MigrationTask.execute Exception handler https://review.opendev.org/669012 | |
| 21:27:22 | mriedem | gibi: stephenfin: i rebased the cross cell series ^ to move some of the FUPs that were outside the series back into the fold and toward the bottom. that might mean some things that were previously +2ed might have changed slightly but hopefully not much. | |
| 22:14:37 | openstackgerrit | Merged openstack/nova master: Add reserved schema migrations for Ussuri https://review.opendev.org/686411 | |
| 22:51:52 | openstackgerrit | Matt Riedemann proposed openstack/nova master: WIP: Migrate old style volume attachments on nova-compute startup https://review.opendev.org/549130 | |
| 23:51:45 | openstackgerrit | Merged openstack/nova master: nova-net: Migrate 'test_availability_zone' functional tests https://review.opendev.org/684332 | |
| #openstack-nova - 2019-10-04 | |||
| 00:28:04 | openstackgerrit | Jing Zhang proposed openstack/nova master: [WIP] Default mem_page_size to small for pinned instances https://review.opendev.org/686079 | |
| 00:36:53 | SonPham | Hi. Any way to create live-snapshot with keep process | |
| 01:13:24 | openstackgerrit | Takashi NATSUME proposed openstack/python-novaclient master: Remove cells v1 and extension commands and APIs https://review.opendev.org/686516 | |
| 02:47:12 | openstackgerrit | Takashi NATSUME proposed openstack/nova master: api-ref: Fix security groups parameters https://review.opendev.org/686517 | |
| 03:56:26 | openstackgerrit | Takashi NATSUME proposed openstack/nova master: api-guide: Fix available info in handling down cells https://review.opendev.org/686520 | |
| 07:11:15 | bauzas | good morning Nova | |
| 07:25:34 | gibi | bauzas: good morning! | |
| 10:14:57 | openstackgerrit | Merged openstack/nova master: nova-net: Migrate 'test_floating_ip_pools' functional tests https://review.opendev.org/684333 | |
| 10:16:12 | openstackgerrit | Stephen Finucane proposed openstack/nova master: nova-net: Migrate 'test_quota_sets' functional tests https://review.opendev.org/684334 | |
| 10:20:56 | stephenfin | Is this displaying oddly for anyone else? https://bugs.launchpad.net/nova/+bug/1846559 | |
| 10:20:56 | openstack | Launchpad bug 1846559 in OpenStack Compute (nova) "Handling Down Cells in nova - security_groups can be in the response for GET /servers/detail" [Medium,In progress] - Assigned to Takashi NATSUME (natsume-takashi) | |
| 10:27:11 | kashyap | stephenfin: Yeah, it is odd | |
| 10:29:09 | kashyap | stephenfin: Not just that, but also blueprints are displayed oddly, too | |
| 10:32:31 | kashyap | sean-k-mooney: To check if a guest is using multiqueues looking for 'queues' / 'vhost' bits in the XML should suffice I guess? | |
| 10:37:16 | kashyap | I'd say so | |
| 12:02:26 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Remove @safe_connect from put_allocations https://review.opendev.org/686579 | |
| 13:26:25 | mriedem | stephenfin: i'm not sure what gmann wants to see happen here but i left some thoughts in the commit message https://review.opendev.org/#/c/685927/ | |
| 13:35:11 | mriedem | takashin already posted fixes for the 2 docs bugs | |
| 13:43:04 | mriedem | gibi: efried: dansmith: shall i send this along or are we waiting for updates? https://review.opendev.org/#/c/686232/ | |
| 13:43:16 | mriedem | looks like sean-k-mooney is +1 so i think i can put it to bed | |
| 13:43:31 | mriedem | or do we have a new rule about a majority of specs cores being on board with it? | |
| 13:44:08 | efried | no such rule yet, no. If we merge it I'll have to update the core liaisons patch to add that template section for this one. but go aheda. | |
| 13:44:10 | efried | ahead. | |
| 13:44:56 | dansmith | mriedem: yep, cool with me | |
| 13:47:05 | mriedem | ok, replied about the validation before the 202 response but approved anyway | |
| 13:47:54 | mriedem | i don't know if i can change the blueprint "Direction" field to "Approved" | |
| 13:47:59 | mriedem | but i updated the Definition | |
| 13:48:31 | mriedem | i'm gonna say this is med/high priority though given the amount of previous attempts to try and get a similar thing done | |
| 13:51:26 | efried | mriedem: yes, let's hold off on "Direction" for now, pending validation of this bit https://review.opendev.org/#/c/685857/4/README.rst@44 | |
| 13:51:53 | dansmith | mriedem: you're worried about them providing a hundred images and us taking too long to ask glance about all of them? | |
| 13:55:50 | mriedem | dansmith: yeah | |
| 13:56:20 | dansmith | mriedem: do we have anything similar in some of our proxy apis? I mean I know we contact neutron a bunch for like instance detail list | |
| 13:56:56 | dansmith | mriedem: would it be too crazy to define in the api-ref that "if you specify more images than some threshold, the images may be validated asynchronously" ? | |
| 13:56:57 | mriedem | i'll say i'm not terribly worried since it's an admin api by default | |
| 13:57:23 | mriedem | so based on some config limit you punt the validation to conductor? | |
| 13:57:34 | dansmith | or not config, just some hard limit we set in the code like 5 | |
| 13:58:09 | mriedem | i think for v1 we can just validate in the api and ignore my fears | |
| 13:58:14 | dansmith | or we could be totally crazy and measure how long it takes to do the first one and then decide what the limit should be, assuming a 60s timeout or something :D | |
| 13:58:29 | dansmith | we could also just state in the API that it's max 5 per request or something | |
| 13:59:19 | mriedem | if we did that i think i'd add a new quota item like metadata_items or injected_files which are there for the same reason i think | |
| 13:59:49 | dansmith | that'd be kindof an odd use of quota | |
| 14:00:12 | mriedem | that's what those quotas are used for though right? rate limiting | |
| 14:00:16 | mriedem | same with instances quota | |
| 14:00:33 | dansmith | metadata_items? isn't that actual storage in the db? | |
| 14:00:46 | openstackgerrit | Merged openstack/nova-specs master: Add image-precache-support spec https://review.opendev.org/686232 | |
| 14:01:00 | mriedem | user metadata is just a foreign key pair in another table so i'm not sure why that would matter | |
| 14:01:09 | mriedem | i mean, | |
| 14:01:23 | mriedem | sure you don't want someone blasting 1K metadata keys per instance since that will likely slow queries down | |
| 14:01:27 | dansmith | because a billion metadata items cost actual space | |
| 14:01:33 | dansmith | seems different to me | |
| 14:01:34 | dansmith | anyway | |
| 14:01:41 | dansmith | we can haggle in the api patch | |
| 14:01:56 | mriedem | i know injected_files isn't in the db | |
| 14:01:59 | dansmith | at least a note in the ref about "if you specify a hundred things here, you'll likely timeout before we've asked glance about all of them" | |
| 14:02:24 | dansmith | no, but it is still resource-related | |
| 14:03:03 | mriedem | i probably wouldn't even mention anything in the ref unless/until someone reports it as a problem | |
| 14:03:14 | mriedem | so like i said, i'm not terribly worried about it | |
| 14:03:22 | mriedem | especially since it's admin-only by default | |
| 14:03:41 | mriedem | and yeah when you're admin listing 1K all_tenants instances we're going to ask neutron for the combined set of ports and security groups for all of them | |
| 14:03:53 | dansmith | I don't see what a note would hurt, given not everyone would piece together what is happening where, but... whatever, we can talk about it in the patch | |
| 14:04:26 | mriedem | i just have no idea what the limits would be, so wouldn't want to say "you'll likely timeout" | |
| 14:04:51 | dansmith | sure, it'd just be a warning about "too many" | |
| 14:05:10 | dansmith | whatever, I'll stop trying to address your concerns :) | |
| 14:05:12 | mriedem | "Since the number of images to cache is not rate limited use caution when sending a large set of images." | |
| 14:05:13 | mriedem | something like that | |
| 14:05:36 | mriedem | anyway | |
| 14:05:52 | dansmith | or I could push validation to the conductor | |
| 14:06:21 | mriedem | failing fast in the API is nice though... | |
| 14:06:23 | mriedem | for this kind of thing | |
| 14:06:30 | dansmith | so basically, | |
| 14:06:40 | dansmith | you will not be pleased with any outcome, is that right mr. midwest? | |
| 14:06:50 | mriedem | that's my general stance with anything in my life yes | |
| 14:06:56 | dansmith | right, got it :) | |
| 14:07:38 | mriedem | laura was all riled up about this impeachment stuff last night and i had to remind her to keep expectations very low and assume the worst in whatever outcome she wants - like i do! | |
| 14:07:40 | mriedem | it's very healthy | |
| 14:07:51 | dansmith | heh | |
| 14:09:12 | mriedem | so here is a thing to compare to in the api, | |
| 14:09:25 | mriedem | during server create i don't think we limit the number of bdms you can specify, | |
| 14:09:44 | mriedem | you can't include the same pre-existing volume more than once since we don't support multiattach that way, | |
| 14:10:04 | mriedem | but you could say, boot me 10 servers with 255 bdms each and they are all using the same image for the volume's disk, | |