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