| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-05-25 | |||
| 07:46:55 | bauzas | morning folks | |
| 07:47:29 | bauzas | * bauzas starts his specs review day | |
| 07:47:38 | bauzas | if folks want me to look at some spec, ping me | |
| 07:58:22 | openstackgerrit | Merged openstack/nova-specs master: Allow migrating PMEM's data https://review.opendev.org/c/openstack/nova-specs/+/785563 | |
| 08:01:39 | openstackgerrit | Lee Yarwood proposed openstack/nova stable/wallaby: Add regression test for bug #1928063 https://review.opendev.org/c/openstack/nova/+/792902 | |
| 08:03:30 | openstackgerrit | Lee Yarwood proposed openstack/nova stable/victoria: Add regression test for bug #1928063 https://review.opendev.org/c/openstack/nova/+/792903 | |
| 08:10:53 | icey | lyarwood: thanks, it's appreciated! I'm hopimng to get it into Ubuntu, and the cloud archive, for Queens (and, incidentally, Rocky, to ensure that upgrades don't break) | |
| 08:11:21 | lyarwood | ack np elod ^ if you could also review icey's change above that would be great | |
| 08:11:52 | icey | lyarwood: sadly, not quite my change, but I do get to hear the desire from the patch's author to get it in :) | |
| 08:13:39 | elod | lyarwood icey : yes, it is on my todo for a long time, I'll try to review it now :S | |
| 08:13:49 | lyarwood | many thanks :) | |
| 08:14:22 | icey | elod: thanks! there's a cherry-pick to Queens as well, it currently has a -1 because it wasn't picked from Rocky; I'd appreciate advice ont he best path forward on that one as well :) | |
| 08:51:04 | stephenfin | lyarwood: have you ever used the 'cinder attachment-*' commands? | |
| 08:51:14 | stephenfin | particularly 'cinder attachment-create' | |
| 08:51:16 | lyarwood | yes | |
| 08:51:19 | lyarwood | oh | |
| 08:51:24 | lyarwood | well only to reserve the attachment | |
| 08:51:31 | lyarwood | never with an actual connector | |
| 08:51:53 | stephenfin | yeah, I'm not sure how that's supposed to work | |
| 08:52:09 | lyarwood | yeah providing an actual connector is awkward as hell AFAICT | |
| 08:52:58 | stephenfin | So it would seem. The docs suggest that you don't need to provide much of it and nova and cinder will fill in the blanks between them | |
| 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 | |