14:08:42 <kopecmartin> #startmeeting qa 14:08:42 <openstack> Meeting started Tue May 18 14:08:42 2021 UTC and is due to finish in 60 minutes. The chair is kopecmartin. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:08:43 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:08:45 <openstack> The meeting name has been set to 'qa' 14:08:48 <kopecmartin> nice :) 14:09:31 <kopecmartin> .. note: the bot was inactive at the beginning 14:09:33 <kopecmartin> continueing 14:09:50 <kopecmartin> #topic Gate Status Checks 14:10:02 <kopecmartin> any issues with the gates? 14:10:22 <kopecmartin> the doc issue we had last week got fixed 14:10:45 <kopecmartin> #topic Periodic jobs Status Checks 14:10:51 <kopecmartin> #link https://zuul.openstack.org/builds?job_name=tempest-full-victoria-py3&job_name=tempest-full-ussuri-py3&job_name=tempest-full-train-py3&pipeline=periodic-stable 14:10:56 <kopecmartin> #link https://zuul.openstack.org/builds?job_name=tempest-all&job_name=tempest-full-oslo-master&pipeline=periodic 14:11:05 <kopecmartin> seems everything (mostly) is green \o/ 14:11:35 <kopecmartin> #topic Sub Teams highlights 14:11:45 <kopecmartin> #link https://review.openstack.org/#/q/project:openstack/tempest+status:open 14:11:45 <kopecmartin> #link https://review.openstack.org/#/q/project:openstack/patrole+status:open 14:11:45 <kopecmartin> #link https://review.openstack.org/#/q/project:openstack/devstack+status:open 14:11:47 <kopecmartin> #link https://review.openstack.org/#/q/project:openstack/grenade+status:open 14:11:49 <kopecmartin> #link https://review.opendev.org/#/q/project:openstack/hacking+status:open 14:13:48 <kopecmartin> one announcement: : Drop Bionic support patch was merged 14:13:53 <kopecmartin> #link https://review.opendev.org/c/openstack/devstack/+/788754 14:14:39 <tosky> kopecmartin: the bot should be back 14:14:48 <kopecmartin> changes with review priority == +1 14:14:50 <kopecmartin> #link https://review.opendev.org/q/label:Review-Priority%253D%252B1+status:open+(project:openstack/tempest+OR+project:openstack/patrole+OR+project:openstack/devstack+OR+project:openstack/grenade+OR+project:openstack/hacking) 14:15:06 <kopecmartin> tosky: yeah, i started the meeting then i hope 14:15:32 <tosky> oh, right, sorry 14:16:01 <kopecmartin> changes with review priority == +2 14:16:03 <kopecmartin> #link https://review.opendev.org/q/label:Review-Priority%253D%252B2+status:open+(project:openstack/tempest+OR+project:openstack/patrole+OR+project:openstack/devstack+OR+project:openstack/grenade+OR+project:openstack/hacking) 14:16:24 <kopecmartin> one regarding OVN 14:16:34 <kopecmartin> #link https://review.opendev.org/c/openstack/devstack/+/791085 14:16:51 <kopecmartin> please check when possible 14:17:32 <kopecmartin> let's move on to the open discussion part 14:17:35 <kopecmartin> #topic Open Discussion 14:17:44 <kopecmartin> first topic from the agenda 14:17:46 <kopecmartin> #link https://wiki.openstack.org/wiki/Meetings/QATeamMeeting#Agenda_for_next_Office_hours 14:17:54 <kopecmartin> Shutdown of ELK, Health dashboard, subunit2sql services by gmann 14:18:20 <yoctozepto> that makes gmann sound like a bad guy 8-) 14:18:56 <yoctozepto> for the record, he is not the one shutting it all down 14:19:15 <kopecmartin> yeah, sorry , i didn't want to put it that way 14:19:21 <kopecmartin> #link http://lists.openstack.org/pipermail/openstack-discuss/2021-May/022359.html 14:19:32 <kopecmartin> the email regarding that ^^ 14:19:40 <yoctozepto> oh, I am just playing with words :-) 14:19:46 <yoctozepto> worry not 14:20:04 <kopecmartin> so the question is if we use Health dashboard ( subunit2sql) and if we have a maintainer for that 14:20:36 <kopecmartin> I don't have an answer to that at this moment 14:20:56 <kopecmartin> #action kopecmartin to check subunit2sql status 14:21:11 <kopecmartin> gmann: anything you would like to share? 14:22:38 <kopecmartin> let's move on, we can get back to that at the end 14:22:42 <kopecmartin> the next topic is 14:22:48 <kopecmartin> " Cinder project issues/questions" by rosmaita 14:22:53 <kopecmartin> Block Storage API v2 is being removed in Xena 14:23:05 <rosmaita> also removing v2 support from the python-cinderclient 14:23:12 <rosmaita> impact on tempest -- i think there is none 14:23:19 <rosmaita> the default 'catalog_type' is 'volumev3' 14:23:25 <rosmaita> #link https://opendev.org/openstack/tempest/src/commit/393e94a604f29940025c2c2d8f406419e7733e5c/tempest/config.py#L970-L972 14:23:36 <rosmaita> impact on devstack -- there is some 14:23:43 <rosmaita> here is a patch to remove volumev2 support: 14:23:50 <rosmaita> #link https://review.opendev.org/c/openstack/devstack/+/791842 14:23:57 <rosmaita> i left a question on the patch about whether a change to lib/tempest is necessary 14:24:03 <rosmaita> you can respond there and i'll revise if necessary 14:24:15 <gmann> o/ sorry I was late 14:24:32 <kopecmartin> ok, thanks rosmaita, i added myself to the reviewers list, i'll have a look 14:24:33 <kopecmartin> gmann: hi 14:24:39 <rosmaita> great, thanks 14:24:59 <rosmaita> next item is a question about the endpoints created for cinder in devstack 14:25:08 <rosmaita> you can see them on the patch ^^ 14:25:11 <gmann> kopecmartin: on healthcheck we need to see if we have maintainer otherwise as per infra notice it will be shutdown 14:25:18 <rosmaita> function 'create_cinder_accounts' in lib/cinder creates 2 v3 endpoints 14:25:24 <rosmaita> but they have different service types: 'block-storage' and 'volumev3' 14:25:30 <rosmaita> tempest looks for volumev3 14:25:36 <gmann> rosmaita: remove v2 means code path as well as endpoint both right? or former one only 14:26:08 <gmann> rosmaita: yeah, we have defaulted Tempest to v3 long back but at same time test v2 also via v2 endpoints with same set of tests 14:26:30 <rosmaita> well, the api will no longer offer v2 as an option 14:26:43 <rosmaita> so all tests of v2 endpoints will fail in xena 14:26:50 <rosmaita> but you can still run them against wallaby 14:27:01 <rosmaita> not sure if that answers your question? 14:28:05 <gmann> i mean GET v2/volumes was same as GET v3/volumes (3.0 microversion), but now v2 endpoints itself will be rejected by cinder ? 14:28:18 <rosmaita> exactly 14:28:22 <gmann> got it 14:28:27 <rosmaita> cool 14:28:42 <gmann> we need to handle it with feature flag in tempest so that we can keep testing it until wallaby 14:29:00 <gmann> I will review the devstack patch and push tempest patch for that 14:29:09 <rosmaita> great, thank you 14:29:20 <kopecmartin> gmann: thanks 14:29:22 <gmann> should not be any issue from tempest side except handling the config bits 14:29:50 <rosmaita> my question about the endpoints is that we create two different service types, 'block-storage' and 'volumev3' 14:29:58 <rosmaita> tempest looks for volumev3 14:30:05 <gmann> as default yes 14:30:10 <rosmaita> but the comment in devstack says the "official" service type is 'block-storage' 14:30:27 <gmann> but we do have a job which request on block-storage 14:30:36 <rosmaita> ok, so you do need both 14:30:53 <rosmaita> i guess my question is where the "official" service type list is maintained? 14:31:05 <rosmaita> (not really important ATM, just a question) 14:31:27 <gmann> for master we should only need one and as devstack is branched may be we can remove it from master but need to check how v2 job on temepst master will work 14:31:59 <gmann> rosmaita: devstack just configure it for Tempest. 14:32:11 <gmann> not sure what you mean by ' "official" service type' ? 14:32:21 <tosky> iirc there is just one specific job which tests volumev2, tempest-cinder-v2-api 14:32:24 <yoctozepto> https://opendev.org/openstack/os-service-types 14:32:42 <rosmaita> yoctozepto: ty 14:33:05 <yoctozepto> specifically: https://opendev.org/openstack/os-service-types/src/branch/master/os_service_types/data/service-types.json 14:33:42 <yoctozepto> block-storage seems to go forward to volumev3 14:33:54 <gmann> https://opendev.org/openstack/os-service-types 14:34:00 <gmann> yeah yoctozepto found it 14:34:13 <rosmaita> ok, that's good to know about 14:34:17 <yoctozepto> interestingly enough 14:34:18 <yoctozepto> https://opendev.org/openstack/os-service-types/src/branch/master/os_service_types/data/service-types.json#L264 14:34:25 <yoctozepto> cinder is not aliased to block-storage 14:34:40 <yoctozepto> I love the tidiness and obviousness of this mapping :-) 14:34:54 <rosmaita> yeah, i am not sure how to read it 14:34:54 <gmann> yoctozepto: yeah that was mismatch in devstack and as it was since starting we did not remove it 14:35:03 <rosmaita> i will look at it later 14:35:20 <yoctozepto> ah, no, it's not the alias, it's the default name 14:35:25 <yoctozepto> sorry, I confused myself 14:35:28 <yoctozepto> everything in order 14:35:39 <gmann> but from devstack master we should default to v3 and should be able to remove block-storage but let me push tempest patch to check that 14:35:43 <yoctozepto> block-storage is the golden name 14:35:47 <rosmaita> so as far as v2 removal goes, sounds like we are OK ... i have the devstack patch up, and gmann will handle the tempest side 14:35:53 <gmann> +1 14:35:57 <yoctozepto> ++ 14:35:57 <rosmaita> great 14:36:07 <rosmaita> next thing is i want to beg for some reviews 14:36:20 <rosmaita> we have some patches up that are required in devstack so we can get some CI going 14:36:31 <rosmaita> first, thanks for merging the one that enables S3 backup driver CI 14:36:42 <rosmaita> this one is for the ceph iscsi driver: 14:36:54 <rosmaita> #link https://review.opendev.org/c/openstack/devstack/+/668668 14:37:05 <rosmaita> the "depends-on"s have already merged on that one 14:37:34 <rosmaita> there's also a patch up so we can test the optimized cinder backend for glance 14:37:37 <gmann> sure, will check today 14:37:46 <rosmaita> #link https://review.opendev.org/c/openstack/devstack/+/757934 14:37:52 <rosmaita> cool 14:38:07 <yoctozepto> I wonder if dsp-ceph would not be a better place if you feel like it's taking too long to merge on the main devstack 14:38:12 <yoctozepto> you have more freedom in there 14:38:58 <yoctozepto> (and a +2 from me in either place) 14:39:05 <rosmaita> i guess we could do that, but the devstack patch is so nice :) 14:39:05 <rosmaita> next thing is that i was digging into interop, and noticed that 14:39:20 <rosmaita> the "new" transfers API isn't tested 14:39:30 <rosmaita> so i put up a patch for that 14:39:41 <rosmaita> #link https://review.opendev.org/c/openstack/tempest/+/790201 14:40:06 <rosmaita> it tests mv 3.55 (we are at mv 3.64 now, so it's not very "new" anymore) 14:40:40 <rosmaita> so that's just another review beg 14:40:55 <rosmaita> so, here is a meaty topic 14:41:01 <rosmaita> validating encryption-type creation 14:41:12 <rosmaita> the issue is that it's currently possible to create an encryption-type spec 14:41:17 <rosmaita> for a volume-type that's missing some fields without which you can't have 14:41:21 <gmann> rosmaita: interop does not test microversion 14:41:25 <rosmaita> a functioning encryption type 14:41:33 <rosmaita> gmann: not yet, but they will have to eventually 14:41:50 <rosmaita> in any case, it's part of the Block Storage API, so we should probably test on general principles 14:41:57 <gmann> yeah, that was plan since 2-3 years but adding test is not issue 14:42:13 <gmann> will review 14:42:14 <rosmaita> yeah, i guess i confused the issue by bringing it up 14:42:16 <rosmaita> thanks! 14:42:47 <rosmaita> ok, so the issue is that you can create a "partial" encryption type, but you don't find out its missing stuff until people start using it 14:42:58 <rosmaita> we want to detect that earlier, at the api layer 14:43:09 <rosmaita> but we can't do the validation because a tempest test fails now 14:43:15 <rosmaita> here's a patch 14:43:24 <rosmaita> #link https://review.opendev.org/c/openstack/tempest/+/791850 14:43:45 <rosmaita> the test i'm changing does create - update - delete 14:43:58 <rosmaita> the create leaves out some key fields 14:44:07 <rosmaita> we want to add validation so this can be caught upon encryption-type creation 14:44:23 <rosmaita> we could add a microversion for this, but it seems dumb to make an operator opt-in to do the right thing -- so we would prefer not to add an mv 14:44:46 <rosmaita> by the way, this is a real-life issue 14:44:55 <rosmaita> https://bugs.launchpad.net/cinder/+bug/1926630 14:44:55 <openstack> Launchpad bug 1926630 in Cinder "Creating an encrypted volume type without a cipher accepted but will fail to create an encrypted volume" [Medium,In progress] - Assigned to Eric Harney (eharney) 14:45:23 <rosmaita> Eric has a patch up that would add validation to the create request: https://review.opendev.org/c/openstack/cinder/+/789603/ 14:45:32 <gmann> rosmaita: currently in internal meeting too, but I will check review and bug report 14:45:49 <rosmaita> ok, thanks, we can discuss again 14:46:18 <rosmaita> another option that would avoid a mv would be for cinder to supply sensible default values for "missing" fields 14:46:53 <rosmaita> we could supply sensible default values for "missing" fields ... but that does not seem to be a good idea for this kind of thing: an operator should know exactly what they want & why when creating an encryption spec 14:47:03 <rosmaita> this is not the kind of thing you want to fool around with 14:47:25 <rosmaita> that's basically it, you can leave comments on the bug and tempest patch 14:47:26 <rosmaita> thanks! 14:47:32 <kopecmartin> yeah, that makes sense 14:47:45 <kopecmartin> i opened all the reviews , will check soon 14:47:46 <rosmaita> that's all from me, unless you have cinder questions :) 14:48:13 <kopecmartin> rosmaita: thanks for bringing it all up 14:48:42 <rosmaita> np, sorry i don't show up more often, but i have a standing conflict with office hours 14:49:10 <kopecmartin> no problem 14:49:39 <kopecmartin> #topic Bug Triage 14:49:41 <kopecmartin> #link https://etherpad.opendev.org/p/qa-bug-triage-xena 14:49:53 <kopecmartin> i don't have anything specific, the number are recorded at ^^ as always 14:50:07 <kopecmartin> anyone anything else to discuss? 14:51:20 <kopecmartin> if nothing else, we can close the office hour 14:51:26 <kopecmartin> thank you all for the participation! 14:51:34 <kopecmartin> #endmeeting