-
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
kie-issues-314: Operator driven service discovery API Phase3 #316
Conversation
Closes #314 |
4981872
to
51c6a1a
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.
Hi Walter! Many thanks for this work! I think we need to adjust a little bit the Knative client builder and we are ready to go. :)
@@ -536,6 +536,42 @@ spec: | |||
- subjectaccessreviews | |||
verbs: | |||
- create | |||
- apiGroups: |
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 catch!
controllers/discovery/discovery.go
Outdated
@@ -84,10 +89,10 @@ type sonataFlowServiceCatalog struct { | |||
} | |||
|
|||
// NewServiceCatalog returns a new ServiceCatalog configured to resolve kubernetes, knative, and openshift resource addresses. | |||
func NewServiceCatalog(cli client.Client) ServiceCatalog { | |||
func NewServiceCatalog(cli client.Client, knServingClient clientservingv1.ServingV1Interface, knEventingClient clienteventingv1.EventingV1Interface) ServiceCatalog { |
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.
We can have a DiscoveryClient
struct to hold all this and share it here as a pointer. Wdyt?
@@ -116,7 +116,7 @@ func doTesQueryKubernetesDeploymentWithService(t *testing.T, outputFormat string | |||
service.Spec.Type = corev1.ServiceTypeNodePort | |||
|
|||
cli := fake.NewClientBuilder().WithRuntimeObjects(deployment, service).Build() | |||
ctg := NewServiceCatalog(cli) | |||
ctg := NewServiceCatalog(cli, nil, 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.
Having a DiscoveryClient
you can get rid of passing nil
here.
NewKnativeDiscoveryClient(cli, knativeEven, knativeSvc)
and NewDiscoveryClient(cli)
. Alternatively, the NewServiceCatalog
could create this knative clients internally if it only depends on client
.
@@ -267,6 +268,35 @@ func generateDiscoveryProperties(ctx context.Context, catalog discovery.ServiceC | |||
} | |||
} | |||
} | |||
|
|||
for _, function := range workflow.Spec.Flow.Functions { |
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.
This method is getting quite large. Maybe a little refactoring here to an app_properties_discovery.go
file that would wrap al of this? wdyt?
main.go
Outdated
os.Exit(1) | ||
} | ||
} | ||
} |
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.
Here's not the best place to add this. If I install this operator first and then knative, I won't have these clients configured. We have to carry the RestConfig
to the controllers and create the Knative clients during the reconciliation.
Alternatively, we can have a factory for these clients to hold them in a singleton pattern. In every reconciliation cycle, we can simply check if Knative is still installed in the cluster and return the client we have.
This accessor then can be used in discovery and we avoid passing all this construct ProfileExtensions
around.
Something like knative.GetClient()
will check if there's an instance ready, if not we create one, cache, and return.
Also, this is not a required state, meaning we can't os.Exit(1)
if we can't create the client.
utils/cluster.go
Outdated
// SetIsKnative sets the global flags isKnativeServing and isKnativeEventing by the controller manager. | ||
func SetIsKnative(cfg *rest.Config) { | ||
if cli, err := discovery.NewDiscoveryClientForConfig(cfg); err != nil { | ||
panic("Impossible to verify if the knative system is installed in the cluster: " + err.Error()) |
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.
Like I said in the previous comment, if we can't get a Knative client, we disable discovery for their objects or any future feature we may have.
utils/knative/common.go
Outdated
* under the License. | ||
*/ | ||
|
||
package knative |
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.
We can have a topmost knative
package to implement everything I'm proposing in the other 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.
I think you can move this code to the new module controllers/knative
@@ -37,6 +41,36 @@ func SetIsOpenShift(cfg *rest.Config) { | |||
var err error | |||
isOpenShift, err = openshift.IsOpenShift(cfg) | |||
if err != nil { | |||
panic("Impossible to verify if the cluster is OpenShift or not" + err.Error()) | |||
panic("Impossible to verify if the cluster is OpenShift or not: " + err.Error()) |
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.
Here it's fine to have a terminal state since being or not OpenShift is deterministic.
@ricardozanini your suggestions were added, would you mind take a second look? |
btw, E3E test is failing because of /home/kogito/launch/build-app.sh file permissions. INFO[0019] Args: [-c /home/kogito/launch/build-app.sh ./resources] |
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.
Only details now Walter! Great work, clean and concise. I like it a lot. Many thanks!
utils/knative/common.go
Outdated
* under the License. | ||
*/ | ||
|
||
package knative |
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 think you can move this code to the new module controllers/knative
@ricardozanini your additional suggestions are in, have a look please. |
kie-issues-314: Operator driven service discovery API Phase3 - Adds the processing of workflow functions to generate the service discovery for knative functions invokations kie-issues-314: Operator driven service discovery API Phase3 - Code review suggestions 1 kie-issues-314: Operator driven service discovery API Phase3 - Code review suggestions 2
ae8ab89
to
5733069
Compare
Hi @ricardozanini , this is ready to merge |
Description of the change:
Motivation for the change:
Checklist
How to backport a pull request to a different branch?
In order to automatically create a backporting pull request please add one or more labels having the following format
backport-<branch-name>
, where<branch-name>
is the name of the branch where the pull request must be backported to (e.g.,backport-7.67.x
to backport the original PR to the7.67.x
branch).Once the original pull request is successfully merged, the automated action will create one backporting pull request per each label (with the previous format) that has been added.
If something goes wrong, the author will be notified and at this point a manual backporting is needed.