Database Version Control and Security Waivers

Transcript

Hi, how's it going? All right. This whole 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 Sam. 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 that call? So, I can update quickly, right? So DB and GI both proposed that 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 backup. 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-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 guest 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 four to six 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 signed the waiver in the cloud or something, whatever. We 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 being an X-ray data Linux issues are more publicly known and more talked. 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 guest, anything below N-1, 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 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 like a separate discussion. So, but the decision is made that today or tomorrow, because two weeks from now, if you 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 all 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 as 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 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 he's expanding on it. He needs exactly the same version. We cannot tell him, right? We discussed all of that with Sam. 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 Juan 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, So that's what you were saying that if, are we changing the rules perpetually? So he's like, we will see, Hey, wow. 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 I just said is about the RU itself. But I know we are hitting customers badly. 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 in the heck is, do you need, because these are 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. But now we have thousands. Yeah, thousand, whatever, right? Yeah, yeah, that's what 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, my thoughts 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're 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 that. We don't want to be responsible. That's the key. You can continue. Maybe you have a business case for continuing beyond whatever 19.x whatever 19 or 20 or 21, whatever your production is. But you need to, somebody in the customer site needs to sign that document. Right. That's what we want. See, we got the notification from one customer saying, oh yeah, there's so many issues in 19.30. 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, yeah. Their thing is there are so many problems with their TV. 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 X-ray data, the number of regression bugs which are caused by a 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 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, 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, on the main and on the audio, did it work correctly before we shipped it to customer, right? That is my line of thinking because we, development writers cannot anticipate and fix every bug. Okay. Right. So the focus should be rather than, you

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 after that, I think until then we can just maybe hardcode it. And GI and DB I think today already. Yeah, it should be totally independent of what you select. Yeah, but yeah, these are monthly select drop-downs in the future. But for now, single select for OS and GI, multi-select for B. It shows a double though, right? Because for GI it's like 19, 700 BA. Yeah, and I can change it, but I just called out for P100. That's perfectly correct, right? Yeah, I mean, I put the note here saying for this only single select for OS and GI. And should be 26 BA, right? No more 22. Yeah, I mean, there should be only one entry there for P1 for MAP. And the other change that is happening here is the search in progress. But one thing, 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 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. So the, it's all or nothing, right? All or nothing or... No, it's not. 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 press create. So when you see the targets, targets would be under that table, 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, but basically what we're saying is that the targets is 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, it's just a minor thing, nothing 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 click create, that is the regular flow, right? Even if you don't add search criteria, you just create and then add target later. That is also, that was not supported for stack before. So we are just saying we're 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 and create or without targets also you can create. That's the only thing Vikas 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 soon as the, as soon as the, I think until then we can just maybe hardcode it. It should be totally independent of what you select. Yeah, but yeah, these are monthly select drop downs. So in the future, but for now, single select for OS and GI multi-select for B. It shows a double though, right? Because for GI, it's in 19, 700 BA. 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 think, yeah. And should be 26 BA, right? No more 22. Yeah, I mean, this will be only one entry there for P1 for MAP. Yeah. And the other change that is happening here is the when you 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 look at 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 like the release version and the systems of their release versions for from here. So basically this will be the simplified search criteria. And this would be permanently for all irrespective of that. Just for stack that we are moving it. Oh, okay. Let's call it out. I think it's there. Yeah, I think I just mentioned for all except for 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 sir. This is the second extract type, right? So we have the GI and OS, this is GI OS DB for both of them we will use this pattern. Okay. 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 at the same format as well. I mean, I think there was a previous conversation that simplify them also. 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. But the only thing other thing I will mention is that today the search criteria kind of migrated where it's creating a stack cycle. They have to open the drawer with legacy 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 be doing but we are just aligning with the other collection types. Well, the, it's all or nothing, right? All or nothing or... Today, like if you go to a DB collection, you can skip the search criteria altogether and just select the search criteria, all together and just select the major version for DB and click create. So we can remove the targets, targets would be under that table, right? But in a DB case, that's not required. Like you can just go with an empty target and still create the collection. So we are just aligning this to that. So, but basically what we're saying is that the targets is 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. Nothing 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 click create, that is the regular flow, right? Even if you don't add search criteria, you just create and then add target later. That is also, that was not supported for stack before. So we're just saying we're correcting that. You don't, targets are not required to create a collection. You can add targets post-create. That is how all others collections are and stack will also follow the same part. This is nothing new we are saying. You can add targets and create or without targets also you can create. That's the only thing Vikas 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 soon as they enter the major versions. So, and it should be totally independent of what you select. Yeah, but yeah, these are monthly select drop downs in the future. But for now, single select for OS and GI, multi-select for B. It shows a double though, right? Because for GI it's in 19, 700 BA. Yeah, and I can change it, but I just called out for P100. That's perfectly correct, right? Yeah, I mean, I put the note here saying for it's only single select for OS and GI. And should be 26 BA, right? No more 22. Yeah, I mean, this will be only one entry there for P1 for MAP. And the other change that is happening here is the search in progress. But one thing, 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 legacy 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. What is 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 search criteria altogether and just select the major version for DB and click create. So when you see the targets, targets would be under the table, right? But in a DB case, that's not required. Like you can just go with an empty target and still create the collection. So we are just aligning this to that. So, but basically what we're saying is that the targets is 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

