Hey, I haven't vlogged in so long and I'm about to record a couple of self-tape auditions But I just wanted to touch base with you. Uh, I haven't been pretty busy. I booked a few things and went camping and Of course the the month of July took a beating on me because I was doing self-tapes every day Sometimes more than one and so yeah I definitely want to update you guys with how I have been getting so many casting calls and self-tape auditions, so I will share with you my Tracker my audition tracker, but right now I need to Film these auditions and send them in. Hi, my name is Feljika and I'm an actress based out of LA and San Francisco And in the last three months, I did 73 auditions although in July 32 31 of those 31 of those were for The challenge I made for myself of filming a self-tape audition every day, but still in August I had 27 so I wanted to share with you guys all of my auditions what websites I use to Self-submit and also where else I have been getting auditions I usually do this every first Saturday of the month the last couple of months have been a little bit crazy I haven't been vlogging as much, but I like to vlog throughout the week and then post on Saturday You know just how what I've been doing what auditions I have been doing and Anything that's really going on in my life acting related So today I'm gonna break down the auditions that I got in June July and August because not every month is This busy and even not every year is this busy as far as self-tape this year already. I've done more auditions already than any other year in 2018 I believe is the last time that I really Logged every single audition and I want to say was like in the 80s and at the end of the video I'm going to give away the final 53 inch paper backdrop from Savage I told you guys this a few months ago that every first Saturday of the month I would be giving away a 53 inch paper backdrop, which is just like the one-and-a-half behind me I use these for my self-tape auditions and obviously for my YouTube videos, too This is not sponsored at all. I'll tell you guys about how to win it at the end of the video But let's get started with June. So June I only had nine auditions nine self-tapes None of I have not auditioned in person since 2019 2020 absolutely not I did not audition in a person 2021 still have not auditioned in person. So in June I got nine self-tapes Like I said one of them was from my Asian and it was a voiceover audition So I just recorded it here at home in my closet One of them was from aura casting and that was just a self-submission seven of the auditions were from casting networks So I submit for casting networks in both LA and San Francisco And I do have a tab for that on my spreadsheet where I you know put all of my information so I can keep track of everything and All of them, but one was commercials and then that other one was an industrial and If you haven't used casting networks, it is a very very very commercial heavy Both in San Francisco and LA. I see a lot of commercial postings in LA I definitely see a lot of music videos, which I I don't self-submit usually to music videos in LA. I'm just not interested and Also a lot of background you can find on casting networks and that's what in my experience in July I only kept track of three auditions and they were all from my agency MDT in San Francisco So those were all San Francisco auditions I did start self-submitting a lot more towards the end of July, but because I was doing my self-tape challenge I was just not Self-submitting as much and not keeping track of the ones that I was self-submitting for you know and auditioning for because I do remember that Towards the end of July I was doing a bunch of auditions one day and some of them work from self-submissions and some of them for work for My agents and I actually booked one of the auditions that my agency sent me and it's not out yet But once it's out, I'll share it with you guys But I was really excited to book that one because it's with the company that I really really like and it was really fun to film it I already filmed it, but we are going to do a quick reshoot Coming up soon. So I'll see if I can vlog while I'm there or at least Before and after in July I did 37 auditions with the 31 being for my youtube channel three being for MDT and then kind of sort of didn't really Remember what the other ones were but I know there were some more now August August was very very busy. I had 27 auditions and 12 of them were really close together as you can see here on my spreadsheet And another thing I noticed is that the casting office Kristen Beck casting has been Asking me for a lot of self tapes. So hopefully soon I can book something with them I would be very excited to Finally book something with them because I remember even when I used to do in-person auditions I would go to their casting office all of the time and it was always a great experience and in August I booked my first reality show and again, I will share that with you guys once it comes out It's nothing big. It's just one episode and of course just like with everything else I don't know if they're gonna use anything that I was in but once it comes out I'll definitely grab a clip and show it during one of my vlogs and I can you know Watch it with you guys I also booked one background job one film from home job and then one commercial job Unfortunately the commercial job there was a sickness in the production team And they had to reschedule it and then they rescheduled it to a date where I was going to be camping But that was a self submission through casting networks in August my agency in san francisco MDT sent me nine self tape requests and one of those were through or a casting So or you can submit to and you know, you just sign up and they can send you auditions and also if you have an agent Your agent can be in charge of handling the the ones that are a little bit bigger Usually agencies tend to do like 500 dollars or more because they do usually take 10 to 20% if it's a lower You know budget production or you're going to be paid a lot less And it's really not worth it for them to invest all of that time Into it if they're just going to get like five dollars, you know, they're not going to do that So in my experience for MDT, I know they said they would do 500 and above So um or I sense you anything that's maybe a little bit less or people that are under Not represented or um even background work the other 18 of the self tapes I did were through Um casting networks and some of them were just they had a script online And they said anybody who fits this go ahead and submit a self tape And then some of them were media requests So I do have it on my spreadsheet if it was a media request I put that so that I know I didn't just submit without them actually even knowing You know who I was and them wanting me to submit So a lot of them were media requests where they were hey, you submitted to this Now we would like you to send in a self tape and then some of them They just put a script and they're like anybody who Wants to send in a self tape send it and those I Usually only do if I can do it within the first day or two because I know a lot of people are going to be submitting So I want to make sure I'm one of the first ones so that they can actually see my self tape because I just don't know How many self tapes they are getting because most of the ones where they just put a script and they're like Send it over are in LA and I know LA casting is a lot more busy than s of casting All four of the jobs that I booked in august I booked through casting networks and I booked myself So not through my agency and in general in the last few months on instagram I definitely find out about a lot of casting calls open casting calls and I will share them When I can on my instagram or through the cast and project instagram that I have talked about in the past a few times My agency of course sends me a lot of self tapes usually for commercials industrials and voiceover because they do represent me across the board And I have also been submitting to actors access both in LA in San Francisco Of course, I submit to LA in San Francisco anytime I can And then I also auditioned for The netflix reality So if you don't know netflix is having a huge open casting call for their reality shows and I did end up sending in a video And you can send in a video too. I did a short about it and a video about it But um, you can watch that I'll link it right here in case you're interested in maybe being in a reality show I think reality shows are really fun. I love like cooking shows Um, I recently watched love is blind that show is really good too. Even though I was very angry during the marriage parts. Anyway Um, and then of course like I mentioned aura I also submit through aura whenever they have an opportunity and for them. I have usually seen Um, a lot of san francisco based auditions But when you sign up for it, it does say that it's basically all of california in the last three months I have been auditioning a lot for voiceover a lot for commercial and then quite a bit film at home Although I don't know if I want to continue doing the film at home. I just I don't know I don't really like this style maybe in the future once I really process it I'll make a video about it. But for now I'm just I don't know I'm not feeling it right now, but we'll see we'll see if things change And I definitely want to audition more for scripted things movies tv shows web series So I'm going to keep an eye out for that and I'm going to continue to be submitting on actors access and of course I am seeking representation in la and I know once I get representation like theatrical representation on in la I will be able to audition more for those types of things But um, those are all of my auditions for this month or This recap of the last three months because I haven't I'll make sure to do another one the first saturday of october But I wanted to tell you about the giveaway. So as I mentioned, I am giving away a 53 inch paper backdrop Which is just like this one that I have behind me the red one So if you want to win a 53 inch paper backdrop from savage universal because they're the ones that are giving us these for free So I mentioned in one of my videos that I wanted to do a giveaway and they were like sure Let's do it. So this is the third one That I'm giving away during my first saturday of the month And so this is the last one for now. We'll see if in the future we can do it again But if you would like to win make sure you comment on this video by september 10th 1159 pst And this is only open for people in the us and no international territories Again, just because they are the ones sending it savage universal is nice enough to give us these So we have to follow their rules Like this video make sure you're subscribed to me and leave me a comment Tell me what you would use this backdrop for if it would be for photos youtube videos Your self tapes whatever it is and what color you would be interested in I have made a few videos on like the different colors that I've used. I've experimented with them Um, and I'm just obsessed with like trying new colors. So I think I'm gonna get some new ones soon Thank you so much for watching and at the end of every video I feature another channel This is today's feature if you would like to be featured on my next video Make sure you're subscribed like this video and leave me a comment


OK, thank you, everyone, to join this presentation. The presentation will be made by our three. This is Xinhui from VMware. I'm a core developer of Sunlin Project. And this is Qiming, come from IBM, and the PTI of Sunlin. And this is Peter, come from Nokia. He's a core developer of Nokia. And there is a photo over there. Actually, he is the runout of the PTI of the MISCHO. He cannot come this time, but he contributed a lot to this presentation and this integration, too. So we appreciate him also. Now we can start. Actually, high availability is a very complicated problem to resolve. By this graph, actually, we showed four types of high availability in OpenStack deployment cloud, where in an OpenStack cloud, OpenStack is supposed to manage a group of hosts. And on the hosts, OpenStack can create and do the lifecycle management about the VMs and containers all these things. And in the container and the VMs, application running. So the four types of availability can involve different kind of factors, such as for the host, we need to consider the availability of the physical hardware and operating system, of course. And network storage all these things. For the VM layer, we need to also take care of the resource availability, such as network storage and mobility. That means migration and do a cross-room placement, something like this. And for the application layer, actually, we need to take care of the service resilience. I'm sure there are already very popular topics into the different scope, such as we need to consider the quality of the service and the cost of transparency and the data integrity when we do the service resilience. And for the OpenStack itself, of course, there are many things we need to do the reliability. To help this scope resolve the auto-healing problem, certainly in the past cycles already do a lot of work to provide the framework to help the failure detection and report and recover this loop. By this graph, actually, we show the auto-healing loop provided by Sunlin. As a clustering service, Sunlin can help to create a group of same type of objects, such as a VM. We call it as a cluster. And the cluster can use a standby mode to do the availability by providing some redundancy. And after creation of a cluster, we can create and attach some policy to control the placement. That means when I scale out a cluster or create a new node in the cluster, I can use the placement policy to define where the new node can be placed. And more importantly, we can provide the health care policy. That means we can use a policy to mention what kind of detection the user want for the target cluster and what kind of recovery action they want to use whenever anything happens, they want to do the recover. Here, for the step two, actually, we provide a different kind of detection way. The first one is polling. That means after if some cluster is registered towards the slim engine, we can pull in to know the status of the different node of a cluster. And we also can monitor and listen that events happened to the targeted VM and maybe applications running inside. That depends on what kind of events the application can emit or fare. And then we can use a thermometer and an AE to send out an alert to the receiver of the assembly. Receiver is a very important abstract provided by assembly. In this way, we consist of a complete loop to do the detection and the recover things. And we already do in the past cycles the finish of the framework. But here, today, we're trying to deliver some extension we made in the past cycle. We want to bring this framework into an industry solution from two perspectives. The first one is we're trying to use some enterprise level monitoring to improve the detection side. That means we should use some reliable and scalable monitoring to generate the alert and to know whenever the failure happens. And more importantly, we need to make the monitor should be powerful to collect different data across different sources. That's very important. So not only a thermometer and an AE, we need to integrate with some enterprise monitor. The other perspective we're trying to extend the framework is integration with some workflow. Here, mystery is our choice. Because actually, whenever the recover happens, actually the action is very important. Maybe sometimes or often, the action can be the long run. That means we need to care about the steps and the status of each step. And then at the same time, actually, we need to handle the parallelism and the error handling. All these things, we need to consider them in a whole way. So that's the reason why we choose to integration with the VR ops. That's just an example of the enterprise monitor. And it was a very powerful project. We collaborated together with Sunlin together to provide an industry solution. In the rest of the presentation, we will introduce what Sunlin is and what's the advantage of the mix tool.  Now I would like to introduce Timing for the Sunlin DeepDial. Thank you. Okay. Just a little bit, quick introduction of the Sunlin project. The Sunlin project was started about two years ago. The goal is building a collection service for OpenStack, a very generic service that can help you manage homogeneous objects on OpenStack. For example, Nova servers, for example, heat stacks. And later on, we also extended Sunlin to many Docker containers. So on this page, I'm showing you the high-level architecture of the Sunlin service. As you can see, from the client side, we have a command line interface implemented as OpenStack client plugin. And we have a dashboard implemented as a horizon plugin. And we also have Python and Java language bendings for you to interact with Sunlin service. And we support multiple engine deployments so that if you are managing large-scale clusters, multiple engine can help you ensure that the scalability is achieved. Sunlin talks to the other OpenStack services through one project, one service that is the OpenStack SDK. We are not relying on any blah, blah, blah client. For example, Nova client or heat client. We're just relying on one service that's the OpenStack SDK. We talk to any other OpenStack service, including Keystone. We talk to Nova to manage VM servers collectively. And we talk to heat to manage a combination of everything else. As I just mentioned, we also support Docker containers today in experimental status. We are still improving that. To make the service even smarter, we also develop a lot of policies that you can attach to a cluster and detach from cluster. Examples including the scaling policy that helps you determine how do you want to scale out a scale in your cluster when something happens, some events you receive. And we also have experimental status health policy. We are still improving that. That can help you also heal any node that has failed. We have deletion policies helping you to decide which node you want to remove from a cluster when you detect something bad happened. We also have affinity policy and other placement policy that help you decide where you want your new node to be placed in a new availability zone, in a new region, or anti-affinity, all those kind of things. We also wrap load balancing. The load balancing service has a policy. So we believe that users are more interested in the policy implemented instead of the service itself. So that's the current status. It provides a lot of primitives, a lot of operations for you to operate your cluster. That's a collection of things together. We provide basic management of your cluster membership. For example, you add a node into a cluster, remove a node from a cluster. You scale it out, scale it in, you resize it. There are a lot of command line options for you to specify. Most of the time, these operations are already sufficient for you to do daily cluster management things. And we also have policy management support to support user scenarios such as auto scaling, auto heating, and placement, and load balancing, I just mentioned. There are some other use cases we are exploring. For example, the standby active cluster deployment so that you can do a rolling upgrade much more easier.  When you are creating a cluster, you specify the desired capacity, the minimum size, the maximum size, and the profile you want to use. The profile here is actually anything that can be abstracted. Today, we have implemented a profile for Nova Server, Heatstack, and the Docker container. Actually, you can add your own profile. We have an extension point for that. If you want to use send-in to manage an array of integers, you can do that. There are many different ways to use send-in. I just mentioned that we have a command line interface on the Horizon plug-in for your interact via the service. When you are writing some policies, there are two ways actually. At least, you can use the send-in command line or web interface directly. You will be writing a YAML file. On this page, I'm showing an example. That's affinity policy that you specify whether you want your server group to honor an affinity policy. This is the send-alone policy specification you can use to manage your cluster. Another way is that we have fully integrated sending resources into Heat. The right-hand side is a snippet of a Heat template file. You can specify send-in policies as a resource in Heat template. So next, I will invite our friend and Mitchell, expert to introduce you on how Mitchell fits into the whole picture. Hello, everyone. As mentioned, I'm jumping in place of Renat. And I will talk about why would you like to use Mistral in place of your own script solution or just using simple novel or heat actions for recovery. If you are not familiar with Mistral, it provides a robust DSL language. It's formalized. And you have all the common building blocks that would be available for you otherwise in your script. You can use your own structures that you create by reusing workflows. And if you're still missing something from Mistral from the built-in actions, you can just create your own plugin written in Python and add it to the Mistral library. Mistral is an OpenStack project. It's very deeply integrated with OpenStack, which means that it has resources for all the actions for most of the other OpenStack projects, which is basically opens the door for Sanlin to be able to interact with many OpenStack APIs. It also handles authentication to Keystone. If you're using the v3 API, that means that you can use trust. And that also means that you can write really long operations if you have very complex recovery solutions. If you would use a script, you would have to handle that yourself. Also, from Mistral, you can use familiar actions, like Nova Reboot and StackUpdate and such actions, which are very, very documented and basically follow the structure of the common line interfaces. And you can also find online examples if you are not familiar with a workflow scheme. And also, it's maintained by the community, and the new actions and resources are continually added to Mistral, which means that it's always growing, and it's always compatible with the latest version of OpenStack. You don't have to maintain it like you would do if you would have a script. But in a bigger picture, what you can do with Mistral templates is along with the Sanlin templates and maybe hot templates, you can deliver the whole recovery solution together. And also, you can separate your business logic and input parameters. That means that you can have a deliverable package that you can send out to multiple customers while the input parameters can be filled in at location. As already shown in the slides, Mistral is capable of parallel execution, which means that if you have multiple nodes to heal, it can be faster. And this is out of the box. One other upside is that there's a graceful failure handling available in Mistral workflows because when one thing fails, usually another tends to follow. So in this way, you can have a chance to escalate an additional failure or still have some more drastic measures to heal your cluster. Also, because Mistral is very capable, maybe your other lifecycle management operations are defined in Mistral as well, so you can deliver together. And also, you have the chance to cancel a recovery execution if you think that an automatic solution is at that moment not favorable. And this can happen in a way that stops at a very reasonable step or a stable state, where you can even continue if you wish so. Mistral also has a directory capabilities for these workflows, so you can have multiple versions, which is very good if you have a very heterogeneous cluster. For example, if you're doing an upgrade, and some of the nodes have already upgraded and would require a newer version of recovery action and other nodes are still using the old software. But you might not realize that with Mistral, you have built-in execution history because all Mistral workflows create a new execution and all the executions have the list of tasks that the execution done or about to do. And this makes it easy for you to debug if the recovery action has failed. And also, it can serve auditory purposes as well. One slide. The downside is that this database is right now is ever-growing, so you have to clean up once in a while. And I give back the mic to you. So I will continue to give the introduction about the VR ops. Actually, this is an example we use to show how our extension to work together with the enterprise products. VR ops actually is a very reputed product from VMware. This product can do different kinds of metrics collection and analysis about the health management, risk analysis, and efficiency management. So the different metrics can collect it from the hypervisor and the hosting label, such as for the health perspective, we can know if any network parts is suffering from the competency or contention. And for the risk analysis, maybe the user want to know if any CPU is suffering from the processor or something like that. And for the efficiency, actually, VR ops can report if anything is suffering from the low utilization. All these things are just simple examples. But for the enterprise level, actually, we can contribute many different kinds of monitoring and concrete metrics analysis. And the more powerful thing about VR ops is this product provides the adapter mechanism that allows different network and storage managers to contribute and integrate their data back to the open stack space. Here, this is a graph actually showed the improved auto healing loop compared to the third slide I just showed. Here you can see we implement a VR ops plug in heat. That means expose the resources group about the VR ops. And in the metaka, actually, we already integrated Sunlin resources with heat. And that means we can use the heat template to create the Sunlin cluster and generate VR ops alert or monitoring the mechanism. And then we can use VR ops to monitor the open stack clusters created by Sunlin and notify if anything happens, the condition trigger what we want to know. We already implemented the mutual plug in inside the Sunlin. And if anything happens, the failure detected by the VR ops, the VR ops will notify Sunlin to do the mutual base recovery. So the seven steps will improve the auto healing loop. Now in the following slide, I will give an example about what the VR ops template will look like. Here, on the left side of the slide, you can see the symptom. Actually, that's one resource definition required by the VR ops. Here, around the condition part lists the property group used to define what kind of matrix you want to use. Here, example is disk space. That means if the left-hand space is less than 5 gigabytes, the unit here is gigabytes, then the symptom will be triggered. So that's one example. On the right side, we will use a symptom to create a VR ops alert. Here, you can see the connection between the two resources. Here, we will use a symptom to define the alert. That means if the symptom is triggered, then I will generate the alert by VR ops. And here, actually, are two very important resources because by the two resources, we connect the open stack space objects with the VR ops side management. Here, for the notification part, it connects the web hook. That means what kind of thing we need to do. Actually, the web hook is generated by Sun Lin. That's Sun Lin provided, as Qin Ming just mentioned. Sun Lin actually provided a receiver. That means we can generate a web hook to do some specific things with authentication. Here, we use a mistro as a recover action and generate the web hook and use it here. The other side to connect by the resources what kind of alert. In the slide side, actually, we define the alert here. So, by the notification, we connect the alert definition under the web hook together. The former part of the custom group actually is another very important resource. Here, we use custom group to identify what kind of VR ops or objects should be targeted by the VR ops to monitor. Here, we can use the filters. The filter here will use the name of the VM that will contain some given keys and to filter out what kind of targeted VMs we need to monitor it. We have other things such as a tag or something like that. Here is an example, actually, about how to use a mistro workflow in a silly health management policy to do the recover things. And we can save all the details here, just pay attention to this part about the recover action definition. Here, we use a name to define the workflow name we want to call to execute, and we use a type of workflow to identify, okay, this action is a workflow, actually. And we use inputs under the parameters to group all the parameters or inputs we need to execute the workflow. Now, actually, we can give a demo to show the whole flow we improve for the auto healing purpose. In the demo, actually, we will use a heat template to create a sending cluster with two nodes, and we will attach a health policy with this cluster where we will point out which mistro workflow will be used as a recover action. Then, once the touch, the policy, silly will pass it and the generator receiver will use the mistro as a recover action. And then, give the URL, you just saw it, it's a webhook URL, and give the URL back to the ops part of the resource to create a notification, as I just mentioned. And then, we will use the tag, that means when underlying, actually, when we create the sending clusters, we will change it over, actually, tag every VM with the sending cluster ID. And the user ID, actually, where ops can fill out the targets we need to monitor. So, we will use all these tags to create the custom group. And then, the heat get everything and create all the where ops resources and close all the loop. Okay, now I would like to show the demo. Okay, here we will save the heat template, the part. We just list the receivers already created. And here, you can see we already create a receiver use the mistro workflow as a cluster recover action. And you can see here is a generated webhook. And then, we can show the where ops part as I just presented. Here is a symptom, and also use the disk space as a symptom to trigger the alert. And then, we will just do the test based on heat. And after the heat is run, and here, actually, we show the different resources already created inside the where ops. Actually, that's the UI of the where ops. And here, you can see the notification alert and the symptom already created because that's actually alert definition user to create the notification part, as I mentioned. This is the custom group we use to fill out the targets where ops need to monitor. And here, actually, is where the alerts to show actually to simulate the disk exhaust condition to trigger the alert. At the same time, we use another thread to DD, you know, write the input into the two nodes to exhaust their disk. And after two cycles, actually, the cycle you can set by the Selene health policy. And after two cycles, actually, the alert will be triggered. And then you can see that's a true alert generated by, detected by the where ops. And at the same time, actually, that's a UI of horizon, of course. And the two nodes is triggered to resize because, you know, the alert is generated to know, okay, the left space size is less than what we need. So we will resize the disk into a larger one. Here, we use a target flavor is a small M1 small. The original flavor is the disk of five gigabytes. And you can see underlying the resize work is there. And then going after it, you can see all the node already be resized to the small flavor. That's our demo, actually. If you want read more about our workflow things, actually, we have the code put on the GitHub and you can read more about what we did in the resize. Actually, that's our YAML used for the workflow side. You can see we actually list all the YAMLs to check if the flavor is right. And if we have the capacity to do the resize and then do the resize at last we confirm and verify all the nodes already be resized to the targeted flavor. So that's the reason why we use MISU here. It's a very good project for us to collaborate. Okay, so that's what we want to show. And now we are open to questions and all the suggestions. Thank you.


