Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2024-02-27
16:21:01 bauzas #topic Review priorities
16:21:09 bauzas #link https://etherpad.opendev.org/p/nova-caracal-status
16:21:13 bauzas #link https://etherpad.opendev.org/p/nova-caracal-status
16:21:20 bauzas #topic Stable Branches
16:21:23 bauzas elodilles: ?
16:21:26 elodilles o/
16:21:39 elodilles #info stable gates seem to be OK
16:21:51 elodilles surprisingly, might be even zed is OK
16:22:18 elodilles as nova-grenade-multinode is just passing :-o
16:22:29 elodilles i don't know how
16:22:34 elodilles so maybe it's just a bug :D
16:22:51 elodilles it should be using unmaintained/yoga
16:23:04 bauzas ...
16:23:31 elodilles #info stable branch status / gate failures tracking etherpad: https://etherpad.opendev.org/p/nova-stable-branch-ci
16:24:08 elodilles please add here any issue if you see one on stable branches ^^^
16:24:30 elodilles that's all from me for now
16:25:47 bauzas thanks
16:25:57 bauzas #topic vmwareapi 3rd-party CI efforts Highlights
16:25:59 bauzas fwiesel: ?
16:26:02 fwiesel #info FIPS do work now, but not reliably (Pass 459 Failure 23 Skip 44) (previously Passed: 435, Failed: 41, Skipped: 42)
16:26:18 fwiesel #link http://openstack-ci-logs.global.cloud.sap/openstack/nova/1858cf18b940b3636e54eb5aafaf4050bdd02939/tempest.html
16:27:03 fwiesel Better, but not quite there yet.
16:27:23 bauzas kudos
16:27:35 fwiesel Serveral of the failures have simpler reasons. I'll probably get those down first before I dig into the FIP issue.
16:28:03 fwiesel Questions?
16:28:19 bauzas none from me, good luck for debugging
16:28:37 fwiesel Okay, then that's from my side. Back to you.
16:29:38 bauzas thanks
16:29:52 bauzas #topic Open discussion
16:29:57 bauzas anything anyone ?
16:30:26 kgube Hi, I wanted to ask a question on how to proceed with my feature: https://review.opendev.org/c/openstack/nova/+/873560
16:30:57 kgube It has a cinderclient dependency, so we need to bump the cinderclient version
16:31:23 bauzas good question
16:31:24 kgube the problem is that the needed change will only be in the comming cinderclient release
16:31:52 kgube wich happens together with the featurefreeze
16:31:54 bauzas kgube: have you seen my question about a Tempest test checking your patch ?
16:32:11 bauzas I wonder how Zuul can say +1 if nothing is changed
16:32:50 kgube bauzas, yes, none of the current tempest jobs are using the codepath that calls the new volume action
16:33:16 kgube so it just works with the previous version
16:33:37 bauzas kgube: do you have a follow-up patch for Tempest about it ?
16:33:47 bauzas like another attribute
16:34:50 kgube so the only job that will be testing the new volume action is the devstack-plugin-nfs one
16:35:43 kgube I have a patch for this, but it also needs changing once the feature is merged
16:35:47 kgube https://review.opendev.org/c/openstack/devstack-plugin-nfs/+/896196
16:35:59 kgube so it's currently marked as WIP
16:36:50 bauzas okay, then we need to have a consensus for accepting your feature without Tempest scenarios
16:37:07 bauzas what people think about ^ ?
16:37:34 bauzas as kgube said, we only know it doesn't trample the other usages
16:39:24 kgube well, the second change I posted has successful tempest runs for nfs online extend, with all of the changes merged in
16:39:57 kgube it just isn't part of the nova tempest jobs
16:40:44 bauzas kgube: I'll ping other cores async
16:40:52 bauzas to see what they think
16:41:04 kgube thank you!
16:41:32 bauzas any other things before we close ?
16:42:34 bauzas looks not
16:42:36 bauzas thanks all
16:42:38 opendevmeet Log: https://meetings.opendev.org/meetings/nova/2024/nova.2024-02-27-16.00.log.html
16:42:38 opendevmeet Minutes (text): https://meetings.opendev.org/meetings/nova/2024/nova.2024-02-27-16.00.txt
16:42:38 bauzas #endmeeting
16:42:38 opendevmeet Minutes: https://meetings.opendev.org/meetings/nova/2024/nova.2024-02-27-16.00.html
16:42:38 opendevmeet Meeting ended Tue Feb 27 16:42:38 2024 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
16:47:55 sean-k-mooney bauzas: the tempest test is not the issue we cant merge the patch without the client bump
16:48:06 sean-k-mooney so we should ask for an early cinder clinent release
16:48:13 sean-k-mooney and if they need to do another one they can
16:48:17 sean-k-mooney at ff
16:48:55 sean-k-mooney the release process is fully automated out sied of the patch review so that should be quick and simple to do
16:48:57 bauzas well, the depends-on is a cinderclient patch
16:49:11 sean-k-mooney right but the nova patch need a min version bump
16:49:13 bauzas once the patch is merged, then Zuul can accept
16:49:30 sean-k-mooney no because our unit/fucntional test will fail
16:49:32 bauzas sean-k-mooney: correct, we should target the required need
16:50:01 sean-k-mooney well it depend on that the client change is doing
16:50:14 sean-k-mooney depends on is not used for the tox changes
16:50:26 sean-k-mooney so those will fial if we are usign a new api form it but we are probaly mocking it
16:50:32 sean-k-mooney so maybe they wont fial
16:51:24 bauzas sean-k-mooney: my point is that nothing blocks the nova change to be merged
16:51:53 bauzas because I guess it's only additive opt-in changes
16:53:39 bauzas paperwork-ish, we should ask for an reqs.txt update
16:53:59 bauzas anyway, I need to leave now b/c of a physical local meetup in Grenoble
16:56:47 sean-k-mooney bauzas: my point is it really shoudl be blocked
16:56:53 sean-k-mooney bauzas: that not how we handel depencies
16:57:05 sean-k-mooney the path that need the new feature does the requirements bump
16:57:53 bauzas sean-k-mooney: please then add a comment in the nova patch
17:31:53 sean-k-mooney i did thats why i -1 it
17:32:43 sean-k-mooney bauzas: on the good news front https://zuul.opendev.org/t/openstack/build/2a3f86e4974b4a4a9e875477c77f81e0/logs
17:32:52 sean-k-mooney bauzas: that fialed one test that shoudl not work in that job config
17:33:34 sean-k-mooney bauzas: i have confirmed that we have 2 compute nodes and each is only reporting 3 ironic nodes
17:33:47 sean-k-mooney each compute is exposing diffent shards
17:34:16 sean-k-mooney adn we can boot nova instnace across either shard
17:35:23 sean-k-mooney bauzas: i was just chatting with JayF and im goign to rework this to be mergable and start wroking on a simple post hook to validate that each compute service is only reportin the ironic nodes we expect
17:36:16 sean-k-mooney long term we may be able to simplfy the setup too but i think this give nova the coverage we ant for the shard work. ironic will seperaly be testing the api in there jobs too
17:54:20 JayF that is already merged and has been running for weeks now (ironic api test job)
17:54:38 JayF https://opendev.org/openstack/ironic-tempest-plugin/commit/f2b9c74c9cb8459a979d9002aae3c1a41737c77a
21:36:45 opendevreview sean mooney proposed openstack/nova master: add multinode ironic shard job https://review.opendev.org/c/openstack/nova/+/910333
21:49:53 sean-k-mooney bauzas: https://review.opendev.org/c/openstack/nova/+/910333 is enabling the ironic job in experimetal and perodic weekly
21:50:43 sean-k-mooney assuming that passes i think that woudl be enough with the exiting ironic testing on there side to progress and we can spend some time adding better coverage post FF and early next cycle
21:52:17 sean-k-mooney the coverage in the job is minimal as it stands today but i have partsed the logs myself and convicned my self that its actully sharding properly
21:52:39 sean-k-mooney see https://review.opendev.org/c/openstack/nova/+/910333/4/.zuul.yaml#974
21:52:59 sean-k-mooney i am not conviced this job woudl cache if that broken on teh ironic side
21:53:25 sean-k-mooney but we can evolve it to do that

Earlier   Later