Open Stack

On 05/19/2017 05:10 PM, Matt Riedemann wrote:
> 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.

That was a fun conversation!

> 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.

I'd honestly like the contents you get from os-interfaces just always be 
returned as part of the server record. Having it as a second REST call 
isn't terribly helpful - if I need to make an additional call per 
server, I might as well just go call neutron. That way the only 
per-server query I really need to make is GET 
/ports.json?device_id={server_id} - since networks and subnets can be 
cached.

However, if I could do GET /servers/really-detailed or something and get 
/servers/detail + /os-interfaces in one go for all of the servers in my 
project, that would be an efficiency win.

> 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).
>