Welcome to class 38 in Topics in Power Electronics and Distributed Generation. In the last class we have been looking at an example of a 10 kVA 3 phase inverter and at 400 volts AC connected to the grid and through a filter inductance and we are looking at different aspects of the problem. We looked at what duty cycle commands would be required at certain instance of time. Then we looked at what would be the value of the filter inductor. We looked at the Faser diagram for operation as a unity power factor active rectifier and then we looked at for short durations of time what the switching functions would be for the three legs, what the common mode voltage would be on the AC side and the DC side and then we looked at the parasitic components of the power converter through which these common mode currents could potentially flow. Then we looked at the expression for the DC bus current and we looked at the different frequency components of the DC bus current and its RMS levels under various operating conditions. So, we use that to then look at what would be the lifetime of the capacitor the power loss in the capacitor bank and the minimum and maximum voltage on the DC bus in terms of looking at the DC bus ripple and we did that for assuming operation under balance conditions. We looked at currents at 5 kilowatt power level and at full rated 10 KVA operating condition. So, in the next part of the problem we are looking at when you have a 3 percent unbalance in the grid voltage and what would be the effect on the frequency components of the currents and what would be the lifetime of the capacitors, the power loss in the capacitor and the ripple on the DC bus under a when you have a 3 percent imbalance. So, under when you had balanced operation the numbers that we calculated was that we are power loss in the or power loss in the capacitor was 5.6 watts and then we use that to evaluate the temperature of the core of the capacitor and the temperature worked out to be 70.3 degree centigrade and we got a life of 2.28 years and our core temperature was 70.3 degree centigrade and the power loss in the bank is 11.2 watts because there are two capacitors in the bank upper and the lower capacitor and then when we looked at the ripple voltage we saw that the ripple voltage was dominated by the ESR effect because the ripple current is at high frequency in this balanced operation and we saw that the ripple voltage due to the capacitive effect had a amplitude of 3.6 volts whereas, due to the ESR the amplitude was 6.3 volts. So, the ripple on the capacitor bank which consists of two capacitors is about 1.3 volts and so we would have a VDC max of 800 plus 1.3 and so this appears at high frequencies as a band around the nominal 800 volts. So, in the next part of the problem we are looking at the 3 percent imbalance and what would be the resulting quantities that would need to be evaluated on a similar manner. So, if you have 3 percent unbalance we are talking about in terms of the ABC voltages we are looking at from a symmetrical component analysis you would be able to say what the voltages are. So, you can write the symmetrical voltage and transformations, symmetrical components transformation V 0, V plus, V minus and V plus is 326 volts which is our amplitude of the line to neutral voltage when your line to line RMS is 400 volts and your negative sequence voltage is 9.8 volts which corresponds to 3 percent of your positive sequence voltage and your 0 sequence voltage is 0. Using this you can calculate what your V a, V b and V c are the 0.1 radian angle difference is from the previous Fischer analysis required for part transfer and V b. So, the signs of 2 pi by 3 is opposite because this is a negative sequence quantity. So, you could then make use of the quantities ABC voltages and we will also assume that the converter still operates with balance currents in its output you could using your the average model come up with your I average would be 12.5 plus 0.375 cos 2 pi 100 T amperes this is at 10 kilowatt and power level of operation at 400 volts. So, you could see what this 12.5 and 3.75 numbers correspond to your 12.5 is essentially 3 into 327.6 into 20.4 divided by 800 which is a DC bus voltage 3 by 2 into 800. So, this is the 12.5 327 is the amplitude of your positive sequence voltage 20.4 is essentially 14.4 amps correspond to 10 k V a operation of a three phase power converter at 10 k V a and the amplitude would be root 2 times 14.4 which is 24 20.4. So, you get that to be your from your DC power transfer and your interaction of the positive sequence current and your negative sequence voltage 9.8 volts times your positive sequence current would give your 100 hertz ripple in addition to that you have the high frequency ripple current. So, you could then evaluate your overall spectrum of the currents that that would be flowing through your DC link. So, at 10 kilowatt power level also at 5 kilowatt power level you have 12.5 amps DC at 10 kilowatts or half of that 6.25 amps at 5 kilowatt power level. If you look at your 100 hertz you have 0.37 amps peak or 0.186 amps at 5 kilowatt power level and your high frequency RMS this occurs at the switching frequency and its harmonics this is 8.8 amps RMS and 4.4 amps RMS at 5 kilowatt power level. And you could use these numbers to evaluate your temperature losses in the capacitor bank and corresponding temperature rise. So, the losses in this particular case our loss per capacitor is 8.8 square that is the high frequency RMS current times 71.5 milli ohms resistance ESR plus 0.37. So, this turns out to be the same 5.6 watts because the quantity due to the unbalance is quite negligible compared to the quantity the 8.8 amps flowing at the high frequencies. So, you have 5.6 watts for the capacitor bank and 11.2 for the capacitor and 11.2 watts for the overall bank and because a participation is not changed your core temperature stays the same is 50 degree ambient plus 5.6 watts into 3.64 which was the thermal resistance that we calculated. So, this turns out to be the same temperature 70.3 degree centigrade. So, your lifetime stays the same which is 3000 hours into 1.2 factor into 2 to the power of 95 minus 70.3 by 10. So, this turns out to be again 2.28 years. So, the 3 percent unbalance did not cause a change in the lifetime because the power dissipation stayed the same, but if you look at it from the perspective of the DC bus ripper you have due to 100 hertz you have V 100 the 100 hertz component is 0.37 into the impedance 1 by 2 pi 100 into 1100 microfarads capacitance. So, this is 0.54 volts per capacitor. So, the overall bank would see about 1.1 volt. So, this would be in addition to the high frequency ripple that shows up and the due to the ESR effect. So, your V DC max this is 0.54 into 2. So, about a 2 volts or amplitude ripple riding over the DC bus. So, you can see that in terms of the unbalance there was a effect on the ripple, but not much in terms of participation or lifetime projection. In the last part of the problem you are asked to repeat the again this calculation when the inverter is operating as a STATCOM providing 10 KVA leading war to the grid to a balanced grid. So, you could do a similar calculation and identify the frequency components of the current then use that to calculate the expected life of the capacitor the power loss in the capacitor bank and the ripple on the DC bus. A similar procedure could be adopted and I will just mention the answers in this particular case. So, in this particular case your inverter voltage terminal voltage is higher 253.6 at angle 0 and at 10 KVA your high frequency RMS current turns out to be lower it is 7.2 amps and there is a no 100 hertz ripple because there is no unbalance. And your lifetime of the capacitor in this particular case works out to be 3.66 years and your power loss in the capacitor bank is 7.4 watts in the bank and your ripple is plus or minus 1 volt in the DC bus due to the high frequency ESR of the capacitor. So, you can see that once you have the procedure for evaluating this components you could apply it for a variety of conditions and see how your DC bus capacitor would be operating. In the last part of the problem you are told to evaluate as to evaluate the losses in the semiconductor devices the 3 legs of the inverter consists of 1200 volt 50 amp IGBT modules and the conduction and switching loss parameters are for the IGBT the collector emitter voltage on during on condition is 0.88 volts plus a resistive term of 0.25 times I c. Similarly, for the diode you have fixed on state voltage term of 0.9 volts plus a resistive term of 0.26 times your diode current the switching parameters for the for the loss parameters are evaluated at a DC bus voltage of 600 volts and at 50 amps. And the on state loss of the switch is 5 millijoules under these conditions the off switching off loss turn off loss is 4 millijoules for the diode for reverse recovery it is 3.6 millijoules and we are assuming the scaling factor for voltage and current to be equal to 1. So, you are asked to evaluate the total power loss in the 3 phase inverter operating as a active rectifier under normal grid voltage. So to evaluate this will look at the losses in each component the diodes and the switch. So the first thing to look at is what your duty cycle of each leg would be your duty cycle would be 0.5 plus 328 by 800 times cos 2 pi 55. 50 t minus 0.1 and these were numbers that we got from the facer analysis. We have the switching frequency f s w to be 5 kilohertz which means that your switching period is 200 microseconds. So the number of switching instance in a fundamental cycle is 20 milliseconds divided by 200 microseconds. So, you have 100 switching instance. You also have your phase current I a of t is 10 into 10 to the power of 3 divided by times square root of 2 to get the peak. So at 10 kilowatt power level. So, you could use that to then evaluate the conduction loss. So, starting with conduction loss in the diode. So, top diode d a the energy loss can be evaluated over a switching interval. Your conduction loss is for d a top diode at each switching interval is given by 0.9 times I a. At instant I is 0.26 into I a square at instant I for a duration of d a at the I th instant times your switching duration t s w for I a which is positive or 0 otherwise when I a is negative and then your conduction loss term over a fundamental is given by 1 by 20 milliseconds 20 into 10 to the power of minus 3 summation of the energy loss terms from I is equal to 1 and there are 100 points over a fundamental. So, you have and this number adds up to be equal to 27.8 watts. Similarly, you could calculate the conduction loss in the in the I g b t. So, you have conduction loss in I g b t s a the bottom I g b t at instant I it is given by 0.88 times I a of I plus 0.25 I a square of I and it is operating for a duration of 1 minus d a. Of I times t s w when I a is greater than 0 and 0 otherwise and then to transfer from the conduction to the energy to power over a fundamental cycle 20 milliseconds summation I a is equal to 1 to 100 of e conduction of s a times t s w. And this turns out to be 5.06 watts then the remaining term that need to be evaluated would be the switching loss term in the I g b t and the switching loss term of the diode. So, you have for the I g b t s a bottom at instant I is your e on and then you have at rated condition plus e of at rated condition times your actual d c bus voltage is 800 volts the rated condition specified is at 600 volts to the power of k v which is 1 and I a at instant I and 50 is the rated condition again to the exponent 1. If I a is positive and 0 otherwise. So, you could then transfer from your energy to your power over the fundamental switching loss power loss in the I g b t over a fundamental be equal to the 1 by your duration 20 milliseconds the summation of your loss I 1 to 100 and of e s w s a b of I and this turns out to be 15.06 watts for this particular operating condition the 10 kilowatt operating condition as active rectifier. If you look at the switching loss in the diode the anti-parallel diode you have the reverse recovery term under nominal condition times your 800 by 600 the power of k v again we have taken this as 1 it could be a number less than 1 more commonly and again I a of I divided by 50 again for reverse recovery it is a number typically less than 1, but we have taken it as 1 for I a greater than 0 and 0 otherwise. So, again you calculate your power from your energy over a fundamental cycle the time is 20 milliseconds for a fundamental and this turns out to be 6.25 watts and for the this is per I g b t device or per diode. So, if you have a three phase inverter you have 6 I g b t switches and 6 anti-parallel diodes so for the inverter would be 6 times. So, this would be 328 watts so if you are looking at the efficiency of such a converter your efficiency considering just the losses and the in your semiconductors would be 96.7 percent. So, if you are considering losses in the other components like your DC bus capacitor in your filter inductors the efficiency would come further down. So, this is the maximum achievable efficiency due to the losses in the semiconductor itself. So, in the next problem we are looking at a 3 phase 6 switch SCR current source inverter and we would like to show that it can be modeled as a pair of a single pole triple throw switches and we will label the switches in the sequence of the firing pulse typically given to a current source inverter and we will assume that the input voltages are balanced and sinusoidal phase is phase shifted by 120 degrees. And first part of the problem is to show that the single pole triple throw switch meets the requirement for efficient transfer of power between the input and output of the current source inverter. So, if you look at typical current source inverter you have thyristors or GTOs connected. So, you need reverse blocking devices 3 phase so you have voltage V A V B V C current I A I B I C your DC link has a large inductor which emulates a current source and the output can be a load or it can be a source in when you need regeneration or breaking and you could then write down the expression for the voltages. So, you have a balance set of voltages V A V B is A sin omega t minus 2 pi by 3 and to model it we could so to show that you could model it as a pair of a single pole triple throw switches. So, the previous power converter can be modeled as a pole connected to 3 throws on the top and similarly a pole connected to 3 throws on the bottom. So, you have essentially switch which could link 0.1 to the top or 0.3 to the top or 0.5 to the top or you could link say 4 to the bottom or 6 to the bottom or 2 to the bottom. Again 4 6 2 1 2 3 you are essentially the switch switches which could be the thyristors or GTO's which would be fired and a typical firing sequence would be 1 2 3 4 5 and 6. So, hence the labeling 1 3 5 4 6 2 for the for the switching devices. So, you could see that in this particular configuration your top single pole triple throw switch would be either in position 1 3 or 5 which means that 1 and 3 is never shorted together because the pole would be only at one of these three points. So, which means that your voltage source would never get short circuited. Similarly, your top throw would be either on 1 3 or 5 and your bottom would be either on 4 6 or 2 which means that your current source has always a path for the current you will never be open circuiting the current source. So, for example, when in this particular configuration your 1 is connected to phase c which means that I c would be equal to I d c and 2 is connected to v a which means that I a would be equal to minus I d c. So, you always have a path for current and you will never short out any of the voltage source and you can efficiently meet the requirements of the voltage sources on the a c side or the current source on the d c side and hence power can be transferred without any shorting of voltage source or opening of the current source and you always provide a path for the source conditions to be met. So, in the next problem we would like to show that the switching states of this particular CSI converter can be shown as by two pair of vectors with three binary values. So, b 3 so the each vector would have a binary value of 0 or 1 and there would be three terms for that particular vector. So, b represents the set of binary numbers. So, if you look at your switching positions your top switch could be considered as a switching vector sp and when sp is device 1 is fired at switch 1 your sp vector could be shown to be 1 0 0. Similarly, when it is at position 3 your sp vector could be 0 1 0 and when it is at position 5 your sp vector could be 0 0 1. So, you could think of sp as a vector with three components sp 1, sp 2 and sp 3. So, you could think of each sp 1, sp 2, sp 3 taking components values of either 0 or 1 and depending on whether it is at position 1 3 or 5 it could take the corresponding values. Similarly, for your vector s n so for the switch s n at position 4 you would have s n would be 1 0 0 and similarly at 6 your s n would be 0 1 0 and at 2 your s n would be 0 0 1. So, similarly s n vector can be thought of as three components s n 1, s n 2 and s n 3 each having a value of either 0 or 1 and the switch provides information about the status of the which switch in the power converter is on at a given duration of time. So, either of the three components of s n can be 1. So, no two of those s n values components s n 1 and s n 2 cannot be simultaneously 1 any one of the three can be 1 at a given point. Similarly, any one of the sp components can have a value of 1 and in the next problem you are told to show the switching space vector diagram for the current source inverter and show that it corresponds to a hexagon and to identify all possible 0 states of the current source inverter. So, we have seen that the voltages V a V b V c are given by this quantity and then we can look at what duration of angle alpha where alpha would be equal to your omega t would each of the switch s p and s n be on for what durations corresponding to say for a diode bridge operation where your firing delay is close to 0. So, under such a condition what would be the values that s p and s n takes. So, for so when it is operating without any delays firing delays etcetera for the thyristor your your s p would be on for 30 degrees less than theta less than 150 degrees and 0 otherwise. Similarly, sp 2 would be on when that particular phase is having carrying the highest voltage. So, this would normal conduction duration would be between 150 and 270 and 0 otherwise. Similarly, sp 3 would be 1 for 270. Similarly, you could write the durations when the bottom switches would be naturally on s n 1 would be 1 for 210. Similarly, s n 2 and s n 2 would be 1 for 90 degrees less than theta less than 210 and 0 otherwise. So, this is when your diode rectifier is essentially operating as a 6 step in 6 step operation assuming constant DC current DC link current. So, if you are operating at high frequencies in PWM you will be using states which are adjacent in this shorter durations of this particular angles. So, you could then look at your transformation from your A B C reference to your alpha beta reference because your state vector diagram is drawn in your alpha beta plane.  So, then you could look at the durations say for duration between say for theta belonging to say theta say 30 degrees to 90 degrees. If you look at this particular duration then we could see that s p 1 would be having a value of 1 with the others being 0 and similarly, your s n 2 would be having a value between 30 degrees and 90 degrees this would be having s n 1 would be having a value of 1 and the s n 1 and s n 3 would be 0 and s n 2 would be having a value of 1. So, you could write your s vector to be equal to 1 minus 1 0 and you could use this transformation to look at your s alpha beta to be equal to 1 minus 1 by root 3. Similarly, you could look at your other switching positions from 90 degrees to 150 degrees your switching vector is 1 0 minus 1 and your s alpha beta would be equal to 0 1 by root 3. Your third position would be for theta belonging to the range 150 to 210 your s vector would correspond to 0 1 minus 1 and your s in your alpha beta plane would correspond to 0 2 by root 3 and your vector 4 would be for the duration 210. Then 270 your s would be minus 1 1 0 and your s alpha beta would be minus 1 1 by root 3 between 270 and 330 degrees your switching vector would be minus 1 0 1 s alpha beta be equal to minus 1 minus 1 by root 3 and your 6 vector would be theta during the duration 330 to 30 degrees. So, if you plot these vectors you will see that the 6 vectors you would have the corresponding positions of 1 2 3 4 5 6 there are 6 points around a hexagon. So, you would get a similar space vector diagram and 0 vector corresponds to the center unlike the voltage source space vector diagram this is actually rotated by 30 degrees. So, this is very similar to what you would experience in a for a voltage source inverter you could make use of the modulating states and show that for a current source inverter also you have a hexagon corresponding to the state vector diagram. The 0 states would correspond to the condition when say for example, if both the the throws are at the same point then essentially the voltage seen by your DC source would be 0 because 2 switches would be connected to the both the throws would be connected to the same pole and your voltage sources would all be open circuit at which means that your I a I b and I c would be equal to 0. So, there is no energy transfer during the 0 states and there are 3 possible 0 states you could either be connected to 1 and 4 or you be connected to 3 and 6 or 4 and 2. So, you have 3 0 states. So, you could write down the 3 0 states as so there are 3 possible 0 states and unlike in a 2 voltage source inverter where there are 2 0 states in a current source inverter there are 3 0 possible 0 states. To look at the input-output relationship between your AC and AC voltage and the output DC voltage and also the DC current and the input AC current you could write down the relationship. So, you have your I a is equal to S p 1 minus S n 1 times I d c is equal to S p 2.  You could also write it as in a more compact form we have I a b c vector to be I a b c vector to be I a I b I c and S p 1 S p is equal to S p 1 S p 2 S p 3. So, you could write it as I a b c vector is equal to S p minus S n times I d c. So, this relates your AC side currents to your DC current of your CSI. Similarly, you could write your where essentially your S p vector is S p 3 and S n vector is similarly you could write your output voltage V out which is the voltage across your positive and negative poles of the of the switch is S p 1 V a plus S p 2 V b plus S p 3 V c minus S n 1 V a plus S n 2 V b plus S n 2 V b plus S n 3 V c. So, this could be written as essentially S p vector minus S n vector transpose take the dot product times V a B c vector would give you output voltage vector. So, you could make use of your switching states vectors to actually obtain your input output relationship. So, here you get the output voltage in terms of your input voltages and then you get your input currents I a b c in terms of your DC current. So, this gives you your input output relationship of this particular power converter. So, we have looked at now the example problems in the next class will continue with where we had left off for the filter design. We had looked at LCL filter and looked at how to determine the values of L and C. We will start with looking at how to determine what would be the damping components required to damp out the oscillations in such a LCL filter in the next class. Thank you.


