[nova] nova spec show-server-group response format
Hi, guys The approved spec show-server-group had 2 options for response. 1. First one(current spec): "server": { "server_groups": [ # not cached "0b5d2c72-12cc-4ba6-a8d7-3ff5cc1d8cb8" ] } } related discuss: https://review.openstack.org/#/c/612255/11/specs/stein/approved/show-server-... digest: This decouple the current implementation of server groups then get a generic API. 2 Second one: "server": { "server_group": { "name": "groupA", "id": "0b5d2c72-12cc-4ba6-a8d7-3ff5cc1d8cb8" } related discuss: https://review.openstack.org/#/c/612255/4/specs/stein/approved/list-server-g... digest: people have tried to change the api to allow adding/removing servers to/from groups, but still not implement yet. we need align this for continuing this work. thanks. Reference: bp: https://blueprints.launchpad.net/nova/+spec/show-server-group spec: https://review.openstack.org/#/c/612255/13/specs/stein/approved/show-server-... code: https://review.openstack.org/#/c/621474/23 Regards Yongli He
This is coming up now because of my questions in the code review: https://review.openstack.org/#/c/621474/23/api-ref/source/parameters.yaml@58... On 2/25/2019 11:53 PM, yonglihe wrote:
The approved spec show-server-group had 2 options for response.
1. First one(current spec):
"server": { "server_groups": [ # not cached "0b5d2c72-12cc-4ba6-a8d7-3ff5cc1d8cb8" ] } }
related discuss: https://review.openstack.org/#/c/612255/11/specs/stein/approved/show-server-...
digest: This decouple the current implementation of server groups then get a generic API.
Jay pushed for this on the spec review because it future-proofs the API in case a server can ever be in more than one group (currently it cannot). When I was reviewing the code this was the first thing that confused me (before I knew about the discussion on the spec) because I knew that a server can only be in at most one server group, and I think showing a list is misleading to the user. Similarly, before 2.64 the os-server-groups API had a "policies" parameter which could only ever have exactly one entry in it, and in 2.64 that was changed to just be "policy" to reflect the actual usage. I don't think we're going to have support for servers in multiple groups anytime soon, so I personally don't think we need to future-proof the servers API response with a potentially misleading type (array) when we know the server can only ever be in one group. If we were to add multi-group support in the future, we could revisit this at the same time but I'm not holding my breath given previous attempts.
2 Second one:
"server": { "server_group": { "name": "groupA", "id": "0b5d2c72-12cc-4ba6-a8d7-3ff5cc1d8cb8" }
related discuss: https://review.openstack.org/#/c/612255/4/specs/stein/approved/list-server-g...
This is the format I think we should use since it shows the actual cardinality of server to group we support today. By the way, I also think we should return this for GET /server/{server_id} responses for servers in down cells: https://review.openstack.org/#/c/621474/23/nova/api/openstack/compute/views/... Since the group information is in the API DB there isn't much reason *not* to return that information in both the up and down cell cases.
digest: people have tried to change the api to allow adding/removing servers to/from groups, but still not implement yet.
we need align this for continuing this work. thanks.
Reference:
bp: https://blueprints.launchpad.net/nova/+spec/show-server-group
spec: https://review.openstack.org/#/c/612255/13/specs/stein/approved/show-server-...
-- Thanks, Matt
On 2/25/2019 11:53 PM, yonglihe wrote:
The approved spec show-server-group had 2 options for response.
1. First one(current spec):
"server": { "server_groups": [ # not cached "0b5d2c72-12cc-4ba6-a8d7-3ff5cc1d8cb8" ] } }
related discuss: https://review.openstack.org/#/c/612255/11/specs/stein/approved/show-server-...
digest: This decouple the current implementation of server groups then get a generic API.
Jay pushed for this on the spec review because it future-proofs the API in case a server can ever be in more than one group (currently it cannot). When I was reviewing the code this was the first thing that confused me (before I knew about the discussion on the spec) because I knew that a server can only be in at most one server group, and I think showing a list is misleading to the user. Similarly, before 2.64 the os-server-groups API had a "policies" parameter which could only ever have exactly one entry in it, and in 2.64 that was changed to just be "policy" to reflect the actual usage. I don't think we're going to have support for servers in multiple groups anytime soon, so I personally don't think we need to future-proof the servers API response with a potentially misleading type (array) when we know the server can only ever be in one group. If we were to add multi-group support in the future, we could revisit this at the same time but I'm not holding my breath given previous attempts.
Personally, I agree with Jay and think that going for the list is better. We know people have asked for multiple-group membership before, and we have existing warts in our APIs where we've had to convert from a singleton to a list, which are still ugly today.
2 Second one:
"server": { "server_group": { "name": "groupA", "id": "0b5d2c72-12cc-4ba6-a8d7-3ff5cc1d8cb8" }
related discuss: https://review.openstack.org/#/c/612255/4/specs/stein/approved/list-server-g...
This is the format I think we should use since it shows the actual cardinality of server to group we support today.
I totally get your reasoning for this, I just think that using a list for a thing that can only be one-long currently is a fairly common thing, and is worth the potential for minor confusion over the work required to maybe someday expand it to N. I don't feel overly strong about it and wouldn't spend much energy trying to convince people. If you (or others) feel strongly, then that's fine. --Dan
participants (3)
-
Dan Smith
-
Matt Riedemann
-
yonglihe