All the Stack Collections

Transcript

All right, 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 2300 messages. Looks like something is going on. I mean, yesterday we had one call with Juan, Sam. I mean, it was more about N and N-1, like supported cloud, we are kind of restricting. Yeah, I mean... 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 databases. 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 are going to deploy, given all this mythos and all that, you can file an SR and you can accept responsibility for the security risk if you want to provision or patch using older N-1 or 2 or 3 or 4, whatever it is. Initially, I think Juan was like, once you sign the waiver, how does it matter? You can go N-10. Then we kind of had a back and forth because already cloud only supports, for stock images, it only supports 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 gets only N through without exception, only N is available, both for VM plus provisioning and guest service patching. Then the medium term, which is right after like four to six weeks out, is N continues to be available without any, you know, issue. N-1 and N-2 for DB and GI will be available through a security risk waiver, but you don't have to file SR, it will be through some cloud API, there will be some cloud attribute which stores your intention, where you'll sign the waiver. to create database from backup, there is a version which we consume when we provision databases. 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 are going to deploy, given all this mythos and all that, you can file an SR and you can accept responsibility for the security risk if you want to provision or patch using older N-1 or 2 or 3 or 4, whatever it is. Initially I think one was like, once you sign the waiver, how does it matter? You can go N-10. Then we kind of had a back and forth because already cloud only supports, for stock images, it only supports 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 gets only N through, without exception, only N is available, both for VM plus provisioning and guest service patching. Then the medium-term, which is right after like four to six weeks out, is N continues to be available without any, you know, issue. N-1 and N-2 for DB and GI will be available through a security risk waiver, but you don't have to file SR, it will be through some cloud API, there will be some cloud attribute which stores your intention, where you'll sign the waiver and that will be the backup. So, that is a two to three weeks proposal. OS, same thing, only N. OS meaning gets only N through. Without exception, only N is available, both for VM plus provisioning and guest service patching. Then the medium-term, which is right after like four to six weeks out, is N continues to be available without any, you know, issue. N-1 and N-2 for DB and GI will be available through a security risk waiver, but you don't have to file SR, it will be through some cloud API, there will be some cloud attribute which stores your intention, where you'll sign the waiver and that will be the backup. So, that is a two to three weeks proposal. OS, same thing, only N. OS meaning gets only N through, without exception, only N is available, both for VM plus provisioning and guest service patching. Then the medium-term, which is right after like four to six weeks out, is N continues to be available without any, you know, issue. N-1 and N-2 for DB and GI will be available through a security risk waiver, but you don't have to file SR, it will be through some cloud API, there will be some cloud attribute which stores your intention, where you'll sign the waiver and that will be the backup. So, that is a two to three weeks proposal. OS, same thing, only N. OS meaning gets only N through, without exception, only N is available, both for VM plus provisioning and guest service patching. Then the medium-term, which is right after like four to six weeks out, is N continues to be available without any, you know, issue. N-1 and N-2 for DB and GI will be available through a security risk waiver, but you don't have to file SR, it will be through some cloud API, there will be some cloud attribute which stores your intention, where you'll sign the waiver and that will be the backup. So, that is a two to three weeks proposal. OS, same thing, only N. OS meaning gets only N through, without exception, only N is available, both for VM plus provisioning and guest service patching. Then the medium-term, which is right after like four to six weeks out, is N continues to be available without any, you know, issue. N-1 and N-2 for DB and GI will be available through a security risk waiver, but you don't have to file SR, it will be through some cloud API, there will be some cloud attribute which stores your intention, where you'll sign the waiver and that will be the backup. So, that is a two to three weeks proposal. OS, same thing, only N. OS meaning gets only N through, without exception, only N is available, both for VM plus provisioning and guest service patching. Then the medium-term, which is right after like four to six weeks out, is N continues to be available without any, you know, issue. N-1 and N-2 for DB and GI will be available through a security risk waiver, but you don't have to file SR, it will be through some cloud API, there will be some cloud attribute which stores your intention, where you'll sign the waiver and that will be the backup. So, that is a two to three weeks proposal. OS, same thing, only N. OS meaning gets only N through, without exception, only N is available, both for VM plus provisioning and guest service patching. Then the medium-term, which is right after like four to six weeks out, is N continues to be available without any, you know, issue. N-1 and N-2 for DB and GI will be available through a security risk waiver, but you don't have to file SR, it will be through some cloud API, there will be some cloud attribute which stores your intention, where you'll sign the waiver and that will be the backup. So, that is a two to three weeks proposal. OS, same thing, only N. OS meaning gets only N through, without exception, only N is available, both for VM plus provisioning and guest service patching. Then the medium-term, which is right after like four to six weeks out, is N continues to be available without any, you know, issue. N-1 and N-2 for DB and GI will be available through a security risk waiver, but you don't have to file SR, it will be through some cloud API, there will be some cloud attribute which stores your intention, where you'll sign the waiver and that will be the backup. So, that is a two to three weeks proposal. OS, same thing, only N. OS meaning gets only N through, without exception, only N is available, both for VM plus provisioning and guest service patching. Then the medium-term, which is right after like four to six weeks out, is N continues to be available without any, you know, issue. N-1 and N-2 for DB and GI will be available through a security risk waiver, but you don't have to file SR, it will be through some cloud API, there will be some cloud attribute which stores your intention, where you'll sign the waiver and that will be the backup. So, that is a two to three weeks proposal. OS, same thing, only N. OS meaning gets only N through, without exception, only N is available, both for VM plus provisioning and guest service patching. Then the medium-term, which is right after like four to six weeks out, is N continues to be available without any, you know, issue. N-1 and N-2 for DB and GI will be available through a security risk waiver, but you don't have to file SR, it will be through some cloud API, there will be some cloud attribute which stores your intention, where you'll sign the waiver and that will be the backup. So, that is a two to three weeks proposal. OS, same thing, only N. OS meaning gets only N through,

