13:02:13 #startmeeting nova-api 13:02:14 Meeting started Wed Jul 27 13:02:13 2016 UTC and is due to finish in 60 minutes. The chair is sdague. Information about MeetBot at http://wiki.debian.org/MeetBot. 13:02:16 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 13:02:19 The meeting name has been set to 'nova_api' 13:02:31 #link https://wiki.openstack.org/wiki/Meetings/NovaAPI 13:02:39 o/ 13:03:21 o/ 13:03:22 ok, I'm still catching up on where things stand. Let's do this quickish. 13:03:29 #topic API priorities for Newton 13:03:56 #info API proxy deprecation landed as mv 2.236 13:04:01 #info API proxy deprecation landed as mv 2.36 13:04:17 great things :) 13:04:40 2.236 I thought I was transported to the future for a moment 13:04:51 we decided that we'd only land 2 more mv this cycle, get me a network as 2.37, and there is a bug fix for 2.38 that ed was working on 13:05:41 https://etherpad.openstack.org/p/nova-newton-midcycle @ L393 13:05:52 were all the notes from the mid cycle there 13:06:08 I started striking out things that are done 13:06:27 so we also have gmann_'s image ref fix - https://review.openstack.org/#/c/338802/ 13:06:54 gmann_: is that ready now? 13:07:09 its adding a microversion still 13:07:18 sdague: yea, i need to update that to make more changes, to remove more stuff on uuid fetch from url 13:07:24 ah, ok, we should get rid of that part 13:07:35 johnthetubaguy: i removed that but need more changes as we clean up this as bug 13:07:40 I think just landing the validation is worth while, we can follow up with the other bits 13:07:46 sdague: johnthetubaguy i will do that on tomorrow. 13:07:50 gmann_: sounds good 13:08:00 johnthetubaguy: ok, i am ok with that way also. 13:08:12 johnthetubaguy: or just wait till tomorrow :) 13:08:31 yup, getting it all tomorrow is cool :) 13:08:46 to follow on with the proxy item before, dansmith is working on the novaclient changes for the CLI, the first pass yesterday looked like a reasonable direction 13:08:46 yea, it will cleanup sample files also 13:08:58 https://review.openstack.org/#/c/347514/ 13:09:51 the last fully uncovered bit for the API this cycle is - https://review.openstack.org/#/c/324068/ 13:10:02 which is the user_id policy enforcement 13:10:31 jichen had some bug fix code around that early on, I'm hoping we can revive that and run with it. 13:10:34 sdague: 1 query on that, reboot is with user policy or without? 13:10:46 I think we said no 13:10:55 yeh, if it's not on that action list, then it's not 13:11:06 https://review.openstack.org/#/c/324068/3/specs/newton/approved/user_id_based_policy_enforcement.rst@63 13:11:31 sdague: humm but reboot can be destructive sometime when server does not come up on reboot 13:11:34 reboot is disruptive, it's not destructive 13:11:55 gmann_: so can many other options 13:12:12 we want to kill this 13:12:14 we're not trying to prevent every single way things can go wrong with servers 13:12:27 right... this is intentionally not a complete answer 13:12:28 so I think supporting the minimum level of stuff makes sense here 13:12:34 johnthetubaguy: ++ 13:12:59 yeah, sends the right, we are helping while we transition you to something better message 13:13:03 sdague: yea if all fine but if someone else reboot and something happens wrong then it destruct the other VM 13:13:15 gmann_: yep 13:13:36 thats intentional, its just a loose don't kill me separation 13:14:12 thing is, we could add reboot later, if that turns out to be the wrong place to put the line, but by that time we have a nice pattern, so it seems a good first stab at doing the minimum 13:14:16 gmann_: the problem with that logic is all of a sudden then you have to start adding back in interface management, security group management, etc 13:14:29 because all those things could make a server non responsive 13:14:38 sdague: +1 that list gets very big very quickly 13:14:47 and we specifically said, this is not a complete solution 13:14:55 sdague: ahhh, yea even console etc also 13:14:58 because we don't want people using this feature 13:15:14 hummm 13:15:22 I mean just doing it on delete is also another option, but I prefer this slightly more complete list 13:15:35 the operators that weighed in on this found this to be enough for their needs 13:15:43 right, thats the key bit 13:16:00 the folks who have bit worries felt happy with this list 13:16:01 johnthetubaguy: sdague i see the point now. 13:16:03 so, I think the list of actions is fixed 13:16:10 it's just about implementation now 13:16:17 and if more action on demand we can add later 13:16:43 gmann_: right, but we'll push back pretty hard 13:16:52 yes. 13:16:56 because, again, this isn't an operating model we want to support 13:17:06 sdague: johnthetubaguy cool, Thanks for clarification. 13:17:11 I have asked the OSIC folks if anyone wants to take this, but I might just leave that for the backport 13:17:22 johnthetubaguy: cool 13:17:55 ok 13:17:56 i can also help 13:18:29 johnthetubaguy: you mean backport part can be taken by OSIC folks? 13:18:35 gmann_: great, I've got my hands full on a few other things this week, so if you or anyone else can start in on the implementation, that would be great 13:18:49 gmann_: possibly, yes, at least I hope so 13:18:52 sdague: yea, i will start on that. 13:18:57 gmann_: thank you 13:19:13 johnthetubaguy: cool, i will start and then backport can be helped by them 13:19:19 gmann: sounds good 13:19:21 #action gmann_ to start on user_id policy patches 13:19:35 Thanks 13:21:22 ok, policy in code.... 13:21:38 are there any updates or needs there, that one I'm not on top of atm 13:22:09 I haven't checked with claudio yet either 13:22:33 ok 13:22:34 I think we agreed baby steps for next cycle, trying out a few existing operations to help the road to unblocking live-resize 13:22:53 right, mostly i was wondering if there is anything outstanding for newton we need to land 13:23:18 there is an entry point from alaski 13:23:40 and possibly the nova-manage stuff to check against a specific user for their policy 13:23:51 ok, do we have patches up? 13:24:12 there, were just hunting 13:24:37 https://review.openstack.org/#/q/topic:bp/discoverable-policy-cli,n,z 13:25:06 ok, great 13:25:09 https://review.openstack.org/#/c/335667/ 13:25:11 and some cli or tox env to generate the merged policy sample file with default and overridden rules 13:25:26 i remember we discussing the same in summit 13:25:37 #action please review https://review.openstack.org/#/q/topic:bp/discoverable-policy-cli,n,z 13:25:58 the last priority is api-ref - which we're now 75% done 13:26:13 the plan is to do a final api-ref sprint post freeze 13:26:34 so it doesn't distract during milestone 3 13:27:08 +1 13:27:16 sdague: so done for Newton RC? 13:27:20 sounds good 13:27:43 woodster_: yeh, more or less 13:27:58 because it's docs from master, it won't really be impacted by the freeze in the same way 13:28:13 sdague: nice 13:29:06 ok, I think that's about it on priorities 13:29:11 #topic Open Discussion 13:29:58 any further topics that people want to discuss? 13:30:09 1 i have 13:30:23 i am doing date-time strict checking in response schema o tempest side 13:30:25 https://review.openstack.org/#/c/304441/ 13:30:45 to make sure we use same format for that in all APIs 13:31:01 but seems like Image API have different format in header 13:31:14 this failure- http://logs.openstack.org/41/304441/2/check/gate-tempest-dsvm-full/ca98815/logs/testr_results.html.gz 13:31:15 the real image API, or our proxy? 13:31:23 ListImageFiltersTestJSON) tests 13:32:17 sdague: list image, on nova side i think but need to dig the code 13:32:18 * mriedem joins late 13:32:45 should we fix it in those are image API at are deprecated ? 13:32:50 at> etc 13:33:07 gmann_: well, honestly, we should probably make those tempest tests talk directly to glance instead of through Nova 13:33:30 I don't think fixing the image proxy is really a thing we should do here 13:33:54 sdague: yea, that's what my thinking 13:33:54 because it's likely to break people that depended on the old format, and it's deprecated 13:34:15 sdague: yea, we can loosen up the schema for that. 13:35:29 sdague: as you pointed, should we change all image API call to glance on tempest ? 13:35:45 sdague: mean no proxy API use in tempest 13:35:53 gmann_: I think long term Tempest needs to stop using proxy API calls 13:35:58 because those are actually going away 13:36:26 I don't know exactly how long that should be done over 13:36:41 sdague: humm. 13:36:48 yeah, its a trick one, but we need to move away from them 13:36:58 mtreinish brought up netwon-eol in the ML, but i don't think we want to wait that long 13:37:14 hmm, true 13:37:58 mriedem: ahh, because for stable branch they are not deprectaed? 13:38:20 gmann_: correct 13:38:21 I mean folks should have been deploying them for ages, but its not universally true I guess 13:38:51 if tempest.api.compute is calling volume or image proxies, i think that's a no brainer 13:38:54 to switch over 13:39:04 network gets trickier because nova-network wasn't deprecated until newton 13:39:11 mriedem: yeh, mostly image proxy is the one that gets used a lot 13:39:20 but, i thought the tests in tempest were pretty well conditional on neutron being available or not 13:39:22 true 13:39:49 i joined late, is there a bug or something? 13:40:10 gmann_ was trying to date validation schema in tempest 13:40:14 mriedem: not for that but we were discussing failure on date-time on https://review.openstack.org/#/c/304441/ 13:40:18 and the nova images proxy is inconsistent with the rest 13:40:25 yea 13:40:47 and I think, we should leave it as known issue, and just get tempest not using those interfaces 13:41:08 sdague: +1. 13:41:26 Makes sense 13:41:33 hmm, we won't detect schema changes in the proxies if we do that, which is probably ok for master, but i worry about stable, 13:41:35 however, 13:41:43 anything changing the api in stable is rare 13:41:50 right 13:42:13 mriedem: and that proxy API which deprecated and noted as critical bug fix only 13:42:28 yeh, I think we're probably safe 13:42:36 gmann_: well it's deprecated as of 2.36 13:42:54 anyway 13:44:04 ok, anything else from folks? 13:44:24 I am good, making some good progress 13:44:46 do we need to mention 2.36 on api-ref for proxy API ? 13:44:58 or just current warning is ok 13:45:37 gmann_: good point, we should probably update that as well 13:45:41 hmm, 2.36 would be more explicit 13:46:02 honestly, I'm not going to fully think about information design on that after the freeze 13:46:15 " Warning These APIs are proxy calls to the Image service. Nova has deprecated all the proxy APIs and users should use the native APIs instead. These will fail with a 404 after microversion 2.35. See: Relevant Image APIs. " 13:46:36 +1 13:46:58 Its tempting to leave all that till the doc sprint, but we do need something like that 13:47:28 I have a feeling we need some groupings in the doc, to make this all a bit clearer 13:47:41 johnthetubaguy: i can do quick update on this tomorrow 13:47:43 we have that in the rest api history doc 13:47:50 probably not leavign till doc sprint 13:47:53 i don't think we need to duplicate the rest api history doc in the api-ref 13:48:06 yeh, I think that strategic grouping of things in the api-ref is going to help here 13:48:08 but adding something to the warnigns in the api-ref that these will fail after 2.35 is probably good 13:48:11 actually, we might, its different readers 13:48:21 yeah, that bit 13:48:24 yea 13:48:35 i thought we were going to move all of the proxies to the bottom? 13:48:42 we did 13:48:44 mriedem: we did 13:48:46 can we just create a "Deprecated Proxy APIs" section? 13:48:55 mriedem: there are many things we could do 13:48:56 yeah, thats what I am thinking 13:49:01 or Deprecated APIs 13:49:10 but feels like we can doc sprint that, else we will get distracted 13:49:13 having all deprecated API 13:49:19 however, I think this is going to be a thing that is going to take trying 3 different things, seeing which is clearest 13:49:32 and is going to be 2 dedicated weeks of trying and getting opinions 13:49:38 which... we should do after freeze 13:50:11 my experience on the api-ref things is the idea you have in advance, turns out to be completely confusing when you see it on the screen 13:50:22 so you try a few things, and stare at them all 13:52:26 ok, anything else? 13:52:39 if not, lets get back to work :) 13:52:50 #endmeeting