| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-05-25 | |||
| 08:53:07 | stephenfin | but I can't get it to move from attaching to attached. Not sure if it's me or my DevStack deploy or what | |
| 08:53:24 | stephenfin | the cinder docs are significantly worse than even the nova docs :( | |
| 08:54:19 | lyarwood | oh there's a final API call to cinder to complete the attachment | |
| 08:54:25 | lyarwood | that moves it from attaching to attached | |
| 08:54:44 | lyarwood | I'm not sure if there's a command for that in cinderclient tbh | |
| 08:55:10 | lyarwood | https://docs.openstack.org/api-ref/block-storage/v3/index.html#complete-attachment | |
| 08:55:11 | stephenfin | * stephenfin wonders what good is attachment-create so :D | |
| 08:55:22 | stephenfin | oh, that exists | |
| 08:55:31 | stephenfin | cinder attachment-complete | |
| 08:55:43 | lyarwood | cool, use that and it should move | |
| 08:56:14 | lyarwood | well create on it's own is useful when we just need to reserve (create without a connector) I guess | |
| 08:56:23 | lyarwood | but if you want to do the entire workflow it's a PITA at the moment | |
| 08:56:31 | lyarwood | a higher level command that does all three would be cool | |
| 08:56:35 | lyarwood | create, update and complete | |
| 08:56:56 | lyarwood | but then that doesn't actually attach it on the nova side | |
| 08:57:11 | lyarwood | so it's only going to be useful in terms of mapping a volume to a host | |
| 08:59:22 | stephenfin | aha, complete did the trick alright | |
| 08:59:39 | stephenfin | I assume there's no way to trigger things on the nova side without invoking the whole flow though? | |
| 08:59:49 | stephenfin | * stephenfin apologises for his lack of knowledge in this area | |
| 09:00:27 | lyarwood | not at the moment, this is why I've wanted to write some nova-manage commands so we can update our BDMs with the attachment_id and connection_info you've just created here | |
| 09:00:31 | lyarwood | for SHUTDOWN instances etc | |
| 09:00:48 | lyarwood | and/or to have nova-manage orchestrate the entire flow to refresh things | |
| 09:04:17 | lyarwood | stephenfin: https://docs.openstack.org/nova/latest/reference/attach-volume.html FWIW | |
| 09:06:15 | stephenfin | lyarwood: is it fair to say that 'cinder attachment-create' doesn't really need to be a user-facing command so? | |
| 09:06:25 | stephenfin | it's a machine API, effectively | |
| 09:06:50 | stephenfin | context being we're implementing this in OSC and I'm trying to decide if we should since I can't figure out how to use it | |
| 09:07:05 | lyarwood | As I said above, I've used it a few times just to reserve things so I wouldn't want to remove it unless I had another command | |
| 09:07:27 | lyarwood | for context, we reserve attachments when shelving | |
| 09:07:56 | lyarwood | and in the past when that has failed for whatever reason I've found it useful to create fresh attachments and update Nova's BDMs | |
| 09:08:15 | lyarwood | so without a nova-manage or cinder-manage command that could do the same I think there's still a place for it | |
| 09:08:31 | stephenfin | so perhaps keep it but have a big warning that you probably don't want to use it unless you know what you're doing? | |
| 09:08:43 | lyarwood | Yup fair | |
| 09:33:15 | openstackgerrit | Tobias Urdin proposed openstack/nova master: When Nova-Api runs behind the load balancer or Reverse proxy, Loadbalancer IP is getting logged in nova_api.log instead of end user source ip by RequestLog https://review.opendev.org/c/openstack/nova/+/786766 | |
| 09:39:34 | openstackgerrit | Wenping Song proposed openstack/nova-specs master: Repropose vGPU support spec https://review.opendev.org/c/openstack/nova-specs/+/780452 | |
| 09:52:22 | sean-k-mooney | stephenfin: given we have started adding admin commands for nova i would personally add the attachment manament commands to osc | |
| 09:53:12 | sean-k-mooney | stephenfin: in that same vain if you are adding commands i have been meaning to add the ablitiy to list, create, activate and delete neutron port bindings | |
| 09:54:02 | sean-k-mooney | stephenfin: lyarwood also going back to cinder attachments you can use cinder standalone. i had an isci volume mounted on my gaming pc at home | |
| 09:54:28 | sean-k-mooney | if i remeber correctly i had to use the cinder clinet instead of osc to do that | |
| 09:54:46 | sean-k-mooney | so if i could avoid cinder clint next time that would be nice | |
| 09:55:46 | lyarwood | yeah that's fair, I almost think we need another osc command capable of pulling the hosts connector JSON blob togther that we can feed into it | |
| 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 | |