| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-10-08 | |||
| 10:00:42 | whoami-rajat__ | kashyap, yep, that operation is successful but we didn't update the backing file of snap2, in a subsequent operation when trying to delete snap2 it errors out because backing_file of snap2 is wrong now | |
| 10:01:09 | kashyap | Right, that makes sense. | |
| 10:03:23 | whoami-rajat__ | yeah i have been trying out a few things here and there lately but no success, i thought the part ``dev = guest.get_block_device(commit_disk)`` might contain the info regarding the whole chain and maybe i can update the backing chain there | |
| 10:03:37 | whoami-rajat__ | but i guess nova calls ``virsh blockCommit`` and libvirt does all the work there | |
| 10:06:19 | kashyap | Yes; see the wrapper method commit() in guest.py | |
| 10:08:24 | lyarwood | whoami-rajat__: just reading up | |
| 10:08:50 | lyarwood | whoami-rajat__: the entire chain should be in .info file no? | |
| 10:09:02 | lyarwood | whoami-rajat__: that cinder controls | |
| 10:09:19 | lyarwood | I guess that doesn't actually show the chain | |
| 10:12:17 | lyarwood | kashyap: why would we commit anything to vol1? | |
| 10:12:32 | lyarwood | kashyap: shouldn't the base volume remain untouched if we are just removing the middle snapshot? | |
| 10:13:07 | lyarwood | ah because we'd want the delta in snap2 to remain the same | |
| 10:13:09 | lyarwood | ignore me | |
| 10:13:15 | kashyap | lyarwood: What happens to the content in the middle one, then? :-) | |
| 10:13:26 | kashyap | Yep, you you're right | |
| 10:13:28 | lyarwood | right I was thinking that would end up in snap2 | |
| 10:14:04 | lyarwood | getting confused with the image COW usecase where we don't want the image to change | |
| 10:14:12 | lyarwood | but this isn't the same | |
| 10:14:26 | kashyap | Yeah, I hear ya | |
| 10:14:54 | whoami-rajat__ | i think that happens incase of a blockRebase when backing file changes move up to the snapshot file | |
| 10:15:02 | kashyap | In this case, we have: vol1 <- snap1 <- snap2. Commit snap1 to vol1. Then update backing file of 'snap2' to 'vol1' (base). Then remove the invalid 'snap1' | |
| 10:15:41 | whoami-rajat__ | yep, 1) and 3) are already done by nova and cinder resp, we need to figure out 2) | |
| 10:17:02 | kashyap | Offline rebase | |
| 10:19:11 | stephenfin | kashyap, lyarwood: Could you stick https://review.opendev.org/#/c/756549/ and https://review.opendev.org/#/c/752912/ on your review queues, please? | |
| 10:20:12 | lyarwood | stephenfin: ack | |
| 10:20:28 | stephenfin | thanks | |
| 10:20:57 | kashyap | stephenfin: Ah, USB controller and 'vmcore'; nice | |
| 10:21:00 | kashyap | Will do | |
| 10:21:49 | stephenfin | kashyap: You'll likely be interested in https://review.opendev.org/#/c/756552/ also. That's lower priority for me right now but still potentially useful | |
| 10:22:46 | stephenfin | bauzas: Dead simple +2 here https://review.opendev.org/#/c/756135/ | |
| 10:23:30 | kashyap | Input devices; yeah, noted. | |
| 12:12:11 | bauzas | stephenfin: roger this. | |
| 12:33:26 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Reproduce bug 1897528 https://review.opendev.org/756696 | |
| 12:33:26 | openstack | bug 1897528 in OpenStack Compute (nova) "32bit pci domain number is not supported" [High,Confirmed] https://launchpad.net/bugs/1897528 | |
| 12:33:26 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Ignore PCI devices with 32bit domain https://review.opendev.org/756697 | |
| 12:36:22 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Ignore PCI devices with 32bit domain https://review.opendev.org/756697 | |
| 12:44:26 | admin0 | hi .. can default_domain in nova be blank ? | |
| 12:57:31 | ganso | Hi Nova folks! I know everyone is busy with Victoria release, but if you have a minute to spare and could please take a look at this stable/ussuri patch that already has a +2 and just needs one more +2 to land: https://review.opendev.org/#/c/752245/ Thanks in advance! | |
| 12:57:42 | ganso | bauzas, lyarwood ^ | |
| 13:59:33 | sean-k-mooney | o/ | |
| 14:05:09 | gibi | \o | |
| 14:06:23 | sean-k-mooney | my os update did not go well after systemd crashed half way thorugh | |
| 14:06:36 | gibi | sounds bad | |
| 14:06:49 | sean-k-mooney | i had to reinstall | |
| 14:07:47 | sean-k-mooney | after a reboot while i could decypt the luxs lvm volume i could not boot form it so trying to get email and other stuff workign again | |
| 14:07:59 | sean-k-mooney | at least i have irc again | |
| 14:16:01 | bauzas | sean-k-mooney: glad to see you | |
| 14:18:21 | sean-k-mooney | i now have fedora 32. goggle calandar is still broken in thruderbird and evoltion and now im having issue with email too but i have a gui again so i guess that is progress | |
| 14:21:43 | openstackgerrit | Navid Pustchi proposed openstack/nova-specs master: add availability-zone-affinity-anti-affinity-filter review. https://review.opendev.org/756380 | |
| 14:30:21 | openstackgerrit | Dan Smith proposed openstack/nova master: Allow excluding image type capabilities https://review.opendev.org/756534 | |
| 14:43:00 | ygk_12345 | hi all | |
| 14:43:02 | ygk_12345 | i have created a availability zone and added a compute node into it. but the zone status is showing as "not available". how can I change its status ? | |
| 14:43:27 | sean-k-mooney | i did not thnk the AZ had a staus | |
| 14:43:31 | sean-k-mooney | the host do | |
| 14:44:28 | ygk_12345 | sean-k-mooney check this outpout http://paste.openstack.org/show/798870/ | |
| 14:45:00 | ygk_12345 | sean-k-mooney the "test-aggregate-az" is not available | |
| 14:45:22 | ygk_12345 | i am not able to launch any vms in it | |
| 14:46:09 | sean-k-mooney | and if you check the host in test-aggreate | |
| 14:46:30 | sean-k-mooney | you see the host is listed and its avaiable/active | |
| 14:46:33 | ygk_12345 | the host is present in the aggregate | |
| 14:46:55 | ygk_12345 | but the host is not getting listed in the output | |
| 14:47:29 | ygk_12345 | http://paste.openstack.org/show/798871/ | |
| 14:48:35 | stephenfin | lyarwood: What, if anything, do you know about image-defined BDMs? | |
| 14:48:45 | stephenfin | Are they a thing we still use/support? | |
| 14:48:48 | ygk_12345 | sean-k-mooney did u see that. it hs one compute | |
| 14:48:54 | ygk_12345 | *has | |
| 14:49:08 | stephenfin | I'd trying to figure out what the e.g. 'img_mappings' image metadata property is/was used for | |
| 14:49:12 | stephenfin | *I'm | |
| 14:54:16 | sean-k-mooney | stephenfin: it might be realted to ephemeral disk | |
| 14:55:12 | sean-k-mooney | when you are using qcow the bdms have a type of local but i think there is a way or there was a way to split up the flavor.ephmerial storage using dbms to have multipel disks | |
| 14:55:28 | sean-k-mooney | no idea if that is what you are trying to figure out | |
| 14:55:50 | sean-k-mooney | e.g. i dont know if we support specfiying that in the image | |
| 14:56:02 | ygk_12345 | sean-k-mooney any idea abt the availability-zone issue ? | |
| 15:01:07 | sean-k-mooney | the docs dont really say much ill have to look at the code | |
| 15:01:09 | sean-k-mooney | https://docs.openstack.org/api-ref/compute/?expanded=get-detailed-availability-zone-information-detail,get-availability-zone-information-detail#get-availability-zone-information | |
| 15:01:46 | ygk_12345 | sean-k-mooney strange behavior here. its status is "not available" | |
| 15:03:00 | sean-k-mooney | https://github.com/openstack/nova/blob/2745e685376abbc4c32516837f6074a3de23aa24/nova/availability_zones.py#L108-L140 | |
| 15:03:07 | sean-k-mooney | so its what i tought | |
| 15:03:26 | sean-k-mooney | we list it as unavaiable if non of the compute service in the aggreate are enabled | |
| 15:03:44 | sean-k-mooney | meaning the compute service on the host you have added to the aggrate is down or disabled | |
| 15:03:59 | ygk_12345 | oh ok let me check that compute node then | |
| 15:06:30 | openstackgerrit | Stephen Finucane proposed openstack/nova master: docs: Add image metadata property reference guide https://review.opendev.org/756867 | |
| 15:27:06 | stephenfin | bauzas: tox config isn't a API we need to protect :) We change things in there (and rightly so) all the time https://review.opendev.org/#/c/756135/ | |
| 15:27:37 | bauzas | stephenfin: sure, but I want to make sure that scripts still work and be a gentleman | |
| 15:27:49 | bauzas | I'm currently looking at how we could do it | |
| 15:27:52 | stephenfin | the only scripts using that are in zuul, which uses both | |
| 15:27:58 | stephenfin | but prefers the new style | |
| 15:28:30 | bauzas | honestly, I'm not that opiniated | |
| 15:28:55 | bauzas | stephenfin: are we sure that all CI (meaning 3rd party) won't use it too ? | |
| 15:30:10 | stephenfin | bauzas: I very much doubt it. The only reason to do so is if you wanted to use a different set of upper constraints than master. Also, they've probably hit it elsewhere http://codesearch.openstack.org/?q=TOX_CONSTRAINTS_FILE&i=nope&files=&repos= | |
| 15:31:03 | stephenfin | *different set of upper constraints than upstream/opendev.org | |
| 15:32:25 | bauzas | stephenfin: well, surely, but we can't assure we won't break others | |
| 15:32:41 | stephenfin | bauzas: actually, we can | |
| 15:32:41 | bauzas | stephenfin: that's the reason why I do care to be soft :) | |
| 15:32:55 | stephenfin | look at the zuul checks | |
| 15:32:59 | stephenfin | no failing third party CIs | |
| 15:33:17 | stephenfin | (in fact, no third-party CI results whatsoever) | |
| 15:34:12 | sean-k-mooney | if its overly complicated im fine with just changing it i like haveing the url in only one place however in the file | |
| 15:34:21 | sean-k-mooney | that the main thing i didnt like | |
| 15:34:37 | sean-k-mooney | we we can support both and prefer teh new form then that fine too | |