You go to different cities and give insightful speeches, and also have a happy hour with your patrons. But how do you decide which one will be the next city and country? David, this is a complex logistics operation that involves sifting through a whole bunch of invitations. I receive on average one or two invitations a day and sometimes up to three or four invitations per day to participate in a variety of events, from very large international conferences down to meetups or small localized events. I have to sift through these more than a thousand invitations a year to figure out which ones I want to go to. And fortunately, because of the support of Patreon, I have staff who help me with this process, who help me basically organize and categorize, vet and review the various invitations, and then make decisions about how we can take these and assemble them into a schedule that makes sense. Generally speaking, lately I've been trying to do more of a tour approach to this so that I'm not traveling continuously throughout the year and I can do all the things like write my new book and participate in video conferences and do interviews and things like that. So in that case, what I'm trying to do is create an itinerary for a tour, like the one we did recently in Europe, where I can visit many cities in a row and do a whole bunch of events in one go. I like to go to cities that I haven't been before, but I also have to and want to visit cities where there's a vibrant community and where I have visited several times before, but it's important to visit again. So I try to keep that balance between visiting new cities and revisiting cities where there's a vibrant community. I have to decide which events are the most appropriate. Some events are for mainstream audiences. Some events are more community oriented. And again, I want to keep that balance between working with the community and helping build community in various cities by creating educational opportunities and excitement around open blockchains and working with the various local groups, as well as doing mainstream conferences where I can speak to audiences that have never heard about this technology or have only heard the kind of very surface, very boring corporate propaganda and marketing or the very negative media coverage. So I can bring a new perspective to audiences like developer conferences and startup conferences that are not focused on open blockchains. And finally, it's also about my personal capacity to travel and, you know, my desire to see many different places around the world. All of these considerations go into it and then there's a very complicated logistics dance to figure out how to build these. The bottom line is, if you want me to come to an event in a city near you and I haven't been there, please send me an invitation. My website has a form specifically for that purpose, aantanop.com slash conference. You can find it there. And I look for very specific things when I'm being invited to a conference and I prioritize the ones that have a community involvement. So either are organized and delivered for the community or there's heavy involvement by the community in the conference ones that have an educational mission as their primary purpose. Ones that have topics and speakers that are promoting valid educational opportunities or not pay for play conferences. I don't do conferences where sponsors are given a speaking slot. Ones that have low cost tickets for students or just generally low cost tickets so that they are open to a broad audience that can afford to attend them as much as possible. And finally I look for ones that have diversity in the lineup of the speakers and in the way the community manages events in general where they encourage the participation of broad ranges of people from the local community and they have the appropriate code of conduct to make the conference a productive educational and safe environment for everyone. So all of these considerations go into it and then I pick a city and I come visit. Hopefully one of these days it will be your city David although you didn't say in your question which city that is.


