How can a regular person be talked into committing heinous acts upon another? And could you be convinced to potentially injure or kill someone else? I'm not talking about self-defense or during war on the battlefield, but someone you have never met before and have had no interaction with previously. How can perfectly normal people commit genocide? Like what we saw in the 1930s and 1940s in Europe, or even in Cambodia in the 1970s amongst other events. What causes people to be active participants in crimes against humanity? If we take Germany in the 1930s as an example, what caused a large part of a modern country to be willing in crimes against people that have been their neighbours and community members for years? It is a really fascinating thought experiment, as when you think to yourself I could never do something like this or even this. But what would it actually take for you to pull trigger, push a button or pull a lever? Well this is where a psychologist set out to see what would be the minimum amount of suggestion for a regular person to administer a potentially deadly electric shock to someone they have never met before. The simple but effective study would be known by the inventor's name, the Milgram experiment. The actual experiment would not result in any physical pain, but extreme stress and inflicted insight to the participants. And this would create controversy with the study. As such I'm going to rate it here five on my ethics scale. This is mainly due to it being a fascinating dive into our hard-wired ability to obey an authority figure even to the point of murder. Welcome to the dark side of science. Stanley Milgram was an American social psychologist born on the 15th of August 1933 in the Bronx, New York. His parents were Jewish and have fled Romania and Hungary during the First World War. His background and family ties to Europe would have an important effect on his later studies into social psychology. As word came back to the Milgram family during the late 30s and 40s of the atrocities inflicted by the Nazi regime. Although in relative safety in the USA, many of Stanley's family members were directly affected by the Holocaust. After the war some surviving members of the family came to stay whilst finding a new life in the US. A young Stanley was exposed to the horrors experienced by his relatives and this would stay with him, igniting an interest into the darker side of human nature. In 1954 Milgram received his bachelor's degree in political science from Queens College in New York. Initial applications to Harvard for psychology masters were rejected but was eventually admitted. The initial setbacks were due to Milgram not taking any undergraduate courses in psychology at Queens College. In 1961 Milgram received a PhD in social psychology. He became an assistant professor at Yale around the same time. Later on he served as an assistant professor in the Department of Social Relations at Harvard from 1963 to 1966 and this brings us very quickly onto his obedient study more commonly known as the Milgram experiment. Stanley's experience of relatives going through the Holocaust coupled with the arrest and trial of Adolf Eichmann in 1961 sparked an interest into finding out what could make seemingly average people take part in atrocities. Eichmann organised the logistics of the deportation of Jews during the Holocaust. He made deportation plans down to the last detail. Working with other German agencies he also determined how the property of deported Jews would be seized. What was interesting about the trial was that he claimed he had not dictated policy but only carried it out and that he was merely a cog in the machinery of destruction. Essentially the I was only following orders defence. This highlights the question that is following an order enough to convince someone to do something so heinous. Milgram would later say in 1974 when explaining the experiment could it be that Eichmann and his million accomplices in the Holocaust were just following orders could we call them all accomplices? The experiment was pretty simple and would make use of three people the experimenter who was in charge of the session the teacher a volunteer for a single session and a learner. Both the teacher and learner would arrive for the session together and they would draw straws as to who would take each role. Participants were sourced via a newspaper ad saying we will pay you for one hour of your time in a study of memory. The teacher and learner after finding out their roles were taken into a room where the learner was strapped into what appeared to be an electric chair and electrode paste was applied to the learner's wrist to prevent blistering and burns. The teacher would hear this being explained and see this happen. The experimenter who was dressed in a lab coat in order to appear to have more authority told the participants that restraints was to ensure that the learner would not escape. The teacher was allowed to experience a sample electric shock similar to what the learner would feel. Before beginning the experiment the volunteers were informed that they would be paid regardless of the outcome thus removing any financial incentive to any results. The teacher was led into another room where they could not see the learner but could hear them and the experiment would begin. The teacher was then given a list of word pairs that he was to teach the learner. The teacher would then read the first word of each pair and read four possible answers. The learner would press a button to show his answer. If incorrect the teacher was meant to administer a shock to the learner. If correct the teacher would read the next pair of words. Each subsequent incorrect answer would mean the teacher had to increase the voltage in 15 volt increments. They were also instructed to announce the voltage before shocking the learner. Pretty cruel you might think but there was only one actual volunteer in each test, the teacher who unbeknownst to them was the real test subject. You see the learner was actually a stooge and wasn't receiving an electrical shock and the chance drawing a straw was to find out who would do either role was actually fixed meaning the teacher would always be the teacher also probably not surprising the experimenter was also in on it. This meant that the whole experience of the teacher was controlled from the authority of the experimenter to the reaction of the learner. To ramp things up in later versions of the study the learner would also shout out in pain when the voltage got too high. The experiment would have a preliminary and a regular run. The first was a practice of sorts where the learner would get three correct answers and seven incorrect ones which would yield a shock up to 105 volts. The second or regular run the teacher would be told to read off a list of words and had to continue repeating it until the learner had gotten all of the pairs correct. The volt dial range from 15 to 450 volts and to add further explanation for the teacher was labelled slight shock to danger severe shock. About 300 volts the learner would kick on the wall and then no longer give answers to the teacher's multiple choice questions. If the teacher showed any hesitation the experimenter was able to give one of four prodding responses in sequence. The first was please continue or please go on followed by the experiment requires that you to continue and then it is absolutely essential that you continue and finally you have no other choice you must go on. The experimenter could only progress to the next prod if the teacher refused. If all four responses were reached then the experiment would end if not it would continue all the way up to 450 volts. If the teacher asked any specific questions the experimenter could reply for example will the shock leave any permanent damage. The experimenter could then reply with although shocks can be extremely painful they cause no permanent damage. After the experiment an interview would be undertaken and the question how painful do you think the last few shocks you administered were. The teachers were instructed to indicate their answer on a scale between one to 14 after which the teacher was reintroduced to the learner and the experiment was fully explained. The experiments began in July 1961 at Yale University and 40 subjects would volunteer through this newspaper advert and the results would surprise all predictions. The 40 men were from a cross-section in society from various different age and career groups ranging from 20 to 50. During the experiment most test subjects showed signs of severe distress when administering the electric shock. They observed sweating, trembling, stuttering, biting their lips, groaning and digging their fingernails into their own skin. The discomfort seen shown that the subjects were aware of the pain the learner was experiencing. Pre-experiment it was expected that only a small amount of the subjects would administer the high-voltage shock between one and three percent but this prediction would be way off. Of the 40 subjects all reached 300 volts at which the learner would bang on the wall and stop giving answers. Only five refused to go beyond this point. Four more went on to shock the learner one more time and then also refused. Two stopped at the 330 volt level and one each at 345, 360 and 375 volts respectively meaning that only 14 refused the experimenter's prods. This meant that 26 proceeded all the way to the end giving the highest available shock to the learner although most showed signs of discomfort and stress they still obeyed the perceived authority of a guy in a white lab coat. The results were understandably unexpected as from a young age we are taught to not hurt others but with the addition of an authority figure the teacher would abandon this fundamental part of their moral fabric. Scarily there was no punishment for disobeying the experimenter nor was there any reward for completing the experiment as payment was assured from the start. Even more strange was the results were similar when a control study was undertaken with 43 unpaid students. In Milgram's paper into the study he highlighted several particular conditions of the experiment that might have contributed to the high level of about 65 percent of compliance to the highest voltage level. The fact that the study was being undertaken at and sponsored by Yale possibly reassured subjects that the experiment was aboveboard and reputable. The perceived randomness of the selection of learner and teacher also could have factored in as the teacher may have thought that he could have been in the other chair hence he was exposed to the same risks. The subject may have also have thought that as he had volunteered that he was obligated to help the experimenter and to the same extent that the learner had also submitted to the authority of the experiment. The subjects were also reassured that although painful the shocks were not deadly and that compliance was built through to shock level 20 when the learner would no longer reply. To refuse would cause a conflict situation where the wants of the learner and the experimenter were at odds with one another and decide would the experimenter was the path of least resistance so to speak. The short duration that the experiment ran for meant that the teacher had less time to think about the actions resulting in little time for reflection. Milgram would repeat the experiment in several variations to see if any of the conditions change would yield different results. Even when Milgram conducted the experiment in an unregistered office far away from Yale the results were fairly similar. Now to the ethical question was the experiment cruel? Well in my opinion no but it can leave long term distress to the teacher especially if they administered the full shock. For many the experience left self-reflection on how they had submitted to the authority of the experimenter. Ethical criticism came from the allowed discomfort of the test subjects where even though they had provided their consent the experiment should have been paused when the distress was observed. However in his 1974 book Obedience to Authority an experimental view pushed back on his detractors saying that the ethical criticism provoked by his experiments was because his findings were disturbing and revealed unwelcome truths about human nature. It is really open to debate as whether the experiment was ethical or not but regardless it was a fascinating dive into human nature. The study would later be compared with another controversial experiment run by one of Milgram's friends, Philip George Zimbardo at Stanford. But that will be a subject for another video. Thanks for watching I hope you enjoyed the video. This video is a plain difficult production. All videos on the channel are creative commons attribution share alike licensed. Plain difficult videos are produced by me John in a sunny southeastern corner of London UK. Help the channel grow by liking commenting and subscribing and check out my Twitter for all sorts of photos, nods and sods as well as hints on future videos. I've got Patreon and YouTube membership as well if you fancy supporting the channel financially. And all that's left to say is thank you for watching.