Okay. Welcome, everybody. My name is Adam Collard. I work for Canonical on the landscape team. Today I'd like to talk to you a little bit about reference architecture for deploying OpenStack and the autopilot, which is a feature of landscape for deploying that reference architecture on your hardware. Okay. So what do we mean by architecture?  It had some configuration files and it ran on one machine. But these days, with modern software like OpenStack or machine learning or big data things, we have a full set of different services and the key piece of information, the key thing we need to know is how to put that onto two machines, four machines, or 100 machines. And that's what we mean by architecture. It's about laying down those services on your sets of machines, working out what goes where, what can be co-located with what. So the reference architecture that Canonical employs is built to scale from very small clouds to very large ones, from dev QA to production clouds for running hundreds, if not thousands of nodes. And it's designed to cope with failure. So hardware will fail. We know that. And what we need to do is basically minimize the effect of that failure on the overall cloud. So I want to talk you through a scenario where we have four servers. Right? We want to put a cloud down on the minimum set of hardware. Maybe it's for dev proof of concept playing around. So first of all, we want to put Nova compute on each of those four machines. Because we want to have the largest capacity available to our users and our customers. And then we also put storage on all of those machines as well. Because if that's Seth or Swift, it doesn't matter. We want to have the largest amount of capacity for storage as well. And if we have dedicated compute nodes, then we're wasting some storage and we're spending a lot of money on those compute nodes. If we have dedicated storage machines, then again, it's a very expensive machine, and we're wasting compute on that hardware. So in addition to that, beyond just the storage and the compute, we also need the control services. So let's imagine this is MySQL, right? We need to put MySQL down, so we put it on one of the machines. But actually, we want HA, right? Because if we lose one of those machines, we don't want to stop operations and kill the whole cloud. So we put MySQL on three different nodes and minimise the risk of losing any one of those nodes. And we do the same with Keystone and Nova Scheduler and all of the other services which comprise an OpenStack cloud. But then we put them in containers. Why do we do that? Because we don't want all of these services contending for the same file system. By putting them into a container, a lexie container, much like was discussed earlier, if you're at James's and Tyco's talk, this gives us a secure, isolated little box to run our service in. And these are full machine containers. You can SSH into them, you get a full process tree, you can debug them and inspect their log files much like you would any other real machine. But we still have the problem that if we were to lose one of these machines, we'd lose one-fourth of our cloud. And if we had some important services, the leader, for example, in MySQL running on the same machine as the leader for Gluster, say, if we were to lose one of those machines, the failover that both of those services need to do at the same time could get very messy. So what happens if we add two new servers into the mix? We've grown the capacity of our cloud, so we want to put compute and storage down on this new hardware. But then we can increase the overall resilience of our cloud by moving some of the services, some of the units, from where they were on the existing set of hardware to the new hardware. So this spreads the load and spreads the failure across the risk of failure across the whole set of hardware. So this also comes into our performance story. The best overall performance of your cloud is when every single machine that forms part of that cloud is humming. It's not screaming, trying to keep up with high demand that it can't keep up with because it's blocked on CPU or IO or network or whatever. And it shouldn't be just idle sitting there doing nothing because then it's an expensive waste of money that you've laid out for this machine, for your hardware, for your cloud that's being underused. So by putting all of the control services across the full set of machines that you have in your cloud, you're making every component of that cloud contribute to the overall throughput and the overall demands on the cloud. And it should be simple. We want to make open stack available for everybody, and we want to have an easy way of exposing that to our end users. And so that's why we made the autopilot. So I'm now going to switch with a bit of luck and show a demo of the autopilot. So as I said, the autopilot is a feature of landscape. It uses both our Metal as a Service, Maz, technology, and Juju, our modeling and orchestration technology to deploy open stack. So this is our landing page. We do some checks with Maz to make sure that we've got enough hardware to deploy an open stack cloud and we've met the requirements. And then through a simple clicky wizard, we can select our hypervisor, our SDN, and this information has been pre-filled, the network information has been pre-filled based on information that's been entered in Maz and discovered hardware information has been discovered by Maz about the particular machines that form, will form part of the cloud. And then we can choose both our block and object storage. So I'm going to pick Swift and Ceph. And then we get down to the machine view. So here we can see all of the hardware that's been registered in Maz that we can then add to our cloud. We get the information about the characteristics of that hardware, how much RAM is available, how much disk is available, how many cores, et cetera. And I can also see that they're connected to the network as well. One important part of our architecture is harking back to the failure is to record just once in Maz where the common points of failure in our hardware is. So if we've got a couple of racks which share a power feed or they share a network feed or they share a cooling system, we can record that in Maz and say all of these machines are in one physical zone. And those zones you define once in Maz when you wire up the data center and it's reused throughout the whole stack. So what that means is that your failure scenarios which occur from your physical wiring and your physical setup of your machines are exposed through availability zones in OpenStack to your users. So that means they can they can build an HA application on top of your cloud which reuses the information that you've already set up once in Maz. So I'm going to add another availability zone which again is a separate physical zone in Maz. So here I can see I've got six machines selected which means I can do an HA cloud. So one important thing given enough hardware in given to the autopilot and to the architecture in general, we will deploy HA by default so that you get a production quality cloud. So that is going to kick off powering on the machines, laying down a bin to on them and then using the charms to pull in packages for the different services which comprise OpenStack. We're not going to wait for this to finish because it takes a little while. But what I will say is at the end we also want to give you a usable OpenStack. So that means we automatically upload into glance images for 1404 LTS and 1204 LTS and also set up security groups to allow SSH and ICMP access and finally set up some information to easily allow juju to be used to deploy workloads on top of that cloud. You can see some more about how we facilitate juju deploying services on OpenStack in a talk later by my colleague Rick Harding. So now we'll jump to one which I prepared earlier. So this is the dashboard that you see once a region, a cloud, has been deployed. So we get some usability graphs, some trending data to see how our cloud is being used and to anticipate outages and to allow us to do capacity planning and to know when we are running out of block storage or object storage or our machines are screaming and really need some more compute capacity. So we also get a summary of the existing hardware, some links to horizon and to download the RC files but what I want to show you today in particular is ad hardware. So this initial deployment was with six nodes but there's more machines registered in mass which allows me to expand my cloud and so groups by az I can see here there's region 1, 1 and region 1, 2. These are two different azs again tied back to that zone information in mass. So I can see I've got two machines that are already in the zone which are already in the in the cloud but I can add another one and I can do the same for the second az if I can hit it. Okay. So again that is doing exactly the same thing as the deployment. It's using juju and mass to boot up the machines, install Ubuntu and then install the software and automatically juju allows us the beauty of juju is that it will automatically manage the relationships between the different components in the cloud so that these compute hosts will automatically show up as additional capacity in horizon or in your nova command line. Okay. Now I'm going to switch back to this one. Okay. What about the hardware? So we think it's important to use commodity hardware when building clouds. There's an economic sweet spot which changes over time as new machines come out and new processor technology is released but at the moment it's around a 2-socket 2U server. So it's important to recognize that the economics of a private cloud are very important and that your users, the users of your public, of your cloud will be competing, they will have the choice to either use your private cloud or your public cloud and so if your open stack install isn't using, isn't the most optimal that it could be in terms of the economics of the hardware that you've bought or the services that you and the head count that you've got allocated to it, then it's going to fail. So commodity hardware as I said 2-socket 2U with approximately 16 gigabytes of RAM in there seems to be the current sweet spot. Okay. So I now want to talk a little bit about the upcoming features of landscape. So the install that I just showed you earlier was installing open stack kilo. With the GA release in two weeks time we will update that to Liberty and with 1604 we will support Mataka and with that 1604 LTS have been to with Mataka, from then on we will support live upgrades within landscape to keep your cloud up to date with the new releases of open stack as they come out. So N onto O and P etc. Okay. One of the new features in landscape is an additional SDN. So during the beta period we just had Neutron's ML2 reference plug-in using open V-switch and with the GA release we are adding open daylight as an additional SDN choice and looking forward again to 1604 we will of course support Lex-D as a hypervisor on your cloud. So if you were at the talk earlier just before the coffee break you would have seen all of the great features with Lex-D and Nova Lex-D and that will come with the 1604 release of landscape and the autopilot to allow you to get very high density loads on your VM loads on your compute and not pay the virtualization overhead that you get with KBM. Okay. I've left lots of times for questions. So that's all I want to say today. Thank you very much. Yes. Okay. So the question was do you need an internet connection in order to install OpenStack using your autopilot? Broadly yes. There are certain sites that we download the images from, for example, and download other parts of the charms and the packages to get that. But you can with the GA release we have proxy support so you can put it behind a proxy and get all of that information from there. So it doesn't need direct access but it does require access to the internet. Yes, exactly. So the broad steps of installing the autopilot are to first install MAS which allows you to then register your hardware in your LAN, install MAS onto one of those machines, be that a top of rack controller or be that some other machine that you've got available. And then that allows you, that runs a proxy on it and caches apps packages and then you install landscape and then you would configure a proxy during that installation of landscape and then it would use that for going forward. The juju storage, did you say? Sorry. So the charms, so during that installation process you'll bootstrap juju, install it onto one of the machines on MAS and then install landscape. All of that can go through a proxy but yeah, you need, you will need, there's features in juju to set that proxy and that will be reused throughout the stack. Is it your place of services and containers? Right, so all of our services are in containers. The only things that aren't are Navi compute and the Neutron router gateway service. Every other control service which forms part of the cloud is in a lexie container. So no, we don't use any KVMs as part of the control service but obviously KVMs are used for the workloads on the cloud. Yeah, so that's, I mean the whole point of the autopilot is to make it seem simple. The, we, landscape gets the information from MAS about the hardware and then makes an intelligent choice as to where to put that. So for example, if you were to install it onto 100 nodes, it puts down three monitors, and then OSDs on all of the rest of the hardware and we'll use all of the storage available beyond the OS disk to expose that as block storage, object storage to the users, to the workload. So if I answered the question, you want to be able to customize the open stack that you've deployed using autopilot? Okay, so, right, so the question is after you've installed a cloud and then you've customized it, could you then confuse the autopilot and it doesn't understand how you've done that? You could certainly, if you try hard enough, yes, you can break it. It depends what sort of customizations you're doing. Sure, sure. It very much depends on what sort of customizations you're doing. The overall, the technology that the autopilot uses is juju to maintain the, to add that hardware and to expand the class to the cloud. Again, it very much depends on what you're doing, but the chances are if it's just, you know, plugins for Horizon or its changes to configuration files, then it depends where on the spectrum that is. Some of it will be overwritten and you would be fighting against autopilot and some of them it would just be alongside it. So if you do want to have a customized version, then all of the charms and all of the ways that landscape is deploying this is open source and is readily available for you to do. So you could, if you don't want the strongly opinionated view that autopilot has, you can easily reuse the charms, deploy OpenStack and then customize that. But yeah, you then don't get some of the benefits that we have with the system. Any other questions? Okay. I have some t-shirts to give out at, if anybody would like an autopilot t-shirt and, I have a screen lock. And I also want to remind you there are feedback forms on your chairs or a chair near you. Please fill it in. By doing so, you get the opportunity to win some great Ubuntu swag. So please give some feedback. And thank you very much. Oh, sorry. One more question? No. So with landscape, with the autopilot, you can for free use up to deploy cloud on up to 10 nodes. That's for free for perpetuity. If you want to expand your cloud or deploy on more than that, then you require some licenses, additional licenses. Okay. Thank you very much.


