Welcome everyone to our panel discussion on the universal code of conduct and the ratification of the enforcement guidelines. Today we have a panel conversation with three folks who are on committee members to share their experiences and insights into the process. I'd love to start off by going around the room for everyone to introduce themselves and share a little bit about your involvement with the movement. Can we start off with a Zoma. Hello. Thank you Sally for having me. My name is Zoma. So I'm a co-founder of the Ebo Wikimedia and use a group. And I was also involved in the UCLC drafting. And also the enforcement guidelines revision committee. Yeah, that's me. I have nothing else to add. Thank you Zoma and Ruby. Okay, thank you so much Sally. My name is Ruby Dameshi Brown from Ghana, and I joined the Wikimedia community since 2019 and since then it's been an awesome journey. I currently support an open foundation West Africa as a senior programs officer and I volunteer for quite a number of things in the community. That includes the Ebo Wikisubs in Africa, which now coordinates and also the UCLC enforcement guideline committee member. And I'm excited to be here to talk to all of you. Yeah. Thank you Ruby. And last but certainly not least Claudia. Hello everyone. I'm Claudia Lo. I am a senior design researcher at the Wikimedia foundation and I do have to say, kind of my exposure to the Wikimedia community movement did largely spring from my position as a staff member. I currently based out of the US I just moved to Chicago, but I grew up in Hong Kong. And in my sort of capacity as a design researcher I mostly support our anti harassment tools team or moderator tools team, and I'm generally focused on working with product teams that focus very strongly on issues of community governance, trying to provide tools for administrators as regular editors to make their experience safer a little bit more pleasant and to allow them to kind of run the communities in the way that they would like them to be run. And for this specifically I was a member of both the UCLC enforcement guidelines committee as well as the revisions committee. Thanks so much Claudia and thank you all for participating in this panel discussion so without further ado, I'm going to get started with some of the questions that we have here for you folks. One is the UCLC was created to define a minimum set of acceptable and unacceptable behaviors as long term members of the movement. Why do you think the existence of the UCLC is important, especially for small and medium communities. I'd love to start off by hearing some of us almost thoughts. So, the existence of the UCLC, I believe, would help the small and medium side, the communities projects, if you put it that way, to help them understand expected behaviors with the understanding of what is expected and unexpected behaviors that the communities can build a healthy community early and also adapt the UCLC based on their lived experiences. The small and medium size, which is, I would say they are fragile and also malleable. They are fragile because they are building an omission stage and they are mostly recruiting and retaining contributors. The issues of unacceptable behaviors can affect and quickly turn their community to an unsafe environment that no one wants to be part of. In the sense of being malleable, because they are at the building stage, it will be easy for small and medium sized communities to adapt and adopt the UCLC, which will guide them towards building a culture that holds every member of the, every member or contributor accountable to their behavior in the wiki space. Which in the long run will result in an atmosphere of trust, inclusivity and a safe environment for everyone to grow. So, simply put, UCLC will help the small wikis grow a sustainable community faster and avoid unacceptable behaviors and their consequences. Consequences that some of the so to say old wikis have faced and maybe some of them have been threatened by, I mean the existence have been threatened by some of these unacceptable or unacceptable behaviors. Yeah. That's, that's it. Thank you so much Yuzoma and I'd also love to hear some thoughts from Ruby on that question and please feel free. If you'd like me to repeat the questions at any point feel free to ask. Yeah, I think is someone has said a lot on this and I really support what she's saying and definitely that's basically what we're looking at. UCLC is a very important tool for our community, and it helps to foster trust, safety and inclusion, making one who comes in the community safe. And so, especially for young smaller communities that are going with we've seen a lot of community spring up in the short space of time this is a very important tool that they can easily adapt because some communities took years to come up with something like that and the work has already been done for you. So all that you need to know is to adapt it and adjust it to your community and, and this is a very great benefit that the UCLC gives to the community and I will say that it also empires small community they'll be able to handle the dilemmas or situational dilemmas that they encounter they don't know how to go about it because young communities are now exploring how to go about certain issues how to handle certain conflicts in the community so this is going to be like a guidance to sort of like help them to or empower them to handle such situations, which is very good useful. Yeah. Thank you and thank you both for sharing some insights, especially for the small and medium communities that we have out there in the benefits of the UCLC. I'm going to jump over to our next question, which is over the last several months, the revisions committee has worked diligently to integrate feedback from the community on the enforcement guidelines. What are some of the reflections you have, and most importantly, why is the EG important would love to hear from Claudia on this one first. One of the really big principles I remember trying to keep to throughout the revisions process certainly was trying to make sure that we would write the guidelines and such way to provide enough structure so that we don't have a kind of history of sort of dealing with these kinds of situations already set precedent and already set methods on how to deal with them to provide structures for them to kind of take those first steps into how do we settle these disputes, how do we fairly enforce these guidelines across all of our many, many diverse projects, while also respecting existing community processes, understanding that there are a lot of ways in which existing projects handle those in ways that are slightly different from each other, but recognizing that all of them ultimately at the end of the day have that same aim of making sure hey, we're all here to contribute to our projects in a healthy way that encourages and allows participation from people in the way that they want to in the way that the most comfortable. So, I think one of the, one of the strengths of the enforcement guidelines, I would say is that it gives everybody that same baseline to work with. And I think we, we did definitely try and I will say I certainly tried to my involvement in the process to kind of understand the fact that this is just a starting line right we want to set a common starting ground for everybody to get a sense of okay well this is the minimum right of how we would like these guidelines to be enforced. If individual projects have ways of going kind of above and beyond. That's absolutely fine. In fact that should be welcomed if people you know people should be able to take the space line and say okay but we actually think that this should go even further for our project because we believe even more strongly in these principles because they matter to us. Thanks Claudia I really appreciate hearing you know your your insights as being part of the progression of the the uc oc. I would love to hear a little bit also from you Ruby what are some of your thoughts there. Yeah, I must say that it's been a wonderful journey, like reflecting on what we've done. A lot of feedbacks that we've got it in different spaces and different languages that were translated, you know so that to bring us in a common ground, when I'm analyzing this feedback and trying to incorporate it where necessary was very vital as part of the work that we do and I believe that the enforcement guidelines are very important to for the community to help us to know how to go about some of the situations that we face because I mean the universal code of conduct says that if you do this if you do that but how do communities practically implement you know this documents set the space for that to happen like tend to bring people to that. It's sort of like a stepping stone in helping us bring that implement this universal code of conduct into the community and one of some of the interesting thing is that we had to create scenarios and practically solve them like put ourselves in those scenarios to analyze and that help us to better analyze some of these things and we also made sure that that feedbacks like we want to know where the feedback coming from and there was great analysis that we're done to help us understand where these feedback are coming so that we're not just incorporating feedback from one community we're trying to bring equity and another amazing thing that I'll say that the committee also did in designing this enforcement guideline was the fact that we categorize it into topics so if you look at one topic you would see that okay which communities have issues with this topic and how do we make sure that we inclusive as much as possible in in in weighing all these feedbacks that were coming. This concerns that were raised against this topic so a whole lot of things were like reflecting back on what the community has done. It's amazing and the community did amazing work providing us with very useful feedback and suggestions which we now have like a very good of course it's not perfect like Claudia said I mean we cannot have a perfect guidelines to move forward. It would definitely be improved. Yeah. Thank you Ruby and as I see you agreeing and echoing a few points that Claudia and Ruby have made. Do you have any thoughts to share as well in terms of some key reflections that you have in terms of the process or using community feedback to do the revisions. So nothing in particular Claudia and Ruby covered it all. Yeah, reminding ourselves that it is the baseline and it's just the baseline while considering the feedback from people and the comments and all that so yeah that was really something we needed to have at the back of our minds and walk with. Yeah. Thank you. Thank you everyone for for adding to that conversation there. I'll jump over to our next question, which is the ratification for the revised enforcement guidelines has begun on the 17th of January 2023 and will be open for two weeks. So why is it important for communities to vote on the revised enforcement guidelines. Why is it necessary in the UC OC enforcement process. If we could start off with you as on that would be great and I'd love to hear from everybody on this question. Sure. So, what in is one of the ways we make decisions binding in our movement. So, really, if we don't vote, we won't have these enforcement guidelines. So, without the enforcement guidelines, there won't be any form of accountability pathways and processes in our communities to tackle issues of unacceptable behaviors, or even escalate them and when they surface. So, yeah, without the enforcement guidelines, the UCSC cannot be fully activated. And it won't be effective in our movement. So it's very important for everyone who is eligible to to vote. Also having the opportunity to stand for what you want in the movement gives a sense of commitment and trust in the outcome. Yeah. If somehow people missed out on opportunity to be heard either as an individual representative of a community. This is really a good opportunity to let your votes count. Even if even if you think that the UCSC is, I mean, if you think if you have comments, I mean, if you think that you support, let your votes count if you think that something needs to be updated. Yes, leave a comment and also let it let it be, let it count. I understand some of the small wikis are busy and have commitments in our in daily lives that can hinder them from participating in discussions around enforcement guidelines in the past. Notwithstanding, they revised the guidelines. This is a good opportunity to be heard and stand up for what will determine how safe and civil projects will be in the future. Just to summarize, we can't achieve a safe environment for also to contribute about the enforcement guidelines. And we, we can't have enforcement, the enforcement guidelines, if people don't vote. So, it matters that we vote and that our voices counts. Thank you so much. I really enjoy hearing your thought process there and having your voice be heard. Ruby, what are some of your thoughts and then we'll jump over to Claudia after but what are some of your thoughts on why it's important for communities to vote in the revised enforcement guidelines and why you think it's necessary for the UCSC enforcement process in general. Yeah, so I would say that this is a very important thing that the community itself wanted in the first place. And so this is a revised version of the enforcement guidelines. We had the first version, which community gave us a feedback, and we went back to work several months to make sure that it's a good shape. So, we're here again, urging all community members to come out in your numbers look have a look at the revised version of the enforcement guidelines and come out and cast your vote, because this is very crucial. And I know Zuma had said a lot about it. It's very important to help for us to implement the enforcement guideline because this is what is going to help the UCSC to be valid. I mean, like, to really work well in the community to provide a safe environment that trust that we've always been longing for.  If all of these communities come out in your numbers, they might be even powerful than maybe one big community that we've always thought about. So we want to urge you all to come out in your numbers, your voice will be heard, your voice is important, your vote is important.  The reality is going to be, it's going to, we're going to see the reality when we actually even enforce it because then we're going to see how practically some of the solutions that we are even thinking around it can happen because I mean, don't think about it to be perfect before you vote. No, I'd encourage all of you to come out in your numbers to vote. And we can have that community or environment that we've always been looking for. Yeah. Thanks Ruby and would love to hear some of your thoughts Claudia. I'm really just echoing everything that Zuma and Ruby have said already it's important to vote. I think it's important to vote from an individual perspective that this is, I really want to commend the, the, the trust and safety team here in their effort in trying to involve as many communities as possible. So when we're really talking about, you know, we were trying to respect the community's wishes that would not have been possible without the very diligent work of a lot of translators and facilitators working and so, so many languages over such a long time, kind of really, really working around the clock to make sure not only were they relaying these questions holding the sessions to try to gather community feedback and really give people a chance to voice their ideas and their ideas, but also to get all of that translated and then analyzed and sent back to us in a way that would be comprehensible for us that wouldn't force us to all spend 40 plus hours of our time every week to try to digest all of this material which is really important because, you know, aside from, you know, not everyone there is staff a lot of people are volunteers a lot of people have other obligations with their time and so I found that process to be very respectful of our time so thank you very much. All that is to say that I think throughout this process we did try really, really hard to reach out to as many communities as possible, regardless of size, regardless of activity levels regardless of you know maybe how active they have been in maybe earlier stages of the this code of conduct, this whole process, or in other community consultations or sort of global movement wide conversations before. I think that's part of what makes this project really important and very important to kind of get everyone's votes in and to get everyone's voices heard, or at the very least to have your opinion logged through the, through the vote on these enforcement guidelines. And yeah just to reiterate truly it does not matter whether your home wiki is big or small, active inactive whether it's a wikipedia, a wiki source a dictionary, all of that is important all of that matters because these are going to be guidelines for all of us. So I have a bit of a similar question but it deviates just slightly, and it is, as you may be aware, past elections, board elections, and so forth are usually dominated in representation by larger wikis. Why is it important for smaller communities to particularly participate in the ratification vote, and to get their views interested represented in the vote. Again a bit similar but zoning in on the smaller community specifically Ruby what are some of your thoughts there. So, I would say that for small wiki communities that this is an opportunity for your voice to be heard, because we shouldn't just let always let big communities decide for you. That is the power to also let your voice be heard so that's all I'll say that this is a very great platform that has been provided for you most, most of the times, we're behind and then we're talking behind, like wanting things to change by just being behind and the things don't change that way. You need to bring your voice you need to know that we're here to these things empower every community allows you to let your voice to be heard so this is what I'll say about that I don't know if anyone has anything to say. Thank you so much Ruby and would love to hear from us Omar Claudia if you have anything to add to that I know this was a bit of a conversation we started earlier in the process but if there are other points that you'd love to add who's on my saw that you unmuted what are some of your thoughts. Yeah, so just to add to what Ruby said, it is, I mean, it's a simple process. Once you're eligible, all you need to do is go to the voting page and support or post the advice them enforcement guideline. And if you're opposing, leave a comment while you are. It is not like multi level voting that has a complexities and all that it's just them, voting, a simple voting process. All that is needed is for the vote to be more than 50% I think that's for support that 50% supports votes, more than 50% support for the enforcement guideline to to pass. So, it's a huge advantage for the smaller kids to at this point to take this opportunity and, you know, make the make this something that would help build their community. So, let's make our votes count really. Yeah. Thank you, Claudia I saw that you unmuted. Yeah, I just also wanted to back on with the caveat that a I have not been, I am not as well first in kind of the perspective coming from within the community looking at these votes and I understand that there may be a history of how these votes have gone but I do know that one thing we were aware of and trying really, really hard to counter was the tendency to the easy tendency to fall back on. Oh well because we're all speaking in English let's go to places where English is already being spoken in the movement like I said there was a huge huge push to, you know, have facilitators and as many languages as possible to use both you know machine translation but also rely on human interpreters and human translators both from the movement itself but also you know professional translators from outside just to get just to allow as many people as possible to express their opinions in the language of their choosing. And I think that's really commendable and I think it would be a bit of a shame honestly if all of that outreach results in sort of people not processing in the vote because of perhaps a belief or a fear however well founded that it's not going to count and or it's not going to matter and I want to say that that is absolutely not the case. It certainly I think was one of the things that preoccupied us was like making sure that we were paying enough attention, giving enough time and space to those concerns of smaller wikis medium sized wikis wikis that maybe don't have as like as developed or as extensive a network of kind of this enforcement structures that they themselves may have already made to try to really really look at those perspectives and kind of understand them and understand those challenges and see how we can support them. Just also say please, please come, please vote I understand that the guidelines are a very long document. We're very sorry we already went through several rounds of trying to make it shorter and trying to make sure that the language was you know, as easy to translate as possible while still being really precise with the language that was a huge, huge concern for us I think we all remember those weeks. And yeah, I would absolutely love to see a high vote turnout from all of our communities when it comes to this round of voting. Thank you, Claudia, Uzoma and Ruby for the importance of of all communities coming out to vote and and speaking a bit towards those smaller and medium sized communities. Really appreciate hearing all of your thoughts there can move on to our next question which is, as some of you may be aware, a universal code of conduct coordinating committee, known as the you foresee would be created to work on the enforcement guidelines. Do you think the creation of such a committee is necessary, and Claudia will start back off with you. So I was assured that it is extremely the committee a community movement thing to conclude one committee by announcing we should create a second committee to keep going. But jokes aside, I think I'll say one of the motivating factors I felt that was a really strong argument for creating. I know yet another community committee was that the us the people in charge of writing the enforcement guidelines should not be in charge of changing it that it was really important to have a fresh set of eyes and a fresh sort of set of participants with different experiences different backgrounds, different understandings of this problem and how to best solve it should be allowed to take that next set of steps towards going. Okay, how do we kind of nuts and bolts oversee the day to day. How do we kind of translate these principles and these guidelines into day to day action and how it would function on an everyday basis across the community and so importantly, how do we build a mechanism that allows us to reflect on these guidelines and to change them if necessary in the future. And I think and I agree that it would not have been proper I think for the revisions committee members to kind of have that job as well as having created it originally. I understand the frustration at making a committee after this committee but I do think that there are good reasons for it. Thanks so much Claudia and what are some of your thoughts to that is Alma. Like Claudia said, you need a neutral body or more like a final authority to handle the UCSU matters on a global scale, ensuring that the code, the code of conduct is enforced and reviewed to apply to peculiar issues that come up in the movement. Yeah. So, I agree with Claudia and. Yeah, you can't, you can't just, you need a neutral body to help with revisions and also ensure that the UCSU is being implemented and everything is working according to plan and well adjusted to current situations or leave the experiences. Yeah. Thank you Zoma and to dive into this question a little bit more and to stick with the you foresee. What are some of the ways the committee can work collaboratively with existing local art comms or admins and I'd love to open this question up to everybody in the room. So yeah so diving in a bit more to the you foresee what are some of the ways the committee can work collaboratively with existing local art comms or admins. And maybe we could start off with Ruby and then we can go around the room. This is a very important question that you asked, and it's very important that the committee, the certain you foresee for me to work collaboratively with the community to ensure that all these issues that come up as a movement as we have already been seeing around at Resolve and make up me, people get to understand the right way to go about some of the issues because community needs also needs support, you know, so two heads is better than one. So coming together is very important, working together helping each other to understand the different situations because without collaboration we will not be able to understand some of the scenarios or situations that we come across. For instance working as a committee we came together with different backgrounds different perspective and this is what makes this document very rich because we are coming with different perspectives trying to make bring meaning to the things that were documented some of the things I wouldn't understand because it's coming the way that it was said, but because we have committee members from other regions were able to understand what the situation is like or what the person is saying. So it's very important that collaboration works in this situation to help us amicably resolve some of the situations that we find ourselves all we encounter. And that's what I'll say about it. Yeah. Thank you Ruby and any thoughts from from Claudia or Zoma and in terms of some ways that the committee can work collaboratively with exists, existing local ARB comms or admins Claudia. Yeah, one of the kind of areas, one of the areas of opportunity I really see for the U4C is kind of facilitating inter wiki communication, especially where language barriers might be a problem. So one of the issues I think we've seen previously is that, you know machine translation being widely available is really great, but it can only handle so much, and especially for cases like sensitive cases of abuse of harassment, especially you know where cases where a lot of nuance or understanding of context and history is really necessary. I hope that the U4C can be a useful bridge and kind of allowing global community to work collaboratively with each other to find solutions. And to also maybe, you know, figure out previous previous attempts to solve similar issues and kind of understand, you know what worked well, what didn't work so well in the hopes that communities don't have to reinvent the wheel and start from scratch every time. In these kinds of situations, especially as these cases might be time sensitive or be very complex and complicated. Yeah, I really hope that the U4C can help with some of this inter project communication and collaboration, whether that's through providing language support, whether that's through giving a pathway for people to understand kind of the context behind solutions or, you know, being a third party mediator or observer in these processes. I think all of those things would be a positive development. Thanks Claudia for adding to that question. Usama any thoughts to add to what these folks have said. So the outcomes and needs faced with some of these unacceptable behaviors more like they're always on the front line with some of these issues. So, they'll be the best people to collaborate with the U4C. And one of the things they can really do is to suggest or surface particular issues they encounter to the U4C for consideration during scheduled revisions of the UCOC. Because as time goes on, things come up and situations arise and all that so there will be the best people to work with the U4C to suggest some of the newly encountered issues and also provide context to understand how to go about incorporating these things to the revised UCOC at the appropriate time. Yeah. Thank you Usama, Ruby and Claudia for answering that question we're coming up to our last question. And I'm going to open this question up for everybody on the panel as well. The next question is the enforcement guidelines drafting committee recommends that the Wikimedia Foundation develop and implementing training for community members with guidance from local communities and affiliates. Can you tell me more about the thinking behind having the foundation, take the lead on this work, and we'll start off with Ruby for this question. So my Sally. Yeah, this is a very interesting question that community sometimes acts over and over again and I will put myself as a scenario, or maybe other volunteers that we work with volunteer have, most of volunteers have the full time commitment and the volunteer for the movement as well. And when you come to staff, affiliate staff and all of those groups, we also have work that we're doing. So a lot of things is happening in the movement, and we want to make sure that volunteers make use of your time to the best that they can, to the things that really matters to them, I mean, like, things that you're committed to so that you're not burdened. Okay, the foundation have resources that are existing they have staff already that are working on these things and so this is a great opportunity to leverage on these staff to facilitate and coordinate and that's what we've seen with Sally and her team doing amazing work because I can't imagine sending all those emails, like, trying to bring everyone together trying to schedule meetings this is a lot of work I've done that before and I must say a lot of work we cannot underestimate that and take it upon itself again so it makes our work easy because all that we need to do is just get the update on the email, like know where we are meeting, where we are supposed to do this and it's well organized and it helps us to contribute because we all come here to get as volunteers on this community, but what's making us move on and making us contribute well organized is because we have this team that is supporting us, facilitating all of these conversations, imagine we can't even gather all the feedbacks from all of the countries. I can imagine that the foundation has the tool to do that to translate all this conversation in the way that we can understand and make our contribution while analyzing this enforcement guideline so I think we cannot do without the support of the foundation which is very important and we cannot underestimate the support in this situation, that's all I can see, yeah. Thank you so much Ruby, we'll go Uzoma and then we'll finish with Claudia, Uzoma what are some of your thoughts? Yeah Ruby, Ruby really had so much to say about this, so just to summarize or just to you know echo what Ruby said, the foundation has time, more time, resources and money and expertise. So, with all these ones burdened the volunteers so much on being as their time is so valuable and it's not that the UCRC is not important to them or the UCRC matter is not important to them but I mean their time is valuable and it will be best channeled into other things not that they're not involved but channeling into other things more and allowing the foundation to take lead and do what they know how to do best. Yeah, so that's what I'll say, the foundation still remains the, I mean the expertise to carry on with the work. Thank you Uzoma and would again love to hear from Claudia as well some of your thoughts around the thinking behind having the foundation take the lead on this work here of the training, yeah. Yeah, very similar to what Uzoma and Ruby said, part of that was resourcing, not only in terms of who, and I think I should say that like a lot of the reason why that sentence is written like that is that the idea is that the, what the training is on should not solely be dictated by the foundation, but the foundation has the obligation to take ideas coming from the community and turn that into a full training module, because it's one thing to say we should pick an example. We should train administrators in digital security, you know, in case their accounts get hacked, and in case you know that poses a really big threat to their project. Right, that's a great idea. What digital security means and looks like for different people in different situations looks really really different. And I think it's really important to understand that. I think that the foundation being in charge of developing those training processes those modules, hopefully means that there is a better likelihood of them being supported into the long term. So, hopefully that if somebody says hey let's develop a training on this topic, not only does that it would not only will that be given the resources needed to make it happen. That it will persist and the year after it first runs we can do it again and the year after that we can do it again and that it can kind of have a permanent home. So I think it's a good group of people in charge of making sure it stays up and that it stays up to date to receive feedback and to refine and keep it going so hard of what you know like the direction doesn't necessarily come from the foundation, but the boring unglamorous legwork of making sure that those materials stay up stay relevant and stay accessible has a clear group of people that are responsible for doing so. And I would rather have that burden placed on the foundation than to shunt it to volunteers who we already asked to do a lot frankly. Thanks so much Claudia and yeah I'm definitely hearing a lot of distribution of labor and a lot of great insights from folks there. Thank you all so very much for participating in this panel for taking the time to share your thoughts and experiences. And for all the folks that are listening voting started January 17, 2013. So please listen to what these folks have told have spoke about have shared their experiences with. Again, a big thank you to Claudia, Zoma and Ruby for sharing those insights. I hope you all have a great rest of your day. And we will be seeing you all soon. Thank you. Please vote.


