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:


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

OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

Reply via email to