Correct, correct. So then, that's what I'm saying. So then... Correct, so then how will they... Correct. So then how will they... If you go to the GI screen, that's typical for GI, he will say something is failed or whatever it is, right? No, but this 100 databases MCD, the association is on the hierarchy from the... Correct, that is the interesting bit because he already knows it. No, but we know it, but where does he associate that? Let's say we give a pane that, hey, these are 100 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 100 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 look at the database, it should showing, if the database is not failed, right? If it is waiting for the next node, things are going on, that's fine. But if it goes to GI, you'll see it's a failure. Correct, correct. So then how will they... If you go to a page with 100 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... 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 action, the individual jobs would also expand. It will look like this. Yeah, but you know, because you have a, you have your example here, right? It says there's only one database. Imagine there are 10 databases. How will the screen look? It will show only one VM cluster. It will not show the remaining. Because that's the database lines. That's a misunderstanding of the UI pattern, which does not make us... If we don't, yeah, I can quickly go on that. 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 of the option where you can page it. There's a progressive loading. Yeah, so this part I need to check it out. Like framework, we don't have a... Go back to your other screen. Okay. Where you had the PM process and DB on DB. Now, how will the screen look like if there are 10 databases on each VM cluster? Yeah, then for each VM cluster, you will have the load more button. How many lines will be there for that? For the database. 11. If you have a VM cluster that has 10 databases, you'll 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... I know, but they'll go off the screen. Correct. So these are the... 100 will also please go off the screen, right? Because what you see in this page, he has maximum entries 10. So anything, even in the... Yeah, yeah. So basically... 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 OS has failed, one GI has failed. And then let's take actually all things 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 children. 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 will have 10 jobs. Of it, 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 failed. Let's say 11 databases are 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 panel. Yeah, that's good. Yeah, because it's just the way we have ingested the payload is how we are troubleshooting our experience, the 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 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 has completed. And when you open databases, you will see, oh. When you open, see, it's about what the screen, I just talked to visualize what is the customer looking at. Yeah, I think this one here, 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 action, the individual jobs would also expand. It will look like this. Yeah, but you know, because you have your example here, right? It says there's only one database. Imagine there are 10 databases. How will the screen look? It will show only one VM cluster. It will not show the remaining. Because that's the database lines. That's a misunderstanding of the UI pattern, which does not make us... If we don't add, yeah, I can quickly go on that. 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 of the option where you can page it. There's a progressive loading. Yeah, so this one I need to check it out. Like 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 and DB one DB. Now, how will the screen look like if there are 10 databases on each VM cluster? Yeah, then for each VM cluster, you will have the load more button. How many lines will be there for that? That's for the database. 11. If you have a VM cluster that has 10 databases, you'll 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... I know, but they'll go off the screen. Correct. So this is exactly... 100 will also please go off the screen, right? Because what you see in this page, he has a maximum entry is 10. So anything go, even in the... Yeah, yeah. So... Yeah, so we were spending with Simon Prince, right? So 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 was it choosing, we can still get by. But the constant progress... 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 life cycle 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 around. 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 life cycle states saying 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 presentation is the same, no matter whether you are doing vertical or that, I completely, that is something worth exploring. But if you're saying OSNGI is combined payload because they have a relationship, then the database is also part of that combined payload, right? No, no, right now, the way it has been implemented, OS and GA are bundled in one resource. Right? And we have rollback or revert or continue retry for combined OS and GA. We don't have it individually. If you can do it individually, I would put them in separate space. Correct? Okay, so if they were, 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, one is for DBs. Okay, 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. Yeah, but Sam, yeah, so I hope it is not because of what is seen on the screen. On the screen, whether you are 100 or whether you are in GA, right, here the only difference between the two barring Sam's comment on the Ten is screen, but the Ten 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 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 OSs, 10 GIs, and you'll 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'll scroll. Yeah, correct. But the difference between that present, so total we have 100 plus, 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 Sabha's comment that if the compute 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, right? So 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 rows. 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, DB, GI, OS, everything is there. 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 a 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 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, OSNGI 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 rightly can 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 OSNGI 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 the concept, right? That's right there, right? 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. The database failed, right? You can go click on the database, it's retro. 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 the other stack components. It will go complete the GI, it'll complete the OS, then it'll go to the third node, right? It'll 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, you 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 Westford court, that's how it is. In Buffer, I don't know how it is, but I'm assuming, yeah, that's how it is in Buffer also because the database part of it, right? They're 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, the same thing. 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. Is the major mistake because... 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? Because that's where I, off the bat, we thought doing any or rollback for that matter. So remember... We can still do it here. How will you do it? Because they don't have relationship with each other, right? No, no, that's what I'm saying. It's not dependent that way. Let's say there are 10 databases that shows 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, those 10 databases are across two clusters. So just retry cluster one's database and cluster two's database, probably not. Probably not, yeah. Because it

