 Good morning, Strakas. Welcome. I just wanted to start with this. This is Srikanth here. I'm part of the Vipro Technologies DevOps team. And I have my co-presenter, Dev Dutta, from the Rackspace. This small introduction about Vipro for some of you are not aware of it. So we're a global IT services company and spread across more than 100 countries. And we have been working across the breadth and depth of the technologies right from process consulting to infrastructure management as well as from ERP as well as to the continuous and all. And as part of the open source, it's been an exciting journey for us. We have been part of open source and especially working with various meetups in open stack. And so far, we have been really taking the knowledge from the open stack experiences to the customers. It's been a great journey so far. And it's been an exciting time being here as well in the summit. So before getting into the today's topic, I just thought I wanted to highlight a few points for the last three, four days. There have been very interesting sessions, great keynotes. And one of the underlying themes has been that how do we make open stack more flexible, more manageable? How do we take it to the customers in a much more simpler, flexible way? And another point is also about the collaboration aspects by which we are able to make sure the open stack is adopted easily, extensively. And these are some of the things which are also underlying in today's presentation as well. So about the continuous integration. So before we get into that, one of the aspects is about the DevOps point of view. So this is part of the global, bigger picture of DevOps while we're not going to jump and talk about DevOps heavily. We want to restrict it towards the infrastructure perspective and looking at the way open stack is adopted and looking at the current trend of DevOps where every enterprise is eagerly embracing the DevOps part of it. And we thought it's a very interesting scenario to extend open stack's capabilities and add some DevOps perspective so that the users who are embarking on DevOps journey will be able to leverage these aspects. So that's the sort of idea that we thought of working on. So as part of Meetups in Vipro, we worked with DevData as part of one of the Meetups in Solemn. Then we thought of coming up with this integration of Solemn with any of the general CI CD tools. So that's how the context for today's discussion. So we all know that DevOps is one of the critical things which heavily talked about. But then it's not just the tools that will make the DevOps. It's a journey where it is touching upon organizational aspects, processes aspects, apart from tools and technologies as well. And the recent developments in the infrastructure we have seen in a lot of discussions. We are moving towards containerization, a lot of cloud-related aspects. And these are all enabling the infrastructure to be much more flexible. That also means that adopting DevOps is going to be much more simpler. It will help in overall journey for the customers. In the current discussion, we are going to see how the infrastructure is affecting the overall DevOps journey. So we have seen the containers coming into picture. That's going to be more of a... The configuration management has become more simpler. Now it's easier to... It also means that it is easier to expedite the DevOps adoption. Looking at the technology aspects from a DevOps point of view, critical things which we keep talking about is a continuous integration, continuous deployment, continuous testing, and it's a continuum of security monitoring, et cetera. So the ultimate nirvana is to have a continuous delivery where we can, we should be able to deliver anything into production on demand. So as part of that, we are trying to focus on two of the critical things, continuous integration and the continuous delivery standpoint. So this is an analogy where we are seeing that it will help to generate, for example, an energy sector. We are just generating the power and then we are delivering it for the usage, just a small analogy. And on the continuous integration part, so far most of the continuous integration tasks, they are more or less streamlined, more or less stable, more or less well-defined. But the continuous deployment is a very interesting aspect. Given that there's a bit of... Every enterprise is unique. There are a different set of processes. The requirements are slightly different. And that's the reason why we have a plethora of tools in the DevOps point of view. And in spite of having so many tools, there's not one single tool which can fit all the requirements. And that's where we still have to stitch out some of these tools to make sure that we have a customer-specific DevOps platform. Now in that point, the integration standpoint, continuous integration, the tasks which are mentioned in general, this is typically more or less streamlined and we know we have multiple tools to manage them. On the deployment side, looking at the type of infrastructure each customer is looking at, the deployment process could change and that's the complexity that we are seeing today. And we thought it's more interesting to leverage the deployment capabilities, deployment orchestration capabilities of Solum in OpenStack and see how we can marry these two parts, the continuous integration of any of the generic tools and how we can integrate that with Solum. They will be talking about the Solum in detail before we get in there. So when we were selecting one of the CI tools to really integrate, so this is one of the surveys which was presented in year back. And if you look at the plethora of tools and we thought we'll start with Jenkins, which is being one of the widely used tools which has got a very good adoption and a lot of plugins are available. So we thought let's take this as one of the use cases for us to demonstrate the integration between these two. So it's another Jenkins user conference content which actually explains how... It's also one of the interesting things is that there's a lot of adoption rate and there's a lot of people who are interested in moving on to DevOps using Jenkins and there's a lot of customer base which is also using OpenStack. We'll start with that. And this is on the OpenStack usage in terms of how people are looking at the QA and the CI part of it. And we thought it's a just sort of assertion of how the whole use case can be expanded out. So one of the things we looked at was to how we can take it to there are multiple capabilities, multiple scenarios that will come in. For example, when we are looking at Jenkins for continuous integration in Solum for the deployment and Solum also has got various capabilities. And one of the... My personal view has been that most of the tools which are in DevOps, they're trying to have overlapping features. So it's very difficult to segregate them, box them, but the idea is to take the best of the things and see which is suitable for that particular enterprise, that particular point in time and then get the best of the ways. So I just hand over to Dave to speak about Solum before we actually get into the overall implementation part. Thank you, Srikanth. So OpenStack Solum is a system which allows you to test, build and deploy applications natively on OpenStack. So it's an application lifecycle management system. You can also think of it as a platform as a service with CI, CD capabilities. And it can be configured in different ways. You can use Solum only to do the continuous integration parts natively within Solum or you can do CI and CD or just use the continuous deployment part. And that is the option that the Ashish and Srikanth's team have used for this POC. So where does Solum fit in context with all the rest of the OpenStack services? The way I like to think about it is on the bottom most layer, we have these basic blocks for storage and networking, projects like Swift and Cinder, Manila, Neutron and so on. On top of that there are these compute capabilities, Glance and NOAA, Ironic, things like that. And Magnum can fit in either that layer or also on the orchestration layer with heat and mistral. And then on top of that there are these application lifecycle projects like Solum and Murano. So Solum fits at that level and it uses internally we use heat to deploy the applications which internally may use NOAA Docker driver or may can also use other capabilities like from Magnum to deploy to container clusters. Now when we were starting to look at how we can do CI CD with Solum or existing tools like Jenkins, there were these three options that we considered. So you could do CI CD with directly Solum. The disadvantage of that option is there are many organizations who may already have some investment in existing tools like Jenkins and they would not want to necessarily change their workflows for the CI part. The advantage of doing everything in Solum is you don't have to manage two different systems like Jenkins and OpenStack. For Jenkins for using something for doing both CI and CD the advantage is you just have everything again in one system but then you don't for complex workflows and if you already have an OpenStack setup then that may become little bit too complex. So the best of both worlds we thought could be that we use Jenkins for your existing Jenkins for doing your continuous integration setup and then once the artifact has been created hand it over to Solum to actually deploy it. So it's essentially a divide and conquer approach. Let Jenkins do the things that Jenkins is good at and then hand it over to Solum to actually do the infrastructure provisioning, application lifecycle management for the containers and so on. So this is the overview of the solution that we have built. So essentially we have a grid repository which is configured to receive web hooks to a Jenkins job creator will generate jobs dynamically based on the web hook that it will receive and then it will actually go through and those jobs are configured to run project specific tests and once the tests are run the artifact which is created it is stored in a place where Solum can use it and you use it to deploy the artifact. So in Solum there is a notion of application image which is a docker container. All the applications are packaged as docker containers so that's the image which is going to get deployed and the artifact repository that we are going to use is essentially Glance. So Solum is able to read things from Glance and deploy it. So the Jenkins setup once it runs the test is going to store those application docker images in Glance and then invoke Solum just to do the CD part and then Solum will deploy it to the existing infrastructure. So some additional details here. We have the Jenkins job creator which will create these dynamic jobs based on triggers and then the main issue that we faced is how do you mesh the Jenkins setup with an OpenStack setup because Solum is natively understands keystone tokens and everything is native to OpenStack. The solution was we define a Jenkins user and that Jenkins user is the one which is going to run your tests and then is going to store the application docker image into Glance as that user and the jobs that are going to get created are essentially jobs for cloning the repository testing application, building the docker image and then invoking Solum to deploy it. Now as part of CI CD we have the issue of how do we get the logs. So for the CI part we are saying that you can use whatever existing log collection tools that you can define in Jenkins and you can send the logs to something like a external rabbit service which can then publish it to some other place where they can be available as far as the deployment side is concerned Solum generates and captures all the deployment logs and makes them available in Swift so you can just access the logs for the deployment parts in Swift. So now I'm going to quickly show you the demo and walk you through the... Well I show the demo, I'll talk about what is happening in each step. So the demo consists of several steps. The first step was to create the Jenkins job. That's what we are showing it right now. There are no jobs. Once we receive a GitHub trigger that is the repository by the way where all the templates and jobs are available. So the four jobs that we have here are to build the initial jobs configuration which is what is being shown right now. The other templates that we have jobs, job templates are for testing an application and deploying an application image, application saving an image and so on. So in this example we just have four jobs but then there can be more jobs and that's why we are creating these jobs dynamically on receiving a Git trigger and this is the configuration file which is used as part of the proxy server which configures and decides what exact things to create as part of the jobs. So now we are starting up the proxy server and then this is where we are starting up the RabbitMQ consumer which will essentially print logs from each step and then those are the four jobs that are going to happen, steps which are going to happen. So right now we are essentially changing some code and are going to do a commit of this code to see how that triggers the application, the job creation and the deployment. So this is all setup done locally using GitLab. Now we see that the jobs have got created and we can look at the view of how the job is progressing. So we see that the first job has got triggered and then on the console for our RabbitMQ consumer we are seeing all the logs which are getting generated. So currently for the CI step, the logs that are generated are synchronous after each step we are capturing these logs after the end of every job which has run. So the app tests have passed now. So the tests are green. The saving image job will store the application, container image to Glance and then hand it over to Solum to deploy it. So that's the Glance image create. We essentially use Glance CLI as part of the CI job step to upload the image to Glance. So in this setup of Solum, we are using Nova Docker as the driver. So the DevStack, and this is all in DevStack right now, is showing that the container, application container will be deployed on using the Nova Docker driver. So this is now the last step where we are showing that the image ID, that particular highlighted image ID is the one which is being passed to the Solum app deploy command. So Solum is only being invoked to deploy an already created application image and the deployment is done. So now the last step is just to check that the application was correctly deployed, whatever changes we made. So showing right now that the app has been deployed, that's the IP address of the app and if you call it, you will see that the change that we made on that particular as part of the commit has been reflected in the deployed app. So that's essentially the demo part and let me now continue with the... So some of the discussion. As I said, the logs of the deployment are captured by Solum and they are uploaded to the Swift container. So in this case, it will be the Swift container of the Jenkins user and you would be able to... There are commands, CLI commands within Solum which would allow you to get the logs. Now another question in typical CI CD setups is how do you do deployments to different environments? Depth, staging, et cetera. So the way you can do that in this setup is you can deploy the same image that you... Once you create an image, you don't have to rebuild it again. You can just deploy it multiple times and those will be your different, essentially, environments. What about things like passing in environment-specific databases or parameters, essentially? So the way that can be done is Solum has a feature to inject parameters as part of application create and also we are right now in the process of adding support to inject parameters at the time of application deployment. So once using those features, it is possible to specify different backend databases for different environments. Then how about things like canary deployments and blue-green deployments? So those, again, should be possible with the way you can do that is you deploy your app and have two different parallel deployments of your app and then based on when the routing, all the traffic has been moved from one app to the other, you can either kill the previous app or keep using it and that same thing can be used for rollback as well. On rollback point, you can also rollback to a previous version because all the images, application images which are created, they are available in Glance. So Glance is essentially the version repository for application artifacts. So that's what we have currently done, some of the additional things that we are going to look at is how do you add manual control as part of the CI CD process. So there are solutions like using the Jenkins's pipeline input step. How about things like supporting multiple user repositories? So that should be possible in the current set of itself as long as the Git triggers are configured correctly, it should be possible. And then the final question is how about if users already have OpenStack accounts, can you do something that the logs will be available for each individual user in their own containers in Swift? So one of the ideas that we have explored is can we use something like impersonation where the CD step after it has done and generated the logs is able to store the logs in the end users containers. So the Jenkins setup code is available on the first link and then if you are interested in Solom, we have our fishbowl session today at four o'clock in the Hilton. So come join us. I'll be showing a demo of Solom as well and some additional features. That's it. Thank you. Nice presentation. Thanks a lot. So the Solom has the capability with the UI dashboard from which we can orchestrate this, number one. The Docker image creation, so you showed that it is outside scope of Solom actually. So it only uses the created Docker image. So does Solom have the inbuilt capability to create Docker images from the Solom command line? So two questions. So good questions. Thank you. Let me answer the second question first. So Solom does have capability to create Docker images starting from the source code. In fact, that is the main feature of Solom that starting from your source code in a GitHub repository, either it could be private or public repository. We built the Docker image optionally running unit test if you have specified them, and then once that Docker image is built, we save it to Glanswift or Docker registry, and then we also do the deployment. So yes, Solom does have capability to build a Docker image as well. In this setup and this talk, we did not use that because the point was, what if organizations already have something which they are using to build Docker images? So for those organizations and those kind of setups, Solom can also be used only to deploy it was the point. But yes, Solom does have capability to build Docker images. The first question was, is there a way to use Solom from using something like Horizon? And yes, we do have a Horizon plugin. The work, it's currently under work and it will be worked on in this cycle. Any other question? Yes. Okay, so how do you evaluate this entire POC? So right now what you can do is... So Solom's Getting Started guide will show you how to set up a DevStack environment which has all the OpenStack services along with Solom, very easy to set up. And then the Jenkins setup has steps to actually set up GitLab and the integration part which are required between GitLab, Jenkins, and Solom. So let me know if that read me or the guides are not very helpful and I'll help you get started on that. And my email address is on the very first slide, but otherwise you can find me on Solom IRC as well. It's FreeNode. So that's my email address. Firstname.lastname.raxspace.com and I'm also on Solom IRC and today evening we have the Fishbowl session in which I'll show capabilities like starting from the source code, building the application image and actually deploying it. I'll demonstrate that. Any other questions? Thank you.