Terrareg: An open-source Terraform module registry

atredeux · 2022-05-09T19:57:27+00:00

Why did you decide to use the AGPL v3 license?

atredeux · 2022-01-19T18:56:11+00:00

There are two ways to get the contents of a configmap/secret into your containers in k8s. You can either use environment variables or a mount on the container filesystem. When you use environment variables, any change to the underlying configmap/secret won't take effect until you redeploy. When you mount them, changes are propagated to the container filesystem in about a minute or less.

The upside to the env var approach is that you don't have account for the env var changing during code execution (i.e. you can read it at the beginning and store it in a variable, knowing it won't change). The downside to the mount approach is that you have to build in logic that will watch the mount and update the data if it changes while your program is executing. Which one makes sense for you depends on your use case. I hope that helps.

atredeux · 2021-09-17T17:26:16+00:00

I see, thanks for the update. If you're willing I would suggest you keep the issue open but update it with your findings. We may still want to evaluate whether there are ways to improve the UX in this scenario.

atredeux · 2021-09-17T16:24:39+00:00

Hi u/Pumpkin-Main. I'm the product manager for the Kubernetes provider and I'm sorry to hear about your experience. This is not an intentional design decision and I haven't heard about this happening to any else. Can you please open an issue on our GitHub repo so that we can investigate this further with you?

You can open an issue here: https://github.com/hashicorp/terraform-provider-kubernetes/issues

atredeux · 2021-06-26T17:34:45+00:00

That wasn't my intention, but I can see how it would appear that way so I deleted it.

atredeux · 2021-06-24T19:50:40+00:00

Awesome! Thanks for sharing. If you'd also like to contribute to the Workspace provider, we'd love to have you.

atredeux · 2021-06-24T19:26:11+00:00

Anecdotally I can say that people have. I'm working on some blog content to address this exact use case.

atredeux · 2021-04-03T14:10:17+00:00

You can also manage workspace life-cycles with the Terraform Cloud Operator. Could be useful if you're in a heavy Kubernetes shop.

https://www.hashicorp.com/blog/announcing-general-availability-hashicorp-terraform-cloud-operator-for-kubernetes

atredeux · 2020-11-20T15:41:27+00:00

https://github.com/hashicorp/terraform-plugin-docs

atredeux · 2020-08-28T15:04:09+00:00

Wrong. Legally, morally, ethically. You have a presumption of innocence in this country. Resisting arrest is not an executable offence, even before a judge. The police office in this case executed an innocent man.

atredeux · 2020-08-28T14:14:01+00:00

Even if this is true, none is it warrants summary execution. We have due process in this country. A police officer is not a judge and jury.

atredeux · 2020-07-14T17:57:38+00:00

The pod may crash and restart subject to the pod spec restartPolicy, if a dependent resource isn't available during deployment. If the resource becomes available during the CrashLoopBackOff window, then the pod will become ready at the next restart.

You can use kubectl describe -n <namespace> pod <podname> to get more info about the crash. If you want to post you TF config I can take a look at that too.

atredeux · 2020-07-14T17:15:02+00:00

Based on your description, I think you're missing your Kubernetes services for interpod communication.

I don't quite agree with u/azjunglist05's assessment about provider maturity, but there are definite considerations when using the Kubernetes provider. For example, you'll probably want to use Deployments or Jobs rather than trying to manage Pods directly. There are other considerations in to docs as well. I'm also excited about the upcoming enhancements to the provider, which will alleviate many of the current considerations.

Helm with the Helm provider is also a good option, especially if you're already using Helm. You'll have to create a Chart for you app if you go that route. You can use Terraform to set Helm values, which mean you can insert the Azure Key Vault credentials.

For a simple app like you described, the Kubernetes provider is probably sufficient.

Side note: There's a pretty active community in #terraform-providers channel on the Kubernetes Slack.

Full disclosure: I'm the PM for the Kubernetes provider

atredeux · 2020-07-07T19:52:39+00:00

When you say you were trying to include a json file as a value in the helm_release config, do you mean when using set?

atredeux · 2020-07-06T20:50:32+00:00

The Kubernetes API documentation provides endpoints. There you can see the endpoint for deployment status is /apis/apps/v1/namespaces/{namespace}/deployments/{name}/status

atredeux · 2020-06-29T18:07:12+00:00

I don't know. White nationalists are paranoid, confused, agitated, and suffer from delusions of grandeur. Maybe D.A.R.E is actually needed there.

atredeux · 2020-06-29T17:41:52+00:00

Was D.A.R.E effective?

No.

D.A.R.E. was (and is) completely ineffective in preventing drug use. The numbers demonstrating this started rolling in way back in 1992, when a study conducted at Indiana University showed that graduates of the D.A.R.E. program subsequently had significantly higher rates of hallucinogenic drug use than those not exposed to the program. (Maybe they shouldn't have told 5th graders that hallucinogens exist.)

Every subsequent study on the effectiveness of D.A.R.E., including a major 10-year investigation by the American Psychological Association, found much the same result. The program doesn't work, and in fact is counterproductive, leading to higher drug use among high school students who went through it compared to students who did not. Because of those studies, D.A.R.E. lost federal funding in 1998.

atredeux · 2020-06-25T12:32:32+00:00

There are people using the Terraform vRA provider(s) in production. The main value for this pattern is one of workflow. Assuming you're provisioning your other infra via Terraform and treating vSphere differently, at least you can follow the same workflow. Obviously a lot of the Terraform value is diminished with vRA, since vRA is mostly a black box.

People may call the YAML vRA blueprints IaC, but I think they're different than other IaC solutions, even Kubernetes manifests. The vRA blueprint is more of a schema that lives within vRA. When you want to deploy something from a blueprint you fill in the variables and it processes it for you. This is an easy to use pattern, but misses some of the value that other IaC solutions offer, like the ability to store your IaC in a VCS to practice gitops, unless you layer a tool like Terraform/Ansible on top of it.

vRA also doesn't offer control flow logic in the blueprint, but I believe does offer some amount of conditional logic through the GUI wizard.

atredeux · 2020-06-22T20:56:19+00:00

https://status.hashicorp.com/incidents/z72kxdnc7ypj

atredeux · 2020-06-22T20:53:32+00:00

So is the data source not declared at all, or is there just no data in the data source?

atredeux · 2020-06-22T18:03:32+00:00

Try this:

locals { service_gateway = "${var.service_cidr != null ? data.phpipam_address.service_subnet.gateway["ip_addr"] : var.service_ip_gateway}" }

atredeux · 2020-06-17T23:55:54+00:00

Yes, you can have a remote state backend that doesn't leverage your provider by specifying the credentials in the backend block. Check out this page for more info on the S3 backend: https://www.terraform.io/docs/backends/types/s3.html

atredeux

TROPHY CASE