| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-12-10 | |||
| 14:58:33 | KeithMnemonic | yes there is a pci limit i thought | |
| 14:58:40 | KeithMnemonic | is that 26? | |
| 14:58:49 | sean-k-mooney | i think its 20 not 26 | |
| 14:59:49 | openstack | Launchpad bug 1770527 in OpenStack Compute (nova) "openstack server add volume fails over 26vols" [Wishlist,In progress] - Assigned to Tsuyoshi Nagata (yukari-papa) | |
| 14:59:49 | KeithMnemonic | it is more than 20 i am pretty sure, problem is this bug is still open https://bugs.launchpad.net/nova/+bug/1770527 so we have a customer asking for it | |
| 14:59:52 | sean-k-mooney | the 26 limit on device names i sobviousl just because tehre are 26 ascii/english letter | |
| 15:00:27 | sean-k-mooney | KeithMnemonic: it may depend on the qemu/libvirt version | |
| 15:00:31 | KeithMnemonic | https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/5/html/virtualization/sect-virtualization-virtualization_limitations-kvm_limitations | |
| 15:01:05 | KeithMnemonic | Hence, of the 32 available PCI devices for a guest, 4 are not removable. This means there are 28 PCI slots available for additional devices per guest. Every para-virtualized network or block device uses one slot. Each guest can use up to 28 additional devices made up of any combination of para-virtualized network, para-virtualized disk devices, or other PCI devices using VT-d. | |
| 15:03:31 | sean-k-mooney | does the 4 include the vnc/spice resouces | |
| 15:04:50 | sean-k-mooney | you can use virtio-scsi too which may allow mulitple volumes per pci device | |
| 15:18:59 | mriedem | lyarwood: surprise surprise multiattach swap volume across 2 hosts is broken | |
| 15:21:28 | lyarwood | mriedem: wasn't mdbooth looking at blocking all attempts to swap/migrate multiattach volumes? | |
| 15:21:49 | lyarwood | he isn't around today btw | |
| 15:22:04 | mriedem | he was for at least cases of the multiattach volume having >1 read/write attachment | |
| 15:22:17 | mriedem | https://review.openstack.org/#/c/572790/ | |
| 15:22:23 | mriedem | but this isn't that issue, | |
| 15:22:49 | mriedem | the swap volume code in compute updates the bdm record for the "old" volume and changes the volume_id to the "new" volume | |
| 15:22:52 | openstackgerrit | Merged openstack/nova master: Add docs for (initial) allocation ratio configuration https://review.openstack.org/622588 | |
| 15:22:56 | mriedem | essentially orphaning the old volume, so we don't cleanup properly | |
| 15:23:48 | mriedem | this https://github.com/openstack/nova/blob/ae3064b7a820ea02f7fc8a1aa4a41f35a06534f1/nova/compute/manager.py#L5798-L5806 | |
| 15:24:10 | mriedem | the bdm that gets updated is the old bdm (source volume), but save_volume_id is the new volume | |
| 15:24:41 | mriedem | we're also clearly wrongly updating the old bdm.connection_info with the new vol connection_info, | |
| 15:24:57 | mriedem | for new volume attach flows that doesn't matter as we don't use the bdm.connection_info, but it's still wrong | |
| 15:25:36 | mriedem | looks like that code assumes we did a cinder-induced retype/migration, "# correct volume_id returned by Cinder." | |
| 15:25:43 | mriedem | but that's not the case here | |
| 15:27:13 | mriedem | if only we had that volume_id uniqute constraint in the bdms table :) | |
| 15:27:20 | mriedem | the bdm update would blow up hard | |
| 15:28:41 | lyarwood | if only, sooooooooooo Matt also had a plan to block the direct use of this API FWIW at some point recently | |
| 15:28:58 | lyarwood | so only allow it to be used via volume migration API | |
| 15:29:20 | lyarwood | but this still sounds valid, do we have a launchpad bug for this? | |
| 15:29:47 | mriedem | not yet, i'm debugging the failures in the tempest-slow job here https://review.openstack.org/#/c/606981/ - i'll be dumping notes in a launchpad bug | |
| 15:30:46 | mriedem | i'm not sure how the compute api would block swap volume unless we checked the volume status to see if it's either 'retyping' or 'migrating' and fail otherwise | |
| 15:31:11 | mriedem | and if we'd restrict that based on a policy check | |
| 15:31:21 | mriedem | because swap volume is admin-only today already | |
| 15:32:34 | lyarwood | Yeah not sure what he had in mind tbh | |
| 15:43:55 | openstack | Launchpad bug 1807723 in OpenStack Compute (nova) "swap multiattach volume intermittently fails when servers are on different hosts" [Medium,Confirmed] | |
| 15:43:55 | mriedem | https://bugs.launchpad.net/nova/+bug/1807723 | |
| 15:46:21 | kashyap | lyarwood: What about Bregret? | |
| 15:46:46 | kashyap | lyarwood: I mean, what are you "dealing" with? Aren't you just supposed to just "suffer the consequences", or you have the power to "do something"? :D | |
| 15:47:33 | kashyap | lyarwood: Oh ... disregard me; just "caught up" with the Tories. | |
| 15:47:58 | stephenfin | jangutter: Reviewed https://review.openstack.org/#/c/607610/. Looks good to me, for the most part, the few updates suggested by others aside | |
| 15:48:10 | stephenfin | jangutter: If you rework today, let me know and I'll swing by again | |
| 15:48:53 | jangutter | stephenfin: thanks, respinning! | |
| 16:00:25 | jangutter | sean-k-mooney: any objection to choosing "Option 1" in the spec now? | |
| 16:00:54 | sean-k-mooney | jangutter: i have not looked in a while but didnt i say that in a previous version | |
| 16:01:55 | sean-k-mooney | ah its still at the same version so sure | |
| 16:02:04 | jangutter | sean-k-mooney: yeah, doing a respin now, just wanted to make doubly sure. I mean, I sold a _lot_ of tickets to "Sean vs Jay's punch-the-ginger contest". | |
| 16:03:49 | sean-k-mooney | jangutter: every know you dont punch ginger people in case its contagious :P | |
| 16:04:34 | jangutter | sean-k-mooney: that's why boxing gloves were developed to be so thick. | |
| 16:05:17 | sean-k-mooney | if you want to leave it till later to decide we can but you already have patches for option 1 | |
| 16:05:39 | sean-k-mooney | my main concern was serialiastion size | |
| 16:06:55 | sean-k-mooney | we can adress that at a later date in other ways | |
| 16:11:28 | openstackgerrit | Jack Ding proposed openstack/nova-specs master: Select cpu model from a list of cpu models https://review.openstack.org/620959 | |
| 16:14:55 | openstackgerrit | Ben Nemec proposed openstack/nova master: Migrate upgrade checks to oslo.upgradecheck https://review.openstack.org/603499 | |
| 16:40:13 | openstackgerrit | Jan Gutter proposed openstack/nova-specs master: Spec to implement os-vif generic datapath offloads https://review.openstack.org/607610 | |
| 16:58:17 | melwitt | o/ | |
| 16:59:03 | sean-k-mooney | melwitt: o/ | |
| 17:02:10 | sean-k-mooney | johnthetubaguy: o/ care to take another look at https://review.openstack.org/#/c/591607/11 | |
| 17:20:14 | melwitt | mriedem: I was thinking we should cancel the dec 20 nova meeting bc efried_cya_jan is out and I think dansmith is out that day too. and I was considering taking the day off as well | |
| 17:21:49 | mriedem | shrug | |
| 17:21:50 | mriedem | i'll be around | |
| 17:21:55 | mriedem | i can run it if needed | |
| 17:22:42 | dansmith | I won't be | |
| 17:25:20 | melwitt | mriedem: ok, if you are able to run it then that works too. I was thinking there might be a lack of quorum | |
| 17:26:04 | s10 | Please review backports for https://review.openstack.org/#/q/topic:bug/1806064 | |
| 17:28:14 | sean-k-mooney | lyarwood: ^ that proably for you | |
| 17:43:32 | jangutter | mriedem: would you be able to take a look at https://review.openstack.org/#/c/607610/ in your copious free time...? Jay's already +2'ed the previous revision. | |
| 17:44:15 | mriedem | uhh | |
| 17:48:10 | sean-k-mooney | by the way was there a proposal to do another spec review day tomorow or was i imagining that | |
| 17:49:26 | melwitt | sean-k-mooney: I suggested it and we discussed it in the nova meeting and decided to give it a miss. I replied on the ML accordingly | |
| 17:49:45 | sean-k-mooney | melwitt: ah ok | |
| 17:53:25 | openstackgerrit | Surya Seetharaman proposed openstack/python-novaclient master: API microversion 2.68: Handles Down Cells https://review.openstack.org/579563 | |
| 17:53:26 | mriedem | lbragstad: have you seen this? http://logs.openstack.org/81/606981/4/check/tempest-slow/fafde23/controller/logs/screen-n-api.txt.gz#_Dec_08_01_45_42_745709 | |
| 17:55:24 | mriedem | seems like something in an api-paste middleware | |
| 17:55:38 | mriedem | b/c it's logged before we call the actual controller method to handle that request | |
| 17:57:25 | mriedem | oh i bet i know what it is | |
| 17:57:32 | lbragstad | it's related to https://review.openstack.org/#/c/619260/3/oslo_policy/policy.py | |
| 17:57:59 | mriedem | nova's RequestContext calls check_is_admin during init | |
| 17:58:02 | mriedem | which is for every request | |
| 17:58:34 | lbragstad | does that call enforce()? | |
| 17:59:23 | mriedem | calls return _ENFORCER.authorize('context_is_admin', target, credentials) | |
| 17:59:55 | mriedem | which calls enforce | |
| 17:59:59 | lbragstad | ah - it does | |
| 18:00:00 | lbragstad | right | |
| 18:00:04 | lbragstad | makes sense | |
| 18:00:41 | lbragstad | oh - weird, target is being overloaded as credentials? | |
| 18:00:59 | lbragstad | i suppose, is it too early in the pipeline for nova to know what the actual target is? | |
| 18:01:04 | mriedem | yeah | |
| 18:01:08 | lbragstad | huh | |
| 18:01:13 | lbragstad | interesting | |
| 18:01:28 | mriedem | remember this? https://review.openstack.org/#/c/564349/ | |
| 18:03:12 | lbragstad | oh - yeah... kinda | |
| 18:04:32 | lbragstad | looks like that would still address the issue | |
| 18:05:00 | mriedem | this is where we get _DeprecatedPolicyValues https://github.com/openstack/oslo.context/blob/0daf01065d1d51694e06aaecb3dcf4dcc78710fe/oslo_context/context.py#L318 | |
| 18:05:04 | mriedem | passing that in as the target | |
| 18:05:23 | lbragstad | right | |
| 18:05:38 | lbragstad | you should be able to pass context objects as credentials | |
| 18:05:59 | lbragstad | but we don't really link anything about target to context | |
| 18:06:00 | lbragstad | at least in oslo.policy | |