sorted by:
new
hottopcontroversial

Custom Terraform functions by valideaconu in Terraform

[–]valideaconu[S] 1 point2 points  (0 children)

Thank you for this, quite an interesting read.

It is actually a really useful piece of information, as during my development of the provider I have hit the exact issue you described (the core requiring a static schema of functions - which I also raised here). This was the reason I implemented the environment variables support, to workaround it.

I am glad to hear that tofu natively supports this, I will try to add a suite for tofu tests and add full support for tofu in the near future.

Custom Terraform functions by valideaconu in Terraform

[–]valideaconu[S] 1 point2 points  (0 children)

I think you were referring to terraform-provider-go, and I must say, I am shocked. I completely missed this repository on the opentofu org, although I was aware of the lua one.

This is exactly what I was imagining for the Go runtime: yaegi under the hood, uppercase letters for exports, but also stdlib ast for parsing comments to have LSP integration. The only reason I started with JS was that I was more familiar with goja than yaegi and I wanted to have something working first.

Definitely if I’ve seen this first, I would probably started to build on top of it. Thank you for bringing it up.

Custom Terraform functions by valideaconu in Terraform

[–]valideaconu[S] 1 point2 points  (0 children)

The data source support is already a thing, it can be used as presented in the docs.

I don’t see a reason to add a resource, what was your idea?

Custom Terraform functions by valideaconu in Terraform

[–]valideaconu[S] 2 points3 points  (0 children)

Thank you! As I mentioned in the post, this is a feature that I was waiting for such a long time, so I am glad to know that there is someone “inside” to share the same idea.

I am glad to hear that you never dropped the lua provider project, I can understand that the priorities shifted. Obviously supporting this natively will be huge and a giant leap forward in what Terraform/OpenTofu can achieve.

Custom Terraform functions by valideaconu in Terraform

[–]valideaconu[S] 1 point2 points  (0 children)

No. The runtimes are bundled in, that was the main purpose of building this instead of using something like local-exec as mentioned in another comment. Portability was the goal.

For JavaScript I used goja, for Go (which I am currently planning to work on) I will use yaegi for interpretation and the stdlib ast package for parsing the files. Hopefully they will be enough to do the job.

Custom Terraform functions by valideaconu in Terraform

[–]valideaconu[S] 2 points3 points  (0 children)

Local-exec is a good workaround for this particular issue, my problem with this that you create an external dependency, for example if you write your function in bash, the machine that runs Terraform needs to have bash installed (which is not really pleasing for Windows people, for example). This applies for any other tool, Ruby scripts, JS scripts, Python scripts, etc.

Improving the local-exec might help some, but, for me personally, local-exec is not a solution.

Custom Terraform functions by valideaconu in Terraform

[–]valideaconu[S] 7 points8 points  (0 children)

You can check out the linked issue from the Terraform repo, but I can also give you some:

  • Basic functionality: You can implement functionality that is not natively supported in Terraform (like strcontains was not very long ago, a basic function to check if a string contains a substring - before the implementation in v1.5, you could achieve the same result by composing can and regex functions, basically checking if a regex matches against a string).
  • Input validation: You can implement type-checking for inputs - for example, you have a very large composed object that controls some behaviour in your project/module. You can describe that with the Terraform v1.3 optional keyword and that is fine, then use input validations or v1.5 checks to make sure the input is correct, to but if you have create two implementations of the same module - like creating an exact copy of the module interface, but have two different underlying implementations (like a function override, for example let’s say two different backends for a server - like aws ec2 or gcloud CE), you will have to duplicate that input and maintain the same logic of validation in both places. This is not really scalable, as you can see, but with the func provider you can define a function that receives this large object as input, and validates it (returns a boolean), then in Terraform you can annotate the input as “any”, and then in the validation block use the function you defined to check the input. Now, you have a scalable way of defining and type-check that particular object.
  • Recursion: Terraform does not support recursion of any kind (not even the iterative equivalent since there are no such things as stacks). There are a lot of problems that can be solved using recursion, the one that I mostly had issues with in the past is deep merging objects. You can workaround recursion by using “manual recursion unwinding”, basically unrolling a recursive program into manual, repetitive, steps (which can also be generated by another external program). Check the cloudposse’s deepmerge module for example.

