Security Waiver Strategy for Database and System Updates

Transcript

Hi, how's it going? All right. This one, security, the discussion is just getting more intense. Last 10 minutes, I didn't check Slack and there are 2,300 messages. It looks like something is going on. I mean, yesterday we had one call with one plan. It's not, I mean, it was more about N and N-1, like supported cloud, we are kind of restricting. And then, yeah, I mean, then. But was there any kind of fruitful outcome from that call? So, I can update quickly, right? So, DB and GI both, proposal is only N is the available version for provisioning, for patching. 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 the database. So, even in that flow. So, only N is allowed. If you need older, then you, short term, short term meaning in the next two weeks, what we're going to deploy, given all this mitos 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 2 to 3 weeks proposal. OS, same thing, only N. OS meaning guests only N without exception, only N is available, both for VM plus provisioning and guest service patching. Then the medium term, which is right after like 4 to 6 weeks out, is N continues to be available without any 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 will be some cloud attribute which stores your intention, where you've signed the waiver in the cloud 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 the X data Linux 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 or whatever, through SR. And for guest, anything below N-1, which by the way, in guest OS it is monthly. So, basically, you are just giving two months of versions in cloud. One is the latest current month, X-ray 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 are 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 values or whatnot. So, those whole 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 3-4 days. And I think the effective dates may be from when this will happen, 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 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 right now. 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 hands-off. One other 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 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. This is like a one-time decision. That's what you were saying that are we changing the rules perpetually? So he's like, we will see. Hey, mom 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. 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 I just said is about the RU itself. But yeah, I know we are hitting customers badly. Yeah, so I don't know this MRP thing, you know, it has been around, but we are not publicizing it a lot, right? So they are saying, why the heck is... Do we need, because these are 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. That's what I'm saying, right? But now we have thousands. Yeah, thousands, whatever, right? You and me. That's the number, right? Yeah, MRP will have thousands. 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, Mitos or 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 they 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 service waivers. Basically we want customers to go with 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 continuity beyond whatever 19.whatever, 19.20 or 21, whatever your production is. But you need to, somebody in the customer side sees so as to sign that document. That's what we want. See, we got a notification from one customer saying, oh yeah, there's so many issues in 19.30. Yeah, that's a different, because yesterday Warren, I don't know how we, I think it's actually, those guys, you know, they mix up the tooling versus the content, you know. So, yeah. Their thing is there are so many problems with the FIP. Oh no, no, FIP. But what I'm saying, Warren yesterday asked an even more nuanced statistic. He was saying that, can somebody tell me for DBGI and X-ray data, 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 are 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 a regression, it's also a next percentage of fixes. So, I mean, we have to tighten, you know, the real issue here is not the... Because when I get a problem from customer, right, I go to my team and say, hey, look, guys, you know, 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

Okay, so should we delay on that feature, that API? This one I will go after that, right? After that preview. Yeah, this will go after that. So I think until then we can just maybe hardcode eight and then move all that. Yeah, it should be totally independent of what you select. Yeah, but yeah, these are the multi-select drop-downs in the future. But for now, it's single select for OS and GI, multi-select for DB. It shows a double though, right? Because for GI, I see 19, C800A8. Yeah, and I can change it, but I just called out for P100. That's been corrected, right? Yeah, I mean, I put the note here saying for it's only single select for OS and GI, but I think... And should be 26A, right? No more 26. All right, sure. Yeah, I mean, there should be only one entry there for P1, for the API. Yeah, and the other change that is happening here is 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 we will remove and the proposal is that it will be moved here and the drawer will be simplified to only show these basic criteria, nothing else. And we will also show 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 collection type. For the stack, we are moving. Oh, okay. Let's call it out. I think it's there. Yeah, I think just mention for all the executable stack collections. We can add an extra note. Yeah, so only for this collection type we are... This one and the one we already shipped, Salva. This is the second stack type, right? So we had the GI and OS, and this is GIOS 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. I think there was a previous conversation that simplified the whole system. 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, what to focus on. And this is basically after the search in progress, but one thing, another 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 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 selected and then they can add the targets later. I don't think many people will do it, but we are just aligning with the other collection types. Oh, the... It's all or nothing, right? All or nothing, or... So today, like if you go to a DB collection, you can skip the search criteria altogether and just select the major version for DB and click create. So when we see the targets, targets would be under that table, right? Right, but 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 that's 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... So what is this table then? No, no, this table is if you hit search criteria, you add 50 targets and you click create, that is the regular flow, right? Even if you don't add search criteria, you just create and then add targets later. That is also, that was not supported for stack before. So we are just doing a correcting that, 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 feedbacks, Saba, is that, you know, that should we change the interface of how we add... Targets are not required, right? So we don't need to show that table. If you 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 currently, all collections have that table. We can remove that. Yeah, okay, let'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 search is done, the 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 trustors and associated databases like China resources basically. And we can discuss this in presentation if we can simplify it further. But for now, I think we will have these filters to begin with. And of course, the combat filters can be multi-select because the targets can span across compartments. And we can try to see if we can simplify any of these other columns. But for now, the idea is like it will be a tree table with these three columns for joining the individual components versions, the current versions. Okay, this thing came from UX designer or you guys made it? I think that's from the UI. I'm not sure whether we have your key table now, but we just have the expand and collapse. I would have to take a look at the library. We haven't implemented any key table. It's a one row expansion. Yeah, no, that is there. I'm referring to this pattern. If 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 have one row expansion. 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. Would be a flat list. 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? Now, the point is, ready to be seen in the screen.

