Good morning everybody. Welcome to Monday the 17th of May 2021 So what we're gonna do today is we're gonna have a look at the crypto space and a couple of these coins Cardano Stellar H bar doge link Ripple Ethereum and of course Bitcoin so what we've had over the weekend is Elon tweeting away like like he doesn't own Bitcoin essentially You know we have reports that test or rumors that tests that are potentially dropping their entire Bitcoin position So it's a bit of a disruption to the space for me. I think this is just a lot of noise You know I'm saying this to Anthony last week that you know a lot of these markets like are bigger than any one Individual and we see that in the future space all the time and That you know people make past big commentary on markets I'm really you know, yeah, there is that initial volatility both and headline risk that does initially affect that market But those markets then largely shrug off Those you know comments like this and I am I am saying that I think we're seeing gonna see this with Bitcoin You know from Elon's commentary So what we're gonna do is as a weekly look ahead We're just gonna look at some of these coins as they trade on the daily Maybe zoom into the 60 minutes and really see where they are technically so I have actually been tracking these for the past number of months and I am a holder of the coins that we're gonna be looking at and You know just for all due diligence purposes and Yeah, so let's just go across and have a look at these charts. So and you know from the top Really actually let's go from the bottom right and we have Bitcoin here And so, you know, this is by an aunt start up And so here's the range that I've been looking at for Bitcoin working really 46 069s on the low here up to a 67 Sorry, 62 750s on the high and you can see using that sort of framework of the market and Then, you know, I've got this lovely area. You can see where trade has been contained albeit blowing out here on the top It's sorry the 9th of April And just not being able to hold above that range and then work it back in and then you can see loosely at the top Of the range here It's just contained to go back down to the other side and just technically mapping this out for you So to show you what you're looking at and also I've used a couple of key levels like the 20,000 which for willow myself was this real demarcation line for the breakout Then the pullback and then the bid up to where we are now You know three times the value if not more But you know also using a fib extension tool from the swing low that we saw on the 25th of Jan this year to the swing high that we saw on the 20th of Feb this year and then the pullback Low to the 27th of Feb and that gives us these Fibonacci extension targets, which You know, they may not make so much sense to you looking at them now But you know, we will track them as we go on through time So I'm just going to cut them short and put them on the left here for now. So from a fundamental perspective You know, we were looking at on our twitch feed last week the sort of bear flag ish activity that we see just in this This sort of sideways apparently sideways consolidation But you know, we did fall out of bed on that bear flag really actually only falling out properly last Wednesday I did flag this up at the time and you know, then coming into the weekend We've seen Elon just bashing Bitcoin driving it back down at the bottom of this range here You know, I actually think there's good buy here on Bitcoin. I'd had this highlighted as a nice area I wanted to get involved at the 46 069 spot on the range And you can see there was a stand-up off of that level which would have been a nice the intraday long last week and we could certainly go over to the The 60 minute chart and have a look at that there. And so here is that sort of pullback on sorry That's not the pullback on that level This is the wrong This is stellar Let me get onto my Bitcoin 60 minute. Here you go. So essentially, yeah, well within that one hour bar You know, we pipped into this area a lot of risk and you know potentially blowing out traders on that long But then getting back up into this range and then, you know, just working its way back again You know a pack session this morning drop it can't hold in the range dropping back This actually to me now looks like a decent short for the intraday traders You're shorting the 46 069 is your sort of risk off level and then trade this on down to get a lot cheaper Than than it is right now. So for me, I actually think for now, there is more downside on Bitcoin Until we until we essentially Probably have reversal of commentary from Elon or he comes out and says he's just joking or something like that And you know, but until then I don't like to look at Bitcoin We will talk about Bitcoin when we talk about our Hedera hashgraph We're also known as H bar to the Bitcoin denominator asset there but the other big boy in town is a As we all know, Ethereum also the only other future CME traded crypto product And I was looking at the bear flag that we had here a couple really back way back on The 12th. So, you know, sorry last last Wednesday We have been tracking this bear flag, right and then lo and behold We blew out in the top put in a new all-time high here Up back 4b 385 euro or sorry USD to the to the Ethereum And before then receding back into the bear flag, right? And that's when I had this sort of area that I wanted to be sure And after actually looking to buy a pullback, then I just thought wow I might want to short this thing And sure enough, we came down to retest this fib extension level here at 32 57s Now this fib extension level again like any Fibonacci extension We've got the low 22nd of Beb 2021 Then we have the high 13th of March And then the pullback 24th of March and that gives us our projection areas moving up here Nice target on this blow top pie that we had. So, you know, the market firmly stuck in this sort of a range Really, let me just kind of put on, you know something a little bit like this You know The buying I think on the 32 57s here I'm not so sure if this is going to hold up. I think we could get a little bit deeper on the pullback And this was the main really decent break out area 25 51 spot 90 On ethereum for me and I think, you know, if I really wanted to pile into this Which I do I'd definitely be waiting for the 25 51s You could be starting to add in a little bit here in the 32 57s, albeit, you know, I'd rather wait until we get this sort of elan You know air out of the market Looking at sorry, I just fixed that up there Looking at let's see doge Doge, I mean what a coin It's just just talking about this with someone we have broken out of this well-defined range that we had in doge You know putting in I think there's this 400 percent up move here Over like I think we did 400 percent in one session There a couple of weeks ago But for me, we are sort of building into what is like a like a flag sideways consolidation structure I always monitored these things and they break out the way the way they came in So this this flag was formed on the bedside and I think it will exit on the bedside and when you and it's not uncommon To see fake outs on the breakout So you get a fake out on the breakout and then that gets entirely reversed quite aggressively So this is kind of the shape of the market I see on bit on doge I think it's very well supported on the 38 euro cent to the doge Um, which is the top of this range So, you know nice nice area to buy here and get on with further upside prices And even if it fails and comes back down I think, you know, you should be buying down here at the 18 or 19 euro cent And 100 percent buying, you know at the 11 euro cents to doge That's just the shape of the market on the daily bars that I can see here Uh link not going to spend too much time on link. This is as clear and clean as it gets Almost well. No, that's what probably isn't as clean as one or two the others I'm going to show you but what we've seen is the range well defined And finally firming up here late April Excuse me and then moving up into what was a bear flag We get the breakdown but then well supported on the top of the range I think we have seen the low for probably at this quarter on link But, you know, I don't like putting out massive calls like that willy-nilly You know, I'd like to I'd like I'd like to think this will remain supported I don't really want to see these markets coming back into the ranges that they've largely spent You know all of this year forming as a nice sort of jump point base area to go on for higher Um ripple, you know ripples a bit of a ripple has had The weight of an sec investigation for the past six months on at the back maybe even longer But now the sort of commentary coming out of that sec conversation and That investigation is actually now swaying towards ripples favor Um, they're not viewing a lot of the activity that went on as being nefarious And so I think this is why I am interested in owning ripple for much further up the upside now Um, I think, you know, we have the the flag Penance this should exit the way it came in I think the consolidation here is is good. It's healthy. I mean, obviously, you know, you wouldn't want to see this and be a buyer Um, but I do like the lungs from say the spot 80 Cent euro sent to the ripple coin. Um, so Yeah, I mean I think further upside on this who knows right now where it's going, but you know, fib extension tools are telling me Um, essentially that you do have Uh, you know good consolidation up here at the one spot five six seven six Um, you know the next leg up. I don't really have Too much of a target apart from the two spot three five one one euro sent and that's a four hundred and twenty three percent extension Fibonacci now just to give you a little flavor of Um, what the percentile gain from where we are now, for example is to there Uh, you're looking at about 86 percent increase in baseline price From here to there. I'll I'll take I'll take that trade at any day. Absolutely So I do like ripple.  Um Yeah, that's that's as simple as that really unrippled. So I actually overall I am very bullish on a lot of these coins H bar a fantastic Uh, really fantastic coin. Um This is really part of more so the data blockchain space rather than DeFi or anything like that. So Hedera hashgraph is kind of used to confirm database transactions and handy, you know crisscrossing data across a lot a lot of systems and um and ripple is Or sorry h bar is is a network used to facilitate that. I've actually worked in this space. Um for a number of years and You know, I'm quite familiar with what's going on with h bar for me The fundamental aspect is that I don't know if many of the very large tier partners that h bar have on their council the the hedera hashgraph council are going to be happy with You know 100 percent 200 percent markup on um the cost of of transferring their data But we are talking very very very small beans. Um per per per confirmation under up transaction Um or any of the dApps digital apps that are built on this network So I think there is quite a lot of upside left for this to run And I'm trading h bar to the bitcoin. So Any time we get a softness in bitcoin, we're obviously going to see appreciation of the underlying price on on h bar btc So definitely I'm staying in here for a continued breakout. Yeah, you could definitely get another pullback here on 549s 549s So You know, I'd be a buyer there again. Um, I don't think this is a a fake out on the upside I'm for believing the upside on this on this coin. Um, so what else can we see ripple? Sorry, not ripple stellar stellar is actually one of my uh overweight coins and I have no problem sharing that and so Again with the range that we've we've formed throughout this year and just fantastic buying, you know participation every time we we break out above and pull back to the top of this range I mean, it's just evidence to see here on the daily bars Uh, I'm still looking at buying more on the 47 914 Uh, stellar is to the euro. Um, the shape of these markets will be exactly the same Um on your usts or your euros to be honest, maybe a little bit different Um, but you know, I wouldn't be too concerned about that I think the the overall shape and momentum of these markets is explained by each of their individual charts, whether it's Stellar gbp stellar a ud stellar ust or euro Um, albeit stellar euro or sorry stellar or any of these coins paired with the u.s Dollar are obviously going to benefit quite a lot given that we have this weaker dollar environment, right? I mean if we look at If we look at this weaker dollar environments here Um, Dixie, which is what you know one of the markets that we cover in the in the main pro Room is that you know, this Dixie trade is you know, the Dixie to me is set for trading down to 89 spot twos Um, certainly down to the 89 spot 9 9s Um, I'm breaching below and you know, this is a well telegraph trade to the market to be honest So why is this important? Well, if you're trading crypto and you have us d denominated coins and positions Well, well then, you know, you're set for a pretty decent Enduring upside as that Dixie value slides off as we have these inflation readings coming in And devaluing that currency. So, um, you know, and then finally, uh, a da cardano cardano Richards one of the pro traders in the crypto room Richards favorite coin I say tongue-in-cheek. Um, but really this is being fantastic on the breakout of the range And then a pullback here seen When we get this pullback, this was strictly speaking. This was actually on the 10th of May And you know that pullback being well supported on the bid going moving up here to the two euro marker To the ADA. I think I think, you know, yeah, we're having a pretty deep pullback today I'm not scared. I think we're going to be seeing much higher prices here as we go on through the rest of this summer And indeed just the rest of this month. I think we're going to see some pretty well supported buy back sorry well supported Sell-offs here like like the one we're seeing this morning. Well, I wouldn't qualify this as a sell-off It's just a pullback really it'd be a sell-off if like if a crash down Below the range high which is here at one spot two three Range high, so that's really a little look ahead for the week The trades, you know, I think I'd be trading off a lot of these range highs and lows For the week looking for the edge there You know, I think it's it's best for me to be monitoring these things on the on the on the daily bars And kind of keep us out of you know, any of those Itty-bitty marginal trades that can get us all into a lot of trouble and get you really turned around On managing your your your book and your investment book in these products And so yeah, if anyone wants to reach out to me you can get me in the discord room live every day Um, I'm live on video on chat with the guys and girls You can email me t.doganaamplifiedtrading.com Or reach out to me on twitter. It's at timdug at timdog So listen guys and girls have a fantastic trading week. Um, don't listen to elan and Yeah, I hope I hope it goes well for you. We'll see you towards the end of the week. Cheers