Okay, so should we relay 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 hardcore it. And GI and DB, I think today already. 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, single select for OS and GI, multi-select for DB. It shows double though, right? Because for GI, I see 1900 VAI. Yeah, and I can change it, but I just called out for P100. That's what I was thinking, right? Yeah, I mean, I put the note here saying for it's only single select for OS and GI, but I can... And it should be 26 GA, right? No more 2026. Yeah, I mean, there should be only one entry there for P1, for MAP. Yeah. And the other change that is happening here is the... When they click edit search criteria here, the other changes that we... So previously, the major versions were being shown here for the search criteria. So we will... 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 a moving release version and the systems of their release versions for from here. So basically, this will be the simplified search criteria. Hey, this would be permanently for all irrespective of the... For the stack, we are moving. Oh, okay. Let's call it out. I think it's there. Yeah, I think I just mentioned for all the stack collections, we can add an extra... Yeah, yeah. So only for this collection type, we are... This one and the one we already shipped, Salwa. 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 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 in the same format as well. And I think there was a previous conversation that one simplify the whole stack. 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 they run the search and progress, but anything other thing I will mention is that today the search criteria are kind of milderated 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, but then 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 or. So today, like if you go to a DB collection, you don't, you can skip the search criteria altogether and just, just select the major version for DB and click create. So when we empty 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 and still create the collection. So we are just aligning this to that. So that's what we are saying is that your targets are not required, right? So we don't need to show that table. You can go to edit search criteria, then fill in, then they select targets, we can show the table and just looking at current implementation. So current 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 you get 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 as you enter the search criteria and hit search, then yeah, then once the discovery is done, this table will be populated and the post for the new stack type, the proposal is the table will become like a tree table to show like a hierarchy of the trusters and associated databases like China resources, basically. And we can discuss this and presentation if we can simplify it further. But for now, I think we will have these filters to begin with. And of course, the compartmental filters can be multi-select because the targets can span across compartments. I think we can try to see if we can simplify any of these other columns. But for now, the idea is that it will be like a tree table with these three columns for showing the individual component versions, the current versions. This thing came from UX designer or you guys made it? I am not sure whether we have a tree 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 tree table. It's a one row expansion. Yeah, that is there. I am referring to this pattern. If you go to the... 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 tree table. So we just have one row expansion. Yeah, that also will make use of it. My understanding is based on the main toolkit that from OCI. So they offer the tree table special expanded for the hierarchy. And they can actually take a look to see whether we support that in current framework. So it will have each, the VM cluster may have many databases, right? Expanded rows or only one. It should be more. It can be some. So if we don't support tree table like this, we may have to revisit. The selection could be in your side panel for each row. But then how will we do that Subodh? So for example, let's say first cluster has five databases, second cluster has... So are you saying that it will be a two-step interaction? Yeah, if you go back to the screen that you are showing. Yeah, this one I will get back like whether we do support in our current framework that we are using. It is there in the framework. I don't know whether Jet supports or not. So you have to find out. We have not implemented any tree table. We have just have the one expanded row. So what I'm saying is like if we don't have that support, we will have your three dots in the first row VM cluster. When you click on it to view or select databases, then the side panel will come. There you will see the list of databases for that VM cluster. But Subodh, this whole thing was populated as part of the search criteria results. Remember, like if you go back, right? But we can filter on the client side if all the results are in one API response. Right. So if I am not able to achieve this, right, the alternative pattern is have your three dots on the first row VM cluster, then select databases would be one of the row action that will show the panel. The panel would list the databases. From there, user can choose the databases. When they close the panel, we will show the expanded row with what are all the databases have been selected. Do you see what I'm saying? Expanded row, but as like you mean like a summary, like an expanded row. Yeah, summary kind of thing, like a database display name comma separated. This is the list. Something like this. Yeah. But in the version, we'll have to do some kind of like because they will all have different versions. If you want to see. They want to see, they have to again open the panel. If you want, we can get this. Like I don't know how many databases each row would have. Right. Yeah, I mean, it could be N databases. So, so. But this whole DBGI, this whole, in general, I mean, so this whole is a tree, right? So is that how all tree, like anything which is parent-child, if you order to display it, how are we doing it? Are we doing it through this side panel? Yes, yes. I will double check on the tree table. If the tree table is not supported in the current library and the framework that we are using, we have to have alternate path. Alternate path is like have your three dots on the row. It will have your select databases and you will have your table with the multi-select. So when they choose and they come back, you will see the expanded row with the databases comma separated. And if you want to see the version, we can show the metadata, but if you are seeing N, number of databases, then this page would be really crowded. Yeah, but Sabha, this pattern is not just this. Later on, on each of these databases, we are offering rollback, retry, those kinds of operations. This structure, right, is not just during create. This is how the jobs will be. This is how, I mean

