[katello-devel] initial stories for non-AR-search

[Bryan Kearney]

On 06/29/2011 06:41 AM, Amos Benari wrote:
>
>
> ----- Original Message -----
>> From: "Mike McCune"<mmccune at redhat.com>
>> To: "Partha Aji"<paji at redhat.com>
>> Cc: katello-devel at redhat.com
>> Sent: Tuesday, June 28, 2011 11:12:46 PM
>> Subject: Re: [katello-devel] initial stories for non-AR-search
>> On 06/28/2011 11:19 AM, Partha Aji wrote:
>>> On 06/28/2011 01:11 PM, Justin Sherrill wrote:
>>>> 1. As a user I want to find a package in a specific repository.
>>>> 2. As a user I want to find all the repos that contain a package.
>>>> 3. As a user I want to find all the products that uses a package.
>>>> 4. As a user I want to find all the environments that has a package
>>> Same as 1,2 3,4 + errata story but add "for a system" instead of
>>> repo
>>>
>>> Also for erratum based searches we want the search to be based of
>>> errata
>>> type (as in
>>> Bug/Enhancement/Security).
>>>
>>> *. As a user I want to find a package that is installed on a system.
>>> *. As a user I want to find a package that is not installed but
>>> available to be installed on a system.
>>> *. As a user I want to find updatable packages on a system.
>>
>> to me these are less of a search query but more just a standard API
>> query in itself. We should show the lists of:
>>
>> * updatable packages on a system.
>> * package that is not installed but available to be installed on a
>> system.
>> * packages that are installed on a system.
>>
>> but then allow search *within* the above results. I don't think it is
>> search's job to drive the initial set of results, just to filter them
>> after the fact.
>
> Having a search capabilities on (almost) every entity and entity relations as we have in Katello and Foreman,
> can result in a small and simple API, for example for the Package we could have:
>   * Package.search
> instead of:
>   * Package.get_by_repo
>   * Package.get_by_errata
>   * Package.get_by_system
>   * Package.get_by_available_for_system
>
> This definition makes the search mechanism more complicated to implement and define but I think it can be useful in both UI and API.
> I think I can implement such a search for Pulp in Katello by adding support for MongoDB in the search plugin and modeling the Pulp
> entities in Katello (without replicating the data itself).
> The API can then be something like /package?search={MongoDB-JSON-where-clause}.
>
> The main feature I would like to avoid in the search is joining several data-sources in a single query,
> because it will add considerable code and performance complexity, so I assume that at leased for the moment it is not needed.
>
> Thank you all for adding user stories.
> Comments on my API design ideas are also welcome :)
> Amos.


So... what would this look like for Candlepin then? How would I show 
systems with a fact X = Y?

-- bk