As a tension grew between Japan and the United States, we started new, what we call, fitness training. So every so often we'd have to go make hikes through the city. It wasn't much territory for us to hike in. We did have a couple of parks, but most of the time we just marched into the street. And we easily carried a heavy marching order, which was all the material you would need to live in the field. The band still just did its duty without interruption. We continued to play our concert, but we made the marching order along with the rest of the troops. One of the elite characters of the Marine Corps in the old days was one Chesty Puller, which everybody knows, was the executive officer of the Second Battalion. And each of the battalions had what they called a group of field musics, which were drummers and buglers that performed their duties in addition to their service within the battalion. But for parades and ceremonies, the buglers and drummers joined the band to make a pretty sizable organization on the street, a very impressive one. And people that are still well remembered, I think, particularly the ones that were children, are now can recall that. So we always put it that the band helped the regiment put its best foot forward for America's presence in the Far East.


The following is a production of New Mexico State University. Patrick Quirk, Cactus Horticulturist at the Desert Botanical Garden in Phoenix shows us how to safely and properly transplant a cactus. Patrick, it looks like you're doing something important here. Well, I'm going to plant this large and unwieldy cactus. It looks like a large one. Sounds dangerous, though. It might be, but if you're careful and use the right tools, you should be fine. Starting with, to handle something so tall and difficult as this, is an old piece of hose that was no longer serviceable for watering. So you can cut them up into lengths and carry large cactuses of any particular description of that. Okay, I can see if you try and hold it just by the pot, there's a good chance it'll tip back on you. It definitely will. This allows me also to hopefully prevent some of these stems from breaking in the process of transport. So it's safety for you and safety for the cactus. Right, I don't want it to be half the size of what I'm done then when I started. Right. Let's see how it's done then. Okay, first I want to point out also that for handling smaller pieces, these beaker tongs are excellent for handling stems of this size, and these little hot dog tongs are excellent for handling little stems of this size. You can also use these in cactus handling. So now, I presume it's time to begin. Let's plant. Alright, now grab this, and this. Okay. Now I have to remove the bucket, and I'll do that by simply loosening it. Alright, here it comes. Okay. Now, this is a soil ball. The roots are well-involved in the whole thing. This is a soil ball made up of mineral soil. If this were made of an organic soil, I would have to clean all the soil off the roots, dry them out, and plant them later, because you can't have two incompatible types of soil, or the plant won't make it. I think this is really interesting. Other plants you don't dry out, but this one you clean it, then you dry it. Yes, the cactus roots have a self-healing quality, which is useful in that respect. So the next thing I have to do now is to loosen the roots from the soil ball so I'll engage with the soil successfully. This is not difficult. Like shampooing. Yep, just massage it up a little, break off some of the top here. Now, here we go. The moment of truth as we raise the flag.  Yes. I think some people would be tempted to plant it deeper than it was before. No, it's always good to plant your plants, be they succulent trees like this one, or ordinary trees and shrubs, or woody. It's always important to retain the same soil level as original. Now, I will firm the soil. This is very important. The soil will be firmly tamped for stability and so it can engage. And then finally, take your shovel and do this to be sure to get rid of any large air pockets and then just fill in and of course rake it up and dress it in any way you like. This cactus is a cactus called Steno-serious Stanley Eye, which originates on the warm Pacific coast of Mexico. So I planted it in this location due to the fact that this is a warmer section of the garden near the buildings and it will therefore rise tall and droop over a little bit without obstructing the view of other plants. Patrick, thank you very much. Thank you. The preceding was a production of New Mexico State University. The views and opinions in this program are those of the author and do not necessarily represent the views and opinions of the NMSU Board of Regents.


