There are certain centers, there are certain centers. Our next talk is going to be given by my co-chairman of the Translational Research Day, David Krizai, as a research professor. And he's going to talk about some of the interesting work they've been doing on glaucoma and the treatment of glaucoma.  So co-chair that has been AWOL most of the time. So sorry about that. Go ahead. So I made this slide a couple of hours ago, literally after I saw the title of the preceding talk. And the question is, what do these conditions kind of come in? They look pretty different in a way. But basically, if we look at this, what they do have in common is some kind of a pathological stretching, or swelling, or pushing. So there's some kind of a mechanical thing going on. So what I would like to sort of address in this talk is can we find maybe unified principles in all kinds of diseases that are afflicted in the human bodies? And can we find this through understanding a process that is called mechanical structure? Taking account that pretty much every cell in our body really cares about mechanical forces. If we look at the eye, for example, it is a highly mechanically active environment. So I went to our road this year, and there was a poster showing that just rubbing our eye, or blinking, or getting up from the bed increases our intraocular pressure with hundreds of millimeters per day. So there is swelling going on, activity-dependent swelling. There is pushing, there is stretching, there is the effect of hydrostatic pressure. So what I would like to leave you with is this idea of this being a highly mechanically active environment. Pushing can cause corneal obfuscation, and so on. So there are all kinds of pathological phenomena that have a very, very strong mechanical component. And we are interested in many of them, perhaps most. But what I'll focus on is glaucoma. Basically, when we think about glaucoma, we think about two things. First is, how is IOP regulated in the front of the eye? And the second thing is, what is actually going on in the back of the eye? How do these cells sense pressure? Do they sense pressure, or do they sense stretch, or what is actually going on? This has been a million-dollar question. Thousands of papers have been published. And really, we have gotten no closer to the answer. And this answer is what we are looking for. So how we do this connects the front and the back of the eye. The likelihood of developing glaucoma is exponentially related to the pressure that patients have. So there is something going on with the pressure. Indeed, we can increase pressure artificially in the monkey and look at the retinas. And you see that the retinas look pretty good, except here. There is this huge loss of retinal ganglion cells. So these guys looked at the sensitivity of the monkey. For light of the day, they found that the sensitivity loss was actually pretty minimal until the monkeys lost about 50% of ganglion cells, which is what we see in humans. In other words, by the time we realize we are getting blind, it's already too late. So we really need to understand how this loss caused by the IOP occurs. What is the molecular mechanism? Because that is really the only way for us to diagnose early. And that allows us to treat those patients before this fulcrum fall. So the question here is what is actually going on in the ganglion? And the hypothesis in the field are actually all over the place. Some people believe that retinal ganglion cells are intrinsically sensitive to pressure. Other people say, no, it's actually the glia. And it's the inflammation that kills the ganglion cell. There is a strong strain of thoughts suggesting there is an excitotoxic stress. Too much glutamate is being released for some reason. And some people say, no, it's actually the thiocellus and some kind of metabolic thing that is going on. And this is definitely the case for higher IVBs, which causes ganglion. Another really acrimonious debate that's been going on is whether the first effect on increased pressure is at the optic nerve head or is it at the dendrons? And this is a very important question that still needs to be resolved. So how do we put all of this together? The hypothesis that I'll be talking about today is that all of these things are happening because these cells express ion channels that are sensitive to pressure or to all kinds of mechanical stimuli. We can mimic the glaucoma phenotype simply by activating these channels. And we can protect the retina from hypertension by blocking these channels. Or by genetically eliminating them from ice. So this is what we'll be looking for. We are looking at several types of these channels. What I'll be focusing on today is a channel called Transcent Perceptive Potential Neural Invisal form 4, which is a member of a large superfamily of so-called channel channels. It's a non-selective channel. And what is interesting about it is it's activated by all kinds of mechanical stimuli, from swelling, from stretch. But it's also sensitive to temperature and lipids, such as arachidontic acid.  It regulates uterine, vascular bladder contractions. And it's been associated with mechanical hyperalgesia and neuropathic pain. So something is going on with this channel and mechanical stress. And the null advice were shown to be less sensitive to painful stimuli and to show less inflammatory responses during mechanical injuries. So it's a very interesting candidate to evaluate in a mechanical force-related disease, such as glaucoma. So when we started, nothing was not about it either. What's wrong? So we looked at it, we find mRNA, we find protein. And when we immunostain, we find that it's very strong especially in the ganglion cells. So the red here is a transgenic marker in retinal ganglion cells, slide one. And you see it very strongly co-localizes with 24 antibodies. And the red here is another ganglion cell marker. And you see it's a transcription factor. So you see the only neuron in dissociated preparations of expressiture before our retinal ganglion cells. You also see this green fuss here. These are the end of the feed of retinal mylargia. So we confirm this by immunolabelling with mylargia marker. So why is this interesting?  So we can take a chemical that selectively activates 24 channels. And we can look at what, and we can load these cells with the calcium dye. And then we look what is going on with calcium signals. And what we see is huge calcium increases in response to this channel. And what is amazing to us and really interesting is that the parent of the calcium response in the neuron, the ganglion cell, in the neuron cell is extremely different. So here we desensitize very quickly. And in the glial cell, the signal is huge. It stays on for as long as it stays. Now, what happens to the light response of these cells when we stimulate this putative mechanical channel adenus? So this we are recording an intact retina home out. This is a cell that responds to light with spiking and turns off during light off. And you see the presence of adenus in the cell, it's crazy. Excitability goes on like it's turbocharged. We also see increasing spiking in a cell type that goes on with the light and that goes off with the light as well. So there are also more spikes. And when we actually look at the excitability, which we test by injecting tiny amounts of currents in the cell and in spikes, we see that we need much less current to invoke induced spikes in the presence of the adenus than in the absence. In other words, what this adenus is doing, it is increasing the excitability, making them much more susceptible to any kind of glutamate or any kind of light signal that these cells are going to experience. So producing an excitotoxic stress. Now, this is the case for all ganglion cells. Because when we take the red, now we plug them to a microelectric array, and we stimulate the agris. We see a huge increase over 100-fold in spiking that shows kind of a similar time course that we see with calcium energy. So we are pretty sure that this cell activates excitability, stimulates excitability. What about swelling, which is another mechanical stimulus? Well, when we induce swelling, there is a huge increase in calcium as well. And we don't see it. So this is an increase in calcium when we swell, and we don't see it in the molecules. Now, our red-nose ganglion cells intrinsically sensitive to pressure. Here, we record to single channels in so-called patches. And we can stimulate with very, very defined calibrated possible pressure. And we can induce spikes. And this is very reliable. But when we do longer pulse stimuli, we see, again, inward currents, which are much smaller in knock-out animals, or knock-out red-nose ganglion cells, or much smaller when in the presence of highly selective tricky work patterns. In other words, tricky four is a pressure sensor in red-nose ganglion cells. And when we take it out, they are less sensitive. Now, can we mimic glaucoma? Or can we mimic sort of pressure-induced red-nose cell death simply by activating a mechanosensitive channel? The answer is yes. So when we inject the agonist, this is the control. This is the eye injected with the agonist. There is a huge loss of red-nose ganglion cells. So we can actually reproduce the mechanical phenotype simply by stimulating a chemically stimulating mechanosensitive channel. So what about this question about dendrites versus the optimal head? I would like to say that this is something that we are still investigating right now. We don't have an answer to this. But when we culture cells, and we can see the dendrites, and we can get localized increase in the dendritic calcium level. So we are pretty sure that this is a way to regulate the synapse formation in the inner plexiform layer. And the newest studies published in Journal of Neuroscience are showing that, indeed, the first changes in response to elevated ILP may, in fact, be synaptic. However, when we look at the optic nerve head, the immunostanding is also extremely strong. So it's very likely that by stretching the laminocerosine primates or the real laminate mice, one would activate this channel. So we stretched the substrate. We have a machine that allows us to do that very specifically. We can see huge calcium increases in retinal ganglion cells that are missing in about 70% of cells. In 30%, we still see some calcium responses. So the knockouts show less. Calcium increases. Trips C1 knockouts, this is another type of mechanosensitive channels, are not susceptible in Trips C1 knockouts, but all of them are susceptible to the selective antagonist of Trips C4 channels. So in other words, we hypothesize, we propose that Trips C4 is actually a mechanosensitive channel that is sensitive to pressure and that is sensitive to stretch, and that might ostensibly mediate the effect of hydrostatic pressure, both in the dendritic and optic nerve head. So this is kind of a very simplistic model of what we're thinking about. Overactivation of the channel leads to overload with calcium. And this act is calcium-dependent proteases, caspases, and so on. And we have proven that as well, and leading to some. So what about the second part? What about the glial? So the Mueller cells, in particular, envelope every single retinal neuron. They are absolutely essential for every aspect of retinal physiology. And what is interesting is that they become activated. The first thing that one sees following IOP increase is glial activation together with dendritic and synaptic So what goes on with Miller cells? I will skip over a long period of time of work, a lot of work. I will just show that how incredibly strongly expressed present are Miller cells developing every single retinal neuron. And if you look from the top, you see these little holes. This is where the cell processes of the dendroids and the synoptysis are. So they strongly express TRIP4. And to just summarize our findings, we nailed down the signaling cascade that is associated with TRIP4 activation. Basically, we think that up to four channels, which are the water channels, serve as detonators for activating TRIP4 channels by increasing the rate of swelling during kind of osmotic shocks. But the TRIP4 channels are intrinsically sensitive to stretch and mechanical stress as well. So we are 100% certain that TRIP4 channels are important stress sensors for everybody. Now, what about glaucoma? When we induce chronic glaucoma in certain genetic mouse models or acutely elevate IOP by injecting microbeads in front of the eye, we can get reactive gliosis of these mirror cells. So the question is, can we reproduce this by activating this putative mechanosensitive channel and the answer is yes. There is injecting this adenis induces huge reactive gliosis. So basically, in other words, we can reproduce key-ass retinal elements of glaucoma simply by stimulating a mechanosensitive branch. Now, what about treatment? Can we protect by systemically treating mice with adenis or by eliminating the gene? And the answer is yes. So this is a normal eye treated with PPS. This is eye that has experienced elevated IOP. You see there was a very significant degeneration, about 20% loss of RGCs, which you see here. In mice that were systemically treated twice a day with a high dose of TRIP4 adenis, there was not degeneration. We've visited this many, many times in dozens of mice. And we think this is a fairly solid result. So somehow, blocking the mechanosensitive channel blocks the degeneration that we see here. Now, when we got this result, we were very thrilled. But we started to worry that maybe the effect is actually not at the granular cell. What if we are regulating pressure itself as well? So we tested this. So this is ejection of micro-V to see elevated IOP in mice. And when we systemically inject the antagonist, you see that the IOP drops like a rock and stays down for as long as we keep injecting the antagonist every couple of times a day. So in other words, not only is TRIP4 expressed in the retina, it is also expressed in the front of the eye and it's regulating IOP. Why is this fascinating? Because this would be a way to treat both at the same time, rather than IOP into neuroprotection. So we can get even a stronger effect when we intraocularly eject the antagonist. And you see this lowering lasts for days. We also designed eye drops here at the University of Utah. And these are also effective lasting for day or two, so better than current eye drops. So the important question now is, where is this channel in front of the eye? Is it in the cellular body which produces the fluid? Or is it in the trabecular meshwork or the cellular muscle where that mediated outflowing? You see that trabecular meshwork is much more important because the higher you go with IOP, the more load is going through the trabecular meshwork. Unfortunately, most of the current glaucoma drugs are targeting the uberoscleric component. So there has been a very strong push of looking at trabecular targets. So we published two papers this year showing that it's expressed in bulk, very strong. And we localized it to non-pigment, to epithelial cells. And so we did a huge amount of work on the molecular physiological genetic methods that I will skip over today, just to make point, it's expressed in bulk. But we, for various reasons, we think the trabecular component is more important. So when we do so-called pressure clamp studies, we see that trabecular meshwork cells are highly mechanosensitive. So the ramps of pressure in both directions induce currents, inherent currents. And when we stretch the cells, we see calcium increases that are blocked by the tricky foreign dagonist. These increases are dose-dependent. This is statistics. But what is really beautiful, and here we were saved by a collaborator who can mimic the conventional outflow in nanofibricated devices that have been populated with trabecular meshwork cells. You can do, you can fuse through that, and this has been shown exclusively by them to be perhaps one of the best in vitro models for conventional outflow. So basically, when we do that, we find that the antagonist is highly effective in increasing the conventional outflow facility. So this would be really one of the first drugs that might be targeted the conventional outflow. If you look at the pressure, perfusive pressure on the other hand, the agonist increases it a lot. So this means that the pores in this nanodevice are much smaller because of activation of this channel. This is exactly what happens in humans when you increase the pressure, the trabecular meshwork cells become stiffer, the cytoskeleton and extracellular matrix become upregulated, this increases the pore contractility which further increases out. So is this the case in terms of 54 channels? The answer is yes, because we can stretch trabecular meshwork and you see the actin cytoskeleton and the focal adhesions get upregulated like recently. So we can mimic what has been shown in human primate nanodermal glaucoma at the molecular level. So we also looked at these nanodevice conventional outflow models and we see that the agonist, 24 agonist itself can reproduce the upregulation of actin and upregulation of exocellular matrix. This is highly suppressed in the presence of these 24 agonist. So the model here is that increasing pressure in front of the eye imposes some kind of a mechanical stress that activates 24 channels leading to increased stiffening of these cells and contractility, which increases outflow resistance and maintains or increases at a later time. So what we're doing currently is we are nailing down the very kind of specific components of the cytoskeleton mechanism that link the internal cell cytoskeleton to the focal adhesions and to exocellular matrix. Some things go up during pressure and stress some things go down. And another fascinating approach that we are using is we use FRET probes. So fluorescent probes that function as force sensors. So basically they are stretch sensitive and by looking at changing fluorescence we can tell how much load is imposed on the cell as we are pressing or as we are doing any kind of manipulation as you can see here. The load or the strain is mainly the focal adhesions. So nobody has done really before that in the eye or the brain. So this is really an exciting way to go forward. So I won't go into this but this is what we're thinking is the mechanism that regulates the outer resistance at the level of trigonometric cells. It involves six or 50 enzymes. It involves calcium and gene expression and we have data for pretty much all of these components. Now to conclude, we think that IOP, the 3D4 channels regulates IOP at both inflow and outflow levels although we think that outflow components is probably more important. We think that they also regulate the remodeling that happens during mechanical stress in glaucoma at the level of ganglion cells, the neurons. Anglia, I didn't talk about microglia, they also have these for channels and they also are very stress sensitive. And combined, these events together function to induce the phenotype that we call the glaucoma to speed. What is very interesting, if you look at this, this has very interesting parallels to the neuropathic pain paradigms that we see and other sort of force or mechanical-dependent paradigms we see across the body but they have different names so we think they're different diseases, so to speak. So if I have just one, a couple more minutes, I will tell you about some of our unpublished work which I think is very fascinating as well because I told you about in the fetal cells that may be involved in glaucoma but they also form the blood venavera and are critical for all kinds of other diseases from diabetes to ischemia and the probability of maternity macular degeneration and so on. So we found the expression before, oh yeah, first of all, just to show you, this is in the fetal cell, it is enveloped by a parasite in case of macovascular chair or smooth muscle cell in arteries and that is shadowed by the end-feet of the fetal cell. So this is called the gliobascular unit that is really responsible for the brain and for the retina to be able to function in any way. And when we immunostain, for check before, we see that the fetal cells very, very strongly expressed in the fetal cells and in fact, what is interesting is that they're expressed in the macrobascular, in the retinal, in the fetal cells but not in cordial capillaries. So different macrobascular bands have very different calcium or ion gel signatures which we have explored, but I don't have the time to obviously talk about. One thing which is interesting is that the calcium increases in these cells are enormous. They are tenfold more sensitive to any other cells that we have ever investigated. When we look at the currents, when we look at the calcium, so they really, really, really care about mechanical stimulation. So we, in collaboration with Dean Lee here at the University of Utah, we can look at now a model of blood-threatening barrier by doing high-profile impedance studies in monolayers of these macrobascular cells. You see when we use the agonist, there's an enormous increase in percolability in bascolar percolability, just like crazy. So, again, suggesting that these cells really care about mechanical stimuli and that should be for channel is a potentially major regulator of permeability. Now, we nailed down, we believe, the molecular mechanism of this, so that the permeability of blood-threatening barrier, or the brain barrier, is mediated by V-catering, beta-catering complexes and occluding complexes. And we found that the 24 agonist triggers a retraction. This is V-catering, this is V-catering, I believe we're acting, beta-catering. A retraction of these complexes towards the interior of the cell, which is directly correlated with increased permeability across these intercellular regions. So, again, this is something we are exploring very actively at the moment. And this is kind of the model of this gliobascular unit, because the interesting thing here is that 24 is very strongly expressed, and in the vasculature, and we believe it's regulating and controlling the flow of metabolites and swells pressure sensitivity within the brain. Now, when we treat any disease, we don't want to treat just any target within it. We want to choose the targets where many signaling pathways converge so as to treat several symptoms at the same time. So, I propose that in terms of treating glaucoma, trip before is a very convenient and reasonable target because, first of all, it's expressed exactly, exactly in cell types that are most effective in glaucoma. It is associated with transduction of mechanical forces and stimuli that are highly relevant for glaucoma. And by treating this or targeting this channel, we believe we could alleviate a lot of the phenotype that is associated with the disease. Here, I would just like to mention that most of these diseases that I plotted here, I plotted because I already knew they are associated with trip before dysfunction. Some of them with trip before mutations which are associated with pathological load bearing with sensory motor neuropathies with neuropathic pain. I don't know about intracranial hypertension, but I will not be surprised, especially because they interact a lot more and it's very strong. So, basically, we think or I'm thinking that if glaucoma is just an ocular version of neuropathic pain, so to speak. It's a kind of a semantic switch that perhaps we could make, especially once we better characterize what is going on in terms of signaling and symptomology. So, Tam, for one, was involved in pretty much all the aspects of the work that I was talking about today and she is really spearheading the endothelial project and driving with her ideas. Everything was started by Dan Riscan who was a grad student in the lab and he kind of started this train rolling. Sarah is working on micro-healt. Oleg and Maxime are electrophysiologists who have done absolutely spectacular work on mechanical introduction. I think this is really, in terms of neuronal stuff, something that nobody has done even in brain neurons, stuff that we're doing right now. Andrea is doing phenomenal work now in steroid glaucoma that I didn't talk about. Andrea, where are you? Here she is, yeah. So, and Andrea has been working in acuporins and swelling and stretch assays and I have to mention here in public Dr. Olson because I am a photoreceptor guy and I wouldn't be talking about glaucoma if it wasn't conversations in support from Randy. So who basically said go ahead to some of the crazier ideas that I had and without that those crazy ideas would go to nothing. So I had no support when I started those studies and with support from Randy this actually started to lose. Sorry for that.


