While I wish things were different and we could just return to a “status quo”, I am optimistic that this will be the best for everyone. HashiCorp can focus on better serving enterprises without the weight of open source, while the open source community can get behind a fork and better drive the product forward in a direction that benefits alternative usages.

Everyone is entitled to their opinions and causes, but I’d challenge you to name one company affected by the license change that isn’t backed by venture capital.

There are no openVault/Consul/Nomad/Boundary/Waypoint/Vagrant projects because nobody else (aside from one firm that won’t admit it) has built businesses on any of the rest of those technologies (well, Nomad does have some folks, but they haven’t spoken up).

I think one of the key differences though is that terraform is more like an “interpreted language” built on HCL. It’s akin to ruby, perl, php. So companies have built businesses using this language. Vault, Consul, Nomad, Boundary, and Waypoint are all “services”. In fact, Terraform Enterprise is a service. If Terraform Enterprise was formerly “open source” and then moved to “BUSL”, I would understand. But moving the language to BUSL is my personal contention.

It’s a good point Erik. And one of my major thought exercises is: at what level of abstraction should someone be able to draw a line between open and commercial products. Especially those built on lots of other OSS products.

I actually think OSS needs a rethink in general when it comes to recognizing contributions for the entire software supply chain, but that’s a very different conversation altogether.

Strongly agree with Erik. I’d go a bit further, and say that the BUSL changes makes no sense for client applications. E.g. terraform, packer, vagrant. For the applications with a server component, sure, absolutely reasonable. E.g. vault, consul, nomad, etc.

Every user of Terraform is at least indirectly affected by the license change and the recent registry T&C shenanigans. Good many folks who do not use Terraform are affected, too.

That is why after I thought it over, I want to voice out and fight it, actually it is not just me having the same thoughts I believe, I just saw the trend again, which is similar to when Oracle acquired SUN(MySQL), and then Postgres became more and more popular. But that took a while. This time we can make the transition faster Lol

That’s essentially what OpenTF is about - keeping the legacy of Terraform alive and useful for years to come, regardless of the fate of the original project.

considering to introduce Rust? lol

For providers - why not.

For the core… IDK, not sure about the cost-benefit ratio of a rewrite.

wow this is good, the agreement in provider realm is not clear to me, introducing Rust may get more attentions from developers

I can’t speak on behalf of the OpenTF project, just my own here, but I’d support spinning off some parts of Terraform into plugins (eg. backends).

DevOps/SRE may become more friendly for Rust developers

I think it would be less about Rust or any other language, more about making plugin development language-agnostic.

Theoretically you could write a Terraform provider in anything you want, but the process is not well defined, and there are no libraries or examples to help you get started.

yeah, English is the best programming language, the goal

Even though under the hood it’s just gRPC.

to my understandings, the time-consuming part is the provider APIs and also uncertain part since backend service is so unpredictable

The difficulty of it all is greatly exaggerated TBH.

feel the same

I contributed a few issues in TF before, and tried to write a custom provider, the framework is kinda easy to work with

As Spacelift we’re hoping to organize regular hackathons to help community members learn the core concepts through hacking on small features, and get productive in the codebase.

We’ll test the idea internally in 2 weeks, if it’s successful we’ll try an open one, too.

golang codes are easy to understand but not easy to work with, especially modules lol

cool

with some easy tutorials to follow with please

I feel TF was becoming difficult to get into for entry level golang dev, hope there are better tutorials for them

Yes, it’s not an entry level codebase. But it’s not crazy either.

how-to contribution , how-to troubleshooting, etc.

https://docs.crossplane.io/knowledge-base/integrations/argo-cd-crossplane/

Lol I promise I didn’t find this post before

etcd concern of it, it is owned by another giant …

Well, I’d say if folks are just using Consul for K/V, moving to something like Etcd or Zookeeper is a good idea in the long run. Consul focus is more Service Discovery/Mesh these days along with integrations to Terraform for automating physical device updates.

owned by another giant etcd is a CNCF project.

It’s often used for service discovery, not just a K/V store though obviously service discovery is a K/V problem.

For service mesh you have Istio, another CNCF project.

got it, CNCF project

Honestly, it depends on the part of Vault you need. Most of Vault exists in cloud providers today, we offer some additional pieces already, and there are other providers out there that offer the last part as well. I’m definitely on the side of I don’t understand why people are still using it.

