Closed Draxter closed 3 years ago
Hi @Draxter,
The provider is using the same session during all his operations and only if the session is not alive it create a new session. When you run apply on checkpoint_management_logout it logout from your existing session so as long as you execute your pipeline with no waits you will have no open sessions at the end.
Regards, Roy
Thanks for your reply @chkp-royl . I understand. But surely if terraform is ran twice; once to apply checkpoint resources, and the second time to apply the logout resource, it ends up creating two sessions (one of which gets logged out).
After running my pipeline once, the resource gets created, but remains locked, when i remove it from the .tf file and rerun the pipeline it fails to remove because it's locked
Error: failed to execute API call Status: 400 Bad Request Code: generic_error Message: Runtime error: Object 'ddd_terraform_network' is locked by another session.
My pipeline's apply stage now looks as follows:
export TF_VAR_CHECKPOINT_USERNAME=$CHECKPOINT_USERNAME
export TF_VAR_CHECKPOINT_PASSWORD=$CHECKPOINT_PASSWORD
terraform init
terraform apply -auto-approve tfplan
cd session_close #The folder where just the logout resource is located
terraform init
terraform taint checkpoint_management_logout.logout #This is so that logout is recreated at each run
terraform apply -auto-approve
You can add 'depends_on' attribute to logout resource in your configuration so it will execute last in a single apply and not two apply's like you do at the moment. Please try this and let me know if it's solve your problem: https://www.terraform.io/docs/language/meta-arguments/depends_on.html
So I followed your advice @chkp-royl and created a dependency tree with depends_on like so:
resource "checkpoint_management_network" "mynetwork" {
name = "my_terraform_network"
subnet4 = "10.0.248.0"
mask_length4 = 24
comments = "Managed by Terraform"
tags = ["terraform", "test"]
}
resource "checkpoint_management_publish" "publish" {
depends_on = [
checkpoint_management_network.mynetwork,
]
}
resource "checkpoint_management_logout" "logout" {
depends_on = [
checkpoint_management_publish.publish,
]
}
This has worked fine. On subsequent pipeline runs I had to make sure that the publish and logout resources were tainted so that they recreate themselves every time. I have tested creation, modifying and deletion and everything works well.
However, I'm in a weird sitation now where I will need to add every new resource I ever create in the future into the publish resource's depends_on attibute so that the session gets published after all the resources get created.
Hi @Draxter ,
I am happy to hear it worked for you. We might need to add logout post apply script just like publish and install-policy to ensure we logout from the current session and no keep open sessions behind. Because terraform runs in parallel we must to make sure logout is being executed as last operation so using 'depends_on' attribute we hint to terraform about order of execution.
Regards, Roy
I'm having trouble figuring out the intended workflow with this Terraform provider. In particular, with using the session and logout resources to publish the session and log it out which is quite unusual in Terraform.
My Pipeline Stages:
Plan: runs terraform plan and outputs a plan file
Apply: runs terraform apply to create a checkpoint_management_network and checkpoint_management_session to publish the session
Logout: changes directory to a folder with a single .tf file that contains a single checkpoint_management_logout resource to log a session out.
However, I still end up with sessions that are left open and sometimes, locked resources. My question therefore is, How do you envisage a pipeline workflow with this terraform provider to work? According to my tests, every time terraform is ran, it logs into Checkpoint API and creates a new session, therefore when it runs the logout stage, it only closes that second session, not the one created in the 'Apply' stage.
I see you also have a second method of publishing a session described in the docs here. However, one would still need to apply the checkpoint_management_logout resource to logout a session, therefore creating a new session.