On Tue, Jun 23, 2015 at 9:11 AM, Daniel DeLeo <
" target="_blank">
> wrote:
Yep, this is awesome. Would actually get rid of quite a few services in the erchef app.
--
Daniel DeLeo
On Monday, June 22, 2015 at 5:30 PM, Adam Jacob wrote:
> Super cool. I've thought about prototyping this - it would, obviously, be great to get rid of a component.
>
> Adam
>
> On Mon, Jun 22, 2015 at 5:27 PM, Jeremy Bingham < (mailto: )> wrote:
> > As some of you know, I've been working off and on for a while on a new way of handling chef search without needing solr, but that's more robust than the built-in goiardi ersatz solr I cooked up, using Postgres to handle the backend. I'm happy to say that there's at last a preview version available in goiardi now. To save space in this email, I'll just link the writeup of the preview that I did: http://goiardi.gl/blog/2015/06/22/postgres-search-in-preview/.
> >
> > There's more here than just announcing that a new goiardi feature is coming, though. While it may or may not be particularly useful for something like hosted Chef (because of issues with hitting Postgres even more than before), it may be useful as an option for standalone self-hosted Chef installations. The tables aren't particularly tied to goiardi at all (you can see them at https://github.com/ctdk/goiardi-schema/blob/pg-search/postgres/deploy/ltree.sql, https://github.com/ctdk/goiardi-schema/blob/pg-search/postgres/deploy/ltree_del_col.sql, and https://github.com/ctdk/goiardi-schema/blob/pg-search/postgres/deploy/ltree_del_item.sql), and I think Chef Server could use the same structure just fine.
> >
> > I thought I'd bring this to the attention of the greater Chef developer community and see what people thought about it, get comments on the implementation, and discuss plans to make it available to erchef if there's interest. The easiest way, probably, to use it with erchef is to make a standalone search program (like how I did a while back with a standalone universe endpoint that I snipped out of goiardi as a proof of concept), but I'm sure there are other ways. A standalone implementation would need to wait until these search changes are merged back into goiardi's 1.0.0-dev branch and for that branch to be finished, for multi-org support and to take advantage of the rewritten http multiplexer, so that's a downside. On the plus side the solr query parser in goiardi's already written.
> >
> > Thoughts? Is this something anyone would like to hear more about?
> >
> > -j
Archive powered by MHonArc 2.6.16.