Buddy hi everyone. This is George cow. That was buddy. So today.  I Want to thank Donna for Giving me that idea. She was commenting on my lessons learned from making a hundred videos and she said oh basically It's keep it simple and sincere kiss. I said it's exactly right and I'm going to share that so So don't keep don't make your content project so intimidating Even if it eventually could become a book or could eventually could become a video course or whatever could become Every day that you make content you can keep it simple and sincere What are you simply trying to say? Say it and as sincere of a ways you can sincere is simply How can this be of true service to the people I'm talking to how can I speak in a way that? Shows my sincere desire to help them That's all keep it simple and sincere and you will find yourself enjoying the content process and Creating something over time that could become something amazing so I hope this is helpful and Always open to your questions and comments until the next video keep it simple and sincere Take care


Hi everyone, Joe for jazby's casebricks.com coming at you with 2016 Donner's Optic Football Hanger box break number 11, Ram team break number with six flawless spots being given away should be pretty nice. So we'll do that at the end of the break with a different dice roll. Also, we just have to do one more of these. It's already on the site. We have to do break 12, think a few spots straight up, and then we can lock that in to tonight. That should be a lot of fun. Let's get that done. All right. And there's everyone here. Thanks for giving this a shot. Might be something in the break here, too. That could be pretty fun. Let's roll it, randomize it, six and a two, eight times for names and teams. One, two, three, four, seven, and eighth and final time after eight, we got Robert down to Don. Six and a two, eight times for the teams, one, two, three, four, and eighth and final time, Dallas down to Baltimore. Dallas is a nice team to get in a 2016 break. All right. So here's the first half of the list right here. No trade windows in this sort of stuff. These little side breaks. Here's the other half of the list right here. Good luck with the break itself. There could be some surprises in here. Sort by Colin B. Box these up. Here's the final printout right here. There's a little Jay Cutler. DeMarcus Robinson, D-Rob, Cody Kessler, and Zeke O'Elliot. There you go. Nice and for the Raiders. Nice to Zeke O'Elliot for Dallas. That's going to go to Robert. Robert Uncle. All right. There you go. Not bad. Now let's flip back to this list again. Let's see who's going to win what. Jay down to Don. New list. New dice. Let's randomize it. Three times. Two and a one, three times. Once again, top six after three. Good luck. One, two, and three. Now from spot seven on down, bad news. Sad time. Sorry, Don. Right there at the edge. Not in the break. Sad times. But good news is that we do have to do one more of these. So if you want to give it a shot and help fill up that break, jaspeaskasebreaks.com. Congrats to William, Christopher, Brandon, Tony, Brandon, and Jay. Happy times for this crew right here. You are in flawless football. I'm Joe for jaspeaskasebreaks.com. I'll see you next time for the next one. Bye-bye.


