All the Executive Stack Collection Type

Transcript

All right, how's it going? All right. This whole security discussion is just getting more intense. The last 10 minutes, I didn't check Slack and there are 2300 messages. It looks like something is going on. Ah. I mean, yesterday we had one call with one. It's not, I mean, it was more about n minus one, like supported cloud, we are kind of restricting. And then, yeah, I mean, but was there any kind of fruitful outcome from that call? So, yeah, 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're 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 minus one or two or three or four, whatever it is. Initially, I think one was like, once you sign the waiver, how does it matter? You can go N minus whatever, nine, 10. Then we kind of had a back and forth because already cloud only supports for stock of images, it only supported N minus four. 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 guest 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 issue. N minus one and N minus two 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 where you have signed the waiver in blood or something, whatever. We still need to design that. So N minus two 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 Exadata Linux issues are more publicly known than whatnot. And there it is N minus one. So you have N and N minus one, which are available. So N is, of course, you don't need any waiver. N minus one through API, you will have a security waiver you have to sign and assume responsibility. And then anything below this, for DB, GI, below N minus two being N minus three, four, whatever, through SR, and for guest, anything below N minus one, which by the way, in guest OS is monthly. So basically you're just giving two months of versions in cloud, meaning one is the latest current month, Exadata image, and then one month before through the whatever security waiver, API-based 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 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 a separate discussion. So, but the decision is made that today or tomorrow, because two weeks from now, if we'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 custom images built with older RUs or whatnot. So those all things will now fail and you'll 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 or four days. And I think the effective dates may be from when this will happen, as in May 28th or June 1st or 2nd. I mean, between that timeframe, 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 really happy with what we support. And now we are making it even smaller. So, but yeah, I mean, that's multiple times. The problem is this heightened. 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. 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 Warren is saying, in this whatever May and June MRP, like we are looking at 5,000 fixes per month, security fixes, 5,000. 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're not on it, then we don't want to be responsible for it. You may have a database and he's like saying. This is 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. And 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 is 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 about the RU itself. 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, do we need, because these monthly fixes, he's a product so buggy. I mean, that's what somebody was saying, right? Like typically we have like five, six fixes. Yeah, that's what I'm saying, right? But now we have thousands. Yeah, yeah, yeah. Clausenpro got a number, right? MRB will have thousands. That's what this expected. I mean, we'll see, but the number of fixes till this whole thing kind of whatever this GenAI or whatever Codex is finding it, Mycosis or whatever, whoever is finding these things, till it gets to a point where at some point, let's say, just making 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 they completely turned it off, right? So only N is available. Everything else is, you have to sign that waiver. Cloud, that's what, I mean, effectively that's what we are doing, but we have some more API based service waivers. Basically we want customers to go with the 19.32, right? Or you sign the waiver and accept responsibility for an N-1. We don't want to be responsible. That's the key. You can continue. Maybe you have a business case for continuity beyond whatever 19.whatever, 19.20 or 21, whatever your production is, but you need to, somebody in the customer side needs to sign that document. Right. 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 accident. Those guys, you know, they mixed up the tooling versus the content, you know. So, so, yeah. The thing is there is so much problem with the people. Oh, no, no, no, but what I'm saying, one yesterday asked an even more nuanced statistic. He was saying that, can somebody tell me for DBGI and Exadata, the number of regression bugs which are caused by our security fixes or any fixes which we deem necessary, because those are also introducing 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 like, 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, it's also a next percentage of fixes? So, I mean, we have to tighten, you know, 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 are the results of the test? Did we pass it before we in the, on the main and on the RU? Did it get it to work correctly before we ship it to customer,

