 Okay, it's been recorded. Hi everyone. Today we will have a recording of the demo for role strategy performance improvements and the linear folder authorization plugin. It's the middle of the second coding phase. Abhidhe Sharma on the call is a GSOC student working on the project. So Abhidhe, could you please briefly introduce yourself and then we put the presentation. Hi, hi everyone. I'm Abhidhe and I'm working on improving the performance of the role strategy plugin in this Google Summer of Code program. So I'm going to share what I've done in the second phase. I'll just share my screen. It's working. Hi. So today we are going to discuss about the performance improvements that I've made to role strategy plugin and about the new folder authorization plugin that works on folders from the cloud base folder plugin. So let's first start with the improvements to role strategy plugin. So we've done a couple of things which have led to some improvements in the performance. The first thing is before role strategy plugin to 12, for every permission checking request that it got, it used to match all the regular expressions that were there for the roles. Now what we do is we cache the collection of rules internally in the role strategy plugin. This is called a roll map and all of these match the given regular expression. So if you give a folder, let's say called foo, and all the regular expressions from the roles which match the word foo are in this roll map. Now we have a cache for this and the cache gets invalidated whenever a new role is added. This has given us significant improvements in performance. However, this is a tradeoff between CPU time and memory. We keep all of the pre-computed calculations in the memory. We use the jmx benchmarks which were created during the previous phase and we saw improvements of up to 3,300% in getting these matching role maps. Now another thing that we've done is we cache the implying permissions. Jenkins permission model follows a tree-like structure. Each permission can be implied by other permissions. For example, if a permission to read a job is implied by the administrator permission. So the administrator implicitly has the access to read any job. So role strategy plugin used to calculate each of these implying permissions every time for a permission check in the same way that it was calculating the matching roles. Now we store these implying permissions whenever the class is loaded and we store them. A big challenge we had here was handling dangerous permissions. Certain permissions in Jenkins are considered dangerous. For example, the run scripts permission which allows non-administrator users to configure Jenkins. Basically, they could do anything that they wanted. So role strategy plugin supports them as an option for backward compatibility and this option is disabled by default. So whenever dangerous permissions were either enabled or disabled, the cache for the implying permissions needed to be changed because when the permissions are disabled, they are deferred to the Jenkins administer permissions. So we added a hook for whenever there's more changes and we invalidate the entries for dangerous permissions. Now let's discuss about how we measured the performance improvements. We use the GMH benchmarks created during the previous phase of GSOC like I told before and all of these benchmark reports were generated during the pull request build. The results were obtained as JSON files which were visualized using GMH visualizer. I also verified the improvements and performance by running on my own machine and running profiling. Now, so the improvements we can see here, we had multiple benchmarks and so we can see improvements of up to 10,000% in the time taken. So an operation that earlier took 100,000 microseconds, now just takes 1,000 microseconds. This is the best-case scenario. The real-life performance improvements may vary a little but it has been verified that there has been actual improvement to the performance of the plugin. Now we have another plugin which was created during this phase, that's the folder authorization plugin which was created to avoid the problems that role strategy plugin had. First, we removed using regular expressions because they were being a big bottleneck for the performance and it also freezes from having backward compatibility. Role strategy plugin I guess is six or seven years old so it had to cope up with a lot of things that were there earlier. For example, the new plugin does not support dangerous permissions by default and just like role strategy, it supports global roles, folder roles and agent roles. Global roles are just like role strategy plugin and they're applicable everywhere within Jenkins. Folder roles which is what is the namesake of this plugin work on cloud beast folders and they can be assigned to multiple users. So each folder role can give permissions to the users. The permissions granted through a folder role, that is to a folder assigned to the folder role are inherited to all the children of the folder. Agent role allow configuring permissions for agents connected to Jenkins. We have REST API methods for adding and assigning roles and finally we have Jenkins configuration as code support. So this is what a sample YAML configuration for the plugin looks like. So you can have agent roles, you can have multiple agent roles, that's an array of agent roles and similarly you have multiple folder roles and multiple global roles. Now let's go for a quick demo. So here we have our administrator account and we can go to manage Jenkins and then folder authorization strategy. So now this is the screen for adding a global role. Now let's just add one role here, let's say anything and we give the global role, let's say the, let's give the job via permission and we click add role. The role was added and you can see the role being added here and now you can assign the SID of the group or of the user. So Jenkins provides two predefined groups that are authenticated and the anonymous groups which are there by default. Other groups are there from the authorization, from the authentication that's currently running. So we can assign a SID, let's say user2 and we submit it. So we can just see that the SID gets assigned to the role. Similarly we have folder roles, we can choose multiple folders to apply a role here and again we can choose the permissions. Similarly we have agent roles. So now let's see how this plugin works. So user1 has been assigned the delete permission for the agent test too. So if we go to user1's account and we go to test2, you can see the user has the delete permissions but if we go to user, if you go to test1 the user does not have permissions. Similarly I'll show you a demo for folders. So there are three folders here and let's just take a look at global roles first. We give the overall read permission to every authenticated user here and then for user1 we give permission to read the root1 folder and to build the projects in root1 slash child. So that's the child folder that's inside of the root folder. Now let's go back to user1 and sign in. So as you can see first the root2 and root3 are not authorized. This user is not authorized to access root2 and root3 and when we go inside you do not need to specify the permissions independently for the child items. Let's go to job1. The user does not have the build permissions here but if we go to child the user was given this build permission through a folder role and we go to this one and you can just build the folder as user1. Finally I'd like to show the configuration as code working here. So if we go to configuration as code you can just view the configuration. Now some challenges that I faced during this phase. The first was to find an efficient authorization method for these roles. This took a lot of time and thinking for me to come up with and as a benefit global role permission checks now happen in constant time that is big O of 1. Another thing that I wasted a full day on was trying to get JavaScript JSON.stringify to work. So what was happening was prototype.js from Jenkins code changed our prototype to JSON and it was giving some garbage values and we were not being able to exchange the data with the Jenkins server and finally there were some issues with configuration as code not supporting sets. There are two pull requests there. One of them is still a work in progress. Now the next steps would be to improve would be to give more improvements for all strategy plugin and find and improve the UI of the folder authorization plugin. This was the first alpha release of the plugin. So there's a lot to be done here and then we have to write the documentation for it and the 1.0 release for the plugin. Finally I'd like to thank my great mentors Oleg, Runje and Supun and please do share your feedback and comments to me through iZero's strategy plugin get to chat author Jenkins developer mailing list. Thanks. Thanks a lot for the presentation. I put some comments to the meeting notes document about what would be changed but yeah I think it's a great introduction and we should definitely share it with the community. It's really nice to see the progress and yeah I think that in next weeks we can have a wider presentation. So one will be definitely as a part of GSOC phase 2 evaluations and if you want we can also use one of special interest groups to do a presentation. Unfortunately I didn't think about this earlier because here we had a platform special interest group meeting yesterday so maybe it could have been a venue for that but if not we still can use the developer mailing list or whatever to get additional feedback. I think it's already a good start. Thanks a lot for doing that. Thank you. Thanks a lot. Yeah so I would suggest to stop the broadcast now and yep just have a regular meeting discussion or if you want we can keep recording so that others can see that whatever you prefer. Whatever you prefer. Okay let's keep recording if needed we can just cut it for later. Okay. Yeah so just a second let me share my screen. Okay this is my screen? Yeah. Yeah so I put a few comments to the meeting notes. Yeah basically yeah I'll just publish the document a bit but yeah I think it was a really good presentation and we have a lot of time to improve it but even in the current state it would be perfectly fine for the evaluation. Okay so we have a few other topics that we discussed and this one of the topics would be to just review pending pull requests to see why we could help and did you want to discuss any details? The UI perhaps? Yeah so for UI UX I believe there is a special mailing list for or I believe there was a list for UX or maybe it was a list for bloatio. Just a second I believe there was a mailing list. Doesn't get anything I remember. Oh yeah Jenkins UX. Oh I'm not sure how active is it? Well basically they will only yeah there was only one message this year because yeah it was basically all around bloatio but yeah it looks like there are not that many activities in bloatio at the moment but maybe it makes sense to send a message and for example just send your presentation to this channel and yeah as I said before it makes also it also makes sense to send it to the Jenkins developer mailing list. So by sending information to this to the mailing list hopefully there will be some feedback about how it could be improved and we already have some discussions ongoing about for example javascript modernization and for each UI injection they also work on UX related stuff at the moment so maybe they will collaborate with you to make some improvements and I guess on my side it makes sense to do another round of testing this weekend trade you know just an action item for me. So I tried the plugin on Monday basically it worked well for me future wise. Yeah UI could be improved a bit but yeah I think that now the best way is to just create the geo issues right? Yeah so yeah everyone will try to test it and if I hit something I will just report the tickets. Yeah this for dependent stories yeah there are four pen and pull requests so we can also see what we can do about that. Okay sorry if I got sidetracked for UI UX but yeah would this items help or could we do something else about UI UX? Yeah yeah this will help. Yeah right and probably one of the notes is over to using cool plugins because your foreign strategy we already had a discussion about that but at some point I included the jQuery UI plugin and apparently it was a terrible idea so now finally there is a contributor reparner who wants to clean it up so yeah hopefully we will integrate it for all strategy but if you depend on external plugins in folder rows yeah but use new ones for example one which was referenced there for jQuery detached basically it's all to be installed on pretty much every instance of Jenkins so yeah it should be safe enough to use it though it also doesn't seem to be that new which is a good question what's going on there yeah the plugin there but it doesn't look to be really active nowadays probably just that's the job. Yeah so regarding pull requests so at this what we need is a review of these pull requests do you have anything else pending where you need help from mentors pull number three pull request number three you mean here right oh yeah the last one yeah so this one there was an ongoing discussion between you and jessia yeah basically jessie sees that the code is too complicated right yeah yeah so basically what jessie says is that integrations should be simple now in case we have an issue in a whole strategy plugin unlikely we have an issue here as well that we access data open and hence it's not enough to use standard collections in some cases especially when it comes to concurrency so here you basically split configuration and the internal push which we used for performance right yeah when it serializes it uses a hash map when it's not being serialized it's a concurrent hash map this comment I don't think he understood what was going on yeah right it's also my impression so you can just comment there but yeah we see them safely mutable causes yeah it's also a fair point but basically it's what you were hitting before in the discussions that if we have a jink operation as code and other things we would rather make the top level object in mutable if it's possible I'm not sure whether it's yeah the fields are immutable but they can be modified for example the sets so yeah maybe yeah it's a fair point so here jessie basically concerned about creating new object and he suggests just modifying the existing one and the return in the base basically what's written here so he basically what it says is just moving to this constructed logic which is already private so instead of that just doing initialization here so here in the read result you can see to initialize this collection and basically you get the same result as if you were doing the new construct of rights the the roles I mean the global roles and the folder roles are final if it makes any sense so would it be fine if I make it if I make them non-final as long as for the private it's perfectly fine so okay yeah final here firstly it's just quality of life thing I mean it's self-protection so you cannot make mistake while doing any kinds of creation but it's not a silver bullet because yeah even if they are final this collection some modifiable and basically occasional modification of these collections is a much bigger problem than creation of a new instance so here it's no problem if you make them non-final just to resolve this command because yeah it's a valid point and yeah I think you could address that okay and speaking of that do we have any round trip tests for configurations I mean a test which just saves the configuration then loads it and ensures that everything is fine oh yeah there's one test it loads in a configuration yaml and then it verifies it okay but yeah it uses fixed inputs right so it's not yeah it's basically a test for sure maybe it also makes sense to have a round trip test in addition to that so basically when you construct an object then save it then load it and ensure that everything is fine so here you just emulate loading but not the round trip is correct yeah it's just is that for configuration escort or the extreme serialization or maybe actually both so for example what you could do you could pass configuration from configuration as code then load it for example using configuration as code rule then you process this object save it manually to the disk load it and see that the object was intact so you can do this round trip it saves your time so basically it's not as result configuration as code but you can combine them if you want we have some round trip tests in Jenkins but I'm not sure what it applies to pitch mission strategies so here for example a round trip do you need a driver at this yeah so maybe it's something you could just see whether it works for you because you know what it basically does it actually round trips the serializable object or maybe not yeah likely it says it's only the first step but you you could do something like that so yeah this method definitely won't work for your keys I do need to make any notes about the implementation well basically if I should just comment in the pull request this test okay so it's configuration as code but basically this test emulates loading of configuration it's definitely cool to have it but again it's not round trip test so what was my proposal is to ensure that you save the data and then you load the data and everything is correct okay yeah yeah this test is definitely helpful just not for this type of issues it's nice to have this test and thanks for doing them okay so yeah I think this pull request we can land it laterally soon so we just need to address this constructor command here and yeah if you had some test information so jc didn't block this pull request just to translate what jc means there yeah he doesn't like the implementation but he doesn't block it so it means that once you're fine with it we can basically integrate it but it would be nice to get fine over it feedback from jc okay then we could also merge the agent roles one right we could make changes according to whatever to whatever happens here yeah does agent roles depends on the pull request the serialization does yeah we can wait with that yeah I think that this pull request can be quickly merged once we integrate the one above so this one is relatively simple and you all set REST APIs in parallel this is good so one thing for REST APIs sometimes it's better to start documenting them right away so for example here when you add this pull request you can also add documentation for well right now we just have no documentation here but basically what would be a good approach is when you add a feature you just patch documentation in parallel for example if you had a page for REST API there the pull request you could have just added agent REST APIs and it could help you a lot because basically you create documentation on the flight spend less time then yeah then you don't need to recover all the context to write the documentation yeah we actually use these REST API from the UAE yeah but it's also available to users right yeah yeah so it's if it's available to users it's better to document it so role strategy is probably not the best example of that because role strategy has kind of separate REST API calls for internal stuff and for user stuff but yeah here since you have a clean implementation I think it's fine to just okay so yeah for documentation basically if you prefer markdown you can just write it right in the github sometimes it saves time though you can do this in ID one thing is when you consider creating big pages maybe it makes sense to consider ASCII DOC because the main benefit of ASCII DOC that you can use some markers for example here you use table of contents which is not accessible to markdown so if you consider creating big documentation pages maybe it makes sense to think about using ASCII DOC and yeah as additional benefit when you use ASCII DOC you can easily move the content for example to your blog post so it's something to keep in mind when you start writing the documentation basically it's what you like you can use both I should probably note it somewhere something like that on the loop page telling for example because parent it's not trivial to a table of contents even in ASCII DOC when you use github so it's easier when recording a generation but yeah for github it requires some tweaks so apart from this pull request is there anything else I can help you with there's one pull request in configuration is code oh yeah configuration is code yeah this one right yeah so the pull request for sets has been already released I believe yeah we had a discussion on yeah so it's integrated and for independent pull requests yeah basically we need community feedback to make the decision whether we integrate it right yeah and I wanted to discuss whether the nullability these annotations like parameters were not null by default they can get over than when we use nullable or similar annotations um do I consider all those cases and um have an implementation that checks everything like an IDE does or is this fine for now I think that it's fine for now because basically all kinds of this of such patches are best I think anyway because you update the plugin in order to implement the basic of particular use cases so here yeah before that we were just checking whether it has non-null annotation but again even that might be a problem because there are dozens of non-null annotations so it's just fine box libraries it's spot box libraries it's gsr libraries also if you use interchange id you can use gen brains annotation libraries etc and this one just this one particular case so it's not a silver bullet on its own but yeah you just do the best effort so here you improve the situation because you added some additional annotations which were not present before maybe it actually works as a potential country so for example for this one because you change your behavior for all users outside the use case of your release okay yeah I'm just adding commands here but yeah I think that what you did here is good improvement and if you want to improve it more why not but if you find with the current implementation I suggest you keep it as is because you definitely improve the situation it may also make sense to add some customization some customization for these cases but yeah it's up to you um there was also a comment from Joseph he was talking about jsr 305 so he wonders whether he could support that does it forward g7 okay so here here it might make sense to use to support spot box annotations but maybe it's a separate change so yes indeed it makes sense to consider that again it's improvement but it's not the improvement strictly related to what you do because you just used the same annotation as before and then for example it's possible to create a follow-up full request okay so yeah it's just maybe a good solution there would be to just create a follow-up and get a pleasure for that yes okay I think that it's fine as is so I'm happy to approve it okay this discussion we can continue it in the background and maybe if you're interested you could submit a separate full request for that I'm not sure which notations you prefer to use in your plugin but yeah some people start integrating to spot box annotations because there are some license concerns about javax annotations so it might make sense so yeah maybe not immediately go I think that even these parameters are known now by default would have been done in a separate full request okay you improve the situation and you address the keys for your plugins so why not okay so done okay so let's see what Tim and Joseph say because yeah for me it's actually not about fix I would say that it's actually improvement are there any other panic pull requests you would like to review I think that's it for now yeah I had a question to you about the pull request to Jenkins test harness so do you want to work on that in this phase no it's perfectly fine I was just wondering whether you would be interested to integrate it I I think this could be useful but from our tests what has happened was the web client benchmarks they almost remain the same so I think our benchmarks may be wrong or something about it yeah it could be that the the methods they work asynchronously so they give the same result every time we'll have I'll have to investigate that would you prefer to do it during this coding phase or would you prefer to postpone it to the next coding phase so both options are fine with me I think we could take a look in the next coding phase I would first like to get done with the serialization part and writing some documentation for folder authorization yeah okay okay so even if you don't get to this pull request in coding phase three it's not a big deal because well it happens here and there so we can just mark this pull request as tail and then take a look again later eventually or maybe somebody else picks it up so if you don't get to it it happens I'm just about that okay anything else for today I don't think so so one thing so I will be likely off on August 2nd so it's in two weeks but yeah most like won't be able to attend the meeting at the time so depending on the status yeah I think that we can safely skip one meeting at this point because everything is fine but yeah I'll talk to SUP point to Runge if they become active or if we find somebody else to work on the year spot we still keep this meeting maybe I will be off yeah I'd also like to tell about my college opening in August so so I might not be able to work full time because I'll have classes during today but I could work during the evenings and the weekend you mean the entire coding phase three right? not the entire coding phase three I guess it would be in August yeah so that would make it the coding phase three so do you mean the placement which is common for Indian students? uh no that's not placement my classes would start in August oh just classes I had mentioned yeah yeah it's perfectly fine so what is the approximate day when this starts? I think it would be around August I guess the first Monday of August that yeah so it's August keeps yeah yeah I think that's perfectly fine I'll I'll confirm the date I'll just confirm the date let you know okay yeah so what happens that we will need to adjust my meetings right? oh yeah yeah so it's something we can do it's not a problem at all and so maybe building products yeah basically codec phase three can be pretty much relaxed if needed so you already did great progress so if you have classes we can adjust the expectation in terms of how much you work because yeah we still want to have you you to have the weekends we don't want the GSOC to impact your study so we can adjust and probably be more relaxed during this phase but yeah basically it would be nice to have a doodle so that we coordinate the rest of the things uh I think we can have a doodle sometime later because my class timings I think won't be decided until 25th of July okay okay that's perfectly fine so we have enough time again so yeah then basically it means that uh we can just have the discussion on July 26 it's in one week uh but yeah it's a regular meeting so we can just discuss it in one week yeah okay okay yeah thank you thank you so much yeah well thank you too so yeah then I'll stop the broadcast and yeah you can just take a look at the recording if you want we publish it this is if you want we can just cut to the demo part or if you prefer we just don't publish anything so it's your decision you just tell me what option you prefer and I will implement it okay okay so yeah thank you and if you love the treat thanks Tokomeva was watching the recording yep see you later okay thanks bye yeah bye