Open Infrastructure

This ticket is about tracking how/where we should continue to develop or things that come to my mind. Anyone who is a watcher here, feel free to update it when things are implemented that I think should be implemented.

Many things might only be brainstorming quality, but I help everyone involved to guide us to the getting it running.

• Table of contents
• Important flows / tasks (read: need to focus on this)
  • Ordering a VM by CLI
  • Ordering a VM by WEB
  • Managing payment
  • Adding an IPv4 address to an existing VM
    • Adding an IPv4 address after creating the VM
• Paying vs. not paying
• Config support
• CLI == web
• Stuff that is cool and probably makes sense, but maybe not right away
  • List orders, orders vs. subscriptions
  • List of products
• Nico's notes / review of 20190924

Important flows / tasks (read: need to focus on this)¶

Ordering a VM by CLI¶

I want to order a VM, so I...

• register on https://account.ungleich.ch/
  • gives me an LDAP account
  • gives me an uotp seed
• create ~/.ucloud (or similar) and store my username + seed in there
  • { username: "nico", seed: "whatigot" }
• I download / install the ucloud client
  • this should be very easy
• I add payment details (bee below for more about this)
  • In the first version this will cleary be a credit card
  • So I type: ucloud payment-register --cc --number xx --verify yy -- expiry i/b --name "Nico Schottelius"

Now I should be ready to rock!

• I will list the available public images
  • ucloud list-images
  • Maybe list-images by default takes some "pool" / "storage" that is named public
  • But you can also specify ucloud list-images --pool xyz
  • But let's not do this now.
• Aaaaand ... oh, I need to have an ssh key registered to access my VMs!
  • @ucloud add-ssh-key --name mygreatkey --key "key content"
• Alright, finally!
  • @ucloud add-vm --name "my first VM" --cpu 12 --ram 10 --os-ssd 10 --hdd 200 --hdd 400
  • Creating a VM with 12 CPU, 10GB RAM, 10 GB SSD and 2 extra disks with 200 and 300 GB

Now how to access the VM?

• Get the details!
  • ucloud list-vm
    • shows all VMs with name and UUID
  • ucloud show-vm --uuid $uuid
    • By name would be cool, but we could also allow same name VMs
    • To be discussed/defined
• Now I have the IPv6 address and can ssh into it!

ssh root@my-cool-vm

Ordering a VM by WEB¶

Pretty much the same as CLI, could even by a JS client... thinking about that: we might be smart in having the client being something like nodejs, which can be the same in the web as on the command line.

• Mondi/Ahmed, can you comment on this?

Managing payment¶

We want to support:

• Wire transfer / pre paid
  • User's can upload money and we will deduct usage from there
• Credit card / post paid
  • We charge once $timeframe
  • $timeframe does not have to be the same as the cycle for the VM
• Coupon support
  • Giving free $something to people
  • Basically deducting from this similar to a pre-paid account

Adding an IPv4 address to an existing VM¶

While ucloud is very IPv6 centered and VMs by default will be IPv6 only, we want users to easily have IPv4 addresses.

Adding an IPv4 address after creating the VM¶

That would be, I created the VM and realise that it does not come with IPv4. Let's fix this.

• Order the IPv4 address
  • ucloud order ipv4address --vm-uuid ${uuid}
• Show IPv4 addresses
  • ucloud show ipv4address --vm-uuid ${uuid}
    • Might return a list

The way how we support it is by using NAT64.

Paying vs. not paying¶

I was thinking about having a --pay flag in case a service costs money for the user, requiring explicit confirmation. The flag name can be discussed and we can also discuss whether we want to have it required by default or not.

In either case, we should have support for enabling/disabling confirmation when charges occur in the config ~/.ucloud file. Something on the line of:

{ ...
   "require_payment_confirmation": "yes" or "no" 

...}

Config support¶

When adding a config file, we should also have something easy to modify it. Or we document it nicely how to modify it.

CLI == web¶

To keep the web view and the CLI in sync I propose to use the same code for both. I was first thinking about using nodejs for both of them to have a reactive / js based app.

However given that I am not sure whether node is available on all client systems easily and that our expertise is more in the python area, I wonder if we can use the same python code for generating the website and generating the CLI output. The difference would be different jinja templates.

• TODO: need input from Mondi/Ahmed here

Stuff that is cool and probably makes sense, but maybe not right away¶

• Billing on second base might be cool
  • To have it feasible we might need to have a minimum fee x + fee per second
  • This could be realised with the one time charging scheme

List orders, orders vs. subscriptions¶

As a user clearly want to be able to list what I have ordered. I wonder if we have to distinguish orders and subscriptions or if the following is actually enough:

• all orders = everything a user ordered
• active orders = still being charged aka subscription
  • the charge can also be 0 chf/time frame
• inactive orders = not active, product not being used anymore

List of products¶

We need to be able to list what a user can buy, something on the line of

• ucloud list-products

Nico's notes / review of 20190924¶

• No production VMs yet running
• Infrastructure unclear defined
  • Need to make it clear which hosts to be used for ucloud
• Networking/IPAM
  • Netbox exists
  • radvd and co. not specifically deployed for ucloud
  • Net to make network design more clear
• Ordering process moving forward, need to see working examples of
  • VM ordering
  • VPN ordering
• 2nd stage ordering needs...
  • different "plans" to be active (i.e. subscription model changes)
• Documentation
  • No central point of entrance -> needs to be defined
• Installation
  • Maybe create packages for Alpine as the default OS?