Provider Q&A Content

[danhunsaker]

Adapted from a conversation in Slack on Nov 16th at 4:49 PM (MST), as well as a few follow-on questions, and converted to a checklist (by @sanderson, on 28 Dec 2016) so we can track progress:

Original Questions

• Q: A base Ubuntu OS is easy enough, but is there a minimum supported version
  A: Probably. We'll need to figure out what that is specifically. Newer versions will work.
• Q: Can I provision a VM or container for this, or does it have to be bare metal (that is, would virtualization interfere with correct operation in any way)?
  A: A VM or bare metal machine will work fine. As long as the OS isn't sharing a kernel (ie: the host can't be a docker container).
• Q: The public NIC is pretty obvious, but what is the private NIC used for? What else is expected and/or allowed on the private network?
  A: Nanobox builds a virtual network on top of the private/internal network. It's a layer 2/3 vxlan implemented in the linux kernel. It could work on the public network, but connection from the web to the database would just be too slow. - Update: in case it's not clear, nanobox builds and configures the vxlan automatically. No special configuration or setup is required. If there's 2 nics, nanobox will do the rest.
• Q: - If all my regions support all the same sizes, is there an alternate format I can use to reduce payload size? Even if I don't support all sizes in all locations, I may at least have a standard set, which means my payload will still contain a large amount of duplicate data...
  A: Right now it'd have to be duplicated. Fortunately since it's just a JSON text api, the compressed response is very small even if the data is duped.
• Q: Is there a minimum size required to support the Nanobox infrastructure, before the user's app is added in? It wouldn't make sense to advertise server sizes that won't boot properly.
  A: The nanobox app platform runs in under 50MB of RAM. So anything larger than 128MB of RAM would be sufficient to run the platform and the app... but it might be a squeeze. I'd recommend 512 as the smallest but technically nanobox can go smaller.
• Q: Is there a timeout in the Nanobox dashboard after which it assumes the system isn't going to be provisioned?
  A: Nope. In fact we just added a meta attribute to set an expectation of time to the end user. It could be a really long time.
• Q: On the private NIC, is there any reason it needs to be a real NIC, backed by hardware, or can it be a virtual NIC, only available to the Docker-host itself?
  A: It can be virtual. As long as the OS sees two nics.
  Q: I assume it would be preferred that it be hardware backed if the user wants their apps to be able to talk to each other ... especially across separate Docker-hosts.
  A: honestly if it becomes a real sticking point, we could modify our configuration to use a single nic if two aren't available. It's just not that way right now.
  Q: I doubt it'll be a big issue. Might look into setting up a virtual device programmatically, though, instead of stacking the private net on the public NIC.
  A: our network really only cares that the nic has a MAC address and an IP address.

New Questions

• Q: What user does Nanobox expect to use on the created servers? Is there a way to specify a different user to use instead? And what permissions will the user need on the system?
  A: The username is returned in the /meta response, and can be anything. The user simply needs sudo access (without password!), or to be root to begin with.
• Q: Can I use non-standard ports? Something other than HTTP:80/HTTPS:443? SSH:22?
• Q: Do my servers absolutely need public IPs for each server, or can I put them behind load balancers of some sort?

[danhunsaker]

There might be other questions I can't see anymore, since the current Slack group settings support limited scrollback, but these at least have been asked and not yet answered.

[danhunsaker]

• Q: Is there a timeout in the Nanobox dashboard after which it assumes the system isn't going to be provisioned?
  A: Nope. In fact we just added a meta attribute to set an expectation of time to the end user. It could be a really long time. ← This appears not to be accurate...