So, welcome everyone. I'm Otilo Slovenček, working for General Electric and my co-presenter is Viktor Šlofr, working for Nokia. We've been working together on an OpenStack migration project a year ago, and that's something we are about to talk here. So, let's see the starting point. We had a REC space, managed OpenStack environment, roughly 2,000 m's, 500 terabytes of data, and it had a mixed storage environment, so a local disk for Nova, Swift, so object store for Glance and SF4 Cinder, and we didn't have an in-place upgrade option because it was an in-sourcing project, so we wanted to manage this OpenStack entirely. Hence, we started up a new OpenStack environment inside of the same case into the same data center. So, we had low latency and high bandwidth connection between the two environments, and Target environment was a Red Hat-based OpenStack based on Queens, so it was P13, and it was an all-SEF environment. So, of course, we gathered business requirements before starting up with that. What we had is what the requirement was is a full automation. The reason is very simple. The theme is small. The change windows are just very short, so there is no time for improvisation. Everything has to be running automated, and also, if something goes wrong or we are just hitting some edge case, we have to roll back, so that's another requirement. Also, we have to preserve the IPs as well, the Max on request, and also, the migration is going for like six months. We are migrating via VM, so if only the half of the application is migrated, those folks has to be able to communicate with each other, so layer-to-trunking is a requirement here as well. The right-sizing, so just like even shrinking the root disk is also important from the storage efficiency point of view, and then the whole migration procedure has to scale out, which means that because we might have some crazy scheduling on how many VMs are just migrated, this methodology should scale out like 100 VMs per day if required, so there shouldn't be any kind of infrastructure or process about the bottleneck here, which is stopping us to do as much as we can at a short time span. We shouldn't have physical access to the original, the source machines, the source hypervisors, because this is a vendor-managed product, so it is either a support exception or we have to open a ticket for doing something on the hypervisor, so that's something we cannot really automate, so we should be restricted to the API as much as we can. Obviously again, for the storage efficiency point of view, we have to utilize the SAF copy and write feature as much as we can, so the deduplication features, and because of this is an infrastructure-to-service support, we don't really have access to the operating system, so we cannot really install and we don't want to interfere with the users if possible to install something like a local agent on the machines, so that is also an important part. Scalar is also a very strong requirement, like 70% of the VMs are managed through Scalar. Scalar is a cloud management platform and this is a fair request that they should or they want to manage these environments even via Scalar, even after the migration, and the flexibility, of course, is very important, so whenever it comes in a new feature, a new edge case, then we have to react on that very fast, so the whole design should be like plugins and hooks, and also we should hold the software in hand, so just to react very fast. Of course, before just re-eventing the wheel, we started with some research, so we just examined what would happen if we were copying VMs via CopyStack, this is a well-known free tool to migrate workloads between OpenStack environments, and practically CopyStack is, would do something like stop the VM, create a snapshot into glance or into sweep, practically, and we have to download that snapshot into a staging area and do some crunching on that, because of like, first of all, we have to convert from Google to RAW, because the RAW image is a format that is supported by self-currently, but also we should do other things like resizing or injecting some scripts or something like that, and once we finish, we have to upload into Glance again, and when that's done, we can spawn the VM. The whole procedure for a moderate-sized root disk is taking over an hour, and of course, we have like eight or 10 times bigger VMs in terms of a root disk, so that probably takes like four or eight hours to migrate, that's probably too long. For us, the other thing is that the whole procedure is restricted by Glance, so the Glance and the Swift on the source side and also the Glance on the target side, so this is a bottleneck, we cannot do as much as we can at the same time, because we are restricted by the network bandwidth of that environment or the load balancer at least, and also every single VM is having his own image, so that's not really effective from the storage perspective, and that's really a big deal because compared to the scenario what we ended up with and what would happen if we were using copy stack, the difference is like 200 terabytes, which is like 600 terabytes, row capacity in self, so that's a lot. So the reasons reinventing the wheel is the lack of scalar integration, the scalar import, and this kind of far migration stuff is very state of art, so not available on and off the shelf tool. The root disk copy is usually using Glance, which is not good from the well-known reasons mentioned previously, and of course the data application is also a problem here. The self integration is also missing, so most of the tools are just trying to be universal, any cloud type of migration, which means that rather clone, copy the volume and do some crunching on that or migration by their own, but because of we have like self on the both sides, this is practically insane not to use the self-provided migration methodology. We also have to develop by an IP collision avoidance tool by our own, and of course the cost is very important factor here. So most of these migration support companies are just doing or providing professional support or just doing something like cloud migration as a service or disaster recovery as a service. And most of the cases, if you are not the most important customer for them, probably you're waiting weeks to have a fix or to have some new plugins implemented. So that's also important for us. So the tool set, what we invented here is like having a centerpiece of Python scripts that are just managing a migration for images and VMs and volumes. And practically, this is talking to the OpenSec API to change the VM states or provision new resources. Also, it has a REST proxy piece, which is just orchestrating the self migration or self mirroring. It has an independent part, the port sync demon, which is taking care of IPs and avoiding IP duplications. And we have a REST proxy for scaler, which is either creating the new constructs or the new containers for the new in the new scaler environment and also managing the state changes of the VMs as well. So that's and of course, we have a bunch of agents. I told previously that it was a requirement not to have an agent. The trick is that we have these agents in a REST queue image in a REST queue mode. So nothing has to be installed on the operating system. So that requirement is satisfied here. So how would you clone the VMs? What is the basic idea here? If you just take step four on the bottom of the slide, you can see that there is the final point is that we have like a source VM, which is created from a Glenn snapshot. And it has a single volume attached. And the requirement is to have a clone of that VM on the other environment, which is just based on the same image and has the same volumes or the clone of those volumes attached. So in order to achieve the goal, first we have to have the snapshot copied to the other side. We are starting with that just to trace back the parent or the grand, grand, grandparent of this image. So this is the base image in step one. And what we are doing here is that taking this base image, we are creating a temporary VM from this base image on the first side. And practically we are creating another VM on the target side from a zero image, zero image is practically a small tiny image full of zeros. Because at that point, the base image is nothing to compare. And we are just transferring everything other than zeros from base image to the other size. And when we just make a snapshot of that temporary VM, we have the clone of the base image. And once we have the base image clone, we can do the same procedure for the snapshot image. So create a temporary VM on the source side, compare the contents of the snapshot to the base image clone. And finally just do a snapshot of the temporary VM. So we have the snapshot clone. A few days before this whole environment, whole procedure or the target window of this migration, we are just initializing the RBD mirroring for the attached volumes. And so these steps are practically preparation. And when the migration window comes, the change window comes, and we are just doing the final migration of the root disk. And we are just managing in and and attaching the volume clones. And we are ready with this migration. Of course, if anything goes wrong, the original source VM and the original volumes are still on the source side. So the aerobic procedure is very simple, we are just discarding the target VM and we are just getting back or restarting the source VM. So what's under the hood, so how the root disk migration workflow is going on? Practically, what we can do is is doing some first of all, our creating or having a rescue image. So that's what I mentioned that we have an agent here installed. So once you just reboot the machine into this rescue image, then you have these agents started. So you can just control the streaming from the source to the target VM. And I mentioned that we are comparing the checksums practically or comparing the target, we target this content to the source we this content. We in order to avoid reading and writing the target, this is the same time. By the time we are just making a copy of the source image, we practically be creating a checksum file, which is like generating a section checksum for each 64 kilobyte chunk. And and by the time you you come to the point of migration, then you just download that checksum file into from an object store into the source VM. So all you have to do is just reading the checksum from the checksum file and calculating the checksum from the root disk. And based on the whether you have a difference or whether it is the same, you are just either transferring the data or you are just instructing the target VM to do a seek on the target disk. So you are practically not storing anything in the set layer for that target file. And the final step, of course, doing all these kind of plugins, like like fixing files, like fixing the MAC address fixing something that an ETC FSTM file or doing any kind of auto modifications on the target side and rebooting that machine. And we are happy. That's how the migration goes. Heading over to Victor. Yeah, so both environment use Salesforce in their volumes. So it was an obvious choice to use RBD mirroring to migrate them from the source open stack environment to the destination. RBD mirroring between self clusters of different providers required additional validation before we were comfortable to move forward with this. A self rest proxy tool was also developed to provide an interface to the self clusters so that the VM migration tool could orchestrate the RBD mirroring of our individual RBD images, like setting image features required for the mirroring and enabling disabling the mirroring and also promoting and demoting the images. The main takeaways of the self RBD mirroring were the following. The journal link has an impact on write performance. So it makes sense to enable it just before the migration enabling the journal feature may fail if the RBD image has heavy load. In such cases, posing or shutting down the VM may be the solution snapshot of the RBD image are also mirrored. So this is what this was quite useful for us as some of our customers had data retention policies that meant that the snapshots had to be migrated as well. Another consequence of this is that the dependencies between the volumes had to be resolved by flattening some volumes in order to prevent migration scheduling constraints. You can only enable mirroring between pools that have the same name that's important as well. So this had to be considered when the Cinder volume were volume types were created in the new environment. The last takeaway here is that the RBD mirroring can be a bottleneck as well. In our case, the observed RBD mirroring speed was around two terabytes per hour, and this was only with five RBD images mirroring running in parallel. Okay, the next one is the sports in demo. The two open stack environments were running in parallel for multiple months, and we had the requirement to keep the IP addresses of the migrated instances. So we had layer two tracking between the open stack environments to make this possible. As a result of this, we had to find a solution that allowed us to create new Newton ports on both ends without causing an IP MAC address collision. We use the different MAC prefix in the new environment, but we could keep the old MAC addresses as well on request. For the IP addresses, having non overlapping allocation pools is only a half solution, as ports with a fixed address can be created without respecting the allocation pool settings. Therefore, we have developed the ports in demo that created port clones on the remote end to prevent reusing the same IP address. These clone ports were then reused during the migration. The last takeaway is that the port ownership needs to be considered here so that the port can be managed by its owner later on. So this slide is about the scalar migration tool and REST proxy that we have developed. A majority of our customers were using open stack via a scalar cloud management platform, so the migration had to cover seamless transition within their scalar environments. Scalar is a hybrid cloud management platform that provides a cloud agnostic definition of the infrastructure with high level primitives like swarms, farm roles, roles. These scalar resources can be defined in different scopes and the visibility of these different configuration items are also important. Scalar had no support for such farm migration between scalar environments, so we have developed our own tool to take care of this. This was mainly based on the public APIs provided by Scalar. There are a couple of interesting things to mention here. Scalar has its own desired state engine, which means that Scalar tries to converge to its internal known state of the VMs and farms, so the VM lifecycle management had to be done through Scalar. Therefore, we have developed a scalar REST proxy as well to provide a simple API for the VM migration tool to execute lifecycle management actions on scalar instances. External integrations with LDAP servers and DNS had to be considered as well, and these were mainly done via webhook integrations that we had to trigger manually during the migration, as again this was a use case that Scalar wasn't really developed and this is something that we had to trigger ourselves. There was also one interesting tidbit that the private keys for the scalar farms are generated when a scalar farm is created, so you have no control of that. This was not good for us because we intended to keep the old private keys and unfortunately this had to be done via Scalar database hex, as there was no API for things like this. Okay, so this slide for me, so how would we use the tool set after the migration has finished, so the first obvious way to do that is to do the image copy between the regions. So we have a monthly obligation to create G customized images for OpenStack and we are just building that on one platform and we are copying it to the other regions and this is providing an effective copy between the environments. The other way or the other thing is a missing feature for OpenStack so that project migrations or project split and merge is not something that we have embedded into the base OpenStack software. So the migration is practically are the moving VMs between projects is just a simplified migration.  So we don't have to have port sync, we just have to share the network between the projects and we are moving the fixed IP between the ports and of course we are using volume transfer instead of self migration. So that's also simple. I have to mention that the snapshots are not transferred so this is something I could take away from that stuff and we are also considering to have something a region to region migration. Ceph is a source spot here so the VAM connection, the high latency connection is probably in the way of doing RBD mirroring so that's a problem and the L2 trunking is also complicated because if your default route is on the original environment you have to route back everything on this VAM connection back to the other regions so some sort of a proximity routing is needed but that's something probably challenging point as well. Okay, so the lessons learned. So first of all, the migrations can introduce a lot of inefficiencies and if you don't pay attention the promise of lowering the IT spending can quickly evaporate. We put in a lot of effort to use the storage efficiently and it allow us to save us around 200 terabytes of self storage which turns out to like 600 terabytes of raw storage. It's also important to make a quick study before you start developing our own tool. We realized early on that there is no off the shelf tool that meets our business requirements but the things that we have learned by checking these products help us to come up with our own solution. We also try to plan everything in advance still there has been a lot of gadgets and edge cases with this amount of workloads that we identified during the migration. So it was really useful that we had the migration tool chain under our own control and it allowed us to adapt our workload quickly to handle non-trivial use cases. For a longer term project it's also identified to have these long lead time items at the beginning. So coordinating development with third parties, networking changes, customers with less flexible schedules are all long lead time items that may impact the timeframe of your whole project. So it's very important to identify these things early on to make sure that you will be able to meet your deadlines. And finally, I would like to say thank you for team for their contribution on this project. So thank you guys for all the coding, testing and of course doing the migration here. And now it's time for questions.


