Yeah, I would have to rejoin but I could show a single picture. I'll be right back. Okay. We'll give him a minute and I'll turn up my volume. So the other thing that I wanted to do is to get people to sign up and I will create a little form for that for the August 17th live demoing of each of the different platforms, okay D for running on that and set it up. So I'll send an invitation and a note to the mailing list to get people to sign up and volunteer for demos demo sessions. Does anyone have an idea about how long each of those sessions should be should they be a half an hour or one hour. Does it take a full hour to deploy okay D say on GKE or and talk about it. I think one hour will be sufficient. One hour is generally the case. I mean it takes 12 and a half minutes just to deploy it. A, not 12 and a half, 12 and a half of one node, a single node, but about 32 minutes for the three node reduce setup. Yeah, I'll actually test a bare metal mirrored install. I'm going to time it what I've been doing in my lab because it's not it's not too terribly long because it's pulling from a local registry that does speed it up some when it's not having to drag the images across the Internet. Yeah, so and then like if I make them in one hour slots and we just schedule them the whole day and live stream or however long and however many we have then in the extra segment. And then have Q and a on whatever the like whether it's Azure or GKE or AWS or bare metal or whatever. So that that's my goal and I'm sticking to it for now. And then I'll create a landing page for that sort of allow the OpenShift Commons gatherings and we can. But I'll do it off of okd.io, as opposed to off of Commons gap the common site and people can come as they wish. So each hour would have to have like the first five minutes might have to be what is okd by each of the the person's just a little, you know, a couple of minutes about what it is. And then go into the demo and then we'll have the end of the day and this is what Diane being sneaky will have, you know, six or seven videos of each of these topics to add for people to use from the website. So I am my my motto is renew reuse recycle content everywhere. And that's really what I'm going for. So Vadim you should be back in now Vadim and I see Christian is here. So how about if we kick off today's meeting with an update on where we are any feedback on the GA and any engineering stuff that we need to be aware of. I'm sure I guess I'll go first. So let me share my screen so that we would see some stats. There is. You might know that if you're using Red Hat's pull secret, OCP and OCD as well are reporting data using telemetry back to our servers. And we are using it to build a very useful that so here is the stats for the OCD for the last week. The orange graph here is the GA release so we can see it steadily growing. And others, for instance, yellow is better five, about 40 active clusters right now. And the blue and green are better six and better four respectively. And some of something like five are C clusters active. Based on that, we can say that upgrades not very popular, which is a bit surprising, but yes, that's what we should improve on. And we've got a lot of new installs which are persisting, meaning the number doesn't drop so people just don't destroy their clusters, which is pretty good, I guess. We have no clue how to estimate if a fake pull secret has been used, but I am assuming the numbers are similar. On the issue side, I don't think we have any new interesting bugs. I think the only one is that you have to create workers twice. You have to run the create manifest twice because of the OCD specific changes we introduced. We can fix that issue a bit later. And that's pretty much it, I guess, from my side. Christian, do you have anything to add? I don't think so. Honestly, I've been head down in the code for the last couple of days ever since we got GA out. Not much more to say from my side. I'm definitely interested in feedback from folks that have installed it. Maybe one thing, we're in the middle of migrating the OCP installer to Ignition Spec 3. Very soon we'll have RATAT CoroS with Ignition V2 that supports Spec 3. And then the OCP and OKD installer will already be much more aligned than they are right now. The MCO we have successfully merged together, so from 4.6 on, there will be just one branch. Vadim and I are currently working on figuring out how to test both OCP and OKD from the same branch there. But yeah, we'll figure that out. Right now, obviously, we're in OKD 4.5 GA. I just want to say I'm very happy about that. Thanks everybody who, thanks Vadim, thanks Diane from my side. Great work and especially Diane for keeping us on edge with this and Vadim for just doing lots and lots of work there. I think we have a question on the telemetry. Does it skew the results of your telemetry if we create and destroy multiple clusters over a period of time? Or is the telemetry counting actual active live clusters? This graph counts active live clusters. CEI is doing the very same thing like creating crazy amount of clusters meanwhile, so we can see some jitter. I think we would come up with a better graph showing if a cluster has lived at least a day, we'll keep it in the stats, but that's something we should invest in on OCP side as well. Okay. I flashed it up on the screen for a minute, but I just was going to share as well. And I'll try sharing again now. I apologize. I'll show everybody that right off the bat. The survey that I went, I sent out about adoption really was meant to just sort of get us a baseline right now. And so I can redo it in six months or three months or whatever in a cadence so we can sort of watch this going up. And I'll share the results with it here. I haven't done any really deep things, but some of it's pretty obvious. And I think a lot of thank you a lot of the responses came from people in the working group. So, which is natural, but there are a few outside folks as well. And that's pretty, pretty, you know, a lot of it is where just it's very early to stuff. And what I was really interested in is what people were looking for in terms of, you know, what we can do as a working group to help them. And maybe developer workshops, operational workshops and as always better documentation on the OCP on the OpenShift side. We are also seeing a lot of asks for help for migrating from three to four. So that didn't surprise me at all.  And the lack of a dual stack support was a couple of issues. Yeah, but it's really still pretty early days. And if you guys saw my tweet with the survey in it, if you could retweet that on your Twitter thing so we can get more people in the door. But it is, you know, I'm not surprised other than the fact that the colors don't coordinate with the words here with the graphics. But I can fix that too. So I'll send a copy of the results here, sans anonymize. But it's a pretty interesting feedback, I think, and it's a good baseline. And, you know, as we don't do any gatekeeping on OKD, who downloads it, who deploys it. It's very interesting to try and figure out who is actually using it out there in the universe. So the surveys will just keep repeating. And if there's other questions that I should be asking, please let me know. I based this on one that we sent out to some open shift folks. So I could compare open shift folks to OKD folks. So that that's my bit for the day. But there's nothing here, nothing here hugely shocking from my point of view. I'll let you all all gander at that and share that with the group. The thing that I, I know I heard from Joseph post that was some conversations about the operators that were available only for OCP operate operators. And I'm wondering if we want to if Joseph you want to express what you need here and maybe we can figure out if that is this working group or another set of resources that we need to attach to that. A colleague of mine was using a few operators like the serverless operator without knowing that it is only available with a subscription. Because it's very easy to get an image pool secret and we didn't understand that it's only for trials. And now after the GA of OKD we tried to set up everything in a clean environment and were surprised that some of the operators, the serverless and the service mesh operator weren't partially available for OKD and this was surprising for us because it's not so clear if you install OKD that you see what the limits are, what you're allowed to use. I was talking with Vadim about the service mesh operators. There is a substitute called Maistra. But I don't know how, how often it is updated. It's a little bit behind in its version behind of the service mesh operator from Red Hat. The serverless operator is not available in the community version and I think it would add lots of value to OKD if they were available because they are based on open source projects. So there is a little understanding from our side why they are not also maintained the same fashion as OKD with images that are the same as the OpenShift ones, which is great. The images from OKD and OpenShift are, I think, almost all the same and it would be great to have a similar situation with the most important operators. So one thing that kind of threw me for a loop, I looked at what the operator hub presented to me. It was, it's kind of empty. There's not a lot available to you and that's actually more depressing and disheartening than I imagined it would be. Because during the betas and the nightlies, and I've played with a few of them here and there, it looks incredibly full and incredibly functional and you could do so much. And now you can basically do nothing. There's not a lot available to you and it doesn't look great. I don't know what's behind all that and why or whatever, but it's kind of sad because there's even operators referenced in the documentation that you do not have access to. They do not show up and that's really not great. We won't ever be able to make you happy, Neil, I think. No, but kidding aside. Wow, I still hurt Christian. No, that's definitely a thing we will look at now that GA is out. So one thing that isn't super visible to the outside is that internally at Red Hat, that's different groups, different teams working on. So we have the core open shift, which is OKD, which doesn't include any of the operators that are on operator hub available either for free as community barriers or by subscription. So now that we have the base working, we can actually approach the teams that would be working on getting that to work on OKD to actually make that. So we will do that and yes, we will follow up on that definitely. So I think the the Qvert operator just merged the PR last week to make it work on on OKD. So I'm not sure whether they'll be promoting that to operator hub right away or whether it may already be there. But yeah, that should technically work now and we'll follow up to make the Qvert operator and the serverless Maestro operator, well serverless and Istio operators also available there. Yeah, definitely. I agree that is a very good use case and we should deal around that. Is it possible that they also get built together with with releases of OKD so they are. No, no, it's not that we have completely different life cycles there which is actually a feature because their services and not part of the core so the life cycles are completely independent of each other. One thing that I was a little surprised was, and I see it right now when I look on operator hub I owe the website and it's there, but like when I when I looked in inside of OKD, like the Rook operator for doing stuff as the back end for your open OKD was not available and that actually kind of threw me for a loop, I kind of expected that to be there because a lot of the documentation leans very heavily on saying hey, you really should be using sep for the storage and I could do no sep and that was a little weird. But that was that was the biggest glitch that I saw the difference here is that operator hub lists Kubernetes operators. They are considered to be upstream for people who do Istio and Maestro operator and they test them pure Kubernetes and they expose it as a Kubernetes operator. The problem is that some of these operators are known not to work on OKD because of FSTCs because of other issues and so on. This is why they are hidden from the community side. This discrepancy is also different from OCP where we package and we can prepare a custom version. So in the end we had a chat with people from operator hub and they said that it's mostly a problem of time of the team. They are unable to manage three different essentially different streams of the operator and we are working with them how to introduce community who would support Kubernetes versions who would support OKD and so on. It's a very tricky problem and we're just trying our first steps with KubeVirt and Image Streams on Fedora. Hopefully the results would be very positive so that other teams would adopt it. But we are crossing into the territory of operator hub teams. We cannot tell them how to live their lives. But you know what I also work on that project too. So Diane can. I'm not quite sure which person you were talking to and I'm glad you've already talked and I really want to make that distinction operator hub.io is Kubernetes generic. And so a lot of them haven't been tested. And so and there are thousands more out there. I just haven't done a lot of outreach to populate it yet because some of the there isn't a lot of automation behind operator hub.io to be quite honest. There are humans and and testing them and you know there is no certification process there at all. And really what operator hub.io is is basically just a catalog that you know you could stand up. Anyone could stand up their own catalog and put a UI around it. So it's a pretty simple website. And the front end is open source as well for operator hub.io. The whole the whole thing is yeah. Okay. So yeah so if you want to put so you know there's there so the operator wish list for okay D. Yes that's a really good thing maybe rather. So that would be helpful for us to prioritize because we want to get there eventually so we'll just have to keep bugging the teams and maybe put some of our own work hours into this. But there's many operators so if you could please add all the operators you want to see which are, you know, the most urgent for you into that list we that would be helpful. Yeah, so I'll add it to the community page as well. So here let me see if I can copy that yes. I think Neil is typing as we speak. Yeah, no Neil is not. Somebody else is building. Yeah somebody else is doing it Neil isn't doing anything because Neil doesn't actually know what these are all called. Neil you can get the Rook operator deployed using the YAML file. Okay, yeah, open shifts and I dropped a link to a copy of it that I made that I did. Okay that'll help. Yeah, because I'm, I'm now starting to look at what it's going to take to do the thing to like replace our open shift origin. Cluster with OKD for and so it's going to, it's going to be interesting. So the preliminary preliminary exploration has begun for doing it for reels. So that'll be helpful. Because this time we want to do it kind of right rather than what we did now and I don't I'm not proud of what we have right now. Yeah, I think and Joseph you when you and I were talking about this it was mostly the service mesh stuff that you were interested in first and serverless. Yes, but serverless I understand at least the service mesh is available in a community version. It's not not not up to date I think but at least several efforts to publish it to the community catalog which which is great. But yeah, but I don't know how often will it be updated or how good is it tested and the same is for every operator in the operator for sure. But this would be this was would make OKD similar as feature rich as OCP I think which would be great because we were waiting so long for OKD to have a service mesh. And now it is not.  So, you know, defeat from the jaws of victory and all that. Is the is the developer content that sits behind the samples operator and kind of the same boat. No, it's it's worse off the samples operator is nobody. Nobody has any samples to provide to begin with the the samples operator for OCP is populated with a mixture of UBI and non UBI content and separating all that stuff like I've looked at it personally like look. Separating all that stuff is complicated. It's probably a lot easier to go back and start and build up content based on fedora base image fedora base image and sent house base image and start putting together a mixture ourselves because the stuff that they use for OCP is like not reusable at all. That's really the samples operator framework is great. The samples that it provides are not usable for non OCP users. So, so that that's the problem with it. But anything UBI based is distributable right. Careful careful careful anything UBI based as long as it doesn't layer on top in unintentionally. And that's what makes it like a little bit of a trap because if you build something using UBI images on top of a rel host your rel certificate your rel subscription populates in and activates the extra content automatically. And so it is unless you explicitly do work to make sure you don't include it you you leak in rel content and and with the way that UBI is currently made I am not confident that none of those samples don't have any non UBI content. So, so that's why it's much easier for us to be let's let's just make it ourselves in with the system that literally cannot pull from rel. We have filtered all the images which are containing non UBI rail packages. That's basically open stacks ironic. Yeah, which is yet another thing we have to get built. Okay D which involves RDO stuff and that's just another. Who is the point person that you're talking to Christian for the RDO stuff, if anybody. Nobody I don't know. Yeah, I think it was Steve Hardy. Yeah, basically folks working on metal cube. Okay, we should contact them directly. Yeah, I think that's probably our next next step is maybe to sort of. Let's let's get that wish list together if the NVIDIA if it's just the drivers and then we can try and figure out who the who to coordinate with and put names next to those of red headers or NVIDIA people or whoever it is that's in video rather people. And figure and move that forward because I think that's a significant piece of piece of work on a lot of people's parts. And then it's ongoing maintaining those things as well so you've got to get buy in for them to not just do it once, but to do it continuously. It is also unlikely that we will be able to make the NVIDIA GPU operator work. Like, just from a practical perspective, it is unlikely that that we can ever make that work, because my understanding is that it relies on the stabilized rail currently be I to function properly on rail. And I do not know of a good way to make this work on Fedora. So I'm not going to I'm not going to offer any hopes about that working right now. Why we can build drivers using the KMS we're using stable F 32 and not using some weird. Because the problem is, I don't know how you're going to make sure you match with the running kernel as things move forward. We'll build them on host we would build them in containers. And if UEFI is activated they won't they won't load. That's not okay these problems. No, but it's your problem with the GPU operator. Like, they don't load, so it's not going to work. It's it works in rel because there's an ugly, very hacky, terrible thing that they've done to make it so that it works with even UEFI mode. But it will not work in Fedora right now. I don't currently have answers for how to improve that, though it is something we're tangentially looking at in the Fedora workstation working group because it's causing other problems like. Hey, people who put Fedora workstation on laptops with Nvidia GPUs, they enable the driver and it doesn't do anything. So there's problems to solve there. I'm just I'm just not giving I'm just giving this warning that it is unlikely that we will have the Nvidia GPU working in all cases. Like in Azure, for example, it's just not going to work because of because of that. Beyond the list that we have here now, are there other ones? I mean, someone was just asking for what did we filter out? And maybe that he not write this instant, but if you can grab a list of what got filtered out that might also be a thing, a thing to add in here, not as a wishlist but just for reference. I don't see. I don't see reason why those should be filtered out. All of them are optional. Some of them might not work in your setup, but that's a different story. But for us, this list is helpful because we can start contacting teams and ask them to implement to revive their OKD support basically. If we get some of them, that's great. We don't commit getting them all of them by I don't know next week and so on. That's just not going to work. That's outside of our reach. And I was just going to ask a question. The service mesh one, if I brought in, say, Kong from Kuma, Kuma from Kong, let me get my names right, or Tetrade. That's not the same one as the one that we deliver with Operator Hub inside of OCP. But does that help at all? I think the more the better. Yeah. I'm just thinking there's at least that I know of two other envoy base service mesh providers beyond Istio. Excuse me that that week that I could ask to see if they will put theirs in. First of all, an operator hub.io and I haven't and I should and then to see if they'll get it and test it on OKD. That's that's another possibility is and we all have been probably watching the Istio K native Google conversations that might not be a bad backup plan to have those available as well. I think this, I think this GPU thing is a very important. Because it's for machine learning, it's a best practice to use GPUs. Yeah, it should really be supported. Yeah. So one of the things just yesterday I did a and ask me anything session with the open data hub folks. And I'm trying to get them to. And I'm pretty sure they already have tried and done it successfully we just haven't demoed it running open data hub on OKD. So that there's a pure open stack open source stack for open data hub. It which is just a reference architect here it's not for ML and AI it's not a product yet from red hat. I say yet because I'm hopeful, but I'm always hopeful. So just just to that as far as I know that's with the office of the CTO and I was approached by someone from octo. And we chanted all throughout last week and they're setting up OKD right now for I think several demos and several architectures. So yeah, that's probably going to come soon. Yeah, so maybe offline Christian we could figure out what those demos are and just get them staged and broadcast them out to the universe I'd like to be on whatever those reference architectures the more we can get that more content that that's great. But I'm thinking the open data hub one will drive the GPU piece. If they if they build open data because they rely so heavily on GPU so that might be a way to a way to nudge that Nvidia people do to do if we need to do anything, or at least get some documentation there. Code ready workspaces. What's the status on that Christian and that Dean. Is there any movement. At all. No. I don't think I am. I don't think I have a concerted that team, but it doesn't require any fancy stuff on the house. So I didn't see any reason why it shouldn't work. That's another one that you can deploy now with the with the YAML files if you go straight to the project. Even though it may not show up in the operator hub you can you can get or you can go upstream and get eclipse che seven and deploy it via the operator. So it's just a matter of packaging. Yeah, cause like just like with with Seth. That's how I've been deploying it is just via the YAML files straight from the project. And apologize if you've already done this. Have you blogged about that or demoed that or anything at all, Charles. It it's in the it's in the documentation for my lab I did drop the links in there. Actually, I'll go ahead and bring this up. I started preparing a poll request to see if you guys like this idea for our O. K. D. site to add a section for recipes. Just little short snippets of how do I install eclipse Che in my O. K. D. cluster or what one of them I've written up is is deploying Seth. Or adding persistent storage to the image registry that kind of thing. Something shorter than the actual documentation, but easy to find. Yeah. So I would love to do an O. K. D. cookbook. Just saying. I did I did a whole bunch of them when I was at active state for Python and other languages with people. I think that's a really effective way to get.  So that's we could do a O. K. D. slash cookbook and then have a whole bunch of recipes out there. And I think that's a known thing in in the tech world to do cookbooks like that. So. Yeah, put the put an issue in actually on O. K. D. I. O. on that site and and on this and then we can just maybe just do. I can set up the infrastructure for that and people can just do pull requests to add them. As Joseph knows, I just basically merged stuff. Anyone gives me and pray, merge and pray is what I do. So, I'm happy to do that. And then I actually think that would be a good ebook to share, like a little to if everybody brought their recipes together. That would be a really great way to do that. A plus for that, but I'm pretty sure there was someone on the code ready team that was looking at building an O. K. D. Code ready thing and I'll dig up the name from an email. I have it somewhere Christian and Betty and we can figure that out. Someone was working on it. I just think it didn't get published anywhere. That was that was it. So, yeah, so that's I'm going to add them to share my screen again. What else should we cover off here and today. Yeah, I have a small thing to talk about. We are preparing O. K. D. for some of our production clusters. And we found out that we had problems in integrating the monitoring in our environment because we have a central monitoring. Which monitor several open shift clusters. And I was talking with Vadim also in the select channel, but I would like to talk here also about that. We had to turn off the monitoring operator for that. We had to bring our own monitoring stack on O. K. D. Because the operating monitor. Monitoring operator is overwriting our our. Prometheus rules and dashboards and yeah, I'm just asking if it's possible to to turn off modules some modules. You don't want to have for some reason during the installation and without any hacks because in other distributions. Colleagues of me always show me, hey, here's a button. Switch off and you don't have to mess around with anything you don't like. And I think it would be a great advantage if you are possible to do so on your own risk. Sure, because yeah, you are responsible for everything. But it's it's possible to also feed the UI with metrics we have achieved that today. My colleagues that did that and it works. But we had to do a little bit of hacks and I think it's a verse to think about to turn off a few things. You don't need or want to replace with something different because you are forced to. This is a very tough topic. And when when Joseph says. Adjusts in you it means rip it out entirely. That's the biggest problem here because. Okay, he has to have all the features of CP has one of the features of OCP is constant monitoring and it's embedded very heavily in every single part of the product you would other other operators might render degraded if they say my metrics. I cannot inject my metrics in Simeo because it's down entirely. So the most gentle solution right now would be minimizing CMO. That aligns with the goal of code ready containers team as well because they don't need to promise this is which are very memory hungry. The biggest issue with Simeo is not that it's invasive. The problem is that it runs to Prometheus instances. Each of them uses at least one gig of memory. And you cannot disable it because other operators require metrics as well. So we will start gently pushing ideas to minimize Simeo. To the team. And that's your own risk similar to what at city has. You can have a non H.A. Prometheus instance. The problem is that your cluster won't be able to create. Because you're losing on H.A. And we cannot guarantee. That it's going to work. That can be worked around. Yes. We'll see the way it's implemented. But. There are options. And now there. Sorry. No, no, no, go ahead. I didn't realize you were still. So more brutal options available right now is. Ripping out Simeo out of manifests in the release image. You can replace it with dummy. Well, I don't know. Well, you be I images. They would just be there have no manifest. We would say I did my best. I played everything we had. And it would move on. Again, you would have to maintain your own for it for that. Which is not really complex. But that's not okay. The anymore. Another brutal. Thing is you can ignore this in CBO and scale down. The monitoring operator to zero. You won't be able to upgrade because you have overrides in studio. So. Nice options are pretty much very limited right now. Mostly because. To me, it was very almost every core operator is actually core and very critical. We cannot disable them. They swore carefully picked up. But we definitely will work on minimizing its impact. It. Could be a cluster profile basically. Where you have a non H A Prometheus which doesn't take a tons of images. The problem is not the memory consumption, but that you can't deploy a second Prometheus operator because. There is no you can say on which namespaces. The second Prometheus operator should list, but you cannot say please don't listen. It's not exclusive. Yeah. And that's why it's it's hard to set up your own stack. But that's basically a semi bug. Because it should not listen to your rules in user namespaces. It should only be limited to open shift namespaces. And if your solution is trying to list. Open shift namespaces it. Hmm. Yeah, that's a tricky, tricky topic. And the use case is very odd. So we might have to have a chat with monitoring team on that. But yeah, I think the broader issue when you go ahead. I consider this to be a semi bug because it. Should be able to be limited to some part there should be a setting. And if you if your use case would be. Pretty useful for others. I'm pretty sure they would be able to. Use that fork. Use that setting in the worst case. You can maintain your own fork with revases, but that's not really a fun time. Yeah, the broader broader issue here is really that. That's the thing we don't support in any, not in OCP and therefore also not in OCD right. So what I would suggest because it's definitely out of out of what we can do right now and in the very short term. What I would suggest is to. In order to raise this awareness with the team that actually does that just open an issue on the on the GitHub repository for the monitoring operator. Asking whether it would be possible to deactivate that specific part. You know, just as for them to have to have a card that says this is an actual use case. Because right now we don't offer that option where to deactivate. Okay, as Vadim said, because it's very integrated into everything. Thank you. Yeah, I interrupted Cheryl, I think. No, actually, that you guys ended up where where I was going. I was asking more about your specific use case. And that's, that's really the place that I know in in 311 right now, both on the origin side and the lab and in the production side in the data center. We are running to Prometheus instances now. This is pre operator, right? We've got Prometheus that came with the cluster and is monitoring all of the cluster infrastructure and we followed the rules on it and didn't muck around with that one. But we did deploy our own set of Prometheus infrastructure in the cluster that is monitoring all of the apps. So it's it we've got it watching the namespaces that we deploy our apps in and it it's working fine side by side with the with with what came deployed with the cluster. For the apps we have user workload feature, which basically control which spins up in your Prometheus control by simul. The problem is that sending metrics back to a different monitoring system. I guess what you could work is an approach used by telemetry. It sends a part of metrics back to a different Prometheus server leaving simul fully intact. This is how we get those fancy graphs basically your clusters ascending a part of critical control plane data back to our servers using remote rights. So instead of fully removing demio and replacing it with your solution, you could send the very same metrics to a different Prometheus and maintain a monitoring system based on that. So is there so this that you've put in this cluster monitoring thing is that that's definitely being something being worked on by the open shift engineering team. They didn't mention that they would start working on it, but they are aware that this case exists and it should be considered. I'm pretty sure the answer would be we won't disable the MO ever, but I'm hoping they would come up with some alternative solution. And if people noticed in the chat, I put a link to a form, which I also put in the community page. If you could sign up and tell me which one, which sessions you'd like to do and what time zone you're in for the August 17th event. I will try and work a schedule that fits to your time zones. I'm pretty sure KubeCon is running on EU time. So it'll be early for me on the West Coast, but please just do fill it in and we'll try and do that. And if multiple people talk about the same platform, like five people want to do it on, you know, AWS, we'll get you all together and you can chat about it and be in one hour and one person could be the driver. So we'll figure that out too. There you go. We're almost to the top of the hour. I've got 10 minutes left. Is there any good news anyone wants to share with us? Anyone deploy a production workload on OKD for yet? I'm hoping I could do that next week. I'm replacing my home cluster. I haven't started yet. Brian, do you think this account is a production workload? As long as somebody else, except probably for you depends on it, that's pretty much production to me. There you go. So Jamie has said that he is. Jamie, where is that production workload? Is that another home system? Well, if you do a production workload there on vSphere, you will get the prize. What is the prize? I got to make up first, I'm figuring out the t-shirt situation. We'll figure it probably a digger at you, Mish. If you are talking about a prize, we are shortly before getting our OKD for cluster in production for internal usage for different teams. And that's why I'm asking about this TPU thing because I think it will come in the midterm. But yeah, we are planning to getting GA in the next very few weeks. And as for data, we're working on figuring out when we're going to do our deployment. There's some underlying unfortunate architectural things that we need to fix first. But we are starting to scope and plan our OKD for deployment to replace our open shift origin deployment. So that's a comment at some point. Hopefully soon, rather than later, because nobody more than me wants us to switch to OKD for already. I've got two clusters running in our lab, but that's preparing our team for an OCP upgrade because we're still running 311. Well, I mean, you're better off than me. That's all I will say. You'll say it sounds like Jamie's in the lead here. So, and we may make him our showcase on August 17. Mike, this is for day job. This is not for Fedora Neil. Fedora Neil doesn't have anywhere to deploy OKD. He's too broke and doesn't have computers. There to go fund me. Oh, that's too frivolous to have a go fund me for. So, Cheryl, so I think that one of the takeaways is I'd like to have a conversation on the side with you about designing the cookbook recipe pages for OKD.io and give you proofs to do to do so. And start to want that because I think that's a really great thing. And then please fill out the form that's in there. I mean, if I'm reading here, Fedora had commune. Yeah, that's what we need the anarchist version of OKD anarchist guide to OKD. That's next. All right. Well, I don't know. Maybe Jamie deliver the child first. Okay. Make sure the child is GA. Yeah, before before anything else, otherwise there'll be some other problems in life. So let's let's see what we can do. And yeah, so if you can everybody fill out the form. I will try and create a landing page for the August 17 thing that we can all use and schedule people on and you can see what your time slots are. And we can promote it. It's a bit of gorilla marketing during KubeCon. So we'll have to use our stealthy social channels and everything else to get the word out about it. But in there's probably 70 other things that are happening on day zero at KubeCon as well. But we can rise above the noise hopefully and at least capture all that content in a day long thing and where you're probably where your T-shirts if we can get them printed and shipped in time and maybe set up a store and sell T-shirts or something at KubeCon and pop T-shirts and popcorn. I have a question. I was thinking about that in the last days. I would very appreciate it if we could do some kind of hackathons. For for different tasks which it will improve OKD such like, yeah, this GPU thing to get that working here and propose a POC or a blueprint how to do that I would love to do so because I think we have some knowledge in in this working group to pick out several things which are too hard to solve some alone. Yeah, I don't know what you think about that. I think that's a great idea. Yeah, that's definitely the way forward I think for us and I think it might be something that we can cross pollinate with the operator framework group and you know co-host that if we can get our list and the point people for each of those things that are on our wishlist identified. That might be the good basis for a CNCF now that operator framework is in CNCF and OKD co-sponsored hackathon and I'd be happy to do that. So let's get that list prioritized figure out who's who there. I'll go on to and reach out to the folks on that the operator framework side and once the list is there and see if I can figure out, you know, how we could do that. So that's that's not a bad thing at all. So I'll add that into the list of possibilities beyond GA but still adoption is really where it's at right now and more feedback and adoption when we have the operators will be easier. I think they can do more things more workloads easier. So that's a key piece of it. And, you know, again, creating content and updating doing the recipes and continuing what you guys have been doing wonderfully. Home labs content on live streams, open ship dot com medium, all that stuff is really it's huge. And we'll just keep doing the outreach and getting more bodies here to talk on this call. So with that, who is live lace here this profiling apps for CPU RAM and GPU. Is that a request? Or is that something you'd want to hack on and I don't recognize your name so if you want profiling is a very interesting topic. If we focus on co operators, that would be extremely helpful to the OCP project. But live hacking on that. We would need to grow some expertise on that. Well, that can be done though. We just need more time to contact folks from the core team because I don't really know where to start. I'm usually just bringing out we were log entries to the team and they fix it, but that's not really. That's great description right there. Awesomely formulated log messages. Yeah, all right. So that's a good, good topic for another another session and let's keep adding to this wish list and see if we can't make it all happen. Probably not in the next week, but maybe two weeks from now and you will all hear from me if you fill out that form. And I will send the form to the mailing list as well to sign up for the August 17th and then I'll start a thread with a schedule proposed and people can yay or nay their slots in that thing. I'll figure out what time we actually have to start at. I think it's like 6am on the West Coast. So I love, I love that we will figure it all out. All right guys. Okay. Thank you very much. Talk to you all soon. Thank you all. Bye.


