Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2020-02-12
13:45:50 openstackgerrit Lee Yarwood proposed openstack/nova stable/rocky: Block rebuild when NUMA topology changed https://review.opendev.org/703116
13:45:50 openstackgerrit Lee Yarwood proposed openstack/nova stable/rocky: Disable NUMATopologyFilter on rebuild https://review.opendev.org/703117
13:45:51 openstackgerrit Lee Yarwood proposed openstack/nova stable/rocky: FUP for in-place numa rebuild https://review.opendev.org/703118
13:45:52 lyarwood sean-k-mooney: ^ just rebasing as stable/rocky should be passing again now and I'd like to land this before we switch over to EM
13:46:22 lyarwood aaaaaand I missed elod's comment
13:56:13 bauzas gibi: sean-k-mooney: I'm back
13:59:42 gibi bauzas: just replied with my understanding of Eric's summary
14:24:19 sean-k-mooney bauzas: just back too
14:24:37 sean-k-mooney had to go to my bank to sort things for the house purchase
14:25:16 bauzas gibi: coolio thanks
14:29:15 sean-k-mooney gibi: ya that is more or less a good summary
14:29:17 gibi bauzas: I think I got enough from efried_afk's summary that I see that my issue is solved by this propsal as well
14:30:05 sean-k-mooney gibi: well this still has the fallback which solves your main issue but also make the numa reporting the default which solve erics main issue of people using the fature after all this work
14:30:06 gibi sean-k-mooney: I treated the splitting algo as an impl detail for now. I think we can make it good enough and if not we have a way out
14:30:49 gibi sean-k-mooney: yeah, I'm OK that U compute is reshape by default
14:30:50 sean-k-mooney gibi: ya honelsty the poc i did would be good enouch in my book
14:30:58 gibi sean-k-mooney: agree
14:31:32 sean-k-mooney i will likely refacto that algoritim and submit a standalone patch later in the week
14:31:56 sean-k-mooney allowing asymetic spliting by default when you just set hw:numa_nodes is a minor change
14:32:03 sean-k-mooney and would be useful for numa instnaces
14:32:55 sean-k-mooney once we do that its just a matter of calling the get_numa_constratis function in a loop and generting the multiple queies and merging the results
14:44:22 huaqiang hi alex_xu
14:44:33 alex_xu huaqiang: i'm here
14:45:53 huaqiang do you mean, in the review of spec https://review.opendev.org/#/c/668656/, we have to mix 'hw:pinned_cpus' with 'resources:P|VCPU'
14:46:20 huaqiang BUT we should avoid the mixing of 'hw_pinned_cpus' with 'resources:xx;
14:46:27 huaqiang right?
14:47:06 alex_xu huaqiang: I mean it have to, althought we don't want that.
14:47:38 alex_xu I don't think we have other choice
14:49:58 huaqiang then there is no problem for setting the 'mixed' policy and cpu bitmask in image properties and then specify the PCPU and VCPU in flavor 'resources:P|VCPU'?
14:54:44 sean-k-mooney i have the mixed cpu spec open by the way so im going to try and finish reviewing it in the next hour or so before my next meeting
14:54:51 alex_xu huaqiang: yes, I think there is no problem
14:55:05 alex_xu sean-k-mooney: thanks
14:55:14 huaqiang sean-k-mooney: thank you :)
14:55:29 huaqiang alex_xu: got. thanks
14:57:01 sean-k-mooney alex_xu: are you largly happy with it?
14:57:19 alex_xu sean-k-mooney: yes, I think so
14:57:46 sean-k-mooney ok just wondering if you had pending comments. ill try and go through it form top to bottom now so
14:58:33 alex_xu no more pending comments.
15:03:26 Sundar gibi, dansmith, efried, sean-k-mooney: Trying to get my head around the rescheduling thing. Previously, the creation and binding of ARQs were happening in the compute manager. So, on failure, we just deleted the ARQs (which will be unbound by Cyborg if needed) and the retry would presumably have created/bound the ARQs on another node. Now the
15:03:27 Sundar create/bind are moved to the conductor, but that is done just before the RPC call to compute manager. So, could we still delete and recreate/rebind the ARQs?
15:04:21 dansmith Sundar: why is it any different?
15:04:52 sean-k-mooney so on a resudue instead of delete and recreate we can just rebind in the conductor
15:05:07 dansmith can we rebind? if so, then sure
15:05:18 sean-k-mooney if we cant delete and recreeate is fine too
15:05:32 sean-k-mooney we can update the host for an exisitng binding
15:05:41 sean-k-mooney it woudl be needed for move opertions anyway
15:05:52 dansmith well, not necessarily
15:05:55 dansmith depends on how they want to do it
15:06:06 sean-k-mooney i guess we could use a souce and dest arg
15:06:12 sean-k-mooney *arq
15:06:22 sean-k-mooney that might be better in some ways
15:06:29 dansmith if they wanted another ARQ bound to the new host and a switch, or whatever
15:06:40 dansmith that's not what he's asking though I assume
15:06:41 sean-k-mooney ya like we now do with neutron ports
15:06:45 dansmith right
15:06:50 Sundar dansmith, sean-k-mooney: It may be simpler to delete and re-create, similar to the rest of the patches.
15:07:03 dansmith yeah, that's fine
15:07:07 Sundar Yes, I am not talking about migration, which is out of scope for now
15:07:08 sean-k-mooney Sundar: i think dansmith and i both think thats fine
15:07:23 Sundar Cool, thanks, dansmith and sean-k-mooney.
15:08:49 sean-k-mooney if delete and recreate makes runing through the cyborg state machicne to prepare the device on the dest simpler i think it also makes sense to just do that
15:09:38 sean-k-mooney i.e. for that reason on its own in addtion to the fact thats what the other patches do and the workflow you have been using
15:11:28 Sundar sean-k-mooney: The Cyborg state machine can technically handle ARQ_UNBOUND state, which is reached when you unbind an existing ARQ without deleting it (and distinct from Initial state). That may be of use in the future, but for now it is simpler IMHO to just delete and recreate.
15:11:59 sean-k-mooney cool works for me
15:12:20 sean-k-mooney Sundar: speaking of delete where you able to repoduce the vm delete issue i hit
15:12:38 Sundar I am not hitting it even after reboots.
15:12:50 sean-k-mooney with the fake driver
15:13:30 Sundar I mostly used the real FPGA driver, but shouldn't matter, one would think. But let me try with the fake anyway.
15:14:00 sean-k-mooney its a keystone auth issue so the driver should not make a difference but i dont know
15:14:49 sean-k-mooney i do now have access to a system with the same fpga you have. but 1 im not sure what image to use and 2 it currently has rhel 7.7 so i have not figured out how to deploy opensatck on it yet
15:15:15 sean-k-mooney i might see if it can be reinstalled with centos 7.7 or ubuntu 18.04 so that i can use devstack
15:18:28 Sundar What's the issue with RHEL 7.7?
15:19:15 Sundar I am using Centos 7.7
15:21:02 sean-k-mooney its not supported by devstack and im not sure i will be able to get it to install with out enable eple and rdo repos which dont technicaly support RHEL
15:21:36 sean-k-mooney im going to try and stack in a vm first with RHEL 7.7 but im expecting the subsription manager to get in the way
15:21:59 sean-k-mooney tl;dr im expecting missing packages
15:22:09 Sundar Got it.
15:22:49 sean-k-mooney if your using centos 7.7 and i have to reinstall ill just use that
15:30:27 sean-k-mooney huaqiang: some minor nits to clean up in a follow up patch but im +1 on the mixed cpu spec
15:31:35 sean-k-mooney stephenfin: i think you are probaly the best person to be the final +2 on https://review.opendev.org/#/c/668656/19 if you think its ready.
15:55:55 efried stephenfin: yes please, what sean-k-mooney said ^
15:59:22 stephenfin Looking
16:00:39 sean-k-mooney i just responed to alex_xu coment regarding the service object version bump. i think we can use a comptue capablity trait instead and avoid the need for that
16:00:52 sean-k-mooney but excpetion for that point im good with it
16:16:41 openstackgerrit Merged openstack/nova stable/queens: Use stable constraint for Tempest pinned stable branches https://review.opendev.org/706714
16:21:14 openstackgerrit Lee Yarwood proposed openstack/nova stable/queens: Block deleting compute services with in-progress migrations https://review.opendev.org/699718
16:33:19 openstackgerrit Ghanshyam Mann proposed openstack/nova master: Skip to run all integration jobs for policy-only changes. https://review.opendev.org/707268
16:33:29 gmann stephenfin: melwitt updated ^^
16:34:26 melwitt gmann: do you have a Depends-On change that shows what gets run on a policy change? I think that's the best way to check whether it's doing what we want before +2ing
16:34:48 gmann melwitt: ok, i can do that.
16:35:52 openstackgerrit Ghanshyam Mann proposed openstack/nova master: Add new default roles in os-console-output policies https://review.opendev.org/707041
16:36:17 gmann melwitt: ^^ done. let's see once gate finish
16:36:48 melwitt thanks gmann
16:37:09 melwitt gmann: oh, you have a typo Depednds-On
16:37:46 openstackgerrit Ghanshyam Mann proposed openstack/nova master: Add new default roles in os-console-output policies https://review.opendev.org/707041
16:37:57 gmann ah sorry, updated
16:40:35 Sundar sean-k-mooney: Do you think https://github.com/openstack/nova/blob/master/nova/conductor/manager.py#L655 is a good place to delete the old ARQs?
16:42:56 gmann melwitt: I am not sure if default GET AZ to admin is right things. can you check this - https://review.opendev.org/#/c/706683/
16:43:35 melwitt gmann: ok, will look
16:43:39 gmann It is currently admin-or-owner which is open for everyone due to bug or that is expected and admin-or-owner in policy is just misleading

Earlier   Later