In the immortal words of the who who are you? Or maybe a better way to phrase it would be who am I? We spent a lot of time developing our own image of who we are and presenting that to the world and So having an understanding of our own self-concept is really important as a communicator in the way that we Deliver and send our messages and in the way that we interpret messages from others and understanding The role of self-concept in that is really important That's what we're going to focus on in this short video is Understanding the self-concept really just focusing in on what is the self-concept? I wonder some of the different attributes of that so first of all what is the self-concept?  I want you to think about Five things that are true about you Five things that you would say objectively are true about you You know it could be could be anything it could be your talk could be your brother You could be your a mom it could be you like volleyball it could be you're a good singer anything at all Whatever it is just write down or think about Five things that are true about me that I would say are objectively true about me So the reason we're doing this is because That's the start of and a part of really what we would call your self-concept The self-concept is just this relatively stable set of ideas that you hold to be true about yourself So it's relatively stable to it's it's takes a form and usually holds that for quite a while and doesn't change easily It can be changed, but it's stubborn it wants to say the same And there are things that you hold to be true about yourself now That doesn't mean that they actually are true, but in your mind they are as we'll talk about the self-concept It's not always accurate. It's not always objective But it's it's the stable set of things that you hold to be true about yourself So those things that you wrote down That's your self-concept or at least a part of it those things you say these this is who I am This is true about me. That's a part of your self-concept If we wanted to then go a little further and differentiate between the self-concept and the self-esteem We could then take that list of things that you said are true about yourself So bring that up in your mind again Bring up that list and look at it or have pull it up in your mind again What are the five things that you wrote down and then ask yourself about each of those things? How do I feel about that? How do I feel about that? Does that make me a better person? Do I think that's a good trait or something positive about myself? Or is it something that I'm that I try and hide that I don't feel as good about myself because of that thing? When we start to think about how we feel about each of those things that are part of our self-concept That's our self-esteem Our self-esteem tells us this is a good thing or this is a bad thing And this is something we should let out and let the world know where this is something We need to kind of you know tamp down and hide a little bit about ourselves That's the difference between the self-concept and the self-esteem again The self-concept is the relatively stable set of ideas that you hold to be true about yourself and your self-esteem is How do you feel about each of those things? So now that we have an understanding of what the self-concept is specifically and what self-esteem is But let's talk a little bit about what? What happens to develop the self-concept how that self-concept develops? Well, there are a variety of factors in the development of the self-concept of one of which is the personality and biology of the person So, you know, there are certain things that we're just born with right now It comes through DNA comes through comes to the genes through our genetics through our parents and And some of that is just biology and so we see ourselves I mean if you're super tall or you're super a good singer or whatever that may be something that you inherited from your parents But it could just be to your personality traits people tend to behave like their parents genetics are very very strong things so Our personality and our biology that will have a massive influence on our on our self-concept Also the reflected appraisal which basically means how do other people see you or and what impression do they give you about you know If they're judging you for example, if they're holding up scorecards, what do people say about you? And just in general, are you a good person? Are you you know somebody that people like to be around or they somebody that they avoid being around? And then more specifically you can get into different traits to how do people feel about your singing? How do people feel about your golfing? How do people feel about your parenting or whatever it is? That's that's reflected appraisal the input and feedback we get from others around us. Is that reflected appraisal? This is really especially powerful for where groups and individuals that we call our significant others Now it doesn't have to be somebody we're romantically involved with Significant others anybody whose opinion we especially value could be our parents could be our siblings could be our best friends Could be you know those people in particular when they say something it really hits home and really Has an impact on our self-concept positively or negatively So that's reflected appraisal though the input that we get and feedback we get from from those around us That helps shape our self-concept as well We also tend to engage in social comparison at times So we gauge ourselves against society in different ways and things we see around us. So For me It would it would be a better comparison for me socially to to go down to the wine compare myself as a basketball player to other You know middle-aged white guys down at the Y who are in my same You know kind of shape, which is not very good. My shape is round, right? So I'd be a much better off in terms of my self-concept and that'd be much more realistic For me to do that and have an idea of where I'm at as a basketball player than to compare myself with somebody like LeBron James Right or any professional basketball player or anybody within you basketball skill at all doing that's gonna You know really damage my self-concept if we have inappropriate social comparison groups but that doesn't mean we shouldn't shouldn't stretch ourselves and push ourselves toward goals, but At this point I'm not going to be LeBron James, right? So I need to find a reasonable social comparison group for my skills as a basketball player And we need to do that for the health of our self-concept as well be aware of our social comparison groups Then there are also culture and gender roles culture and gender And culture in particular influences everything about our life and everything about our communication So we look around at our culture for to see What's appropriate? What's good quote-unquote good, right? But we do need to be careful because this is contrary to what you see in the media We are not all supposed to look the same So we have this issue of you know, I'm looking around at my culture I'm seeing that I'm out of the norm right if this is the office of rules and norms I'm outside of the norm and that makes me feel bad about myself But the truth is in some ways, we're not all supposed to be the same So we need to be cautious with that as well But our culture will give us kind of those gut and those guardrails about this is who we are as a culture And as a people and try and stay within those things and then you have some people who intentionally work outside of that And that's part of there. That's part of their self-concept is to do that But but how we fit into that culture those culture and gender roles will have an impact on our self-concept as well So some different characteristics of the self-concept some different things we need to keep in mind and understand About the self-concept first of all self-concepts are multifaceted. We have more than one self I mean we have more than one self so to speak in different situations We will let these different selves out and and and show different sides of our personality probably and and so But we have the self concept is multifaceted. We don't just have one self concept or one self We have multiple cells and it's not a psychological break or anything like that.  We mentioned I mentioned this when we talked about the definition There there these things there it's there's these things that you hold to be true about yourself That doesn't mean they actually are right. We need a differentiate between objective and subjective Objective says these are oranges. That's objective whether you like oranges or not. Those are oranges subjective says I love oranges I do not love oranges. So my subjective view of this of this Of this pile of oranges will be different than the person on the right. They love oranges I don't but even so objectively we can agree that they are oranges So we need to consider things Remember that the self concept is subjective, right? It's possible for us to look at it and and see something different than somebody else Somebody else may tell us we're really good at something and in our mind we have a fix that we're not So we need to be aware of that and where that the self con our own self concept can be off at times It can be incorrect at most at times I Mention this before too are enduring, but they're changeable. They're relatively stable set of concepts, but they can be changed They they they're their their notion is to say the same, but they can be changed for sure This is a reference if you're familiar with the movie the princess brides. Hello. My name is in ego Montoya It's a reference to the movie the princess bride and there's a character in her name in ego Montoya And he spends his entire life and this is an ego. He's on the left in ego Montoya is on the left And he spends his entire life Going after this one goal of killing the six-fingered man then spoiler alert he does in the movie He gets to he gets to the six-fingered man And he does kill him and he avenges his father's death and afterwards he's talking to his friend Wesley at the window here and he's saying You know, I've spent my entire life chasing this one thing now I don't know who I am without that who am I his self concept is enduring his self concept was I am the greatest swordsman in the World I'm in ego Montoya. I'm here to kill the six-fingered man, and that's it Right and once that was done his self concept was having trouble moving on and shifting We've got to be able to have that flexibility and and you know work on that flexibility. It takes time We can do that though So this is just to give you an overview of the self concept and what it is now that we have an understanding Of what the self concept is we can get to some different aspects of how the self Impacts communication and what role it plays in communication If you have questions about the self self concept anything related to to communication at all, please feel free to email me I'd love to hear from you in the meantime I hope that you've done some evaluating your self concept and self-esteem and have a better understanding of what it is so that we move forward as And increasing our communication competence we can understand the role that self concept would play in that


