Open beckettsean opened 1 month ago
Continuation of learnings from #52
Met with the team and suggested using Packer (for creating the image) and Terraform for deploying the image.
A separate Terraform project can be used to deploy the image to a server for developer access.
@jtieri sez "client asked for this to be visible and / or open-sourced". Can we do this? Any contractual or other constraints? @beckettsean would love yr thoughts.
Get someone with a reasonable title (VP Eng, CTO, or higher) from the client to state in writing that they want us to open-source this code. (e.g. email or a public post in GitHub, something permanent and discoverable in a couple years if there's legal action)
Ask them to determine the license, with us defaulting to Apache 2 if they have no opinion. Copy the code into an empty, history-free, public repo under strangelove-ventures
, add the license, give the client the link.
We would not make the actual VPS instances public, nor should anything from our GCP projects allow public or unauthenticated access.
I would say that in this case, the client can locally override any contractual IP considerations that might be in the SOW or MSA. cc @chipcope for verification of that assumption.
I have checked off the "remove pubkeys" after cleaning up the repo, generalizing more of the Packer and Terraform code and rewriting history on the repo to remove any items that we would not want public-facing. If you have pulled this repo recently, you will need to reset to the origin as the history has been rewritten
@beckettsean - We'd need to pair briefly so that I can make sure I'm clear on the details, but I generally agree that this assumption is correct. Depending on what trying to accomplish, there are a few different ways we could set this up. For example, if we want a license election in a GH repo to govern, we can provide a URL and expressly incorporate the language at that URL into the Agreement by reference. I think we'd likely have language in the Agreement stating that Apache 2.0 is the default, subject to a contrary election (I'm assuming the Customer will have unilateral discretion to alter the license) at the GH URL. Another option would be to enshrine a license change procedure in the Agreement setting forth a simplified process whereby the Customer and SL can formally amend the Agreement itself in order to affect any changes to the license.
I would say that in this case, the client can locally override any contractual IP considerations that might be in the SOW or MSA. cc @chipcope for verification of that assumption.
Current results of my tire kicking:
This PR added helper scripts as suggested in the previous meetings that allow quickly starting the required infra/commands for running Tilt: https://github.com/strangelove-ventures/sl-vps/pull/1
It adds 2 scripts to the images that are globally accessible for all users on the machine:
wormchain-start-minikube
- starts minikube with sane defaultswormchain-start-tilt
- starts minikube (if not already started), then runs tilt up with sane defaultsRunning these commands with --help
will provide usage info.
The final issue to tackle is for secure access to the images, which is an infra-specific (GCP) issue. This is documented in the internal repo so we can track security-specific tasks on the deployment code.
As SL We're electing to create TILT servers in the cloud for the dev team to use Bc TILT doesn't run correctly on ARM hardware (and we don't want to tackle solving the ARM problem)