How would you like to make better returns than 85% of hedge fund managers? What if I told you there was a way to do this while having zero investing knowledge, spending almost no time researching and also paying nothing in fees on your investments? Now, I know that probably sounds too good to be true and it also probably sounds like a bad infomercial. But all joking aside, index funds basically accomplish this and I would say for the average investor, index funds are probably the best place to put your money. And at the very least, index funds should make up a significant amount of every investor's portfolio. And in this video, I'm going to be explaining why that is. And I'm also going to be giving you my top five index funds to make you rich. And if you're familiar with index funds, you probably think that they're boring. But if you keep watching the video, I'm going to show you how they can be pretty exciting as well. And later on in the video, I'm also going to reveal to you which company I believe to be the best for investing in index funds for beginners. Now, by the way, I'm going to be mentioning index funds as well as ETFs, which are exchange traded funds. So gently tap that like button and let's jump right into it. There are small differences between index funds and ETFs. And depending on which company you use, one of them can be slightly better than the other one. But with that being said, generally speaking, it's a little bit easier to get started investing into ETFs rather than index funds. However, they both accomplish the same goal of diversifying your investments. So I'll be giving examples of index funds as well as ETFs that are very similar to them. Alright, so first one on the list, number five is going to be the Vanguard Total International Stock Index Fund Admiral shares. This is also referred to as VTIAX. And by the way, I'm going to be going from the least risky to the most risky types of index funds that does not mean that I think one is better than the other. And of course, I don't give financial advice, but the best one for you is going to depend on your own personal situation. So sit back, relax, look at all of these different ones and see which one is the best for you. So this particular one is the least risky on the list.  And large cap generally means a company that's worth more than $10 billion. So these are usually going to be established blue chip companies. That means that they likely are not going to have astronomical gains, but at the same time, they're also less risky. And some would say the fact that it's an international fund rather than just a U.S. fund means that it's even less risky as well. Now, historically speaking, companies from the U.S. have outperformed international companies. But if you think this is going to change in the near future, for instance, maybe you think international companies are undervalued, then this might be a good index fund for you. Or maybe you think something really bad is going to happen to the United States like the economy is going to collapse or maybe it splits in two or something along those lines. This might be a better option. Now this one does not include United States companies. There are others that include the United States as well as international stocks. So just keep that in mind. You would probably also want to include an index fund that covers the U.S. as well. Now, as you see here, it's only gone up about 27% in the last five years. So a little over 5% per year. That of course is a lot less than the United States stock market has gone up. But remember, just because we've seen certain trends in the past does not mean that is going to continue in the future. A very similar ETF would be VEU or the Vanguard FTSE All World X USA Index Fund ETF shares. Yeah, that's a pretty big mouthful. And again, this is another one that tracks international companies and excludes the United States. The next one is going to be VTI or the Vanguard Total Stock Market Index Fund ETF. Now this one covers all different sizes of companies within the United States. So small cap, medium cap, as well as large cap stocks. It also covers companies from all industries and sectors. And in the last five years, this one has gone up a very healthy 84%. In the last year, it's gone up 11.46%. And all time it's gone up about 277%. And that is since 2001. So really good gains there. That's well over 10% per year. Now the expense ratio here is very low about 0.03%. That means for every $10,000 invested, it's only going to cost you around $3 annually. So very nice, very well diversified fund. You get exposure to pretty much all industries, all sectors within the United States. You also get exposure to small, medium and large cap companies. Now the next one on the list, number three is actually what Warren Buffett recommends to him, it's going to be basically the perfect balance of risk and reward. And what Warren Buffett recommends is putting your money into the S&P 500 index fund, but I have one that's even better. And if you didn't know the S&P 500 index fund is an index that tracks the top 500 companies in the United States. So the index I'm recommending that I say is even better than the S&P 500 is FNILX. Now this one was created in 2018. So it actually doesn't have five years of history, but over the last one year, it's gone up about 14%. And that's very nice, especially considering that we're having a pretty big correction right now. Now the market's basically crashing, which means it might be a really good time for you to buy in. So it's only been around for about three and a half, four years, and we've seen it go up by 53% already. So that is fantastic. Now the expense ratio on this one, remember, it says the Fidelity zero large cap index fund. There's a reason that zero is there. The expense ratio on this is 0%. You don't pay anything. So that means if you invest $10,000, you pay $0 annually. Now, if you are a fan of Vanguard, a very similar ETF is going to be VU. And that is the Vanguard 500 index fund ETF. It is up 89%. The last five years, the last year, it's up 15%. And since its creation in 2010, so about 11, 12 years ago, it is up 291%, which is just amazing. So yeah, this is Warren Buffett's recommendation for where you should put your money basically into a, you know, S&P 500 index fund or something very similar to it. Now in terms of my personal recommendation for a beginner, if you want to invest in index funds, it's a little more difficult. I would recommend Fidelity though. I really love Fidelity. They're super easy to use. That's where I personally invest in index funds, but you can't go wrong with Vanguard either. They basically invented index funds, not technically not, but they were the first ones to bring it to market. And if you want to invest in ETFs, which is a little bit easier, what I recommend you do is use my Weebol link down in the description where you can very easily invest in ETFs. And you can also get two free stocks just for signing up and funding your account. Now we're moving on to the slightly riskier and also slightly more fun index funds. So these are going to be index funds that have a little bit higher upside, but at the same time, they are also more risky. So this particular one, IWY, the iShares Russell Top 200 growth index fund, as you can see over the last five years, it has increased by 158%. That is over 30% per year, right? So that one significantly beats the S&P 500. For instance, over the last year, it's gone up by about 12%. And since it was created in 2009, it's up over 522%. That is almost a 50% increase per year. Now this one is composed of large cap companies that are expected to grow faster than usual.  And as you can see over the last five, 10 years, growth stocks have done exceptionally well. Now one thing you should keep in mind about growth stocks is in a bear market when the market crashes, they usually crash more than just your average everyday type of stock. So keep that in mind if you are thinking of investing in something like this. But this just shows that index fund investing doesn't necessarily have to be boring. If you're really bullish on a certain industry or sector or a type of stock, you can put your money into an index fund that probably tracks that sector industry or stock. There are so many different index funds and ETFs that track all kinds of different markets. I mean, you can get extremely specific like number one on this list, which is the roundhill ball metaverse ETF. Now this one just came out last year in July of 2021. And basically what this does is it tracks all things that have to do with the metaverse. Now when it comes to investing in the metaverse, you can invest in different types of cryptocurrencies. But this gets really complicated because when it comes to cryptocurrency, first of all, it's really difficult to understand. You've got the blockchain and then you've got the crypto that sits on top of the blockchain. You've got tokens that sit on top of that. And then you've got the company that creates all of it. And then when you zoom out even further, you're going to have companies that create the hardware that is going to run the metaverse. And nobody really knows where the majority of the money is going to flow. Is it going to flow into the companies or is it going to flow into the cryptocurrencies? And then even when it comes to the companies, you don't know which one is going to end up winning. So this ETF basically invests in a bunch of different companies that are involved in creating the metaverse. So companies that are involved with computing, networking, virtual platforms, interchangeable standards, payments, content assets and identity services, hardware, they are trying to cover it all. So if you're somebody who is extremely bullish on the metaverse, you think that NFTs, the metaverse gaming cryptocurrencies are going to be huge, this might be an ETF you would consider investing in. So index funds and ETFs are some of my favorite investments to make. And I think they kind of get a bad rap because they're just a little bit boring to talk about. But I hope I showed you in this video that they don't have to be boring. Now, if you're wondering what investment app is best to use, especially with everything happened with GameStop and Robinhood last year, check out this video right here, because I think it's going to help you out a lot. And I will see you next time.


