On 05/21/2017 03:56 PM, Monty Taylor wrote:
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.

It seems you're asking us really to get rid of REST and implement a GraphQL API.


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

Reply via email to