-
Notifications
You must be signed in to change notification settings - Fork 25
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
CRD changes for 2.1.0 release of the operator #728
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
- add `RestorePointPolicy` type in `Spec` - `Archive` must be specified if a restore is intended - one of `ID` and `Index` must be specified (`Index` assumed to be 1-based) - webhook rules to validate `RestorePointPolicy` - revivedb_reconciler checks whether restore is supported given the server version and deployment method - must use vclusterops and has server version greater than v24.2.0 --------- Co-authored-by: Roy Paulin <[email protected]>
This PR build out the stub for an empty controller to handle the VerticaRestorePointsQuery API. It does not include a webhook, as there are no defined rules for transitioning the Custom Resource (CR), given that the spec portion contains only two fields. The operator can observe the new API, initiate a reconciliation iteration, and take no action, as we have set nil for the actors during this implementation phase --------- Co-authored-by: Matt Spilchen <[email protected]>
- Fix webhook bug so that negative index values are denied - Fix revivedb reconciler so that only the first letter of the first word is captitalized --------- Co-authored-by: Roy Paulin <[email protected]>
- pass restorePoint configuration from VerticaDB CR to vclusterops while we revive - new e2e test for reviving from a restore point
…ry cr (#658) In the VerticaRestorePointsQuery CRD we have status conditions to know when the query has started and when it has finished. conditions: - lastTransitionTime: <ts> status: "True" type: Querying - lastTransitionTime: <ts> status: "True" type: QueryComplete This PR can add the status condition logic as follows: - skip reconcile if QueryComplete is true - set Querying status condition prior to calling vclusterops API - clear Querying status condition after calling API. Include an error message in the status condition if the API fails. - set the QueryComplete if the vclusterops API suceeded
This PR will fetch the VerticaDB to collect this information from a VerticaDB for the new VerticaRestorePointsQuery CR, and extract out the config information to pass down to the vclusterops API. --------- Co-authored-by: Matt Spilchen <[email protected]>
- operator now handles ReviveDBRestorePointNotFound error returned from vclusterops - e2e test for invalid id and index - e2e test for cluster scaling before restoring --------- Co-authored-by: Matt Spilchen <[email protected]>
This PR adds custom print columns for the new VerticaRestorePointsQuery CR, so that a kubectl get vrpq command tells you if the query has completed.
This PR build out the stub for an empty controller to handle the VerticaScrutinize API. For now The operator can observe the new API, initiate a reconciliation iteration, and take no action, as we have set nil for the actors during this implementation phase
As we discussed, this task is divided into two parts. This PR completed the first part, which involved calling the vclusterops API to perform the restore points query. A follow-up task to copy the result of the query into the CRs status fields will be processed later
This PR represents the second piece of implementing controller logic for VerticaRestorePointsQuery. It involves copying the result of the query into the status fields of VerticaRestorePointsQuery CR
This includes a few updates to the vcluster API - Update to function signature for VReviveDB - Update Restore Point struct to make status fields not required
This adds the logic to generate a dummy pod when a VSCR CR is created. It does the following: - checks if the VerticaDB specified in Vscr exists - checks the server version and abort reconciliation if version is too old - creates a pod For now the pod does not run scrutinize, the logic for that will be added on a follow-up PR. The pod composed of 2 containers, an init container (that will collect scrutinize container later) and a main container. Both run hard-coded image (busybox) and respectively sleep for 5s and for infinity. We also set some fields(initContainers, Volume,...) with values from Vscr.
The control-plane: controller-manager label changed in the last merge. Updating test cases that exist only on the vnext branch.
- update vrpq CRD to support filtering options for archive name, and start and end timestamps - update e2e test to test for the archive name filter and timestamps filters --------- Co-authored-by: spilchen <[email protected]>
…#700) This PR adds some checks for the new VerticaRestorePointsQuery CR. The VerticaDB should be running with a minimum version of 24.2.0 and should be deployed with vclusterOps. We don't support admintools deployments
- add e2e test for date-only timestamps --------- Co-authored-by: spilchen <[email protected]>
This PR creates a webhook for the new VerticaRestorePointQuery CR to catch the checks early. There is some webhook part that is added in #643."
When a VerticaScrutinize resource is created, the operator: - collects some info from the specified VerticaDB in order to construct vcluster scrutinize command arguments - builds the scrutinize podspec. That pod will shares the same serviceaccount, podsecuritycontext, image as vertica pods. - adds some env vars to the podspec needed by nma and also 2 new env vars(`PASSWORD_NAMESPACE`, `PASSWORD_NAME`) to allow vcluster scrutinize to read the db password from secret. Once the pod is created, a new reconciler(`PodPollingReconciler`) will wait for scrutinize to finish and update status condition
This pulls in the latest changes from main into vnext. There are a lot of changes here because of the copyright year change. --------- Signed-off-by: GitHub <[email protected]> Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com> Co-authored-by: spilchen <[email protected]>
this give users a way to set the main container resources through annotations. The main container resources remain unset unless the resources are set for the init container too. The annotations are as follow: ``` vertica.com/scrutinize-main-container-resources-limits-cpu vertica.com/scrutinize-main-container-resources-limits-memory vertica.com/scrutinize-main-container-resources-requests-cpu vertica.com/scrutinize-main-container-resources-requests-memory ```
This caches the tarballName in our VSCR status after a successful scrutinize run. The generated tarball name follow a specific format needed by `grasp`. To access the tarball name between reconcilers, we cache it in the scrutinize pod annotations.
Now when you have a VerticaScrutinize CR created, if you do kubectl get, you will get info about the scrutinize pod name and the state of the scrutinize run. The state is `Ready`, `PodCreated`, `ScrutinizeInProgress`, `ScrutinizeSucceeded` if successful and `NotReady:<reason>`, `PodCreationFailed`, `ScrutinizeFailed` in case of a failed run. kubectl get vscr will look like this: ``` NAME STATE POD AGE verticascrutinize-sample ScrutinizeSucceeded verticascrutinize-sample 84m ```
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This merges the vnext branch into the main branch. We utilized this branch to keep CRD changes separate until they were prepared for release. As a result, it contains numerous modifications. The following is a summary of the changes: