Should the Ravens re-send the franchise tag from Matt Judon? Will Lamar Jackson rush for under or over a thousand yards this upcoming season? Will J.K. Dobbins be treated like Lamar Jackson was his rookie year where the Ravens really try to do everything that they possibly can to get him on the field? Please and many many more questions on this episode of NFL Questions from Subscribers. If you want to be a part of questions from Subscribers just send me an email at teamkeepitcleanergmail.com and we'll answer your question in a video. Or you can send something to the PO Box, the address for that is down below in the description. Love y'all, I appreciate y'all. Team Keep It Clean y'all been, again, supporting like crazy. So I thank you for all of that. Y'all are just the best man. Straight up, y'all are the best and I appreciate y'all. So the date that I'm recording this is Friday, May 8th. It's 9 20 a.m. I went to sleep early last night. Shout out to my guy Dre. He said, hey, make sure you stay hydrated. Make sure you get sleep, man. So we've been doing it, man. So I went to sleep early last night, slept through the night. I mean, early for me was like one o'clock, but I didn't sleep through the night. Y'all know, those of y'all that follow on Twitter, y'all know that for me, if I go to sleep before 12 and even before one, then, but definitely before 12. If I go to sleep before 12, then I'll wake, it never fails. I always wake up around like three in the morning. I wake up around like 2.33 in the morning every time. But when to sleep at one, woke up at like 8.45, 8.30, 8.45, something like that. But anyway, so it's not the best schedule yet, but it's getting a lot better. So I appreciate it. So first question in this episode of NFL Questions From Subscribers came from my boy Ibrahim Rao. He said, since you mentioned many times that Joe Flacco and Tori helped elevate the play of each other while they were Ravens, were there any other passcatchers that Flacco helped elevate their game because I thought of this for a while and I can't think of any passcatchers that were good because they had Flacco a quarterback? Well, did he elevate anybody else's game? Well, we can't really say Dennis Pitta because we never got to see him play for another team. So that would be somebody that I would say. But we never got the opportunity to see him play for another team. But I can't think of anybody. I know Anquan Bowden helped elevate Flacco's game because he gave him somebody reliable. And that was the thing with Flacco, man. He didn't throw out his career. He had many reliable targets. I mean, yeah, Derek Mason reliable. He had Anquan Bowden reliable. We asked these men senior reliable. But outside of that, I mean, him and Tori Smith, they had that connection. But outside of those four receivers, wow. When you think about it, that's a big yikes outside of those four receivers. He didn't really have nothing that was very reliable. I know some people might say Mike Wallace, but Mike Wallace, there ain't no offense to him and no diss to him or anything, but just... And how long we had Mike Wallace for a year or two years? I forget how long we had Mike Wallace for. But he wasn't bad when he was here. But Joe Flacco had a better connection with those possession guys. Man, that's rough. But the second part of his question was, if Flacco does decide to play in 2020, do you think any team will sign him back up after Cam Newton gets signed because QB injuries always happen in pre-season and in the season? Yeah, I think Patriots could be a good destination for him. Patriots, maybe Jaguars, maybe even the Bengals. Next question came from a boy, Cliff. He said, what's up, Justin? You know I follow you on Instagram and listen to your videos back when I'm at work, whenever there's a content I missed during the day, which helps me get through the night shifts a lot. So I appreciate that. And I'm sure with the longer videos, they definitely make that shift go by because they probably go over your shift. And you probably find yourself, you might be listening to a video or something and be like, hold up, I got a clock out. This video went way over these nine hours. But nah, I appreciate it, though. Thank you, man. Anyway, he said, my question, am I the only one who wants us to rescind Judon's tag? I mean, yeah, he had his best year last year, but that was only relative to himself and other players currently. That was nothing compared to, say, 2014, I believe, when you had Dooms and Sugs both competing with double-digit sacks along with McPhee cleaning up. That was outstanding. But our best and his best year last year was just mediocre. Aside from stats, we only got the production on his deal year. That being said, there's a huge risk that after the deal he just falls off if he's only motivated to come pay out I think that's part of why EDC ain't putting the trust in big money on him. I'd much rather have 16 mil to throw at Clowney or Yannick Ngagwe. Judon is the best when he's got no competition, but we're trying to be the best period, not just the best one we have on hand. Also, when we talk about Clowney or Ngagwe, we add the caveat that they could come if putting faith and success over the money they could make. We are cool with that pitch to strangers to the organization, but Judon ain't interested in the same concept. Where's his trust in the Ravens? He's trying to get all this money regardless of team success. If he don't have faith in what we're building, how can we ask someone else to? I'm not huge on pocket watching, but Judon has me confused, feeling entitled to more when he's not exactly a household name. Sorry for the long ramble, and I'm sure I forgot other key points, but hopefully as you dissect this question you come up with what I have missed. Appreciate you, bro, and keep it clean. All right, what a way to start off a question from subscribers. Well, not started off, but just being away at the beginning. All right, looks like we're going to be here for a little while on this one. So he said, is he the only one that wants the Ravens to rescind Judon's tag? No, I know other Ravens fans feel the same way, especially it being $16 million worth of money. And he said, I mean, yeah, he had his best year, but that was only relative to him and other players currently. And that was nothing when you compared to like Doom and Gloom, well, Suggs and Dumeville competing with double-digit sex. And those guys were two established, two veteran, two elite past rushes at that time. So it's hard to, I know what you're saying, but it's hard to compare Judon to them because this is only Judon's, what would this be his fifth year? This year, I think, something like that. Yeah, his fourth or fifth year, he ain't been playing long. And those guys had already been playing, I think double-digit years, by the time they got to play with each other that year. So it is a slightly different situation. And with Judon, he ain't, like, he didn't have, yeah, it's just different, man. And he also said, oh, aside from stats, we only got this production on his deal year. Well, yeah, it technically was his deal year. It was his contract year, but at the same time, this was the year that he got the most opportunity that he ever got.  He ain't gonna have no Zadaria Smith on the other side. Oh, man, that's a big yikes.  He got nine and a half. And regardless of how he got him, regardless of what type of pressure the Ravens were bringing when he got those sex, he still got him. He still got him. So you can't take that away from him. And he said, there's a huge risk that after the deal, he just falls off if he's only motivated to come pay out. Well, that's just a risk in business period. That's a risk in business period. If any of us were at our job, and it was like, uh-oh, it's time to get a raise. If we knew that our potential big raise was coming up, depending on our performance this year, it could be like, hey, yeah, I feel like I'm a good worker already, but I'm about to put in extra. I'm about to put in extra, because I'm really trying to get this payday, man. So, I mean, you could say the same for anybody in the profession because there is that risk. Well, okay, we paid you now what you're going to do. So hopefully the increased pay, like for any of us too, hopefully the increased pay would mean even more increased production. And you would want to maintain a level of consistency because as you know, I mean, it's obviously different in the workforce than the NFL, but things can happen. You can get dropped like that. Whether it's for work performance or the company just needing to make cuts. Trust me, I know from experience. But things can change quickly. But you would just hope that with his new pay, that he could end up stepping up even more. And that's just something out of everybody's control. So anyway, and he said, I think that's part of why EDC ain't putting the trust in big money on him. And I mean, he definitely put some trust in big money on him because he got him on a tag right now. Now, he hasn't signed a tag yet, but he got him on a tag right now for 16 mil. So he definitely trust him. And then he said, I'd much rather have 16 mil to throw a clowny or Yannick Ngagwe. I wouldn't want to pay clowny all that money. If it was over two years, like two years, 16 million dollars, okay, I'm with that all day. I'll be with that all day. Okay, cool. You getting paid eight mil per year. Okay, cool. I'm fine. Um, and with Ngagwe, um, I would like Ngagwe on this team. I just, I would just really like to see him for a year first thing before they issued this all this big money to him. I really like to see him for a year first. That'd be nice to hear Kalea's Campbell on the other side again and a newly motivated like when you got new motivation, even if you're older like Kalea's Campbell, if you got a newfound motivation on a new team who's had success before and you could be one of them missing pieces. Oh man. And then if they brought Yannick Ngagwe, oh man. But Yannick Ngagwe happening. Um, and he said, Judon is the best when he's got no competition, but we're trying to be the best period, not just the best we have on hand. Well, I mean, again, his best year came, uh, this year when he had no elite pass rush on the opposite side of him. And he didn't have any veteran on the opposite side of him. Well, he had pernemic fee for a little bit, but then he got hurt. Judon was still there whole year. So got to take that into account too. Um, and he said, uh, we are cool with that pitch to strangers to the organization, but Judon ain't interested in that same concept. Where's his trust in the Ravens? He's trying to get all this money regardless of the team's success. If we don't have faith in him, that we're, uh, if we don't have that faith in what we're building, how can we ask someone else to? I'm not huge pocket watching, but Judon has me confused feeling entitled to more when he's not exactly a household name. If, if you're working your job and not everybody on your job or not every boss, not every employee, not every, um, employer with that company, if not all of them knew who you were, would you still feel like you should be paid any less? Just because they don't know who you are? Should you pay be paid based off of your name alone? Or should you be paid off of performance and especially timing? We always talk about how on here timing is everything. And it, this reminds me going back to Joe Flacco. Was Joe flat?  Was any point in Joe Flacco's career, was he the best quarterback in the NFL? Not at all. He wasn't. He was never the best quarterback in the NFL. He did his thing in the playoffs and that, there was a period in time where he, he was one of the best in the playoffs. Ain't no debate in that, but was he the best quarterback in the NFL at any point in time? No. But did he get paid like it? Yes, twice. Why? Because of timing. His contract came up. And he could have got the deal a year earlier, but he said, no, I'm going to wait it out. Him and his agent, I forgot his agent's name. I think the last name starts with an E, but it's not even important. But him and his agent, they waited and waited until his final year. And then what happened? Oh, the Ravens just so happened when the Superbowl.  So with his contract, with him, he's not, he wasn't a household name, but the timing of his contract and the performance that he put at the end of his contract, it certainly worked out for him. So with Judon, it's the same situation. Is he a household name? No. Does everybody know who Judon is? No. A lot of people do, but he's not a household name. But just because you're not a household name you don't deserve to get paid. And he is, if he signs the tag, he will be getting paid 16 mil a year. Now, whether that 16 mil comes from the Ravens, if they keep him on the tag or they extend him to a longer deal, or if he signs the tag and becomes against traded to another team. And that would of course be contingent on who he's being traded to and if they can agree to a long-term deal because nobody's going to keep him on a 16 mil tag. Well actually some people could possibly but it's highly unlikely. So with Judon, I... it's just so many different factors. I do not think that it's him being entitled at all though. I don't think that at all. Because I don't feel like just because somebody's not a household name that if they feel like they should be paid more and that the timing comes up to when it's time for them to be paid, I don't think that that makes them entitled. Because he hasn't been around like on Twitter saying Ravens, y'all should pay me. Y'all need to pay me. He hasn't been putting all this stuff on the social media saying oh, y'all better pay me. He hasn't been doing none of that. None of that. We've seen other teams, we've seen other players where they go on these tirades and stuff. And their situations are different. They may not be feeling that organization or whatever. But I mean you look at I mean from Maryland too. I mean I know Matt Judon ain't from Maryland. But Stefan Diggs. Stefan Diggs. He would go to social media and he would say that some of the tweets who ain't have nothing to do with Vikings but they have something to do with Vikings. Straight up man.  We don't know what was happening behind closed doors. We don't know. So I can't really speak on that but as far as how he portrayed himself going these little tangents and tirades on the Vikings and stuff then of course we see Yannick and Gagway who you also mentioned. He was straight up with it. Jaguars, trade me. Trade me. That's the end of our relationship. Trade me. Get me out of here. Trade me, trade me, trade me. And while he's been a good player there's no doubt about that. He's been a good player but everybody handles stuff differently. He could say the same thing. He could say, hey, trade me. Or sign me long term. Because players want security. What a lot of people and it usually happens when you get a bit older in the workforce. When you're younger the only thing you think about when you're applying for a job is pay. How much money am I making? That's pretty much the only thing you think about. How much money am I making with this job? What's the salary? What's the hourly wage? What's the hourly wage? What's the hourly wage? What's the salary? Whatever. But when you're older you start thinking more long term. You'll of course still appreciate a good salary but you're thinking benefits. What are my health care options? What are my retirement plans? What's my 401K? It gives them one year, fully guaranteed. A lot of money for that one year. But beyond that, that's it. You get injured you got nothing. You got that one year, that's it. You got that one year and that's it. So that's why a lot of players don't just jump quick and be like, okay, I'll sign a franchise tag. And that's no offense to any players that did go ahead and sign it already. But with players that don't sign it right away, that's the reason. They want long term security. And I can't call Judon entitled for trying to get that. If that's what he's trying to do. Next question came from a boy, Jordan. He said, I ain't Graven. I sent a love from Canada. I appreciate you man. He said, if the Ravens find that Thomas violated his contract and let him go, do you think the Ravens will use the money? They will save from letting Earl go to sign to David and Clowney and then trade for Jamal Adams to fill Earl's spot. Yes. Especially more so the Jamal Adams part. Or Ravens made, I'm sure that if they do end up doing that I'm sure they got some backup playing that safety. I'm sure that they do. Who it could be but I'm sure like, I'm sure they have they went through this entire thought process and been like, okay, because again that the thing came out last night that the Ravens are looking to see if he violated that contract. So I'm sure that they got a whole plan in the back of their minds like, okay, if we do release Earl then this is who we gonna go after. So I'm sure they got something under wraps but we'll see if he even gets to that point. Next question came from boy Adam. He said, today I was watching the Pat McAfee podcast show I love his show. One of the only things that I don't like on the show is when they don't keep it clean and when AJ Hawke the linebacker used to play for the chiefs he'll be sitting there and it's like, what are you doing if you're sitting there smoking a cigar while they doing the podcast and stuff and it's like what's the point? You just had to come on here and show off that you do want to smoke a cigar it's so pointless man every time he does that it's so cringy man but besides that I love his show man I love his show I love that he's one of those players like he's one of those players that doesn't talk about his playing days in a cocky arrogant way because there's some players who have a platform whether they on ESPN or whatever and whenever they talk about when they play it comes off as very arrogant it comes off as like, well yeah I played before and it's all how you present something but when he talks about his playing days he's cocky at all doesn't come off as arrogant he's very funny I love how honest he is I love his energy I enjoy his show a lot and he talks about everything everything and he could say what he wants cause he ain't part of the NFL no more but yeah but he doesn't disrespect anybody and he like players anything like that and yeah he just I enjoyed it a lot but anyway he said I was watching a Pat McAfee show who was the retired former coach punter he brought up that Adam Shepter came out and reported that if the season is played without fans this year that will be a loss of about 100 million revenue for each franchise which may cause the salary cap for each team to drop 30 to 80 million dollars and if this happens it will cause teams to lose a lot of good players what do you think about this it's a hashtag team keeping it clean and hashtag Raven's flock appreciate it Adam I think we just had to wait and see we just had to wait and see because with that potential loss and salary cap I think that what the NFL would do because it would obviously affect every team I think what the NFL would do would be to just change how something I think they will come up with something to where they change how like maybe contracts are applied to the salary cap because if you think about it a lot of teams spend close to the cap and if they spend close to the cap and that cap ends up dropping by a lot of money then I think they would have to come up with something because it's like you can't just cut all these players and teams will end up getting so much dead money because of the salary cap dropping and if they had to cut a bunch of players to get back under the salary cap I think they may do a thing where they may allow them to maybe be over the salary cap or even when free agency starts because you know when free agency starts the new league year starts and that's when you're supposed to be under the salary cap but they may do something they're going to do something man because if it were to drop 30 to 80 that's a big drop that's a big drop and it just they're not going to have something where okay everybody got to cut everybody they're not going to do that and they could work something out for the salary cap what that plan is I'm not sure but we'll see when we get there next question came from my boy Greg he said I don't have a dog in this fight I'm a Darhaw Ravens fan but I need to speak on Dalton and Prescott in my humble opinion there's no difference in talent between Dalton and Prescott they are exactly the same if you compare their first four seasons honestly I'm taking Dalton over Prescott people forget Dalton averaged 10 wins and 25 touchdowns in his first five seasons he said the cowgirls have made offers to Prescott but he declined it come on man get real Prescott Jerry Jones isn't going to but his organization oh he's not going to put his organization in salary cap in a salary cap mess for a second to a quarterback if I was Jerry Jones I would tag and trade Prescott to gain draft capital to trade up for Trevor Lawrence or Justin Fields in next year's draft what's your thoughts on the matter he said go Ravens um yeah Dalton the way I look at it with Dag Prescott they just as a whole he's not as bad as people make him think but neither is Andy Dalton and with Dag Prescott their team he's got a lot of his numbers they've come in like garbage time when his team is weighed down and they have to throw their way back in the games or just try to play catch up especially last year and that's how I think Dallas end up getting like the number one offense well because of that but anyway with Andy Dalton oh man he's done a lot more I feel with a lot less and he's somebody that when he's hot he's hot man he's gonna get going and he's done it with just he hasn't done it with the weapons that Dallas has if you give him the weapons that Dallas has an offensive line of Dallas has and a running game with that Andy Dogg if he's up serious man with Dag Prescott I feel like Dallas they don't fully trust well they obviously do trust them cause they did offer them the deal but the only thing I heard about the deal was like it was worth like 33 mil per I believe there's some language in the deal that Dag Prescott and his agent didn't like we don't know why he turned it down we don't even know if he even really got offered the deal cause you know again sometimes teams will have information put out about players so the team can make themselves look better it happens all the time it's a nasty business man it's a very nasty business so don't just be like oh well Dag got offered the deal oh man that guy is stupid cause I know that's what a lot of people have been doing a whole lot of people have been doing but it's a possibility that maybe they didn't even offer him something maybe they just put it out there in the media so they can sort of have fans turning on them and stuff and media turning on them so that sort of has him cave to where it's like okay I'll take the deal because you don't want a bad public image but Andy Dogg and yeah he is no slouch and Andy Dogg can come in and do some work and the fans definitely know next question came from man man he said in gravy do you think the reason the or no the media and teams are criticizing Lamar running the ball is because they just using that to manipulate him from doing that against him and their teams because let's be real Lamar's ability to run the ball hurts a lot of teams so do you think the pressure of him throwing the ball will benefit the other teams not saying he can't beat you with his arm but if teams know you throwing the ball you become more predictable they are not concerned about that because they would actually like that a lot of people in the media would actually like that if he did get hurt because that would mean that so many of them would end up being right because that's what a lot of and it's a shame it's a shame but people would be willing to for a good player like him they would rather him get hurt so they can say hey I told you so I told you it's gonna happen they would rather that happen than to see him do well and it's sad and there even fans like that the people like that is it's just sad but it is what it is and like we said from jump when Lamar first came on board with the Ravens that's what we said from jump it's always gonna be like this his entire career so get used to it cause it's always gonna be like that but I think with Lamar's answer when he was asked about it I think that cause he said he's gonna be running less this year and I think he's just saying that that's why I said at the end when we did the video on that that's why I said at the end just put it in the comment section and I think he's still gonna play his game he's still gonna run break his big ones, break his short ones do what he does but I also do expect him to expand the passing game too now he don't need to change his game for analysts for the experts for the media, for none of that just play your game next question came from a boy Leron he said I know he signed Chris Moore to a one year deal but do you see any of the drag the wide receivers playing point and kick return? oh yeah Proche, Duvenay, I think definitely Proche Proche I think he could be he could end up fighting for that point return or kick return spot especially point return boy Jarvis Fowler he said well Lamar Jackson rushed for under or over a thousand yards this upcoming season I'm gonna say under because I mean what he did last year whoa you know what, now that I think about it it could be over it could be over again and I was gonna say because I know last year he definitely ran a lot and it benefited the Ravens in a big way but um they're gonna have the similar style offense and they may throw little wrinkles in here and there but he was off for two games in one quarter and he still rushed for a thousand and still let the league touch it so you know what I can say over and I feel bad about it because he rushed for over last year and missed two games worth of time next question also came from a boy Jarvis Fowler do you think we should re-sign Gus because Mark England doesn't have that many more years left so when he does retire we have Gus Edwards Justice Hill and J.K. Dobbins and will Antoine Wesley be forgotten like Jaleel Scott hmm well to the second question it's crowded it's crowded at receiver and it's gonna take it will take a lot for him to make it whether the regular I mean not regular season, whether active roster or practice squad it's gonna take a lot for him to make it um but I do expect him to keep about one or two practice squad but we just got to see how that all works out um but for your first question should we re-sign Gus because Mark England don't have that many more years left I just I don't see him being on the team man I know Eric DeCosta talked about oh yeah we keep four running backs that'd be cool if they did okay cool but I just I don't see them doing it I don't see them doing it so I think that he would end up getting traded before the regular season next question came from my boy Mr. Einstein one he said hey hope your day is going well hey it's going really good he said my question for team keeping clean is will J.K. Dobbins be treated like Lamar Jackson his rookie year because Lamar was a backup to Joe Flacco but Raven's always tried putting Lamar Jackson in much in as much as possible plus Lamar took full control after Joe's injury do you see J.K. having the same path or results if Mark Ingham gets injured halfway through the season ooh I like how he put that not the injury part but how yeah I love that because yeah that is exactly what they did with Lamar Jackson they were like man we got this guy this new weapon this new athlete this new just quarterback that can do so many different things we gotta get him on the field we we we gotta get him on the field we got to got to so they forced him on there even when stuff was going good for Flacco and Flacco was having some consistent drives they said hey Flacco you go at go at Y receiver Lamar come here come here you know you get out there and they did just that and they because they really wanted to use him they really wanted to have him out there and hey most of the time it worked sometimes it didn't but most of the time it worked and yeah he ended up Flacco got that injury and I believe the injury may have been a little overblown just so Lamar could be that guy um and they they sort of I think they sort of may have used that to be like oh well okay well this is the sort of transition from Flacco to Lamar um but regardless uh and that's and then Lamar was born into being the starter and everything changed um so with J.K. Dobbins and Mark Ingram yeah I could definitely see that where they like hey J.K. all right you up Ingram come here real quick let me talk to you real quick and then like J.K. hey you up baby let's go let's go so and and and they put him out there I could definitely see that happen because you know I think it's gonna be like a Willis McGathey and Ray Rice not even not even just the the little Joe Flacco and Lamar but Willis McGathey Ray Rice we got an established veteran running back but then you got this second round pick number 27 um who is what number did Willis McGathey wear when he was here was it 23 I think it was 23 because I think he wore didn't he wear 21 in Buffalo anyway don't matter um but you got this established veteran running back and you got this rookie coming in and this rookie is a complete back he can do everything that all the backs can do but he can do it all in one because he got speed he can catch out of the back field um he can break he can do all that stuff so with that being said you're gonna want to get this guy on the field and again you didn't draft no running back in the second round for nothing because running backs don't get drafted high too often so if you're drafting a running back high you're gonna be using them so yeah I do expect uh like you said the J.K. Dobbins is to sort of have that Lamar Jackson uh impact and for the Ravens to do him like they did Lamar Jackson a couple seasons ago so that was a real good question