but I want to just back up for a second. Deb, you were talking about this confrontation with Shadow and there's a really lovely quote from young in Collected Works 14 that speaks to this. He says, self-knowledge is an adventure that carries us unexpectedly far and deep. Even a moderately comprehensive knowledge of the Shadow can cause a good deal of confusion and mental darkness, since it gives rise to personality problems which one had never remotely imagined before. For this reason alone, we can understand why the Alchemist called their negrado melancholia a black, blacker than black. So when we think about the darkness versus the lightness or the black versus the sunniness of the personality, most of us create a sense of self and a sense of outer personality, outer persona that allows us to seem kind of bright and appealing and congruent with the norms of the culture. And when the negrado, when the Shadow begins to royal, all of a sudden those pretty and nice elements of the personality begin to become challenged at the very least. I'm thinking about a lot of YouTube videos running around of people lunging at rolls of toilet paper. That's become a point of comedy and scorn. At the same time, if we think about being one of those people racing to the shelves to greedily or desperately grab 48 rolls of toilet paper, and then later that day sitting down quietly and thinking, I'm that person. I'm like the person that elbowed the old lady to grab the 48 rolls of toilet paper and scurry them into my car and asking, where do I put that image of myself? And yet, there it is. I'm thinking of a sort of fictionalized case here. You know, if someone who maybe is mid-career and very well established and finds that, you know, partly as a result of the disruption of the pandemic, he falls in love with his colleague who's much junior. And, you know, this has never been something he would ever have thought would happen. And this was never in his value system to cheat on his wife or have an affair. And this is, you know, sort of the wrong thing to do for all kinds of reasons. And yet, he just is sort of tempest-tossed with these wild desires that seem to be propelling him to go in this completely new direction. That is like a negrado place and it has to do with the dissolution of old forms. Things that used to work and hold us up and contain us and give us direction and meaning now suddenly just feel like they've been swept away or they've been melted down. And we're left really confronting ourselves and wondering, who the heck are we? I think that speaks so poignantly to exactly what a confrontation with shadow feels like, whether it's your example, Joseph, of the person that scoops up lots and lots of toilet paper in desperation or greed or whatever it is. And then what do we do with that later? Or your person, Lisa, who has to realize that there's an attraction that doesn't really fit what he had thought was his morality system, of that there's a death of our illusion about who we thought we were that ties into what you talked about, Joseph, the persona of I'm a nice person. I'm good to people. I feed my cat.  And then what really we're called to do is when we get home that night or home from the grocery store is to confront that part of ourselves that is not what I wanted to be. I'll look at what I have done of what I have said, this illicit or seemingly illicit relationship, the hoarding of whatever it might have been from the grocery store. That is part of who I am. I think that's the key. Yeah, it's the way that realizing really having to own your shadow just kind of melts you down. It is a real and terrible disillusionment that I am not all those things that I thought I was. And the point isn't to necessarily remonstrate with oneself about, gee, I really shouldn't have done that. The point is to come to terms with that as an internal reality so that it doesn't have to be enacted. And Jung says we all have a thief and a trickster and probably a murderer and all these really dark things within. But if we can give them a place at the table of consciousness, then we are paradoxically freed up from having to enact all these things in the outer world. I agree with you Deb and having sat with someone who, you know, my fictionalized case, you know, I have sat with people going through things like that. And I just want to say that it's easy to jump to, well, if we just give it a place at the table, then we won't have to act it out.  I think an alchemical image that really captures that, and I think it's one of the Rosarium images, is a vibrant muscular green lion that is chomping and eating the sun and saliva is dripping down from its mouth. And that's a depiction of raw, powerful, instinctive energies that have the capacity to take hold of the ego and gobble it down, like sink its teeth into it. That it's not a pretty process, it's not an abstracted process, but it feels like being chewed up by the passion to have an affair with the junior colleague or grabbing and hoarding things because we feel that our survival suddenly depends on it when we've always been a rather refined or elegant person. Any number of other behaviors, and there's this terrible behavior that's happening where if somebody appears to be not complying with social distancing, this vigilante attitude is springing up in communities and individuals are harassing people, like screaming at them if they're not following what the authority figures in the culture are telling them what to do. So this kind of shadow bullying is rising up in the culture. Now, one of the things that we do first when shadow rises is we often defend against it. Oh, that's not me. Sometimes we'll literally forget that we did something because it's so incongruent with our view of ourselves. Sometimes within moments, we're projecting it onto another person and saying, they're the one that's doing it. I didn't do that, but the Negrado begins when we have to put hands on the experience. And if the Negrado is navigated successfully at the end, we can say, I am that. I am everything I have been. But I am also that.


Red is unfolding very slowly in Tanzania like many other countries in Africa and Tanzania is still forming up all these institutions and laws. They don't have it something on the paper or how they are going to work with red, how they are going to implement projects. Most of the funding is coming from donor support from the Norwegian support on red and is implemented I think in about nine sites in Tanzania or nine called NGOs, nine government organizations and the government side they develop what they call the national red strategy and has gone through several stages I'm sure by now so they keep reviewing it to the point where they'll come up to the final document and then maybe move forward with other things. I joined CFO three months ago but at that time CFO had already collected data what they called baseline data last year and these were data household data women survey data, village data and proponent some of the more baseline stuff where before the red has actually been started implemented last year and this year I came on board to first take over on what they call survey project implementation phase two after the baseline trying to find out what is happening on the implementation side talking to proponents and asking all sorts of questions on how they are going to calculate reference labels what's the perceptions of red and opinions of different people critics, government officials and then figuring out from the village meetings where are they with red what they've done so far from all the process of FPEC to whether they've done set up the carbon monitoring plots and the like. Well the experience has been great to me I call it a occurrence of buying something to me it's an exchange just like in Brazil but in Tanzania it's the same we are the first or CFO is the first organization ever to go back to finding research they said what are you crazy we've never seen somebody bring back the results I mean what is that for we don't even know what to do with it and then at the begin they were like wow listen it's interesting we like to hear more can you ask other people to come and present their findings and I'm like I can't control what other people are doing but this is CFO way of doing business and we're going to probably continue with this atmosphere of returning the findings and to me it was more easy to ask more questions after presenting the findings and it can be any better it depends on whether it's rained you need 4x4 Tanzania in most part of the area but you just go there arrange meeting inform the government the village leaders but you are intending to come and what's your intention and now explain more a little bit that you're going to present the findings the findings are going to be from the previous study you're not seeking any new answers or something like that you're thinking to just give that back as a token of appreciation to them and you go and call up a village meeting most of the time we get help from what they call the village executive officer arranging all the people and you get this big meeting where everybody is not expecting to see you there and then at the begin the atmosphere is very cool but once you finish you actually realise that they were interested because there's rain of questions coming and people really wanted to know more about SIFO about what they're doing what is red about the findings we've found and whether they're useful what we're going to do with the data in the future so all sorts of things and to me they were more interested sometimes they sing you a song they ask even about the crack a joke and it has been a really easy atmosphere to go back to especially when you're defining before asking new questions you be as simple as possible I can talk about all the jagans and all the acronyms at SIFO but I really simplify when I'm at the village and that's the key you probably don't mention percentage when you're presenting data you just say majority and give an estimate of something a closer estimate of what you want to say and that's the villagers understands more than just figures and numbers and you have to be very careful with that the simplicity is what matters there


Hello, DevXDays, and welcome to my talk today about Cloud Native Foundation for Developers and Platforms. My name is Max Karbecher, I'm from Liquid Reply, and I spent the past years about designing platforms, crafting platform engineering teams with various customers focusing on the application delivery, how to bring software code from the local machines to remote development environments to Kubernetes clusters, and also advise here clients and how to utilize and actually drive a little bit through the whole Cloud Native environment with its hundreds of open source tools. I'm part of the Kubernetes release team, basically in the evenings and nights, at least from German perspective. And I run with my colleague Christoph Degaszer, newsletter called Native Cloud Dev, which was published weekly. So you maybe have read one of these articles, and they're all about the term platform engineering, and what this actually means. And I think there's at least 20, 30 other articles which are going more in depth about all these topics. So we want to talk about what does actually this platform means and what is the engineering part in it. When we are talking about platforms and all these articles are talking about platforms, it means Kubernetes, most often. In my opinion, it can be also other things like Nomad or I don't know if Mesos is still a thing or OpenShift or whatsoever, but overall, it is a tool which abstracts away the infrastructure. As I already said, application delivery is a huge part for my job, but also what is nowadays very important. How do we get the code to the environments? How we can ensure a good developer feedback cycle? How you can get insights into your tool and your performance of the tool? And then for us, it's very important to have an automation. Automation is king, but we need to nowadays develop an automation in various kinds. A developer maybe wants to speed up fast the cluster to test something. This should not take long, but it also doesn't need to last long. On the other hand side, you have clusters which was the same principles, needs to live very long. They need to live a longer time. And then everything should be declaratively. We utilize APIs, throw our manifests against it and tools taking care about to provision what we have requested. The foundation for all of this is that we basically come to a trustful, reliable infrastructure which can be utilized by development teams, but also by operational teams to run software, to run your business logic, somewhere in production. Now, platform is a very poor terminology. There can be a lot of different kinds of platforms. We are also talking about platform as a service, but well, sometimes there's a little bit more than that. And at the moment, one of the common trends is to actually call it an internal developer platform. It should represent that the internal development team is providing code through all the mechanisms there and to deploy the application. And that the platform takes away all the complexity which is behind it. DNS resolution, image records, trees, infrastructures and whatsoever. And sometimes not very happy about the terminology. I think it, for example, is a little bit shortcoming in the operational perspective, but at the moment I do not know a better appropriation for it. So please feel free to give some nice wordings in the chat if you have some. So when does this IDPs appear? Well, if you work in one of the cool Spotify, Netflix and Lyfts on this planet, you most likely have something like this, but you have it because you're IT driven. You're born out of IT. You're born out of automation on the software focus. And because of this capabilities, you build a product. Now, the most companies on this planet are not software companies, surprisingly. They have other background in engineering, chemistry, banking, financial services whatsoever. So they have a really long IT history and most of the time the IT history is way more older than the most of us. But they need nowadays also IDPs to orchestrate all the chaos, to move ahead because the way how software was developed in the past is not applicable anymore, at least not to keep speed with, well, all the cool young IT hipster companies. So when we're talking about an ideal IDP, we need to start on like, where does the platform engineering team come from? And what they want to achieve? I will not go too much in every detail point here. You can read it afterwards also by yourself. But important is who we need to support as a platform engineering team. And on the first place is always the development team. We need to reduce the walls, the hurts for the developer to join these platforms, having a single point of entry and to rely on it that whatever you need will be provisioned through the platform and you get immediate feedback to utilize it. I said also the operations team is a very, very important piece of it. And it's a little bit shortcoming in the terminology and the point of view of IDPs. Nevertheless, platforms needs to be also operated. This can be done by platform engineering teams but most of the time there's someone else in addition who runs not only the platform but also the application. So we need to bring all the good and relevant tools from the beginning into this discussion. And we need to utilize what the platforms allows to do like self-healing, restarting containers when they are failing, replacing whole infrastructure switching to other data centers if possible. Security, at least for me as a German point of view is another very, very big thing. We need to consider security from day one actually. And reality security is mostly applied in the end and then it makes it more difficult. I think with IDPs, we have a chance to apply security rules very in front to do all the heavy lifting of encryption, of threat detection, of integration of CM and take this all away so that you can pure focus on the main business logic of the application. And we need to also support somehow the business because somewhere we get also the money from. And on the other hand side, we need to also make transparent where the money goes to. With a platform as an equation of platforms, we can create a kind of transparency, show which development, which solution maybe costs you more or less, where you have higher reliability in the software and which services are maybe more frequently requested than you actually expected. So what you actually want to achieve is that from a development or application point of view or something that wants to call a product, your cloud platform and all your infrastructure is abstracted away. You maybe see the database entry points, something for message streaming, something for logging. You need to store some of your secrets, just the difference. And most of the time, you're very, very sure on which platform you're running. You know that it's a container, maybe in Kubernetes. You know that you install on virtual machine and so on. But what would be even better is that you get rid of these things, which are too specific. When you put your platforms right and your entry points are correct, then you can go one more step away from it. And no one needs to know anymore where it is running on, on which platform, which environment it is running on. Is it the OCI compliant container or something else? Now, this is a little bit future topic in my opinion, but it's something where we are going to, the only reason why we are not there is that you need to define nowadays still how the software should be deployed. And this is actually something which the people who write the software know best. So about some lessons learned, the little things I would call them. And you maybe will be surprised, but whatever you do, it's absolutely wrong. We will focus on the past that if you go the way left and we just say, okay, everyone can build containers and it's not a problem. You can just throw it through container registry. Suddenly a huge group of people appears on the other hand side and say like, hey, no, that doesn't work anymore for me. Or vice versa. And then there's the market. It is, the market is quite fast actually. And well, appears that you sometimes have some issues here because actually you're developing, the market develops the tools faster than you can replace them. And it's not about tools only, but also about all the ideas, all about the methodologies. We need to simplify the infrastructure, but we should not have the target to explain everyone how it actually looks like. You cannot train thousands of developers within an organization to understand every single part of the infrastructure. And this is not interesting for everyone. For everyone who's interested in this, great. You can do so, but it's not necessary to understand every little piece into the topic. And as I said before, you need to start early with security. Every project where we start really late with the security getting more and more harder to closely come to production. It's still possible to do so, but it suddenly this, well, pain in the room which you have when you enter the security part. When you do the other way around, apply security from the beginning, it's way more easier to do so. Now from a platform engineering perspective, there's a lot of complex things you have to keep in mind. This picture is actually a little bit older, but I still like to utilize it to explain to people what we all have to keep in mind. But yeah, well, take a look on it by your own. You mean there's it mixing topics, it's mixing responsibilities. It's all somehow connected with each other and somehow it's not connected with each other. And therefore it makes it complex to develop platforms. Let's look on three more interesting lesson learns which I took with me and which we try to explain to everyone whom we approach. Kubernetes is not a hypervisor. Well, that's not something which I've learned, but it's something that I've learned that most people understand who start utilizing Kubernetes. They treat it as a random virtual machine as a hypervisor. I try to always explain it this way. When you go and bet on Kubernetes, you have actually two choices.  Or you go all in Kubernetes. You rely on the product, you rely on the platform but it takes over for you encryption, DNS resolution, observability tracing, traffic management, security, whatever else you want to have, user management, authentication, authorization, all the things can be taken away but you have to bet on the platform. And this is what the people not understand. They think like I will build my software like I have done it in the past but I'm bringing it to Kubernetes but I will not 100% utilize it because I do not want to have too much dependencies to the platform. And yes, it's a point to have too much dependencies. It's not good. But in this case, you need to see it as a whole ecosystem which comes together. And if it's done well, it's a very, very beneficial approach for yourself. Also, it makes it more harder if you try to keep doing the software like you have done in the past without very integrating with the Kubernetes itself because you need to invent all the time workarounds. Cloud providers matters. On the paper, all cloud providers are the same. They have more or less the same prices. They have more or less the same features and capabilities and whatsoever. We implement products and projects on various cloud providers and more than is written here. On hypervisors, it doesn't matter. And I can tell you one thing. Every hypervisor or every cloud provider has its own problems and you need to understand them. And you need to push for that. You really choose the best for your development perspective, for your infrastructure perspective, for your engineering point of view rather than maybe for the best deal. Just because you can save a million euro on the environment, it doesn't mean that the platform is the same good as when you have something which is a bit more expensive. For my experience, quality sometimes costs more. And you can see this also in some very specific places. Infrastructure is a code that's crucial for a platform engineering. It is most important, one of the most important things. Now, I love cross-plane. It's an awesome tool because it really fulfills all the modern needs of building platforms. But cross-plane, for example, has a very poor support for Azure because the Azure community also here is not very much contributing back rather than taking a look on AWS and GCP where you have a great amount of people behind supporting it. Now, I know that the guys are developing here and keep up with Azure but Azure at the moment have a really big drive on the market but we cannot adopt cross-plane or the whole cloud-native approach to provision infrastructure because the adoption is not so good. And there are a few other issues with the technology itself of Azure. Lastly, there's a mythos about CI-CD. Back, I don't know, five, six, seven years ago, CI-CD was this thing. Every company starts to implementing it and it was really helpful. The automation was great to take away jobs from ops teams, free them up to focus on the really important things to keep the infrastructure developing and so on. But it has also some, well, nowadays issues. We really need to break up CI-CD. It's not one single word, it's two parts. It's the integration and the delivery. Modern DevTools like Tilt which you can use for cloud-native development reaching from your local machine or your remote machine where you develop up to the infrastructure where you're going to deploy and give you a fast feedback cycle about what's going on. And that is so important for the development and you have to allow it. On the other hand side, as I said, I'm coming from a market where security is a very, very important point. So for going for a productive lifecycle, we need to make there a cut and setting a checkpoint or sometimes even the break point. Now, in all the projects which we have done, one of the best break points is the container registry. The container registry and the Git repository or the chart library wherever you want to define how to deploy your container. Well, it's like that. Well, we can apply there all those security features which we need to have, scan for problematic things, make a bomb, like builds of material list, check containers for bad configuration, check for bad dependencies in the software. And then still the autonomy and the flexibility and reliability to deploy, you need to go away from the classic CI CD pipeline thoughts and move on to GitOps because then GitOps take the certified, the ensured container which has a high quality and the configuration and throw it to the clusters where you need to be, but not only this. So GitOps is needed not only because of this breaking point which is required, but there will be also changes in the future and the way how we can deploy containers or that you will deploy containers at all. Just think about a web assembly. It's something which is approaching as fast but the community is driving hard into it to make it possible to utilize web assembly more and more often because it solves other questions around security and isolation, for example. So if you set up now already a pipeline which is based on GitOps, you in the future can replace very easily the part of deploying it or CI compliant Docker and replace it with any other kind of container format. And that's very helpful in this point of view to break this CI CD up. For sure you need a unified observability to implement it on every kind of infrastructure. The thing is that for every cloud provider you need to adjust it a little bit. You need to fine tune a little bit because everyone does a little bit differently. And you have to do it. An average, I think from the cloud native report from last year, enterprise has at least 2.4 cloud provider public cloud provider. In other words, the one company has two the other company has three cloud providers and this is the huge amount. So you need to find an observability way which is unified for any kind of platform. And this is needed to support development teams and to deliver the developer the full insight of traceability, the logs, the events, how does the application performs. Think about progressive delivery, metric based shifting from workload from A to B. You need to give the insights back. I think I talk enough about security. Sorry for annoying that. Maybe I should change the name of the talk we'll talk a little bit differently, but it is the same and start early with it. So a few things which also do not work so well when you're building platforms. Number one is the observability is not designed for platforms nowadays. If I want to operate and manage and observe the infrastructure, I basically always observe also the containers on top of it. But what I actually want to do is that the software which runs on top of it in its isolated environment has its own stack of observing, of metrics of logs. And this should be shipped somewhere else, not into the infrastructure itself. And it's very cost intensive. And it doesn't matter in which club provider you want to use native tools or an additional tool, they're all very, very costy. Mighty tenancy. Actually it's a topic which, well, it's getting somehow sorted out slowly step-by-step. But remember, containers are not secure. So the isolation isn't also. On the other hand side, yes, the user management is somehow sorted out, but it's complex and hard. And projects I've seen, user management is one of the most complex part in all of these things. And there's still no very good solution which can easily sort this out. And the metadata, we had built a, let's say Kubernetes distribution thing for an telco provider, where we have so much metadata which needs to be stored somewhere. And there were so many ideas about starting Kubernetes, but like, hey, Kubernetes is not the database itself. It should do other things. You can start in Git, but sometimes Git is getting too slow if you have too many requests. It doesn't matter which GitLab, GitHub. And then you came up with an own solution, but this is also not perfect. So these three things are not that very well done in my opinion yet, but I think also on the other hand side, this platform topic is still quite new and young on the market. So to finish this talk, there are a few key metrics which we keep in mind when we build platforms. And the first one is that the number of scripts you need to provision and maintain your infrastructure is the same or shows how inflexible you are. The more scripts you have, the more dependencies you create between tools. And that's not good. And this leads directly to point two. The more components was interdependencies, you have the less you can use your platform in the future. As said, the market has developed too fast. You will have to replace tools in the future. If you do not build your platform for changing the sum of the parts, then you have to rebuild the platform again. And this is the major issue. The most of the enterprises needs to do over and over and over again. Rebuilding platforms. And last but not least, my favorite one and also actually from one of my product owners which got in a product in a project bag as a feedback. If the handbook for the developers is too complex, it means that the platform is worse and that actually it's less likely to be used. Developer focus ends where your documentation starts. And if the documentation is too complex, well, you have a problem. Thank you very much. I hope you could enjoy it and have a great day.


