14:00:10 <melwitt> #startmeeting nova
14:00:21 <openstack> Meeting started Thu Apr 19 14:00:10 2018 UTC and is due to finish in 60 minutes.  The chair is melwitt. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:22 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:24 <openstack> The meeting name has been set to 'nova'
14:00:27 <mriedem> o/
14:00:29 <dansmith> o/
14:00:30 <gibi> o/
14:00:31 <takashin> o/
14:00:40 <melwitt> hi everybody
14:00:55 <melwitt> #topic Release News
14:01:04 <melwitt> #link Rocky release schedule: https://wiki.openstack.org/wiki/Nova/Rocky_Release_Schedule
14:01:07 <bauzas> \o
14:01:45 <melwitt> today is the first milestone r-1 and we're going to be doing releases for stable branches too as we've had a lot of fixes land there
14:01:51 <efried> ō/
14:01:59 <melwitt> we're also going to do a novaclient and osc-placement release
14:02:35 <melwitt> thanks to all who've been working on stable branch reviews. please continue helping today as I'll be proposing the release patches by EOD today
14:03:01 <melwitt> #link Rocky review runways: https://etherpad.openstack.org/p/nova-runways-rocky
14:03:09 <melwitt> #link runway #1: Add request_id to instance action notifications [END DATE: 2018-05-01] https://review.openstack.org/#/c/553288
14:03:15 <melwitt> #link runway #2: PowerVM Driver [END DATE: 2018-04-30] series starting at https://review.openstack.org/#/c/526094
14:03:21 <melwitt> #link runway #3: Consoles database backend [END DATE: 2018-05-01] series starting at https://review.openstack.org/325381
14:03:48 <gibi> the solution for runway #1 is on the gate as we speak
14:03:54 <melwitt> we moved the z/VM blueprint out of the runway early, please see the Log area of the etherpad for details. there's a ML thread about it
14:03:57 <jaypipes> o/
14:03:58 <melwitt> gibi: a-ha, nice
14:04:00 <edleafe> \o
14:04:48 <melwitt> the forbidden traits blueprint was merged within 2 days of being added to a runway
14:05:28 <melwitt> does anyone have anything else for release news?
14:05:41 <efried> .
14:05:48 <efried> I was gonna bring up a runway suggestion.
14:06:05 <efried> It may not be necessary, if we're getting good movement as is
14:06:48 <efried> but the idea was: to assign a "champion" to each runway.  Could be core, could be not, but shouldn't be the series owner.  The champion is responsible for pestering cores for reviews and owners for followups.
14:07:31 <cdent> -1. seems to assume cores and owners can't be trusted (or required) to have self-discipline
14:07:35 <efried> Seems like it's not needed right now, but perhaps something to keep in the back of our minds as we move forward and the runway concept loses some of its shiny.
14:08:20 <efried> ack.  No need to discuss further, just wanted to get it off my brain and make room for other stuff.
14:08:22 <efried> moving on.
14:09:27 <melwitt> okay, we'll keep that in mind then. I hadn't been thinking of having additional pestering going on for runways so far
14:09:33 <mriedem> as for runways
14:09:37 <mriedem> https://review.openstack.org/#/c/553288/ - was just approved, but
14:09:57 <mriedem> in case we care to pull it out, i know Kevin_Zheng said he was heading out
14:10:06 <mriedem> pull it out of the gate i mean
14:10:25 * tssurya waves late
14:11:34 <gibi> mriedem: can we add the unit test in a followup?
14:11:35 <melwitt> okay. is it missing test coverage, should we just ask Kevin_Zheng for a follow on patch or?
14:11:54 <mriedem> follow up for the unit test is fine, i care more about the ugly method sig
14:12:04 <mriedem> which i guess can also be refactored in a follow up?
14:12:19 <mriedem> if so, then carry on
14:12:38 <gibi> mriedem, melwitt: I OK to ask for a followup
14:12:45 <mriedem> ok
14:12:46 <melwitt> for that maybe we should pull it from the gate because that goes along with a object version bump
14:12:54 <mriedem> oh...yeah...
14:12:56 <melwitt> or does it not affect that?
14:13:03 <mriedem> i believe it does
14:13:07 <mriedem> the hash is based on the signatures
14:13:12 <mriedem> dansmith: right?
14:13:24 <arvindn0_> i thought only on field signatures
14:13:37 <mriedem> no the hash is fields and methods
14:13:38 <dansmith> it hashes remotable method signatures yeah
14:13:48 <efried> The object signature doesn't change.
14:13:48 <gibi> __init__ is not remotable
14:13:53 <dansmith> if it's remotable then it'll matter, but not if it's just a regular method
14:13:54 <efried> ^
14:14:02 <efried> The arg is just in the init signature
14:14:19 <efried> the object's request_id is being set from the contents of the context param in the init.
14:14:27 <efried> So that's copacetic, right?
14:14:43 <melwitt> I dunno, I'd tend to pull it out of the gate to refactor all of those. when I suggested followup I was thinking of just the missing unit test
14:14:51 <mriedem> what if i just pull it, fix it myself so kevin doesn't have to stay up for this, and then bug gibi and efried once it's ready
14:15:09 <melwitt> that sounds like a good plan to me
14:15:15 <gibi> mriedem: let's do that
14:15:17 <efried> mriedem: ++
14:15:34 <mriedem> done
14:15:35 <mriedem> thanks
14:15:38 <mriedem> sorry for the distraction
14:15:45 <melwitt> cool. no worries
14:15:59 <melwitt> anything else on release news or runways?
14:16:21 <melwitt> #topic Bugs (stuck/critical)
14:16:33 <melwitt> no critical bugs in the query
14:16:39 <melwitt> #link 35 new untriaged bugs (up 3 since the last meeting): https://bugs.launchpad.net/nova/+bugs?search=Search&field.status=New
14:16:54 <melwitt> untriaged bug count is creeping up, we need to do some more triage
14:17:03 <melwitt> #link 9 untagged untriaged bugs: https://bugs.launchpad.net/nova/+bugs?field.tag=-*&field.status%3Alist=NEW
14:17:10 <melwitt> #link bug triage how-to: https://wiki.openstack.org/wiki/Nova/BugTriage#Tags
14:17:22 <melwitt> that page has a good how-to guide on triage ^
14:17:31 <melwitt> Gate status
14:17:37 <melwitt> #link check queue gate status http://status.openstack.org/elastic-recheck/index.html
14:17:50 <melwitt> gate has seemed relatively smooth lately
14:17:56 <bauzas> melwitt: we need more triagers, that's what we need
14:17:57 <mriedem> i've got a request for ci
14:18:09 <mriedem> i'd like to see the nova-multiattach job be voting again https://review.openstack.org/#/c/554317/
14:18:16 <bauzas> melwitt: because I won't able to review bugs for like the two next milestones
14:18:16 <mriedem> so it doesn't regress
14:18:36 <mriedem> bauzas: i've already started a 3D print job for a new triager
14:18:39 <mriedem> should be ready in a few hours
14:18:43 <melwitt> heh
14:18:59 <melwitt> yeah, we could use help from more people to triage bugs
14:19:35 <melwitt> and yes, also would be good to get the nova-multiattach job voting again. just needs one more +2
14:19:44 <melwitt> 3rd party CI
14:19:44 <mriedem> i'll do some triage after fixing up kevin's patch
14:19:51 <bauzas> mriedem: we need robots
14:19:58 <melwitt> thanks mriedem
14:20:00 <bauzas> mriedem: with 3 laws of Asimov
14:20:08 <melwitt> #link 3rd party CI status http://ci-watch.tintri.com/project?project=nova&time=7+days
14:20:22 <bauzas> melwitt: mriedem: +Wd for multiattach job
14:20:28 <mriedem> thanks
14:20:52 <melwitt> anything else for bugs or gate status or CI?
14:21:20 <melwitt> #topic Reminders
14:21:28 <melwitt> #link Rocky Review Priorities https://etherpad.openstack.org/p/rocky-nova-priorities-tracking
14:22:04 <melwitt> find and add subteam and bug reviews here to get more visibility ^
14:22:51 <melwitt> I posted nova-related forum topic links to the ML http://lists.openstack.org/pipermail/openstack-dev/2018-April/129488.html
14:23:04 <melwitt> that have been proposed
14:23:14 <melwitt> just FYI
14:23:39 <melwitt> does anyone have anything else for reminders?
14:24:11 <melwitt> #topic Stable branch status
14:24:16 <melwitt> #link stable/queens: https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:stable/queens,n,z
14:24:32 <mriedem> once that one change merges we can release
14:24:34 <melwitt> nice, good progress on reviews for queens
14:24:41 <melwitt> sweet
14:24:48 <bauzas> I'm on pike as of now
14:24:50 <melwitt> #link stable/pike: https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:stable/pike,n,z
14:24:58 <melwitt> cool bauzas
14:25:08 <efried> sounds painful
14:25:15 <melwitt> #link stable/ocata: https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:stable/ocata,n,z
14:25:32 <edleafe> efried: you're on a roll today
14:25:58 <melwitt> ocata looks pretty good. need another person for some reviews that were posted by lyarwood
14:26:24 <melwitt> thanks for all of the reviews on stable
14:26:35 <melwitt> anything else for stable branch status?
14:27:01 <melwitt> #topic Subteam Highlights
14:27:30 <bauzas> just one note, folks, please keep in mind when you review a stable patch to check whether all the libs and calls to other modules are supporting what's called
14:27:34 <melwitt> dansmith: cells v2, we skipped the meeting. anything else you'd like to highlight?
14:27:40 <dansmith> melwitt: nope
14:28:29 <melwitt> yup, that's a good reminder bauzas. I especially find that's true related to os-brick
14:28:42 <melwitt> edleafe: scheduler?
14:28:48 <edleafe> Agreed that the granular request work should be added to the Main Themes section of the weekly placement update.
14:28:51 <edleafe> cdent agreed to create a spec for forbidden traits syntax to keep the Nova gods happy even though most felt it wasn't needed and would take longer than implementing would.
14:28:55 <edleafe> We agreed that listing all the ongoing reviews as links in the meeting really isn't necessary, and would be replaced by a single link to the most recent placement update email.
14:28:59 <edleafe> edleafe and efried snickered at mriedem's getting 8 inches of snow last weekend, while we enjoyed the warm Texas spring.
14:29:02 <edleafe> that's it
14:29:24 <bauzas> 8 inches of snow is meaningless if you can't ski them
14:29:34 <efried> Update on forbidden trait syntax in flavors
14:29:43 <edleafe> bauzas: on the Mountains of Minnesota? :)
14:29:50 <efried> cdent made a specless bp, which was approved, and the code was merged, so it's closed out.
14:29:58 <jaypipes> edleafe: worst movie ever.
14:30:09 <edleafe> jaypipes: shortest one, too
14:30:23 <mriedem> fwiw,
14:30:23 <melwitt> efried: so no spec needed after all or?
14:30:43 <mriedem> nova using forbidden traits in extra specs could have just been lumped in with the other bp for adding forbidden trait support in placement,
14:30:45 <cdent> there was overlap of instruction on that stuff
14:30:46 <efried> melwitt: The paragraph in the bp was sufficient.
14:30:49 <melwitt> just making sure I understand the status
14:30:52 <mriedem> like alex's bp for traits during scheduling in queens
14:31:02 <cdent> i had already made a blueprint when eric asked for a spec update
14:31:04 <efried> cdent also made a slight update to the original spec to indicate where we landed on that.
14:31:11 <melwitt> k
14:31:22 <efried> I believe both bps are closed at this point.
14:31:24 <cdent> yes
14:31:38 <melwitt> okay, cool
14:31:52 <melwitt> gibi: notification subteam?
14:31:58 <gibi> sure
14:32:11 <gibi> I'm back so we have a fresh status mail
14:32:15 <gibi> #link http://lists.openstack.org/pipermail/openstack-dev/2018-April/129398.html
14:32:25 <gibi> with couple of new bugs to look at
14:33:07 <gibi> on the meeting we agreed to ask for a spec amendment of the 'Add trusted_image_certificates to REST API' feature to include the certificate id to the notifications
14:33:22 <gibi> and then a followup patch as well
14:33:31 <mriedem> jackie-truong: ^
14:34:00 <gibi> to help the future spec authors I proposed a spec template update describing what to consider for notifications
14:34:19 <gibi> #link https://review.openstack.org/#/c/562265/
14:34:24 <melwitt> ah, that sounds like a good idea
14:34:59 <gibi> mriedem filed a bug https://bugs.launchpad.net/nova/+bug/1763051
14:35:01 <openstack> Launchpad bug 1763051 in OpenStack Compute (nova) "Need to audit when notifications are sent during live migration" [Medium,Triaged]
14:35:06 <jackie-truong> gibi: Thanks, we'll work on a spec amendment
14:35:15 <gibi> jackie-truong: ping me if you need help
14:35:35 <jackie-truong> gibi: Absolutely, will do
14:35:53 <gibi> and I filed a backlog bp to cover in general the problem that some of the start / end notifications are not at the start or end of the ection
14:35:57 <gibi> *action
14:36:04 <gibi> #link https://blueprints.launchpad.net/nova/+spec/emit-start-end-versioned-notifications-to-the-start-and-end-of-the-given-action
14:36:26 <gibi> note that this bp does not intended for Rocky
14:36:38 <gibi> that is all
14:36:49 <melwitt> cool
14:37:09 <melwitt> does anything have anything else for subteam highlights?
14:37:13 <melwitt> *anyone
14:37:31 <melwitt> #topic Stuck Reviews
14:37:38 <melwitt> we have one in the agenda
14:37:47 <melwitt> https://review.openstack.org/#/c/486204/
14:37:52 <melwitt> Contention over the need for a certificate validation policy rule
14:37:58 <melwitt> http://lists.openstack.org/pipermail/openstack-dev/2018-April/129494.html
14:38:11 <dansmith> is that really stuck?
14:38:16 <melwitt> jackie-truong: did you want to explain that a bit?
14:38:34 <jackie-truong> I added that to the stuck reviews because we don't know how to move forward
14:39:02 <dansmith> that's not what this section is for :)
14:39:10 <jackie-truong> mriedem started a thread suggesting that we add a policy rule for cert validation
14:39:36 <jackie-truong> A couple of responses suggested that we don't need to do that, and a couple of responses suggested that we do
14:40:01 <dansmith> I think everyone is fine with a policy knob no?
14:40:01 <jackie-truong> We viewed this as "there is some disagreement that needs resolving"
14:40:47 <jackie-truong> jaypipes and Chris Friesen didn't see the need for it
14:40:54 <jackie-truong> But I suppose they didn't flat out say no
14:41:13 <dansmith> I don't think they said no to the policy knob
14:41:20 <dansmith> and I think jaypipes at least misunderstood what mriedem was saying
14:41:28 <jackie-truong> Okay, sorry for the misunderstanding
14:41:51 <jackie-truong> We'll work on a new patch to add a policy rule for cert validation
14:43:05 <dansmith> melwitt: moving on?
14:43:34 <melwitt> okay, I think I didn't see how the thread was discussing the policy rule thing except for the first post
14:43:42 <melwitt> (reading through it again)
14:43:47 <dansmith> because it's not contentious I think :)
14:44:28 <melwitt> okay, so we'll have the policy rule in addition to the fail messages if BFV?
14:45:01 <dansmith> yeah
14:45:11 <melwitt> just so it can be turned off by operators if their config doesn't support it? okay, cool
14:45:20 <dansmith> or if they don't want you using it
14:45:26 <melwitt> yeah
14:45:43 <melwitt> okay, anything else for stuck reviews?
14:45:56 <melwitt> #topic Open discussion
14:46:03 <melwitt> one agenda item
14:46:08 <melwitt> (mriedem): specless blueprint https://blueprints.launchpad.net/nova/+spec/hide-hypervisor-id-flavor-extra-spec
14:46:15 <melwitt> This is just making the 'img_hide_hypervisor_id' image property also work using flavor extra specs.
14:46:28 <mriedem> just parity, simple, i'm +1 on the change
14:46:35 <melwitt> me too, +1
14:47:01 <bauzas> I have another item
14:47:06 <arvindn0_> wanted to discuss https://review.openstack.org/#/c/560718/ - Handle rebuild of instance with new image, because it seems like there is a lot of history with rebuild and where placement comes into play
14:47:12 <bauzas> (forgot to add it to the agenda)
14:47:21 <melwitt> okay, hang on
14:47:34 <melwitt> so we have two +1 to approving the feature parity spec, any other votes?
14:47:43 <bauzas> +1 for specless BP
14:48:18 <melwitt> okay, no one in opposition, so we'll approve that
14:48:28 <gibi> +1 too for the flavor extra_spec addition
14:48:33 <bauzas> (even if I don't like hiding KVM for business reasons :p )
14:48:33 <melwitt> bauzas: what is your item?
14:48:41 <bauzas> arvindn0_ has one thing fiesrt
14:48:51 <arvindn0_> ty bauzas
14:49:10 <melwitt> go ahead arvindn0_
14:49:20 <arvindn0_> wanted to discuss the rebuilding of servers and when placement comes into play
14:50:02 <bauzas> we had a chat with arvindn0_ yesterday
14:50:11 <bauzas> I gave him the context we discussed at the PTG
14:50:24 <arvindn0_> currently for a rebuild, placement is not called because of bug https://bugs.launchpad.net/nova/+bug/1750623
14:50:25 <openstack> Launchpad bug 1750623 in OpenStack Compute (nova) pike "rebuild to same host with different image shouldn't check with placement" [Medium,In progress] - Assigned to Lee Yarwood (lyarwood)
14:50:26 <bauzas> basically about rebuilds having tech debt
14:51:11 <arvindn0_> since we are adding traits to images, incase the image/image traits changes, we want to call placement
14:51:59 <melwitt> yeah, I would think you would have to call placement if image traits are involved
14:52:19 <arvindn0_> but there are differing opinions...i think last comment from alex suggested we just reject rebuild when image changes along with its metadata
14:52:25 <mriedem> i'm -1 on that
14:52:37 <melwitt> I would be -1 on that too
14:52:38 <dansmith> personally, I don't think this is something we need to hold everyone on the team captive to discyss
14:52:41 <bauzas> I think we are creating problems
14:52:43 <mriedem> if we did that, the user can rebuild with certain images but not others, which is bad UX
14:52:47 <dansmith> it's been discussed in the nova channel, and will continue to be,
14:52:49 <bauzas> zactly that
14:52:51 <dansmith> but it's a subset of people, IMHO
14:53:05 <mriedem> i said i'd go back over the spec again today which i will, later
14:53:19 <mriedem> we agreed earlier to call placement, but were bikeshedding on implementation details
14:53:30 <bauzas> mriedem: we also have the fact we set the target before calling the scheduler
14:53:49 <bauzas> mriedem: I'd like that to be fixed *before* we'd do any further check
14:53:59 <mriedem> i don't know what that has to do with this,
14:54:02 <mriedem> but let's move the discussion
14:54:18 <melwitt> okay, let's convene on the spec to make our comments
14:54:28 <arvindn0_> cool...thanks
14:54:37 <melwitt> bauzas: did you have a thing for open discussion?
14:54:43 <bauzas> yup
14:54:53 <arvindn0_> rebuild seems to be a touchy, complicated topic :)
14:55:04 <bauzas> https://review.openstack.org/#/c/557065/ was spec'd
14:55:13 <mriedem> arvindn0_: the first rule of rebuild is you don't talk about rebuild
14:55:15 <jaypipes> arvindn0_: one of many such topics.
14:55:22 <bauzas> because I was proposing a new conf opt
14:56:20 <bauzas> after a few comments, looks like the consensus is just to either A/ don't do anything and leave people create things first out of nova or B/ write something which is not a conf opt, but rather an external descriptor, like a YAML file
14:56:37 <bauzas> both A/ and B/ don't really look specy to me
14:56:41 <bauzas> specky*
14:56:51 <edleafe> spec-y
14:56:56 <edleafe> :)
14:56:57 <mriedem> ha, i like how you're correcting spelling for something that's not a word
14:57:11 <edleafe> mriedem: exactly
14:57:21 <bauzas> call my French
14:57:26 <bauzas> anyway
14:57:40 <bauzas> worth considering that an implementation detail and abandon the spec ?
14:57:45 <melwitt> if there's a YAML file, wouldn't the format of that be documented in the spec or?
14:58:14 <bauzas> I think we can leave that for the implementation, but that's my opinion
14:58:25 <bauzas> having code to show up would help
14:58:38 <mriedem> if we're going to start adding new yaml file things for stuff, i'd like to see a design written up for that
14:58:40 <mriedem> personaly
14:58:49 <melwitt> me too
14:58:50 <mriedem> *personally
14:58:51 <mriedem> :)
14:59:00 <bauzas> personnall-y ?
14:59:03 <melwitt> for things like the metadata response format, old specs are the only place it's documented
14:59:15 <bauzas> okay, I'll consider  that
14:59:33 <bauzas> jaypipes had a spec up for a YAML descriptor file
14:59:40 <melwitt> so, in those cases people are glad they exist else there's no decent way for them to see how the format is supposed to be
14:59:46 <bauzas> but let's punt of the meeting
14:59:47 <bauzas> we're late
14:59:47 <mriedem> 10 seconds...
15:00:03 <melwitt> yeah, we have to end now
15:00:05 <melwitt> #endmeeting