| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-12-10 | |||
| 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 | mriedem | https://bugs.launchpad.net/nova/+bug/1807723 | |
| 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: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 | |
| 18:06:28 | mriedem | seems we should just pass target={} | |
| 18:06:30 | mriedem | since we don't know | |
| 18:07:06 | lbragstad | (we wanted to use context objects as a replacement for a dictionary called credentials since it makes things easier for services using oslo.policy - instead of just assuming service developers know what to put in credentials or how the internals of oslo.policy parses it) | |
| 18:07:37 | lbragstad | and it relays a bunch of useful information about the user making the request - which is what credentials was trying achieve anyway | |
| 18:08:22 | lbragstad | but yeah - if you don't know anything about the target, an empty dictionary would seem safer than overloading target as a set of context attributes | |
| 18:12:00 | lbragstad | for example - in keystone we protect APIs like this https://github.com/openstack/keystone/blob/master/keystone/api/users.py#L137 | |
| 18:12:31 | lbragstad | we look at the context object associated with the request and generate "credentials" https://github.com/openstack/keystone/blob/master/keystone/common/rbac_enforcer/enforcer.py#L380 | |
| 18:12:44 | lbragstad | and then pass that to oslo.policy https://github.com/openstack/keystone/blob/master/keystone/common/rbac_enforcer/enforcer.py#L81-L82 | |
| 18:18:10 | openstackgerrit | Dan Smith proposed openstack/nova master: Make compute rpcapi version calculation check all cells https://review.openstack.org/623284 | |
| 18:18:10 | openstackgerrit | Dan Smith proposed openstack/nova master: Make service.get_minimum_version_all_cells() cache the results https://review.openstack.org/623283 | |
| 18:19:33 | openstackgerrit | Georg Hoesch proposed openstack/nova master: refactor get_console_output() for console logfiles https://review.openstack.org/575735 | |
| 18:38:19 | dtrainor | Howdy. I'm trying to troubleshoot a failed deployment that ultimately results in "Message: No valid host was found. There are not enough hosts available., Code: 500". Digging deeper, it looks like RamFilter is returning 0 hosts because the hosts appears to return a value of 0 MB RAM http://paste.openstack.org/show/736921/ | |
| 18:38:35 | etp | Do max_placement_results and host aggregates/AggregateInstanceExtraSpecsFilter work together or am I looking at configuration error? Say cloud has 100 hypervisors, max_placement_results = 10, two host aggregates 50 hypervisors each, flavor extra specs matching latter aggregate with hypervisors 51-100 | |
| 18:38:59 | dtrainor | the nodes get properly introspected. the introspection data is good. there may be a bug in the Ravello hypervisor that this is being deployed on which ahs been known to return 0MB if the host BIOS returned a negative number (read something about an overcommit ratio sometimes causing this) | |
| 18:42:02 | dtrainor | I'm using all default values for this downstream queens deployment. The flavors show a minimum requirement of 4096MB, that's the only place I can find this number occurring. | |
| 18:50:07 | dansmith | etp: 10 is small enough that you're likely to not get back any hosts in the aggregate you're looking for yeah | |
| 18:50:27 | dansmith | etp: unless you're enabling a request filter in nova that helps to ensure that you do | |
| 18:50:38 | dansmith | which is currently az or tenant filtering | |
| 18:53:58 | TheJulia | Hopefully someone can help jog my memory... A long time ago I remember there was a discussion of how nova represents a baremetal node being torn down. I believe the state then and now is that the instance is generally "ACTIVE" until the node is actually deleted, and I think the motivation behind that was resource accounting wise. Does anyone remember this discussion (it would have been 2+ years ago I think) | |
| 18:57:42 | dansmith | TheJulia: the instance goes away immediately, AFAIK, as that's the way delete is supposed to work, but nova tries to make the node not schedule-able until the cleaning is done | |