Okay, so should we rely on that feature, that API? This one I will go after that, right? After that preview. Yeah, this one is after that, so I think. I think after that, we can just maybe hardcode 8 and then. And GI and API I think today already. Yeah, it should be totally independent of what you select. Yeah, but yeah, these are multi-select drop-downs, in the future, but for now, it's single-select for OS and GI, multi-select for VS. It shows double though, right? Because for GI, I see 19, see how many API. Yeah, and then, I can change it, but I just called out for P100. I think, until then, we can just maybe hardcode 8, and then, put all that. And GI and API I think today already. Yeah, it should be totally independent of what you select. Yeah, but yeah, these are multi-select drop-downs, so in the future, but for now, it's single-select for OS and GI, but I think until then, we can just maybe hardcode 8, and then, put all that. And GI and API I think today already. Yeah, it should be totally independent of what you select. Yeah, but yeah, these are multi-select drop-downs, so in the future, but for now, it's single-select for OS and GI, but I think until then, we can just maybe hardcode 8, and then, put all that. Yeah, I mean, there should be only one entry for P1, for MAP. Yeah, and the other change that is happening here is the, when they click add research criteria, the other changes. So previously, the major versions were being shown here, for the research criteria, so the proposal is that will be moved here, and the drawer will be simplified to only show these basic criteria, nothing else. And we will also be moving the release version and the systems software release versions for from here. So basically, this will be the simplified search criteria. Okay, this would be permanently for all irrespective of the... For stack, we are moving. Oh, okay. Let's call it out. I think it's there. Yeah, I think, yeah, I just mentioned for all the executive stack collection type, we can add an extra note. Yeah, yeah. So only for this collection type, we are... This one and the one we already shipped, Salwad. 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. Okay. The other ones, we 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 in the same format as well. And I think there was a previous conversation that would simplify the whole. Yeah, 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 and progress. But one thing, another thing I will mention is that, today, the search criteria are kind of migrated. While it's creating a stack cycle, they have to open the drawer. But like it's like 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 bundled, and then they can add the targets later. That's just, I don't think many people will do it, but we are just aligning with the other collection types. Well, the, it's all or nothing, right? All or nothing. I'm not sure whether we have here a key table now, but we just have the expand and collapse. I will have to take a look at the library. We haven't implemented any key table. It's one row expand. Yeah, no, that is there. I'm referring to this pattern. You go to. Yeah, they have it, but I don't know whether jet have it or not. So I will have to take a look whether the framework that we use supports the key table. So we just pick up one row expansion. Yeah, that's what the question is. I don't know whether the visibility in terms of the customer, you know, looking at the results and acting on them. Right. Would be a flat list. That's what I'm thinking. How will we do that 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. Right.

