Many countries have some fairly good systems. Some countries have excellent systems. And I'm not here to say that how donors and multilaterals have been spending their money as a waste of time. But what I am trying to say is that from our perspective, as the DHIs to platform developers and managers, we see a large hodgepodge of different systems being used, very little global coordination or standardization, and a very wide range of sophistication. And I think that is a good foundation to appreciate what do we actually want to do with DHIs too. Martin, you can go ahead and start recording now. Looks like you are. Great. OK. So what do we want to do with DHIs too? Well, we want DHIs too to be the single platform. And the platform, our DHIs to platform is not just one thing. It's many different apps, right? You all use DHIs too. Hopefully you know that it's made up of different applications, kind of just like on your smartphone. There's multiple applications. DHIs too is the same kind of platform. But we want that platform to have all of the apps and tools that are necessary for facility level and community health worker level logistics reporting. We want to make sure that you can use DHIs too in the apps that are within that ecosystem to be able to report all of your supply chain at the lowest levels. Again, that's one of the biggest issues that we've seen. You don't have to take my word for it. That's something that Global Fund and WHO and Gavi have all published is that there is a lack of resources and tools at the lowest levels for logistics reporting. And we want DHIs too to be able to be that tool. Many countries are already using DHIs too at the lowest levels for disease reporting, surveillance reporting, service delivery reporting. And so we want that to be able to be extended into supply chain as well. We also want to develop standards for supply chain indicators and reporting in partnership with the WHO, with the CDC, with Gavi, Global Fund, and others. And we've actually established these lines of communication. We have already developed some of these standards in partnership with the WHO and we'll be presenting those throughout the week starting tomorrow actually. But we want to continue to develop on this. We want everyone to kind of appreciate some harmony here and make sure that DHIs too is able to support that those standards. Also very importantly, we want DHIs too to have as easy interoperability with other supply chain and logistics software out there. We know that many of you, and I've previously said this are using other systems. Maybe you're using Medexis, OpenLMIS, M-Supply or maybe you've developed something locally. But we want to make sure that if those platforms, those other supply chain software that you're using and maybe that you like them a lot we're not saying that you should change necessarily but if you do like that you do want to use it then at least on the DHIs too side it should be able to speak to those systems. Now the question always becomes is can those systems speak to DHIs too, right? It's a two way street.  And that's usually where things start to break down is we maintain what we call API that's application programming interface. That's the backend interface of DHIs too. We maintain interoperability standards there. And I think on Thursday more than our lead interoperability engineer is going to take us through some of those. And we're going to hear from John Lewis who's practically used them to make interoperability with some supply chain software out there. But we want to make sure that we maintain these standards so that if another system wants to be able to talk DHIs to it's as easy as possible for them to do that. That requires a lot of work on our end to maintain these standards developer time and time that we're not developing new features and shiny buttons and new fancy apps this is all work on the backend that basically no one ever sees unless you are trying to connect two systems together but it's necessary and we make sure that we have the resources required to be able to do that. We want to be able to calculate or produce all key logistics indicators and analytics. So any and all supply chain indicators that you deem as necessary or that the donors and multilaterals or say are standard or required we want to make sure that that value can be calculated in DHIs too. That DHIs too has the functionality the ability to be able to produce that value and produce it accurately to produce it that value whenever you need it. That number is always available to you and it's available to you on any type of analytics that you need that you want to see. So whether it's a scatterplot, a bar chart, a map, a pivot table, a dashboard, a standard report however you want to actually see that indicator we want to make sure that that indicator can be seen in that way the way that's the most appropriate to you. Second to last point here is that we want to also provide the guidance to countries and users how to get LMIS data into DHIs too. And this academy is the very first step to providing this larger global guidance. Again, this is the first time we've ever even done this academy. And so you're all a little bit of a guinea pig right now we're all you're the first cohort of folks that we're kind of testing this academy on. We certainly appreciate your patience and we do very much appreciate your feedback but this is the first step for us as a platform, as DHIs to owners and for you yourself as the DHIs to user community that is interested in supply chain to start to build out this kind of guidance that can be handed into countries. And again, I talked about wanting to build a community of practice after this. I think that's one of the major goals of the academy is that this doesn't end on next Tuesday that we are actually all kind of moving together as a global community, sharing ideas, learnings, lessons best practices resources collectively to actually just move us all forward together. This is something, this is not a zero sum game. This is something that everyone in the world can benefit from. And we wanna make sure we have those connections in place to be able to allow that. And then the last bullet point and this is the most important bullet point probably the most important point of the entire presentation today. So I might repeat it several times it's also going to be one of the quiz questions at the end of today. We do not want to develop DHIs to to be a warehouse information system or to be a complete ERP. That's electronic report and electronic requisition and reporting system. That's like the kind of systems that you see at grocery stores or supermarkets but check out counters. DHIs to will not ever be those systems. And the reason is, is because those systems require a fundamentally different database architecture than what DHIs to has. So you will never probably see DHIs to core applications that are developed out of University of Oslo functioning in a warehouse. You may see other software that are working with DHIs to that are operating in a warehouse. And I think that we're actually getting we're working towards that goal. But DHIs to will probably not be the warehouse solution for you. But that takes me back to the the second bullet or sorry, the third bullet point here which is that we want to make sure that we have as good interoperability as possible with these systems so that these systems are talking to each other. And I think that that brings me to this point here. This is a model of what our good friends over at I Plus Solutions who developed the Medexus platform are trying to produce in Burundi and potentially some other countries as well but currently ongoing work in Burundi. And Burundi is using DHIs to as their health information system as many of you are but and they capture data at facility level in DHIs to. So what are we trying to do? On the left side, you see the supply chain information systems. And then on the right side, you see DHIs to serving as the health information system. In the middle, you have the various levels of the Burundi health hierarchy. So it starts at smaller health facilities then you have larger hospitals then you have district level, regional level and central or national level. So what are we trying to do? I think that this actually serves as a great example of what we are trying to build DHIs to to be able to support. First of all, you have DHIs to at the lowest levels at the lowest health facility levels community health worker level. And that means that we don't want to give them we don't wanna give them a lot of different tools. We want the people working at those levels to have one tool that they can use to report all of their data. We don't want them to have to use multiple apps or different devices or go between lots of different registries. We just want it all to be in one place simple, easy, clean as possible. And we are configuring DHIs to to be that tool at the lowest levels health facilities and community health worker level DHIs to is capturing all of the supply chain data. Then that data is then pushed into Medexus. And Medexus is serving at larger hospitals, district level and regional level and also national level to perform the higher functions of a supply chain information system. Those are warehouse management, routing and fleet management, developing pick lists and commodity catalogs. These things that DHIs to is not so good at. And that's exactly fine. I mean, DHIs to is not not always the best tool for every job. So Medexus is there and we are developers are working with the Medexus developers to try to form very close connections and interoperability between these two platforms. And actually, I think it is Thursday where we will have the team from Medexus actually present on what they're doing in Burundi. And I think they're gonna actually be able to demonstrate this to you. So you don't have to take my word for it. It's something that we'll be able to see. So, but of course, data is not just pushing from DHIs to into Medexus. Medexus is also pushing data back and forth with DHIs to. So if you're looking at DHIs to, you're able to see the supply chain data. You're able to see the supplies at health facility level. Then you're able to see the supplies at health facility level and you're able to see your patient data in DHIs to and you're able to have these two and you're able to put all of that data into one dashboard into composite indicators. And that's how you're able to do your root cause analysis or bottleneck analysis. Of course, above Medexus looking at the highest level in the top left corner of this diagram, you have some ERP. So you have like things like Oracle or Sage. Some countries have this, other countries don't. It's not, I don't think it's actually from my experience necessary that you do have a fully functional ERP to have a very functional supply chain. Maybe some other folks may disagree, but at least in the Burundi case, they're trying to push this to another higher level ERP. So I think this is a good model and I think Medexus, they may actually present this model again, but to me, this is one of the clearest pictures of what we're actually trying to get DHIs to, to be able to do. Again, capture data at the lowest levels, produce those analytics and indicators around supply chain all the way up through all levels and then have these more specialized functions that are required for a well-functioning supply chain like warehouse management in a product, a platform like Medexus that is specifically developed for it and have the data moving back and forth between the two. In the future, could it be that Medexus is presented in DHIs to ecosystem? Could Medexus just be maybe another application within DHIs to, possibly? And it's something that we're going to be exploring over the next several months with them as well as our other partners. But as it stands right now, Medexus is a separate platform and we're working with their engineers or working with ours to make sure that those systems are able to speak to each other. Okay, so this is kind of what we want to be able to do. How are we going to get there? So we commonly say that now we have four legs to our LMIS approach here at the University of Oslo as well as with our partners in this. The first leg is that we have new DHIs to functionality. The second one is that we have new content. Of course, this Academy being one of those. We have the third leg being interoperability integration. Again, I've talked about this a little bit, but we'll go into a bit more detail. And the fourth leg being some technical expertise. So people who actually know both the DHIs too, who know supply chain and are able to actually develop solutions in partnership and collaboration. So let me just go into each one of these in a little bit more detail quickly. So functionality. Over the last three or four years, we've been developing a lot of new features in DHIs too, to facilitate both the data capture as well as the calculation of indicators and the presentation of those indicators in DHIs too. For example, in the capture app, that's the Android capture app, what you use on your mobile device, you are now able to do QR code scanning and barcode scanning of commodities as they come in. And George McGuire, I think on later in the week, will actually be presenting on how the international right cross is currently doing this in filled hospitals in Yemen, which is gonna be really exciting to see very cutting edge use of DHIs too. But we know that scanning barcode, especially for immunizations is extremely important.  You wanna get it in the same place that you have your patient data, because if there's an adverse event or reaction to any of the immunizations or drugs that are being given out, you wanna know who received that drug, who got that shot from that vial, from that batch number, and you want that to be all able to be easily put in through barcode scanning. And so now we have that, we have that in DHIs too. And you can use that two day, if you're using DHIs too. And the mobile app, the mobile capture app. We also have been developing resources, technology resources like the API that I mentioned earlier, as well as many others to be able to support local innovations within DHIs too, to be able to capture supply chain data. And we're gonna have a few of these present. So in Mali and Burkina Faso, his West Africa, that's Adam Kosi's team, again, he's gonna be presenting tomorrow on this. They developed an app for the capture of supply chain data. And that's the picture at the top, the first picture at the top, you see that is the application that they've made. And it provides, it does a lot of calculations automatically, it provides a really good, clean user interface for the lowest levels to be able to enter in their supply chain data. And so Adam is gonna be able to present that tomorrow. We also in Bangladesh, a group of developers has made up a kind of a fork of DHIs too, called D2 log. And this is basically, like I said, a fork of DHIs too, specifically for supply chain. So that's another innovation within the DHIs to ecosystem and community. And then the last one, which is the bottom picture here, that is from Uganda. Uganda has also developed a supply chain application for the capture of supply chain data at lowest levels. And so that's what you can see there as well. And we want to support these local innovations. We wanna make sure that DHIs too is a platform that people can build apps into. And those applications can be, say, unique for Malawi, or sorry, for Mali or Burkina Faso or Uganda, but you can still feed data into the same data warehouse or backend and produce indicators and analytics using the common applications like maps and charts and pivot tables and scorecards. The third point to make on the functionality is that we want to be able to integrate aggregate and tracker mobile data together. And so if you're entering aggregated data and you're entering tracker data, if you're not sure what tracker is, tracker is the modality of data capture that we have in DHIs to track individual, what we call tracked entities, which could be a patient. It also could be a drug or maybe a stock out. It doesn't necessarily have to be something tangible. It can be the lack of something like a stock out. And we want to make sure that those different types of data can be captured in one tool as well. And so again, with the new Android application, the new Android capture app, you're actually able to capture both aggregate data and tracker data in one app. There's not moving back and forth between multiple apps. There's just one app. All the data can be put in in that one place. You only have to provide one training to the health staff to be able to enter that data, right? So that's a new innovation and that's largely built on the development of the Seastock system, which I'll talk about in a little bit in just a few minutes in Kenya. Some additional functionality. Now, if you're a DHIs to techie, you're going to appreciate this a lot. If you're not so technical in DHIs to, maybe this might go a little bit over your head, but I'll just try to make it as simple as I possibly can. And I think later in the week, we will come back to going into this in more detail. But starting in DHIs 2.29, 29, all the way up into DHIs 2.34, which is we're currently at DHIs 2.35, DHIs 2.35. But from 29 to 34, we built in something called predictors. And predictors are a special way in which you are able to calculate indicators in DHIs to your calculate values in DHIs 2, referencing previously reported data. So this is very important. Being able to reference previously reported data gives us the ability to say, like, calculate consumption averages, right? Consumption averages can be used to calculate things like stock status and resupply values. And these really key supply chain indicators. So predictors have been there actually now so for about two and a half, three years. And those can today be used to calculate some very complex supply chain indicators. We also have built in some advanced indicator logic. So little known fact, if you're a DHIs 2.techie, you're probably not aware that on the bottom picture here, so if you look at the bottom picture, you can actually see that I'm building you can build indicators now in DHIs 2 that have some aggregation of logic in them. For example, if statements. So you can see here's an indicator that's saying, like, if this, then do this. If not, then do this. If not, then do this. If not, then actually it's the if and or statement. So if this, or this, or this, or this, or this, do count one. If you didn't follow me, that's okay. But it's just basically to say that you can build out fairly complex logic in standard indicators now. That can become very important. For example, I want to count the number of health facilities that are stocked out of all malaria commodities. So I can say, if this stock equals zero for ACT6s, if the stock is zero for ACT12s, if the stock is zero for ACT18s, and the stock is zero for ACT24s, then count one. And that would tell me that would actually put a value for all of the health facilities that are stocked out of all anti-malarial drugs. And then you'd be able to build maps and charts and dashboards and stuff with that number to show, hey, now get a total count of the number of health facilities that are stocked out of all malaria drugs, for example. Again, we're gonna go over this in a lot more detail later in the week. So if I'm losing you now, it's okay. But just to let you know that these kind of functionalities are available. And of course, the last bullet point is we have something called program rules, which we are now able to connect an individual dosage of a commodity to a specific patient. So you're actually now able to say that this patient got a shot from this vial. So in the case of adverse events or something like that, we're able to make those relationships and produce some analytics around them. So what are some of the indicators just to give you a snapshot? And again, we're gonna go over this in a lot more detail later in the week. We're able to do things like resupply values based upon average consumption as well as seasonal trends. Again, yeah, average consumption, maybe average consumption is looking at, and you can define your average consumption. Maybe you wanna look at the last three months. Maybe you wanna look at the last six months. Maybe because you're looking at some kind of seasonal consumption, like with malaria or rotavirus or something like that, you have a kind of a more seasonal frequency of these kinds of diseases. Then you once say, I don't wanna look at the average consumption in the last three months. I wanna look at the average consumption over for this month over the last three years. If you're going into the Epicurve, you don't wanna look at the last three months because that would be misleading because that has a lower consumption. You wanna look at maybe the consumption over the last three years at the same point in time. So you can do that as well. So this is all very definable by you. You can also do stuff like stock status. So I wanna say the facilities that are understocked, adequate stocked or overstocked, and you wanna count these or you wanna have a percentage of each order fill rates. So how much did they ask for versus how much did they actually receive? The number of stock out days, lead time, which is the amount of time between when a facility needs a drug to when they actually receive the drug. And we are also able to do, depending upon how you configure DHIs to, line listing of something like current stock outs or the total number of stock outs over time. So we say, where are those facilities today that have a stock out of some drug? We can do that kind of analytics and calculation in DHIs to now. If you don't believe me, you can take Malawi's word for it. Mungini from His Malawi will be presenting this later. Just a quick look, this is some of the work that they've been doing in building out some supply chain indicators and analytics. And it's really incredible what they've managed to achieve over the last year and a half where they're actually able to seed now in Malawi, where do they have stock outs of various drugs? And what is the stock status for each one of, at each facility for each one of the key commodities that they track? They've really done a lot of work to kind of, in the guesswork, they know where, oftentimes where the stock problems are now in Malawi through connecting open LMIS with DHIs too, to be able to produce these kinds of analytics. And so this is actually a picture directly from the Malawi HMIS. And so we'll go over a little bit this in more detail. I think Mungini will have an excellent presentation on how they managed to do these kinds of analytics and these kinds of indicators in DHIs too. Again, more types of analytics. On the left, you see a custom dashboard app that HIST West Africa built for, I believe it is Mali. And in this application, they're able to monitor the stock status at facilities and give key indicators and analytics to monitor the current stock availabilities as well. Again, on the right side here, we have some analytics from Malawi. And again, this is also like demo data as well. So you don't have to, if you're trying to study this in detail, you're not actually seeing the current status in Malawi. Of course, this is all demo data and it's quite old now as well. But you can see that Malawi is actually able to build in some really incredible ratios. So like stock on hand to case load ratio or consumption to issuance ratio. These kinds of ratios where they actually put the supply chain data in the same indicator as the service delivery or case data, right? They have it in one place now. So they can build these kinds of indicators and these indicators are very useful for forecasting, for planning, for policy development, for looking at how disease trends and patterns are affecting supply data or commodity availability data. They're able, because they have the data in one place, they're actually able to build these indicators. And it's a very powerful, very useful analytics to have. Okay, so that's on the technology innovations. Let's talk about the content that we're working on. And again, we're gonna go over this quite a lot of detail starting tomorrow and then George is gonna take us through some of the indicators later in the week. But just to suffice this little bit of an overview right now, over the last, I think about four years, the University of Oslo as a WHO contributing partner has been working with them to develop what we call standard metadata packages. These are packages of preconfigured DHIs to reporting forms, data elements, indicators, dashboards, sorry for the Slack notification. And they are there available for you on our website as well as the WHO website to download. They come with guidance materials, PowerPoint presentations for you to install. So for example, if you are a country that's brand new starting and you wanna start an HIV program which most every country already has an HIV surveillance program. But just to say that you were starting from scratch or you wanted to update your existing one to follow the new global guidelines, we have already configured the data elements and the indicators and the dashboards following the WHO standards for you. So you can grab that standard metadata package and you can just simply install it into your DHIs too, in instance. And you may will probably have to do some configuration, a little bit of customization based upon your clinical workflows, how your country is structured. But for the most part, it's done there. It's something that you can start to utilize much more quickly than say if you had to develop it from scratch yourself. So these exist for many different WHO programmatic areas. So you have HIV immunization, malaria, tuberculosis, I know that they're working on integrated disease surveillance, they have maternal and child health, they have immunization, yeah, sorry, I already mentioned immunization. They're currently working on non-communicable diseases as well. There also is one for COVID-19 if you were interested in that. And we are additionally now building on top of these supply chain indicators and components. So we are building out a standard metadata package just like we have for these various diseases, one for supply chain data. So no longer is it just disease specific data, it's also the supply chain data that goes with these specific diseases. So, and you can see an example of that on the second picture on the right. So looking at some stock indicators. Again, George is gonna go over this in detail. I'll talk about it a little bit more tomorrow as well. But this is really exciting that we have some pre-developed content available. Second, the third leg to our stool here is around interoperability and integration. We are expanding our conversations and communication with other supply chain systems like OpenLMIS and supply and specifically a lot with Medexus as well. And we want to make sure that we are able to be able to speak to these systems. You know, and if you're asking like, well, can you talk to my system that was developed in my country? That's a question that I can't really answer because I don't know anything about your system. But these are three platforms, excuse me, these are three platforms that are some of the more commonly used ones in that, you know, there's a handful of countries, you know, probably a little bit less than 10 using each one of these systems. And so because of that, we want to make sure that we are having, starting to establish some bilateral relationships with these various platforms to be able to have as good interoperability as possible. Next year, we've started those conversations now, next year they're gonna really take off because next year we're gonna have additional resources on our end, developer resources, hopefully to be able to more seamlessly connect these to these platforms. And the last point that I want to make is that we have now some additional expertise. We will have a LMIS starting next year here at the University of Oslo. We will have an LMIS portfolio lead, that's actually Brenno, he's on this. I've seen him post some questions to the Logistics Slack channel. So hopefully this time next year, Brenno will be giving this presentation. We're really excited to have Brenno, he's coming to us from the Norwegian Red Cross a tremendous amount of experience, practical field experience on implementing supply chain information systems. And so he's gonna be kind of steering the ship to some degree starting next year here at the University of Oslo, which is the first time that we've ever had anyone solely devoted to sitting here at the University, solely devoted to LMIS. So that's a huge addition. We also have George McGuire here, you're gonna hear a lot of presentations from working as a DHIS to technical advisor. George is again, one of the world's experts on supply chain, at least amongst all the folks that I've met, certainly a fantastic addition to the team. And the big news is, you're some of the first folks to hear this in the whole world, is that we have a new partnership with the University of Basel, the Swiss Tropical Health Institute and ourselves, the University of Oslo to develop a partnership, an actual organization, it's called the Stella Organization based in the University of Basel, they're gonna present next Tuesday. And this partnership, this organization comes with additional resources, both human resources, implementation advisors, technical experts, but also technology partners as well. So trying to plug in, not just with the three software, other platforms that I mentioned, but with a lot of other much more advanced technologies. We're talking about like machine learning, there's some talk around blockchain and these really cutting, a lot of cutting edge technologies that we could start building around and collaborating with. It's also being very practical. This organization, the Stella Partnership, will focus on preventing global guidelines and global guidance and hopefully producing some standardization, of course, in partnership with WHO and Global Fund, et cetera, but starting to be kind of a resource hub that anyone in the world can start to utilize. So we're really excited about this partnership, the addition of these two people on our team, which again, you'll be introduced to George this week and Brenna will hopefully be someone that you're working with in the future, as well as the collaboration on the Stella Partnership with the University of Basel and the Swiss TPH means that there's about to be a lot of resources and expertise in the DHIS2 community on supply chain.  Okay, so I think that is all that we will be presenting for today. Martin, can you help me with any questions that are coming through on the Slack channel? So again, if you have any questions, please post those to the Slack channel. We have a few minutes now, we can answer any questions that you have. So we're taking your questions through Slack. Martin, are there any questions out there? Thank you, Scott. Yeah, first I would like to remind everyone that the word of the day is welcome if you haven't already got it. Some of you may have come in late and didn't get it before. So remember, it is welcome. Right, we do have at least two questions from the Askable Logistics. First one is from Brino. Scott, can you see the question? It's pretty long, so I don't sure I wanna... Yeah, I do see the question. So Brino's question is coming about software development, understanding the ability to share information among various platforms from a technical architecture perspective. Will we touch on this? And will we be able to talk about a little bit about interoperability? Yes, we will, I'm forgetting the day. We have a day specifically on interoperability where Morton, who is our lead interoperability engineer here at the university, will take us through some of the fundamentals of interoperability. And then we have John Lewis, who again is leading HISP Vietnam. Talk about how they managed to form interoperability specifically with M-Supply there in Southeast Asia. We will not be going into a lot of very technical detail on interoperability. This is not a super technical academy. There is a developers academy that is for if you're a DHIS2 developer and you're listening to this right now, I think that it's important that you appreciate that there is a specific academy on how to develop applications and make connections between multiple systems, make applications within DHIS2 and make connections between multiple platforms and DHIS2. That's the developers academy. They offer it several times a year. So I think that that would be the format which they go into a lot of technical detail. But we will be giving you an overview, at least give you a list of key things to consider and show you some examples of it. All right, so the questions are coming in a little bit quicker now. Pascal says in the indicator calculations, internal validation rules to be built in between levels of health facility, hospitals, ministry of health levels. There's often confusion errors around data standards stores, specifically that stores are greater than secondary box packages or containers, cartons, pharmacies have more containers and blisters and dispensary levels have more single tablets. So yes, Pascal, that's a really great question. Actually, two weeks ago, we had a specific academy on how to build validation rules and data quality checks into DHIS2. All of these different scenarios that you just described about inconsistencies and stock levels across multiple places or sites can be checked with standard data quality checks already existing in DHIS2. Again, we have a whole academy on that. That was actually just two weeks ago that we did that academy. I believe that the materials are also still available online for that. So if you just wanna know how to build validation rules, data quality checks, use the various data quality tools in DHIS2, you can do that. Now the question then becomes, do we have these specifically for supply chain? And the answer to that one is no. We have not developed kind of standard validation rules or data quality checks for some of the supply chain indicators and data elements reporting forms that we have been developing with WHO. That needs to come next. We need to actually start working on that. It's one thing to have the standard indicators and data elements together that countries can use. It's very helpful, but it's a whole nother level of usefulness for them to also have guidance on how to analyze the data as well as to make sure the data is clean, accurate and validated. And we need to build those kinds of guidance into the standard metadata packages as well. We don't have it yet. This is all still very new. Hopefully the next steps that the LMIS team will be working on. I think also, sorry, George does actually have a lot of guidance and I think George hopefully will be able to go over this in his presentation later in the week on how some of these indicators can be used and maybe George you can also speak to some of the common data quality mistakes or issues that you might see among them. Sophie asks, is there a general perspective about common, about consumption definition between service delivery points versus medical stores? I think that's a great question that would be good for George or one of the supply chain, more technical supply chain experts to go over in the coming days. So I think that maybe we'll put a pin in that question there, Sophie. Martin is reposting a question from Tentally and asking, do we need administrative privileges in order to customize DHIS2 LMIS app? Well, there's a couple of things here to be said. The first one is that there is not a specific LMIS application within DHIS2. We are customizing or really just configuring the existing applications to be able to capture supply chain data as well as visualize or analyze that supply chain data. So there is no custom app. There is no specific supply chain application currently in DHIS2 that we develop as here at the University of Oslo. Now what you will see throughout the course of this week and a little bit next week are some of the apps that have been developed amongst the community. So people in West Africa or in Vietnam developing applications that are specifically for supply chain data capture or analytics. And so those apps are fairly customized. They may come with different privilege settings, but if you're using core DHIS2 to capture, I mean, not a custom app, if you're just using a core DHIS2 generic application to capture supply chain data or visualize supply chain data, you will have to have administrative privileges to edit and configure those applications. So it's not something that you can do if you're not a DHIS2 administrator very likely. All right, some more questions coming in. So we still have a bit of time here. So please do ask your questions. So he, Sophie asked, sorry, is there someone speaking? Yes, it was me, sorry. I thought you, yeah, not just to remind the Mentimeter. All right. Okay, so let me just answer one or two more questions here and then we will go over to the Mentimeter. Yeah, we're not done for the day, so please don't leave. What are your recommendations for LMIS in country? Okay, that's a bit of a loaded question. That one will take a little bit of a longer answer. I would say I referenced, I guess the slide on what that we got from the DEXIS on Beroondi, I think that's my general recommendation. Okay, so Alice, thank you so much for the reminder. I'm sorry to just keep on rambling here. I will hand it back over to you. I'll stop presenting my screen. Yes. And you can take us through the Mentimeter for the day. So over to you. Okay, cool, just a minute. So I would invite everyone, do you all see my screen? Yes. Yes, Alice. Yes, okay, cool. So I would invite each of you to go on menti.com and then enter the following code, 72 58 176. So I will give you one minute to do so. And then we will get started. So it's very simple. I will ask you some questions. You will have a few seconds to reply. And then Scott will let you know the correct answer and maybe a few explanations if needed. Is that okay, Scott? Yep, sounds great. We will start very soon, 10 seconds. Okay, let's start then. Or maybe, Martin, can you double check in the chat whether anyone has any problem joining us on Mentimeter? Yeah, on Mentimeter. Just to make sure, do we need to use the phone or can we use it directly from the browser? Oh, you can use it from the browser too, no problem. Yeah, because the link takes us to an instruction to use the phone. You basically type www.menti.com. Okay, let's start with the first question. Okay, sorry, I'm having some trouble moving to the next question actually. Here it is. Yes, now it works, great. Yes, so first question. Question should be posted on Zoom, Slack, or I don't know. People keep voting, that's good. Okay, so let's show the correct answer. Oh no, sorry. It's okay, hopefully everyone knows that the correct answer is Slack. We are using Slack. Sorry about that. We're able to see Alice from your screen sharing what the majority was voting, and that was the correct answer. Yeah, exactly, that's cool. Then second question. It is critically important to have supply chain data in the HMIS. True, false, that's good. Yeah, I think on this one I'd be very interested to hear the opinion of the 16 people that said false, certainly not part of the general global guidance and understanding, but certainly, I mean, there are now 17 people. I mean, there are many different opinions on this. Like I said, there's really very little standardization out there, but I think in our experience, we really can't do the bottleneck analysis, the root cause analysis. We can't actually start to appreciate why are we having issues in our clinical service delivery unless we get the supply chain data in with the HMIS, something that many countries are struggling with. So if we see that our service delivery, our coverage rates are going down, our immunization coverage rates are going down, a lot of times that's an issue with the supply chain. Maybe we've run out of supply chain stocks. Maybe we've had a lot of expire, and if we don't have that data in one place, we can't really actually start to figure out what the issue is, and so that's why ourselves in partnership with the WHO and many other multilateral are trying to stress that we try to get all this data into one place, the HMIS, which is often DHIS too. But again, the 70 people that said no, certainly, I would like to appreciate your opinion as well on the subject. Correct answer was. Well, the correct answer is true in our opinion. In our opinion. Then next question. Select all that apply. We want the HMIS too to be able to capture all of the HMIS data at facility level, able to calculate all of the HMIS indicators, able to visualize all of the HMIS data, serve as a warehouse information system. On this one, we do actually have a little bit more of a clear specific answer in that we as DHIS too platform developers are not trying to develop DHIS too to work as a warehouse information system. Again, a warehouse information system has a fundamentally different database architecture than what DHIS too is. Some people do use DHIS too to manage warehouses, but it is definitely not something that we would recommend. So for those 37 folks who said to serve as a warehouse information system, please out now 38, someone even had another one, please talk to us and maybe reconsider using DHIS too to manage your warehouse. It's not the best tool for that job. And it's very important for us as University of Oslo to have you appreciate what DHIS too can do, but even more important that you understand what DHIS too cannot do. We certainly know the limitations of DHIS too better than anyone. And I would just make it highly a strong recommendation that DHIS too not serve as your warehouse information system. Okay, and the other three are correct. Yeah, we of course do want DHIS to be able to capture all supply chain data at facility level. We do want it to be able to calculate all LMIS indicators and we do absolutely want it to be able to visualize all LMIS data. But just the function of like the day to day operations of managing a warehouse, it's not really the best tool for that job. Thank you Scott. It was the last question. Great, so then we need to point folks to the feedback forms as well as the participant. Sorry. Alice, what do you mind sharing your screening going through quickly the Slack channels again and functionality? I think we have a few who missed that part. Yes, just give me seconds so that I can go and Slack. And Alice, can we also take a look at the feedback form and the participant survey as well? Yes, just let me go first through, let me share my screen, which functionality is exactly, Martin? Everything? Show the channels what you want to use for which type of questions. Yes, no problem. So we will be for any announcement that we would like to make if you want to inform you guys about anything, we will use the channel announcements that you can, no, sorry, it's not the correct, I'm sorry. It's not the correct Slack channel. I have multiple ones open, obviously. But it will be the same idea. Just give me a second. No, it's not this one. Okay, here it is. We're also getting some feedback that our feedback and survey link are not working either. So we will be handling those issues as soon as possible. Let me just, okay, so if I do that, then it will be, okay, so now normally you see, you're all seeing the LMIS level to academies Slack channel, correct? Martin, if you can confirm, yeah? Yeah, that is the right. Okay, thanks. So we have, you will see, we have the different channels here. So for any, as I was saying, for any information that we would like to send you, we will use this channel announcements. So I would advise that you keep an eye on these channels, if you want to be informed about any major updates, then we have the channel ask about logistics. If you have any questions regarding, or if you want any tips regarding logistics at large, if I can say, do not hesitate to use this channel and we'll make sure that one of our facilitator or one of the training member, training team member will try to make sure that you get a reply as soon as possible. Then the two following channels are also quite interesting because tomorrow from 1.15 to 2.15, and also Thursday from 1.15 to 2.15, we will be hosting the experts lounges. So the experts lounges are basically an hour session where an expert in this case for Africa, especially West Africa, our partner from East West Central Africa will be facilitating this channel discussion. So for one hour tomorrow from 1.15 to 2.15, if you are based in Africa, if you have any questions related to logistics in your local context, don't hesitate to participate in this conversation that will be held once again tomorrow from 1.15 to 2.15, or through time. Then the same will happen again on Thursday, we will be hosting another experts lounges this time for Asia Pacific region. So if you are based in Asia and would like to ask some questions about logistics, still same time Thursday from 1.15 to 2.15, we will have our partner from his Vietnam will be dedicating one hour just to reply to your questions, giving you some specific tips on logistics in Asia region. Then the other channel really interesting is introduce yourself because we want to know where you come from, why you base what you're doing for which organization you are working. So do not hesitate to drop a few words on this channel so that we get to know you a little bit more. And then finally, we'll find the last channel if you have any technical issues like difficulties to access one of the platform or the videos or the forms, you can drop us an email message here and we will try to make sure that we sort this out. We see that some participants have some problem with the attendance link. We will sort this out as soon as possible. I'm sure my colleagues, Simona and Martin are currently working on that. So give us two minutes and we'll make sure it is sorted. And once it is sorted, we'll post a message to let you know here in technical support channel and announcements channel as well. Final thing for those who arrive a little bit late but you probably received the information by email. I sent an email, I believe last week. So we will be, besides Slack, we will be using the LMIS repository folder. It's a Google Drive folder that I shared with you. So in this folder, you will be finding the attendance and feedback form. Very important to us because we would like to know what you think about our sessions or we can definitely improve them, at least improve the next ones so that we are sure we meet your needs and requirements. So don't hesitate to fill in the feedback form. It literally takes one minute. So we'll be more than happy to hear from you. This session today is recorded and it will be the case for all the sessions during the academy. And we will make our best to make sure that the session, that today's session is available in the LMIS repository folder within one or two hour maximum. So if you missed anything, you will have the opportunity to go to the folder, to the LMIS repository folder and have a look at today's session. Same, once the recordings are available, we'll drop your message on Slack. And same for presentation, I'm sure Scott will probably upload today's presentations in few minutes. And I believe that's amazing, already uploaded. Sorry, but while sharing the screen, could you also show them how to add channels because I don't think everyone has all the channels are in all the channels yet. And normally on, okay. Sorry. So if you go back to your Slack for a second, please. Let me go back here. So I would believe like here, you have this arrow. If you click on it, you will be able to see normally all the channels included on Slack. Sorry, you have to click on the plus icon next to the channels to find the rest of them. Oh, and you have to be, yeah, and browse channels. Yeah, that's good. You will be able to find another question and answer there, for instance, if you click on that. Yeah. That's it, yeah. Is there any other questions related to? I don't think so. All right. I've been told that the link should be working now. Please check the links for your survey feedback again for today. Right, so we have two forms there. We have the feedback form, as Alice correctly pointed out, we take very seriously. We do review your feedback every day. And then we have a participant survey. We just want to know a little bit more information about where you are with your country supply chain logistics information system and tell us what things are important to you. We will be looking at the participant survey to maybe potentially revise some of the content over the next few days to be more specific to what you guys are telling us is important to you. So we take these very, very seriously. Please fill out the feedback and the participant survey. Both of them should take no more than five minutes. Okay, so I know that we're a little over time. Today, Alice, Martin, anything else that we need to mention on the logistically? Nothing from my end, Scott. Okay, all right. Well, then I just want to say, okay, thanks, Alice. And then I just want to also thank all of you all for joining today. I do apologize for going a little bit over time, but thanks for hanging with us. We will get started again right back here tomorrow at 11 o'clock Oslo time. In the meantime, I hope you have a wonderful afternoon. Rest of your day. Good morning, tomorrow. And we will see you again soon. So bye for now. Thank you, bye-bye.


