| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-04-28 | |||
| 12:34:50 | gibi | multi create with neutron net is supported without bandwidth | |
| 12:35:00 | bauzas | ack ok | |
| 12:35:33 | bauzas | fwiw, multi-create works with vGPUs if one RP has all the capacity for all the instances | |
| 12:35:49 | brinzhang_ | bauzas, gibi: I am now confused (dazzled) ^^ | |
| 12:36:02 | bauzas | and I guess it's the same for cyborg resources | |
| 12:36:47 | gibi | brinzhang_, bauzas: I have to jump on a call, sorry. I will read back later | |
| 12:36:52 | brinzhang_ | bauzas: you mean change "Add" to "All"? | |
| 12:38:09 | brinzhang_ | bauzas: if possiable, you can edit that patch, or you can leave comments inline, I have to go home now, it's too later for me, I am sorry | |
| 12:38:47 | brinzhang_ | gibi, bauzas: thanks ^^ | |
| 12:40:54 | openstack | Launchpad bug 1874664 in OpenStack Compute (nova) "Instance multi-create doesn't support available resources spread between children RPs" [Medium,Confirmed] - Assigned to Wenping Song (wenping1) | |
| 12:40:54 | bauzas | brinzhang: see the bug description modification https://bugs.launchpad.net/nova/+bug/1874664 | |
| 12:47:14 | brinzhang_ | bauzas: I think that use you write in bug description in my patch | |
| 12:47:20 | brinzhang_ | it looks better | |
| 12:47:30 | brinzhang_ | an easy to understand | |
| 12:47:36 | brinzhang_ | s/an/and | |
| 13:01:01 | AJaeger | The nova ussuri translations are at https://review.opendev.org/723160, any stable nova core to import them, please? | |
| 13:02:46 | nightmare_unreal | can someone review this : https://review.opendev.org/#/c/715395/ Thanks | |
| 13:18:12 | elod | AJaeger: about https://review.opendev.org/723160 : if I understand correctly it is safe to merge now and don't really need any extra review. Am I right? | |
| 13:20:05 | AJaeger | elod: it's safe to merge now and most projects have single core review. | |
| 13:20:15 | AJaeger | elod: let me grab you a link for the safe... | |
| 13:21:28 | AJaeger | elod: http://lists.openstack.org/pipermail/openstack-discuss/2020-April/014437.html has "For projects with translations, watch for any translation patches coming through and merge them quickly" | |
| 13:21:57 | elod | AJaeger: thanks! reading | |
| 13:23:41 | elod | ohh, the release countdown mail, i see, thanks | |
| 13:23:52 | AJaeger | yep, that one | |
| 13:24:55 | elod | AJaeger: approved | |
| 13:30:36 | artom | stephenfin, any chance I could get you to revisit https://review.opendev.org/#/c/687404/20 ? | |
| 13:41:12 | AJaeger | thanks, elod | |
| 13:43:23 | openstackgerrit | Marcin Juszkiewicz proposed openstack/nova stable/train: Add default cpu model for AArch64 https://review.opendev.org/723900 | |
| 13:48:23 | elod | well, thanks for calling my attention to that patch. I've already had a look at it, but saw that zuul was in bad shape so waited for zuul to get back to normal | |
| 13:53:19 | stephenfin | artom: sure | |
| 14:04:49 | kashyap | s/fatique/fatigue/ | |
| 14:17:33 | artom | stephenfin, thanks :) | |
| 14:21:05 | gmann | gibi: thanks, i added comment. i think changing 'oslopolicy-sample-generator' depends how we change it, say adding deprecated rules by default or based on request. because there might be operator who are using this tool for no-deprecated-rules usage | |
| 14:22:18 | gmann | which was the only way to move to new defaults and stop old token to pass via deprecated rule until we introduced new flag in oslo.policy 'oslo_policy.enforce_new_defaults' | |
| 14:22:21 | stephenfin | dansmith: Now that we've branched, could you take a look at https://review.opendev.org/#/c/537414/ and https://review.opendev.org/#/c/530905/ again? | |
| 14:23:12 | gmann | may be bnemec and stephenfin can input how we can accommodate both use case of 'oslopolicy-sample-generator' here. | |
| 14:23:39 | gmann | i mean adding deprecated based on request can be done but if it solve the zigo case. | |
| 14:23:43 | dansmith | stephenfin: ack | |
| 14:23:49 | stephenfin | dansmith: ta | |
| 14:23:57 | dansmith | gmann: I thought it was said that the generator wasn't going to get that new mode | |
| 14:24:00 | dansmith | or at least, not in time | |
| 14:25:17 | gmann | dansmith: yeah that was my understanding but gibi opinion is to do that if we can. | |
| 14:25:28 | bnemec | I'm not a big fan of adding a feature to support an anti-pattern in deploying OpenStack. | |
| 14:26:03 | stephenfin | Could we just handwrite a policy.json file and include it in our sdist for this release? | |
| 14:26:17 | dansmith | gmann: the problem I see is that the oslo tool will not do that by default, but our default in nova is to need the deprecated rules, | |
| 14:26:25 | stephenfin | zigo could consume that instead of using the oslopolicy tool | |
| 14:26:29 | gmann | we have to carefully things of way for operator to move to new defaults was only overwrite the rule in policy file which is this case we taken as broken | |
| 14:26:34 | dansmith | so we're requiring a lot of people to know to disable one default and override another, to get a consistent set of defaults that will work | |
| 14:27:06 | artom | stephenfin, thanks :) | |
| 14:27:08 | gmann | exactly | |
| 14:27:16 | artom | dansmith, https://review.opendev.org/#/c/672595/73 pretty please? When your queue gets to it | |
| 14:27:35 | dansmith | stephenfin: I think that's more obscure for people that aren't already looking for a sample file, but maybe easier to get themselves out of the hole once they realize they've deployed and screwed themselves up | |
| 14:28:04 | dansmith | artom: ack | |
| 14:31:17 | gmann | gibi: I will update the patch for reno comments and will keep bug open. and we can discuss the best possible approach about policy file usage in cross project sessions in PTG what bnemec added in oslo etherpad and i linked in nova ptg ethrepad too. | |
| 14:32:10 | gmann | gibi: zigo that works for you ^^ ? | |
| 14:35:41 | dansmith | stephenfin: oh right, yeah I'm not going to approve those completely inconsistent style things in the middle of a file, but I'm sure someone else will | |
| 14:36:06 | stephenfin | huh? | |
| 14:37:03 | dansmith | the "black says this ugly style is cool, so I'll just break from the rest of nova conventions here for the new code I'm adding" thing in your tests | |
| 14:37:39 | stephenfin | um, those are entirely new tests? | |
| 14:37:56 | dansmith | in a file with a style, in a project with a style | |
| 14:38:29 | stephenfin | really? | |
| 14:38:47 | dansmith | you're not even consistent within those tests | |
| 14:39:10 | stephenfin | we're inconsistent all over the place | |
| 14:39:17 | stephenfin | you're not going to hammer me for style, surely? | |
| 14:43:26 | artom | stephenfin, dansmith, hey, I may be late to the party, but those .contains("nova_object.name") searches... | |
| 14:43:38 | artom | This kind of substring search is notoriously slow in SQL, no? | |
| 14:43:52 | artom | For the compute nodes, it's probably fine, since there aren't that many of them, but for instances... | |
| 14:43:58 | dansmith | artom: they're not indexed, so yes | |
| 14:45:00 | artom | So we're just accepting that? | |
| 14:45:46 | artom | I dunno if that's been talked about before, as I said, I'm late to the party | |
| 14:46:05 | stephenfin | I don't think we've a choice. There's no other heuristic we can use to differentiate the legacy entries from the non-legacy ones | |
| 14:46:17 | dansmith | I guess if we did it in python, despite being slower, it's load on the machine running the nova-manage, instead of the DB server itself, which is probably better | |
| 14:47:39 | dansmith | although maybe we'd have no filter at that point and basically return all the instances | |
| 14:47:43 | dansmith | so yeah I dunno | |
| 14:49:21 | openstackgerrit | Ghanshyam Mann proposed openstack/nova master: Clarify the policy new defaults upgrade notes https://review.opendev.org/723645 | |
| 14:49:40 | gmann | dansmith: gibi zigo updated , please check - https://review.opendev.org/#/c/723645/ | |
| 14:50:30 | artom | dansmith, stephenfin, I guess there's no way to do "pagination" when selecting instance_extra? | |
| 14:50:48 | dansmith | artom: what would that help? | |
| 14:51:29 | artom | dansmith, select all instance_extra in steps of 100 or whatever, do the filtering in Python, find the instance UUIDs that way, then with those go back to the database? | |
| 14:52:58 | artom | Apparently you can do stuff with LIMIT: https://stackoverflow.com/questions/3799193/mysql-data-best-way-to-implement-paging | |
| 14:53:02 | dansmith | artom: but we'd still end up selecting every instance out of the database every time right? | |
| 14:53:11 | dansmith | every instance, in groups of 100 | |
| 14:53:26 | artom | Yeah, but at least it's spread out over time? | |
| 14:53:46 | artom | You're not filtering on all X thousands instances in a single query | |
| 14:53:55 | dansmith | artom: well, the migrations are supposed to be idempotent, so ideally you can run this over and over and have less and less impact | |
| 14:54:04 | gmann | melwitt: all setup for devstack and grenade now. we can approve this - https://review.opendev.org/#/c/704364/5 | |
| 14:54:08 | gmann | and then backport | |
| 14:54:26 | dansmith | artom: I think I'd rather the string filter in the query than just continually select every instance out of the database on every run, only to find that none are needed | |
| 14:54:28 | gmann | *done now | |
| 14:54:41 | dansmith | artom: I'd have to iterate every instance in the DB every time you asked me "are you done?" | |
| 14:55:06 | artom | dansmith, but isn't that what the string filter in the query is doing anyways, behind the scenes? | |
| 14:55:15 | artom | Looking at every instance in the database? | |
| 14:55:40 | dansmith | artom: no, it's looking at every value in a table | |
| 14:56:16 | dansmith | which is massively less expensive than selecting multiple tables, feeding those to python, constructing tons and tons of objects, for us to go through and do...that same string comparison | |
| 14:56:51 | artom | dansmith, right sorry - but what's what I was suggesting we do in python - select instance_uuid, numa_topology from instance_extra <in steps of 100>, fitler in python, use those instance_uuids for the actual update | |
| 14:57:17 | artom | But maybe ^^^ is impossible with our models/sqlalchemy? | |
| 14:57:31 | dansmith | you mean a direct query and not an ORM one? that's better, but you're still sending the results of all those queries across the network every time | |
| 14:57:52 | dansmith | no, we can do it without an ORM query, we do that in places | |
| 14:58:46 | artom | dansmith, yeah :/ | |
| 14:59:19 | artom | I guess we'd need metrics of how long the string filter would take, as a function of # of instances | |