Database Versioning and Execution Model

Transcript

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 will... What the difference will be from their... from their perspective is, so the same guys who are doing database today, the departments, right? The finance or whatever, whatever it is, they will be... If it's been delegated to them, they will still submit their jobs. Okay, right? But it will get executed as part of a vertical and they will be informed, hey, you know, we are doing the vertical this weekend, so you guys monitor your database jobs. You guys have submitted it. When they have submitted, it will go into a queue and then it will get executed as part of vertical. But they will be... 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 give 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 it can't say, hey, this is vertical. I'm seeing I've got to go through this. This is not vertical. I've got to go through this, right? You give them the same experience. But in real life, that's how it is. At least on the ones that we know. But if 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 end-to-end. Exactly, yeah. So that's not too bad. Yeah. Yeah, it's more of complete. So, okay, we'll... I don't think because it will not, like all the other decisions we made, even if it's split, will not change. But I do think that at the time of creation, if you don't have this parent-child relationship, 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. On the job part of it, nothing changes, right? We've done the same things. Yeah, so the creation part of it, also somebody 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. That doesn't mean it is a child or anything, right? So parent-child relationship, do we need that leaf to show that? Or can we just get away with... Because then you can also argue technically that at the time of creation, this screen, yeah, this is... I'll tell you what will happen. Customers, like today, for example, this is the part of the thing that we worked with before. What happens is they are scheduling a thousand databases for the weekend, okay? Now, in FBP, 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 keep run those thousand commands in lots, right? They will say, let's do that in batches or whatever it is, right? They do that. Now, wait for 30 minutes or half an hour or 10 minutes and do the other one. Keep doing that till all thousand are running, something like that, right? Now, what happens is that the, you know, 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 needs. You know, the guys who are doing the database, they don't know, like, which VM cluster or which OS, which GI. They have the database name and they're all unique anyway. They have the database name and say, I got to go, you know, disable, you know, this database from getting patched because, you know, something important is running. So at that point again, you know, 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. Some, maybe that may be true in on-prem world, but in cloud, I think the hierarchy may help. I mean, at least with the Indian cases and all, right, they know which DB in which cluster. And knowing that... We are trying to bring BFA to cloud. We are trying to bring this power to cloud, right? If you are expecting that they will change their organizational structure to accommodate cloud, I doubt it. The department guys, you know, they're going to say, hey, you know, it's cloudified the cloud. Otherwise, you know, you guys continue to, you know, your interfaces will change. But they aren't going to move people around or, you know, we all do a... 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, there is no... Even if it is like the vigorous 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 people flat or not? I think all of this is coming down to flatten out the namespace. It is much more modular and extensible and aligns with the operator model. Forget the data model. Data model is only for us to execute. The operator's model is database is different, clusters are different, and host is different. And that is continuing to... should be the jobs model, execution model, reporting model is what I think, Sam, you're trying to get to. Yeah. Yeah. Okay. That's a fair thing. Yeah, I think I will... Yeah, I think we can accommodate that. But main thing, let's 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, Sarabh, what is the situation on tree? Because that tree thing I'm using in all other proposals also. So it's a very important... I'll get back on that. 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 I, the proposal I'm working on is single select. So three expansion with, I mean, here he's not showing it, but the one which he was showing, right, the pattern, the 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 that I'm using that. So if multi-row is not there or multi-select is not there or single-select is not there, then we have to come up with alternatives for it. Okay, so Vikas, now kind of about the staging, right? Let me decide how we are going to ask for the images based on version for the database. Yeah, let's have a thing, the first screen, right? I think. I kind of forget, where do we ask for this? Image selection based on the version. Image selection based on the... Let's say a cluster has some 19 databases and 26 databases, right? Both need to be patched. We need to ask for the image for 19 image for 26. You say you want the target or... Yeah, this is the presentation, Sam. Yeah, this is doing, that's doing create maintenance cycle. Right, create maintenance cycle, you're like... Yeah, so basically, at that time, whatever, like, ignore the 2 for GMR, just assume there is one OS, one GI image version, and then... There is a selection, I don't see a drop-down. Is the... This is the default tool. You will automatically populate the table, and this is an internal API for that tool to implement, to show the default or the latest gold version. Well, the target version, will it show a drop-down? Yeah, if you click on this, drop-down dot to open the drawer, and that side panel will allow, will show them the whole view. All the other options. Yes, why can't there be a drop-down on the database software? Because there are two types, right? If you do a drop-down, you also have customer images, right? So, based on that drop-down dot, will allow you, that will have a split between whether you want to use Oracle stock or whether you want to use your custom. If you see Oracle stock, we give you the four versions which we support. By the way, those all things will change because we only allow the latest. And if you do custom... No, no, no, the default will be the latest, that's fine, but I still, you know, we should have a drop-down, right? Why do we need to go to the dot dot dot? Because you can also choose from custom images. The drop-down you are asking for is... I don't know, custom image already because the customer would have created. Correct, so that choice between whether you want to... No, no, that can be a drop-down on the customer image column, right? But then it is either or, right? So, that presentation of whether you want to go A or B. That's why I thought there will be one drop-down. Yeah, this is our... The current idea is a simplified version of this. When they click the dot dot dot, it will show the drawer, and then, I mean, ignore the split, but just for each major version, they will show the drawer and then they will have this combo where they can select either Oracle supplied values or if they click on this, then they will see the other option of like the customer image. We don't even need this pop-up, right? No, but because the customer images are coming from a different compartment, different region, multi-region, that's a very interesting selection, right? So, the custom images today, you can create in one region and then you can use it in some other region. Yeah, no, but if in the pop-up screen, if it's going to show those images, we can even also show them in the drop-down. No, but drop-down, Sam, is like a... Can you blow this up? So, the properties of a custom image are which compartment, which region, what is your display name, what is your version, when was it created. That is how another it is available or it is expired. These many properties are how you fully identify a custom image. So, in a drop-down, when you click here, so that is like... And also, even in the Oracle stock, today we only show four versions. So, can you go back to the other one where the Oracle stock is displayed? One of the thing which is key is, right now it's showing this is not enough. We will say, what is the version, when was the release month, that is a key attribute now because, and then if it is an MRP, hopefully the MRP will... They have to create one per compartment. They don't have to create one per compartment. If you have access to the compartment, you can keep it in root and you can keep it in some region where everybody is pointing to that. But you need to know the location and find it and you have to have access to it, get called privileges to it. Yeah, it's more about this FSU cycle and actions having access to the image model. The idea is that during stage, we will use the FSU actions, resource console to access the image in stage again. So that's the customer will be responsible to send it. 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 drop down may not cut it. At least customer it will not. Maybe it will work for stock image, simple drop down now, but that simple drop down 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. Yeah. But yeah, I think. So I think what I'm thinking, hey, Sam, I think tomorrow somebody will be there, right? Sam, from your end to pick up, right? Look, one will be there. Look one 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 little more broader audience. And probably I don't know if you are 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 review. But what I was hoping is that, yeah, there will do a full. Yeah, we'll craft that. Yes, we will do that. But I think the idea is the API should not kind of have much impact. Like, you know what Sam's coming. How we can achieve it with the existing ones, right? Correct. I think we have a story. Correct. Okay. API is fine. I mean, it's just data, right? Correct. Correct. I think that's a part. So we will go with that tomorrow and then we will kind of rehash these things as we move on with the user experience. Yes, please also have your inputs. Because the one thing, Sam, I think is all these things are ideally, it would have been better with the UX designer and things, but I think we kind of focused on the app. Because they had these things, right? But I want your inputs also, Sam. Okay. Yeah. Yeah. Yeah. Thank you. I think that we can have some finer discussions around that. 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 kickoff has been... So Sabha, this is the engineering kickoff. It's 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, I mean, see, Vikas need that EPS. And one more question, Vikas, that jobs is flattened. So in the example, it will be 120 job IDs. Of its 100 will have related job IDs posted, correct? Yeah. But in the initial creation, when you have the parent-child work, 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. UI, okay, API is good. So the main work is there, right? So UI we will discuss. Okay, good. So that means we are not changing much in the, and nothing of what's last, Sam said about custom image, not dropped down. None of that impacted the number of gold version and the representation also. 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. 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. So all 19th databases have moved to discussion, all the 26 systems. Whatever database is a moved to discussion. We will not run subsequent. We can say, oh, move 19.x to 19.y and move 19.8 to 19.p. We are not having that kind of discussion. No, no, what I'm saying is that for an 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 and post it. You have no other metadata, right? All the things we're talking about, target versions, stock image, we will have extra date, all of that. That is all coming from some other thing, right? You will have the data ID order. 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? Right, because Sabha will have this and then we will kind of pursue our, like, like Prince said, the UX may have some transformation, right? Sabha, that we can have discussions. Sure. OK. OK, OK, then I'm going to jump to another call also. OK. Thanks. Thank you. Thank you so much.