| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-05-25 | |||
| 09:55:50 | lyarwood | something like | |
| 09:56:19 | sean-k-mooney | like the tooling we have around bdm creation | |
| 09:56:25 | lyarwood | openstack volume attachment create --connector $(openstack volume connector fetch) --volume $volume-id | |
| 09:56:43 | sean-k-mooney | ya that would be nice | |
| 09:57:01 | lyarwood | but that would mean calling into os-brick | |
| 09:57:26 | sean-k-mooney | cant you get the connector info form cinder api | |
| 09:58:07 | lyarwood | the volume connector is a dict detailing the local hosts attributes like IQNs etc | |
| 09:58:36 | lyarwood | Nova just asks os-brick to generate it | |
| 09:59:00 | sean-k-mooney | ah right | |
| 09:59:06 | lyarwood | that's passed to c-api during attachment create and/or update to then map the volume to that specific host | |
| 09:59:08 | sean-k-mooney | cinder client has flags for all the fields | |
| 09:59:23 | sean-k-mooney | e.g. --iqn ectra | |
| 09:59:42 | lyarwood | I'm not sure if it has all the fields but tbh it would just be cleaner to have a blob generated by another command we can then pass in | |
| 10:00:09 | sean-k-mooney | for the nova usecase maybe | |
| 10:00:14 | sean-k-mooney | but for standalone you need both | |
| 10:00:48 | lyarwood | for true standalone yeah that's fair | |
| 10:00:58 | lyarwood | where you don't want os-brick on the host | |
| 10:01:07 | sean-k-mooney | https://docs.openstack.org/python-cinderclient/latest/cli/details.html#cinder-attachment-create | |
| 10:01:08 | lyarwood | but tbh with os-brick we could even connect the volumes | |
| 10:01:20 | sean-k-mooney | so the iqn is --initiator | |
| 10:01:41 | sean-k-mooney | you can also se the host/ip exctra | |
| 10:01:52 | sean-k-mooney | andn if you pass --connect | |
| 10:02:00 | sean-k-mooney | it generates teh connoctor info | |
| 10:02:53 | sean-k-mooney | other then a lack of docsn which i was ment to go write ... teh cinder cli parmaters seams to work well | |
| 10:03:28 | lyarwood | right my point was that the connector dict we get from os-brick can contain alot more info that the options there | |
| 10:03:41 | sean-k-mooney | oh ok | |
| 10:03:47 | lyarwood | that's just the basics for iSCSI etc | |
| 10:04:01 | lyarwood | it doesn't cover FC | |
| 10:04:07 | lyarwood | NVMeOF etc | |
| 10:04:46 | sean-k-mooney | well the initiator is generic it does not have to be an iscsi one but ya i get your point not everything is exposed | |
| 10:04:59 | sean-k-mooney | osc could call into os-brick | |
| 10:05:13 | sean-k-mooney | but may os-brick should call the sdk | |
| 10:05:30 | sean-k-mooney | and we sould move the code for the connector generation | |
| 10:05:45 | sean-k-mooney | then osc can call the sdk without needing os-brick | |
| 10:06:15 | sean-k-mooney | lyarwood: i think osc currently calls python-client | |
| 10:06:34 | sean-k-mooney | *cinder-client | |
| 10:06:50 | sean-k-mooney | does cinder clinet depend on os-brick for its local-attch command | |
| 10:08:08 | sean-k-mooney | ah no | |
| 10:08:15 | sean-k-mooney | thats packaged seperatly in python-brick-cinderclient-ext | |
| 10:08:35 | sean-k-mooney | https://specs.openstack.org/openstack/cinder-specs/specs/mitaka/use-cinder-without-nova.html | |
| 10:24:30 | openstackgerrit | Merged openstack/nova stable/rocky: Update pci stat pools based on PCI device changes https://review.opendev.org/c/openstack/nova/+/761824 | |
| 10:47:20 | openstackgerrit | Hemanth N proposed openstack/nova stable/queens: Update pci stat pools based on PCI device changes https://review.opendev.org/c/openstack/nova/+/761825 | |
| 10:56:41 | gibi | bauzas: I've left questions in https://review.opendev.org/c/openstack/nova-specs/+/792796 feel free to ping me if you want real time discussion | |
| 11:02:16 | sean-k-mooney | lyarwood: i responded to the open question on https://review.opendev.org/c/openstack/nova-specs/+/783806 but have not done a rereview but i removed my -1 since you adress my previous concerns | |
| 11:02:23 | sean-k-mooney | lyarwood: ill try an review that again today | |
| 11:02:33 | sean-k-mooney | lyarwood: are you currently wroking on a new reviewion? | |
| 11:02:42 | sean-k-mooney | *revision | |
| 11:03:21 | lyarwood | sean-k-mooney: I was trying to but tbh I'm totally distracted waiting for a phone call from the hospital, I'll wait for your review and respin it later today if that's okay | |
| 11:03:58 | lyarwood | /me has been waiting for the call since 8:30am, damn NHS. | |
| 11:08:17 | sean-k-mooney | lyarwood: ok i dont know if i have any real changes that i want you to make there are thing we discussed previosly but i expect any comment i add to be relitvly minor | |
| 11:08:37 | lyarwood | ack kk | |
| 12:05:58 | masterpe | Hi, In train when I use the command ./nova-manage db archive_deleted_rows with --before it will a long time before it completed the command. Even tho I use a --max_rows 1000. Without the --before option it is a lot faster. When I do a SHOW INDEX FROM nova.instances; on the database I think I don't see any indexes on the deleted_at column. | |
| 12:08:57 | sean-k-mooney | masterpe: --before is intedned to be run requently as in daily | |
| 12:09:17 | sean-k-mooney | so typicaly it would be used to delete rows over say 90 days | |
| 12:09:35 | sean-k-mooney | and you would do that daily so its only removeing 1 days worth at a time | |
| 12:10:38 | masterpe | Without before it is doing everything? | |
| 12:11:24 | sean-k-mooney | if you dont set anything i think so | |
| 12:12:08 | sean-k-mooney | its slighly painful to do the initall catch up but once you get it to the time period you want to retain --before is generally our recomended way to do this | |
| 12:35:17 | bauzas | gibi: sorry, I was afk | |
| 12:35:48 | sean-k-mooney | bauzas: im making my way through your mdev spec currently too by the way | |
| 12:36:05 | sean-k-mooney | mainly grammer nits/word chocices so far nothing technical | |
| 12:36:09 | bauzas | sean-k-mooney: okay, then we could be discussing about this spec once you look at it | |
| 12:36:46 | sean-k-mooney | actully just got to a technical point | |
| 12:36:58 | sean-k-mooney | i do not belive we should limit the resouce class | |
| 12:37:13 | sean-k-mooney | and i do not belive we should have a singel generic mdev class | |
| 12:37:41 | sean-k-mooney | we should support Custom_ resouce classes | |
| 12:37:54 | sean-k-mooney | im undecieded if we shoudl supprot standard ones or not | |
| 12:38:25 | masterpe | But I see that "nova-manage db archive_deleted_rows" command uses a filter on the deleted_at column when using the --before option. But on that column is no index. | |
| 12:40:00 | bauzas | sean-k-mooney: well, then we would need to ask the operator to provide which custom RC they'd like to get | |
| 12:40:13 | sean-k-mooney | bauzas: yes | |
| 12:40:36 | sean-k-mooney | so must remove choices form mdev_class | |
| 12:40:45 | sean-k-mooney | and allow it to be just a sting | |
| 12:41:17 | sean-k-mooney | we can desided to limit it in python to Custom_ if we want too or not | |
| 12:41:33 | gibi | bauzas: no worries. I'm on a call, but I will try to multitask :) | |
| 12:53:58 | admin0 | lyarwood, do we save any version info or migration info in the nova database .. i have a nova database which is fairly old ..and i need to figure out if its from newton, ocata or pike | |
| 12:58:34 | bauzas | gibi: I soft+1d again your PUT RP spec | |
| 12:58:43 | bauzas | gibi: with another API alternative | |
| 12:59:12 | bauzas | in my mind, QS parameters are just another way to pass attributes without using data | |
| 12:59:36 | bauzas | so, generally those params should be identical to the resource attributes | |
| 12:59:50 | gibi | QS are not part of the object representation, while the body is. So whatever we add to the body we make it part of the object as per REST | |
| 13:00:08 | bauzas | gibi: I proposed to use a sub-resource for this | |
| 13:00:37 | bauzas | /force is maybe a bad name | |
| 13:01:23 | gibi | resource_providers/{uuid}/force feels like an action API that is also not that restful | |
| 13:02:21 | sean-k-mooney | bauzas: ok just pushed my comments on your spec | |
| 13:02:25 | gibi | bauzas: so you feel that we cannot add param to the QS that is not part of the body? | |
| 13:02:59 | sean-k-mooney | admin0: i belive we do have a version for the schema yes | |
| 13:03:07 | sean-k-mooney | admin0: i think there is a nova manage command to get it | |
| 13:03:31 | gibi | admin0: mysql> select * from migrate_version; | |
| 13:03:34 | gibi | | repository_id | repository_path | version | | |
| 13:03:39 | sean-k-mooney | admin0: nova-manage db version | |
| 13:03:40 | gibi | | nova | /opt/stack/nova/nova/db/sqlalchemy/migrate_repo | 422 | | |
| 13:03:43 | gibi | +---------------+-------------------------------------------------+---------+ | |
| 13:03:57 | gibi | admin0: or wha sean-k-mooney suggessts | |
| 13:04:14 | sean-k-mooney | ^ is teh db table its reading form | |
| 13:04:40 | sean-k-mooney | so if you have a backup you have not loaded gibi's way might be quicker to grep for | |
| 13:05:04 | sean-k-mooney | there is also nova-manage api_db version | |
| 13:05:06 | bauzas | gibi: as I said in my last comment, the current API is not RESTful either way | |
| 13:05:18 | sean-k-mooney | nova-manage db version tells you the cell db version | |
| 13:06:23 | sean-k-mooney | bauzas: the resful way to update the parent uuid woudl be jsut to update it | |
| 13:06:35 | sean-k-mooney | so a put to resource_providers/{uuid} | |