14:00:10 <johnthetubaguy> #startmeeting nova
14:00:11 <openstack> Meeting started Thu Feb 19 14:00:10 2015 UTC and is due to finish in 60 minutes.  The chair is johnthetubaguy. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:12 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:14 <openstack> The meeting name has been set to 'nova'
14:00:20 <jaypipes> o/
14:00:22 <bauzas> aloha
14:00:25 <jaypipes> heya
14:00:27 <alevine> o/
14:00:29 <bauzas> mornooning
14:00:29 <n0ano> o/
14:00:31 <edleafe> o/
14:00:31 <markus_z> o/
14:00:47 <johnthetubaguy> #topic Kilo release status
14:00:57 <johnthetubaguy> hello hello
14:00:58 <claudiub> o/
14:01:00 <anteaya> o/
14:01:03 <johnthetubaguy> so you probably saw the email:
14:01:10 <johnthetubaguy> http://lists.openstack.org/pipermail/openstack-dev/2015-February/057100.html
14:01:17 <johnthetubaguy> a few exceptions were granted
14:01:30 <johnthetubaguy> there is a link to the etherpad with a summary of the discussion
14:01:42 <alaski> o/
14:01:53 <johnthetubaguy> basically maximum chance to merge, minimum chance for disruption to priority stuff
14:02:14 <johnthetubaguy> #info next deadline: 5th March https://wiki.openstack.org/wiki/FeatureProposalFreeze
14:02:47 <garyk> johnthetubaguy: can you please post the link to the etherpad for the exceptions
14:02:49 <johnthetubaguy> so the next deadline is for all the exceptions to get merged by one week after the above email
14:02:59 <garyk> maybe we should discuss progress of each one to see where they are?
14:03:06 <johnthetubaguy> so the exceptions are basically the approve blueprints in kilo-3 now
14:03:18 <johnthetubaguy> #link https://etherpad.openstack.org/p/kilo-nova-ffe-requests
14:03:25 <johnthetubaguy> more details in that etherpad
14:03:37 <johnthetubaguy> the list is in that email I just posted
14:03:43 <johnthetubaguy> any questions on all that?
14:04:05 <bauzas> johnthetubaguy: I do
14:04:11 <johnthetubaguy> fire away
14:04:15 <sdague> o/
14:04:21 <bauzas> johnthetubaguy: FPF is for blueprints or changes without specs, right ?
14:04:56 <johnthetubaguy> bauzas: they were only given to folks who already have an approved blueprint and code up for review
14:05:19 <bauzas> johnthetubaguy: I see
14:05:24 <johnthetubaguy> sdague: so I just noticed no mention of ec2 on the etherpad :( but do fire away
14:06:00 <alevine> johnthetubaguy: Yes I'm worried about the EC2 but I'm not sure if it's already the time to ask.
14:06:16 <johnthetubaguy> alevine: so the problem is that time has been and gone
14:06:27 <sdague> johnthetubaguy: so, I'm actually completely confused about what happened there
14:06:38 <alevine> johnthetubaguy: I'm not sure what you mean by that.
14:06:47 <sdague> because last week mikal said the ec2 api team should put the patch up and we'd evaluate it this week
14:06:52 <sdague> then it was -2ed
14:07:15 <johnthetubaguy> yes, it was −2ed from me, because thats when I did the big pass through all the blueprints
14:07:27 <johnthetubaguy> I removed −2s from the feature exceptions
14:07:45 <johnthetubaguy> somehow, ec2 got missed off the list of exceptions we discussed about, so its been put on the agenda for the meeting today
14:08:04 <gilliard> o/
14:08:38 <sdague> ok, so I would argue, as I did last week, based on the relatively low intrusiveness of the needed change, and the priority from the operators, that we put externalizing this ec2 info on the priorities list
14:09:43 <johnthetubaguy> sdague: that seems reasonable, and it sounded like the api folks were OK with that happening quickly on the ML
14:09:58 <johnthetubaguy> quite how that got dropped off the other list I need to dig into
14:10:16 <sdague> johnthetubaguy: well the team was never told they needed to FFE
14:10:34 <sdague> and based on last week's meeting, it was definitely not clear that they would need to
14:11:01 <bauzas> could we just say that the EC2 API is part of the already prioritized v21 work ?
14:11:47 <sdague> bauzas: I think it's worth calling it out as a change in priorities, based on some very specific stakeholder feedback
14:11:49 <johnthetubaguy> sdague: yes, so I am confused whats happening with that now
14:12:12 <sdague> johnthetubaguy: ok, so lots of confusion :)
14:12:24 <bauzas> sdague: makes sense
14:12:25 <sdague> so, how do we get un confused
14:12:27 <sdague> ?
14:12:33 <alevine> johnthetubatuy: From the code's and design's standpoint it's ready, I want to believe. The review is out.
14:12:34 <johnthetubaguy> sdague: yeah, that totally needs doing, I guess no one owned doing the "paper work" for that, let me own that
14:12:38 <garyk> ctrl + alt + del
14:12:53 <johnthetubaguy> so I will talk to mikal and get that un-stuck somehow
14:13:08 <johnthetubaguy> #action johnthetubaguy to sort out whats happening with ec2 after last weeks meeing
14:13:15 <sdague> johnthetubaguy: especially as we are really talking about 1 patch to a v21 microversion (we'll only do this on v21, not on v2)
14:13:22 <sdague> cool, thanks
14:13:36 <alevine> johnthetubaguy: thanks
14:13:42 <sdague> which I also think will give us a good carrot for v21
14:14:03 <sdague> you'll need that for this enhanced ec2 support
14:14:07 <johnthetubaguy> sdague: alevine: I will try get an answer by the end of the week, hopefully you will see the −2 go away quickly
14:14:14 <sdague> johnthetubaguy: thanks
14:14:15 <johnthetubaguy> sdague: yeah, its a nice one
14:14:37 <johnthetubaguy> sorry folks, clearly a totally screw up there, miss understood the comments on the patch, I will fix that
14:14:46 <johnthetubaguy> #topic python-novaclient release
14:14:49 <sdague> thanks johnthetubaguy, appreciated
14:14:51 <alevine> johnthetubaguy: Yes, thanks again.
14:14:54 <johnthetubaguy> so I guess this was the topic last week
14:15:07 <johnthetubaguy> no idea why thats not happened
14:15:12 <johnthetubaguy> anyone want to raise that here?
14:15:31 <johnthetubaguy> was this the release pinning stuff?
14:15:39 <gilliard> I think that was all fixed.
14:15:42 <sdague> we should be safe on release pinning
14:15:48 <johnthetubaguy> that was my take too
14:16:01 <sdague> I think it's good to go, someone that knows how, and has permissions just needs to do it
14:16:05 <johnthetubaguy> #action johnthetubaguy to kick mikal over python-novaclient
14:16:17 <johnthetubaguy> #topic gate status
14:16:27 <sdague> and as a part b) we should probably increase the pool of people that know how, and have permissions (which I think was on the thread)
14:16:48 <johnthetubaguy> sdague: yeah, agreed, the timezone coverage argument made lots of sense
14:17:04 <sdague> the nova side seems pretty solid, I've seen a lot of neutron bounce recently
14:17:22 <johnthetubaguy> yeah, I don't see anything here,
14:17:24 <johnthetubaguy> moving on
14:17:31 <johnthetubaguy> #topic bugs
14:17:47 <johnthetubaguy> we we were making progress here, but it seems to have slowed
14:17:57 <johnthetubaguy> possibly because we did the easy ones, but lets keep pushing
14:18:05 <johnthetubaguy> #link https://etherpad.openstack.org/p/kilo-nova-priorities-tracking
14:18:06 <bauzas> johnthetubaguy: agreed, that's also needs more time now
14:18:21 <johnthetubaguy> bottom of the above page has lots of links for "active" bug reviews
14:18:40 <johnthetubaguy> #help please help review more bugs listed at the bottom of https://etherpad.openstack.org/p/kilo-nova-priorities-tracking
14:19:08 <johnthetubaguy> #topic stuck reviews
14:19:10 <sdague> yeh, I think the # of trivial bug fixes in our review system are actually quite small
14:19:37 <mdbooth> This one's still stuck: https://review.openstack.org/#/c/134499/3
14:19:43 <johnthetubaguy> sdague: yeah, maybe we merged the fixes, time do some some more fixes
14:19:52 <mdbooth> Not terribly important, but stuck
14:20:02 <mdbooth> Due to -1 from dansmith
14:20:27 <johnthetubaguy> mdbooth: ah, yes, do we have tests to debunk dan't claim about the issue?
14:20:45 <mdbooth> johnthetubaguy: Yeah, I wrote one
14:20:58 * anteaya votes for dan't for his new friday nick
14:21:01 <mdbooth> I'm not going to commit it, though, because it would just be noise
14:21:24 <johnthetubaguy> mdbooth: can you add it after that patch maybe?
14:21:33 <mdbooth> It's a comment in the patch
14:21:39 <mdbooth> Seriously, it doesn't make any sense
14:21:51 <mdbooth> The act of writing the test reveals its nonsensicalness
14:22:13 <mdbooth> The confusion appears to be over the behaviour of assignment in python
14:23:12 <mdbooth> Jay Lau also posted a test
14:23:13 <garyk> johnthetubaguy: there are a couple of critical bugs in the vmware driver that have been in review for months.
14:23:37 <johnthetubaguy> garyk: can you add the top two or three into the review list in that etherpad?
14:23:40 <garyk> i fpossible could we please get a few eyes on https://review.openstack.org/113908 and https://review.openstack.org/124782
14:23:50 <garyk> johnthetubaguy: sure, will do. thanks
14:24:00 <sdague> mdbooth: yeh, that seems fine after the follow on discussion
14:24:09 <johnthetubaguy> garyk: thanks, just keep an eye on it
14:24:30 <johnthetubaguy> mdbooth: yeah, it looks OK, one of us, or sdague should approve that one I think
14:24:37 <mdbooth> Cool, thanks
14:24:41 <johnthetubaguy> cool, any more?
14:24:52 <johnthetubaguy> sdague: thank you
14:25:02 <anteaya> did I miss the kilo priorties section of the agenda?
14:25:16 <johnthetubaguy> anteaya: whoops I did
14:25:24 <johnthetubaguy> #topic priorities
14:25:34 * anteaya has an item
14:25:41 <johnthetubaguy> #link https://etherpad.openstack.org/p/kilo-nova-priorities-tracking
14:25:49 <johnthetubaguy> updates are available in the usual place
14:25:58 <johnthetubaguy> #help please review the priority patches in here: https://etherpad.openstack.org/p/kilo-nova-priorities-tracking
14:26:03 <johnthetubaguy> anteaya: fire away
14:26:07 <anteaya> thanks
14:26:19 <anteaya> so at the last nova net to neutron migration meeting
14:26:26 <anteaya> which johnthetubaguy attended, thank you
14:26:40 <johnthetubaguy> I heard my name mentioned and came running
14:26:40 <anteaya> I am hearing taht nova would like the direction to be subclassing the api
14:26:48 <anteaya> thanks for that
14:26:51 <dansmith> anteaya: no
14:26:54 <anteaya> which means redirecting to L
14:27:00 <anteaya> no
14:27:05 <anteaya> then I mis-heard
14:27:11 * anteaya listens again
14:27:30 <dansmith> anteaya: there is some concern about doing this by just subclassing objects and replicating at the persistence layer
14:27:36 <johnthetubaguy> dansmith: I was missing interpreting the comments on the review I guess, we seemed against the hack nova objects approach at least?
14:28:10 <dansmith> johnthetubaguy: anteaya: he's going to do another round of a more complicated piece of the implementation so that we can see what it looks like at the objects layer
14:28:19 <dansmith> but it feels really awkward to me to do it there
14:28:35 <alaski> +1
14:28:45 <johnthetubaguy> dansmith: is this for the using neutron but a few hosts still nova-net case?
14:28:52 <dansmith> it's definitely a hack that avoids making changes to either nova-net or neutronapi to make this actually a natively supportable thing
14:29:22 <dansmith> johnthetubaguy: this is for making us run using nova-net, but every time we save something, we redirect to neutron under the covers
14:29:33 <dansmith> ...and also try to save stuff into nova-net's database as well
14:29:58 <johnthetubaguy> ah, yeah, the sync stage
14:30:05 <dansmith> if we didn't have objects, it would be identical to putting stuff into db_api to keep neutron and nova-net in sync
14:30:19 <dansmith> it's doable, and maybe it's the least ugly thing, but it doesn't feel that way
14:30:31 <dansmith> I also don't have a better suggestion (well I do: don't do this silly thing at all), but...
14:30:32 <anteaya> dansmith: so obondarev talked to you?
14:30:35 <johnthetubaguy> right, it feels the wrong level of abstraction
14:30:41 <dansmith> anteaya: yes
14:30:46 <anteaya> wonderful
14:30:49 <anteaya> sorry I missed that
14:30:56 <anteaya> so happy to hear
14:31:10 * anteaya will recheck channel logs
14:31:14 <dansmith> anteaya: sorry, I shouldn't have said no to what you were hearing -- I meant no to the analysis
14:31:21 <anteaya> that is fine
14:31:27 <anteaya> since you had new info
14:31:31 <anteaya> glad he talked to you
14:31:58 <anteaya> so right now you and oleg have agreed that oleg will write a new patch and you will review?
14:32:03 <anteaya> do I have that correct/
14:32:13 * mriedem joins super late
14:32:21 <dansmith> he's going to expand on it, yes
14:32:28 <anteaya> good enough for me
14:32:30 <anteaya> thanks
14:32:37 <dansmith> but I will say,m
14:32:40 * anteaya will wait for another round then on the patch
14:33:04 <dansmith> that even if we go this route, time is getting pretty tight for me to imagine this is actually going to be a workable thing in kilo timeframe, just given the level at which we're operating here
14:33:13 <anteaya> yes
14:33:17 <anteaya> and I concur with you
14:33:23 <anteaya> but oleg seems determined
14:33:35 <anteaya> and he did talk to you, which is what I was hoping for
14:33:42 <anteaya> so I am willing to give him a shot
14:33:54 <anteaya> if you are
14:34:34 <johnthetubaguy> anteaya: so the code has technically missed the deadlines for kilo now, so we can't let it merge without some sort of exception, but lets not bog down on that
14:34:41 <anteaya> right
14:34:45 <dansmith> johnthetubaguy: this is a priority right?
14:34:49 <dansmith> so it has until k3?
14:34:52 <anteaya> since we don't know if we have anything worth excepting
14:35:34 <johnthetubaguy> dansmith: yeah, just we don't have a blueprint merged for that yet, but we could do that
14:35:50 <anteaya> I have what I need for this week, sorry to keep others waiting
14:35:53 <johnthetubaguy> anyways, thats s pointless debate, if its ready we will do something exceptional for it
14:35:53 <anteaya> thank you
14:35:56 <dansmith> okay, I didn't think that mattered, but I don't know what to put in a blueprint at this point
14:35:57 <johnthetubaguy> probably
14:36:20 <johnthetubaguy> dansmith: its just tracking I guess, mostly for docs at this point
14:36:29 <johnthetubaguy> but thats just paper work we would need to do
14:36:36 <johnthetubaguy> anyways, any more on priority stuff?
14:36:46 <anteaya> oh and we have a docs patch: https://review.openstack.org/#/c/155947
14:36:52 <anteaya> if folks could review that
14:37:06 <anteaya> it will be presented at ops mid-cycle
14:37:10 <anteaya> by sdague
14:37:12 <johnthetubaguy> anteaya: is that linked in the tracking etherpad?
14:37:16 <anteaya> yes
14:37:31 <johnthetubaguy> anteaya: awesome, thanks
14:37:38 <johnthetubaguy> #topic open discussion
14:37:49 <alaski> o/
14:37:56 <johnthetubaguy> mriedem: just a poke about the gate incase you wanted to raise something
14:38:00 <johnthetubaguy> alaski: fire away
14:38:08 <alaski> https://review.openstack.org/#/c/153666/ vs https://review.openstack.org/#/c/157156/
14:38:13 <mriedem> johnthetubaguy: http://status.openstack.org/elastic-recheck/gate.html
14:38:21 <alaski> essentially alembic vs sqla-migrate for new migrations
14:39:04 <alaski> I like alembic personally, but it does mean that devs need to learn a new system
14:39:24 <alaski> though ultimately this will be moot with the online schema change work
14:39:54 <alaski> I want to gather thoughts and opinions on which path I should go with
14:40:13 <johnthetubaguy> alaski: so its a new DB right?
14:40:29 <alaski> johnthetubaguy: yes, totally fresh database
14:40:30 <johnthetubaguy> and alembic is the one actually maintained by the upstream project still
14:40:40 <johnthetubaguy> so thats quite attractive from where I am sat
14:40:56 <dansmith> I think the question is,
14:40:58 <johnthetubaguy> and as you said, it all goes away once we have online migrations working I guess
14:41:08 <dansmith> if we're not going to see alembic from our code once we have the online schema bits,
14:41:16 <dansmith> then it's just learning a new thing for no real gain
14:41:19 <johnthetubaguy> but thats a new tech for a very short amount of time I guess?
14:41:20 <dansmith> er, yeah, that :)
14:41:20 <garyk> i suggest reaching out to a few people in neutron who work with the alembic migrations
14:41:30 <garyk> salv-orlando would be a good place to start
14:41:44 <garyk> the nova way of writing them is far easier in my opinion
14:42:01 <alaski> garyk: to ask what?
14:42:15 <garyk> whether it is a good way to go, what the painpoints are etc.
14:42:24 <johnthetubaguy> alaski: you know, this one is quite easy I guess: https://review.openstack.org/#/c/157156/2/nova/db/sqlalchemy/api_migrations/migrate_repo/versions/001_cell_mapping.py,cm
14:42:35 <mdbooth> Vaguely on the topic of migrations, I posted this earlier: http://lists.openstack.org/pipermail/openstack-dev/2015-February/057324.html
14:42:38 <alaski> the migrations are very similar, though alembic can do a lot of it automatically
14:43:02 <mdbooth> It's about creating a unique constraint in the db to cover the use case of osapi_compute_unique_server_name_scope
14:43:22 <mdbooth> However, it would seem to require configuring the db schema on the fly
14:43:28 <alaski> it sounds like there's a leaning towards not learning a new system for a short period of time
14:43:49 <alaski> so I'll move forward with sqla-migrate
14:43:55 <alaski> as a followup
14:44:09 <alaski> I moved the current migrations in my patch to a new directory
14:44:16 <dansmith> alaski: honestly, I think that'd be my preference.. avoid putting any more blockers in our way
14:44:20 <johnthetubaguy> alaski: I like how it gives us more reasons to drop that code you are adding once we are happy with the online stuff
14:44:24 <dansmith> unless there's some real technical reason
14:44:40 <johnthetubaguy> alaski: I was thinking it was good to learn the new way
14:44:52 <alaski> do people like/dislike the directory move to distinguish migrations?
14:45:00 <johnthetubaguy> mdbooth: I would vote we deprecate the config option, FWIW, and see who shouts
14:45:03 <alaski> dansmith: no real technical reason, beyond alembic autogenerating migrations
14:45:19 <johnthetubaguy> alaski: maybe don't rename the old one?
14:45:26 <dansmith> alaski: right, I meant reason like "sqlamigrate is really unable to do two streams" or something
14:45:27 <mdbooth> johnthetubaguy: Works for me.
14:45:46 <alaski> dansmith: yeah, everything seems to work fine at this point
14:46:02 <dansmith> then my vote would be to concentrate on other hard problems I think
14:46:12 <dansmith> even though I think I was +1 on alembic before,
14:46:13 <sdague> also, openstack project owns migrate at this point, so we can fix it if we need to
14:46:16 <johnthetubaguy> alaski: ah, its two different DBs with separate sqlalchemy_migrate streams right?
14:46:21 <dansmith> but wasn't really factoring in the online schema thing
14:46:26 <dansmith> johnthetubaguy: yes
14:46:33 <alaski> johnthetubaguy: yes, I renamed to distinguish them easily
14:46:40 <mriedem> feel free to ping me to rubberstamp any and all sqla-migrate changes :)
14:46:42 <johnthetubaguy> alaski: got it, thats a nice solution
14:47:11 <alaski> johnthetubaguy: it does break turbo-hipster which hardcodes where it looks for migrations, but I have an email to them already about that
14:47:29 <johnthetubaguy> alaski: can we avoid the rename, or does that just look too messy?
14:47:40 <alaski> it can be avoided for now
14:47:47 <alaski> I think eventually we'll want it
14:48:09 <alaski> I think I got what I needed
14:48:18 <alaski> drop alembic, probably don't rename for now
14:48:22 <johnthetubaguy> well, eventually we just delete it, but yeah, that too
14:48:29 <johnthetubaguy> cools
14:48:31 <alaski> but reviews welcome with further feedback
14:49:30 <johnthetubaguy> cool
14:49:33 <johnthetubaguy> seems like we are done
14:49:39 <johnthetubaguy> any last items?
14:49:56 <johnthetubaguy> thanks all, feedback on the agenda welcome, we had a few dead areas today
14:50:06 <johnthetubaguy> #endmeeting