| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-09-22 | |||
| 10:55:10 | brinzhang0 | stephenfin: ack, thanks, I will jump these two comments | |
| 10:55:54 | ygk_12345 | hi all i am using OSA train 20.0.2, but when launching a vm, it is goging into error state with the following erro message | |
| 10:56:17 | ygk_12345 | libvirt.libvirtError: Requested operation is not valid: format of backing image '/var/lib/nova/instances/_base/a580bb66b9bb88e1af8354d582ab15a2afba3785' of image '/var/lib/nova/instances/9dd2ab12-f050-4eab-a887-ffc9c4a67dc3/disk' was not specified in the image me | |
| 10:56:46 | ygk_12345 | Requested operation is not valid: format of backing image '/var/lib/nova/instances/_base/a580bb66b9bb88e1af8354d582ab15a2afba3785' of image '/var/lib/nova/instances/9dd2ab12-f050-4eab-a887-ffc9c4a67dc3/disk' was not specified in the image metadata (See https://libvirt.org/kbase/backing_chains.html for troubleshooting) | |
| 10:56:52 | ygk_12345 | is this a known issue ? | |
| 10:57:53 | lyarwood | ygk_12345: yeah with libvirt >= 6.0.0 | |
| 10:57:59 | lyarwood | ygk_12345: are you using the train UCA? | |
| 10:58:29 | ygk_12345 | lyarwood it is OSA train 20.0.2 version | |
| 10:59:11 | lyarwood | ygk_12345: https://review.opendev.org/#/c/710788/ landed in stable train 20.2.0 and should resolve that | |
| 10:59:27 | lyarwood | ygk_12345: to be clear that's Nova 20.2.0 | |
| 10:59:59 | ygk_12345 | lyarwood so is this fixed in 20.2.0 OSA train version ? | |
| 11:00:37 | lyarwood | ygk_12345: it's fixed in the 20.2.0 version of Nova, I have no idea which version of OSA would use that | |
| 11:00:49 | ygk_12345 | oh ok | |
| 11:00:56 | lyarwood | https://github.com/openstack/nova/releases/tag/20.2.0 | |
| 11:02:36 | brinzhang0 | stephenfin: addressed your comments, except above :) thanks | |
| 11:23:11 | elod | lyarwood: sorry, just one question: where can we see that we are already using train UCA? Is there a patch for that? | |
| 11:23:11 | CeeMac | lyarwood: would it just be the nova-compute logs or the others too you would need extracts from? We had to delete / recreate one of the instances so it'll be tricky tracking back to find the correct request ID for that one sadly but I have another one where only 1 of the disks succeeded in retyping, the other didnt and it is also now dead | |
| 11:26:14 | openstackgerrit | Lee Yarwood proposed openstack/nova stable/queens: Improve CinderFixtureNewAttachFlow https://review.opendev.org/749228 | |
| 11:26:15 | openstackgerrit | Lee Yarwood proposed openstack/nova stable/queens: Robustify attachment tracking in CinderFixtureNewAttachFlow https://review.opendev.org/749229 | |
| 11:26:16 | openstackgerrit | Lee Yarwood proposed openstack/nova stable/queens: compute: Use source_bdms to reset attachment_ids during LM rollback https://review.opendev.org/749230 | |
| 11:26:17 | openstackgerrit | Lee Yarwood proposed openstack/nova stable/queens: compute: refactor volume bdm rollback error handling https://review.opendev.org/749231 | |
| 11:26:19 | openstackgerrit | Lee Yarwood proposed openstack/nova stable/queens: Add regression tests for bug #1889108 https://review.opendev.org/749232 | |
| 11:26:19 | openstack | bug 1889108 in OpenStack Compute (nova) queens "failures during driver.pre_live_migration remove source attachments during rollback" [Undecided,In progress] https://launchpad.net/bugs/1889108 - Assigned to Lee Yarwood (lyarwood) | |
| 11:26:20 | openstackgerrit | Lee Yarwood proposed openstack/nova stable/queens: compute: Don't delete the original attachment during pre LM rollback https://review.opendev.org/749233 | |
| 11:26:43 | lyarwood | elod: https://review.opendev.org/#/c/752641/ sorry | |
| 11:26:54 | lyarwood | elod: I can respin the commit to point to that if you'd like | |
| 11:27:17 | lyarwood | CeeMac: nova-compute would be the most useful yes | |
| 11:27:31 | elod | lyarwood: no need for that, I just haven't found that :) | |
| 11:56:49 | CeeMac | lyarwood: where would libvirtd log to by default? | |
| 11:57:28 | sean-k-mooney | /var/log/libivrt | |
| 11:57:39 | sean-k-mooney | unless you are using ooo | |
| 11:58:19 | sean-k-mooney | in which case they are in /var/log/containers/nova/nova_libvirt or something like that | |
| 11:59:04 | CeeMac | using osa, will check | |
| 12:00:07 | CeeMac | ok, folder is there, which logs in particular? qemu presumably? | |
| 12:00:19 | CeeMac | I have libxl, lxc, qemu and uml folders | |
| 12:00:22 | lyarwood | CeeMac: libvirtd if you have it | |
| 12:00:30 | lyarwood | CeeMac: but it might not be enabled by OSA by default | |
| 12:00:45 | lyarwood | CeeMac: libvirtd.log that is | |
| 12:00:57 | CeeMac | lyarwood: can't see that one | |
| 12:01:15 | CeeMac | i found some things in nova-compute though | |
| 12:01:22 | CeeMac | i'll pull a bug together | |
| 12:01:56 | CeeMac | is it ok to paste the errors directly in the bug, or you'd prefer a paste url? | |
| 12:02:16 | CeeMac | hmm, 100 or so lines, maybe paste url for readability | |
| 12:03:03 | lyarwood | yeah pastebins are easier to read | |
| 12:03:13 | lyarwood | launchpad-- comments are pretty awful | |
| 12:03:13 | sean-k-mooney | you can put it at the end of the bug but paste it better | |
| 12:03:29 | sean-k-mooney | lyarwood: you have used bugzilla right :P | |
| 12:03:39 | sean-k-mooney | at least launchpad comments dont have conflicts | |
| 12:03:39 | CeeMac | no worries, i'll do a paste url :) | |
| 12:03:56 | sean-k-mooney | for that alone i forgive much | |
| 12:15:28 | lyarwood | sean-k-mooney: yeah rhbz has many faults but the comments are readable and editable now :) | |
| 12:18:03 | sean-k-mooney | really even comment 0 | |
| 12:19:45 | lyarwood | sean-k-mooney: yeah even c#0, landed in the recent upgrade | |
| 12:20:11 | sean-k-mooney | well that is progress at least | |
| 12:28:07 | brinzhang0 | hi all, compared to appclient what benefits the introduction of openstacksdk can bring us? | |
| 12:28:47 | brinzhang0 | I saw we introduced it, but not used it, if I am not missing some key message | |
| 12:29:28 | sean-k-mooney | the sdk would be replacing keystone auth client and then eventrully replcing the other service python clients | |
| 12:29:29 | openstackgerrit | Mamduh proposed openstack/os-vif master: Fix - os-vif fails to get the correct UpLink Representor https://review.opendev.org/745895 | |
| 12:30:03 | brinzhang0 | benifit? | |
| 12:30:34 | sean-k-mooney | to not need to main tain project sepcicif clients and eventurlaly only have one python sdk with all features | |
| 12:30:50 | sean-k-mooney | eventually we will hopefully get rid of python-novaclint | |
| 12:31:00 | sean-k-mooney | but we need full parity in osc and sdk first | |
| 12:32:11 | sean-k-mooney | the sdk also papers over some of the interoperablity issue between clouds | |
| 12:32:11 | brinzhang0 | yeah, now the sdk cannot support the cli, if we decrapted it, that how to use the command? | |
| 12:32:46 | sean-k-mooney | osc can use the sdk if it wants too | |
| 12:33:03 | sean-k-mooney | but osc should replace all uses of nova cli eventually | |
| 12:33:42 | sean-k-mooney | i wanted to freeze all addtions to nova cli last cycle and require new feature to be added only to osc but others disagreed | |
| 12:34:07 | brinzhang0 | yeah, I remembered gibi said, there is still a big gap between osc and novaclient | |
| 12:34:29 | sean-k-mooney | yep i dont think we should be widening that by adding new feautres or comands to nova client | |
| 12:35:01 | brinzhang0 | sean-k-mooney: if we can required new feature and added the lack of feature to osc, I think it will be good start | |
| 12:35:41 | brinzhang0 | *interoperablity issue between clouds* can you give some example? | |
| 12:37:19 | sean-k-mooney | the sdk has 3 levels fo apis. 1 is a raw rest client that just handels auth, 1 is driect method for the indigivual apis and the final one is a high level api that abstrct the differnce between say the old glance image import and the new way using the correct one for the cloud its conneccting too | |
| 12:37:21 | brinzhang0 | Do we plan to replace the SDK? In W release or X release, or more further? | |
| 12:38:12 | sean-k-mooney | brinzhang0: another example is that the high level api provide a way to look up the ip you can ssh over taking into account floating ips and if the vm is directly connect to an external network | |
| 12:38:24 | sean-k-mooney | basically the functionality that shade provided | |
| 12:39:03 | sean-k-mooney | brinzhang0: replce the sdk? no adopt the SDK we should in thoery use it any time we need to call an new api in a different service | |
| 12:39:42 | sean-k-mooney | brinzhang0: for example we shoudl be interacting with cybrog via the sdk rahter then using a python-cyborgclient | |
| 12:40:06 | sean-k-mooney | im pretty sure we already do use the sdk to get a rest client and make direct rest call | |
| 12:40:22 | sean-k-mooney | if the sdk had cyborg supprot we would use that instead | |
| 12:41:04 | brinzhang0 | oh, that the sdk and novaclient will be all exist in Nova, it means we will maintain two tools | |
| 12:41:08 | sean-k-mooney | much of https://github.com/openstack/nova/blob/master/nova/accelerator/cyborg.py could live in the sdk | |
| 12:41:14 | sean-k-mooney | not all of it but much of it | |
| 12:41:36 | sean-k-mooney | brinzhang0: the sdk is a sperate repo | |
| 12:41:46 | sean-k-mooney | not part of nova | |
| 12:42:02 | sean-k-mooney | and novaclinet will eventually be deprecated and removed hopefully | |
| 12:42:22 | sean-k-mooney | just not in W or likely not in X either | |
| 12:42:25 | brinzhang0 | yeah, I know, but if we want to use sdk for the new api call, we need to deploy it, and add the api support in sdk | |
| 12:42:46 | sean-k-mooney | sure | |
| 12:43:46 | brinzhang0 | yes, now we interactiing with cyborg via cyborgclient | |
| 12:44:05 | sean-k-mooney | we do not use cyborgclient | |
| 12:44:27 | sean-k-mooney | and we should not | |
| 12:45:07 | sean-k-mooney | we use a raw rest client and make json queryies to the cyborg api | |
| 12:45:33 | sean-k-mooney | we have our own cyborg client https://github.com/openstack/nova/blob/master/nova/accelerator/cyborg.py#L81 | |
| 12:45:48 | sean-k-mooney | but its not the python-cyborgclient | |
| 12:46:11 | sean-k-mooney | we never use https://opendev.org/openstack/python-cyborgclient | |
| 12:46:38 | sean-k-mooney | and likely never will in nova | |
| 12:47:08 | brinzhang0 | sean-k-mooney: oh sorry, when we complete the nova-cyborg interaction we havenot completed the python-cyborgclient, so we cannot use the python-cyborgclient in that time | |
| 12:47:28 | sean-k-mooney | right but we also would not use it | |
| 12:47:38 | sean-k-mooney | we had already started adopting the sdk | |
| 12:47:43 | brinzhang0 | yes | |