Okay, it's four after I think we can probably get started. So, thanks everybody for joining the senior working group meeting meet every Monday 1600 UTC. In case you missed it there's a link to the meeting minutes in the chat if you can just add your name. That would be great. And then before we get started is there anything that anyone would like to add the add to the agenda. I think I think we can probably jump right in then. Yeah, I'll just, can I add in a very small thing to agenda just a quick update on the network orchestration task force. Sure. Do you do you mind if I add it here do you want to have it at the beginning. Do you want to do it now or later. Not your choice. Okay, you can go first if you want. Okay, sure. So, some of you, maybe even all of you if I'm looking at the list here know but there's a, there's a new slack channel on CNCF called Tug networking orchestration. The discussions have been in the context of the tug, but it was clear that you know there's a lot of overlap both in things people work on and the people themselves. And I think after a fruitful conversation we decided that best place to start to work would be under the CNF working group with its governance. So yeah, I had a personal meeting with Taylor and we worked some stuff out and hopefully this week I'll have time to really flesh it out on the GitHub repo and we can start to work so not a lot to say today other than that. And maybe the next CNF work group I might have something more to add to the agenda and get into more details. But for now probably the best way to continue working is on slack. I know slack isn't accessible to absolutely everybody so if you if slack isn't great for you and you do want to be involved. Please let me know and I'll try to figure out some way to to include you. It has to be inclusive not exclusive. That's it. I'll go a little bit to that towel. And Bill, could I share my screen real quick. Absolutely. Let's see. All right. So the main thing that we were trying to work on was breaking down. What are all the different parts of what we want to accomplish across in the orchestration but then looking at all the different groups. As far as what you could do getting started we think the requirements definitions and gap analysis or in scope for the CNF working group. And we're talking about either current or new Kubernetes technology and past and current non Kubernetes so that would be thinking anything outside. We could say legacy but not all of it there's new stuff happening. And then specifically like presenting solutions. These could be maybe outside maybe inside of the CNF work group some of it could be the telecom user group. But the parts that we think we could get started immediately as far as the GitHub repo for CNF working group would be around requirements definitions and gap analysis. We broke a lot of this down. I'm not going to go through all of it. That'll be something I think you'll see as we move forward. But that's would be the main areas and towel and would you agree that kind of covers what the highlights at the top. Yeah, absolutely. The reason I didn't want to get into the details of this is that this could easily take the whole agenda so it's a starting point I'll I'll put something on the slack maybe hopefully this week more people can look at this provide feedback and maybe next work group meeting we could do something more productive. Yeah, this is this is I think a really great opening shot. And I think, you know, I treat these things as buckets of work where I think many different people in the group can contribute so I'm optimistic I think this could be a very productive endeavor. Absolutely. And that's the idea that we're trying to do with on the how the structuring specifically on CNF working group but ideally any of the different groups, wherever you're passionate about working. Hopefully you find a place, you can just focus, you will not just focus but you can focus on that and not think that you need to cover all the things. So the different buckets.  Thanks Taylor and thanks tell. So, looking forward to the PR so they're going to be incoming and if you want to dive more into the networking orchestration task force, join the slack the link is here or reach out to tell directly. And I think his email is here. If you want to reach out to him. So, thank you. One is this pull request from Taylor, adding a code of conduct. So, essentially, this is just saying that the CNF working group will follow the CNCF code of conduct. In other words, unless anybody has any major objections to this I think we can probably merge this as everyone has agreed so far. Any last objections. Okay, great. So now we have a code of conduct. Perfect so thanks for that Taylor. The next one is from Ruben is he on the call today. I don't see him on the call today, but essentially, what this pull request is is in the charter also adding for operations of CNF, adding out the life cycle management component. So instead of just deploying and managing really looking at the whole life cycle management so deployment configuration management upgrade. So last week, I think there's quite a few approvals here unless there's any last objections on this call, also merge this to know three to one. Okay. Great so thanks everybody who took the time to review that to the next one I'd like to point out as Taylor said earlier there's multiple ways to get involved in the project. Beyond just some of the core stuff and so part of it is to create a contributing document and I know Taylor has started doing this but if there's anybody that's interested in working on this with him I mark this as a good first issue. So anybody wants to raise their hand on the call, or anything else you can do that now or look into it later so I'll just see if anybody's interested in adding the name now. You can also add your name later. So there, otherwise, I know Taylor is putting something together right now. So, okay. Last week, we talked a little bit, just like as a refresher is that we need to update the template around the user stories that the user stories should not be marked optional. I mean, if there's none you should start a GitHub discussion caveat shouldn't be optional and there's and it should be renamed to trade offs. And so, thanks to Watson he's made a pull request here, just giving these updates, essentially so the pull request is linked here. Just essentially. So, changing user stories from optional since that's going to be a category for us changing notes to trade off constraints and like caveats. Yeah, I think it's a pretty straightforward small pull request so if anybody. I know this is just committed three hours ago. So I'll leave it up for another week but if anybody wants to review it or wants me to add them now as a reviewer, I can do that. You can put my name there. Thanks and also Robbie said in the chat so thank you. Okay so I added both of you as reviewers and obviously anybody is free to review it. Thanks we'll leave that one open for now but I think we can probably get that merged easily next by next week it's pretty small change. The next one. Also I just want to take pauses anybody have any questions on what we've done so far. Then the next one is creating templates for use cases. So, just as a reminder last week we merged in the, the kind of, you can think of like the table of contents for the use cases document and one of the comments there is that we should have a template for use cases, and this is kind of the discussion out of there. What else is looking for a good first issue to jump in on is to create like a template for these use cases. If anybody wants to raise their hand right now in the meeting, I'm happy to assign you, or people can self assign after the meeting to build a book is speaking, I could take that one. Okay, what are use cases. Okay. Great thanks book. So, you have been assigned and looking forward to the forecast on that one. Unless, is there anything you want to discuss about it right now are you happy to go off and just kind of create an initial template and then have. I'll create initial draft template based on some ideas and practice. I use them in and will create a merge request to be reviewed and discussed. Okay. That's fine. Awesome. Thank you very much. I follow up on the template. If, if before we have a template decided on if you have a use a use case or a user story which is higher level. That you want to talk about then feel free to create a discussion. You don't have to wait for some having a bunch of content we can add a new discussion or add to the discussion list, just the idea. Yeah. And maybe that's a good time. I'll actually go a little bit out of order here is actually to go to the BGP use case, because this is one of the use case. So if is Ian on the call. I am yes. I'm not by the way terribly proud of this I wrote it in an hour this morning and got up especially early so it was ready for you but to. Yeah, I mean it's a beginning at least. So it was one example. I've seen this before. And the reason I've used this specific example is because it requires a second VRF on the network, which highlights a shortcoming that we run into. So it's just an example of how I might put a BGP speaker on and what I wanted to do is talk to my customers VPN network so a network that I have access to. But I don't want its manager to be on the customer network I want it to be managed independently. Tell us telling me off and not putting this in as a discussion and he's got a point, because it's as vague as anything and we don't have a use case template yet and I could probably have waited for that and done a better job of it. But the thing I was running into is it really did feel like it needed a document to discuss so that people could point to the document and say this is a thing I don't like very much about the way that this is put together. I'm quite happy to withdraw the call request if it turns out it's too early and it's the wrong thing to do, but for the time being I would at least give it once over and read it and see what you think. What I was trying to say with this as I say is here is a straightforward use case and again arguably not the right place for it here are set reasons why it's problematic as we stand where we find that we're getting into some difficulty, which again arguably isn't really correct for putting into a use case but I assume everybody that's seen it which probably about two people at this point appreciates that it's a reasonable problem description that it is a thing that does come up. Great, thank you for creating this. So, what do you mind if I, like, add you as a reviewer on here just that as they're going through and creating the template you can kind of see what you think is good what you think is missing and you I think you can kind of get a little bit on this kind of as a collaborate creating the template and actually having like a real use case. Yeah. So, it's a good to base it on some concrete content and then see what fits what doesn't fit. Yeah. Just to that concrete use case. I just want to mention, we have cases where we talk about seven VRFs to plump and so on so that's give a better example of this or a different example that comes from your perspective. I strongly encourage you to do that. I know for well we've got use cases where we want more than one VPN as well but they get more than one VRF, but they get complicated to explain so I thought I'd start with the simple one which points out a short coming. And then we can, you know, if we come up with a better, again, concrete example of it happening and why you would want to do it, then we can we can write another one as well. There's nothing wrong with one feature solving multiple use cases. I just wanted to mention that it is, it is reality and one aspect or one way to look at it is how can you resolve it on Kubernetes level. Another is what we are trying to do actually is how we can resolve it on data center fabric and integration of that fabric into into wide area network level. So that we offload everything to move everything from Kubernetes clusters into into the fabric as much as possible. But yeah, side comment only. No, I agree. Right. And again, well so that's that's where this document has a problem because one half of that is a use case and one half of that is implementation problems but I absolutely agree I see exactly the same short coming and it's a thing that I want to see fixed so anything that points in that direction is going to help us kind of flesh out what we would need to fix it. I think that's great. Ian, would you mind trying to add this as a discussion with your slide with the diagram as well we don't have to close the pull request out but just duplicate it. I'm interested in seeing what it would look like with the diagram embedded. That's an interesting question. Let's see what happens. That diagram by the way I did it in draw.io and it's an editable draw.io diagram. It's SVG I'm sure it would work with PNG as well just think of it as another experiment. And the discussion forum can also link or the discussion topic could link to the pull request and then once you know if we get it merged then it can link to the document but the discussion might be an area to have like larger conversations about that document but keep it in the get repo. Cool. So thanks Ian for putting this together and I'm looking forward to seeing kind of like this first use case kind of come together and sparking some discussion around there. Then. Yeah. I have a question. What is the expectation on the use case. I'm asking because I'm at this point to be lost. It's to where to start if I wanted to submit one and exactly how what to draw out of that use case. I might have missed that from earlier meetings but I appreciate if maybe can explain again. I'm just asking what a use case should contain or what is the purpose that we're for the scene of working group what like why are we trying to have the use cases. Yes, that one more. I mean I understand why we do use case based right before the scene of working groups so the it ties back to. And so that right now the practice the focus is to get towards best practices or techniques. How are you going to utilize if you're on a Kubernetes based platform. Then how can you take advantage of service capabilities how are you going to have apps networking apps that can utilize maybe other networking applications so what are best practices and Kubernetes. We had talked about for the scene of working group, but if you don't have some type of real world context then it makes it difficult to even talk about those. So the idea with a use case I'm going to make it even simpler one then thank you and for doing the BGP we've been talking about it for months. And even simpler one would be like a bump in the wall firewall bump in the wire so you have a firewall. CNF that's just sitting there and that one we could take and then break down what is the behavior and features it's small enough that we can talk about how we would expect it to act. If you're deploying it and break those features down to a point where we can say okay here's here's how we would expect to manage it from the life cycle management what are the different aspects.  Then what are some things that you could do to make it easier to develop and deploy like thinking from a developer standpoint. So that if we have the use case then we can analyze it and then start saying what are the things that we could do in Kubernetes that would be helpful. Okay. Of course, anything these use cases I think are going to be useful outside of that focus. You know, there's some things that may go this should go to the tag or we should go talk to the network plumbing group and then Kubernetes or some other sig, or the multi cluster whatever it may be within the CNF working group that would be the focus. What would you recommend in order to discuss that we don't necessarily going fully in for a pull request. I mean you were saying best is to start by the discussions right. I'd say it's how sure are you on what if there's you know and put something out and arguably it could go either way. I'd say with the amount of content that he has and we don't have a template. If you there's let's see there's one of them networking use cases and user stories right there. So this one. This is just a long list. Essentially, this is whatever idea that you have if you don't have enough content but you're like we should take a look at this then feel free to add it here. And then we can get started and then if you say I have a little bit of content, but I don't feel like I have enough to fully define it then maybe start a new discussion. And that way we can start adding more and more to it. And of course we can come back and talk about reference. And then if you feel like you have enough content, some diagrams, and there's enough content that we can actually examine, then that would be create a pull request. But if you're not sure just go with one and then we can talk about it. Where, wherever you think. Thanks for gently taking my hand. No problem. It's all new for all of us this area. Now this is all work in progress. I think we're trying to figure it out at the same time. So, Okay, we've done everything also above. The next thing that is quite exciting is the governance PR. So this is the different roles of people, because obviously Taylor and I have helped set this up, but we'd really like this to be the community Latin government initiative going forwards. So just to kind of give people a preview what this PR is is setting up basically the different roles so the chair is the technical leads and everyone else. So basically lays out what the chair the technical leads and what other people do. Yeah, I'm going to open this up for conversation. I know there's quite a few approvals already but if anybody wants to make any last comments on this or has anything else they'd like to add like please feel free to say it now. Okay, hearing nothing. I think it's time to merge this also. I think we've added this here and we discussed it. Unless anybody has any objections like I'd be fine with also committing this, rather than making it a separate PR. Unless anybody has really strong objections to that. Ian's just adding Cisco as one of the interested parties. So this is, yeah, I mean, I know it could be another poll request it just didn't seem particularly necessary and the list of companies there clearly Jeff and Daniel got to this first and so there are two. But I think the other thing is if there's anybody else who wants adding to this speak now or for her all your piece and then we can just basically alter this right this second. Yeah, so this is just a reminder, since as we are trying to set up kind of more formalized governance and everything. We'd like to go to the like the TOC or other groups and say, these are all the interested parties and this is like our governance just that we're kind of like a formal body, kind of in line with what everybody else in the ecosystem is doing and this is just one part of it so your company is interested please feel free to. Um, maybe quick question about this. Going back to the networking orchestration task force. If it will be under the CNF working group umbrella. Should it be formalized in some way regarding membership here as a tech lead or for a specific topic. I'm just not sure what what the best way to handle it would be. Bill. If you'll click on the other view, the little for the answer the diff do the other view. Yeah. Okay, and then this everyone else members. Yeah, there we go. So, I'd say for right now. Let's just keep it under this area. So there's essentially on all members. We can create other roles that aren't part of the charter. I don't think that we need to create defined charter roles for the task force right now. But we can just say we're, we have a task force that's looking into this within the group. Anyone that wants to do that. We say, okay, well, you know, tal right now you're. Helping to lead this task force and whoever else won't step up, but I would put that under that all members and that specifically that second bullet point under all members. We can have other roles, and they're just not a defined role in the charter. Yeah, I guess, yeah, I wasn't suggesting that we need additional roles I was wondering how it would fit in the roles. So I, you know, I'll step up if it's needed to become a tech lead or something else but I'm absolutely fine if it could be just in everyone else category for now. I don't think we need to define that and the tech lead. I mean it could very well be under there but you know if the goal is here soon we're going to request again some nominate self nominations are going to happen but that's tech lead for all of the CNF working group. I see and then versus the task force. I think that's clear. Okay, and just since we will be doing salt self nominations, I'm just gonna like quickly like skim to the different roles that people like are familiar with them. So the chairs is going to be three chairs one from the Kubernetes community one from the service provider, and one from the CNF developer. And just to note, like the primary role of chairs is to run the operations and governance of the groups that's like things like setting and just agendas, managing the discussions starting the scheduling for proposals asking new things and working with the tech leads to establish the roadmap, whereas the tech lead is really kind of the people that are experts in networking tacos Kubernetes and want to provide like the technical leadership to produce the outputs of the CNF working group. So it's kind of the divide between the two roles. And so the tech leads are really deeply diving into like the project. But also, I guess, going to the conversation we just had is that membership is self declared there's no membership requirements to be part of it and it's open public open working group so if you want to contribute you can maybe be in one of these roles to contribute so you don't feel like if I don't get one of these roles, I, there's no place for me in the CNF working group it's absolutely open to everyone. And so, these are just a little providing a little bit structure but not, they're not the only ways that you can work within this group. So there's no further discussion on merge these and then what's going to happen after this is, we're going to come up with a voting PR just that there's a structure around how our voting and in the meantime will have a self nomination period. And so, this will be opened on the mailing list so anybody can nominate them there'll be a little bit of a structure saying like who you are, what you're nominating yourself for, and it'll be open until March 1. And then we'll probably have. Sorry, a voting period for two weeks after that so we expect to have our new governance team by mid March. Bill. Yes, what mailing list. The CNF working group mailing list. Taylor do you have a link to that off the top of your head. I'm just thinking if we have a mailing list, they probably ought to be at the top of this document just to make that it should be in the read me. Good catch. We will. I'll drop it at the top. Yeah, I think it is in the main read me you're right. It's right here, but also added in the meeting notes to sorry. Part of that I encourage you to join it. If you have any problems joining like please feel free to reach out to me. Obviously. Yeah, so that's kind of the rough timeline does anybody have any questions about that. Okay, so look forward to that PR and email coming in later this week. I have 23 minutes left. I just wanted to. I didn't have a ton of time to like prep but in case anybody wanted to dive into any of the discussions I see in. Thank you for adding the discussion so quickly. And Taylor I guess this is how it looks in the discussion in case you're wondering. Is there any discussion topics that somebody wanted to talk or is there anything that I missed on the agenda. Otherwise we can also end the meeting early. So actually, let me let me talk about that pull request because one thing did come up when I put it in. I mean discussion pull request doesn't really matter how you put it. We've got template. The template's not finished so it's not committed to the template but I think it did tell me a couple of things about how we should be putting it together if. Yeah, and I put a get ignoring because you know we need to get ignore but setting aside the one thing I found myself doing here and I don't know that's the right thing or not is the use case and this is a use case because it's not describing a function not a person's behavior. It basically highlights a bunch of shortcomings that I've expressed in terms of if I deployed Kubernetes out the box with the CNI. These are the things I would struggle to do. I don't know whether that's the right place to put it or not did anyone have any thoughts on how we might want to organize this seems like it's a good thing to put in, but it's not technically the use case. Anything if if you feel like it's additional reference material you could always add a section for additional context. Yeah. The thing is it seems like it's the thing you want in the main document in the sense of you really do want someone to basically read this as they're reading the document as well not just read the document go away happy. It's all going to work, but you know, and there's two parts to that one is it could potentially change over time if Kubernetes get better. The other is, if we're measuring this up against a platform definition of some variety, then if our platform definition changes if we say well our platform is not base Kubernetes obviously it's based Kubernetes plus these features, then that would change the change the results slightly. I don't know. I'm, I'm asking I don't have a great answer to this one but it's it's really a question on, you know, requirements design split so here's a use case and the use case raises a bunch of work items or a bunch of issues however you like to define it right well if no one's got comment then it will stay as it is for the time being and we will work on the assumption that that's the right thing to do. If anyone wants to pick on that then again there is both a discussion and a pull request. You can you can put your thoughts in there later and we'll decide how to how to react. So, thanks for that and obviously, as Ian said, there's the discussion on the pull request so add your thoughts. Is there anything anybody else wants to go over today. Otherwise, I think we can all have 20 minutes back. So, thanks everyone for joining today. Cheers. Cheers by everyone. Thanks everyone.


