Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2020-03-26
17:02:22 gmann and cinder will keep working as new defaults keep allowing admin to access
17:02:53 dansmith yeah
17:03:09 gmann ok adding comment on the review for brinzhang_
17:03:19 sean-k-mooney gibi: looking at that os-vif repo we have not merged any patches since we did the last release so i think we can stick with the 2.0.0 release for m3 which we created at m2
17:04:22 sean-k-mooney gibi: if we do merge something between no and next week i can request a release but for now we are good.
17:14:48 openstackgerrit John Garbutt proposed openstack/nova master: Add reno for unified limits https://review.opendev.org/715271
17:49:37 gmann dansmith: please let me your opinion on this, 'not expose the non-nova exception name to non-amdin' - https://review.opendev.org/#/c/694428/9/nova/objects/instance_action.py@200
17:52:24 dansmith mnaser: right, which is why we hide the message now
17:52:41 dansmith mnaser: the question is whether or not hiding the actual name of the exception (i.e. LibvirtError) is a problem and I assert that it is not
17:53:22 mnaser dansmith: i agree with that, especially if its a libvirt-specific error
17:53:29 mnaser makes life easier
17:57:39 sean-k-mooney mnaser: to be fair the cve that we had in the past was not acatlly as sever as the bug suggested since the cpeh monitor details specifcaly the ip are also availabel to non admins via the attachment which they can see. but just reporting the name avoids that entirely
17:59:10 sean-k-mooney the only infomation leak that actully causes was the name of the ceph keyfile, still not ideal.
17:59:23 sean-k-mooney but that is fixed in that case at least
18:02:35 gmann mnaser: does any user ask about what driver you use for your cloud and my VM will be running on? before they buy :)
18:02:54 gmann or hypervisor
18:02:55 openstackgerrit Sasha Andonov proposed openstack/nova master: rbd_utils: increase _destroy_volume timeout https://review.opendev.org/705764
18:03:03 mnaser gmann: i don't think we've actually ever had a customer ask what hypervisor/backend storage/etc
18:03:10 sean-k-mooney gmann: in principaly they should not care
18:04:00 gmann yeah, they should not. I was curious if they make the decision based on that.
18:04:24 sean-k-mooney they might make a dession based on specific features
18:05:08 sean-k-mooney which might only work with specific hyperviors but if vmware and libvirt but suppoted the features/api actions they cared about they proably would not care as long as there application worked fine
18:06:33 sean-k-mooney i mean i think aws uses xen in some from and google cloud suses some form of kvm with its own lightweight qemu alternitive but i dont think most people care when they use either product
18:08:38 gmann in one of our RFP, the customer asked to provide hypervisor-based choice to the user request of VM. not sure how good/bad/usable that was.
18:09:13 gmann though I am not sure it was user request or just customer thought.
18:09:25 sean-k-mooney well that is not realy that hard to do you just use multple virt dirvers in one cloud
18:09:47 sean-k-mooney there are then several filter you can use
18:11:21 sean-k-mooney the over used example is running windows instnace on hyperv but you can use custom extra specs in flaovr or a trait today to support that
18:58:38 mnaser sean-k-mooney: aws has moved away from xen btw :p
19:03:15 sean-k-mooney mnaser: good to know but im not sure there customer will notice which was kind of my point. to them the use an awx m1.whatever instnace
19:04:20 mnaser sean-k-mooney: yep agreed
20:06:01 sean-k-mooney dansmith: im currently testing resculde. it seams to work but sofar i have just added a raise ValueError at the top of spawn in the libvirt driver
20:06:19 dansmith cool
20:06:23 sean-k-mooney the allocation and arq were correctly created against the second host
20:06:37 sean-k-mooney is there anything else you want me to check specificlly
20:08:28 dansmith on reschedule?
20:08:37 dansmith I forget, did you try cold migration?
20:09:04 sean-k-mooney no but i can. i thikn we expect that to fail like evaucate and resize fails.
20:09:51 dansmith ah okay.. I can see migration working and resize not, but only in a few scenarios, so if you did that already that's fine
20:09:52 sean-k-mooney dansmith: this is the current list of followups that we need to adress after the current series is merged https://etherpad.openstack.org/p/cyborg-nova-followup
20:10:03 dansmith evac is a little different since it doesn't get help from the original node
20:10:20 dansmith sean-k-mooney: ah sweet, hadn't seen this
20:10:32 sean-k-mooney ya so evac works but it does not claim an fpga on the dest or update the arq
20:10:46 sean-k-mooney dansmith: sundar created it todeay
20:10:49 sean-k-mooney *today
20:11:02 dansmith doesn't try to update the arq, or fails because the old one isn't deleted?
20:11:33 sean-k-mooney good question i will check but since the placemnt allocation does not have a device i suspect it doesnt even try
20:11:48 sean-k-mooney dansmith: the rebuild path does not have to do any arq updates
20:11:55 sean-k-mooney so i suspect it does not try
20:12:17 dansmith but we scheduled to pick a new host,
20:12:18 dansmith but yeah, fair point
20:12:42 sean-k-mooney ill go check and let you know
20:14:44 dansmith I'm sure there are plenty of things missing, but yeah it'd be good to know where we're starting from
20:17:15 sean-k-mooney dansmith: ah so cold migration is blocked in the code :)
20:17:16 sean-k-mooney Forbidden with instances that have accelerators. (HTTP 403) (Request-ID: req-c318fb6b-730c-4bd3-9ddf-cb7de6e472a3)
20:17:30 dansmith ah okay, I haven't really gotten to that patch at all
20:17:33 dansmith so... good :)
20:17:44 sean-k-mooney so that works at least although the respocne code still looks wrong to me
20:17:54 sean-k-mooney it should proably be a 400 or 409
20:22:29 dansmith I thought we agreed on 403?
20:22:45 sean-k-mooney we proably did
20:23:08 sean-k-mooney i just find 403 forbiden which is normaly used for auth issues confusing
20:23:33 sean-k-mooney i would expect to get 403 if i did not have enough permission to do something not because its unsupported
20:26:15 dansmith IIRC, 401 means "authorization required" and 403 means "not permitted" - the latter which may or may not be because of insufficient or missing credentials
20:26:40 sean-k-mooney https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/403
20:26:49 dansmith "401 Unauthorized: If the request already included Authorization credentials, then the 401 response indicates that authorization has been refused for those credentials. 403 Forbidden: The server understood the request, but is refusing to fulfill it"
20:27:19 dansmith "tied to the application logic"
20:27:36 sean-k-mooney ya it gives us leway to use it this way
20:27:45 dansmith "such as (but not limited to) insufficient rights"
20:28:10 sean-k-mooney im just used to thinking about it as related to authorisation
20:28:33 melwitt zzzeek: I've been tracing the gate bug situation with DNM debug logging and the latest thing I found is that this call to _create_session never returns https://github.com/openstack/oslo.db/blob/master/oslo_db/sqlalchemy/enginefacade.py#L657-L658 any ideas how or why that could happen?
20:28:35 dansmith I think a lot of things don't use 401 and 403 properly, so it's common to not have a gut feeling about the difference
20:33:13 sean-k-mooney so this is interesting GET /placement/allocation_candidates?limit=1000&resources=DISK_GB%3A1%2CMEMORY_MB%3A64%2CVCPU%3A1&root_required=COMPUTE_ACCELERATORS%2C%21COMPUTE_STATUS_DISABLED
20:33:45 sean-k-mooney the placement request for the evacuate gets teh trait added by the prefilter
20:33:52 sean-k-mooney but not the resouce requests
20:37:22 dansmith yeah, that's weird... that means the prefilter is seeing the device profile in the flavor
20:37:29 sean-k-mooney yep
20:37:51 sean-k-mooney im not seeing any attepmet to update teh ARQ
20:38:28 sean-k-mooney did we move to putting the resouce groups form the device profile into the request spec
20:38:59 melwitt gmann: I have a followup patch here related to the new policy rule I added earlier in the cycle, would appreciate your review https://review.opendev.org/713295
20:44:15 sean-k-mooney interesting the "requested_resources" is null http://paste.openstack.org/show/791213/
20:48:58 sean-k-mooney we do populate the accel_info in the resouces https://review.opendev.org/#/c/631244/69/nova/compute/manager.py@2604
20:50:10 sean-k-mooney but i guess we never save that sice we call save on line 2570
20:53:08 sean-k-mooney actully saving the instance in not important
21:46:17 openstackgerrit Merged openstack/nova master: nova-net: Remove unused parameters https://review.opendev.org/703974
21:46:18 sean-k-mooney dansmith: found the issue i think. https://github.com/openstack/nova/blob/9d212738bec63d7490998a2840598d790a3c94fc/nova/conductor/manager.py#L1121-L1128
23:05:46 openstackgerrit sean mooney proposed openstack/nova master: [WIP] cyborg evacuate support https://review.opendev.org/715326
23:48:25 gmann melwitt: +1. lgtm
23:48:40 melwitt thanks
#openstack-nova - 2020-03-27
00:24:10 openstackgerrit Brin Zhang proposed openstack/nova master: Expose instance action event details out of the API https://review.opendev.org/694430
00:24:11 openstackgerrit Brin Zhang proposed openstack/nova master: Add instance actions v284 samples test https://review.opendev.org/706251
00:27:56 gmann brinzhang_: thanks, lgtm. though you are racing on 2.84 with stephenfin. let's see who win.
00:28:53 brinzhang_ gmann: np, thanks for concerning this
00:52:10 brinzhang_ gibi, stephenfin: instance action events patch updated done. https://review.opendev.org/#/c/694430/
00:53:13 openstackgerrit Merged openstack/nova master: Create and bind Cyborg ARQs. https://review.opendev.org/631244
01:05:03 gmann johnthetubaguy: how about making GET flavor access default to @ instead of admin-only. we cannot verify the owner in this API so anyone trying this API and not having the access to flavor will anyway get 404. changing to admin as i proposed currently will disallow the tenants who have access to flavor - https://review.opendev.org/#/c/713697/3/nova/policies/flavor_access.py@68
01:06:58 gmann johnthetubaguy: keeping @ will keep existing deployment working as it is and also does not show flavor-access info to all who does not have access.
01:34:30 openstackgerrit Kevin Zhao proposed openstack/nova master: fix scsi disk unit number of the attaching volume when cdrom bus is scsi https://review.opendev.org/712607
02:07:25 openstackgerrit Merged openstack/nova master: Pass accelerator requests to each virt driver from compute manager. https://review.opendev.org/698581
02:09:07 brinzhang_ gmann: Can I push a new to change the os-volume-attachment:update policy to os-volume-attachment:swap policy for swap volume api?

Earlier   Later