You can configure the values.yaml used by the helm chart and pass it into the module. Within the values.yaml you can add your configuration https://github.com/cloudposse/terraform-aws-helm-release/blob/main/examples/complete/main.tf line 45

And for a template of the values.yaml look at https://github.com/DataDog/helm-charts/blob/main/charts/datadog/values.yaml

You want the section named confd on line 500

Thanks! This is very helpful. One addition; from the docs and from datadog support, we are being instructed to explicitly install the puma integration as it is not provided by default in the datadog agent. Specifically, we need to add

RUN agent integration install -r -t datadog-puma==1.2.0'

to the image dockerfile, or otherwise invoke this same command on a boot hook.

I am inferring from this yaml file that the gcr datadoghq registry is how the image is specified, and if Ii want to add a custom image to add the above, I would possibly fork this chart and add our own image? Or should there be an easier method to customize the container we are using for our datadog agent?

You would specify your registry in the values.yaml and then deploy it with helm. That would tell helm how you want the install customized.

https://www.hashicorp.com/license-faq

What is considered a competitive offering?
HashiCorp considers a competitive offering to be a product or service provided to users or customers outside of your organization that has significant overlap with the capabilities of HashiCorp’s commercial products or services. For example, this definition would include providing a HashiCorp tool as a hosted service or embedding HashiCorp products in a solution that is sold competitively against our offerings. If you need further clarification with respect to a particular use case, you can email [email protected]. Custom licensing terms are also available to provide more clarity and enable use cases beyond the BSL limitations.

https://github.com/runatlantis/atlantis/issues/3663

Well this has ruined my week

Will this lead to a fork of free terraform?

Spacelift responds: https://spacelift.io/blog/hashicorps-license-change

Hope the impacts are manageable for CloudPosse

Think Spacelift/Digger/Env0 will give it a go.

https://github.com/diggerhq/open-terraform

Based on this year, terraform core looks to have around 4 main developers. https://github.com/hashicorp/terraform/graphs/contributors?from=2021-11-08&to=2023-08-11&type=c

I guess the issue will be if a breaking change in Terraform occurs that the main TF providers keep supporting v1.5.5. The trend is to auto-generate the providers so perhaps it won’t be too difficult.

The reaction is strong. I really hope that digger fork, or another, gets going. There are a lot of PRs that were never accepted on the tf project that would have made it so much better. https://news.ycombinator.com/item?id=37081306

So What this drama meaning for someone like a DevOps engineer, who help companies with their IaC work? I’m I a competitor?

you’re fine, Hashicorp aren’t going to come after you. The issue is that conservative/paranoid organisations, the kind who are just coming into Terraform, decide it’s not worth the legal ambiguity.

Earthly, for example, went BUSL but found ground-up adoption in Enterprises was hampered by ambiguity so they then reverted to open source.

https://podcasts.apple.com/us/podcast/two-time-founder-vlad-a-ionescu-on-finding-success/id1514646781?i=1000623896594

https://twitter.com/thockin/status/1690223611372851200

https://blog.upbound.io/hashicorp-bsl-license-change?utm_medium=twitter&utm_source=organic-social&utm_term=blog

The fact various vendors quickly jumped and tried to calm down the mass is great however that is only the tip of the iceberg.

If you overlay what Tim Hockin & https://typefully.com/iamvlaaaaaaad said … well the cats are out of the bag and that is the un-measurable damage Corporations don’t account for - see RH/ IBM with CentOS, the move RH did a while back with ansible.

Very simple view:

Nowadays my world is in GCP where entire IaC investment put in by Google is not on Cloud Deployment Manager (similar to Cloudformation) but TF.

If a very well respected person like Tim H says what he said then ….. sad

The precedent was created with Mongo and Elastic hence copycat …

Seems Digger are going to collab with others. Terragrunt had the wishful thinking idea of them being the new ‘open source’ terraform.

This is in the works, precisely along the lines of teaming up / industry backing. It was a fun weekend :) Stay tuned!

Hopefully GCP, Oracle and maybe Tencent back it with engineers and it lands in CNCF. GCP did some of this with Airflow where they outsourced maintenance/core contributions to some Polish folks.

https://github.com/diggerhq/open-terraform/issues/5#issuecomment-1676830159 https://github.com/gruntwork-io/terragrunt/issues/2662

Has anyone seen any discussions on potential forks of Hashi Vault?

