Open Stack

I'm glad this is getting some attention; it creates a visible bug in
Horizon that hurts the UX. (I'm adding the horizon category to this.)

But it sounds like Option 1 would potentially return a huge number of
instances. There's nothing to stop the user from asking for all starting
with "9". The UI could prevent it, but it really should be avoided in the
API. So I would vote for an option that honors the limit.


Randy Bertram

Vishvananda Ishaya <vishvananda at gmail.com> wrote on 01/28/2015 12:32:16 PM:

> From: Vishvananda Ishaya <vishvananda at gmail.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> Date: 01/28/15 12:38 PM
> Subject: Re: [openstack-dev] [nova] [api] Get servers with limit and
> IP address filter
>
> On Jan 28, 2015, at 7:05 AM, Steven Kaufer <kaufer at us.ibm.com> wrote:
>
> Vishvananda Ishaya <vishvananda at gmail.com> wrote on 01/27/2015 04:29:50
PM:
>
> > From: Vishvananda Ishaya <vishvananda at gmail.com>
> > To: "OpenStack Development Mailing List (not for usage questions)"
> > <openstack-dev at lists.openstack.org>
> > Date: 01/27/2015 04:32 PM
> > Subject: Re: [openstack-dev] [nova] [api] Get servers with limit and
> > IP address filter
> >
> > The network info for an instance is cached as a blob of data
> > (neutron has the canonical version in most installs), so it isn’t
> > particularly easy to do at the database layer. You would likely need
> > a pretty complex stored procedure to do it accurately.
> >
> > Vish
>
> Vish,
>
> Thanks for the reply.
>
> I agree with your point about the difficultly in accurately querying
> the blob of data; however, IMHO, the complexity this fix does not
> preclude the current behavior as being classified as a bug.
>
> With that in mind, I was wondering if anyone in the community has
> any thoughts on if the current behavior is considered a bug?
>
> Yes it should be classified as a bug.
>
> If so, how should it be resolved? A couple options that I could think of:
>
> 1. Disallow the combination of using both a limit and an IP address
> filter by raising an error.
>
> I think this is the simplest solution.
>
> Vish
>
> 2. Workaround the problem by removing the limit from the DB query
> and then manually limiting the list of servers (after manually
> applying the IP address filter).
> 3. Break up the query so that the server UUIDs that match the IP
> filter are retrieved first and then used as a UUID DB filter. As far
> as I can tell, this type of solution was originally implemented but
> the network query was deemed to expensive [1]. Is there a less
> expensive method to determine the UUIDs (possibly querying the
> cached 'network_info' in the 'instance_info_caches' table)?
> 4. Figure out how to accurately query the blob of network info that
> is cached in the nova DB and apply the IP filter at the DB layer.
>
> [1]: https://review.openstack.org/#/c/131460/
>
> Thanks,
> Steven Kaufer
>
> >
> > On Jan 27, 2015, at 2:00 PM, Steven Kaufer <kaufer at us.ibm.com> wrote:
> >
> > Hello,
> >
> > When applying an IP address filter to a paginated servers query (eg,
> > supplying servers/detail?ip=192.168&limit=100), the IP address
> > filtering is only being applied against the non-filtered page of
> > servers that were retrieved from the DB; see [1].
> >
> > I believe that the IP address filtering should be done before the
> > limit is applied, returning up to <limit> servers that match the IP
> > address filter.  Currently, if the servers in the page of data
> > returned from the DB do not happen to match the IP address filter
> > (applied in the compute API), then no servers will be returned by
> > the REST API (even if there are servers that match the IP address
filter).
> >
> > This seems like a bug to me, shouldn't all filtering be done at
> the DB layer?
> >
> > [1]: https://github.com/openstack/nova/blob/master/nova/compute/
> > api.py#L2037-L2042
> >
> > Thanks,
> > Steven Kaufer
> >
__________________________________________________________________________
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
__________________________________________________________________________
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150128/071f87b4/attachment.html>