Database Version Control and Security Waivers

Transcript

Hi, how's it going? All right. This whole security discussion is just getting more intense. Last 10 minutes, I didn't check Slack and there are 2300 messages. It looks like something is going on. Yesterday, we had one call with one tab. I mean, it was more about N and N-1 like supported cloud. We are kind of restricting. Was there any kind of fruitful outcome from the call? So I can update quickly, right? So DB and GI both. Proposal is only N is the available version for provisioning for patching. Like there are three proposals, three milestones. One is the immediate two weeks, within two weeks milestone. So only N is allowed for provisioning, patching, and backup restore, like restore, like create database from backups. There is a version which we consume when we provision database. So even in that flow, so only N is allowed if you need older, then short term, short term meaning in the next two weeks, what we are going to deploy given all this mythos and all that. You can file an SR and you can accept responsibility for the security risk if you want to provision or patch using older N-1 or 2 or 3 or 4, whatever it is. Initially, I think one was like, once you sign the waiver, how does it matter? You can go N- whatever, 9, 10. Then we kind of had a back and forth because already cloud only supports for stock of images, it only supported N-4. So long story short, that came down to through exception, SR exception, you can take any version if you like, but you have to assume the security risk. So that is a two to three weeks proposal. OS, same thing, only N. OS meaning guests, only N. Through, without exception, only N is available both for VM plus provisioning and guest service patching. Then the medium term, which is right after like four to six weeks out, is N continues to be available without any, you know, issue. N-1 and N-2 for DB and GI will be available through a security risk waiver, but you don't have to file SR. It will be through some cloud API. There'll be some cloud attribute which stores your intention, which where you signed the waiver in blood or something, whatever. We still need to design that. So N-2 is going to be available through API, but same security waiver is required. For some odd reason, I think there was a big debate that in X-ray Linux, the issues are more publicly known than whatnot. And there it is N-1. So you have N and N-1, which are available. So N is, of course, you don't need any waiver. N-1 through API, you will have a security waiver you have to sign and assume responsibility. And then anything below this, for DBGI, below N-2 being N-3, 4, whatever, through SR and for guests, anything below N-1, which, by the way, in guests, guest OS is monthly. So basically, you're just giving two months of versions in cloud, meaning one is the latest current month, X-ray image, and then one month before through the whatever security waiver, API security waiver. And then everything below that, if you want to use, you have to file SR and whatever. The SR will have some automated approval thing where you will have to accept the terms of the security, security impact to applying something older or using something older to create also, you will need that waiver. So that's where the conversation is right now. Nothing to do with MRP yet. That will be like a separate discussion. So, but the decision is made that today or tomorrow, because two weeks from now, if you're implementing this, we have to send a notification out and reach out to all the bigger customers because they may already be halfway through using the API for already existing versions. And you may have, you know, custom images built with older RUs or whatnot. So those old things will now fail and you will have to raise an SR in the short term. So that notification, that customer notification will be sent out, I think we have like next three, four days. And I think the effective dates may be from when this will happen is May 28th or June 1st or 2nd. I mean, between that time frame, between 28th and 1st. Yeah, that's where this is. It's pretty crazy that we are kind of, you know, changing the acceptable versions. Already our customers are not very happy with what we support and now we are making it even small. So, but yeah, I mean, that's multiple times. The problem is this heighten. If a customer has like a production databases at a particular version level, right? And he's expanding on it. He needs exactly the same version. We cannot tell him, right? We discussed all of that as a hand. So whatever thing which I did not realize that in this whatever MRP or I don't know whether it is DBGI combined, but some numbers which the one is saying in this whatever May and June MRP, like we are looking at 5000 fixes per month, security fixes, 5000. He's like saying that's the number of fixes. So the next RU and the MRP is inside that RU is almost non-negotiable. If you are not on it, then we don't want to be responsible for it. You may have a database and he's like saying that's like a one time decision. That's what you were saying that if are we changing the rules perpetually? So he's like, we will see folks were like between now and December, we will see how many of these issues we are fixing. Right, but for RU 13, whatever, this one 32, right? 32 and 33 for sure. It's like the fixes are way too much and that is more of an MRP decision. The number of fixes are so huge that we will have to force them to take MRPs also. Right now, all this what I just said is. The problem is this heighten. If a customer has like a production database at a particular version level, right? And is expanding on it. He needs exactly the same version. We cannot tell him, right? We discussed all of that as a hand. So whatever thing which I did not realize that in this whatever MRP or I don't know whether it is DBGI combined, but some numbers which one is saying in this whatever May and June MRP, like we are looking at 5000 fixes per month, security fixes, 5000. He's like saying that's the number of fixes. So the next RU and the MRP is inside that RU is almost non-negotiable. If you are not on it, then we don't want to be responsible for it. You may have a database and he's like saying. That's what you were saying that if, are we changing the rules perpetually? So he's like, we will see a month, folks were like. Between now and December, we will see how many of these issues we are fixing, right? But for RU 13, whatever, this one 32, right? 32 and 33 for sure. It's like the fixes are way too much. And that is more of an MRP decision. The number of fixes are so huge that we will have to force them to take MRPs also. Right now, all this what I just said is. Yeah, I know, we are hitting customers badly. Yeah, so I don't know about this MRP thing, you know. You know, it's just been around, but we are not publicizing it a lot, right? So they are saying, why the heck is CSE doing? Because guys need like monthly fixes. It's a product so buggy. I mean, that's what somebody was saying, right? Like typically, we have like five, six fixes monthly. But now we have thousands. Yeah, thousands are a lot, right? That's what I'm saying, right? But now we have thousands, right? MRP will have thousands. Now you see, that's what is expected. I mean, we'll see, but the number of fixes till this whole thing kind of, whatever this Gen AI or whatever Codex is finding it, Mythos, whatever, whoever is finding these things, till it gets to a point where at some point, let's say, just make it up like you were saying, let's say by December, the most of the fixes are in and after that, every time you run this, it comes back to a normal level, which is mostly whatever normal product fixes we do. It's only the data. But this is all historically, whatever we have is getting exposed and we don't want to assume responsibility. So on-prem, we completely turned it off, right? So only N is available, everything else is, you have to sign the waiver. Cloud, that's what, I mean, effectively, that's what we are doing, but we have some more API-based services. Basically, we want customers to go to the 19.32, right? Or you sign the waiver and accept responsibility for it. We don't want to be responsible. That's the key. You can continue. Maybe you have a business case for continuing to be on whatever 19.0 or whatever 19.0 or 20 or 21, whatever your production is, but you need to, somebody in the customer side needs to sign that document. Correct. And that's what we want. See, we got a notification from one customer saying, oh, yeah, there's so many issues in 1930. Yeah, that's a different, because yesterday, I don't know how we, I think it's an action item. Those guys, you know, they mix up the tooling versus the content, you know. So, yeah. The thing is, there is so much wrong with the CPU. Oh, no, no, no, FPGA. But what I'm saying is, one yesterday asked an even more nuanced statistic. He was saying that, can somebody tell me for DBGI and X-Radar, the number of regression bugs which are caused by our security fixes or any fixes which we deem necessary, because those are also inducing regressions. So, are we tracking the regressions from security fixes separately? Because that is another, like customers will be saying, are these all net new problems? Are we fixing something? Are your fixes causing more problems? You know, but he's, of course, we're not externalized, but he's trying to understand, you know, are all of these just net new things and will it tail off? I mean, like, or are we saying that every time we fix regression is also an X percentage of fixes? So, I mean, we have to tighten the, the real issue here is not that, because when I get a problem from customer, right, I go to my team and say, hey, look, guys, you know, do we have, do we have a test case for this? If there's a test case, what is the result of the test? Did we pass it before we gave the, on the main and then on the audio? Did it work correctly before we shipped it to customer, right? That is my line of thinking, because we, development guys cannot anticipate and fix every bug. Okay, right? So the focus should be, rather than, you know, saying there are more and more bugs going to customers, we should be looking at how can we reduce that by building a better quality control. Right. So Sam, I mean, again, I think here the overall quality control is, I don't know what the focus is, but secure, these are all security related ones. And I think what we publicly, I think whoever that we sent out that email, right? Like Evals, right? I forgot the first name. The email from our EVP, assuring all customers is that we will make sure that all publicly found like, you know, security vulnerabilities will be fixed in our code base, right? And it will, he is also coming to some date. Every month, I think it's the 18th of every month, right? So that, and it is, this is a new world, right? I think, I don't know. No, it's public ones. That's not things that Codex found or something. Correct, correct. So, which is exactly the public ones, but thousands, the thousands are coming from Codex and Kiwi and this and that, Verify. And it's not like they're not introducing regressions, right? Yeah, yeah, yeah. I mean, there was that one, you know, XML path validation thing that, you know, worked fine on 23, then instantly, you know, it got backported to 19 and then it broke the installer because nobody runs install LRGs when backporting something to 19. And it broke them not because they were calling the code, but they had, because they had a JAR file that was conflicting with the JAR file that we were using, API that we were using, an old, an old XML parsing JAR. So, you know, that kind of thing, I don't know how we could improve the quality control to find it other than, like, you know, running install LRGs for every backport. I don't think that's going to happen. Yeah, it's tough. Anyways, okay. Yeah, let's move on to the, I think I put in the subha. I'll just say subha. Thanks for joining, Subha. he's there? Yeah, yeah. We've been missing you for a while, Subha. Where are you? Yeah, it comes down to this is sticking. I don't know, Subha our idea is not there. Oh, can you hear me now? Yeah, now we can hear you. Oh, yeah. So escaping from you guys. And some things are going on. No, I think, I know. But today, I think what I wanted to do, I think, you know, we discussed offline and we kind of, tomorrow the engineering kickoff is scheduled for the DBGI and the Don Yu, right? What we discussed. So I thought we will just walk through that thing with, I think Sam and Jonathan had been there, but including Subha. Maybe we can just have a quick walk through of what we are going to present even in the kickoff, right? That we fully, we know what is the picture. So maybe Vikash, go ahead, Vikash. Go ahead and share the story. But Sam, this is all the things that we have been discussing, right? And so we have a consensus now with Prince also, right? That this is what we will tackle for the Don Yu DBGI. But the thing is still about the full post-story and other things, right? but the idea now is this piece is aligned with that other thing, Prince. I think that is what is the bottom line, right? The DB, Don Yu and GI that we are doing is workable into our higher model that you've been discussing for the post and things, right? Right. Makes sense? Yeah. Okay, okay. Yeah, go ahead. I don't know if you heard. Yeah, because it's a totally different look. I'm seeing him after a really long time. Yes. Any guesses about? Yeah, he complained and wanted to say he wanted a record also. Yeah, yeah, that record also. He complained doesn't get the video, right? Recording in progress. Right, yeah, we'll have both. Yeah. Anyway, Sabha, Vikas got married, that's a really simple is changing update. Oh, congratulations. That's it. I should ask one filter. One filter here. All experiences. Okay, let's go on. Okay, we are talking about that one. Yeah, so let's go start with the create collection flow. So basically, this is the new drop-down menu value that will be added for collection type. I think there was some back and forth about whether to use a different pattern, but I think for now, for this project, we'll go with this pattern, just showing a new drop-down value. Okay, because I put my screen, and I see if I can create again. It's okay, I cannot make out the letters. We'll do one more. Maybe one more larger. Yeah, that's about, I can make out except for database service on dedicated infrastructure. Okay, I can manage to read it. Okay. Okay, just a thing, these are still marks, drafts, Sabha, Prince, Vikas has been brainstorming this, but I think I will leave it to you. I don't know, Prince, we have been thinking of involving the designers also if needed, right? But this is just a rough draft marks. Okay, yeah, cool. In previous discussions, I think we thought rather that for MVP slash P1, we will go with one major version for OS, guest OS, one major version for GI, and major versions for database. I just called it out, the Scorpio. So in the future roadmap, we will support like multi-selects for the Linux 9 and 8 for OS and so on, but for P1 slash MVP, we went with 1.1 and model. So the other changes, we will look at it on the next slide, but this is, we are introducing a major version. Today when you do create collection for stack, the major versions are not shown here. So this is a new addition to the flow for the stack is. Yeah, and then once they select anything. One question, so the Linux 8 would be a drop down, like what are the values we have to show? Would you? Yeah, I think today it's only 8. I think today, actually, today I think the API has 6, 7, 8, but based on the discussion with Spencer and Nixon, the web UI can only show 8, I guess. So we have a filter for that one. So it's going to be ordered or it's going to be like unique given values. Oh, I think there is one project probably in the works to offer an API to show the supported accelerator major and core versions plus streaming versions, but I'll go with that project. If that project gets before this, then we can leverage that.

