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