21:00:14 <mriedem> #startmeeting nova
21:00:14 <openstack> Meeting started Thu Apr 27 21:00:14 2017 UTC and is due to finish in 60 minutes.  The chair is mriedem. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:00:15 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
21:00:18 <openstack> The meeting name has been set to 'nova'
21:00:39 <mriedem> howdy pardners
21:00:40 <efried> o/
21:00:45 <takashin> o/
21:00:50 <gibi> o.
21:00:52 <melwitt> o/
21:00:54 <edleafe> \o
21:01:09 <hferenc_> \o/
21:01:09 * bauzas waves
21:01:57 <mriedem> ok we can get started
21:01:59 <mriedem> #link agenda https://wiki.openstack.org/wiki/Meetings/Nova#Agenda_for_next_meeting
21:02:07 <mriedem> #topic release news
21:02:14 <mriedem> #link Pike release schedule: https://wiki.openstack.org/wiki/Nova/Pike_Release_Schedule
21:02:37 <mriedem> next big thing in the scheduler is the summit in a little more than 1 week
21:02:43 <mriedem> *schedule
21:02:44 <mriedem> :)
21:02:56 <mriedem> next milestone is p-2 on June 8th
21:03:11 <mriedem> #info Blueprints: 70 targeted, 65 approved, 8 completed, 11 not started
21:03:23 <mriedem> #link pike-1 recap and pike-2 focus: http://lists.openstack.org/pipermail/openstack-dev/2017-April/115700.html
21:03:29 <mriedem> #help There are still some approved blueprints looking for owners: http://lists.openstack.org/pipermail/openstack-dev/2017-April/115899.html
21:03:46 <mriedem> questions about the release?
21:04:01 <efried> mriedem I *may* be able to take on that other keystoney one that overlaps with service-catalog stuff.  Keep me in mind if no other takers.
21:04:11 <mriedem> the service token one?
21:04:14 <efried> yah
21:04:20 <mriedem> ok. i think some of that is already done
21:04:22 <mriedem> but ok
21:04:32 <mriedem> #topic bugs
21:04:50 <mriedem> no critical bugs
21:05:02 <mriedem> #link check queue gate status http://status.openstack.org/elastic-recheck/index.html
21:05:06 <mriedem> gate has been ok
21:05:14 <mriedem> #link 3rd party CI status http://ci-watch.tintri.com/project?project=nova&time=7+days
21:05:22 <mriedem> i don't have any news about 3rd party ci
21:05:39 <mriedem> anything for bugs?
21:05:57 <mriedem> #topic reminders
21:06:13 <mriedem> #link Pike Review Priorities etherpad: https://etherpad.openstack.org/p/pike-nova-priorities-tracking
21:06:29 <mriedem> continue updating ^ as your changes progress
21:06:35 <mriedem> and subteams review things
21:06:41 <mriedem> #link Forum planning: https://wiki.openstack.org/wiki/Forum/Boston2017
21:06:49 <mriedem> #info Start creating etherpads for your sessions. There is an optional template: http://lists.openstack.org/pipermail/openstack-dev/2017-April/115972.html
21:06:58 <mriedem> the etherpads are linked into that wiki ^
21:07:10 <mriedem> #link https://etherpad.openstack.org/p/BOS-Nova-brainstorming Forum discussion planning for nova (add your name if you are going)
21:07:35 <mriedem> i saw in the ML today that there are going to be some reservable rooms,
21:07:47 <mriedem> but i don't know if we have space in the schedule for anything that requires that
21:07:56 <efried> #link https://ethercalc.openstack.org/Boston_Forum_Hacking_Rooms
21:08:00 <mriedem> or any topics that aren't already covered in forum sessions
21:08:21 <mriedem> yeah,
21:08:31 <mriedem> personally i've found i don't have much in the way of free time given the sessions i'm already going to
21:09:04 <mriedem> if anyone can think of a major nova issue we need to discuss that isn't already covered in a session let me know
21:09:08 <mriedem> and we can see if there is a slot we need
21:09:18 <mriedem> #info Forum sessions: https://www.openstack.org/summit/boston-2017/summit-schedule/global-search?t=forum
21:09:32 <mriedem> anything about the forum?
21:09:45 <mriedem> #topic Stable branch status
21:09:51 <mriedem> stable/ocata: https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:stable/ocata,n,z
21:09:55 <mriedem> stable/newton: https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:stable/newton,n,z
21:10:11 <mriedem> we're working some fixes through those and then i'll be looking to do a patch release next week
21:10:20 <mriedem> i also need to check that for novaclient on stable
21:10:28 <mriedem> i have requested a 1.4.1 os-vif release for ocata this week
21:10:29 <mriedem> not merged yet
21:10:42 <mriedem> #topic subteam highlights
21:10:57 <mriedem> i'm filling in for cells v2
21:11:06 <mriedem> major review focus is on two things
21:11:11 <mriedem> 1. quotas https://review.openstack.org/#/c/446239/
21:11:22 <mriedem> 2. multicell https://review.openstack.org/#/c/458634/
21:11:29 <mriedem> a good chunk of the latter has merged
21:11:52 <mriedem> that's about it
21:11:59 <mriedem> edleafe: scheduler?
21:12:04 <edleafe> Short meeting this week, as nothing contentious was under discussion.
21:12:04 <edleafe> We got an update on the status of various placement specs and patches, and things seem to be moving along well.
21:12:07 <edleafe> cdent wished for additional help harassing jaypipes during his upcoming talk in Boston.
21:12:10 <edleafe> That's it!
21:12:22 <mriedem> talk(s)
21:12:30 <mriedem> there are multiple opportunities to ruin his day
21:12:44 <edleafe> I'm counting you to help with that, mriedem
21:12:47 <mriedem> i don't imagine tdurakov is around for live migration updates
21:13:11 <mriedem> there is a live migratoin related bp that's looking for an owner
21:13:20 <mriedem> and another that's looking for someone to take over the patches
21:13:36 <mriedem> https://blueprints.launchpad.net/nova/+spec/live-migration-force-after-timeout
21:13:40 <mriedem> https://blueprints.launchpad.net/nova/+spec/live-migration-per-instance-timeout
21:13:55 <mriedem> api meeting highlights
21:14:23 <mriedem> i was there but can't really remember
21:14:25 <mriedem> :/
21:14:39 <mriedem> we talked about something for an inordinate amount of time
21:14:57 <mriedem> on the upside, microversions 2.43, 2.44 and 2.45 are merged now
21:15:09 <mriedem> gibi: notifications meeting highlights?
21:15:23 <gibi> It was a sort meeting this week
21:15:23 <gibi> Focus is on two things in the subteam
21:15:23 <gibi> 1) https://review.openstack.org/#/q/status:open+topic:bp/additional-notification-fields-for-searchlight
21:15:27 <gibi> 2) instance.volume_attach, the patch series starts here: https://review.openstack.org/#/c/401992/
21:15:30 <gibi> that is all
21:15:56 <mriedem> gibi: köszönöm
21:16:02 <mriedem> yeah?
21:16:08 <gibi> szivesen
21:16:08 <gibi> :)
21:16:16 <mriedem> efried: powervm?
21:16:20 <efried> Great progress since last week.  Three ready for final reviews (one waiting for verification to start behaving again): https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:bp/powervm-nova-compute-driver+is:mergeable  Once one or two more of those go through, will start in on the others in the series again.
21:16:37 <efried> That's it from me, unless any questions/concerns.
21:16:57 <mriedem> ok
21:16:58 <mriedem> cool
21:17:12 <mriedem> for nova/cinder this week,
21:17:14 <mriedem> Review focus is on the new detach flow: https://review.openstack.org/#/c/456896/
21:17:28 <mriedem> i've got a series up through swap volume, needs some tweaking,
21:17:57 <mriedem> others have some patches up for other operations dealing with detach, like instance delete
21:18:23 <mriedem> and i think someone (ildikov?) is going to work on resurrecting the attach patch with the new flow that makes everything go
21:18:37 <mriedem> #topic stuck reviews
21:18:44 <mriedem> there was nothing on the agenda,
21:18:49 <mriedem> anyone have anything to bring up here?
21:19:08 <mriedem> #topic open discussion
21:19:15 <mriedem> Special scenario/filter tests: http://lists.openstack.org/pipermail/openstack-dev/2017-April/115800.html (hferenc)
21:19:32 <mriedem> gibi: coworker of yours?
21:19:37 <mriedem> hferenc_: ^?
21:19:38 <gibi> mriedem: yes
21:19:43 <hferenc_> yes
21:19:48 <hferenc_> thx
21:19:57 <hferenc_> so in short: I'd like to add some testcases that couldn't be merged to tempest because they require a special environment for testing.
21:20:04 <hferenc_> For me testing the aggregates isolation scheduler filter would be the most important but if it's possible I'd like to add more tests later on.
21:20:13 <hferenc_> Sorry if this is not the right time and place to discuss this. I just wanted to shed some light on the topic. I'd appreciate any review.
21:20:26 <mriedem> hferenc_: so why can't we test this with in-tree functional tests?
21:20:31 <mriedem> using fixtures
21:20:36 <bauzas> wouldn't it be possible to use functional tests in-tree ?
21:20:40 <bauzas> meh
21:20:42 <bauzas> jinx
21:20:58 <Vek> bauzas: great minds think alike, right?  :)
21:21:10 <bauzas> :p
21:21:16 <mriedem> https://review.openstack.org/#/c/315786/ is something that you need devstack for https://review.openstack.org/#/c/315786/
21:21:19 <mriedem> oops
21:21:20 <hferenc_> It would be ok these with functional tests - i'm also working on that
21:21:30 <mriedem> i think the scheduler filters could be tested in tree
21:21:46 <mriedem> https://review.openstack.org/#/c/315786/ couldn't be
21:21:48 <bauzas> sure thing, we already have some
21:21:50 <hferenc_> but functional tests cannot be run against deployments
21:22:03 <mriedem> hferenc_: it depends on what you need to test
21:22:23 <mriedem> if you're ok using fixtures for running services and a fake virt driver, just to test placement logic with the filters, i think in-tree is fine
21:22:33 <mriedem> if you're testing actual hypervisor features, then yes you need an openstack deployment
21:22:57 <mriedem> we have talked in the past about having a dsvm-integration suite of tests in-tree that relies on a backing devstack installation
21:23:02 <mriedem> for testing things like libvirt
21:23:11 <mriedem> tempest is really about testing the apis
21:23:19 <mriedem> so https://review.openstack.org/#/c/315786/ doesn't really make sense in a tempest plugin imo
21:23:58 <mriedem> i can see a lot of value in a dsvm-integration set of tests in-tree so we could run tests in serial, like then we could test evacuate
21:24:51 <mriedem> i guess your watchdog test goes through the api b/c of the flavor setup
21:25:43 <gibi> so this dsvm-integration suite would spin a devstack but it would run some functional test instead of tempest
21:25:45 <mriedem> so that could probably actually be a tempest plugin test
21:25:51 <mriedem> gibi: yes
21:26:01 <mriedem> gibi: i think of it like the functional tests in novaclient
21:26:01 <gibi> is there any example for that in other modules we can copy?
21:26:05 <mriedem> those rely on a devstack
21:26:07 <gibi> ohh
21:26:16 <mriedem> and they run novaclient CLIs against that devstack
21:26:19 <mriedem> so it's not tempest
21:26:23 <mriedem> but it's not a fake env either
21:26:30 <gibi> sounds interesting
21:26:41 <mriedem> i think we can test scheduler filters using functional tests in tree with fixtures,
21:27:05 <mriedem> and things like this watchdog action test could be done via a tempest plugin, or in-tree integration tests (like novaclient),
21:27:21 <gibi> for the placement test, we have some requirement to prove the tenant separation works against a deployment (like user acceptance tests)
21:27:22 <mriedem> like we'd probably have a dsvm-integration-libvirt, dsvm-integration-ironic, something like that
21:28:08 <gibi> so we made those filter tests in tempest to be able to used against a deployment
21:28:16 <gibi> and we would like to share it :)
21:28:32 <mriedem> gibi: it's a very narrow and specific deployment is the problem
21:28:48 <mriedem> you can get the same thing using the in-tree functional tests
21:28:54 <mriedem> which run actual services and populate the database
21:29:07 <mriedem> they just don't use real cinder/neutron/virt driver, but you don't need those for scheduler placement tests
21:29:48 <mriedem> for example https://github.com/openstack/nova/blob/master/nova/tests/functional/regressions/test_bug_1671648.py
21:29:49 <gibi> sure for the functional validation the current functional test env is ok
21:30:00 <gibi> but for user acceptance it isn't
21:30:04 <mriedem> ^ tests that if we fail to build on a compute, we properly retry on another compute
21:30:14 <gibi> but I feel we wont solve the user acceptance test problem in nova :)
21:30:41 <mriedem> what i'm hearing is you guys have an internal business process dictating how you do your testing
21:30:50 <mriedem> which, whatever, that's fine
21:31:31 <mriedem> i personally feel it's a waste to setup a CI job with a very specific environment and set of filters just to run a single test
21:31:38 <mriedem> when you can do it in-tree to test the same thing
21:32:01 <mriedem> if your job could reconfigure itself on the fly so it can test multiple scenarios, that's a different story
21:32:09 <mriedem> that's what our live migration job does
21:32:27 <mriedem> https://github.com/openstack/nova/blob/master/nova/tests/live_migration/hooks/run_tests.sh
21:32:31 <gibi> most probably we want to much as a first step :)
21:32:51 <gibi> I think we can look into the dsvm-integration thing for the watchdog test
21:33:02 <mriedem> so maybe we take this to the mailing list, i can dump some comments there
21:33:11 <gibi> mriedem: sure
21:33:11 <mriedem> i'm not sure if there is anything you really need from me here,
21:33:23 <mriedem> you guys have a requirement and you've delivered on it for your corporate overlords
21:33:25 <gibi> thanks for the feedback
21:33:49 <mriedem> in general i'm always happy with more testing, so +++ there
21:33:58 <mriedem> ok, anything else for open discussion?
21:34:17 <hferenc_> mriedem: thank you
21:34:22 <mriedem> yw
21:34:28 <mriedem> alright let's wrap it up, thanks everyone
21:34:30 <mriedem> #endmeeting