15:00:35 <n0ano> #startmeeting gantt
15:00:36 <openstack> Meeting started Tue Mar  3 15:00:35 2015 UTC and is due to finish in 60 minutes.  The chair is n0ano. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:37 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:37 <bauzas> clock ?
15:00:40 <openstack> The meeting name has been set to 'gantt'
15:00:47 <n0ano> anyone here to talk about the scheduler?
15:00:51 <alex_xu> o/
15:00:53 <bauzas> \o
15:00:55 <edleafe> o/
15:01:31 * n0ano notes that meetbot commands work better in a window running meetbot
15:01:36 <bauzas> sounds like we definitely lost jay because of his prom :)
15:01:53 <n0ano> anyway, edleafe congratulations on the spec, it's finally in
15:02:02 <edleafe> \o/
15:02:05 <PaulMurray> o/
15:02:25 <n0ano> so, to business (hopefully short)
15:02:30 <n0ano> #topic patch status
15:02:43 <n0ano> all the specs are approved so now we just have to implement them
15:03:14 <n0ano> I guess I'll throw it open, anyone have any problems they need help with?
15:03:31 <bauzas> n0ano: we can circle on the blueprints
15:03:32 <edleafe> I do
15:03:50 <n0ano> edleafe, go ahead
15:03:53 <edleafe> I'm getting strange RPC version mismatch from the ec2 tests
15:04:10 <bauzas> before digging into details, we should just provide a quick reminder to all
15:04:22 <edleafe> If you see the Jenkins logs for py27 in https://review.openstack.org/#/c/160513/
15:04:30 <bauzas> Feature Proposal Freeze is this Thursday 5th
15:04:47 <bauzas> so, no new patches unless exceptional circumstances
15:05:03 <bauzas> that said, now back to edleafe's problem
15:05:21 <edleafe> I'm not sure why these tests are failing now
15:05:31 * bauzas checking
15:05:53 <edleafe> From what I've traced, it looks as though the compatibility check says that 3.x is not compatible with 4.0
15:06:17 <edleafe> IOW if the major version is newer, it assumes that the endpoint can't handle it
15:06:22 <edleafe> which makes no sense to me
15:06:42 <bauzas> edleafe: I think that's probably a side-effect of your change
15:06:44 <edleafe> especially since the old version for scheduler was 4.0, and I bumped it to 4.1
15:07:00 <n0ano> edleafe, indeed, you would think that would be a greater than rather than an equal test
15:07:36 <edleafe> bauzas: I don't see how I changed anything in the path for ec2's stop_instance calls
15:07:52 <bauzas> edleafe: by reading the trace, I can see some path by the compute.api
15:07:56 <n0ano> edleafe, did you change any common code
15:08:08 <edleafe> n0ano: not that I can see
15:08:23 <lxsli> oops o/
15:08:53 <bauzas> edleafe: I think that needs further verifications, have you tested on your local devstack ?
15:09:00 <bauzas> edleafe: because even Tempest is red
15:09:15 * n0ano bauzas beats me again
15:09:18 <edleafe> bauzas: yes - it fails there too
15:09:37 <edleafe> n0ano: the one thing is in compute.rpcapi.py
15:09:56 <edleafe> I tried bumping the version there, and it just makes different ec2 tests fail
15:10:05 <edleafe> but all due to incompatible versions
15:10:22 <n0ano> well, if it's failing locally we have to fix that first
15:10:27 <bauzas> edleafe: I seriously need to review your code before saying anything
15:10:45 <edleafe> bauzas: sure
15:10:49 <bauzas> edleafe: at least try to identify on your local machine
15:11:01 <edleafe> I'm just wondering if there is any magic rpc version juju that I don't know about
15:11:18 <bauzas> edleafe: well, see my patch about upgrading the RPC version if you need help
15:11:26 <edleafe> bauzas: ok, will do
15:11:32 <alex_xu> ec2 unittest like a function..... running all the service...
15:11:45 <bauzas> at the moment, the gate is in a pretty bad shape so I'm rechecking consistently but I'm sure about my code
15:12:06 <bauzas> alex_xu: you mean it's a functional test ? indeed
15:12:34 <n0ano> bauzas, yeah, but if it's failing locally then the gate status doesn't really matter
15:12:48 <edleafe> n0ano: yeah, this isn't a gate issue
15:12:52 <alex_xu> bauzas: yea, I just found that, but I didn't find out anything can help edleafe
15:13:21 <bauzas> n0ano: I was mentioning my own series which is done but has various -1s
15:13:39 <edleafe> I was hoping that someone had a quick answer that could save me hours of searching
15:13:45 <bauzas> but agreed, let's fix first locally before sending it back to gerrit
15:13:48 <n0ano> bauzas, but yours passes locally I assume so it would be a good template
15:14:06 <bauzas> edleafe: it does need hours of reviewing before giving a quick answer :)
15:14:15 <edleafe> bauzas: heh
15:14:24 <n0ano> edleafe, looks like there's no magic bullet for this one
15:14:55 <edleafe> I'll let everyone know what the problem was when I figure it out
15:14:56 <bauzas> the good news is that something so tomato red just means that you made a huge mistake
15:14:57 <n0ano> edleafe, keep me posted, I'm free most of today so I'll look at this also
15:15:12 <bauzas> and huge mistakes are the easiest to fix
15:15:26 <n0ano> bauzas, and more likely a single problem that impacts everything
15:15:33 <bauzas> probably
15:16:04 <n0ano> OK, since we're all here, let's do a quick cycle through the specs
15:16:05 <edleafe> bauzas: yeah, it is something with the interaction between compute and scheduler RPC version numbers
15:16:16 <edleafe> gotta keep playing around with it
15:16:19 <bauzas> edleafe: both are unrelateed
15:16:28 <n0ano> PaulMurray, how's your resource tracker use objects coming?
15:16:36 <PaulMurray> great
15:16:39 <bauzas> edleafe: you can bump a version without touching the other
15:17:03 <PaulMurray> n0ano, I have one more patch to put up for compute nodes - just fixing some tests
15:17:15 <edleafe> bauzas: that's what I thought, but the ec2 tests started failing
15:17:21 <n0ano> PaulMurray, cool, we'll mark you as green, let us know if you need any help
15:17:33 <PaulMurray> n0ano, I think there are one or two places where instances are still using conductor calls gut don't need to - so will sort that
15:17:42 <PaulMurray> n0ano, will do
15:17:55 <n0ano> PaulMurray, great
15:18:22 <n0ano> bauzas, next is detach service from compute node
15:18:32 <bauzas> n0ano: I'm in
15:18:58 <bauzas> n0ano: so basically, 95% of code is merged, only a few patches missing - basically about the service field on the DB side
15:19:17 <n0ano> bauzas, excellent, mark that as bright green
15:19:24 <bauzas> so I'm still beating with last outstanding bugs but I have core reviewers support
15:19:52 <bauzas> n0ano: yeah I'm considering this blueprint as done for Kilo, the rest can be done in Liberty
15:19:54 <edleafe> bauzas: anything we can do to help push it across the finish line?
15:20:16 <n0ano> jay doesn't appear to be on line, I'll manually go over his patch series after the meeting
15:20:17 <bauzas> edleafe: not really, that's quite simple but I had to deal with side effects
15:20:50 <n0ano> bauzas, next 2 are you, model request spec and cahnge select_destinations
15:20:52 <bauzas> I'm planning to deliver a last iteration by today
15:20:55 <edleafe> bauzas: k
15:21:24 <bauzas> n0ano: yeah, so let's consider these 2 specs are not targetable for Liberty
15:21:44 <bauzas> n0ano: because even the spec was wrong - based on reviews
15:22:11 <bauzas> n0ano: so I'll focus on *one* spec (will merge both) by L-1 once the trunk opens
15:22:20 <bauzas> that should be quick
15:22:44 <bauzas> targeting this spec for L-1 as you understand
15:22:47 <n0ano> I'm a little confused, even though they were accepted you're saying they are wrong?
15:22:52 <bauzas> n0ano: right
15:23:34 <bauzas> n0ano: ndipanov and I agreed on the fact it was better to add new RPC method instead of managing the hydradation on the same method, ie. select_dest()
15:23:38 <n0ano> bummer, I hope we don't have an infinite review process on them during Liberty
15:24:02 <bauzas> also, the RequestSpec proposed object is probably wrong, we don't need all the Instance object
15:24:19 <bauzas> n0ano: I don't think so, we had good feedback on Kilo for this spec
15:24:38 <bauzas> n0ano: and as it was an approved spec, it will be short for L
15:25:05 <n0ano> OK, my worry is will this cause issues with splitting out gantt
15:25:15 <bauzas> n0ano: I have a plan :)
15:25:34 <n0ano> we're all listening
15:25:38 <bauzas> n0ano: but that requires to be discussed on Vancouver
15:26:00 <bauzas> n0ano: I mean, we know that we have lots of things to do for splitting out Gantt, not only fixing tech deby
15:26:21 <bauzas> n0ano: so I'm in favor of identifying the work for the migration path and do it for L
15:26:35 <ndipanov> bauzas, are we talking about request_spec object one?
15:26:36 <n0ano> OK, maybe an outline in one of the future IRC meeings would be good so we have an idea of what you are thing of
15:26:37 <bauzas> n0ano: I have ideas again, I need to drop them off
15:26:44 <bauzas> ndipanov: yup
15:27:10 <bauzas> n0ano: sure, let's outline that next week - but ideally I would expose it once FF is there
15:27:21 <bauzas> n0ano: because we don't exactly know what's missing
15:27:46 <bauzas> like the resource-objects BP is currently stale
15:28:12 <n0ano> I don't want to put you on the spot right now but I don't want to hit everyone with new stuff at Vancouver so yeah, let's talk on this next week
15:29:00 <bauzas> n0ano: agreed
15:29:27 <n0ano> I think that's everything for the current patches (mostly green except for those that aren't :-)
15:29:28 <bauzas> next BP ?
15:29:35 <bauzas> n0ano: nope, you forgot one
15:29:42 <bauzas> n0ano: and I have excellent news
15:30:19 <bauzas> so, bp/isolate-sched-db for aggregates is up for code-review
15:30:35 <bauzas> full completion of the spec, only waiting feedback
15:30:58 <n0ano> bauzas, that is good news, hopefully it'll merge soon
15:31:15 <bauzas> n0ano: yeah, I was targeting to be uploading it before FPF
15:31:35 <bauzas> it will become very hard to propose new patches by next week
15:32:07 <bauzas> btw. edleafe our patch about fixing the cast_as_call fixture got merged, you can rebase on top of master
15:33:15 <n0ano> so, anything else on patches?
15:33:37 <bauzas> folks, think about updating the nova priorities etherpad if you want core support
15:34:18 <n0ano> bauzas, good point although we can push at the nova IRC meeting also
15:34:44 <n0ano> then, moving on
15:34:48 <n0ano> #topic opens
15:34:49 <edleafe> oh, and the isloate-sched-db for instances is up for code review too
15:35:02 <n0ano> edleafe, excellent
15:35:16 <n0ano> anyone have anything new for today?
15:35:53 * edleafe hears crickets
15:36:02 * n0ano also
15:36:16 <n0ano> then tnx everyone, we'll talk next week
15:36:20 <n0ano> #endmeeting