14:00:12 <mriedem> #startmeeting nova
14:00:12 <gagehugo> o/
14:00:13 <openstack> Meeting started Thu May 19 14:00:12 2016 UTC and is due to finish in 60 minutes.  The chair is mriedem. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:14 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:16 <openstack> The meeting name has been set to 'nova'
14:00:17 <lbeliveau> o|
14:00:18 <edleafe> \o
14:00:19 <jlvillal> o/
14:00:20 <_gryf> |o
14:00:20 <gagehugo> \o/
14:00:21 <mdbooth> \o/
14:00:21 <mriedem> now do it all again
14:00:24 <lyarwood_> o/
14:00:24 <alaski> o/
14:00:25 <rbradfor> o/
14:00:26 <takashin> o/
14:00:27 <gibi> o/
14:00:28 <bauzas> \o
14:00:28 <andrearosa> hi
14:00:30 <efried> o/
14:00:32 <gagehugo> woo
14:00:32 * dansmith hates the pre-ping
14:00:39 <alaski> +1
14:00:40 <PaulMurray> o/
14:00:42 <macsz> hello stackers
14:00:49 * kashyap waves
14:00:54 <cdent> o/
14:00:55 <mriedem> #link agenda https://wiki.openstack.org/wiki/Meetings/Nova#Agenda_for_next_meeting
14:01:03 <mriedem> #topic release news
14:01:14 <mriedem> #link newton release schedule for nova https://wiki.openstack.org/wiki/Nova/Newton_Release_Schedule
14:01:19 <mriedem> hasn't changed
14:01:27 <mriedem> #info June 2: newton-1, non-priority spec approval freeze
14:01:38 <mriedem> #info we're 2 weeks away from non-priority spec approval freeze
14:01:46 <raj_singh> o/
14:02:07 <mriedem> with probably a few hundred open specs, not everything is going to make it
14:02:26 <mriedem> https://review.openstack.org/#/q/project:openstack/nova-specs+status:open
14:02:41 <mriedem> #topic bugs
14:02:51 <mriedem> i'm not aware of anything that's critical
14:03:05 <mriedem> if something critical does come up, mark it for milestone n-1
14:03:15 <mriedem> since the release team will be looking at those for tagging i think
14:03:33 <mriedem> #link gate status http://status.openstack.org/elastic-recheck/index.html
14:03:49 <mriedem> nothing really new for nova here - we did revert the fernet token thing in devstack yesterday, so the gate should be smoother now
14:04:06 <mriedem> i don't have any news about third party CI status
14:04:15 <sdague> yeh, the gate finally cleared last night after that
14:04:20 <mriedem> \o/
14:04:33 <jroll> woo
14:04:40 <mriedem> only other thing i know about bugs is markus_z was going through the old wishlist bugs and cleaning house on some of tohse
14:04:43 <mriedem> *those
14:05:04 <mriedem> #topic reminders
14:05:11 <mriedem> #link Newton review focus list: https://etherpad.openstack.org/p/newton-nova-priorities-tracking
14:05:25 <mriedem> if you are a subteam putting stuff in there, make sure it's up to date on a weekly basis
14:05:35 <mriedem> after your subteam meeting is a good time to do it
14:05:45 <mriedem> We have 59 approved blueprints: https://blueprints.launchpad.net/nova/newton - 6 are completed, 5 have not started, 3 are blocked
14:06:03 <mriedem> #help https://wiki.openstack.org/wiki/Nova/BugTriage#Weekly_bug_skimming_duty Volunteers for 1 week of bug skimming duty?
14:06:11 <mriedem> i think andrearosa has this week
14:06:29 <mriedem> i see some names in the table in there, nice
14:06:33 <mriedem> thanks to those that are signing up
14:06:37 <raj_singh> I added my name for next week
14:06:49 <mriedem> yeah i see that, thank you
14:06:49 <andrearosa> mriedem: correct, I did it for a couple of days
14:07:05 <mriedem> #topic stable branches
14:07:12 <macsz> i will add myself torah_singh, mriedem
14:07:13 <mriedem> #link stable branch status https://etherpad.openstack.org/p/stable-tracker
14:07:40 <mriedem> as far as i know the stable branch jobs for nova are ok
14:07:51 <mriedem> stable/liberty is in security fix only mode now
14:08:28 <mriedem> there are a few open stable/mitaka backports
14:08:36 <mriedem> i'll be looking to do a release for both around n-1
14:08:58 <mriedem> #topic subteam highlights
14:09:11 <mriedem> alaski: want to recap anything from the cells meeting yesterday?
14:09:16 <alaski> sure
14:09:45 <alaski> I'm going to be looking into getting devstack to use the upgrade to cells command
14:10:10 <alaski> but we no longer have anyone focused on testing so we need to get that work picked up somehow
14:10:26 <mriedem> #help need help with cells v2 testing in the gate
14:10:39 <alaski> and melwitt is looking into using transport_url if configured to make upgrading easier
14:10:45 <dansmith> was that v2 or v1 testing?
14:10:53 <dansmith> I thought ccarmack was working on v1 test fixes or something
14:11:00 <alaski> and has been discussing deprecating the old driver specific messaging options to encourage deployers to set transport_url
14:11:05 <alaski> dansmith: v2
14:11:07 <mriedem> dansmith: i think he basically abandoned that
14:11:12 <alaski> he was also putting together a plan for v2
14:11:15 <mriedem> the security group config stuff in tempest
14:11:18 <dansmith> okay, I hadn't realized he was working on v2 stuff
14:11:19 <dansmith> okay
14:11:52 <alaski> I think that's about it
14:11:55 <mriedem> alaski: are any of cccarmack's notes written down?
14:11:56 <mriedem> etherpad?
14:12:03 <alaski> they're in an etherpad, yeah
14:12:07 <bauzas> yeah we have an etherpad for testing
14:12:08 <alaski> I need to dig it up
14:12:10 <mriedem> https://etherpad.openstack.org/p/nova-cells-testing
14:12:18 <mriedem> #link cells v2 gate testing etherpad https://etherpad.openstack.org/p/nova-cells-testing
14:12:21 <alaski> that's the one
14:12:40 <mriedem> ok, thanks
14:12:58 <mriedem> edleafe: want to go over any highlights from the scheduler team meeting?
14:13:16 <bauzas> oh, I was on pto at Monday...
14:13:24 <edleafe> mriedem: sorry - on a call
14:13:31 <mriedem> ok, i'll pitch in here
14:13:34 <cdent> g-r-p spec merged
14:13:36 <mriedem> generic-resource-pools spec is merged
14:13:39 <cdent> jinx
14:13:46 <mriedem> everything is dependent on moving inventories to the api db right now
14:13:46 <bauzas> coolness
14:13:48 <cdent> BUY ME A COKE
14:13:50 <mriedem> dansmith:  have a link for that series?
14:14:04 <dansmith> the inventory moving one?
14:14:07 <mriedem> yeah
14:14:15 <dansmith> https://review.openstack.org/#/c/315681/
14:14:23 <dansmith> cdent had a few things to address on the bottom patch
14:14:33 <dansmith> apparently there is some database named db2
14:14:35 <dansmith> that is really picky
14:14:45 <mriedem> it's a strict one
14:14:46 <dansmith> and then another table we need to throw in there while we're doing a mgiration
14:14:49 <mriedem> very conservative
14:14:54 <dansmith> mriedem: strictly picky, yeah
14:15:16 <mriedem> #help review the inventory tables move to API DB series for the scheduler https://review.openstack.org/#/c/315681/
14:15:48 <mriedem> moving on
14:15:57 <mriedem> PaulMurray: any highlights from the live migration meeting?
14:16:00 <PaulMurray> yep
14:16:02 <PaulMurray> a few
14:16:11 <PaulMurray> For CI:
14:16:11 <PaulMurray> tdurakov switched the live migration job in experimental queue to use Xenial (Ubuntu 16.04) to
14:16:11 <PaulMurray> get recent versions of qemu and libvirt. So can now test recent features in those.
14:16:32 <PaulMurray> Increasing CI coverage of storage backends:
14:16:42 <PaulMurray> mriedem added tempest-dvsm-lvm job to experimental queue
14:16:52 <PaulMurray> - but change has not merged yet - it was waiting on depndencies that have merged.
14:17:07 <mriedem> it should be in soon
14:17:07 <mriedem> https://review.openstack.org/#/c/316298/
14:17:16 <mriedem> oh it's merged
14:17:26 <PaulMurray> cool
14:17:27 <mriedem> also, on the live migration job on xenial
14:17:29 <PaulMurray> mriedem will also change an existing job to use raw (almost all use qcow2 right now).
14:17:40 * PaulMurray (lots of mriedem in there this week)
14:17:49 <PaulMurray> For storage pools: making progress.
14:17:52 <mriedem> the live migration job is failing because libvirt isn't sorting out the gate64 cpu model
14:18:20 <PaulMurray> The bdm code is confusing because of the wrappers for objects and
14:18:29 <dansmith> a bunch of mdbooth's cleanups have mereged
14:18:31 <PaulMurray> bdm v1 vs bdm v2. So propose deprecating bdm v1 and start moving towards getting rid of it
14:18:40 <dansmith> one is in the gate now, and the next one has feedback to address
14:18:41 <PaulMurray> see mriedem ML:
14:18:41 <PaulMurray> http://lists.openstack.org/pipermail/openstack-dev/2016-May/095226.html
14:19:06 <PaulMurray> yes, good to see that mdbooth is getting reviews
14:19:08 <mdbooth> Thanks dansmith and feodor especially for all the reviews, btw
14:19:22 <dansmith> we're about to get to the meat of it I think
14:19:29 <mriedem> we'll probably lump the bdm v1 deprecation with some other misfit APIs in a single spec
14:19:29 <mdbooth> Yup
14:19:54 <sdague> mriedem: you want that piled into the extensions cleanup spec?
14:20:08 <mriedem> sdague: like agent-builds and cloudpipe? yeah
14:20:12 <sdague> yeh
14:20:14 <mriedem> we don't test bdm v1
14:20:15 <sdague> and os-certificates
14:20:25 <mriedem> the island of misfit apis
14:20:36 <sdague> right, and the schema parse is wibbly wobbly for it
14:20:58 * PaulMurray likes wibbly wobbly
14:20:59 <mriedem> as for the raw job change, i was going to add that to the postgres job
14:21:04 * PaulMurray as a term
14:21:10 <mriedem> but need to be able to set the value in devstack - so working on that
14:21:18 <mriedem> piggly wiggly
14:21:37 <mriedem> thanks PaulMurray
14:21:39 <mriedem> moving on
14:21:47 <mriedem> sdague: alex_xu: api subteam meeting highlights?
14:22:11 <sdague> yeh, we're about 40% of the way through the api-ref cleanup - http://burndown.dague.org/
14:22:35 <mriedem> example verification should be easyish
14:22:39 <mriedem> param verification is the hard one
14:22:41 <sdague> realistically, there are a few tough ones to sort out, but then the rest are pretty easy and will just grind for the rest of the cycle
14:23:03 <sdague> and we'll probably do a post freeze sprint at end of cycle to clean up any stragglers
14:23:07 <rbradfor> sdague, like the added table of TODO work.
14:23:29 <sdague> we then mostly focused on the details of deprecating the API proxies
14:23:51 <sdague> which apparently just merged - https://review.openstack.org/#/c/312209/
14:24:15 <sdague> it also spawned out a second discussion of disable_deprecated_apis config flag
14:24:31 <sdague> http://lists.openstack.org/pipermail/openstack-dev/2016-May/095353.html
14:24:38 <sdague> which people should comment there if they are interested
14:25:06 <sdague> and we're just waiting on alaski to say where he needs help on the policy in code work
14:25:12 <sdague> I think that's pretty much it
14:25:21 <alaski> it's under review in oslo.policy
14:25:46 <mriedem> sdague: how about this guy? https://review.openstack.org/#/c/265282/
14:26:11 <mriedem> we can talk about that after the meeting too
14:26:25 <sdague> mriedem: yeh, I haven't circled back on that one yet, I can do post meeting
14:26:43 <mriedem> ok
14:26:49 <mriedem> sriov/pci meeting
14:26:53 <mriedem> moshele is in nova, but not here
14:27:03 <mriedem> i was there for part of the meeting,
14:27:11 <mriedem> was mostly about reviews, and those should be in the reviews etherpad
14:27:30 <mriedem> L182 here https://etherpad.openstack.org/p/newton-nova-priorities-tracking
14:27:36 <moshele> hi
14:27:46 <mriedem> moshele: i was just going over the sriov/pci meeting highlights, mostly reviews
14:27:53 <mriedem> moshele: anything else you wanted to add?
14:28:28 <moshele> yes: we are working on the resize patch
14:28:55 <moshele> hopefully it will be ready for review next week
14:29:11 <mriedem> ok, people are just testing it out this week, correct?
14:29:23 <mriedem> moshele: but for ci testing, that requires multinode?
14:29:25 <moshele> mriedem: also I found issue with resize in general
14:30:01 <moshele> mriedem: we can do it with one node intel PCI has tests for it
14:30:14 <mriedem> ok, cool
14:30:37 <mriedem> that will be key to getting that patch merged
14:30:38 <moshele> mriedem: the test are passing
14:30:57 <mriedem> alright, anything else?
14:31:18 <moshele> mriedem: there is general issue  with resize that I need to open a bug
14:31:30 <moshele> we can talk about after the meeting
14:31:33 <mriedem> moshele: ok
14:31:34 <mriedem> thanks
14:31:37 <mriedem> moving onto notifications
14:31:41 <gibi> hi
14:31:42 <mriedem> gibi: highlights from the notifications meeting?
14:31:47 <gibi> sure
14:31:52 <gibi> We agreed with searchlight representatives to not purse the idea to have the same data in the notification as in the API response right now but do a more stepwise approach.
14:32:04 <gibi> Do the transformation first then add missing pieces searchlight needs as a next step.
14:32:34 <gibi> this solved the last comment on the transformation spec
14:32:43 <gibi> #link https://review.openstack.org/#/c/286675/
14:33:12 <gibi> both jay and john has positive feedback on it but need additional spec-cores to look at it
14:33:29 <rlrossit> it also has my +1 now too
14:33:43 <gibi> rlrossit: thanks for that
14:34:00 <mriedem> ok. i haven't gone through that one yet. will try to make a pass on it today.
14:34:13 <gibi> mriedem: thanks
14:34:15 <mriedem> anything else?
14:34:26 <gibi> we have some PoC code already up on review for this spec as well the subteam working on it
14:34:35 <gibi> also
14:34:35 <gibi> the json schema generation spec https://review.openstack.org/#/c/311194/ has been merged in ovo, implementation is just started
14:34:48 <johnthetubaguy> I am still torn on instance vs server, but I like the approach
14:34:50 <rlrossit> yeah we have some work to do in o.vo for a bit
14:35:20 <mriedem> oh it's a spec, ok
14:35:34 <rlrossit> johnthetubaguy: we're approaching the "speak now, or forever hold your peace" point :)
14:35:34 <mriedem> alright
14:35:47 <mriedem> rlrossit: well, 50% of specs end in divorce
14:35:52 <mriedem> so, meh
14:35:55 <rlrossit> ha
14:36:00 <gibi> lol
14:36:12 <gibi> nothing else from the notification subteam
14:36:15 <mriedem> ok, thanks
14:36:22 <mriedem> #topic stuck reviews
14:36:30 <mriedem> there isn't anything on the agenda
14:36:37 <mriedem> anyone waiting to pounce on this?
14:36:42 <tpatzig> hi
14:36:49 <tpatzig> should we shortly talk about https://review.openstack.org/#/c/267673
14:37:07 <mriedem> sure
14:37:18 <tpatzig> it seems to go in the direction to use an additional column, right?
14:37:59 <tpatzig> which disallowes local ephemerals at all for that flavor
14:38:17 <mriedem> alaski doesn't want to introduce new complexity to the flavor API
14:38:20 <mriedem> which i can agree with
14:38:28 <tpatzig> alaski, mentioned not to add that as additional field to the api…
14:38:34 <mriedem> but a new db column and attribute on the flavor object could help make the code internally cleaner for this special case
14:38:47 <tpatzig> ok
14:39:04 <tpatzig> but for the api we map root_gb=None to that new column
14:39:14 <mriedem> sounds like it
14:39:24 <alaski> yeah, that's what it would be
14:39:31 <dansmith> this does't seem stuck to me
14:39:39 <dansmith> just requiring further discussion
14:39:42 <alaski> yep
14:39:51 <tpatzig> ok. i'll adjust the spec and we can discuss if needed in there
14:40:01 <mriedem> sure, which i think is fine to bring up in a meeting
14:40:05 <mriedem> ok, cool
14:40:09 <tpatzig> thanks
14:40:09 <mriedem> moving on
14:40:15 <mriedem> #topic open discussion
14:40:28 <mriedem> anyone have anything they want to discuss at great detail for 20 minutes?
14:40:53 <mriedem> not hearing anything
14:41:03 <mriedem> oh, also,
14:41:16 <mriedem> i'm out until 5/31 so if i have a -2 procedural on something of yours, ping me today to remove it
14:41:37 <mriedem> otherwise sdague is going to be the lightning rod while i'm out
14:41:47 <mriedem> and infra can remove -2s if needed
14:41:52 <flip214> please advise how to proceed with https://review.openstack.org/#/c/256292/
14:42:02 <sdague> mriedem: you are going to reset the glance -2s, right?
14:42:30 <flip214> do I need to redo the spec at https://review.openstack.org/#/c/134153/, or is that unnecessary if it's just another os-brick connector?
14:43:00 <mriedem> sdague: probably yeah
14:43:01 <flip214> general overview page is at https://blueprints.launchpad.net/cinder/+spec/drbd-transport; only the nova part is still missing.
14:43:14 <bauzas> I have a midcycle-related question
14:43:18 <mriedem> flip214: i don't think we need a spec for a new brick connector
14:43:27 <mriedem> flip214: the os-brick change is merged
14:43:54 <mriedem> the nova change will need to depend on a global-requirements change that raises the minimum required os-brick to the version that has the drbd connector
14:44:05 <mriedem> flip214: ping me in nova after the meeting to sort out the paperwork
14:44:08 <mriedem> bauzas: go!
14:44:11 <flip214> mriedem: thanks a lot!
14:44:31 <bauzas> mriedem: just knowing before you leave if we have some Intel feedback about possible hotel rooms block rate
14:44:45 <mriedem> i asked about that last week, they were going to check on it
14:44:46 <bauzas> given the form we provided
14:44:53 <bauzas> okay
14:44:54 <mriedem> last time we were there it was larkspur landing
14:45:01 <mriedem> they also said holiday inn express but needed to check
14:45:04 <mriedem> i can email them again today
14:45:12 <bauzas> go on vacation, it's not that urgent
14:45:16 <sdague> mriedem: stick me on cc, and I'll follow up while you are gone
14:45:24 <mriedem> sdague: cool, i was going to anyway :)
14:45:26 <sdague> :)
14:45:35 <mriedem> anything else?
14:45:41 <bauzas> FWIW, it seems Intel is also hosting a few more midcycles at the same time
14:45:43 <mriedem> dansmith: you have some items you wanted to talk about i think?
14:45:51 <dansmith> mriedem: I don't think so
14:45:55 <bauzas> at least Watcher AIUI
14:46:12 <mriedem> bauzas: yeah i think so, but not sure it matters to us
14:46:18 <bauzas> right, just a FYI
14:46:34 <mriedem> ok, thanks everyone
14:46:37 <mriedem> #endmeeting