My name is Jason Webber. I'm a Principal Lead Consultant with Magenik. And this session came about from my experience and the experience of my colleagues performing a number of migrations into the cloud, Cloud Foundry, and other paths or platform as a service solutions. We have our obligatory fire announcement. I suspect you've already seen this a few times today, so I won't read it for beta. But look around, find the exits. The exits get out. From out, you can get to outside. And of course, I have every confidence that everyone here is going to be nice and polite to the public safety folks in the event of a fire. So that's interesting.  So there's no necessary reason that a legacy migration of a .NET framework app, as big as it may be, needs to happen as a big bang, a giant exercise all at once, after Cloud Foundry lands. That's an OK way to do it, if that's what you want. But it's not the only way. There are things you can do before you have access to the platform. You can do these things in place in your running application, keep the lights on, keep the application going, and improve the quality of that application while at the same time making progress towards your eventual migration or potentially your replatforming goals. And there are some benefits to this approach. So you get a head start on uncovering all the things you didn't know. You're going to learn about the application. You're going to learn about the process. That's going to benefit the people involved. And it's also a good risk mitigation strategy. The sooner you know about a challenge, the sooner you can begin to address it, factor into your planning. And frankly, you'll get better estimates the sooner you start. So we're going to cover that. But we're not going to cover. So today, we're going to go over in the next 20 minutes roughly a framework for thinking about migration. This is broad sense. We'll cover a pre-flight checklist, some things we should go through prior to actually beginning one of these endeavors. We have the five ways of improving things and making progress on your migration goals. And then we'll wrap up. And there will be code, as promised. So before we start, given the audience, I want to make sure that some of the terms I'm using are going to be clear. So lots of these, I'm sure you've already heard today and perhaps before the session, before this conference. Migration, lift and shift, fork lift migrations, cloud ready. For our purposes, these all mean essentially the same thing. You're going to take an application and with roughly speaking minimal changes, just pick it up and move it into Cloud Foundry. That's one set of goals. That's what we're going to be talking about today, how to get closer to that. The next two are different in important ways. So cloud native or replatforming, these are typically much more significant efforts. If you're starting with a legacy.net framework application, a big one, to get there to the point where you're taking full advantage of the Cloud Foundry platform, lots more effort. Architectural refactorings, all kinds of things going on. That is not what we're going to be talking about today. Although the good news is, the progress you make towards that first goal, that smaller goal, can help you in some cases meet the larger goal as well. So no loss. And then lastly, I'll be distinguishing today between barriers to scale, meaning these are things that are going to inhibit your application from scaling out versus barriers to migration. And these are things that we have to tackle, must do's, if you will, in order to actually migrate a legacy application. Now by show of hand, I'm curious, how many folks in the audience today have heard of the so-called 12-factor app or 12-factor application? All right. That's good. So for those of you who haven't, this is a way of thinking about software. You could say it's an architectural, a set of architectural patterns for developing code that runs in Cloud Foundry. You could also say it's a way of thinking about an existing application and measuring its suitability to run in the Cloud and Cloud Foundry. So we don't have time to go through all 12 of these today, and that's okay, because it turns out that for our purposes, to migrate a legacy application, some of these are more important than others. And the purists may push back on this and that's fine, we can have a conversation afterwards if you're interested. But we're gonna focus on these three today. Dependencies, configuration, and logging. These three must be addressed in some fashion. Historically, must be addressed in order to migrate an application, a legacy dot in that application, a framework app into Cloud Foundry. There's a little bit of an asterisk here because in late March, as you may be aware, Pivotal released PCF 2.1, and that release actually relaxes some of the constraints on what you can do, what you need to do in essence, to take that legacy application, that dot in that framework app, and run it in the Cloud. Now this is still important to be aware of though, because in many respects, if you don't do these things, you're not gonna be able to take full advantage of that migration. So it's not like you don't need to do these things, but technically some of these aren't really must-dos any longer. While we're doing this, we're gonna keep our eye on three other of the 12 factors. Now these are a little bit different. Based on my experience, these are the three factors that often introduce barriers to scale. So we don't actually need to solve for this in order to achieve a migration, but we're gonna keep our eye on these as we go. At least that's what I'd recommend. And there may be some low-hanging fruit here that you can pluck along the way. So these are nice to have. So out of 12, that gets us our framework, a three plus three framework, if you will.  One of the ways to prevent bad outcomes in life in many endeavors, not just migrations, is to plan and to do a little bit of analysis before you start. Some people may take that as anti-agile, but really if you read carefully, the agile folks would say you do the right amount of planning and no more, which I agree with completely. By the way, this is autopolo and it turns out this has a history in Massachusetts. So kudos to the local crowd. So here's a pre-flight checklist. If this is something that you're interested in, if you have a big application, a legacy framework application that you're interested in migrating, I'd recommend these five steps first. So the first thing you wanna do is find a technical SME. Someone who knows the application really well, ideally, you do the best you can. If this person knows the business as well, that's even better. But for our purposes, for technical migration, that's actually secondary. If we can find a person like this, that person's not always available.  But if you do have this person, they can help us with the next four steps. And that is coming to grips with our dependencies, external dependencies, system dependencies, as well as shared state. So singletons are one example. Other shared state could be, you name it. In most legacy applications, there is a lot of shared state. As opposed to most modern applications, there's very, well, depends. You may discover there is a little or a lot of shared state depending on who wrote it and when. So dependencies and shared state. So having a large family with lots of dependents can bring a person much joy in life. But the same is not true in software. Software with lots of dependencies is painful. In migrating that software is hard because if you're not aware of these dependencies, they can really trip you up. So before we actually engage in migration activities, I strongly recommend that we put together a list of all the dependencies for a particular application. And these are examples of some of the things we're talking about. So again, PCF 2.1 makes this a little bit easier on us, but we should still do this for numerous reasons that'll become clear a little bit later on. So using the registry, using the global assembly cache, file system usage, session state, all these things you wanna be aware of. Because we may or may not be able to use them as is and these sorts of things may need some changing before we're able to really succeed in migrating to the cloud. Shared state is another one of these challenges for us. So everything is easy shared state-wise when you're a single process running on a single box. But one of the reasons we move to the cloud is to be able to scale out and shared state is the bane of scaling out. So just as with our dependencies, you'll wanna create a list of all the different forms of shared state. Could be physical shared state, meaning using a cache, I'm using a database, which is connected and that's okay. Could be logical shared state. Could be singletons in the code. That was a pretty popular pattern in the 90s. So depending on when your application was written, this could be very significant. And I have to say, I put this as number one because I actually think this is one of the most important things you can do from a practical standpoint in terms of really succeeding. If you're in an organization with a high tolerance for failure, you can skip it. And nobody likes this. Nobody enjoys doing this. But it's pretty important. So if we've done this, if we've gotten our list together, then we can do a little bit of a quick assessment and say, all right, are we ready to do this or not? So here's how we can assess whether we're ready or not. Do we have that SME? Or is this gonna be one of those slog should the code where we just don't know what we don't know and therefore we can't estimate how long this is gonna take? Does the SME agree with the rest of the team? Overall, in terms of how much effort this is, if there's a big mismatch, it's worth having a conversation about that. Some people are just those negative people and everything's always a disaster and they're gonna take a million years. Okay. But sometimes there's some valid concerns. You really wanna hear those folks out. They know a lot in many cases. How do we feel about our lists? Does the level of completeness of our lists match with our organizational tolerance for risk? Is it good enough? Do we understand our limitations? Have we figured out which parts we can succeed with and which parts we can't? Because in many organizations, you say it's a migration. Three conversations later, it's the CIO talking to someone and it's much more than a migration. So it helps to communicate very precisely. And then of course, are we comfortable with whatever benefits we expect to get having gone through this exercise? This is a good way to have that checkpoint and rationalize the effort. Great. So we've gone through that exercise. We think we're good to go. So the good news is you've already done one of the five things, the five ways. It was the creation of those lists and doing your due diligence. And if you feel cheated, I've got a number six at the end that will make that one up. So here's way number two that we can start. And again, this is in place in the current environment with the current application. Many legacy applications are running on older versions of .NET. And that's, generally speaking, not that great. If you're on 4.5.2 or later, you're more or less supported. Microsoft supports that version. But if you're running on 4.5.1 or earlier, technically you're out of support. So this is a great thing to do, whether you're migrating or not. Now, depending on where you're coming from, there can be subtle differences in the CLR versioning that can cause some problems. So this isn't a slam dunk. It's pretty easy to do. I'm not, I'm sure everyone in the room probably who has a technical background knows what's involved. So I'm not gonna go into details on this one. But it's worth noting that you can't assume it's gonna work. And so plan accordingly, maybe set up a VM, try to duplicate the environment, upgrade in place, see what happens. Test it out. Testing is probably the most important step here. And if you've got automated testing, that's fantastic. If not, you can maybe solicit help from other parts of the organization to test it out. Generally speaking, this is a can do or can't do. Occasionally there are some gotchas, but for the most part this is fairly straightforward. And you know reasonably quickly if it's gonna work for you or not. And if it's not going to work for you, this is a much bigger red flag from an organizational perspective. These earlier versions present security risks. And depending on what your application does could be a pretty big deal. The other thing I wanna mention in regard to versioning is that although it doesn't apply in the in place case that I'm discussing today, once you have your application and you're ready to migrate, as you start moving forward, once you get it into Cloud Foundry, odds are good if it's a .NET application that you'll wanna take a look at Steeltoe. So this is essentially a look ahead. Steeltoe is a fantastic implementation, re-implementation of Spring Boot. And even if you don't use the whole thing, there's lots of pieces that can be pulled out separately. It's hard to imagine you do a migration into Cloud Foundry and not be able to, given .NET, of course, and not be able to use at least one or two parts of this. And it's well written, it's all good. The reason I mentioned it here is that depending on when you'd go through this, you may discover that there's some version dependencies. So for example, back in December, Steeltoe supported 4.6.1, but not 4.7 yet. So it's just a timing thing. It does now. The new release of Steeltoe works with 4.7. So that's really just the timing thing. Here's way number three. We can do this in place. Externalize our configuration. And this actually bumps into some of the other, of the 12 factors, but the gist of this is that when you're running in the Cloud, you don't want to do what you may be doing on-premise. So how do you do configuration today? Well, lots of .NET apps have configuration files, app config, web config. And those, by and large, will continue to work, but it's not ideal. For a variety of reasons, when you're operating in a containerized environment, changing config via files, at least, is not what you want to do. So what we would like to do instead is figure out a way that we could inject our configuration via environment variables, which is a pattern you see in Cloud Foundry. And we want to do this. We want to enable this without breaking our application today because it's running in place on systems we need to keep the lights on. So what we're gonna do, what I propose, is you define a new interface, C-sharp, or whatever language you're using. You implement that interface using the current data source. You've already got the code. So whatever you're doing today, you just put that in the implementation. You've just added an interface. Then you can refactor your app logic to use that interface for the purpose of getting config. So instead of calling configuration manager, you're just calling your own method on that new interface that you've created. And I'll show this in a minute. Test it out. Then you can implement that interface and back it up with environment variables. And that will allow you to overlay the value of environment variables on top of your files. Or not use your files at all if you prefer. And then of course, test it. Always test it. It's like backups. Backups are easy. It's when you try to restore that you learn whether they work or not. So here's what that can look like in real code terms. This first block here is a demo key. This is a pretty conventional approach for getting a piece of information out of configuration using configuration manager from app settings or web.config. The second block here, I'm not sure if I can hit this with the pointer. Does that show up? Not really. So here what we're doing, this is the logic for how to pull a piece of configuration information out of the environment variables. And what you wanna do as we've showed here, you see the application config prefix.  Who knows what other process is or anything else that's been installed on a particular host is gonna put in there. So you might have a name, just as you do in web config, you have a key name and then the value that you're pulling out. You're gonna wanna do that here, but what I'd recommend is that you establish some sort of unique prefix so that common names don't collide in that global namespace with other environment variables. An example would be path. Path is already set on every Windows machine. You can't use path. Use a prefix, path, you're good to go. So that's the code for that. Now in terms of making this essentially a pass-through, this is an implementation that does both of the things I just described. What we would do here is we would first pull the value out of the configuration file. I'm assuming that we're not gonna make any changes to those because that's not part of what we're trying to do here. And then we would overlay, as I mentioned, the value from the environment variable on top of that. So you can deploy as you have it today in the event that you get to the point where you can migrate to Cloud Foundry. You can literally take the set of assets you've got, push them in, the config file goes with them, and then you can add configuration at runtime via the environment variables and just overlay on top. Or you can just use environment variables. This is an example of the interface I mentioned. It's pretty straightforward. You don't need a lot. A key, a read method, and then the implementation, this is literally the implementation using the previous method, it's a one-liner. So the amount of, the actual amount of code change that's necessary to implement this is quite low. And this gives us the ability to then configure our application via the environment variables, which is something you're absolutely going to want to do in Cloud Foundry. This is something you can do today without turning the lights off. It's very straightforward. Way number four is to come to grips with logging in the cloud. So this is something that's gonna come up in any platform as a service environment, Cloud Foundry or otherwise. If you have an application running on a server, on-premise, you can remote in RDP if there's a problem, figure out what's going on, reboot it, restart it. And the cloud is a little bit different. So it becomes more important to have, for lack of a better way to put it, good logs. Logs that are going to give the information that's required by the different audiences that might use them. And I find it helpful when thinking about logging to keep in mind that sometimes some audiences use logs for things other than strictly speaking logging such as monitoring. So you may have operations folks who are interested in the current state of the system. You may have business analysts or business owners for a particular application who are interested in transactional stuff. How many transactions per minute are we running through the system? How many transactions are completing? How many shopping carts are getting left unbought, et cetera. And of course you have a development team and they're probably gonna be looking at the logs when there's a problem debugging, et cetera. So to address logging in the cloud, we can adopt a very similar approach to what we just did. And this actually sits on top of the configuration. So in Cloud Foundry, there's a logger gator it's called. And if you emit your logging information to standard out, it will pull it in and make it available through numerous mechanisms. Now a legacy application is probably writing it's log information into files on a database or maybe you're using a third party service. That's fine. You can keep doing that. Just as we injected a little bit of extra functionality to get configuration turned on, we can do the same thing with logging. These are the steps. We'll define a new interface, should mention. As a consultant, I've had the luck, good fortune to work on numerous applications in numerous environments. And one of the things I've learned doing this is that lots of different organizations have different ideas about how to do logging. I think there's a lot of different frameworks out there. So when we're aiming for Cloud Foundry, we're gonna wanna try and line up with standards. And the six log levels that I'll show you in a minute are based on the Microsoft standard. And they represent a framework to work with them and I think it's a good one. We might wanna follow that. So we're gonna implement an interface. We're gonna continue writing to whatever you're doing right now for logging, but we're also going to write the standard out. Then we'll refactor the app logic to use our new interface just as we do with config. Very similar. And of course we'll test as we go. Now in terms of getting logging working, we actually have some tools we can pull from. The Microsoft Extensions libraries are very easy to get via NuGet. These are the two you'll need to do this, at least to do the version I'm gonna show today. And in terms of the actual implementation, it's as simple. So the approach is different depending on whether you have for example, a web service, a web application or a stateful process, Windows service, you name it. But in general, the steps are the same. So in this example, we use the Microsoft Dependency Injection, the Microsoft Extensions to create a new service collection, which is a dependency injection class. And then you notice the next line is Configure Services. So this is taking a page from .NET Core actually. We'll write our own. This is a pattern, should be pretty familiar if you're familiar with .NET Core. Then we build the service provider and then we can use that service provider to get an instance of our logging interface. And this is our own Configure Services that we've written for this purpose. It's very straightforward. We're just gonna say, we're gonna use the extension method that the logging framework makes available to us. This is Microsoft's framework. We'll say add console and that'll get us our standard out. When we log something, it'll automatically be put to standard out. And we can also set a minimum logging level. We may or may not want trace turned on most of the time. Typically, you would not do this. You would not run your trace logs all the time. You could make this configurable as well. You might choose to drive your logging level based on an external variable that you can change in the environment, which is something that SteelTow can do for you. So here's an example of the Microsoft's logging interface, just a set of very simple messages, the six levels. And this is what it looks like on the console. If you're a developer, this is probably what you'll see if you were to run that program. Couple things to note here, because some of these, you may notice, it may be obvious to you that a lot of these are related. Configuration is related to logging. And we're gonna talk in a minute about air handling. All very interrelated topics. So there's a separate presentation I think we could do in terms of proper air handling. The thing to be aware of is in the enterprise, it's very common to see a desire to just keep the process up no matter what. In Cloud Foundry, not so much.  It's much safer. You can't do that in place. This is again a case where you might wanna inject a switch via configuration that'll allow your Windows service, for example, to die gracefully if there is a big problem, which would be a critical event in the log, I would hope. Or a failure would be an exception. So we'll let it die in the cloud. We might try and keep it up again as long as it's on premise. Because our goal is to do all these things in place. So nothing changes today, you're just getting ready and making progress. When it comes to configuring the logging, this can get a little tricky. So there's a couple of links here in this presentation, especially if you're using one of the older versions of the CLR.NET framework, these are worth a read. Given 25 minutes, I don't have time to go into all the details, but these are good resources for that. I can assure you, if you're having problems and you wanna throw up your hands and say it doesn't work, I've done it. I've done it on all these versions. It absolutely does work. And if anyone has a problem, you can feel free to send me an email. Try to point you in the right direction. Which brings us to number five, air handling.  Cloud Foundry is gonna help us out that way. This is a great opportunity to go through that legacy application, the bigger the better, I guess, and take a look at how air handling is being implemented. There are well-defined best practices and worst practices by Microsoft for what to do around air handling. The one I'm showing here in the top left, as a consultant, I don't often get to say never do this. The answer is usually it depends to most complex questions, but this is almost always wrong. More than 99% of the time, you don't wanna do this. So in addition to the Microsoft best practices guidelines, my personal favorite reference is a CLR via C-Sharp. It's a pretty thick book by Jeff Richter. There's a couple chapters that relate to this. Absolutely fantastic, highly recommend. And each of these things, if done properly, I think it is fair to say, will improve the quality of that application, the quality of the code base. All right, if you felt cheated by number one, the dependencies, you said it wasn't really a way to improve things. That's planning, it's management, I don't like that. Well, here's number six. This is for the overachievers. You've already got that list of dependencies. So if you really wanna get ahead, pick a few of those and try and decouple from them, try and get some of those assets into NuGet, for example, whether you host it publicly or privately, try and work on that build pipeline. Having put that dependency list together, you're halfway here. Now it's just a question of implementation. So if you can do this, you pick something easy, something simple, migrated dependency, could be a gacked library, preferably something you control, typically the easiest ones. Get it into NuGet, update the references, test it out. Can you build it, does it pull? You're one step closer. I think we're at time. And I think we've hit all of our marks. We covered a framework. We talked about the pre-flight checklist. We went over the five ways, you can improve the application in place today. And those five to recap again are addressing dependencies, putting those lists together, updating to a reasonable and responsible version of the .NET framework, if you're not already there. Add and configure ability, typically via environment variables to begin with. Addressing logging, improving your logging and getting it to standard out as a first step. And addressing air handling. Those are our five. So thank you very much for your time today. I appreciate it. If you have any questions, I'll be at the Magenic booth, I think that's 128. And I believe we're trying really hard to give someone in the audience a Raspberry Pi on the way out. So, thank you.