Hello, everyone. My name is Ryan Turner and I'm a software engineer at Uber and a maintainer on the SPIRE project. And today I'm excited to talk to you about some updates with the projects and that I'd like to share from the last time we got together at Production Identity Day in North America in November of 2020. So first, I'd like to just share some statistics about the project as of early September this year. This is between last Production Identity Day and this September. So we've released 11 new versions of SPIRE in that time. We've deployed out 49 new features into the repo and 59 bug fixes and improvements. And a total of 339 pull requests were merged in the last year. And this is just awesome. This is like way up from last year. So it's super exciting to see the growth and momentum of the projects and in total we've had 48 contributors over the past year. So that's really great. That's also up from last year. So thanks everyone who has been active in the project and contributed new pull requests. Those who have filed issues, you really drive the direction of the project forward and we're really all appreciative of that. So I'd like to just highlight the folks who have contributed in the last year. These are all the users who have committed something to the SPIRE repo since last Production Identity Day. So huge props to all these people and we really appreciate all your contributions and keep them coming. So this year we were really focused on trying to release a 1.0 version of SPIRE. And a 1.0 version for us as maintainers of the SPIRE projects really signified a stable and secure release that really showed that the project solves a core use case that applies to many organizations in the software industry. And we felt like coming into this year we had really found a real momentum of the project and found that a lot of organizations were interested in SPIRE. And so we felt like the project was getting to a stable enough place to make this symbolic gesture, if you will, of 1.0 being the next release of SPIRE. So early this year, back in about February, we were considering trying to release 1.0. In the meantime, we had actually commissioned a security audit of the project to just make sure that we didn't miss anything. And it turns out there are a couple of vulnerabilities that were discovered as part of that security audit. And I'll talk a little bit about those in a little bit. But basically, once those vulnerabilities were reported, we sort of had to reevaluate our direction and make sure that we were achieving the objectives that we had laid out for a 1.0 release. So back in March, we actually released several versions of SPIRE to patch some of the security vulnerabilities that were reported as part of the security audit. And that took place in March. So in April, we were looking at all of the pending contributions, all the pull requests that were open. And there were a lot of things that folks from the community wanted to contribute. And we didn't want to hold those things up artificially just to try to release something that was called 1.0. So we decided to merge most of those changes into a couple of point releases on the 0.12 major release branch. And those constitute the 0.12.2 and 0.12.3 releases in April and May of this year. And once we had time to let those releases kind of be out in the wild for a little bit and give users an opportunity to use them and report any issues, we felt like around July, it was a good time to actually declare this project a 1.0. And so we actually did release a 1.0.0 version of SPIRE in July of this year. So it's a huge accomplishment for the projects. And we're just excited to see where it goes from here. And hope that it kind of fuels the adoption for the next wave of users who might potentially find benefits from adopting SPIRE. So earlier I mentioned that there were these security releases that came out earlier this year. And I'd like to just kind of talk about what prompted those releases. So we actually commissioned a security audit to a firm called Tier 53. They're a really great reputable security research firm. And they started looking into the project around February of this year. And they did a full like in-depth white box analysis of the project. And so they were really looking through the source code and all different kinds of potential attack vectors. And in general, the project was found to be pretty well designed in their words. But there were a couple of vulnerabilities that they found. And this was all focused on the 0.12.0 release, which was the latest release at the time. But they were performing the audit. So there were one high and two medium vulnerabilities that they discovered. And we took these vulnerabilities very seriously. They were initially only reported back to the maintainers of the SPIRE project. We have a security vulnerability reporting process, which is described in the GitHub. And essentially, these kinds of security vulnerabilities we ask anyone who finds them to send an email to the security email address that we have on the GitHub repo, which gives the maintainers an opportunity to evaluate whether or not there is a vulnerability and what the potential impact of that is, as well as developing some patches to try to fix those vulnerabilities and figuring out what affected versions are out there. So these are the two vulnerabilities that we filed CVEs for. You're more than welcome to go on to the GitHub repo. We've published GitHub security advisories for both of these vulnerabilities, which describe the issues in a lot more depth and also refer to the fixes, which were applied to all the affected versions. So I'll just briefly cover what the vulnerabilities were that the audit uncovered. So the first one here, legacy node API allows impersonation. So there is an existing set of APIs that came out before the current V1 API layer, which was introduced in late last year. And one of those APIs was called the node API. This was something that the Aspire agent used to attest itself to the Aspire server. In a sense, prove that it's a valid agent in the infrastructure. And there was one path available where if an actor was able to obtain an agent SVID, meaning it was able to successfully attest to the server, it could potentially request SVIDs for identities that it wasn't allowed to serve based on the registration metadata registered in Aspire server. So that was one of the vulnerabilities. And then the second vulnerability was around spiffy ID paths. So spiffy IDs, as you probably know, if you're familiar with spiffy, they are designed as URIs. So in the URI specification, there's no restriction on like Unicode characters or selected characters that are like punctuation marks and such, that those kinds of characters can be represented through this percent encoding mechanism. And it turns out that it's really hard to uniformly handle those kinds of sequences in URIs across different languages, across different libraries. And so there were some inconsistencies with how those URIs were being handled. So effectively, we decided to amend the spiffy specification to disallow the use of Unicode characters as well as restrict the ASCII characters that could be used to a limited set to try to prevent these sort of issues where like spiffy IDs could be interpreted in multiple ways depending on the URI library or implementation used. So as I said, we released new versions with fixes for all these vulnerabilities. And we published the results of the vulnerabilities and patches into the Spire GitHub. And if you're interested in reading through the audit itself, that is also published as a PDF on the readme file for the Spire repository in GitHub. Okay, so I want to kind of walk through the releases in the last year and just highlight some of the notable accomplishments in the project. So let's go ahead and start with the 0.12.0 release, which came out last December. So as I mentioned before, Spire introduced a whole new set of APIs called the V1 APIs, which just brought a lot of more consistency to the API design across the board. And so those APIs effectively replaced the initial set of APIs in the 0.12.0 release. So Spire started using all of those APIs internally. We also introduced significant improvements to the agent sync operation, which to describe that in a little more detail, the agent sync essentially, it's an operation where the agent very frequently every five seconds requests all of the registrations that it's eligible to serve identities for on the host it's running on. And that operation used to take a lot of time with a larger number of agents or a larger number of registrations in Spire, because it was using dynamic database queries that were not very efficient. So we optimized this whole procedure using an in-memory cache and the server, and that really sped up the time that it takes to fetch all of this data that the agent needs to be very predictable. And then we also introduced support for the Envoy SDS V3 API in Spire Agent. So that brings our compatibility to latest versions of Envoy. And then in March of this year, this is when we released all of the security fixes that we just talked about. And then in 0.12.2, this was released in April of this year. And some of the noteworthy things to point out here, there was a new server key manager plugin created, which uses AWS Key Management Service. So this allows you to manage all of Spire's private keys and signings and a key management service and AWS. There was also a new plugin added for the Spire server to use GCP CAS as the upstream authority. So it allows you to chain to CAS managed chains of trust. And then in 0.12.3, there was support added into the Kubernetes workload registrar for registering workload entries in Spire that need to federate with other trust domains. And this was released in May of this year. Okay. And then the big one is 1.0.0, which was released in July of this year. So a lot of things went into 1.0.0. One of the major things that happened was that there was a big refactoring of how the Protobuf definitions are managed in Spire.  One was the core Spire module. And the second was a Protobuf module. So any API clients could take dependency on that Protobuf module. That Protobuf module contained Protobuf definitions for both the API layer as well as plug-in SDK Protos. So it was kind of overloaded with a couple of different things. So we decided to refactor that into separate GitHub repositories for those API and plug-in SDKs. And those are called Spire API SDK and Spire plug-in SDK. And those are both in the SPIFI organization GitHub. We also added support for versioned plugins. So if we need to change the plug-in interfaces in Spire, we have an effective way to do that now through versioning. There's also support added for a cert manager upstream authority plugin. So if you wanted to use cert manager as your chain of trust for the upstream for Spire, that's now possible. There's also new commands added to the Spire server CLI for banning agents and counting some of the resources tracked by Spire like agents and entries and bundles, which used to be kind of an expensive thing to calculate if you had a larger scale deployment because you had to list all of those resources and all their data, which could take a while and was kind of intense on the database. Now this is kind of an optimized command, which does that all in the database doesn't require transmitting a lot of data. There is a new authentication method added to the vault upstream authority plugin in the server to use Kubernetes-based authentication with service count tokens. The server now supports the latest configuration for the Spiffy Federation feature, which was added last year. And the Spire agent can now provide trust bundles to unregistered callers via a new RPC, which was defined in the Spiffy workload API spec. So if you have workloads which need to verify SBIDs, but themselves don't really need to use SBIDs for authentication to other workloads, you don't need to register those verification workloads anymore in Spire. You can use this unauthenticated unregistered API to just obtain the bundles. Also on the server and the agent now implement the standard gRPC health service, so this improves the health check story for Spire. In 1.0.1, we added an LDV ID-based TPM node attester plugin, which basically uses a proof of possession and proof of residency challenges to verify that host is issued by or has a TPM that's issued by a trusted vendor. So this improves like private cloud kind of attestation if you're using TPMs. And then we've also had node attestation for AWS VMs across multiple AWS accounts using AWS IAM role assumption. In 1.0.2, we added an experimental support for defining authorization policies in the server using OPA. So this kind of changes the mechanism that the server uses to authorize inbound callers. There's also audit logging added to the server API layer, so all calls to server APIs are now audit logged. Support for the SPIFI certificate validator was added to the Envoy STSV3 API and Spire agent to enable federated SPIFI authentication. And there were also support added to the Kubernetes workload registrar for identity templates for SPIFI ID paths. So you can now dynamically generate SPIFI ID paths based on attributes of Kubernetes pods, for example. All right. And just want to quickly go over what's coming next. So in the near term and medium term, we're looking at it continuing to simplify the experience in Kubernetes to make it more turnkey. And this applies to both how SPIRE is deployed as well as the way that registrations are created for workloads in Kubernetes. We want to continue to focus on how we can support workloads which don't run in an environment where a SPIRE agent can run. In the classic example, this is like a serverless environment like AWS Lambda. There is ongoing work to provide a new API, which allows like a trusted process to delegate the, to delegate S-FIDS to other workloads running on the same host. In the past, this has only been contained within the SPIRE agent, but now we're allowing like trusted proxies, for example, to be able to do this kind of issuance of identity as well. We are looking to provide a new API to programmatically configure federation relationships. We're exploring ways that we can do better verification of binary signing to use things like TUF, for example. And then we want to provide ways to connect to GCP, using secretless authentication with OIDC federation. And in the long term, we're looking at how do we effectively do key revocation and forced rotation, identity, also secretless off to Azure with OIDC federation, continuing to iterate on our health check subsystem and improve our error messages to be more actionable. So that's all I had today. Thanks for joining and have a great production identity day.