Correct, correct. So then, that's what I'm saying. So then, actually... So correct, so then how will they... Correct, so then how will they... If it goes to the GA screen, the GA, he will say something is failed or whatever it is, right? No, but this hundred databases MCDA, the association is on the hierarchy from the... Correct, that is the intensive because he already, he knows it. No, but we know it, but where does he associate that? Let's say we give a name 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? On the point of execution, you know, it should look like, you know, the one... Look like if you have submitted a hundred databases and 10 OS and 10 GI, right, these three as individually. So he can go and manage those. Only thing is that when you're doing this, when you're looking at the database, they are still progressing. If the database is not failed, right, if it's waiting for the next node, things are going on, that's fine. But if it goes to GA, you will see it's a failure. Right, no, but Sam, you are still thinking that it is hierarchical, right, Sam? I think it's... No, I think it's... Yeah, I think Sam is saying that. Yeah. But the other way, you know, the interface, right, will get so confusing to the customer. He needs to feel like, you know, I'm... I can submit a hundred databases, right? And then I see the job, the 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 retie, whatever, that experience of 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. Right? No, but the retie, you are saying that it will be separate things, Sam. What is that? Even the retie, you are saying that somebody just goes to... The retie will be on the same component. He will say what failed, right? OS failed, the go rate and the OS and then you 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 are just multiplying. One failure in the OS will say GI failure, 10 databases failed. 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 this 10 and all those things, right? That is what I'm saying. This was promising, no noise. There's 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 20... I'm not going to fit in one screen. And then also the failure will get percolated to the top, right? I think we have it in the other one, right, Vikas? If you are submitting 100 databases patching, they are all in progress. Something fails, say the 90 was failed. It will percolate 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 we are racing on the date column, then the default sort is not like... It should bubble up the failure in some form, right? That's not the bubble, it's just how it is represented based on the filter and the sort. So Sam, this one we can look at but one question I had. So for example, just to break that down, right? So you have in this example, say in 10, we have clusters. So technically, just for the 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 engineer knows about, right? The end person who is 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 start OS here. I'm saying we can show a bar saying, hey, this is part of a 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. So you have 10, three tabs, just for sake of argument, 10, 10, 10, 10, 100, right? So now the question is, if you have an OS failure, which is the first thing which has happened, let's say VM cluster 1, 2, 1 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 don't go concurrently. I don't think that will be the case. But whatever, where the OS is crossed over, it has gone ahead with GI, probably gone ahead with DB. Right, right, right. But what I'm saying is just at 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 they have not started, right? I mean, they just started and you will get started. Now 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, just for now, let's say and just for sake of this discussion, all these VM clusters are all four 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. 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? 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 are also 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 progresses, you are envisioning and maybe you are thinking is slightly different. But let's just see what you are saying. No, but it was going to be, right? No, no, but we had all of this in one page. It is like all parent-child. No, no, I'm just saying that is not visually friendly to the 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 is not hundreds of, right? Those hundred are like each, let's say again, just to make this example more simpler, right? Yeah, one VM cluster has 10 databases. So you have each row has 10, 10 databases in it. But they are related because the first VM cluster's first VM and the first GI and the first database, all are going to be done together. That is when one VM will be done. Then the second VM cluster, second VM, so OS will be done, GI will be done. And the second, each of those 10 databases, one, one, one, one, one, one will be done. Correct. So... 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 failed. No, no, the point in showing that is, if you want to show 10 databases failed because the GA failed, right? The customer is going to see a lot of things. And what is he supposed to do? No, no, no, no, databases are not what we show. 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, 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