On Wednesday, January 31st, the East Kentucky Dream Center participated in the annual K-Count. This yearly census for the homeless population is used to better assess their needs while shelters use the information gathered to acquire federal funding. East Kentucky Dream Center Executive Director Rachel Dotson gives us more details. The Dream Center works with our partners, West Care Homeless Shelter, Mountain Comprehensive Care Center, some of the rehabs, just different locations to get actual numbers on that K-Count. The K-Count is from the Kentucky Housing Coalition. Basically, that determines the HUD grant dollars that come into this area. The K-Count determines if we have X amount of homeless people, we're going to get funding based upon that number. You know, a lot of people in eastern Kentucky think downtown Piperville and surrounding county doesn't have homeless. We do. Homeless people don't just, it's not just locals.  So whatever their reason is, we're here to help them. We want to get a number on them so we can help get them the services that they need. The Dream Center is dedicated to helping the less fortunate by providing food and clothing during the K-Count. This year, homeless individuals could visit the Dream Center instead of waiting to be counted. So we just celebrated our fifth anniversary here at the Dream Center. One of the things that we have been able to do is we get out and we build relationships with the homeless. We help get them jobs, we help get them into housing, we help get them into rehab, we help get them the medical care, the food, the clothing, the necessities that they need. So we did things a little different. Instead of going out to the locations that they are, today was one of our free lunch days so we did our K-Count within. When they came to pick up their lunch and their free meal, you know, we asked the questions that are important to fill out the surveys. One of the, I guess, misconceptions is that you want to run out and you want to help somebody that lives under a bridge or in a tent, but they don't always like their life in the spotlight. They don't always want to feel like they're, you know, they're put out there, they're put on the spot. So that's one of the good things the Dream Center does. We've built relationships but we allow them to come to us for their needs. Reporting for Mountaintop News, I'm Nick Colum.


Good morning everyone. I am Anubha from Delhi and this paper was written for IPCCAR6 cross chapter mountains and it was written under a training for which six candidates from developing world were selected so Dr. Verozka who is here was one of the mentors and I got the opportunity to get trained from them and write this systematic review as a part of this training. So why are mountains important? They cover 25% of the land mass and 15% of the population live there because of their complex terrain and erratic climatic patterns. We have limited understanding of the processes which take in mountainous regions and because of all this adaptive capacities of the people living there are limited and because of this reason making adaptive strategies for these regions is difficult. So it's a challenge that you know because of the limited understanding of the region, their remoteness and we have to figure out which adaptations will work well and under what conditions. So here we carried out a systematic review where I included ultimately 84 papers and I saw that most of the papers were written by authors from Europe, Asia and US and the studies were mainly focused on Asia and South America and Europe and it was seen that all the regions of the world they are facing similar water related issues like there is unpredictability of precipitation, there are floods, there are hazards and cryospheric changes like there is glacier area change, there is increase in glacier lakes and there are changes in these snowfall patterns and the various activities the sectors are getting affected like the domestic users, agriculture, tourism and it was seen that because of all this the government and local communities both are involved in trying to implement adaptations to cope up with these problems and the main limitation for every region was their social conditions that how well they are ready to accept any adaptation and we saw that adaptations are being implemented in various sectors like infrastructure, energy, water storage, tourism and these strategies were related to like rationing, economic diversification, mobility and we saw that adaptations had various kind of effects on the regions they were not only positive, they were also negative and they were changing the social structure, the social conditions of the region and there were ecological impacts, positive, negative both for example in Europe to maintain the skiing grounds artificial snow is being spread so when you are making artificial snow it is putting pressure on the water resources so we saw that the adaptations they are structural and non-structural in their nature and like artificial snow making, improving water infrastructure covering snow with insulated material then agriculture modifications data collection they were structural adaptations and capacity building water pricing laws they were non-structural adaptation and it was seen that obviously Asia is very big so 15 popular adaptations were observed in Asia 13 in South America so I saw that in Asia artificial glaciers emerged as one of the most popular adaptation in South America the glacier protection laws was one of the most important one in Africa it was more about agriculture like crop diversification, economic diversification in Europe it was more about maintaining tourism and in North America they want to invest more in the funding in mountain adaptation programs and in Australia and New Zealand they were more about economic diversification motivating non-snow tourism so here we see that in all these regions we have different adaptations and they can be categorized into three major groups like policy and management infrastructure and capacity building and the main sources of uncertainty involved when you are formulating adaptation strategies like the climate data which is used to do impact modeling or projection then there are uncertainties that okay what is the snow variability what are really the impacts of the floods and because of the erratic behavior of the climate it is difficult to use the local knowledge of the inhabitants and it is difficult to take any strong decision so and obviously there is also scientific uncertainty which is associated with climate change so the main conclusions were that okay mountains are definitely facing water stress and number of adaptations are being implemented all around the world and in the developing world it's more about survival like they are trying to implement adaptations in agriculture sector and there is economic diversification in Europe and Australia it's more about maintaining the tourism sector again it is sort of maintaining the livelihoods and Africa it is more about the agriculture and the main limits to adaptation is that how well the people are ready to accept it there is misuse of the funds sometimes there is lack of interest in the government and there are lack of resources and there is lack of investment in the mountain programs and ultimately the main popular adaptations which were observed were related to water storage infrastructure, better agriculture and irrigation practices, economic diversification and improved water governance and laws thank you thank you