Hello in this presentation, we will work a problem related to the accounts receivable cycle similar problem that we had in the past However, now we will be recording the transactions here as we did in the past But not posting them directly to a worksheet But rather to the general ledger building the general ledger as we go Then using that general ledger in order to construct the trial balance, which will then remain in balance So as you can see, this is going to be a bit longer of a worksheet This is kind of the traditional type of worksheet that we would work out However, we're going to set up this worksheet a bit differently than many book problems in that We will be posting the journal entries as we go to the general ledger and then building the trial balance as we go I suggest putting a system together like this whenever possible because it's going to save you time in that if you do Everything at once over here and then post it to the general ledger and then post it to the trial balance. It's very likely that


Hi everyone, Joe for Jaspy's casebreaks.com with a quick little Mini box break right here 2013 select Top two names at the end of the break and the re-randomizer will win spots in diamond icons Which is technically sold out We just need to do one more of these and then we'll be in breaksville on that All right, so for the break itself. Let's double your names up one spot gets you two in the on even set this up And that was technically it's a half box Random team number 25 2013 panini select Baseball. All right, let's roll it. Let's randomize it five into three eight times for each list just for the break one two three I know it's just too eager to get into the get into the break CUNK eastwood down to Jacob five into three eight times And eighth and final time when I do the randomizer for the spots that were given a eighth and final time When I do the Randomizer for the spot giveaways that we're gonna take the original 15 names All right, so there's the first half of the list There's the second half of the list right there Let's sort by team Let's print and rip Random team 25 we marked that so we know it's from the same box. All right. Good luck got Zach McAllister Cleveland Indians that'll be for Dan G Marco Scooter Look at the weird cuts on that right there. It's a weird batch And we got Brian Morris 21 out of 75 gold Gold out of 25 not 75 25 And that is for Pittsburgh. That's gonna go to Richard Dunn another weird Weird cut right there Maybe that's why a PSA 10 Mike trouts are going for so much Let's go to Jacob Johnson and the Angels and Fuego Mike trout. There you go Let's give away two spots and diamond icons random hit break number seven Let's gather everyone's names Richard down to Dan Or no, I'm doing the original 15 names. There you go right there. So let's re-roll it I already had set up got ahead of myself two and a one three times top two names after three one two And good luck everybody third and final time. We've got Jacob Johnson Greg S. Vang. There you go Congrats to the both of you. You're in diamond icons. You're guaranteed a random hit I don't know what it's gonna be, but we'll find out later tonight Joe for Jasper's case breaks calm I'll see you next time