Okay, so should we rely on that feature, that API? This one I will go after that, right? After that preview. Yeah, this is after that. So I think after that, I think after that, we can just maybe hardcode it and then go on. And GI and DB are I think today already, you know. Yeah, it should be totally independent of what you select. Yeah, but yeah, these are the money select drop-downs in the future, but for now, it's a single select for OS and GI, multi-select for DB. It shows a double, though, right? Because for GI, I see 19, 700 days. Yeah, and I can change it, but I just called out for P100. That's correct, right? Yeah, I mean, I put the note here saying for, it's only single select for OS and GI, but I can change it. And it should be only 6 days, right? No more 20. Alright, sure. Yeah, I mean, there should be only one entry there for P1, for MAP. Yeah. And the other change that is happening here is the, when they click Edit Search criteria here, the other changes are, so previously, the major versions were being shown here for the search criteria, so the new proposal is that will be moved here, and the drawer will be simplified to only show these basic criteria, nothing else. And we'll select only the earliest version and the systems of their release versions for it from here. So basically, this will be the simplified search criteria. And this will be permanently for all, irrespective of the stack. The stack we are moving. Oh, okay. Let's call it out. I think it's there. Yeah, I think, yeah, just mention for all, except this time collection, but we can add an extra note. Yeah, so only for this collection type. This one and the one we already shipped for the big one. This is the second stack type, right? So we had the GI and OS, and this is GI OS DB. For both of them, we will use this pattern. The other ones, we will not scope. Maybe it will all line up, but we don't want to increase scope and go and look at DB and single collections right now. Maybe it will just work the same format as well. Again, I think there was a previous conversation that simplified the whole thing. Yeah, so that's why we are just focusing on the stack for now. And then maybe these changes will propagate to other collection types also. But right now, we don't want to focus on it. And this is basically after the search in progress. The other thing I will mention is that today the search criteria are kind of migrated where it's creating a stack cycle. They have to open the drawer with the legacy link going forward. They don't have to do that. They can just hit create after specifying the major versions. So this will align with the single component collections like DB or GI. Basically, they can create like an empty collection just with the major versions plugged in and then they can add the target state to the library. That's just, I don't think many people will do it, but we are just aligning with the other collection types. It's all or nothing, right? All or nothing or... So today, if you go to a DB collection, you can skip the search criteria altogether and just select the major version for DB and hit create. So when you empty the targets, targets would be under that table, right? In a DB case, that's not required. You can just go with an empty target and still create the collection. So we are just aligning this to that. So what we are saying is that the targets are not a required thing for you to define your collection. You can just say that I have a collection and then you can add targets post-create or during create before the API would error out. That's just a minor thing, the thing we need to kind of, you know, like that. So what is this table then? No, no, this table is if you hit search criteria, you add 50 targets and you hit create, that is the regular flow, right? Even if you don't add search criteria, just create and then add targets later, that is also, that was not supported for stack before. So we are just saying we are correcting that, that you don't, targets are not required to create a collection. You can add targets post-create. That is how all other collections are and stack will also follow the same part. This is nothing new we are saying. You can add targets in create or without targets also you can create. That's the only thing Akash is calling out. Yeah, I think today the behavior is the create button is disabled. So we're just saying that this will always be enabled as, this will be enabled as soon as they enter the major versions. So that's it. Can we totally remove that table only if they hit on the search criteria after they choose target, we can show this table. It would be confusing, right? We show tables with no items to display. But basically, so now that's a different UX discussion which we need to do, right? So this is there for all collections, right? All five collections. You're saying that that is a different, I think, enhancement we should work on. Previously, like we should have some targets, right? No, zero state, we never have targets in any other collections. And when you hit search criteria, you find it and then add it, then it shows up here. That's how the current behavior is. The only change is that the API errors out if you don't add any targets. Today, it is, that is true for other collections here, I mean, for stack collection, we just removing that restriction that you are allowed to create a collection without targets. But that's not the emphasis. We are just aligning with whatever is existing. And we can change that pattern also, but let's keep that as a separate thing. Okay. That's all. That's the only thing. That's it. Your feedback, Sabha, is that, you know, that should we change the interface of how you add? Targets are not required, right? So, we don't need to show that table. You can go to edit search criteria, then fill in, then they select targets. We can show the table. I'm just looking at current implementation. So, current, all collections have that table. We can remove that. Yeah. Okay. That's, we can take that as a side enhancement. Yeah, okay. Because I think Sam also provided feedback. We'll probably change that whole add targets experience as a separate focused item to make it like slightly different. We have some ideas, but then that will kind of deviate from this whole vertical. We have to get the DBGI OS out. So that one, maybe it will come before and then we can use that presentation. Maybe it will come after, but we don't have to overload this project with that enhancement of, you know, target selection, if you will. Okay. So, edit search criteria for this use case is only to choose some targets if the user wants to. Yeah, which is true for all the collection types, all five collection types. Okay. And then, assuming they enter the search criteria and hit search, then once the discovery is done, this table will be populated. And for the new stack type, the proposal is the table will become like a tree table to show like a hierarchy of the trusters and associated databases like China resources, basically. And we can discuss this in presentation if you can simplify it further, but for now, I think we will. to begin with, like almost the compartment filters can be multi-select, because the targets can span across compartments. We can try to see if we can simplify any of these other columns, but for now the idea is like, if you actually get all these three columns or join the individual compartment questions, the current questions. This thing came from UX designer or you guys made it? That's from the UI team. I am not sure whether we have a key table now, but we just have expand and collapse. I will have to take a look at the library. We haven't implemented any key table. We have just have the one expanded row. So what I'm saying is, if we don't have that support, we will have your three dots in the first row VM cluster. When you click on it to view or select databases, then the side panel will come. There you will see the list of databases for that VM cluster. But Sabba, this whole thing was populated as part of the search criteria results. Remember, if you go back, right? But have we filtered on the client side if all the results are in one API response? Right. We could do it. So if I am not able to achieve this, the alternative pattern is, have your three dots on the first row VM cluster, then select databases would be one of the row actions that will show the panel. The panel would list the databases. From there, user can choose the databases. When they close the panel, we will show the expanded row with what are all the databases have been selected. You see what I am saying? Expanded row, but as like you mean like a summary? Like an expanded row. Yes, something like this. But in the version, we'll have to do some kind of, because they will all have different versions. If you want to see, they have to again open the panel. If you want, we can get this. Like, I don't know how many databases each row would have. Right? Yeah, I mean, it could be end databases. But this whole DBGI, this whole in general, this whole is a tree, right? So is that how all tree, like anything which is parent-child, if you order to display it, how are we doing it? Are we doing it through this side panel? Yes, yes. I will double check on the tree table. If the tree table is not supported in the current library and the framework that we are using, we have to have alternate path. Alternate path is like, have your three dots on the row. It will have your select databases and you will have your table with the multi-select. So when they choose and come back, you will see the expanded row with the databases comma separated. And if you want to see the version, we can show the metadata, but if you are seeing n number of databases, then this page would be really crowded. Yeah, but Sabha, this pattern is not just this. Later on, on each of these databases, we are offering rollback, retry, those kinds of operations. This structure, right, is not just during create. This is how the jobs will be. This is how, I mean, this is how the actions will be. These are the jobs will be. And each of those individual things which have failures will have retry, rollback, those kinds of things. So one side, I thought we were once we get to the jobs, right, we will have individual target type screens. Correct. Yes. But it is all under the row parent, right? So let's say you have one VM cluster, you have five databases underneath it, right? And this whole job is one action, right? So if let's say the VM cluster 1 has one GI job, one OS job, and 15 database jobs, and it is all operating as one vertical job, right? So if let's say of the 15, let's say database 4 and 7 failed, then you can do retry on them. No, no, but what I'm saying is if we have five VM clusters. No, no, five VM clusters are very good. That is clear. Let me finish this. If you have five VM clusters with 25 databases. Each or across. Across, across. 25 databases in one screen as a database result. No, no, no. So how many does one VM cluster have? That is the key. Is it 25 each or 25 across? Across. Across. So how many, this whole presentation is about how much each has. So you'll have job number 1, which is VM cluster 1, and it will have underneath that one entry will be for GI update for that VM cluster. Right, right. So if you kind of draw a panel today, there is a single component here in the database, right? The database there in that list of job they show, right? They can belong to multiple VM clusters, right? No, they cannot, right? One database can only belong to one VM cluster. No, no, those set of databases in our database collection. Oh yeah, yeah. But here the collection is on the VM cluster, right? So database is just the sub-resource, right? This is the vertical job starting at the OS, right? I know, I know. But even what I'm saying, on the results page, right, we will show have a screen only for databases, right? All databases that are part of that collection. No, Sam, like independently, the database doesn't mean anything, right? Because the database update happens for, let's say, if that database is a four-node VM cluster, right? VM1's GI, OS, and one database instance gets done, right? No, but they all will get done in parallel. Yeah, yeah, but only, correct. So let me give you a bigger example then. Let's say there are 10 VM clusters. Correct. Okay? And there are 100 databases. Each? Across. Across, across, total. 10 VM cluster, which means 10 GA, 10 OS, and 100 databases. Correct. Right? Now, this is one collection, the vertical collection, three components, correct? So let's say we created this collection based on a criteria and all those things are there. There are 10 GA targets, there are 10 OS targets, there are 100 DB targets, right? Now, we are thinking of passing all this, out of all this, right? We have already given the images everything, right? We are thinking of an update. Now, the customer wants to now look at the results. Hey, how is my update going? Correct. Will we still have an interleaved screen where the 100 databases will be interleaved between the OS and the VM cluster, or are we saying there will be a job screen that will show only the 100 databases, similar to the individual database target, right? And there is a job screen that will show only the job. So the presentation will be like this, but they can filter, right? If they want to filter, they can apply the filters saying, I only want to see DB kind of jobs, or I want to see GI jobs or OS jobs. So the filters will, is what will help them to populate the table based on what, if they want to focus on only one target, then they can add a filter saying target type equals DB. But more importantly, yeah, so the filter is the second part, Sam, but the main question is, in those 100 databases, imagine they are all evenly distributed on 10 different VM clusters, right? So the progress is different. So your database is a job is dependent on your each instance GI and OS completing, right? Yeah, but all 100 databases are potentially concurrently progressing. Right, concurrently progressing. Yeah, just, yeah, but it is in the respective context of your, so the vertical job will be, you'll have job ID 1, which has GI job, OS job, and all the 10 databases underneath it. They're all progressing as one job. The second VM cluster will have GI job, OS job, and 10 databases underneath it, right? So basically, it will be just like the interleaved, like what, however the, because your retry and rollback and all of that are tied to your OS and GI, correct? So it will be just like the interleaved, the way it is executing is how it will present it. Are you saying what I'm saying is, right, those 100 databases, a customer should be able to see that on one screen, right, and then monitor the progress. And when they're all done, you can go to the failed ones, and then, you know, do you know the last column, right? Last column had a drop down, you can say, you know, rollback or, you know, continue, right? So that way you'll have to come back some. This is the same as the previous. No, no, wait, so I'm kind of trying to close the loop here with Prince, Kannan, Vikas, right? The customer should be able to see a screen, there's only databases, and decide on that once a job is done, right? It's not like as it is going, right? Yeah, yeah, yeah. So for some, it would be a blacklist of 100 databases, where we refer to hierarchy. Yeah, that's what the question is. The hierarchy exists, but the visibility in terms of the customer, you know, looking at the results and acting on them, right? Could be a blacklist. Would be a blacklist. That's what I'm thinking, because… So then, Sam, how will we do the retry of, because database jobs are not the only ones, right? So for one database, let's say the GI is hung, so then where will you go for the GI retry? No, the point of the database will be seen in the screen.

