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

Add import support #6

Open
ocharles opened this issue Apr 11, 2019 · 7 comments
Open

Add import support #6

ocharles opened this issue Apr 11, 2019 · 7 comments
Labels
enhancement New feature or request question Further information is requested

Comments

@ocharles
Copy link

I imagine it would be terraform import nix_nixos.foo <readlink /run/current-system on remote host>.

@andrewchambers
Copy link
Owner

not sure it is so easy. I can't think of a way to find the configuration of a machine, especially if it is split into multiple modules. Maybe the cases of a single configuration.nix in the default location could work.

@ocharles
Copy link
Author

Oh, would you need to do that? I thought it would be enough to just store the store path that the current-system symlink points to

@andrewchambers
Copy link
Owner

I don't think I fully understand the use case. If you write a new resource pointing to an existing nixos install, it will read the system and update only if it differs already - It won't really do anything destructive.

@andrewchambers andrewchambers added enhancement New feature or request question Further information is requested labels Apr 13, 2019
@ocharles
Copy link
Author

It's just about bringing an existing network into Terraform. For example, I have a machine x that's running some NixOS configuration. I'd like to be able to import that into my Terraform state, such that the initial terraform plan says there is nothing to do. It's harmless to deploy the current running system, but it is redundant and makes it difficult to make sure my Terraform configuration matches what I'm currently running. To clarify, this is about the initial work of moving existing infrastructure into Terraform.

@ocharles
Copy link
Author

ocharles commented Apr 15, 2019

Perhaps another way to think about it is: I should be able to write a Terraform configuration, deploying it, delete my state, and then using only terraform import I should be able to reach a state where terraform plan says there is nothing to do. Or maybe you are saying that should already be the case?

@andrewchambers
Copy link
Owner

Hmm, terraform plan may say it is creating a new resource - but then when the creation actually runs, I don't think anything would happen. I will leave this issue open though, maybe it isn't too hard to support.

@HuwCampbell
Copy link

I don't know if you're interested in this anymore.

Usually, resources are based on some canonical ID, like an ARN in AWS; and that state can be used to find the resource in the real world and load its state the next time Read is invoked.

Here however, the resources are given random IDs, as finding the nixos server is simply a matter of interrogating the host via ssh. So I think for a terraform import the best thing to do would be to ignore the final argument and just assign a random ID as well.

Importer: &schema.ResourceImporter{
	State: func(d *schema.ResourceData, m interface{}) ([]*schema.ResourceData, error) {
		d.SetId(randomID())
		return []*schema.ResourceData{d}, nil
	},
},

Then when Read is invoked on the next plan, it will get the current state of the operating system and not say it has to create it (or update it at all if it is indeed the right system state).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request question Further information is requested
Projects
None yet
Development

No branches or pull requests

3 participants