Database Version Management and UX Considerations

Transcript

Vertical also? Yeah, 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 delegated to them. They will still submit their jobs, okay, right? But it will get executed as part of a vertical, and they'll be informed, hey, you know, we are doing the vertical this weekend, so you guys monitor your database jobs. You guys have submitted it. When 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 are in a single target. Because sometimes they may have a round of patching where there is only database, right? Some security fixes come in, some new image for database, so they can't say, hey, this is vertical, I'm seeing I've got to go through this, this is not vertical, I've got to go through this, right? You give them the same experience. But in real life, that's how it is, at least on the ones that we know. Once we do the splitting, right, I think that keeping OS and GI in one payload also is kind of a little more confusing. We may have to... It's like one-to-one is to one, right? It's not too bad. You mean resource to the number of resources are just one. One OS plus one GI, right? Yeah. Yeah, yeah. I mean, the cardinality is not in that. Exactly, yeah. So that's not too bad. Yeah. Yeah, it's more 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, it will not change. But I do think that at the time of creation, if you don't have this parent-child relationship, then how is the vertical aspect kind of driven? Like the mental model that this is vertical, how does customer know that this database is related to this VM cluster, right? That part is not yet... On the job part of it, not on the creation part. The job part of it, nothing changes, right? They have done the... 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 it? Because then you can also argue technically that at the time of creation... 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 that they are scheduling a thousand databases for the weekend, okay? Now, in FIP, 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, They'll do that, right? Okay, now wait for 30 minutes or half an hour or 15 minutes, and do the other one. Keep doing that till all thousand are running, something like that, right? Now, what happens is that on Friday evening, there are certain internal customers come back and say, Hey, this database, I don't want, you know, there's some urgency is going on. I don't want this database you 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 though is 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 needs. You know, the guys who are doing the database, 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 silica really doesn't help them. The flat thing helps. They can quickly go to the database and uncheck or check or whatever it is. Don't do check or whatever, right? And then it's off the table for that round. Some maybe that may be true in on-prem world, but in cloud, I think the hierarchy may help, mainly at least with the daily cases and all, right? They know which DB in which cluster and knowing that. We are trying to bring Bofar to cloud. We're trying to bring this power from powered 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 itself. Otherwise, you know, you guys continue to, you know, your interfaces will change, but they won't. They're not going to move people around or, you know, we all do a reload. 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, they have a food box for you. 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. Yeah, I'm just, I'm just saying that, I'm just translating 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 that 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 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 hosts 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. Yeah. Okay. That's a fair thing. Yeah, I think that will. Yeah, I think, I think we can accommodate that. But main thing, Sabah, 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 what is the situation on tree because that tree thing I'm using in all other present proposals also. So it's a very important. Yeah, I, I'll get back on that. We haven't implemented it yet, but we do have one row expansion, but multiple child resources we don't have yet. And also the ability to check, this is multi-select, the one which, the other proposal I'm working on is single select. So three expansion with, I mean, here he's not showing it, but the one which he was showing, right, the pattern, three expansion multi-row with multi or single select. That is the pattern eventually we want. I mean, not in this project, but that is the, I'm talking about a different project when I'm using that. So if multi-row is not there or multi-select is not there or single select is not there, then you have to come up with alternatives for it. Okay, Vikas, now come on, about the staging, right? Did we decide how we are going to ask for the images based on version for the database? Yeah, that's the first screen, right? I think. I had a problem here. Where do we, where do we ask for this? Image selection based on the version. Image selection based on the... Yeah, let's say a cluster has some 198 databases and 126 databases, right? Both need to be patched. We need to ask for the image for 19 image for 26. You say you don't want to target or goal. Yeah, the target. Yeah, this is the presentation, Sam. Yeah, so this is doing less during create, maintain, cycle. Yeah, create, maintain cycle, you're right. So basically, at that time, whatever, like ignore the F2G, just assume there is one OS, one GI image version, and then... And even in Oracle stock, I think there will be a few more properties, I think, the release month. And then we will, maybe depending on how the MRP implementation goes, maybe it will be a normal image or it will be a normal image underscore MRP1, MRP2. And then the key part then will become, when was it released, the month, date, and whether it has a security, yes, no, whatever. So there will be more metadata even on the stock image other than the version. So a simple dropdown may not cut it. At least customer it will not. Maybe it will work for stock image, simple dropdown now, but that simple dropdown will also have more identifier properties in the future. So we can, that UX is not a problem, but can you go back to your UX which you were presenting to Sam, like the one in the back. So Sam, the idea is that whether your target version is, actually this UX also will improve, right? Because target version, yeah, I mean target version is derived from the stock image or custom image. And if you're doing a custom image, you will have some more attributes to show that, you know. Okay. Yeah. But yeah, I think So I think I was thinking, hey, Sam, I think tomorrow somebody will be there, right, Sam, from your end. Yeah, Bluefin will be there. Okay. So anyway, we will go with this. See, all these things, anyway, friends, I think this has to go more rounds with a little more broader audience. And probably I don't know if you're having plans to review with the one and others also, right friends, at some point. Yeah, so we'll have to, yeah, so we'll have to come up with that story of the review. But what I was hoping is that, yeah, the we'll do a full, yeah, we'll craft that. Yes, we will do that. We'll craft it, but I think the idea is the API should not kind of have much impact. Like even what Sam's comment, how we can achieve it with the existing ones, right? Correct. Then I think we have a story. Correct. Okay. API is fine. I mean, it's just data, right? Correct, correct. I think that's the part. So yeah, we'll go with that tomorrow and then we will kind of rehash these things as we move up with the user experience. Yes, please also have a look at your inputs. Because the one thing, Sabah, I think all these things are ideally it would have been better with the UX designer and things, but I think we kind of focused on that, Prince, because they had these things, right? But I want your inputs also, Sabah. Okay. Being more of the kickoff con. Yeah. After the kickoff. I think that we can have some finer discussions out later. I'm saying like, can we move the kickoff itself so that I can have the concrete answer for this? No, I think let's do this because this kickoff has been... So this is the engineering kickoff. This is not the project kickoff. So we still have time. By the time project kickoff, we will close out all these things. So because that way, main is see, Vikas needs that EPS and hope. One more question Vikas, that jobs is flattened. So in the example, it will be 120 job IDs. Of it's 100, we'll have a related job ID posted, correct? Yeah. But in the initial creation, when you have the parent-child, what Sabha is saying, is it a flat list of, is it 120 targets or is it 10 targets with children targets? Okay, then we have got API is good. You are, okay, API is good. So the main work is there, right? Because that... So you and me will discuss. Okay, good. So that means we are not changing much in the... And nothing of what last Sam said about custom image, drop down, none of that impacted the number of gold version and the representation also. Right, I understood the custom image. Yeah, but that did not impact your Vikas any, nothing... Doesn't impact you, right? Because the gold version presentation, multiple gold versions, having the gold version and the version is derived from custom image. None of those things are impacted. Yeah, so basically, we are mapping into the number of major versions in the collection. And even if you have additional metadata, you only care about the version, but all of that is just for the customer to make a choice, right? If you're coming from API, you're just plugging the gold version. The one I'm trying to say is that, so all nine can see databases with no discussion, all 26 systems, but whatever database is with no discussion. We are not going to have subsequent, they can say, oh, more 19.x to 19.y and more 19.8 to 19.p. We are not having that kind of discussion. No, no, what I'm saying is that for the API user, and when I'm doing this target version setting in the cycle, if I say 19.31, the only thing you care about from the custom image is the final OS, right? You just have to go in the OS. You have no other metadata, right? All the things we're talking about, target versions, stock image, we'll have extra date, all of that. That is all coming from some other thing, right? Either the repo update ID or the... Okay, update ID or other. So basically, none of those things change your current. So it looks like API things have not been changed. So Sabha, your point, I think you should ask the engineering kickoff. Right, Sabha will have this and then we'll kind of pursue it like, like Pranav said, the UX may have some transformation, right Sabha, that we can have discussions. Sure. Okay. Okay. Okay, then I've got to jump to another call also. Okay. Thanks. Thanks, Sabha. Thank you, Sam. Yeah. Bye.