Yeah, because I got to turn on the mic. Is he ready? All right. Welcome, everybody. So glad you could come join us here. Tired of this talk is CERN and Science Clouds in Europe with Tosca OpenStack Heat and Heat Translator. And this is some work that's involved different companies, organizations, and different standards bodies, and, of course, open source technologies like OpenStack. I'm going to just really quick introduce my co-presenters here. It's Ricardo Orocha from CERN. There's Matt Rokowski. I think he's hiding. He's an IBMer. Anybody know Sadev from the Heat community? Sadev Zala from IBM as well? Not a single one. That's great. So we actually got together at the last summit. And there were some interesting things going on, a big project in the CERN and Indigo, having a European infrastructure that was going to go across clouds. Some of them OpenStack, some of them not OpenStack. So now you're looking at heterogeneous cloud infrastructures and what can be done to exploit those. And so in having discussions, and I won't forget the discussions because it was at OpenStack in Tokyo. And I remember we were late to get into lunch. And we had to get these box lunches that I really did not enjoy. It was all veggie. I don't know if anybody else remember those? You took one bite. I'll just go hungry. But anyway, we had really great conversation. And looking at TOSCA, something that Matt Rokowski's been working on for years, as sort of the specification language for orchestrating cloud infrastructure and applications that can work across infrastructures, works with OpenStack, works with non-OpenStack infrastructures. So looking at working together to be able to use that across those heterogeneous cloud infrastructures, and then how do you map and make that work? Well, turns out we had to pull the rabbit out of the hat. We've been working for years on a couple of sub-projects that have made their way into OpenStack Heat, Heat Translator, and TOSCA parser that one's looking at doing the parsing and one's doing the translating to map the world to hot templates. And these were embraced for a couple of years with this dream of we're going to do this so that we can funnel more stuff to OpenStack. So if we can find a way to translate stuff to hot, guess what?  So if you look at what we're going to talk about in this presentation, Saadev's going to come in and talk about the work that we've done in those sub-projects of OpenStack Heat, the TOSCA parser, and the Heat Translator. Then Ricardo is going to talk about how they use this in the big with Project Indigo and the work that CERN's been doing to work across these different heterogeneous cloud infrastructures. And then he's going to show some demos off YouTube, so anybody can go see them. He's going to show some demos. And then Matt here is going to talk about the latest things going on with the TOSCA specification, which is sort of pulling this all together. So at this point, I'm going to hand over to Saadev. Thanks, Brad. Hello, everyone. My name is Saadev Zala. I'm a software engineer at IBM in Raleigh, North Carolina. I'm a technical lead for TOSCA parser and Heat Translator. Both are sub-projects of Heat. So I'll brief about what they are. Some of the enhancements, the significant enhancement we've made in the Mitaka, and we have an excellent momentum going on working with different projects in OpenStack. So I'll just brief about that as well. So as you may know, there are two different TOSCA profiles. This is TOSCA Simple Profile in AML, and there is the NFV profile. The Simple Profile is focused on more general specification, topology orchestration, whereas NFV profile extends the Simple Profile for NFV specific needs. Parser basically supports parsing both of those profiles. It basically reads different TOSCA entities, TOSCA node types, capabilities, interfaces, policies, group, any custom types. And it basically produced in-memory graph of different nodes and relationship among them. Thanks to the development team, we had two point releases during Mitaka cycle, 0.3 and 4. And we had the significant enhancements. The most notable one was support for NFV. TOSCA seems getting increasingly popular in NFV community. And in last summit in Tokyo, we had a meeting with the attacker project team. The attacker is an OpenStack mainstream project now about extending the support of TOSCA parser to NFV profile. Originally, the parser was only for the Simple Profile. As part of that meeting, we had a collaborative efforts between attacker developers and ourselves. And now we support the NFV. Just real quick, tomorrow we are giving a Brownbeck tech talk just on NFV. So if you're interested to know more about NFV architect, how attacker is using these projects, parser and transmitter, please join us. It's 2.15 PM tomorrow in Brownbeck room. Besides NFV, we continue developing against the TOSCA Simple Profile specs. We added new features to parse things like TOSCA groups, which is a notion in TOSCA to group different nodes so that common operations can be applied on them, as well as something like policies can be applied on a group. We also added parsing support for TOSCA namespace, nested properties, and working with the project Indigo members, like Sun and other folks. They are bringing a lot of goodies cases. They use a lot of custom types. So as part of that, we did found a certain announcement and we took them as bug fixes to strengthen our relationship between custom types and normative types. We also, with 0.3, we're doing a full validation of TOSCA templates. So now we give you a compile errors when you're validating the template, support for nested imports. And TOSCA parser is basically used as a library, but we still created a shell utility program just for folks to play with it. Parser was a new project created a couple months before Mitaka Summit. So during this cycle, we did create the utility and we have a few other things available on master, like support for load balancer, range dive, et cetera. Moving to heat translator. So the translator project was created a couple years back. The goal was to enable deployment of non-heat workloads by means of translation to HOT. As you can see on the right side, there's a snippet showing TOSCA Hello World template and how it's translated to HOT. Again, thanks to the team. We had two releases, 0.4 and 0.3, during the Mitaka cycle. We typically have those releases in parallel to the TOSCA parser. Though heat translator uses TOSCA parser pipelines, so there are usually three weeks gap in between them to enable translation for the features added in the parser. But the new features, similar to what I was saying in parsing side, we added translation for NFV, for policies. We completed work on the OpenSec client side with the new test suites. I just want to mention that we do run into challenges when we translate. There is no one-to-one mapping for everything. Things like TOSCA has a constraint base of flavor and images, whereas heat takes flavor and image, the name itself, or, for example, the key name, property of NOAA. It's commonly used in templates in HOT, whereas there is no such concept in TOSCA. So now we basically let user provide those key names as an argument to the translator, and we basically set that accordingly into the HOT. Also, during the 0.3, we are now dynamically creating against NOAA to get the flavor. I'm going to actually talk on that in the next slide with some example there. But we keep adding new command line options to make a translator more user-friendly. We added a few during the MetaCycle, a smaller one, but things like only validating the template. If someone don't want to translate it, but only validate, they can do it. They can save the translator output to a preferred location. On master, that's something we really wanted to do it, is making deployment automatically from translator. So for folks who are translating TOSCA to HOT, now with the deploy option, you can actually deploy it as well. So we basically underneath, we just invokes the stack create, and let it take it from there and deploy the template. Other things like support for NCVOL and Puppet, the folks at CERN on the Project Indigo, they use NCVOL heavily. So thanks to them, they added the support to basically set the group for the NCVOL and Puppet. And we already tested. We have some tests making sure it's all working well. So real quick here, we have an excellent momentum going on. We are working with different OpenSec projects. Either we are using them for our need, or we are working with them to increase the TOSCA adoption. And we're working with our stakeholders. So for example, on the left, Noah and Glance, that's the snippet I was talking about, the constraint-based host in OS, a flavor and image. So if a translator is invoked within OpenSec environment, then we basically query against Noah for a best match of available flavor for the constraint. And again, similarly, we query against Glance to find an image that best matched the constraint. If translators use outside OpenSec environment, which is pretty common, then we have a predefined list of flavor and image, which are commonly used. And we basically find a best match from there and set it in the template. It's a user's responsibility to make sure those flavor images are available into the environment when they deploy. On the adoption side, we now have a Murano TOSCA plugin available. We have an OpenSec client plugin out there. And just a few weeks back, we completed our integration with Community App Catalog. So all the TOSCA templates can be browsed from apps.openstack.org. On TOSCA adoption side, we have two important stakeholders, TACOR and Open Platform NFV or OP NFV. They're both using TOSCA parser and heat translator. And their developers also contributing to both the projects. And we are heat, our destination is heat, so we translate to hot and we deploy with heat. So that's pretty much for me for now. Thanks, and I'll give it to Ricardo. So hi, everyone. So my name is Ricardo. I work at CERN in the OpenStack team. A bit of a background on what CERN is. Some of you might have heard in other talks in other OpenStack summits. So CERN is built by 21 member states, and many other states are involved also in the collaboration. The main machine we have right now is the Large Hadron Collider, which is a particle accelerator 27 kilometers long. And it's 100 meters underground. And that's the tool we use to accelerate protons and generate collisions. So these collisions happen in specialized detectors around 600 million times a second. So it generates a lot of data that has to be analyzed. So archive for the analysis later. So we're generating around 30 petabytes of data. There might be more data coming that is generated from this base data. So the CERN Cloud right now, we're using OpenStack, and we have around 6,000 hypervisors, 150,000 cores available, some 2,000 active users of the Cloud. And at any moment, we'll have around 16,000 VMs running. And we have a ratio of like 200 creations and deletions per hour. So it's kind of a pretty big cloud. Then one of the things that we do at CERN also, because we have all this data, we collaborate with a lot of institutions around the world. So traditionally, we've done this. There are multiple projects we've tried in the past. So grid computing is one that is very successful in distributing all this data and getting analyzed. But for many institutions, now we are looking at other solutions. So the European Union funded in the European Union Horizon 2020 program defended this project called Indigo Data Cloud. And its main goal is to have software infrastructure that can be used easily for science for multiple communities, not only CERN, but many, many other communities. CERN is more high-energy physics, but also biomedical communities, Earth observation, many other subjects in science. So there are many partners. I named here some. So NFN in Italy, CERN in Geneva, and then UPV in Valencia, Daisy in Hamburg in Germany. So many different institutions, both from research and university, more related, and also from the industry that joined as partners. So one of the main aspects of this is that many of them are using OpenStack, but a few are also using Openabula. So we had this to take into account when designing the system. So the main strengths of this project are to provide support for different scientific communities to build an available solution. So we don't want to develop anything new. There's plenty of solutions there that we can build on. It has to be quick, so people don't have to have a very long installation guide to follow. They just want to do their analysis and then support this distributed and hybrid environment with both private and public clouds to output some credits of people that helped a lot with the work that we are explaining here. So why Tosca? This is a bit explaining our experience with Tosca. Why we considered it and to see how we started using it and what point we are now. So the first step was to consider what options are there. Inside CERN, we are an OpenStack deployment, and many other partners have the same setup. So HEAT was an obvious choice, but it's specific to OpenStack. And CloudFormation had the same limitations. So we started looking around, and with discussions with IBM and other people, we took Tosca as a viable common denominator, both for the topology of the system, so to decide what goes into each site and to just orchestrate the whole thing, but also for people to start defining end users' applications in the same way, which was always a problem in the past. There was an existing code base. So the Tosca parser and HEAT translator were there, and we could just start trying it. And one big point is that they are libraries that we can reuse in other contexts. So we can, for example, the HEAT translator and the Tosca parser. Tosca parser is being used by one of our partners in another system. The HEAT translator, we can also use it for translating the same mechanism that we used to translate from Tosca to HOT. We could use it to translate to other formats. And there's growing support in different communities. So we started with very simple use cases. The first one was to deploy a single VM with a certain image and see if it worked. Then we started getting to our specific use cases. So one of them is batch processing. So we have a lot of data. We distribute the data, and then we launch jobs that analyze the data and give back results. We do this in a batch mode. Also in an Alice mode for the physicists. But we do this in a batch mode for the reconstruction of the data. There are many systems in use that the HEAT and other communities in science are used to. So Tor, Slum, and Condor are some solutions. Then, of course, now a lot of people want to use newer systems like Mezos or other container based tools. And then one use case that came was from the biomedical community, which they have their own portal where they just orchestrate what is a batch clustering behind. But they have a portal where the scientists will go to submit their analysis and say, I want to analyze this data with this algorithm and send my results, please, to this place. And then Indigo specific for the infrastructure jobs. So this is more like how to package things and how to get the infrastructure to just keep running without so much attention. So these are all the use cases we consider from the start. So from here, I go to some examples. I hope you can read it. But the goal is just to explain a bit how it looks. So if you're used to hot and the heat, it's not that different. It looks very similar. It's YAML. But then the constructs are a bit specific. So one thing, in this example, so we have here a simple node that we call Indigo compute. And then we say we need polygyp available. And we want these properties for this node. One thing that you will see is that this is not a basic construct existing in Tosca. So we have these custom types here imported. And that's where we define the needs we have. So what is an Indigo compute node? If we look here, Tosca has the ability to define derived types. So you can say, an Indigo node, an Indigo compute node, is actually an Indigo monitor compute. And this allows us to define common things in the same place. This is very similar to what you would do with heat. So in this case, we are saying, in addition to deploying an OVA server, in OpenStack, it would be, also configure a Zavis server. This is the endpoint. And these are the extra metadata I want. And then for the installation part, as said I've mentioned, in Indigo, we use Ansible templates for defining the installation and the several steps in the installation. So in this case, we are saying, on creation, run this specific template playbook. And then on this configuration and the start, launch of the service, use these different ones. And you can reuse properties that were defined in previous templates in Tosca. So then we translate it. And how does it look in the hot? So the same, the exact template I showed you, would translate to something that if you use to heat, it's very common. So it translates to an OVA server. And then it says, the flavor that the person specified is small. And then they wanted this image. We need software config defines for the installation. And then what is a step in the installation procedure of Tosca? Just maps to software config in heat. So it's very direct. You won't see anything very surprising there. Then the Ansible integration was an important one. Internally, at CERN, we use mostly puppet. But in Indigo, the decision was to use Ansible for most of the software installation. So in this case, what does it look like? Just to give you some details, in the installation is just saying which package should run. These are very small examples. There would be more complex ones. And then for the configuration, it's just using some of the predefined variables to fill up the template in the configuration file. So then one thing that we started also is that, of course, if you'd start defining a lot of these bits and pieces, one good thing is to use Ansible roles. So we use the galaxy portal for Ansible. And we just pick up. So instead of having to define all the steps in each template, you just point to an existing role here, and then it just builds on it. Makes things a bit easier. So one good thing that came from this is that through the work we did with IBM, we added the support to have multiple deployment and config options. So when you define in the heat translator anything that looks like YAML, we assume it's Ansible, PPS puppet, because we are also interested in that, and anything else is script. So you can hook in Python, Bash scripts, whatever you need to configure your system. And that works for us. And then if you need something else, you can have a look. It's not hard to integrate this. Then we started looking at more complex examples. The batch cluster, I will take the biomedical case here. So the goal is to have a batch cluster with a portal in front. So the user doesn't see any of the complexity of the system. It just sees a portal. And it goes there and says, I want to analyze this data with my algorithm. And then there's a batch system behind. In this case, we are aiming at Torq. And then there's one entry point for the batch cluster that takes the jobs. And then there's multiple worker nodes that consume the jobs, run them, and send back the results. The main thing here to see is that if we would do this in heat, we could deploy it in OpenStack easily. But as we have a diverse set of infrastructures, we want it to be able to have one entry point, but then have worker nodes running in multiple clouds. So it can be in our cloud at CERN in Geneva, or it could be in a cloud in Valencia, or a cloud in some of the partners in Germany. And then everything should just work. There shouldn't be any complication due to that. And by defining it in Tosca, then we can convert to the local systems in each of the sites and reuse the same templates to deploy parts of the infrastructure. So that's one of the main benefits here. Again, an example, it's a bit hard to put this in templates in a slide, because the templates can grow quite a lot. But the goal here is an elastic cluster defined by our templates that has one front end, and in this case, one or more worker nodes. So the front end looks like the configuration of it will be an Ansible template that we refer to, but the main thing is that it depends on an actual server, so it requires a server with these properties. And then the template would define the Galaxy roles that are needed. Same for the worker nodes here. It says the host is required here, and then the description of what the worker node should be. And then this translates locally to the clouds as needed, and this is where we stop defining the infrastructure, which makes it quite easy. There's a lot of work then at the infrastructure level to make all these pieces work, but this is what we've been doing with IBM by contributing upstream. So I'll just show a quick demo if this works. Just to ask. Oh, there we go. So this is a very simple example, but it's just to get a feeling of how all works. I hope you can see it. So in this case, it's like the batch example. So the goal is to show you how this works. So I'll stop here. In this case, as I've mentioned, there's this tool called HitTranslator that takes a Tosca template and outputs whatever you need. So in this case, we're saying take my elastic cluster template and generate Tosca in this case and to this output file. So then we actually copy it to another. We have this distributed file system inside, and then once we have the hot template, we can just submit it to Hit inside. So in this case, we are submitting to the cloud at CERN, and we're generating exactly the same. If you use Hit, this is all it took. We just generated the hot. We deployed the stack. The stack looks like this. It's building, so we'll wait a bit for it to build. All the resources are complete, so we do a novel list. And we see in this case, we only had an initial set of one server and one worker node, and they're both active. There's an IP that we took there, and now we can try to access the service. So as I mentioned, this is a batch cluster, so the goal is to define a job and to run a set of jobs. So in this case, we have two PBS, Torq is PBS the tool. So PBS nodes lists the available nodes, and we see that we have one node that was the one we deployed. Then we define our job. In this case, we'll define a very simple job, which is a batch script that just echoes a nice sentence there. And we'll try to deploy this into a batch cluster and see what the result is. So QSub is the submission tool for this system, and we stay here waiting that this status changes to complete. So it's still executing, and now it's complete. So once it's complete, I can log in. So in this case, just to check what it did, we'll log into the box. In this case, we only had one worker node, so we'll log into the box and see what happened. So our worker node's IP, we log into that box, and we check the execution of the job, and it will just print whatever message we have in the beginning. So it's a very simple example, but you can see the potential of this in terms of large deployments. So we have other deployments that we have the same exact Tosca template is being used to do much larger deployments. So what we do is we use the same. We'll deploy the same front-end node, and then we'll just scale the worker nodes to many sites and tens or hundreds of nodes as required. So right now, we are building slowly, so we already have some clusters with a few nodes, and eventually we'll scale to a lot more. So in terms of the Indigo project and the status of Tosca usage, the first use cases are already covered. A lot of work we've done upstream with the IBM has been very positive. So for the Tosca parser, actually, the University of Valencia and Miguel has been doing a lot of work. And at CERN, we've done the integration with the heat translator for the requirements we had. And then one good thing is that there's the heat translator CLI, but actually there's integration also with the common open stack client tool. So if you prefer that, there's integration there, and you can just deploy using a Tosca template. And there's integration with other APIs, which in our case is very important because we need to integrate with existing systems and having a better interface than the CLI tool is good for that. So coming next, we'll expand this deployment for more and more sites that are part of the project. And then try to start using Tosca also for end user applications. So this example was for infrastructure. We want to have the specific applications of the users defined in the same templates, and then continue contributing to the upstream. And with that, I give back to Sadev for some of the plans. So just real quick, and I'll make sure Matt can talk to you. Yeah, just real quick about the Newton plan. We are continue releasing point releases. Matter of fact, the next month, we should have 0.5 out and then another at least two releases throughout the Newton cycle. As we work with the Sun and other members of Inigo, we should have more need come up. And we're going to work on them. We continue working with the Tacker project with some of the more complex NFV use cases. And similarly with the Open Platform NFV team as well. We have completed most of the work against SPAC 1.0, but there are still a few items that needs to be worked on, like a container support, some of the interesting function, et cetera. And we're going to continue working, growing the ecosystem. Those last couple things, we already have some work in progress. Based on the stakeholder feedback, we're going to let them pass parameters as an input file. And lastly, Horizon Plugin to enable translational deployment from the dashboard insert to make it more user friendly. Thanks, guys. I'll hand it over to Matt for SPAC. So I'm here to tell you what's next and what cool things you should be looking for in Tosca, the standard. So metadata. We added metadata a while ago to just the service templates. You can track special values and things you want to track through your templates through the system with the service template level. But now we've added it to all top-level entities. So anytime you have a resource or a connection or anything like that, you can add metadata to track those things. It's interesting to note, I'll talk about this later, but we also have a metadata standard we've adopted in OASIS called TAG. So one of the big things we're doing in terms of conformance is using the metadata for tagging service templates for test cases. So we can actually add the metadata information about which part of the spec you're testing or if you implement your own schema for Tosca, you can actually embed in the metadata a test standard if you want to. Group type, as I've mentioned, we're advancing the group type. It's beginning to look more and more like a node in Tosca. It has currently everything but artifacts. So basically, you can actually have a node abstraction that manages other resources as a group. And we're actually evolving that towards a cluster type that you see two bolts down. Policy definition, that's a big thing. I'll show the next slide. Policy is very important. Cynlin Project, if you guys follow that in OpenStack, has blueprints open to use Tosca for policy. They need some people to do the work. The blueprints are written. They're all approved. So it would be nice to have a standard like Tosca be used instead of an ad hoc format for policy in Cynlin. Cluster type I mentioned, 75% of the work is complete. We've agreed on how to implement standard representation of clusters for homogenous types of deployments, which again matches Cynlin. We're debating on how to do some heterogeneous things in terms of different types of composite applications. And they might scale or be clustered differently, have different considerations. So we basically will have node types that will handle be able to describe load balancing and routing and some very basic functions you expect from any cluster, whether it be a ANOVA cluster, a bare metal cluster, a Docker cluster, or even going forward a serverless cluster, those types of things. Workflow, now this is a very interesting area. So one of the big things we recognized in Tosca was that it's all or nothing typically. When with Tosca or Heat, when you go declarative, it's basically saying, forget your imperative, leave it behind, or you have to write your imperative to match it to certain things like I can only install with this script. I can only destroy with the script. Well, we're actually very close to finishing workflow, where it can actually say, I want to take over certain state changes in Tosca. So if I want to take over the installation or configuration, I can say, I want this workflow where my Ansible and other scripts can take over, take you to completion and do configuration, do a bunch of stuff, and I'll put you back and tell you where you re-enter the declarative workflow. So it's a very cool thing we're doing in Tosca you'll see more of going forward. Again, we want people to preserve their value they have in their existing script languages where they have complex things they don't want to rewrite declaratively. So this is one of the major goals for Tosca. Next slide, policy. I want to show this because we actually have a model. It's important not just to have policies in name and say, we're going to have policies, these abstract things. We actually have a concrete representation of policies based upon an event condition action model. So basically, we're focusing on operational policies. You can actually say there are a small number of Tosca event types that can map to your target system. In Tosca, they can map to a Manasca event or a salameter event of some type, an alarm. You have conditions that are evaluated based upon the state of the system that can fire an action. And those actions can be script actions or call-outs to webhooks or services. So that's the concept. And again, if you see Sendlin, that matches well with Sendlin's concept. If anybody's are looking forward to serverless technologies AWS Lambda, OpenWisk is a new thing that IBM announced we're working on in the open community. Those all follow an event condition action triggering type model. Very cool stuff. Going forward, we can see we're very busy in many areas. I'm very excited about interoperability because everyone says to me, when you try to use Tosca, how do I know, as a standard, if somebody implements it, in OpenStack, we make sure we follow the standard, someone else wants to do Tosca. Well, we're gonna create conformance test suites. We're actually gonna create a GitHub repo. We're actually have one already. We're populating it with test cases. We're gonna announce in May. So every part of the spec will have test case coverages, coverage for any Git repo, and people will be able to contribute their own test cases going along.  Network function, that was mentioned by Sotov as well. The TACR project is using Tosca. The entire Etsy community around network virtualization needed a standard, and Tosca seems to be that standard. We can actually carry configuration data from Yang and other places, and we actually do that in TACR. And we actually are about ready to complete the final version of the NFE profile for Tosca 1.0. It has things like how do you do composition, how do you define network functions, network services from virtual network functions, and in turn they can be composed of even smaller granular units. And they have actually forwarding paths, forwarding graphs. You can actually describe your network flows with Tosca, very cool stuff. Instance model, we have a role group talking about how you do management. How do you, after you have it running, how do I introspect and get out the running model? So the input now is a template, but after it's running for a period of time and it has policies, it's scaling, it's failing over, doing whatever it's doing, you wanna capture that state. Maybe you want to get the idea of something and manage it or introspect it. These are things we're doing, and we're gonna define an API for instance model manipulation. Monitoring, ongoing work with the monitoring work group, you'll see some of the things in terms of be used by the clustering stuff, by the policy stuff to trigger events that can fire, evaluate rules to fire alarms if you're choosing. So you'll see these things, we're taking a very high level stance. We're doing a green, yellow, red approach saying you're in the green, you're in the yellow and the red and you need to pay attention. And you can actually derive your own granularities of events if you want to, but we're basically from a portability standpoint, we're having a very high level event monitoring type, a very flexible concept in TOSCA. So those are the things we're doing and I just wanna let everyone know that the TOSCA 1.0 spec is done. We had our 60 day review in December. We had comments, we answered, we finished our 15 day review in March. The final standard is out there, it's just been published. We're actually gonna take it to final OASIS standardization with a full OASIS wide company vote and hopefully that'll be done by in the summer. So if you're, no matter where you're using TOSCA, whether it be in OpenStack, other places, you have, you can write tooling against the standard, it's not gonna change, we're gonna track a Rata, you have complete faith that a group of companies are going to maintain that standard and not yank or change things out from underneath you. So that's all.