Come take my first steps with me after my most recent amputation surgery. So I headed up to Denver to extremity prosthetics to have my prosthetist create a brand new socket for me. This is a process that takes a few hours, but it's actually able to be completed start to finish in one day. Specifically through this company. So you went through the fitting, the measuring, creating the mold, grinding it down. There are so many steps and so much art involved in this. It's so cool to watch. And by far the coolest part is that at the end of this I have a socket I can hopefully use. I was very anxious to put this on because I am still having a lot of nerve pain. But it is important to start trying to walk again to kind of work through some of that pain. So we got the whole socket fabricated and this is me taking my very first steps. It was uncomfortable. I lost a lot of muscle so I'm very unstable. But overall it actually went really good. I'm very cautiously hopeful and will continue practicing on my leg, building that muscle back up. Hopefully pain will continue to decrease and oh my god I might actually be able to walk again.


monitor 2 alpha Bravo change rate change didn't recognize it won't flash okay so the winks I know that it took the change rate down change rate change rate stop and mark this are you probably marking us but I'm gonna mark some of the ones that I think I'm having trouble with if we agree go zoom in change rate right stop I think I would cycle a whole thing one more time monitor one monitor one monitor to monitor to voice command standby activate activate go go go left left right stop change rate change rate easy easy still cameras still cameras or too much too much change rate change rate tilt up zoom in tilt up stop focus far stop mode active select one time particularly the mode activity is on the standout it is off so that means you've activated right so we knew that and you already knew that so if we I'll talk to chef how we're going to manage that okay well like I told chef what's most important our most important feedback is your opinion sure that is our most important feedback so you come back happy whatever makes you happy okay this would be where you deactivated if you wanted to for as required that's better yeah yeah with the data is compared against ground data that we acquired during astronaut training hopefully we'll be able to see or the effects the space environment has on the speech process and voice recognition there are several successful applications of voice commanding systems in in the commercial sector for example in the area of aid to the handicap and handicap person can control by voice a motorized wheelchair medical reporting currently doctors are using voice recognition to to generate medical reports whereby they're looking at a x-ray for example and are examining it and are inputting words into the recognizer that it recognizes and it's generating report about the doctor's examination other applications is access control where they use a speaker verification system is the person that wants to get into this door truly the person it is and they use a specific voice print algorithm to try and determine if this person is indeed the person he says he is the system that we use is what they call speaker dependent system which means that the crew each crew person has to train the system before it can use it training consists of going through a vocabulary two times and saying each word each word is then digitized and stored in memory as a template or voice print similar to a person's thumbprint and then all those words are then saved according to each person as their templates okay when the astronaut wants to use the system he will come in he'll plug in his headset and plug in the display in the shorting plug and then all he has to do is turn on the power switch to you on and that's the only manual step necessary after when the system powers up then the system automatically prompts the astronaut to say his name when he says his name and recognizes who he is will go out and load his templates from memory into the recognizer then when he wants to control the system he'll say a command it takes that word and digitizes it and compares it with the words that were loaded into the recognizer if it finds a match it sends that in for it sends some information from the recognizer to our controlling hardware where we process information figure out what word it was and then send the appropriate signal out to the cctv system to control a camera or a movement or a monitor whatever the function happens to be the voice command system is the first experiment to be flown in space which uses voice is the control we think this is going to be useful to the astronauts for two reasons and the first reason is that by having a system which is voice controlled the astronauts hands and eyes are free to perform other tasks the second reason is that by using a voice controlled system it isn't necessary for you to be in the location where the system is in order to control it so you're free to move around and you can be remotely located no we can have as many people as want to can use our system we have it set up so that only five five people can actually have their voices put on to e-square prompts but we also have the ability to retrain templates real time so anybody who wants to use the system may not already have theirs templates made but they can come up to the system and make their templates anytime they want so we're not limited on the number of people who can use the system all right well we have 40 commands that are possible on the voice command system most of these commands are exact duplicates to what are on a cctv manual switch panel and these are selecting monitors cameras and working the camera motions like panning and tilting zooming focusing all of those we also have some bcs unique commands which are used to activate the system deactivate the system identify the user and we also have some special macro commands for example we have a command that will stow all of the cameras in the payload bay into the position that they have to be in for launch and entry simply by saying stow cameras so we also have some special features that the manual switch panel doesn't have well the way we chose the words to use is because they're the words that are actually on the switch panel so they're the ones they're familiar with when they think of moving a camera up they think of tilting it up so we we selected all of those words now they did tailor their vocabulary to their personal use words that they were the most comfortable with words that work the best for them so both of our astronauts have have a different vocabulary but they're also very similar and they're the words that make sense to them and that's how we came up with our vocabulary well there's not a lot known about the effects of microgravity on the voice we do know that in zero gravity that the position and the shape of the lungs and diaphragm are altered now if this causes a great enough distortion in the voice good recognition could be difficult to get so we're expecting that this may be a problem well what we're going to do is that if the astronauts do find that they have trouble getting recognition we have the ability to remake their templates real time so simply by clicking this mode switch twice the system is automatically put into the template making mode and our system will prompt them through the entire vocabulary list they'll say each word twice and they'll have a brand new set of templates that are real and representative of their voice at that time it feels so fabulous you know there's times when you really think it isn't going to fly it's just it's not going to go and now not only is it going to go but our astronauts love it they love it they're having fun with it everybody we've shown it to likes it people are coming up out of the corners with ideas of how to use it and it really makes you feel like you've accomplished a lot


