 Good morning, welcome. In this presentation, we'll be presenting a quick overview of an ideation that we have, the architecture, and more about a deep dive of the architecture, the use cases that we have, and how it can enable our enterprise customers and different other users to use this application, service sentinel, and use the use cases. I am Partha. I lead the solution development for next generation technologies in open source communities. We are active contributors to OpenStack, Open Daylight, and OpenWaySwitch. Along with me, I have Swati. Hello. Hello. A very good morning to all of you. I'm Swati, and I am a solution architect from TCS. I'm working on OpenStack. So our today's topic for discussion is service sentinel. This is basically a mobile application that deals with the critical OpenStack operations for the OpenStack users on the go. So to provide a heads up, what we have for you today is in the first section, we are going to show you what are the day to day operations of OpenStack, and what are the OpenStack users still missing. So we'll draw an insight into what is still there in OpenStack that are still not supported for the users while mobile. In the second section, we will take a deep dive into the viable service sentinel use cases, the technical architecture that it covers, along with the different dashboard it has for different kinds of OpenStack users. In the third section, we demo day in the life of a user, showcasing what are the key activities of OpenStack that can be performed via service sentinel for the OpenStack users. So to kick off, let's take a look at what are OpenStack users doing today. So a diverse variety of OpenStack users are working on tools. They are working on OpenStack frameworks, products, suites, and et cetera. Depending upon the kind of work that the users perform, they are primarily classified into three main categories. So as you all know, category A users will be the ones who are basically dealing with the infrastructure operations. They are performing different kinds of monitoring activities via different dashboards, OpenStack tools, et cetera. And these users are also dealing with the scaling request depending upon the criticality of the request. The infrastructure users are also responsible for the migration activities across sites, depending upon the thresholds of the resources. The second category of users that we have here are basically the ones who are dealing with the CI CD operations, that is the continuous integration and continuous development. So as per different release cycles, we have development activities, we have release management activities, and we have deployment tasks that have to be performed on different target holes. So DevOps user will be able to perform such tasks via our application. The third category of users we have in OpenStack are the general users. As the name suggests, these users are the ones who are using the services that are provided by different OpenStack service providers. By service providers, we mean here they are the business people or the enterprise-specific people who are responsible for planning, strategizing, different OpenStack product suits, and services. Moving to the next slide. We named category A users in Service Sentinel as a lab-infra-people. So as we just discussed, the lab-infra-people are the ones who are managing the monitoring activities, performing horizontal scaling, vertical scaling, and migration across sites. So there are certain key challenges that a lab-infra user faces today while on the go. He's not able to perform certain tasks, which are critical to him. For example, we have, can he actually monitor the various sites across locations on the go? Or can he monitor or address different kind of service requests or scaling requests while he's mobile? Or the third challenge for him can be if he wants to perform a scaling or migration activities while on the move. So these are the key challenges that a lab-infra user faces today. Moving to the next category of users, we call them as the DevOps users. As the name suggests, these people are the ones who are basically engaged in CI CD at TAS. So here also we have three main challenges that a DevOps user faces today. So can he actually monitor or trigger the different kinds of build requests of critical open stack bugs or blueprints while he's mobile? The second challenge for him is he wants to monitor different build processes, and on which tool the build process is happening right now. So there might be certain failures, and he wants to deep dive into the build process to check out where and all the root cause lies. This will enable a DevOps user to further take actions to resolve a particular issue. And the third challenge can be when he has to perform certain releases on the target host while on the move. So these are the key challenges for a DevOps user today. And coming to the last family of users in open stack, these are the general users. So here also we have certain challenges. As a general user, I want to be updated with certain activities of open stack services. I want to be updated with open stack vendors and categories of product suits that they provide. As a challenge, I have is when I want to request certain feature sets, or I want to order a product, open stack service, from vendor XYZ. So I want to, I should be able to do that from a mobile application itself. I want to see the list. I request for a particular open stack product and there you go. The second challenge can be when I feel like comparing the different open stack services that are provided by different open stack vendors. And I just want to fire an act to compare commands so that I can fetch out my results. The third key challenge can be when I am subscribed to certain open stack product features and I want to receive notifications for that particular product or a vendor. So this will also provide a win-win situation for a service provider because he can enable or keep the users abreast with the open stack services that are still going on today. Moving to the next slide. So boom, this gives a view of Service Sentinel. That is how an on-the-go user will be able to access the open stack critical operations on the go. This solution will enable all the open stack users to get rid of their main pain areas. And the modularity and extensibility of this application will make it interoperable to work with different enterprise tools as well. This is applicable, as we discussed, for the LabnPri user, the DevOps users, and the general users of open stack. Our final aim to achieve via Service Sentinel is to allow any time and anywhere access of the open stack critical operations on the go for any kind of open stack user. To summarize, we discussed about the different kinds of main-to-main day-to-day activities of Service Sentinel. So we now will do a deep dive into the top-level features of Service Sentinel. What are the key features that it provides today that makes it unique? The first one being on-the-go. That is, it allows any time and anywhere access of the open stack operations to the user. The second one being collaboration tools. That is, it can be made interoperable with various open stack collaboration tools as well. So today, various open stack tools are evolving, be it public, be it open source, be it proprietary, or there are certain licensed tool as well. So the extensibility of this application will enable it to interwork with tools via adapters. The third key feature setters, it is an extensible framework. What we mean by that is, it can be extended with existing enterprise solutions that are existing in today's world and which are otherwise only available via CLI or web-based interfaces. The fourth key feature setters, it can enable the services provided for the DevOps users and the lab and for people to carry out the mundane tasks. The fifth key feature setters, it can be enhanced for the general users as well so that they can use the services that are provided by the service providers of OpenStack. Last but not the least, this is customizable and deployable. That means it can be tailored and customized according to the needs of different enterprise networks. So to summarize, we have discussed about the day-to-day operations of OpenStack users, what are the users missing, what are the top-level features of Server Sentinel, and let's take a deep dive into the architecture of Server Sentinel. In Server Sentinel, we target three main use cases for the lab-infra users and they are the remote monitoring of data centers or sites across locations. The second one can be a lab-infra user will be able to perform scale-up and scale-down activities of the resources across locations depending upon certain KPIs. And the third one can be when a lab-infra user will be able to manually trigger the migration activities. So for example here, I can state this, in daytime the sites are used to the maximum potential. And in lean time hours, there is always a scope of reducing the power consumption. So a lab-infra user will be able to perform these migration tasks so that the VMs can be consolidated and can be used to the maximum potential via Server Sentinel. Below we have different dashboards that relate to different tasks and we will see that in the forthcoming demo. Moving to the next slide, before we deep dive into every use case of the OpenStack user, we will discuss in detail about the Server Sentinel framework and the high-level architectural overview. So here we have four main tiers specifically. The first tier being the presentation tier where the users can receive requests. The users can be lab-infra, the revops or the general users. And this presentation tier interacts with the northbound interface or the NBI layer through a certain REST APIs that we have written. The NBI layer consists of Sentinel-specific or vendor-specific APIs that perform the different tasks on the controller or the Sentinel-coliar. The Sentinel-coliar consists of various components that are targeted when a lab-infra user or a revops user, et cetera, perform certain kind of activity and we will discuss that in detail in the forthcoming demo. The next is the Sentinel agents tier. So here we have certain agents that are doing different kinds of jobs depending upon the activity. For example, we have the monitoring agent that is looking over to the monitoring task of hosts, VMs, resources, and so on. The second is the tool agent tier which is basically leveraging different kinds of open-stack tools or the third-party tools that are used for performing the tasks for the lab-infra or the revops user. The next one is the message broker that is being used to streamline the communication between the Sentinel-coliar and the base-level APIs. And the last one being the DB connector which is responsible to fire DB-specific commands on different vendor databases. Along with these agents, we have the lower API layer as well which consists of public APIs, private APIs, and third-party tool APIs. Now let's take a look at the deep-dive architecture for service Sentinel lab-infra users. As we discussed, the service Sentinel architecture will remain the same. Only the components will change with respect to the tasks that a lab-infra user performs. So here the Sentinel-coliar with consists of four main components. The first one being the resource manager which is basically used for tracking the resources and updating the records of the resources pre- and post-migration and scaling activities. The second is the workflow manager. This comes into picture when different user requests come up on the dashboards and the processed responses are sent on the respective dashboards. So the workflow manager will also be responsible when there are certain notifications coming up from different enterprise networks as well. The third one being the scheduler. So scheduler is a component that is scheduling different kinds of scaling requests and different kinds of migration requests across the sites and also depending upon the priority of the request. And the last one is the load balancer. So load balancer is tracking different resource APIs to distribute the workload and the traffic that is driven by different kinds of servers and the service request. Let's move to the next slide. Here we can see what kind of APIs we are leveraging here and what kind of tools we are using in this current release of service Sentinel for the lab and for users. Some of these APIs listed here are the resource APIs that is used for gathering or updating the resource records. The Selometer API that we are using here for the meter list and the sample list records. Griffana is the tool that we are using for different kinds of monitoring activities and it has various kinds of dashboards. For scaling and migration, we are engaging the APIs of OTCS and House Framework that is NFV Concerto. And lastly, as we explained, this tool can be extendable with different enterprise networks as well. So we are planning to integrate it with other third party tools like Ibana and LogStash. So we discussed about the lab and for user use cases, the architecture for a lab and for user and the different kinds of APIs. Now let's take a look at how the logic flow happens for a lab and for user when he performs different tasks from a mobile application. The first sequence shows how a migration or a monitoring activity is happening from the dashboard for a lab and for user. So these are the key functions that are taking place to actually fulfill the scenario of monitoring of the sites. The second scenario is when a user is performing the migration activity across the sites. So this kind of workflow happens when he's performing migration to reduce the carbon footprint. And the third sequence comes into picture when a critical service request comes into the queue of a lab and for user and he has to fulfill that request. So the third is for scaling up or down the resources. Moving to the next category of users, we have the DevOps users. So these users are the ones who are basically dealing with the CI CD task and equivalently important is to get the releases deployed on different testbed environments. The main use cases that we are targeting for a DevOps user in Service Sentinel are to remotely monitor different kinds of service requests or the build activities that are taking place. The second use case can be he can track the different build processes that are happening on different tools and also he will be able to perform the root cause investigation of where and all the requests are failing, where are the block requests and what applicable action he can take to resolve a particular issue. The third use cases when he allows the deployment of a created package on different target hosts. Moving to the next slide. Here we present an architectural overview of Service Sentinel for DevOps users specifically. So the layout will remain the same. That is the framework for a Service Sentinel. The Sentinel core layer will now deal with only two main components here, that is the build manager and the release manager. So as the DevOps user are mainly engaged in the building processes, the build manager here will deal with the components that are involved in the performing the build request of different packages or releases. This manager will in the end forward the details of the packages or the releases to the release manager. And lastly, since a DevOps user's primary task is to perform the deployment of the releases on different target host bed environments, the release manager component will come into picture. So this is primarily responsible for creating the releases from the build packages and getting these releases deployed on different environments. After we have discussed about the architectural detail for a DevOps user, we have the different APIs that we are leveraging in the current release of Service Sentinel for a DevOps user. And some of the tools that we are using here are Git and Garrett APIs for tracking the repository changes, the Jenkins API that we are using for the build processes, heat and zero meter we are basically using for gathering the meter records and performing the automated deployments. And it can also be extended with third party enterprise tools as well. For example, we are planning to integrate it with dockers, containers, LXC, Ansible, Zool, NotePool, et cetera. Moving to the next slide. This gives an overview of the different dashboards we have for a DevOps user on a mobile application. So we will discuss this in detail in the last demo. Coming to the last family of users, that is the general users in Service Sentinel. So as we discussed, the general users are the ones who are using the services that are offered by the service providers of OpenStack. The three main use cases that we are targeting for a general user of Service Sentinel are, firstly, he can deep dive into the vendor specific catalogs. He can check out what are the different vendors available in OpenStack world and what are the different kinds of services or the product suites that they provide. Second one, he can have a comparative readout, that is he can compare and filter the different OpenStack services that are provided by different service providers. And thirdly, he can keep the, it is like the solution can keep the users notified and updated with the services that are provided by the providers. So this will be a win-win situation for the service provider itself because he can keep the users updated with all the OpenStack services that are available in his enterprise. Moving to the architecture overview of a general user in detail, the basic framework will remain the same, only the Sentinel core components will change here. So the workflow manager is usually required for processing the requests and the responses. Then comes the services module, which is basically dealing with managing different kinds of OpenStack provider services and also performing a comparative study of the different OpenStack services that are provided. The next comes the policy control module, which comes into picture when a general user requests for certain policy from a service provider and a service provider can perform a feasibility check via this component so that he can enable or disable a particular service for the general user. So in all, we have discussed about what are the users missing today? What are the day-to-day operations of OpenStack? What are the high-level service Sentinel features that a user can use on the go? Now, let's take a look at day in the life of a user where we have a recorded video of the demo because we have emulated this environment on an XS tab. So this shows a dashboard overview for a lab-infra user, where in the left panel, we can see the different sites that a lab-infra user can monitor. Once I put the status of site A as on, the different processes start for this particular site. That is, we can see the usage or the memory is changing, the number of VM processes are changing and in the graph, we can see the RAM usage in the last one hour. So now I have put the site B also on. So here also, the processes keep on starting. This is basically a wandering dashboard where the user can see what is happening on different site locations. In the next view, I am able to see a detailed view of a specific site or a data center that is site A, Sheena Gava. Here, I will be able to perform the migration activity from this dashboard. So once the user selects a particular host, he sees that there are certain resources that are about to reach the thresholds. For example, the threshold value is 85 and so let's see what he does. He selects certain particular VMs who have reached the threshold beyond 85 and he wants to perform the migration activity. So for the migration activity to take place, the user has to select a destination site. The migration activity can take place in the same site or a different site. He selects a destination site from the dropdown. Suppose he selects site B and he starts the migration progress to happen. In this migration process, the VMs that have attained their threshold are being migrated from one host to another or from one data center to another. The third use case that we discussed was regarding scaling activity. So here, this gives an overview of the different requests that I have received on my dashboard for scaling. Some requests have a high priority status amount against them. The user goes and selects the high priority request first and he wants to scale the host so that the users or the RAM or the CPUs goes up. In the backend, there are certain APIs we are leveraging from the thesis in-house framework that is NFV Concerto, which is basically taking care of what are the feasibility checks required for the resources. So this is a scaling process happening for site A hosts. This is all we had for the lab infra users. Now let's take a look at the demo for a DevOps user. Okay, so this shows a dashboard for a DevOps user. When he has received certain requests for build activities, these requests are for certain bugs that he wants to get built on certain tools of OpenStack. So the user decides to pick on some of the bugs here. That is the first three bugs so that he can start the build process for these bugs. He starts the build process and what happens in the cycle is for a particular bug that is the first one, there are different tools that are being used for the build activity. So the first one gets ticked here. That means the build process for this bug is attained and the second one is still on with the build request. We can also check out the cycle here that we had clicked on three bugs that were there for the build request and this is dynamically happening here. When the third bug is also finished, a build cycle is complete. Now we take a different scenario wherein there is a bug which is facing a problem for build request. I've selected two more bugs here. The build process completes for the first one and in the second one, we'll see what happens. This is a process that is facing an issue while the build process. I monitor it for some time and I see that this is not moving on. Then I'll take a deep dive into a detailed view of what's happening for this particular bug and I monitor the build process for only this bug. I can see here this bug is marked as yellow. That is still, it is pending. And I see here there is a red mark for the Jenkins tool. That means it is failing at Jenkins. From here itself, I will be able to monitor the issue that is coming up in Jenkins for this particular bug. It says, prepare an environment for the run. So I'm able to track the issue that is happening here and I will be able to log this issue in Storyboard as a DevOps user does. Coming to the last use case for a DevOps user, we have the deployment activity. So here we basically see in the left panel, there are certain releases that I want to get deployed on different hosts that are on the right side. The processes are running on different kinds of hosts. I pull a Juno release that is 3.1 and I want to make it deployed on 3.0. And secondly, I want to kill a 1.6 release on Gamma 1.4 release. Here I start my deployment process. So this is very plain and simple via service central. Things are made very easy. The deployment activity, the monitoring tasks, the scaling activities, the migration activities, etc. Now let's see what we have for the general user. As we discussed, a general user will be able to perform the tasks that are offered by the open stack service providers. So this gives a basic view of the dashboard for a general user where he has certain open stack news and events coming up on the dashboard. And on the leftmost panel, there are certain vendors that are available for a general user. He can pick on those windows and decide on the activity. There are other features as well for a general user that is ask open stack, attending IRC, there are sharing details, add to favorites and whatever the products he has subscribed to. The second use case that we were discussing was comparing products of different open stack services. So let's see what happens when he clicks on comparing products. A general user will be able to see different open stack products and services when he clicks on comparing products. So now we select two different products. These products details will also be available when he clicks on different kinds of vendors. So that they provide the vendor specific products of open stack. He has selected two products. He can subscribe to a particular product. Now when he says compare products, he fetches the details of two products of different vendors or the same vendor along with the feature sets. So this will enable a general user to perform the comparing and filtering activity according to his need. That's all we had from our side. We are open to questions. Thanks, Wathi. So we are happy to take your questions. As we mentioned to summarize, the service Sentinel is more of a framework which can integrate with any of the enterprise open stack versions. And so it's more as it has modularity and extensibility to connect with any of the enterprise customers or products. So any questions, we are happy to take that. Logs, yeah, control. Which user you are talking about? Archive. Okay, so the question is for any of the users, are we able to access any of the logs or do we get access to those logs, right? Okay, so for build activities, if you consider the DevOps users, he will be able to monitor different kinds of activities or the tools that are being leveraged for a DevOps user, as I just said. So when he monitors the build activities, he will be able to check out the tools, right? The build activity was failing on one section that was red that time. So there he will be able to find out what is the different problem. There will be a proper link on the dialogue and he can check out the logs from that variant. So while at present we're retrieving only the exception, it will be another line of code, a few lines of code to access the logs and retrieve it back on the dashboard. Yeah. So that's feasible. Any more questions? If not, thank you for your time. Thank you. Thank you.