Okay, it's 10 after 5.  That's the one thing I want you to take away from this presentation today. Detecting problems in your code before it actually becomes part of your larger code base. Hi there, my name is Evertaves. I'm a developer advocate at Rackspace. Now I get the question enough, just what is it a developer advocate do? What do you do all day? I get the question enough that I could spend a minute at the start of the presentation just kind of saying what it is I do. So first and foremost, I am a developer. I write code for some portion of my time. Sometimes it's 20%, sometimes it's 80%. Just kind of depends week to week, month to month. Whatever is going on. To that end, I'm a project management committee member and committer on a open source Apache project known as JClouds. This is a multi-cloud toolkit that works with many clouds out there, all the big clouds out there, including OpenStack and Rackspace and HP and all the OpenStack providers and Google and Microsoft and Amazon as well. The advocate person. He's the guy doing the song and dance before you today. He's the guy that goes out into the world wherever the developers are, conferences, user groups, meetups. And not only am I advocating for our technologies, you know, JClouds, OpenStack, Rackspace, et cetera, et cetera, I'm advocating for you, our users. I wanna hear about the experiences you're having using our developer tools and especially if that experience is bad because then we can improve it. I can take that feedback and feed it into our product teams or take it into the tools that we're responsible for directly. And this is me giving you a presentation right here, right now at the OpenStack Summit. This is me, okay. I've also done a bit of operations at my time. In a previous job, I helped build the first OpenStack cloud in Canada with one region in Alberta and one region in Quebec connected by a high-speed research network. And I later found out that this was actually the first OpenStack cloud built outside of NASA. We adopted it very early. And now I work at Rackspace. During the course of a week, five days, I along with some other co-authors helped write the OpenStack operations guide. And, you know, we spent the last day, day and a half editing it down, trying to get something readable out of it. And that's the version here on the left. And then O'Reilly got wind of it and they kind of grabbed it and turned it into a book and actually edited it down so it really made sense. And now I very much consider myself just a contributor to it because we've released it to the community. Anyone can participate in the creation of this book and make it better. You can download it here or buy the dead tree version, whatever floats your boat. And there's really no need to write down URLs or anything here. I'm gonna make these slides available after. And there will just be one URL you need to remember. Okay, so continuous integration. How many people here are practicing continuous integration right now? So half. So those people can kind of keep their hands up. How many people here know what continuous integration is? So just about everybody. Okay, so I'm just gonna quickly zoom through a definition so we're all on the same page. So it's really part of your software development life cycle or SDLC. It's really a very fundamental and crucial part and if it isn't, it should be. And hopefully you can take away some tips today to make it so. It's all about integrating code from many developers working on the same project, bringing their code together in the same base and integrating it. Now the definitions are always kind of fuzzy on just how frequently you should be. Like they say, I don't know, every few minutes, every few hours, a few times a day. So I would like to advocate that you do it with every single change to your software. Every single change that happens in your software should go through the continuous integration process, no matter how small. Naturally, this is all brought together in a shared code repository. Subversion, Git, Mercurial, what have you. The same place where everybody's bringing their code together to work on it, to create, say, a web application. Now you need somewhere to automate the build of your software to actually bring it together, to continuously integrate it and build that software. So you have servers out there that do this sort of thing like Jenkins or Travis or Shipit, I think is another one. One of the core aspects of doing continuous integration and running that automated build is running your tests. Your unit tests, possibly even your integration tests, if you can automate those as well. But it's really important to know that your test run, that gives you a much, much better indication of the quality of that change that has been made. So again, coming back to detecting problems before they become part of your code base. This to me is the fundamental core principle of continuous integration. If you can prevent a problem before it becomes part of your code base, you're much, much better off. You have much higher quality software, which is something that we all desperately want. So now I'm gonna talk about continuous integration for applications on OpenStack. Now there's a huge, gigantic, sweet continuous integration suite that OpenStack itself goes through in order to become OpenStack and in order for people to make changes to OpenStack. That is not what I'm talking about. I'm talking about the developers who are building applications on top of OpenStack, who are deploying their applications on OpenStack Clouds and doing continuous integration on OpenStack Clouds, not OpenStack itself. So who are the players in this story? It is Jenkins. It's gonna be our continuous integration server that we'll be using. We'll be using a plugin for Jenkins, the JClouds Jenkins plugin. GitHub will be our shared code repository. And of course, our cloud is going to be OpenStack. This is where it all happens. So let's take a look at this from the developer's perspective. That is the developer who is actually creating that application on OpenStack. Say it's a web application for doing event registry, you know, like event bread or something. People are building that on your OpenStack Cloud. Okay, so here we've got some of our players. We have our developer, GitHub, and a cloud. The developer, eh, you know, maybe they don't even really care what cloud they're running on. They just know they're running on a cloud. They're getting resources and using that to build their application and deploy it. So that developer wants to make a change. So they submit a pull request to GitHub. And then, we're not even really too sure. Something else happens that triggers some sort of magic. This magic goes on for a little while. Not really sure what's happening there. And then at the end of the magic, there's some result. And you get notified in GitHub of what that result is. So again, you know, continuing with the developer's perspective, they issue a pull request. And how many people here are familiar with GitHub and pull requests? Okay, pretty much everybody by now. That's good to hear. So as we know, a pull request is kind of the, what I consider the basic currency of contribution in a shared code repository. So they go ahead and they make their change and they create their pull request. My change, I'm trying to commit it to master. I've got my branch, my change at the very top.  And then some happens, something else happens, magic at this point. And at the end of it, I see in my pull request that it's waiting to hear about this commit I made. Merge build started. Okay, sounds good. That sounds like some magic that's happening somewhere that I don't know where. So after a little while, you get the result and it looks something like this. Blah!  My build failed. And I get this message at the bottom, you know, failed in red. You could still conceivably merge this pull request, but there's a problem with it, right? So at this point, the code that I submitted, the change that I submitted has been merged with the larger code base, not made part of the shared code repository yet, but, you know, merged within our continuous integration server. The test ran, you know, the code was checked for code style problems, something failed, something went wrong. So now I just need to click on the details link, and that takes me to the console output of Jenkins. And so I can immediately, wow, after scrolling for much, much output, I can find out exactly what it is that went wrong. And once I know what went wrong, I can go back and fix it.  So I fixed it, whatever it was that was wrong. And now the continuous integration ran again, and all is well. Good stuff. Now I can merge that pull request, make that code part of my code base with much more confidence. There's no guarantee it's perfect. There's no guarantee it's right, but you have much more confidence now that this is a quality change being introduced into your code base. And of course, as part of the whole pull request procedure in GitHub, whether you're using GitHub public or private, is the code review. You know, that's an aspect that you don't want to ignore either as part of your changes. So as you're going along, not only are you looking for the result of your continuous integration, you need more eyes on that code too. You need more people looking at it to making sure it is a good change and appropriate for your project, for the web application that you're building. And this is an example of a good change where you kind of knocked it out of the park on the first try and everything passed, just to contrast it with that initial failed build change. Okay, thank you for sticking with me for this long. Let's take a bit of a brain break for a bad slide. This is a terrible slide. I start with Comic Sans, obscured text that you can't see. Old outdated internet memes and terms that nobody uses anymore. Video with no sound. This is me. I live in Austin, Texas now. I went to a Maker Faire with my family. And you go to a Maker Faire expecting to play with Lego or Raspberry Pis or computers and soldering and putting things together. The first thing that we saw there was a 60-foot scaffold and people jumping off it. A stunt camp had set up shop and we're having people jump off this thing. So to my family's credit, my six-year-old, my eight-year-old, and my wife-year-old all jumped off this thing, including myself, and it was just a really bizarre way to start a Maker Faire with this jolt of adrenaline. Okay, so now that we've taken a little break, let's look at this from the operator's perspective. So this may very well be you. So who here is kind of responsible for administrating the resources on their cloud? Okay, so, Han, so this certainly applies to you and it's also good knowledge for developers to have as well, to have some idea of what's going on in the background. This is also a role that can be fulfilled by, say, if you wanna call them a build master, somebody who's responsible for creating all the artifacts that make up your software project. They can also fulfill this role. So again, we have the same players, but now for sure we know that we're using an open-stat cloud. That we know for sure, because that's why we're all here. So we have, again, our developer creative pull request, but now, because we're under the hood, we know that a webhook is being fired from GitHub to our Jenkins instance. And we know that Jenkins is our continuous integration server. And at step three, a build is happening on one of our worker machines. We're not necessarily building on the Jenkins master itself. We've created a pool of workers to pull from or dynamically create. And once that's done, Jenkins feeds back the result to GitHub. Okay, so the reality of this is that it is really very complicated to actually set those steps up. And it's really more detail and more complexity than I can kind of reasonably deliver in a presentation like this. It's really more of a workshop, a hands-on kind of workshop thing. So what this is here is a link to this blog post on the developer.rackspace.com page. And this is a very, you probably can't quite see the scroll bar here, but quite a lengthy blog post on how to set up Jenkins on an open-stat cloud. The example happens to be on Rackspace private cloud, but that's just open-stack. And this works on vanilla open-stack anywhere you can find it. The reason I put this here like this is because when I encounter a blog post or a knowledge-based article or whatever it is, I like to see everything at once and put things side by side. So as I'm working through the blog post or whatever it is, the instructions, I have the things that I'm working with on the left-hand side. And you can see I have them in the tabs up there. Either this is all on one screen or you've got multiple monitors. And this is probably common sense, but I've seen enough people not work like this where they flick between screens that it kind of makes me crazy. So just a little tip when you encounter a lengthy kind of one, two, three instruction-style blog post. So again, this is a link that takes you to this blog post. What I'm going to give you here is kind of the high-level overview of the steps you need to take to set this up on open-stack. Okay, so first off, you need a server. You need to create a server for your Jenkins master. Then on that server, you need to install Jenkins. And this is just a matter of setting up a specific repo and getting the latest and greatest Jenkins rather than installing whatever the packaged version is for your Linux distro. You definitely want to secure Jenkins. Out of the box, it comes unsecured. If you're working through the UI, you just want to go out and do it directly first thing. You can script that as well, which is also recommended. Then you need to install a handful of Jenkins plugins for working with GitHub. And they're all specified in the blog post. It's the GitHub plugin, the GitHub OAuth plugin. So you can use OAuth tokens and GitHub and the GitHub pull request builder. There's a special plugin just for working with pull requests. Then you create a Jenkins job. This is the job that's configured to actually build your software project. Then you need to kind of fiddle a bit in GitHub itself to allow access to Jenkins and allow Jenkins to access GitHub. And there's definitely a fair amount of fiddling going on here. And in this case, I think the complexity is warranted because you're establishing trust between two systems. And you need to make sure that all the bits and pieces are in place so you don't get hacked, basically. Now, if you're running all of this behind your firewall, if you have your private open stack deployment, then that sort of thing might not be as much a concern because you're running behind your firewall and you've got a whole team worrying about security just keeping people outside of your firewall. But you know what? It's not a bad idea to also pay attention to security for your internal systems. You always want to consider security in depth. You want layers of security in your organizations. Okay, so I've been going on and on about pull requests and building pull requests. But the reality of it is at some point, people are just gonna commit directly to master and skip the pull request process. It's true. It's not a good idea, but people are going to do it. And maybe sometimes it's warranted. Maybe it's a trivial change. So they just wanna go, boom, I'm fixing a spelling mistake or whatever it is. They're just gonna commit directly to master. So you do need to configure your job to also build on commit. But this is really what you wanna do. This is what you wanna focus your energy and effort on. And that's building whenever a pull request is issued to that shared code repository. So now we've got Jenkins and we've got GitHub and we've got kind of all the machinations completed there.  What if we wanna be a little more intelligent about how many jobs we're running and the capacity that we're using in our cloud? If we can run our jobs in parallel, then developers don't have to wait as long to see the results of their commits, of their pull requests to that repository.  It's a big complicated system. Lots of tests, lots of dependencies. You don't want all those builds coming into a queue as developers are making changes. Ideally, you could run all of those builds in parallel rather than running them one after another. So here's how you create Jenkins workers using the Jclouds plugin on Rackspace private cloud. Again, just open stack. This is another link to a blog post that I literally finished writing last night and got published today. So it's hot off the press and this is how you configure Jenkins to create workers for you. First, I show you how to do it manually and then dynamically so it kind of helps you understand it a bit. Again, a little too much detail to get into right now. So I'll take us through kind of the high level steps. First of all, you need to install the Jclouds plugin. You need to add a new cloud as Jenkins terms it. You go into a configuration page and you add a new cloud and it's the Jclouds cloud. It's kind of a funny terminology. Then you create an instance template. This is a template that is responsible for building your application. It's how your instance starts up and this instance is responsible for building your application and running the tests that are part of your test suite doing the continuous integration. So once you have that template, you want to test it out because you have to know that it can actually build your project that it actually works properly. So you do a manual instance creation.  And if it blows up, you get a stack trace and an error page and you can see what went wrong. So now that you've got this instance, this one lone instance, you want to test it and make sure it can actually build your job. You've created it. Now you actually want to run a build on it so you know that it's capable of building your job. After you've determined that, that this template is good and it can actually build your job, then you can take a step back and delete the thing, say, okay, I know this works.  So this is where, as build jobs are coming in, you're creating workers for those build jobs. Developer makes a change, webhook fires to Jenkins. It creates a worker and runs a build on it, runs all your tests and everything and then the result comes back. So let's see what that looks like now and fill in the blanks. So again, here's what I just described. This whole process of the continuous integration life cycle in your software project, putting it all together, the pull request that we saw before. So now we know that it's actually a webhook firing from GitHub to Jenkins saying, oh look, here's a pull request. In your repo in GitHub, if you click on settings and then go to, on the left hand side, you'll see a menu for webhooks and applications or something like that. You can actually then drill down into the requests that GitHub has sent to your Jenkins server and you can see here at the top all of the headers that are sent in that request and then the payload, the body of the request. So there's just a ton of information in this payload. It's all the information that any, practically any client continuous integration server would require to build your project. But really the key here is that there was a pull request and now I'm firing this webhook off to Jenkins so you can do something about it. And build your project. Step three. So this is kind of the status page of Jenkins for the jobs. And as my example, I actually was building J Clouds itself. I forked the project and submitted a change to my own fork of the repo. Did the whole pull request process. And then I had an instant spin up dynamically to run the tests in J Clouds itself. So it's like I'm using J Clouds to build J Clouds here. Some nice inception going on. And you can see the progress of the build. And finally, from the developer's perspective as we saw before, you get the result. Whether or not it was a good change. Whether or not there were any problems, attempting being introduced into your code base. So now that you're doing continuous integration for your applications on OpenStack like this, what's next? What are some of the next steps you can take after you've gone through all of this stuff? And there's quite a bit there to do. Well, you could conceivably instead of, you know, you create that server and then you install Jenkins on it. You could actually turn that into a heat template. And in fact, lots of these heat templates already exist out there.  The creation of your continuous integration server becomes much more reproducible, much more repeatable. Now here are a couple of my favorites. Again, these are links. Hijacking the build pipeline. This is the slide deck from a colleague of mine, Kyle Kelly, talking about security. He's very much into security and he came up with this great talk that he did at DEF CON about how if someone knows kind of your continuous integration pipeline, there are ways to insert themselves into it and actually hijack it and take it over.  They introduced the code that they change is simply printing out environment variables. And they're phishing for things that could be printing out the environment variable password and then they'll do a bad change so that they see that Jenkins error page. And at the top is gonna be, oh, here's what the value of that environment variable was. And there's lots of ways that you can secure against this, but I just want to impress upon you that if you're doing this stuff in public or if you're doing it in private, you wanna think about security and find ways to prevent people from hijacking your build pipeline. Another good one from a colleague of mine in the J Clouds community, Andrew Bayer. He actually works for Cloudera. He's responsible for building the Hadoop distribution that Cloudera produces. And he's pretty much a build master over there. And he has a great talk called, hello, AV guy? Is that me? Hello? Okay. Little glitch. Okay, well, we're almost done here so let's get through it. Okay, so anyway, he's got this great talk, seven habits of highly effective Jenkins users. Lots of good advice in here. Just tons of good advice in here. And he gives this talk at Jenkins conferences and when CloudBees goes out to present at conferences, they fly them out there. So the key part, this one, the key takeaway for me for this one is automating a lot of the Jenkins dials and knobs and levers and pulleys. There's so many of these things on Jenkins you wouldn't believe. There's an UI element for each one of these things. So if you can, you can use the Jenkins API, the application programming interface or the Jenkins command line interface to automate a lot of this stuff. So again, that's speaking to making the creation of your continuous integration server a lot more repeatable, a lot more reproducible. So once again, the whole point of this, all of this work is to improve the quality of your software projects that you're producing for OpenStack. These web applications that you're creating on OpenStack, all of these different things that you wanna do on OpenStack, they can be higher quality when you introduce continuous integration into your software development lifecycle. So detect problems before those problems become part of your code base. I will be making this presentation available at that short URL right there. That's the one and only URL that you need to remember from this presentation. Does not work right now because there's nothing up there. So, but I'm hoping that this evening I'll have a chance to upload the presentation and put it up there. You can find it at that URL, that short URL. If you wanna try this stuff out on a public cloud, massively scalable OpenStack public cloud, check us out on developer.rackspace.com where you can sign up for our Developer Plus program and that lets you kick the tires for free on our public cloud for $50 per month for 12 months. Thank you very much. I'll take some questions now. Just a question. If you have bills that take, say, 10 minutes to do, what happens when you get one commit, you start doing the build and you get another commit? Do you start doing the second build immediately with all data or counting the first commit? So there's a configuration piece in the, I believe it's the job configuration page called Single Use Slave or Single Use Worker and the terminology I was using here and that ensures that you only ever use a worker once and then you discard it. So that's one way to avoid that situation. I'd have to toy around with it a bit more but it should spin up. I was thinking about conflicting commits. Oh, conflicting commits. Yeah, so that the first one would work but the second one applied to base will work but the second one and the first one will not work. So you'd still have to have it bisecting, something to do bisecting afterwards. Oh, so like from different developers? Oh, from different, yeah, okay. So I mean, in that case, like if they don't have any knowledge of each other at that point, then they won't actually see the change. The continuous integration won't see the change but I think I know what you're saying in that, this kind of comes back to how you manage your software development. If you were to have something like, if you were managing your development, your integration with like feature flags and everyone's just constantly committing into master rather than everybody having their own feature branches. Like when everybody has their own feature branches, yes, you get into this situation that you described but if you were to do feature flags where everybody's constantly committing to master, constantly all putting into the master branch, then that'll make the developers aware of each other's changes a lot earlier on. So that's one way to avoid that scenario. Do you mind asking into the mic if you would? We're using OpenStack. So why do you need the Ajay Clouds abstraction layer except for the fact that you're a contributor? Yeah, no, it's just one way to spin up workers is the answer. It's one way to spin up workers for your builds. There are other ways to do it. You could manually provision a whole bunch and not even use Ajay Clouds at all. I just find that it's a convenient way to go about it. And yes, that was the next point, thank you. You can use it across different clouds. You can build on any cloud that Ajay Cloud supports. I'm not using any hosted services, so I'm using GitLab, not GitHub, and everything's internal. Why should I run Jenkins in the cloud instead of just deploying it on bare metal? What are my motivators for deploying in the cloud and dynamically allocating sleeves? So in this particular case, it is that you said it right there, you hit the nail on the head is the dynamic nature of it. It's being able to create workers as you need them. And I kind of forgot to mention, it also removes those workers when they're not used anymore. There's a retention time dial in there. So if you only have five bare metal servers for your continuous integration cluster, then you can only ever have four builds running at once. And honestly, they're probably using some small portion of the CPU, or you could dynamically create many virtual machines in order to run your builds in parallel. Does that answer your question? Sort of? Yeah? Is the dynamic nature in being able to parallelize your builds? In this case, pretty much so. Does anybody have anything else that can help? Okay. Oh, I see. Is JCloud's plugin specific for Jenkins or it works with, let's say, Bamboo? This particular plugin's, yes, specific to Jenkins. The question was, is this used in Cloud Foundry? And the answer is no, not to my knowledge. Okay, thank you very much, everyone, and have a great time for the rest of the summit.


