 Okay. Hello, everybody. I'm Travis Tripp with Nikhil Kumawar as co-PTLs for Project Searchlight. And we are here today to provide an overview of Searchlight for the Liberty release. Nikhil, we'll start us off with some background. I'll cover a few of the Searchlight concepts before going into the Liberty priorities, and then Nikhil will finish things off. So with that, I'll turn it on over to you, Nikhil. Thanks, Travis. Hello, everyone. This is Nikhil. I will briefly discuss about some related developments that have in it, Nikhil. Next slide, please. Yes. So what are we trying to accomplish in this program? As you can see, we have advanced and scalable indexing and search capability planned across Multan and cloud resources. Next slide, please. So going to some of the background behind this accomplished mission, or you can call it our goal for this cycle, and possibly extend it in the future. So there have been a lot of interest and demand from operators and developers equal for a search provisioning within the OpenStack ecosystem. You may be aware about the new features that were introduced in plan, namely metadata artifacts. These are metadata-rich features, and they can really benefit by coexisting with such a service for better lookup of entities that they provide. Another reason behind this spin-off of Glance and other infrastructure services do not necessarily focus on the usability aspect. There can be a reason for bad usability experience due to either more number of queries, API calls, or those calls can be expensive from the perspective of usability. Next slide, please. Yes. So we started this goal in a slow and steady manner. We tried to do an experimental feature in Glance within the killer release timeframe. We were able to accomplish something called a catalog index service. So the reason we called it catalog index service was Glance supported some of the cataloging features, and then we wanted to accomplish better lookup and indexing of those entities. So as a stat, we provided indexing and search form images as well as metadata definitions, and they were backed by the elastic search backend. The search provisioning was given using a separate deployable optional endpoint. It was optional in DevSec so that people could experiment and figure out if they liked it. And it turned out to be a really popular feature. As you can see, we had a good number of contributors and reviewers, and seven different companies had participated in the same. Next slide, please. We had good discussions during the summit as well as in the get-it review. There were multiple requests, and some of the discussions led to the concept of spinning this off as a separate project, expanding its scope. So Travis had a great demo at the summit. You can find the link in the slide. So we had some discussions at the Glance as well as Horizon Fishwall sessions. There were some discussions with the NOVA PTO on being able to provide indexing for NOVA entities. So follow-up was a get-it review where the technical committee almost unanimously voted for this project, and we got it approved, and we are set to make some exciting developments in the reporting cycle. So I will let Travis go over some of the background concepts as well as the priorities for the committee. Thanks, Nikhil. You can go to the next slide. So let's start off by covering some of the ideas of what Searchlight provides. Across the OpenStack service APIs, you'll find varying degrees of consistency capabilities and performance when it comes to searching resources. With Searchlight, we want to provide the full power of Elasticsearch while also ensuring all the proper RBAC is in forest. You can go to the next slide. So Elasticsearch is based on Apache Lusine, and Searchlight is based on Elasticsearch. And this gives us a lot of query power with a lot of exciting features. So some of the more exciting features that we have is we're actually going to be able to do full text search on any OpenStack resource and on any attribute of that OpenStack resource that has been indexed in. This leads to being able to do search term fastening. So if I want to search on a very specific attribute with some very interesting queries like ranges or wild cards or other things, I'll be able to do that on any resource that's been indexed in. You also get things like search auto completion. So if I start typing a term, I might be able to do term completion or phrase completion. And those are things that are optionally enabled underneath the covers using Elasticsearch. We also have the ability to actually limit the properties we care about. So if you do a search and you only want to get back, say, five properties on, say, all the instances, you can say, I only want these five properties. One of the cool things is another thing called fuzzy search. So if you were to be looking for Fedora and you mistype it and say transpose that R and O, you can actually do fuzzy search and it would still return your results, giving you the proper results. And there's a more like this feature. So you can go to the next slide. Let's cover a little bit of the concept flow. So if we start down in the bottom right with your native cloud services like Nova and Glance, they have various resources like instances and images. We can index those in on demand into Searchlight using a plug-in mechanism that knows what to index that also includes the various RBAC properties or things that are needed to perform the RBAC needed. That gets stored into the underlying Elasticsearch cluster. Next, when Horizon and other clients want to come in and do listing and querying requests, they can send in a native Elasticsearch query string. This goes into Searchlight. The plug-ins ensure that that query string based off that type of resource being requested gets the appropriate filters to get your RBAC query into Elasticsearch to limit your results. And they also have the ability to filter data on the way back out if that's desired. Next if you want to actually deploy, say, an instance or instantiate instance, you still would go against your native, say, Nova API or your native cloud service API. And what happens is since we're listening for notifications, we will get updates and we'll keep that index as up-to-date as those notifications come in through the system. So if an instance is created, notification can be generated, which then is consumed by Searchlight, which will then index into the underlying data store. So let's go to the next slide. So when do you use it? Well, you can use it when it's there. It is optional. The idea is it's a per region endpoint deployment. It's listed in the service catalog under the search type. And when you're going to query and list your resources, you simply check to see is the search service available for the type of resource that you are carrying the query for. If it is, you use the search service. If not, you can use a standard API. And our goal is to provide results objects that will be as similar as possible if not the same as the standard API results. So then you can display and use those results accordingly. Okay, next slide. Okay, so what's coming next? Jump on to the next slide. So for Liberty, we've been working on completing the separation from Glance. The whole project is set up. All the other associated systems are set up now. So there is an actual project, repo, everything's imported into OpenStack. We're working on various deployment options, manual and DevStack. Both of those we already have working in their initial phases. We're finishing out Glance image and metadata definition indexing. We're starting work on NOVA indexing of instances, flavors and metadata. And we are looking into the initial integration with Horizon. So with that, we'll be looking at being able to optionally enable searching within Horizon for the images table, the instances table, but also potentially in other interesting ways across Horizon. We're looking to improve the testing that came out of Glance under the previous feature in Glance as well as improving the documentation. Next slide. We have some additional blueprints underway. Designate plugin is being developed now. It's got some very nice progress. We're doing some investigation into Neutron for what it would mean to index that as well as Swift metadata. Another interesting concept that we're investigating is the ability to have the plugins define their own named queries. So of course we want to give the full power of Elasticsearch, but we also recognize that you may want to get the benefits of Elasticsearch at speed and some of the power without having to know the full query language. So we're investigating ways that that could be incorporated that the plugins could advertise pre-established named queries for quick querying. Next. And speaking of the plugins, we're looking to really make that pattern more established. So there's things that we are looking into like handling API versioning across the services, how to properly do plugin configuration for each plugin, and other best practices that can come from the plugin framework, which is, by the way, based off of Stevedor. So I think we can go to the next slide and I think I'll turn it back over to you, Nikhil. Thanks Travis. So we, as you have already seen that we have spun off a new project. We have contributors who were interested in developing this under glance, but we have still seen enough number of interest as a separate project. Three different companies are participating. Twelve cores are existing in the credit group at the moment. And we are looking for interested folks. So if you are, if you want to join us or if you are interested in becoming core or a driver, the following slide has some information. Next slide please. So you can send an email to the open sector mailing list. The tag is search slide. You can always join us on IRC on OpenStack app and search slide. Or you can join us in any of the meetings. Next slide please. Thank you. Yes, thank you very much.