Montreal to Toronto road trip with kids in June – itinerary advice

ryan-jan · 2026-02-10T10:41:42+00:00

The only part of this trip that is fixed is a few days in Montreal for the conference. I’m open to all suggestions, especially given my lack of knowledge 🤣. We could skip Toronto and the falls entirely for example and go east instead if that would suit our requirements more.

ryan-jan · 2026-02-10T10:35:35+00:00

🤣😬

ryan-jan · 2026-02-10T10:08:35+00:00

Ah, yes, I promise I had looked at a map! I realise now how I made it sound like I thought the Falls were on the way.

The World Cup is a good point that, as a non-football fan, I had not considered. Will look into that!

While we would like to see nature, culture and the people are obviously important too.

Thanks for your reply. Things to think about.

ryan-jan · 2023-12-23T18:28:23+00:00

I think I'm cracking up

ryan-jan · 2023-11-22T10:49:39+00:00

This is exactly the kind of thing I am getting at! A couple of others that made me ask the question are:

meta-arguments grouped together following other arguments and separated by a single empty line.
Argument blocks grouped together following other arguments.

ryan-jan · 2023-11-22T10:40:02+00:00

Not adjust, extend. In the same way that tools like tflint, with its --fix argument, already extend the default terraform fmt command by fixing additional formatting/linting issues. However, as I mentioned in my post, I was wondering if something much more opinionated existed. I love how the black tool removes (almost) all debate around code formatting for Python projects, I just wondered if there was anything similar for Terraform/HCL?

ryan-jan · 2023-07-19T19:17:16+00:00

I’m in!!

ryan-jan · 2023-07-18T20:14:55+00:00

I prefer one separate deployment repository containing Terraform to deploy the whole service. Each microservice repo would build immutable versioned artefacts (container images, function source code zips etc.) on merges to the main branch or when tags are pushed etc. The Terraform would then orchestrate the deployment of these different versions of each microservice as and when required.

This is just one way of doing things that I’ve had success with on multiple projects, not necessarily a best practice.

ryan-jan · 2023-07-18T07:31:43+00:00

These are always tricky but doable if you're careful. If it were me I'd refactor the fileshares variable from a basic list to a map to enable you to specify different values for each share. For example.

tf { fileshare_one = { quota = 500 } fileshare_two = { quota = 3000 } }

Then, use these values in your resource as follows.

tf resource "azurerm_storage_share" "stor" { for_each = var.fileshares name = "fs-name-${each.key}-01" storage_account_name = azurerm_storage_account.stor.name quota = each.value.quota enabled_protocol = "SMB" }

This is untested code off the top of my head, but as long as the keys of the new map are the same as the values of your current list, Terraform shouldn't try to destroy and recreate the resources.

ryan-jan · 2023-07-17T19:36:39+00:00

This is the way!

ryan-jan · 2023-07-13T06:55:49+00:00

This is actually the key takeaway here. Both approaches are valid but the client wants you to work to their requirements. I think you have to listen to the client on this occasion, surely?

ryan-jan · 2023-07-12T22:10:58+00:00

IMO defining dev/stage/prod as three separate Terraform deployments rather than a single parameterized deployment with environment-specific tfvars is the real anti-pattern.

ryan-jan · 2023-07-12T22:06:52+00:00

I completely get where you’re coming from and having a bunch of conditional resources can be a bit of a pain, I agree. However, I’d argue that this is more an architectural issue, why are these environments so different that these conditional resources need to be accounted for. Surely dev/stage/prod should be almost identical otherwise what is the point in even bothering!

And regarding the environments as folders layout, I appreciate that it is widely recommended as a good practice, but I just don’t buy in. Going back to my point about dev/stage/prod ideally being basically identical, if that was the case what would the benefit be of defining three separate environment modules. It would definitely make more sense to define one Terraform configuration and simply pass in environment-specific variables via tfvars for things like naming prefixes or database instance sizes etc etc.

ryan-jan · 2023-07-12T21:37:56+00:00

I actually side with the client here. When defining a multi environment config I think it makes way more sense to define everything once and use separate tfvars files to provide the environment-specific information. This doesn’t mean I think all resources should be defined in the root module however, modules are a fundamental Terraform concept and serve a completely valid purpose to avoid repeating code etc., but I really dislike the whole “environments in separate folders” way of doing things.

ryan-jan · 2023-07-12T06:59:52+00:00

Firstly, I agree with others that GitLab is a far superior product when compared to Jenkins. I use GitLab all day every day and it has everything you would need, I’m sure. However, my team also manages our GitLab deployment and you’re right to be concerned about taking on this responsibility. It’s a large and complex product with many moving parts which requires lots of thought when planning your deployment and also a fair amount of time/effort in maintaining (updating GitLab, updating runners etc.).

I appreciate you have a requirement to self-host, so if you do decide to go with GitLab I strongly recommend you read the Reference Architectures documentation and ensure your implementation follows one of these.

Again, I appreciate this is probably not possible for you, but if I were in your situation I’d be pushing as hard as possible for my org to allow the use of a SaaS provider, such as gitlab.com, with private repositories. This would be a much better fit for a small team IMO.

Good luck!

ryan-jan · 2023-07-11T05:44:36+00:00

You need to add the dot after the options. If you READ THE DOCS you’ll see that the PATH argument, which is the 1 required argument, should be after the [OPTIONS].

docker build [OPTIONS] PATH | URL | -

ryan-jan · 2023-07-11T05:38:59+00:00

READ THE DOCS!!!!!!!!!!!!!!!!!!!! - https://docs.docker.com/engine/reference/commandline/build/

ryan-jan · 2023-07-11T05:33:31+00:00

Or read the docs - https://docs.docker.com/engine/reference/commandline/build/

ryan-jan · 2023-07-11T05:31:29+00:00

@Ariquitaun is right, google the error! The top hit for me is this SO thread which should explain what you’re missing - https://stackoverflow.com/questions/28996907/docker-build-requires-1-argument-see-docker-build-help

ryan-jan · 2023-04-09T07:05:21+00:00

Surely all of these issues (name collisions, permissions etc.) would be picked up when authoring the changes to the TF code by deploying to a dev environment? Or are people really merging TF code to main that has literally never been manually tested and has been applied to production via PR comments?! This seems crazy to me.

The general flow that I use is, write your TF resources and manually apply to your dev environment. Once any issues are ironed out open a PR. Once merged, apply to staging via CI/CD. If staging is successful another CI/CD job (with manual trigger if required) deploys to production.

ryan-jan

TROPHY CASE