Implement Project-level defaults

[bnaecker]

As part of RFD 21 and the discussion on #1003, we'd like to implement defaults at the level of a Project. The canonical example from RFD 21 is a default VPC Subnet, in which we create NICs for a guest if one is not explicitly provided in the client request. Defaults should be configurable resources, at the Project scope, for example via CRUD on an endpoint like /organizations/{org}/projects/{project}/defaults. We'll need a new table in CRDB to manage these. Below is a preliminary list of the defaults we'd like to include, but more should be added as they make sense.

• VPC
• VPC Subnet
• Image from which guest instances are created
• Whether guest NICs default to dual IPv4/v6, or exactly one of those. As an example, if the default is to provide both versions and the client requests only a specific IPv4 address, an IPv6 address is added automatically.

[bnaecker]

@rmustacc Another thing occurs to me getting back up to speed on IP pools and instance NAT. In order to meet the goal that every instance should be able to reach the internet by default (assuming FW and routing rules allow it), we'll need to provide a unique (IP, port-range) tuple for each instance, which OPTE would use for that instance's outbound connectivity. If that's correct (a man-sized "if"), it seems we might want to reflect part of this in the project-level defaults. Something like the size of the port-range might make sense, to represent the default NAT quota. Let me know if you have thoughts here.

[bnaecker]

Something about this concept doesn't quite make sense to me. It's been rattling around in the back of my head, and I think I know what it is now. Consider this quote from RFD 21:

When a project is created, a default VPC is created as well.

If that's true, how is that information populated? It can't refer to the project-level defaults, because those defaults don't exist yet. The user may be able to change them, but only after the project (and default VPC) have been created. It seems like we need a bunch of default values for these Project-level defaults, or we need to have a way to change them at a higher level than a project, such as an Organization.

I guess an alternative is to provide a flag to the Project creation endpoint that prevents creating that default VPC. The user could set that, change the project-level defaults, and then create the default VPC again. Though at that point, why have the defaults at all?

[bnaecker]

I talked with @rmustacc offline about the above question. The main take-away is that Project-level defaults are intended only to apply to new resources created within the project scope, such as instances, disks, or images. For example, a Project default VPC Subnet of "foo" would mean that, when provisioning a new instance in that Project, the NIC for the instance is created in the VPC Subnet "foo", unless otherwise specified.

In particular, this is not intended to change anything about the VPC and VPC Subnet that are named "default", and currently created when a user creates a Project. Those should still be created (subject to the setup_defaults parameter of the Project POST being true). Users can decide to rename them later, if they want.

Additionally, the setup_defaults = true parameter means that we prepopulate the Project level default fields with some set of values. For example, we'd set the default VPC and VPC Subnet to "default" and "default" respectively. If setup_defaults = false, then these fields are not populated. Should users then provision an instance, and leave out the VPC Subnet name, an error would be returned. In other words, the database record for the defaults object would be all NULLs in that case.

[bnaecker]

As of #1458, we have the optional argument to an instance create request which specifies whether to assign an instance an external IP that can be used for inbound connectivity. That's currently an ephemeral IP, but will be expanded to include floating IPs when they come down the pike.

We might want to add a project-level default controlling whether all instances in the project get such an address by default. The API would probably need to change a bit, to an actual optional value, so that a client can request that the instance not have an external IP by doing something like external_ip: []. That'd allow a None or null-like request value to mean "use the project default".

[david-crespo]

I think we could probably close this. None of this seems very important anymore. If we ran into this problem again we'd probably characterize it differently.