This is Jeremy Gaussian. I'm coming to you live from Password Village HQ2 in sunny Austin, Texas. Today's high is 104 degrees. So today I'm going to be talking to you about what it's like cracking at TerraHash's scale. I'm not going to make this a bender pitch in any way. I'm going to focus on the technical challenges that we encounter as we support clients who have, you know, hundreds of GPUs in their clusters. You know, when I first kind of started on this, I kind of thought like 100 GPUs was a really big deal. Now we kind of tend to view 100 GPUs as like meh. I mean, it's good, but it's kind of middle of the road. So, you know, there's a lot of distributed solutions for hash cat out there. But as far as I know, TerraHash is the only one that aims to operate at warehouse scale. And what I mean by that is more so with the most recent version, but with every version that passes, we aim to embrace the concepts of data center as a computer. And while we currently don't have any clients who have an entire warehouse full of password cracking hardware, that's the point where we're trying to go. And we try to enable the software to be at that level even if our clients are not are not quite at that level. So I'm going to go through the history of how I got started in, you know, massive distributed cracking. And I'm going to go through the technical challenges that we faced as we continue to evolve our hashtag distributed solution. So I'm going to start the slide deck. So in the beginning, I kind of got into this because I was messing around with distributed computing, I was doing stuff with MPI, some other most like software rocks clusters, you know, things along those nature. But all that was all CPU based and then when GPU cracking came about. You know, we started looking for solutions that would enable us to distribute GP workloads. So I found a piece of software out of Hebrew University called virtual CL. And I did a presentation on a 25 GPU proof of concept cluster that me and bit weasel put together passwords 12 and Oslo. And when I woke up the next morning after giving that presentation, we had gone viral. We were on the front page of slash dot gizmodo boing boing NBC news, the register like we were everywhere. And in hindsight, I really should have used a lot more than 25 GPUs. I mean, we had more GPUs. That's just what we chose to dedicate to this proof of concept and had I known in advance in any way that the general public would react how they did to this proof of concept. I would have used like three times the number of GPUs. So just, you know, some of the headlines that came out the next morning that I woke up to, which was pretty surreal because I didn't really see this as a big deal. So, virtual CL was cool at the time because it was the first solution that I knew of that enabled us to sort of transparently distribute open CL jobs across the arbitrary cluster. So what virtual seal does is it provides a virtual open CL platform. And the target software in theory doesn't need to be aware it's communicating with a virtual platform.  So the target software just simply leased against live open CL which provided by VCL which then communicates to a broker demon. And then that broker demon distributes the agent demons and the agent demons which are installed on the compute nodes actually communicate with the real open CL library be at AMD and video whatever. So in theory, all this is transparent to the end application but in practice, it didn't quite work that way. We had to have a special fork of OCL hash cock called VCL hash cat, which had some workarounds for VCL quirks and such. It also required infiniband because it was really latency sensitive and ended up being a very chatty protocol and it required essentially real time communication bandwidth wasn't so much of an issue it pretty much consistently pulled you know less than one gig of bandwidth but the, it was really sensitive to latency, you know, even just a couple of milliseconds was a couple of those things were acceptable but if you start getting up into like double digits of latency.  And of course if end of end hardware is expensive is way more expensive than Ethernet. And it was also closed source and it required frequent updates.   And VCO was no exception. So, with VCL hash cat, we had to have our own workarounds for virtual CL. And then the VCL team or virtual CL team had to turn around and implement any workarounds for any new driver releases every time they were released, which is, you know, a pretty substantial job. The problem is virtual CL was created by grad school students. This was a grad school project, and they created this their senior year. And when they graduated in spring 2013, that was it. The project died. So when, you know, the next version of FGL or X was released, you know, I think that was version 13.9 in September of 2013.  This is actually a 64 GPU cluster, which I mean, we're just starting out.   And then we go to install virtual CL and FGL or X, and virtual CL just shuts the bed. So I like panic and email Hebrew University, you know, I'm like, you guys really need to update virtual CL for catalyst and FGL or X 13.9. And they, they're like, well, we can't everyone who is working on this project is gone. And intellectual property remains with Hebrew University and mosics. So they can just like, you know, have those people work on it outside of that. I offered to take over the project for them. Because it was kind of essential to what we were doing and I didn't want to see the project die. I thought it was really neat. But the professor over there who was in charge of the project was not amenable to that idea. He actually had pretty grave concerns when we first started using virtual CL for password cracking because he envisioned us turning the world into like a giant botnet. And of course that wasn't really on our agenda, at least not at that time.  So we were left high and dry without a software solution. And so we desperately needed something. So we conceived the idea of hashtag.  But the more we actually sat down and thought about what that entailed, we determined the level of the level of effort for that was just way too high. And the timeframe in which we needed it was way too short. Like we literally had, you know, hardware in house that we're building for clients who now have no software solution because of virtual CL. So we decided to make a distributed wrapper and that's when we came up with the idea of hashtag. Like I said, we had iterate really quickly on this. So we went from a whiteboard session to production in less than two months. And this was basically me and Tom Steele locking ourselves in the office and, you know, ordering like over $100 for the Taco Bell and just banging this out as fast and furious as we could. I had a traditional client server agent architecture. And it was hashtag focused, but it actually had a generic plugin interface. We had plugins for and this is before there was just one hashtag, right?  And then we had like just a generic interface to where any cracking tool could be made to work with hashtag as long as it adhered to like a standard format that we had defined. And then it also had the ability to run arbitrary commands when idle. This was less for our clients and actually more for me because we were running hashtag in house as well for our, you know, cracking as a service type stuff. And this is back in a time when GPU mining was still profitable. So when we weren't working on a password cracking job, I wanted this thing to be generating coins in the background. So the arbitrary idle accept command was literally just put in place so that people could like mine light coin or name coin or whatever when their when their cluster was idle. So, you know, totally different time. But I mean, it actually worked, you know, it did exactly what it's supposed to do and it was good. And the whole goddamn thing was implemented in this fancy new language called Node.js. Again, this is, you know, early 2013. So like, you know, Node.js was the new hotness and, you know, everyone was starting to move that direction with microservices and everything and that's something is not on the slide but we implemented hashtag version one entirely as microservices.    But even then like our clients would still kind of mess it up, you know, they're, you know, like they would upgrade like 10 of 20 packages and then like the other ones would just be stuck at all versions or, you know, one demon would die and another demon would know that it's dead so then it would be fine anyway.  I tried to use all like the latest and greatest everything because at the, at the time that seemed like the best idea. And also hashtag was more than just workload distribution. So a lot of our clients at the time to thought that hashtag was just a GUI friends in for hashtag. So it's not, it's not just a web UI for hash cat.  But it actually did a hell of a lot more than that. In fact, when you installed hashtag on your box, it basically hijacked it and configured it exactly the way that we needed to be configured it would actually provision the entire server from just installing like the initial meta package. So it's a complete stack of packages they get stack hashtag that's where it comes from. So we had a driver installation driver configuration driver updates and again this is back at a time and even nowadays so kind of a challenge but this is back at the time when GPU drivers were painted in the as to install and then once you've got them installed it was painted in the as to the update. So the fact that we kind of handle this automatically was a pretty big value at also handle XOR configuration even though these are headless servers.  There's probably very few people watching this who actually remember that. But yeah, if you had a completely headless server each one of those GPUs had to have a special dummy plug attached to it. So we had to collect the necessary pins to trick it to think that there's actually a monitor attached and we actually had to run XOR because even though these are headless without XOR we didn't have the ability to manually set fan speeds or GPU clock rates or set like power to profiles or any of that. So, even though this is a headless server we still had to have dummy plugs to think there's a monitor attached still had to run XOR and still had to configure XOR properly.  And then along those lines. Hashtag also did GPU tuning for you and also automatic overclocking. And this was kind of a double-edged sword. When the R9-290X came out, at first it was like entirely unusable because of the way that AMD aggressively implemented power tune firmware, power tune, I think it was 2.0 at the time. But the GPUs would throttle so aggressively that it was like way slower than the 7970 and it was just essentially unusable. And I wrote OD6 config.  I'm sorry. Oh, no, no, power tune is AMD. Power miser is AMD. All right, whatever. So OD6 config, you know, enabled us to properly configure the R9-290X and but it was still like it was good but it was still kind of like mediocre, right? But at that time when I measured it, it was only drawing 300 watts, which is important because our server platforms like the Brutalis can only handle GPUs that drop the 300 watts. You draw more than that. You're going to blow a fuse on the PCI slots on the motherboard. So we had an automatic overclock profile for the R9-290X that we pushed out to our clients that made the GPU draw just about 300 watts. And then a little bit later down the road, about a year, year and a half later, AMD pushed out a new driver update that actually caused the power consumption to go up by a good 50 to 75 watts. And we did not know this. This kind of went undetected by us until we started getting a rash of clients who were seeing dead PCI slots on their motherboards and all of them had R9-290X based solutions.  But we actually had the ability through all these mechanisms that we had in hashtag at the time to enable like the automatic overclocking and configuration and all that to push out a new underclock profile to all of our clients to try to drop the power consumption down to keep it from blowing PCI slots on the motherboards. So it's both good and bad. Like the fact that we're able to automatically overclock GPUs, you know, to help get the most speed of the GPUs is awesome. But then like in that one specific scenario, it was bad because you start blowing PCI slot pieces. But then it was good that we had this functionality because then we could like correct it through software over the air and automatically correct it on all of our client systems at the same time, which saved us a lot of money because we were, you know, spending hundreds of thousands of dollars on new motherboards. So yeah, and then of course, hashtag also had cluster resource monitoring. So there were some drawbacks. Like I said, the entire guide amp thing was written in Node.js. And while Node.js is asynchronous, it also runs on a single CP thread that may have changed at some point. But we're talking like 2013, seven years ago, and I haven't even touched Node.js since.  So yeah, any long running methods would just totally block the entire application. And we had massive scalability issues. I think the very first like alpha that we released to clients can only support like four nodes. The second one, we were able to get up to like, you know, nine or 10 nodes. Basically anytime a client ordered a cluster larger than the previous largest cluster we had ever built, we ran into some kind of scalability issue identified some bottlenecks and had to work to remove those bottlenecks. Unfortunately, 90% of the time the bottleneck was the fact that JavaScript was too slow for the tasks that we were trying to do. So we had to reimplement, you know, those bottleneck methods in a faster language and they just shell out to them. So like key space calculation was re implemented and see now calculating key space for a mask attack is like really lightweight. But you know, when you talk about massive dictionaries or rule files, trying to count the number of lines in a file with JavaScript is painfully slow. So that's largely why that entire portion was re implemented and see, and we just like shelled out to that binary to eliminate that body now not eliminate but dramatically reduce it. Um, regex anything regex, we actually implemented we had re implemented in Pearl because Pearl is amazing at regex JavaScript is not very good at regex. The primary thing that we're doing with regex here was like validating the hash lists right so client uploads a uploads a hash list and, you know, some of our clients wouldn't even bucket throwing like 200 million hashes at hashtag right and like one job. But then hashtag has to sit there and, you know, receive the massively large hash file and then validate each individual hash. And then, you know, stuff in the database. That was a massive bottleneck.   But yeah, so we also used MongoDB, because no sequel was like, you know, the rage at the time. And out of all the no sequel databases we tested Mongo was the most performant.   Like, you know, they would go through the process of creating a job, uploading the hash list, and they would just sit there with like the little spinner for a while until it timed out. And then so they'd go to create the job again because it timed out, right? And then they'd go back like 10 minutes later and find out that the other job had finally completed and was actually active and running. But because they went through the process four times trying to get it to start, now they have like for the same process running on the cluster. So we threw Redis in front of Mongo as an in memory caching layer. And that actually had a significant impact like positive impact. And they enabled us to ingest hashes a lot faster. But still not a very great solution overall. The web UI clients was implemented implemented as a single page application in Angular. It was really clunky. It was really heavy. It was really slow. It constantly caused the browser to freeze if you left it up for more than like 30 minutes. And it just had a ton of bugs.  You know, if there's no way to move quickly in that UI and it gets very repetitive and very tedious. So there was a lot of drawbacks to having that Angular web UI. I absolutely hated it. And, you know, anyone who was like really experienced with with cracking and hash cat and stuff, they also hated it and begged us not to have that again. And we were just severely limited by what we could do in a browser for non hash formats at the time. We were scraping everything server side.  And we would, you know, scrape the file server side to get the necessary bits, you know, like office to hash cat and PDF to hash cash like that. The problem then became like, what do we do with things like, you know, true crypt volumes or really large sevens of volumes or raw files. Right. Like, are you really going to upload like 100 gigabyte disk image through the browser and just we can scrape off like two kilobytes. Like, no, that doesn't make any sense. So yeah, the browser was an issue and then we implemented access controls, but there was nothing fine grain. We assumed that because everyone operating the hashtag cluster was on the same team that, you know, they all kind of had equal rights and equal access to the cluster and therefore all users are admins. We didn't have like, you know, different roles or anything, it was just, if you have an account, then you obviously have a right to be there.  And I think some of our clients have no problem with that because it's like, yeah, like everyone on this team does do, you know, have equal rights and access and privilege to the cluster. So this is totally fine. Other clients were like, this is absolutely unacceptable. They eventually got to the point where the old version one code was completely unmanageable. Even just implementing what should have been like a minor bug fist ended up like requiring major refactoring. It just wasn't because we threw it together in less than two months, you know, so we didn't think of everything in advance, you know, that would come up and it got really, really hard to implement new features and, you know, try to work around some of the, you know, some of the bugs in there. So we decided we needed an entire ground up rewrite for hashtag version two. And at some point I got the idea to create a commercial fork of hash cat with native distributed capabilities.  It seemed like the best idea, like in the world to me at the time. So we set out to do just that. Now this is right before hash cat went open source. And then we started work on this like literally the minute that hash cat went open source. So we implemented and go laying and see with postgres database. Now we chose go laying because of hiking high concurrency with with go routines right. So with no JS everything ran on a single CPU thread and we wanted the opposite of that for version two, right, we're going to learn the lesson on that.  And going actually also allows for pretty rapid development so we thought it was a pretty good choice.  So the first thing we had to do is we had to split hash cat in two.  And everything else we placed into the server library. And then for any code that wasn't already in hash cat, such as like the Jason API, and the, you know, proto buffs for agent server communication workload distribution multi user access control and this time we actually implemented fine grained multi role access control. All that was implemented and go, and then we just linked against the sea libraries and this effort actually laid the foundation for the hash cat 4.0 refactor with live hash cat. And then, because of how clunky our old web UI was, we actually ditched it entirely for a cross platform CLI, which made our power users like really happy. But our less experienced users were not very thrilled with that decision. They still wanted, you know, a GUI, which fair enough. So our plan, initially was to maintain both hash cat and hashtag trees in parallel. And then if there was any features that we added to hashtag, or any like new kernels that we wrote, we would just, you know, backport those as we chose to ask at this didn't really work out very well in practice though. So when we released version two, it was in sync with hash cat 3.5, but it didn't stay that way for very long. And of course we had to add a cross platform GUI to the roadmap as well because we had significant feedback from our clients that they really wanted to goddamn GUI and they were not happy that we took away the web UI.  I completely underestimated how much work was involved in creating a commercial fork of hash cat.  We spent like 100% of our time just backporting things from hash cat into hashtag instead of actually adding new features or running new kernels. Like literally months of work, you know, just backporting hash cat commits. And I got really frustrating, you know, it's like, Hey, are we, are we working on these tickets? Are we working on these features? No, we're working on backports.  And then when Adam refactored hash cat for 4.0, that also meant that we had to refactor hashtag as well. And we hadn't even finished implementing all the backports at the speed that Adam was, you know, committing things to hash cat. So this was just like, absolutely unmaintainable, right?  And then there was also this other little minor problem where we picked the wrong HTTP library for the API. And this basically limited the service capability to about 12 nodes. Now, 12 nodes might seem like a lot. That's 96 GPUs. You know, that's a pretty respectable size cluster. The problem is, this particular clients had ordered 320 GPUs, 40 nodes. And you can't really deliver a 40 node client to a cluster with a server that can only really handle 12 nodes.  And there was no, like, drop in replacement. So basically anywhere where we were dealing with HTTP, we had to rip out the old library and then, you know, add in all the stuff for the new library. But they did resolve the issue. It was just really painful at the time to have to mess with that. But the server still continued to be a single point of failure and still proved to be a source of bottlenecks as we, you know, tried to build larger and larger clusters. We kept running into problems with the server being a bottleneck and a single point of failure. And we also had clients coming to us asking us if they could order multiple cluster controllers and cluster them together, you know, either high availability or like load balance them or something. And we didn't have a solution for that, but I started thinking about a solution for that. And again, like 40% of our clients were just completely pissed that we had no GUI.  Like we never ever want to make any of these mistakes ever again. We've learned a lot of lessons from, you know, what we've done over the last seven years. So, but we need more than just completely ground up rewilding. We need an entire paradigm shift. Like we need to rethink this entire problem entirely and come up with something that's completely different from what's ever been done. So we need to eliminate the single point of failure at the server. We need to enable like actual infinite horizontal scaling, because again, we're, you know, we always try to strive for like warehouse as a computer. Right. We're looking at warehouse scale computing as like the target that we're trying to hit. There should never be any, you know, limiting factors outside of budget for like how many nodes we can support in hashtag right. And then of course the other big requirement is we have to actually move at the pace of hashtag development. We have to, you know, as Adam commits things to hashtag, we need to have those not instantly available on hashtag, but within a very reasonable time frame. So the very first idea that we came up with was let's not do a traditional client server agent model. You know, and let's not even try to cluster the cluster controllers. Let's just eliminate the cluster controllers entirely and make everything peer to peer where all nodes are equal. And there are no dedicated servers. And the biggest requirement to this is that work can be submitted to any node. So let's say you have like, you know, 20 users and you have, you know, 10 boxes, like there shouldn't be just one node that all of them have to hit. They should be able to hit any node in the cluster and, you know, have the same view from any node. And it also needs to be more user friendly than ever. And also needs to run on Windows. I'll tell you why in a minute. So set out to like figure out how we're going to implement this because we have we have the high level requirements, right? Like we know it needs to be peer to peer.  How are we actually going to do this? So pretty obviously we're going to need some sort of distributed state machine, right? And that that's just straightforward and self-explanatory. But, you know, like, like, we just don't message queue at it and some pubs up and, you know, Bob's Uncle. But what about disagreements or, you know, maybe even more than disagreements?  So I started coming up with solutions for this. And I somehow got into my head, like, dude, what if computers could vote? Right? Like, you just make it to where, like, you know, if there's a dispute, then one of the nodes like requests to vote, right? And so they take a vote and majority wins.  Like, why not? And if a peer doesn't accept the results, like then the rest of the cluster just shuns that peer. And I started thinking about, like, is this, is this actually like a thing? Like, can we actually do this?  It turns out that I really don't have to put that much more thought into it because this already exists. Like what I thought up is actually a thing called the Raph consensus protocol. Now, it's cool that it already exists because that, you know, means we don't have to do a whole lot to implement it. But it's also cool because it kind of validated, you know, my ideas and theories on how to make this work.  And we found several implementations of the Raph consensus protocol. And the one that we ended up liking the most and settled on is ACA, which runs on the JVM that's written in scale.   You know, I completely condemn Oracle JVM. But there is open JDK. We don't have to use Oracle. And we don't have to write in Java. We can use scale in Kotlin. And since I've started to work on this, I actually really like Kotlin. I don't really have too many negative things to say about it. It's actually kind of fun to work with. And then ACA also has some plugins or modules that, you know, help us even further, such as ACA persistence. What ACA persistence does is it takes our distributed state machine, which is normally resident memory and persists it to disk. And then ACA distributed data, of course, would be like what implements the distributed state machine. And then on top of all of that, we built a custom multi-cast base protocol to enable cluster nodes to automatically discover each other on the network, and then automatically join the cluster. Now we made this opt-in because obviously that's kind of a security risk if anybody can just join the cluster at will.  So, you know, again, thinking about warehouse scale computing or, you know, data center as a computer, let's say you just have racks and racks and racks of compute nodes. You would just unbox one, literally throw in the rack and power it on, and it would discover the cluster as soon as it's powered on and join the cluster and start doing work. You know, that's kind of the vision that we have for this. And of course, since it's all peer-to-peer, you know, that enables it to actually be just literally that simple. But of course, you know, the default is you manually specify which peers you want to be part of this work. Okay, and then in April this year, we had the unique opportunity present itself to purchase Lothcrack. Dildog approached me and then we entered negotiations and we purchased it early this year primarily for the GWT, which is written in C++ using QT as the windowing framework. And while it's not currently cross-platform, that's a really easy platform, or that's a really easy language and library to make cross-platform. So instead of hashtag version 3, we now have Lothcrack version 8. And while Lothcrack 7 uses John the Ripper as a backend, we've ripped all that out and we are in the process of integrating what was hashtag version 3 as the new backend for Lothcrack 8. And the final thing we're doing with this is we are dropping the TerraHash hardware requirement.  We say like, you know, the only way to get hashtag is to buy a TerraHash appliance and it comes pre-installed and that's the only way to get it. But Lothcrack has always been sold standalone. So we are changing the model now to where, you know, keeping with Lothcrack being sold standalone, we're going to be selling, you know, Lothcrack 8 as a standalone product without the TerraHash hardware requirement. So yeah, that's where we are now with development. That's how the product has evolved over time. And that's some of the challenges that we have faced trying to obtain our goal of true warehouse scale computing. Thank you and hope you've enjoyed this.