terraform-aws-access/notes/domain.md

Domain

multi-phase deployments and select when not creating paradigm

• we need to have the ability to select a domain so that we can verify its existence in multi phase deployments
  • this means assume that this module has already run, but in a different phase and nothing is in this phase's state
• select options allow us to decide to deploy some resources at earlier phases, while still keeping them in state
• select when not create gives us unified output for modules and the ability to make assumptions about available data and outputs
• select is therefore a special use case, so we should ask the user if that is what they want

skip deployments options

• while being able to select reources that were deployed in an earlier phase it is also good to be able to choose to deploy resources later
• skip options work like feature flags
• skip options enable unit testing modules
• skip options allow us to decide to deploy some resources in later phases
  • select options allow us to decide to deploy some resources at earlier phases
• skip is a special use case, so we should ask the user if that is what they want

how do we know to look for a domain vs creating a domain?

• if creating a zone, we need to create a domain
• can we select a zone, but create a domain?
  • no, we want it coupled and encapsulated
    • in this situation the user has a zone that maybe serves multiple projects, they want a domain in the zone for this project
    • we could suggest that the user create a zone for the project, but it doesn't need to be a top level zone
    • the user can have a top level zone "example.com" and a project level zone "project.example.com", then a project level domain "entry.project.example.com"
      • the user can then have a cname for the project level zone pointing to the project level domain "project.example.com -> entry.project.example.com"
    • this couples the zone to the domain, and it also gives us a generic domain name to use
    • from the user's perspective they have a domain "project.example.com" that works for their project
    • while we are actually generating a zone, domain, and cname, the user doesn't need to control this
    • selecting a domain is a special use case, so maybe we ask the user if that is what they want
• I think this is addressed with the specialized use case section below

specialized use cases

• it seems I have identified a generalized use case for internal modules or features
• maybe every feature should have some argument to either skip or select
  • this makes sense since these are not mutually exclusive
    • if you want to select a module you don't want to skip it
• this makes the default behavior for any feature to be creation
  • this has implecations on new feature additions
  • maybe we have an 'experimental' phase where new features are skipped by default
    • I think this is too complicated
  • then after a period of time we flip the skip default?
    • this breaks the interface, something we really don't want to do
    • breaking changes should result in major version numbers
  • what if we make the default behavior to be skipping a feature
    • then users will need to enable each feature individually
    • I don't like this because it makes the user interface huge and overwhelming
    • I also don't like this because the initial set of features are enabled by default
      • then we have 'core' and 'additional' features, which is too complicated
  • I think the best compromise is to expect users to pin the major version in ther versions file if they don't want breaking changes
    • this is suggested by Hashicorp, so it should be standard practice
    • the default posture for features can be create, with the option to skip
    • skipping the feature allows you to easily update to the latest major without implecations, but there is some change necessary
• what should we name the argument?
  • options: 'skip', 'select', or 'create' defaulting to 'create'
    • skip is like 'no', create is like 'yes', select is like 'kinda'
  • use_domain, domain_use, domain_usage_level, domain_usage
  • https://www.phind.com/search?cache=pxw1uu72n85u69ti4p4v8hmg
  • domain_use_strategy per that conversation ^^
  • this will also extrapolate to blah_use_strategy for any feature
    • I will need to backfill this argument, but that will have no effect on the current usage since create is the default
  • in cases where I already have something I will need to alter the interface which is a breaking change, so there will need to be notes on this

TLD

• I don't like the idea of a demo user having to go buy a domain manually for this to work, I would rather generate one for them
• I can't seem to get a valid cert when creating a TLD on our account, so until that works we are stuck with it

Kubernetes

• I have the domain and load balancer working
• I decided to generate a cert for the domain
• In order to assign the cert to the load balancer I need to choose a port to listen on
• This gets application specific... which makes me feel like I have made this module too specific to stand on its own
• Kubernetes should be a specialized use of this module not the only way to use it.
• Kubernetes expects a load balancer and domain and cert listening on port 6443
• maybe we listen on port 443? but then the kubernetes API will need a new listener in the server mod?
• maybe the root module should include any application specific stuff, like a listener on port 6443
• isn't 443 application specific then? does a kubernetes cluster need 443 exposed?

How do I use this thing?

• Getting started with AWS is a hassle, you have to generate a vpc, subnets, an internet gateway, security groups, etc.
• I was thinking, y'know, before I can even start working on a project I have to figure out a lot and do a lot.
• I really wish there was an easy way to get this stuff that didn't lock me into AWS forever
• I don't want to be stuck at AWS in the end. I would like to be able to move my project somewhere else eventually if I need to.
• This module should be the starting point for a project, even if that project has nothing to do with kubernetes
• this lays the groundwork for any project on aws
• it doesn't use any super in-depth or complicated AWS things, just the basics, and with a few tweaks I could use it on any cloud