Correct, correct. So then, that's what I'm saying. So then, actually... Correct. So then, how will they... Correct. So then, how will they... If you go to the GA screen, for GA, he will say something is failed or whatever it is, right? No, but this hundred databases, I'm seeing the association is on the hierarchy from the... That is the interesting thing because he already, he knows it. No, but we know it, but where does he associate it? Let's say we give a thing that, hey, these are hundred databases. How does he associate that this database is involved with this vertical collection? I mean, this particular cluster ID. The point of execution, you know, it should look like, you know, the one I was saying, it should look like if you have submitted a hundred databases and the 10 OS and 10 GA, right? These three as individually. So he can go and manage those. Only thing is that when you're doing this, when you look at the database, they are still progressing. If the database has not failed, right? If it's waiting for the next node, things are going on, that's fine. But if it goes to the GA screen, that's people for GA, he will say something is failed or whatever it is, right? No, but this hundred databases, I'm seeing the association is on the hierarchy from the... And that is the interesting thing because he already, he knows it. No, but we noticed it, but where does he associate that? Let's say we give a thing that, hey, these are hundred databases. How does he associate that this database is involved with this vertical collection? This particular cluster ID. At the point of execution, you know, it should look like, you know, the one I was saying, it should look like if you have submitted a hundred databases and the 10 OS and 10 GA, right? These three as individually. So he can go and manage those. Only thing is that when you're doing this, when you look at the database, they are still progressing. If the database has not failed, right? If it's waiting for the next node, things are going on, that's fine. But if it goes to the GA, he will say it's a failure. Right, right. No, but Sam, you're still thinking that it is hierarchical, right, Sam? I think it's... No, I think that... Yeah, I think Sam is saying that... The interface, right, it will get so confusing to the customer. He needs to feel like, you know, I'm, I have, I can submit a hundred databases, right? And then I see the job results. Now, he should have that same experience when it comes to vertical, in terms of at least handling the... Submitting is different because we all know that it's a different way of submission. But the results handling, the output, the progress, you know, the retry, whatever, that experience of it should be very similar to what he's doing if he's doing only databases or if he's doing only GA or only OS. Even the retry you are saying that it will be separate things, Sam? What was that? Even the retry you are saying that somebody just goes... The retry will be on the same component. He will see what failed, right? OS failed, go retry on the OS and then he continue on the other ones, on the vertical, right? But the GA or DB will not show failure at that point. Otherwise, you know, these failures will just multiply. One failure in the OS will say GA failure, 10 databases failure. And then the guy will get confused and say, hey, what am I supposed to look at? Right? Or is he going to visually correlate these 10 and all those things, right? That is what I'm saying. They show us promising, no noise. If there is no nothing to complain, no noise. But wherever there is noise, we have to show it and make him look at the one part of it that needs action. Because you see, these 100 databases with the 10 OS and 20, I'm not going to fit in one screen. And then also the failure data per layer to the top, right? I think we have it in the other one, right, Vikas? If you are submitting a hundred databases patching, they're all in progress. Something failed. Say the 91 was failed. It will per layer to the top and show the failure on the top, right? Yeah, that depends on the default sort you are applying on the column. So yeah, if you are applying the default sort, it is not like... No, that's all. It should bubble up the failures on top, right? That's not the bubble. It's just how we represent it based on the feature and the sort. So Sam, this one we can look at. But one question I had, like, so for example, just to break that down, right? So you're in this example saying 10, we have clusters. So technically, just for sake of, just to translate what you just said, right? You will have a, if you go by the OS, each component has its own page. You'll have a page where 10 GI jobs are listed, 10 OS jobs are listed, and 100 database jobs are listed. It happens to be interleaved. That's like something which the engine knows about, right? The end person who's looking at it, you have three lists of things. Now, based on our thing, we know that, you know, each of those clusters and the, you know, first all, you know, because we start OS here. Show a box saying, hey, this is part of the vertical. But visually, right, we should, we should get his attention to look at only the thing that he needs to act on. Sure, sure. And that part we are achieving. If that is the objective that we are achieving here also. But let me just kind of finish like the thought which you had, right? So you have 10, three tabs, just for sake of having 10, 10, 10, 10, 100, right? So now the question is, if you have a OS failure, which is the first thing which has happened, let's say VM, like, you know, VM cluster one, two, one through 10, you know, whatever. Nine of them are progressing. Eight, one has failed, right? Now GI is not started for any of them. Database is not started for any of them because in this format, OS is what is going to be like the first one which is running. No, they all run concurrently. I don't think that will be the case. But whatever, where the OS is crossed over, it has gone ahead with GI, you know, probably gone ahead with DB. Right, right, right, right. But what I'm saying is just the beginning, right? When OS is the component which is being patched, at that time GI and OS, they will be showing some kind of state like in progress, correct? Because... No, they are not started, right? I mean, they started, it will get started. So may in this case, if it's combined job, it might show in progress, yes. Yeah, right. So basically, right, so the GI all 10 will show in progress and DB all 100 will show in progress, but really the job has just started on 10 VM clusters for the OS to happen. And just for now, let's say, and just for sake of this discussion, all these VM clusters are all full node clusters. So first VM is going on, like, typically they should all take similar-ish time. So let's say one of them failed, the OS job failed on one of the VM clusters. So now that failure has happened and then the other nine have progressed to GI. On that first VM, we are still talking about just the first VM, right? And then now that one failure has happened on the OS, now you have the option to click on that. What was VM cluster or first VM of the... First VM because remember, all of... And it is happening across these three tabs, basically, because first tab is only GI jobs and they are all operating on the GI. I mean, first tab is OS tab. They're all operating on the first VM of all those 10 clusters. Then after that, they will operate on the first VM of all the 10 GIs. Then it will operate on the first database instance on all 100 databases. So the way this progress, you are envisioning and the way we are thinking is slightly different, but let's just see what you are saying, right? But we had all of this in one page. It is like all parent-child. I'm just saying that is not visually friendly to a user. Because they are all in progress. See, if we are seeing like hundreds of databases, right? Showing it to you in one page, it's not going to be... No, no, it's not hundreds of, right? Those hundred are like each, let's say, again, just to make this example more simpler, right? Each component has its own page. You'll have a page where 10 GI jobs are listed, 10 OS jobs are listed, and hundred database jobs are listed. It happens to be interleaved. That's like something which the engine knows about, right? The end person who's looking at it, you have three lists of things. Now, based on our thing, we know that, you know, each of those clusters and that, you know, first all, you know, because we started OS here. Show a box saying, hey, this is part of the vertical. But visually, right, we should, we should get his attention to look at GI and the first database all are going to be done together. That is when one VM will be done. Then the second VM plus second VM, the OS will be done, GI will be done, and the second, each of those 10 databases, one one one one one will be done. You see what I'm saying, Sabha? So basically, split it into multiple pages and all, UI you can do, but the key part here is how do you like address like in failure, right? So first, let's just say OS has failed. The first component has failed on VM cluster 8, and that means that, you know, now the minute that failure happens, that means your GI and database are stuck. They will not progress. Correct. Correct. So you have, let's say, one entry in the GI page, which will have some state saying that, you know, it cannot no longer be failed. It will not, it will no longer say in progress because you're not even started. You are in progress, but your GI... Technically, right, the way it works, right, can I take a VM, right? The databases, services gets stopped, databases get stopped, the GI gets stopped, then the OS patching starts. You cannot do the OS until you get these guys down. Correct. So it's in progress technically. I don't think, you know, it's all up and running and stuff, right? Correct. So it is, correct, but that... The wrong is showing in progress. Yeah, but okay, so then the question, that's what I was trying to say that now... If you go, if you have one page that has nothing but databases in it, then some of those databases are marked in progress, but really they're not progressing because they're underlying GI fail. No, no, wait, wait, wait. The point in showing that is, if you want to show 10 databases failed because the GI failed, right? The customer is going to see a lot of fails. And what is it supposed to do? Hey, I'm not going to let them. No, no, no, no, the databases are not going to be shown. If you go to a page with a hundred databases and they all look happy, but some of them aren't going forward and the rest of them are, then, you know, that's, I'm just saying it would be nice to have some way of telling the ones that are stuck because they're waiting for something else that failed from the ones that are happy and they're... The thing is, visually, right, the display based on the type would be more convenient. And it's, what I would say is it's, it gives the same experience to the customer whether it does a single target or whether it does work. Right? I don't know, you know, but you're no longer making somebody click a different tab. I'm not making you click. So that's what I'm saying. You're telling me, right, if GI is in progress or GI is in progress, database also shows in progress, right? Even if it is stuck, okay, and it is showing progress, it still needs to go to the GI or the OS screen. Correct. And that's what, yeah, correct. And that's what we are trying to get to, right, Sam? That to do troubleshooting, it is not that all hundred databases are, you, you, so even whether you put it on three tabs or on a single tab with parent-child relationship, the way to troubleshoot will be, in this case, let's say VM cluster 1, I mean, VM cluster 8, OS has failed on the first VM, VM cluster 2, GI has failed on the second VM, and let's say all the other eight are progressing as expected, right? So when you see failure, you will see jobs today, what Vikas is presenting is, you will see 10 vertical jobs, just 10. I'll give another example because let's say OS and GI success, the hundred databases, say 11 databases failed on different clusters. Sure, so that also we will take, but let me just finish this one. But Sam, actually, that's a beautiful example because both your example and this example have the same number of clicks to troubleshoot is what I was saying. First, let's just finish this one, right? One VM, OS has failed, one GI has failed. And then let's take actually all three in one shot. And in another example, because only these two, the other eight were progressing, and let's say imagine that, you know, on VM cluster, another single VM cluster, eight of them have failed. So basically, seven jobs are running, and all databases are progressing. No problem. So if you go look at the vertical jobs list, you will first of all see 10 entries. We all agree? Any questions there? 10 jobs, 10 vertical jobs, because there are 10 VM clusters and they are related to it. So first interface will be, you'll have 10 jobs. I'm just trying to play out what Vikas is saying and how the troubleshooting works, right? So if you just have a nested list, you'll have 10 jobs, of which seven will say in progress because they have no issues. One of them will say failed, that is on OS. Other will say GI failed, which is on the GI component. And the third job will say failed. And when you open it, you will see the database failure. Let's say 11 databases have failed. So wherever you have failure in your stack, amongst the three components, it gets updated and shown on the job, which is a composite of all the components, which needs to be updated, right? But you will have 10 jobs, and you know seven you don't have to interact with. Three you have to interact with. The minute you click the first one, you will see, oh, OS has failed. Then you interact with it. But rest of it, you don't have to interact with. You don't have to interact with the GI job or the database job when you open the topic. Yeah, that's right. That's right. Because it's just the way we have ingested the payload is how we are troubleshooting our experience at payload. But it is a function of wherever the failure is. So second job you will open, you will say OS has completed, GI has failed, you will interact with the GI component. But again, you will not open the database or do anything with the database because databases have not even progressed. Right? And then the third one, you will see, when you open the job, you will see OS has completed, GI is completed, and when you open database, you will see, oh, there were 11. When you open, see, it's not the screen that you stop to visualize what is the customer looking at. Yeah, I think this one we can, we can show, right? I mean, maybe, but because we said it will be flat, we did not get to that presentation though. Because do you have that presentation? The idea was that the individual jobs would also expand. It will look like this. Yeah, but you know, because you have a, your example here, right? It says there's only one database. Imagine there are 10 databases. Now, how will the screen look? It will show only one VM cluster. It won't show the remaining. That's the misunderstanding of the UI pattern, which does make us... If you don't... Yeah, I can quickly try it. It's about like this, right? Like if you have this kind of a list, then this is what would happen. We can do this kind of a presentation of the option where you can page in it. There's a progressive loading. Yeah, so this point I need to check it out. Like current framework, we don't have a... No, no, no. Go back to your other screen. Okay. Where you had the VM process and DB1DB. Now, how will this thing look like if there are 10 databases on each VM cluster? Yeah, that will, for each VM cluster, you will have the load more button. How many lines will be there for that? 11. If you have a VM cluster that has 10 databases, you'll have 11 rows. So that screen is already used up mostly. But the other things will be collapsed because first of all, the first VM cluster, I know, they'll go off the screen. Correct. So these are exactly the same pattern, same pattern as adding the databases, right? And are we allowing for one component to go through without the other one unless it's taken out of the stack, right? No, you can retry, right? Rollback, yes, but retry if you fix something, you can retry all failed databases in one shot under the cluster, or you can retry the whole job or the GI, right? Retry is allowed, right? Rollback, yes. In one cluster, if there are 10 databases, if the GI fails, there's no need to say retry for GI and the database. No, no, you don't have to. But if... Correct. You don't have to. That's what I'm saying. Here you show, maybe you have tabs, right? You show the, whatever, VM classes on one tab and the databases on another tab. And there is no need to have the hierarchy thing, but that would be like, you know, the panel for the child resources if you want to retry. Yeah, but then how will we see the running progress without opening the panel? Only a database collection in job screen. But Sam, this already we need for GI and OS, right? Even if you have zero databases, and if I just want to do OS and GI, should we have two tabs or one tab? Let's forget databases. OS and GI are bundled together, right? Currently, it's a small because they go together. But no, if you... There's no separate prefix. But then this whole notion of like whether my GI is progressing, OS is progressing, are we talking about just because it's VM clusters and database are different resources? What is the philosophy behind it, right? One philosophy is that each component I want to see, which is the original, each OS is a collection, GI is a collection.

