| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-02-05 | |||
| 14:43:19 | kashyap | sean-k-mooney: I can argue in good faith that this is also a bug-fix. As it absolutely helps during upgrades for operators. | |
| 14:44:09 | kashyap | sean-k-mooney: And what hyphenated flags are you talking about? Example, please. There are no hyphenated CPU flags | |
| 14:44:20 | kashyap | sean-k-mooney: The +/- syntax is the simplest way to go. | |
| 14:44:53 | sean-k-mooney | kashyap:correct right now but this was discussed at the ptg many moons ago now and there was some disagrepmetn on that syntax | |
| 14:45:20 | sean-k-mooney | im not against it but we shoudl not assuem the kernel will not add hypenated cpu flags | |
| 14:45:26 | sean-k-mooney | its simple to supprot | |
| 14:45:37 | kashyap | What's the disagreement? I don't recall. Please, let's keep things concrete | |
| 14:45:48 | kashyap | sean-k-mooney: Indeed, it is simple. I hope we don't get bogged down in the weeds | |
| 14:46:01 | sean-k-mooney | just change flag = flag.strip('-') to flag = flag[1:] | |
| 14:46:32 | sean-k-mooney | kashyap: the was a view expressed that deployment tools may prefer 2 config opitons instead of 1 | |
| 14:46:35 | kashyap | Looking at your comments ... | |
| 14:46:41 | kashyap | sean-k-mooney: Thanks for the quick review | |
| 14:48:15 | sean-k-mooney | if you do flag = flag[1:] it wont matter if the kernel adds hypeinated flags in the futrue. there are a number that have undercosres which is why im not sure they wont add ones with - https://unix.stackexchange.com/questions/43539/what-do-the-flags-in-proc-cpuinfo-mean | |
| 14:49:37 | sean-k-mooney | oh possible aes-ni | |
| 14:51:16 | sean-k-mooney | ah no that is shortened to just ase | |
| 14:51:21 | sean-k-mooney | *aes | |
| 14:52:30 | kashyap | sean-k-mooney: Yep; note: strip(+) will strip it from the beginning and end. *Not* from the middle | |
| 14:54:43 | sean-k-mooney | ah it does have that limitation | |
| 14:54:53 | sean-k-mooney | that is different then other languages | |
| 14:54:54 | kashyap | Anyway; can do the sliced index | |
| 14:57:01 | sean-k-mooney | https://docs.python.org/3/library/stdtypes.html#str.strip i was expectin git to work more like sub but i guess that makes sense i have used ti to strip leading and trailing whitespace before | |
| 14:57:14 | sean-k-mooney | and i knew it maintained that | |
| 14:57:46 | sean-k-mooney | by the way im not against implementing this i just want use to do the paperwork correctly | |
| 14:58:25 | sean-k-mooney | so basically add it to the adgendar for next weeks nova meeting and get the bp approved for wallby if the core team agrees | |
| 15:01:37 | gibi | kashyap, sean-k-mooney: yepp that bp needs an approval, but honestly it is pretty late in the cycle. we past M2 so if it is not super urgent to fix some bad situation somewhere then I don't think it fits in Wallaby. We have 18 approved bps and I think we will only have time to finish like maybe 2/3 of it | |
| 15:02:53 | kashyap | gibi: It does fix a major problem | |
| 15:03:01 | kashyap | gibi: I'll explain in a bit; running a meeting | |
| 15:03:01 | gibi | is it a bug? | |
| 15:03:05 | gibi | ack | |
| 15:06:23 | sean-k-mooney | gibi: a downtream one basically a kernel abi break | |
| 15:06:50 | sean-k-mooney | though it wont nessisarly fix it it just will help prevent new people form hitting it | |
| 15:06:55 | kashyap | sean-k-mooney: Not just downstream | |
| 15:06:58 | kashyap | Affects upstream too | |
| 15:07:36 | sean-k-mooney | to be clear this wont acutlly help improve upgrade without a vm reboot | |
| 15:07:56 | sean-k-mooney | anyway ya i should join that too | |
| 15:08:01 | sean-k-mooney | the call | |
| 15:09:20 | kashyap | sean-k-mooney: It won't; but let's not get bogged down into details, please :) | |
| 15:12:31 | kashyap | gibi: In short, that fix (which allows selectively disabling CPU flags) helps migrating instances from any Intel host that doesn't have "TSX" to a destination host that has "TSX" | |
| 15:20:39 | gibi | kashyap: lets bring it up next week on the nova meeting. I will review your patch now. If next week we see that it has a positive review and close to merge then I can accept to approve the bp late and at the same time merge the code and forget all about it | |
| 15:25:58 | kashyap | gibi: Thank you; sure. | |
| 15:31:19 | openstackgerrit | Stephen Finucane proposed openstack/nova master: policy: Copy rules before providing them to enforcer https://review.opendev.org/c/openstack/nova/+/774252 | |
| 15:31:23 | stephenfin | gmann: ^ | |
| 15:31:35 | stephenfin | Just to be safe | |
| 15:33:36 | artom | Wait, is making a field nullable in an object mean a version bump? | |
| 15:33:49 | artom | Wait, no, ignore me | |
| 15:51:15 | sean-k-mooney | gmann: is https://opendev.org/openstack/openstack-tempest-skiplist new? | |
| 15:51:41 | sean-k-mooney | i dont recall seeing this before i assuem we do not use it in nova? | |
| 15:52:48 | sean-k-mooney | ah this is a ooo thing | |
| 15:53:36 | sean-k-mooney | thats fine i was concerned that we would be skipping tests without knowing it just be cause ooo or another poejct hit an issue | |
| 15:54:04 | openstackgerrit | Artom Lifshitz proposed openstack/nova master: WIP: libvirt: start tracking NUMACell.socket for hosts https://review.opendev.org/c/openstack/nova/+/766816 | |
| 15:54:07 | openstackgerrit | Artom Lifshitz proposed openstack/nova master: WIP: extra specs/image pros: add `socket` PCI NUMA affinity https://review.opendev.org/c/openstack/nova/+/772748 | |
| 15:54:09 | openstackgerrit | Artom Lifshitz proposed openstack/nova master: WIP: Add `socket` PCI NUMA affinity policy request prefilter https://review.opendev.org/c/openstack/nova/+/772749 | |
| 15:54:12 | openstackgerrit | Artom Lifshitz proposed openstack/nova master: WIP: Track host NUMA topology in PCI manager https://review.opendev.org/c/openstack/nova/+/774149 | |
| 15:54:16 | openstackgerrit | Artom Lifshitz proposed openstack/nova master: WIP: pci: implement the `socket` NUMA affinity policy https://review.opendev.org/c/openstack/nova/+/772779 | |
| 16:32:40 | stephenfin | gmann: I removed that legacy PolicyFixture. 482 unit test failures. Haven't run functional tests yet. This is going to take some work :-) | |
| 16:48:27 | kashyap | gibi: Thanks for the quick review. Yes, let's talk on the Nova meeting week | |
| 17:57:05 | mnaser | anyone know off the top of their head if you can specify volume type when using bfv (so nova creating the volume?) | |
| 17:59:25 | sean-k-mooney | mnaser: via the block device mappings i think that came up at some point | |
| 17:59:40 | mnaser | sean-k-mooney: yeah, i'm looking at the code to see if that is currently possible | |
| 18:00:13 | mnaser | > If you want to create a volume to a specific storage backend, you need to use an image which has cinder_img_volume_type property. In this case, a new volume will be created as storage_backend1 volume type. | |
| 18:00:45 | sean-k-mooney | mnaser: we talked about it at the ptg but i cant recally if we said yes or not | |
| 18:01:05 | sean-k-mooney | i know we were relutant to support it as we did not want to keep proxing thigns to other services | |
| 18:01:13 | sean-k-mooney | but we may have allowed this | |
| 18:01:17 | stephenfin | mnaser: yes, you can | |
| 18:02:10 | mnaser | > Microversion 2.67 adds the optional parameter ``volume_type`` to block_device_mapping_v2, which can be used to specify ``volume_type`` when creating a server. | |
| 18:02:11 | mnaser | aha! | |
| 18:03:22 | stephenfin | mnaser: If you're using novaclient, you can pass the 'volume_type' key to the '--block-device' parameter | |
| 18:03:30 | stephenfin | (of 'nova boot', of course) | |
| 18:04:16 | sean-k-mooney | https://specs.openstack.org/openstack/nova-specs/specs/stein/implemented/boot-instance-specific-storage-backend.html | |
| 18:04:22 | sean-k-mooney | added in stien yes | |
| 18:05:04 | sean-k-mooney | you can manually specifcy the bdms as a json blob too right? | |
| 18:05:10 | sean-k-mooney | so you can use that to add it | |
| 18:05:47 | mnaser | neat. this cloud is running train so i can take advantage of it | |
| 18:05:54 | mnaser | awesome, thank you so much stephenfin / sean-k-mooney :) | |
| 18:06:08 | sean-k-mooney | so openstack server create --block-device-mapping {stuff} | |
| 18:08:57 | sean-k-mooney | mnaser: im not sure the current osc suport will actully work but you can defeintl do it with nova clinet until stephenfin patch lands | |
| 18:10:22 | sean-k-mooney | mnaser: https://review.opendev.org/c/openstack/python-openstackclient/+/771699 | |
| 18:13:03 | dansmith | stephenfin: I'm seeing all your db rechecks because I'm subscribed to all of them and there are a bunch | |
| 18:13:15 | dansmith | stephenfin: any hunch on what the common fails are | |
| 18:13:25 | dansmith | I feel like I'm seeing a lot of cinder fails these days | |
| 18:17:51 | sean-k-mooney | we have some ocational issue with the ssh verifciaton in some of the cinder tests | |
| 18:18:09 | sean-k-mooney | although i have not seen any one test stand out to me that much | |
| 18:18:13 | dansmith | are the ssh things specific to cinder tests? I didn't think so | |
| 18:18:33 | dansmith | lately when I need to recheck it seems like it's always some volume-related test | |
| 18:18:36 | sean-k-mooney | i have noticed it on some of the volumn ones but i think that just a seperate issue | |
| 18:18:41 | dansmith | usually related to not being able to delete a volume | |
| 18:20:53 | sean-k-mooney | https://review.opendev.org/c/openstack/nova/+/769720 just fialed with image import | |
| 18:21:06 | sean-k-mooney | in the nova-ceph-multistore job | |
| 18:21:42 | sean-k-mooney | and it previously failed in gate with tempest.scenario.test_encrypted_cinder_volumes.TestEncryptedCinderVolumes | |
| 18:22:26 | dansmith | this one is a timeout | |
| 18:23:04 | sean-k-mooney | well not a job time out though so something falied but ya | |
| 18:23:34 | dansmith | yes, job timeout | |
| 18:23:43 | dansmith | stopped in the middle of an otherwise successful-looking tempest | |
| 18:24:16 | sean-k-mooney | https://review.opendev.org/c/openstack/nova/+/769720? | |
| 18:24:29 | dansmith | nova-ceph-multistore TIMED_OUT | |
| 18:24:30 | dansmith | yeah | |
| 18:24:50 | dansmith | RUN END RESULT_TIMED_OUT: [untrusted : opendev.org/openstack/tempest/playbooks/devstack-tempest.yaml@master] | |
| 18:25:06 | sean-k-mooney | thats not what im seeing is says failure for me in the dashborad | |
| 18:25:16 | sean-k-mooney | https://zuul.opendev.org/t/openstack/build/b7ad596d805b4f4fb428a047459d7ed8 | |
| 18:25:26 | dansmith | oh sorry you mean the not yet reported job? | |