[DPE-5866] Add Charm Terraform Module

[phvalguima]

This PR extends our current charm to add a terraform module for the charm. It also adds github workflow to test + a basic test setup.

[marcoppenheimer]

todo: From what I remember about OS, it's likely that we'll have multiple machines with different internal specs for different roles. High memory for ML, high disk for something else etc.

I think you might want to add an optional machines var here, that takes a list of juju_machine resources for placement.
I'm not 100% sure of the provider syntax for that, and it's changed a lot recently there and in the spec, but hopefully you get my gist.

[marcoppenheimer]

Same with storages?

[phvalguima]

@marcoppenheimer, TL;DR: this is the "charm terraform". So, we are modeling a single "juju app" here. What you are referring to is the "product terraform". That may be composed by multiple types of juju apps, dashboard, etc. Indeed, for the later, we have to care about that.

Now, back to your questions, I agree with should have both as options: machines and storage.

[phvalguima]

@marcoppenheimer @ghislainbourgeois placement is broken in our provider. If I deploy without using placement, I still get a failure with:

╷                                                                                                                                  
│ Error: Provider produced inconsistent result after apply                                                                         
│                                                                                                                                  
│ When applying changes to module.opensearch.juju_application.opensearch, provider "provider[\"registry.terraform.io/juju/juju\"]" 
│ produced an unexpected new value: .placement: was cty.StringVal(""), but now cty.StringVal("1").                                 
│                                                                                                                                  
│ This is a bug in the provider, which should be reported in the provider's own issue tracker.                                     
╵                                                                                                                                  

There are bugs already reported:

• For placement specifically: Error: Provider produced inconsistent result after apply for placement directives juju/terraform-provider-juju#443, Terraform Failure due to Error: Provider produced inconsistent final plan in Application Placement juju/terraform-provider-juju#182
• and I've also seen that for constraints, as reported here: provider produced inconsistent result after apply on constraints juju/terraform-provider-juju#344, Arranging constraints order shouldn't matter and constraints should resolve properly (GB -> MB) juju/terraform-provider-juju#536

juju/terraform-provider-juju#182 proposes a workaround with:

lifecycle {
        ignore_changes = [ placement, ]
    }

We should not skip changes in placement, nor constraints in my view.

Therefore, I am keeping placement out of this module for now (it will be commented only).

[phvalguima]

BTW, I tried the ignore_changes and dis not work on my test. I am not sure if I missed something.

[ghislainbourgeois]

I think keeping placement out for now is the right course of action until we find the right approach.

[ghislainbourgeois]

This looks great, nice job! On top of the comments that @marcoppenheimer already left, I added a comment regarding the variable model_name.

[phvalguima]

@ghislainbourgeois @marcoppenheimer I have closed the comments that seem to be addressed. There is one big question for me about placement. Can you check that out?

[Mehdi-Bendriss]

Thanks Pedro, it looks good. I have small questions