13:00:03 #startmeeting nova api 13:00:04 Meeting started Wed Oct 18 13:00:03 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:05 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 13:00:08 The meeting name has been set to 'nova_api' 13:00:13 who is here today? 13:00:14 o/ 13:00:19 o/ 13:00:51 #topic specs 13:01:10 #link https://review.openstack.org/508101 13:01:18 gmann: how was that? 13:01:59 yea, i am still not sure about instance_name attr - https://review.openstack.org/#/c/508101/5/specs/queens/approved/api-extensions-policy-removal.rst@91 13:02:01 #link https://review.openstack.org/#/c/508101/5/specs/queens/approved/api-extensions-policy-removal.rst@91 13:02:02 looks like a -1 from jichenjc 13:02:24 because of OS-EXT-SRV-ATTR:instance_name 13:02:39 should we consider this admin related and keep the policy for this 13:03:02 may be you know the background as you remembered it was for ec2 13:05:44 sdague: johnthetubaguy any feedback on 'OS-EXT-SRV-ATTR:instance_name' ? 13:05:56 #link https://review.openstack.org/#/c/508101/5/specs/queens/approved/api-extensions-policy-removal.rst@91 13:07:00 what is it again? 13:07:47 johnthetubaguy: in this spec, i am proposing the deprecation of few policy which are related to extensions as discussed in PTG 13:07:49 #link v 13:07:53 #link https://review.openstack.org/508101 13:07:55 actually, I see, the API docs say it should be for admins only, that makes sense I guess 13:08:16 "OS-EXT-SRV-ATTR:instance_name": "instance-00000001", 13:08:21 is the example in the API docs 13:08:28 so that policy control many other attribute also like user_data which does not seems admin one 13:08:29 that is of no use to an end user really 13:08:37 ah, it is the name store in the libvirt xml 13:08:54 yeah, its the name shown in the underlying hypervisor 13:09:10 ok 13:09:17 user_data is just really big, I suspect thats what it wasn't returned 13:09:25 johnthetubaguy: i see 13:09:36 i remember of seeing that name with virsh list 13:10:10 I remember someone filed bug about show the user_data for the normal user 13:12:05 ok, 13:12:31 emm...I can't find that bug 13:12:33 I really worry about exposing new things all of a sudden, I wasn't in that PTG discussion I guess, so not sure on the context 13:12:43 johnthetubaguy: alex_xu should we keep all attribute listed @91 as it is. i mean no change in policy ? 13:12:53 so there is a whole heap of deprecation's we should totally do 13:13:25 johnthetubaguy: main idea is to deprecate the policy which were more related to and added when api extensions were added 13:13:27 alex_xu: this one? https://bugs.launchpad.net/nova/+bug/1670978 13:13:28 Launchpad bug 1670978 in OpenStack Compute (nova) "most of extended server attributes returned in 2.3 api versions should not require admin role" [Wishlist,In progress] - Assigned to jichenjc (jichenjc) 13:13:53 I think we need to work out how to make the policy change on those attributes, it almost feels like we should have a microversion for the change 13:13:58 johnthetubaguy: for example polucy 'os_compute_api:os-extended-availability-zone' @70 13:14:17 takashin: thanks 13:14:37 johnthetubaguy: microversion for policy change? 13:15:03 depends how you look at this, to 90% of the people using our API we are adding new attributes 13:15:22 how did instance_name ever get into things? 13:15:54 I wonder why ec2 needs those 13:16:17 sdague: thats probably more to do with admins wanting to know what instance name to look at in their system 13:17:05 oh... ec2 uses instance-00000001 as its name, rather than the user one, back in the day 13:17:45 (...thinking back to when I was using euca tools because python-novaclient wasn't finished) 13:17:59 oh 13:18:17 gotcha, though that's weird given that it's not unique :) 13:18:19 oh, sorry, the 2.3 microversion is for ec2, but the name isn't in the list 13:18:48 oh, and you can break it by chaning your config 13:19:07 yea by CONF.instance_name_template 13:20:42 Just to baseline, I guess we all agree on dropping the crazy policies that default to allow, but just randomly kill parts of an ex-extension? 13:21:22 (by drop I mean deprecate...) 13:21:37 yea, default to allow all one are main candidates 13:21:46 yea by deprecation 13:22:28 so in that list in spec, only ''os_compute_api:os-extended-server-attributes'' is admin one only all other are default to all 13:22:50 i will remove this policy ('os_compute_api:os-extended-server-attributes') from proposal 13:23:46 ^^ is ok? 13:24:48 I think we keep that problem separate, while we think about the best way forward 13:24:56 (i.e. don't block the other good progress) 13:25:04 so +1 from me 13:25:11 yea 13:25:29 ll update spec tomorrow. 13:25:37 not sure johnthetubaguy and sdague is knowing the background, we want to keep the policy for the admin-only attributes since the admin may want to configure those attrs for other role like admin 13:25:59 does sound make sense? 13:26:09 yeah, we totally have to keep the admin policy either way 13:26:26 the question is about what attributes it applies (and if that changes depending on the microversion) 13:28:17 sure. let's target non 'admin only' first 13:29:12 johnthetubaguy: sdague alex_xu thanks for feedback 13:29:24 johnthetubaguy: sorry, the question is reference to the problem separation? 13:30:28 probably ignore that comment, just thinking about the admin-only instance_name and user_data 13:30:51 ah, i see 13:31:05 johnthetubaguy: thanks 13:32:00 gmann: fyi, tomorrow is the spec-freeze 13:32:31 alex_xu: :) yea, i can update this now quickly 13:32:32 last chance is probably the tomorrow night 13:32:55 ok...anything other spec people want to bring up? 13:33:16 gmann: thanks 13:33:28 nothing from my side. 13:34:00 nothing 13:34:23 ok, so I guess nothing for the open also 13:34:58 let us close the meeting, thanks all! 13:35:00 yea from me 13:35:03 alex_xu: thanks 13:35:07 #endmeeting