Question \ FR - Ability to assign static Pod\Service\Job names to RuleBook Activations (K8s)

[Daniel-Vaz]

Please confirm the following

• I agree to follow this project's code of conduct.
• I have checked the current issues for duplicates.
• I understand that EDA-Controller is open source software provided for free and that I might not receive a timely response.

Feature type

Enhancement to Existing Feature

Feature Summary

Currently when a RuleBook Activation is created and enabled a default name is generated based on its internal ID and given to the created Pod, Service and Job Objects inside a K8s clusters.

When there is a use-case where a user wants to have a central, long-lived and unique RuleBook Activation, it would be nice if it could have some control over the generated Service Object name. This would make it much easier to create default Ingress\Mappings to expose the RuleBook endpoint.

Currently the RuleBook Activation needs to always be first manually created, and then can we see the generated name for the service so they can be later exposed outside of the cluster.

Steps to reproduce

Create a RuleBook Activation.
See the generated Pod, Service and Job names.

Current results

Pod, Service and Job Names follow the following naming convention:

• Pod: activation-job-<ID>-XXX
• Service: activation-job-<ID>-<PORT>
• Job: activation-job-<ID>

Sugested feature result

Add the ability the statically define the generated resources names (at least Service), in the RuleBook Activation page, and have that name be used for the generated Service Object instead.

Additional information

No response

[Alex-Izquierdo]

RFE: https://issues.redhat.com/browse/AAPRFE-821

[kurokobo]

Pod: activation-job-<ID>-XXX
Service: activation-job-<ID>-<PORT>
Job: activation-job-<ID>

In the recent implementation, these names are updated to use 2 different IDs:

• Pod: activation-job-<Activation ID>-<Instance ID>-XXX
• Service: activation-job-<Activation ID>-<Instance ID>-<PORT>
• Job: activation-job-<Activation ID>-<Instance ID>

These names change simply by reactivating the Rulebook, which increases the difficulty of maintaining a stable connection when users want to create an Ingress as the frontend of the Service. I would like to see this RFE implemented.

[rooftopcellist]

Short of handling the entire flow and creating the Route/Ingress for the user for cases where there is a webhook triggering the rulebook, I think this is a good solution.

The user could specify a custom service name to be used when EDA creates the Service for the Activation. It would be on the user to create a unique name for the Service here.

I think that we should also show the Service name on the details page for the resulting RulebookActivation.

[jon-nfc]

Why this was not even thought of when first implemented is somewhat bemusing.

This feature in particular intorduced a bug, (#616) As the implementation was poorly done. A simple understanding of the DNS would not have had this feature implemented the way it was.

It creates a service in this case, which exists to leverage the DNS system-Which in turn is a large part of how kubernetes communicates hence it's built in implementation of a complete system. DNS exists largely for the purpose of solving the "changing IP address problem". having an item "kubernetes Service" with a name that constantly changes defeats the purpose of having the service in the first place.

I touch upon a part of the issue in #616, with the "useless service name information" whilst this useless information is only metadata, it's better suited for annotations. This still raises an issue with "A DNS name must be unique within the domain it forms part of." This problem however is only reduced to the namespace that EDA is part of, so just the service name. setting the service name to match the rulebook name would suffice with the EDA /rulebook metadata being added as annotations. Using this name as the service name you'd have to filter to [a-z|-] so it remains a valid dns hostname (the first octet of the DNS address). On the odd case that there are two rulebooks with the same name, this would be up to the administrator to correct; As the same name implies the same actions. Although now i think about it, possibly including the project name would allow two projects to have a rulebook with the same name.

As it currently stands now, this amoungst a few other "war stoppers" (As time permits you'll have my bug reports with solutions) makes EDA un-usable as now I need to have automations or a cron job setup to check and correct when a rulebook activation service name changes and as such the time taken to correct this will miss any inbound data, which defeats the sole purpose of having EDA in the firstplace.

I'm a +1 (and some) to have this prioritized for immediate resolution

edit:

• correct last sentence to make sense

[mihaipuha]

We also wait for this to be resolved so we could go into production.