00:01:36 #startmeeting api wg 00:01:37 Meeting started Thu Nov 27 00:01:36 2014 UTC and is due to finish in 60 minutes. The chair is etoews. Information about MeetBot at http://wiki.debian.org/MeetBot. 00:01:38 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 00:01:40 The meeting name has been set to 'api_wg' 00:01:56 i just updated the agenda 00:02:08 #link https://wiki.openstack.org/wiki/Meetings/API-WG#Agenda 00:03:01 #topic voting 00:03:26 #link https://review.openstack.org/#/c/131358/ 00:03:51 I guess I should really update that one 00:03:57 i haven't had a chance to fully review that 00:04:05 i was kinda curious to see the next revision 00:04:06 can you tl;dr? 00:04:21 yea I'll get to that today my time and merge in the comments 00:04:57 what's the consensus? 00:04:57 I guess the only thing I'd like to really retain is that the voting %'s are based on who turns up to vote, not who is eligible to vote 00:05:16 I think that would make it easier to get things through at this stage (we can tighten things up later if we want to) 00:05:18 etoews: not sure i can tldr it well, there's a bunch of detail about how the process should work out. 00:05:48 cyeoh: that seems reasonable to me. 00:05:50 cyeoh: that makes sense, do we need some sort of minimum number for a quorum? 00:06:08 elmiko: i suggested 5 in the comments 00:06:24 cool, missed that one 00:06:35 if things look like they're going crazy with that being too small then we can always revisit... 00:07:28 i can envision it being an issue, but i feel like with the time frames involved for voting it won't be a huge deal. 00:07:38 does that minimum of 5 need to have a particular role? e.g. wg member, ptl, tc, etc. 00:08:03 etoews: honestly I think we should just go for speed for now, so no. those who are interested. 00:08:11 +1 00:08:13 it is all still marked as draft (I did merge that) 00:08:34 and the TC still has the final say on the document overall before we can get out of draft - so there is sanity checking 00:08:39 it seemed to me that the idea of creating a hierarchy would definitely need to be discussed 00:09:25 elmiko: I'm ok with the there being more processes once we have more of a document (say a 1.0) 00:10:00 cyeoh: agreed, i just noticed that even talking about "wg members" proved to be contentious 00:10:04 elmiko: in the current document we have two gates to the document coming out of draft. The TC and the PTL rep vote - but that's just on the document overall, not on a per patch basis which I thikn would be too small 00:10:19 so what happens in the case that the tc disagrees with some small detail of the guidelines? they veto publication and we fix small detail? 00:10:48 etoews: yea, I'd hope it would not go to a vote, that they'd just give us feedback ahead of time so we could fix 00:10:55 cyeoh: yea, after thinking about it more, i think the gate measures in place are good enough for what we are proposing, even if membership is wide open. 00:11:25 okay 00:12:14 so an action item for cyeoh to update it? 00:12:31 sure! 00:12:36 +1 00:12:57 #action cyeoh to update https://review.openstack.org/#/c/131358/ based on feedback 00:13:22 so for the record I am going to be pretty much out and uncontactable after 4th december until january. So after that point anyway should feel to update the patch if its not yet merged 00:13:46 s/anyway/anyone/ ??? 00:14:02 cyeoh: good to know 00:14:27 well anyone who is really interested (sorry, unfortunately unavoidable but I have to go in for some surgery and not sure of recovery time yet 00:14:48 no worries, and good luck =) 00:14:52 thx! 00:15:07 cyeoh: youch. all the best. 00:15:26 #topic APIImpact flag 00:15:38 #link https://review.openstack.org/#/q/status:open+AND+(message:ApiImpact+OR+message:APIImpact),n,z 00:15:57 looks like people are starting to use the APIImpact flag :) 00:16:03 yes :-) 00:16:15 yea, was gonna say it's a nice list 00:17:04 is there anything we should look at right now? 00:17:42 I think this one is worth a look: https://review.openstack.org/#/c/136487/ 00:18:20 its proposing another use of resource/action on a resource 00:18:42 we do this a bit already in Nova especially in /servers/ but my understanding is that its not really well liked (bit of a hack) 00:18:51 so I'm interested in what people think 00:19:10 yeah, actions are not good to have in URLs 00:19:33 bit of background - this is for remove a server from a server group 00:19:52 is the server a standalone resource? 00:19:54 miguelgrinberg: i thought actions were acceptable if they are accessing an api function? 00:19:55 I suggested DELETE /v2/fake/os-server-groups// instead 00:20:39 elmiko: acceptable by who? According to REST guidelines this is always bad. 00:20:45 DELETE seems more natural to me too 00:21:03 if the individual server has a URI, then send a DELETE to that guy, yes 00:21:18 miguelgrinberg: yes, we generally access server stuff through /servers 00:21:32 miguelgrinberg: in this case we're not deleting the server, just removing it from the server group 00:21:51 then send a PUT to the group 00:22:06 and include all the servers in the group minus the one you are removing 00:22:08 what is currently proposed in the spec is /v2/fake/os-server-groups//action 00:22:34 miguelgrinberg: a bit racey though isn't it? 00:22:35 I see that the URI ends with /action, that cannot be a URI of a group resource 00:22:48 is there additional metadata associated with the server's membership in the group? that would make it a proper resource. 00:23:33 stevelle: no a server is simply in the group or not 00:23:46 what stevelle suggests is always a viable option. Have a resource that maintains the membership of a server to a group, then DELETE that resource 00:24:02 cyeoh: that would generally support miguelgrinberg's suggestion it seems 00:24:15 miguelgrinberg: is that what a server_group_id is? 00:24:33 i mean isn't that what a server group id is? 00:24:58 you create through os-server-groups resource a server group which contains a list of server_ids 00:25:01 I need to look up the API docs, I can't find that in this patch 00:25:02 DELETE /v2/fake/os-server-groups// seems legitimate as well to me 00:25:27 the api docs for the rest of the ops would be a big help here 00:25:29 its a very specific statement about how to patch the server - group membership 00:25:40 miguelgrinberg: yea this is just a proposal to be able to remove a server from a group since that was not supported in the original impl 00:26:00 http://docs.openstack.org/api/openstack-compute/2/content/ext-os-server-groups.html 00:26:05 stevelle: maybe DELETE /v2/fake/os-server-groups//servers/ 00:26:24 etoews: also acceptable to me 00:26:40 cyeoh: what's in the "members" attribute in the response when you ask for a server group? 00:26:45 don't believe we have come to any convention on the topic of naming resources before identifying them in paths 00:26:55 is it URIs or IDs? 00:27:14 miguelgrinberg: id's - we only very very rarely have uris in nova 00:27:44 I think we need to separate our discussions into the practical and the forward looking. 00:28:05 If we talk about the best solution, then I would put URIs to group-membership resources in that list 00:28:11 then you can DELETE any of those 00:28:22 of course we'll have to figure out something else for the short term 00:28:35 more in line with current practices 00:28:43 note that ids refer to the servers ids (so we don't want to delete them) 00:29:00 cyeoh: yes, I understand that 00:29:31 i expect that currently you can't even refer to individual servers in a server group 00:29:47 i would expect to get a list of servers in a group at /v2/fake/os-server-groups//servers/ 00:30:27 etoews: yea, can't do that, only can get it through the members list 00:30:41 nuts 00:30:48 but I think I understand what you're saying now 00:31:10 so anyone I think it'd be nice if we can comment what the least-worst solution is for what we have now 00:31:17 (on the proposed spec) 00:31:17 the problem with /servers is that it doesn't give you the membership, we are still missing the concept of a group membership, which is what you may want to remove 00:31:28 right 00:31:34 yes, that makes sense 00:31:48 I think /action is the worst solution ;-) 00:32:04 but it is consistent with other things currently in place, correct? 00:32:25 we do use actions a lot on /servers 00:32:35 ah, I see, there is no /actions on server-groups yet 00:32:52 but I've heard a few people complain about it. Yea, nothing on server-groups yet so we can avoid it 00:32:59 the reboot action does not have a clear HTTP verb 00:33:08 so what do you think if the members list is sent in a PUT request without the server that needs to be removed? 00:33:28 miguelgrinberg: my first thought is potentially racey? 00:33:44 is this async? 00:33:44 someone adds one while someone deletes one? 00:33:47 it's also kind of painful for a client to code to 00:34:08 how bit are these groups normally? 00:34:12 *big 00:34:23 you can never just remove a server membership 00:34:30 you always need to know all the members 00:35:53 miguelgrinberg: I don't really know, I guess they could get pretty big. mostly just used for affinity at the moment I think, but either way I think only being able to set the group is awkward. and we won't support adding a server for a whiel 00:37:01 well, given the current state of things, editing the members list is the most restful option, without having to go into exposing URIs for memberships 00:37:26 and it leaves the door open to additions when they are implemented 00:38:05 is this members list paginated? 00:38:25 or is there ever a situation where you would get a partial list 00:38:31 don't know for sure, I doubt it 00:40:46 what do you think about having a /server-groups//servers/ resource? 00:40:59 that would be a membership resource, you can delete it to remove the membership 00:41:11 and if you query the /servers you get the list 00:41:20 miguelgrinberg, etoews: if you could put your suggestings on the spec I think that would help (otherwise its likely to get just approved as-is) 00:41:34 miguelgrinberg: I'd be ok with that. I think it heads in the right direction 00:41:40 miguelgrinberg: that option makes a lot of sense for me 00:41:43 cyeoh: okay, I'll comment on the spec 00:41:48 +1 00:42:14 my only (minor) concern is that it may look like you are deleting the server, not the membership 00:42:37 #action miguelgrinberg to comment on https://review.openstack.org/#/c/136487/ regarding restfully removing a server from a group 00:42:46 miguelgrinberg: what about your suggestion earlier of having a membership id that could be deleted? 00:42:57 i need to leave in a few minutes. can someone else end the meeting? 00:43:09 etoews: only you have the power to end the meeting :-( 00:43:22 that would be this, I'm just saying that having a URL in form /groups//servers/ may seem like it points to a server, while it points to a membership 00:43:43 ok, yea i could see that 00:43:52 still better than what's proposed 00:44:13 +1 00:44:17 instead of /servers/ it could be /server-memberships/ ? 00:44:34 ah, that would help 00:44:36 that at least makes it clearer 00:44:54 +1 00:45:08 +1 for good naming 00:45:08 or maybe its /group-memberships/ ? 00:45:15 (sorry for arriving late) 00:45:40 depends on the perspective... 00:45:49 adding /members/ is shorter and coincides with a glance v2 api 00:46:00 but I like the long form 00:46:01 at that point do you even need the "group-" part? 00:46:26 i'll stick around until 7 to end the meeting and just be late for my next thing. :P 00:46:28 yea the only thing that could be a member is a server anyway 00:47:17 seems clearly spelled out in the uri /groups//memberships/ 00:48:05 i'd prefer consistency with glance and use /members/ 00:48:05 these memberships are given when the group is created, correct? 00:48:24 miguelgrinberg: yes currently that is the only way 00:48:25 etoews: agreed 00:48:47 members is also consistent with what's in the json body 00:48:55 etoews: +1 00:49:00 +1 00:49:44 do we want to try another APIImpact or move on to api-wg proposals? 00:50:12 probably should move on, only 10mins left 00:50:14 other agenda items (if any) then circle back? 00:50:28 == stevelle 00:50:44 #topic Reviews 00:50:54 #link https://review.openstack.org/#/q/status:open+project:openstack/api-wg,n,z 00:51:11 #link https://review.openstack.org/#/c/133087/ 00:51:21 i just updated my proposal. 00:51:27 LGTM 00:51:28 initial feedback is positive 00:51:59 anyone care to bring up another one? 00:52:25 I added the async counterpart, if anyone cares to review: https://review.openstack.org/#/c/137490/ 00:53:45 miguelgrinberg: looks good to me 00:53:57 me too 00:54:04 miguelgrinberg: lgtm, one piece of whitespace aside 00:54:19 I think we should concetrate on simple statements, and get them merged asap. There's always going to be time to fine tune. 00:54:20 there's a bit of psuedo code in the paragraph 00:54:40 do we want to call it out with a slightly different format? 00:55:31 the only reason i ask is because in the first sentence it ends with the if statement but the next sentence starts with an if statement. 00:56:03 it's just a bit harder for me to parse 00:56:05 okay, I'll see if I can condense that, I tend to be wordy sometimes, to leave any possible ambiguity 00:56:13 etoews: yea I think things like pseudo code/ rationale should be formatted differently 00:57:20 miguelgrinberg: +1 00:57:39 okay, I'll reword, remove the whitespace and resubmit later today 00:58:06 #action miguelgrinberg to reword, remove the whitespace and resubmit https://review.openstack.org/#/c/137490/ 01:00:00 thanks everyone! 01:00:09 thank you, see you next time 01:00:19 etoews: thanks for chairing =) 01:00:19 have a good holiday weekend if it's a holiday weekend where you are. 01:00:26 likewise! 01:00:28 cheers 01:00:39 etoews: thanks! 01:00:55 have a good surgery if you're having surgery in the next couple of weeks. 01:01:08 +2! 01:01:16 seriously though cyeoh. all the best. 01:01:22 #endmeeting