Hello everyone, welcome to our session application auto-scaling through elastic Kubernetes part. My name is Kathy Zhang. I'm a senior principal engineer at Intel. Along with me is Teresa Shan, who is a senior cloud software engineer at Intel. Let me go to the next slide. This is what we are going to cover in today's talk. First, we are going to talk about what is elastic Kubernetes part. And then we will go through some use cases and why do we need it. And then Teresa will take over and talk about how do we support this. And she will also do a POC demo and finally will show some test results. So what do we mean by elastic Kubernetes part? By the elastic Kubernetes part, what we mean is that when the application needs to scale out, instead of creating multiple applications paths, with elastic paths, you can create multiple application containers inside an existing running path. For example, as shown in this diagram, the user first create a pod with one application container and another sidecar container. And then the user can specify a replica number. For example, a replica number equals 10. And then after that, the system will take over, will automatically create 10 new replicated application instances inside the same running pod. So why do we need it? The first use case is function as a service. In function as a service, the system needs to scale out, automatically support scale out and scale in based on the incoming requests. So for example, at the very beginning, the system is running just one function container. And then when the users updates the replica and the system needs to automatically scale out more container application containers. And so it will scale out that application containers inside the same running pod. The second use scenario is container network function, so CNF. As this diagram shows at the beginning, the user will create application container, and along with that, he or she will create a firewall CNF and load balancer CNF. And then when the network security attack is detected, a DPI container needs to be created or added as a sidecar to that application container. So instead of creating, instead of deleting the existing pod, which has two sidecars and create a new pod with three sidecars. With elastic pod, you can create, we can reuse the existing pod and create a new DPI CNF sidecar inside the existing pod. So this will reduce the creation time, the creation latency and also to save the resource utilization rate. The third use case is in confidential computing. In confidential computing, when you create an application pod, it involves three steps. The first step is to pull encrypted application, the encrypted application container image from a remote image registry to sub-enclave. And then the image management service will then do, will then decode and unpack the image. And a test agent, which run inside the same enclave, same step enclave will do the attestation and retrieve the decryption key. And then the image management service will launch the application container in a separate application enclave. So the enclave means a security running environment for the, for any container or any module running inside it. So if we need to create two application containers in the existing mechanism, we need to create two pods, then, you know, each pod creation involves the three steps. So basically if we need to create two pods, we need to repeat, you know, the three steps, the three steps twice. With the elastic pod mechanism on the two application containers can share the same stop enclave. So we only, so we only need to do the three steps once. So the step one, sorry, the step one, step two, once. And then, you know, we can do the step three for each as we launch, to launch each application container. So this will also reduce, you know, the overhead of doing, you know, the step one, the step two multiple times if we need to create multiple application containers. And the fourth use case is performance optimization. With, without elastic pod, if a pod, if an application container spec changes, there will be multiple pod spec changes request sent to the Kublai component. And the Kublai component will send multiple messages to the pods. Basically, you know, send one message to each pod. But if for suppose if we have, you know, 10 application containers, which, you know, maps to 10 pods, then, you know, there will be 10 pod spec change messages sent to the Kublai. And the Kublai will send, you know, 10 messages, you know, to the, to the pods, to the pod worker, to the 10 pod workers. And then each pod worker will send the pod status update to the API server. So totally, there will be 10 pod status update to the API server. And this elastic pod, the, the only because all these 10 containers running inside the same pod inside one pod, and there's only one pod worker. So there's only one pod spec change message sent to Kublai. And Kublai only need to send that message to one pod worker, and that one pod work and that pod worker will only send one pod status update message to API server. And Kublai reduces the message communication overhead between all the different components of the Kubernetes framework. Now I'm going to hand it over to Teresa to go through how we support. Hello, everyone. My name is Teresa. I'm a cloud software engineer for Intel. And welcome to our presentation. Today I'm going to walk you through the design details of our elastic pod method. And also I will elaborate what we've been, we've changed to the current Kubernetes is called base. And off that, we will go through the lifecycle management of the replicated containers. And finally, we're going to quickly go through a demo. Firstly, let's take a look at the high level architecture of Kubernetes. From a high level, a Kubernetes environment consists of a control plan, also known as the master node. And distributed a storage system, which is the ATCD database, and a number of worker nodes running on the running, which runs the Kublai agents. The control plan is the system that continuously manages the object status. It also works to make the desired actual status of the replica to match the desired state of the object. And as you can see from the left illustration, the control plan is made up of major three components. They are the API server, the Kublai controller manager, and the Kublai scheduler. The API server provides API to support the lifecycle orchestration, such as scaling, updates, etc., for different types of applications. And the scheduler is responsible for the scheduling of pods across the worker nodes in the cluster. And the Kublai controller manager is a demo that embeds the control loops shipped with Kubernetes. On the right hand, the worker nodes are actually the machines that really run containers through container run times and maintain the lifecycle of the pods and the containers on them. And the bullets below, this is the major change we made to Kubernetes. First of all, in order to specify the replica value, we add a replica field in the pod spec. I will discuss it later in the next page. Additionally, we also modified the API server to validate the replica value and set the replication state. We also modified the Kublai scheduler to calculate whether the node resource fit for the replication. And besides that, we add a logic in Kublai to make it create or delete containers by reading the replica value. In the pod spec, we extend the pod status by adding a new data struct to manage the lifecycle of the replicated containers. I will talk more about it in our POC demo. Here are the changes we've made to the pod spec. As you can see on the up left right corner of the slides, a field called replica has been added into the pod spec under the container struct. The replica value specifies the total number of the running instance of the container, including the original container and its copies. The value ranges from zero to a predefined positive integer number, which could be defined and loaded into API server staff command. Zero is permitted here because in a serverless environment, users are usually billed per their usage. In our POC, we allow users to delete all the containers in a pod, only keeping the pod sandbox running. In that case, the function instance are created based on the volume of requests. In addition, as you can see on the bottom right of this page, the container statuses are also extended to track the replication containers status. It also watches the replicated containers lifecycle changes by using the POEG component in the Kubelet demo. As well as the pod spec chains, we also define a set of states to manage the lifecycle of the replicated containers. There are five states. The first is the unset state. Unset state is already state before the replication. The replication state will also be set to unset when the replication is completed. The next is the proposed state. Proposed state is a state set by the API server. It is set when the pod spec in the patch request is valid. The important state indicates that the nodes allocated for resource fit for the replication. It is set by the Kubelet scheduler. The fourth state is an infeasible state. Infeasible state is set when the resource request is beyond the nodes capability, meaning that it is impossible to complete the replication at all on the node. The last state is a timeout state. A timeout interval is set when the Kubelet starts. A timeout state indicates that it takes longer than the timeout interval to complete the replication. Then Kubelet would stop the trying and set the replication state to timeout. Then let's move over to the left to take a look at the status flow. From the left on, containers follow a defined lifecycle, starting in an unset state, moving through the proposed state, when the replication value is valid. Then it will move through either an infeasible state or a progress state, or keeps in the proposed state, depending on whether the node resource fits for the request. In our elastic pod method, the replicated containers will be scheduled onto the node that hosts the primary container. As the pod can only be scheduled once in its lifecycle. Therefore, the scheduler continuously watches for the pod in proposed state and checks whether the node resource could fit the replication request. It will be set in infeasible state if the nodes total capacity cannot meet the request. Or it keeps in proposed state if the current resource cannot fit the request, but the nodes total capacity can. It will transit into the incogra state when there are sufficient resources for the replication. Then from the incogra state, the container moves through the timeout state or an unset state, or keeps in progress state, depending on whether the replication is achieved or not. It goes back to unset state when the actual replica equals to the desired replica, meaning that the replication is completed. It goes to timeout state when the replication time exceeds the timeout interval. Otherwise, it will stays in the incogra state when the replication is not yet complete. Let's flip over to take a look at the system flow chart. On the left corner, as you can see, when a user sends a patch request to the API server to update the replica value in the prospect, then the API server will validate the replica value set the replica stage to in proposed. In the meantime, the scheduler works for the positive replica stage. When it is in proposed state, the scheduler would reevaluate whether the node resource fits. The scheduler set the replica stage status to infeasible when the resource request is beyond the nodes capability. Set it to proposed when the node resource does not fit for the time being. Set it to in progress when the replication is good to go. After that, both the scheduler cache and the ATCD database will be updated accordingly. When the container is in progress state, Kubelet will be triggered to create or delete containers by reading the replica value. The Kubelet replica stage will be set to unset if the actual replica equals to the desired replica. The replica stage will be in progress state if the node is not available for the time being. Otherwise, if it takes longer than the timeout interval to complete the replication, the replica stage will be set to timeout. Alright, after having an overview of our detailed design, I'm going to show you how it really works by a demo. In the demo, we're going to demonstrate the following scenarios. Firstly, we're going to demonstrate scaling up and down container in a pod that holds only one container, including scaling down the container into zero replica. And secondly, we're going to demonstrate a pod that holds two containers and scaling up or down both of them concurrently. Then let's quickly go through the demo. Finally, we're going to create a pod that holds only one container, and the container has two replicas. Let's take a look at the pod spec. As you can see, a replica value is specified here, and the value is two, meaning that two instances of the container will be running in the pod. Then let's try to create a pod. Let's take a look at the pod status. There are two instances operating running. And take a close look at the pod status. As you can see here, we add a pod struct under the pod status. There are a couple of fields in the replica object. The container name lists the name of containers, including the original container name and the replicated container names. The field replica stands for the actual number of the running instances. The field replica time at the time COVID starts to make replications. The field reserve the replica stands for the desired number of instance to be started. As you can see here, the replica value equals to the reserve the replica value. And the replica stage is in unset state. That means that the replication is successful. Next, we are going to scale down the stress container into zero replica. Before that, we are going to send a patch request to the API server by specifying the replica value to zero. Let's check the status. As you can see here, both the actual replica value and the reserve replica value has become zero. Meaning that there are zero instance running in this pod. Next, we are going to scale up the stress container to five instance. We're trying to send a patch request to the API server. There are five instance are up and running now. Let's take a close look at the pod status. As you can see, there are three additional containers has been created for the replication. And the actual replica value and the reserve replica value are both five. Next, we are going to create a pod that hosts two containers. Let's take a look at the pod spec. There are two containers in this pod. The container named stress is the primary container. And the container named debug is a sidecar container for troubleshooting. And when the replica value is not set, the default replica is one. We're trying to create this pod. Check the status. And we are going to verify whether the default replica value is one or not. As you can see, both the actual replica value is one. And then we are going to scale both of the containers to two replicas. Send the patch request to the API server. And check the status. There are four instance are up and running now. Yeah. Yeah, out of the four, two are for debug, two are for the stress container, right? Yes, right. And as you can see here, the stress container has two replicas now. And the debug container has two replicas as well. Meaning that the replication is successful. Okay, based on the implementation demo on the above, we also performed a test to compare the time used to create replications use Kubernetes replica set with the time using our elastic pod method. The test is performed on an Intel knock with 16 gigabyte memory and eight core CPU. And it is performed in an all-in-one Kubernetes cluster. Our code base is implementing the base on Kubernetes 1.23 code base. And the container image we use for test is Devian 11, which is pre-downloaded onto the host. On the left hand, as you can see, the column chart illustrates the time used to create replication replicated containers. The x-axis represents the replica value, which is scaling from scales from one replica. The y-axis represents the time consumption in second. The blue column represents the time consumption by our elastic pod method. And the red column represents the time consumption by the replica set method. As you can see from the calling chart on the left, the startup latency goes up slightly when the replica value rises using our elastic pod method. The data fluctuates around one second because Kubernetes tracks the container status every one second. The default relays interval deeply impacts the startup latency here. In contrast, when using the replica set method, the time consumption increases rapidly when the replica goes up. In comparison, the elastic pod method dramatically cut down on the time to replicate the container, especially when the replica value is very large. Based on the test data, we could conclude that the higher the scaling concurrency is, the more performance gains of using our elastic pod method. And it also seems that the replica value does not have much impact on the scaling latency. And our elastic pod method reduces the startup latency up to 87% when adding 10 replicas. All right, that's all we have for today. And thanks for watching. If you have any interest in our project, don't hesitate to contact us and look forward to your feedback. Thank you. Yeah, if you have any questions, feel free to reach out to us by email. Our email is listed at the beginning of the slide. Yeah, thank you. Thank you.


