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

[Amos Benari]

----- 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.

> 
> 
> > *. As a user I want to find an erratum that is applied on a system.
> > *. As a user I want to find an erratum that is not applied but
> > available to be applied on a system.
> > *. As a user I want to find updatable erratum on a system.
> 
> same thing as above, search should be able to find items within a
> general list as driven by the list query but it isn't the search
> itself
> doing the initial set.
> 
> >
> >
> > Similarly
> > * Find systems that have a given package
> > * Find systems that have a given product
> > * Find systems that have a given repo
> > * Find systems that have a given erratum
> 
> all the above would be awesome on the main system list, +1
> 
> 
> --
> Mike McCune
> mmccune AT redhat.com
> Red Hat Engineering | Portland, OR
> Systems Management | 650.254.4248
> 
> _______________________________________________
> katello-devel mailing list
> katello-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/katello-devel