We have, someone told me, the biggest party ever at Tobu University. And this was just the beginning. So can you imagine what will happen after this speech?


We know that in most circumstances that there are two outs in an inning and somehow a fielder gets a ball gets the ball and he's able to quickly tag out two runners that That's not technically a double play because as soon as the the first one first runner is tagged out That would be the third out in the inning and then the next guy is really irrelevant to the situation He would not be so the fourth out that wouldn't carry over to the next inning But whenever it comes to appeals there are there is a few situations where the umpire and it can actually acknowledge Or under the rules of the game they would acknowledge something called the fourth out And so there's quite a few different ways because obviously it's there's a different quite a few different possibilities Situations that are possible to to to have an appeal play so But let's just look at one and see how this fourth out could possibly Come into play So let's say for this example. We have the bases loaded Runners on first second and third base And that there are two outs in the inning And and with two outs Our batter here he comes up to the plate and He hits a line drive single Hard hit ball out to center field So with two outs That means that all the runners are moving right away So this runner on third base he runs home and he scores No problem this The runner on second base. He's going to to run and he's gonna touch third. He's gonna round third And he's going to be coming home. And while he's doing that He's center fielder out here. He's going to pick up the ball Never catch her in here and so and so Because the the the single was so hard hit the center fielder He's gonna pick up the ball and he's going to throw it into the catcher The catcher is going to catch the ball and he is going to tag out This second runner here this runner who originally started on second base and So he's going to To tag out this runner and that would be Presumably the third out in the inning however While this is going on We had this runner here who started on on first base and Whenever he was he was coming around Second base he actually for whatever reason he stepped over second base. He did not touch second base He came over but he made it the whole way to third base and Then the the the batter of course he would he would have run up. Maybe he just waited on first base So what we have here is this runner who started on third base He ran home and he scored one run no problem And then because this runner who originally started on second base was thrown out It seems like he was he was the third out in the inning So we have one run in and we have three outs. However, if the defense realizes they were They were paying attention and they they know the rules They can can appeal this play here this The runner who started on first base that stepped over second base and did not touch it because remember You know here that if a runner Misses a base that's legitimate grounds that the defensive team can appeal so So maybe the second baseman he says wait a second To the to the maybe the catcher still has the ball. He says hey throw me the ball We're gonna appeal this play the second baseman gets the ball Steps on second base appeals to the umpire says we feel that this runner Stepped over second base and then continued his way on to third base and in that situation because this is a force out on the appeal that means that the run would not count because it is the Third out in the inning and so we would have three outs We would have no run score and and and the inning would then be over Because the the defense then they could elect to to take that It would be the Quote-unquote fourth out in the inning and so so that is where that can come into play


