13:00:05 <alex_xu> #startmeeting nova api 13:00:06 <openstack> Meeting started Wed Jun 29 13:00:05 2016 UTC and is due to finish in 60 minutes. The chair is alex_xu. Information about MeetBot at http://wiki.debian.org/MeetBot. 13:00:07 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 13:00:09 <openstack> The meeting name has been set to 'nova_api' 13:00:19 <alex_xu> who is here today for Nova API? 13:00:29 <Kevin_Zheng> o/ 13:00:40 <gmann> o/ 13:01:38 <alex_xu> very quiet today, US have holiday recently? 13:02:27 <gmann> hummm 13:02:38 <alaski> no, but there's one coming up next monday 13:03:03 <alex_xu> alaski: so next week will more quiet than today :) 13:03:13 <alex_xu> anyway, let's running the meeting 13:03:18 <alaski> very likely :) 13:03:30 <alex_xu> we didn't have action from previous meeting 13:03:37 <alex_xu> #topic API priorities 13:03:56 <alex_xu> for policy discovery, we have a bunch of patches waiting for review 13:04:11 <alex_xu> alaski: any important update on that? 13:04:28 <alaski> the patches are merging, but there are still a few up 13:04:37 <alaski> it's looking pretty good for completing 13:04:39 <alaski> that's all 13:04:43 <alex_xu> #link https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:bp/policy-in-code 13:04:52 <alex_xu> wow, most of them are merged 13:05:21 <alex_xu> alaski: i guess the last thing is the cmd for policy discovery, right? 13:05:29 <gmann> alaski: there will be policy generator tox env right, which merge the existing policy file with default one ? 13:05:31 <alaski> yeah, we have been pushing last week and this week 13:05:46 <alaski> alex_xu: that, and what gmann just mentioned 13:05:57 <alex_xu> alaski: gmann cool 13:06:03 <gmann> nice 13:06:06 <alaski> I think claudiub had a patch up for the discovery cmd 13:06:07 <alex_xu> good progress at here 13:06:32 <alex_xu> for api ref 13:06:42 <alaski> https://review.openstack.org/#/c/322944/ for reference 13:06:46 * edleafe comes in late 13:06:52 <woodster_> o/ 13:07:11 <alex_xu> alaski: thanks 13:07:13 <gmann> alaski: thanks, ll check tomorrow morning. 13:07:35 <alex_xu> for api-ref, i didn't see any news, except a set of patch waiting for review 13:08:00 <gmann> alex_xu: yea, little bit slow progress we have on those. 13:08:17 <gmann> alex_xu: if you can look this one - https://review.openstack.org/#/c/326975/ 13:08:33 <gmann> alex_xu: I will start giving some time on those next week may be 13:08:56 <alex_xu> gmann: will try to reach that asap 13:09:16 <gmann> alex_xu: Thanks :) 13:09:34 <alex_xu> we have hackathon in China next week, i may spend some time on that also 13:09:36 <alex_xu> gmann: np 13:09:56 <alex_xu> for proxy api deprecation, i have a set of patches up at here 13:10:05 <alex_xu> #link https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:bp/deprecate-api-proxies 13:10:08 <gmann> alex_xu: cool, can you get more developer on that in hackathon? 13:10:45 <alex_xu> gmann: i will try that, hope i can attract some developers 13:10:53 <Kevin_Zheng> i will join 13:10:58 <gmann> +1 13:11:01 <alex_xu> Kevin_Zheng: you are cool :) 13:11:41 <alex_xu> All the patches for proxy api deprecation at here 13:11:48 <alex_xu> but it needs a rebase 13:12:21 * mriedem joins late 13:12:25 <gmann> alex_xu: Thanks. ll look into those 13:12:28 <alex_xu> but I want to leave a space for non-priority features, so rebase after tomorrow, and hope people take a look at those patches are good for merge together or not 13:12:34 <alex_xu> gmann: thanks 13:13:00 <johnthetubaguy> alex_xu: gmann: I mean to say, I hope OSIC folks can get back on that api-ref stuff post feature freeze 13:13:18 <alex_xu> johnthetubaguy: cool :) 13:13:19 <gmann> johnthetubaguy: very nice. 13:14:47 <alex_xu> johnthetubaguy: mriedem the patch for proxy deprecation are on the gerrit, hope you guys can take a look at, then we find a time later or next week to merge them all 13:15:22 <johnthetubaguy> yeah, feels like we sneak that in post freeze? 13:15:31 <alex_xu> johnthetubaguy: yea 13:16:40 <mriedem> +1 on that 13:16:48 <mriedem> i don't want that to go too long though 13:17:13 <alex_xu> the last for api prorities is extension deprecation, but sdague isn't here. most of activity patches are merged looks like. 13:17:16 <alex_xu> mriedem: cool 13:17:46 <alex_xu> i think we can check with sdague about extension deprecation when he is back 13:17:47 <mriedem> extension deprecation or folding? 13:18:07 <alex_xu> mriedem: they are on some bp? 13:18:14 <alex_xu> s/some/same/ 13:18:22 <mriedem> i think so yeah 13:18:37 <alex_xu> for now, it should be folding 13:18:47 <johnthetubaguy> I think the spec deferred some bits of it to ocata, which seemed about right 13:19:00 <mriedem> sort of related, https://review.openstack.org/#/c/334053/ needs to be cleaned up 13:19:03 <alex_xu> johnthetubaguy: yea, right 13:19:10 <mriedem> i could do it, or it could wait for friday 13:19:53 <johnthetubaguy> mriedem: are we doing a python-novaclient release soon? 13:20:05 <mriedem> johnthetubaguy: we just did one to get tags support out 13:20:06 <mriedem> 2 weeks ago 13:20:11 <mriedem> we'd do a release after ^ though 13:20:19 <gmann> mriedem: we need proxy API deprecation also on client side right? 13:20:22 <mriedem> andreykurilin has some things he wants to release for deprecations too 13:20:24 <johnthetubaguy> right, I was wondering if we were holding that up 13:20:39 <mriedem> proxy api deprecation in the client, we were going to discuss at the summit 13:20:42 <mriedem> s/summit/meetup/ 13:20:53 <gmann> ok 13:20:57 <johnthetubaguy> makes sense 13:20:58 <alex_xu> ok 13:21:06 <mriedem> there are some notes in the etherpad on that https://etherpad.openstack.org/p/nova-newton-midcycle 13:21:11 <mriedem> L24 13:21:28 <gmann> mriedem: nice, Thanks. 13:21:33 <gmann> I will try to attend if get budget from company 13:22:17 <alex_xu> cool 13:22:57 <alex_xu> looks good at here, so any more question on api priorities? if not, let's move on 13:24:02 <alex_xu> i guess the answer is let's move on 13:24:12 <alex_xu> #topic open 13:24:22 <alex_xu> #link https://review.openstack.org/#/c/305369/ 13:24:28 <alex_xu> alaski: your turn 13:25:16 <alaski> I wanted to bring that up to get the reaction to versioning responses 13:25:45 <alaski> I wasn't sure if that was a level Nova was planning to get to 13:26:27 <mriedem> wha 13:26:40 <alex_xu> at least for now, we can implement different repsonse code with write another new method 13:27:07 <johnthetubaguy> yeah, I think we have done that be adding new methods, actually maybe we haven't done that much yet 13:27:08 <alaski> sorry, should have been more specific. response codes, not just reponses 13:27:08 <alex_xu> so we didn't have very strong requirement for that decorator 13:27:25 <mriedem> right what alex_xu said 13:27:38 <alaski> okay 13:27:46 <alaski> so that's one aspect, the decorator isn't needed 13:27:50 <mriedem> we also have separate versioned methods for the expected_errors decorator also 13:28:10 <alaski> so we do actually microversion response code changes? I wasn't sure on that 13:28:32 <alaski> I mean I wasn't sure we made those changes 13:28:32 <johnthetubaguy> I think the rules say we have to for success codes, or new error codes? 13:28:46 <alex_xu> yes, we do 13:28:59 <gmann> yea, we did for keypair but along with other changes 13:29:00 <alaski> okay, cool 13:29:14 <mriedem> same for hypervisors https://review.openstack.org/#/c/326940/16/nova/api/openstack/compute/hypervisors.py 13:29:18 <mriedem> i posted a comment in the change 13:29:42 <alaski> thanks 13:29:54 <alaski> that was it 13:29:55 <mriedem> i'd prefer we are being explicit about the stuff we do within the methods themselves 13:30:02 <johnthetubaguy> #link http://docs.openstack.org/developer/nova/api_microversion_dev.html#when-do-i-need-a-new-microversion 13:30:02 <mriedem> rather than magically version a response in a decorator 13:30:14 <alex_xu> mriedem: +1 13:30:23 <johnthetubaguy> +1 on explicit, where practical 13:30:52 <gmann> +1, much readable/debugable also 13:31:03 <edleafe> using a decorator for this seems slick, so probably not a good idea 13:31:35 <alex_xu> yea 13:31:48 <mriedem> ok, i left a -1 13:31:48 <alaski> agreed on explicit. I haven't reviewed much of the API changes though which is why I wanted to ask about that review 13:31:48 <alex_xu> if no more question, let's go next item 13:32:07 <mriedem> alaski: cdent would probably throw this into a nova-ism for wonky confusing magic wsgi 13:32:18 <edleafe> mriedem: heh 13:32:25 <mriedem> i don't disagree though 13:32:29 <alaski> true 13:33:25 <alex_xu> #link https://review.openstack.org/#/c/326326/ 13:33:31 <alex_xu> Kevin_Zheng: your turn 13:33:46 <Kevin_Zheng> thanks 13:34:20 <Kevin_Zheng> I was working on add pagination and timestamp filter for os-instance-actions 13:34:55 <Kevin_Zheng> alex suggested that for timestamp filter we should use updated_at instead of created_at 13:35:02 <Kevin_Zheng> which is good 13:35:20 <Kevin_Zheng> but currently this field is mostly empty 13:35:26 <Kevin_Zheng> except error occors 13:36:01 <mriedem> sort by updated_at first, created_at second? 13:36:16 <Kevin_Zheng> should we sync updated_at to created_at when it is created? 13:36:27 <mriedem> we don't do that for anything else 13:36:29 <mriedem> so that would be odd 13:36:35 <alex_xu> that is due to the new event added to instance-action, the new event is separated db record, so the update_at of instance-action won't update 13:36:42 <Kevin_Zheng> and also, we only called record_action start 13:36:58 <Kevin_Zheng> record_action_finish has never been called 13:37:00 <alex_xu> actually we can sort with updated_at first, then created_at 13:37:20 <mriedem> hrm 13:37:32 <mriedem> when we create a new instance action event, we could bump the updated_at on the parent instance action 13:37:34 <mriedem> just a thought 13:37:43 <alex_xu> mriedem: yea 13:37:56 <Kevin_Zheng> yes 13:38:32 <Kevin_Zheng> so shoud we do it in a separate patch? 13:38:33 <Kevin_Zheng> as bug? 13:39:00 <mriedem> that seems like a decent separate bug fix 13:39:13 <Kevin_Zheng> OK then 13:39:37 <mriedem> alaski: any issues with that? 13:39:41 <mriedem> you're the action event guy 13:40:05 <alaski> from a mechanical pov no, that seems fine 13:40:18 <alaski> but because events are exposed that might be weird from a ux pov 13:40:22 <alaski> are not* 13:40:32 <mriedem> they are 13:40:36 <mriedem> instance action details 13:40:43 <mriedem> doffm had to deal with it i think 13:40:44 <alaski> only for admins, at least by default 13:40:59 <alex_xu> so do we still need sync create_at and updated_at? or just sort updated_at first then created_at 13:41:09 <mriedem> https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/instance_actions.py#L88 13:41:29 <alaski> mriedem: line 85 13:41:32 <Kevin_Zheng> I think if we want to show updated_at in the response, we have to sync 13:41:37 <mriedem> alaski: yeah 13:41:44 <Kevin_Zheng> otherwise updated_at will be empty 13:42:03 <mriedem> i'm just wondering if ordering by updated_at,created_at will look weird 13:42:17 <alex_xu> Kevin_Zheng: we need expose that, otherwise user didn't know how to fill the marker parameter 13:42:53 <Kevin_Zheng> alex_xu: then I suggest we sync that, looks like other projects do that, like heat 13:43:05 <alaski> I'm on the side of setting updated_at when creating the action 13:43:39 <mriedem> i think that's weird 13:44:08 <mriedem> it's a hack for our sorting, which we otherwise wouldn't do 13:44:22 <edleafe> mriedem: what if it was named 'last_touched'? 13:44:32 <mriedem> gross 13:44:33 <alaski> I've always thought we should do it generally 13:44:58 <alaski> if we're not going to do that then basing it off of action-events is the next best thing I think 13:45:19 <mriedem> alaski: as in updating updated_at on the instance action when creating an event for that action? 13:45:35 <alaski> mriedem: yes 13:46:04 <mriedem> maybe this is a ML item 13:46:12 * mriedem wishes sdague were here for sage advice 13:46:16 <alaski> it's on the ML 13:46:31 <mriedem> touche 13:46:31 <alex_xu> i think sync create_at and update_at are not just for this patch, it is about all the db model. How about sort updated_at,create_at first. Then discuss create_at and update_at later. 13:46:53 <alaski> http://lists.openstack.org/pipermail/openstack-dev/2016-June/098299.html 13:47:23 * alaski also misses sdague here 13:47:23 <mriedem> i'm trying to think of other parent/child resources like this where we'd update updated_at when changing the child 13:47:36 <alex_xu> emm...I wish another adivce from sdague for next page also :( 13:47:36 <mriedem> like instance group member and instance group 13:48:33 <mriedem> i need to read the ML and digest there really 13:48:37 <mriedem> just got online 13:48:57 <alaski> yeah, I don't think we do this anywhere else 13:50:34 <alaski> alex_xu: I agree that this is a more general thing than just instance actions, syncing updated/created 13:50:52 <alaski> I'm not sure I understand sorting by updated_at, created_at though. Is updated_at ever set? 13:50:52 <alex_xu> alaski: yea 13:51:51 <alex_xu> in the beginning, it is not. it will better after Kevin_Zheng fix the sync of action-event's updated_at to action's update_at 13:51:57 <mriedem> https://github.com/openstack/nova/blob/master/nova/db/sqlalchemy/api.py#L5968 13:52:03 <mriedem> ^ action finish updates the action 13:52:34 <Kevin_Zheng> yes but this has never been called by any API 13:52:54 <alaski> yeah, it's not used yet 13:53:03 <alex_xu> why that isn't used? 13:53:19 <alaski> because it's not trivial to determine when an action is finished 13:53:38 <alaski> so it hasn't happened yet 13:53:46 <alaski> there's a proposed, but not approved, spec to do it 13:54:25 <mriedem> is that the backlog spec on tasks? 13:54:27 <alaski> my only real concern with basing it off of action-event syncing is that every action needs at least one event then 13:54:43 <alaski> mriedem: fortunately not, it's specifically about instance-actions 13:55:04 <alaski> https://review.openstack.org/#/c/256743/ I think 13:55:15 <mriedem> i'm not sure why every action would require at least one event 13:55:27 <mriedem> you create the action, you create the event + update the parent action 13:55:36 <alaski> otherwise updated_at wouldn't ever get set 13:55:46 <mriedem> that's fine if we order by updated_at,created_at 13:56:08 <alaski> yeah, if created_at is included that works 13:56:30 * alex_xu reminds 4 mins left 13:56:33 <mriedem> we've got 4 minutes left 13:56:34 <mriedem> yeah :) 13:56:43 <alaski> maybe it was https://review.openstack.org/#/c/248248/ I was thinking of 13:56:46 <mriedem> how about we table this for now, and move it to the ML 13:56:50 <alaski> +1 13:56:54 <Kevin_Zheng> sure 13:56:56 <alex_xu> +1 13:56:59 <Kevin_Zheng> Thanks alto 13:57:02 <Kevin_Zheng> alot 13:57:34 <alex_xu> ok, if no more question, let's close the meeting 13:57:42 <gmann> 1 have one. 13:57:46 <gmann> #link https://review.openstack.org/#/c/335349/2 13:57:58 <gmann> johnthetubaguy: alex_xu i agree we need version bump here 13:58:12 <gmann> but m thinking it is worth to bump version for this? 13:58:25 <alex_xu> gmann: yes, i guess not 13:58:28 <gmann> or we leave that as it is and do if someone really complain 13:58:36 <alex_xu> so keep it as for now 13:58:40 <gmann> because only cinder is user 13:58:49 <alex_xu> gmann: yea, i prefer that 13:58:56 <gmann> alex_xu: ok, cool 13:59:12 <alex_xu> ok, we have to close the meeting now 13:59:16 <alex_xu> thanks all! 13:59:19 <alex_xu> #endmeeting