13:00:07 <alex_xu> #startmeeting nova api
13:00:08 <openstack> Meeting started Wed Mar  1 13:00:07 2017 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:09 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
13:00:12 <openstack> The meeting name has been set to 'nova_api'
13:00:18 <alex_xu> who is here today?
13:00:43 <Kevin_Zheng> o/
13:00:56 <alex_xu> johnthetubaguy: sdague, are you around?
13:01:01 <sdague> yeh
13:01:03 <macsz> O/
13:01:04 <alex_xu> Kevin_Zheng: welcome back
13:01:16 <sdague> man, it's wed already....
13:01:35 <alex_xu> yea...
13:01:40 <johnthetubaguy> o/
13:01:57 <Kevin_Zheng> alex_xu: ：）
13:02:31 <alex_xu> I see why we didn't prorioty for api this release now, the policy stuff is waiting for more hierarchy quota things
13:03:19 <johnthetubaguy> policy stuff?
13:03:30 <alex_xu> #topic anything we looking for api team in Pike although no prority task
13:03:36 <johnthetubaguy> that shouldn't be blocked by any hierarchy stuff
13:03:59 <sdague> right, policy can happen now
13:04:26 <alex_xu> johnthetubaguy: maybe I misunderstand the note at https://etherpad.openstack.org/p/nova-ptg-pike-api@6
13:04:28 <johnthetubaguy> I got the some OSIC folks kicked off on that yesterday, specs are up
13:04:29 <sdague> alex_xu: yeh, honestly, when we got to the priorities section, it wasn't clear to me that there were must haves besides the policy docs
13:04:39 <johnthetubaguy> sdague: +1
13:05:06 <sdague> alex_xu: happy to entertain ideas to move forward, it didn't seem like there were that many proposals for big pushes
13:05:27 <alex_xu> i'm cool with that
13:05:29 <johnthetubaguy> alex_xu: hmm, yeah, that note looks wrong to me
13:05:54 <johnthetubaguy> alex_xu: we discussed all the policy stuff when the keystone folks came to visit, maybe thats what that meant
13:06:13 <alex_xu> ah, i see now :)
13:06:30 <sdague> right, there were kind of 2 different things there
13:07:07 <johnthetubaguy> for other things, we did mention the api concepts guide needs some more love, but with api-ref in a good shape its not as critical as policy docs IMHO
13:07:19 <alex_xu> yea
13:08:42 <alex_xu> johnthetubaguy: what about https://review.openstack.org/433037 ?
13:08:48 <alex_xu> just waiting for more review?
13:08:56 <johnthetubaguy> FWIW ironic have already done a great start at the policy stuff: https://github.com/openstack/ironic/blob/8db68fef4e97b2ed6552b80215ab03093f18e615/ironic/common/policy.py
13:09:28 <johnthetubaguy> alex_xu: for me all three specs just need reviewing as a sub team, then getting the other specs-cores to take a look afterwards
13:10:07 <alex_xu> johnthetubaguy: got it, i'm clear the path now
13:10:35 <johnthetubaguy> I believe keystone are planning on doing the move policy into code, and add descriptions bit
13:12:12 <johnthetubaguy> has anyone got any questions on the three policy specs?
13:12:29 <johnthetubaguy> if you are like me, you are still having your brain reboot post PTG, so thats more for next week
13:12:37 <sdague> johnthetubaguy: no, I just need to get enough breathing space to start reading
13:12:47 <johnthetubaguy> sdague: cool, totally
13:13:13 <alex_xu> me too
13:14:22 <alex_xu> so i think we are clear the plan, anything more?
13:14:27 <johnthetubaguy> I found a pending spec of mine around tidying up security groups APIs
13:14:35 <johnthetubaguy> I frankly don't have the bandwidth on that
13:14:44 <alex_xu> which one?
13:14:48 <johnthetubaguy> #link https://review.openstack.org/#/c/382414/
13:15:00 <johnthetubaguy> so if someone wanted to take that and drive it, I would be more than happy
13:16:20 <johnthetubaguy> for the notes...
13:16:22 <johnthetubaguy> #link https://developer.openstack.org/api-guide/compute/users.html
13:16:38 <johnthetubaguy> #help lots of api-guide TODOs that need filling in
13:17:09 <johnthetubaguy> #info main focus is likely policy docs, please review the spec: https://review.openstack.org/#/c/433010/
13:17:38 <johnthetubaguy> for extra context, there is a POC here: https://review.openstack.org/#/c/434842/
13:17:46 <johnthetubaguy> #link POC for policy docs: https://review.openstack.org/#/c/434842/
13:18:02 <johnthetubaguy> there is a POC for the scope work, which is way more confusing
13:18:23 <johnthetubaguy> #link POC for policy scope here: https://review.openstack.org/#/c/435485/
13:18:30 <alex_xu> I remember we talk about deprecation personality? that should be a simple microversion? if yes, I can take that
13:18:44 <johnthetubaguy> #link spec for policy scope work here: https://review.openstack.org/#/c/433037
13:19:06 <johnthetubaguy> alex_xu: good point, that needs a spec doing
13:19:15 <johnthetubaguy> alex_xu: I think mriedem was going to take that
13:19:23 <johnthetubaguy> worth asking him
13:19:35 <alex_xu> johnthetubaguy: ok, cool, i will check with thm
13:19:41 <alex_xu> s/thm/him
13:20:43 <johnthetubaguy> thats all I have for sure
13:20:44 <alex_xu> johnthetubaguy: thanks for the link
13:21:18 <johnthetubaguy> I suppose quota changes are API related, and sdague is taking up that one with keystone
13:21:39 <johnthetubaguy> but its more a tracking/planning thing for us this cycle, I assume
13:21:47 <sdague> yeh
13:21:55 <johnthetubaguy> (well except the cells v2 related changes, but thats not really API as such)
13:22:16 <sdague> and fending off the folks that want to rip up current progress :)
13:23:19 <alex_xu> I guess we didn't have freeze timeline yet?
13:23:32 <johnthetubaguy> we didn't do timelines, thats true
13:24:31 <alex_xu> ok, that probably we come out later i guess
13:24:56 <alex_xu> I think we can move on
13:25:04 <alex_xu> #topic open
13:25:35 <alex_xu> #link https://review.openstack.org/409644
13:25:55 <alex_xu> bhagyashris: ^ have a patch to fix a strange value of rotation
13:26:20 <alex_xu> it is also a case we need to think about the question "microversion or not"
13:26:38 <johnthetubaguy> "Caveat: The last backup of an instance should be deleted by user explicitly."
13:26:39 <alex_xu> but I feel the backup API maybe a target we want to deprecate in the future?
13:26:44 <johnthetubaguy> I am not sure what that means
13:27:50 <johnthetubaguy> I think the question here is would we backport this change to all previous stable releases, well maybe.
13:29:23 <alex_xu> emm....not sure how to answer the question about would we backport this change
13:30:24 <johnthetubaguy> well, is it a bug fix we want to backport, with zero discoverability
13:30:31 <johnthetubaguy> ... maybe, I could go either way
13:30:58 <alex_xu> the backup API is something we can implement in the client with create_image API, so i wonder is anybody want to deprecate backup API?
13:32:45 <alex_xu> sdague: ^ any thought?
13:33:02 <johnthetubaguy> I think it was meant to eventually do differential snapshots, but I don't believe it does today
13:33:44 <johnthetubaguy> that caveat, I wonder if it means you can delete all old snapshots by passing in a value of zero?
13:33:45 <alex_xu> yes, it is entire snapshot
13:34:09 <johnthetubaguy> if thats the case, we might want to keep this, and just fix the code so it stops creating a new snapshot, and just deletes the old ones
13:34:58 <johnthetubaguy> FWIW, I think this is one of the rubbish APIs that were "inherited" from the old slicehost cloud API
13:35:11 <bhagyashris> yeah as  I have changed the rotation parameter from 0 to 1 then user will nedd to delete tha last backup explicity
13:35:27 <johnthetubaguy> feels like we should just stop the code creating the extra snapshot then
13:35:28 <bhagyashris> s/nedd/need
13:35:32 <johnthetubaguy> would that fix the problem?
13:37:11 <alex_xu> emm...I also feel like that, just stop the code creating the extra snapshot
13:38:51 <johnthetubaguy> bhagyashris: I added a link to the two lines in the code you need to look at to skip creating the snapshot if rotation==0
13:39:15 <johnthetubaguy> bhagyashris: there are some niggles around upgrade that make it not quite that simple, but that shouldn't be too bad
13:39:30 <johnthetubaguy> s/niggles/problems/
13:40:01 <bhagyashris> ok.
13:41:38 <alex_xu> ok, bhagyashris if you feel good now, i think we can move on
13:42:31 <bhagyashris> yeah sure
13:42:44 <bhagyashris> thank you.
13:42:58 <alex_xu> np
13:43:32 * alex_xu just found that involve service min_version
13:43:41 <johnthetubaguy> yeah
13:44:02 <johnthetubaguy> only skip creating the snapshot, once all nova-compute nodes are upgraded
13:44:12 <johnthetubaguy> creating the snapshot record in glance, that is
13:44:35 <alex_xu> yea
13:45:22 <alex_xu> johnthetubaguy: so you want to keep the api behaviour consistent in upgrade?
13:46:22 <alex_xu> I feel it is fine just some nodes skip the snapshot, some nodes not.
13:46:22 <johnthetubaguy> well, its more about ensuring it works
13:46:33 <johnthetubaguy> if you don't create the snapshot, old compute nodes will fail backup
13:46:44 <johnthetubaguy> because they are still trying to upload the snapshot
13:46:45 <alex_xu> whatever all the snaphsot will be deleted finally, the result of API won't change
13:46:55 <johnthetubaguy> yeah, the API doesn't change
13:47:12 <johnthetubaguy> except there is no longer a snapshot that is created and deleted, but thats basically a noop
13:48:26 <alex_xu> ah, image created in the nova api
13:50:03 <alex_xu> I see now
13:50:31 <alex_xu> so...anything else we want to bring up?
13:50:43 <Kevin_Zheng> i have one
13:50:48 <Kevin_Zheng> https://review.openstack.org/#/c/423112
13:51:00 <Kevin_Zheng> Do we like this or not
13:51:02 <Kevin_Zheng> ?
13:51:41 <johnthetubaguy> it seems we implemented the spec just fine, but the DB can fit more in than the API
13:51:54 <johnthetubaguy> feels like we should keep 60 limit, let me check the API-WG spec
13:52:33 <alex_xu> I also feel it isn't worth a microversion
13:52:51 <Kevin_Zheng> If that's the case I will abandon this and do my other tags related bp with limit 60 :)
13:53:05 <johnthetubaguy> hmm, we should update the api-wg spec: https://specs.openstack.org/openstack/api-wg/guidelines/tags.html
13:53:12 <johnthetubaguy> it doesn't seem to mention max lenght
13:53:24 <johnthetubaguy> I don't think we should increase it really, unless we have a really good reason
13:53:26 <alex_xu> yes, it didn't metion it
13:53:35 * alex_xu add a todo for himself
13:54:02 <alex_xu> johnthetubaguy: +1
13:54:50 <Kevin_Zheng> I will update the API e.g.
13:54:57 <Kevin_Zheng> API wg
13:55:07 <alex_xu> Kevin_Zheng: cool
13:55:21 <alex_xu> so anything more?
13:55:34 <johnthetubaguy> just to be clear, we enforce the 60 character limit in the API right?
13:55:44 <johnthetubaguy> in the json schema I assume?
13:56:28 <alex_xu> yea, as i read, it is 60
13:56:31 <alex_xu> in schema
13:57:36 <alex_xu> I guess Kevin_Zheng just drop the network
13:58:12 <alex_xu> ok, 3 mins, I guess no more will bring up
13:58:33 <alex_xu> thanks all!
13:58:35 <alex_xu> #endmeeting