Good morning, everybody. I am Dr. Chaitanya Kiste, a junior resident from Topiwala National Medical College in Nair Hospital, Mumbai, and the topic for my paper presentation is shear wave elastography in patients with chronic kidney disease. So, I will start with the aim, the introduction, the methods that I have used, the results and followed by the discussion. So, the aim of my study is to explore the use of shear wave elastography as a non-invasive biomarker that can distinguish normal renal parankyma tissue from disease kidneys. As we all know, chronic kidney disease is a progressive loss of kidney function whose cause is mainly due to hypertension, diabetes, and primary renal disorders. Now, CKD in its advanced stages is associated with increased mortality and morbidity. Currently, we use EGFR, which is derived from serum creat to stage CKD. However, there are many limitations to this technique, including confounding by race, gender, and muscle mass. Now, there are also clinical situations where EGFR results may become inconsistent and misleading, such as during acute changes in kidney function, high dietary protein intake, and extreme body size severe liver disease. Intra renal fibrosis is a final common pathway and pathological end stage for all CKD patients, and the degree of fibrosis can be correlated with disease severity. This is a principle that is used, and for a long time, renal biopsy was the only known method used to detect the intra renal fibrosis. However, there were significant disadvantages, like it is expensive. Being invasive, there are more chances of complication, and it is also subjected to sampling errors. So, there is a huge interest in developing non-invasive methods to accurately evaluate nephropathy. The parankymal ecogenicity, using BE mode, is a commonly used marker for nephropathy currently. However, this marker is subjective, not quantitative, and often fails to detect renal abnormality. Shear wave elastography is an emerging ultrasound technique used to measure tissue stiffness. First, we look at the principle of shear wave elastography. Elastography can be strain elastography or shear elastography. The source of source in shear wave elastography are short durations, strong focus acoustic pulses. These generate something called the shear waves. The shear waves are induced perpendicular in direction to the dynamic force. Ultrasound system via multiple sound pulses records these shear waves, and the energy is generated in kilobascals. The method used in my study includes, for cases, patients of all age groups referred from nephrology, internal medicine, urology to the department of radio diagnosis with chronic kidney disease were taken. And as controls, I selected patients with other comorbidities subjected to abdominal ultrasound without chronic kidney disease. Patients with renal cortical thickness less than 10 mm and not the patients not willing to give written informed consent were excluded from my study. The data that was obtained was entered into Microsoft Excel and mean and standard deviation was calculated. So, after taking my informed consent, the first step was to do a B mode analysis of renal length, width and cortical thickness. Then the patient was taken into subjected to lateral recubus stress and asked to hold his breath. The ROI box was placed in the renal cortex parallel to the medullary pyramids and five readings excluding the pools were taken. Then the elastography values were obtained, creatinine report was collected and EJFR calculated and the values were compared with the control group. These are the results of my study. The creatinine right kidney length, left kidney length, the right kidney width, left kidney width and the parankimal thickness of right and left kidneys has been recorded and the mean values have been calculated. The shear wave elastography values obtained in the case group was 9.6 and in the control group was 3.4. The median estimated young's modulus was significantly high in cases that is 9.6 as compared to control that was 3.4. The intrasubject variability was also higher in CKD patient as compared to normal control patients. The mean length of right kidney was 9.8 and left kidney was 9.7 in control group whereas in the case group it was 7.9 and 7.7 centimeter respectively. Then the mean parankimal thickness was 1.56 and 1.45 centimeter in control group whereas it was 1.3 centimeter and 1.32 centimeter in case group and the serum creatinine of control group was 0.62 milligram per deciliter and of case group was 3.43 milligram per deciliter. These are some representative cases so the first case is of a 51 year old male patient with history of hypertension and on dialysis. We can see the B mode analysis in the first picture and the elastography that was taken and the second is of a control group 34 year old male patient with headache and vomiting and this is the representative images. SWE can detect renal fibrosis at an early stage allowing for timely intervention and management. It provides a non-invasive method for monitoring changes in renal tissue stiffness over time helping to track disease progression. Now of course there will be there are some tissues micro's environment factors such as inflammation that make unfound SWE estimates of tissue young's modulus. This is known to be the case in liver disease as well where hepatic inflammation has been shown to increase the tissue stiffness. However despite this the clinical utility of elastography for liver fibrosis staging is now well established and SWE is used to clinically differentiate early as well as advanced liver fibrosis without biopsy. Now same can be anticipated in the in case of renal as well. So SWE may similarly have great utility in diffuse renal disease as it has the potential port to reduce the biopsy and to permit repeated non-invasive direct estimates of renal paranchymal disease severity. Ultimately such a tool could potentially be used to track renal fibrosis progression and permit therapy individualized in a manner that is presently not possible. Now while SWE is a promising tool it is essential to interpret the results in conjunction with other clinical and imaging findings for a comprehensive assessment of CQD. Thank you.


