Implementation of Vertical Model for Database Jobs

Transcript

Speaker 1: Vertical also? And even vertical. But right now, of course, the database is not part of the vertical, right? It's only OS plus GI.

Speaker 2: Yeah, so see, that's right, because once you dedicate...

Speaker 1: 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?

Speaker 2: 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've seen earlier. They will be the single target. Because sometimes they may have a round of patching where there's 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'll give them the same experience.

Speaker 1: But in real life, that's how it is, at least the ones that we know. But 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.

Speaker 2: But you mean resource to number of, I mean, the number of resources are just...

Speaker 1: One OS, one GI, right?

Speaker 2: Yeah. Yeah, yeah. I mean, the cardinality is not in...

Speaker 1: Exactly, yeah. So that's not too bad.

Speaker 2: Yeah.

Speaker 1: Yeah, it's more of complete. So, okay, we'll, 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...

Speaker 2: From the job part of it, not from the creation part. The job part of it, nothing changes, right? We have done that.

Speaker 1: 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. So parent-child relationships, 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... I'll tell you what will happen. Customers, say 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 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'll keep run those thousand commands in lots, right? You may say, let's do the hundred in batches, whatever it is, right? They do the hundred. Now wait for 30 minutes or half an hour or 15 minutes and do the other, but keep doing that till all thousand are running, something like that, right?

Speaker 2: 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 urgencies going on. I don't want this database to patch. Take it out. And they get about 50 databases. That's what they say. They get about 40 to 50 databases which are supposed to be removed, okay? Now, here for us, 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 name. 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.

Speaker 1: Some maybe that may be true in on-prem world, but in cloud, I think the hierarchy may help. Mainly at least with the cases and all, right? They know which DB in which cluster and knowing that...

Speaker 2: We are trying to bring Bopha to cloud. We are trying to bring resolve from on-prem to cloud, right? If you are expecting that they will change their organization structure to accommodate cloud, I doubt it. The department guys, you know, they will say, Hey, you know, it's cloudified itself. Otherwise, you know, you guys continue to, you know, your interfaces will change, but they want, they don't want to move people around. 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.

Speaker 1: Right. At that point, you know, they have...

Speaker 2: Yeah, I think that's a fair thing.

Speaker 1: Yeah, I think I think we can accommodate that. But main thing, Subha, 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?

Speaker 3: So let us know, Subha, what is the situation on tree, because that tree thing I'm using in all other proposals also. So it's a very important...

Speaker 4: Yeah, 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 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 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.

Speaker 3: Yeah, because the staging, right, we decide how we are going to ask for the images based on version for the database. 

Speaker 4: Yeah, that's everything that first screen, right? I think I'll have to forget, where do we ask for this image selection based on the version?

Speaker 3: 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.

Speaker 4: You say you want the target or goal version?

Speaker 3: Yeah, this is the presentation, Sam.

Speaker 4: Yeah, so this is during the create maintenance cycle and actions having access to the image model. The idea is that during stage, we will use the FSU actions, resource consultant to access the image in the stage again. So that's the thing that customer will be responsible to set up. 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 and 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. Like at least custom 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.

Speaker 2: 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 tomorrow somebody will be there, right, from your end to pick up, right? Look front will be there.

Speaker 1: Look front will be there.

Speaker 2: Okay. So anyway, we will go with this. See all these things, anyway, friends, I think this has to go more rounds with broader, 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.

Speaker 1: Yeah. So yeah, we'll have to, yeah, so we'll have to come up with that story of a review. But what I was hoping is that, yeah, we'll do a full, yeah, we'll craft that.

Speaker 2: Yes, we will do that. But I think the idea is the API should not kind of have much impact. Like even what Sam's coming, how we can achieve it with the existing ones, right?

Speaker 1: Correct.

Speaker 2: Then I think we have a story.

Speaker 1: Correct.

Speaker 2: Okay. API is fine. I mean, it's just data, right?

Speaker 1: Correct.

Speaker 2: Correct. I think that's a part. So we'll go with that tomorrow and then we will kind of rehash these things as we move up with the user experience. Yes, Samaya, please also have and then your inputs, because the one thing 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 at Prince because they had these things, right? But I want your inputs also, Samaya.

Speaker 3: Okay. The kickoff call. Yeah. After the kickoff I think that we can have some finer discussions over here.

Speaker 1: So I'm saying that can we move the kickoff itself so that I can have the concrete answer for this?

Speaker 3: 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 hopefully...

Speaker 1: One more question Vikas, that jobs is flattened, so in the example, it will be 120 job IDs of which 100 will have related job ID posted, correct?

Speaker 2: Yeah.

Speaker 1: 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?

Speaker 2: The same.

Speaker 1: Okay, then we have got API is good. So the main work is there, right, because that... So you and me will discuss.

Speaker 2: Okay, good. So that means we're not changing much in the...

Speaker 1: And nothing of what's last Sam said about custom image, it dropped down. None of that impacted the number of gold version and the representation also, right?

Speaker 2: I understood the custom image.

Speaker 1: Yeah, but that did not impact your Vikas any, nothing...

Speaker 2: 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.

Speaker 1: Yeah, I mean, I think that... So basically, we are mapping it to the number of major versions in the collection. And if you, 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 one. The one I'm trying to say is that, so all nine can see databases with no discussion, all 26 systems, whatever database is with no discussion. We are not having subsequent. They can say, oh, more 19.x to 19.y and more 19.8 to 19.p. We are not having that type of discussion.

Speaker 2: 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 on the OSID. You have no other metadata, right? All the things we're talking about, target versions, talk image, we'll have extra date, all of that. That is all coming from some other thing, right? You don't need those.

Speaker 1: Okay, 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. Because Sabha will have this and then we will kind of pursue it. Like Prince said, the UX may have some transformation, right, Sabha, that we can have discussions.

Speaker 2: Sure. Okay?

Speaker 1: Okay, okay, then I'm going to jump to another call also.

Speaker 2: Okay, thanks.

Speaker 3: Thank you, Sabha.

Speaker 1: Thank you, Sabha.

Speaker 2: Yeah.