Earlier  
Posted Nick Remark
#openstack-nova - 2020-04-02
07:54:01 gibi so something is different in those classes
07:55:14 gibi this passes VolumeAttachPolicyTest
07:55:30 gibi VolumeAttachNoLegacyPolicyTest and .VolumeAttachScopeTypePolicyTest fails
07:55:37 brinzhang_ yes, it's ok in VolumeAttachPolicyTest class, and not ok in VolumeAttachScopeTypePolicyTest and VolumeAttachNoLegacyPolicyTest class
07:56:32 brinzhang_ I tried move it to VolumeAttachScopeTypePolicyTest class, but I think I cannot do that, I should keep them in the base class, I think
07:56:49 brinzhang_ of course, in VolumeAttachScopeTypePolicyTest it's also failed
08:13:20 gibi I gave up, we need gmann to look at these tests
08:17:33 brinzhang_ gibi: yeah, thanks also ^^
08:32:09 gibi stephenfin: just to double check is this bp done now? https://blueprints.launchpad.net/nova/+spec/remove-nova-network-ussuri
08:32:21 gibi I don't see any open patches
08:32:48 gibi stephenfin: nvm, I see that the bp is in Implemented state
08:52:55 stephenfin Yeah, I updated that last week
08:53:34 gibi stephenfin: thanks
08:54:14 gibi I'm going through the BPs targeted to ussuri just by eye skipped a line an thought nova-net bp is not closed
08:54:21 gibi s/by/my
08:54:46 gibi stephenfin: how familiar you are with the oslo policy stuff?
08:55:04 stephenfin I've been learning it slowly
08:55:05 gibi stephenfin: brinzhang_ has a test that fails on policy problem and I didn't find the solution
08:56:33 gibi stephenfin: this is the problematic test (in the comment in the paste) https://review.opendev.org/#/c/711194/11/nova/tests/unit/policies/test_volumes.py@176 if you have time. If not then no worries we will ping gmann later
08:59:34 brinzhang_ gibi, thanks mention these, if stephenfin can give some help, I will be appreciate
09:03:07 stephenfin will do
09:03:35 luyao stephenfin: Hi, I hope you could continue looking at vpmem live migration support https://review.opendev.org/#/c/687856/ if you have time. :)
09:17:03 brinzhang_ gibi, dansmith: I will modify the SPEC in 2020/4/4 or 2020/4/5, to show the new PUT api changes, I think it's not later
09:17:38 gibi brinzhang_: sure. doc changes can go in after FF. and the spec repo is not even released so that is OK to update even later
09:20:55 brinzhang_ gibi: thank, if so, I will update that while I have more free time ^^
09:21:10 gibi brinzhang_: thanks
09:21:17 brinzhang_ gibi: np
09:39:11 openstackgerrit Stephen Finucane proposed openstack/nova master: Remove future imports https://review.opendev.org/714675
09:39:11 openstackgerrit Stephen Finucane proposed openstack/nova master: Use unittest.mock instead of third party mock https://review.opendev.org/714676
09:39:11 openstackgerrit Stephen Finucane proposed openstack/nova master: hacking: force explicit import of python's mock https://review.opendev.org/708768
10:28:51 stephenfin gibi, brinzhang_: RE: https://review.opendev.org/#/c/711194/11/nova/tests/unit/policies/test_volumes.py@176 - you're using the wrong HTTPRequest object
10:29:56 stephenfin you're modifying 'nova.context' on 'self.req' and then calling things with a local 'req' that doesn't have 'nova.context' configured
10:30:41 brinzhang_ stephenfin: I should add v2.85 support, what I do to change req = fakes.HTTPRequest.blank('', version='2.85')?
10:30:58 gibi stephenfin: good eyes! thanks!
10:31:23 stephenfin brinzhang_: I'm guessing but I think think self.req.version = '2.85' should do the trick??
10:31:37 stephenfin If not, you need to do req = fakes.HTTPRequest.blank('', version='2.85')
10:31:46 brinzhang_ stephenfin: let me try
10:31:57 stephenfin and the do e.g. req.environ['nova.context'] = self.system_foo_context
10:32:03 stephenfin ^ that's what I did locally
10:33:09 stephenfin brinzhang_: Actually, in the setUp, is there any reason not to configure 'self.req' with a version argument?
10:33:32 stephenfin You're testing policy, not microversion support, so you'll always want to use a known working version, right?
10:33:52 brinzhang_ yes
10:35:45 brinzhang_ stephenfin: you mean I should change self.req to req in setup()?
10:35:52 stephenfin no
10:36:24 stephenfin instead of self.req = fakes.HTTPRequest.blank('')
10:36:33 stephenfin do self.req = fakes.HTTPRequest.blank('', version='2.85')
10:36:49 stephenfin here https://review.opendev.org/#/c/711194/12/nova/tests/unit/policies/test_volumes.py@78
10:37:19 brinzhang_ no, it dosenot only for v2.85
10:37:35 brinzhang_ so I just used req in v2.85 policy tests
10:37:36 stephenfin ah, I see now, this is only for the 'update_volume' case
10:37:41 brinzhang_ yes
10:37:49 stephenfin gotcha
10:37:57 brinzhang_ req.environ['nova.context'] = self.system_foo_context
10:38:11 stephenfin yup, that'll do so ^
10:38:13 brinzhang_ I added this, it run ok now, will update
10:38:18 brinzhang_ thansk stephenfin, gibi
10:47:28 openstackgerrit Brin Zhang proposed openstack/nova master: Separate update and swap volume policies https://review.opendev.org/711194
10:47:33 brinzhang_ gibi, stephenfin: done thanks
10:48:43 brinzhang_ stephenfin: can you +A for this patch https://review.opendev.org/#/c/693828/25? it's ready for everything, that comment inline, I will fixed by FUP
10:50:39 stephenfin brinzhang_: I haven't looked at that in a while so I'll need a while
10:50:52 openstackgerrit Stephen Finucane proposed openstack/nova master: api: Add framework for extra spec validation https://review.opendev.org/704643
10:50:53 openstackgerrit Stephen Finucane proposed openstack/nova master: api: Add support for new cyborg extra specs https://review.opendev.org/716222
10:50:53 openstackgerrit Stephen Finucane proposed openstack/nova master: api: Add microversion 2.85, extra spec validation https://review.opendev.org/708436
10:50:54 openstackgerrit Stephen Finucane proposed openstack/nova master: docs: Add documentation for flavor extra specs https://review.opendev.org/710037
10:51:35 stephenfin gibi: addressed the comments from Sundar and removed those errant prints from the last doc patch ^
10:51:38 brinzhang_ stephenfin, gibi, gmann: thanks, hope you have a greate day ^^
10:52:47 openstackgerrit Sylvain Bauza proposed openstack/nova master: Provide the parent pGPU when creating a new vGPU https://review.opendev.org/715489
10:52:48 openstackgerrit Sylvain Bauza proposed openstack/nova master: WIP: Support different vGPU types per pGPU https://review.opendev.org/715490
10:52:53 bauzas sean-k-mooney: ^
11:03:45 openstackgerrit Merged openstack/nova master: Add new default roles in remote console policies https://review.opendev.org/716484
11:38:31 gibi stephenfin: ack, will look shortly
11:41:27 gibi stephenfin: I'm all the way +2 on that series. Do you have a novaclient change as well?
12:25:26 stephenfin bauzas: You think you could review https://review.opendev.org/#/c/710037/8/doc/ext/extra_specs.py ? It's not the least bit complicated, if that helps :)
12:25:38 bauzas oh yeah
12:25:42 stephenfin Happy to trade reviews
12:34:20 sean-k-mooney bauzas: at the moment i assume you are not allowing multiple vGPU types on a single pGPU
12:34:41 sean-k-mooney bauzas: there is noting in princiapl that prevents that form working even if nvida does not support that
12:35:21 sean-k-mooney the vfio mediated device framework fully support using multiple mdev_types on the same devcie concurrnetly
12:35:26 alex_xu anyone know why we can swap the same volume before https://review.opendev.org/#/c/693828/25/nova/api/openstack/compute/volumes.py@495...
12:36:35 sean-k-mooney alex_xu: lyarwood is on pto i think but i think we can may do that for a volume retype on the cinder side
12:36:38 alex_xu oh, I guess we can't, that will fail at later voluem status check
12:36:53 alex_xu sean-k-mooney: ah, thanks
12:37:25 sean-k-mooney alex_xu: im not sure if my guess above was correct by the way. we could very well just fail later as you said
12:37:41 alex_xu yea
12:38:13 sean-k-mooney but i think cinder allows use to retype a voule while its attached to an instance and this is the only way i can think if for it to tell nova that it has updated
12:39:20 alex_xu sean-k-mooney: ok, thanks
12:41:26 sean-k-mooney alex_xu: i didnt review the rest of that patch but just -1'd it since its aliasing the id builtin fucntion and using id as a varible which is wrong
12:41:44 sean-k-mooney in this context it wont break anything but we should never do that
12:51:28 alex_xu sean-k-mooney: I'm not sure we can check that, I need to check the api code. we use 'id' in many API. but I agree that seems wrong
12:53:22 sean-k-mooney im not sure we call id directly in nova since we normally dont care about the objects address in memory
12:53:42 sean-k-mooney but its just not good practic to alias builtins in general
12:54:20 sean-k-mooney it would only really be an issue if you did "id=dir" or something at module scope
12:54:47 sean-k-mooney inside a function it will jsut make id unavialbel in that function body
12:57:37 sean-k-mooney but if you do python3 -c "id=dir; help(id)" it will show the help for dir so if you do that at module scope anything that uses id after will get dir instead
12:58:16 alex_xu yea, agree with that
12:58:39 alex_xu sean-k-mooney: this is where id coming from https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/routes.py#L820
13:00:12 sean-k-mooney ah i see ya we proably shoucl change that to <resouce>_id for all of the usages and add a hacking check.
13:00:33 sean-k-mooney that is a seperate change however so ill remove my -1
13:00:46 sean-k-mooney this is an existing bug
13:02:43 openstackgerrit Huaqiang Wang proposed openstack/nova master: Introduce the 'CPUAllocationPolicy.MIXED' enum https://review.opendev.org/716267

Earlier   Later