Story 1, the game. I was searching around the game's tab in Roblox, I saw nothing too interesting, until I decided to type random things in the search tab and see what will come up. The first thing I searched was the game, and only one game appeared. I expected more but I clicked on the only option. When I joined the game it had free models everywhere, and it was really a trash game, but the unexpected happens, the creator joined the game. He walked around the place looking like there was nothing else to do, then he said this. Oh. I didn't expect a player to be in my game. I was really confused, I didn't know this was a joke, to make fun of those really bad myth games. Or he is actually being serious. Everyone gather around the player.  I was just really broad and left the game, I got a message, for the creator. I read it and it was really weird, with the many incorrect spelling of words and really poor grammar, I just stopped reading in the middle of the message, because I couldn't just handle the poor grammar. Until I realized, I had my message set to a friend only. Story 2, Breakout. There used to be this pretty popular war group called the Indefined Army, or whatever that means, I used to be part of this group and it was really fun. Until they made this game called the Breakout, I joined, because I thought it would be an interesting role-play game, boy, was I wrong. First of all, it was clearly a rip-off of SCP, with all the monsters and the entities, but I didn't really think much about it, because people copy already popular games all the time. Moving on to what was going in the game, there was a group of people getting ready to be tested on, kinda like the Class D in SCP. Until a random loud and annoying alarm went off, Subject 834 and other people have escaped, report to the main decks. I was really confused now, what the heck is the main deck? Anyways the guards were saying to stay back and not to move, I looked over and saw another person that looked pale, I heard coughing sound effects. He was clearly sick, the guard proceeded to take him into another room, never to be seen again, Subject 984 has been infected with virus 983. What I think was going on was that this war group was testing diseases, so they can affect enemies with those viruses, and get them sick and they would die. A weird battle plan but alright, you. Come over here. A random guard said, they took me into a room and proceeded to ask questions about my health. They went out to get something and they brought a cart of tubes full of viruses. I was too freaked out to continue, so I just left the game and then decided to leave the war group. As far as I know, their group got closed for good because of that game. So that's why I don't join war groups anymore. Story 3, The Enlisted. There is a secret group in Roblox called The Enlisted, these users committed crimes that Roblox had to enlist them from the site. When the exploiting community heard about this rumor, they went crazy trying to find some truth to this, but they ended up finding one account. They couldn't access their games which is obvious, but one of the hackers in the group got weird messages from the user. Everyone in the group was weirded out and thought he was just playing a trick on them, until they started to get the weird messages too, but from a different account. That account was enlisted, but if you're wondering what were the messages well most of them just said, we didn't do anything. Or help us. The group of hackers ended up abandoning the hunt for enlisted accounts after that. Roblox was notified about the hackers and they are now IP banned. For accessing a company secret, but one of their accounts seemed to be gone forever, it's like they got enlisted from the website. Story 4, Easy Obgi, Easy Obgi, Easy Obgi. I was on Roblox looking for a game to play, there was this one game that was named Easy Obgi, Easy Obgi, Easy Obgi. I thought it was a random bodied game, but I went to play another game, then out of nowhere, I got teleported to a random game. I thought it was some hackers thinking they were funny, but no, it sends me to the Easy Obgi game. Also, it wasn't even an obgi, but it was a sword fighting game, there were other players too, confused why they got teleported to this game. When you killed a player, it would send you to another game, called Welcome to Death. I was really freaking confused. I didn't know, if it was a salty game creator or a hacker, well I quit the game and went to another game. Then it sends me back to the Easy Obgi game. I was mad at this point, I just wanted to play my game. So as other players, it turns out Roblox was testing how to remove teleportation hacks, I'm just really confused at this point. I decided to take a break from Roblox, because it was getting too weird for me, then I got some news that someone got a random admin password. Kinda what they did in the 2012 hacking, but I'm so glad that it was just some teleportation hack instead of something worse. Story 5, Happy. There was an old Roblox game called Happy, when you joined the game you will see decals on the wall of people creepily smiling.  The sad people looked scared more than sad, no one knew what the game intentions were. Some people overreacted and thought that this was a hacking group, but they were very wrong. Happy was much bigger than we thought, because Happy was a test account made by Roblox staff. So, when players joined the game, they wouldn't feel alone, kinda like Jondo and Jane Doe. Then happiness fell into obscurity, never to be remembered until a Roblox admin logged into Happy, made the game happy. Roblox found out that he made the game and fired him, but what people didn't know was that there were two happy accounts named Happy. So no one knows which one is the real Happy, and which one made the original game. At the end Happy is definitely not a test account anymore, it's a virus on Roblox ready to take over.