Okay All right, I think we're good to go so we're gonna talk really fast because we just got we thought we had 45 minutes And we only have 40 my name is Diane Mueller I'm with red hat on the I'm the community manager for open shift the platform as a service project and my colleague here Is Daniel Hansen he is from Cisco and he is an engineer who's been working on our next generation of open shift And we're gonna talk today about deploying open shift a platform as a service on open stack using heat and Docker and Kubernetes in 39 minutes or less So we've got some work to do here. So today's Agenda is pretty quick pretty clear why infrastructure as a service is not enough when you're delivering Your clouds what is pads? I'm gonna cover We're gonna talk about how to deploy open shift on open stack today So the current version the current release of open shift and all of its flavors and how you can do that with v2 And I'm gonna do it really quickly and do it maybe a few witty one-liners And then we're gonna switch over and we're gonna give you a quick overview of Docker of Google Kubernetes both open source projects that are really rock open shift v3 and we're gonna give you a demo of that and then we're gonna give you all the tools to go off and Get started with open shift v3 on open stack today So the important stuff. I told you who we are why we love open stack. We love open source I'm the community manager. We are really looking forward We have a couple of other presentations that other red hat folks are giving I'm giving another one tomorrow on Cross community collaboration. We've been some great work with the heat team and an open stack to make the templates available For open shift both origin and enterprise. We'll talk a little bit about that All of our cool stuff is on github and you'll will show the links to that stuff and move through that Pretty quickly so that you know where to find all the resources You can always follow me at Python DJ on Twitter and I will send you the URLs If you look on Twitter now under Python DJ You'll see that I tweeted out the link to this presentation So if you'd like to follow along with that presentation the URLs up top This is a reveal JS one will tweet out the link to that again after the presentation So some of the assumptions I have here. I'm not going to explain Open stack today. So you've got to be all open stack savvy. You know a little bit about heat I'll talk a little more about it.  All right good. I'm not gonna explain that one And you've heard about Docker everybody heard about Docker Yes good Optional skills are get Docker anyone play with Kubernetes yet a couple of you. Yay Anybody program and go oh Even better. I'm not gonna explain go Suffice to say that origin v3 v2 that the open source Persian per Project was all a Ruby and Rails app and v3. We've rewritten the entire thing and go So I'm really happy as a Python programmer to get out of the Ruby world But some of the Ruby people aren't so happy about that so one of the reasons that you would put a platform as a service on Infrastructure as a service is really that the extra special sauce that Platform as a service brings to the to the table for your developers and for your people and operations trying to Keep your developer community happy is that we add that middle layer beyond just the compute resources So if you put it on one put platform as a service You'll be able to deploy and automate the entire lamp stack for your applications You'll be able to deploy your Applications faster in a more standardized way. You'll be able to be more flexible You'll be able to give your developers and your development teams the testing and QA environments and the different languages That they they're looking for to use And a way to do that that allows you to deliver all that in a multi-tenant Elastic way so that the applications can scale up and scale down on demand that the developers can service themselves They can do self-service for those resources And really a lot of the reason why you would put a platform as a service on top of open stack is because Developers expect that kind of functionality today They don't expect just to have to get an instance build their own lamp stack and make that all happen and manage that They really expect that level of automation So they expect now to be able to take their credit card go to a public cloud and get a lamp stack Deploy an application and if you're building an on-premise private cloud Your development team your QA team your test teams all expect to have that kind of level of automation available to them So as I said really infrastructure as a service is not enough You're just getting the service the servers in the cloud You're building and you're and you're on the hook still for building and managing everything right down to the OS to the app servers to the database and Platform as a service really Makes that into an automated way if you're just delivering Software as a service people can combine those and integrate those and we have some offerings that allow you to do that XPAS and cloud forms and other things but You're really restricted to only using those services that are available to you So really platform as a service in in my humble opinion is really the secret sauce in the cloud It's what makes the development and the agility to bring new products to market quickly and to be able to scale them and leverage all the ease and scale and power of the cloud Very rapidly and make that done in a way That's compliant and easy to manage from an ops point of view and easy to self-serve from a developer's point of view So with OpenShift, there's three flavors of OpenShift There's OpenShift online So if you go to OpenShift.com you can play with everything that we're going to talk about today and we do it We eat our own dog food. We host and we have over 2 million apps deployed on OpenShift the public cloud version of it And we also have an enterprise version But the part that I'm really happy with it because I'm the community manager is that everything that we use in the public cloud and in our Enterprise project product is available in OpenShift origin the online project and all of that is in GitHub So if you wanted to go and deploy it today on rail on Centos or on Fedora, you could do that So what can you do with OpenShift? Well, you can do just about anything you can imagine with OpenShift You can deploy all the languages that you'd expect if I tried to jam them all in here You'd not be able to read this thing, but it runs on OpenStack. It does run on AWS. It runs on bare metal It runs on Rev It runs on any rail or Centos or Fedora And it basically deploys the entire LAMP stack all of the serve database services and everything you need to get To get your applications running on the cloud So how does it work? I'm going to be really quick about this. It's basically it's taking that The the management interface or the broker So it's taking it's creates a broker and you need to know this in order to understand what we're actually deploying onto OpenStack, so when you look at the heat template, she'll figure this out with v2 What you're getting is a broker a messaging ActiveMQ and a node in which the cartridges and your actual applications live in so we've got two types of things that we have to deploy using heat So a little bit about heat We've done some great work with the heat team Steve Dake Chris Alfonso and a number of other folks have done some wonderful work creating the heat templates They're all up there in GitHub. Some of them are in the GitHub repo for OpenStack and some of them are in the enterprise ones are in the OpenShift repo So what we've done is taken the everything you need to deploy both the brokers and the nodes and put them into heat templates And that allows us to spin up register things with plants spin up the compute nodes and scale them and make them run With all the authentication Capabilities, so we'll do all that ha stuff and I'm trying to do this all in ten minutes or less All right, so you have all the time you need so the origin heat templates for Fedora and for Sentos are in OpenStack heat templates here They're easy to find and this is all the stuff for v2 and and all the stuff for the enterprise version is all in GitHub It's all open source. It's easy to run So if you've got heat installed on your OpenStack, you should be able to run these right out of the box and you can watch a wonderful YouTube at your leisure here and I've treated out these links as well and you can watch this whole thing run into it, but instead of doing that today We're going to talk a little bit about a new pass a new generation of platform as a service So one of the reasons you might ask is why do we need to do a new version of OpenShift? Well, how many of you are using Docker? Everybody loves Docker We've got change become a new era of Tooling Kubernetes was open-sourced by Google. So we wanted to take advantage of that We had we learned a lot from deploying those two million apps on OpenShift.com And we wanted to incorporate that and put out the next generation of OpenShift And one of the wonderful things about working in the open-source world is we get to work with great people like Cisco And Denian who actually on v2 did all of the HA puppet scripts to make The HA capabilities built into v2 So if you're using any of the install.openshift.com Puppet scripts for v2 you're using work done by Cisco and donated and pulled right back into the project So what I'm going to do is I'm going to step aside and let Denian talk about all the work that Cisco is doing and Introduce v3 as opposed to me talking about it. So, Denian take it away Thanks, Diane Can everyone hear me okay? I don't know if this seems working. Oh, here we go. That's better as Diane mentioned v3 the the newest version of OpenShift that is still under heavy development. It's considered alpha Has gone through a major major architecture change All the way from the language that it is programmed in from Ruby to go and So as part of the architecture change there's a lot of tools within the architecture that have changed as well and one of the first tools is how The applications within the PAS system are being isolated from one another Previously there was a technology or a language called cartridges that used Se linux and C groups and and so forth to to isolate those applications within the platform The v3 or the newest version of OpenShift again still under heavy development Is using Docker leveraging Docker and so to understand what? Dockers all about we you know, let's just really quickly talk about what containers are they're a form of isolating You know applications and the application dependencies like configuration files and libraries from one another right so If we look at virtual machines We were able to isolate virtual machines from one another all the way down to basically the hardware driver level With containers. It's an isolation approach that allows us to take a single Kernel or operating system and then isolate Applications and and those application dependencies from one another and So part of that isolation mechanism is that Docker or containers Leverage kernel facilities like C groups and namespaces to create that isolation amongst the applications And part of the way that Docker is able to do this is Is using Docker images right and so Docker images and what Docker does is it takes? It takes the file system and traditionally in a root file system. It will go ahead and The kernel will mount the root file system as read-only do its checks and then turn it over to a read write File system what Docker does is instead of changing that to a read write file system It mounts a union file system so that we can have multiple file systems on top of that Brute file system So I kind of think of it as like a layered cake and so when you create your Docker images You're creating an image based off of a base image that base image is a read-only image If you if you go ahead and make any changes to that read-only image Those changes you make within your image Are now read write within your image. You never change any of the contents within that read-only image So Docker images I Say this is it's more like git than tar right so we can go ahead and pull and push images we could tag and version them and From a developer standpoint the developers love git so you can imagine When docker came around with this image concept that developers very quickly embraced Docker images as well So you know here's just what it kind of looks like if I want to go ahead and pull So I take a host I install Docker on that host and I immediately could go ahead and start pulling down Docker images from from Docker hub the central public registry I could also push an image so I go ahead and I create my own image or I have pulled an image I've made some changes now. I want to push that image back up To Docker so that if I want to go ahead and pull down that image somewhere else It's available and again That's kind of talks about the power of the workflow of docker is being able to push and pull those images down So if I develop on my desktop, I make some changes Go ahead and push those changes up to my image sitting on Docker hub And then I'm able to go to a production system and pull those the recent image down Version and tags so I go ahead and take an image I make some changes to it and say hey, let me go ahead and tag this as something That's useful So I could go ahead and keep the existing image the way it is and now I've got an image just like that But with my changes, but just with a different tag and then some just some Typical operations of containers. I go ahead and run the container I could use different flags like the I and the T and actually get You know go right into a bash shell within my container. I could list my containers using the ps-l I can diff a container so I go ahead and run a container again make some changes and I walk away have lunch come back and I say, oh, what did I change or my changes? running on my container from that image that I went ahead and Ran that container from I ran run a diff on it and I could see that when I did a W install W Get it made to all these changes to that to that image. I Could run my container as a daemon. That's typically how how containers are run Using the dash D flag. I could also add the dash P flag to my docker run And what that does is it basically tells docker. Hey docker go ahead and map ports the dash P's the ports So here I've got a container My engine X container that is running and it's listening on port 80 of that container Well, now I want to go ahead and map that port 80 on the container to the host Right, so the rest of the world can can hit that container on a poll you know on an IP address and the port that they're expected So here's all the cool things that docker does right portability pushing and pulling images so I can go from developing on my laptop to a test dev environment to approach an environment simply by pushing and pulling all the way through And that really aligns with the workflow, right? So developers love that workflow of being able to push and pull and tag images Diff images so on and so forth really easy to use I take a host virtual machine wherever it may be install docker and Very quickly can pull down an image and run a container so I can go from a standard host to To a docker engine running an engine X container within literally a few minutes And then speed because I'm not you know typically These docker images are very lightweight So it makes it very easy for me to to run or pull and push images very quickly Part of that is a union file system, right? So if I make a change to an image and push that those changes up to docker hub I'm not pushing an entire image. Let's say it's 500 meg. I'm just basically dipping right I'm dipping those changes between my original image and the changes that I made and doctor when I do that docker push It's gonna go change by change and say oh, let's go ahead and only push these changes up So what docker doesn't I mean it's it's really was developed as You know a host type of solution, right? There's Docker doesn't have this concept of how can I manage and orchestrate? Hundreds or thousands to tens of thousands of containers across hundreds or thousands of hosts across tens to hundreds of data centers I can't go ahead and bring containers that I would want to maybe operate together and manage those containers as a Coordinated group, so let's bring in kubernetes So kubernetes open source project that Google Open source I want to say about four months ago You know Google's been using containers for over ten years. I believe they're saying that they're You know starting up and shutting down millions of containers a week and so they know a thing or two about containers and What kubernetes does is it's pretty much a cluster manager so that? It's a cluster manager for clustering and managing Containers and so in kubernetes terms There's a concept of a pod and a pod is a collection one or more containers that you would want to have Together on a single host right In this example, we see pod one with a c1 and c2 right so c1 could be my Apache container and it's running my Apache process my Apache configuration files any other Libraries and then c2 could be a service that I normally tie together with the Apache service Maybe it's a log rolling service a data low loading service something like that Whenever I whenever in my environment I go and run Apache I want to make sure that that this other services together I bring them together and that forms a pod and and it makes it a nice unit of management because If you're hearing the term of microservices right so taking containers and instead of treating a container like a virtual machine Or we take one container and load up a bunch of different services on it It's taking a container or what you'd normally have in your application and containerizing each of those services and Then grouping those services together those common services into pods There's a concept of a label so that I could go ahead and take a bunch of these pods You know and in a large environment I may have hundreds of thousands of pods, but I may say wait a second Let's start managing these pods more effectively I'm going to take and take these pods and they're going to be my front-end pod So I'm going to put a label called front-end well I'm going to even further manage those and say within that That pod or the grouping of pods called front-end. I have test dev I have Production so different environment labels so I could stack all these labels together and taking all those labels that allows me to manage These pods so that I don't have pod sprawl and Then all the different services that make up Kubernetes Can be bundled into two typically into two different scenarios One could be your master and another collection of services is your minion or your node your master Think of that as your control plane so within open stack a terminology. This is your controller node All right, and the minion think of that as your worker bee right so the the master is talking to the minions saying Fire up this pod tear down this pod Another big piece of kubernetes is at CD and at CD is a highly available distributed key value store and it's used for shared configuration management So I can go ahead and define Something I could define a label that labels may be foo equals bar Well, I define that within my master Master stores that at at CD and now any of my minions is aware of that particular label So one of the minion daemons is called the kubelet, right? And if you think about the kubelet What that does is think of it as like a translator between the kubernetes world and Docker, right? so the kubelet the kubelet will take your pod definition and it will go ahead and talk to Docker and fire up the Containers necessary within that pod or if I remove that pod definition. I say kuby config delete pod xyz It's gonna go tell that kubelet. Hey Run the Docker commands necessary to remove that container from this Docker host Another daemon is a kubi proxy think about the kubi proxy as like a Distributed virtual Load balancer right so I go ahead and create these pods. I now want to expose One of the services from the pod again I've gotten an Apache example and I say all right. I've got a bunch of Apache pods Let me go ahead now expose Apache on port 80 to the rest of the world, right? I go ahead and create the service I use the label that I was talking about to tie the service to the pod and the kubernetes API will go ahead and create that service endpoint The and store that in ecd and the kubi proxies running on all my minions will be aware of it and say, oh, there's this new endpoint Let's go ahead and pull it down and now load balance for this for this service to all the minions And so it's you know, think of it as a load balancer slash service discovery I have these pods I create the service the the kubi proxy running on the minions is now aware of it and then exposes it to the rest of the world And it's just really interesting that that proxy runs on all the minions. So if I've got a hundred minions from You know one and two one sixty eight dot a hundred to two hundred every single one of them is aware of that service That I create and will load balance on the back end It knows about the IP address or IP addresses associated to the containers or the pods And then it will go ahead and front end the proxy to its own IP address So cluster management, you know, I've talked about some of these is the kubi API That's basically how clients users interact with the system the scheduler very simplistic now But is meant to be more extensible in the future It's scheduled to basically says hey, where do I go ahead and run these pods? Throw this pod on minion one minion two or minion three and then the controller manager Basically works with the kubernetes API and it's monitoring the status of those pods So if I go ahead and say all right, I've got this Apache pod I want three replicas of it for high availability or scaling that service and The controller manager will make sure that all the three of those pods are always running if one is somehow deleted The controller manager will know about it and say let's spin that thing back up If there's for some reason four or five of them, it'll say let's tear those two extra down and Then kubi's cfg. That's just our command line how to interact with the system So kubernetes does a lot of really awesome things But there's some things that it doesn't do right and so kubernetes Really does a good job at how do I manage? containers at scale it doesn't really look at how do I take an application and Manage it through the entire lifecycle of that application How do I take my application source code and turning that into a? Running application That brings that brings us to open shift bringing it all together, right? So if we look at applications, what are they or what do they what do we want them to be in the new era of? Application development is really distinct interconnected services We say distinct because with a microservice concept we want to treat each of the services independently if we need to patch them we patch them independently we test and dev them independently, but they need to be interconnected because you know complex applications are groupings of Services and we want to be able to deploy and manage those in concert, but we don't want them tightly coupled So applications within open shift You know just some key concepts You know for example a config it's a collection of objects describing You know what the application is right? So it would contain our pod or pods our service or services our replicas How many you know how many replicas of this particular application do we want and then a concept of a template right? This allows us to parameterize our application and This is kind of what a a config template looks like we give it a name We specify the top-level parameters that we want to go ahead and use throughout the application services and Then items that really make up the the configuration of that application And here we just dive down into the parameters. So in this top section we define what the parameter is In the template we go ahead and reference the parameter and then when we actually process that template into a config you see that That the environmental variable actually picks up that expression from the template Then there's also a concept of builds or build configs within OpenShift v3 And this is a real powerful aspect of OpenShift It allows us to take source code and turn that into a running image within our environment a running docker image So it basically interconnects the source code. I'm a developer I create some source code and The build config allows me to take that source code and turn it into a running image in the environment If I make any changes to that source code I also have the instruments necessary to keep that image updated in my environment again You know very I believe a very powerful aspect and it really goes into this this slide of of life cycles So we can use or leverage triggers To always keep that image updated my Apache image running in my Kubernetes environment, right? It's awesome that I'm able to put that thing there But three months from now six months from now a year from now am I keeping that updated based on the Continuous iterations that I'm making to that code base And then the deployment the deployment really brings it all together, right? How many replicas do I want? What are my trigger policies? And what's my strategy for deploying the application? Trigger policies You know we can either manually trigger saying hey go in and build this now I could go ahead and trigger it based on a change in the the image or in the error in the config file So very very powerful as well New concepts just to kind of keep in mind with v3 is you know the configurations the builds and the deployments The configurations of the collections of the kubernetes as well as open shift objects The templates that we use to go ahead and take parameters that we're going to leverage throughout our application So take those variables and parameterize them throughout the application The builds taking the source code and turning it into a docker image and then the deployment. How do we actually Get this application up and running So let's actually see what what we're talking about here So I've got I've got a open stack Juno cluster And I'll actually show you so I've got Juno running on fedora 20 And what I'm going to do very simply is go from my open stack environment all the way to running an application in v3 One of the first things I do is I pull down the kubernetes Templates the master branch and I simply put some stuff in the local.yaml, right? What's my keys that I'm going to use? What are the flavor size? What's the IP addresses I'm going to use and this kubernetes heat templates actually a nested template. So So the cluster or the high-level template It's doing some basic things. It's setting up our neutron network. It is setting up our SSH keys to To our instance it's setting up the security and And also basically tying it down to the lower level Heat yaml template So the high-level template as well as the node template, right? It's a nested template And where are we at here? So let me just back up one second So I believe this is This is the second template that we're using here and this configures our kubi minions Right very similar to the the high level or the cluster template It's configuring the network for the minions the security for the minions and then actually configuring The nova instances and within both of these Templates there's a lot going on Basically we're using the the user data parameter within the heat template to install a special repo Pulling down certain packages running some scripts on on the nodes as well You see that we fired off the heat cluster And it is building we could see take a look at the resource progress and see that It's still building out and what we're doing now is just Seeing that oh nova has fired off these instances. They show active But let's take a look at the council log and see where they're at. Well, even though they're active They're still updating their packages pulling down the latest packages that we need for kubernetes Well, now it's complete. So let's go ahead and ssh into our kubi master Now that we're in the kubi master. Let's just see You know that the packages are actually there. We got the kubernetes package We've got the ecd package really the two core packages On the master Let's take a look and we actually see the minions. Oh the minions are there I've got two minions at dot four and dot five Let's take a look at and make sure that the services the kubi api The kubi scheduler the controller master make sure that they're running ecd's running everything so far. Yay Heat did what it's supposed to do things are looking really sweet. All right next step in this flow Now let's pull down another set of files That we're going to use to go ahead and now deploy Openshift v3 on my kubernetes cluster. I pull down the files I'm showing you what the files look like You know, you may want to modify the files if you know if you're master and ecd servers at a different ip address But otherwise I go ahead and create that kubi service, right? So now all the kubi proxies are proxying port 8083 and sending it to my my v3 pod or pods I go ahead and create a pod. You see that it's sitting there waiting You know, so kubernetes is basically saying oh danien wants to create a pod Let's go ahead and schedule these pods out to the minions Download the the docker images and start up the the necessary docker containers It's done that the pods are ready to go. I've got uh a container id and I go ahead and Verify that the container looks good. You see that the services are running now Let me actually get into the container. So I'm going to go ahead and get the container id Use a tool called n setter to basically counsel right into uh into the container And I'm in there great. So now I'm in my open shift v3 environment that's running on kubernetes that was deployed by open shift or by open stack heat Next thing i'm going to do now that i'm in v3 is again pull down some files And i'm going to build build out my docker registry within my open shift v3 environment Open shift takes advantage of a private docker registry And you see that um what this file is it's a config file what we talked about it's going to describe What service so this is kind of like a higher level wrapper right within kubernetes? We're used to or we're familiar with you know the pod files the service files Well now we've got the config file that wraps that all together within the open shift world You know part of the config file is specifying what you know what image do I want to use what ports do I want to expose Now let's go ahead and fire off that config and it creates those services The service is uh is being proxied by kubi proxy Now i'm going to go ahead and create a build config remember I told you about the build Configs what the build config does is allows us to create that connection between the source code And the docker image right and so it needs some parameters to understand that What's the url of the source code sitting on github? What's the the tag of the Image or the image name that I want to use when I go ahead and create that image I go ahead and create the build config And not what i'm doing is i'm uh simulating A webhook right and so what this webhook normally does Is if I go ahead and I set up a webhook in my github repo and whenever I make a change It's going to go ahead and let Openshift v3 know hey something's changed in this sort of source code That's going to kick off v3 to pull down those changes and re and rebuild that docker image And now I've got an application template right so this is going to be my sample application And instead of just creating an application config I'm now using a template and what I talked to you about just a few minutes ago with the template It allows us to parameterize those variables that I want to share within my application So things like admin username and passwords and maybe a certain Configurations within configuration files. I could go ahead and parameterize Here's it includes my pod template. So, you know, what's the name of the container? I want to use what's the image that I'm going to use and this is where I'm actually consuming those parameters within the template And now I'm going to go ahead and generate a config from the template and also run that config All in a single command and now you actually see I've got a running application And it's a simple application a hello world application But what I wanted to focus on was that whole process being able to take An open stack deployment Juno open stack deployment, but this should work on ice house as well How do you take that environment and Build out a kubernetes cluster run v3 open ship v3 on it and then run an application on top of v3 So here's where you can go ahead and get started with open ship v3 github.com slash open shift slash origin And it's got a whole getting started guide We don't really have much time for questions, but I'll hand it back to to dianne Yeah, so thank you very much danian. Um, that was awesome And That that's the kind of beauty of working in an open source community And we would love you to come and contribute and test out open shift origin v3 It's all in github all the getting started stuff there. I'll tweet out the links We're going to be over in the cisco booth Right after here if you have questions to danian or to myself on how to get involved Or how to contribute or how to start testing and if you're interested in running the v2 stuff We can show you how all that works as well I'll be in the red hat booth all day tomorrow. So please come forward and ask any questions you might have Thank you very much for your time and attention Enjoy the show


