14:00:11 <efried> #startmeeting nova
14:00:19 <openstack> Meeting started Thu Mar  5 14:00:11 2020 UTC and is due to finish in 60 minutes.  The chair is efried. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:20 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:23 <openstack> The meeting name has been set to 'nova'
14:00:35 <lyarwood> \o
14:01:00 <efried> #link agenda https://wiki.openstack.org/wiki/Meetings/Nova#Agenda_for_next_meeting
14:01:10 * johnthetubaguy lurks
14:01:31 <brinzhang> \o
14:02:41 <efried> let's get started and let folks trickle in
14:02:44 <efried> #topic Last meeting
14:02:44 <efried> #link Minutes from last meeting: http://eavesdrop.openstack.org/meetings/nova/2020/nova.2020-02-27-21.00.html
14:03:05 <efried> I was alone there, so I'll again go over...
14:03:11 <efried> #link Minutes from last last meeting: http://eavesdrop.openstack.org/meetings/nova/2020/nova.2020-02-20-14.00.html
14:03:33 * efried efried unblock and +W the support-volume-local-cache spec after the meeting https://review.opendev.org/#/c/689070/
14:03:33 <efried> Done
14:03:33 * efried efried to fup with lyarwood about rocky EM
14:03:33 <efried> See Release Planning below
14:03:33 * efried efried to look at the nova PTL guide and update if/as appropriate
14:03:33 <efried> #link Nova PTL guide https://docs.openstack.org/nova/latest/contributor/ptl-guide.html
14:03:48 <efried> I did that ^, it looked okay to me as is
14:03:55 <efried> sfe fup: destroy-instance-with-datavolume http://lists.openstack.org/pipermail/openstack-discuss/2020-February/012616.html
14:03:55 <efried> Done (approved)
14:04:02 <efried> anybody have other old business to bring up?
14:04:23 <efried> #topic Bugs (stuck/critical)
14:04:23 <efried> No Critical bugs
14:04:29 <brinzhang> efried: I have pushed this code, need to review
14:04:45 <brinzhang> destroy-instance-with-datavolum
14:04:45 * lyarwood has it open to review
14:05:03 <lyarwood> note there's about 4 of us trying to land on the 2.83 microversion at the moment
14:05:16 <efried> um
14:05:18 <lyarwood> nothing new, just wanted to note that things much get messy
14:05:24 <lyarwood> might*
14:05:25 <brinzhang> yes, 4 feature need add a microversion
14:05:49 * gmann in tc meeting going in parallel
14:05:53 <johnthetubaguy> we handed out microversions in the past, and linked with depends-on, is that worth doing?
14:06:13 <johnthetubaguy> problem is picking the order
14:06:25 <efried> okay, I thought https://review.opendev.org/#/c/692707/ was 2.83 already, but it's 2.82. Carry on.
14:06:55 <efried> johnthetubaguy: If the patches are ready, that sounds doable.
14:07:08 <brinzhang> yes, nova-cyborg-interaction feature was already get v2.82
14:07:36 <brinzhang> efried: agree
14:07:44 <efried> johnthetubaguy: someone would have to coordinate though (hint: it won't be me)
14:08:23 <efried> otherwise, we must carry on in gold-rush fashion.
14:08:27 * johnthetubaguy nods, and looks busy
14:08:28 <brinzhang> The policy defaut refresh patch need more works on
14:08:44 <efried> Back to bugs...
14:09:05 <efried> I'll note that our new/untriaged count leveled off since last time, but it's still way high (108)
14:09:18 <efried> #link 108 new untriaged bugs: https://bugs.launchpad.net/nova/+bugs?search=Search&field.status=New
14:09:25 <efried> #link bug triage how-to: https://wiki.openstack.org/wiki/Nova/BugTriage#Tags
14:09:25 <efried> #help need help with bug triage
14:09:43 <efried> #topic Release Planning
14:09:43 <efried> Rocky EM (lyarwood)
14:09:43 <efried> #link nova EM patch is merged https://review.opendev.org/#/c/709902/
14:09:53 <efried> Thanks for driving that lyarwood
14:10:11 <lyarwood> well thanks to you and elod for doing most of the work :)
14:10:52 <efried> We're in the release phase where we should be working features, and...
14:10:59 <efried> #topic PTG/Summit planning
14:10:59 <efried> Please mark attendance and topics on
14:10:59 <efried> #link PTG etherpad https://etherpad.openstack.org/p/nova-victoria-ptg
14:11:20 <efried> Any comments on release or PTG/summit planning?
14:11:37 <efried> #topic Sub/related team Highlights
14:11:37 <efried> Placement (tetsuro)
14:11:56 <efried> It looks like melwitt and tetsuro are iterating on the consumer types feature.
14:12:03 <efried> No other news that I'm aware of here.
14:12:16 <efried> API (gmann)
14:12:16 <efried> API related BP coding in progress. Other than that not so much change this week. Most of the things are covered in spec/features approval work.
14:12:16 <efried> Last week update: http://lists.openstack.org/pipermail/openstack-discuss/2020-February/012563.html
14:12:36 <efried> (note, I think that ^ is last-last week's update)
14:12:46 <gmann> sorry i did not update the status for this week
14:12:58 <efried> sokay, we're operating on a 2-week deficit anyway
14:13:16 <efried> has anything changed since then gmann?
14:13:23 <gmann> one update on policy stuff is johnthetubaguy and myself discussing on  few more test cases to cover more on admin_or_owner side
14:13:24 <brinzhang> gmann: Support re-configure deleted_on_termination in server this BP code is ready ^^
14:13:38 <gmann> brinzhang: thanks i will check today.
14:13:53 <brinzhang> gmann: np
14:14:06 <efried> #topic Stuck Reviews
14:14:06 <efried> Any?
14:14:19 <alistarle> Hi, do you know what is missing on this patch https://review.opendev.org/#/c/701609 ? I heard about some microversion conflicts, so I can bump it if needed
14:14:44 <brinzhang> https://review.opendev.org/#/c/709955/2
14:14:44 <efried> alistarle: at a glance, the patch is currently in merge conflict
14:15:08 <efried> alistarle: do you know how to fix that?
14:15:11 <brinzhang> These patches are ready to review, link is the first one https://review.opendev.org/#/c/709955/2
14:15:55 <lyarwood> https://review.opendev.org/#/q/status:open+topic:workaround_native_luksv1 & https://review.opendev.org/#/q/status:open+topic:rbd_block_device - I'm trying to introduce some workaround options for a libgcrypt perf issue impacting native LUKS decryption. I'm not sure if this needs a bug, specless BP or full blown spec next cycle tbh.
14:16:15 <lyarwood> ^ any suggestions welcome, I can also take this to the ML.
14:16:44 <lyarwood> https://review.opendev.org/#/q/status:open+topic:bug/1861071 - and another encryption related bugfix series could use reviews if anyone aside from stephenfin has time.
14:16:54 <alistarle> Yeah I saw that, it was not there when I look at it some days ago
14:17:01 <efried> alistarle: other than that, I'm afraid slow reviewer response is just par for the course, given code volume : maintainer ratio. But you can bug folks for reviews in #openstack-nova periodically :)
14:17:10 <brinzhang> johnthetubaguy, gmann: with the os-instance-actions poliy change, I modified the unit/policies/base.py, hope you can reivew https://review.opendev.org/#/c/707777/5/nova/tests/unit/policies/base.py
14:17:40 <efried> alistarle: oh, the conflict will be the patch I mentioned earlier: https://review.opendev.org/#/c/692707/ got microversion 2.82 already.
14:18:03 <brinzhang> That we can get the api response to assert what we want while fatal=False.
14:18:05 <efried> alistarle: so you'll have to rebase and bump your microversion to 2.83 -- whereupon you'll be entering the race with several other patches wanting the same one :/
14:18:34 <johnthetubaguy> brinzhang: cool, thank you, I will try review that again soon
14:19:02 <brinzhang> johnthetubaguy> thanks
14:19:06 <alistarle> efried: Ok, let's compete for this race then ;)  I will refactor the patch
14:19:31 <efried> Cool.
14:19:34 <efried> Let's move on.
14:19:38 <efried> #topic Open discussion
14:19:38 <efried> [efried] Exiting OpenStack
14:19:38 <efried> #help PTL pro tem needed
14:19:38 <efried> #link call for volunteers http://lists.openstack.org/pipermail/openstack-discuss/2020-February/012663.html
14:19:46 <efried> Tomorrow is my last official day
14:19:56 <efried> however, I'm supposedly on vacation
14:20:01 <efried> so basically already gone.
14:20:06 <tframbo> Excuse me, I have a question about the flavor. The property "OS-FLV-DISABLED:disabled" defined when we created the flavor, but there is no method to change this property.I want to know our community how to consider this condition.
14:20:20 <tframbo> https://docs.openstack.org/api-ref/compute/?expanded=list-migrations-detail,id320-detail,update-flavor-description-detail,create-flavor-detail#create-flavor
14:20:27 <efried> tframbo: hold on a bit please
14:20:51 <brinzhang> efried: Because of the new crown virus, please take good protection, if possible, try not to go out.
14:20:57 <efried> I will be f'real taking today and tomorrow off, at least partially.
14:21:18 <efried> brinzhang: Thanks for your concern. I'm not worried about exposure here.
14:21:40 <brinzhang> efried: ah, good luck ^^
14:22:04 <efried> After this week, I'll probably still hang around on IRC a bit, but will be unlikely to be doing a whole lot.
14:22:26 <efried> A couple of folks have talked to me privately about taking over the PTL role.
14:22:31 <efried> But nothing has solidified as yet.
14:23:00 <efried> So we at least need someone to run next week's meeting.
14:23:42 <gmann> FYI, PTL election will be on April 7th-14th
14:23:43 <gmann> https://governance.openstack.org/election/
14:24:09 <efried> Given recent attendance at the 2100UTC meetings, I would also suggest trying to move & consolidate our meeting times.
14:24:09 <brinzhang> gibi, stephenfin, alex_xu, lyarwood?
14:24:36 <lyarwood> brinzhang: I'm expecting to be out on paternity sometime soon otherwise I would sorry.
14:25:16 <stephenfin> I'd never be able to attend the 2100 UTC meeting, unfortunately
14:25:20 <brinzhang> lyarwood: congratulations!
14:25:38 <efried> If we made it 1600 UTC every week, that would allow folks from US Pacific through Euro to attend during business hours.
14:25:49 <brinzhang> That time is too early for alex_xu and me.
14:26:09 <stephenfin> but I could run the other one if gibi really can't (since he's run meetings in the past :))
14:26:17 <stephenfin> 1600 UTC wfm also
14:26:33 <efried> I'm not going to try to pull the trigger on this schedule change, just making a suggestion.
14:26:42 <brinzhang> 1600UTC too later for US in China
14:27:10 <efried> gibi has volunteered to run the early meetings regardless of PTL-ship
14:27:12 <brinzhang> s/US/us
14:27:44 <efried> okay brinzhang. Problem is that the current time is way too early for west coast US like dansmith and melwitt
14:27:53 <efried> (less so after DST is over)
14:28:12 <efried> anyway, I'll just leave that on the table and let my posterity sort it out.
14:28:58 <lyarwood> stephenfin: are you taking that?
14:29:09 <stephenfin> taking what?
14:29:21 <lyarwood> stephenfin: moving the meeting, running the next one etc.
14:29:26 <stephenfin> <efried> gibi has volunteered to run the early meetings regardless of PTL-ship
14:29:26 <brinzhang> efried: Yeah, everyone has the different time to attend meeting, too later or earlier ..
14:29:34 <lyarwood> stephenfin: ah sorry
14:29:41 <efried> stephenfin: but next week's is a 'late' meeting.
14:30:04 <stephenfin> Ah, yeah, I can't do those. Thursday's are date night :(
14:30:12 <stephenfin> *Thursdays
14:30:19 <efried> I could probably just cancel it. Attendance has been very light there anyway.
14:30:31 <lyarwood> stephenfin: but you need a date for that to be an issue right?
14:30:38 <efried> ouch
14:31:00 <stephenfin> lyarwood: alcohol, my good man.
14:31:06 <lyarwood> haha
14:31:09 * efried celebrates 23y of marriage this year. Every night is date night.
14:31:26 <brinzhang> cool, alcohol
14:32:05 <efried> so, I'll cancel it, and if someone can run it, they can resurrect it.
14:32:09 <efried> moving on.
14:32:12 <gmann> efried: wow, congrat!
14:32:20 <efried> :) thanks
14:32:22 <efried> [shilpasd] Ignore root_gb if instance is booted from volume
14:32:22 <efried> Help to finalize approaches suggested by Dan Smith https://review.opendev.org/#/c/694462/8/nova/db/sqlalchemy/api.py@2008
14:32:22 <efried> IMO option #1 is more performance efficient with less code changes.
14:32:43 <efried> shilpasd: you around?
14:33:02 <shilpasd> yes
14:33:33 <shilpasd> Alex voted for option2
14:34:07 <shilpasd> I think Dan also prefer option2
14:34:55 <shilpasd> option1 suggests to have extra column at instances table
14:35:26 <shilpasd> option2 suggests to modify instance query itself to join BDMS
14:35:57 <efried> Without dansmith and alex_xu here to discuss, is there a way to make progress?
14:36:20 <efried> perhaps asking stephenfin or lyarwood to weigh in?
14:36:26 <efried> (on the review)
14:36:28 <shilpasd> yes please
14:36:59 <lyarwood> efried: ack can do, option #2 does appear the way to go at first glance.
14:37:04 <johnthetubaguy> FWIW, option 1 sounds like caching, which always turns out to be hard to get right, option 2 seems OK
14:37:13 <johnthetubaguy> but yeah, its just a first glance
14:38:20 <efried> shilpasd: were you the only one advocating for option 1?
14:38:53 <shilpasd> ya, option1 performance efficient with less code changes.
14:39:21 <efried> okay, but it sounds like everyone else (including several cores) prefers option 2, so....
14:39:25 <shilpasd> for option2,  instance query is at many places
14:40:49 <efried> I don't have context on the change, but surely there's a way to make it so you don't have to touch every instance query
14:41:12 <efried> we have code paths where we build up bits of SQL conditionally based on what's requested.
14:41:31 <shilpasd> so suggesting to touch where simple tenant usage api referring
14:41:41 <efried> and certainly we have responses pared down to just what's necessary, where necessary.
14:41:51 <johnthetubaguy> while we are talking about the API change, alex_xu noted that it is a big behaviour change, so needs a microversion and a spec
14:42:22 <shilpasd> patch is to address https://bugs.launchpad.net/nova/+bug/1715570
14:42:23 <openstack> Launchpad bug 1715570 in OpenStack Compute (nova) "simple tenant usage api calculating disk usages incorrectly" [Medium,In progress] - Assigned to Shilpa Devharakar (shilpasd)
14:42:44 <johnthetubaguy> while it is a bug, its still an API behaviour change, so needs a microversion
14:43:06 <shilpasd> agree on microversion, but do we need spec?
14:43:09 <johnthetubaguy> some people rely on the hold behaviour, no matter how nuts it might seem
14:43:20 <johnthetubaguy> s/hold/old/
14:43:24 <shilpasd> and still its a bug
14:43:53 <efried> traditionally, any API change requires a spec
14:43:56 <gmann> yeah, API change need spec
14:44:07 <brinzhang> agree, add a spec for this change
14:44:12 <efried> and procedurally, that means it won't land this release.
14:44:24 <efried> unless rules are bent.
14:44:36 <shilpasd> ok
14:44:49 <johnthetubaguy> bugs can be a good excuse for a spec freeze exemption, but agreed with the above
14:45:36 <johnthetubaguy> for context: any API change that is merged has to be maintained for all time, so its good to make sure we make the correct change to the API
14:45:45 <efried> I'll just leave this here
14:45:45 <efried> https://www.grin.com/document/284052
14:46:12 <efried> but yeah, bug fix for granting freeze exception wfm
14:46:37 <efried> Have we landed on this? Moving on?
14:46:49 <shilpasd> one more help needed
14:46:51 <johnthetubaguy> this API call usually takes out the database anyway, so shrugs
14:47:10 <shilpasd> i have one question asked here https://review.opendev.org/#/c/694463/8/nova/objects/instance.py@102
14:47:38 <shilpasd> Dan suggested to have extra column to be part of '_INSTANCE_OPTIONAL_JOINED_FIELDS'
14:48:05 <shilpasd> but getting ArgumentError, so moved to '_INSTANCE_OPTIONAL_NON_COLUMN_FIELDS'
14:48:17 <shilpasd> so is it correct understanding?
14:48:43 <shilpasd> i am adding one column 'is_volume_backed' which  don't translate to db columns
14:48:49 <dansmith> shilpasd: just like several other fields there, you can still handle that field specially at the database instead of letting it go straight into the join
14:49:58 <shilpasd> dansmith: ya, that understood, and that's the you suggesting as option2
14:50:38 <dansmith> shilpasd: please go look at how system_metadata or metadata, or others are handled to go into the optional_join_fields set, yet they don't get joined directly as a column in the final query
14:51:00 <dansmith> which is what you're trying to do *currently* and why you don't need a new bespoke field set parameter
14:52:11 <efried> We're short on time and have one more topic. shilpasd/dansmith can you continue in -nova or the review?
14:52:35 <efried> tframbo: you had a question about a DISABLED flavor property?
14:52:59 <tframbo> yeah
14:53:15 <shilpasd> dansmith: ok, will check it and get back to you , thnaks
14:54:12 <shilpasd> So listing here action items, Dansmith please confirm
14:54:24 <tframbo> The property "OS-FLV-DISABLED:disabled" defined when we created the flavor, but there is no method to change this property.I want to know our community how to consider this condition.
14:54:43 <efried> that's the key, right?
14:54:48 <efried> the value is a bool (true/false)?
14:55:10 <efried> So as admin you should be able to set that property via the flavor API, no?
14:55:26 <tframbo> boolean
14:55:43 <tframbo> yes
14:56:02 <tframbo> we can't set it now
14:56:06 <efried> openstack flavor set --property OS-FLV-DISABLED:disabled=true $flavor ?
14:56:10 <efried> or something like that ^
14:56:43 <brinzhang> efried:  OS-FLV-DISABLED:disabled is a column of flavor, not extra spec
14:56:45 <dansmith> =false, but yes
14:57:02 <brinzhang> it's default value is false
14:57:04 <tframbo> we just allow modify the description about flavor
14:59:10 <efried> Let's continue this in #openstack-nova
14:59:10 <efried> It sounds like it may just be a documentation issue
14:59:35 <efried> So long, and thanks for all the fish.
14:59:35 <efried> #endmeeting