One common API, one management model, and a massive amount of identity mappings. And it works at massive scale. Dynamic (JIT) secrets, Dynamic cloud credentials, simplified PKI, format and non-format preserving encryption (at massive scale) with key material kept in Vault, Bring Your Own Key KMS across all cloud providers, TDE…

That is why Vault is so critical for it works closely with cloud providers who are reluctant to stand up, not like what happened when Elastic changed ELK license AWS was annoyed

Vault is a pretty good product and is hard to beat, but some companies go to Vault because they hear about it ,but in reality many of them could just use almost free services from their cloud providers and a good secret strategy and they will be fine with just that, but , for more complicated workloads Vault is a good choice. The problem I had with Vault is the sales team wanted to charge me 2M a year for 1 prod Vault cluster…..and since then they have been trying to get back into the company and sell more products with no luck

There is a big disconnect between use cases in some places. Many folks just need K/V and nothing else. For which something like Parameter Store or Secrets Manager are good alternatives.

Vault Secrets is in beta now, and I think will be a better fit for simpler use cases:

https://developer.hashicorp.com/hcp/docs/vault-secrets

For a SaaS vendor, there is AKEYLESS And as mentioned above all cloud providers have a solution as well, AWS Secret Manager, AWS KMS, AWS Parameter Store, GCP Secrets Manager, and Azure Key Vault.

There’s also https://infisical.com/

cool, https://infisical.com/infisical-vs-hashicorp-vault

Infisical is to Vault Enterprise what Spacelift is to TFE/TFC

awesome, found its repo here, https://github.com/Infisical/infisical

https://blog.gruntwork.io/the-future-of-terraform-must-be-open-ab0b9ba65bca

Thanks, Open source version attempts normally are hard to excel the original ones, that is the reason I feel we need alternatives :)

stop adopting new features and migrate to alternatives

Atlantis?

I wrote this a while back, it’s been pretty much what we needed most of the time: https://gist.github.com/wparad/ea473f573a420134cb12dbac0e2184a9

https://github.com/dflook/terraform-github-actions