There are a myriad of reasons why certain Super Famicom games never leave Japan. Some maybe simply couldn't find a publisher, state side or elsewhere, but in a lot of cases, the original source material the game was based on, was never made available outside of Japan. For instance, Ghost Sweeper Mikami started as a manga, and was eventually adapted as a 45 episode anime, and it was pretty rare for stuff like this to get any exposure in the US at the time, other than what you might see at a place like Suncoast Video. Ghost Sweeper Mikami later received two video games, GS Mikami for the PC Engine, and Ghost Sweeper Mikami, Joraiishi One Ice Body for the Super Famicom. Your mileage can vary when it comes to licensed games, but thankfully this one was made by Natsume, who also made great games like Wild Guns, Ninja Warriors, and Pocky and Rocky. And no, I admit Ghost Sweeper Mikami doesn't measure up to those titles, but it's still a perfectly good action platformer in its own right, and it brilliantly captures the source material really well. There's seven total levels, each interspersed with a cutscene that tells the story of the title character, Rekko Mikami, who runs a poltergeist hunting agency. I should mention that no, you don't need to know Japanese to play through this one, and unfortunately there is no English patch available yet. There is however a text translation floating around out there, it's pretty easy to find if you just google it. Anyway one day a mysterious package shows up at Rekko's door, containing a statue with a note that says that there are hidden stones that you can find that when attached to the statue, can unlock a treasure of some kind somewhere, I guess? As you can see, Rekko and her partner Yoko Shima are pretty fired up about that, while Okinu, their ghost friend, isn't so thrilled. Unfortunately these other two characters aren't playable, but they're key components to how the story is told here, as well as the general vibe of the show, so fans should enjoy that. They do show up in the game to help you out with all sorts of health replenishments. At first glance, this game calls to mind another anime-style action platformer in Kendo Rage, but Ghost Sweeper Mikami has a lot more going for it. Yeah it's pretty standard stuff at first, a single player game with a health meter, three lives, and unlimited continues in a password system, but there's this odd little mechanic here where you can attach your wand or staff or whatever this is to the bottom of these platforms by doing a downward slash. Press the up button and you do a flip that doubles as an attack, and the game gets pretty creative with how these are utilized, like the last level here where you're actually creating your own platforms as you go, all while dealing with the changes of gravity the game throws at you, it's really well done, and it adds something slightly different to the genre. There's also three different power-ups for your staff, but they just really only add a projectile. They're useful for boss fights, but it's nothing special, and you lose them if you take just one hit. In addition to that, there's talisman you can pick up that serve as clear screen attacks, and during boss fights they will actually freeze bosses for a few seconds, and there's also a regular freeze talisman I guess, which freezes the entire screen for a bit longer? Seems kind of redundant, but whatever. The level design overall is quality throughout the game, it keeps you on your toes not knowing what to expect next.  For instance, right away you've got these zombies coming at you and your initial attack only destroys their torso, their legs keep coming toward you. There's also whatever these things are, whatever this is, or these disembodied hands, or these weirdos peeking out from behind doors. Yeah, kind of weird. Most of the boss fights also have kind of an unsettling vibe to them like this ghost thing that comes out of the walls, or this giant possessed doll. Now that is creepy. One thing to keep in mind is to always, and I mean always hold up when you attack, because it does kind of an upward slash, and not only does it have the most range of all of your attacks, it also deflects enemy projectiles back at them, so it's an extremely useful attack. And that brings me to this game's one big flaw, the difficulty. There kind of isn't any. And don't get me wrong, that's fine. Not every game has to be Super Ghouls and Ghosts, but this game is a breeze to play through, and it's a pretty short game, which is both a good thing and kind of a disappointment in my eyes. I really like a lot of what this game has to offer, and there's just not enough of it, or not much of a challenge either, but whatever. Oh well. So yeah, Ghost Sweeper Mikami, Joraiishi, what a nice body, is well worth checking out. As you can see, a lot of effort went into making this game look like it's source material, and it nails the vibe of the anime. The sprite work here is fantastic, I mean that should be obvious to anyone watching. And the music is also well done. This one may not be all that well known, but it definitely has that polished feel to it you'd expect from a high quality developer like Natsume. So this is another one you're going to want to play any way you can. All right, I want to thank you for watching, and I hope you have a great rest of your day.