 All right, so welcome everybody for this webinar. I'm Stefano Mofulli, and I'm the Community Manager at the OpenStock Foundation. And I'm here with Sanjiva Nath from Zazel, CEO and founder that will help through the morning with a demo of the pilot that we've been doing. So we've been working together to provide a better view of OpenStock projects and how things that are scattered among different companies can be put together. And this morning, Sanjiva, if you go to the next slide, we'll go through this project that we've worked on with Zazel, give an overview of that together with a brief introduction to OpenStock. Then we'll see the demo of the pilot with Wicked Smart powering it. And Sanjiva will give a brief overview also of Zazel and we'll look at the next step of where we can go with this project, how it can better serve the OpenStock community and live some time for Q&A after that. Next, so just many of you probably are already familiar with OpenStock, but just to reiterate, what OpenStock is trying to achieve is to become the cloud computing platform that can meet needs for private and public providers of clouds that want to be simple to implement that must be scalable. It started two years ago, a little over two years ago and with that intention in mind to become ubiquitous. So it wants to be large, it wants to be huge, it wants to have a large participation of the ecosystem from developers that build the platforms to users that deploy the platform and other users that consume the APIs, consume the platform. And we work on code and we have OpenStock, a large believing communities and participation. Next, and being born with that DNA in mind of large ecosystems, we have seen large growth in our communities, from conferences and these to number of developers growing month over month. The latest release is just in out this week with participation from over 300 developers from almost 60 companies. The OpenStock Foundation that launched this last month to has seen contributions coming in from a lot of large corporations, all major Linux distributions that are supporting OpenStock. The large corporations are developing on top of OpenStock, are contributing to OpenStock in many aspects. Next. So what it provides is basically three building blocks, main building blocks and shared services. So that OpenStock can be considered somehow a cloud operating system a full-blown operating system that you can imagine sitting on top of Thunder's hardware across a whole data center. And if you go next, we look at the capabilities with compute that provides tools of computing on demand and the project name is called NOVA. The block storage, which is volumes, it was in NOVA and now it's in its own project code name Tinder. Object storage, which is Swift, it provides petabytes of storage on standard hardware and network, virtual networking capabilities so that provides OpenStock pieces through quantum can have fully automated networks, virtual networks. And then on top of this, there is a web dashboard with self-service and role-based capabilities so that users can help provision their own virtual machines and get their own block storage and network storage configured and fed up. And administrators can also run tasks through it. And the shared services like authentication and image service called Keystone and Glam and all these pieces together have their own, are developed through public community-based management where the technical leaders are elected by the developers themselves. There is no mandated like paper play type of configuration inside the community. It's all based on technical merits and there are no forces. I mean, the forces that make all the development happen are all based on the technical meritocracy. So that's a lot of code. There is a lot of decisions to be made. There is a lot of pieces that fly around inside the OpenStock community developing OpenStock. And the community picks and uses tools to help manage all of this and they're all different and they all sit in different places. So we have a wiki powered by Moin that got some of the information in it for tracking some parts of the documentation, the discussions for proposals of new features or discussions about how to do things inside the community. Launchpad is the main repository nowadays for requirements and blueprints and bug tracking. It also maintains the identity of all the members of the OpenStock developers community. Then there's the kit repository, the version control system hosted on GitHub and Garrett itself where we keep all the code with all the changes and we keep also the documentation in there. Garrett with Core Code Review Scala. It's fairly new Jenkins that does all the gating for all the commits and then we have email lists and forums in other places for collaboration. So all of this content is separated and there is very little interaction between this different silos. The identity is the signal sign-on is basically the only thing that works across all of these systems and other information among all of these is complicated and separated. And it's hard to find a correlation between a bug and a discussion that happened on a mailing list for feature and how the decision to implement that feature came through or who had been working on that feature. So this complexity is something that community manager has to deal with every day and I always wanted to have something where I could get an overview of the community of everything that has happened in the community and try to make sense of all together because I get questions from management sometimes that ask me, why did we get to implement that feature? Why, who had been working on that feature and how did we came to that decision to implement it? How much did it cost to implement it? And how many, how much did it cost pain when we got through it and how much value did we get out of it after we implemented it? And these are kind of questions that nowadays with systems that are scattered all across different, they are not collaborating that where you cannot extract information easily from it. It's a very hard to answer. So next, it's, the main challenge is giving the disability to all the work that is being put into OpenSpark as a project by different actors in it is what led to work on the pilot with Richard Smart and Gagel. Wanted to find the interoperability among all this project, or take a possibility to trace back what happened, who did something, why did that something happen and also this is to allow better collaboration within the community members so that also everybody that is involved can get a better knowledge of its actions. Next one. So with the pilot, we started to get the idea of integrating Launchpad with the bottom management system and the requirement management with the version control system and put this information correlated together inside the dashboard that in the pilot, for the pilot is powered by Confluent and the correlation is managed by the Wicked Smart contact server. Next one. So the idea is for the pilot is to have answer simple questions. So who are the most active users? What their trends into activity have been contributing more or less? What is happening to bugs? Are they getting fixed over time? Are they just increasing in quantity of open dimes? And also the other question is how to correlate information among companies and users. For the future and going beyond the idea to make this information available in a more in a creative way publicly but also make it possible that it can be combined with private information inside the corporation that are contributing to open stack. So for example, the possibility to from a future request that comes to a customer that is therefore filed inside the corporate sales force then have that future request inside the sales force will generate a lot of action inside the community on the public side of open stack project. And we pray back that the work being done in the community back to the sales force future request is something that I probably say is interesting and could be one way to move forward with this pilot. Also, I'm interested in like how much to the company put inside the open stack community in terms of involvement, code and all of that and how much did they get back from these contributions. So start to illustrate or make it visible make more visible the value that the community provides. Next, I think this is time for Sanjeev to give a demo and talk a little bit more about what we've tried to achieve. Great, thank you Stefano. Greetings everyone, this is Sanjeev Matt. So what I will talk about is really two things here. One is to demonstrate some of the work that we did for the pilot that Stefano had described earlier in terms of demonstrating some of the capabilities that could be achieved with WickedSmart. And then second, I will also explain how it achieves this level of integration. And one of the things to point out is that WickedSmart is open source and available on source boards. All of the features and capabilities that you will see that are implemented in this pilot are built into the stack and we definitely encourage open source communities in particular to adopt it and contribute to WickedSmart's evolution. So in terms of the pilot demo, what I want to show is how we have unified information from two sources, GitHub and Launchpad, into a context which is the WickedSmart contact server. And then presented this information automatically within Confluence. Everything you will see is automatically generated in terms of Wiki pages and Wiki content. And of course, Confluence then further provides an environment for collaboration, for adding comments, for having discussions there related to particular objects such as bugs or check-ins or user organizations or depositories. And then also you can embed reports and passports, for example, within Confluence so the whole community can come together into a single environment where all information that is relevant to them exists and they can search for things rather than having to go to specific tools to look for information. So the demo consists of a number of different views, for example, view by organization and committers. We'll show you how you can follow and commit to what bug gets related to what are the other activities of that committer, what are the activities related to the organization. And then of course, finally we'll talk about faceted search. This is really very powerful because now you have information that has been captured from multiple sources and you can find it in one place. You can look for it in one place and you can look for specific categories or concepts if you will. You can search for a bar or you can search for a commit or you can search for a particular user or a comment and so it's much more precise and faster. So let's go to the demo. And what I will show you here as I mentioned earlier is you're looking at Confluent Wiki where we have captured where we are presenting all of the content. And so in the home space, for example, for this particular pilot project, we embed a couple of reports. Daily commit activity here and daily bug resolution activity here. So this is again all dynamically generated information so as activities are occurring within Launchpad, within GitHub and then as we integrate other tools, all of that information will automatically be presented here. Then you'll also see some anchor points on the right, organizations, depositories, users, and of course you can add additional ones for bugs or projects, requirements and so on. And again, as I mentioned earlier, all of the content that you'll see here is automatically generated. So let's go to organization, for example. So now we'll explain how we achieve this. So what we have done here is if we look at GitHub, GitHub primarily represents commit activity by user and users have some optional relationships to organizations and users have some contact information like email and so on. And then of course in the comments within the commit, there may be also some reference to a bug which exists in Launchpad. So we have done reconciliation here wherever it was possible just as we are demonstrating where we related a commit to certain files commit to user and then user to organization and also in situations where there wasn't information related to the organization then we went into Launchpad to see if we could find some correlation. And then so trying to bring all of that together into a single store if you will so that you can now start to have different kinds of views for each one of these objects. So here you can see by a view by organization. So here are all the organizations, their IDs, their logins, and whatever emails have been registered. And then here is all of the commit and bug related activity for the organization. So the commit comes from GitHub and then orange but here is all of the orange bars are basically all the bugs that have been picked up from Launchpad. And this data is actually for a particular period in time although in a normal deployment this would be real-time information that you will capture and it will be showing you whatever the current level of activity exists. So now some of the other things. Let's take a look at one of these organizations for example. We can go to Rack Space Hosting. And now you will see again as I had pointed out earlier these are form-based templated pages. So all pages will have a consistent look and feel and they're very easily customizable. But the idea that we wanted to present here is that you can have all of the information relevant to the organization automatically generated and presented. So however, the number of commits that have been done by Rack Space Hosting, the number of bugs, how many bugs are assigned to that organization potentially to different individuals. Logging information, email, blog and so on. Who are the contributors for this organization? What are the repositories that they own? The commits, the resolve bugs, the history here for example. So between January and June is the data that we have chosen for this pilot. And then of course activities on a monthly basis. So this is again as I said, this is all generated. Now the other thing here to look at is the Wicked Smart Pleasant Confluence gives you these smart forms so that you can add additional attributes related to that particular object or concept. So here, if we want to capture the organization description, know it's in any other information, we can extend it within the Wicked Pages context of that organization regardless of whether the organization was picked up from Launchpad or from GitHub. So that's the general implementation. Now we can go back to the home page and look at some of the other information that we've captured. So for example, repositories. So you can go to the repositories page and you'll see the repositories and branches that exist out there. So for multiple projects and multiple repositories, you will see that single anchor page if you will that will give everybody information about all of the details. And then again, since we were only working with Nova, so here's a page that describes something about Nova. What is the repository? EURL? Who's the owner? What's the site? And what are all the branches and any other information that needs to be captured? So again, in this particular case, we have pulled all of this from GitHub itself and created formal relationships within the contact server that described the repository. And then again also finally the user. So you can start with the organization and go to users, so you can just look at the users themselves to see who are all the active users out there in terms of bug fixes, in terms of check-ins and so on. And so for example, if we were to look at for instance any particular user, Brian Walden for instance, and this information related to Brian Walden is automatically pulled in from GitHub from any activity that Brian may have been involved in within Launchpad itself, so some description and notes related to Brian, commit activity. And now you can see even more information like what are the commits, with some description related to the commits, and what bugs, if any have been referenced for that particular commit. And again, all these links will take you directly to the source of this information. And if we were to, for example, integrate Gareth into this mix, then you would also be able to see any code reviews that have been done and who participated in the code reviews. So this is one aspect of this integration where information from two different sources have been pulled in, reconciled and captured in a formal way using a very rich meta-model, so then now you can represent it in so many different views, if you will. And the second aspect of it that's also very powerful is the search. So for example, within Confluence itself, now we can search for various things that may either come from Launchpad or from GitHub. So for example, if I want to search for, and this is what we call the fastest search, because you're actually searching for a specific concept, so you can search for a commit, you can search for a requirement, at any point in time you're searching for something very specific. So we can say we want to look for commits by Vishwananda. And now it will show me all the commits that he has been involved in. But when you see the search, you'll see that it's, first of all, it's only returning commit results. It's not matching on particular text streams. So these are all commits, and the commits are actually done by Vishwananda. And then in both cases, it turns out the commits are related to a bug. So you can click on the bug and, you know, the Zagel semantic depository provides you with a graph-based knowledge base, if you will, which then allows you to traverse. So we can see that this commit is related to a bug. There's information about the bug. And the bug actually was reported by Jesse Andrews. So you can see something about Jesse Andrews, for example. For example, what's the ID? Any attributes? What are the commits that Jesse has done? What bugs that he's been assigned and what bugs that he reported and so on and so forth. And so you can continue to navigate across the graph in this model, in this way. You know, as you're exploring all the different activities. So this gives you some semblance of traceability, if you will, because you can really trace all of these different events and activities and people across various objects. And then, of course, there's also the idea of just being able to do search. So if I'm going to look for a bug, for example, and I can say, show me all the bugs related to live migration, then I will get all bugs related to live migration. So in this case, it's just doing a texting match, but it's actually matching against particular concepts. Now, I can also say I want to search for commits related to live migration, and I'll see all the commits that have been done related to that. In this particular case, this commit also has an associated bug. And then, of course, as before, you can continue to explore in terms of who's the reporter about, what else have they reported, for example, and so on and so forth. So that's actually the demo. Now, let me come back to explaining how this works. So as Stefano had pointed out earlier, this is basically the architecture. If you look on the left, you've got Launchpad and GitHub, for example, and you've got, so for all of these different tools, whether they're hosted or whether they're on premise, we can smart provide connectors, and you can also build connectors on your own. And again, that's really for the open source community in particular to contribute more and more integration potential for this platform. For each one of these connectors, you can see that there are certain concepts that they represent. For example, Launchpad, as Stefano had pointed out, represents projects, requirements, bugs, and so on. GitHub represents check-in commits and so on, and users and organizations. So we're pulling all that information into a contact server. And then from there, that information can be retrieved by any of the tools. So this gives you both integration and interoperability. So in this pilot, you only saw how information is just pulled into Confluence, but it is also, of course, possible that that information can be rendered back within GitHub or Launchpad, or Confluence itself can be a contributor to information. For example, any description or comment related to organizations or commits. Wicked Smart, at a higher level, is an information unification platform. So it comes with a very elaborate knowledge model that describes all the different concepts related to software engineering, everything from projects, requirements, test cases, bugs, check-ins, and so on and so forth, across all stages. And so that knowledge model is what is used to start reconciling information that can be captured from multiple sources. And then the connectors, parts that allow you to do some of the reconciliation in terms of matching and parsing as it comes in so that you can customize, depending upon what you're pulling and from what tool. So in this case, for example, you've got Launchpad, you've got GitHub, Git, potentially Jenkins, and you can capture other tools here as well. And so all of those tools can be unified in a single repository. And so then the information is not only contextual, but it also has very formal relationships captured. And let's talk a little bit, just the introduction to Zagel. Zagel, I founded Zagel in 2006. Our first product was launched in 2009. The mission behind Zagel is what you've, what I've described already. It is to integrate teams, tools, processes, and knowledge, particularly across heterogeneous tool environments across geographies. We have partners with Lassie and Zenda, HPE, Salesforce, and HRAP, as well as system integrator partners. I urge you to look us up on info all the next few times. There's been some very interesting press coverage, as well as our customers. So we get smart platform benefits just really briefly. There's instant integration. So you install the connectors, you point them to the contact server, and things start to automatically get captured and interrelate. It's smart solutions, meaning there's template-based composite applications you can create even within Confluent itself that start to integrate environment and allow you to a lot richer application behavior in terms of process flow. And then, of course, the information is insightful because now you're not just doing text searches and finding all matches within Wikipedia, for example, but you're actually doing faffeted search where you're looking for very precise information. And you can have dashboards and reports embedded. We showed you dashboards within Confluent. We showed you search within Confluent. But the same search could be implemented as an open source or gadget, for example. The dashboards and reports could be captured within a portal or any other application. And, of course, Wicked Smart, not only is it open source, but it's based on open standards. So Wicked Smart is based on Jenna, which is a semantic application platform. It's an Apache project. Wicked Smart, the queries and reports that you saw, for example, are based on Sparkle language, which is W3C standard. And the repository itself is an idea of X and L. So, Stefano, on that note, I will turn it back to you for next steps and conclusions. All right, so, yeah. So thank you. Thank you for the demo. I guess we have a few questions. So I want to skip through rapidly about the potential next steps and how to proceed further, and then we can go rapidly to answering the questions. So this is the next slide, please. So we started with fairly simple ideas, integration of – started with integrating only LaunchPad and GitHub. And we want to go on and we would like to keep integrating more of those of the systems that are around OpenStack that OpenStack uses, the community uses. And we also want to start thinking of what to do next. I mean, once we have integrated these systems, what questions do we want the community – what questions would you want to find an answer in this unified view? Next one. And one of the ideas that we haven't had in mind was to have something like a public portal for everyone. So where everybody, including members of the Foundation or non-members of the Foundation, can go a little – can have a unified view of what's happening inside OpenStack across the projects and across the tools that are used to develop OpenStack. So they can see what's happening. See who's working on what and all that. And then have another view also to provide that information inside the corporations that are contributing to OpenStack. So that they can avoid, for example, duplicating bugs between their internal bug tractors and the public bug tractors that sometimes I noticed it happened when it's a customer that files a bug that is not simply a bug for a particular implementation of OpenStack or a particular distribution, for example, OpenStack, but it's a generic bug. So that bug ends up being duplicated somewhere else. And the history of that bug cannot be traced back or cannot easily be traced back into the origin of that artifact inside the project. So that sort of bridge between corporate content with the OpenStack community site, something that may be interesting. But for all of this, I would like to have feedback from the community, from the individual members of the Foundation, individual developers to the corporations themselves. We go to the next slide. And we put out a survey with very simple questions that would like you to give a look at and provide your feedback. You can tell me what you would like to see. And of course, there is the OpenStack. The blog post has got more links to further discussions at the OpenStack Summit next week or in 10 days. Go back. So I hope to see most of you in San Diego, but I saw that there are questions. So I will repeat the questions so that we have them in the recording. And Sanjeev, you can answer them because they're mostly for you. There is a question from Tom that asks, capture and integrate that is mentioned with the capability of Wicked Smart. What's the travel time between capture and when the views will be available? Exactly. So the question is between capturing information from tools and having the view, the lifetime between that? Right. Yeah, I think that's the question. Okay, yeah. So it is, in Wicked Smart, you would expect to have it in real-time because Wicked Smart's model is primarily transactional. So the connectors act as listeners and they are listening in on all the transactions. Any activities that occur within the tools themselves, all activities are captured and of course they're made available and they're accessible in real-time. Right. And John Dickinson is asking if the tools can associate bugs with commit, with email list threads and Twitter conversations. Yes, that is the direction that we'd want to go. And of course the key here is to try to find all the potential leads that allow us to reconcile between them. For example, between the check-in and bug, the association was by scanning for a bug ID within the check-in itself and then using that to go to LaunchFact and retrieve information about the bug. So it would be the same in terms of Twitter and other social media tools, for example. Right. So another question is how does, from Alvaro, how the data is captured from different data sources? We are actually capturing data from the application, not so much from data sources, although it is also possible. So we do not actually go, in this case, the information is captured through from GitHub and LaunchFact and we are actually, we're using REST interfaces for that. So we can do queries against the tool directly or against the application in that case and pull information. But as I said, there's a number of different mechanisms that would get smart allows. So it all depends upon what you want to integrate. You can just pull in CSV files. If you happen to have some static data available, you can have connectors which we also provide for JIRA, for software and Salesforce and DEST where it's actually the, each one of the connectors is a listener and so as activities are happening in this application, they're capturing help times. And then you can also, basically, use REST interfaces to pull information if you want to do this, for example, for seeding data or for just pulling it one time. Another question by John Dickinson is how do you create the metadata with each content source created? Sorry, I didn't hear that clearly. How do you create the metadata for each content source? Right, so the metadata does not represent the content source. The metadata actually represents the knowledge model that represents the core concepts. So we get smart currently provides, I think close to about 20 oncologies or metamodels, if you will, that represent all these core concepts like project requirements, stages and so on, as I mentioned. And so they cover all stages of a software engineering life cycle, including process, not only applications. So the metadata is not specific to any particular application. The information from GitHub, for example, was not captured in a GitHub-specific repository. And what that means, actually, and it's a really good question, because what it means is that if you were using five different potentially version control systems, you know, Subversion and GitHub and a few others, for instance, then information from all of them would show up in the same place. I mean, a commit is a commit. It doesn't matter what application it comes from. And so you would still see a commit, but the source may be GitHub or your local Subversion environment or something else. Same thing with bug. I mean, it could have been a bug from Launchpad, or it could have been a bug from Jira. It doesn't matter. It shows up and it captures as a bug. Cool. Are there any more questions? Everybody's still alive listening? All right. So, as I said, this is a very important project for, I believe, for the OpenStack community. Being so complex, being so large and growing at this rate, I expect the complexity not to diminish, but to keep going up, and we need to have better tools to manage to know what's going on, to understand what's going on. And I definitely ask you to go and give us feedback. Let me know what you think of this pilot in particular. What you think, in general, the OpenStack Foundation can do to make it easier for you to understand what's going on inside OpenStack, what's going on inside your organization, your team, your group, how to reduce the problems created by this complexity. And, yeah, the survey is very simple. It's very fast. Please go and answer those questions. And we will have another session at the OpenStack Summit, October 17 in San Diego. So, if you're interested in the topic, please join that session too. We will keep continuing. And I hope you enjoyed this. So, thank you very much. Thank you, Sanji. Yeah, we'll put the presentation on the slide share too. So, you have the rest of it. Thank you very much. Bye-bye.