Hello everybody. Welcome to our session about vendor agnostic serverless functions. We will be presenting today with Mohit, so first let's introduce ourselves. My name is Zvynie Grubalik, I'm based in Czech Republic. I'm in general working at Red Hat in Open Chief Serverless Team. I'm a member of K&E team community, so I'm a member of K&E team TOC. I'm also a maintainer of Project KDA, so if you have any questions on those two projects feel free to ask me. Good afternoon everyone. My name is Mohit Zvyn and I work at Red Hat and I'm a senior product manager working around Red Hat developer tools. I'm based out of India and today we are going through some of the cool stuffs, what we do around serverless, K&E team and functions. So let's pass on to Vinik. Cool. So this is the short agenda, so we will do some introduction, this has been done, right? And then we are talking about serverless functions, so maybe we will say what the serverless actually is. Then we will show the demo. OK, so what is serverless? I bet that the majority of people, when they serve serverless, they think, OK, that's AWS Lambda, right? But there might be different ways how to achieve those similar capabilities. So, for example, this is a definition from CNCF. I won't read the whole definition, but basically the main point is that serverless, there are applications that do not require server management. And they have like a very simple deployment model. And they should be executed and scaled based on the demand in the very specific moment. So if I can summarize this in a few bullet points. So serverless, it's like autoscaling, right? This is important feature of serverless, so scale to zero. Simplified development and deployment model. And by its nature, the serverless services or functions are event-driven, so they should be asynchronous. So we need to take this into consideration when we are, let's say, building our solution based on the serverless approaches. Also the serverless, I don't want to deal with the server configuration or with the infrastructure configuration. It should be very simple with a very nice UX. Also when we are talking about serverless, there are serverless functions, functions of the service. There are different opinions on these terms, so this is how we see it, actually. So for us, the serverless is a deployment model that basically abstracts the way that we deploy the application on the infrastructure. It provides the capabilities to scale the workloads, save the configuration and all this stuff. Functions, on the other hand, for us is more like a programming model. So because it has like a certain function signature that you need to match to actually deploy the function. So once you build this function, then you can deploy it as a serverless workload. So serverless, you can take basically any of your containers or whatever, deploy it as a serverless, but functions is more like a glue, so you have a strict thing to follow, and it's usually like a smaller service. So what is the idle serverless workload? It might be a workload that is stateless because with the serverless we would like to scale very fast, so we don't want to keep the state, but we don't want to keep the state inside the application. We can keep the state outside the application in some key value store, for example, Redis, but we should not have the state. It should be ideally short-running, so if your application is short-running, it's ideally candidate for serverless workload because it will do this job and it will scale in. And if your application is HTTP-based or event-driven, then also it is a good candidate for a serverless workload. So let me explain more, like let's say this is the serverless pattern, we call it. So on the left-hand side you can see event. It could be HTTP request, it could be Kafka message, it could be some other event, and this event triggers our application and this application does some work and produces some results based on this event. Once the job is done, the application should be scaled in. Also if there are more requests, the application will scale out, so this is the serverless, basically nutshell. And since we are on KubeCon, so let's take a look on the serverless approach and let's say from the Kubernetes way, because this might have several benefits, because, for example, if you have your traditional applications, your legacy applications already deployed on your Kubernetes cluster, and you would like to maybe connect a bunch of services and make them, let's say, serverless ready, then you can use Knetif basically to have all the workloads in a single environment, in a single cluster. If you use, for example, AWS Lambda, you might have some services in this runtime and the other might be in another cluster. So everything in one cluster is a benefit that basically you approach all the workloads in a similar way. You can have the same CI, et cetera. Okay, so let's get started with what we have with Knetif. So this was a CNCF incubating project started in March 2022, and we have seen a lot of community growth. We have a dedicated booth in the project maintenance track for Knetif, and these are the sites where you can read more about Knetif and how you want to work ahead with. So the demo will be focusing more on that. These are the three specific aspects of Knetif currently serving, eventing, and functions. Serving basically is allowing your container to have your applications from scale zero, and eventing is basically monitoring your infrastructure. Let's say you have some events which are there and you want to simulate your applications through the eventing process, you can do that. And functions is something which we are focusing a lot in the demo today, so we'll be having more understanding about how you can do serverless functions and with a vendor agnostic approach. So let's see how that exactly works when we say vendor agnostic. So right now, if you want to deploy a serverless function, it should not be dedicated to a specific cloud provider. It can work on any Kubernetes platform. It can be a raw Kubernetes, or it can be in a hybrid cloud. Let's say it's working on Red Hat OpenShift, Microsoft Azure, AWS, or GCP, and the best advantage is any runtime you want to select to deploy your functions will work out of the box on any cloud provider. So that's a major advantage we are trying to showcase here, and in the demo you will be seeing how we can replicate the same logic onto multiple clouds. To help the developers more, we have also integrated this serverless workflow into multiple ways, like you can do the same using CLI, or you can also do through your ID extensions. So you as a developer need not switch between multiple tools to perform one task. So the idea is if you are a developer who resides in their specific ID, let's say you are comfortable with Visual Studio Code or you are comfortable with IntelliJ. So the idea is you want to do all those serverless tasks directly from your ID. So you have an application, an opening in a workspace, and you want to deploy that application, creating a function, building that function and deploying, everything can be done directly from your ID. So we have dedicated extensions for them, which is known as VS Code Knative and IntelliJ Knative. So it goes by the community name of Knative. So we have a lot of community participants who are contributing to that extension and it has multiple releases across every three weeks. So we are continuously working on that and these are some of the stuffs which will be also focusing in the demo. So right now let's get started with what we have for the demo because that's the most exciting part here. So let's get started with it. So right now if you see, we have an OpenShift running on AWS and we have our application already deployed for the demo, so this will showcase your frontend application, which is written on React and already deployed on OpenShift. If you can see the view, the application is already deployed here. If you click on it, you can see all the routes are already created and it's currently running. So let's go and see how that application currently looks. This is where we have already hosted our application. You can see the URL, it might be a bit smaller, but this is how the application looks. And this is a simple React application which we have written and let's say what's the functionality. So right now I want to search any neighborhood in Amsterdam city and I want to see the latitude and longitude of the area. So let's say right now we are in Amsterdam Rye, so let's type and see. OK, so we have multiple places here which mentions that, so let's type that. OK, so we have got this. So you can see it automatically fetches, and this is the latitude and longitude here. So we have already defined that. So this application is deployed. So the next step is how we can connect multiple functions to it, and we can see, OK, for this location, what's the specific weather. And if we know, OK, what's the specific weather, then we have the second task which we will be showcasing later on. So let's go back to the slides again. So in this demo we already have, as I mentioned, we have a React application with Node.js and a backend, which is already running in a Kubernetes deployment. This deployment is currently open-shift on AWS, but it will also seamlessly work on any Kubernetes platform you have. With this front-end application, the socket.io communication does with the backend which is on Node, and we have a cloud event emitter and the REST APIs which communicate together to send the data given on that street what's the latitude and longitude and what's the weather which will be coming from the functions we have. The REST APIs which basically communicate to the front-end. When I say cloud event, these are some of the examples of how you see the cloud event look like. You can specify what type of endpoint it needs, what type of content it has, it is an application type and you can also pass the exact format here that you want to provide the name, the quantity, the price. It has an SDK which is available across languages from Golang to Node.js Basically the data here contains a payload, what payload we want to pass on to it. The next part comes to the eventing part here. There are three specific types when we talk about eventing. One of them is a broker which is an event mesh. Right now in the demo we will be going through in memory but you can also configure your Kafka or your RabbitMQ instance. The second part comes from the triggering that when you have a workload which is already subscribed to that broker to receive those cloud events, the third one is pretty important here because it does a sync binding. Basically your standard application will be connected to that broker together and your application can listen to all the communications coming from that cloud event through the backend. You can read more about it from the eventing documentation we have. This is how exactly the application looks. Right now what I showcase on the demo this is the frontend app which already has a backend connected to it and now what it will do is do a cloud event emitting to connect to that broker. So let's go to VS code and see how it does. So this is my application which is already open in my visual studio code instance and I have my broker.yaml already open. If you can see these are the configuration which we need to define here and this is the sync binding which will be added to it. So let's run this code and we do sync binding is already created and if you go to the k-native extension so this is the k-native ID extension what we have on visual studio code and the similar experience will be there on IntelliJ also. So let's say if you are a developer who is comfortable more on the IntelliJ side we will have the similar experience and if you see I already have deployed my broker so it will be present here and my sync binding is also added here and if I go to my topology view you can see as soon as previously just having this react application deployed but now it also has the broker and the sync binding connected to it. So I'll pass on to Binik to discuss more about what next we can do with the functions experience. So what you just saw it's the standard application and as I mentioned you can mix your standard applications with the service functions so let's build a function so let's build a function that will tell us what is the weather actually on that location. So what can I do? I can open the K&T view and I just say OK, let's create the function I will call it weather I need to select run time so with the K&T functions we support multiple run times so I will write this function and go and we have several templates so when I was talking about K&T functions it's like this programming model so we offer different templates for the developers so they can just create a function and it will serve the request so it can be template based on HTTP so it will accept incoming HTTP requests or it could parse cloud events because our standard application exposes cloud events we will use the cloud events one and we will just create it in our in our directory so let me just select the location and create a function OK, so and I'll add it to my workspace so as you can see it's visible it's a pretty standard Go function there is a Go mode and the most important thing is this handle.go so basically this is all I need to do to implement the business logic so this is the function signature and it accepts the cloud event and I just need to write the code in here so I will need to fetch the weather information from some endpoint I will cheat a little bit because we don't have much time I will just copy paste the source code but I will explain it a little bit so OK and I will actually deploy this function so I can do it through UI or through this command line so all I need to do is to run func deploy, which is our CLI tool and now it will start building the function image and it will deploy the image what the function does is basically it just calls the API endpoint on this location sends a new cloud event back to the broker with our information about the weather information let me go back to the slide so this is what I was just talking about we have this K&T functions it provides the developer experience and we have the templates and we support multiple runtimes and you can trigger the functions based on HTTP or cloud events so how do we build the function from the source code we are using buildpacks or we can use S2I strategies and we are also planning to add more strategies for building the image so if you don't know what our buildpacks is, it's a cool CNCF project that lets you automate the process of building the container image is based on the runtime that you have so we with the functions provide like the set of runtimes and set of prepared buildpacks builders that will automatically package our application and produce a container image that is ready then it's been pushed to container registry and then it's been deployed as a K&T service so K&T service is one of the components of K&T is the serverless deployment model for the sales application applications and what it provides basically I can just tell it this is my container, it will deploy the container as a K&T service and it will automatically scale my application based on incoming HTTP requests I would like to stop a little bit on here because scaling based on incoming HTTP requests is another simple task because imagine you have your application accepting HTTP requests let's say I'll scale this application to zero replicas and guess what I would like to reach this application so if I do a request I need to somehow catch the incoming request hold it for a while scale out my application and request further down so this is all been handled by K&T for you so you don't need to take care of this there is also separation of code and configuration so let's say I deployed my application in version 1 then I can deploy version 2 and K&T automatically stores let's say snapshot of the configuration so you can easily roll back between the versions or you can even specify multiple traffic splitting about 80% of traffic to my previous version and 20% traffic to my new version so our function is being built by buildpacks as a container and then deployed as a standard K&T service so this is what the application looks like now so the application should send the cloud event to our broker with the coordinates we should connect the weather application to the broker and then it will reply back so our function has been already deployed as you can see in here and it has been already scaled to 0 replicas because there is no traffic I just need to connect my app to this broker so I will connect this function to the broker and because I know that the standard application emits cloud events cloud events let's say some metadata about the cloud event and the payload and there is a field which is called type so I can filter these cloud events based on the type so this is very useful when you are connecting different let's say event providers it could be Kafka, it could be some custom stuff and everything has been bundled as a cloud event so you can imagine the cloud event as a wrapper around your arbitrary workload and you can access the cloud event all the cloud events in a unified way huge benefit so let's filter based on type and I know the type is coordinates and now my function receives the coordinates it queries the endpoint and it receives the metadata and now I need to talk back to my standard application I can do it from the function or I can write another function that will do that for me so let me go back to the VS code and I will create another function this time it will be a node function I will call it a responder so it will respond back to the application and it will also accept the cloud event so it will accept the cloud event from the weather function and it will reply back to my standard application so let's create this function I'll add it to the workspace and again this is the responder and it is very standard node project there is index.js where you need to implement your business logic again I will cheat because we don't have much time so I will I will just copy paste the code and I will put it into my index.js and what we are doing here let me let me so this is the handle function which receives an event and if the event is type of weather which is the one from the function it will send it to the backend on the resend point and that's it so let's deploy this function again all I need to do is to write a func deploy responder and this will build the function and it will it will deploy it on a Kubernetes cluster so if we go back to the slides so this setup this setup should be okay so we are building this responder function that takes the event from the broker and making HTTP request to our app I did the deployment through the command line but we also have the extension where you can for functions you can do this through the ID so you can build the function deploy the function or you can invoke the function invoking the function means that for example you would like to test your function except certain cloud event so you can send the test payload to this directly to this function and this function can run on your cluster or it can run locally so for example this is node application so you can just run npm start it will start on your localhost or you can run it locally in your container so I can see that my application my second function has been deployed so let's quickly check okay my responder function is here so I will also connect it to the broker and I'm interested in cloud event type of weather so that's it so now if I search for an address I hope that we will see some weather information in between so you can see that now we can see the weather information about a specific location I just want to highlight that this is a simple demo so I know that you can do all this stuff maybe in a single application but we just want to showcase how you can use this event driven approach so you can have multiple functions and each function is being scaled based on the specific needs so maybe some part of the application requires higher load some requires lower load so this is the current state so what can we do now so it looks like a very good weather and with a good wind speed so I want to rent a e-bike can you help me with that sure let's write a function for this data or Amsterdam city provides an open data on this endpoint it's in Dutch so I needed to use a translator because I don't speak any Dutch but this particular endpoint is telling me what are the scooters e-scooters available in Amsterdam so we will just query this endpoint we will get the list of the scooters and we will try to find the closest scooters coordinates that we specify in the application so basically we will implement this so we will implement another function that will receive the very same coordinates from the broker and respond back so let's go again I will use Golang because I love Go so let's call this scooters let's use Go again we will use cloud events and we will use directory we will create a function we will edit to reverse space and if you look at the scooters again it's a good function again I will cheat so I will put the implementation in there scooters in here so if we look at the function it's simple it receives the coordinates then it talks to the endpoint and then it checks and the scooter is available because in the rest of the page there is also unavailable scooters and it will sort them by distance and it will give me 5 closest scooters and again I will respond back in a cloud event it will be type of type scooters so let's deploy this deploy this function so right now again it's very simple just provide the business logic and the build packs are building the application by deploying as a as a cognitive service so so we need to wait a little bit in the meantime what we can do we can quickly check again the extension so you can see that I have all the functions here I can see that if they are local or if they are deployed already on the cluster I can deploy them, I can deploy them I can build them here I can see all the eventing infrastructure for plugging all the stuff together and we can see that our function has been deployed so let's quickly check ok, it's here, perfect so I will also connect it to my broker I can do it through the UI I can do it through the command line that we have we have KNCLI for this or I can use YAML file so this type I would like to receive coordinates to this coordinates and also to actually update my responder because my responder function if you recall my responder function just accepts the type of cloud event type of weather I need to extend it with the type of scooters which provides my new my new function so I will need to update this function and build it so is there any other way which you can do this well, yeah, yeah so basically at the moment we are building the function locally because some maybe I don't want to run a broker on my machine I don't want to run podman on my machine or maybe my company doesn't allow me to run this kind of stuff on my machines or I just want to use the CI or something like that so what we can do, we can build a function on a cluster because we have the power in the cluster so let's use this one and how we can achieve that we will approach, we call it on cluster build so on cluster build takes my source code it forwards it to the cluster to a volume and it will initiate the tecton pipeline if you don't know tecton, tecton is a Kubernetes CI let's say and it will execute the pipeline it will build the function again and it will again deploy it as a as a cognitive service what I want to show you today is something a little bit more advanced pipeline is a code so the pipeline definition lives with the source code of my function and I can submit it to the git repository and this function will be automatically built with each commit or each action against this repository so I can easily build the function on cluster triggered from the GitHub so let me update the function again I will cheat a little bit so I just need to add this at this case so in here so in this case I have two cases and I will talk to different endpoint on my on my application so what I need to do I need to configure this function to actually do this stuff so what I need to do I can run this command I can run fun config of the function and I would like to configure git but before I can do it I will actually initiate the git repository on my responder function so I will go to the responder directory and I also have like this so basically what I'm doing I'm just initializing new git repo in this and I've already created a GitHub project so what I did I initiated the git repo and now I need to run my configuration for the git so it will ask me couple of questions it will find the correct URL for the function are we targeting the main branch so we are targeting the main branch we can target multiple branches it could be subpath whatever and this is like it ask me if I want to configure the webhook so it means that it will automatically build the function for me so yes, I won't like to do it and I need to provide my access token so I will copy it and I will just provide the access token sorry, I just need to probably copy paste it the layout is a little bit broken so here it is so what's happening in my source code of repo there are new pipeline definitions created on the cluster the cluster is configured to talk to the GitHub repo and it's been hopefully set up for the action I can see some error, but I hope that it will be work so what I need to do I just need to commit these changes to my git repo so I will commit this stuff and I will publish so if we go to my this is the GitHub repository I will just refresh it and we should see the new code and here is a small action running on this latest commit and it is running the build of the function on my cluster so I will go back to my cluster and switch to pipelines and under pipelines we can see that there is a new pipeline running and it has three tasks so the first task is pulling the git repo the second task is just finished it will build the function using build tags and the third step is to deploy the function so we just need to wait a little bit hopefully it will be so the deploy step is still running and once the function is updated I will see a new revision of my function seems like the demo gods are not with us today but trust me this actually works so let me fall back to my backup solution which is the application that has been deployed in different namespace the very same application and I will show that it actually works so if I select some address now if we go back to the topology view just let me refresh maybe the internet connection is not good it already like forward me like the cosy scooters to this location and really what it does it just talks through these functions do all the stuff so this is the final solution and thanks for the feedback if anyone has any questions feel free to ask so are there any questions yeah there is a question can I hear you can you be louder it is Kubernetes so it's like the Kubernetes scheduler so how fast we can schedule the port but what we can do we can set the minimum replicas to one so we always have one so the function is running and we will just scale out but we are using Kubernetes so there are some drawbacks in this and this is relates to the scheduler any other questions so we are also available at redhat booth so if you have more questions around this feel free to drop by and we will be glad to answer so thank you guys


The measles outbreak was declared over recently after no new cases were diagnosed in the previous 42 days. While a majority of the cases were in counties surrounding the Twin Cities, the outbreak did make its way to Crowing County and Brainerd with four cases of measles. The outbreak also brought the vaccination debate to the forefront, and health officials in the Brainerd area say that the increased awareness in vaccinations led to the end of the outbreak. I think that all of the efforts across the state, you know, here in Crowing County, especially down in the Twin Cities, the Minnesota Department of Health, all of that, you know, increased awareness of the importance of the measles-mumps-rebella vaccine and making it more available to people, getting the word out about how important it was really helped put an end to the outbreak that we had and helped get some of those unimmunized people immunized so that they were not at risk then to contract measles. The measles outbreak affected 79 people in Minnesota with a majority coming from Hennepin County and the large Somali-American population there. If you've enjoyed this segment of Lakeland News, please consider making a tax-deductible contribution to Lakeland Public Television.