Open Stack

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@5869

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-group.rst@67
> 
> 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-group.rst@62

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/servers.py@203

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-group.rst
> 
> code: https://review.openstack.org/#/c/621474/23
> 


-- 

Thanks,

Matt