It is a collection, the presentation is the same, no matter whether you are doing vertical. That I completely, that is something worth exploring. But if you are saying OS and GI is combined payload, because they have a relationship, then the database is also part of that combined payload, right? No, no, it's not that. Right now, the way it has been implemented, OS and GI are bundled in one resource. Right? And we have rollback or reward or continue retry for combined OS and GI. We don't have it individually. If you can do it individually, I would put them in separate screens. Correct. Because that way... Okay, so if they were, which is what we are going towards, so you are saying in that case, you will have three tabs, one is for OS, one is for GI, and one is for... Okay, so if they were, which is what we are going towards, so you are saying in that case, you will have three tabs, one is for OS, one is for GI, and one is for... Okay, so if they were, which is what we are going towards, so you are saying in that case, you will have three tabs, one is for OS, one is for GI, and one is for... So if you have a screen for 10 OSs, 10 GIs, and you will have a screen for 100 DBs, they will all, let's say, the pagination size for all of them is 5. That's what I said. So on first page also, you will scroll, second page also you will scroll, third page also you will scroll. Correct? But the difference between that presentation, so total we have 100 plus, you know, whatever, 10 plus 10, 120 rows across three tabs. That is one model, and we have not explored it, but we will explore and come back. But just to kind of clarify, the current presentation is not very complex. I'm barring Sabah's comment that if the compact itself is not supported, then we have a different problem, but that's a technical problem, and first we need to align what we want. So the user experience. Yeah, so the user experience, so the current problem is very clear, right? You always have, it's a fixed function. It's always 10 rows, no matter what. And you only interact those. And those not collapsed, you know, all collapsed. All collapsed, because you will only interact when there is a failure. So if there is a failure on one database, the color gets propagated to that row. Then only you will interact with it. Otherwise, you don't have to open it, correct? If everything is perfect, 10 rows, DBGI rows, everything is there. Utilization of the summaries. Yeah, you will get, yeah, so now that's different. Now, I'm seeing was a summary. So if you want to say, right-click open all rows, what you will get is, let's say, they are all evenly distributed, or let's say there are 10, 10, 10 in each cluster. What you will get is 10 rows which are existing parent rows, and within each, you will get 10. So 100 plus. So you will have 100 plus and 110 rows fixed, no matter what. You will have 110 rows, and the open-close collapse will determine what you are viewing C. That is the net-net. And you will still have scroll. So instead of 120 rows across three tabs, you will have 110 rows if it's fully open on one tab. That is the present. Now the question is, how do you do RC, right? You only interact if the first row is red. First row is red means something in your stack has gone down, right? Whether it is DBGI. So if, let's say, that's why I was saying that dividing of 10 rows, and seven rows are all green, you don't touch it, you don't open it, you don't need care because everything is going as planned. One of them is red. Let's say the last three are red. First one you open, OS has failed. So the minute you open, you will have an entry for OS and GIS at the entry itself. You will see, oh, OS has failed. Retry. Databases, all 10 of them are all in progress. You don't interact with it, but it is open. The second one you open, OS has succeeded, GIS failed. That also is on the same row which you opened and interact with it. You right-click and say retry GI or rollback GI, whatever you want, but you open 10 databases. They are not progressed. They're all like in progress. Third row, you open, you see OS and GIS are marked as green. It's on the same row. And then the 10 databases, 1, 2, 3, 4, databases are all successful. 7, 8, 9, 10 have failed. Now there, you can do right-click each or you can do right-click. From the way I see it, customer perspective, it seems this is a little bit more tedious, right? You can really need to go and then uncollapse those, expand those, right? Otherwise, you have to switch between tabs and make the correlation that which is the parent, which is the child. That is super complex. No, no, no, Sam. But the tab is only there, but you still have to build that relationship, right? From there, you have to find out which parent. You don't need to know which parent belongs to. If the database failed, right, you can go click on the database, click retry. Now resume or whatever it is, right? And you know, the dependent components will proceed. If you look at our vertical stack implementation, let's say on the second node, the fifth database, now I'm giving an example, it perhaps is not technically what we want, but for argument's sake, let's take it this way. When it does a retry on the fifth database on the second node, right, and it goes through, right, it will go through to the other stack components. It will go complete the GI, it will complete the OS, then go to the third node, right? It will do all of the stuff. So he doesn't need to really know the dependency. He just says, where is the failure? Well, then I'm looking at the failure. I decide what to do, and I act on it. That's all. That is, see, the way customers see it, right, it sounds like, you know, they understand this, there's a hierarchy here, but for them, there is a database team, there is an infrastructure team, you know, in most likely in West Coast, that's how it is. In Buford, I don't know how it is, but I'm assuming, yeah, that's how it is in West Coast, I mean, in Buford also, because the database part of it, right, they are given out to the respective departments. They handle it. And then the infrastructure part of it is handled by the central team, right? So it depends on, you know, that's what I'm saying. As long as we tell those guys, hey, look, you know, there is something, you're still going on, you don't need to do any action, that's fine. And for us to get them to look at it and do that action as quickly as possible with minimum clicks, with minimum expansion, with minimum scrolling, that's the best. Then we have to play that out, Sam. I'm just thinking, because the key part there is, the one only last question I have, retry in that example, it's a very minor issue, but we don't need to pivot our whole UX based on that. So in this example, let's say I opened up one of the VM clusters. No, no, but retry meaning individual retry versus, yeah, so if I want to say that I want to retry all of the ones which are part of this cluster, then you need to handle the parent. But is that, do you see that as a use case or? Because that's where I, off the bat, without doing any, or rollback for that matter. So remember. You can still do it here. How will you do it? They don't have a relationship with each other, right? No, that's not the thing. It's not dependent that way. Let's say there are 10 databases that show failure in different VM clusters, okay, on the database tab, right? 10 databases. The only reason we'll show a failure there is because the database patching failed. Correct. Right? The cause of the GI or OS. So the action to retry on all of them is completely valid. So, but the action to retry a subset of it is probably not important enough. Like, for example, those 10 databases are across two clusters. So just retry cluster 1's database and cluster 2's database, probably not. Probably not, yeah. Because it just continues and it does, it gives me, it's a collection for him, right? He wants to get all of it done, right? So he says retry on the whole lot. And he can go to the OS plus GA also and say retry on all of them. Because that's where they have failed at that point. Now, there is an action where the guy says, hey, I want to remove GA, you know, from the vertical stack, right? So when he does that, at that point, we have to kind of hide those things. Not show failures from the GA part because they are reverted. It's not being done, but the OS plus DB operation is getting done, right? So at that point, we won't show failure because of GA because it's reverted. On any cluster. First time, I think, yeah, I get your point. I think, see, what you are saying is you still, we have to maintain the association, but we should be able to see these individual components for this ticket. Yeah, yeah. From a customer's action perspective, right? The simplest way, the direct way for him to act on it is the main thing. But the action to retry a subset of it is probably not important enough. Like, for example, those 10 databases are across two clusters. So just retry cluster 1's database and cluster 2's database, probably not. Probably not, yeah. Because it just continues and it does, it's a collection for him, right? He wants to get all of it done, right? So he says retry on the whole lot. And he can go to the OS plus GA also and say retry on all of them. Because that's where they have failed at that point. Now, there is an action where the guy says, hey, I want to remove GA, you know, from the vertical stack, right? So when he does that, at that point, we have to kind of hide those things. Not show failures from the GA part because they are reverted. It's not being done, but the OS plus DB operation is getting done, right? So at that point, we won't show failure because of GA because it's reverted on any cluster. So Sam, I think I get your point. I think, see, what you are saying is you still, we have to maintain the association, but we should be able to see these individual components for this ticket in the database. From a customer's action perspective, the simplest way, the direct way for him to act on it is the main thing. Correct. But the actions are completely separate. So we have to maintain the association but we should be able to see these individual components for this ticket in the database. Right. I know. One thing is the one who is submitting it. No, that submitting owner has the responsibility to bring up the database GA and the OS. That's not going to happen. Because the guy, think of it this way, when the jobs are there, the guy who is an expert in the GA part of it will not know the DB part of it. The guy who's doing the DB part of it will not know the GA part of it. He will not know the GA part of it. DB and GA probably may know, but you are at sea side, maybe right. OS guy will probably not know DB for sure. I mean, not for sure, but there's a chance that the guy who's doing with OS, Linux and all that. But Sam, but still, right, the person who's doing vertical privilege model wise, there is, when we say guy, right, we have to step back and say that somebody who has update privileges on all three to do software update is the only one who can submit this job. That means they have to have full access and ability to define payload all of them. So then if the person who's submitting the job is not the one who's troubleshooting, then whoever comes, then they have to have read privileges on different, different resources. So I don't know if that is true, right? Because if I, like I am a DB user, I have I think something of a group, right? Based on the group. Correct. But that group will have all privileges, all three level privileges. This is what I'm saying. But you're saying that maybe I'm a database admin. I have, see if there are 1000 databases, right? You can't have like, you know, one admin guy who is submitting it to be able to do everything. You can't have that. No, I think the team will coordinate with others, but I think the principle. Yeah, but the UI system. So make sense, I'm telling you, right? The database owners would need to be able to handle database, right? And on the failure part of it, not on the failure part of it. No, I think what Vikas suggested earlier, right? No, Sam, I think the way it is, is you have this association. At the point of failure, what Vikas said is to, can we have a filter to just say, hey, this is the whole stack, but I just want to see what are all the databases involved in this. That became a parent, but they are all still parent-child relationships. So yeah, I think we should still have the parent-child thing. That's what I feel, but I don't know. If we don't have that parent-child thing, sometimes we don't even know if the Uber guy is expecting somebody to just go independently do the databases. Because the Uber guy has some responsibilities. Become on the relationship, right? Even on the database tab, right? We can have a mark indicating this is part of a vertical. Correct, correct. That we need to have it. It's not that we are keeping it ignorant of that. Right? No, I mean the whole collection itself is vertical. But key part here is to Sabah's point, right? This whole, if we are saying that it is like going VM1, there are four VMs in a cluster, VM1 is going DB, I mean sorry, OS, GI, and all five database instances. Then it is going VM2, DB, GI, and all five database instances. Right, right. But what I'm saying is that relationship during creation is not established because it's a separate. Looking at the from a developer perspective, from a customer perspective, from an operator perspective, right? He doesn't care, you know, what sequence it is or when it is done. For him, right? My application is a hundred databases. I need to make sure that my databases are getting done or not. Yeah, if anything, if we do this flattened view, yeah, one of the things will be because you see, if it is sitting on progress to Jonathan's point, right? And if you're on a database page and let's say all of them say progress, then the work request needs to say that currently doing vertical patching of your OS. It has to say that, right? Then it will say currently doing GI patching of your VM1. In fact, it has to say exactly database instance one is running on VM1, VM1's OS is going on, VM1's GI is going on. Now database instance one is going on, right? Otherwise it will be. Yeah, I mean, like if you split, yeah, if you split the presentation, then you have to explain that in the work request of the child that your parents' certain component is going on. Otherwise they will think that, oh, it is taking such a long time and is my database update even started? That's what I was saying, when, when, who was asking, will it show as executing or will it not start at all or something, right? Correct. So yeah, because otherwise you'll think that database patching is being, if you, and if the way you are describing somebody comes to the cycle and they're only watching this tab, which is kind of very, to me, we have to go back and think what it means. That means, rest of the tabs they are not have access to, they don't watch. Then they will be like, oh, two hours, 43 minutes, database is going on. Open the work request. Like even a single job has not started. They will be like, anything don't have hardback for others. They will be like, oh, two hours, 43 minutes. They will be reasoned and they will say, two hours, 43 minutes, nothing happened in the database. So if we split it, it will become a different kind of model, but it has other benefits because then this whole thing. Yeah, I mean from the plan database alone and my database got done in 45 minutes. Now it comes to vertical, the clock duration will be longer. Longer, right? So we will have to keep on saying, in fact, hey, this is not. Does not work for you. It's taking too long. No. We are other components between which, you know, which he has to understand. Correct. So in fact, so if we go with this kind of presentation, advantage to this kind of presentation is you can do right click on this tab and create a report if you're a database guy and not have other components. There is other kind of reporting benefits to this view because then you are truly in a statement of vertical or non-vertical. You can have database be like database. Correct. So in fact, in this statement, if we go with this kind of presentation, advantage to this kind of presentation is you can do right click on this tab and create a report if you're a database guy and not have other components. There is other kind of reporting benefits to this view because then you are truly in a statement of vertical or non-vertical. You can have database be like database. Correct. So in fact, in this statement, if we go with this kind of presentation, advantage to this kind of presentation is you can do right click on this tab and create a report if you're a database guy and not have other components. There is other kind of reporting benefits to this view because then you are truly in a statement of vertical or non-vertical. You can have database be like database. Correct. So in fact, in this statement, if we go with this kind of presentation, advantage to this kind of presentation is you can do right click on this tab and create a report if you're a database guy and not have other components. There is other kind of reporting benefits to this view because then you are truly in a statement of vertical or non-vertical. You can have database be like database. Correct. So in fact, in this statement, if we go with this kind of presentation, advantage to this kind of presentation is you can do right click on this tab and create a report if you're a database guy and not have other components. There is other kind of reporting benefits to this view because then you are truly in a statement of vertical or non-vertical. You can have database be like database. Correct. So in fact, in this statement, if we go with this kind of presentation, advantage to this kind of presentation is you can do right click on this tab and create a report if you're a database guy and not have other components. There is other kind of reporting benefits to this view because then you are truly in a statement of vertical or non-vertical. You can have database be like database. Correct. So in fact, in this statement, if we go with this kind of presentation, advantage to this kind of presentation is you can do right click on this tab and create a report if you're a database guy and not have other components. There is other kind of reporting benefits to this view because then you are truly in a statement of vertical or non-vertical. You can have database be like database. Correct. So in fact, in this statement, if we go with this kind of presentation, advantage to this kind of presentation is you can do right click on this tab and create a report if you're a database guy and not have other components. There is other kind of reporting benefits to this view because then you are truly in a statement of vertical or non-vertical. You can have database be like database. Correct. So in fact, in this statement, if we go with this kind of presentation, advantage to this kind of presentation is you can do right click on this tab and create a report if you're a database guy and not have other components. There is other kind of reporting benefits to this view because then you are truly in a statement of vertical or non-vertical. You can have database be like database. Correct. So in fact, in this statement, if we go with this kind of presentation, advantage to this kind of presentation is you can do right click on this tab and create a report if you're a database guy and not have other components. There is other kind of reporting benefits to this view because then you are truly in a statement of vertical or non-vertical. You can have database be like database. Correct. So in fact, in this statement, if we go with this kind of presentation, advantage to this kind of presentation is you can do right click on this tab and create a report if you're a database guy and not have other components. There is other kind of reporting benefits to this view because then you are truly in a statement of vertical or non-vertical. You can have database be like database. Correct. So in fact, in this statement, if we go with this kind of presentation, advantage to this kind of presentation is you can do right click on this tab and create a report if you're a database guy and not have other components. There is other kind of reporting benefits to this view because then you are truly in a statement of vertical or non-vertical. You can have database be like database. Correct. So in fact, in this statement, if we go with this kind of presentation, advantage to this kind of presentation is you can do right click on this tab and create a report if you're a database guy and not have other components. There is other kind of reporting benefits to this view because then you are truly in a statement of vertical or non-vertical. You can have database be like database. Correct. So in fact, in this statement, if we go with this kind of presentation, advantage to this kind of presentation is you can do right click on this tab and create a report if you're a database guy and not have other components. There is other kind of reporting benefits to this view because then you are truly in a statement of vertical or non-vertical. You can have database be like database. Correct. So in fact, in this statement, if we go with this kind of presentation, advantage to this kind of presentation is you can do right click on this tab and create a report if you're a database guy and not have other components. There is other kind of reporting benefits to this view because then you are truly in a statement of vertical or non-vertical. You can have database be like database. Correct. So in fact, in this statement, if we go with this kind of presentation, advantage to this kind of presentation is you can do right click on this tab and create a report if you're a database guy and not have other components. There is other kind of reporting benefits to this view because then you are truly in a statement of vertical or non-vertical. You can have database be like database. Correct. So in fact, in this statement, if we go with this kind of presentation, advantage to this kind of presentation is you can do right click on this tab and create a report if you're a database guy and not have other components. There is other kind of reporting benefits to this view because then you are truly in a statement of vertical or non-vertical. You can have database be like database. Correct. So in fact, in this statement, if we go with this kind of presentation, advantage to this kind of presentation is you can do right click on this tab and create a report if you're a database guy and not have other components. There is other kind of reporting benefits to this view because then you are truly in a statement of vertical or non-vertical. You can have database be like database. Correct. So in fact, in this statement, if we go with this kind of presentation, advantage to this kind of presentation is you can do right click on this tab and create a report if you're a database guy and not have other components. There is other kind of reporting benefits to this view because then you are truly in a statement of vertical or non-vertical. You can have database be like database. Correct. So in fact, in this statement, if we go with this kind of presentation, advantage to this kind of presentation is you can do right click on this tab and create a report if you're a database guy and not have other components. There is other kind of reporting benefits to this view because then you are truly in a statement of vertical or non-vertical. You can have database be like database. Correct. So in fact, in this statement, if we go with this kind of presentation, advantage to this kind of presentation is you can do right click on this tab and create a report if you're a database guy and not have other components. There is other kind of reporting benefits to this view because then you are truly in a statement of vertical or non-vertical. You can have database be like database. Correct. So in fact, in this statement, if we go with this kind of presentation, advantage to this kind of presentation is you can do right click on this tab and create a report if you're a database guy and not have other components. There is other kind of reporting benefits to this view because then you are truly in a statement of vertical or non-vertical. You can have database be like database. Correct. So in fact, in this statement, if we go with this kind of presentation, advantage to this kind of presentation is you can do right click on this tab and create a report if you're a database guy and not have other components. There is other kind of reporting benefits to this view because then you are truly in a statement of vertical or non-vertical. You can have database be like database. Correct. So in fact, in this statement, if we go with this kind of presentation, advantage to this kind of presentation is you can do right click on this tab and create a report if you're a database guy and not have other components. There is other kind of reporting benefits to this view because then you are truly in a statement of vertical or non-vertical. You can have database be like database. Correct. So in fact, in this statement, if we go with this kind of presentation, advantage to this kind of presentation is you can do right click on this tab and create a report if you're a database guy and not have other components. There is other kind

