-
Notifications
You must be signed in to change notification settings - Fork 220
Fixes #318
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Conversation
|
||
import java.util.Date; | ||
|
||
public class Version { |
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.
immutable classes 🧡
I think the Quarkus sample should be updated with the new start() method. Also it would be good to make it minimal.. only inject the necessary stuff, as it's a bit weird now, makes me think every time why do I need all those injected things. |
TomcatOperator fails to start:
|
Running the Quarkus sample I don't see any new output with git versions and stuff:
|
About #315 - What's the new functionality there? Until now the Operator crashed if the CRD wasn't present. Does it just quietly not register the controller now? |
It logs a warning and skips the controller registration so that other controllers can still be registered and the operator proceeds. |
That's weird. Did you clean and recompile the whole project? |
Not sure that is a good thing, won't be better just fail? Follow the fail fast principle. If something in the code that intends to register a controller but it is not working, is a big issue, this means the operator is de facto not working as intended. |
I agree that fail fast is better then not registering a controller. Kubernetes is already so async it's hard to find what's causing an issue. This could lead to a situation where the admin says the operator is running while users are complaining that their CRs aren't working. |
The reason for this is that the default configuration service relies on these annotations to be present to do its work. Note: Quarkus applications don't need to be annotated if no changes to the default configuration is needed.
That's a fair point, however in a Kubernetes environment, it might be tricky to diagnose the issue if you just crash the operator as it will cause the pod to restart all the time. Not sure what's the best solution here from an ops' perspective… 🤔 |
You can still check the logs of the pod if it started up and process exited, so that would not be a problem. (The problem is when the container cannot be started, in that case you don't see anything, but this is not this case.) |
Fail fast when the CRD is not found instead of letting watchers throw a cryptic exception based on PR discussion. Fixes #315
Can we merge this, @adam-sandor @csviri ? |
@metacosm LGTM |
private final Date builtTime; | ||
|
||
public Version(String project, String commit, Date builtTime) { | ||
this.project = project; |
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.
@metacosm What is project stands for exactly? Isn't this information inherently redundant?
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.
Or is this meant to be like the application name is spring boot?
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.
@metacosm still not sure about why is this? this seems to me some opionated way. Especially with build time and project. Commit id is fine? Is there some deeper meening of this, or its required by quarkus?
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.
@csviri Maybe a better name would be helpful, indeed. This corresponds to the Maven project version. Why would it be redundant? The goal is to make sure that the operator is running the SDK version the user thinks it's running which can be helpful to diagnose issues.
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 see, makes sense, but isn't the commit id enough for that, like log "running sdk version: {{commit id}}" . Or rather even the release version, thus version of the dependency.
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 the project version is useful as a first check because it's not as easy to figure out which version of the SDK you're running solely from the commit id.
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.
Absolutely, I agree, I just not see any field for real version (in terms of semantic versioning), just commit id and time stamp. Or am I missing something?
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.
Why wouldn't the sdk version be useful? If you have a running operator on a cluster, it's easier to look at the logs than try to figure out which version of the code was used to build the image. Or make sure that the image is actually running the version of the code you think it is… 😄
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 its useful probably just the naming was confusing, so by "project" you meant the SDK Version right? I think that was the only issue, thus was not obviouse what it is.
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.
Yeah, I renamed it to getSdkVersion
LGTM too |
Note that the rename trickles down to several spots because Quarkus' @RecordableConstructor is sensitive to parameter names: the parameter names used in the constructor must match an existing getter.
Fixes #313
Fixes #314
Fixes #315
Fixes #317