the cloud, perhaps. Well, it claims to be doing it. Luckily, that's doing it. And if I get a link at the end of this, which says it actually recorded it, I'll share it with everyone as I follow up to the session. I hope people are following on. So let's go back and have another look at our controller node now. So there's two several interesting things that have happened. Firstly, we've gained some new users, Collar and Stack. We've gained some bridge devices. We've gained a Docker runtime, but no Docker containers. So other things could happen, too. We could have LVM configuration, for example. We could have other things besides this in terms of repos and what have you. So there's a good deal of preparation work that can be done at this stage in order to make our bare bones sort of sent us VM into a working thing. Let's start the next bit, which could take a little while. Container image pool. At this stage, what we are doing is we're bringing down all of the Docker container images to the control plane, so to the controller and to the hyperfisor of the compute node. And this will be done according to the OpenStack Collar configuration, so which services are defined to be running and placed on which compute nodes. And so what will be happening here is that we are talking to our local Docker registry, which is inside the deployment in Equinix Metal and local to the region, but is not on the CVM. And it'll have a list of containers to download. And I can show you where that comes from. I'll just change tabs again while it's doing that download. So back into the Koby config repo, our infrastructure is code. There's a file called colla.yaml. And this is largely at defaults, I think. That means that we're not going to get anything special. The only significant difference here is we're not going to be enabling Ironic. So by default, the control plane includes the Ironic service for managing bare metal, certainly up to the usury release. And so if any of these collar-enabled flags have been set and they were not the default already, then we would start to be pulling in those container images for that. And within the universe from nothing lab environment, it's perfectly possible and readily available to change the configuration from a running setup, run the playbooks again, and have it reconfigured to the new setup. Let's see how it's doing. Still a little way to go. If we were doing this on a running machine, so for example, if we were updating some of the versions of our containers, and you can update them on a very fine grained basis, so you can easily do one service and update it from one point release to the next, then pulling the containers has no effect on the running system. It's simply staging the software images local to where they are running, in a way which then enables us to shut down the active instance and replace it with a new version of the active instance in a fairly snappy way. Now, so the time that any single server is doing the upgrade is the time it takes to restart a service, for one. But also, Collar Ansible has the logic of orchestration, so things like the stateful services, the databases, and the message queues. The updating of those across the control plane is done in a orchestrated way, where there is no disruption to the service while this update is happening. My system has completed the pool of containers. Now, this is a bit that could easily go wrong with everybody in the lab pulling from the local registry. So if you hit problems with yours, do shout out. And hopefully, Mark or John could step in and help you get the bits that are missing. Overcloud service deploy then is the process of writing the configuration into the controller node and the compute node for the services that we're going to deploy, and then starting them up in a coherent fashion. The way that it does this in the Collar model is quite nice. It seems to work quite well. And I can just quickly take you through the different stages in which the configuration of different containers is written. Because Collar is what you might call opinionated. It has defaults for pretty much everything that you want to do, apart from parameters that simply cannot have a default value on every configuration. And that means that the actual configuration that we need to worry about is where we differ from essentially a reasonably sensible set of defaults. And that means that the configuration that we store under source control is not unduly big and is as simple as it can be without being simpler than that. I'll show you a little bit about how that works and the different stages in which configuration makes its way from our KB config repo onto the running machine. There's three key stages, maybe four. So I'll just change terminal again to our config here. And inside this directory there is a subdirectory called Collar. And inside there is one called config. And this is where we can put a lot of service specific config in a very fine grained way. So now we're thinking particularly about specific files or specific data that we might want to add to files inside the OpenStack control plane configuration. So it's really quite targeted and quite precise in terms of the config that we're applying here. There's several ways that we can apply data. And the first of them is that there will be a service.conf file in pretty much every OpenStack service. So for example, here we have Neutron. And there is some custom configuration here which is applied to a file called Neutron.conf. So pretty much every OpenStack service has a service.conf kind of naming convention. And so that the easy pieces we can apply usually go in there. What we can see here is a fragment of an ini file. But it's got some ginger parameterization to it as well. So we can see this variable AIOMTU. And that actually is expanded from our set of KUB variables which were a couple of directories up in the networks.yaml. So just here we can see that this is a symbolic representation of the MTIU on our all-in-one network. And that's quite a powerful thing for a start. That in our Neutron.conf we can add particular random fragments of config and refer to them in this sort of symbolic algebra of our KB configuration so that we don't have to carry around a load of numbers and repeat the numbers everywhere and then change them everywhere as well. The next level of detail is within the Neutron service we might have other config files to which don't follow this sort of fairly simplistic naming convention. And so we have ML2.conf for example. And so within a subdirectory in our caller config directory we also have a place where we can put other files which will all be transferred over into the running configuration of our services. So again, ML2.conf also has a variation on a theme in terms of this parameter pathMTIU. And this will be inserted into other configuration, other global config that caller will be applying on the machine itself. We can go further than this. And actually, we can make subdirectories within these subdirectories and say that we can apply specific service to specific groups within our control plane inventory. So for example, a good use case for that could be that we have a group of GPU-enabled hypervisors. And perhaps we want to be able to pass through PCI whitelist details specifically on those servers and not on others. And so there's a nice way that we could just create a group within our caller config here specifically for Nova config for a group of servers. And that config would be uniquely contained within those servers. So it's very powerful and very flexible. But at the same time, it's very intuitive and uses Ansible's inventories to its strengths. The next stage in which that config is passed is that if we go back up to the top of our KB config directory, we get this sort of macro expanded caller configuration as well. And if you remember that KB drives caller Ansible to manage the orchestration of deployment of containers. So within the caller configuration then. And I think there's a neutron.com. There we are. So the caller configuration looks pretty much the same, apart from that our parameterized KB variables have been expanded. So details from the infrastructure have gone from being symbolically represented to being concrete instantiations of those parameters here. But this, by itself, you never have a one line neutron config. So the next stage is then that the other details that caller is going to be applying based on the parameters of the deployment will be feathered into this ini file as well. And if we go on to the control plane itself. So if I go on to the controller node become root, that the final or the next stage of the path of the flow of configuration is that there is a directory on all managed nodes or the nodes on the control plane called et cetera caller. And within this directory, there are subdirectories for all of the containers that are being deployed. And right now we haven't quite got to the point where neutron has worked, has gone through yet. So we probably are a little bit ahead of the service deploy here. I think it might be coming up soon. What's going on is that the NOVA configuration files are being written and the containers will be being deployed here. I'll go back to the controller node and we can see that happening. Yes, so it looks like NOVA API came up 17 seconds ago. So that's very much still underway. Another interesting piece here is that we can see the container releases that we have here. So most of the caller containers will just be pulling from builds upstream. We have the option to build our own and there's two ways that we can do that. The binary path is simply to create a root image and install RPMs into it from the RDO project. And the source image, the source container kind is where we pull down the tables or the Git checkups and essentially we go past RDO and we install from the sources themselves. In terms of the tags, Suri is a rolling release branch of stable releases but we also have point versions made within a release cycle. And so it's also perfectly possible to pin to a single point release which gives you greater repeatability of the containers that are being deployed from one day to the next. It looks like Neutron is on its way now. So over here, we're gaining a few directories and our Neutron.conf, for example, should have the MTUs and there is the MTU parameter interleaved with a lot of other configuration parameters that have been applied by Color and Spill as well. This is the longest stage in the exercise because it can take a good amount of time to get through the deployments of the OpenStack containers and their configuration. Looks like we're nearly done. Okay, so on the system, the OpenStack control plane is up and actually we can source the overcloud credentials that were generated by this deployment. So I'm in the wrong directory so that for this we can use the source config, source kbconfig, et cetera, Color, OpenRC. Color generates this file with the credentials of other cloud is just deployed, just an RC file. So with the public credentials of the system, we can now do a post-configure which doesn't do much in these systems. Usually it's the point where we would be downloading things like Grafana dashboards and setting up pieces for ironic management as well. So things like the RAM disks and the other pieces needed there. So we just run it for completeness. So I just sourced the public RC but now we can look at pulling down things like a seros image and defining flavors and networks and other pieces that we might need to boot a machine. I think at this stage there's a script that we can run which is in the Google doc which comes with this presentation which I'll just open here. I'm gonna run this again because quite often I think that as part of the lab environment we do some things to the host VMs networking, the host instances networking and I think we need to rerun this script so I will just type that in. And what this does is it sets up forwarding and some ports to connect to. Okay, now we can, we step away from Koby and we start interacting with the system itself, the open stack through its own APIs. I'm gonna leave the Koby environment set up here and I'll go over to one of the other terminals or tabs on my Tmux. Oh, I'm rude, that's why. Excuse me, long day. Okay, and I will also source the other color credentials here. Okay, so now I should be able to create a VM and I'll just check if my open stack environment is set up. Run some simple commands. I think m1.extralarge is probably pushing our luck. So let's go for a tiny. There's some preloaded state here which should just make this command the same for everybody, there it goes. And the machine is created. So we have a VM running. Let's step on though and see how well it works. So make a floating IP. The scripting there is an easy way to see or to extract the floating IP programmatically but I will just use some copy and paste here. So we have, this is our floating IP. Obviously this is meant to be an external network but in the lab case, the setup local networking that we're doing, he's doing some IP tables translations so that we can use any public IP address on the outside and translate it to a quasi-public external network here which is 10.02. Add that floating IP to my VM. So I should now be able to SSH to my VM and hey, Presto, there it is. So we've made an open stack deployment and we've actually made a VM inside it and now we can connect to our VM and you can see it's a one core 512 may, not very big VM, but it's enough to demonstrate that we can make these test environments on one server for a multi-node or representing a multi-node control plane. There's a little bit more we can do as well as that. So if you remember the IP address you had from your email, if you've deployed the control plane, you should be able to open your web browser to that IP address and see Horizon work. You can also get it from Bonzero here, I believe. So if I open a tab here, we should see a login on your open stack web interface. Now what was the password again? It'll be the same one, the admin account is from the same credentials that we had before. So I'll just make this a bit bigger. So that is our little VM running inside our lab environment and accessible from your machine. How are people doing? We've got a few minutes available to complete any problems people have had if people have not quite made it to the end, but I wanted to go on to show you guys what we could do next. And I'm afraid that in an hour and a half, we don't have a lot of time to cover some of the sort of follow on exercises, but I will take you through what they look like as well. So first one, and these are covered in the handout as well actually. So if you're interested in understanding now that you've made your universe from nothing environment, you can use it in all kinds of ways to understand more about the different ways that we might transform an open stack control plane to add services, to make changes, to understand it better and how to work it. It's quite easy to take this environment and develop it further. And there's a few nice examples in the handout which you're very welcome to have a look at and work through. As I say, please do try this at home because there's a lot of things that we can do that. So I think if I go back to the controller node, we can see the full set of Docker containers that have been deployed. More than a page here. So let me just bring that down a bit. And so this is what a caller control plane looks like, a suite of containers interacting through message buses and APIs, REST APIs and things, not interacting through common file system or other things like that. On this machine, a default vanilla config of caller will have fluently aggregating logs between all of the different services. But basically there won't be any sort of developed logging service, any really sort of user-friendly logging service. So fluently can easily be configured to send data to other places, forward it on to host logging infrastructure, that kind of thing. But actually we can create our own as well. So we can, with one line of config change, we can deploy an Elasticsearch and Kibana deployment to take all of the logging from Fluency and present it in an interactive exploration way using Kibana. It takes a little bit more than the time we have now, I'm afraid, but it's, it's well worth doing if you're interested. It's surprising how well Elasticsearch will work in a limited footprint like this. Surprises me anyway. In terms of other exercises that we have here, one of the really nice things that we can do in Koby configuration, given that everything is Ansible-driven, is that it's quite easy to generate all of the configuration from a, will be effective, a parameter change in our configuration, expand everything into the final level of expansion, which would be the config files written into the host's config directories themselves. And then also then enable us to bring that back and then compare it with what's currently active on the system. And so if you were ever worried about what the full effect of a change is, this is a way in order to enable you to see the full effect of a config change and then understand, well, actually, it's changing a little bit more than I expected it would. And so you can look before you leap. It means that every OpenStack reconfiguration isn't a leap of faith. You completely understand the consequences of it in terms of OpenStack configuration. OpenStack configuration state changes. So that's a pretty cool thing as well. And it's all facilitated through using these Ansible models. There's a couple of other nice exercises I should call out before we go too far. So we've looked at Elasticsearch and Kibana. That was that one. If you've ever enabled Skydive, that's quite a cool thing to add here. Skydive is the interactive network analyzer, which enables you to understand how OpenStack's neutron hypervisor networking configures strings sticks together. And so it's quite an intuitive graphical presentation of hypervisor networking. Well worth the look if you're interested. I think now though, we've only got a couple of minutes left. So were there any questions that anyone would like to raise at this point that we could cover before we finish? I see a comment about SRIOV networking. Yes, that fits in well here. So it's a nice example of how we can use the deployment hooks so that if we have specific hardware from an SRIOV supporting vendor, we can set it up in our host boot process in a way which works for that class of Nick and then set up the environment as well. Similarly for some of the more advanced sort of hardware offloadings, things like ASAP squared from Melanox as well. Those things can be configured as using the deployment hooks so that they fit into the steps of the standard process and extend it in useful ways. There's a question on any docs on how to start with Kola and Kaby for production environments. And Lukas, you're very welcome. Thank you. Yes, the OpenStack online documentation for Kaby I think makes an excellent reference for getting set up. The sort of this end-to-end approach of deployment, sometimes it's nice to start with a reference example for another cloud that's deployed using the Kaby environment as well. And if you look in the Google doc that was the handout with this session, there is actually an example of a production system. So it's an OpenStack cloud for a radio telescope project here in the UK. And that config should be a good example of reference implementation for various scientific computing like facility features. Quite useful to get started. But the online documentation for Kaby is I think very, very good, very articulate and explains a lot of the reference details quite well. Okay. We should probably stop at this point. Thanks a lot everyone who's made it through. I hope you've found it useful. I think it's a good fun environment. And like I said, say it again. I do hope you'll take it away and have fun with the Universal Nothing workshop. It's all open and we look after it. So it usually works pretty well. We add new exercises to it all the time as well. So I'll follow up in any email if the recording is successful and with the details. So you can take that. Yeah, good point Mark. So Kaby and Collar Ansible and Collar on ISC, OpenStack Collar is a helpful channel. There's people from all over the world in there. So it's usually pretty busy. Oh, go for it Stanislav. The seed node will deploy all of the servers in the control plane, including storage and hypervisors. If you, by default, it will do all of those. So we often deploy a Ceph cluster which is connected to well integrated with but usually slightly separate from the OpenStack environment on its own hardware. And so it's perfectly possible to deploy a wide range of other pieces of the infrastructure using the seed node approach. You can deploy pretty much anything you choose to with that system. Okay, in the reference architecture there is all right. So Ironic is just being used to deploy anything that is any of the servers in the control plane. Does that answer your questions? So, okay, I think it's not about providing Ironic to users. It's about using Ironic to install the compute and the control plane, all the resources. Warren, I think the VMs, or the lab instances are gonna be up today. And I think they'll disappear either overnight or the first thing tomorrow. Okay, well, good luck everybody. I hope I'll see you all around and thanks a lot for making it to the end. Cheerio.


The Bemidji Police Department posted on social media that a level three sex offender has moved to the Bemidji area. 47 year old Randall Dean Adams was released in 2011, but recently moved to Bemidji on February 13th. According to the post on the Bemidji Police Department's Facebook page, Adams has no known address and is listed as homeless. Back in 2009, Adams was convicted of third degree criminal sexual conduct with a helpless or mentally impaired victim in Hubbard County.  He is not wanted by police as he has served the sentence imposed on him by the court. If you've enjoyed this segment of Lakeland News, please consider making a tax deductible contribution to Lakeland Public Television.