Hi, Professor Gerald Friedman, Department of Economics, University of Massachusetts, Amherst. And we here today talk about how we measure success in the economy. What does it mean to have a successful economy? In the orthodox world, which extends to the Economist Magazine, the Wall Street Journal, the New York Times, to some extent to the United Nations, Federal Reserve, TV News, most of the blogosphere, success is measured by the gross domestic product, the sum total of how much we produce and market, which is different than how much we produce. But the gross domestic product is some total of stuff that goes through markets. You take that number, which in the United States right now was $1 trillion, you divide it by the population, and you have per capita income. How much the average, if we divided it evenly, the average person would have of market transactions. And that number in the United States comes to $45,000 or so per person. And on that basis, we say we're a success. France is $34,000 a person. Greece is $25,000 a person. Mexico is $20,000 or so. So we're better than them. We're number one. Well, actually, we're not like number five, but close enough. Now, this measure is so flawed that, well, let's just say that one of the founders of the gross domestic product, Simon Kuznitz, wrote long essays about how bad it is as a measure of actual well-being. And in fact, if you look across the world at happiness studies, if you ask people how happy they are, richer countries are associated with greater happiness, but only up to about $20,000. Really poor countries, countries that have very little market activity, they really are sad. They're unhappy people. They have short life expectancies, and they're unhappy. But when you get to about $20,000 per capita income, where the United States was in, say, 1950, that's about where happiness peaks. After that, it's not clear that greater income leads to any greater happiness. In some countries it does, other countries it doesn't, but no systematic effect. This is because the gross domestic product is such a flawed measure.  As I said, it doesn't take all production. It only takes production that goes through the market. It doesn't take home production. It doesn't take taking care of your sick grandmother. It doesn't count the community. Standing around chatting with your neighbor doesn't take care of friendship, of course. It doesn't take care of environmental degradation. On the contrary, paying to clean up the environment may lead to a higher GDP. Polluting the environment doesn't do anything. Military spending counts doesn't make us happy. If you get robbed and then go out and buy a new camera, it's the GDP. Doesn't make you any happier. Makes you a lot less happy. Spending money on hiring people to protect your stuff because you were robbed makes you unhappy because you have to have these security people around, but it adds to GDP. So gross domestic product is not a good measure. Now, this matters because capitalist firms are organized to increase the gross domestic product. That's what they do. I mean, it's not their goal. Their goal is to make profit. But the way they make profit is by producing more stuff in the marketplace. And that's the gross domestic product. They don't care if they pollute unless the government catches them or something. They don't care if they're making tanks, bombs, poison gas, or life-saving pharmaceuticals. They don't care just so they make profit. They'll produce stuff and they'll increase the GDP. They'll use up the environment.  They'll make it impossible for you to talk to your neighbors. They don't care. But they will increase the GDP. Work at co-ops are different, however. Because work at co-op, the work of cooperators, the people who work in the co-op, live in the community. Therefore, there's a natural tendency on the part of co-operators, worker cooperatives, workers working in a cooperative setting, to organize their firms' goals to promote other things than just increasing GDP, other things that people like. Because people in a co-op live in the community, they care about the environment. They care about whether the company is organized in a way that allows neighbors to talk to each other. Or if it runs its plants so loud and so stinky that nobody can stand around on the sidewalks. So a cooperative, while it may increase GDP, because it tries to produce stuff to sale, it may also, more than capitalist firms, concern itself with the environment, with the neighborhood, with the safety and welfare of the community in other dimensions than just the gross domestic product. So thank you very much. And have a nice day. Bye-bye.


