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