Correct, correct. So then that's what I'm saying. Correct. So then how will they It goes to the GA screen, that's for GA, he will say something is failing or whatever it is, right? No, but this hundred databases, let's see the association is on the hierarchy from the Correct, so then how will they go to the If you go to the GA screen, that screen for GA, he will say something is failing or whatever it is, right? No, but this hundred databases MCV, the association is on the hierarchy from the Correct, so then how will they go to the If you go to the GA screen, that's for GA, he will say something is failing or whatever it is, right? Correct, so then how will they go to the If you go to the GA screen, that's for GA, he will say something is failing or whatever it is, right? Correct, so then how will they If you go to the GA screen, that's for GA, he will say something is failing or whatever it is, right? Correct, so then how will they go to the GA screen and that's what we are trying to get to, right, Sam, that to do troubleshooting, it is not that all hundred databases are, so even whether you put it on three tabs or on a single tab with parent-child relationship, the way to troubleshoot will be, in this case, let's say VM cluster 1, I mean VM cluster 8, OS has failed on the first VM, VM cluster 2, GI has failed on the second VM, and let's say all the other 8 are progressing as expected, right? So when you see failure, you will see jobs today, what Vikas is presenting is, you will see 10 vertical jobs, just 10. I'll give you another example, let's say OS and GI fails, a hundred databases, say 11 databases failed on different clusters. Sure, so that also we will take, but let me just finish this one. But see, actually, that's a beautiful example because both your example and this example have the same number of clicks to troubleshoot is what I was saying. First, let's just finish this one, right? One OS has failed, one GI has failed, and then let's take actually all three in one shot. And in another example, because only these two, the other 8 were progressing, and let's say imagine that, you know, on VM cluster, another single VM cluster, 8 of them have failed. So basically, 7 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 will have 10 jobs. I'm just trying to play out what Vikas is saying in other troubleshooting modes, right? So if you just have a nested list, you will have 10 jobs, of which 7 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 failures. Let's say 11 databases have failed. So wherever you have failure in your stack amongst the three components, it gets updated and shown on the job, which is a composite of all the components which needs to be updated, right? But you will have 10 jobs and you know 7 you don't have to interact with. 3 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 component. Yeah, that's correct. Yeah, that's correct. And that's what we are trying to get to, Sam. That to do troubleshooting, it is not that all 100 databases are, you, you, you, so even whether you put it on three tabs or on a single tab with parent-child relationship, the way to troubleshoot will be in this case, let's say VM cluster 1, I mean VM cluster 8, OS has failed on the first VM. VM cluster 2, GI has failed on the second VM. And let's say all the other 8 are progressing as expected, right? So when you see failure, you will see jobs. Today, what Vikash is presenting is, you will see 10 vertical jobs, just 10. I'll give you another example, Vikash. Let's say OS and GI success, a hundred databases, say 11 databases failed on different clusters. Sure, so that also we will take, but let me just finish this one. The same, actually, that's a beautiful example because both your example and this example have the same number of clicks to troubleshoot is what I was saying. First, let's just finish this one, right? One VM, OS has failed, one GI has failed. And then let's take actually all three in one shot. And in another example, because only these two, the other 8 were progressing. And let's say, imagine that, you know, on VM cluster, another single VM cluster, 8 of them have failed. So basically, 7 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 will have 10 jobs. I'm just trying to play out what Vikash is saying in other troubleshooting modes, right? So if you just have a nested list, you will have 10 jobs, of which 7 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 failures. Let's say 11 databases have failed. So wherever you have failure in your stack amongst the three components, it gets updated and shown on the job, which is a composite of all the components which needs to be updated, right? But you will have 10 jobs, and you know 7 you don't have to interact with. 3 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 component. Yeah, that's correct. Yeah, because it's just the way we have ingested the payload is how we are troubleshooting our experience of 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 database, you will see, oh, there was, you know. When you open, see, the sort of a screen, they just have to visualize what is the customer looking at. Yeah, I think this one we can show, right? I mean, maybe, because we said it will be flat, we did not get to that presentation now. 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 know, your example here, right? It says there is only one database. Imagine there are 10 databases. How will the screen look? It will show only one VM cluster. It won't show the remaining. It won't show the database lines. That's a misunderstanding of the UI pattern, which does not make us. If we don't, yeah, I can quickly draw 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 an option where you can page it. There is a progressive loading. Yeah, so this one I need to check it out. Like framework, we don't have a retry. Tell me if there are 10, go back to your other screen. Okay. Where you have the PM process in TV 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. You have a VM cluster has 10 databases. You will have 11 rows. So that screen is already used up mostly. But the other things will be collapsed because first of all, the first VM cluster. I know, but they'll go off the screen. Correct. So these exactly. Yeah, but what I'm saying is just the beginning, right? When OS is the component which is being patched at that time, GI and OS, they will be showing some kind of state like in progress, correct? Because they have not started, right? I mean, they just started and it will get started. But in this case, if it's a 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