Hello, everyone. Welcome to the session about highly available Cloud Foundry on Kube. I'm Vladivanov. I work as a technical lead for Cloud Foundry at SUSE. And I'm going to talk to you today about SUSE Cloud Application Platform, how we've containerized it, and how we're trying to make it highly available. So what is it? It's a platform as a service that's based on Cloud Foundry. Runs applications has a large number of components, just like Cloud Foundry does. And it's deployed on Kube using help. So probably everyone here knows a few of these components. CAP is made of the exact same stuff as Cloud Foundry. It's actually built from the same sources. So we have here the exact same pieces as Cloud Foundry. And this is a view that shows them grouped by their function. And every container in the system is actually represented by a green box. So again, same Cloud Foundry that you know and love, just containerized. And we can see that there are quite a few components. So containerizing them is only part of the story. That can happen automatically. And once you do that, it becomes easy. But actually running it and orchestrating it can be difficult. And making that happen in a highly available fashion can be even more difficult. So next, we hope you realize that some boxes have turned red. So it's useful to think about the critical pieces of the system that you want to be highly available more than anything else. So in this case, you can see that the elastic runtime is red and routing is red as well. So basically, these are the things that run your applications and also route traffic to them. And this is very important. You want the system to gracefully degrade, but the application and, of course, traffic flowing through them should still be online. So this is the most important part of Cloud Foundry, let's say. You want the applications to stay online. It's OK if you can deploy applications for a few minutes or for an hour while you deal with the problem that occurred, but you want applications to stay online. And being aware of these critical pieces is important because it drives us to make specific decisions on how we locate components. For example, we have special affinity and anti-affinity rules for the router and for the Diego cells that make them run better separately. So how are we containerizing Cloud Foundry? We all know that Cloud Foundry is usually deployed using Bosch. And Bosch is a tool chain that allows deployment of highly complicated systems on top of VMs. But we wanted to do containers on top of Kubernetes, so we had to develop this tool called FISAL to essentially convert Bosch releases into Docker images. And we're still using Bosch. So Bosch takes you from your source code to your end-to-day deployment in your environment. But a lot of Bosch is how you package your sources, so packages, jobs, stem cells, and so on. So we use all that release information, the spec for the packages, for the jobs, how you compile things. We use all that information to create the container images. And we actually build the stem cell just like you build a normal Bosch stem cell. So at some point during the Bosch stem cell VM creation process, there's a split happening. On the one side, you actually convert the OS image into a Bosch stem cell that's specific to the CPI that you're going to use, or Azure, AWS, and so on. And for us, on the other hand, we turn that OS image into a Docker image. And that's the basis for all of the containers that make up our cloud application platform. So essentially the same, we just skip the CPI parts that kind of turn each Bosch stem cell into a YAS-specific VM image. And since we actually use the same exact sources, so we use the CAPI release, Diego release, and so on, we actually believe that we can be a certified distro by the foundation. OK, so going back a bit to high availability, we want to think about the mechanisms that we need to make each component of Cloud Foundry highly available. And we kind of have two flavors that we work with. Things that can be load balanced, things like the Cloud Controller, or the routers, or the Diego cells. And then you have things that cluster. So for example, MariaDB, or LCD, or console, these are a bit more special. The actual replicas that you instantiate need to be aware of each other. So for example, replica number one of MySQL needs to have a specific address that you can reach it where you can reach it. And if it goes down and comes back up, it needs to come back up as MySQL one. So other replicas in the network need to be able to identify it. And it needs to be able to identify itself.  You don't need to specifically be able to identify a router. And you can also start them up all at the same time. So it's a bit easier to run these load balanced components rather than the clustered one. And next to these two flavors, we also have components that follow an active passive model. So for example, I think the Diego database does this. You can run multiple replicas of it, but only one will be active at the same time. So they will connect to console. They'll grab a lock from there. One of them will be elected as the master, and the other ones will be passive, meaning that whenever the master goes down, one of the passives will be promoted, and they'll become the active component. So we need to be able to support all these flavors, all of these configurations. And this is where Kubernetes comes in. And we have various Kube primitives that allow us to configure a deployment of Cloud Foundry. So we have the fissile tool that I talked about earlier that actually turns Bosch releases into container images. It also creates Kube configs and Helm charts. And Helm charts are basically templatized Kube configs that describe everything you need in order to stand Cloud Foundry up. So we have services, storage classes, deployments, stateful sets, probes of various kinds, pods. And I'm going to talk about a few of these in detail so you can understand how we use them and what they offer. So first, we have Kube services. And Kube services describe how we want to talk to a component. So for each of those components that you saw at the beginning, we have services that describe how you talk to them. And that includes the port, the protocol that you use to talk to them. And after you describe a service and you kind of turn it on for a pod, you also get an address for that service. For example, you get console.cf.svc.cluster. So that's a well-known address for that service, in our case console, and for that port, 8500. And this will actually also load balance. So you create a service for the console component. What you get is an address. You get load balancing for it. So we define multiple of these for each component and for each port and protocol that we need in the system.  And you can imagine that the load balancing is very useful for our HA requirements. So next, stateful sets. These are very important because they allow us to support clustered components like MariaDB. In a cube deployment, pod replicas have no real distinction. You can't tell one from the other. They get a random host name when they start up. And that's basically it. And you have no control over when they start. So if I want, say, 20 routers, they'll all start up. They'll be deployed across Kubernetes nodes. And they'll eventually come up in whatever order. And with a stateful set, you actually get an index. So all of those troopers there are different. They're the same, but they're different. You can identify them by an index. And cube will also make sure that each index is started in a particular order. So say you have, again, three Nets replicas. Nets number one will not come up until Nets number zero is up and ready. And we're going to talk about what it means to be alive and ready in a second. That's very important. So they don't all start up at once. Kubernetes will make sure that they start in an ordered fashion so that you can do database migrations in index zero. And then when index one comes up, it can talk to index zero. It knows that it's there. It can share information with it. It can talk to it. So it enables us to deploy clusterable things like MariaDB. Furthermore, with deployments, when you create a service for pods, you get that load balancing that's basically round robin across all the pods that you deployed. And you can't really target an individual pod by a well-known address. But stateful sets give you this capability. So here, if I have a stateful set for Nets, I actually have Nets dash one, so the index of the replica. And I can be sure that it'll always target Nets number one. So individual components of that clusterable component can talk to each other by a well-known address. Now we have probes. So there are two types of probes that we use. There's a liveness probe that basically detects when a container is running or not running. And based on this, we restart. So for example, if something bad has happened in the container, the liveness probe should be able to detect that. And then Qube will actually take action and restart the pod. And since we automatically generate these configurations, we use the, I think in almost all cases, we use Monnet to figure out if something is wrong inside the container. So Monnet has an API. Like I said, if you look inside a container, it's basically the same as a Bosch VM. So you'll find Monnet there. You'll find VAR, VCAP, directories, and so on. And we use Monnet to tell if the container is OK and alive or not. And then you have the readiness probes. And these are very cool. Basically, the readiness probe will tell Qube if that container is ready to accept traffic. So this is exactly what we want for the active passive model. So if one of the containers grabs the lock from console and becomes the master, it'll actually tell Kubernetes via the readiness probes that it's ready to accept traffic. All the other ones won't be able to do that, and they won't show up as ready. And that's OK.  But that's OK. That doesn't mean they're not healthy. They're just not ready to accept traffic. And if you kill the one that it actually is ready, you'll see that one of the other ones will grab the lock, become ready, and then Qube will start routing traffic to it. And of course, this is also important for clusterable services, clusterable components. You don't want them to accept traffic while data is still being migrated. So very useful capability there. OK, so now that we know the primitives that we used in Qube to be able to achieve high availability, I want to talk a bit about how we're exposing it with Helm. So Helm is where everything comes together. In the end, even though this is capable, we can do this. Even though this is possible, we also want to make it easy for the operator. So when someone is managing their CF deployment, it should be easy for them to scale their cluster up and down, move from a basic deployment to an HA1, and so on. So I'm not sure if you can read this, but you can see there the count for NATs, for example. For the operator, it's as easy as changing that value from one to three. And what will happen in the background is that the Helm templates will pick up the change in value and will actually change the replica count of the NATs stateful set.  And the operator is not aware of all this complexity. They just change from one to three.  Pods get restarted. Components that need to be aware that NATs has gone from non-HA to HA will be restarted. And essentially, the cluster will transition from a basic deployment to an HA1 seamlessly. And this is all possible using these Helm templates. So what have we achieved so far? We can horizontally scale the critical pieces to make sure that user apps stay online and they suffer no downtime. We can actually make all of the CAP components HA. So when you do an upgrade and you do rolling upgrades, all the components stay up and running. And the service doesn't degrade, essentially. We talked about the fact that it would be OK if it degraded and your application still stayed online. But we actually want to make sure that when you do an upgrade, there's no degradation in the service. And then we want to survive the chaos monkey. Little disclaimer here is not the actual Netflix chaos monkey. We just wrote a simple script that gets a random pod from the deployment and basically just kills it. So I'm going to show a video here because this has actually happened. This was recorded across three hours. This is a full deployment. Oh, you can't actually see this. So this is a full deployment of the Cloud Application Platform, runs on Kubernetes. It has an application deployed on it with four instances. And we have this chaos monkey script that kills something every three minutes. And we will see that we have some scripts that constantly monitor the API of Cloud Foundry and the application that's deployed there and counts how many times it succeeded and how many times it failed. And this was done over three hours and compressed it to a few minutes. So hopefully you can read this. So on the left here, you see the actual list of all the pods running in the system. You can see a few of the components that are active passive. So you have the Diego database there. One of them is the master. One of them is passive there, so it's not ready. And as we move forward, we're going to start seeing things being killed on the right here. And on the right, you see application requests that have happened, how many of them were OK and how many of them failed, same for the API. And I'm going to fast forward through this a bit. So the movie does accelerate, you'll see here. And essentially you'll see things popping in and out of existence as things get killed. So what we want to happen here is that we don't want to see application requests failing or API requests failing. And we just run this for about three hours. And you'll see that we killed essentially everything. There are no special pieces here.  And if you look at the pod list, you can actually see which ones are deployed as stateful sets. So they actually have an index, 0, 1, 2, versus the ones that are deployed as a cube deployment that just have random strings in their name. So in total, over these three hours, we had 54 killings of various components in the system. There was a 99.5% application availability and 99.8% for the API. This is actually the other way around. We actually want more app availability than API availability. Like I said, we don't really care if you lose the ability to deploy a new application across a few minutes, but you care if the application is down. So we still have some work to do, but I think we'll get there. Because so in conclusion, I'd like to say that cube is an awesome host for Cloud Foundry. It can make it run in a highly available fashion. It can do this seamlessly. It has all the primitives required to do this. And we've actually deployed the same exact bit, so our product is open source. You can see it at github.com. slash susus slash scf. We have a better release there that you can deploy by yourself. And the reason we think it's an awesome host is that we deployed the beta bits on Google Container Engine and on Azure Container Services with very few changes, just enabling some kernel parameters on the VMs that run there. So the exact same Helm release that we deployed on top of our own container management stuff on RAND-Fine on Google Container Engine and Azure Container Services. So Cloud Foundry loves cube, I think. So I'm going to open it up for questions. If anyone has any questions, I'd be happy to answer.  So the question is if we tested loss of an entire host. We haven't done that yet. We're getting to it. This was a small deployment. It was not across multiple AZs or anything like that. It was actually just sitting on one VMs. We just wanted to test the actual concept that all of the cube pieces work as expected so that the services are correctly routing, that stateful sets come back online without any loss of data and so on. How does the deployment compare to a Bosch deployment? Speed of the deployment. So depending on how fast your hardware is, after the images get downloaded from the registry, and you can think about this like a Bosch compiled release because the container images have all the compiled binaries inside them, about five minutes you'll get stuff running. So if you were to deploy on Azure, on medium VMs for the cube nodes, everything will stand up in about five minutes. So the question is about a parallel between how Kubernetes will act as a host versus compared to OpenStack and Bosch being a host for Cloud Foundry deployments and how the host system that you deploy on has various configuration settings like timeouts that can affect the health of the system. So a cube gives you a lot of control on how these types of things are set up for the deployment that you're doing. So timeouts for readiness probes, for liveness probes and so on. We haven't seen an issue moving from Azure to Google to our own cube deployment so far. We do have some specific requirements for the cube that's supposed to host us, things like enabling privilege mode, of course having an overlay network available, having some specific kernel parameters enabled. But overall, I think it should be easier because Kubernetes exposes timeouts and the network topology to us so that we can make the decisions instead of the actual infrastructure. So it should be okay, we think, or at least better. So the question is if we were able to do an upgrade, like a helm upgrade, while the system was running. So we're working on that right now. The one reason we can't do it with the beta release that's available there is how we treat secrets. Basically every time that we do an upgrade, all the secrets get rotated. So of course, most things will come up but then they don't because all the secrets got rotated so. The question is if you create a secret inside cube, is it available in Cloud Foundry? No, it's not. So you don't, from your application, you don't see the environment of the hosting container. Just like in a VM, if you have an environment variable in VM, the app is shielded from all of that, Kubernetes. So why did we choose Kubernetes? So first, I think you mentioned the CPI. We don't actually use a CPI for this. So this is not deployed using Bosch, it's deployed using Helm. There is a CPI I think available for cube from SAP but I think that's still in an early phase. Why did we choose cube? It's because it has all the features that we require and I think that the cube community has a tremendous momentum behind it and it seems to work great. So we looked at all its capabilities and specifically around these stateful sets and probes, we realized that we could deploy, we can deploy on par with what you can do with Bosch in VMs. Can you please repeat? So the question is what's running inside of the Diego cells? The same exact thing. So like I said, we built from the exact same sources, the Diego cell is one of those components that has to be privileged in order to be able to run containers in containers. We realized that that sometimes sounds scary that you're running containers in containers and it kind of sounds like VMs in VMs. That's not actually the case because you're sharing the kernel, you're not running a kernel inside another kernel. So it's just C group namespaces at the end of the day. So we haven't seen a performance degradation or anything like that. So it's garden with a run C backend and we actually use Groot FS. If you know that's a new project in upstream Cloud Foundry that allows you to use a butter FS or overlay instead of the old AOFS which helps us greatly when containerizing Cloud Foundry. We haven't done those tests yet. You're looking at application performance or infrastructure performance. Okay, yeah, we'll take a note and look at that. Yeah, so how do we keep our helm chart essentially on par with the Bosch manifest? So Fisal will take up Bosch releases. It uses the same exact descriptors as the packages and jobs specify. So those spec files consumes all of those, compiles everything, and then we wanted to expose configuration to the user in an opinionated way. So we don't expose everything that's available from the Bosch releases. We only expose things via environment variables. So technically if you wanted to, you could grab all of the Docker images, run them manually with specific environment variables and you'd get a Cloud Foundry out of it. So the helm templates only expose the environment variables that we choose as a distro of Cloud Foundry and the other ones are basically automatically generated. So you'll see, let's see if I can go back. You actually see something like this. This doesn't contain the actual environment variables that I was discussing, but imagine you have nv.domain there and domain would be the domain of the system or Cloud Admin password. And then we use those environment variables and feed them into the actual Bosch properties and we feel that this makes it much easier. You don't have to repeat yourself as much and you have one way to configure the entire system. One values file is essentially in helm. So we don't expose it one to one. Hopefully that answers the question. Thank you.