Dear students, in this module we are going to talk about the perspectives on social movements. Social movements are a complex phenomena and different sociological perspectives offered varied insights and different aspects to be interpreted for the origin, processes and impact. The first one that we are going to discuss is the deprivation theory. It argues that the social movements arise when people feel deprived of resources, rights or opportunities that they believe that they should have. An example can be the agrarian movement of farmers in India where they protested against the perceived deprivation caused by the new farm laws. When we see that there is a relative deprivation and people do feel that they are not being given their adequate share of rights, they do begin to agitate against that situation. Then we have resource mobilization theory. This theory emphasizes the importance of resources in the success of a social movement. So, basically this resource mobilization theory helps us understand that how a particular social movement can lead to become a successful social movement. These resources can be tangible like funding and infrastructure or intangible like organizational skills and networks. So, basically this theory tells that if a certain social movement have the available resources it can become more successful like it has adequate funding available to gather people for the common good or for the shared cause and particular infrastructure as well. If they can have the better communication mechanism and if they can sustain that social movement because of the availability of infrastructure, that social movement can become more successful as compared to those movements who lack the funding as well as infrastructure. Then we have the political process theory which proposes that the political opportunities in indigenous organizational strengths and shared cognitions among the movements proponents play a significant role in the rise of the outcome of the social movement. So, the movements which are backed by the political powers can also become the successful social movements. For example, the anti-apartheid movement in South Africa they were the shift in the international political climate and if you observe the history had they not been the political back of the international powers that apartheid movement would not have been that quickly successful and the strong internal organization and shared consciousness against the racial segregation facilitated that movement success. Then we have the new social movement theory that posits that the new social movements are more about the quality of life identity and human rights as compared to the conventional movements which were merely talking about the economic or political inequalities. The environmental movement for example, which is for sustainable development and the prevalent which are prevalent globally can be seen from this perspective. Then we have the framing perspective which views the social movements as signifying the struggles over the production of mobilizing and counter mobilizing ideas and meanings. The movement success depends on how effectively it can frame or construct the meaning around the issue. Basically, when a social movement arises it depends that how that social movement using different symbols and meanings can communicate or can better communicate their agenda to the public so that the public could develop a consensus a shared consensus to become part of that social movement and for that they need to frame that agenda in a very particular way in a way in such a way that it could mobilize the masses. For instance, the global movements against the climate change have effectively used the framing to emphasize the urgent need for action and challenging the complacency and advocating for the sustainable practices. Pakistani society too witness the diverse social movements. For instance, the teachers and doctors movements in Pakistan with the educators and medical practitioners protects it for the better pay and better working conditions and it can be understood from the deprivation theories perspective. While the successful anti polio campaign with the help of local health workers and global health organizations showcases the resource mobilization theory. So, by applying these theories we can better understand that how these movements have been framed and how these movements have been reflecting the relative deprivation and by applying that sociological lens we can better interpret and predict the success or failure of such social movements. So, these different perspectives with their unique emphasis and insights contribute to a more comprehensive understanding of social movements and their role in societal change.


