Tuesday, 2016-09-20

*** shu-mutou-AFK is now known as shu-mutou00:18
*** TravT has quit IRC00:44
openstackgerritRick Aulino proposed openstack/searchlight: Date field needed for get_version  https://review.openstack.org/36983500:56
*** lei-zh has joined #openstack-searchlight01:39
*** lei-zh has left #openstack-searchlight01:39
*** Kevin_Zheng has joined #openstack-searchlight02:32
openstackgerritMerged openstack/searchlight-ui: Update reno for stable/newton  https://review.openstack.org/37268802:34
*** david-lyle has quit IRC03:03
*** GB21 has joined #openstack-searchlight04:56
openstackgerritRick Aulino proposed openstack/searchlight: Need to escape colons in query string  https://review.openstack.org/36982205:20
*** pcaruana has joined #openstack-searchlight06:50
openstackgerritRick Aulino proposed openstack/searchlight: Cinder mapping incorrect.  https://review.openstack.org/37295306:51
*** shu-mutou is now known as shu-mutou-AFK08:36
*** alisha has joined #openstack-searchlight08:37
*** RickA-HP_ has joined #openstack-searchlight09:57
*** RickA-HP has quit IRC09:59
*** GB21 has quit IRC11:55
*** alisha has quit IRC12:23
*** alisha has joined #openstack-searchlight12:24
*** alisha has quit IRC12:36
*** david-lyle has joined #openstack-searchlight12:56
*** matt-borland has joined #openstack-searchlight13:28
*** openstackstatus has joined #openstack-searchlight13:37
*** ChanServ sets mode: +v openstackstatus13:37
-openstackstatus- NOTICE: OpenStack Infra now has a Twitter bot, follow it at https://twitter.com/openstackinfra13:44
*** TravT has joined #openstack-searchlight13:59
*** TravT has quit IRC14:03
*** sjmc7 has joined #openstack-searchlight14:04
*** TravT has joined #openstack-searchlight14:06
openstackgerritYuriy Zveryanskyy proposed openstack/searchlight: Allow listener to process different priorities of notifications  https://review.openstack.org/36446114:07
openstackgerritYuriy Zveryanskyy proposed openstack/searchlight: Searchlight ironic plugin  https://review.openstack.org/36446214:09
*** lcastell has left #openstack-searchlight15:21
*** pcaruana has quit IRC17:14
*** matt-borland has quit IRC17:30
openstackgerritMerged openstack/searchlight: Cinder mapping incorrect.  https://review.openstack.org/37295317:33
openstackgerritRick Aulino proposed openstack/searchlight: 'deleted_at' Date field needed for get_version  https://review.openstack.org/36983518:31
openstackgerritRick Aulino proposed openstack/searchlight: 'deleted_at' Date field needed for get_version  https://review.openstack.org/36983518:36
*** matt-borland has joined #openstack-searchlight19:15
matt-borlandsjmc7, following up on your question in https://review.openstack.org/#/c/367677/20:00
sjmc7yarp20:00
sjmc7there may be a better way to do it, too. i made a naive assumption20:00
matt-borlandThere are two sets of known facets...the facet 'definition' which is a complex object, and the 'current search' facets, which are just k/v pairs20:01
sjmc7right20:01
sjmc7searchlightFacet and facet respectively20:01
sjmc7although i didn’t realize that at the time20:01
matt-borlandcool.  So what question did you have in the query-utils.service.js?20:01
sjmc7i need to get at the ‘nested’ attribute of the searchlightFacets20:02
matt-borlandoh, ok, yeah.20:02
sjmc7inside addBestGuessBoolQueryParamThisFunctionNameGoesOnForever20:02
matt-borlandyou want this to be done early in lifecycle of loading/reloading any of the facet definitions20:03
matt-borlandis that right?20:03
sjmc7mmmm… i need to check it while building up the query20:03
sjmc7right now there’s a happy coincidence that if the name has a ‘.’ in it the UI can assume it’s a nested object20:03
sjmc7which wasn’t necessarily true before and definitely isn’t now20:04
matt-borlandyeah, that's not a great path forward :)20:04
matt-borlandoh, let me see20:04
sjmc7i don’t think it’s possible to do ti during the conversion to magicsearch facets20:05
matt-borlandyeah, they lose all context by that point20:05
matt-borlandthey become very shallow k/vs20:05
matt-borlandthere are a lot of problems if we try to make the data more complex I'm afraid20:06
matt-borlanddue to limitations/assumptions throughout the code.20:07
matt-borlandit's a fundamental problem.20:07
sjmc7ok...20:07
sjmc7so maybe we should just remove access to nested facets?20:07
sjmc7this doesn’t seem like an unsolveable problem20:08
sjmc7can i create a map of name->nested/object/simple ?20:08
matt-borlandit's not unsolvable.  I first need to understand the problem better.20:08
matt-borlandso 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
sjmc7server’s image.id20:09
matt-borlandok, cool.20:10
matt-borlandIt 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
sjmc7right20:10
matt-borlandOK, let me follow the code paths to find a good place to insert that.20:10
matt-borlandSo the idea is that the object that is used in the SL query has this 'nested' member with appropriate data?20:11
matt-borlandeesh, 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-borlandI'll trace it back.20:17
matt-borlandyeah, 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-borlandI'll double-check to see if they aren't passed in part of that way.20:24
matt-borlandThere's still added complexity because of the limited exposure of the facets from the magic-search controller to the search-table controller :(20:25
sjmc7yeah, it seems pretty heavily separated. i don’t know the least-bad way of getting the information in20:56
matt-borlandThe problem with magic search is that the scoping gets all inside-out.21:01
matt-borlandI think it is happily shielding us from what unfortunately we need21:02
matt-borlandI'll see if we expose it in a way that we can just make changes to SL-UI (not Horizon)21:02
matt-borlandA service that manages its state comes to mind, one that is injectable to the generator service.21:03
matt-borlandthat 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-borlandmaybe 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-borlandyeah, 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-borlandthere could be some minor timing issues, but I think that would work.21:12
openstackgerritRick Aulino proposed openstack/searchlight: Do not index some Neutron ports.  https://review.openstack.org/37278121:20
*** matt-borland has quit IRC21:49
openstackgerritRick Aulino proposed openstack/searchlight: Security group rule race conidition  https://review.openstack.org/35568922:08
*** sjmc7 has quit IRC23:30
*** Alexey_Abashkin_ has joined #openstack-searchlight23:45
*** Alexey_Abashkin has quit IRC23:46

Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!