On forks of vault, not seen anything. The reasons is probably won’t be are that the hyperscalers have their own solutions to cover the 80% use case, the abstraction by tools like External Secrets Operator, it’s a complex product, and hashicorp’s FAQs seem to be tolerant of internal teams at enterprises continuing to operate it for free.

New projects might take a chance on Infisical ($3m seed) but which is also single-vendor.

Reasons it might be forked is it’s priced very highly and if many second and third tier clouds use it for their own (external facing) secrets service and they decide to pool maintenance.

I don’t get the point here. Would you like to see Hashicorp become like docker inc? All for not paying licences? And still in this case it’s more spacelift/env0 taking the hit as they are competing with Terraform cloud that by the way could be improved. Hashicorp over priced? But how compared to gitlab and other solutions? I see dumb saas for project management like miro and so racking a lot more if you count per user licences!

It made sense for our company to run Hashi Vault before they hiked up their rates. Now it’s cheaper to use the cloud provider’s secret manager, especially given the additional overhead of running and managing the enterprise instance.

PTR records are not supported for private IP addresses like 10.10.21.57. Probably what has changed is that you are using an updated tool that now checks for PTR records where it did not before, rather than anything changing with the deployment itself.

Why have many AZs if you only have one gateway?

Because we’re fine in the trade off of redundancy at the price difference

We dont need that many nines of uptime, usually when things break, the whole region is broken, I can’t remember a time when we’ve had an issue of a single AZ.

You’ll pay a bunch in cross-az network transit too.. That’ll offset your savings.

Maybe the workaround is to create the nat GW separately

only if there’s a lot of outbound traffic

What I mean is, why spread your infra over many AZs in the first place? Put everything in one AZ. You’ll save on cross AZ traffic and complexity.

Using many AZs but a NAT in only one of them is worst of both worlds. Less reliable and more expensive.

It’s a false sense of security to have multiple AZ and a single NAT gateway

That said I think recent changes to dynamic subnets supports a configurable number of NAT gateways. Cc @Jeremy G (Cloud Posse)

We have too many overly-specialized subnet modules, so in an effort to cut down, we are focusing our effort on terraform-aws-dynamic-subnets , which supports a configurable number of NATs and many other nice features.

https://github.com/clouddrove/terraform-aws-subnet

you can find multiple az with multiple Natgateway.. Its a managed module.

https://github.com/clouddrove/terraform-aws-subnet/blob/master/examples/private-subnet/example.tf#L37

And guess who’s behind this? See the list of the compagnies already. Most of those are directly threatened by BSUL no end customer.

Indirectly, all the users of the products built by those companies, for whom TFC didn’t cut it or was too expensive

Well they are making money with Hashicorp software and they could cut a deal with them and pay licences. That’s how it works. Nope they claim hero’s of the open source cause while all their offering is closed source.

I don’t see a problem with it. TFC is also closed source

And free open source is exactly free to use as they did. They helped build the Terraform community, and then competed well. Hashi just had to build a paid product people actually wanted, and they failed

TFC is the way Hashicorp make money to fund TF. Same over Vault Entreprice offering and HCP.

Hashi could easily have spread the load of terraform maintenance, but they largely rejected community involvement and contributions. If folks fork and succeed, perhaps Hashicorp will switch to use the fork in their enterprise and cloud offerings

Hashicorp did a lot of great job with their open source and free products. They deserve to make more money. And yes TFC sucks we ditched it.

Hashicorp using the fork that would kill them. That’s insane

I don’t see why it would kill them, if it provides as good or better capabilities, and the license is amenable

it will make Hashicorp like docker inc which again something I don’t want to see.

That doesn’t track to me. They’d lose some control, but also be able to refocus resources on their paid offerings

I agree they ought to be able to make money, though “deserve” is probably too strong IMO. They need to compete and win with a paid product

That’s a good way of putting it. Instead of trying to prevent people from competing, win people over by competing with a better product.

I’m interested to see if Cloudposse has any thoughts on OpenTF or intends to back it.

Lots more folks pledging support, checking the prs… https://github.com/opentffoundation/manifesto

Pledging is free. Efforts on the long run is another.

Of course, its just getting started. The future is unwritten. There was a previous version where several companies were also committing 1 or more engineers for 5 years. I believe that commitment still holds, since they removed it only because they didn’t want to deter folks from pledging who weren’t comfortable with a commitment. Check the prs

The future hasn’t been written, but the BSL change is a bad sign for how HashiCorp is doing as a company. If you make money doing Terraform consulting and the creator is desperately trying to strange money from people, well… put two and two together.

