*** shu-mutou-AFK is now known as shu-mutou | 00:18 | |
*** TravT has quit IRC | 00:44 | |
openstackgerrit | Rick Aulino proposed openstack/searchlight: Date field needed for get_version https://review.openstack.org/369835 | 00:56 |
---|---|---|
*** lei-zh has joined #openstack-searchlight | 01:39 | |
*** lei-zh has left #openstack-searchlight | 01:39 | |
*** Kevin_Zheng has joined #openstack-searchlight | 02:32 | |
openstackgerrit | Merged openstack/searchlight-ui: Update reno for stable/newton https://review.openstack.org/372688 | 02:34 |
*** david-lyle has quit IRC | 03:03 | |
*** GB21 has joined #openstack-searchlight | 04:56 | |
openstackgerrit | Rick Aulino proposed openstack/searchlight: Need to escape colons in query string https://review.openstack.org/369822 | 05:20 |
*** pcaruana has joined #openstack-searchlight | 06:50 | |
openstackgerrit | Rick Aulino proposed openstack/searchlight: Cinder mapping incorrect. https://review.openstack.org/372953 | 06:51 |
*** shu-mutou is now known as shu-mutou-AFK | 08:36 | |
*** alisha has joined #openstack-searchlight | 08:37 | |
*** RickA-HP_ has joined #openstack-searchlight | 09:57 | |
*** RickA-HP has quit IRC | 09:59 | |
*** GB21 has quit IRC | 11:55 | |
*** alisha has quit IRC | 12:23 | |
*** alisha has joined #openstack-searchlight | 12:24 | |
*** alisha has quit IRC | 12:36 | |
*** david-lyle has joined #openstack-searchlight | 12:56 | |
*** matt-borland has joined #openstack-searchlight | 13:28 | |
*** openstackstatus has joined #openstack-searchlight | 13:37 | |
*** ChanServ sets mode: +v openstackstatus | 13:37 | |
-openstackstatus- NOTICE: OpenStack Infra now has a Twitter bot, follow it at https://twitter.com/openstackinfra | 13:44 | |
*** TravT has joined #openstack-searchlight | 13:59 | |
*** TravT has quit IRC | 14:03 | |
*** sjmc7 has joined #openstack-searchlight | 14:04 | |
*** TravT has joined #openstack-searchlight | 14:06 | |
openstackgerrit | Yuriy Zveryanskyy proposed openstack/searchlight: Allow listener to process different priorities of notifications https://review.openstack.org/364461 | 14:07 |
openstackgerrit | Yuriy Zveryanskyy proposed openstack/searchlight: Searchlight ironic plugin https://review.openstack.org/364462 | 14:09 |
*** lcastell has left #openstack-searchlight | 15:21 | |
*** pcaruana has quit IRC | 17:14 | |
*** matt-borland has quit IRC | 17:30 | |
openstackgerrit | Merged openstack/searchlight: Cinder mapping incorrect. https://review.openstack.org/372953 | 17:33 |
openstackgerrit | Rick Aulino proposed openstack/searchlight: 'deleted_at' Date field needed for get_version https://review.openstack.org/369835 | 18:31 |
openstackgerrit | Rick Aulino proposed openstack/searchlight: 'deleted_at' Date field needed for get_version https://review.openstack.org/369835 | 18:36 |
*** matt-borland has joined #openstack-searchlight | 19:15 | |
matt-borland | sjmc7, following up on your question in https://review.openstack.org/#/c/367677/ | 20:00 |
sjmc7 | yarp | 20:00 |
sjmc7 | there may be a better way to do it, too. i made a naive assumption | 20:00 |
matt-borland | There are two sets of known facets...the facet 'definition' which is a complex object, and the 'current search' facets, which are just k/v pairs | 20:01 |
sjmc7 | right | 20:01 |
sjmc7 | searchlightFacet and facet respectively | 20:01 |
sjmc7 | although i didn’t realize that at the time | 20:01 |
matt-borland | cool. So what question did you have in the query-utils.service.js? | 20:01 |
sjmc7 | i need to get at the ‘nested’ attribute of the searchlightFacets | 20:02 |
matt-borland | oh, ok, yeah. | 20:02 |
sjmc7 | inside addBestGuessBoolQueryParamThisFunctionNameGoesOnForever | 20:02 |
matt-borland | you want this to be done early in lifecycle of loading/reloading any of the facet definitions | 20:03 |
matt-borland | is that right? | 20:03 |
sjmc7 | mmmm… i need to check it while building up the query | 20:03 |
sjmc7 | right now there’s a happy coincidence that if the name has a ‘.’ in it the UI can assume it’s a nested object | 20:03 |
sjmc7 | which wasn’t necessarily true before and definitely isn’t now | 20:04 |
matt-borland | yeah, that's not a great path forward :) | 20:04 |
matt-borland | oh, let me see | 20:04 |
sjmc7 | i don’t think it’s possible to do ti during the conversion to magicsearch facets | 20:05 |
matt-borland | yeah, they lose all context by that point | 20:05 |
matt-borland | they become very shallow k/vs | 20:05 |
matt-borland | there are a lot of problems if we try to make the data more complex I'm afraid | 20:06 |
matt-borland | due to limitations/assumptions throughout the code. | 20:07 |
matt-borland | it's a fundamental problem. | 20:07 |
sjmc7 | ok... | 20:07 |
sjmc7 | so maybe we should just remove access to nested facets? | 20:07 |
sjmc7 | this doesn’t seem like an unsolveable problem | 20:08 |
sjmc7 | can i create a map of name->nested/object/simple ? | 20:08 |
matt-borland | it's not unsolvable. I first need to understand the problem better. | 20:08 |
matt-borland | so what is an example of a nested query that we do now, for example? | 20:09 |
matt-borland | (or...would like to do) | 20:09 |
sjmc7 | server’s image.id | 20:09 |
matt-borland | ok, cool. | 20:10 |
matt-borland | It seems we should at worst be able to cross-reference the definition when processing something with the facet data (generating a query, etc.) | 20:10 |
sjmc7 | right | 20:10 |
matt-borland | OK, let me follow the code paths to find a good place to insert that. | 20:10 |
matt-borland | So the idea is that the object that is used in the SL query has this 'nested' member with appropriate data? | 20:11 |
matt-borland | eesh, yeah, all that information right now is just hanging out on the magic-search controller...not immediately accessible to the code path that does this query generation. :( | 20:17 |
matt-borland | I'll trace it back. | 20:17 |
matt-borland | yeah, there's no way to reference it other than to pass the contextual data (the facet definitions) along through the chain, which is search-table.controller/search() -> searchlightSearchHelper/search() -> searchlightQueryGenerator/generate() and some functions in that context. | 20:24 |
matt-borland | I'll double-check to see if they aren't passed in part of that way. | 20:24 |
matt-borland | There's still added complexity because of the limited exposure of the facets from the magic-search controller to the search-table controller :( | 20:25 |
sjmc7 | yeah, it seems pretty heavily separated. i don’t know the least-bad way of getting the information in | 20:56 |
matt-borland | The problem with magic search is that the scoping gets all inside-out. | 21:01 |
matt-borland | I think it is happily shielding us from what unfortunately we need | 21:02 |
matt-borland | I'll see if we expose it in a way that we can just make changes to SL-UI (not Horizon) | 21:02 |
matt-borland | A service that manages its state comes to mind, one that is injectable to the generator service. | 21:03 |
matt-borland | that would probably produce the least "pass this random data around" scenario, esp. since I believe we get our facet defs from the SL service essentially. | 21:04 |
matt-borland | maybe one of the existing services can do this already, or we can place information onto the state of the generator service. Not exactly pretty, but it might be reasonable. | 21:06 |
matt-borland | yeah, that's basically the approach I would suggest. Catch the state of the facet definitions as we retrieve them, then use them for reference on the way back out (in contruction of queries) | 21:11 |
matt-borland | there could be some minor timing issues, but I think that would work. | 21:12 |
openstackgerrit | Rick Aulino proposed openstack/searchlight: Do not index some Neutron ports. https://review.openstack.org/372781 | 21:20 |
*** matt-borland has quit IRC | 21:49 | |
openstackgerrit | Rick Aulino proposed openstack/searchlight: Security group rule race conidition https://review.openstack.org/355689 | 22:08 |
*** sjmc7 has quit IRC | 23:30 | |
*** Alexey_Abashkin_ has joined #openstack-searchlight | 23:45 | |
*** Alexey_Abashkin has quit IRC | 23:46 |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!