ActonOS
Dashboard
Manualprocessed

Database and Vertical Integration Strategy

Streamlining Operations with Vertical Execution

Original calendar title: Discussion Summary and Follow-ups

May 22, 2026, 12:00 PM

ActonOS summary

Database and Vertical Integration Strategy

Date: May 22, 2026

Attendees: Not stated

The meeting focused on optimizing database operations through vertical execution, addressing parent-child relationships in databases, and the transition of systems to the cloud. Discussions included the practicalities of maintaining existing namespace models and using tree structures in UI API design.

1. Vertical Execution

  • Performing job executions in a unified manner as part of a predefined vertical workflow.

2. Feasibility Testing for Tree Structures

  • Examine tree structure feasibility for managing resources in new cloud-based systems.

Action Items and Follow-ups

1 tracked
  • In progress

    • Feasibility Testing For Tree Structures: Relevant Stakeholders will Examine tree structure feasibility for managing resources in new cloud-based systems.

      Next step: Follow up with Relevant Stakeholders if there is no update in 2 days.

Follow-up Points

Nothing flagged.

Additional Notes

  • Consider feedback loops for continuous improvement during the transition phase.

Decisions

Nothing flagged.

Open questions

Nothing flagged.

Risks

Nothing flagged.

Commitments

1 found

Feasibility Testing for Tree Structures

mediumopen

Examine tree structure feasibility for managing resources in new cloud-based systems.

Relevant Stakeholders

No deadline

Transcript

Vertical also. But right now, of course, so see, 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, whatever it is, they will be physically dedicated 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 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 might 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 in 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... If it's like one-to-one, it's not too bad. But you mean resource to number of, I mean, the number of resources are just... One OS, one GI, right? Yeah. Yeah, yeah. I mean, the cardinality is not an entire. 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, nothing changes, right? They 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 side panel, they can also be kind of reference resources. It doesn't mean it is a child or anything, right? So, parent-child relationship, do we need that field 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... I tell you what will happen. Customers say today, for example, this is the part of thing that we worked with before. What happens is they are scheduling a thousand databases for the weekend, okay? Now, in FEP, 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 run those thousand commands in lots, right? They will say, okay, do that in batches or whatever it is, right? They do that hundred. Now, wait for 30 minutes or half an hour or 15 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 you 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, 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, 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 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, 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. Some maybe that may be true in on-prem world, but in cloud, I think the hierarchy may help. Mainly, at least with the Indian cases and all, right, they know which DB in which cluster. And knowing that... We are trying to bring Bofar to cloud. We are trying to bring result from Bofar 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 want to say, hey, you know, it's cloudified, that's all. Otherwise, you know, you guys continue to do, you know, your interfaces will change. But they won't, they are not going to move people around, you know, rework, do a rework. 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, you know, there's no... We have a foot in both. Even if it is a, even if that, like the vicious 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, I'm just thinking, yeah, 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. 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 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 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. Okay, that's a fair thing. Yeah, I think I will... Yeah, 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 mix, right? So let us know, Sabah, 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'll get back on that. I 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 tree expansion with, I mean, here he's not showing it, but the one which he was showing, right, the pattern, the 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 you have to come up with alternatives for... Okay, so I think, I think that's a fair thing. Yeah, 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 mix, right? So let us know, Sabah, 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 will get back on that. I 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 tree expansion with, I mean, here he's not showing it, but the one which he was showing, right, the pattern, the tree expansion multi-row with multi or single select, that is the pattern eventually we want. I mean, not in this project,