Yep, cloud posse on the list… https://github.com/opentffoundation/manifesto/pull/73

With Hashicorp’s innovation, other companies may not have the same great features for I always learned from their CTO’s speeches, just feel pity/shameful that their CTO may not be that great without the spot light of open source projects, for there will be no next Terraform any more

sorry for spamming, sent a wrong place at the first time..

Ironicly there may be some legal ambiguity for Hashicorp’s BSL change as Terragrunt founder pointed out.

Oh wow, that's a very good point on the CLA language! I wonder if that invalidates this license change? At least for external contributions?
...

Might be worth checking with a lawyer...

https://www.reddit.com/r/Terraform/comments/15rtieg/comment/jwf8qap/?utm_source=reddit&utm_medium=web2x&context=3&rdt=60848

@marcinw in case you folks have the resources to see if the CLA wording and the pledge can change Hashi’s mind .. just saying

We have our legal looking at it today.

TFC is the way Hashicorp make money to fund TF That’s an interesting take. Perhaps a few numbers worth considering though:

• the revenue made from TFC/TFE;

• the maintenance and development cost of core Terraform;

• the value of unpaid work (outside contributions) that went into the above from non-Hashi folks to whom the CLA promised FOSS forever;

• the value of unpaid work on the ecosystem (providers, modules, tutorials, linters, etc.)

• the marketing value from running as FOSS;

• the value of open source projects that they build on;

considering the complexity of open source license, and oversight from lawyers… it may happen 20 years ago, but not sure it will be the case for now

• tflint for linting

• tfsort for sorting

if you like them, please give stars

thanks! I didn’t realize tflint could check for missing variable descriptions

and will check out tfsort, didn’t know about that

it can

tflint configuration set to all https://github.com/terraform-linters/tflint-ruleset-terraform/blob/v0.2.0/docs/configuration.md

perfect, thanks! Just used tfsort as well and it was exactly what I needed. It’s missing from this list https://github.com/shuaibiyy/awesome-terraform

you can check my star list here https://github.com/stars/mhmdio/lists/terraform-helpers in case you are missing something

I just test tflint with variable description