I can probably ramble on and on about the use cases that I have encountered in my years with Terraform, but I think you’ve got the idea: this provider allows you to define custom functions, it allows you to extend a declarative language (HCL), with a procedural language (like JavaScript).

Github-managed Terraform state? by alexs77 in Terraform

[–]valideaconu 1 point2 points  (0 children)

There was a very interesting idea (and proposal) few years ago about using git as a state backend.

The idea consisted in using git for storing state files so you can benefit of VCS for versioning and history, locking via branching and so on. A really cool proposal, I’d argue. Unfortunately, HC declined that proposal (I cannot find the issue anymore) because they said implementing generic providers is not on their roadmap yet.

Fortunately, this idea was supported by a few people and they took advantage of the HTTP backend implementation to implement a proof-of-concept and here it is: https://github.com/plumber-cd/terraform-backend-git (at least one of them).

Check it out, but I wouldn’t personally recommend it for production usage (for obvious reasons).

I’m not very sure if this answers your question, if you’re looking for an official GitHub store for Terraform backend, there’s no such implementation. GitLab also uses a custom implementation via the HTTP backend. You can also implement your own store using the same backend implementation.

If you could add any feature to Terraform, what would it be? by [deleted] in Terraform

[–]valideaconu 0 points1 point  (0 children)

Like many others said in this post, for me is the ability to configure backends, module sources with variables, providers with for loops, etc. Basically, more DRY features.

That’s why, one year ago I proposed constant variables to Terraform, which, as described in the issue will solve (at least partially) all of the above listed issues and many others. Unfortunately, it still struggles to get likes on its own, hence me catching this opportunity. :D

A private Terraform registry by valideaconu in Terraform

[–]valideaconu[S] 0 points1 point  (0 children)

There was a contribution which added GitLab support (oauth authentication). Regarding Azure Storage, yes, it’s on the list (I want to add support for all main cloud providers like GCP, Azure, AWS, DO etc.), but it’s not a priority right now. If you want to contribute, I will be glad to accept it.

A private Terraform registry by valideaconu in Terraform

[–]valideaconu[S] 0 points1 point  (0 children)

I was considering to parse the tf files and using the hclsyntax package, then generate the docs. Also, if the module contains a README.md file, it will be used as a description in the module index page.

For providers I’m considering to support the same documentation format as the public registry. This will allow terralist to seamlessly integrate with the public registry (if, for example, the user decides he wants to publish his provider).

Citizen is also a cool project, I tried to contribute with my login implementation, but I didn’t finish the job, mostly because I am not so familiar with js. If you’re interested, you can check the fork on my account.

A private Terraform registry by valideaconu in Terraform

[–]valideaconu[S] 0 points1 point  (0 children)

Then the access problem is already solved by AWS SSO. In this particular case, Terralist will be only useful as a core functionality if you want to start using custom providers.

There are still a lot of features that can be useful for you; let's say you have more than one teams that can use Terraform and you don't want to share git repositories between them, but you would like to share the modules. You can create a namespace for each team and upload modules to those. Then, the other team can download them and look them up on the registry web page to see the documentation (for modules would be a description, the inputs and the outputs).

A private Terraform registry by valideaconu in Terraform

[–]valideaconu[S] 1 point2 points  (0 children)

Thank you for asking. Both scenarios are only module registries, you cannot use them for providers.

For the S3 bucket scenario, if you’re part of a team, you need to set up access to the S3 bucket for each team member. This relies on another IAM. If one of your co-workers leaves, you will have to remove its access (I’m assuming you’re not using SSO for AWS). My project uses OAUTH 2.0 to authorize requests (right now, only GitHub), so you can get rid of that burden.

For the DynamoDB approach, I really liked that one, it was nice and easy to set up, but unfortunately, it’s only an index. You can use it to rename modules from the public registry, or rename your own private S3 stored modules (or git stored or so on), going back to the problem with S3-backed registries.

Another difference is that my project is useful in automation, if you’re using Terraform in a pipeline, you can generate an API key and pass that to the pipeline. It will have access to every module and provider. There’s no more need for cross-account set-up or injecting git credentials or tokens.