So thanks, everyone, for joining IN Fabiano Fidencio. I am a software engineer who works for Intel as part of the CloudHop Advisor in Cata Containers team. I'm here today to talk a little bit about, well, Cata Containers, just go through these quite quickly. The confinement work that we have done because this talk is confining the extra security layer. So we are going to go through how we got Cata Containers to properly behave using SL Linux. What is it still missing? The benefits to the community, and we are going to do a quick recap. I must tell you, I have a lot of slides. So I may not be able to actually get to the Q&A here. I'm going to have to speak quite fast, but I will be here outside. So we can just chat there. Don't worry, I'm not going to be running. I cannot run anymore. So Cata Containers, I guess the best way to start talking about Cata Containers is to start talking about traditional containers. Is everyone here familiar with traditional containers and Cata Containers? OK, so cool. Traditional containers are pretty much like a process running on top of the host Linux kernel. And they are confined by C groups, namespaces. And they can have sometimes like monitor access control, which a bunch of people just disabled it. And they can be less privileged or more privileged according to capabilities and set comp. Cata Containers is pretty much the same thing. But we provide an extra hardware virtualization layer where you can actually run your container process inside. So on the case here, on the right, if there is an escape, you are pretty much on the host Linux kernel, like you can do pretty much whatever you want if this is not confined by some mechanism like SA Linux. On the Cata Containers, though, if you have an escape, you are inside that really, really lightweight virtual machine. And the only thing you can see there are the resources that were allocated specifically for your pod. So you cannot mess around with different process unless you are able to also escape the virtual machine, which is like, well, good luck. OK, how Cata Containers actually works. Folks here are familiar with Kubernetes? OK, Cata Containers, since the version 2.0 is quite tailored to Kubernetes. We don't have Docker or Polymer support anymore. And how it works on the Kubernetes side. You have the kubelet demon running on a node. A user creates a pod, kubelet receives a request. Then it will just pass the request down to the CRIN gene, which is either cryo or container d. And then it will start the container d in Cata V2. This long name is the name of the Cata runtime. I will interchangeably say a container d in Cata V2, Cata Shin, Cata Runtime is the same thing. Cata Runtime then will start the VMM process. And on Cata Containers, we have support for, well, we actually test on RCI three different VMMs. Kiemu, which is, I guess, everyone's familiar with. It was the first one that we started using. We have support for Firecracker, which relies on Rust VMM. And we also have support to Cloud Hypervisor, which is a project from Intel, from my team, which is also based on Rust VMM. But it's really, really tailored for the Cloud user cases. OK, Cata Runtime starts the VMM process. The VMM process will actually have the guest up. Inside the guest, we have a need process that is the agent. And the agent is responsible for the lifetime of the containers. You have to share content between the host and the guest. You have to share the container with the FAS. If you have volumes, if there are mounting volumes, those have to be shared between the host and the guest. There are two ways to do that. Well, the first one is using a device mapper. So you can just attach a Virtio Block or a Virtio Scuzz device there. Or you can use something like a Virtio FSD or NIDOSD, which is a shared file system protocol that can just allow you to do that. The Virtio FSD started as a replacement of the old 90-PFS, which we all hope that stays as that as it is nowadays. So enough talk. Let me show you a little bit of what I've been telling you. Here I have a Kubernetes cluster running with Cryo as the CR engine. And I'm going to start to engine X containers. The first one is going to run with the full runtime using the engine X image. The second one has this. The main difference here is this runtime class name, which is just telling me, like, I'm going to use the Cata containers runtime with the KEMU as VMM. So start both pods. They are both running. Let's actually check that they are behaving as expected. So the first one, well, for both of them, we're just going to check that the engine X server is up, works very well for the run CKs, which is default container runtime, and also works very well for the Cata containers. Now, let's take a look at the processes that are running on the host side. Let me just go back here. We have the Cata runtime process. We have Virtio FSD that I mentioned for sharing the file systems between the host and the guest. And we have KEMU. So those are the process that are running on the host side, and those are the process that can, if there is an escape, are through those that an attacker could actually have access to our host. So we have to confine them better. What is the best way to get a process that we see here that is running as root? Because rootless Kubernetes is still not a thing yet. They are doing it with progress, but what is the best way to confine a process that is running as root to not have access to other content? SA Linux. So what is SA Linux? There is this, Red Hat has this really nice definition in their web page. They say, like, this is Security Hands Linux. And it says it was started by NSA, got to the Linux kernel in 2003.  And it has been expanding since it started to accommodate new technologies, which is amazing. I like the definition, though, from Lukas Vrabets from Red Hat, who says that SA Linux is a technology for process isolation to mitigate attacks via privilege escalation. How does it do it? I guess the main thing we have to understand here is the difference between mandatory access control and discretionary access control. DAC is what we have with any Linux system. We have a file. You can set who owns the file, the permissions on that file. And that's pretty much it. But we have a problem. Imagine that I have a file, that I have a really only file that can only be accessed by the user Fabiano. But someone breaks into my machine, gets root access to that. They can simply change the permissions. They can simply change the ownership. They can access the file. They can do whatever they want. With mandatory access control, this is a slightly different. Because MAC actually defines access controls for the applications, process, and files on the systems. So it basically defines the interactions that a process can have with the other things that you have running on your host side. It uses a set of rules of what cannot be accessed. We call those policies. And when a process requests access to an object, the permissions are checkered, and then it will be denied or granted. So with a Linux, you may be root. You may try to access a file that has 7.7.7 permissions. And if your process is not labeled correctly, you will not get access to that. You'll just get the permission denied. So this is what we want to ensure. So in order to ensure these four Cata containers, new policy had to be created, we have Dunwash from Red Hat, as known as Mr. SA Linux, created this policy called container KVMT. And the whole idea is we get the container T policy, which is what container should be using, which is a very, very restrictive policy. And we expand this a little bit to allow whatever a VMM and virtual OSSD have to do in order to actually be able to use Cata containers. The container T label can actually access all the things that are container file T label. So everything that is inside the container. And if a container breaks out, it will just get blocked. Because if it tries to write anything on slash root, slash usr, slash var, it has no permission to do so. However, it can still read and execute binaries from slash usr, because it's interesting for you to actually create a pod where you can actually link a binary from your host to inside the container. The problem is hypervisors and shared file systems, they need different access. If you are thinking about a hypervisor, it has to somehow have access to Tantap devices in order to pass this to the gas side and then we can have connectivity inside the gas. Verti-OFS, it has to mount directories volumes on the host side. And we really don't want the normal container T label to be able to do so. So instead of actually expanding the container T, the decision was create a new container KVMT type. And mind, this is way more restrictive than just the VM normal label. Because it was going in the opposite direction of us, we got the containers and just tuned that to what we need for Kata containers. And we hope that this would work out of the box for all VMMs and shared file system solutions. We were wrong. So anyways, this was introduced. The most part of the work done on this front, there were two projects there. Container SL Linux, which is the policy. So Dunwoz added a new policy there. And then we have the SL Linux library for Go. And we had to add the support to actually checking the correct file, see if the label exists in the system, and then actually properly pass the label, set the label to the process. So those two projects were involved there. And then we wanted to have this actually working as part of Kata containers. So the approach taken was, we should receive a label from the upper process. So the CRI engine should be the process that should actually tell me, as the container runtime, I want this label. I want you to respond the VMM and the virtual OSSD process with this label. And we pass it down via the OCI spec. So Dunwoz, again, did the majority of the work here. I was pretty much only taking care that we were setting the label in the correct parts of Kata containers. Then I started working on the cryo support, because if you want to have this running on OpenShift, OpenShift uses cryo, we have to have it running with cryo. The cryo support was added by Urvashi. But there was one mistake there. She added this when we were creating the container, and we create the container already inside the virtual machine. We don't care about this being confined inside the virtual machine. We want this to be confined on the host side. And I end up doing the changes there to just set the label on the OCI spec by the time you are creating the sandbox. So it gets to the Kata runtime, and then it will be able to actually spawn everything with the right label. So let me just show you. This is not going to go and run the whole demo game, because it's exactly the same recording. I have the links for that. It's exactly the same recording. This is just the second part of the recording. I'm just going to show you here that the first demo I run with SLinux set as enforcing. SLinux has three modes, disabled. Don't do that, please. Permissive, that is like, you can run everything, but you're going to complain about that. We're going to log all the errors. And enforcing, which is like, if there is an error, I'm just going to block it. So everything was running as enforcing. And here you can see the label of the process. So we have the VertiOFSD here. Is that it? Yeah, VertiOFSD here. And this is running as the container KVMT, VertiOFSD, and the same about KEMU. But Cryo is not the only CRIN gene that we have interest on. We have container D. Container D is by far the most used CRIN gene out there. And does it work? There is only one way to know, right? This is, again, like Kubernetes cluster using Sentos. And I'm going to do exactly what I did before. I'm going to start the NGINX pod using Cata Container's runtime class with the KEMU as VMM. Apply the pod. Take a look that it's up and running. Let's check that everything is actually working as expected. And then let's check the process labels.  So you can see here, the VertiOFSD is running with the container runtime T label. It's not the container KVMT. It's actually the same label that the Cata runtime is using. This label is really permissive. It allows you to play with the C groups. It allows you to create namespaces. It allows you to have way more permissions than you actually should be able to do. But so this is weird. There is something wrong here. The same happens with the KEMU, the VMM process. So let's compare. Like up there, we have container D. Down here, we have cryo. We have the same labels being used for the Cata sheen, for the Cata runtime. But we have those different labels being used for the VIRTiOFSD and KEMU process. Down here, it's the right ones. Up there are the way more permissive ones that we don't want. So I started debugging this. What is going on? So the first thing that came into my mind is like, is this actually enabled on the container D side? This is the configuration that I'm using. And here you can see, it is enabled. So I didn't miss that part. Does container D actually have support for passing this KVM container D labeled down to the Cata containers? It does. It was added by Michael Crosby in that commit over there. It was almost a birthday gift for me one day before on August 2020. So I'm actually running a version of container D that has that patch. I was using 1.5.2. And that is part of 1.5.2. So there must be something fishy for the code. So sorry if this is too small. This is the best that I could do. But what container D does when it's actually setting up the label? It comes here. It tries to modify the process label. It checks, like, is this process here, Cata containers? If it is, let's just get the KVM label here. That one we'll call this one here. And this one here we'll just get to this function. Well, this function will actually populate all the content from that file. And this one here we'll check, like, if container KVM D is part of that file over there, customizable types, we return that, OK, here is the KVM label. Otherwise, it will just return new, which means that it will be running with the same label as the parent process. And you can see that as it's running, as it was running with the container runtime T, it's exactly the same label as the parent process. So let's take a look at that file that it's actually using. If we open that file, we don't see the container KVM D label there. It's just not there. So what do we know? We know that container research is for a label in a file where the label is not there. This label, though, is present in another file called in USR-SHA containers as a Linux context. Those are two different projects. Those are two different packages. The first one over there comes from the SLinux policy targeted package from our distro. The second one comes from the container SLinux process, policy and package. So how do we fix that? What shall we do to fix that? Just remove a bunch of code. Best way, right? What I'm doing here is I actually, instead of doing this whole dance to get the label or not, I just rely on the SLinux library because that library actually knows where to check for. And if it's present there, it will just return you the right label if it's not, it will return you an error. So we just do this, rely on that, and let's see if this works. Same drill as before, right? So container de-cluster, same Cata containers, NGINX pod. It's running, it was before. Let's see if it's working as it was before. And now let's take a look at the label of the process. You can see here, VertailFSD is running confined by the container KVMT. Same about the KMO process. So now we have the right level of restrictions that we want to have. This was measured as part of the container de-1.6.0 beta 5. Fix is there, I back-parted this to the container de-1.5.9. And cool, container de now has support to this and is working as it is expected to work. But we are talking about KMO all the time. I work for Intel, I have a really strong interest in having CloudHip Advisor running everywhere as possible. So does it work? Again, only one way to check it. Same cryo machine first one. We have everything setting to run as enforcing. Here we have the runtime class. Same one as KMO, but this time using CloudHip Advisor as the VMM. So we start the pod and let's take a look. Container creating for four seconds. This is fishy. So something's going on here. When we describe the pod, we can see that there was an error there. If we take a look whether SL Linux was able to catch something, you can see there was an AVC. Don't worry that much about this right now because I have those here. So up there is the error that happened when trying to start the pod. Down here is the AVC. It basically says, OpenTap failed because of permission denies it. The CloudHip Advisor binary, which is running with the container KVMT label, is not able to open a Tantap device. In my mind, I was like, how is it different from what KMO was doing? Took a look at the CloudHip Container's code and what KMO actually does. It receives the file descriptors of an open Tantap device. While with CloudHip Advisor, what we do is we get, we open the Tantap device as part of the Katachine. We close it and we get its name. Pass the name down to CloudHip Advisor. Close it and say, hey, open this for me. And then it's not allowed to do that. Does it have to be fixed on the container or CloudHip Advisor? Yes. So let's go a little bit about how CloudHip Advisor works. CloudHip Advisor is quite neat. Like when you launch CloudHip Advisor, it basically starts an HTTP server for you. And then you can talk to CloudHip Advisor via REST API. Then you create DVM. But create DVM just means you pass the configuration. CloudHip Advisor will use that configuration for a VM whenever the VM is booted. So createVM and bootVM are two different things. But we have a problem. We have a problem because createVM does not have the capability to receive any file descriptor from for the network device. But you can do this when you are attaching a new network device. However, it was only possible to do that if the VM is booted up. But like attaching a network device when the VM is booted is not the way that the containers would work in general. We expect the network to be up when Sandbox is created. It will just fail. And then we have a problem that this REST API is provided by this project. Well, there is this project called OpenAPI that does the bindings. It out-generates code for you so you can get these definitions. And it can just like out-generates go code that we use inside the containers. And it has no notion about the socket control messages. So that was hard. So what I did to actually fix this on the CloudHip Advisor side. I talked a lot with Robert Bradford and Sebastian Boff, who are the maintainers. And we decided to just allow people to create the VM, it means create the configuration, patch it. If you are trying to hot plug something, you just patch the configuration. You are not starting the VM. It does not require the VM to be up. You just change the configuration. That's fine. And then when the user boots it up, everything is there in place. This work was done, measured, and this is what we are using on the CloudHip Advisor side. On the CloudHip container side, though, we had to do a few changes. Because we were getting the network device, we were creating the VM, and then we were booting this up. But we had to postpone the network addition to after the VM is created, but before the VM is booted. Because we want to do this change in the config where we can actually pass the file descriptor down to CloudHip Advisor. And instead of passing the name, we pass the file descriptor. Because if you pass the name, CloudHip Advisor has the preference for that. And we'll just try to open the device by its name. And because of the limitations on OpenAPI, what we had to do was actually taking care of the request by ourselves, because OpenAPI has no notions about sending and receiving sockets. So we just had to do this simple put a request, get the response on our side. And this is a work that is still going like it's there for review, had some really good feedbacks. And I hope to get this merged next week. And this will be a part of the next release. So let me just give you a demo of this running. You can see the same cluster as we had before. Now we are just creating the Nginx pod. Same thing as before, using CloudHip Advisor as the runtime class name. And let's get the pod, make sure that everything works. This is the pod here. It works. Now let's take a look at the labels. Yay. You can see here, virtualFSD is running as the container KVMT, CloudHip Advisor process is running as the container KVMT virtualFSD process. And you can see SLinux is set as enforcing. So yay, we have this done. But is this work completed?  We are still missing. We have to make sure that this actually works with CataDeploy. CataDeploy is a demon set that we have to ease the deployment of Cata containers in Kubernetes cluster. We have to have a firecracker support added. So changes will be really similar to what we have done for CloudHip Advisor. It uses the same like REST VMM crates. But I'm not sure if the community will actually accept the changes. We have to check with them. Nidus, the support, which is a virtualFSD-like shared file system solution program, I never tested with that. Should we have a separate support inside the guest? Maybe. Do we want to have API armor support? Maybe. If someone is interested in working on any of those, I would be really, really happy to mentor. Let me just quickly go through the benefits to the community on this. Now with this, we can actually run everything using Cata containers on clusters using SL Linux by default, which basically means like rel and fedora-based Kubernetes cluster. We have Kubernetes-specific distros that are using container DNS, SL Linux, like Flatcar, Runcher, Typhoon. And maybe, I really hope that at some point, as part of OpenShift sandbox and containers, we can have a hypervisor that's slightly more tailored to the cloud use case than KEMU. Don't get me wrong, I love KEMU. But if you can have something like more modern that has the right use cases for, I would prefer. So pick recap. Cata containers can run under the container KVMT label. Support for these has been added since 2.0.0, but only for KEMU. Cryosupport has been working since the version 119.0. Container D-Patch was merged for 1.6.0, backported to 1.5.9. CloudHopRevisor support has been there since 22.0. Cata containers changes for CloudHopRevisor will be merged hopefully next week and will be part of the next release. It's going to help us to expand where we can easily run Cata containers. And if someone's interested in doing some work on this, I'm happy to mentor. And that's it. Thanks a lot, and I over my time for two minutes. Thanks.