Notice: `app_fqdn` output has no description (terraform_documented_outputs)

  on outputs.tf line 29:
  29: output "app_fqdn" {

Reference: <https://github.com/terraform-linters/tflint-ruleset-terraform/blob/v0.4.0/docs/rules/terraform_documented_outputs.md>

ahh cool thank you! saved me a lot of time I wasn’t using the “all” preset, just “recommended”

That’s a great list @Mohammed Yahya

Thanks @Mohamed Naseer

thanks for the fix. approved and merged

https://github.com/cloudposse/terraform-aws-firewall-manager/releases/tag/0.4.1

Thanks

Dependabot is great. But be sure provider upgrades are worth doing. IMO, provider upgrades aren’t useful because they only contain new features. It’s less work to upgrade providers on demand then to review dependabot PRs every Monday morning forever

I was looking at this the other day - https://github.com/minamijoyo/tfupdate

because they only contain new features this is false. new features are around 30 or less of regular terraform provider release notes

less work to upgrade providers on demand in my experience it’s contrary. it requires major PITA to upgrade providers if current provider is year or more old

i prefer regular frequent updates with small changes that easy to track and verify

My experience has been AWS provider fixes are very rarely things we update for. And the only upgrades with any upgrade pain have been the few major version bumps

I’m looking forward to the upcoming “groups” feature in dependabot to combine updates of different dependencies but within the same language. Should reduce the pr burden. I also like to set a monthly schedule, weekly was definitely too much

i believe you can do all that already

Schedule yes, groups only if you’ve opted into the feature currently in beta

Oh it’s public beta now, with some new options behind another private beta… https://github.com/dependabot/dependabot-core/issues/1190#issuecomment-1623832701

Does your module/resource jsonencode it?

I’ve solved it actually the module has some errors when jsonencoding it so I’ve removed the json encoding in the module and do not use a hcl map. This down belowed work for me when you change event_pattern = jsonencode(var.cloudwatch_event_rule_pattern) to this event_pattern = var.cloudwatch_event_rule_pattern

I’ve just opened an issue concerning this bug https://github.com/gruntwork-io/terragrunt/issues/2782

@Jeremy G (Cloud Posse) @Andriy Knysh (Cloud Posse)

eksctl is a separate tool and not compatible with Terraform. They are 2 different ways of managing a cluster.

@Max Lobur (Cloud Posse) @Zinovii Dmytriv (Cloud Posse)

1. try switching from map to lists

      ec2_config = [
        {
          name = "vm1" 
          instance_type    = "m6i.xlarge"
          root_volume_size = "32"
          data_volume_size = "200"
        },
        {
          name = "vm2
          instance_type    = "m6i.2xlarge"
          root_volume_size = "32"
          data_volume_size = "500"
        }
   

1. try creating a module that represents 1 object (vm, volume) -> getting a module that represents 1 group of related objects (vm+ip+volume = tenant) -> iterate that for multiple tenants

1. try grouping related vars, if elastic IP is used by a VM it may be easier to just put int inside vm object map

After much banging my head on my desk, that’s kinda where I arrived to.

locals {
  tenant_config = {
    tenant1 = {
      vm1 = {
        instance_type    = "m6i.xlarge"
        data_volume_size = "200"
        elastic_ips      = ["x.x.x.x"]
      }
    },
    tenant2 = {
      vm1 = {
        instance_type    = "m6i.xlarge"
        data_volume_size = "200"
        elastic_ips      = ["x.x.x.x"]
      }
    },
    tenant3 = {
      vm1 = {
        instance_type    = "m6i.xlarge"
        data_volume_size = "200"
      },
      vm2 = {
        instance_type    = "m6i.xlarge"
        data_volume_size = "200"
        elastic_ips      = ["x.x.x.x"]
      },
      vm3 = {
        instance_type    = "m6i.xlarge"
        data_volume_size = "200"
        elastic_ips      = ["x.x.x.x"]
      },
      wm4 = {
        instance_type    = "m6i.xlarge"
        data_volume_size = "200"
        elastic_ips      = ["x.x.x.x"]
      }
    },
    tenant4 = {
      vm1 = {
        instance_type    = "m6i.xlarge"
        data_volume_size = "200"
      },
      vm2 = {
        instance_type    = "m6i.xlarge"
        data_volume_size = "200"
        elastic_ips      = ["x.x.x.x"]
      },
      vm4 = {
        instance_type    = "m6i.xlarge"
        data_volume_size = "200"
        elastic_ips      = ["x.x.x.x"]
      }
    }
  }
}

Then building a module which takes that information and builds everything required for that tenant.

looks good

vm does not need to be a key, since you just iterating it. Just make it a list of VMs where vm name is just a field

Well, I’m using that to build additional locals within the module.

ah I see

I’ll eventually rework tenant config slightly to go from a local to an actual variable (because these could be different in a dev vs prod environment) so I can leverage workspaces to select the right set of values.

The pricing model has been pretty stable. It’s changed twice in a few years iirc

I’m not exactly sure of times, but TF Enterprise is licensed by number of workspaces and has been for awhile. I think originally there was just a platform price.

TF Cloud has changed a little bit. It started off with workspaces, then moved to successful applies. And just recently changed to Resources Under Management (RUM).

There’s a lot of work in the background with sales teams and licensing to ensure that migrations to new licensing schemes don’t have shocking financial issues for customers. If you get a significant change in price (for the worse, nobody complains about paying less), definitely work with your sales team on this.

And while not an official HC messaging, one thing I’ve noticed about these updates is that they’re not arbitrary and certainly not quick. RUM has been something I’ve heard discussed for years and it was originally shot down.

Hashicorp also seem to have clarified the definition of embedded to include all TACOS, initially some like digger thought they’d be exempt.

No VC would give any money to someone beholden to regular price hikes by Hashicorp (e.g. if they went private (PE owns 30% of the company)), so it is existential for them.

https://www.hashicorp.com/blog/hashicorp-updates-licensing-faq-based-on-community-questions

Q: What does the term "embedded" mean under the HashiCorp BSL license?

A: Under the HashiCorp BSL license, the term "embedded" means including the source code or object code, including executable binaries, from a HashiCorp product in a competitive product. "Embedded" also means packaging the competitive product in such a way that the HashiCorp product must be accessed or downloaded for the competitive product to operate.

interesting, GCP just dropped their own first-party TACO. Hashicorp are still speaking at Cloud Next, so I wonder has Hashicorp already got long-term sweeheart deals with the hyperscalers?

https://cloud.google.com/infrastructure-manager/docs/overview

added <i class="em em-opentf"></i>

Ya haven’t seen more than normal in my news feed

Gruntworks have a great overview of the Iac tools which you may have seen. Obviously biased, but his point that there’s no responsible way to use Pulumi open source in production is worth considering.

You can switch to other supported backends for state storage, such as Amazon S3, Azure Blob Storage, or Google Cloud Storage, but the Pulumi backend documentation explains that only Pulumi Service supports transactional checkpointing (for fault tolerance and recovery), concurrent state locking (to prevent corrupting your infrastructure state in a team environment), and encrypted state in transit and at rest. In my opinion, without these features, it's not practical to use Pulumi in any sort of production environment (i.e., with more than one developer), so if you're going to use Pulumi, you more or less have to pay for Pulumi Service.

https://blog.gruntwork.io/why-we-use-terraform-and-not-chef-puppet-ansible-saltstack-or-cloudformation-7989dad2865c

It looks like S3 supports state locking but this isn’t documented: https://github.com/pulumi/pulumi-hugo/issues/1448 I guess there is almost zero appeal in moving to another tool if the cynical take in that pr is right. (It’s not documented so that people use pulumi cloud more.)

You can answer these questions by looking at the repository.

I would say that SI looks a little immature, and also not a direct replacement for Terraform in the same way pulumi is

thought a small example would help to understand more about how SI can do

I don’t read it that way. The fact they’re anticipating taking current infrastructure and importing it into SI is pretty telling.

others may see it in a quite different way, this would be a scary part for many project owners tbh

cc @Matt Calhoun

I don’t know of any packages, per se. I was a former maintainer of terratest and terragrunt and now work with atmos and if you look at how some of those tools do it, they are all wrapping exec.Commandfrom the os/exec package and capturing stdin, stdout and stderr. The easiest example to follow is definitely in terratest source code.

Apparently this is the library hashicorp provides now pre v1.0.0

A Go module for constructing and running Terraform CLI commands. Structured return values use the data types defined in terraform-json. License type: hashicorp/terraform-exec is licensed under the Mozilla Public License 2.0

I think OpenTF should pool some money and poach apparentlymart from HC

imagine if he leaves HC and creates a fork!!!!!, lets not even go there….bad idea bad idea…

Probably they can afford one or two superstars and then a few journeymen.

https://news.ycombinator.com/item?id=37263022

Marcin here, co-founder of Spacelift, one of the members of the OpenTF initiative

We provided a dedicated team on a temporary basis. Once the project is in the foundation, we will make a financial contribution, with which dedicated developers will be funded. At that point our devs will gradually hand over to the new, fully independent team. The other members of the initiative so far follow the same pattern but I can't speak on their behalf re: exact commitments

can use an environment var like TF_VAR_collect_list

and pass it into the template file,

may also need join or split functions

thanks, lemme mess with it…

https://developer.hashicorp.com/terraform/cli/config/environment-variables#tf_var_name

I was inspired by Kelsey and he is right

Hi @Michael Lee Did the new thread suggestions solve the issue? https://sweetops.slack.com/archives/CB6GHNLG0/p1693230062027589

Hi, thanks for the reply. Unfortunately no, the issue still present.

Hi, has anyone faced the same issue? below is my script for eb provisioning

module "vpc" {
  source  = "cloudposse/vpc/aws"
  version = "2.1.0"

  ipv4_primary_cidr_block = "172.16.0.0/16"

  context = module.this.context
}

module "subnets" {
  source  = "cloudposse/dynamic-subnets/aws"
  version = "2.4.1"

  availability_zones   = var.availability_zones
  vpc_id               = module.vpc.vpc_id
  igw_id               = [module.vpc.igw_id]
  ipv4_enabled         = true
  ipv4_cidr_block      = [module.vpc.vpc_cidr_block]
  nat_gateway_enabled  = true
  nat_instance_enabled = false

  context = module.this.context
}

module "elastic_beanstalk_application" {
  source  = "cloudposse/elastic-beanstalk-application/aws"
  version = "0.11.1"

  description = "EB app for ${var.app_name}"

  context = module.this.context
}

module "elastic_beanstalk_environment" {
  source  = "cloudposse/elastic-beanstalk-environment/aws"
  version = "0.51.1"

  description                = "EB env for ${var.app_name}"
  region                     = var.region
  availability_zone_selector = var.availability_zone_selector
  dns_zone_id                = var.dns_zone_id

  wait_for_ready_timeout             = var.wait_for_ready_timeout
  elastic_beanstalk_application_name = module.elastic_beanstalk_application.elastic_beanstalk_application_name
  environment_type                   = var.environment_type
  loadbalancer_type                  = var.loadbalancer_type
  tier                               = var.tier
  version_label                      = var.version_label
  force_destroy                      = var.force_destroy

  instance_type    = var.instance_type
  root_volume_size = var.root_volume_size
  root_volume_type = var.root_volume_type

  autoscale_min             = var.autoscale_min
  autoscale_max             = var.autoscale_max
  autoscale_measure_name    = var.autoscale_measure_name
  autoscale_statistic       = var.autoscale_statistic
  autoscale_unit            = var.autoscale_unit
  autoscale_lower_bound     = var.autoscale_lower_bound
  autoscale_lower_increment = var.autoscale_lower_increment
  autoscale_upper_bound     = var.autoscale_upper_bound
  autoscale_upper_increment = var.autoscale_upper_increment

  vpc_id                              = module.vpc.vpc_id
  application_subnets                 = module.subnets.private_subnet_ids
  loadbalancer_subnets                = module.subnets.public_subnet_ids
  loadbalancer_redirect_http_to_https = true
  loadbalancer_certificate_arn        = var.loadbalancer_certificate_arn
  loadbalancer_ssl_policy             = var.loadbalancer_ssl_policy

  allow_all_egress = true

  additional_security_group_rules = [
    {
      type                     = "ingress"
      from_port                = 0
      to_port                  = 65535
      protocol                 = "-1"
      source_security_group_id = module.vpc.vpc_default_security_group_id
      description              = "Allow all inbound traffic from trusted Security Groups"
    },
    {
      type                     = "ingress"
      from_port                = 3306
      to_port                  = 3306
      protocol                 = "-1"
      source_security_group_id = "sg-07ddd9db717161661"
      description              = "Allow MYSQL inbound traffic from trusted Security Groups"
    }
  ]

  rolling_update_enabled  = var.rolling_update_enabled
  rolling_update_type     = var.rolling_update_type
  updating_min_in_service = var.updating_min_in_service
  updating_max_batch      = var.updating_max_batch

  healthcheck_url  = var.healthcheck_url
  application_port = var.application_port

  solution_stack_name = var.solution_stack_name

  additional_settings = var.additional_settings
  env_vars            = var.env_vars

  extended_ec2_policy_document = data.aws_iam_policy_document.minimal_s3_permissions.json
  prefer_legacy_ssm_policy     = false
  prefer_legacy_service_policy = false
  scheduled_actions            = var.scheduled_actions

  s3_bucket_versioning_enabled = var.s3_bucket_versioning_enabled
  enable_loadbalancer_logs     = var.enable_loadbalancer_logs

  context = module.this.context
}

Can you paste the full (masked) contents of your main.tf

need to add data “aws_caller_identity” “current” {}

@Segun Olaiya data “aws_partition” “current” {}

locals { enabled = module.this.enabled policy_name_inside = “${module.label.id}-inside”

policy_arn_prefix = format(
"arn<i class="em em-%s"></i>iam:policy",
join("", data.aws_partition.current.*.partition),
join("", data.aws_caller_identity.current.*.account_id),   )   policy_arn_inside = format("%s/%s", local.policy_arn_prefix, local.policy_name_inside)   policy_json = jsonencode({
Version = "2012-10-17"
Statement = [
  {
    Action = [
      "ec2:Describe*",
    ]
    Effect   = "Allow"
    Resource = "*"
  },
]   }) }

module “lambda” { source = “cloudposse/lambda-function/aws” version = “0.5.1”

filename = var.filename function_name = var.function_name handler = var.handler runtime = var.runtime cloudwatch_lambda_insights_enabled = var.cloudwatch_lambda_insights_enabled cloudwatch_logs_retention_in_days = var.cloudwatch_logs_retention_in_days iam_policy_description = var.iam_policy_description

custom_iam_policy_arns = [
"arn<img src="/assets/images/custom_emojis/aws.png" alt="aws" class="em em--custom-icon em-aws">iam:policy/job-function/ViewOnlyAccess",
local.policy_arn_inside,

]

}

@Hao Wang: I have added data partition still does not work

@Hao Wang Thanks for your right pointer , after adding caller identity resolved. But now its new error

│ Error: Reference to undeclared module │ │ on main.tf line 6, in locals: │ 6: policy_name_inside = “${module.label.id}-inside” │ │ No module call named “label” is declared in the root module.

oh guessing you may need to find the original reference which lead you to this rabbit hole lol

There are cloudposse modules for both these things, have you checked them for examples?

Yep! all our modules have an examples/ subfolder with a working example

Thanks for the reply. I will have a look at rds and elasticache example.

https://sweetops.slack.com/archives/CB6GHNLG0/p1693398023635929?thread_ts=1693033151.692939&cid=CB6GHNLG0

may be related to the question https://github.com/ugns/terraform-aws-route53-dnssec/blob/main/main.tf#L26C11-L26C38

This guy needs a big hug

So angry!

Oh, I absolutely need all the hugs, kisses, and cuddles — that’s my love language!

But this wasn’t that. Nononono

I find it offending when OpenTF spreads misinformation and I find it absolutely disgusting when a bunch of trusted tech leaders praised OpenTF as “a beacon of open-source success” without doing any due diligence.

You’re entitled to your opinion.

Just a note that there are real people on the other side of the receiving end of your writing, folks you may stumble upon at meetups, conferences etc.

And I would say the same thing to people’s faces. This is a major failure and a breach of trust! I certainly expected more from Spacelift

I would say the same thing to people’s faces Really looking forward to being called a moron and an imbecile in person

I did not criticize individuals, I criticized actions! There is a difference.

This is a fine line to tread.

Re: actions. Hopefully in a few weeks time you will be able to appreciate the motivations.

In the meantime please remember that the people whose actions you comment on, folks whose words you misrepresent, they are members of the same community, and sooner or later you will need to look them in the eye.

Over and out, have a nice day Sir!

A panel discussion hosted by SweetOps could be a good idea perhaps?

@Pawel Rein please let our actions over the next few weeks speak for themselves. There is a lot happening behind the scenes, and personally I am not willing to get into a battle of ad hominems.

I look forward to being proven wrong and I am genuinely hoping that will happen. HashiCorp does need a kick in the butt and OpenTF could be that.

At the same time, I will keep trying to criticize actions and not individuals. I don’t want to hurt people.

Let’s have a deal @Vlad Ionescu (he/him). Let’s have a few pints in 3 months. If you’re right, drinks are on me. If not, they’re on you. How’s that?

Deal @marcinw!

In the meantime, you badly misrepresented the words of one of my colleagues here.

Spacelift currently provides a number of employees (way more than 5). But one thing we want to avoid is have a bunch of alternative vendors be in charge of something that’s a public good.

Which is why we believe that it’s in the interest of the community to have a dedicated team of folks who do not ultimately report to one of the vendors, and whose work is in the interest of the community.

You may or may not like this approach, but it hurtful to a real human on the other side of it to be called a liar.

A panel discussion hosted by SweetOps could be a good idea perhaps? is not a good idea imo, not at this point in time. Once the regular calls start to be put in place then this sort of conversation could take place.

Until then the tone should be kept within some common sense boundaries to give time for folks who had the courage to embark into this initiative to get the wheels in motion.

I’m sure folks who managed to secure funds and build / start a business have done their due diligence in terms of $ and i’m also sure they are aware of the effort required to fund an open-source project - see K8s and the cost of running Prow and how much Google funded CNCF.

In closure, i’d like to believe that the strong language used by Vlad (even criticising the actions and not individuals) is maybe due to his latin roots and i think more restrain should be used in public ..a word/ phrase written sometimes can be twisted in many ways and could have a negative impact.

@marcinw I very much agree with the approach, I just don’t see how it would work. CNCF does not hire developers to work on projects. OpenTF creating a new foundation means a lot of money spent on lawyers, IP, admin, etc. Is there a third alternative I am missing?

Yes. But doing big things for real takes time and effort. Having to deal in the meantime with online aggression and misinterpretations does not help.

Can you expand on what that alternative is?

I am happy to delete the posting or to add a reply with “I was wrong about this because X” (I’d rather delete it tho cause people don’t usually read replies and I don’t wanna spread lies) but I need to see a realistic plan first or even just an outline.

Patience, please.

Things will fall into place eventually, I promise.

As an aside, this is the problem with everybody doing communication and PR. Incomplete information gets twisted and we all end up worse

I look forward to them falling into place and I hope you’ll succeed, but I can’t delete that post until Spacelift clarifies how funding OpenTF will work.

I am happy to jump on an off-the-record Zoom to chat about this too if you want.

everybody doing communication and PR For sure. That’s how spontaneous initiatives work though.
on an off-the-record Zoom I am sure you will understand that based on your recent writing it would be highly risky for me to discuss anything off-the-record

I get it.

Would you be on with me adding a reply to that Tweet saying something like “Spacelift allegedly has a concrete and realistic plan for how funding will work that’ll be released in a few weeks. I look forward to seeing that!” ?

Again, I don’t want to spread misinformation but I can’t just delete that based on “yes we have a plan”

(I am happy to hear alternative wordings of that message)

No @Vlad Ionescu (he/him), this is your opinion, your writing, and ultimately your responsibility to whatever guides your moral code.

I respect your right to have opinions, theories, assumptions etc. I would just like you to not hurt real people.

And if you actually care about the cause, please give us time, don’t add your writing to a list of challenges But again, this is your choice, and in 3 months you can call me a clown all you want.

Ok, I won’t add any reply to that tweet then.

I am not planning any other writing, so no worries there!

I do have an ask though: can OpenTF please consolidate communication and postings? Having fragments of information posted by everybody involved only leads to bad situations like these and further hurts OpenTF

Valid point, work in progress!

Does anyone have a read on how the big three cloud providers are evaluating it internally? GCP in particular just launched a (basic) TACO and are known to have Hashicorp employees embedded in the company to help with Terraform. Are they waiting to see before expressing an opinion or have they already decided to stick with Terraform?

The cloud providers are generally contributing to the terraform providers (not terraform core), and the terraform providers are unaffected by the license change. so i believe the intent is for opentf to continue using the hashicorp terraform providers. essentially, that layer of the design would be unchanged, with no impact to users of either hashi terraform or opentf

The cloud providers also have Business Development contracts with HashiCorp. It’s a whole different discussion

@Vlad Ionescu (he/him) do not have kids, otherwise you will be complaining that they can’t walk in the first 2 weeks

If nobody is posting a negative take, do it yourself to get attention. When called on toxic behaviour, double down. You weren’t calling people dumb-fucks, but “actions”! When mistakes are pointed out, refuse to apologise, claim the true error is with “incomplete information”.

my 2 cents, sorry, we have to move from Hashicorp

@marcinw I owe you at least 1 drink! You are doing funding though the Linux Foundation (not through the CNCF) and I was wrong on that

(or I assume that’s what you’ll do based on the LF acceptance)

Let’s wait some more time, I mean to collect all the drinks @Vlad Ionescu (he/him)

not too shabby, $425m total raised and last valued at $3.7bn.

See discussion here https://www.linkedin.com/posts/osterman_terraform-registry-activity-7102670109948743680-ReJ1?utm_source=share&utm_medium=member_ios

He’s a co-founder and that’s very unlikely. His whiteboards are excellent though.

maybe only one of co-founders can live thru the capital wars, seems HashiCorp is talking to giant companies, and sold itself before going downturn like Docker, may happen in 6 months to a couple of years

I’m in no way suggesting this is going to happen, but I could potentially see Mitchell leaving. I also don’t think it’s going to happen as the company is named after him and he’s doing what he loves, but you never know.

As for whether HashiCorp remains an independent entity…time will tell. I know there’s been a handful of offers over the years, and here we are.

I sometimes think people forget we have more products than Terraform, and Vault is a major player in the industry. I came here after running Consul for years and that’s everywhere (though very few folks talk about it). Heck, Nomad is getting traction these days.

As for “capital wars”…not really sure what that means. HashiCorp is a public company, it’s not a non-profit. Unless run by a state or a non-profit, every company is capitalist. You either make money and profit and survive or die or get sold off.

I think people forget about the other products because nobody (even Hashicorp) have a convincing monetization strategy

Mitchell is also great presenter, oh yeah, I almost forgot his role changed a couple of years back

These people who can present and write codes are geniuses

Well, that’s clearly not true Alex.

Hey - what happened to hashicorp/terraform? I’ve been reading about replacements and that something has happened but I don’t know what exactly happened, can you share an informative link?

The licenses of Hashicorp open source projects (maybe just Terraform or all) got updates and will adopt biz license which will restrict competitors to use their products

Competitiors only ? What about companies who just use it ofr IaaS… go back to Puppet/Ansible/Cloudformation ?

Hsshicorp said no impacts on the end users

Nomad is a great product and getting more attentions recently years even under k8s shadow, but the future of nomad is clear now, like Docker Swam…

oh is Terragrunt taken as a competitor by new license?

Any suggestions on this please?

it clearly says this permission is missing on the service account iam.serviceAccounts.getAccessToken