ZeligsoftDev / CX4CBDDS

CX4CBDDS component modeling and generation tool
Apache License 2.0
8 stars 5 forks source link

Issue with CDD creation of multiple domains within a single deployment plan #396

Closed emammoser closed 2 years ago

emammoser commented 2 years ago

Issue and tracking information

Our applications frequently require the ability to deploy the same components/code to various domains. We have a solution in CX where in the deployment plan, we can drag in a domain multiple times and assign multiple different sets of ip addresses and ports to create various CDDs that are equivalent in structure (same number of nodes and names of nodes) and differ only in the hostname:port specifications per node.

It doesn't look like this is working anymore. When I take our BPS example and copy in the domain again, the CDD that is created is using the new node names specified in the configure pane (probably to avoid name clashes), which mean that the deployment system cannot deploy components to the new nodes. In other words, if our CDP says that we deploy to "node1", we cannot deploy to a CDD that has "node1_2"

I am attaching a slightly modified BPS example model with the two domains in the deployment plan along with the CDDs that are created. ExamplesDomain.cdd is the original CDD which is still generated correctly. ExamplesxDomain_2.cdd has the incorrect node names in the file.

Developer's time Estimated effort to fix (hours):

BPS.zip CDDs.zip

Developer's Actual time spent on fix (hours)

Issue reporter to provide a detailed description of the issue in the space below

emammoser commented 2 years ago

We would like this fix done on both papyrus and streams/v2.1.x-maintenance

ysroh commented 2 years ago

After the investigation, I found out that this problem is introduced after fixing https://github.com/ZeligsoftDev/CX4CBDDS/issues/228. We allowed users to modify node names within the deployment plan rather than changing the node instance name from the domain. So I will set the default names of nodes to their node instance names when they are dragged onto the deployment.

emammoser commented 2 years ago

Hmm, I see the problem. I think the end goal is this. We want the names of the nodes in the CDP and all CDDs generated to be that of the first domain in the deployment plan (i.e. the one that is set in the deploy side of the deployment plan). However, we still need the ability to have multiple domains in the configure pane, and the CDDs that generate from the extra domains must work with the single CDP generated from the deployment plan.

ysroh commented 2 years ago

I think you just need to make sure that the node names are the same under all domains. For example, if you modified one of the node names from the deployment plan, then you also need to change the node names from other duplicated domains as well. Do you think this solution works?? The other solution is to go back to the code base before issue #228 so we use the node instance name to generate CDD but do not allow users to modify the node name within the deployment plan. In this case, all generated CDD will have exactly the same node names. You need to change the node instance name if you want to change the node name though. How often do you need to change the node name within the deployment plan to generate a node name that is different than the actual node instance name?

emammoser commented 2 years ago

The deployment plan complains if we have nodes with the same name. Looking back in RSA, multiple domains in the deployment plan had different node names I believe. The only one that mattered was the first domain.

I would also be okay with thinking of a different solution all together. The end goal is that we want to specify a domain with a set of nodes which generate to a CDP and CDD combination. Then, we also want the ability to generate other identical CDD files for that CDP file with different node<-> hostname pairs.

Maybe we distinguish between the first domain and the extra domains?

ysroh commented 2 years ago

Fix merged onto "papyrus" branch. I turned off the warning for duplicate names and set the default node name as its model element. If you change the node name from the deployment plan, you need to make sure to change the node names from other duplicate domains in the deployment. Please let me know if the solution is satisfactory.

emammoser commented 2 years ago

This solution sounds good to me. I will build and verify it on my end, but first...

I agree with the onus being on the user to keep their node names in sync across other duplicate domains in the deployment plan. I do wonder if there is something CX could do to warn the user when this isn't the case. Basically, if the first domain has 4 nodes and some duplicate domain has different nodes, that duplicate domain will not work with the generated CDP file, so I would think it is at the very least a warning condition. Any thoughts?

ysroh commented 2 years ago

No problem. I will throw a warning during validation if node names do not match among multiple domains in a deployment.

ysroh commented 2 years ago

I guess we could close this ticket without adding a validation since issue #400 will solve this issue?

emammoser commented 2 years ago

If #400 does solve this issue such that no user could create a CDD/CDP combo and have different node names between them, then I agree. Additionally, we would need #400 to be implemented relatively soon. If we think it may take a while, that is okay, but then we would want the validation.

ysroh commented 2 years ago

My rough estimation for issue #400 is about 3-4 weeks since this involves a bit of remodelling on the deployment plan and generation plus a new domain definition editor.

emammoser commented 2 years ago

Okay, I think we can ignore the validation warning at the moment since it would be a new feature, more-or-less. I still want to verify this on my end before we close it out.

ysroh commented 2 years ago

Sounds good. thanks.

emammoser commented 2 years ago

This fix looks good to me, but we need the fix on the streams/v2.1.x-maintenance branch too

ysroh commented 2 years ago

Merged to v2.1 maintenance branch as well. closing...