 There we go. All right, welcome. So this is Google Summer of Code, Get Credentials. It's our second mentoring session. It's the 20th of May, 7.30 AM, India Standard Time. Good morning. Good morning, everyone. Good morning. Good morning. All right, so Harshith, I think you'd mentioned that you had some questions. We could go with those first. And if we could have you share your screen or I can share screen, whatever you'd prefer. Screen with the document. If it helps with your questions, whatever questions you have. OK, so my first thought was regarding the snippet we have to generate for the working of the get credential, like we have to generate a separate snippet in the pipeline syntax. We won't be using the with credential binding snippet, right? I was assuming we would use with credentials and just add a new type. So today we've got what is it? Username and we've got username password and we've got private key. And I was assuming we would have a get username and password and a get private key as the type so that we know when they give that argument that we need to set the collection of what we need to set the correct get variables to allow that to work for command line get. So I was assuming we would use with credentials. But so that means, Mark, that we would add that in the credentials binding plugin. That was my assumption. Right. So this moves from get. So that means that because I was under the impression that the proposal said that we're doing it in the get client with a new step with get. OK, all right. And I had I had not caught that in the OK. So harsh. Maybe we do need to share your share the proposal. Let's take a look at it. So that's maybe I'm just I'm off base there. Thanks. Thanks for highlighting that, Rishabh. So no, no, I'm sorry, Mark. I was I think there was a discussion there that it could be done in the get in the credentials binding plugin or there could be I think in the project idea, we said that we could create a new step. But then hardship recommended that we could do it within the credentials binding plugin. So yeah, it'll be best if we just confirm that from and maybe we could discuss which one is a better approach and what's her shit's idea on that. I thought of making the good plug in compatible with the pipeline. So we could work on that. The good credential plugin I thought I was taking as a reference rather than working on that. And I guess if I remember correctly, I think technically if if we wanted this to be in with credentials, you could provide a new credentials type. So you'd provide a new limitation of a credential type. And I think you could potentially put that in either space. So maybe that's where. Finding the right spaces, maybe what we're centering on, is that? Well, yeah, so so OK, so so I was maybe maybe that's where I've misunderstood the credential system. Everyone OK if I share my screen for just a minute to have something concrete to talk to. Yeah, because this way I've got I've got a Jenkins instance that I can we can talk to and and reduce number of mistakes that I may be making. OK, so. And I stood up my docker if I if I need to explain that. Excellent. OK, so so what I what I have, for instance, here is a here is a freestyle. Let's see. No, we do we want freestyle or do we want? Oh, no, we want a we want a pipeline job. So here is a pipeline job that builds the get plug in and runs its tests. And in this, I was assuming we would do with credentials. Oops, where is the credentials with credentials at a binding at a new thing here that would allow us to do to do. Um, what do you call it to do? I get SSH private user private key. But Justin, I think is your point that these are in fact a list of credential types. And so what my idea was mistakenly saying we needed to create a new credential type. Yeah, yeah, I think well, I think you're saying you need to create a new credential type rate. Like that's essentially what you need to do. And I think credentials binding is maybe I'll look those up if I remember correctly. OK, so then and that that sounded to me. That sounds to me like more work or different work than I was expecting. My apologies for not having thought that through. So so what that says is because I was assuming I want to use as a user. I want to use one of my existing private keys. I don't want to have to create a new credential that is this this other private key. And so I wanted it to allow me to use any old private key. And and if we implement it, if if Harshith implements it as a new credential type, I'll have to define that new credential when I with potentially containing the same private key. But I will have to define that. Right. That's my understanding. OK, so that all right. Well, so then Harshith, it sounds like I had the wrong concept. Maybe we stop sharing my screen and have you you share your concept and let's let's be sure we understand each other. So you were envisioning implementing it in the get plug in. Yeah. Why? So this is your project proposal. Yeah, that may be that may be the best. Let's look at it again. I apologize. I thought I had understood in quite depth and obviously I was mistaken. Go ahead. And it makes sense to look from a point of view. The love and it makes sense that we are we if we're creating new bindings, we would do it in the credentials binding plugin. Because it is the place where the bindings are. Right. So if we're creating new bindings, well, yeah. Not exactly. OK, I think that you get new bindings from other plugins. So like I think Mark had a Docker credential. And I think that that credential type actually comes from the Docker plugin when that's installed in the credential binding plugin. If I remember right, is just looking up types of credentials. Yeah. So so I guess conceptually, Justin, what you're saying is that a credential binding for get SSH private key here could be written in the get plug in or the get client plug in. It would then be found by the credentials binding plug in and displayed to the user. But it would be a separate credential type, wouldn't it? Right. Right. OK. All right. So that that shows my my ignorance in writing the project idea. OK, Harsh, so that's I mean, I think you're fairly general. So I think you're good. Actually, I read it that way from your proposal. You're all good, man. OK. And I guess I guess it's it's acceptable to do a new credential type, and that does have the benefit that it would be implemented in the get client plug in or the get plug in. So, Harsh, is that what you were envisioning as you were? No, I thought if we use the get credential binding plugin, then we have to use the get client plug in to perform the authentication operations. Then get plug in won't be that much of use. Get client plug in will be of more use in that case. And that is just fine. Placing a get client plug in makes makes a makes a lot of sense that that would if that's because they they travel as a pair, right? I I always if I've got the get plug in installed, I must have the get client plug in installed. And so so that's not not a problem. That would be great. Yeah, and and I also acknowledge like there may be good reasons to even put it in the credential binding plug in. I'm not aware of where like I'm looking for you to define kind of where that goes. I think that some of these other ones went in the credential binding plug in because they were useful for generally like lots of plug in. So like I think that's where, you know, we have the username password and SSH private here and there. But I think you'll also find that other plugins maybe contribute additional credentials once that plug is installed into Jenkins. Then it will see that additional credential type. That makes sense. Yes, I'll note that maybe hazy on this, too. So so please feel free to say that. Hey, Justin, you're out of date. Listen, I had a doubt and please correct me if I'm wrong. So if my credentials are something that many plugins could use, then definitely I would add it in the credentials binding plug in. But if I know that it's specific to my plug in and it's not necessary for others to be available with, then I would add it to my own implementation in my own project. Right. Yeah, I think that makes sense. I mean, if you even think of it from a user perspective. So if I don't have any plugins installed on my Jenkins instance, should I have a Git credential type? That makes sense, yes. And that's going to the fancy. Like again, like if it makes good sense for it not to be in the Git plugin and there's a good explanation for that, I don't think we have to go that far and say we have the perfect thing that's beautiful and meets all of the things like. But my understanding is that probably should just work itself out. OK, so then then I think what so is this a case where one of the questions to harsh it would be explore. A implementing a implement. Whoops. Explore. Implementing. Well, but OK, now I'm going to I'm going to pull back then, Justin, because I'm going to harsh it. Are you OK if I stop sharing sharing your screen and share mine? Yeah, I wanted to show Jenkins again, just or if you've got a Jenkins up, I could I could have we could have you share your your Jenkins. This is another PC. I don't have in this. OK, so so then I'm going to start sharing mine. Oh, you can see hopefully you can see it now. OK. So so when I do this binding, there is user and password username and password conjoined and user and username and password separated. Aren't those both representations of a username password because there isn't a separate. Credential that is username and password conjoined, right? The only credentials types that I've got are username username slash password and private key, well, private key and a few others. So it doesn't that hint that at least the credentials binding plug-in has a way to represent one credential in two different forms. Yeah, so I see two implementations. Sorry, I'm sorry to interrupt. I was just looking at the credentials binding plug-in and I seek two implementations for the user password binding. It's a user password binding and it's user password multi binding. Could it be the two you're talking about the conjoined and I think so. I think so. What you're seeing is two implementations. When you look inside those implementations, are they both using the same base credential type? The same base Jenkins credential type username Maybe maybe maybe it's worth us looking at those. OK, so that was yeah. Yeah, so I because a lot of this is based on the type system. So I think that's what's happening there, but we should look at it. Yeah, again, I definitely acknowledge that I could be I could be out of date. So OK, so you, Rishabh, it was in. Implementation, so here we've got username password binding, which does a. Uses a standard username password credentials class. Yes, I think both of those use that one. OK, and so if and now if we look at multi binding, you would think it's probably the same thing standard. OK, good. All right. So that gives me a look up on that credentials ID. And then they just represent it differently as variables. So it's kind of like a bridge between the actual credential and. Like the downstream. Step, right, right. So OK, so and that that was that now you're you're that's, for instance, this M dot put here. Sorry, is that big enough for people to read there? This M dot put is is sort of that specific implementation you're describing, right in the in the bind here. It's saying, OK, we're going to us create a variable for username, and it's going to have this value. And yeah, it's going to look up on 75. What was that on 75? It's doing the look up. Yeah, so here it goes and grabs that credential. So now. I think this may have removed my my earlier worry. About, oh, dear, are we going to have to add a new credential type? I think we don't because can't the same thing work here for the SSH user private key binding? Harshith would create a new maybe call it get SSH private user private key binding or SSH user private key binding for get or something and then add additional things in the bind step here that are specific to. What command line get needs in order to find that private key so I get SSH command environment variable or those kinds of things because because this is doing that same get credentials that you mentioned earlier, Justin, isn't it? Yeah, I guess the only edge case I could see there potentially is like someone puts and maybe this is what you're saying is like I think you're looking for a super type of this that would do all the same things as this subtype. Sorry, that would do all the same things as this, but it would also have that extra extra stuff. I think we probably would want. Folks to say this is actually is a get private key and this is not. Right. And maybe that's getting a little too extra. Well, see, I was I think at least for me, I don't want to have to say that this thing is a get private key because I'm already using private keys in lots of places for get. Right. There are most of the cases where I use private keys already or forget and I don't want to have to define a new credential just to be able to use it with this new capability that Harshith is going to implement. So for me, I like it that that this that the. SSH user private key binding or I assume a class maybe derived from it. I don't know how the implementations look is is the multi binding a derivative of the other one. So the challenge there, though, is that I think you're going to need to fill in another variable. And so I think you if I understand correctly. We're trying to fill in another variable, which is the get version. Right. Well, what we're trying, what one of the things we have to do is at a minimum. So for the SSH case at a minimum, we have to define the SSH. What is the SSH command? I there's the get SSH command environment variable, which includes in it. The SSH command we use and that SSH command has the path to the private key file. So so yes, there is we have to do an additional environment variable for the the get version of this. And in this one, we've got to do an additional environment variable, at least one for how do we transmit the the username password to the user or to the to the get command. Right. But it's just derived. It's not something that the user has to fill in, right? Correct. Right. It is just derived. Yes, you're absolutely correct. In fact, we don't want the user to have to think about it. It should just be done inside the code. Now, Harsh, we've had a lot of conversations between your three mentors and you haven't you haven't said anything. So stop us and let's let's talk about what what questions do you have and what do you need to know? Harsh, we're not hearing you. Sorry, I mean, Mark, can you share the screen again? Oh, you bet. Sure. So till now, what I understand is that we have to create a separate wine binding named like a potential SSH, something like that. And we have to dive it from the SSH user and perform it for basic get tasks. That was that was my assumption. And that's where Justin tell me if we're so Justin, Justin's concept was no, it would be best if we had a separate credential type. And I'm still not not entirely sure I understand it. But Harsh, you do. Harsh, you described what I was thinking is that there would be some special specialized version of this, not SSH user private key, but get something. Get SSH user private key binding. That would be the that would know how to do get. But it would use the standard or the SSH private key credentials that are already available. It wouldn't define its own SSH private key credential type. Yeah, I think that makes sense. And it would just do the special things that it needs to do to be the get type of that. Yep. So so that's that's one of it. Back to the let's see. Where was the that that project idea you had shared it? I think you were sharing the project idea from the Jenkins that IOS site. Weren't you, Harsh? So if I go to project ideas, that's not it. Sorry. There we go. Project ideas and here when this thing. Was describing get SSH private key. That was the kind of idea I was at least mentally thinking was it would be a class like this one, but not this one. So it would be this one plus some additional capabilities. And then then this one was the same kind of idea. Based on I don't know if it should be based on multi binding or binding, I'm not sure and that I think we would need you to investigate which of those two is the better choice in terms of getting delivering the information to command line get. And I think that we implementing these two bindings what we need in the Git Client Plugin would be easier for Harsh because then we would have the Git Client APS within although we could do the same in the Git Credentials Plugin as well, but sorry, the Credentials Binding Plugin, but very easy within that ecosystem. And I think that's a good point. Which location should do it is a very good point, right? Because just as Justin noted, as Justin noted, this Docker Client Certificate doesn't have any implementation here, right? There's no mention of Docker anywhere in the Credential Binding Plugin. So that must be coming from another plugin. So I think you've got a very good point, Rishabh, that the Git Client Plugin may be a great place to put this and it could then use the implementation, borrow from these implementations or extend them or whatever makes sense there. Yes, and I think Justin also made the point that without the Git Plugin, would we want those Credentials? Right, right. If I'm not a Git user, why should I have a dropdown here which offers me a Git Binding? Yeah, good point. So it sounds like Rishabh is suggesting and Justin, it sounds like you'd be okay that Harsh, your idea, let's put it in the Git Client Plugin rather than putting it in the Credentials Binding Plugin or the proposal is let's have you put it into the Git Client Plugin. That has the benefit that I'm a maintainer of the Git Client Plugin. I can merge your changes if you propose them. We don't have to go to ask anybody else. So that's a real incentive for us to choose the Git Client Plugin as the destination. Yeah, that's good. Yeah, and I think it has those other benefits too. So, I mean, most people are probably going to have Git on their Jenkins, but some people might not and it kind of fits nicely and I think it also would be convenient for Harsh. Yeah, just so everyone's clear. A Jenkins without Git is actually immoral. I don't know why anyone would have, but sorry. Just kidding, just kidding. My team foundation server friends really like their server. Perforce. Yes, that's another one. I loved working with Perforce. That was great. I enjoyed that very much years ago. Okay, so, Harsh, does that piece, maybe I should make a note here in the note. So, after discussion, it seems best to implement the two credential bindings in the Git Client Plugin. Visible only if Git Client is installed. And it's a plugin that we're maintainers of. We can merge without, without others. Good. Are you okay with that? Yeah. I added a convenient access to the credential type within the plugin also. Right. Makes sense. Very good. Okay. Not that big of a deal, but. Ciclic dependency potentially. Mm hmm. Yeah. Now, now this probably means, okay, does this mean that we have. That will mean either an explicit. Dependency from Git Client to credentials binding. So this will be a new dependency, right? No, if the, if the. I don't think you're going to need to depend on it if you're not already. Okay. Well, you might already have a dependency already because of these types. Well, it certainly has a dependency on credentials, but they're provided by the credentials plugin, not by the binding plugin. Right. Yeah. And I think you're going to ditch this dependency because you only need to depend on your credential type. Yeah, I don't need credentials binding. Well, but, but I was, I was assuming that some, some place in the get plugin, it will have to reference. This notion of a multi binding. Or. But you would need the SSH user private key potentially, unless we type on this. So, so if I subtype on this, then I am definitely going to depend on, on the credentials binding plugin. But I mean, that makes sense. You can't have this unless we depend on it. And then it's that, that's, that's fair. Right. If, if you want this functionality and, and we've got many users who want it, then they need credentials binding. That's good. Yeah. Yeah, I think that makes sense. Okay. I mean, actually I'm kind of would be surprised if they don't already have to do that anyways already. Oh, okay. All right. So it may be that they've, they're already dependent on it. Okay. So, okay, but so there is a mistake here in this statement, it says implemented in the get plugin. Harsh, you correctly noted, no, it's the get client plugin that needs this, not really and Rishabh, you're, you agreed and Justin as well, that it should be in the get client plugin, not in the get plugin. Yeah. Okay. So actually while I was thinking about it, I was thinking more in terms of get client plugin or the credentials binding plugin, but within the get plugin in the get client plugin. I am not sure if there's a preference there for me, or I would have to think about it. We'll see the, the, the CLI get API implementation is down in the get client. And so it's the thing that knows lots about how to do, how to communicate credentials to command line get. And since it knows how to communicate credentials, the command line get, it's, it makes sense to me, it really should be the get client plugin. I should have thought of that when I was drafting this idea. It, I think get client plugin makes more sense. Yeah. Yeah, I would agree. Yes. Hmm. And also, I can, in the get SCM class, I can see that we are using the credentials, standard username credentials and standard username password credentials, which is coming from a cloud page. Is it, is it the credentials plugin? It is right. Yeah. So, so how I'll call that out again, it was, you said it was a standard username password credential. Yeah, standard username credentials and standard username password credentials. Yeah, it looks like the get plugin and the get client plugin both just depend on credentials and SSH credentials. Right. So this will. So Harshad will add a new dependency on credentials binding and then we'll use that dependency to implement an SSH username credit, multi binding or binding whichever. And then we'll use that for this one and, and, or a username binding and then an SSH one for this one. You might look into whether you need that too though. You might be able to just directly leverage the same underlying ones and you may need multi binding. So you, you might be able to just get away with doing that look up like these do potentially. Sorry. I'm not sure what that's going to look like. So that's where I'm going to look for, for you to do the some work, but does that make sense? What I'm saying to anyone. Could you explain that one? I don't understand it completely. Yeah, so these credential pipes are basically extending a multi binding, which is also a credentials binding thing. But they're extending multi binding, which is a wide standard username password credentials. The get client and get just look at the credentials plugin classes. You may be able to get away with just doing a credentials look up. I think get credentials. See where does get credentials come from that method. I think. Does that come from credentials binding? I think it looks like it's coming from binding that Java in this class or multi binding. It is within the. It's inside the inside this. Right. By the way, I've never used GitHub's browser. I'm very impressed. That was much better than I expected. So this is inside the credentials binding plugin. Yeah. So I mean, you could. We could decide whether we want to take a dependency on this and I'll, I'll mostly leave that to you. Yeah. The dependency is just fine. Me just, it was good for me to understand it because that makes sense. It should. And I think it's perfectly reasonable that we, that Harsher will add a dependency on credentials binding plugin into the get client plugin. Cool. Makes sense. Because if we're going, go ahead. No, no, I'm sorry. Okay. I was just saying that. This, this should be a good exercise for Harsher for the design document is what we're discussing here is essentially how we're going to design. Those implementations for the potential. So, right. Good point that. Okay. So this is. Good topic to describe in the detailed design document. Yeah. Implement. Two bindings. In get client plugin to credential bindings. And then the question is, is it. Which are the best. What would you call it? Best classes to use as the model for it. Or as the, so is it. Yeah. Harsher could answer those questions or try to explore those. Right. Yeah. Yeah. I don't think y'all have a hard time. Kind of understanding what's going on here. But definitely let us know if you have questions. I don't think there's a lot of code in these is what kind of what I'm getting at. Right. And to expand on that slightly is like. Yeah. So the other option could be that you decide that it's not worth taking on the dependency to this exact class. And maybe it makes sense to have. You know, another class that extends binding or multibinding from. From the credential finding plugin. Use your imagination. Up to you. I think that we should. Need another class. I don't think we should take this from. The previous classes. I think the question is if you want to build your binding on top of what the binding provides, or do you want to. Start fresh and just use the credentials API. That's what we're getting at. Right. Right. I think so. So this one. Yeah. At least that was my idea. My thought was. If, if it's more convenient to extend the class so that. Effectively you're borrowing all of the implementation that's inside here. Great. Now. Or is this. Yeah. So. That'll be an interesting to see what that means. I suspect with this. At symbol, it probably means you, you, you cannot. Simply extend it. Right. Or if you do, you have to provide a replacement descriptor. You have to implement a descriptor inside your replacement. I'm not as fluent in these at symbol things as I should be. Yeah. I don't, I think it may yell at you for. Having duplicate symbols. Right. So, so, but that, that hardship is certainly a piece for the. Just, I think you were asking the question. Extend it or implement. Separately is, is the question. Implementation, implementing. Sorry, ask implementation or implementing. And then I missed. What was the rest. Implementing a separate class. Right. Credentials would be a better idea rather than extending it. The extending previous one, the user password, multi binding or the user password binding. And that, I think that's a good thing for you to explore in the design document that very good. Any other topics. Any other questions you'd like to discuss, harsha. No, but can I walk through the, what I understand from today's session. Yes, please. Absolutely. Okay. So. So, our basic idea is to make a dependency of grid credential binding in the client plugin. And we have to, I have to explore more on the classes. On the class of what I have to implement. Either a new class or extend the previous one. Also, the class that, that will be created if I implement a new one that we use in the, using the credential binding plugin. I think so. So say that again, could you, did I, did I capture what you said correctly? Yeah, so I thought, so we have to create a separate class to implement the functionality of the Git operations in the client, in the credential plugin. And then we can like use that dependency in the grid client plugin to perform the authentication operations. Okay. Now, now that one, I, I'm not sure. I think you mentioned something about the credentials plugin. Did I miss, misunderstand that? I don't think you need to modify the credentials plugin at all in this case. Say that, could you say that again? Okay. I thought like the good, good client plugin will taking the credential binding as a dependency and the credential. I was thinking of creating a new class in the credential binding, which would be specific for the Git operations. And then that could relate to the Git client plugin, client plugin for the low level operations. Yeah. So, and I think that new credentials binding class actually would be in the Git client plugin rather than in the, in the credentials binding plugin. So, so say that again. Let's keep talking. Say that again. I mean, if the class is in the credential, in the client plugin, then. It's okay to think out loud. You can. Yes. It's a good exercise. So basically you're measuring the pros and cons of implementing the binding on the Git client plugin or the credentials binding. Right. Yeah. So as we, as Justin pointed out initially, since this binding will be closely associated to the Git plugin and its users, would it be beneficial for us to implement it in the credentials binding plugin? Be available for all of the plugins? You know, the implementation will be in the Git client plugin, but I am a bit confused upon how we will use the Git credential binding as a dependency. We are using the Git credential, sorry, the credential binding plugin just to display the option of a Git credential binding and then the snippet would be generated and that, that would be used in the pipeline and the Git client plugin will perform the operation in the back end. So I think the dependency on the Git, on the credentials binding plugin is more for taking in that the binding and multibinding classes that you can extend from because those are actually credentials binding plugin classes. Does that make sense? I need to look at the code. Sure, no worries. And maybe that's, maybe that's what, yeah, as you're doing the document and stuff, like definitely feel free to like play around with code and like see what kind of makes sense, try and see if you can get some of the stuff working and stuff like that. Yeah. Yeah. So Harsh, I thought maybe you were asking this question is how does the credentials binding plugin find the new credentials binding class that's implemented in the Git client plugin? Did I, or are you already comfortable with the answer to that question? I need to look at the, I will tell you, I need to look at the code also, I need to do some research on this. Yeah, well, and as far as I understand it, what it does is it, Justin, you, I suspect know this far better than I do. It uses Java's own ability to look at itself, to introspect, to find all implementations of a particular interface. I think that's what it's doing, isn't it? Or an all extension implementation of an extension point. And so because this Docker client certificate, even though it's not actually implemented inside the credentials binding plugin, credentials binding finds it by searching in the currently running Jenkins. And so that's how Git client plugin will provide it as well, it'll just be found automatically. Justin, did I describe that correctly? Yeah, if I remember right, I think there's like an extensions registry that Jenkins has that registers these types of classes and but yeah, it's essentially using a form of reflection. I think it's a registry in Jenkins, if I remember right, but it might just be reflection. Okay, so it's not even anything as exotic as introspection or reflection, it's just go look it up and everybody registers when they come in, okay. I think so, but it might at the end of the day just be reflection too. Similar thing, similar, similar setup. So one quick way to test that out first it would be just create a class where you extend the binding from the credentials binding plugin and see if you can create the descriptive implementation there and if you can see that in the list of credentials. Harshit, have you run a, have you done the Maven HPI run stuff within a plugin? Because that's super useful for testing things out like this, if that makes sense. Yeah. Okay, cool. You already know, excellent. Okay, that's, that's very, very good. It took me an embarrassingly long time to read, to discover that thing. Me too. Oh, nice hyperlink, Justin, very good. Love the links. Excellent. Okay. So, how should other, oh, I guess I have a question before we're approaching the end of our hour. I have another question in terms of what are good times to meet and I've got. So let's see, good times to meet. And Mark's news. So does this, this time I think we decided works reasonably which, which days work, work well. I'm not available. Let's see today is Wednesday. Is that right? I'm not available tomorrow at this time. And then I'm gone to go visit my grandchildren until Monday. But I could meet our till next Tuesday, India time. I could meet next Tuesday. I could also do next Thursday could do both. What works well for others. I could do, but you're talking about Tuesday evening seven. Yes, right. Exactly. Next Tuesday at this same time next Thursday at this. Oh, sorry. And when I say Justin, this, this is complicated. When I say Tuesday, I'm talking India standard time. So you and me Monday. Oh, okay. And, and Thursday would be Wednesday for us. I think either of those would work for me. So. Do those two days work for you? You know, yes. Is there another day or time that's better for you? This is this timing is okay, but if we have to decide, then it should be in the evening in IST. Oh, evening IST is better for you. Yeah, or early in the morning or evening. I guess to the two options for me. Okay. So early evening IST. For me at least tends to collide with my business meetings with my colleagues in Europe. So because early evening IST for is early morning. Mountain time for me here in your Denver. Okay. Let's see. I'm going to bring up a calendar. Just a minute. So if we look here at. Next week. So right now it is. 3am utc. Okay, so if we look at next week's calendar thinking about. There's 3am utc. Oops. Or. Okay. I think it should be roughly 12 hours. 12 hours offset. Harsh it that would work well for you. If you wanted to do evening IST. Yeah. No, I mean, I'm okay with the evening and morning both. Oh, you are. Okay. Yeah. For the majority. If everyone is okay, then we could decide on that. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. So my, my evenings are much more open than my mornings are. So for me evenings, these, the time we're doing now works much better for me. Justin, you're, you're, are you okay with. If it's okay with everyone. I don't have a problem with the morning, but I'm not a morning person. That is why I'm saying that, but it's okay. I can be. Yeah. I mean, I, I definitely want to support. Kind of harsher than the majority. I can, I can make this time work. No problem. Morning works for me also. If that's something that we want to go for, but yeah, this works. This time works. Well, okay. So if. If morning works for you, then maybe what we do, because the next piece is I've harsher. I'm, I have been approved to donate a kidney. To my nephew. And I will go offline. June the ninth. For surgery. And so, so we're going to look for somebody else to act as the third mentor here. But Reshab and, and Justin would do it. So maybe we should go for mornings. Try to find two mornings that work. And that way we're not, we're not in convince inconveniencing Reshab. And Justin, you said you don't mind mornings. Mornings are okay for you. Yeah. I can't do nine a.m. my time. So we can work. We can work around the times. I think. So we're going to look for somebody else to act as the third mentor here. So we can work, we can work around the times, I think probably, but I think we were normally doing like a little earlier than that anyway. So I'm assuming that's kind of like what we would be talking about in terms of time. And it's totally fine for me to not break. To not, you know, it's okay for the time we have right now, if that's what Justin and Mark, you both have. You're comfortable with I can be, it's okay. It's not like I have a problem. I am free at this time. I don't have a problem. Yeah. And that's very kind of you. The notion I was thinking is that. It may be easier on Justin to do it during his working day. And then he's still got his evenings free. So. I'm kind of okay. The way really. I don't want to make, make anything. Difficult. Okay. So then. Yeah. I was just saying, I am the same notion. Oh, you're, you're both very kind. That's great. Well, so then, then I'm going to admit that for the next, for the next meeting, I'm going to put it at the same time. Perfect. And, and we wait a sec, wait a sec. Maybe I just lied because I think I may have a collision already. Because. Now you're committed, sir. Yeah, exactly. See, see it's what I've got is next time is next Monday is Doc's office hours. And it collides with this time. Yeah. So, so I would need to do this on. Wednesday, India time, not Tuesday to hit this exact time. Harsha, would that be okay? So for you, it would be Wednesday morning, your time we would meet. And then we could meet either Thursday or Friday morning, your time. Yeah. So if I remember correctly, Harsha, one hour. So you've got class that starts right now, don't you? Yes. Okay. So, so we can't just make this one hour later. And if we make it one hour earlier, we're being really painful on, on Risha because then it's 630 a.m. And that's really early. Yeah, that challenge is right. Okay. So I'm going to propose then let's go with Tuesday, the 25th. Oh, no, sorry. Is that is. So that just feels like a long time away. If it's necessary, it can be 630. That no, we want you, we want your brain engaged, not just your body presence. So that's okay. So I'm going to go ahead and send the invitation for next Tuesday or next Wednesday, India standard time, the 26th. So let's have conversations through chat between now and then. If you have questions that feels like a long time. That's almost a week for us. That is a week between our chances to talk together and that's awfully long, either that or the rest of the team could get together. Friday or Monday without me, you know, I don't have to be here. So you could all meet on Monday during that time or Tuesday during that time, if that works for you. Yeah, I'm fine with that. So, so it depends on you. If you have, you have accumulated or doubt, you know, to discuss them earlier so we could keep it. You know, on those days, Friday or Monday. So I can tell you by the evening, or it has to be fixed right now. You can just notify us. You can just tell us that's great. I'm going to tentatively put one on the calendar and we can adjust it. So I don't mean to make it seem like we have to have the answer. We don't. Absolutely. All we need to do is get an answer that works for everybody. So I'll put something on the calendar. And if that doesn't work for you, please, please suggest a different time. All right. Thanks everybody. Sorry for the long meeting. Good luck in class today. Thank you very much. Thank you. Have a great trip, Mark.