Skip to content
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

ENG-9397: Repository Binding Resource Changes #329

Merged
merged 7 commits into from
Dec 20, 2022

Conversation

hbaackmann
Copy link
Contributor

@hbaackmann hbaackmann commented Dec 7, 2022

Description of the change

This PR contains changes to update the cyral_repository_bound_ports resource for Port Multiplexing.
The bound ports data source has been disabled, and will be updated in a separate PR.

Note: Once the changes to the repository resource were merged in, I replaced my original PR with this PR, since I ended up switching branches.

Type of change

  • Bug fix (non-breaking change that fixes an issue)
  • New feature (non-breaking change that adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to not work as expected)

Checklists

Development

  • Lint rules pass locally
  • The code changed/added as part of this pull request has been covered with tests
  • All tests related to the changed code pass in development

Code review

  • This pull request has a descriptive title and information useful to a reviewer. There may be a screenshot or screencast attached
  • Jira issue referenced in commit message and/or PR title

Testing

All tests pass with k8s & CFT CP running port multiplexing controlplane-templates feature branch

Hannah Baackmann-Friedlaender added 2 commits December 6, 2022 18:33
@hbaackmann hbaackmann marked this pull request as ready for review December 7, 2022 05:40
Copy link
Contributor

@VictorGFM VictorGFM left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @hbaackmann, I've added some comments for your consideration. The other parts of the code look good!

cyral/provider.go Outdated Show resolved Hide resolved
cyral/resource_cyral_repository_binding.go Show resolved Hide resolved
DeleteContext: resourceRepositoryBindingDelete,

SchemaVersion: 1,
StateUpgraders: []schema.StateUpgrader{
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we remove the StateUpgraders, old state versions of the cyral_repository_binding will probably cause an error when trying to apply the resource (See - this is for the Framework but I believe it also applies to SDKv2). How are we planning to do the state migration in this case? Why are we not using the StateUpgraders to do the state migration by keeping the StateUpgrader for v0 and adding another one for v1?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point, I wasn't sure how to handle that. I can re-add the old state upgraders-- but I figured there is no point, since the migration script will need to be run anyway (in order to upgrade to 4.0, all bindings will be migrated in the CP and then imported into terraform, like the previous migration). I investigated using the state upgraders for migration, however I decided against it because I was concerned with the fact that if the StateUpgrade fails for some reason, it would be hard to catch and address it (since state upgrade happens automatically when terraform apply is run). Additionally, since bindings are migrated in the CP using various validations, I figured it was safer to just import those back into terraform to eliminate potential inconsistencies. Also, since listeners need to be created based on bindings, there needs to be a script anyway.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see. In this case makes sense to remove the StateUpgraders - since we need to have a migration script anyway.

Comment on lines -210 to -219
// SidecarAsIdPAccessGateway is set to false to stop
// using the bound sidecar as the Access Gateway for Identity
// Provider users. This is needed so that the binding can
// be deleted, otherwise it will throw a validation error.
resourceData := getRepoBindingDataFromResource(d)
resourceData.SidecarAsIdPAccessGateway = false
if err := updateRepositoryBinding(c, resourceData); err != nil {
return createError("Unable to delete repository binding",
fmt.Sprintf("%v", err))
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As I understand, we removed the access gateway flag from the binding resource, and according to this discussion we will have a separate API to manage the access gateway. If that's the case, this is great, especially from a Terraform perspective, the way we designed this access gateway flag in the past caused a lot of unwanted behavior when managing the bindings (The code above is one of the examples, as it was a workaround to avoid errors caused by this gateway flag when trying to delete the binding).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That is correct! There will be an entirely new resource for access gateways.

docs/resources/repository_binding.md Outdated Show resolved Hide resolved
# MongoDB replica set. Cyral will automatically/dynamically identify
# the remaining nodes of the replication cluster.
host = "mycluster-shard-00-01.example.mongodb.net"
# MongoDB replica set. You can explictly specify the host and port of
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@gengdahlCyral Can you review the comments on this guide? I need some guidance here to make sure that everything is explained properly :)

Type: repositoryBindingResourceSchemaV0().
CoreConfigSchema().ImpliedType(),
Upgrade: upgradeRepositoryBindingV0,
ListenerBindingKey: {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@gengdahlCyral Can you also make sure all of the descriptions seem correct to you?

Copy link
Contributor

@VictorGFM VictorGFM left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM @hbaackmann! Very good to know that we simplified a lot how to calculate the total number of bound ports with this new binding/listener design. The docs also look good to me, although would be better if we could have someone else reviewing them, just to make sure the guides cover all the examples we want to provide to users with this new design.

@hbaackmann hbaackmann merged commit 4de9477 into feature/multiplexing Dec 20, 2022
@hbaackmann hbaackmann deleted the feature/ENG-9397 branch December 20, 2022 02:07
hbaackmann added a commit that referenced this pull request Jan 5, 2023
* bindings

* bound ports data source and test

* fix query params for bound ports

* update all documentation
wcmjunior pushed a commit that referenced this pull request Jan 11, 2023
* bindings

* bound ports data source and test

* fix query params for bound ports

* update all documentation
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants