All right, good morning, everyone. We're going to get started with some introductions and stuff like that as people trickle in. But we have quite a few slides, as you'll see, to cover. So anyway, good morning. Ting and I are here to talk about orchestrating an OpenStack DevOps cloud to achieve continuous delivery, something that we both worked on in a collaboration a few months ago. And we'll get into it. So I'll introduce myself first, and I'll hand it off to Ting. And then I'll come back later. So I am Thanay Nagy, Solutions Engineer at Electric Cloud, which is a software delivery system, acceleration automation company. I'll introduce it a little bit more later. And a former engineer on the Electric Commander project, which we'll be talking about today. All right, thank you. Good morning, everybody. My name is Ting Dao. Currently, I'm working as the director of the IND Cloud Data Center at Huawei USA branch, where I am responsible for bringing the latest IND engineering methodologies and best practice, such as cloud computing, infrastructure, and DevOps environment back to the company to continue improving our engineering efficiency. Before Huawei, I was the principal solution architect at a company called VCE to deliver the VBlock 300 converted infrastructure product. And I also worked as the senior product manager and the solution architect at a different company, networking vendors, such as Cisco and Juniper, responsible for the data center switch product families and enterprise solution architecture design. Before we get started, I would like to give you guys some background about the company Huawei and the challenges we try to solve together with our partner, Electric Cloud. Overall, Huawei is a privately owned, multi-billion international technology company with the headquarters based in Shenzhen, China. Huawei has been an innovative industrial lead for the last decade in the telco and IT domain. Huawei has very broad product and solution portfolios, and its customer covers all the corners of the world. Internally, in Huawei, we have three major business groups, service provider business group, enterprise business group, and consumer business group. Their product covers the service provider routers, LTE wireless stations, data center switches, service storage arrays, IP telephony, and even the consumer products, such as media patterns, smartphone. Even in very weak, in the past few years, we all know the global economy is very weak, but Huawei still has successfully maintained a very rapid revenue growth year over year. In 2012, we achieved around 35.4 billion US dollars in the revenue, and we are expecting around 10% year over year growth in 2013. Huawei is really a global company. More than 65% of its revenue come from the region outside of China, including EMEA, APEC, North and South America. Huawei has been very committed to its R&D innovative investment since its early founding stage. Globally, we have around 150,000 employees and 16 R&D centers. Around 50% of our total employees, which is 70,000 people, are R&D engineers. In 2012, we spend around 13% of our revenue back to the R&D innovative investment, which is around five billion US dollars. That's a lot of money, and we would like to spend them wisely. In other words, the cost of R&D investment is so big, a small percentage of the saving in the R&D cost or a little bit improvement in the engineering efficiency can help bring the hundreds of millions of dollars back to the company's stake. So let's talk some challenges we are facing these days in Huawei. As we discussed, Huawei offers hundreds of product families every year, and the internal R&D environment is so complicated. A lot of time during the peak business hour, the development tools requires hundreds of CPU computing power to complete certain R&D activities or to accelerate certain R&D activities. Instead of provision more local physical build server, for example, we would like to reduce the software build time from hours to minutes. So instead of create more physical build servers in the lab, certain technologies we used in this acceleration solution requires a huge amount of distributed CPU computing power on demand whenever they are needed. Most of us come from the engineering background. In a traditional way, we all know how time consuming are tedious to set up the compile or build environment for the development team or to set up the software testing environment for the QAT. In average, let's assume 10% of the engineering forces for a company will get involved in those environment setup every day. If we can help them to reduce 30 minutes in those provision process to a large company like Huawei with 70,000 R&D engineers, in total we actually can save the cost of 450 engineers for the company per year. That's a huge return in the RPEX to any large company. In these days, data produced by the R&D activities are growing very rapidly. And unfortunately, they turn out to be more and more valuable to be stored somewhere so that we can use them to analysis the pattern of the R&D process or to trace back the product issues, so on and so forth. So the R&D environment required that we should be able to expand our R&D storage capacity dynamically scale out without impacting the existing running application or existing environment. In order to achieve more efficiency in the engineering productivity, the integration of roles between the development and operation engineering become a hot topic these days. The progress in the virtualization technology and cloud computing converged infrastructure in these recent years, along with the automatic provision and configuration management for devices, make it ready for the R&D organization to provide a multi-tier and multi-platform infrastructure in an easy way. DevOps gives the engineering more control over their development environment and even the production environment. It bridges the gap between the development and operation activities, and also helps to automate as much as possible to avoid those unnecessary human errors. The dynamic infrastructure especially helps those giant companies like Huawei to support globally distributed R&D teams. So obviously, virtualization and the cloud are the solution, way to go solution here for us. But keep in mind, the internal R&D data center or internal R&D environment is always a cost center for most companies. We spend money without bringing the revenue directly. So let's take the commercial software as an example. In order to build R&D data center with 3,002 CPUs service, right? Most likely the company need to spend millions of dollars every year depending on what type of license or support contract they choose. But in the meanwhile, the open source community, especially the cloud technology, become more and more active in the past two years. The graph shows the population of the open source cloud software community grows dramatically in the past few years. Among the top four open source cloud software, OpenStack definitely gained the most and the best attention from the individual developers, users and even some big cloud vendors. The development and the maturity of the OpenStack is evolving day by day and that's why we are here this week. So in the project, for the project, we might team did with our partner ElectroCloud. We chose OpenStack as our underlying cloud infrastructure. And the rec mount server Huawei IH 2285 are used and our OpenStack is deployed and managed by Huawei ILCN, which is called Huawei ILCN, Intelligent Lab Configuration Manager, which is the in-house lab configuration tool framework. The Huawei ILCN deploy the OpenStack and manage the OpenStack, use a modulated script and it also leverage the OpenStack community existing best practice deployment by integrating those open source tools such as Chef, Puppet, Cobbler in the backend. We are considered to contribute back to the community when the solution get mature. In our system, we also created a portal for the cloud admin and the cloud users with a different level of privileges to log in and manage the cloud resource. With several clicks, the virtual machine pre-installed with different tools or application can be provisioned very quickly and easily. So up to this point, literally we achieved a low cost cloud infrastructure for our IND data centers. But can we go further down to reduce the cost by leveraging the open source as much as possible? Looking into those open source tools in each IND process area, the answer definitely is yes. And that's exactly the idea on top of which we built this dynamically DevOps system solution here. So in the project we did with ElectroCloud, as we discussed, we called Houdos, Huawei Unified DevOps System. And we chose OpenStack as our cloud infrastructure provisioned and managed by Huawei ILCM. On top of the cloud, the user also have the option to create couple virtual machine provisioned with the open source tools along with the cloud provision process initially. For example, we use the open LDAP for the user identity management. RedMind for the backtracking tools and track for the project management. Revealable to help with the code review. And Jenkins to provide the local build compile as well as the continuous integration. We use Git or subversion to provide a source code management and graphite for the resource monitoring. Also the working station virtual machine pre-installed with the customized open source Eclipse can be created dynamically to provide the IDE platforms to the engineering group. At last but not the least, we chose Electric Commander, which is a perfect framework here to integrate all those tools together, including the OpenStack cloud. To provide us an intelligent, lean, low-cost DevOps system empowered by the latest cloud technology. To the individual users, such as development engineer or testing engineer or release engineer, we also provide a portal or dashboard as the daily upfront user interface so that the users don't need to jump in between those queries for different tools. The portal and dashboard give the most functionalities by backhand integrating with those open source tools through Electric Commander. Another big benefit for that is that engineering only need to get trained with this who does portal or dashboard GUI without the need of being aware of those different open source tool or cloud technologies we used in the background. This dramatically reduce the engineering training cost and improve the efficiency of tool usage. Depending on the user privilege in a specific project, the portal and dashboard can provide the users infrastructure as a service and the platform as a service accordingly. Now I'm going to turn this to Tanei, let him to go through some more details how we use Electric Commander to integrate those tools and the cloud together to provide an end-to-end automatic DevOps system. And he will also go through the design and development and user case by using our Huda system. Is that my call? Thank you, Tane. So I'll jump a little bit with a little bit of introduction into Electric Cloud. So Electric Cloud is a software company in located in the Bay Area or headquartered in the Bay Area I should say. And we have a software delivery system. Our products, Electric Accelerator and Electric Commander enable you to automate and accelerate your entire software delivery process from build, test, deploy all the way through to release and really something that helps you achieve continuous delivery. Electric Commander is the product that we used at Huawei for the Huda system. And that is the framework with which you can automate, parallelize, resource manage, schedule manage and pretty much run whatever you want to run, wherever you want to run, whenever you want to run it using Electric Commander workflows, which you see in the background which we'll see a little bit more of. So the OpenStack integration, it was not something that we previously had before we started working with Huawei, but it was something that we created on site. Very, very quickly, it's something that we're formalizing as we speak right now, but for those of you who are familiar with OpenStack and the REST API or the NOVA tool, it'll be pretty familiar to you. So you can see over here, this is a project. This, what we're looking at over here is Electric Commander. The project contains a few procedures to deploy one VM, deploy multiple VMs, undeploy one, undeploy multiple and update some local information. So this is a deploy procedure. The details aren't too important, but just kind of to show you guys what the integration looks like. And it uses the Electric Commander Pearl API to talk to the OpenStack REST API as well as parses some output from NOVA. This is a second procedure built on top of the original deploy procedure, which uses dynamic job step creation in Electric Commander to basically run and create as many VMs as you want to dynamically. So I'll walk through a solution with a couple of scenarios for what we achieved using the Huda system. And after that, I'll turn it back over to Ting to go into some summary and then you guys can ask some questions if you like. So this is a development scenario. We have a developer Joe on one side, a reviewer Mike on one side and the Huda system in the center. So the developer Joe modifies their code using Eclipse and launches a pre-flight build. How many of you guys in the audience are familiar with the concept of pre-flight or pre-commit builds? Not too many? Okay, well, the concept is with Electric Commander, what you can do is you launch a pre-flight build. It takes your local source changes, uploads them to the server, downloads them onto the agent on top of a clean source snapshot. So you're effectively simulating your check-in and then it runs a whatever procedure, whatever job you would normally run in production. It runs that against that simulated check-in and only automatically checks in the code at the end if that pre-flight was successful. So what we'll see over here is once the user modifies the code and launches Eclipse, if you see that little cloud lightning icon, that's where it passes over to Electric Commander, which is then going to orchestrate all of the different tools that Ting spoke about earlier. So the first thing we do is check out the sources and overlay the deltas from the developer's box to simulate their check-in. Then in Red Mine, which is the issue tracking system we use in this case, you mark the issue as build and unit test. So that way you can track from your issue tracking system what each issue's status is. So we added some statuses that reflect what happens when an issue is being passed through the Huda system, excuse me. After that, Commander will then launch a build and test on Jenkins, passing it instead of the normal subversion repository, the pre-flight source directory that it created. After that, if the build or test was successful, the Commander job will do one of two things. In the case where the build failed on Jenkins, it immediately reports it to the developer and the developer's check-in is not allowed and they're then told to go take a look at the build, see what failed, try again after you make a fix. So in the case where the build test succeeds, it then moves on to Red Mine, marks the issue as in code review. This is using a Red Mine integration. And then in review board, which is the open source review tool that we use for this case, it creates a review request, which then goes over to reviewer Mike. So now review Mike has a chance to review the modified code. Electric Commander will wait until that review is processed and whether it was successful or not, it's again going to notify the developer. So in the case where the reviewer rejected the code, once again in eclipse, the developer receives a notification that the code review is rejected, they can go and take a look at that. And their commit is not allowed. In the case where the review is successful, Commander will automatically mark the issue as resolved using the Red Mine integration and then notify the developer, automatically committing their code in eclipse. So this window that you see over here on the left-hand side, from the time the developer modified their code and launched their pre-flight to the time the code was checked in, that's a huge time savings. You don't have to worry about what happened with the auto build test. You don't have to worry about breaking production builds. You don't have to worry about closing out your issue or about even the code review happening. It all kind of happens in a black box, so to speak, for the developer and they can move on to other tasks. So I'll walk through some screenshots, kind of just to go through the same thing that we just spoke about. It'll be pretty quick. I won't spend too much time, but this is Red Mine, if you guys are familiar with it. This is the bug that was marked in progress by the developer as they started to work on it. In Eclipse, they modify their code and launch a pre-flight using Electric Commander's Eclipse plugin. And over there you can see it's a run configuration. They run their build and unit test. In Electric Commander, the subversion pre-flight is created. The subversion pre-flight source snapshot is created and then passed over to Jenkins where it launches the pre-flight build using that simulated check-in. It also automatically updates the task in Red Mine to a new status which we added, which is build and unit test. In Jenkins, you can see that the build was started by user Electric Commander, which is the user that's blessed by Jenkins to be launched from Electric Commander. So this job was launched from Electric Commander. It's the exact same job that you, or the exact same build that you would launch if you wanted to run this in production. So the same build is running under CI as well, monitoring subversion changes. In the case where the Commander build fails, Commander picks that up from Jenkins and it fails the workflow. It never moves on to code review. It reports the error. And on the Eclipse developer side, it's hard to read that, but it says the automated build and test failed and the developer's code was not committed. So the developer modifies their code, launches another pre-flight. This time the Commander build succeeds and it's sitting there waiting for review. So in the case where it's waiting for review, this is review board. This is the automatically submitted review request. And so this is the reviewer on the other end. They choose to reject their changes in this case. Commander picks up that the changes are rejected and the workflow fails and it's gonna report that back to the user in Eclipse. The change was reviewed and rejected. Eclipse, he received the error message, makes whatever changes he wants, relaunches the pre-flight, third time's a charm, except the changes on the reviewer side this time after getting through the build and unit test and the workflow succeeds. And at the bottom, the changes have been successfully submitted within Eclipse. I'll walk through another test scenario. This one talks a little bit more about the open stack integration over here. So the test engineer Jill, she picks an issue to verify and which test cases she wants to run against that issue in Electric Commander using a procedure that was set up for that task. Once again, we use the red mine integration to mark the issue as verifying. In open stack, we provision the virtual machines based on the test cases that she wanted to run. Now this is completely dynamic and flexible. How you want to deploy machines when you want to deploy them is really up to the designer of the procedures within procedures and workflows within Electric Commander. From Commander, it launches the automated tests on agents that are on those open stack machines that were just deployed. And whether the test was successful or not, will then get what happens next. In the case where the tests failed, the developers notified and that the VMs are ready to inspect. So the VMs are not automatically undeployed because typically if a test fails, you might want to, as a test engineer, you want to go and take a look at those VMs and see what happened. So they're notified. They're given some information about how to get to those VMs based on the floating IP addresses that were assigned and the links to the web VNC via open stack. The user then goes in and manually decides when they want to tear down the virtual machines that were deployed. In the case where the test succeeds, Commander automatically tears down the virtual machines. This is, again, a design decision. Whether or not you want to do that is really up to you. But in this case, we decided, in the case where the tests succeed, there's really no point keeping those VMs around. Might as well keep it as elastic and dynamic as possible in that case. Mark the issue as closed in red mine. Notify the developer, and sorry, notify the test engineer that the test passed and closed the issue. So once again, the same type of time savings over here. The test engineer does not have to worry about provisioning or tearing down these virtual machines that's all taken care of through an abstraction layer. And the tests are automatically run through it based on, sorry, did you have a question? So yeah, in this case, so this was definitely more of a kind of a proof of concept. And so it really depends on how you want to do that. So in this case, what we did is we just kind of had a certain few test cases which run on different platforms which are represented by open stack VMs. But that's not the case really. I mean, depending on what you want to have it as, it could be based on you select test cases, you select test directories, you select a product and it runs through the whole test suite. So it really depends on the designer. So this is the time savings for the test engineer. Once again, it doesn't have to worry about any of the stuff that's automatically taken care of by the Huda system. So I'll go through some screenshots again. You can see over here there are no dynamically deployed VMs. These two are the actual machines on which the commander servers are running. So this is the test workflow. Again, this is just an example. It's not something that is hard and set, these parameters and what the behavior of the workflow and procedures and commanders completely customizable. But in this case, the test engineer selects a red mine issue, selects which test cases they want to run on which platforms automatically provisions the machines from commander. So the VMs are dynamically deployed using that open stack integration, which I showed you guys earlier. You can see that they're spawning. Once the IP addresses are assigned, those IP addresses are automatically picked up. Once again, using the open stack integration. They're links to the deployed machines and these are the web VNC links which are also available through the API. And in the case where the test failed, it sits there in the error state waiting for the test engineer to come back and decide to tear down those machines. It sends an email out to the test engineer with these same links. And once they've taken a look using those web VNC links, you can log in directly to the machines, which is really cool. And commander sits there waiting for the manual transition. Once the user decides to take down those machines, they run the transition, click okay. The machines are automatically torn down in open stack. We're back to our same two statically deployed VMs. Now, in the case where you relaunch the test workflow, this time same issue, same case, same test cases, something was fixed along the way. If the tests were successful, the VMs were never, sorry. If the tests were successful, the VMs were dynamically deployed and undeployed. The test engineer never really had to run anything in that case or never had to interact with open stack at all in that case. So I'll hand it back over to Ting for a summary and then we'll have some time for questions. Hello. In Huawei actually we have very aggressive goals to improve the engineering efficiency with very detailed target metrics. For example, in the coming years, we would like to reduce our software build time from hours to minutes with those tens of millions line code embedded software. And we also would like to, for example, reduce the full automatic regression testing cycle from execution time from days to hours. And those complicated solution testing cycle from months to weeks, none of them are easy task for any organization. But we do believe the next generation only data center empowered by who does solution can help us to get closer or achieve those aggressive goals. Thanks to the team from ElectroCloud and the team from Huawei, in the project we did jointly, we designed build and validate live and working system to help us to increase the resource utilization and the productivity to reduce the cost to deliver software and hardware and also shorten the product time to market with better qualities. In the meanwhile, our China team has also started the work to deploy and roll out the INE data centers across different cities in China by leveraging the who does solution we did jointly in Huawei US branch. And we definitely look forward to share with you guys more exciting story next year with those large scale real world deployments. So this concludes our presentation today. I think we still have some time. Any questions, comments? Tonight I know I will be. Yeah, that's the tool that we use. So yeah, the tool that we were using is the tool basically. So the question was what kind of tool are we using to orchestrate the whole who does system basically. So the answer is electric commander is the tool that we use. That's electric cloud software and I was working with Ting as part of the partnership. So yeah, so electric commander, as you saw, you saw some workflows and maybe some resource type, some dynamic resource integrations and the integrations that it has with other tools like OpenStack. But the software is really an enterprise class build, test, deploy, automation, and orchestration tool. So yeah, so the question. Actually it takes some time to establish a new tool with all the development systems. So since you have mentioned Eclipse, let's say Eclipse Python I'm going to use for my development system and let's say I have five users who are developers. So to do this kind of thing, what kind of, is it one server, 10 server, 15 server? How do you estimate and how fast you can do this? That's the first part we mentioned. Actually we use Huawei's in-house tool, Huawei ILCN to provision the whole system. It's like one hour, two hour. If you just have a couple of servers, two hours, you can have a fully functional OpenStack along with the integrated tool, only tool environment. Depending on what type of like programming language you choose, you want a Python development environment, you can choose that environment during the provision process. We actually, the next step, we would like to move on to the past level, platform as a service. Depending on what type of program language or program environment the developer needs, we can easily provision or provide those type of environment with our tool. Your software is agentless, right? I'm here. Okay. You're asking the commander. The software is agentless, so how do you provision the stack on the machine? How do you configure that? The electric commander does have an agent. You don't have to actually install an agent. You can run it through an SSH proxy, but it's not agentless. Okay. And so your agent coordinates the installation on the virtual machines? Yeah, so whichever agent has access to, whichever machine or host has access to OpenStack, that's the agent that you use to provision and deploy machines. I mean to provision the software that you want to test on top of the machines. I see. Yeah, so you use the commander agent or you use an SSH proxy to actually run commands on that machine, on the machines that are dynamically deployed over OpenStack, and so that's how you would use that agent to deploy your software. Okay, thank you. Is anyone using this for financial control? In other words, you seem to have a very good feel for what everyone's doing. Is there any kind of reporting, you know, so you can understand what all the developers are doing, and if they're actually working on your projects, things like that? There will be some extended development on those open source tools. For example, we use a track for the project management, right? We need some resource to do extended development on those project management software. But in Huawei, we also have some legacy project management software. So we need to see which one we are going to choose. But that's definitely one of the options. Also, right now, Huawei is developing in partnership with Electric Cloud. The dashboard that Ting spoke of, that's very much under development. So there is an administrative view where you can see all the different products and where in the life cycle they are, where in the kind of continuous delivery pipeline each product is, each version of each product. Developers that are associated with each product can take a look and see where they are. Actually, Tanay is going to, for the next two weeks, he will be in Shenzhen working with us to do some extra further work. I want to ask about, and I guess it addresses both of you. So I have a software shop, and there's folks all over, in the U.S., all over the country. And we need to integrate them all. And we're using a variety of tools. We have Jira, we have Jenkins, Gary. That's the same idea pretty much. Developers go, range from Eclipse to VI. And how to, A, can this, I'm assuming, can address the issues we have of lack of connectivity and doesn't involve, is it like, I'm assuming this isn't a downloaded product that would involve, you'd have to help with integrating it with all this, or do I just click Next? Oh no, yes. So I mean, if the integration doesn't exist, something Electric Cloud would work with. Okay. Would work with you for. That's what we do for our customers. But to your point, from Eclipse to VI, we showed Eclipse as an example, but obviously the world doesn't use Eclipse, so, or everyone in the world doesn't use Eclipse, I should say. So you have command line utilities available that do exactly the same thing that you saw. So really that's kind of a wrapper around the command line utility. So the ID integrations that we have are Visual Studio and Eclipse, but for the most part, developers who use VI who use Emacs, they tend to use the command line utility. Communicate back and forth. So the communication mechanism, basically so the client preflight submits a request over HTTP and uploads the changes over, I believe, STOMP. I'm not sure of the exact protocol. And then the commander server, basically, will notify that client on the other end once the job completes, and that's how you receive the feedback. No, it's not an agent, actually. It's just a tool that you run on your machine that communicates with the commander server and then waits for the job to complete. Just a couple questions about your OpenStack install. How big was it? How many compute nodes and what version of OpenStack were you using and did you use any deployment tools like fuel or crowbar? Yeah, actually, probably came late. Actually, we used the Huawei in-house tool called Intelligent Lab Configuration Manager, which is the Huawei in-house lab management tool framework. But in the back end, actually, we will integrate those Chef profit cobala to leverage. Because in the OpenStack community, we have so many best practice deployment tools. So actually, in the back end, we use Chef and the Puppet, depending on which we have the option you'll get. Oh, I meant deployment of the OpenStack infrastructure. Right, right. And in that pro concept, actually, in our lab, we have eight servers and three servers are the controller nodes to provide high availability. Three compute nodes and two story nodes. The ideal is actually, I would like to have this system to support our U.S. branch, which is around a couple of hundred people environment. Yeah. This is a little bit looking ahead, but are there plans to maybe offer this as sort of like an SQA or test as a service? That's exactly the second testing scenario. We have those testing scenarios, right? This is kind of a pro concept in the U.S. branch, but the current work we are doing is we transit this work to the headquarters. They have much more complicated environment. They have very large scale testing environment. That's work we are doing. Basically, we integrate those like test management, test case management system, test execution servers into this solution. Whatever kind of dynamic created and the tear down, we will use the OpenStack elastic advantage to provide that. Yeah. Any more questions? We have one more minute. Yeah. I have one question. How do you make a new test for new feature in your product in testing phase? That's a great question. We do not create the test. It's definitely the onus is always on the developer or the test engineer, whoever creates test to create the test. Commander is a framework by which you run the test, so it's not actually a test creation framework if that's your question. Right. So, usually in typical enterprise environment, we have the test management system. Basically, this one server or multi-server to manage all those test cases is centralized. So, as I said, we are going to integrate those systems into our cloud system. Make it dynamically created. Okay. Thank you. All right. Thanks, Tai. Thank you. Have a good day. Thank you.


Big round of applause. Hi, everyone. Can you hear me? So my session is about conversational AI, Alexa. First a bit about me. I am Sushi Kirk. I'm online available as Gorg Sushi pretty much everywhere. That means on D.Auto, Twitter, Facebook, LinkedIn, Drupal.org everywhere, and Gorg Sushi pretty much. I work for Accenture. My official title is application development manager, whatever that means. But I am tech leading. I'm also trying to build a team. So I'm hiring. So if any of you. All right. So this is the agenda for today. We'll do a, we'll have some theory. We'll do a demo, probably the exciting part. And then I'll try to break down the demo into the Alexa part and the Drupal part and how the two talk to each other. So this is the agenda, introduction to conversational AI, what are the different options we have when we talk about conversational AI, why Alexa, why Drupal, then some basic terms of Alexa, then the demo, and then break down of the demo. And then hopefully we have time for some basic question answers, basic. Disclaimer, no animals, yeah. But the actual disclaimer here is that this is, I am not an expert in Alexa. I have been doing Drupal since 2006, but I'm still not an expert in Drupal. So this presentation is all about sharing my experiences. I may or may not be answering your questions, but there we are. So conversational AI, what is conversational? Who all has interacted with Siri? I'm sure everybody has. Most of you have iPhones. Hey Siri, I don't want my phone to go off now, but hey Siri, get this done. Or Alexa, who has the temperature today, or things like that. So that's what conversational AI is, and that's what our mindset about conversational AI is, but the definition essentially is the official definition, I think, is a set of technologies behind automated messaging and speech-enabled applications. So conversational AI actually includes not only speech-enabled, but also text messaging chatbots that we interact a lot. So I'm sure you must have seen Facebook Messenger apps wherein they pop up with five different, you know, what do you want to do? And then five options. They are also part of conversational AI. And the main thing about conversational AI, they try to provide human-like interactions between computers and humans, and they can act like a human by, number one, recognizing speech and text, understanding the intent of the user, then trying to decipher different languages, because when it comes to natural languages, it's not a straight algorithm. And they try to respond in a way that mimics human conversation. So as I said, conversational AI solutions can be both text and voice modalities, and therefore various channels and devices. There are various channels and devices which offer these options, from SMS and web chats, et cetera, et cetera. We have phone calls, phone call responders, and we have smart speakers, smart speakers like Alexa. And why is this important? Because I know, I mean, when we started the whole website thing, now we keep on talking about mobile-first approach, et cetera, et cetera. But I think the next generation is going to be more speech-enabled stuff, rather than even mobile-first. People are moving away from websites and from even phones and typing stuff. They want to just interact. So that's why it's important. Some stats, as per that research, by 2020, 30% of the web browsing will be done without any screen, and that's where these things come in. Just a quote, I like this quote. Read it through, nothing special about it. All right, so this slide explains how the conversational AI works. So I'll just come over there. To give you an example, hi, I forgot my account. Password, help me. So this is the user saying something, and then it can either be to a voice-enabled thing or to a text-enabled thing. So if it is to a voice-enabled thing, that's the worst part. So there in the ASR, that is automated speech recognition, that comes into play, and then it listens and then tries to comprehend everything and goes to this part. If it is just a text-enabled, there is no ASR involved, naturally, and we go straight here. So this particular box is of, there is a concept called natural language management, and natural language management consists of two parts. Understanding and then generation. So this part, yes, I got somebody saying, hi, I forgot my account password, help. So this part is responsible for converting that into some kind of intent, some kind of dialogue management, and that's when we go here. Dialogue management happens, something happens in the backend, et cetera, et cetera. A response is created, but that response is still not ready for the consumption because we have the ASR in place, so we have to output as a natural language, and that's where the natural language generation happens, and then we get the answer saying, sure, I can help you reset the password. And across the whole spectrum of this, there's something called machine learning and deep neural networks. Essentially, it's all about AI being, trying to train itself and trying to be more, trying to train itself and improve itself, improve its algorithms. So that's in nutshell how conversational AIs essentially work, and what can be the main challenges, especially when we talk about voice-enabled things, languages, dialects, accents, pronunciations, naturally, they are a big, big hurdle. Noisy surroundings, multiple speakers, unscripted questions, unsupported answers, tone and sarcasm. And then, of course, slang and jargon. So Aussies may have a different way of saying something, but the Americans might have a totally different way of saying the same thing. So when we are creating any kind of an application, we have to try and cater to these different things and try and take them into account. Then, of course, there's a concept of security and privacy. We will not be going into that part of it now. This is just a demo. I'm just trying to showcase what I did. So as I said, voice and text. On a technical level, the divide between the two is not huge. As I showed in the earlier diagram, is just the ASR, which is the differentiator. Other than that, most of these things are pretty much the same. And they both rely on artificial intelligence or simple decision tree structures to carry out the conversation, the two-way conversation with users. Some examples of voice assistance. Echo, Alexa. That's what, why we are here. Google Home, Siri, Cortana, if anybody has used Cortana, Microsoft. I'm not very sure of that. All right. Why Alexa and not Google Home? Specifically for me. These are some of the parameters. When it comes to documentation, Google is great, especially for the initial skill creation. The documentation that Google has is amazing. They have the ladder-based approach. But once the initial skill is created, you don't really know what to do next. It's a bit difficult. It's kind of like Drupal versus WordPress. Sorry. But Alexa, the documentation is great once you get over the initial skill. So once you understand the concepts and create your initial, very basic skill, it becomes better. Cloud integration, both are pretty much at par. Code-less skills, the templates in Alexa, they're amazing. Google has some templates, they're not that great. But the current install base of Alexa versus Google, that really weighs Alexa to be in a better position. But to be very frank, the reason why I chose Alexa, I had Alexa at home. So I did not have a Google, so I thought, why not? Go ahead. Now, the question is why Drupal? Well, I'm a Drupalist, that's why. But jokes apart, the reason is Drupal is a content management system. It has in-build workflows, translations, APIs, content modeling, et cetera, et cetera. We don't want people to be writing, the people who are writing content, we don't want to know development. We want them to be able to just focus on content and we want development to be kept separate. And that's why. Also, Google has a pretty good built-in front end, even though we might not need it, but it always helps. All right, so before we start, let's look at the basic terminology in Alexa. So in Alexa, how many of you actually have Alexa at home or have used Alexa at home? All right, at least one person is there. All right, what do you use it for? Are you fairly new to Alexa? Okay, so tell me the time for example. So in Alexa's world, there is something called Alexa skills. So people go ahead and build Alexa skills and then you can go ahead and install them on your Alexa and you can use them. So take for example, the time and weather and blah, blah, blah. Those are almost pretty much built in Alexa. You don't really need to install them. I'm sure you didn't have to install tell me the time app or tell me the time skill, but I use a grocery listing app. It's called R Groceries and it has a Alexa skill. So when you are configuring your Alexa, you have to log in into your phone Alexa, blah, blah, blah. But there you can search for skills and you can just enable it for your Alexa. So in Alexa terms, there are apps for Alexa, but the Alexa term for it is Alexa skill. So that's what we are doing here. Wait, what happened here? So Alexa skills. Now each skill can have multiple intents. So intents are essentially the goals that we want the user to achieve and within the intents we can have utterances and slots. So utterances are the exact terms that you expect the user to say. So for example, what time it is or how's the weather today? Or how's the weather today in Hobart? How's the weather tomorrow in Hobart? All those things are utterances. And within this utterances, so when I say how's the weather today, that today is a slot because today is a variable thing. I can say how's the weather tomorrow. I can say how's the weather tomorrow in Hobart. So tomorrow and Hobart, these are variables. So these are called slots. So that's pretty much when we talk about a basic skill, that's pretty much what we have. We create a skills, we can have multiple intents and within the intents we have utterances and slots. Now utterances, plural, similarly slots, plural. The reason why we have plural utterances is how's the weather today? Is it sunny today? How's the weather in Hobart today? What is the weather today? All these are utterances, different utterances. The way people can ask the same questions, they can change. So that is why it is when you're creating an Alexa skill, it is always useful to have multiple utterances. What do you expect the user to be saying? And again, slots or entities, the slots can also be multiple, like today and Hobart. And the slots can be required or not required because the place may not be required when you say how's the weather today. It will pick up your current location as in what is the current location configured in your Alexa API and then tell you the weather accordingly. It may or may not pick the location of, so if I say now, Alexa, how's the weather? It's not even up, all right, fine. So it may or may not pick up. So the weather today, tomorrow, today, tomorrow is also optional because if you say don't say today and tomorrow, it gives you the current weather and if you don't see the space, the place, that also is, it gives you the current location. So slots can be required, they can be non-required. All right, so for demo, let me see if it is working. So just to explain to you the demo that I'm doing is I've created a very basic recipe site. The different intents are I have an ingredient, what can I make out of it? So if you can just list out the recipes which has this particular ingredient or the another intent can be I know the recipe name, can you tell me the steps? Or I know the recipe name, can you tell me the ingredients that it has? These are the very basic three intents. All right, let's see if it works. Otherwise, we might have to give it a ceremonial sacrifice. Alexa, Drupal cooking. There are no other devices to drop in on. Right. And none of your- Alexa, stop. If you are trying to get into the camera. Sorry, you have to be patient. Alexa, Drupal cooking. There are no other devices to drop in on. Sorry, give it, please, be patient. If you are trying to- Alexa, stop. Alexa, Drupal cooking. Do you want to search for a recipe using an ingredient? Or do you want to find the ingredients of a recipe? I can also tell you the steps of a recipe. Did you hear that? Do you want recipes with- Alexa, Drupal cooking. Do you want recipes containing Drupal cooking? No. Main the ingredient, please. I have coconut milk. Coconut milk. It's gone dead. Sorry. Alexa, Alexa, we'll have to start again. Alexa, Drupal cooking. This is a development skill, so this doesn't normally happen. Alexa, Drupal cooking. I have other options. Alexa, Drupal cooking. Welcome to Cooking with Drupal. Do you want to search for a recipe using an ingredient? Or do you want to- I have coconut milk. Let's just stop this. I'll show them a demo in a different way. So this is Alexa Developer Console. We also have a testing option here. It's not as glamorous as actual Alexa demo, but it's a backup if it works. Which one is it? Drupal virus? Yeah, okay. So zero, one, nine. D-small? Yep. Okay, so I need to just- So I can actually do it through Mike as well as just typing here. Do you want to search for a recipe using an ingredient? Or do you want to find the ingredients of a recipe? I can also tell you the steps of a recipe. Do you want recipes containing coconut milk? These are the recipes containing coconut milk. Coconut rice. Do you want recipe for coconut rice? Alrighty then. The recipe for coconut rice is, take rice, wash and soak it for at least 20 minutes. Drain the rice. Add rice to pressure cooker. Add coconut milk. Add water. Add salt and sugar. Close the pressure cooker and cook the rice for one whistle. Let the pressure settle. Open the cooker and fluff the rice using a fork. Do you want ingredient for coconut rice? Alrighty. The ingredients for coconut rice are rice, one cup coconut milk, one cup water, half cup salted pinch sugar, one tablespoon. Alright, so this was the very basic demo. Now I'll try to break this demo into the Alexa side and the Drupal side. So coming to the Alexa side first. This is the console for the developer, Alexa developer tool. And if you look at this particular name, if you look at the first name there, that says Drupal cooking, that is my skill name, alright? And then these are the various intents that I have created. And then each and every intent has certain things. I'll just walk you through that. I don't have a USB port, it just works. Yeah, thank you. Then whenever you start creating Alexa skills, the first thing you do is tell which language it is in. So for example, for me, I said English Australian. Then you have to say a skill invocation name. So what do you actually say when you say Alexa? And after that, what do you actually say? That is a skill invocation name. So for example, I had said Drupal cooking. So that's why I had to say Alexa, Drupal cooking. And then it would, it should happen. Let me respond to my thing. But so that's one part. Then comes the intent creation. So if you look at my skill, there were three intents that we did. One was I have this particular ingredient. What can I make out of it? So that was captured ingredient and tell me the recipes. The second was this is my recipe. This is the recipe name. Can you tell me the different ingredients? And the third one was this is the recipe. Can you tell me the steps for that? So if you look at the first one, the first ingredient that I have here, the first intent that I have here, that's captured ingredient intent. And these are the sample utterances. I have ingredient. What can I make with ingredient? As you can see, the thing in curly braces, the ingredient here, it's essentially what we had earlier said, the slots. So ingredients in the curly braces, here is the variable that we will be using. And I have just put in two sample utterances, but they can be many, many variants of the same thing. So what can I make with ingredient? I have this. I want to make something with coconut rice. All those things are the sample utterances. And then this is the slot. And then we are creating a skill. We have to actually say, what is the slot type? So that if there is a relevant slot type, we can actually also put in certain validations, et cetera. So for example, if I go ahead and say that my slot type is date time, I can put in validations as well. In my case, that didn't make a lot of sense. So let's look at this slot a bit further. So the slot type is Amazon food. And if I don't, is this slot required or not? Actually, in my case, I'm trying to capture an ingredient to tell the different recipes. So that is a required slot. It may or may not be required in your particular skill or your particular intent. So in my case, it's required. And if whatever the user said and Alexa skill was not able to capture the slot, it just gives you a prompt. And you can actually ask, tell Alexa that what is the prompt? Name the ingredient, please. Also, if Alexa says name the ingredient, please, again, these are the sample utterances. If you remember during the demo, when I said I have coconut milk, it asked me, do you want recipes for coconut milk? So that is a confirmation statement by this, by, so does this slot require confirmation? Just so that I am sure that whatever the ingredient was is the correct ingredient. So I say, do you want recipes for ingredient? So this is my first intent with the slot. Now let's look at the other intents. The second one was find recipe intent. That I know the recipe name from the first intent. The first intent result told me that the recipe name is whatever. Now I want the steps for that. So for that, naturally, the variable will need to be a recipe, and that's what we hear. How do I make recipe? And these are the some simple, some sample utterances. Tell me the recipe for coconut rice. How do I make coconut rice? I want recipe for coconut rice. There can be multiple more utterances. Similarly, just like our earlier one, we have recipe, and again, this is required, and do you want recipe for recipe? And coming back to our third intent, I know the recipe name I need to know. So I have coconut milk, but, and I have, I know one of the options with coconut rice. Let me look at all the ingredients that are there, do I have them or not. So recipe ingredients intent, what do I need to make recipe? What are the ingredients for recipe? This is pretty similar to earlier one, because we have the same intense lot, and it is used in pretty much the same way. So that is the basic skill making that you need to do on the Alexa end, and all this is available via this developer console. You don't have to really code anything here. There are some built-in intents which Amazon Alexa provides to you. So for example, cancel intent, what happens when you say cancel, or stop, and there are some others. Now one important thing that you have to finally do is, I'm sorry, end point. So because in our case, we have, we have created an Alexa skill, when you are initially creating an Alexa skill, there is a testing place, and you can actually host everything on this developer console itself. When you go to the top of it, you do have an option of code, where you can actually see the code. But in our case, we want to link it to Drupal. So that is why what we are doing here is, what is the service endpoint? I'm saying the service endpoint is blah, blah, blah. We will be coming back to this in our next slide. And please note two things here. Number one, this cannot be a local host. You can't create something on locally, because Alexa needs to access that. And number two, it has to be HTTPS. It has to have SSL certificate, and you actually have to define what kind of certificate it is. So that's the thing on the Alexa. And coming back to our presentation, the demo didn't go really well, but oh well. So these are the three intents that we have. So intents and slots. Now, the Drupal side of the demo. We need a D8 install, of course. SSL certificate, and as I said, the D8 install cannot be local. It has to be on externally accessible place. It's externally accessible server. The most important part now is the Alexa module. And this Alexa module actually uses this library. Then we need to have, naturally, the D8 install needs to have content with the correct modeling. And here comes actual custom module development. So we do have the Alexa module, yes, but in order to interact with the custom skill that we have created, we need to have a custom module. So let me try to show you a custom module. So if you look at this particular module, Alexa, and this is now where we get into the backend part of this particular presentation, you need to create a module, a custom module. So Alexa module comes with a custom module called Alexa demo. You can use that as a base. And I'll start showing that to you now. Okay. So I created a custom module called Drupal South. Very unimaginative, I know that. But I didn't. So it needs to have, naturally, it's a custom module. It needs to have an info.yaml and it needs to have a services.yaml. So basically we need an event subscriber and a request subscriber. And that's the only file that is important in this particular module. So let's look at the actual file here. Okay, and I'll try to go presentation mode. All right. Can you guys see the code clearly? Am I losing some people now? All right. And if you look at the different parts of this module, you start to realize what we are actually doing here. The base module I've just copied as all good developers do copy from somewhere else. So that's what I've done. I've copied it from the Alexa demo module and I created a class request subscriber. It implements the event subscriber interface. And this is the whole, the meat of this particular module. So if you look here on request, the event. So event is the Alexa event that is happening that is coming to our callback. I can parse that to get a request and a response. And then I try to get what is the class of that request. If it is a session in request, just say, okay, bye. If it is a launch request, launch request is essentially what I said Alexa Drupal cooking. So that's what it echoes out. Welcome to cooking with Drupal. Do you want to search for a room for Alexa? Stop. It didn't work when I wanted you to work.  All right. So here I can customize how my Alexa should be responding in different scenarios. This particular scenario, when I say Alexa Drupal cooking, what do I want my Alexa to say? Do I want them to say, okay, go to taste.com and find out your recipe? Why are you coming to me? Or something like, okay, do you want to search for a recipe? You want to see the ingredients, et cetera, et cetera. And I'm sorry, but before I do that, I should actually be showing you the actual site for which I have to just to see what the content is. Not easy. All right. So this is my site where I have put in some content. If you look at the content called recipe. I've added just some sample content. They're actual recipes. They're not just some sample content. And let's try and look at one of them so that we can see how, so the recipe has a recipe name. It has a prep time. We're not using the prep time and the cooking time, et cetera, in our Alexa skill as of now, but we can. This is what is used for when we are doing an ingredient search. So this is just, everybody here knows Drupal. This is just a taxonomy. So when I'm doing an ingredient search, basically what I'm taking that recipe variable, I'm trying to feed it in here and doing a simple view invocation saying this is the recipe with a contextual view saying recipe, give me the list of all the, this is the ingredient, give me the list of all the recipes. Then this is the actual method. And because I was a bit too lazy, this is all ingredients in one particular variable. So this is what I'm responding to. So coming back to our code because, yes, I should have shown this to you earlier. So the first one, launch request, launch request, and I say, okay, this is, do you want to do this? Do you want to do that? Whatever. Now comes if the type is intent, any kind of intent, then I can do a case, switch case kind of a thing. So this one says capturing ingredient intent. And this is the way I'm getting my ingredient name from Alexa's request. And after that, it's all Drupal. I have a view which has an exposed filter. The exposed filter is the ingredient name and that you just list out the names of the recipes. So what I'm doing here is the view name is recipe list. That's the set display and the ingredient, and the argument is the ingredient. I execute it and I just say these are the recipes containing and then it gives me the value of the title of the view result. That's all. If we look at, if I don't get anything, sorry, I did not find any recipe. Similarly, if I look at find recipe intent, so again, dollar recipe. Now this is just a node load and emit out the body field. That's all we are doing here. So load by properties, title is whatever. And then I look at the body value. Sorry for people who are cold. There's some bad code here, but please ignore that. But this is essentially what we are doing, that this is the response text where I say, you know, what is the recipe body, which is actually the method. And the third one is ingredients. So again, taking the recipe, find out the, find the recipes which have the same title and then list out the, that particular variable. Very, very simple. Nothing else. And then Amazon help intent. This was the intent that is Amazon pre-built. What happens when somebody says help during that time? This is what we emit out. That's pretty much it. And once you're done, this is working. This is working ideally. Ideally your skills should be working. Sometimes it does not, but all right. Okay. So in a nutshell, not to do this. I'm just quitting PHP from altogether. All right. So broad steps in a nutshell, creating an extra skill. Make sure the endpoint is correct. On the rule, install, create the content type and some sample content, install the module, create a custom module with the request subscriber, change the endpoint. Test, first test using the inbuilt test tool. That's where we did the demo. And then test using an actual, actual Amazon device. Some troubleshooting steps because that's what I faced. I wanted you to also know. I cannot see my skill in the Alexa app. Make sure that you have logged into Alexa app using the same credentials as your Amazon developer account. I can see the skill in the app, but my echo device is just not recognizing the skill. This is something I really had a major problem with. And this happens when the language of the skill and the language of your Amazon app is a mismatch. So make sure that you make sure that the languages are the same. If you try to change the language of the skill after you build the skill, it will go. Don't do that. And one more troubleshooting. Alexa is not responding to my address. There is a device log that is really useful in the developer console that really helps. So look at that. Take, for example, in my case, it was having a problem with ampersand NBSP thing. I had to string replace that. All right, questions. I was just wondering, in the Alexa developer console, what do we call that? Is it possible to specify different end point URLs per intent and pass through the parameters? No. So the end point is per skill. It's not per intent. Okay. If there was, then you could just point it directly to a view without having to go through the back. They're not. They can configure your Drupal accordingly. Yeah, yeah. Hello, tough luck on the demo. That's brutal. There was no sacrifice. Is there any methodology used to develop those intents, like designing the conversational language at all? Not really. This was, as I said, this was nothing. This was just a side project I was doing. So I didn't really have time or the bandwidth to do that. By the way, there is a module that has come on Drupal.org recently. This was launched just the day before Drupal gone Amsterdam. It is supposedly it tries to, it helps you in creating a skill on Alexa. The Alexa skill from Drupal, but currently it's not working. There are some errors, et cetera. It's fairly new. I plan on working on this module a bit more, but there's no methodology that I followed. Any more questions? I'm just interested in making it a bit more human. You know the require confirmation thing. If you turn that off, would she just give you the answer straight away? And you know how you say, you talk about coconut rice, and then you say give me the recipe for coconut rice. Is there any way you could make it to say just give me the recipe for it? Yes, there are ways to do that. It tries to pick up the earlier. It does that. I have not really tried that, but yes, I have seen skills that do that. I was just going to ask with the, you know I've said like define the different phrases, call it the terminology. Yeah, I don't see it. Does Alexa automatically, is it like good at interpreting? Like if there's like another word and they didn't expect or like use a different word, does that have to be exact? No. So for example, when I say give me the recipe for coconut rice, if I say give me our recipe for coconut rice, it will not understand that. Unless until I actually give it another. So you pretty much have to define as many audiences as you can. Yes, yes. Okay, that's cool. Anyone else? Thank you. Siri, repeat after me. Assistant, not a pirate with beautiful plumage.