[openstack-dev] Search Project - summit follow up

Oleg Gelbukh ogelbukh at mirantis.com
Fri Nov 22 10:04:20 UTC 2013


Dmitri,

If you intend to make this middleware generic and reusable between
different OpenStack services, your best shot, to my understanding, will be
to propose a new library in oslo-incubator.

--
Best regards,
Oleg Gelbukh


On Fri, Nov 22, 2013 at 4:05 AM, Dmitri Zimin(e) | StackStorm <
dz at stackstorm.com> wrote:

>
> On Wed, Nov 20, 2013 at 2:11 PM, Dolph Mathews <dolph.mathews at gmail.com>wrote:
>
>>
>> On Wed, Nov 20, 2013 at 1:06 PM, Dmitri Zimin(e) | StackStorm <
>> dz at stackstorm.com> wrote:
>>
>>> Thanks Terry for highlighting this:
>>>
>>> Yes, tenant isolation is the must. It's not reflected in the prototype -
>>> it queries Solr directly; but the proper implementation will go through the
>>> query API service, where ACL will be applied.
>>>
>>> UX folks are welcome to comment on expected queries.
>>>
>>> I think the key benefit of cross-resource index over querying DBs is
>>> that it saves the clients from implementing complex queries case by case,
>>> leaving flexibility to the user.
>>>
>>
>> I question the need for this service, as this service **should** very
>> much be dependent on the clients for this functionality. Expecting to query
>> backends directly must be a misunderstanding somewhere... Start with a
>> specification for filtering across all services and advocate for it on both
>> existing and new APIs.
>>
>
>
> Dolph, thanks for the suggestion: we will begin drafting the API on the
> wiki.
>
> Just to be clear: this is not filtering. Existing filtering APIs are
> [getting] sufficient. This is a full text search, which doesn't exist yet.
>
> SWIFT is now considering Search API, ideologically similar, but limited to
> Object Storage metadata [1]. Search middleware can make it generic and
> extensible. And yes, middleware may be a better term, as this is not a
> "service" like nova or cinder, but a layer on top.
>
> Do we need to clarify where search middleware shall live?
> Or do we question wether there is the need for search functionality?
>
> What else shall we do to make the discussion forward?
>
> [1]
> http://lists.openstack.org/pipermail/openstack-dev/2013-November/019014.html
>
>
>
>>> -- Dmitri.
>>>
>>>
>>>
>>>
>>> On Wed, Nov 20, 2013 at 2:27 AM, Thierry Carrez <thierry at openstack.org>wrote:
>>>
>>>> Dmitri Zimin(e) | StackStorm wrote:
>>>> > Hi Stackers,
>>>> >
>>>> > The project Search is a service providing fast full-text search for
>>>> > resources across OpenStack services.
>>>> > [...]
>>>>
>>>> At first glance this looks slightly scary from a security / tenant
>>>> isolation perspective. Most search results would be extremely
>>>> user-specific (and leaking data from one user to another would be
>>>> catastrophic), so the benefits of indexing (vs. querying DB) would be
>>>> very limited ?
>>>>
>>>> --
>>>> Thierry Carrez (ttx)
>>>>
>>>> _______________________________________________
>>>> OpenStack-dev mailing list
>>>> OpenStack-dev at lists.openstack.org
>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>
>>>
>>>
>>> _______________________________________________
>>> OpenStack-dev mailing list
>>> OpenStack-dev at lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>
>>
>> --
>>
>> -Dolph
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> 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/20131122/342a87b8/attachment.html>


More information about the OpenStack-dev mailing list