That one for rope! Rope! We're going to run over here. You don't want any, you know, stick in there. If you don't want any prigs or branches swinging back. And then every half an hour from what we've got in the park. So, obviously like if you're down in a valley or in a creek. Okay, if you find yourself near an off-camp road.  Do you want a black one for that, or is it working? I think it's working. From here, 75 meters, 75 to 100 meters, go in line, and then just push, push right.


Welcome back to our lecture series Math 1060, Trigonometry for Students at Southern Utah University. As usual, I'll be your professor today, Dr. Andrew Misseldine. In lecture 10, we're going to start talking about transforming trigonometric graphs. In this lecture and the next one, we're going to focus exclusively on the graphs of sine and cosine. But in the one after those, we're going to talk about transforming the other trigonometric functions. The transformations are going to be basically the same, but sine and cosine are a good place to start on these transformations. So we want to talk a little bit about general transformations of functions and see specifically how they affect sine and cosine when we transform these things. And so the first type of transformation we're going to talk about in this video is the idea of stretching and compressing a graph. And there's two types of stretches we have to talk about, a vertical stretch and a horizontal stretch. So in general principles, imagine f is a function and we have some positive real numbers c. And for the sake of this example, let's say that c is greater than one. It's like two, three pi, something like that. If you have a function, you have your function y equals f of x. If you put a coefficient of c in front of the function, this has the effect of it vertically stretching the graph by a factor of c. So if I were to illustrate this real quick, what we mean is here's our x-axis right there. And so we have some function. You know, it's something like this maybe. If we vertically stretch it by a factor of c, what it means is that the parts above the x-axis will get elongated and by a factor of c. So it's gonna get steeper. And the stuff that's below the x-axis will also get elongated. It gets stretched out by again that factor of c. So we get that thing stretched out. So this graph right here is y equals c f of x. While the original one was just y equals f of x. You don't have the c in there. So things, it vertically stretched the graph. If you put that c in front. Now that's if you have a number larger than one. If the number in front of the function is less than one, that actually causes it to be a horizontal compression. That is, things maybe get flatter. Maybe something like this. They get squished. So you might get something like y equals one over c f of x because if the number is less than one, then it's reciprocal be greater than one. Oh, I couldn't hold it in. I'm sorry. We'll start again in three, two, one. So a coefficient in front of the function causes it to either be stretched or compressed vertically. What if you put a number, I might not do that one here. All right, we'll come back to that one. So start again in three, two, one. So let's see how this would affect your typical sinusoidal wave. That is, if we were to look at sine or cosine. So if we look at the graph y equals two sine of x, let's sketch its graph just on a typical period from zero to two pi. So you see illustrated on the screen in yellow, just a typical sine wave, just this friend right here. And we're just doing the standard period as we go from x equals zero to x equals pi right here. Remember that the x intercepts of sine are gonna be zero pi and two pi, the maximum's obtained at pi halves and the minimum's obtained at three pi halves. These five points coincide with the quadrantal angles that is thinking of the unit circle. These are the four places, well, five places because we repeat the first and last one. These are the five places where the x and y axis intersect the unit circle at zero, at pi halves, at pi, at three pi halves, at two pi. So when we graph a trigonometric function, we transform it, we are very interested in what happens to these five points. Well, if you consider the graph of y equals two sine of x, the fact that there's a coefficient of two in front of it means that the graph has been vertically stretched by a factor of two. All of the y-coordinates are now double. Well, if you take an x intercept, if you double that, so for an x intercept, the y-coordinate is zero, if you double that, it's still zero. So x intercepts are not affected by vertical stretching, but this maximum value is what was y equals one will get doubled to y equals two. And what was y, it was equal to negative one, doubles to be y equals negative one. And if we connect those dots in the usual sine wave fashion, you get this graph right here. So y equals two sine of x is gonna be just a sine wave where the amplitude has now been doubled. The amplitude of this function is now equal to two. So we see that the humps here and the trough of the sine wave are now larger because the amplitude was increased. Another example, let's sketch the graph of y equals one half cosine of x. And again, we'll do this on the standard period, zero to two pi. So you see here illustrated in yellow the standard cosine wave. Remember the main difference between sine and cosine is that cosine starts at its maximum while sine would start at the origin. So we have our standard cosine wave. Look at the five critical points there, the five quadrental points. You have zero, pi halves, pi, three pi halves and two pi. For the standard cosine function, you get one, zero, negative one, zero and then one again. What we're gonna do is we're gonna cut each and every one of these in half. So the y value of one drops down to one half. Zero stays zero because the x intercepts are not affected by stretching. Negative one is gonna then drop down to be negative one half. Zero stays put and then the one goes back down to one half. And if we connect those dots, whoops, if you connect those dots like so, we then see that our cosine wave looks like it's been compressed because its amplitude has been changed. We get that the amplitude of this cosine wave is gonna be one half and we see that by looking at the coefficient in front of the cosine wave. And this principle is very much in general. If we have a coefficient in front of sine or cosine that's positive, that coefficient is the amplitude. So y equals a sine of x or y equals a cosine of x, a is the amplitude in that situation, meaning that the range of the sine or cosine wave will be negative a to a. But that's if a is positive. What if a is negative? What if you have a negative coefficient in front? Well, it's just a simple reminder that if you take y equals negative f of x, putting a negative sine in front of the function has the effect of reflecting the graph across the x-axis. So you take your graph and you reflect it across the x-axis. That's what that negative sign does. That's not gonna affect the amplitude because the amplitude is always a positive number. So if you were to look at the function y equals negative cosine of x, the fact they have a negative sign in there means you're going to reflect, you're gonna reflect across the x-axis. That's how that should be interpreted and it doesn't affect the amplitude. The amplitude in the situation would still be one.  This time, let's actually graph three periods of the graph. We go from negative two pi to four pi. Let's think of the standard cosine, which you can see right here again. Just like on our last example, this is standard cosine. Well, if we reflect this across the x-axis, we should end up with this picture right here. Right? Still going. So instead of one, we're now at negative one. Zero's unaffected by stretching or reflection. One, y equals one that becomes, excuse me, y equals negative one then becomes a positive one right there. Zero's unaffected and then a positive one switches over to negative one. You have those five points in consideration right there. So let's look at them again. Negative one, zero, one, zero, negative one. It's now the reflection of what you see before. And so that's one period of the graph. Just copy it for the other side. So as we go from zero to two pi, we can copy that to go from two pi to four pi. And we can copy that as we go from negative two pi to zero, like so. And we can draw this picture as large or as small as it needs to be.


