Open Stack

On 5/19/2017 3:35 PM, Monty Taylor wrote:
> Heck - while I'm on floating ips ... if you have some pre-existing 
> floating ips and you want to boot servers on them and you want to do 
> that in parallel, you can't. You can boot a server with a floating ip 
> that did not pre-exist if you get the port id of the fixed ip of the 
> server then pass that id to the floating ip create call. Of course, the 
> server doesn't return the port id in the server record, so at the very 
> least you need to make a GET /ports.json?device_id={server_id} call. Of 
> course what you REALLY need to find is the port_id of the ip of the 
> server that came from a subnet that has 'gateway_ip' defined, which is 
> even more fun since ips are associated with _networks_ on the server 
> record and not with subnets.

A few weeks ago I think we went down this rabbit hole in the nova 
channel, which led to this etherpad:

https://etherpad.openstack.org/p/nova-os-interfaces

It was really a discussion about the weird APIs that nova has and a lot 
of the time our first question is, "why does it return this, or that, or 
how is this consumed even?", at which point we put out the Monty signal.

During a seemingly unrelated forum session on integrating searchlight 
with nova-api, operators in the room were saying they wanted to see 
ports returned in the server response body, which I think Monty was also 
saying when we were going through that etherpad above.

This goes back to a common issue we/I have in nova which is we don't 
know who is using which APIs and how. The user survey isn't going to 
give us this data. Operators probably don't have this data, unless they 
are voicing it as API users themselves. But it would be really useful to 
know, which gaps are various tools in the ecosystem needing to overcome 
by making multiple API calls to possibly multiple services to get a 
clear picture to answer some question, and how can we fix that in a 
single place (maybe the compute API)? A backlog spec in nova could be a 
simple place to start, or just explaining the gaps in the mailing list 
(separate targeted thread of course).

-- 

Thanks,

Matt