So, if I feel an overwhelming force, then I need to go indirect force, or Gan Zip King, because now his force is redirected and now I am attacking him on an angle. So this is very simple. You want to go on an angle, just like in boxing, right? I want to go on the angle so I can get these shots in, right? I can go on the angle so I can get these shots, right?  But he's got less defense when it's on an angle, even less defense when I'm behind him. The key concept is to have indirect force. Instead of matching somebody's force with force, we want to redirect the force or get out of the way so that we can attack on an angle. So that's indirect force, indirect energy, or Gan Zip King. Let's move on to the next one.


Richard Sherman has signed with the Tampa Bay Buccaneers for $2.25 million this year. They were able to make room by somehow navigating the salary cap gymnastics better than anybody else with a man named Mike Greenberg, still being able to have $2.25 million at this stage to pay Richard Sherman a solid deal as Rappaport is put it, which I think we all can say week four. Richard Sherman with what happened this off season, not being in a training camp, getting a $2.25 million deal from the reigning Super Bowl champions. This is best case scenario for Richard Sherman. I think the Tampa Bay Buccaneers who need some help on the back end are probably very excited about this as well. Happy Richard Sherman has obviously passed whatever he was going through that we all publicly documented and saw. Happy's back in the league, the league's better with a minute.


Hello, brave and beautiful souls, welcome back to Art of Awakening. This is Ona, and today's message is a little bit unusual because I'm recording this in order to answer a question that a viewer posed in a comment on one of my recent videos. And the question is, are archons real? That's A-R-C-H-O-N-S. And this really caused me to delve into gnostic myth as well as spiritual law. And I'm going to be sharing some of that and some downloads I've received recently around truth and belief. And I think there's definitely some synchronicity at play and the timing of this question along with those downloads. So I'm excited to bring this to you, but I'm also wanting, because this actually also delves into the nature of evil a little bit. There's a reason I'm sitting here in front of this waterfall. It's like my guidance was like, okay, we'll do this near running water. And I've brought some mugwort as an offering to the stream and to Mother Earth. And asking that any negative entities or anything like that, that they be cleansed and purified through this beautiful clear water, through this river and with the presence of Mother Earth and the water. Okay. So that said, this question, are archons real? First let's look at what are archons, okay? And this is something I wasn't actually really familiar with. So I did some research and it turns out it's a gnostic or at least I'm thinking that this is maybe what this person was asking about. There's a gnostic belief or a gnostic myth that stems from gnosticism. This is a branch of Christianity that was very, very early. And they had some very different ideas. And some of which resonate with me, some of which definitely don't, okay? So this is this gnostic creation myth that I was able to find. And in this creation myth, God sees himself reflected as in a mirror. And this gives rise to a feminine being who gives birth or gives rise to all these divine beings, okay, that are spring out of this union between God and this beautiful divine feminine. And so these beings are holy beings and in the beginning there's just this, basically it's heaven, it's fulfillment, it's this divine place that these beings are coming out of and Christ comes out of it and all these things. So most of these beings come forward in pairs, in masculine feminine pairs and they are things like truth and will and wisdom. So the youngest of them, wisdom, decides that she wants to conceive just on her own. And so she gives, she does and she gives birth to an abomination, right? And his name is Yalda Baoth or Samuel. And then once she gives birth to him and realizes that he's really deformed, she rejects him, tosses him away and he goes on to create the world, the material world along with humans but somehow a divine spark gets caught in the humans, okay? So the humans turn out to be having a divine spark. And so Yalda Baoth gives rise to 12 archons which are demonic beings that are, they, Gnostics believed to rule the earth and eventually these archons multiply into 365 archons, one for every day of the year and these are these demon beings that are kind of ruling the world according to the Gnostics. Okay, so first of all, I just found this creation with very, very interesting because it embodies this idea that the earth was created in sin, that the earth was, is actually an unholy thing like the material world, which actually to me really flies in the face of what I feel to be true and I feel the earth, it feels so wonderful, right? It's as if you feel the love of Mother Earth, it also flies in the face of every indigenous culture that I've ever been aware of, you know, where the knowledge is that the earth is this beautiful, its creation is divine. But, you know, where does this come from? I don't know but I find it interesting because there are certain things in Gnosticism that actually really do resonate with me so I wanted to kind of delve into that and I've got some ideas around this which I'm going to share in a little bit but as I mentioned I've had a few downloads recently and they're all around the power of belief and the nature of truth and I'm going to write them all up into a blog so if you want to really delve into and see the exact wording that came through for me you can do that, the link is going to be in the description below. But basically what my guidance is telling me is that the world is made of love, is created of love and that this is a fundamental truth. They say that you may question this but we don't recommend it because such questioning leads to suffering and will ultimately bring you to a dead end. But they say if you will assume the truth of this, choose to choose this truth over another then you will begin to change the world through your beliefs. And they go on, there's a whole lot that they told me about the value of questioning so do check that out if you want. But the main idea here that I want to bring forward is that we create the world through our beliefs but they're saying truth is what you choose it to be and by this they distinguish between little case truth and uppercase truth. So truth is what you choose it to be. What makes one concept truth and another not is that truth with a capital T and another not is that universal truth, universal choosing of higher truth will ultimately result in sustained harmonious life while an agreement to choose a truth that's not aligned with the will of universal mind results in eventual termination of that line of inquiry including any manifestations stemming from it. So in the larger picture only those truths aligned with universal mind are in actuality truth. So this gets a little convoluted but the basic idea is that we are creator beings. We're created in the image of the great creator and that you can think of the great creator as sort of like the master of the studio or the master scientist running the lab and we as smaller beings are actually just creating little bits to go into the master creation and that we can only deal with small bits at a time. They say in the smaller picture you're allowed to choose alternate scenarios which in your belief you endow with truth and begin to manifest as true. So when you have a deeply held belief you endow it with truth and it will start to manifest. However, non aligned truths if these what you take is true and you start to work on that through your beliefs if that's not aligned with the higher truth with higher will with higher divine consciousness it's going to result in miscreation. Which ultimately is either going to lead to termination or you die out or the choosing of more aligned truth. Now let's look at a couple of the spiritual laws. One is the law of mentalism which is the universal the law of universal oneness right and this is that all everything that is is part of universal consciousness right so that ultimately if you're taking the big big big picture it's all one and so it's like it's up to you to decide well is that good or not right. Like typically I think most people will agree that the oneness is good it creates everything. You can put your own spin on that though. The other one that I want to bring forward is the law of relativity and this states that if you take any piece of reality any piece of creation you can't really make any judgment about this you can't really you know really say anything about it unless and until you put it in relationship to other things you can only really judge something through its relationship. Okay so let's take a look at nature because nature is really the ultimate teacher as in my mind and take a look for example if you take a wolf for example and you look at it from the point of view its relationship with the deer from the deer's point of view a wolf is going to appear evil right and it is it's a source of destruction and pain and suffering but if you take the higher perspective and look at wolf in terms of its relationship to its entire ecosystem you get a whole different picture and in fact if you take the wolf and look at it as its relationship to deer the whole herd of deer the whole species of deer it's actually benevolent right so just kind of keep these things in mind now let's look back again at this idea of archons right so what I want to look at is like okay where did this idea come from and what if this idea of the world as a as an unholy place was actually an allegory within an allegory what if you were looking at it as the world that humans are creating the world as filtered through human belief and what's manifesting out of that okay through egoic belief and the world that is being created there's a lot of miscreation happening I think we can all agree that if you you know from just like I don't have to name them but all the egregious things that are taking place have taken place on planet earth no wonder somebody could look at that and say hey the world's you know an evil place I don't believe the that it's intrinsic in the world I believe the world is divinely created but we are also you know creators in our own right and we are morphing and changing you know the world according to our beliefs so what if that gnostic concept of the world was just an illustration of what happens when we are creating the world through our ego right and then of course you're going to have nature has destructive forces nature has things like large predators and destructive winds and floods and all the stuff it's also got the divas of these things it's got the the spirits there are spirits out there that you know are can be destructive and what if as humans begin to become aware of these in the absence of being able to see the higher picture you know what if human being started to pass judgment on these as evil okay they're they're bringing into play a belief in evil there and as they begin to really you know focus on these things I saw a video recently of a deer a doe who this is a wet a trail cam video and she saw a hawk chasing a rabbit and she went and chased down that hawk and stomped it to death and like she was relentless she she would circle around and stomp and stomp and stomp and it must have been 10 to about a million times over by the time she was done and this is what the human ego will do it will really really stomp on things and and and focus the human ego ego will focus on problems it will focus on things that it considers evil and focus and focus and focus well if these are forces of nature you you can't destroy them right and so the all the focus does is give power to it because the more you focus your energy on something the more you feed into it right so if humans are doing this and you know we're actually taking energies that are naturally existent in harmony in nature and we're feeding negative power into them well why wouldn't they grow into something like an archon some kind of demonic being right why wouldn't they and so maybe we've created a world in which we've given power to our concept of evil what would happen if we change those beliefs what would happen if we took the higher perspective and said hey you know the things that are happening to us the things that are not not pleasant the things that are painful the things that appear destructive what if those are here to teach us and what if those were just here to to maintain some kind of harmony or order even as strange as we can't even understand it from where we're at but from the higher perspective what if it all fits into the pattern what if we started taking our focus off of that and started putting our focus on to the beauty and feeding into that what kind of a world would we be creating them what kind of a world can we create if we stop giving power to evil and begin to feed our power into the beautiful into love and joy and grace and harmony and peace and human oneness what would that world look like okay so uh i think this kind of was a long convoluted conversation i hope that it starts a process of inquiry within you remember that like you don't have to believe anything that i've just said anything right i really hope that you find your own beliefs and go with what you feel is the truth within you and may that truth bring you somewhere beautiful um if you're if you would be interested in learning more about the 12 spiritual laws i i have i will be giving a workshop on that it will be either you know free by donation whichever works for you that link is going to be in the description box below and we'll be discussing the 12 spiritual laws why they're so important right now especially for star seeds and light workers at this time of great awakening and how you can actually use that those 12 spiritual principles to create a beautiful world until so you can sign up by following the link below and if you haven't liked or subscribed yet this is a great time to subscribe there's going to be more coming of channel material and more probably about the spiritual laws as well um so i wish you all love all happiness all joy all peace all grace see you soon and remember that you were born to be free