The study found that primary health care professionals had a high prevalence of common mental disorder symptoms, which were associated with previous and current symptoms of mental disorders as well as work overload during the COVID-19 pandemic. This article was authored by Fabricio Emanuel Sores to Oliveira, Samuel Trezina, Veronica Oliveira Diaz and others.


We're from the Berkley Student Cooperative. We've partnered with the City of Berkley and the Chancellor's Office at UC Berkley to get a grant to do this helping seniors in their homes project. Garden work, yard work, painting, decluttering in their homes, things that students are able to do, but that seniors might not have the physicality to do anymore. It really beats spending the weekends in the library, you know? Like actually getting out and being active and doing something good. It feels good. Being an international student, I think this adds an extra layer to my experience. It allows me to meet people I wouldn't normally be able to meet, and they're parts of like Berkley American culture that I wouldn't be able to see just living in a co-op. There's a learning opportunity to get to meet with the seniors and forge a relationship with seniors in town. It's really a bonding experience for everyone involved. We've probably served upwards of 20-22 seniors already, and we've only been fully running the program for about a month and a half. I feel great about this. Now I can plant, which I do every year. I like to stay in this house forever until I die. I couldn't do it without this help.


Hi everyone, welcome back to my channel and happy Pride Month. Today I'm coming at you with one of my five book recommendation videos, Pride Edition. So for those of you who don't know, I have a video series here on my channel where I do five book recommendations for different types of books. I have five book recommendation videos for literary fiction, classics, poetry, fantasy, non-fiction, children's fiction, a bunch. If you want to go and check out the playlist with them all in, I will leave that linked around. As this video is in celebration of Pride Month, all of these book recommendations will be written by queer authors and or feature queer characters. I will be saying what kind of queer rep these books have in them as we go along. We have a range of books here from fiction to poetry, so let's get straight into the recommendations. So first book that I'm going to be recommending today is The Confession by Jesse Burton. This is a literary fiction novel that I absolutely adore. It was one of my favourite books of last year, and this one has lesbian rep. The story here follows two timelines. One of the timelines is in the 1980s when two young women fall in love and end up moving to Glamorous LA because one of the women is an author and her book is being made into a film. The other timeline is set three decades later when a woman is trying to find out what happened to her mother who abandoned her when she was a baby, and in order to do this she ends up working for and befriending an old reclusive novelist who was the last person to see her mum. This book is awesome. If you love books that focus on female protagonists and female relationships and female sexuality, then you will love this. The characters in here are so great. All of the main characters are so well drawn, so complex. I was totally convinced by them. Following Constantine in particular was so great because we got to see her when she was younger and when she was older, and I thought this was handled so well. She totally felt like the same person across the whole thing, but you could also see the ways in which she had changed and developed due to everything that had been thrown her way. All of the different relationships in here are handled brilliantly. They all feel so raw. Through them we explore themes of motherhood as well as self-identity and romantic love. The structuring in here is great. I loved following the multiple timelines and piecing everything together about these women's lives. This combined with the realistic, yet slightly mysterious plot definitely adds to this sense of intrigue throughout. It definitely keeps you turning the pages. And lastly, the writing is gorgeous. It leans toward being lyrical and descriptive, but it isn't overwritten. It perfectly supports her characters and her plot. Jesse Burton is one of the best novelist writing today, I believe, just for the way in which she's able to pitch everything so perfectly. She always just includes the right amount of this and the right amount of that to create the most satisfying, well-rounded stories. I can't recommend her more highly. The next book I'm going to recommend today is Clouds Cannot Cover Us by Jay Hume. This is a contemporary poetry collection I read recently and absolutely loved. You will hear me shouting about this poetry collection for more time yet to come, believe me. This collection details the experiences of Jay Hume as a transgender teenager growing up in Leicestershire in England. It looks at working-class families and school life and racism and sexism. I read that this collection was aimed primarily at teenagers and that the aim was to really talk about a lot of the issues that they face today, to not shy away from them, and to not talk down to the audience. I think this was certainly achieved here. These poems are powerful and unflinching. There is such raw honesty to all of the poems in here. Honestly, I was blown away by this collection. The style of poetry is very accessible, so if you haven't read much poetry before, I wouldn't let that put you off picking this up. Jay Hume makes it very easy for you to understand and to feel things from these poems. But while it was so accessible, this didn't result in it lacking in any depth. For me, there is tons to pick apart in these poems if you would like to. I found this to be just as layered and impressive as many other contemporary poetry collections I have read recently that are far better known. There was just such beauty and power in here. It definitely made me reflect. It made me feel a whole host of emotions. I haven't seen nearly enough people reading this collection. I don't know if I've even heard anybody talking about it on booktube, and this needs to change. I know that so many people would enjoy this collection. If you enjoy contemporary poetry at all, then give this a go.  Just please give this a go. You can thank me later. So now time for a classic. The next book that I'm going to be recommending is Morris by EM Forster.  It is a homage to same-sex love, which if it had been published at the time Forster had written it would probably have ended his career. The novel is set in the early 1900s and it follows the life of a young man named Morris who goes against many of the societal expectations placed upon him in relation to class and wealth and politics and love in order to be true to himself. So EM Forster is one of my favourite authors of all time. Howard's End is one of my favourite books ever, and I also love A Room With A View. So honestly it's no surprise that I'm managing to get in a recommendation for him wherever I can. But honestly I do think this one is really, really great and definitely worth trying if you're wanting to read some queer fiction that isn't contemporary. This is a relatively short novel. It is pretty easy to read. As always, EM Forster just ticks all of the boxes in this one. The prose is impeccable. The settings are so well realised. Everything is underpinned with really perceptive scathing social commentary. And of course his characters are so well thought through there is so much to them. The main characters in here aren't necessarily likeable, but they are certainly complex and seeing the different ways in which they both work through their own sexualities and their own self-discoveries is brilliant. So yes, if you're looking for a classic gay text then this one is for you. The next book that I want to recommend today is Radio Silence by Alice Oseman. This is an incredible YA novel. It is one of the best YA novels I have ever read and it has bisexual and demisexual main characters as well as lesbian and gay secondary characters. So in the novel we follow two 17-year-old British teenagers called Francis and Allid. Francis spends a lot of her time studying. She wants to get into Cambridge University and she has never really felt as though she fits in with her school friends. Allid is super quiet, no one really knows anything about him other than that he gets straight A's. And through this novel we get to see Francis and Allid make a podcast together and form a deeply caring and supportive platonic friendship.  At that age you are verging on adulthood, you may not know who you fully are yet, you've got tons of pressures put on you from loads of different places and this book captures that feeling so well. Alice Oseman is known for her brilliant characters and I certainly loved these ones. They were so interesting and dynamic and relatable. They actually felt like British teenagers who knew. The central friendship in here is probably one of the best I have ever read. As I mentioned previously there is a ton of sexuality rep in here but there are also characters of different gender identities and characters of different ethnic backgrounds.  And similarly the ways in which these characters socialise and the ways in which they use social media feels realistic. It isn't weird. Everything about this book just felt authentic and enjoyable to me. I would highly recommend it to anyone even if you aren't a big YA reader. It's honestly a breath of fresh air.  The final book that I want to recommend to you today is Don't Call Us Dead by Danez Smith. Danez Smith is one of the best contemporary poets I have come across in the past couple of years. They have written a couple of different collections now, both of which I love. This one feels particularly pertinent right now. It explores a ton of issues that are at the heart of modern day America. It explores themes of race and violence and sexuality and illness among others. So this collection is so unflinching when it comes to what it is to be a gay black man in America, what it is to be HIV positive, what it is to experience racism and police brutality. The poems paint such striking images. They really transport you to where Danez Smith is. Getting to second hand experience a lot of these things which I am probably never going to experience first hand is so important and I think it was achieved so powerfully through this medium. The technical craftsmanship in this poetry collection is also incredibly impressive. The language choices are gorgeous, the imagery is so vivid, the sounds and rhythms created in the poems just add so much more to what Danez Smith is saying. This collection took my breath away whilst I read it. It is truly stunning. It is full of intelligence and passion and rage and I think it's incredible. If you're looking for a poetry collection that's really going to hit you hard and make you stop and think then this is the one for you. So there we have it. Those are five of my book recommendations in celebration of Pride Month. I hope you enjoyed hearing about them. Please let me know if you've read any of them and of course please let me know some of your best Pride recommendations. I always love hearing your guys' recommendations so please let me know some down below. I really look forward to speaking to you all as always. I hope you're all doing well. Happy Pride once again and hopefully I will see you all soon in my next video. Bye everyone!