the presentation is the same no matter whether you are doing vertical. That I completely, that is something worth exploring. But if you're saying OS and GI is combined payload because they are relationship, then the database is also part of that combined payload, right? No, no, no, not right now. Right now, the way it has been implemented, OS and GI are bundled in one request, right? And we have rollback or revert or continue retry for combined OS and GI. We don't have it individually. If we can do it individually, I would put them in separate screens. Correct. Okay, so if they were, I mean, which is what we are going towards, so you're saying in that case, you'll have three tabs. One is for OS, one is for GI, and one is for DB. Here are kind of taking the conversation. But if you go to databases, right? Then you want to be able to see, hey, I've got my hundred databases. You know, 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. Yeah, 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 here, right? Here, the only difference between the two barring Sabah's comment on it. The 10 is green, but the 100 is not green, 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 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. Barring Sabah'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. Yeah, I know, but look at the user experience. Yeah, so the user experience that, yeah, 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 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, DBGIOS, everything is good. Utilization of the summaries. Yeah, you will get, yeah, so now that's 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 RCE, 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 imagine you have 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 is 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 interacted with. You right-click and say retry GI or rollback GI, whatever you want. But you open 10 databases, they are not progressed. They are 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. From the way I see it, from a customer perspective, this is a little bit more tedious. Right? You need to go and then uncollapse those, expand those. Otherwise, you have to switch between tabs and make the correlation that which is the parent and which is the child. Tab is super constant. Right? Tab is right there. Right? No, no, no. 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 it belongs to. You don't need to know which parent it belongs to. Right? It can go click on the database, retry. Whatever it is. Right? And 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, it's perhaps 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 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 other 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, now see, the way customers see it, right, it sounds like, you know, they, they understand this, this hierarchy here, but for them, there is a database team, there's an infrastructure team, you know, in most likely in, in Westford core, that's how it is. In Buffalo, I don't know how it is, but it's, I'm assuming, yeah, that's how it is in Buffalo also because the, the database part of it, right, they're, they're given out to the respective departments. They handle it. And then the, the infrastructure part of it is handled by the central team. Right? So it depends on, you know, that the same thing, as long as we tell those guys, Hey, look, you know, there is something that's still going on. You don't need to do any action. That's fine. And for, 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, we have to play that out. Sam. I'm just thinking because the key part there is like, one only last question I have retry in that example. It's a very minor issue, but we don't, 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 VMs. 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 the handle of 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. I can still do it here. How will you do it? Because they don't have relationship with each other, right? No, no, no. That's the only thing. It's not dependent that way. Let's say there are 10 databases with a close failure in different VMs clusters. Okay. On the database tab, right? 10 databases. The only reason we show a failure there is because the database patching failed. Correct. Right? Because of the GI or OS. So the action to retry on all of them is completely valid. So the action to retry a subset of it is probably not important enough. Like,

vertical also and even but right now, of course, the database is not part of a vertical, right? It's only OS plus GI. Yeah, so see, that's where, right, because once you delegate, 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 database today, the departments, right, the finance or whatever, whatever it is, they will be if it's been 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'll go into a queue and then it will get executed as part of a 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 didn't do the single target because sometimes they may have a round of patching if there is only database, right? Some security fixes come in, some new image for database, so it 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. Because 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 OS plus one GI, right? Yeah. Yeah, yeah. I mean, the cardinality is not in there. 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... Not in the job part of it, not in the creation part. The job part of it, nothing changes, right? They have done their jobs. 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. It doesn't mean it is a child. 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... Yeah, this is... I'll tell you what will happen. Customers, today, for example, there's part of thing that we worked with before, what happens is they are scheduling a thousand databases for the weekend, okay? Now, in FPE, 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 will keep run those thousand commands in lots, right? They will say, let's do that in batches, 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. Please 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 flows 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 needs. You know, the guys who are doing the database, they don't know like which VM cluster or which OS, which GI. They have the database name and they're all unique anyway. 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. Sam, maybe that may be true in non-cloud world, but in cloud, I think the hierarchy may help. Mainly, at least with the ADLD cases and all, right? They know which DB in which cluster and knowing that... We are trying to bring gofa to cloud. We're trying to bring this power cloud, right? If you're expecting that they will change their organizational structure to accommodate cloud, I doubt it. The department guys, you know, they want to say, hey, you know, it's cloudified the cell. Otherwise, you know, you guys continue to, you know, your interfaces will change. But they want, they don't want to move people along or, you know, we all do a refund. 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 that point, you know, they have... even if it is a... even if that, like the Vikas 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 complaining that the requirement... 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 clusters but also has implicit database filter in it, you may, 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 names, 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, Sam, we are trying to get to. Yeah, okay, that's a fair thing. Yeah, I think that will... Yeah, I think we can accommodate that. But main thing, Sabha, 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, Sabha, what is the situation on tree? Because that tree thing I'm using in all other proposals also. So it's a very important... I'll 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 and the one which I, 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, I'm talking about a different project that 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. But Vikas, now about staging, right? If we decide how we are able to ask for images based on version for the database? Yeah, that's everything, the first screen, right? 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 26 databases, right? Both need to be patched. We need to ask for the image for 19 image for 26. You're saying about the target or goal version? Yeah, the target, target. Yeah, this is the presentation, Sam. And this will be, yeah, so this is during, that's during create maintenance cycle. Right. Yeah, create maintenance cycle. You're right. So basically, at that time, whatever, like, ignore the 2 for GI, just assume there is one OS, one GI major version and then... I don't see a dropdown. This is the default view. We will automatically populate the table. This is an internal API for that. And then show the default for the latest goal version strategy. The target version, will it show a dropdown? Yeah, the dropdown. Yeah