It's a collection, the presentation is the same, no matter whether you are doing vertical. That I completely, that is something worth exploring. But if you'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, 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 or revert or continue retry for combined OS and GI. We don't have it individually. If you can do it individually, I would put them in separate screens. Correct. Okay, so if they were like, 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 database. Okay, but Sam, yeah, so I hope it is not because of what is seen on the screen. What's seen on the screen is 10, whether you are 100 or whether you're in GA, right? Here, the only difference between the two barring Saba's comment. The 10 is screened, but the 100 is not screened, right? No, no, no. Sam, 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're 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 will still have to scroll even for that 10. So you'll 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'll scroll. Second page also, you'll scroll. Third page also, you'll 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 Saba's comment that if the compart 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 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. No, 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 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, like, 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... Okay. Here I'm some 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, 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. What's seen on the screen is 10, whether you're 100 or whether you're in GA, right? Here, the only difference between the two barring, Sam's comment. The 10 is screen, 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're 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? The image still have to scroll, even for that 10. So, you'll 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'll scroll. Third page also, you'll scroll. Yeah, 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 Saba's comment that if the compart 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? You 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 done. Utilization of the summaries. Yeah, you will get a, yeah. So, now that's a different, now I'm seeing what's the 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 the 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 3 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 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, it seems this is a little bit more tedious. Right? You need to go and then un-collapse 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 constant. Right? It's right there. Right? 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. Right? You can go click on the database, see 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, 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, and it goes through, it will go through the other stack components. It will go complete the GI, it will

