| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-04-14 | |||
| 20:35:00 | sean-k-mooney | that should retrun true an print the message | |
| 20:35:05 | sean-k-mooney | did you get that message printed | |
| 20:35:05 | sean-k-mooney | did you get that message printed | |
| 20:35:23 | noonedeadpunk | cell.database_connection here is resolved and `mysql+pymysql://nova:534d29a090559b5a6345122e999a8ef29f67@172.29.236.101/nova?charset=utf8` but database_connection is `{scheme}://{username}:{password}@{hostname}/{path}?{query}` | |
| 20:35:23 | noonedeadpunk | cell.database_connection here is resolved and `mysql+pymysql://nova:534d29a090559b5a6345122e999a8ef29f67@172.29.236.101/nova?charset=utf8` but database_connection is `{scheme}://{username}:{password}@{hostname}/{path}?{query}` | |
| 20:35:28 | sean-k-mooney | looking at http://paste.openstack.org/show/804488/ no | |
| 20:35:28 | sean-k-mooney | looking at http://paste.openstack.org/show/804488/ no | |
| 20:35:52 | sean-k-mooney | noonedeadpunk: ah ok | |
| 20:35:52 | sean-k-mooney | noonedeadpunk: ah ok | |
| 20:36:19 | noonedeadpunk | as when we run objects.CellMappingList.get_all(ctxt) we end up in https://opendev.org/openstack/nova/src/branch/master/nova/objects/cell_mapping.py#L159-L169 | |
| 20:36:19 | noonedeadpunk | as when we run objects.CellMappingList.get_all(ctxt) we end up in https://opendev.org/openstack/nova/src/branch/master/nova/objects/cell_mapping.py#L159-L169 | |
| 20:36:22 | sean-k-mooney | that porbaly happing when we load the object form the db | |
| 20:36:22 | sean-k-mooney | that porbaly happing when we load the object form the db | |
| 20:36:33 | sean-k-mooney | yep | |
| 20:36:56 | noonedeadpunk | yep, and we trigger it here https://opendev.org/openstack/nova/src/branch/master/nova/objects/cell_mapping.py#L258 | |
| 20:36:56 | noonedeadpunk | yep, and we trigger it here https://opendev.org/openstack/nova/src/branch/master/nova/objects/cell_mapping.py#L258 | |
| 20:37:18 | sean-k-mooney | so we need to do this https://opendev.org/openstack/nova/src/branch/master/nova/objects/cell_mapping.py#L162-L165 | |
| 20:37:18 | sean-k-mooney | so we need to do this https://opendev.org/openstack/nova/src/branch/master/nova/objects/cell_mapping.py#L162-L165 | |
| 20:37:25 | sean-k-mooney | in the nova manage command | |
| 20:37:25 | sean-k-mooney | in the nova manage command | |
| 20:37:27 | noonedeadpunk | So I was thinking to add an extra argumet or adjust context, so that it contained like `template_resolve=false` | |
| 20:37:27 | noonedeadpunk | So I was thinking to add an extra argumet or adjust context, so that it contained like `template_resolve=false` | |
| 20:37:56 | sean-k-mooney | noonedeadpunk: i think it would be simpler just to reolve the unresolved one | |
| 20:37:56 | sean-k-mooney | noonedeadpunk: i think it would be simpler just to reolve the unresolved one | |
| 20:38:08 | sean-k-mooney | by calling cell_mapping.format_db_url | |
| 20:38:08 | sean-k-mooney | by calling cell_mapping.format_db_url | |
| 20:38:25 | sean-k-mooney | in this if https://opendev.org/openstack/nova/src/commit/9e5feb051c15166988e87b10132927135bd56884/nova/cmd/manage.py#L623-L624 | |
| 20:38:25 | sean-k-mooney | in this if https://opendev.org/openstack/nova/src/commit/9e5feb051c15166988e87b10132927135bd56884/nova/cmd/manage.py#L623-L624 | |
| 20:38:42 | noonedeadpunk | well, that would have side effect, that in case config on the node where we run nova-manage differs, new cell will be created anyway | |
| 20:38:42 | noonedeadpunk | well, that would have side effect, that in case config on the node where we run nova-manage differs, new cell will be created anyway | |
| 20:39:07 | noonedeadpunk | so I think we should compare what we have in database and what we're about to add there | |
| 20:39:07 | noonedeadpunk | so I think we should compare what we have in database and what we're about to add there | |
| 20:40:06 | sean-k-mooney | well the cell.database_connection value is being formated with your local nova.conf too | |
| 20:40:06 | sean-k-mooney | well the cell.database_connection value is being formated with your local nova.conf too | |
| 20:41:47 | sean-k-mooney | noonedeadpunk: so for your actul usecase you could list the cells and check if the cell is present with that name already | |
| 20:41:47 | sean-k-mooney | noonedeadpunk: so for your actul usecase you could list the cells and check if the cell is present with that name already | |
| 20:41:51 | noonedeadpunk | yes, but I may depend from node to node? | |
| 20:41:51 | noonedeadpunk | yes, but I may depend from node to node? | |
| 20:42:01 | sean-k-mooney | and only create it if it does not exits | |
| 20:42:01 | sean-k-mooney | and only create it if it does not exits | |
| 20:42:26 | noonedeadpunk | *it may depend | |
| 20:42:26 | noonedeadpunk | *it may depend | |
| 20:43:03 | sean-k-mooney | well nova-manage is only run on the controler nodes right and typically only one of the contoler per cell | |
| 20:43:03 | sean-k-mooney | well nova-manage is only run on the controler nodes right and typically only one of the contoler per cell | |
| 20:43:23 | sean-k-mooney | you do not normally run it on compute nodes for example | |
| 20:43:23 | sean-k-mooney | you do not normally run it on compute nodes for example | |
| 20:44:20 | noonedeadpunk | I mean shouldn't be there a valid protection, that exact same cells are not present in DB with different UUIDs? | |
| 20:44:20 | noonedeadpunk | I mean shouldn't be there a valid protection, that exact same cells are not present in DB with different UUIDs? | |
| 20:44:23 | sean-k-mooney | noonedeadpunk: checking the db content wont work i this case actully | |
| 20:44:23 | sean-k-mooney | noonedeadpunk: checking the db content wont work i this case actully | |
| 20:45:20 | sean-k-mooney | i think the cell name is really the unique thing | |
| 20:45:20 | sean-k-mooney | i think the cell name is really the unique thing | |
| 20:45:29 | sean-k-mooney | ingoring the sharding usecase | |
| 20:45:30 | sean-k-mooney | ingoring the sharding usecase | |
| 20:45:34 | sean-k-mooney | that is not currently implemetned | |
| 20:45:34 | sean-k-mooney | that is not currently implemetned | |
| 20:47:11 | sean-k-mooney | dansmith: actully i dont think we can support the sharding usecase with the current db schema without denormalising the database | |
| 20:47:11 | sean-k-mooney | dansmith: actully i dont think we can support the sharding usecase with the current db schema without denormalising the database | |
| 20:47:18 | noonedeadpunk | but at least combination of name+transport_url+database_connection should be unique IMO. And considering templates, I see the only way to do that is to check here https://opendev.org/openstack/nova/src/commit/9e5feb051c15166988e87b10132927135bd56884/nova/cmd/manage.py#L623-L624 that cell.database_connection is still in tempate format, but not transformed | |
| 20:47:18 | noonedeadpunk | but at least combination of name+transport_url+database_connection should be unique IMO. And considering templates, I see the only way to do that is to check here https://opendev.org/openstack/nova/src/commit/9e5feb051c15166988e87b10132927135bd56884/nova/cmd/manage.py#L623-L624 that cell.database_connection is still in tempate format, but not transformed | |
| 20:47:36 | sean-k-mooney | dansmith: we would realy need to have a second db table that mapped db urls to the cell id or similar | |
| 20:47:36 | sean-k-mooney | dansmith: we would realy need to have a second db table that mapped db urls to the cell id or similar | |
| 20:48:02 | noonedeadpunk | I kind of submitted bug regarding this https://bugs.launchpad.net/nova/+bug/1923899 as well | |
| 20:48:02 | noonedeadpunk | I kind of submitted bug regarding this https://bugs.launchpad.net/nova/+bug/1923899 as well | |
| 20:48:04 | openstack | Launchpad bug 1923899 in OpenStack Compute (nova) "Nova create duplicate cells when templates are used" [Undecided,New] | |
| 20:48:04 | openstack | Launchpad bug 1923899 in OpenStack Compute (nova) "Nova create duplicate cells when templates are used" [Undecided,New] | |
| 20:48:09 | dansmith | sean-k-mooney: yeah, above I said that was the original intent to be able to do that, but that we'd still have work to do to make it work | |
| 20:48:09 | dansmith | sean-k-mooney: yeah, above I said that was the original intent to be able to do that, but that we'd still have work to do to make it work | |
| 20:49:20 | noonedeadpunk | sorry for late discussion, already midnight here, so need to head out :( | |
| 20:49:20 | noonedeadpunk | sorry for late discussion, already midnight here, so need to head out :( | |
| 20:49:39 | sean-k-mooney | no worries | |
| 20:50:42 | sean-k-mooney | i think if we jsut put a unique constarint on name that would be enough. if we want to supprot sharding we would need to have a second table with something like (id, cell_id, db | |
| 20:50:42 | sean-k-mooney | i think if we jsut put a unique constarint on name that would be enough. if we want to supprot sharding we would need to have a second table with something like (id, cell_id, db | |
| 20:50:50 | noonedeadpunk | eventually what I intended to do is to rely on cell_create command return code, and if it's 2 - update_cell, if 0 - proceed with setup. And for me it's now always 0 when using templates :( | |
| 20:50:50 | noonedeadpunk | eventually what I intended to do is to rely on cell_create command return code, and if it's 2 - update_cell, if 0 - proceed with setup. And for me it's now always 0 when using templates :( | |
| 20:51:01 | sean-k-mooney | (id, cell_id, db_url, db_table) | |
| 20:51:01 | sean-k-mooney | (id, cell_id, db_url, db_table) | |
| 20:51:42 | sean-k-mooney | noonedeadpunk: ya for now i guess you have to check and not use the return code | |
| 20:51:42 | sean-k-mooney | noonedeadpunk: ya for now i guess you have to check and not use the return code | |
| 20:51:59 | sean-k-mooney | but i think the bug is more or less valid and we should be returning 2 | |
| 20:51:59 | sean-k-mooney | but i think the bug is more or less valid and we should be returning 2 | |
| 20:52:02 | noonedeadpunk | yeah:( | |
| 20:52:02 | noonedeadpunk | yeah:( | |
| 20:53:24 | sean-k-mooney | dansmith: im not sure how ye were thinking about shardin gby the way so you might not need to do it by table so maybe the other table would just be (id, cell_id, db_url) not (id, cell_id, db_url, db_table) | |
| 20:53:24 | sean-k-mooney | dansmith: im not sure how ye were thinking about shardin gby the way so you might not need to do it by table so maybe the other table would just be (id, cell_id, db_url) not (id, cell_id, db_url, db_table) | |
| 20:55:15 | sean-k-mooney | but the impotant thing is we would need to model the many to one relation ship while maintianing only on uuid per cell | |
| 20:55:15 | sean-k-mooney | but the impotant thing is we would need to model the many to one relation ship while maintianing only on uuid per cell | |
| 21:06:10 | mnaser | i've been noticing an issue where in a scenario that libvirt loses config, when using vgpu, and doing a hard reboot generates xml that _does not_ contain the vgpu | |
| 21:06:10 | mnaser | i've been noticing an issue where in a scenario that libvirt loses config, when using vgpu, and doing a hard reboot generates xml that _does not_ contain the vgpu | |
| 21:06:47 | mnaser | to reproduce: openstack server stop <instance>; virsh undefine <instance>; openstack server start <instance>; virsh dumpxml <instance> ... no mdev | |
| 21:06:47 | mnaser | to reproduce: openstack server stop <instance>; virsh undefine <instance>; openstack server start <instance>; virsh dumpxml <instance> ... no mdev | |
| 21:12:07 | mnaser | https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L3453-L3456 | |
| 21:12:07 | mnaser | https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L3453-L3456 | |
| 21:13:09 | mnaser | this is starting to sound like mdev state is actually conserved in libvirt domains? | |
| 21:13:09 | mnaser | this is starting to sound like mdev state is actually conserved in libvirt domains? | |
| 21:57:42 | melwitt | mnaser: this seems kinda related https://bugs.launchpad.net/nova/+bug/1900800 | |
| 21:57:42 | melwitt | mnaser: this seems kinda related https://bugs.launchpad.net/nova/+bug/1900800 | |
| 21:57:43 | openstack | Launchpad bug 1900800 in OpenStack Compute (nova) "VGPUs is not recreated on host reboot" [Low,Confirmed] - Assigned to Sylvain Bauza (sylvain-bauza) | |
| 22:01:19 | mnaser | melwitt: that’s exactly it | |
| 22:01:19 | mnaser | melwitt: that’s exactly it | |