Greetings. I'm Richard Garriott and I have been a member of the X-Prize family since its founding. And I am very excited to speak to you today about the challenges and potential of virtual learning environments. As some of the other speakers in the series, I myself am a bit of a non-traditional learner. In fact, I consider myself one of the first successful products of the self-taught through self-curated videos era. In school I was a BC student at best, yet I found a way to shine through independent self-paced projects like science fairs, which I excelled at. This allowed the faculty at my schools to give me the latitude to take on more independent projects, and I flourished with their great support on my independent exploration of computers. By the time I finished high school, my career as one of the very first ever computer game developers was already well underway. When I went off to college, as my business income soared, my GPA shrunk. And ultimately, with my family's blessing, I left school to run my first company, and while my family expected that era to eventually pass so I could finish my degree and get a real job, at this point I don't think I'll be returning to school, at least not as a student. I am an example of how, with the right tools and a motivated mind, one can in fact not only get the basics of an education, but ride to the top of a field through hard work and sufficient access to appropriate educational content. But I've also learned, by direct experience, about the competition for a learner's attention. You know, whatever the platform, whether it's videos or computer screens, potential learners are bombarded with other non-educational uses of the same technologies, often produced at even higher levels of quality than much of the educational content. This makes leveraging these platforms especially challenging. Let me illustrate this with some stories out of my own games. The computer games that I'm best known for was a role-playing series called Ultima. The series started in the late 1970s and is responsible for modern use of the term avatar, which I will discuss shortly, and the series also spawned the first massively multiplayer online game, or MMO, with a game called Ultima Online, and its successors continue to this day. Through more than 40 years of creating that game series and its follow-ons, I began to recognize the power of role-playing. When I would get fan mail, even for my early primitive works, I realized that players were reading and interpreting my work in many unusual ways. As humans seem to do, they would often speculate, fill in gaps, and interpret a broader meaning than I had ever intended. And while this was generally harmless, I quickly realized the impact I could have by laying a more purposeful foundation in my work. You know, my earliest games had simple stories about hunting monsters, gaining power, and defeating a primary antagonist. But players quickly learned that the shortest paths to victory often included morally questionable activities that the game allowed. For example, you could steal from the shops in my games, and while the guards would chase you off, players still exploited these behaviors all while supposedly on the path of being the savior of the people. And at the end of all my games, my personal character in the game Lord British asked players to write to me in the real world and tell me of their quests. I then and now send players to write to me a personally signed certificate of their accomplishments. Interestingly, most who wrote to me after winning in these early games also told me their stories of cheating. So I resolved to make my next game in such a way that while I still allowed a moral behavior, the world would respond more realistically to directly show that a moral behavior would lead the in-game society to decide that you were not their savior, but in fact a rogue unworthy of helping, often working against you. The characters that you might steal from would quickly quit helping you and ultimately work against you in the game, and in this way, cheaters never prospered. You know, at this time in computer games, your persona that you played was generally referred to as your character. Your character might be an evil alter ego and thus you might enjoy pretending to be evil. But for this game, I wanted you, the real earth human, to feel responsibility for the actions of your character. And I had come across the term avatar in Hindu text describing the term as the human incarnation of various gods while they visited earth as the gods avatar. I adopted this term and created a game fiction that not only called your character your avatar, now in my fictional world, but your avatar in the game world also started with a psychological profile test that created its initial conditions in my game world. This was the first use of the term avatar in computer games, but as you know, this term has now become quite ubiquitous. When this game was released, it became my first number one bestseller, and to this day it is seen as a watershed moment in gaming. Many people wrote to me about how much they learned through playing the game, how their actual personal morality had been affected, and in fact, the New Yorker magazine recently published an article called The Computer Game That Led to Enlightenment, as this is the 35th anniversary of the publication of Ultima 4, Quest of the Avatar. You know, the game showed me that by making the play experience relevant and personal, not only can I make an even more successful piece of art, but also that this new interactive digital art form had potential far beyond what I had ever imagined. All the games that I've written since have attempted to speak to players at a deeper level, to speak to current issues and real-life problems, and all of those stories are recast as deceptively as possible into my medieval realms, but they're all packed with as much learning as I could possibly cram in. So throughout the decades, I've often been asked, you know, why don't you or others just make one of your AAA games as a full-on educational experience? And for many years, I started to believe that this was just not possible. And for years, the market at large failed to produce very many AAA educational experiences that rose to the level of self-sustaining financially. And I believe that this was largely due to the competitive landscape when trying to captivate someone's attention on these digital devices. Now, I've been in this industry from its inception to the current day, from a time when bringing in $100,000 of revenue in a game was an exciting new threshold across. Yet today, now the costs to make a AAA title have reached over a billion dollars, and the revenues of AAA games are often in the multiples of billions of dollars. You know, computer gaming-related experiences are now far bigger economically and by social impact than all movies, television, books, theater, and other forms of art combined many times over. eSports now commands as large or larger audiences than physical sports. But it remains a hit-based business. If you make one of the top 10 products in a winning category, you can win big. But after that, it gets tough fast. And the majority of computer game-like experiences do not make returns commensurate with their costs. Because of the profoundly difficult competitive race for the consumer's attention, anything you do that is not laser-focused on how do I reach the top 10 as great risk into reaching the top 10 and thus financial viability. You know, I regularly tell people that as someone who sees the potential power of interactive education that the price of entry is so high and the odds of earning back your costs are so low that to try and make a self-sustaining educational AAA product that was commensurate with its costs was folly. You know, people would then often lobby me to consider making a budget experience with donated money. But my answer remains similar, that no one would play or stick around in an experience that didn't compete with the AAA alternatives on their digital devices. And for many years, this seems to have remained true even in hindsight. The good news is we finally seem to be moving beyond this limitation. Computing devices have finally become so powerful and the reality engines that we create for them have become so readily available that just looking and playing well is no longer one of the key challenges to developers. And finally, since competing purely on graphical bells and whistles is losing absolute dominance, we're also seeing great massively successful experiences that both abandon the best reality engine look and contain great content that bridges the gap from pure play and begins to move into focused learning. Now, my favorite example of this bridge is Minecraft, which I expect most of you here know well. You know, I happen to love Minecraft not only because it's a great game, but because it's organized in such a way that the players can quickly move from being pure passive consumers, which they are in most gaming experiences, to actual contributors. You know, first using the world editors to reorganize their own play space, but then by making mods to the game, some even will add their own code to the game and ultimately share or even sell their mods to others. And so Minecraft remains one of my most highly recommended experiences for parents to buy for their kids. You know, recently developers began expertly crafting MMOs with a strong educational focus. My favorite current example is called Adventure Academy, which was recently launched by Age of Learning, the makers of ABC Mouse. You know, and while I was personally critical of the slow tech used by ABC Mouse, kids didn't seem to mind. The product did very well and the company's new offering is great across the board. It is a beautiful integration of all the classic MMO features, which encourage and reward participation in educational quests. The rewards that kids earn and share, they can share their constantly improving avatars on homesteads within the world. Which brings me to this final section, you know, where we are today. You know, for decades, I've claimed to simultaneously be one of the world's greatest virtual reality enthusiasts, hoping beyond hope that we were close to seeing AAA MMOs in virtual reality, which I hope to be the first to create and have throughout my career. You know, in fact, a fun little side fact is that I was the inspiration for James Halliday, the creator of the Oasis in Ernest Cline's Ready Player One. But simultaneously, I was always sad to realize or come to the conclusion that true self-sustaining AAA virtual reality worlds for profit or education remained even further off. I was usually convinced it would be ten years or more, no matter which decade you asked me that question. You know, today, I actually believe we have the pieces necessary to finally begin to truly open this door. Events like this today are a great sign. You know, the newest light wireless virtual reality headsets are also essential. The quality reality engines that are now broadly available are essential. Still, I would argue that the door is just open a crack. It remains to be proven whether we can open it wide and keep it open, but I am now finally hopeful. But remember, any new experience, pure entertainment or educational, are competing for the same audience hours. Only the really great content will ultimately survive. Fortunately, we now have examples of all the pieces. We have great examples of educational experiences driven by AI. We have great educational experiences in compelling open social MMO environments. And we now see great VR experiences as well. I hope and believe that we all, as members of the XPRIZE extended family, can manifest this reality. And since I hope some of you listening will either make or support a team in making this reality come true, I offer a few brief tidbits from my lectures on virtual world creation. For example, do your research. You know, good fortune in my mind is the intersection of preparation and opportunity. Another adage I like to chat about is that no one enjoys an experience that does not run well on their machine. You have to make your experiences stable, fast, and fun in that order. Obviously, if it's not stable, it won't be fun. If it's not fast, it won't be fun. And a final one is that, you know, this work is hard and often bigger teams don't help. You know, your development when you start one can either be on time, on budget, or on quality. And you can only pick two of those. The third one will often go far out the window and support the other two. You know, with that, I will begin wrapping up here by repeating that, you know, I really believe that the challenge and opportunities are both great experiences, which are deeply meaningful, personally responsive and connecting humans to humans for the betterment of all are now possible. This is the time to demand them for our students. This is the time that creators can create them. But the realities of the hit based world of digital experiences must still be met. No half baked ideas will see the light of day, only the best skilled creators driven by passion, supported by strong mentors, and sufficient capital will lead us to this bright future. So I thank you.