Correct, correct. So then, that's what I'm saying. So then, after you... It's still progressing. Either if it's a second node or a third node, right? It's still progressing. Correct, so then how will they... It goes to the GA screen, that's people, for GA, he will say something is failed or whatever it is, right? No, but these hundred databases, let me see, the association is on the hierarchy from the... Correct, correct, that is interesting because he already, he knows it. No, but we know 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? I mean, this particular cluster ID. The point of execution, you know, it should look like, you know, the one execution should look like if you have submitted a hundred databases 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 result handling, the output, the progress, you know, the retell, whatever, that experience of, should be very similar to what is doing if it is doing only databases or if it is doing only GI or only OS. Correct, so then how will they... If you go to the GA screen, the customer, for GA, he will say something is failed or whatever it is, right? No, but these hundred databases, let me see, the association is on the hierarchy from the... Oh, that is interesting because... He already, he knows it. No, but we know 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? I mean, this particular cluster ID. The point of execution, you know, it should look like, you know, the one execution should look like if you have submitted a hundred databases and then I see the job results. Now, each and every database is patching. If the database is not failing, if the database is not failing, that's fine. But if it goes to GI, he will see it's a failure. 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... Yeah, yeah. No, but the other thing, you know, the interface, right, will get so confusing to the customer, right? He needs to feel like, you know, 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 result handling, the output, the progress, you know, the retell, whatever, that experience of it should be very similar to what he's doing if he is doing only databases or if he is doing only GI or only OS. Even the retry, you are saying that it will be separate things then? What is that? Even the retry, you are saying that somebody just goes... The retry will be on the same component. He will say what failed, right? OS failed, go retry on OS and then he continue on the other ones, on the vertical, right? But the GI or DB will not show failure at that point. Otherwise, you know, these failures will just multiply. One failure on the OS will say GI 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 why I'm saying the show is promising, no noise. If there is 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 see, these 100 databases with the 10 OS and 10, I don't want to fit in one screen. And then also the failure will be declared to the top, right? I think we have it in the other one, right, Vikas? If you're submitting 100 databases patching, they're all in progress, something fails, say the 90 was failed. It will populate 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, let's say I take column, then the default sort if it's not like... No, the sort, it should bubble up the failure in the top, right? It's about like this, right? Like if you have like this kind of a list, then this is what will happen. You can do this kind of a presentation option where you contain it. There's a progressive loading. Yeah, so this one I need to check it out. Like our framework, we don't have a... I don't know, I'll have to go back and check whether we support pre-table or not. So what I'm saying is like the first row will have your three dots that will open your panel where you see we are all talking about 10 databases, right? It could be N number of databases. So having the separate panel for choosing the database would be the right thing. So what's the choosing we can still get by, but the constant progress... It's the same clicks, right? It's the same click because you expand, you have to click on expand. That is equivalent to show databases. One click. It's the equivalent clicks. No, no, no, no, sir. I'm not even talking about clicks, right? I'm talking about the lifecycle of it. Those entries have API calls on it. That's my thing. And it is related to your parent's status. That's the key part. Here it is just adding. This is like still we can somehow get... Because you have that presentation. The idea was that the action, the individual jobs would also expand. It will look like this, right? Like if you have like this kind of a list, then this is what will happen. You can do this kind of a presentation option where you contain it. There's a progressive loading. Yeah, so this part I need to check it out. Like our framework, we don't have a... Tell me if there are 10, go back to your other screen. Okay. Where you had the PM process in DB, one DB. Now, how will the screen look like if there are 10 databases on each VM cluster? Then for each VM cluster, you will have the load more button. How many lines will be there for that? For the entries. 11. If you have a VM cluster as 10 databases, you will have 11 rows. So the screen is already used up mostly. But the other things will be collapsed. Because first of all, the first VM cluster... They will go off the screen. Correct. So these are... 100 will also please go off the screen, right? Because what you'll see in this page, he has a maximum entry step. So anything go even in the... Yeah. So... Yeah, so basically... ...with Sam and Prince, right? So we... I don't know. I will have to go back and check whether we support pre-table or not. So what I'm saying is like the first row will have your three dots that will open your panel where you see we are all talking about 10 databases, right? It could be N number of databases. Yeah, yeah, yeah. So having the separate panel for choosing the database would be the right thing. So about the choosing, we can still get by. But the constant progress... Minimum clicks. Yeah, yeah. So... It's the same clicks, right? It's the same click because you expand, you have to click on expand. That is equivalent to show databases. One click. It's the equivalent clicks. No, no, no, no, sir. I'm not even talking about clicks, right? I'm talking about the lifecycle of it. Those entries have API calls on it. That's my thing. And it is related to your parent's status. That's the key part. Here it is just adding. This is like still we can somehow get... This one we can still maybe, you know, somehow hack it together. I think it's confusing. But the main thing is that this structure is how the actions and jobs are also planned. Because each of those entries have its own dot, dot, dot. And it has its own lifecycle stating retry only this entry, not its parent. Or there is an option saying retry this parent with all its children. Yeah, that's still possible. It's 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 GIA, right? Retry is allowed, right? Rollback, yes. Retry on one cluster with 10 databases. If the GIA fails, there's no need to say retry for GA and the database. No, no, no, not... You don't have to. But if... Yes, correct. 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 clusters on one tab and the databases on another tab. No, there is no need to have the hierarchy thing, but that would be like, you know, the panel for the