Yeah, we on boss talk one on one. Yeah, we gonna talk. Yeah, it's your boy marvelous jobs Make sure y'all check out my interview on boss talk one-on-one with eco. Miss Jamaica and money Moses If you if you've been on a YouTube you definitely can't miss this guy, man He's a known figure now for me and for a lot of people according to the views that he get My guy marvelous Jarvis is in the building. What's going on my brother? What's going on man, what's going on man now seeing my brother he's a he's 10 years older than me So he raised me kind of like, you know, okay like that. So he the one put me in boxing So this is going back to the question like so pretty much my brother. He put me in boxing He's all are you when you started boxing? I think I was like 14 I was younger than that, but like when I started like When I signed up for actual gym, I was like 15, you know, 14 15, but I was fighting on the streets, you know Were you any good? Yeah, did you win all the fights?  How did that happen? How did you end up doing that? I mean how many times you got whooped over there trying to get A lot of time a lot of time.  Yeah, like he's been a rival of mine Since we was kids the rivalry broke by the time he went to the Olympics didn't cuz I quit boxing I want to talk about your the comedy I want to talk about How you came up with doing the skits the way you do how you and and what make cuz you've driven the numbers up You got over how many subscribers on YouTube? 320,000 and then also Just how do you like I know the people change the girls that do the skits with you the guys that do the skits with People changes this relationship driven. I'm just trying to understand Where did the sense of humor come? Yeah, just give it give us a spell man. Give it up like how I got into Yeah, how you got into it and then we're going to the other side of that doing music videos for people I started doing music videos for people so I would do music videos for Courage shows are IP course man and brothers just on here. We gave more war. Yeah dope So I would do people videos for him Trap boy Freddy Trap boy shout out Trap boy Freddy you need to come on the show man. Stop playing Just different people like that in my neighborhood, you know, yeah by this time I moved from Overtime side to Woodtown. Okay, I've been in Woodtown, but some some plus years. I went to high school at Carter I'm always in a long relationship like I'm always in a long long What does how does she feel about all the like kids and the females even my ex before that didn't like it Yeah, but what about when the chicks coming? I say that all the time But it's acting Like it's acting. She like but you got the power to write what you want to write and this is what you choose the right That's what they always say like But then at the same time we've we've interviewed a couple of comedians and they'll say well Sometimes they try to drift from what they're currently doing to please the please that person or to please just to be different But they're like the crowd doesn't like it. They don't like it What they like is what you put out man. Oh my god, so I tried to like stir away from what I was doing to do something different I promise you I got like I got 300,000 subscribers.  It's more of this job is we at boss talk one on one where the bosses talk Make sure y'all check out my interview and it's going down marvelous TV