| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-10-04 | |||
| 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 | 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:20:56 | stephenfin | Is this displaying oddly for anyone else? https://bugs.launchpad.net/nova/+bug/1846559 | |
| 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, | |
| 14:10:23 | mriedem | the api will GET that image 2550 times at least | |
| 14:10:28 | mriedem | since we're too dumb to cache the results | |
| 14:11:08 | mriedem | that's in _validate_bdm called from a for loop in _provision_instances | |
| 14:13:06 | dansmith | yeah, you're saying we do that today and nobody is complaining? | |
| 14:13:23 | dansmith | obviously less likely to run afoul of that with 255 BDMs vs. images to pre-cache | |
| 14:13:29 | dansmith | but same deal | |
| 14:13:47 | dansmith | actually, that all happens in the conductor right? | |
| 14:13:49 | dansmith | used to be in the api | |
| 14:14:12 | mriedem | no it's in the api | |
| 14:14:22 | mriedem | and yeah no one is complaining about that right now | |
| 14:14:23 | dansmith | okay | |
| 14:14:46 | mriedem | i remember the power boyz really wanting a couple hundred volumes attached per server | |
| 14:14:58 | mriedem | so do that + multicreate | |
| 14:15:42 | dansmith | yeah | |
| 14:18:58 | dansmith | mriedem: well, we have the new imagecache group, maybe we just chuck a configurable limit in there.. no real reason not to I guess | |
| 14:20:10 | mriedem | config-driven api is the only reason not to... | |
| 14:20:21 | dansmith | yup | |
| 14:20:24 | mriedem | which is why i was thinking of quota config etc | |
| 14:26:00 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Add boot from volume functional test with a huge request https://review.opendev.org/686734 | |
| 14:32:34 | openstackgerrit | Eric Fried proposed openstack/nova-specs master: Add 'Core Liaison' spec process https://review.opendev.org/685857 | |
| 14:33:27 | efried | updated to make dansmith his own liaison on his precaching spec, and took out the idioms gibi called me on ^ | |
| 14:33:49 | efried | also clarified self-liaison wording can just be "None" as bauzas suggested ^ | |
| 14:49:00 | efried | aspiers: update on SEV fix? | |
| 14:49:55 | stephenfin | mriedem: I'm reworking the NeutronFixture to mock out the security group-related APIs instead. It's going to be much larger but seems more correct | |
| 14:50:21 | efried | aspiers: I'm gonna say by... Tuesday we will merge the "document it's busted" patch if the fix isn't ready. | |
| 14:50:38 | efried | so that we can be sure it's through the gate by Thursday when we have to produce our final RC. | |
| 14:52:00 | mriedem | stephenfin: ugh....can we just do that in a follow up? | |
| 14:52:07 | mriedem | b/c that's going to slow things down quite a bit | |