It's a collection, the presentation is the same, no matter whether you're doing vertical. That I completely, that is something worth exploring. But if you're 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 there. Right now, the way it has been implemented, OS and GI are bundled in one request. Right, and we have rollback for the reward for continuous retry for combined OS and GI. We don't have it individually. If you can do it individually, I would put them in separate things. Correct. Okay, so if they were, which is what we are going towards, so you're saying in that case, you will have three tabs. One is for OS, one is for GI, one is for... Okay, so here I'm kind of taking the conversation, but if you go to databases, right, then you want to be able to see, hey, I've got 100 databases, how many have completed, how many have failed, and how many are progressing, right? Those kinds of things are visible on a database collection screen, and that is what I want to bring the same experience. But Sam, yeah, so I hope it is not because of what is seen on the screen. Seen on the screen is 10, whether you are 100 or whether you are in GA, right? Here, the only difference between the two barring Samad's comment on... The 10 is screened, but the 100 is not seen, right? No, no, no. Sam, on a page, you can only see 10, or whatever the limit is, 50, right? That is based on the viewport, right? Even if you see 50, nothing will happen here. So the difference is, you will have in the presentation, you are saying, you will have a table with 10 entries for OS, right? So they may or may not happen in the screen, depending on... We are all operating on a certain screen resolution. You will still have to scroll, right? You may still have to scroll, even for that 10, so you will have a screen for 10 OSes, 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've 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 present, 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. Barring Samad's comment that if the component 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 clean, right? You always have, it's a fixed function. It's always 10 rows, no matter what. And you only interact those 10 rows not collapsed. You know, all collapse. 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, DB, GI, OS, everything is correct. That's the localization of the summaries. Yeah, you will get, yeah. So now that's a different. Now, I'm saying versus 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, see. 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 if I have only 10 rows, and 7 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 last three are red. First one you open, OS has failed. So the minute you open, you will have an entry for OS, OS and GI, that entry itself, you will see, oh, OS has failed, retry. Database is 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, GI has 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 GI are marked as green, it's on the same row. And then on 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... The way I see it, from a customer perspective, it seems this is a little bit more tedious, right? You 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 fast, right? Tab is right there, right? No, Sam, but the tab is only there, but you still have to build a relationship, right? From there you have to find out which parent. You don't need to know which parent belongs to. You don't need to know which parent belongs to. The database speed, right? You can go click on the database, it's free. 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. Perhaps it's not technically what you 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 the other stack components. It will go complete the GI, it will complete the OS, then it will 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? Go ahead, 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's an infrastructure team, you know, it may most likely be in West Coast, that's how it is. In Bhopal, I don't know how it is, but I'm assuming, yeah, that's how it is in Bhopal 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, it's 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. We have to play that out, Sam. I'm just thinking, because the key part there is, like, 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. 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? Because that's where I, off the bat, without doing any, or rollback for that matter. So remember. It can still do it here. How will you do it? Because they don't have a relationship with each other, right? No, no, no, that's what I'm saying. It's not dependent that way. Let's say there are 10 databases that show failure in different VM clusters on the database tab, right? 10 databases. The only reason we show a failure there is because the database patching failed. Correct. Right? The colors 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

