| openstackgerrit | Steve McLellan proposed openstack/searchlight-specs: WIP Cross-region search spec https://review.openstack.org/301227 | 00:06 |
|---|---|---|
| openstackgerrit | Merged openstack/searchlight: Zero Downtime Re-indexing Unit Tests. https://review.openstack.org/300203 | 00:12 |
| *** yingjun has joined #openstack-searchlight | 00:45 | |
| *** bpokorny has quit IRC | 01:02 | |
| *** RickA-HP has quit IRC | 01:11 | |
| openstackgerrit | Rick Aulino proposed openstack/searchlight: Zero Downtime Re-indexing Functional Tests. https://review.openstack.org/301990 | 01:20 |
| openstackgerrit | Merged openstack/searchlight: Listen to instance volume attach/detach events https://review.openstack.org/301943 | 01:34 |
| openstackgerrit | Li Yingjun proposed openstack/searchlight: Add region_name to service_credentials for devstack https://review.openstack.org/302495 | 02:11 |
| openstackgerrit | Merged openstack/searchlight-ui: Searchlight-ui devstack plugin https://review.openstack.org/301935 | 02:44 |
| openstackgerrit | Li Yingjun proposed openstack/searchlight: Hypervisor plugin https://review.openstack.org/297586 | 02:58 |
| openstackgerrit | Tin Lam proposed openstack/searchlight: Making searchlight-manage python-3 compatible https://review.openstack.org/300911 | 02:59 |
| *** openstackstatus has quit IRC | 03:01 | |
| *** khushbu_ has joined #openstack-searchlight | 03:07 | |
| *** khushbu_ has quit IRC | 03:34 | |
| *** khushbu_ has joined #openstack-searchlight | 03:44 | |
| *** khushbu_ has quit IRC | 04:20 | |
| *** TravT_ has joined #openstack-searchlight | 04:41 | |
| *** TravT has quit IRC | 04:43 | |
| *** GB21 has joined #openstack-searchlight | 05:00 | |
| *** ankur has quit IRC | 05:21 | |
| *** GB21 has quit IRC | 06:12 | |
| *** GB21 has joined #openstack-searchlight | 06:12 | |
| *** pcaruana has joined #openstack-searchlight | 06:26 | |
| *** GB21 has quit IRC | 06:26 | |
| *** GB21 has joined #openstack-searchlight | 06:28 | |
| *** GB21 has quit IRC | 06:44 | |
| *** GB21 has joined #openstack-searchlight | 06:44 | |
| *** GB21 has quit IRC | 06:51 | |
| *** GB21 has joined #openstack-searchlight | 06:54 | |
| *** GB21 has quit IRC | 07:02 | |
| *** GB21 has joined #openstack-searchlight | 07:03 | |
| *** khushbu_ has joined #openstack-searchlight | 07:10 | |
| *** GB21 has quit IRC | 07:16 | |
| *** khushbu_ has quit IRC | 07:22 | |
| *** GB21 has joined #openstack-searchlight | 07:29 | |
| *** GB21 has quit IRC | 07:37 | |
| *** GB21 has joined #openstack-searchlight | 08:26 | |
| *** openstackstatus has joined #openstack-searchlight | 08:29 | |
| *** ChanServ sets mode: +v openstackstatus | 08:29 | |
| -openstackstatus- NOTICE: jobs depending on npm are now working again | 08:34 | |
| *** khushbu has joined #openstack-searchlight | 08:54 | |
| *** khushbu has quit IRC | 09:32 | |
| *** yingjun has quit IRC | 09:36 | |
| *** yingjun has joined #openstack-searchlight | 09:36 | |
| *** yingjun has quit IRC | 09:41 | |
| *** akanksha_ has joined #openstack-searchlight | 10:01 | |
| *** GB21 has quit IRC | 10:28 | |
| *** GB21 has joined #openstack-searchlight | 10:31 | |
| *** GB21 has quit IRC | 10:49 | |
| *** GB21 has joined #openstack-searchlight | 10:50 | |
| *** khushbu has joined #openstack-searchlight | 10:57 | |
| *** khushbu has quit IRC | 11:12 | |
| *** GB21 has quit IRC | 11:21 | |
| tsufiev | hi, folks! | 11:49 |
| tsufiev | can SearchLight be used for the following task: | 11:49 |
| tsufiev | when the user wants to delete a tenant in Horizon, he is warned with a list of entities that are contained in that tenant, and if he confirms Delete operation, not only tenant is deleted, but also all the entities that were assigned to that tenant? | 11:50 |
| tsufiev | to me the case 'give me a list of things in a particular tenant and do it fast' looks to be perfectly aligned with SearchLight mission | 11:51 |
| tsufiev | but I'm much less confident about the deletion part | 11:51 |
| *** GB21 has joined #openstack-searchlight | 11:52 | |
| tsufiev | sjmc7, TravT_ ^^^ | 11:53 |
| *** jhesketh has joined #openstack-searchlight | 11:54 | |
| *** ChanServ changes topic to "OpenStack Searchlight - https://wiki.openstack.org/wiki/Searchlight" | 11:54 | |
| *** khushbu_ has joined #openstack-searchlight | 12:02 | |
| *** jhesketh has quit IRC | 12:07 | |
| *** jhesketh has joined #openstack-searchlight | 12:07 | |
| *** GB21 has quit IRC | 12:16 | |
| *** yingjun has joined #openstack-searchlight | 12:29 | |
| *** yingjun_ has joined #openstack-searchlight | 12:31 | |
| *** yingjun has quit IRC | 12:31 | |
| *** sigmavirus24_awa is now known as sigmavirus24 | 12:47 | |
| *** khushbu_ has quit IRC | 12:49 | |
| *** khushbu_ has joined #openstack-searchlight | 12:52 | |
| *** yingjun_ has quit IRC | 12:54 | |
| *** yingjun has joined #openstack-searchlight | 12:55 | |
| *** yingjun has quit IRC | 12:59 | |
| *** TravT_ has quit IRC | 13:10 | |
| *** TravT has joined #openstack-searchlight | 13:11 | |
| *** khushbu_ has quit IRC | 13:25 | |
| openstackgerrit | Rick Aulino proposed openstack/searchlight: Zero Downtime Re-indexing Functional Tests. https://review.openstack.org/301990 | 13:32 |
| *** khushbu_ has joined #openstack-searchlight | 13:35 | |
| openstackgerrit | Rick Aulino proposed openstack/searchlight: Zero Downtime Re-indexing Functional Tests. https://review.openstack.org/301990 | 13:52 |
| sjmc7 | hi tsufiev | 14:07 |
| sjmc7 | we can list all the things belonging to a tenant that we’re able to index. deletions would have to go to each service’s API but part of the actions registry work that matt borland and travis are working on would allow that kind of context sensitive action | 14:09 |
| *** RickA-HP has joined #openstack-searchlight | 14:25 | |
| tsufiev | sjmc7, hi! | 14:27 |
| tsufiev | yes, I was thinking about the registry stuff | 14:28 |
| *** yingjun has joined #openstack-searchlight | 14:28 | |
| TravT | hey tsufiev | 14:28 |
| TravT | sjmc7 has it right | 14:28 |
| TravT | that is one of the target use cases. | 14:29 |
| sjmc7 | that’s going on my resume | 14:29 |
| TravT | but even without the registered batch actions, you can see the things | 14:29 |
| tsufiev | TravT, can the context-sensitive action be triggered programmatically? | 14:29 |
| sjmc7 | deletion is interesting because there are some restrictions around ordering and i don’t know how we capture that | 14:29 |
| TravT | tsufiev, have you tried out searchlight at all yet? | 14:30 |
| tsufiev | now I'm ashamed :( | 14:30 |
| tsufiev | still in the backlog | 14:30 |
| TravT | a simple devstack install would let you try it | 14:30 |
| TravT | we actually even have a ui plugin for it now | 14:31 |
| TravT | that is devstack installable | 14:31 |
| TravT | i'd also be happy to do a hangout with you if that's easier | 14:31 |
| tsufiev | okay, I think the preparations are no more serious than pulling out a patch for code review | 14:31 |
| tsufiev | I'll do it | 14:31 |
| TravT | we have a local conf sample | 14:32 |
| TravT | speaking of which sjmc7, this can be approved now: https://review.openstack.org/#/c/301901/2/devstack/local.conf | 14:32 |
| sjmc7 | okey dokey. all the changes in the ui repo are there to support it? | 14:33 |
| TravT | yep | 14:33 |
| TravT | david and li approved it last night | 14:33 |
| TravT | tusfiev https://github.com/openstack/searchlight/tree/master/devstack | 14:33 |
| sjmc7 | ok. will test it shortly and +2 | 14:33 |
| TravT | there is a sample local.conf there. | 14:33 |
| tsufiev | TravT, thank you, going to look at it today-tomorrow | 14:34 |
| TravT | the only thing it is missing is this line: https://review.openstack.org/#/c/301901/2/devstack/local.conf | 14:34 |
| TravT | sounds good. | 14:34 |
| TravT | tsufiev, if you also want to try out the swift searching, that takes a couple extra manual steps | 14:34 |
| TravT | to get the middleware installed on swift for indexing | 14:35 |
| tsufiev | no, I'll omit Swift for the first time | 14:35 |
| TravT | sounds good | 14:35 |
| TravT | sjmc7, regarding the local.conf patch above | 14:39 |
| sjmc7 | yes…? | 14:41 |
| TravT | nevermind for now. | 14:43 |
| TravT | i'm gonna bring it up briefly in the meeting | 14:43 |
| *** khushbu_ has quit IRC | 14:43 | |
| sjmc7 | ok. regarding your note on https://review.openstack.org/#/c/298570/ - what changes are you expecting for a potential rc3? | 14:43 |
| *** sigmavirus24 is now known as sigmavirus24_awa | 14:55 | |
| *** sigmavirus24_awa is now known as sigmavirus24 | 14:55 | |
| TravT | Courtesy Searchlight meeting reminder in #openstack-meeting-4: lakshmiS, nikhil_k, rosmaita, TravT, david-lyle, sjmc7, abhijeetm, itisha, GB21, briancline, lei-zh, yingjun, RickA-HP | 15:00 |
| *** khushbu has joined #openstack-searchlight | 15:08 | |
| *** GB21 has joined #openstack-searchlight | 15:42 | |
| *** pcaruana has quit IRC | 15:53 | |
| *** lei-zh1 has joined #openstack-searchlight | 16:01 | |
| *** yingjun has quit IRC | 16:03 | |
| openstackgerrit | Lei Zhang proposed openstack/searchlight: Disable index refresh during data re-sync https://review.openstack.org/301996 | 16:04 |
| openstackgerrit | Steve McLellan proposed openstack/searchlight: Remove port.create.end handler from nova https://review.openstack.org/302918 | 16:06 |
| sjmc7 | TravT: 302918 is the patch for https://bugs.launchpad.net/searchlight/+bug/1567525 | 16:06 |
| openstack | Launchpad bug 1567525 in OpenStack Search (Searchlight) "port.create.end events are handled incorrectly by nova" [Critical,New] | 16:06 |
| sjmc7 | i have to run an errand i’ve been putting off for weeks, be back in a bit | 16:06 |
| *** lei-zh1 has left #openstack-searchlight | 16:07 | |
| *** lei-zh1 has joined #openstack-searchlight | 16:09 | |
| *** lei-zh1 has left #openstack-searchlight | 16:14 | |
| *** RickA-HP has quit IRC | 16:18 | |
| openstackgerrit | OpenStack Proposal Bot proposed openstack/searchlight: Updated from global requirements https://review.openstack.org/302888 | 16:24 |
| *** bpokorny has joined #openstack-searchlight | 16:29 | |
| *** david-lyle has quit IRC | 16:36 | |
| *** lakshmiS has joined #openstack-searchlight | 16:39 | |
| openstackgerrit | OpenStack Proposal Bot proposed openstack/searchlight: Updated from global requirements https://review.openstack.org/302888 | 16:46 |
| *** david-lyle has joined #openstack-searchlight | 17:06 | |
| *** pcaruana has joined #openstack-searchlight | 17:08 | |
| *** david-lyle has quit IRC | 17:11 | |
| *** david-lyle has joined #openstack-searchlight | 17:17 | |
| *** briancline has quit IRC | 17:18 | |
| TravT | lakshmiS: sjmc7 plugin output | 17:20 |
| TravT | https://bugs.launchpad.net/searchlight/+bug/1557778 | 17:20 |
| openstack | Launchpad bug 1557778 in OpenStack Search (Searchlight) "Plugin info api does not expose parent child relationships." [Undecided,New] - Assigned to Lakshmi N Sampath (lakshmi-sampath) | 17:20 |
| sjmc7 | lakshmiS’s comment is similar to what i had but includes grandchildren | 17:20 |
| lakshmiS | so what structure is useful for horizon to read? | 17:20 |
| sjmc7 | lakshmiS: you will also need the parent field mappings | 17:20 |
| *** briancline has joined #openstack-searchlight | 17:20 | |
| sjmc7 | zone_id, container_id etc | 17:20 |
| lakshmiS | sjmc7: the structure i had is complete tree and you had a flat strcuture | 17:21 |
| sjmc7 | right | 17:21 |
| lakshmiS | its not restriced by one level | 17:21 |
| sjmc7 | yeah, my slight preference was direct descendants but i’m not too fussed | 17:21 |
| TravT | well, i think just immediate parents and children might make more sense | 17:21 |
| sjmc7 | there’s some duplication with complete trees | 17:21 |
| sjmc7 | i.e container will exist twice | 17:21 |
| TravT | because you have to combine them anyway | 17:21 |
| sjmc7 | unless any children don’t exist at the top level | 17:22 |
| sjmc7 | which i think will complicate parsing | 17:22 |
| lakshmiS | thats right. there is no top level child | 17:22 |
| TravT | let's pretend OS::Swift::Account had another child | 17:22 |
| lakshmiS | it only exists once | 17:22 |
| TravT | OS::Swift::Container wouldn't know about it's siblings | 17:22 |
| sjmc7 | “children” would need to be a list in that model, also | 17:23 |
| TravT | so i think client has to build a tree structure by parsing everything anway? | 17:23 |
| lakshmiS | yes it need to be a list for that | 17:23 |
| sjmc7 | TravT: the obvious client use is to enumerate all plugins as you can now | 17:23 |
| *** david-lyle has quit IRC | 17:23 | |
| sjmc7 | and i think keeping that is useful without requiring tree parsing | 17:23 |
| sjmc7 | i.e. i don’t agree with introducing breaking behavior | 17:24 |
| lakshmiS | i am ok either way or we could include both based on input | 17:24 |
| openstackgerrit | OpenStack Proposal Bot proposed openstack/searchlight: Updated from global requirements https://review.openstack.org/302888 | 17:24 |
| TravT | sjmc7 i can't tell if you are agreeing with me or not | 17:25 |
| sjmc7 | i’m stating my preference: i think all plugins must exist at the top level | 17:25 |
| lakshmiS | i am actually inclined to do both since client can request in what is useful for them and we cant always predict that | 17:26 |
| TravT | oh, okay we were talking about a couple of different things | 17:26 |
| sjmc7 | whether we include multiple levels of grandchildren i prefer not, but not too bothered | 17:26 |
| TravT | i missed that aspect of Lakshmi's | 17:26 |
| lakshmiS | so what is the primary use case of this output? | 17:26 |
| TravT | i missed that lakshmi's moved to complete tree structure | 17:26 |
| *** akanksha_ has quit IRC | 17:27 | |
| TravT | i'll talk UI only for a moment | 17:27 |
| sjmc7 | ease of use should be the main concern | 17:27 |
| TravT | 1) I would like to come up with a way for a general purpose way that people can do parent / child restriction queries | 17:28 |
| TravT | they can do this today in kind of a not so great way. | 17:28 |
| TravT | but really can only do has parent | 17:29 |
| TravT | by restricting on the parent id field | 17:29 |
| TravT | 2) i think there may be a way we could make the resource type structure navigable / learnable | 17:30 |
| TravT | i was talking with piet and another ux person the other day | 17:31 |
| TravT | about how to make things usable and learnable | 17:31 |
| sjmc7 | to people or machines? | 17:31 |
| TravT | people | 17:31 |
| sjmc7 | i think maybe it doesn’t make sense to do this if we don’t know what we want | 17:31 |
| sjmc7 | or rather, until we know what we want | 17:31 |
| TravT | am i not pointing out why i want it? | 17:31 |
| sjmc7 | you are pointing out you want something, but it’s much bigger than just the parent relationships | 17:32 |
| TravT | anyway | 17:32 |
| TravT | umm | 17:32 |
| sjmc7 | sorry, finish up | 17:32 |
| sjmc7 | i shouldn’t presume & interrupt | 17:32 |
| TravT | so let me go back to 1) then | 17:33 |
| TravT | i simply can not in the ui even think about creating a way to do parent child queries | 17:33 |
| TravT | because all it has is an id | 17:34 |
| TravT | no knowledge of even what that id type is | 17:34 |
| sjmc7 | yep. so i think we can solve that with exposing the parent/child relationships | 17:34 |
| TravT | which also relates to this: https://blueprints.launchpad.net/searchlight/+spec/disoverable-resource-type-mapping | 17:34 |
| sjmc7 | if it knows that RecordSet:’zone_id’ refers to Zone:id | 17:35 |
| TravT | on #2) | 17:35 |
| sjmc7 | yes - so that one the scope is much larger | 17:35 |
| sjmc7 | it’s more like exposing a subset of the mapping | 17:35 |
| TravT | one way of learning is being able to explore structure | 17:35 |
| sjmc7 | maybe we can solve 1) bearing 2) in mind | 17:36 |
| lakshmiS | my argument is that it is so easy to create output in both tree and flat; lets do it and leave the user/ui to use it the way it fits to the scenario | 17:36 |
| sjmc7 | well, wait - if we want to move to a point where the info includes that Server:image.id refers to OS::Glance::Image we can do the parent-child in the same way | 17:37 |
| sjmc7 | so perhaps not use “children” as the key, but “metadata” or something | 17:37 |
| sjmc7 | the fact it’s parent child is sort of a special case of that | 17:37 |
| TravT | yeah, that's also something I was thinking when I added that bp above | 17:38 |
| sjmc7 | but i do think we can add the parent-child links in first, and expand it later | 17:38 |
| sjmc7 | just bear the later stage in mind | 17:38 |
| TravT | so from a learning perspective | 17:39 |
| lakshmiS | the expansion can include a lot more fields for interlinking | 17:39 |
| TravT | a computer can easily assemble a tree from flat with just parent and child | 17:39 |
| TravT | a person can't | 17:39 |
| sjmc7 | our trees are not going to be more than 3 levels deep, i wouldn’t think | 17:40 |
| TravT | also, what we do with rbac? | 17:40 |
| TravT | is there a case where you can see a child, but not a parent? | 17:40 |
| sjmc7 | yeah, potentially | 17:41 |
| lakshmiS | hmm yes | 17:41 |
| sjmc7 | another reason i don’t like a full tree | 17:41 |
| lakshmiS | atleast not all the fields in parent | 17:41 |
| sjmc7 | it just seems to complicate stuff | 17:41 |
| lakshmiS | plugin info is only for structure right? | 17:41 |
| lakshmiS | rbac will still gets applied irrespecitve of that | 17:41 |
| lakshmiS | i dont see a reason for complication | 17:42 |
| sjmc7 | what if Snapshots are visible, Volumes are not? | 17:42 |
| lakshmiS | or maybe i am not understanding your point | 17:42 |
| lakshmiS | so what are we including in plugin info for volume | 17:44 |
| lakshmiS | other than index | 17:44 |
| sjmc7 | currently, you wouldn’t see Volume at all | 17:44 |
| lakshmiS | ah i see | 17:44 |
| sjmc7 | http://paste.openstack.org/show/F2UwFQ7GOWQvAMYy6IWN/ | 17:45 |
| sjmc7 | that’s what i mean with using metadata | 17:45 |
| sjmc7 | that could be expanded to include other relationships | 17:45 |
| lakshmiS | the scope has definetly expanded for plugin info | 17:45 |
| sjmc7 | and you could flip that for zone->recordset | 17:46 |
| sjmc7 | i think the only thing i’d be really firm on is that moving to a full tree is a breaking change | 17:46 |
| sjmc7 | and i would be very loathe to do that | 17:46 |
| lakshmiS | it depends on what fields you show in metadata | 17:47 |
| TravT | sjmc7: another option is to show that info in facets | 17:47 |
| sjmc7 | yep | 17:47 |
| sjmc7 | this is true | 17:47 |
| lakshmiS | if its only parentd id field, thats not something useful to user since they cant retrieve it | 17:47 |
| sjmc7 | not sure i understand | 17:48 |
| sjmc7 | lakshmiS: | 17:48 |
| sjmc7 | i think also we’re going to go round in circles forever :) if we can agree on the requirements at least, that might be a better start | 17:48 |
| lakshmiS | i mean from an rbac perspective even if volumes are not visible to the user, including parent id of volume in snapshot is not going to reveal anything that rbac would disallow | 17:49 |
| lakshmiS | it is going to be field name and not any value of the field | 17:49 |
| TravT | well, i have two things i know i'd like to do in the UI now. Easily restrict by parent (which is indirectly possible by guessing parent id field) | 17:50 |
| TravT | and be able to know how to handle resource id linkages | 17:51 |
| sjmc7 | ok | 17:51 |
| sjmc7 | so, given that, and that we don’t necessarily need to solve it in one step, that should influence the design | 17:51 |
| *** lakshmiS has quit IRC | 17:52 | |
| *** lakshmiS_ has joined #openstack-searchlight | 17:52 | |
| sjmc7 | perhaps we add explict parent/children, and then other linkages later; perhaps they’re similar enough that the separation isn’t so forced | 17:53 |
| TravT | you know | 17:54 |
| TravT | i'm thinking i could make the has parent in ui easier with just the metadata in facet... | 17:55 |
| *** david-lyle has joined #openstack-searchlight | 17:56 | |
| *** david-lyle has quit IRC | 17:56 | |
| lakshmiS_ | That's better than metadata in plugin info | 17:56 |
| sjmc7 | problem solved :) | 17:57 |
| *** david-lyle has joined #openstack-searchlight | 17:58 | |
| sjmc7 | so now the decision is how to indicate in the facet output that a field refers to another type, and that (in some cases) that type is the parent of this one | 17:59 |
| TravT | i think so, with one question on top of that | 17:59 |
| TravT | are facets too limiting | 18:00 |
| sjmc7 | :D | 18:00 |
| TravT | IOW, can i have resource IDs in fields that are not listed as facets? | 18:00 |
| TravT | my brain made an escape attempt due to lack of food energy | 18:00 |
| sjmc7 | yes. but arguably that shouldn’t be the case | 18:00 |
| TravT | i gotta run for lunch | 18:00 |
| sjmc7 | yeah, me too. i think putting those links in facets is reasonable | 18:01 |
| sjmc7 | what you will NOT get there is the ‘child’ links | 18:01 |
| TravT | that is very true... | 18:01 |
| sjmc7 | though i guess you could indicate that Zone.“id” refers to RecordSet | 18:01 |
| TravT | in my limited use with the ui, i haven't needed that yet | 18:01 |
| sjmc7 | you might if your ‘details’ included children | 18:02 |
| sjmc7 | “show me all subnets belonging to this network" | 18:02 |
| TravT | but it definitely seems like you would want to say, show me zones with x record | 18:02 |
| TravT | yeah | 18:02 |
| TravT | okay, let's come back on this after a little bit | 18:04 |
| khushbu | sjmc7: I have some queries related to this bug https://bugs.launchpad.net/searchlight/+bug/1526080 | 18:05 |
| openstack | Launchpad bug 1526080 in OpenStack Search (Searchlight) "'TypeError: format requires a mapping' from some error messages" [Medium,Incomplete] - Assigned to khushbu (khushbuparakh) | 18:05 |
| *** TravT has quit IRC | 18:06 | |
| sjmc7 | khushbu: shoot, although i am trying to squeeze in some food :) | 18:08 |
| sjmc7 | it’s possible this has been fixed by other changes since it was filed | 18:09 |
| sjmc7 | lot of water under the bridge since december | 18:10 |
| khushbu | so I am trying out to find the repo n I got this https://github.com/openstack/searchlight/blob/master/searchlight/elasticsearch/plugins/nova/servers_notification_handler.py with some error logs so we are facing type error in this file or some other | 18:10 |
| sjmc7 | i think this may have been fixed | 18:12 |
| sjmc7 | see https://github.com/openstack/searchlight/commit/faba34ddb88f05ed12478a07d04b074a76452195 (scroll down to servers_notification_handler.py) | 18:12 |
| sjmc7 | some of the log messages were altered as part of that patch | 18:12 |
| khushbu | ok | 18:18 |
| sjmc7 | thanks for looking at it, sorry it was a red herring :( | 18:18 |
| khushbu | So one should mark it as complete | 18:19 |
| sjmc7 | yeah, i’ll close it | 18:19 |
| khushbu | Thanks for help | 18:20 |
| *** TravT has joined #openstack-searchlight | 18:42 | |
| *** GB21 has quit IRC | 19:03 | |
| *** nikhil has quit IRC | 19:07 | |
| *** nikhil has joined #openstack-searchlight | 19:11 | |
| *** david-lyle_ has joined #openstack-searchlight | 19:13 | |
| *** david-lyle has quit IRC | 19:15 | |
| *** sigmavirus24 is now known as sigmavirus24_awa | 19:17 | |
| *** david-lyle_ has quit IRC | 19:19 | |
| *** bpokorny_ has joined #openstack-searchlight | 19:23 | |
| *** briancline has quit IRC | 19:24 | |
| *** briancline has joined #openstack-searchlight | 19:25 | |
| *** bpokorny has quit IRC | 19:26 | |
| *** david-lyle has joined #openstack-searchlight | 19:29 | |
| *** david-lyle has quit IRC | 19:31 | |
| *** david-lyle has joined #openstack-searchlight | 19:31 | |
| *** khushbu has quit IRC | 19:32 | |
| *** david-lyle has quit IRC | 19:37 | |
| *** TravT has quit IRC | 19:39 | |
| *** bpokorny_ has quit IRC | 19:40 | |
| *** bpokorny has joined #openstack-searchlight | 19:41 | |
| *** bpokorny has quit IRC | 19:52 | |
| *** bpokorny has joined #openstack-searchlight | 19:53 | |
| *** lakshmiS has joined #openstack-searchlight | 20:07 | |
| *** bpokorny has quit IRC | 20:16 | |
| *** lakshmiS_ has quit IRC | 20:54 | |
| *** david-lyle has joined #openstack-searchlight | 20:56 | |
| *** pcaruana has quit IRC | 21:01 | |
| *** bpokorny has joined #openstack-searchlight | 21:02 | |
| *** bpokorny has quit IRC | 21:25 | |
| *** bpokorny has joined #openstack-searchlight | 21:26 | |
| *** bpokorny_ has joined #openstack-searchlight | 22:01 | |
| *** bpokorny_ has quit IRC | 22:01 | |
| *** bpokorny_ has joined #openstack-searchlight | 22:02 | |
| *** bpokorny has quit IRC | 22:04 | |
| *** briancline has quit IRC | 22:14 | |
| *** RickA-HP has joined #openstack-searchlight | 22:17 | |
| *** briancline has joined #openstack-searchlight | 22:17 | |
| *** briancline has quit IRC | 22:25 | |
| *** briancline has joined #openstack-searchlight | 22:27 | |
| *** lakshmiS has quit IRC | 22:46 | |
| *** briancline has quit IRC | 22:46 | |
| *** briancline has joined #openstack-searchlight | 22:52 | |
| *** briancline has quit IRC | 23:02 | |
| *** briancline has joined #openstack-searchlight | 23:07 | |
| *** briancline has quit IRC | 23:22 | |
| *** briancline has joined #openstack-searchlight | 23:25 | |
| *** briancline has quit IRC | 23:34 | |
| *** briancline has joined #openstack-searchlight | 23:38 | |
| *** bpokorny has joined #openstack-searchlight | 23:40 | |
| *** bpokorny_ has quit IRC | 23:40 | |
| *** bpokorny has quit IRC | 23:46 | |
| *** bpokorny has joined #openstack-searchlight | 23:47 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!