| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-02-12 | |||
| 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? | |
| 17:29:53 | stephenfin | i.e. not via the image | |
| 17:30:12 | sean-k-mooney | yes | |
| 17:32:46 | sean-k-mooney | technically you could do evial things with a cyborg device profile but if you put VCPU or PCPU int eh device profile your on your own | |
| 17:35:05 | sean-k-mooney | *evil | |
| 17:38:59 | sean-k-mooney | lyarwood: by the way did you want me to do anything with the backprots for the numa inplace rebuild patches | |
| 17:39:31 | sean-k-mooney | lyarwood: you pinged my earlier but i was not sure if you already fixt them up or if there was still stuff pending | |
| 17:39:53 | stephenfin | huaqiang: Reviewed https://review.opendev.org/#/c/668656/. You need to drop the image metadata option and avoid the need to mix placement'y syntax extra specs with legacy extra specs. Do that and I'm +2 | |
| 17:39:56 | stephenfin | sean-k-mooney, efried, alex_xu: ^ | |
| 17:40:24 | sean-k-mooney | what do you think about the need for the service bump | |
| 17:40:45 | stephenfin | vs. a capability? | |
| 17:40:45 | sean-k-mooney | e.g. do you think we could use a compute capablity trait isntead | |
| 17:40:49 | sean-k-mooney | ya | |
| 17:40:59 | sean-k-mooney | i would be fine with leaving that to impleenation to decied | |
| 17:41:04 | sean-k-mooney | but i think the trait would work | |
| 17:41:43 | sean-k-mooney | there may be another reason for the service version bump that i missed | |
| 17:41:55 | stephenfin | I used a capability for the PCPU work | |
| 17:42:01 | stephenfin | so yeah, I'd probably do the same again | |
| 17:42:35 | stephenfin | commit f329ee5a3b6 | |
| 17:42:43 | sean-k-mooney | using the capablity trait means we can support rolling upgrades too rather then requiring all nodes to be upgraded | |
| 17:43:10 | sean-k-mooney | just the contoler and the host it lands on will need to be ussuri | |
| 17:44:59 | stephenfin | Exactly | |
| 17:45:22 | sean-k-mooney | there is a usecase for keeping the image property by the way | |
| 17:45:32 | sean-k-mooney | we support setting the realtime mask in the image | |
| 17:45:44 | stephenfin | We do, but I think that's wrong | |
| 17:45:45 | sean-k-mooney | so for parity we could support the pinned cpus there too | |
| 17:45:49 | sean-k-mooney | why | |