vertical also and database is not part of vertical, right? Yeah, so see, that's right because once you dedicate... But I'm saying when they go to database, they will want that model to continue. That is, what will have the difference will be from their perspective is, so the same guys who are doing database today, the departments, right, the finance or whatever or whatever it is, they will be physically delegated to them. They will still submit their jobs, 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 the single target because sometimes they may have a round of patching where there is only database, right? Yeah. Some security fixes come in, it's a new image for database, so we 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? Do you give them the same experience? But in real life, that's how it is. Yeah. At least in 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 an... 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 is 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? We have done it. Yeah, so the creation part of it also Saba 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. It doesn't mean it is a child or a parent, right? So parent-child relationship, do we need that need 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 here, this is... But 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 databases for the weekend, okay, now in FEP, of course, we didn't have collections, right? So they have to create a thousand commands, okay? And then Friday night or Saturday, whatever it is, they'll run those thousand commands in lots, right? They will say, I'll do that hundred in batches or whatever it is, right? They do the hundred. Now, wait for 30 minutes or half an hour or 10 minutes and do the other. Keep doing that till all thousand are running, something like that, right? Now, what happens is that on Friday evening, there are certain internal customers come back and say, hey, this database, I don't want, you know, there's some urgency is going on. I don't want this database you patched. Take it out. And they get about 50 databases. That's what they said. They get about 40 to 50 databases which are supposed to be removed. Okay. Now here for us, right, in this one, what really that requirement will not go away. What really shows in the creation or in the, not in the creation, in the creation of the maintenance cycle, right? They need to be able to take those databases off the current cycle. So we need to be able to give them, give them, and that will be based on the database names. You know, the guys who are doing the database, they don't know like which VM cluster, which OS, which GI. They will have the database name and they're all unique anyway, right? They have the database name and say, I got to go, you know, disable, you know, this database from getting patched because, you know, something important is running. So at that point again, you know, the hierarchy really doesn't help them. The flat thing helps. They can quickly go to the database and uncheck or check or whatever it is. Don't do check or whatever, right? And then it's off the table for that round. Some, maybe that may be true in on-prem world, but in cloud, I think the hierarchy may help. Mainly, at least with the cases and all, right, they know which DB in which cluster and knowing that... We are trying to bring both parts to cloud. We are trying to bring both parts to cloud, right? If you are expecting that they will change their organizational structure to accommodate cloud, I doubt it. The department guys, you know, they're going to say, hey, you know, it's cloudified the solve. Otherwise, you know, you guys continue to, you know, your interfaces will change. But they're not going to move people around because it's going to be done in phases, right? If an application has like a thousand databases, they might take a whole year or something like that to move those, right? At the point... They have a foot on both. Even if it is like the rigorous model, if you give a search and filter that they can just come and search the DB. Even on that, like even in that parent-child... I'm just saying that, I'm just tumbling with the comment. Yeah, no, no. Yeah, you're right. Like searching on a flat database page for databases versus starting on a page which looks like VM process, but also has implicit database filter in it. It may not be intuitive. And it's not even... See, UI is just one thing. I'm thinking the API payload, right? So if the API query is after on the VM cluster, give me databases, or is it based on databases, whether people flat or not? I think all of this is coming down to flatten out the namespace. It is much more modular and extensible and aligns with the operator model. Forget the data model. Data model is only for us to execute. The operator's model is database is different, clusters are different, and host is different. And that is continuing to... Should be the jobs model, execution model, reporting model is what I think Samir are trying to get to. Yeah. Okay. That's a fair thing. Yeah, I think we will... Yeah, I think we can accommodate that. But main thing, Shabab, let us know that, you know, Sam's comment plus if you say that trees are out, then we have other problems, right? But if we can solve Sam's concerns and if trees are available, then, you know, we keep it in the mix, right? So let us know, Shabab, what is the situation on tree. Because that tree thing I'm using in all other proposals also. So it's a very important... Yeah, I will get back on that. I 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, 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. Well, because, well, Kanban, about the staging, right? If we decide how we're able to ask for images based on version for the database... Yeah, that's everything, the first screen, right? I can't... Where do we ask for this image selection based on the version? Image selection based on the... Yeah, let's say a cluster has some 19 databases and some 26 databases, right? Both need to be patched. We need to ask for the image for 19 image for 26. You say the target or goal version? Yeah, the target, target. Yeah, this is the presentation, Sam. Yeah, so this is doing, that's doing create maintenance cycle. Yeah, create maintenance cycle. You're right. Yeah, 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