vertical also. But right now, of course, database is not part of vertical, right? It's only OS plus GI. Yeah, so see, that's where, right? Because once you dedicate... But 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 physically dedicated to them. They will still submit their jobs, right? Right. But it will get executed as part of a vertical, and they will be informed, hey, you know, we are doing the vertical this weekend, so you guys monitor your database jobs. You guys have submitted it, and they have submitted, it will go into a queue, and then it will get executed as part of vertical. But they will be asked to monitor their jobs, their database jobs. And at that point, you know, their experience should be pretty much the same as what they have seen earlier. They will be with a single target, because sometimes they may have a round of patching where there is only database, right? Some security fixes come in, some new image for database, so they can't say, hey, this is vertical, I'm seeing, I've got to go through this, this is not vertical, I've got to go through this, right? You give them the same experience. But in real life, that's how it is. Yeah. 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. I mean, the cardinality is not... 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, it 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... 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 sidebar panel, they can also be kind of reference resources. It doesn't mean it is a sidebar. So parent-child relationship, do we need that tree to show that? Or can we just get away with... Because then you can also argue technically that at the time of creation, the screen... Yeah, this is what will happen. Customers, so today, for example, this is part of the thing that we worked with before. What happens is they are scheduling a thousand databases for the weekend, okay? Now, in FTP, 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... That is the... 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 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 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 databases, they don't know, like, which VM cluster, 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 on-prem world, but in cloud, I think the hierarchy may help. Mainly, at least with the ADAD cases and all, right? They know which DB in which cluster. And knowing that... We are trying to bring buffer to cloud. They're trying to bring the cloud to cloud. If you are expecting that they will change their organization 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... You know, your interfaces will change. But they're not going to move people around, you know, we all do a reason. 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? So that point, you know, they have... They have a foot of those because 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 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. 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 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're trying to get to. Yeah. Yeah. Okay. That's a fair thing. Yeah, I think I will... Yeah, no, yeah, I think, I think we can accommodate that, but main thing, so 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, 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... Yeah, I, I'll get back on that. I, 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 I, other proposal I'm working on is single select. So tree expansion with, I mean, here he's not showing it, but the one which he was showing, right, the pattern, tree 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 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, then we have to come up with alternatives for it. But the staging, right, if we decide how we're able to ask for images based on version for the database. Yes, yes, everything, the first screen, right? I kind of forget, I forgot now. Where do we, 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 some 26 databases, right? Both need to be patched. We need to ask for the image for 19 image for 26. You're talking about the target or goal? Yeah, the target, target. Yeah, this is the presentation, Sam. Yeah, so this is doing, that's doing create maintenance cycle. Right, create maintenance cycle here, right? Yeah, absolutely. So basically at that time, whatever, like ignore the 2, 4G, just assume there's one OS, one GI major version and then... I don't see a dropdown. This is the default tool. We will automatically populate the table. This is an internal API. That's what we will implement to show the default or the latest