-
Notifications
You must be signed in to change notification settings - Fork 42
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[KOGITO-9940] Add Job Service to SonataFlowPlatform CRD #311
[KOGITO-9940] Add Job Service to SonataFlowPlatform CRD #311
Conversation
8dac349
to
cba7063
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice work! Many thanks! I just left a few small comments.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great work! ❤️
Can you run:
Should pass the CI. |
lgtm |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
missed this earlier
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've added some comments guys at the time we continue working in parallel to make the service work by using the PR sources.
good job in general!
|
||
// GetServiceImageName returns the image name of the service's container. It takes in the service and persistence types and returns a string | ||
// that contains the FQDN of the image, including the tag. | ||
func GetServiceImageName(persistenceName string, stype ServiceType) string { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let me add guys a general comment regarding the app_properties.go. I think that here, we originally started to manage the application.properties related to the workflows, but the application.properties related to the services are a different stuff. Now I think this is starting to become a sort of all in one.... Not sure it's good.
now we have things like this:
incubator-kie-kogito-serverless-operator/controllers/profiles/common/app_properties.go
Line 256 in 9a1e05d
handler := &appPropertyHandler{ |
with a common.NewServiceAppPropertyHandler that uses the original handler := &appPropertyHandler{
platform: platform,
isService: true,
}
and that we use when we need to create the applicaton.properties for a service, in places like this:
workflowproj.ApplicationPropertiesFileName: common.NewServiceAppPropertyHandler(platform).Build(), |
IDK, just thinking aloud, but maybe this deserves a piece of refactoring.
@@ -58,30 +60,72 @@ func (action *serviceAction) Handle(ctx context.Context, platform *operatorapi.S | |||
return nil, err | |||
} | |||
|
|||
if err := createDataIndexComponents(ctx, action.client, platform); err != nil { | |||
return nil, err | |||
if platform.Spec.Services.DataIndex != nil { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have question here, maybe I'm missing something or not understanding well, but my understanding is that when we execute this Handle, is because the platform.Status.IsReady().
So, when the platform is ready, we start to create the services. All good, but on the other hand, if the platform is ready, the workflows might have been started the creation procedure too.
if worklfows and services re being created at the same time, what happens if a workflow needs a service?
does it make sense?
return platform.Status.IsReady()
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
agreed we should enhance the SonataFlowPlatform's status to account for service deployments.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
KOGITO-9972 will require changes to SonataFlowPlatform.status
and, i expect, will be a good time to make some enhancements.
0688e86
to
fdd9ef4
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for the refactoring, but can you kindly consider my comments? Many thanks!
@masayag PTAL |
@@ -58,30 +55,32 @@ func (action *serviceAction) Handle(ctx context.Context, platform *operatorapi.S | |||
return nil, err | |||
} | |||
|
|||
if err := createDataIndexComponents(ctx, action.client, platform); err != nil { | |||
return nil, err | |||
if platform.Spec.Services.DataIndex != nil { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we get into this block if platform.Spec.Services.DataIndex.Enabled == false
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it's correct as it is. the Enabled
field does not control whether a service is deployed. instead, it controls whether its used by the "prod" workflows -
incubator-kie-kogito-serverless-operator/api/v1alpha08/sonataflowplatform_services_types.go
Lines 27 to 29 in a96add5
// Determines whether "prod" profile workflows should be configured to use this service | |
// +optional | |
Enabled *bool `json:"enabled,omitempty"` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for the reference.
In which case should this be set to false, assuming the workflow's profile is set to prod
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
no, this flag only affects "prod" workflows. if it's a dev workflow, this flag won't even be checked by the operator. when a user elects to set platform.spec.services.dataIndex.enabled
to true
(which is the default), they are saying they want "prod" workflows to use this data index.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My question is when would platform.spec.services.dataIndex.enabled
be set to false
?
Which business use case is served by disabling the data-index (or job-service) for prod workflows?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I also think this all sounds reasonable, with RollingUpdate
as the default when this new "flag" is not set. @ricardozanini I don't think the cluster-scoped changes would need to wait for this though... what is your thinking with that?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Won't we replicate the spec in the cluster scope? I'd rather have the change once and propagate to the cluster-scoped requirements.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
no, we will not replicate the spec in cluster-scope. we previously discussed this and decided to only reference the chosen platform in spec and leave it at that. the referenced SonataFlowPlatform will be the single source of truth.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fair, I remembered now sorry for the noise. @masayag can you open an issue here to implement this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See #321
e1bd42c
to
320ab56
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@wmedvede can you please take a second look too?
439c96b
to
1e0f2f5
Compare
@jordigilh does your PR descrip still match the changes you're making here? if not, could you update it? thanks! |
Updated. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, I've added some comments, thanks!
// service's spec field `Enabled` set to true | ||
func GenerateJobServiceApplicationProperties(workflow *operatorapi.SonataFlow, platform *operatorapi.SonataFlowPlatform) *properties.Properties { | ||
props := properties.NewProperties() | ||
if profiles.IsProdProfile(workflow) && jobServiceEnabled(platform) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
maybe this condition explains what we chatted, note that if no workflow is present and we create a platform with the jobs-service it's created.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jordigilh @ricardozanini In my opinion to instanciate the services even with no workflows is valid.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
btw, @jordigilh @ricardozanini the comment above regarding the IsProdProfile check apply also for the data-index
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, that should work independently.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Removed references to the workflow in both data index and job service application properties generation.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jordigilh can you explain what was changed here and why?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@tchughesiv This change is because in order for the workflows to work, (when configured) we need the jobs-service and data-index to be deployed first, but also, it might occur, that we push the platform into the namespace, and then, we push the workflows. So, what we are looking for with this change is that the deployment of the services are not dependent on any particular workflow.
That's basically the aim of this change.
Signed-off-by: Jordi Gil <[email protected]>
…or version Signed-off-by: Jordi Gil <[email protected]>
Signed-off-by: Jordi Gil <[email protected]>
Signed-off-by: Jordi Gil <[email protected]>
Signed-off-by: Jordi Gil <[email protected]>
…r jobs-service Signed-off-by: Jordi Gil <[email protected]>
Signed-off-by: Jordi Gil <[email protected]>
Signed-off-by: Jordi Gil <[email protected]>
…nts and avoid duplications between packages Signed-off-by: Jordi Gil <[email protected]>
…tionProperties and GenerateDataIndexApplicationProperties Signed-off-by: Jordi Gil <[email protected]>
Signed-off-by: Jordi Gil <[email protected]>
Signed-off-by: Jordi Gil <[email protected]>
This reverts commit 2b3638a.
…generate the application service properties. Reactive URL for job service won't include a default schema if it's not provided in the JDBC URL for PostgreSQL Hardcoded Job Service replica count to 1. Signed-off-by: Jordi Gil <[email protected]>
… configmap Signed-off-by: Jordi Gil <[email protected]>
…gresql port value Signed-off-by: Jordi Gil <[email protected]>
…job service Signed-off-by: Jordi Gil <[email protected]>
…cover the two cases of deploying the service with its unique properties and the ones generated specific for workflow deployments Signed-off-by: Jordi Gil <[email protected]>
Signed-off-by: Jordi Gil <[email protected]>
Signed-off-by: Jordi Gil <[email protected]>
eb9d750
to
dc887d7
Compare
…rty tests Signed-off-by: Jordi Gil <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
After the final local tests on openshift I can see the following scenarios working
1) jobs-service and data-index deployed with postgresql + a later workflow deployment
Services are started well and gets positive health checks, and has the expected configurations. Similar results for the workflow.
2) jobs-service postgresql + a later workflow deployment
Job service is started well and gets positive health checks, and has the expected configurations. Similar results for the workflow.
3) data-index deployed with postgresql + a later workflow deployment
Data index service is started well getting positive health checks and, and has expected configurations, similar for the workflows.
I conclude that we can merge, other fine tunnings or missing tests can be done in a follow-up PR.
minkube deployment checks where was done by @jordigilh
Good job!
@ricardozanini let's merge!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm
* [KOGITO-9940] Added job service field in platform CRD Signed-off-by: Jordi Gil <[email protected]> * Add reconciliation logic for Job Service Signed-off-by: Jordi Gil <[email protected]> * Added ServiceType enum type and changed the image tag based on operator version Signed-off-by: Jordi Gil <[email protected]> * Make generate-all * Add application.properties entry for jobService URL Property Signed-off-by: Jordi Gil <[email protected]> * Renaming serviceSpec field 'job' to 'jobService' Signed-off-by: Jordi Gil <[email protected]> * Add missing job service properties Signed-off-by: Jordi Gil <[email protected]> * Add reactive property when postgreSQL is configured as persistence for jobs-service Signed-off-by: Jordi Gil <[email protected]> * Refactor to use interface Signed-off-by: Jordi Gil <[email protected]> * Refactoring services to extract from profiles/common Signed-off-by: Jordi Gil <[email protected]> * Moved platform services and reconciliation constants to common/constants and avoid duplications between packages Signed-off-by: Jordi Gil <[email protected]> * Updated golang doc function description for GenerateJobServiceApplicationProperties and GenerateDataIndexApplicationProperties Signed-off-by: Jordi Gil <[email protected]> * Updated ginkgo to v2.13.0 and gomega to v1.30.0 Signed-off-by: Jordi Gil <[email protected]> * Added unit tests for data index and job service application properties * Changes based on feedback from Walter Signed-off-by: Jordi Gil <[email protected]> * Revert "Changes based on feedback from Walter" This reverts commit 2b3638a. * Check for not dev profile instead of production one for condition to generate the application service properties. Reactive URL for job service won't include a default schema if it's not provided in the JDBC URL for PostgreSQL Hardcoded Job Service replica count to 1. Signed-off-by: Jordi Gil <[email protected]> * Include the platform service application properties in each service's configmap Signed-off-by: Jordi Gil <[email protected]> * Fix sonataflowplatform_controller_test.go failing due to invalid postgresql port value Signed-off-by: Jordi Gil <[email protected]> * Fix tests due to changes in schema and additional properties for the job service Signed-off-by: Jordi Gil <[email protected]> * Extended logic in Job Service for application property generation to cover the two cases of deploying the service with its unique properties and the ones generated specific for workflow deployments Signed-off-by: Jordi Gil <[email protected]> * Updated generated properties based on feedback Signed-off-by: Jordi Gil <[email protected]> * Refactored unit tests for properties and rebased to fix e2e test Signed-off-by: Jordi Gil <[email protected]> * Add JS generated property for deployment and cleaning chores on property tests Signed-off-by: Jordi Gil <[email protected]> --------- Signed-off-by: Jordi Gil <[email protected]>
* [KOGITO-9940] Added job service field in platform CRD Signed-off-by: Jordi Gil <[email protected]> * Add reconciliation logic for Job Service Signed-off-by: Jordi Gil <[email protected]> * Added ServiceType enum type and changed the image tag based on operator version Signed-off-by: Jordi Gil <[email protected]> * Make generate-all * Add application.properties entry for jobService URL Property Signed-off-by: Jordi Gil <[email protected]> * Renaming serviceSpec field 'job' to 'jobService' Signed-off-by: Jordi Gil <[email protected]> * Add missing job service properties Signed-off-by: Jordi Gil <[email protected]> * Add reactive property when postgreSQL is configured as persistence for jobs-service Signed-off-by: Jordi Gil <[email protected]> * Refactor to use interface Signed-off-by: Jordi Gil <[email protected]> * Refactoring services to extract from profiles/common Signed-off-by: Jordi Gil <[email protected]> * Moved platform services and reconciliation constants to common/constants and avoid duplications between packages Signed-off-by: Jordi Gil <[email protected]> * Updated golang doc function description for GenerateJobServiceApplicationProperties and GenerateDataIndexApplicationProperties Signed-off-by: Jordi Gil <[email protected]> * Updated ginkgo to v2.13.0 and gomega to v1.30.0 Signed-off-by: Jordi Gil <[email protected]> * Added unit tests for data index and job service application properties * Changes based on feedback from Walter Signed-off-by: Jordi Gil <[email protected]> * Revert "Changes based on feedback from Walter" This reverts commit 2b3638a. * Check for not dev profile instead of production one for condition to generate the application service properties. Reactive URL for job service won't include a default schema if it's not provided in the JDBC URL for PostgreSQL Hardcoded Job Service replica count to 1. Signed-off-by: Jordi Gil <[email protected]> * Include the platform service application properties in each service's configmap Signed-off-by: Jordi Gil <[email protected]> * Fix sonataflowplatform_controller_test.go failing due to invalid postgresql port value Signed-off-by: Jordi Gil <[email protected]> * Fix tests due to changes in schema and additional properties for the job service Signed-off-by: Jordi Gil <[email protected]> * Extended logic in Job Service for application property generation to cover the two cases of deploying the service with its unique properties and the ones generated specific for workflow deployments Signed-off-by: Jordi Gil <[email protected]> * Updated generated properties based on feedback Signed-off-by: Jordi Gil <[email protected]> * Refactored unit tests for properties and rebased to fix e2e test Signed-off-by: Jordi Gil <[email protected]> * Add JS generated property for deployment and cleaning chores on property tests Signed-off-by: Jordi Gil <[email protected]> --------- Signed-off-by: Jordi Gil <[email protected]>
ServiceSpec
in the SonataflowPlatform CRD for a Job Service, reusing the same type as theDataIndex
field.profiles
and move it insideplatform
package@tchughesiv @ricardozanini PTAL.