vertical also? But right now, of course, the database is not part of the vertical, right? It's only OS plus GI. Yeah, so see, that's where, right? Because once you dedicate... 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, or whatever it is, they will be allocated 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, the 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? 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? Do you give them the same experience? But in real life, that's how it is. At least 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 resources are just one. 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 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 allocated 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, again, 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? Some security fixes come in, some new image for database. So if 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 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 plus one GI, right? Yeah. Yeah, yeah, yeah. I mean, the cardinality is not in my... 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? They have done all the 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 side or anything, 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... Yeah, this is what will happen. Customers, so today, for example, this part of thing that we worked with before, what happens is they are scheduling a thousand databases for the weekend, okay? Now, in FPP, 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 or whatever it is, right? They do the hundred. Now, wait for 30 minutes or half an hour or 15 minutes and do the other ones. 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 to patch. 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, and that will be based on the database names. You know, the guys who are doing the databases, they don't know, like, which VM cluster, which OS, which GI. They'll 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, this 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 on-prem world, but in cloud, I think the hierarchy may help. Mainly, at least with the ND cases and all, right? They know which DB in which cluster and knowing that... We are trying to bring the on-prem to cloud. We are trying to bring this cloud to cloud world 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 want to say, hey, you know, it's cloudified the cloud. Otherwise, you know, you guys continue to do, you know, your interfaces will change. But they're not going to move people around or, you know, we all do a little. 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 to move those. Right. At that point, you know, they have a... Even if it is a... Even if that, like the regarious 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 struggling with 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 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 we do 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, Sam, you are trying to get to. Okay, that's a fair thing. Yeah, I think it will... Yeah, no, yeah, I think we can accommodate that. But main thing, Samar, 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, Samar, 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. Okay. But