vertical also and even vertical. But right now, of course, database is not part of vertical, right? It's only OS plus GI. Yeah, so see, that's where, right? Because once you dedicate... But what I'm saying, when they go to database, they will want that model to continue. That is, what the difference will be from their perspective is, so the same guys who are doing database today, the departments, right? The finance or whatever, whatever it is, they will be physically delegated to them. They will still submit their jobs, okay? Right? But it will get executed as part of a vertical and they will be informed, hey, you know, we are doing the vertical this weekend, so you guys monitor your database jobs. You guys have submitted it and they have submitted, it will go into a queue and then it will get executed as part of vertical, but they will be asked to monitor their jobs, their database jobs. And at that point, you know, their experience should be pretty much the same as what they have seen earlier. They will be with a single target because sometimes they may have a round of patching where there is only database, right? Some security fixes come in, some new image for database, so they can't say, hey, this is vertical, I'm seeing, I've got to go through this. This is not vertical, I've got to go through this, right? You give them the same experience. But in real life, that's how it is, at least on the ones that we know. But once we do the splitting, right, I think that keeping OS and GI in one payload also is kind of a little more confusing. We may have to... No problem, it's like one-to-one is to one, right? It's not too bad. But you mean resource to number of, I mean, the number of resources are just one. One OS, one GI, right? Yeah. Yeah, yeah, yeah. I mean, the cardinality is not in the hierarchy. Exactly, yeah. So that's not too bad. Yeah. Yeah, it's more of complete. So, okay, we'll... I don't think, because it will not, like all the other decisions we made, even if it's split, will not change. But I do think that at the time of creation, if you don't have this parent-child relationship, and then how is the vertical aspect kind of driven, like the mental model that this is vertical, how does customer know that this database is related to this VM cluster, right? That part is not yet... On the job part of it, not on the creation part. On the job part of it, nothing changes, right? They've done the job. Yeah, so the creation part of it, also Sabah mentioned, right, that you will not be able to show you parent-child like that. You will have to do kind of like a... See, when you have a side panel, they can also be kind of reference resources. That doesn't mean it is a side or anything, right? So parent-child relationship, do we need that tree to show that or can we just get away with it? Because then you can also argue technically that at the time of creation, the screen, yeah, this is vertical, I'm seeing I've got to go through this, this is not vertical, I've got to go through this, right? Do you give them the same experience? But in real life, that's how it is, at least on the ones that we know. But once we do this splitting, right, I think that keeping OS and GI in one payload also is kind of a little more confusing. We may have to... It's like one-to-one is to one, right? It's not too bad. But you mean resource to number of... I mean, the number of resources are just one. One OS, one GI, right? Yeah. Yeah, yeah. I mean, the cardinality is not in the hierarchy. Exactly, yeah. So that's not too bad. Yeah. Yeah, it's more of complete. So, okay, we'll... I don't think because it will not, like all the other decisions we made, even if it's split, will not change. But I do think that at the time of creation, if you don't have this parent-child relationship, and then how is the vertical aspect kind of driven, like the mental model that this is vertical, how does customer know that this database is related to this VM cluster, right? That part is not yet... On the job part of it, not on the creation part of it. On the job part of it, nothing changes, right? They have done the job. Yeah, so the creation part of it, also someone mentioned, right, that we will not be able to show you parent-child like that. We will have to do kind of like a... Let's see, when you have a side panel, they can also be kind of reference resources. That doesn't mean it is a side or anything, right? So parent-child relationship, do we need that tree to show that or can we just get away with it? Because then you can also argue technically that at the time of creation, the screen, yeah, this is vertical. I'm seeing I've got to go through this. This is not vertical. I've got to go through this, right? Do you give them the same experience? But in real life, that's how it is, at least on the ones that we know. But once we do this splitting, right, I think that keeping OS and GI in one payload also is kind of a little more confusing. We may have to... No problem, it's like one-to-one is to one, right? It's not too bad. You mean resource to number of... I mean, the number of resources are just one. One OS, one GI, right? Yeah. Yeah, yeah. I mean, the cardinality is not in the hierarchy. Exactly, yeah. So that's not too bad. Yeah. Yeah, it's more of complete. So, okay, we'll... I don't think because it will not... Like all the other decisions we made, even if it's split, will not change. But I do think that at the time of creation, if you don't have this parent-child relationship, and then how is the vertical aspect kind of driven, like the mental model that this is vertical, how does customer know that this database is related to this VM cluster, right? That part is not yet... On the job part of it, not on the creation part. The job part of it, nothing changes, right? Yeah, so the creation part of it, also someone mentioned, right, that we will not be able to show you parent-child like that. We will have to do kind of like a... See, when you have a side panel, they can also be kind of reference resources. That doesn't mean it is a side or anything, right? So parent-child relationship, do we need that tree to show that or can we just get away with it? Because then you can also argue technically that at the time of creation, the screen, yeah, this is vertical. I'm seeing I've got to go through this. This is not vertical. I've got to go through this, right? Do you give them the same experience? But in real life, that's how it is. At least on the ones that we know. But once we do this splitting, right, I think that keeping OS and GI in one payload also is kind of a little more confusing. We may have to... No problem. It's like one-to-one is to one, right? It's not too bad. But you mean resource to number of... I mean, the number of resources are just... One OS, one GI, right? Yeah. Yeah, yeah. Yeah, I mean, the cardinality is not in the hierarchy. Exactly, yeah. So that's not too bad. Yeah. Yeah, it's more of complete. So, okay, we'll... I don't think because it will not, like all the other decisions we made, even if it's split, will not change. But I do think that at the time of creation, if you don't have this parent-child relationship, and then how is the vertical aspect kind of driven, like the mental model that this is vertical, how does customer know that this database is related to this VM cluster, right? That part is not yet... On the job part of it, not on the creation part. The job part of it, nothing changes, right? They have done the job. Yeah, so the creation part of it, also someone mentioned, right, that we will not be able to show you parent-child like that. We will have to do kind of like a... See, when you have a side panel, they can also be kind of reference resources. That doesn't mean it is a side or anything, right? So parent-child relationship, do we need that tree to show that or can we just get away with... Because then you can also argue technically that at the time of creation, the screen, yeah, this is vertical. I'm seeing I've got to go through this. This is not vertical. I've got to go through this, right? Do you give them the same experience? But in real life, that's how it is in the... At least on the ones that we know. But if once we do this splitting, right, I think that keeping OS and GI in one payload also is kind of a little more confusing. We may have to... No problem. It's like one-to-one is to one, right? It's not too bad. You mean resource to number of... I mean, the number of resources are just... One OS, one GI, right? Yeah. Yeah, yeah. I mean, the cardinality is not in the hierarchy. Exactly, yeah. So that's not too bad. Yeah. Yeah, it's more of complete. So, okay, We haven't implemented yet, but we do have one row expansion, but multiple child resources, we don't have yet. And also the ability to check, this is multi-select, the one which the proposal I'm working on is single-select. So three expansion with, I mean, here he's not showing it, but the one which he was showing, right, the pattern, the three expansion multi-row with multi or single select, that is the pattern eventually we want. I mean, not in this project, but that is the, I'm talking about a different project when I'm using that. So if multi-row is not there, or multi-select is not there, or single-select is not there, then we have to come up with alternatives for it. Yeah, Vikas, now the staging, right? Did we decide how we're going to ask for images based on version for the database? Yeah, that's the thing, the first screen, right? I think. I kind of forget, where do we ask for this? Image selection based on the version. Image selection based on the... Let's say a cluster has some 19 databases and 126 databases, right? Both need to be patched. We need to ask for the image for 19 image for 26. You are talking about the target or goal version. Yeah, the target. Yeah, this is the presentation, Sam. Yeah, so this is doing, that's doing create maintenance cycle and actions having access to the image model. The idea is that during stage, we will use the FSU actions resource principle to access the image in the stage again. So that's the customer will be responsible to send it. And even in Oracle stock, I think there will be a few more properties, I think, the release month. And then we will maybe, depending on how the MRP implementation goes, maybe it will be a normal image or it will be a normal image underscore MRP1, MRP2. And then the key part then will become when was it released, the month, date, and whether it has a security SNO or whatever. So there will be more metadata even on the stock image other than the version. So a simple dropdown may not cut it. At least custom it will not. Maybe it will work for stock image, simple dropdown now, but that simple dropdown will also have more identifier properties in the future. So that UX is not a problem. But can you go back to your UX which you were presenting to Sam, the one in the back? So Sam, the idea is that whether your target version is, actually this UX also will improve, right? Because target version is derived from the stock image or customer image. And if you're doing a customer image, you will have some more attributes to show that, you know. But yeah, I think, so I think I was thinking, hey Sam, I think tomorrow somebody will be there, right Sam, from your end. Look, finally be there. Look, finally be there. Okay. So anyway, we will go with this. See all these things anyway, friends, I think this has to go more rounds with broader, little more broader audience. And probably I don't know if they're having plans to review with one and others also, right friends, at some point. Yeah, so we'll have to, yeah, so we'll have to come up with that story of a review. But what I was hoping is that, yeah, we will do a full, yeah, we'll craft that. Yes, we will do that. But I think the idea is the API should not kind of have much impact. Like even what Sam's coming, how we can achieve it with the existing ones, right? Correct. Then I think we have a story. Correct. Okay. API is fine. I mean, it's just data, right? Correct. Correct. I think that's a part. So we will go with that tomorrow and then we will kind of rehash these things as we move up with the user experience. Yes, Sam, I please also have and then your inputs because the one thing Sam, I think is all these things are ideally it would have been better with the UX designer and things where I think we kind of focused that Prince Vikas, they had these things, right? But I want your inputs also, Sabha, okay? We need more of the kickoff call. Yeah. After the kickoff. I think that we can have some finer discussions around that. So I'm saying like, can we move the kickoff itself so that like I can have the concrete type for this. No, I think let's do this because this kickoff has been... So Sabha, this is the engineering kickoff. This is not the project kickoff. So that's what we have. So we still have time. By the time project kickoff, we will close out all these things. So because that way, main is see, Vikas needs that EPS and one more question Vikas. The jobs is flattened. So in the example, it will be 120 job IDs of which 100 will have related job ID posted, correct? But in the initial creation, when you have the parent-child what Sabha is saying, is it a flat list of, is it 120 targets or is it 10 targets with children targets? Okay, then we have got API is good. So the main work is there, right? So UI we will discuss. Okay, good. So that means we are not changing much in the, and nothing of what's last Sam said about custom image dropped down. None of that impacted the number of goal versions and the representation also. Yeah, but that did not impact your Vikas any, nothing, doesn't impact you, right? Because the goal version presentation, multiple goal versions having the goal version and the version is derived from custom image. None of those things are impacted. Yeah, I mean, I think. So basically we are mapping into the number of major versions in the collection. And if you, even if you have additional metadata, you only care about the version, but all of that is just for the customer to make a choice. Right. If you're coming from API, you just plug in the goal. So all nine can see databases with no discussion, all 26 systems, whatever database system, no discussion. They're not going to run subsequent. They can say, oh, more 19.x to 19.1 and more 19.8 to 19.3. We are not going to have that type of thing. No, no, what I'm saying is for an API user, and when I'm doing this target version setting in the cycle, if I say 19.31, the only thing you care about from the custom image is the final OSID, right? You just have to go and OSID it, right? You have no other metadata, right? All the things we're talking about, target versions, talk image, we'll have extra date, all of that. That is all coming from some other thing. Right. Update ID order. So basically, none of those things change your current. So it looks like API things have not been changed. So Sabha, your point, I think you should ask the engineering kickoff. Right, Sabha will have this and then we will kind of proceed. Like Prince said, the UX may have some transformation, right, Sabha, that we can have discussions. Sure. Okay. Okay. Okay, then I'm going to jump to another call also. Okay. Thanks. Thanks. Thank you. Thank you so much. Yeah.