 now we're starting getting good to the last session of the day before you jump into the happy hour so we're going to spend some time to hear from some of the maintainers some of our key contributors on how you can help how we can be more involved in the project with various all the things you can do to help all the areas where you can help some of the cool things are going on in the project so hand it over to Jesse and Alex to kick it off yes thanks Henry okay um thank you all right I'm just here to kick things off but this session is about how to get started contributing to Argo so we'll go over what it's like to make a code contribution I know it can be pretty daunting and so hopefully this will make things a little more scary but if you do take one thing away from this session is that you don't have to be a developer to contribute to Argo you know we have folks just focusing on documentation marketing security so there's a lot of different areas to contribute and so as you know Argo has two tracks like CD rollouts and workflow events so every week there is a Argo CD rollouts meeting on Thursdays this for it's technical discussions and similarly on workflow it's not every week but workflows has I think bi-weekly meeting on workflow related issues and technical discussions there's and I don't you'll have to look on the calendar for all of these but there's meetings focused specifically on like the UI of course we have like the monthly community meetings which is kind of more targeted for you know more general public and then less main maintainers and other things like marketing committee and even one focus on security so if you're interested in becoming a member if you go to the Argo proge umbrella repo there's a membership markdown file that kind of outlines all the steps that it takes to become like transitioned through like member or reviewer or approver and so there's basically you know we're looking for people who kind of have a continued presence and contribution whether that be in Slack or or issues or answering discussions or and just kind of show that you're in there for the long haul and then you know we proactively meet like try to meet like every least like once a quarter where the maintainers try to identify people in the community that are you know hey I noticed this person is has made a lot of PR so maybe there'd be interested in joining as a member but also if you're interested in being a member just like you know reach out speak to us and say hey what can I do to contribute so I think some some other tips I know it's hard to get attention of maintainers so I find it effective to kind of show up to some of these contributors meetings and and just get in our face and actually raise issues add things to the agenda especially that will you know bring things to the forefront if that meets discussions and we do try to tag issues as good first issues so if you're just kind of looking for things to get started on first thing you should do is you know filter the issues list with the good first issue tag and I think the last part of contributing and I think you'll have a lot to defer to Henrik but we do have like the whole corporate track right corporate contribution but and so you know the code fresh and red hat and the QED like the black brock but if you're if you have a organization a corporate and that wants to get involved we have you know ways to join us there so I think that's all I had Alex is going to start introducing the various people presenting today thank you. Thank you Jesse so one more time I'm Alex and I'm a maintainer of Argo CD project and so we're going to have five speakers today that's why I have a job to introduce all of them and first speaker is Regina Valoshen she actually is not here but she's going to present virtually we have a video record that and Regina she a long time user of Argo CD and she was so excited about the features that Argo CD provides so eventually she decided to contribute and with that I think it's time to play the video and she will introduce herself and tell you her story. Hi everyone my name is Regina and I'm a huge hit of spam I'm also a cloud platform team leader in Bank of Bali since I was a child I was always the only female somewhere the only girl in class one of the few women lecturing in DevOps areas and lately I have become one of the few female open source contributors yes this is a shout out to you ladies to participate as well as you can see I'm also outnumbered in my own family I have a one merge full request to Argo CD repository for such a tiny achievement why is this worth any of your time and why should you even care I want to share my experience as a junior contributor and the great value this journey had both for me and my company Bank of Bali why I decided to become a contributor in 2020 I had an Argo CD performance issue managing remote open shift clusters Alexander Am said a zoom with me to identify the problem he had a fix ready in two days only that was mind-blown the support was much better than for products I pay for and so I decided I must get back but that didn't happen for quite some time and let's see why contributing looked scary and beyond my level I had windows on my laptop I had windows on my laptop I used virtual box and installed a VM but that VM wouldn't start with some weird error and I found nothing about how to fix it so I said an EC2 instance in an AWS account and then I managed to build the code but then I had to spin an IDE I tried to install the ID on the same EC2 instance that was obviously the wrong path at that point I knew nothing about VS code remote extensions so the environment was not working I didn't know going I was afraid of asking stupid questions on slack I was also afraid of living my comfort zone I was even more afraid of touching code that was absolutely new to me so why did I eventually dare them when we started using Argo CD in the bank the UI was only accessed by my team later on the developers required access as well the security team was highly concerned about pod logs being public in the UI they required log access control prior to developers using Argo CD in production and the requirements seemed beneficial for other users as well and so my excuses for not having contributed so far have come to an end living comfort zone in time zone I wrote a proposal for the feature and put it up the shared community meeting agenda documents I checked the date of the meeting four times and the time different five times when I entered the meeting I was two hours late nevertheless luckily they still discussed it without me and decided they want this feature so this is contribution reality VS how it looked like in my mind in the beginning working with fourth repo took longer than I expected I was forgetting to sign off the commits and had to recreate my branch often I also didn't work efficiently with pulling changes from master and so I had to reply my changes frequently the environment set up took longer than I expected however windows on my laptop turned down to be a much smaller problem using tips from both my bank colleagues and the community I installed WSL too with docker for desktop and VS code with remote extensions people actually go that path and it works didn't know go like a much smaller issue I come from a Java background so go lang was quite different for me I chose the path of learning only go basis and then learning more from rgo cd examples even after contributing I still cannot say that I know going well but now I feel comfortable reading and understanding go code asking stupid questions on slack was also a much smaller problem I see that rgo cd maintainers deal with junior contributors all the time and so beginner questions were normal when I was stuck I explored the problem and tried various solutions on my own and I also use the debugger a lot but once those were done and things were still not working I asked for help in the slack contributors channel and people were very responsive and very welcoming they even said zoom sessions with me to help me progress afraid of touching new code also a much smaller problem I programmed by example meaning I started with identifying the components that had similar functionality to what I had to implement and then I followed the code to understand the architecture and the general flow the same about the tasks living by comfort zone turned to be challenging and rewarding next I will cover the inspiring insights from participating in our project which I have partially implemented in my company OSS projects had covered long before we had even heard that words it means that they had to deal with people being remote to each other working in different time zones and hardly sharing an office while the rest of the world started dealing with the remote challenge of sharing knowledge and design decisions and common context effectively only in 2020 OSS projects already have a mature methodology for that this can be argued but as I see this mature methodology is mostly around managing github issues correctly we adopted argocd issues categories and templates I have explored how argocd github issues are categorized and managed and incorporated that in some of our projects so now in my team we have clear categories and templates for the issues we manage and we are in the process of changing the mindset towards making github issues a source of design decisions based on what I have learned from argocd-cicd pipeline we have adopted the following in my team prayer release and release github tags categorized github message merge request commit message prefixes release auto-creation by invoking github API the logs argoc feature was definitely not a good first issue that innocent change turned out to be a breaking change unless explicitly allowed it would have disabled overall UI access to pod logs and so a transition release with a feature gate was needed the change management at configuration upgrade instructions and release blob levels has stopped me from logs why did my pipeline fail new configuration was introduced but no relevant documentation changes were added this was my own for me it makes you rethink automation we will adopt this in the future this is how I felt when my pull request was merged and this is not even health of how excited I was upgrading our argocd to the version with my lines of code so what's next more pull requests for me further promoting OSS contributions in my company so to wrap it up we use OSS because it is successful and because we trust it when we contribute we learn the methodology that makes OSS successful we can then incorporate that methodology in our own companies making our products better contributing is very excited because the whole community benefits from that contributing makes us leave the comfort zone and grow even a small one-time contribution can have a big impact thank you so much for some presentation I'm not sure if it was recorded but if not then we'll just tell Regina how welcome your presentation was okay and our next speaker is Julia Vogel she is going to talk about Albo workflow scope base yeah contributing to Argo workflows and events this is blinking again all right you have a magic shot check up so I'm from workflows and events and I was asked to talk because I have the newbie perspective because I've basically been working on workflows for the last five months for three months before that on events but disclaimer like if anything I say is wrong please feel free to interrupt me you know basically you'll find that all the Argo projects I think are under github.com slash Argo prod and that includes one for Argo workflows one for Argo events if you're looking to contribute maybe you're somebody that already has your own need right you're using it and there's either an enhancement that you want to see that's not getting addressed or maybe there's a bug that you need fixing um so please we welcome all the contributions if you do um but if you don't then uh you know there are plenty that you can find if you go to github issues um just find one that's unassigned uh we ask people to put a thumbs up on any issue um that they're interested in uh so the popular ones have more thumbs up um and then consider a good first issue I'm not sure if everybody knows what that is um but basically there's a tag um you know which if you go to a label I should say so there's a good first issue label there um so yeah I mean there are plenty of code fixes uh bugs bugs and enhancements that could be addressed um but documentation too you know um we have uh our documentation is also on those same repos and that gets published uh to a site that that shows all the documentation so if we want to help us improve that that's definitely welcome okay so before you start fork the repository and create your branch off of that if it is a big change you probably should first uh bring it up like in a github discussion that's also you know on the repo here is this list of discussions here so you can start a discussion or even bring it to one of those um workflows and events to developers meetings that Jesse mentioned um just because you know I've seen people uh submit PRs for features and then the response they get is basically oh well it would have been better if it were done this other way right so I don't want anyone to you know waste time if it's something significant enough you may want to go that route first um okay so while you're making the changes um what you'll find is in our documentation we actually have um we have this developer guide here uh developer guide tab uh and then you know there's a page here called running locally so this gives you you know basically the instructions for for how to run things locally um so like our workflow controller and our our growth server actually run just bare metal on your machine instead of in a uh a separate pod it just makes the development easier right um so yeah if you have questions which I'm sure you will then you know feel free to bring those up in the github discussions that I mentioned before or in these cncf slack channels um and then please you know if do add unit tests um and then if applicable end to end test let me present this so it's easier to see okay so you're ready to submit your pull request you know basically we've just got kind of a checklist of things you need to do first of all pull requests should start with the keyword uh either feet fix docks or chore um and then if there's an issue uh that's either a bug or an enhancement that your pr is tied to then um you know usually writing fixes and then the the number of the issue is good so then it'll automatically you know link them together um sign the commit uh as well um you can look up how to do that and in github if uh you don't know um and then also we have a lot of things that get auto generated uh based on changes um and then things that get checked as well so uh by running this make pre-commit def b you can do all of that stuff um if you don't what tends to happen basically is the ci will run in github on your pr and you'll just see that there are various things that have failed so you can always go and look and see well what did fail and and try to address any issues in there um so one thing to mention is we have so many tests that automatically get run as part of our ci that some of them unfortunately uh fail on occasion due to timing issues and so that's something we want to resolve uh but just note that yeah if you have a ci failure it may be your failure it may not be so um if you think it's not then you can basically issue an empty commit which you can look up if you haven't done that before but um to re-trigger the ci to hopefully get it to pass so just kind of going over the general architecture of argo workflows this might be a little hard to see um but you know really the main thing you need to run argo workflows is the workflow controller itself um you know that's going to basically be looking for your workflow crd objects and you know creating the appropriate pods out of them and everything um you can also run an argo server which enables you to use the ui um and also you know use the rest api and the client sdks which use the rest api but anyway this so this is a general diagram for the different components of argo workflows so by the way this is um in that same why am i not seeing this open let me reload this oh yeah so this is under developer guide as well um if you want to take a closer look at what's in here there are a few diagrams in here um we uh you know your container actually runs as part of a pod which includes three containers so um the one that your container is the user supplied container is running in is called the main container um and then there's also this init container and a wait container so the init container will preload um any incoming parameters or artifacts that uh that the pod needs um as defined in the template um and the wait container will do the reverse and it'll make sure that any output parameters and artifacts get saved off um but if you're looking at any of that stuff that's kind of what's going on under the hood um actually what's interesting is we we take your container and we actually put our process uh we volume mount our process into it and it actually launches your command as a sub process and then yeah so this diagram kind of just shows the main flow of operation within the workflow controller um i mean basically what's happening is there's a queue or i guess a couple of queues that uh the controller is is working on just like you know processing all of these workflow changes um that have occurred so all right just some key files to be aware of uh sorry that's getting pretty detailed but workflow types this is uh kind of where your where the workflow spec is defined controller.go is um sort of the main loop which is you know processing that queue of workflow changes operator.go is called by controller.go to basically process a workflow and then down here argoserver.go is uh you know basically setting up the HTTP listener you know that's listening for messages coming from the UI or from the REST API and then sorry this is the last slide these two slides will probably be more useful for anybody that's looking at the slides later than right now but this is kind of just you know sort of the key directories um within argo workflows um and by the way yeah i'm mentioning argo workflows a lot here i haven't really talked much about argo events i think that's because there's a lot more work to do on hargo workflows um but uh yeah so key directories um you know this command argo is basically where you know the argo cli stuff is uh command argo exec is for the executor which is running in the workflow pods um stocks as self-explanatory examples you know it just has a whole ton of um like workflow yaml files um that you can run uh manifests basically uses customized to uh deploy workflows um in a few different uh scenarios package api client provides uh the REST interface as well as the go sdk which is using the REST interface um server is where the argoserver logic lives and then workflow controller is where all the workflow controller logic lives and i think that's my last slide yeah any questions or anything i don't know if i ran over time but you have time and we plan to open for questions after the after the last speaker so thanks a lot judy for uh sure i would not it's not my experience i think last two slides could be way more useful than you think okay i want to introduce the next speaker uh i cannot see him here for some reason oh then then i could yes he uh contributed a lot of things to argo including making sure each and every person who you know knows about argo so he is going to talk about marketing perfect yes everyone's favorite topic marketing uh so for those that aren't aware we started a program within argo some time ago to introduce special interest groups and the two special interest groups that we created there's already a special interest group for UI which uh someone else is going to talk about and we started a special interest group for security because as you know we've been doing a lot of focus on the project and improving security which also someone else talk about and we also started a special interest group for marketing and that group is responsible for doing things like running argocon and uh managing webinars reviewing blog posts all these kinds of things and so this is a really great area to get involved if you're interested in dev rel um or a lot of i mean i think most of the people here are very technical but you may have people on your team that are less technical that are interested in contributing to open source and in the sig marketing group we have a mix of very technical people and very non-technical people um for example one of the people that helped put on argocon from the code fresh team is uh Sharon and Sharon is not a programmer she doesn't know anything about programming she's an events manager and so she helped organize to make sure that we had the right buildings worked with the cncf all of these kinds of things so the opportunity is there no matter what kind of contributions you want to do if you can't do if you if you were watching that last talk and you were thinking this is too hard if you were unconvinced by the ease of use of that experience and you're thinking i still want to contribute um but maybe i can contribute in a different way maybe i can do more blog posts maybe i can go out and talk about argocon maybe i can help with events maybe i can help run a meetup um any of those kinds of things sig marketing is the place to be and so to get into sig marketing all of the sig information is on the uh on the argocalendar does it is everybody know where the argoproject calendar is raise your hand if you know that there is an argoproject calendar okay so maybe i should have had a slide to tell you where to find that um if you go to github.com slash argoproject slash argoproject it's argoproge slash argoproge it's abbreviated um there's a link to the calendar and you can add that calendar to your google calendar and it will show you all of the argom meetings that are happening the argomaintenor meetings the contributor experience meetings as well as the sig meetings uh sig marketing meets twice monthly i believe i think it's like every other week and then sig mark sig securities like every other week and someone else will talk about sig ui but at any rate um that's the basic pitch any questions about sig marketing no no in-depth technical review of that okay great so with that uh do you want to introduce the next speaker okay thank you two more speakers and one is going to talk about one more uh sig group remington so remington contributes a ton of ui changes in argocg and he's leader of uxc group in in argoprojects thank you welcome everyone uh thank you alex for the introduction uh i'm remington uh and as alex said uh i lead the sig ui group um and so today i'm going to talk a little bit about how to contribute to argo ui um so i want to start off with saying that there are two main ways that you can contribute as dan said it's not always just code um you can contribute in a lot more ways than just code um so on the left here i have the react logo so if you know any react which is code um that's going to be the main way with which you contribute to the argu i but you can also contribute on github which is why i have the github logo um so you can contribute by opening uh github issues by uh contributing to discussions um by creating proposals um and then further in the community meetings um you can come to the sig ui meetings uh you can come to the general contributor meetings to talk about your ui ideas and complaints um as i'm sure there are many uh all right so i'm going to talk a little bit about the current state as well um so first we have the cdui um argocd's ui is fairly mature um and fairly stable as well um we also have the workflows ui uh which has had quite a bit of features uh you'll see later in the presentation i'll show you a little bit of the state of workflows ui um but i think workflows is where we need a lot of help so if you're looking to contribute uh to argu ui please help us in workflows um and then the role s ui which has this dashboard which is relatively new uh as of about a year and a half ago um and it's continuing to improve and evolve uh jesse spoke earlier about how uh the dashboard is uh we hope to add a login feature or authentication rather um and then finally uh this is maybe in the most important area in which you guys can contribute uh so this is the shared library between all of the argu ui's um so cdu workflows and rollouts events doesn't have a ui um but all of these projects use argu ui's repository um and it's also fairly stable but it is fragmented we have um several sets of components that are not shared um so improvement here is going to be improvement for all three of these projects so uh your efforts would be multiplied if you if you do decide to contribute to argu ui um all right so moving on i'm going to talk about three key areas uh i sort of went over two of them already uh but i also want to talk about extensions um but before i do that i would like to speak a little bit about why i think ui is important for argu um so we all know that kubernetes is very complex um and argu has oops oh no oh no oh all right uh argu has uh sort of reduced some of that complexity uh or rather it's introduced abstractions that we all use to leverage the complexity of kubernetes um but argu is also very complex uh and so the ui sort of reduces the cognitive load that is required for using argu and i think that the ui is sort of argu's superpower in a lot of ways um and it is an advantage that we offer that a lot of other projects don't trying to do the same things um and i think it makes argu more powerful um and it makes kubernetes more approachable all right so moving on to the first of my three key points uh so argu workflows as i said it has many features i included the screenshot uh so you can see you know this is almost a dozen sections of the ui and it's becoming very complex and we need contributions uh so if there's one takeaway from this talk please help with argu workflows ui um and i think it's especially important to consider polish because there are a lot of new features that are on the bleeding edge you could say um we need to sort of bring it to a similar state that cd is in where it's relatively mature and stable um so yeah workflows uh we would appreciate help with workflows uh and then for cd as i mentioned it's pretty mature um and it's important to consider that massive changes are going to be jarring to users uh so i think while visual modernization we need to do it uh we should also consider that we should evolve rather than uh offer some sort of revolution to the argu cd ui um and we of course welcome new features as well uh but i will talk about extensions in just a second uh so before you consider adding a brand new feature to argu cd ui maybe consider introducing it as an extension um to help grow this new section of the ui um so moving on to extensions this qr code will link you to the documentation for creating an argu cd extension so feel free to scan it um and if you guys are not aware we introduced extensions relatively recently uh and this is a powerful new way to add functionality to argu cd ui um so essentially i'll show you a screenshot in the next slide but you can extend the ui with your own uh subsets of the ui so your own components uh your own react components and it's pretty easy to to get started with it it's easy to develop them um and there's no need to wait for pr reviews and releases i think uh bala mentioned plugins for argu workflows this is similar uh plugins are sort of beyond ui but this is purely ui and you don't have to wait for us to review your prs because sometimes that can take a while um we're busy and and it might get swept under the rug so this is a really easy way for you even to introduce private functionality uh only for your company so if you have a really specific use case that your company um would like to introduce to the ui you can absolutely do this um and we tend to believe that this is the future of ui for argu um most likely for workflows as well um we'd like to add some sort of extensibility to workflows uh but certainly for cd uh this is where cd is headed because it's so extensible because it's future proof um and i will mention too that argu rollouts dashboard uh it was created as an extension and again i'll show you screenshot in just a second but uh we're also going to be adding application level extensions uh or that's already introduced i think um if it's not introduced already it will be soon um and then sidebar extensions as well this is something in progress so multiple areas of extension and then leo uh also has a pr open for introducing reverse reverse proxy functionality to extensions so this should make it a lot more powerful as well and this is the qr code for that proposal if you guys want to take a look at that reverse proxy proposal uh and here is a screenshot of the rollout extension so as you can see it looks almost identical to the rollout dashboard and that's because it is essentially the rollouts extension is a repackaged version of the rollout dashboard and this is the primary example of an argu cd extension so as you can see you click on a resource in your resource tree uh in one of your argu cd applications uh and there is an extra more tab at the top right you click on that and if you have the extension installed for this specific cr that will be displayed um so that again this is a rollout extension so it's pretty easy to install and you can create extensions like this uh to add more functionality to the ui all right uh so what now um as dan i think mentioned we have the sig ui meeting it's the third wednesday of every month and that's going to be at nine a.m pacific time uh and we welcome you to open new issues or implement uh fixes for old ones um as i said polish is really important so maybe prioritize the bug fixes um but again we do welcome new features and new feature ideas even if you don't want to implement them somebody else probably will so please feel free to open an issue um and then uh you could always help review existing prs uh even if you're not a official maintainer that can uh go ahead and approve a pr to be merged uh feedback is always welcome so feel free to pitch in your two cents this is especially easy with ui um it's usually good practice to include a screenshot if you open a ui pr um so you can always take a look at the screenshot and if you like what you see give it a thumbs up if you don't then feel free to leave a comment um and then we also have the argu sig ui channel in the cncf slack um so feel free to join that and uh pitch in your opinions um and then yeah feel free to come find me to chat i'm always open to talk about ui issues um and to hear new ideas and uh yeah i'm always thinking about this so uh here are a couple qr codes to uh ui issues uh there's a ui label in argu city and in an argu workflows um so these are going to be issue specific to the ui so um feel free to scan these and um thank you thank you so we have one last speaker who is going to talk about the most exciting topic security so please welcome michael okay i unironically love security so i might not be all that relatable but i want to show folks a few ways they can contribute even if you don't like it's super excited about security oh yeah we're gonna keep bad guys out then uh there are ways you can still help the project um you know in huge ways so first i want to show what what dan was talking about with the argu project calendar so if you go to the argu project org and then hit the argu projects append repo scroll down oops we lost it scroll down to the bottom so the magic thing the magic thing okay yes so if you click this you can load the argu project calendar into your calendar for me it was a bit of a trick to get it into outlook but very very worth it because if you're having a slow day at work or whatever you can hop into one of our meetings um and usually there's something interesting going on specifically we have a security meeting um every other week on tuesdays and the only way we know to design features uh particularly security features in a way that one works for you and two doesn't break your stuff is if we hear from you and and you're in the discussions about how we're designing things so uh absolutely drop into the sick security meetings um we'd love to talk with you second thing uh write documentation um right now particularly argu cds documentation and that's mostly what i'm going to focus on a cd it's written in a here's how you get your argu cd setup here's how you create a project here's how you create an application i think that we would really benefit from documentation that is okay you've got all this set up how do you retroactively look at it tell if it's secure and then if not make changes to secure it and the people who can write that documentation the best are the people who have set up their own argu cd instance and have considered how do i get this secure so um we'd love to see prs for that type of documentation if you don't want to put up a pr against argu cd because then you have to know our markdown format then you have to you know work at getting reviews done please write a blog post even if it's a really short simple blog post about your thoughts um i wanted to call out one in particular that i love to see uh denilson nestasio from uh ibm wrote this blog post and i just randomly saw it in a tweet and this is fantastic writing it talks about um how you can harden argu cd instance and the main thing that i loved about it it said you have a default project that most people leave as is in their argu cd instance but that default project isn't locked down and he describes how to lock it down um so simple stuff like this write it up feel free to slack it to me uh tweet about it i'll see it um i want to see how people are thinking about security in their argu cd instances it really helps us if you're more into code and less into docs a couple places where you can start uh are with this projects in the argu cd repo ate a logics recently did a security audit for argu cd and actually for all of the argu products and as part of that they identified some cds we got the cds fixed and the fix is pushed out but they also identified just some like room for improvement areas and we've written all those up into issues some of them are kind of big a few of them are pretty small and simple so drop into this project see if there are any issues that look like you could tackle some of them are just documentation so even if you don't want to write code that's all available for you and there's also a security label for issues that you can narrow down and look at what's available one particular kind of issues issue that i'd like to see if folks are interested in we created a new issue template in the argu cd repo for security logs so we're going to try to identify areas of the code where the logging could benefit from highlighting hi this is security related and here's how closely you should look at this logging event so for example we've started adding logging for when argu cd fails to close a file you can just ignore that error and move on but you could run into issues where your controller is running out of resources so we want to log that event and give admins the opportunity to monitor that and tell if there's potentially a security issue so if there's something that happens in argu cd that you're like i'd want to know about that as a security person then open an issue tell us about it and we can add the structured logging to make it easier for your security folks to find those events let's see one last thing i'm going to talk about is um spend some time and and ask your bosses for time to audit your argu cd instance and sit down and just look at your arbat config and consider how would i attack this consider how you're allowing people to get manifests and resources into kubernetes via git repositories do you lock down your git repositories with code owners files or with github groups just ponder how you would break your security model and then if there are issues then obviously fix them please write about it or create a discussion in the github repo or talk about it in our security meetings if there aren't any issues and you think i just have a really awesome argu cd security setup then please write how you're doing that and blog about it because companies are going to secure their stuff in completely different ways and it's really helpful for us to know what those different ways are so that argu cd can provide first class support for all those different methods of securing uh so that's all i have for security i'll pass it back to alex for q and a and then i think we're going to henrik after you yep after q and a yeah so yeah and yes as michael said it's time for you to ask questions feel free to i guess address it to any of the speakers or to me question but a comment uh somebody left a mac charging cable over here so if you were sitting right over here and you're missing a cable here i think i will you know maybe we'll get it let's go and then story somewhere here okay any any questions about argu yes please the two links you had to the ui cd and workflows did we get that slide back um i don't have it anymore and i will get them in like a couple minutes maybe to provoke some questions i have questions for you like anyone here contributed to argu besides maintainers team awesome so maybe any any stories you want to share about your contribution experience and that can maybe you have a question or request so so yeah so this is we just have a few more minutes available just for any maintainer q and a at all there are a number of maintainers in the room so if it's hey i'm looking for this feature when is that going to be available uh why did you make this architectural decision um that i hate uh why did you do this one that i love um any of those kinds of things roadmap questions yeah actually we're using home to manage our current infrastructure is any way to i see there's a way to integrate home and argu cd uh is it the first class citizen the home uh because it seems that you are describing deployments in in the kind of your own custom way and applications but we really use home to package our application right is that the first class citizen and again uh your question is is helm a first class citizen within argu cd essentially i mean i think so what do you think that's yes so i think maybe there are like two answers one helm is the first class citizen we definitely uh argu cd integrates this helm and let users deploy their applications using helm uh and then we also in another aspect is we have helm charged for argu cd and i'm not sure if you asked about that if uh uh well let me explain it in more detail and speak up a bit and yeah yeah so i am by the way from ea which was really funny cars uh so we do package our applications as a home charge and currently we're doing just simple uh pipelines to deploy them just run simple a helm apply and it goes to Kubernetes right so we want to keep the same feature just package all applications but speech to uh argu has the CI cd yeah let's support it argu cd has two ways to support helm first you can just have your helm charged in git repository point argu cd to the helm charge and it will uh figure out what parameters you can specify it lets you give parameters values uh in the argu cd you are itself without even committing it back to git and also helm like you can use helm repository directly it doesn't have to be committed to git and then 2.5 release that's coming hopefully soon in like a week or two it even supports one additional use case where you can take the helm repository was a git repo and feed a values file from git repo basically combine those two repos to produce your final manifest so yeah i think it's basically the helm is very very supported as much as possible and and uh even like um how most helm hooks are re-implemented within argu there are a few exceptions but like i think helm test isn't interesting but most of them are that's actually yeah since you asked and we don't have that many questions yes helm hooks are supported as well uh except few helm like very specific helm hooks so in particular argu cd don't support tests because it's like it doesn't make sense to run tests uh like there is no room in argu cd world for helm tests and we do not have install uninstall events because it's kind of in git ops you it's hard to say when you're if you're installing complication for the first time or maybe you'll delete it all your resources in production and just reapplying so only those two type of hooks thank you yeah michael i can add something so argu cd uses helm to generate manifest and then it uses those they use qcdl to apply those manifest and cluster if your developers are super used to like using the helm itself man that i think they're helm vans to implicit releases etc that's not available because we don't use helm to actually install releases we just use it to build manifest and then that goes to the vans so a bit of a deaf word for change yeah but luckily once they have argu cd all the applications would be listed as well so you just do argu cd list at list but this is true of the entire like approach to manifest argu cd at the end of the day is just going it's going to end up with manifest to apply through whatever config management tool you're using and argu cd is not really opinionated about that helm is the one that has the most opinion because it has like in the ui like helm repo you know you can actually switch from get to helm repo to specify it but none of the others really require that yeah good question has there been a consideration of expanding the functionality of argu rollouts to more resource types uh not because of the being able to use the metrics of the analysis templates to be able to do things like oh i rolled out any daemon set let's say and based on the metrics now that that things that's generating rollback the previous image but that daemon set was running that type of functionality yeah so the question was is there are there any plans to have argu rollout support resources beyond just basically deployments i think jesse is going to come answer so uh stateful set is i think the second most requested um argu rollout feature after the um auth dashboard um it's it's gonna it would be nice to support it it is gonna be pretty challenging because um if you think about the way rollouts work it's actually implemented as as a drop-in replacement for a deployment resource so it creates and manages replica sets but if you know what a stateful set is like it's it creates pods directly and has things called controller revisions and so it's actually completely different implementation and same history for daemon set and so to implement and support stateful set we we would have to go through that same process of um kind of replicating the the logic we actually import and reuse a lot of logic of upstream Kubernetes for the deployment functionally but we would have to kind of repeat that the other consideration about this is that their rollout is equivalent to deployment but those two other resources are actually you know different resource kinds and you don't want to say a rollout can do both like the the functionality of a daemon set a stateful set and a deployment because you know daemon sets are much more impactful to a cluster so we would have to introduce a daemon set equivalent so with all that said it I think it is kind of a stretch goal I would say and there is some effort to extrapolate some of the reusable components that we did that to kind of lay the groundwork for more easily being able to support those type of stateful workloads but it's I would say it's it's going to be a long road if you have a brilliant idea for how to implement it and want to get started we could probably get you a startup just around that problem it's just some investment money not directly related to that question because it's not actually an auger rollouts thing but there is a really interesting feature coming from the community that hasn't been accepted yet the proposal hasn't been accepted but to support rollouts across application sets which would be more like fleet management yeah and you can follow that so I want to see UI and all the workloads allow you to update parameters or templates and stuff are there any thoughts around being auger to be write that back to Git so being tricky obviously to change parameters write that back to Git or update a workflow write that back to Git yeah so the question is um is there any idea of having the UI so that when you make a change in the UI having that write back to Git instead of just having to change the UI and I think the answer is no but I mean what what would you say because you look like you had a different idea there is a hidden feature actually that's made as kind of hardware so it is possible to create a special file in Git and if you call that file dot argocd dash source then argocd will kind of take a look at this file and it will assume that inside of that file you have a yaml which is application source and it will try to kind of merge parameters from that file into parameters already specified in source during during manifest generation and image of data uses that feature so and basically we didn't get a lot of like requests to to so that the last thing that we have to do is to just teach argocd to manage that file in Git and that kind of gives you like a universal API to change any parameters so basically argocd you don't have to understand if it's customize or have to write changes back to Git because it's all now encapsulated in a single file yeah so I guess if you if you like the idea to teach argocd to do that maybe create an issue and see how many problems that we get but we're kind of close to to support it yeah that's so my answer was no and yours was no but maybe yes yeah the main main problem with the feature is like it's against a little bit against GitTops approach so kind of like some people think it's a controversial way to manage manifests because yeah you get like two source of truth so on one hand you have maybe customization config plus bunch of camel files and it produces your set of manifests but argocd will take the same set of you know configurations and apply this magic file on top and produce you completely different so yeah and maybe I'll just add so I think also with the the extension functionality with combined with the proxying portion of that extensibility I can imagine a world where someone writes in argocd extension with the back end that introduces a button in the in the interface that says like sync this live state to back to Git and then so I think to me I think those type of you know some maybe more controversial features or things that maybe to kind of keep the the argocd from getting bloated I feel like extensions is like the right mechanism in the future to handle these type of things yeah good question other questions question for the workflows maintainers they have left the building the question are any workflows maintainers in the room oh ballah yeah come on up question is why should I use a argo workflows plugin instead of just wrapping up the functionality I'm interested in you know so why use a plug-in instead of just like a regular so like in a lot of cases you want to use my voice is quite loud yeah cool yeah workflows are usually easier for users to use um a plug-in is intended to be um allow you to avoid running pods effectively as part of your workflow so when a plug-in executes a task it spins up a single container I think that lives with the pod with the agent pod and that container executes those tasks in sequence so it uses less resources than a template it doesn't spin pods up and down to complete each task so that's one reason is a different security model as well um and the idea about plugins is they're intended to be a bit more shareable and reusable than workflow templates so you can publish them on the internet and other people can consume them there are more things like uh workflow template is like a namespace code a cluster template you can use it but you cannot give like a privilege to that all the namespace like the access in a cluster template if you install that the plug-in in your controller it will be available for all the namespaces with the multi-tenant talkbanks so you don't need to like name the cluster or template for each namespace giving a permission and everything so we have another one over here yeah yeah I got two questions uh first question there's going to be any more of love given to our workflow catalog so that's a little more no yeah I think it's just genuinely quite hard to make really generically useful work by templates it's a fundamental issue and a catalog requires um curation so it takes quite a long time to curate code fresh made one at the risk of being inappropriate and the event maintainer second question so I have a workflow that does with CICD and it's basically a lift generator do an app set so like different environments are updating like the same file like very rapidly is there any way to like kind of better integrate like uh lots or anything I know there's mutex but like it gets kind of sometimes it bugs out and I get issues with like a merge conflict about like that one file so to have said is there any suggestions there or features so the mutex is the right way to um lock exclusive resources with workflows but that is buggy and that's because I mean it's either you know a file that you just wouldn't fix or if there's a if the tech need for the approaches of using a mutex it's a vicious history maybe you have like a deadlock I think it's doable to do it with the mutex uh maybe I need to do some information on my app I was wondering if there's gonna be any sort of like a bridge do I deal with appset yeah so I have an app set right I have like a one file of all my dev environment for that app like staging production and you know developers are pushing their changes on the grant and stuff like you know concurrently very rapidly so when the workflow triggers like sometimes there can be some sort of issue like for example I got a 502 with a GitHub website and then they tried to retry it and then there are some issues with like I think like the way that we were doing all requests but sometimes there's like like merge conflicts just because like you know maybe they push like very close together like if I think I get out of like a phone like a mutex I just had to retry it but like I always want measures that are why because because you are committing them yeah yeah app set was meant to replace a step of workforce so application set supposed to keep checking if there was a source or two and you have to do and every time it finds something new it's supposed to just start using that maybe one option is to do not use application set and then create applications take offline okay offline discussion you got you got offline because do good of a question um I think we have time for like one more yeah one more one last juicy question yeah uh are there any plans to make the application controller at Argo CD more scalable dynamically oh okay is there going to be plans to make dynamic scalability for Argo CD application controller yeah okay yeah I cannot date you about the progress so there is uh at least we had a plan which is kind of like Argo to execute it but idea was that we introduced the charging which is a way to charge you know have many controllers serving bunch of clusters it was just scary to we just learned that it's kind of expensive to recharge because every time you change the way you assign clusters uh in most cases all controllers has to stop and restart from like from zero that takes like a couple minutes so what we did was we we developed a command that go through all the clusters and tries to decide what's the best way to charge and the idea was to have this CLI command available in Argo CD binary itself and then we were we were hoping to offer people just to have a control that you can run this control maybe like once a day because clusters and won't get added frequently and hopefully the command would just do nothing most of the time if you add a new cluster it would restart and you know provide a better balancing so the current state is uh this full request is pretty much ready to get noticed they're just missing tests and I guess the main reason is not that many people in the world need it like yeah my current problem is that I have maybe like a dozen application controllers and they use a very lopsided amount of resources because not everything is balanced equivalently across all the clusters at a point too so I have to like dynamically sorry I have to size them all for the largest application controller and I would much prefer it if the application controllers could balance among themselves what mode is passed out and also allow them to scale up and down dynamically based on how many applications are running so basically I think I can just um I can promise to find the finisher because it's so close to the area and then as soon as it's yours I think you can just give it a try uh you know like you will get so once it's yours there will be an image in back a half that has this command and it's kind of trivial to you you just need to package it into a drone drop that has permissions to to manage uh stateful sets it also not stateful sets uh it needs permissions just to it's in our CDNM space and that's I guess the biggest it's really difficult to test if it is useful you know if it's effective or not so in theory it should work you know if you test it that will be a big help yeah and then we can document how people should use it and we can refer to your example and say that yeah it did help and then in other things to know about it currently it uses basically the first attempt to implement proper sharding or balancing was to really implement a fancy you know dynamic programming algorithm that tries to iterate for all possible ways to distribute clusters and and provide the best one it works on like 10 clusters if you have like 400 clusters it takes one hour which just doesn't work it so right now there is a kind of primitive way it just tries to assign clusters and pick the best uh yeah so it's kind of naïve implementation but it works and then I was testing it on large number of clusters and it was as good as it was not much of a difference between fancy algorithm so if you're testing for the same then it's good enough how many clusters uh 30 about 30 okay then all right there's a PR to get involved in uh so with that I think we're going to close the Q&A thank you for all of the questions and if you want to track any of us down during the happy hour just you know speak loudly and it makes noise