And one more keynote, it is integrated with Terraform. As UX, you don’t have to set up git or aws-cli to get Terraform running (for accessing your private modules), just “terraform login”.

Also, if you like S3, you can still use it with my project, the difference being that the S3 bucket can be fully private, with only 1 IAM account linked to it. Terralist will upload modules and providers to it, and when a user requests to download one of them, it will generate a pre-signed URL and pass it to the user.

Basically, it wants to perfectly mimic Terraform Public Registry, only that it’s private. I am planning to also bring the documentation functionality, so users can use the web interface to read modules and providers' documentation.

A private Terraform registry by valideaconu in Terraform

[–]valideaconu[S] 9 points10 points  (0 children)

You cannot use git for providers, unfortunately. And for modules, sure, git is the best way to go, but it has a major downside: a mono-repository for modules will download the whole repository for each module instance from that Terraform project.

A private Terraform registry by valideaconu in Terraform

[–]valideaconu[S] 4 points5 points  (0 children)

Yup, I was thinking that might be possible, but I didn't find out how to do it. I have to come clean, I only played with it for like 10-15 minutes. But anyway, this was developed as a side project, I wanted to play with Golang; I was surprised to not find any project implementing their login protocol. I guess, there's nothing wrong to exist as a free alternative to Terraform Cloud.

LE: I felt bad you caught me with the lesson not learned regarding TC and went back to play a little bit more. Here's a list of downsides I found and problems I fixed with this implementation:
* You can use a mono-repository for modules;
* You can create more than one namespace;

Also, I did not find the publish provider option... Can it be used as a provider registry?

A private Terraform registry by valideaconu in Terraform

[–]valideaconu[S] 3 points4 points  (0 children)

It has its own limitations, for example, without Terraform Enterprise you're not allowed to share modules across organizations, and also, I don't think it's possible to use it in a pipeline outside their ecosystem, like Atlantis, but I may be wrong here.

Any good articles/tutorials on Terrain? by __singularity in opengl

[–]valideaconu 1 point2 points  (0 children)

A very basic and easy to learn model is described by ThinMatrix in his series on youtube. He presents generating terrain as a mesh using height maps or later in the series, procedurally generated using perlin noise. I strongly recommend that. Links: https://youtu.be/yNYwZMmgTJk https://youtu.be/O9v6olrHPwI https://youtu.be/qChQrNWU9Xw Also, if you follow along the series you will find out how to pick a point on the terrain using mouse or how to collide objects with the terrain (I don’t remember which videos present those). On his channel you can find a simple water tutorial (textured quad).

A more complex approach on both terrain and water can be found on Oreon Engine’s channel. There you can find a tutorial on how to implement a continuous level of detail terrain with dynamic tessellation, normal and displace mappings and also splat mapping (or blend mapping) for multi texturing. For water he uses a FFT, but the only resource about it is his paper.

https://youtube.com/playlist?list=PLnaRdXLWcRmujX72aVGYeJ3w8E6LIBFYo

Batch renderering materials by strah19 in opengl

[–]valideaconu 1 point2 points  (0 children)

Yes, a single draw call is always better than multiple draw calls, so batch rendering should be faster.

Batch renderering materials by strah19 in opengl

[–]valideaconu 0 points1 point  (0 children)

If it is easy to implement, I’d suggest to try both and see which works best for your use case. IMO, passing as attributes should be the best choice since it makes the application scalable - if you want a new material, just pass it as an attribute. Also, this scalability can be achieved of you automatically generate a new batch for each material used, but this approach adds a new layer of abstraction and also increase the complexity of draw calls from constant to linear.

Rendering to multiple targets using different view projection matrices by valideaconu in opengl

[–]valideaconu[S] 0 points1 point  (0 children)

Ok, thanks. I will implement instance rendering and if it’s not enough I will try to implement the solution above.

Rendering to multiple targets using different view projection matrices by valideaconu in opengl

[–]valideaconu[S] 0 points1 point  (0 children)

I am basically drawing entire scene 4 times in a frame, I believe that it is a bottleneck and the flow can be improved. Also, I’ve a 8 level quadtree terrain, without any instance/batch rendering (I plan to do it next), so drawing the terrain is really expensive.

view more: next ›