| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-05-24 | |||
| 17:58:45 | lyarwood | sean-k-mooney: ack yeah or backport a modified version of that? | |
| 17:59:13 | sean-k-mooney | well that is waht i was going to do but with lower min version to match the branch its going too | |
| 17:59:44 | sean-k-mooney | im not sure if starting from that patch will be faster or not | |
| 18:30:24 | openstackgerrit | sean mooney proposed openstack/os-vif stable/victoria: Resolve dependency issues https://review.opendev.org/c/openstack/os-vif/+/792840 | |
| 18:56:29 | sean-k-mooney | elod: lyarwood: am i allowed to squash two change in a backport upstream | |
| 18:57:23 | sean-k-mooney | basicaly i have 2 chocie squash https://review.opendev.org/c/openstack/os-vif/+/716223 and the ussuri version of https://review.opendev.org/c/openstack/os-vif/+/792840 | |
| 18:57:51 | sean-k-mooney | or i can incoperate ignoring W504 | |
| 18:58:52 | sean-k-mooney | oh wait no that is not adding W504 | |
| 18:59:02 | sean-k-mooney | that not the patch i need to add | |
| 18:59:39 | sean-k-mooney | its https://github.com/openstack/os-vif/commit/d57a5f39edcb8ef3de09e80925c8fe628e5e0f3a | |
| 19:01:15 | sean-k-mooney | but since that raise the min version hackign i cant really backport | |
| 19:02:16 | sean-k-mooney | ok ill take a look at this again tomorrow | |
| 19:06:26 | lyarwood | <sean-k-mooney "elod: lyarwood: am i allowed to "> Yes FWIW, if it fixes an otherwise unsolvable problem you can merge multiple. | |
| 19:07:18 | sean-k-mooney | i tought that i need to backport the cleanup patch and merge it with the lower constratint one but that is not what intoduced the w504 skip | |
| 19:07:35 | sean-k-mooney | lyarwood: it was the patch that bumps hacking form 1.x to 3.0 for python 3 support | |
| 19:08:26 | sean-k-mooney | ill see if i can figure out how to cap flak8 and py code style to avoid the hacking bump | |
| 19:09:06 | sean-k-mooney | but if i cant we will have to deciside if we are oke with the bump to hacking in the pep8 tox env | |
| 19:09:27 | sean-k-mooney | given it wont impackt any other test and wont be used at runtime | |
| 19:10:54 | sean-k-mooney | if we are ok with going to hacking 3.0 ill look at squashing thsoe two patches | |
| 19:11:25 | sean-k-mooney | well tomorrow im going to go get dinner now o/ | |
| 22:01:16 | openstackgerrit | Merged openstack/nova master: image_meta: Provide image_ref as the id when fetching from instance https://review.opendev.org/c/openstack/nova/+/790659 | |
| #openstack-nova - 2021-05-25 | |||
| 06:11:00 | icey | hey - any chance of getting a review on https://review.opendev.org/c/openstack/nova/+/761824/ ? It got a +1 from Zuul a while back but has been sitting in limbo since February | |
| 07:43:35 | lyarwood | icey: Apologies, I'll take a look now | |
| 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 | |