Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2020-04-28
11:25:08 brinzhang_ gibi: can you check
11:25:20 gibi brinzhang_: will check soon
11:25:27 brinzhang_ gibi: thanks
11:40:38 gibi brinzhang_: confirmed the bug.
12:30:37 bauzas gibi: brinzhang: FWIW, I think we should change the title of bug 1874664 to make it clear it's for all nested Resource Providers
12:30:37 openstack bug 1874664 in OpenStack Compute (nova) "Boot more than one instances failed with accelerators in its flavor" [Medium,Confirmed] https://launchpad.net/bugs/1874664 - Assigned to Wenping Song (wenping1)
12:30:37 openstackgerrit Brin Zhang proposed openstack/nova master: Add nested resource providers limit for multi create https://review.opendev.org/723884
12:31:01 gibi bauzas: I agree
12:32:59 bauzas changed https://bugs.launchpad.net/nova/+bug/1874664
12:32:59 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:33:35 bauzas gibi: have you tested it for bandwidth-aware instances ?
12:33:52 bauzas actually, that's traits, right?
12:34:35 gibi bauzas: multi create with neutron ports are not supported even without bandwidth
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 bauzas brinzhang: see the bug description modification https://bugs.launchpad.net/nova/+bug/1874664
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: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

Earlier   Later