| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-11-30 | |||
| 13:01:07 | knsahm | 2017-11-30 12:44:55.281 77 ERROR nova.api.openstack.extensions [req-ec42f6ad-1e3e-4f7b-a3f6-c813ae94b9c9 c756af2957c4447eafc4cef39cdb79e5 469dc3d300df4d41aaea00db572043ae - default default] Unexpected exception in API method | |
| 13:02:09 | knsahm | i can create snapshots by using the openstackcli | |
| 13:02:25 | nsingh | knsahm: i think your token is expired. | |
| 13:03:16 | nsingh | knsahm: Run command "openstack token issue" | |
| 13:03:59 | knsahm | | expires | 2017-12-01T13:03:44+0000 | |
| 13:06:59 | knsahm | i've refreshed my session | |
| 13:07:00 | openstackgerrit | Matthew Booth proposed openstack/nova master: Add uuid field to BlockDeviceMapping https://review.openstack.org/524127 | |
| 13:07:00 | openstackgerrit | Matthew Booth proposed openstack/nova master: DriverBlockDevice: make subclasses inherit _proxy_as_attr https://review.openstack.org/524167 | |
| 13:07:25 | knsahm | the problem still exists | |
| 13:23:26 | openstackgerrit | Takashi NATSUME proposed openstack/nova stable/pike: Add 'delete_host' command in 'nova-manage cell_v2' https://review.openstack.org/513717 | |
| 13:33:37 | gibi | the weekly nova meeting will start in less than 30 minutes on #openstack-meeting | |
| 13:35:23 | jangutter | gibi: didn't you know? perl is a write-only language. | |
| 13:36:20 | efried | Only for those who don't know Perl | |
| 13:37:08 | gibi | readable only if the author did not know Perl well enough | |
| 13:38:05 | jangutter | I love that both opposing perspectives apply equally well! | |
| 13:53:50 | mriedem | takashin: i think i might know why this randomly fails https://review.openstack.org/#/c/524027/ | |
| 13:56:12 | takashin | mriedem: I don't know it. | |
| 13:57:14 | mriedem | i left a comment in there | |
| 13:58:37 | takashin | mriedem: I will check it. | |
| 13:59:57 | openstackgerrit | Eric Fried proposed openstack/nova master: Make _Provider really private https://review.openstack.org/523932 | |
| 13:59:57 | openstackgerrit | Eric Fried proposed openstack/nova master: ProviderTree.uuid_set() https://review.openstack.org/520243 | |
| 14:05:47 | gmann | alex_xu: gibi: stephenfin oomichi_afk can u check this, it is good to go now - https://review.openstack.org/#/c/500347/12 | |
| 14:18:45 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Assert that we restrict cold migrations to the same cell https://review.openstack.org/524035 | |
| 14:19:45 | mriedem | edleafe: before sydney we glanced at the conductor changes and had mentioned something about how we thought we should do something differently in there, which would require changes to the selection object, but i can't remember the details off hand atm, but that's what i'm referring to, and i haven't been back to the conductor changes in the series yet to see what you have changed | |
| 14:20:10 | gmann | jaypipes: for you - https://review.openstack.org/#/c/500347/12 | |
| 14:20:47 | jaypipes | gmann: ah, that's the one from Kevin Chen, yeah? | |
| 14:20:58 | gmann | yea | |
| 14:20:58 | jaypipes | gmann: you happy with that one now> | |
| 14:20:59 | jaypipes | ? | |
| 14:21:01 | jaypipes | k | |
| 14:21:09 | gmann | yea it looks good, m +1 | |
| 14:21:33 | edleafe | mriedem: the only thing I remember was the two RPC params instead of one | |
| 14:22:04 | jaypipes | gmann: +2 | |
| 14:22:25 | gmann | jaypipes: thanks | |
| 14:22:30 | jaypipes | gmann: np :) | |
| 14:22:34 | edleafe | mriedem: nothing about the Selection object | |
| 14:23:10 | edleafe | mriedem: and if something *does* come up, it can be addressed in a subsequent patch, no? | |
| 14:26:47 | mriedem | edleafe: referring to this https://review.openstack.org/#/c/511358/24/nova/conductor/manager.py@587 | |
| 14:28:05 | mriedem | i'm sorry this isn't all wrapped up already, sydney happened and dan and i have been dealing with cve fallout before sydney and after, draining time and energy on much else | |
| 14:28:51 | edleafe | mriedem: ah, that was changed the day you mentioned it. | |
| 14:29:16 | edleafe | it no longer relies on the emptiness of the allocation_request field | |
| 14:37:44 | efried | jaypipes I'd like to fix https://bugs.launchpad.net/nova/+bug/1735430 pretty quick here, would like to discuss possibilities. | |
| 14:37:45 | openstack | Launchpad bug 1735430 in OpenStack Compute (nova) "Report client doesn't handle RP create conflict (409) properly" [Undecided,New] | |
| 14:38:12 | jaypipes | efried: ok dokey | |
| 14:38:40 | jaypipes | efried: wouldn't it be nice if we had error *codes*? :( | |
| 14:38:55 | efried | jaypipes Like in the body of the response? | |
| 14:39:01 | jaypipes | efried: ya | |
| 14:39:23 | jaypipes | efried: so you could distinguish between bad name and bad UUID... for example | |
| 14:39:25 | efried | jaypipes Is there a reason we don't do that? | |
| 14:39:36 | jaypipes | efried: just never did it. I blame cdent. | |
| 14:39:50 | cdent | jaypipes: hah, I validated the api guideline that says it should happen | |
| 14:39:53 | cdent | I blame jaypipes | |
| 14:40:13 | efried | Okay, if there's no reason we're avoiding it, we could get started on that as a long-term solution. | |
| 14:40:13 | jaypipes | cdent: :) | |
| 14:40:26 | gibi | gmann: looking... | |
| 14:40:31 | jaypipes | efried: ack, though there are more pressing concerns at this point, no? | |
| 14:40:39 | efried | In the meantime: in PS2 I actually made us raise an exception: https://review.openstack.org/#/c/523932/2 | |
| 14:40:44 | cdent | efried: I think it was mostly just a kind of distraction in the early days and then forgotten | |
| 14:40:50 | cdent | however, it wouldn't make any difference in this bug | |
| 14:41:06 | efried | jaypipes That broke a functional test that runs _init_compute_host twice. cdent was helping me look at that last night. | |
| 14:41:28 | cdent | the 409 is the same in either case: uniqueness is violated and we require uniqueness. the bug isn't so much the response code as the return of None | |
| 14:41:35 | jaypipes | efried: sorry, I didn't mean the bug wasn't pressing. I meant reworking things so we have proper error codes. | |
| 14:41:45 | jaypipes | efried: as opposed to grepping through an error string | |
| 14:41:46 | efried | jaypipes Yeah, I'm with you. | |
| 14:42:00 | efried | jaypipes Hold on, are you saying we could grep the error string? | |
| 14:42:05 | efried | as an interim solution? | |
| 14:42:33 | jaypipes | efried: we've already done that in a couple places, yeah. | |
| 14:42:43 | cdent | the error string doesn't matter in this bug | |
| 14:43:12 | cdent | or rather the fact that we hide the error response in the expection message made it hard to debug | |
| 14:43:16 | jaypipes | cdent: well, the whole "the error is saying I used a bad UUID, when I actually used a bad name" is problematic. | |
| 14:43:26 | jaypipes | cdent: since they both have the same error message | |
| 14:43:26 | cdent | that's a different bug: | |
| 14:43:30 | jaypipes | cdent: ack | |
| 14:43:42 | cdent | https://bugs.launchpad.net/nova/+bug/1735405 | |
| 14:43:44 | openstack | Launchpad bug 1735405 in OpenStack Compute (nova) "Error message from placement when creating resource provider uses ambiguous identifier" [Undecided,New] | |
| 14:43:44 | efried | So let's say we do grep the error string - how would report client react that would be appropriate here? | |
| 14:43:53 | jaypipes | ok, agreed, diff bug | |
| 14:43:55 | cdent | the db duplicate response message does include which columns were duplicated | |
| 14:44:03 | cdent | I changed that some months ago | |
| 14:44:10 | cdent | but we hide that in the report client, and shouldn't | |
| 14:44:15 | jaypipes | efried: raise an exception back to the caller. | |
| 14:44:29 | jaypipes | cdent: gotcha | |
| 14:44:39 | cdent | why do we need to grep the error response? | |
| 14:44:48 | cdent | if uniqueness fails, uniqueness fails | |
| 14:44:58 | cdent | you can only get a 409 from post to /resource_providers for uniqueness fails | |
| 14:45:00 | jaypipes | cdent: in order to log an appropriate message, that's all | |
| 14:45:17 | jaypipes | cdent: it's just misleading to write an error saying bad UUID, when it was the name that was problematic | |
| 14:45:17 | cdent | pass on the response's error message, no need to parse it, just use it | |
| 14:45:40 | jaypipes | cdent: sure, can do that | |
| 14:46:09 | efried | Hold on | |
| 14:46:13 | efried | I don't agree | |
| 14:46:45 | efried | Right now we assume it's UUID conflict, so we GET the provider by UUID and return it (or None) | |
| 14:47:03 | cdent | the code is incomplete | |
| 14:47:16 | efried | Right | |
| 14:47:28 | cdent | if we want to assume that a 409 _could_ be "another thread created" | |
| 14:47:33 | cdent | then yes, parsing it required | |
| 14:47:52 | cdent | (or adding more detailed error codes, eventually) | |
| 14:48:36 | gibi | gmann_afk: +W | |
| 14:49:47 | cdent | but, then we have 409 meaning potentially 3 things: uuid uniqueness violation (good luck!), name uniqueness violation, concurrent violation | |
| 14:50:09 | cdent | and while telling some of those apart is gravy, the uuid ones, unclear | |