Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2020-02-12
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
16:43:42 gmann melwitt: thanks
16:48:09 melwitt gmann: I think it should be admin_or_owner, is it possible to just fix the bug? AZ is user-facing but usually only project members would be able to see which AZ in a instance is in (not everybody from other projects)
17:08:24 sean-k-mooney Sundar: looking
17:08:25 gmann melwitt: but issue is we do not know the owner while GET AZ.
17:08:54 melwitt oh ... /me looks again
17:08:59 gmann melwitt: this is list and detail API - https://github.com/openstack/nova/blob/1fcd74730d343b7cee12a0a50ea537dc4ff87f65/nova/api/openstack/compute/availability_zone.py#L108
17:09:43 sean-k-mooney am we could. althoh i belive we will do a cleaup of the failed spawn before that so you might be able to do it earlier.
17:10:01 sean-k-mooney that is proably the latest i would delete and recreate the ARQ
17:10:52 sean-k-mooney Sundar: you could also do it here https://github.com/openstack/nova/blob/master/nova/conductor/manager.py#L694
17:11:03 sean-k-mooney which i think is where i would expect it to happen
17:11:50 melwitt gmann: ohhhh this is just giving a list of all the AZs that exist, not the AZ of any particular instance. yeah, sorry, let me comment again
17:11:56 gmann melwitt: "which AZ is instance is in" is admin-or-owner which is via GET /servers API
17:12:01 gmann melwitt: yeah
17:12:04 Sundar sean-k-mooney: Ok, got it. Thanks.
17:12:55 sean-k-mooney im not 100% if you want to be in our out side of the if but you likely should be doing the clean up in that exeption handeling code https://github.com/openstack/nova/blob/master/nova/conductor/manager.py#L674-L699
17:14:36 melwitt gmann: yeah, I agree it should be allowing everyone to see AZ list by default. I added a comment
17:15:34 gmann melwitt: ok. detail make sense to be admin-only as it has host info
17:15:44 melwitt gmann: right, agreed
17:16:03 gmann thanks. I will modify accordingly
17:29:49 stephenfin sean-k-mooney: You can only specify the number of instance CPUs via the flavor, right?

Earlier   Later