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).
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
