| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-06-19 | |||
| 06:49:32 | gmann | like - https://opendev.org/openstack/nova/src/branch/master/nova/api/openstack/compute/volumes.py#L354 | |
| 06:50:23 | gmann | HTTPBadRequest can occur due to multiple reason and their details are in error message | |
| 06:52:54 | gmann | amotoki: Horizon showing the error message which include the error details for example: "invalid volume id is request" not enough ? or you want to prepare some addition helpful error msg ? | |
| 06:54:00 | gmann | novaclient also decode them into ClientException - https://github.com/openstack/python-novaclient/blob/003ac57d9af74aa4658a7bf6cc6b6b3bafa58c11/novaclient/exceptions.py#L249 | |
| 06:56:44 | amotoki | gmann: thanks for checking. The horizon patch I mentioned above is to try to show a message from nova API as-is instead of showing a generic message "Unable to attach volume". | |
| 06:57:29 | openstackgerrit | Takashi NATSUME proposed openstack/python-novaclient master: Add irrelevant files in dsvm job https://review.opendev.org/666217 | |
| 06:57:52 | amotoki | gmann: it is generally a thing avoided in horizon (as messages cannot be translated and sometimes they are not friendly to GUI users) but we don't have a good idea for this case. | |
| 06:58:19 | gmann | amotoki: i see your point. | |
| 06:58:24 | amotoki | gmann: my initial question is whether we can assume BadRequest only for that case. | |
| 06:58:55 | amotoki | gmann: for example, I wonder BadRequest can be raised for input validation or something others. | |
| 06:59:23 | gmann | amotoki: it is hard to say, there can be various other error can be raised by Nova which is API specific and many times we do add/improve the exception | |
| 07:00:13 | gmann | amotoki: how about putting else only in case of 500 error code. ex.htttp_status == 500 | |
| 07:01:02 | gmann | and for rest all, horizon can use the ex.msg as it is. which is much reliable because nova API prepare that error msg explicitly. | |
| 07:01:19 | amotoki | gmann: in a best case, we can catch a specific exception and show an appropriate message by horizon..... | |
| 07:01:48 | amotoki | gmann: for example, horizon tries to hide UUID but most API messages include UUID :-( | |
| 07:02:01 | gmann | 2nd option is: include all possible exception per APIs which you can get info from API ref | |
| 07:02:48 | gmann | amotoki: yeah so you can do that. but in that case you need to decode the error message. because error message include the details of "why it is BadRequest" | |
| 07:04:28 | gmann | amotoki: does neutron client hide such info ? or horizon does ? | |
| 07:04:33 | amotoki | gmann: yeah, that's the dilemma.... if English is the only language it would be much much simpler | |
| 07:04:53 | gmann | yeah. it depends on locale | |
| 07:05:10 | amotoki | gmann: this is neutronclient code https://opendev.org/openstack/python-neutronclient/src/branch/master/neutronclient/v2_0/client.py#L65-L73 | |
| 07:06:33 | amotoki | gmann: 'type' contains an exception name in neutron server and if a specific exception is defined in https://opendev.org/openstack/python-neutronclient/src/branch/master/neutronclient/common/exceptions.py#L136 neutronclient raises a corresponding exception to callers. | |
| 07:06:44 | gmann | amotoki: so it does include the complete 'error_message' send from neutron API correct ? | |
| 07:07:47 | gmann | amotoki: novaclient does the same - https://opendev.org/openstack/python-novaclient/src/branch/master/novaclient/exceptions.py#L249-L276 | |
| 07:08:16 | amotoki | gmann: yes, the general format of an exception message is like: {"type": "fooException", "message": "...."} | |
| 07:08:37 | amotoki | gmann: we add new entries to neutronclient/common/exceptions.py per request from consumers. | |
| 07:09:36 | amotoki | but in this case it looks better to concatenate (translatable) "Unable to attach volume" with a message from nova API. | |
| 07:09:50 | gmann | amotoki: yeah, nova has only high level exception only not so rich like neutronclient | |
| 07:10:02 | amotoki | what I think is to catch exceptions related to multi-attach and send a specific error message. | |
| 07:10:26 | amotoki | so I wonder there is a way to distinguish multi-attached related exceptions from otherr BadRequest. | |
| 07:10:39 | gmann | amotoki: hummm. that is good idea. I am just wondering how many such Client exception we need to add in nova case | |
| 07:10:42 | amotoki | but it looks not easy now. | |
| 07:11:08 | gmann | attach volume has only 5-6 exception which is not so hard | |
| 07:12:02 | gmann | but see the server boot exceptions - https://opendev.org/openstack/nova/src/branch/master/nova/api/openstack/compute/servers.py#L695-L763 | |
| 07:12:36 | amotoki | yeah I know it | |
| 07:13:15 | gmann | is it too bad to show UUID in horizon? i mean horizon will be showing it to owner or admin only | |
| 07:13:45 | gmann | or you find nova exception error message include more details which can cause security issue | |
| 07:15:54 | amotoki | in the current impl of horizon, if UUID is shown to users, they sometimes need to fallback into CLI. | |
| 07:16:37 | amotoki | I don't think it can be a security issue. it is just an usability topic. | |
| 07:16:47 | gmann | yeah | |
| 07:16:54 | amotoki | UUID is shown only in the detail page in most cases. | |
| 07:22:18 | gmann | amotoki: i replied to either include all possible exception or check case of 500. | |
| 07:22:41 | amotoki | gmann: thanks. | |
| 07:22:46 | amotoki | gmann: http://specs.openstack.org/openstack/api-sig/guidelines/errors.html might be a candidate (though I don't think it is implemented) | |
| 07:23:26 | amotoki | gmann: neutron API does similar thing in a different way https://opendev.org/openstack/neutron/src/branch/master/neutron/api/api_common.py#L512-L524 | |
| 07:23:47 | amotoki | gmann: anyway thanks for the discussion. really appreciated. | |
| 07:28:54 | gmann | amotoki: yeah standard error format is the missing part. NovaException does not provide scuh better way like neutron does. we have only 'code' and 'message'. | |
| 07:31:29 | gmann | amotoki: let me see sometime ( when i will be free) if we can have such wrapper method in NovaException to fetch the data in more standard way. | |
| 07:31:38 | gmann | thanks for reporting it. | |
| 08:04:36 | openstackgerrit | Josephine Seifert proposed openstack/nova-specs master: Spec for the Nova part of Image Encryption https://review.opendev.org/608696 | |
| 08:15:39 | openstackgerrit | Josephine Seifert proposed openstack/nova-specs master: Spec for the Nova part of Image Encryption https://review.opendev.org/608696 | |
| 08:24:17 | openstackgerrit | jiasirui proposed openstack/nova-specs master: fix the spelling mistakes https://review.opendev.org/666244 | |
| 08:28:05 | shilpasd | <efried> i am facing issue in n-cpu start, due to nova/db/sqlalchemy/migrate_repo/versions/397_migrations_cross_cell_move.py | |
| 08:28:20 | shilpasd | efried: this got commited at https://review.opendev.org/#/c/614012/ | |
| 08:28:36 | shilpasd | error is:Error starting thread.: RemoteError: Remote error: DBError (pymysql.err.InternalError) (1054, u"Unknown column 'migrations.cross_cell_move' in 'field list'") | |
| 08:28:53 | shilpasd | i have run db manage command, but no success | |
| 08:28:59 | shilpasd | any solution? | |
| 08:30:36 | shilpasd | efried: mriedem: here is the detailed error log, http://paste.openstack.org/show/753170/ | |
| 08:44:08 | openstackgerrit | Martin Midolesov proposed openstack/nova master: Implementing graceful shutdown. https://review.opendev.org/666245 | |
| 09:38:20 | openstackgerrit | Merged openstack/nova master: Fix wrong assert methods https://review.opendev.org/665897 | |
| 09:50:45 | openstackgerrit | zhaixiaojun proposed openstack/python-novaclient master: Modify the url of upper_constraints_file https://review.opendev.org/665934 | |
| 09:57:53 | openstackgerrit | Stephen Finucane proposed openstack/nova master: xvp: Start using consoleauth tokens https://review.opendev.org/652967 | |
| 09:57:54 | openstackgerrit | Stephen Finucane proposed openstack/nova master: xvp: Remove use of '_LI' marker https://review.opendev.org/665425 | |
| 09:57:54 | openstackgerrit | Stephen Finucane proposed openstack/nova master: nova-status: Remove consoleauth workaround check https://review.opendev.org/652968 | |
| 09:57:55 | openstackgerrit | Stephen Finucane proposed openstack/nova master: Remove nova-consoleauth https://review.opendev.org/652969 | |
| 09:57:55 | openstackgerrit | Stephen Finucane proposed openstack/nova master: objects: Remove ConsoleAuthToken.to_dict https://review.opendev.org/652970 | |
| 09:57:56 | openstackgerrit | Stephen Finucane proposed openstack/nova master: docs: Rework nova console diagram https://review.opendev.org/660147 | |
| 09:57:56 | openstackgerrit | Stephen Finucane proposed openstack/nova master: docs: Integrate 'sphinx.ext.imgconverter' https://review.opendev.org/665693 | |
| 09:58:14 | openstackgerrit | Surya Seetharaman proposed openstack/nova master: Grab fresh info from the driver during nova start/stop actions https://review.opendev.org/665975 | |
| 10:21:07 | openstackgerrit | Stephen Finucane proposed openstack/nova master: tests: Use consistent URL regex substitution https://review.opendev.org/665949 | |
| 11:18:07 | ohwhyosa | hey there! I uploaded an iso ubuntu-server-18.04 (not live) and when connecting via console to the instance, it does detect it (it lets me get to the keymap selection part) but then it complains no cd-rom image is mounted, any idea why might that be? | |
| 11:21:19 | sean-k-mooney | not really while you can use iso its a little complicated in that you generally have to also a data volume to install to | |
| 11:22:24 | sean-k-mooney | when you select the iso as a disk image it gets attached as the root disk. im not sure if it is attahced as a cdrom or not | |
| 11:23:08 | ohwhyosa | thanks sean-k-mooney! the recommendation would be using other image formats if available then, right? | |
| 11:23:44 | sean-k-mooney | well normally you would locally install it in a vm and then upload that to the cloud or use a prebuild image | |
| 11:25:12 | sean-k-mooney | you can enable a boot menu too. you can convert the iso into a data volume in cinder and then boot an instance with a blank volume and install too but in generall you are better off preparing the image first rather then trying to do it in openstack | |
| 11:25:54 | ohwhyosa | nova.console.websocketproxy keeps on saying broken pipe, by the way, tried the openstack-ansible multinode and the aio (which should set up all the networking correctly by itself) | |
| 11:26:16 | ohwhyosa | It is only the console service that broken pipes, just saying in case there might be an issue behind it | |
| 11:26:24 | ohwhyosa | I used both latest and stein | |
| 11:26:28 | ohwhyosa | stable/stein | |
| 11:26:55 | sean-k-mooney | im not sure that sound more like a spice server or websockify issue rather then nova | |
| 11:27:15 | sean-k-mooney | ohwhyosa: if you have not seen https://github.com/openstack/diskimage-builder you should check it out | |
| 11:28:04 | sean-k-mooney | there is also virt-builder but tool like those are how people usually prepare image for openstack | |
| 11:29:21 | ohwhyosa | sean-k-mooney, thanks a ton! (and it happened both with noVNC and spice, but it is indeed happening with websockify) | |
| 13:01:45 | efried | shilpasd: You've hit this: https://review.opendev.org/#/c/614012/ | |
| 13:01:58 | efried | shilpasd: sorry, you already said that. | |
| 13:02:18 | efried | are your conductor & computes running at the same level? | |
| 13:10:16 | shilpasd | efried: yes | |
| 13:10:50 | efried | shilpasd: In any case this sounds like a bug (it should behave better than that even if versions are mismatched) but something mriedem will have to look at once he gets here. | |
| 13:12:42 | efried | there he is :) | |
| 13:12:49 | shilpasd | efried: ok | |
| 13:12:51 | shilpasd | yes | |
| 13:14:22 | shilpasd | mriedem: i am getting http://paste.openstack.org/show/753170/ while service restart on master, can you help here to solve | |
| 13:14:25 | alex_xu | mriedem: we replied your comment on vpmem. also explored the bdm, let us know your thought | |
| 13:15:13 | alex_xu | mriedem: sean-k-mooney also in case you don't know, we already submit the vpmem code to gerrit https://review.opendev.org/#/q/status:open+project:openstack/nova+branch:master+topic:bp/virtual-persistent-memory, hope that is helpful on review spec | |
| 13:15:40 | mriedem | shilpasd: looks like you upgraded code without syncing the database | |
| 13:16:17 | shilpasd | mriedem: nova-manage db sync, is run still the issue | |
| 13:16:37 | shilpasd | any other command to be run? | |
| 13:18:45 | sean-k-mooney | alex_xu: sorry i have kept defering re reviewing https://review.opendev.org/#/c/601596/ ill grab a cup of coffee and go review before my next meeting | |
| 13:19:17 | alex_xu | sean-k-mooney: no problem, thanks | |