14:01:02 <gibi> #startmeeting nova
14:01:07 <openstack> Meeting started Thu Sep 20 14:01:02 2018 UTC and is due to finish in 60 minutes.  The chair is gibi. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:01:08 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:01:11 <openstack> The meeting name has been set to 'nova'
14:01:12 <mriedem> o/^2
14:01:13 <takashin> o/
14:01:13 <efried> ō/ again
14:01:14 <dansmith> \Oj
14:01:15 <gibi> sorry for the mixup
14:01:18 <mhen> o/
14:01:19 <bauzas> \o
14:01:19 <Luzi> o/
14:01:20 <gibi> old habits :)
14:01:23 <edleafe> \o
14:02:01 <gibi> let's get started
14:02:11 <gibi> #topic release news
14:02:25 <gibi> we have a Stein release schedule #link Stein release schedule: https://wiki.openstack.org/wiki/Nova/Stein_Release_Schedule
14:02:56 <gibi> #link Stein runway etherpad: https://etherpad.openstack.org/p/nova-runways-stein
14:03:02 <gibi> #link runway #1: Resource retrieving: add changes-before filter (brinzhang) [END: 2018-10-01] ; patch is the gate queue
14:03:06 <gibi> #link runway #2: https://blueprints.launchpad.net/nova/+spec/api-extensions-merge-stein (gmann) [END: 2018-10-03] ; one patch left #link https://review.openstack.org/#/c/603831/
14:03:10 <gibi> #link runway #3: <empty>
14:03:17 <gibi> the queue is empty so the last slot is still empty
14:03:35 <gibi> if you have someting that is ready for review then put that on the etherpad
14:04:16 <gibi> anyting else about release or runways to talk about?
14:04:59 <gibi> #topic bugs
14:05:16 <gibi> there is no Critical bug on our list
14:05:24 <gibi> #link 65 new untriaged bugs (up 15 since the last meeting): https://bugs.launchpad.net/nova/+bugs?search=Search&field.status=New
14:05:30 <gibi> #link 24 untagged untriaged bugs (up 14 since the last meeting): https://bugs.launchpad.net/nova/+bugs?field.tag=-*&field.status%3Alist=NEW
14:05:36 <gibi> #link bug triage how-to: https://wiki.openstack.org/wiki/Nova/BugTriage#Tags
14:05:40 <gibi> #help need help with bug triage
14:05:59 <gibi> there is an increase in the bugtriage queue most probably due to the PTG last week
14:06:39 <gibi> anything bug related we need to discuss?
14:07:42 <gibi> gate status #link check queue gate status http://status.openstack.org/elastic-recheck/index.html
14:07:47 <gibi> zuul is slow due to missing resources: #link http://lists.openstack.org/pipermail/openstack-dev/2018-September/134867.html
14:07:48 <mriedem> the gate is f'ed
14:07:56 <mriedem> it's not only missing nodes
14:08:17 <mriedem> we need to get the categorization rate up on http://status.openstack.org/elastic-recheck/data/integrated_gate.html
14:08:21 <bauzas> yup
14:08:26 <mriedem> 13.3% means we don't know what is failing
14:08:31 <mriedem> but lots of stuff is failing and resetting the gate
14:08:42 <mriedem> which is why it's taking multiple days to merge anything
14:09:22 <mriedem> that's it
14:09:37 <gibi> mriedem: thanks. then we need to do categorization and file bugs for not yet reported problems I guess
14:09:50 <bauzas> uncategorized doesn't really see a pattern for me but I can try to look at
14:10:03 <gibi> bauzas: thanks
14:10:40 <gibi> #topic reminders
14:10:47 <gibi> #link Forum session topic call for presentations is due Sept 26: https://etherpad.openstack.org/p/nova-forum-stein
14:11:13 <gibi> #link Stein Subteam Patches n Bugs: https://etherpad.openstack.org/p/stein-nova-subteam-tracking
14:11:57 <gibi> anything else we need to remind ourselves?
14:12:30 <mriedem> on the forum thing,
14:12:41 <mriedem> our etherpad cupboard is very bare https://etherpad.openstack.org/p/nova-forum-stein
14:12:53 * stephenfin wanders in
14:13:09 <mriedem> i don't have any great ideas, except nominating dan to talk about something
14:13:13 <mriedem> although,
14:13:33 <mriedem> dansmith: i noticed yesterday the public cloud wg already has a forum session proposal for changing ownership, so this would just roll into that
14:13:45 <dansmith> ah cool
14:13:52 <mriedem> https://etherpad.openstack.org/p/BER-forum-public-cloud
14:14:25 <mriedem> would be nice if we could see what other people are submitting like the before times...
14:14:38 <mriedem> tobberydberg: ^
14:14:51 <mriedem> we can move on
14:14:54 <gibi> mriedem: one thing I can think of is checking on cyborg-nova integration status as we talked a lot about that in Denver last week
14:15:10 <johnthetubaguy> could do a policy and quota direction refresh thing? but that is probably covered in keystone proposed sessions, I would assume
14:15:16 <mriedem> you think a lot is going to be done by the time we get to berlin?
14:15:33 <mriedem> johnthetubaguy: without knowing what's been proposed it's hard to tell...
14:15:41 <mriedem> i feel a rant coming on in the ML
14:15:51 <johnthetubaguy> yeah
14:16:09 <gibi> mriedem: I hope there will be progress in cyborg-nova. at least issues discovered during spec writing
14:16:16 <bauzas> well
14:16:33 <bauzas> I feel it's too early to ask operators to chime on cyborg/nova
14:16:43 <bauzas> given they don't exactly know how things will work, right?
14:17:03 <bauzas> like, I could be tempted to ask operators to come by and talk about vGPUs
14:17:08 <gibi> bauzas: right
14:17:20 <johnthetubaguy> the previous forum session on that topic was fairly pointless, not sure there is new info yet
14:17:44 <bauzas> but honestly, the numbers of people both interested and running queens would be super low
14:18:08 <bauzas> I was thinking of a bug triage session to see whether we could get some operators helping us
14:18:13 <gibi> OK, at least we tried to gather ideas about forum sessions :)
14:18:14 <bauzas> filing a bug is one thing
14:18:39 <bauzas> triaging the bug could be a thing for some operators that have good experience on the product
14:19:04 <bauzas> and that would one way to get more involved on projects (heh, tobberydberg)
14:19:10 <bauzas> would be*
14:19:27 <gibi> bauzas: let's add that idea to the etherpad
14:19:46 <bauzas> gibi: well, the etherpad is one thing, but the submissions are already open
14:20:06 <bauzas> I can post a proposal, but nobody will be able to review it
14:20:18 <bauzas> and I don't know who the review committee is
14:20:20 <bauzas> TC ?
14:20:31 <gibi> bauzas: I think it is worth trying to gather operators for bug triage
14:20:33 <johnthetubaguy> some folks from TC + UC I think
14:20:41 <bauzas> anyway, 20 mins just for that is too long, we should move on
14:20:51 <bauzas> I'll just write a proposal and see what people think
14:20:53 <mriedem> it's hard enough to get operators to report bugs, i don't think there is much hope for getting them to also triage bugs
14:20:58 <mriedem> if we can even get our core team to triage bugs
14:21:08 <mriedem> *can't
14:21:25 <mriedem> but yeah let's move on
14:21:31 <dansmith> please
14:21:43 <gibi> #topic stable branch status
14:21:49 <gibi> #link stable/rocky: https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:stable/rocky,n,z
14:21:55 <gibi> #link stable/queens: https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:stable/queens,n,z
14:21:58 <gibi> #link stable/pike: https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:stable/pike,n,z
14:22:03 <gibi> #link stable/ocata: https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:stable/ocata,n,z
14:22:18 <gibi> there are stable patches waiting in the gate queue as far as I see
14:22:22 <mriedem> yes, lots,
14:22:32 <mriedem> i have release requests up for rocky, queens and pike, stacked up,
14:22:42 <bauzas> time for reviews then
14:22:45 <mriedem> but was waiting for the rocky/queens approved changes to flush through before doing the actual release
14:22:56 <mriedem> the reviews have happened for the most part,
14:23:03 <mriedem> i mean, feel free - there are lots of open pike reviews
14:23:11 <mriedem> but i'm waiting for what's approved to merge before doing the release
14:23:23 <mriedem> and that's taking 3+ days because of the gate issues
14:23:33 <gibi> mriedem: thanks for the update
14:23:45 <gibi> anything else about the stable branches?
14:24:13 <gibi> #topic subteam highlights
14:24:21 <gibi> dansmith: cellv2
14:24:33 <dansmith> no cells meeting this week, not much to report since ptg
14:24:58 <gibi> efried: scheduler
14:25:34 <efried> I was not present; jaypipes-ooo ran the meeting. I assume ooo means he's not here to talk about it (either that or we're just supposed to be really impressed)
14:25:38 <cdent> i'm pretty sure there was no scheduler meeting. efried was out, i was out, and last I checked there was no log
14:25:52 <gibi> thanks
14:25:58 <efried> The logs are here: http://eavesdrop.openstack.org/meetings/scheduler/2018/scheduler.2018-09-17-13.59.log.html (jaypipes-ooo used 'scheduler' instead of 'nova_scheduler')
14:26:03 <gibi> gibi: notification
14:26:07 <gibi> there was no meeting
14:26:15 <bauzas> we had a scheduler meeting
14:26:29 <gibi> bauzas: do you have a summary?
14:26:57 <bauzas> well, I was a bit off for 20 mins during that meeting
14:27:35 <mriedem> tetsuro has a spec up for the !member_of thing
14:27:44 <gibi> I was also there but don't have memories
14:27:45 <cdent> thanks efried
14:27:47 <mriedem> i think that was about it
14:27:53 <gibi> OK
14:28:11 <mriedem> and i asked for a recap on the consumer generation series
14:28:22 <gibi> mriedem: ohh yes now I remember about that :)
14:28:42 <bauzas> we basically discussed a bit of CPU pinning PCPU resources, about the negative member_of, some reshape questions and some NUMATopologyFilter case
14:28:51 <bauzas> nothing really more than a PTG follow-up
14:28:56 <gibi> OK
14:29:09 <gibi> So there was no notification meeting but I sent the word out about the deprecation we agreed about on the PTG #link http://lists.openstack.org/pipermail/openstack-dev/2018-September/134721.html
14:29:20 <gibi> that is all about notifications
14:29:31 <gibi> gmann: API
14:29:43 <gibi> there is notes on the agenda
14:29:44 <gibi> No API office hour this week.
14:29:48 <gibi> Added the API cleanup items in spec. need Feedback on those -https://review.openstack.org/#/c/603969/
14:30:25 <gibi> any other subteam active at the moment?
14:30:50 <gibi> #topic stuck reviews
14:30:55 <gibi> nothing on the agenda
14:31:22 <gibi> #topic open discussion
14:31:30 <gibi> there is one item on the agenda
14:31:31 <gibi> (gibi): seeking for approval of the specless bp https://blueprints.launchpad.net/nova/+spec/use-nested-allocation-candidates
14:31:44 <claudiub> also, review the mock autospec patch? :D https://review.openstack.org/#/c/470775/
14:32:07 <gibi> claudiub: sure :)
14:32:16 <claudiub> woohoo :D
14:32:29 <gibi> as we discussed this bp is prerequisit for every nested scheduling work in nova
14:32:33 <mriedem> i'm good with https://blueprints.launchpad.net/nova/+spec/use-nested-allocation-candidates of course, it's needed to make sure we can even use NRPs including scheduling to child VGPU providers
14:32:56 <gibi> I've rebased the patch series
14:33:18 <gibi> and also added more functional tests to cover nested allocations during instance move operations
14:33:36 <gibi> this last step uncovered some faulty edge cases as we expected
14:33:53 <gibi> but there is a lot of patch in the series before that to review
14:34:17 <gibi> the impl series starts here https://review.openstack.org/#/c/591597
14:34:26 <gibi> mriedem: thank
14:34:43 <mriedem> dansmith: bauzas: i'm assuming you're ok with this too
14:34:45 <mriedem> i'll approve if so
14:34:46 <efried> so we decided we don't need a spec or anything that enumerates all the bits and pieces we want to be checking for nrp viability?
14:34:47 <gibi> any objection approving the bp?
14:35:00 <efried> because it's basically try-everything-and-see-what-breaks-and-fix-it?
14:35:02 <bauzas> mriedem: yup
14:35:03 <gibi> efried: I think we did.
14:35:11 <gibi> efried: I addes a short summary in the bp
14:35:13 <dansmith> yeah
14:35:36 <bauzas> efried: I think we tried to identify the gaps for n-rp at PTG and none was requiring a spec, rather
14:36:07 <efried> wfm, just making sure.
14:36:14 <gibi> efried: also if you feel I missed things in the test coverage then I'm happy to add more tests
14:36:21 <gibi> cool
14:36:24 <efried> gibi? Miss a test? NEVER!
14:36:26 <gibi> mriedem: thanks for the approve
14:36:30 <mriedem> throw it in runways
14:36:38 <gibi> mriedem: I will after the meeting
14:36:45 <gibi> mriedem: at least the first couple of patches
14:36:57 <gibi> moving on
14:37:06 <gibi> claudiub: do you want to talk about your patch?
14:37:51 <claudiub> eh, it had a +2 from stephenfin
14:38:29 <claudiub> there are a few changes outside of nova/tests though
14:38:36 <gibi> claudiub: OK, I will try to get to it
14:38:48 <claudiub> since some signatures weren't being respected in some cases.
14:39:11 <mriedem> https://review.openstack.org/#/c/470775/38/nova/test.py is the meat right?
14:39:16 <mriedem> mock the mock
14:40:03 <claudiub> sorry, i didn't quite get what you meant
14:40:11 <mriedem> i mean,
14:40:26 <mriedem> MockAutospecFixture is globally mocking mock so that all mock.patch* calls are autospeccing
14:40:38 <claudiub> yep
14:40:51 <mriedem> is there a significant time difference in the test runs with this?
14:41:06 <mriedem> doesn't look like it
14:41:32 <claudiub> ~30 seconds maybe
14:41:44 <claudiub> in total
14:41:48 <mriedem> ok
14:42:14 <gibi> anything else to discuss before we close the meeting?
14:42:19 <mhen> o/
14:42:27 <gibi> mhen: go ahead
14:42:37 <mhen> sorry I didn't put it on the agenda
14:42:44 <gibi> mhen: no problem
14:42:51 <mhen> https://bugs.launchpad.net/nova/+bug/1793159
14:42:51 <openstack> Launchpad bug 1793159 in OpenStack Compute (nova) "no signature check for cached images" [Undecided,New]
14:43:17 <mhen> I'd like to discuss the proposal there
14:44:00 <johnthetubaguy> oh, right, I think I pointed someone at a email thread from when we removed the md5 checks on cached images
14:44:28 <mhen> that was presumably Luzi, she's on my team
14:44:47 <johnthetubaguy> yes, that's right, it was Luzi
14:44:57 * johnthetubaguy is trying to find the link again
14:45:25 <mhen> however, this is about actual signatures (as stored in Glance metadata) - I assume the md5 check was some local hash only used by Novas caching mechanism?
14:45:25 <johnthetubaguy> before we said it provides minimal extra protection, as once you have access to the cache its game over
14:45:48 <johnthetubaguy> it was md5 matching the glance md5, as thats all the signature we had at the time
14:45:58 <mhen> oh I see
14:46:34 <johnthetubaguy> there was a bit rot discussion, and we decided protecting against bit rot is out of scope for Nova really
14:47:03 <mhen> in our case it's not against bit rot but rather against tampering
14:47:29 <mhen> I pointed out some arguments in the bug report I linked
14:47:33 <johnthetubaguy> right, that was the previous comment, if you can tamper with the image cache, its basically game over, you have root on the hypervisor
14:48:04 <johnthetubaguy> right, NFS is a different attack surface I guess
14:49:29 <mhen> maybe some of you can provide some more input on the bug report, I don't want to hijack the meeting for a detailed technical discussion about this
14:49:37 <johnthetubaguy> I guess we need clarity on the specific use case this helps, sounds like image cache on external storage, but local instance disk encrypted?
14:49:59 <mhen> johnthetubaguy, you're right about the scenario
14:50:52 <gibi> mhen: could you add the specific use case to the bug. I hope that mbooth and mriedem will check back on the bug report
14:51:23 <johnthetubaguy> +1
14:51:32 <mhen> I kinda described it within my comments on the report so far, but if desired I can also add a summarized use case additionally
14:51:42 <gibi> mhen: cool, thanks
14:52:01 <gibi> anything else to discuss today?
14:52:02 <mriedem> this is way over my head fwiw
14:52:09 <mriedem> which is why i roped mdbooth into it
14:52:58 <gibi> mriedem: and as you typed the proper irc name he is now pinged :)
14:53:19 <gibi> if nothing else then thanks for everyone
14:53:32 <mhen> thanks guys, I will add a use case scenario description to the report
14:53:36 <gibi> mhen: thanks
14:53:49 <gibi> #endmeeting