Thanks im testing atlantis seems intersting (we are using terragrunt(

from https://github.com/bottlerocket-os/bottlerocket

Wait wha?

you may need mkdir -p?

There are 24 open issues, 125 closed ones

This is snippet of the code with some comments:

provider "aws" {
  region = var.region
}

data "aws_vpc" "vpc" {
  filter {
    name   = "tag:Name"
    values = ["${var.namespace}-${var.environment}"]
  }
}

provider "aws" {
  alias  = "eu-west-1"
  region = "eu-west-1"
}

data "aws_vpc" "vpc_vpn" {
  provider = aws.eu-west-1
  id       = "vpc-my-fancy-vpc-id"
}

module "vpn_cluster_vpc_peering" {
  source  = "cloudposse/vpc-peering-multi-account/aws"
  version = "0.19.1"

  # condition
  enabled = contains(var.peering_map[var.environment], data.aws_vpc.vpc_vpn.id)

  name = module.label.id
  tags = merge(local.tags, { Name = "VPN => ${module.label.id}" })

  namespace   = var.namespace
  attributes  = var.attributes
  environment = var.environment

  # role created via cloudposse/iam-role/aws
  requester_aws_assume_role_arn             = module.vpc_peering_multi_region_role.arn
  requester_vpc_id                          = data.aws_vpc.vpc_vpn.id
  requester_allow_remote_vpc_dns_resolution = false
  # hardcoded because it is not working anyways.
  requester_region                          = "eu-west-1"

  # same role as for requester
  accepter_aws_assume_role_arn = module.vpc_peering_multi_region_role.arn
  accepter_vpc_id              = data.aws_vpc.vpc.id
  # region is setup in a tfvars file. In this case it is "eu-central-1"
  accepter_region              = var.region

}

How can this be fixed?

I raised a PR that fixes the issue for me. https://github.com/cloudposse/terraform-aws-vpc-peering-multi-account/pull/78

@Dan Miller (Cloud Posse)

the vpc-peering-multi-account module does support cross region peering. See requester_region and accepter_region

For example, see our component for vpc-peering https://docs.cloudposse.com/components/library/aws/vpc-peering/

vpc-peering-multi-account does support it, but failed with the requester subnets. Thus the PR. vpc-peering does not support peering between multiple region as far as I can tell.

also this module did not create default routes in the requestes routing table. fixed it today in the same PR.

Any chance someone can look into this? @Dan Miller (Cloud Posse)?

@Dan Miller (Cloud Posse), @Gabriela Campana (Cloud Posse) You were the only ones replying to this thread. Can anyone have a look at the PR?

Yes apologies for the delay @Vitali I’ll ping our team and we’ll review

Thank you!

pipeline was failing, I just ran fmt and the make parts to fix validate .

this PR depends on the upgrade to support Terraform AWS Provider v5, which we have here: https://github.com/cloudposse/terraform-aws-vpc-peering-multi-account/pull/74

I’ll ask the team to prioritize this module

Thanks.

@Dan Miller (Cloud Posse), the PR has been merged already. Is there a chance you can check the other PR now?

Hi @Vitali Daniel is on vacation until next week.

I will see if any one else at Cloud Posse can check the other PR now

could you show us your terragrunt.hcl file ?

Sure. Here is a snippet

It worked when I referenced a local copy of the permission set submodule.

I guess I’m just committing a mistake in the way I set the source.

yes, shared modules like permission-sets are not supposed to be used directly in terragrunt. See https://terragrunt.gruntwork.io/docs/reference/config-blocks-and-attributes/#a-note-about-using-modules-from-the-registry for the explanation.

ok, thank you

although, it created the resources

using the local copy of the submodule

I wonder why it does not detect any changes if I run the gitlab repo as a source

You should check the content of .terragrunt-cache. See what was copied in both cases.

thanks for the tip

All chnages are detected and applied correctly after referencing to the submodule in that format

This is a bit of a meta comment, but it’s generally recommended to use cloudfront in front of an S3 bucket for reading rather than allowing people to access the bucket directly.

@Gabriela Campana (Cloud Posse)

@Elad Levi Please see comments

Hi @Gabriela Campana (Cloud Posse) Just did what @Andriy Knysh (Cloud Posse) asked.

@Elad Levi Andriy made more comments

I have seen AFT and is a big of a monster with all this step functions and lambdas and such

and in this client I will not need to create accounts all the time

i don’t really see a huge value to AFT. creating an account is a single, one-time call to the org:CreateAccount api. i just use the aws-cli instead

AFT is a lot of complexity for so little value

yes it is a lot of stuff just to create accounts with sso and such

SSO is another story. tons of customization required to get it into shape for any given environment/customer. hard to see any one-size-fits-all module really working out

I’m using gsuite in my case

are you going to use SCIM also? gsuite has an interesting limitation where, though it can sync users, it can’t (yet) sync groups to to aws sso

https://github.com/cloudposse/terraform-aws-components/tree/main/modules/aws-ssosync

I was thinking to use that

Ahh that could work. We use okta and azure ad, so sync works natively

I set up AFT last year. It is kind of a pain. If you do it wrong, you get half set up accounts, and then it’s a pain to troubleshoot and rectify. That said, when creating several accounts, it was nice to get new accounts setup already with an IAM role for Atlantis to do the rest.

if you want another option that will create such a role and doesn’t require AFT, we have a lambda wrapped in a terraform module that uses the role provisioned by org:CreateAccount to create a role in a new account https://github.com/plus3it/terraform-aws-org-new-account-iam-role

we use that to create a role for the CI/CD system, and then use a import block in the account’s tf config to bring the role back into management. pretty easy really

ohhhhh that is cool, that is a good idea too

we’re about to start doing that import trick for backend s3/ddb configs also. simplify that bootstrap, while also managing the config “normally” with tf

you do a lookup and then an import?

Nah, no need for lookup. The import id is predictable and fixed

ohhhhh right…cool interesting

i wonder … why is that not seen as a competitor to TFC by Hashi ?

google is hitching their wagon to Hashicorp for now at least. They have jointly managed tickets for support, had a joint talk at Cloud Next, Hashicorp were on their podcast recently, and it looks like they’ll be supporting terraform for their on-prem sovereign cloud.

Unclear how much heads up google had or how long the agreements are for, I guess the real decision point would be when there’s a breaking TF change they add support for in their managed version.

Wow

“To work with Infra Manager, you should be familiar with Terraform, which is an open source tool.” sounds like they may need a new open source tool.

The concept of “data” subnets is not really suited to cloud workloads

You will probably have to roll your own implementation for this if it’s a requirement foisted upon you. If you have the power to change this requirement, I recommend doing so

dynamic-subnets can create multiple subnets per AZ. You can have a set of private subnets (for backend, database, etc.) and a set of public subnets if needed

see https://github.com/cloudposse/terraform-aws-dynamic-subnets/tree/main/examples/multiple-subnets-per-az

https://github.com/cloudposse/terraform-aws-dynamic-subnets/blob/main/examples/multiple-subnets-per-az/fixtures.us-east-2.tfvars#L13

anything more complicated than that, you can create your own module

thanks, will create my own module with two dynamic-subnets modules

Yeah we just use a bunch of the dynamic modules, i’m probably a freak here but i actually don’t like making too deep for modules. IMO terraform is more a manifest language than a functional one. If i can’t look at 1-2 files and understand what is being done it detracts from some of the niceties of iac.

I feel like there’s a habbit of making stuff super DRY but sometimes copy paste has its merits if its making it easier to see whats going on for a reviewer

Ignoring changes on the name seems fine to me. How often do you change names?

I wish Terraform had a message when ignore changes was active though, to help debugging

Your use case makes sense, although we haven’t really had to deal with it too often. Mostly, in the case of S3 buckets in which case we supply an override name for the bucket.

Ignoring changes seems reasonable.

May be local_file …

you want to expand a bit more please ?

right i see https://support.hashicorp.com/hc/en-us/articles/12319426712595-How-to-use-local-file-to-output-values-as-formatted-text

That is one way but i wonr’t be able to use the native for_each or dynamic block.

I am also looking at https://github.com/gruntwork-io/terraform-fake-modules as is an interesting idea

back in the days of Saltstack i used to have what you suggested and it was working v well since it was full j2

I believe you can use for_each this way (untested): resource local_file "test" { for_each = toset(["a","b"]) name = "file${each.key}.txt" content = "test ${each.value}" }

But you’re right about dynamic blocks.

Right, is better than console. Thx a bunch for giving me few ideas

you’re welcome

I’m not entirely sure about what you’re trying to do.

Generally if I have to do some messy hcl transformations I might break that out into a config module

Which at the end of the day is just a directory with terraform variables, locals and outputs, with no resources. To make a stateless/pure module

You can then just use a test.tfvars file or similar to test, and run the outputs through jq if you really want.

There’s tftest for python if you need something a bit more structured for handling inputs and outputs

Terraform sns_topic_subscription partially supports email https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/sns_topic_subscription.html

• protocol - (Required) Protocol to use. Valid values are: sqs, sms, lambda, firehose, and application. Protocols email, email-json, http and https are also valid but partially supported. See details below. If an aws_sns_topic_subscription uses a partially-supported protocol and the subscription is not confirmed, either through automatic confirmation or means outside of Terraform (e.g., clicking on a “Confirm Subscription” link in an email), Terraform cannot delete / unsubscribe the subscription. Attempting to destroy an unconfirmed subscription will remove the aws_sns_topic_subscription from Terraform’s state but *will not* remove the subscription from AWS. The pending_confirmation attribute provides confirmation status.

@Dan Miller (Cloud Posse) Can you point on how to set the topic name using cloudposse module

Have used name variable..but it is not working

without using context.tf

let me check

thanks for response

@Dan Miller (Cloud Posse) Thank you able to create sns topic with required name but experiencing an issue with outputs.

value = sns_topic_arn.arn

A managed resource sns_topic_arn arn has not been declared in the root module

nevermind sorted it out.

What problems or limitations do you face? What is your current level?

Many modules do this with a directory, often examples/ or tests/

Yes, @loren is correct. Modules should have an examples folder, with different examples in separate sub folders. Ideally then, terratest is also used to validate each example as part of the CI process. See Cloud Posse modules for examples

Implication s for the name of this Channel?

yay!!! OpenTofu!!

Have you also set engine version? The default version is 8

Logging also shows the request, maybe you missed it in the spam

thanks, that sounds promising! I don’t see anything like engine version in the param list. Know what it’s called offhand?

ah - found it

BINGO! Thank you Alex!!

When you use logging, consider -parallelism 1 or whatever the option is called

short answer from me: no if your usecase fits entirely in a k8 cluster then sure its an option but the subset of things that this article touches on that live inside the cluster is a really small subset of the full picture.

Law of headlines. Any question, the answer is no

since terraform constantly evolved, we used diff ways of doing that. Probably the best way now is to use the one() function

vpc_id = one(aws_vpc.default[*].id)

in short no pre-commit hook is your best bet for automatic action, or editor configuration. But honestly if its not enforced in CI its a matter of time before it gets missed.

yy currently the CI part it’s passive (no edits) for TF

I asked to check if there is something out there that we haven’t found

for up until CI will enforce them

Thanks for your answer!

Well, you can run it in CI and fail the build if it doesn’t come up with a non-diff…

what PR do you want to be reviewed and merged?

There are actually two open PRs for the same change:

• https://github.com/cloudposse/terraform-aws-ecs-container-definition/pull/168

• https://github.com/cloudposse/terraform-aws-ecs-container-definition/pull/166

Just saw that https://github.com/cloudposse/terraform-aws-ecs-container-definition/pull/166 was merged, thanks for getting that in! Will let you know if I run into other issues related to ECS service connect.

Do you mind flagging this PR for your team to review? https://github.com/cloudposse/terraform-aws-ecs-container-definition/pull/169 Looks like I’ll also need access to the appProtocol field and the previous PR updated var.container_definition but not var.port_mappings

Should I use:

AWS_PROFILE=accountOne terraform init -backend-config="profile=accountTwo"

for local run and:

AWS_ROLE_ARN=arn-from-accountOne terraform init -backend-config="role_arn=arn-from-accountTwo"

for CI ?

Use the same in both environments. In the CI you can also write AWS cli profiles to its config file

All the pieces are there to solve this and I’m failing somehow. :confused:

I did run into an issue applying the spaces module where the example code needed tweaked. Hoping this is just a tweak I can’t figure out.

@Andriy Knysh (Cloud Posse) @Matt Calhoun

the error sayas that module.root_admin_stack_config.spacelift_stacks is empty. Did you provision the root space and root admin stack first? (please review the steps here https://github.com/cloudposse/terraform-aws-components/tree/main/modules/spacelift)

@Matt Calhoun please confirm that the error is b/c the root space or root admin stack was not provisioned first

I’m under the impression from the instructions that running atmos terraform apply admin-stack -s root-gbl-spacelift is the step of provisioning the root stack? That’s what’s failing.

yes, if the first step is failing, then local.create_root_admin_stack ? keys(module.root_admin_stack_config.spacelift_stacks)[0] : null is not the correct expression when you do Spacelift cold start. @Matt Calhoun please take a look at this

@RickA in https://docs.cloudposse.com/components/library/aws/spacelift/, did you set the root_administrative variable?

I’ve attempted to set root_administrative with false (what is on the document page) and true. Thinking perhaps it’d need done manually one way and toggled the other when Spacelift is in the mix. Same error in both values.

Rick, I’m wondering if there may be a bug in the code. Do you have other admin stacks defined in the stack config (but not yet applied)? If not, there may be an issue where we are expecting to find them in stack config, but aren’t finding them, and therefore the error that you are experiencing. Also, if it helps, there is a very small repo in my personal GitHub that I used to setup the minimal use case for this and there may be some useful config in there.

I do have a config laying around that’s for an admin stack that I want the root to create.

Thanks for the link. As soon as I’m able I’ll run through things and report back.

Just a follow up on the topic to say thanks…

Matt your repo helped, appreciate it. I have a suspicion that I made mistakes in the docs examples somewhere as that response ought to have reappeared otherwise. I had different errors in the infra-live example that I found to be user error. The errors generated aren’t so helpful, but also I have no idea how we’d make them better when the issue was me putting bad/unexpected config into the yaml file.

Thanks again and have a great rest of your day/weekend.

Even without considering the for_each loop, there’s a cyclic dependency between the 2 modules. You should first try to break this one.

But its working for single certification..

Did you try adding a depends_on to the module.alb block, to see if the changes then happen in the same run ?

depends_on = [
  module.alb_security_group
]

If that works, and you’re curious, you could use terraform graph with/without the depends_on to shed some more light on it.

That did not resolve it

I don’t understand why, but the compact call is what is causing the issue

https://github.com/cloudposse/terraform-aws-alb/blob/main/main.tf#L79-L81

when that function is removed it works as expected

What if instead of module.alb_security_group, you added its egress rule alone to the security group given by module.alb.security_group_id ?

Or, my preference (and because module.alb’s SG already allows full egress) just create an ingress rule on the ECS SG, specifying source_security_group_id = module.alb.security_group_id .

What if instead of module.alb_security_group, you added its egress rule alone to the security group given by module.alb.security_group_id ? whether the egress is in the rules or rules_matrix var it doesn’t seem to matter. The issue seems to be directly with how the alb module handles the concat of the var.security_group_ids and the default group created by the module
Or, my preference (and because module.alb’s SG already allows full egress) just create an ingress rule on the ECS SG, specifying source_security_group_id = module.alb.security_group_id . I figured allowing default egress anywhere (even an lb) was not a best practice. We also restrict the ingress on the ECS service side as well.

If I did use the default security group provided with the module (var.security_group_enabled) then this might not be an issue.

I figured allowing default egress anywhere (even an lb) was not a best practice. Personally I like setting egress targets to other security groups (source_security_group_id) … precise, maintainable, and still applies defense-in-depth, but depending on the circumstances I might not mind allowing egress-anywhere (e.g. if the LB only accepted internal traffic). Maybe raise an issue on the alb module to support input egress rules (and/or the security_groups expression of course).

@Max Lobur (Cloud Posse)

Yeeep. This is reproducible.

1. Create an RDS instance with a read replica and blue-green enabled.
2. Update something that triggers b/g. IE: the CA with apply_immediately true.
3. The primary will have the new instance reflected in the state file at instances.attributes.id, ~.resource_id.
4. The read replica will not have its new ID populated in the state file, BUT does see its address and endpoint fields updated to reflect “-old1”. At this point, you have to go put in the new ID and remove -old1 from the affected fields to associate the resource with the AWS issued (bg) one.

Crud.

There’s a line in the doc linked above that mentions old instances are not deleted. This is true for the read replica, but the primary instance doesn’t get left behind. I bet this is the break point for this workflow.

I have a depends_on in the replica… I wonder if that might be the culprit. I can imagine it snagging on the update logic. Trying without.

Second thing… Blue/green makes the specified CA (rds-ca-rsa2048-g1) fall off on the AWS issued green instance, meaning it gets the default (rds-ca-2019), which is expiring and must be updated.

Here’s the issue on this one. https://github.com/hashicorp/terraform-provider-aws/issues/33702

This may be the solution I use: https://github.com/hashicorp/terraform-provider-aws/issues/5945#issuecomment-496904498

1. Provide a dummy filename for initial creation (though I don’t want to commit a .zip file to the git repo that TF is in)
2. Set a lifecycle rule to ignore s3_key when that eventually gets used.

Unfortunately the cloudposse/lambda-function/aws module doesn’t support s3_key as a lifecycle rule

Manage the resources yourself, rather than using the module. It doesn’t do anything particularly complex

Thanks, and yeah I’m coming to that same realization myself.

Atmos components are actually wrappers with some opinioned practices of fetching remote state and other things.

So if you don’t want to use atmos, you just use the wrapped terraform modules. In your case, try use https://github.com/cloudposse/terraform-aws-components/tree/1.313.0/modules/sqs-queue/modules/terraform-aws-sqs-queue

It is actually just a wrapper of stock sqs resource from AWS provider.

as you can see here https://github.com/cloudposse/terraform-aws-components/blob/1.313.0/modules/sqs-queue/modules/terraform-aws-sqs-queue/main.tf, the component/module is nothing more than a few lines of code configuring resource "aws_sqs_queue" - you can just use the same code

our terraform modules don’t require Atmos, you can use them as plain terraform https://github.com/cloudposse?q=terraform-&type=all&language=&sort=

our catalog of terraform components, on the other hand, can be configured with Atmos (but this is also not required) https://github.com/cloudposse/terraform-aws-components

Atmos allows you to separate code/implementation from configuration (in stacks). But you can use all those modules/components directly by providing all variables that they require

We’re also not getting a successful connection when we try and connect with that Cloudsmith url

welllllll…. the current bastion user-data is of the opinion to add chamber to a docker image and then have the machine pull that. It’s admittedly more steps, but I guess if you can push this to ECR and update the bastion to have permissions to pull (I guess just add it to the ECR policy however you see fit), then you could just go that way.

I’m reading that setup.rpm.sh since there’s probably still a one-off way to get it jiggered back into working order

testing this I think it works, but I did have to modify the script to do a sudo yum install -y chamber…. you might try that. But it should work well enough

if you get more issues, I’d recommend a couple ways forward. For one, cloud-init should be putting its scripts in /var/lib/cloud/instance… if you snoop around in there, you should find the scripts you need to re-run so you can see errors. If they don’t error out and chamber works when you run it from there, then the issue is deeper

you can use systemctl to look at any degraded units (you’ll probably find cloud init as one of them), and then you can inspect those logs using journalctl -xu <degraded unit name>. I could probably make a quick video showing how to diagnose this if you like. And you can always just run journalctl without any args and instead use the / command to start a search… you ought to be able to search for either chamber or yum and see helpful info there

journalctl uses a ‘vim-like’ mode, so you use the h, j, k, and l keys to move around and / to search down or ? to search up

Hey @Jeremy White (Cloud Posse) !! Thanks for looking into this for me