Hi, welcome to my talk and presentation on GitOps Kubernetes and SQL Management. I'm Karzena Malk. I work at CloudBees, most of the Jenkins X open source community. Jenkins X is a CI-CD platform on Kubernetes with GitOps built in and committed to facilitating GitOps best practices. In today's presentation on GitOps and SQL Management, we'll see the GitOps-based workflow the Jenkins X project creates for applications and see how Jenkins X manages Kubernetes SQL securely using Kubernetes external SQL. This talk follows on from a talk I did previously on GitOps, Kubernetes and SQL Management, which provided more context and discussion on the issues and tradeoffs with different approaches to SQL Management using Kubernetes and GitOps. So the previous talk, and there's a link in the slide, has a whole baking metaphor to introduce some of the concepts. There was also some information, but especially on the tradeoffs between the different SQL Management techniques when doing GitOps and Kubernetes. For this talk, I've kept the cake photos because they're pretty. But also this is a great week to celebrate. So enjoy a cake. In this talk, the focus is more on Jenkins X3 Alpha. During this talk and the brief presentation, we're going to discuss and see how Jenkins X3 guides you to set up your repositories to create a GitOps-based workflow and how Jenkins X handles secrets using Kubernetes external secrets. So first we'll briefly go over some of our terms and set a little bit of context in which we're considering this problem of SQL Management. And SQL Management is an issue across software development, but in this talk, we're looking at it in the context of GitOps and Kubernetes. First, why Git? It doesn't have to be Git, but Git is the most widely used version control system in the software industry today. Awesome side note. Git recently celebrated 15 years since its first release, hence the cake celebrating 15 years of Git. Happy birthday, Git. GitOps uses Git as the single source of truth for declarative infrastructure. And it now enables developers to manage infrastructure with the same Git-based workflows they use to manage a good base. This means all infrastructure configuration and application code are stored in Git repositories. Infrastructure as code isn't unique to GitOps, but it is foundation for GitOps. With GitOps, the entire state of your system is described using declarative specification for each environment, and these are stored in Git. A key part of GitOps is this idea of environments as code, describing your deployments declaratively using files such as Kubernetes manifests that are then stored in a Git repository. And this, having infrastructure config and deployments declaratively described in files in Git raises issues of secret management. And how Jing and Zex approach a secret management with GitOps and Kubernetes is a subject in the stock. So at this high level where we're at right now, your desired state of your system is declared in Git, and this is the single source of truth for your system when doing GitOps. So the other part of GitOps that's important to keep in mind is that you have to be able to observe the actual state of your system and reconcile that with the desired state of your system as described in Git. So Kubernetes helps a lot with this. It handles active reconciliation within your cluster. Kubernetes has been open sourced by Google and is now the most popular container orchestration system of that form. So you can do GitOps without Kubernetes. However, there are really natural fit together. With the deployment of declarative Kubernetes manifest files being controlled by Git operations. So Kubernetes deployments have the following properties which are really helpful. Automation. So Kubernetes automates the process of applying changes correctly and in a timely manner. Convergence. Kubernetes will keep trying to update until the update is successful. Item presence. Multiple applications of convergence have the same outcome. That is to say that the same actions can be done and will result in one single desired outcome. They are not cumulative. Just go to one state. So they can be applied multiple times without changing the result beyond that initial desired outcome. So when doing GitOps with Kubernetes, it is helpful to have a new GitOps Kubernetes operator which automatically ensures that the state of your cluster matches the config in Git. So the operator will pull the Git repo for changes or divergence between the desired and the actual state and will trigger deployments in Kubernetes to reconcile them. And make sure your new container images and config changes are propagated to the cluster. So when following the GitOps model, the desired configuration of your system is starting to get. So the GitOps Kubernetes operator software process, in our case, literally a Kubernetes operator is responsible for changing the currency of the system into designs to your system. So Jenkins X, of course, has a GitOps Kubernetes operator and the combination of GitOps methodology with Kubernetes declarative configuration and active reconciliation model combine to provide a number of operational benefits that all aim to produce and provide a more predictable and reliable system. Having all your configuration files version control in Git has many advantages, but securely managing secrets in such a system has been difficult. First, what are secrets? A secret is anything you want to tightly control access to. Kubernetes provides a mechanism allowing users to store bits of sensitive information into a protected resource object called the secret. So Kubernetes provides a built-in object for managing secrets called secret. Common examples of data you would want to store in a secret include username and password credentials, SSH keys, API keys, TLS, certificates. So here we have an example of a simple Kubernetes secret. It's a very simple data structure composed of three pieces of information. You have your name or your secret, the type of the secret, which is optional, and a map of field names to sensitive data encoded in base 64. So when you first see a Kubernetes secret, you may be tempted to think that the values are protected by encryption. They are not. Base 64 encoding allows binary data to be represented as a string format. It does not promote encryption. The base 64 encoding is like plain text. And here we can see those same secrets easily unencoded reading username. That's my join and password. Andi, think. You do not want your secrets laid out in Git. Okay. Git up spectators may be very happy to store configuration files in Git. They are unwilling to store their sensitive data in Git due to security concerns. There are additional reasons as to security concern to store secrets in Git. Git was designed as a collaborative tool. Making it easy for many people to view and review each other's code. Git is designed to enable access to other people's code. And for these reasons, it is very dangerous to use Git to hold secrets. We have no granular file level access controls in Git. So Git does not provide read protection of a sub path or a sub file in a Git repository. In other words, it is not possible to restrict access to some files in a Git repo and not others. And when dealing with secrets, you ideally should be granting access to secrets on a need-to-know basis. For example, if you have a temporary worker, you would want to give that new user the least amount of access to sensitive data as possible. Unfortunately, Git does not provide any way to do this. And this is an all or nothing when giving access to your repository. And distributed Git repos. So with GitOps, team members locally clone the Git repository on their laptops and workstations. This would mean the proliferation of the secrets to GitOps. So GitOps is one of many systems. Because opening up the attack surface. Our one rule for GitOps, Kubernetes and secret management is don't store Kubernetes secrets in Git. And especially don't store raw base 64 encoded Kubernetes secrets in Git. But we're trying to do GitOps. And there are, and we want to have the entire state of our system in Git. Luckily, there are a number of potential solutions. But unfortunately, they all come with trade-offs. So in this talk, I'll be focusing on the solution that Jenkins X has chosen to manage secrets with GitOps and Kubernetes. But if you wanted more of an overview of other solutions, potential solutions, then you can watch my previous talk. The Kubernetes secret object is convenient to use. It provides a declarative API that makes it easy for application pods to access secret data. And without any special code. So we do want to use Kubernetes secrets, but how do we do it skewed? And the approach that Jenkins X has chosen is to use external secret management system. These secret management systems may differ in future, but the general principles of that are the same. In this strategy, rather than using native Kubernetes features to store and load secrets securely into the container, the application containers themselves retrieve the secrets values dynamically at one time at the point of use. And this is what Kubernetes external secrets helps you with. So you don't have to write that code yourself because teams were doing that and it was taking up a lot of time to do it well because it's important to do it very quickly. Kubernetes external secrets is a very nice open source solution that works extremely well. And that is why Jenkins X is focusing on it. So luckily there's Kubernetes external secrets. And this has been open source by GoDaddy. Kubernetes external secrets enables the secure retrieval of secrets stored in external secret management systems and the ability to securely add secrets to your cluster. Look at how that's done. So the project extends the Kubernetes API by adding an external secret, secret objects using a custom resource definition and a controller to implement the behavior of the object itself. An external secret declares how to fetch the secret data while the controller is responsible for fetching that secret data from external providers and converting all external secrets to secrets. The conversion is completely transparent to pods that can access the secrets on one because of Kubernetes secrets. So Kubernetes external secrets supports the external secret management systems of all the major cloud providers and hash code vaults. The controller fetches the external secrets using the Kubernetes API. The controller uses external secrets to fetch that secret data from external secret management systems. And the controller upserts secrets. And then pods can access secrets normally. For Jenkins X, our number one main concern is we do not want to commit raw Kubernetes secrets to any external secret resources to get. And we highly recommend using Kubernetes external secrets. Which means you can check in the external secret resources into get. And we will see an example of that. And these are in a reference to the actual secret management values, the actual secret values that your secrets contain. Jenkins X supports the major external secret management providers to, that will then be holding like the single source of truth for that secret. The Jenkins X team are big fans of Kubernetes external secrets. And then we developed a JX secret, which is a small client tool for working with Kubernetes external secrets. And it integrates really nicely with the Jenkins X workflow for continuous delivery on Kubernetes. So Jenkins X has chosen a secret management approach that adds an abstraction layer above secret management solutions. All those external secret management systems. And this enables users to choose where the source of their secrets can be stored, preferably outside the Kubernetes cluster. And storing your secrets outside the Kubernetes cluster is a very good process for disaster recovery scenarios. We're now going to do a quick walkthrough on setting up Jenkins X3 Alpha, the get ops approach in Jenkins X3, and secret management using Kubernetes external secrets. This is the docs landing page for Jenkins X3 Alpha. As you can see, we have some easy to find top level guides and developer guides. In the administration section, we have links to a number of quick start get repositories. These are GitHub repository templates that make it easy to start when installing Jenkins X3. You choose one depending on the cluster you want to create, whether it's Google, Amazon, Azure, Minikube, OpenShift. For this demo, we'll use Google Cloud. And we'll use GKE in Terraform. So we click on the create get repository. And this brings us to a template to create our infrastructure repel. We'll name it JX3 Terraform in front. Make it private. This is just in case to accidentally check in any secrets. This should not happen, and secret management with Jenkins X helps that not happen. But just in case we'll make it private. The owner should be the GitHub org that you created for Jenkins X. And now you can see that repo being created within the GitHub org. Now what we're going to do is we're going to clone this infra repo. Great. Now we're going to clone that repo and CD into the clone. Now we'll create our cluster repository. Let's read the docs on how to create the cluster repository linked to from this button here. We create a cluster get repository choosing the desired secret store. Either Google secret manager or Vault. I'll use Google secret manager for this demo. And we'll use this link here. For this repo, this is our cluster repo of the Jenkins X3 GKE cluster. Again, set the owner to my GitHub org, making it private and creating our repository. Our last little bit of setup is to configure the git URL of your cluster git repository which contains the helm file YAML. You can see it here. And we need to configure this into our infrastructure git repository which contains our main .tf file. So we need to get this URL from inside our git clone of the infrastructure git repository which already has the file's main .tf and our values auto tfrs inside. You need to link to the cluster repository by committing the required terraform values and I am going to use these values grabbed from the instructions we were just looking at. Although I populated it with the git URL that's how we needed to grab that and I populated it with the name of my GCP project. I've set, if you see here, I've set Google Seeker Manager to the value true because I'm using Google Seeker Manager and we're putting these values into our values.lado.tfrs file. So the values of that file now contain this line which was already present and then the added information. Now we commit those values and push them. Once those values are added to our infrastructure repo done now, we can terraform init and this downloads the various terraform modules initialize and verifies the terraform stuff. We're being asked for the bot token that's being used to interact with the Djingatex cluster git repository. This is the token for the bot you created that's a member of your GitHub org. So I'm going to enter that value here but I will not show you because let's do the token. Great. Now we have a chance to approve our plan. And we'll say yes. We recommend using terraform to manage the infrastructure needed to run Djingatex. There are a number of cloud resources which maybe needed to be created such as IAM bindings used to manage permissions for applications using our cloud resources. We have our Kubernetes cluster also storage buckets for long-term storage of logs and you get a name created for you and I will be flying goose which works for me. Okay, so now that that is done let's connect to our cluster and then we can tell the Djingatex installation logs and for that we have a command hello install you can see here you can see custom resources being created so this is quite interesting. You can see these secrets are being created and added as a number of secrets that are needed for Djingatex. And in fact some are generated and some are provided at installation by the user like our bot taken and these need to be managed and there are a number of solutions that can help. So Djingatex prefers to use managed cloud services where possible. Google secrets manager is a good example where secrets are stored out of the cluster and synchronized in cluster using external secrets which we will see in a minute. Where managed cloud services are not available or desired Djingatex can also use a vault. Great, we're done. And now let's look at our namespace. Awesome, so here you can see a number of namespaces that we have. Let's look at Djingatex. So now we've moved into the Djingatex namespace and we can create a project. We have quick start projects to help you very quickly try it out. The one I'll demo much we do will do node. So we're going to create a name for it, awesome node to initialize with our automated commit message. So you can see Djingatex has created clone of that node repo in the quick start. And then it's created a pull request on our cluster repo. Excellent, that's now finished. And as you can see we have an awesome node repository that has been created for us in the Djingatex space. We'll have a look at that in a minute and see the pull request that's happened on the cluster repository in the commit and the creation of that additional repository in your GitHub org. And while activity is happening in your cluster you can watch pipeline activity or pipeline log. First I want to show the UI that Djingatex now has with Oxent. So a common question we've heard in the community over the years is when will there be an open source UI for Djingatex and there is now. We're using Oxent by way of an Oxent.JX plugin. Right now we can see the Oxent front end where it's showing us what's happening in our cluster. As you can see I set up Djingatex in the repositories last night, so 10 hours ago. And we can take a look at the pods we have running in our cluster. So you can see all our running pods created 10 hours ago. You can look at our Djingatex and as per usual for Djingatex we have three environments, development, production and staging. You can also see some of the pipelines including the latest pipeline setting up awesome load. So here we can see some repositories that are in our Djingatex space, the GitHub repository. We have our GKE cluster repo and also the awesome node repo that we have just added. And remember our GKE cluster contains the configuration for your cluster repo. As you can see this repo has the helm file which defines all the charts that we're deploying. And here you can see Kubernetes external secrets. In addition you can see here the PR from last night. We'll take a look at it. As you can see it's promoting our awesome node repository to our staging environment. And this PR has been done by our bot and it was merged automatically by the bottom. So if we go into our Djingatex space org and take a look at awesome node this is the repo that we added. So if we go back into Octane and we look at our pipelines and we look at this one. This is the pipeline for the awesome node quick start. The repo for that quick start was cloned, the image was built and it's gone through successfully all the way through to staging. With Djingatex 3 we use a single GKE repository for all the name spaces in the cluster. Within Octane we can view our secrets but remember Octane is giving us a view into our cluster. And within our cluster the secrets are Kubernetes secrets which means that they are only base 64 encoded which means I cannot show you a secret here but I'll talk through some of the Kubernetes external secrets flow and how that works with Djingatex. So that the source of truth of the secret is stored outside the cluster. Let's look at Nexus. You can see here that there is a password and within our cluster that is a Kubernetes secret here is some metadata on it without the actual secret. The secret is in this YAML file so I can't show you. But this gives a bit of a flow and how external secrets is helping to populate the Kubernetes secret. We'll take a quick look now at our cluster repo and we look in our helm file. We can find a reference to Nexus. That's where we say where the Nexus chart is and it's at Djingatex Nexus. This is an off the shelf helm chart that we are installing and here we can take a peek at it here. It's Djingatex charts Nexus. As you can see this helm chart has a Kubernetes secret in it. Kind of secret. You can see the templating for admin password and how good that gets piped into base 64 encoding. Which is how that secret will be in your Kubernetes cluster. So when we install Nexus the boot pipeline runs and it attacks as a Kubernetes secret and it turns that into the external secret. Which we can see in the cluster git repository. And there is no actual secret data that has been checked in to get. So it's very secure to use Kubernetes secrets and to use getups with Kubernetes but you do not have to check your actual secrets in to get. You check in the external secret. When the boot pipeline applies all of that YAML external secret resources are installed and our external secret controller sees that it's an external secret. And it's got a watch on our Kubernetes API server. And it's like, hey, I've got a new external secret that says to create a new secret for Nexus. So we'll get the details, the data, the password, the keys from this location. Then the controller goes and gets that secret data and creates a real Nexus Kubernetes secret in the JX namespace. And there's a little bit this diagram of that happening. As we saw, the Nexus Helm chart has a secret in the chart. When we add it to Jynkin's X, the boot pipeline generates an external secret which gets applied to our cluster. The external secret controller which is running in the cluster will see that and go read the location to go and find the real secret.  And this can be seen in this YAML time. But the Kubernetes secret data is never checked in again. Okay, so here are some links to discover more about Jynkin's 3Alpha, how it differs from Jynkin's X2, some architectural changes that were made in Y. Also, links for finding out more about how to become involved with the Jynkin's X community. Join us for our bi-weekly office hours. Join us on Slack. Okay, quick wrap up. GitOps enables developers to treat the configuration of infrastructure and deployment of code in a similar manner to how they manage their software development process using a familiar tool. Git. Protecting secrets is not a small challenge in software development. Database passwords, API keys, TLS certificates all need to be carefully protected and changed. Fortunately, cloud providers are designing systems and services to make this process easier. And Kubernetes provides a secret object that can be used to protect any sensitive information needed within the Kubernetes cluster. However, getting secrets securely from back-end secret management systems into your cluster to be sorted as Kubernetes secrets has presented some security challenges and teams have had to create their own solutions to fill this gap. Kubernetes external secrets does a great job of securely solving and that is why Jing and Sax has chosen it as a solution for secret management with GitOps and Kubernetes. So above all our one absolute rule for GitOps Kubernetes and secret management is do not store raw Kubernetes secrets again. So thank you for listening and watching this presentation.