Hi, I'm Mark Bodman, Chair of the Adoption Work Group, and I welcome you to the IT for IT forum and to participate in our adoption activities. We work on awareness of the IT for IT standard, and we also help organizations understand what they can do with the standard and the benefits they will get from adopting the standard. So we need people in the Adoption Work Group that have that aspirational goal of changing the foundations of how companies deliver and utilize and leverage technologies today. This is a group of companies and vendors and individuals that know IT organizations really well, and they want to better the industry, not just one organization. We believe that the IT for IT standard will propel organizations into delivering on the premise of becoming digital and being able to realize a digital business. So if you have skills to present complex topics to executives and other individuals in the market, please join our Adoption Work Group. So you would be a valued member, and we would love to have you participate and learn and grow with us, and you'll get the word out for IT for IT.


We're seeing some unprecedented challenges in a lot of ways to the norms and the institutions of the post-World War II era. There's been a rise of xenophobia, of nativism, attacks on immigration, attacks on the NATO and the UN and the alliances and institutions that we built after World War II from lots of different sources all around the world. What do you think accounts for that kind of change in the cultural moment or the intellectual moment we're in? And can you give us some hope about a path out of it? Well, I think your quick summary of some of the challenges we face only needs to be edited and added to because we're also facing internal challenges here to our institutions. And so I think you have to look at both the domestic and the international scene and try to answer that question the best we can. There's a lot of really smart people on this campus who are thinking about and writing about it, but I would just offer a few observations. You know, we did create the post-World War II order and it served the United States very well and it served the world very well. We had sustained peace and prosperity. We saw the rise of democratic governments. We had a real alliance across the Atlantic with our friends in Europe. We worked hard to make sure that we never saw the horrors of the previous World Wars. And I think that we owe a debt of gratitude to the leaders both in our own country and abroad who created this time in history. I think things have changed. There's no doubt about that. And a lot of institutions are under stress, including the ones that you mentioned, Mike. And we have to ask ourselves, okay, why did this happen? I think some of it is because the natural movement of thought and understanding about what's needed, the rise of technology and the sharing of information across the world, the competition that comes from people who are putting forth a different point of view. There's a natural rhythm to this that I think we are watching unfold. But I would add there's also a concerted effort to undermine our faith in these international institutions. There is a real effort by some to try to create dislocation and disruption. And at the top of that list, I would put Vladimir Putin who has been trying to undermine NATO and the European Union, American democracy, our elections for his own purposes in pursuit of his geopolitical strategic goals of restoring, in his view, Russian greatness. You see China offering a competing financial system and that competing financial system is grounded in authoritarianism in state-run enterprises. But it's being quite successful. And so people are saying, well, democracy is messy. The free market has all kinds of problems. And so maybe there's something to be learned from what's happening in China. You have rogue nations that are trying to create chaotic conditions for their own purposes. And so you can look around the world and you can see why it is in the interest of some leaders, particularly autocrats, to sow discontent, confusion, disappointment with those institutions. What we should be doing is saying, you know what, we need to take a hard look at what has served us well since the post-World War II era, where they need to be reformed, where they need to be updated. Let's engage in that process. But I think we find ourselves in a much more defensive crouch than we should be. We should be standing up for the success of the last 75 years, not throwing it onto trash heap of history. So unfortunately, we don't have leaders right now that are willing to do that, but that is what not only the United States needs, but I would argue the Democratic experiment, the transatlantic alliance, the hope for greater freedom and opportunity around the world. So yes, we need to engage now in a new process of trying to restore and renew, and we're necessary reform and even replace institutions that are no longer serving us well.