Project

General

Profile

Actions

Task #7138

closed

Task #6869: Challenge OpenStack and OpenNebula with ucloud

Nico's open / next points for ucloud

Added by Nico Schottelius over 4 years ago. Updated 3 months ago.

Status:
Rejected
Priority:
Normal
Target version:
-
Start date:
10/06/2019
Due date:
% Done:

100%

Estimated time:
(Total: 0.00 h)
PM Check date:

Description

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.

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?

Subtasks 1 (0 open1 closed)

Task #7205: Try 1: Installing ucloud on Arch LinuxRejectedNico Schottelius10/06/2019

Actions
Actions #1

Updated by Nico Schottelius over 4 years ago

  • Description updated (diff)
Actions #2

Updated by Nico Schottelius over 4 years ago

  • Description updated (diff)
Actions #3

Updated by Ahmed Bilal over 4 years ago

https://redmine.ungleich.ch/issues/7138#CLI-web

Yes, our expertise is in Python. I don't have much experience working with Javascript. I think using Python to create website would be a better idea.

Actions #4

Updated by Ahmed Bilal over 4 years ago

https://redmine.ungleich.ch/issues/7138#Ordering-a-VM-by-CLI

This is implemented but in a different way. Currently, user have to put his OTP credentials in ~/.bashrc. Like

OTP_NAME={name}
OTP_REALM={realm}
OTP_SEED={seed}

Installing ucloud client aka ucloud-cli is very easy (You need Python + Pipenv). I think we should use requirements.txt instead of Pipenv for ucloud as it saves user from installing Pipenv.

cd ~
git clone https://code.ungleich.ch/ucloud/ucloud-cli.git
cd ucloud-cli
pipenv install
echo "alias ucloud='pipenv run python $(pwd)/ucloud-cli/ucloud.py'" >> ~/.bashrc
Actions #5

Updated by Mondi Ravi over 4 years ago

I made a version 0.5.1 of ucloud-pay (https://code.ungleich.ch/ucloud/ucloud-pay) and deployed/tested it on ucloud-pay-dev.ungleich.ch and I think we are good to head over to the step where you should be able to "rock".

ucloud-pay: https://code.ungleich.ch/ucloud/ucloud-pay
ucloud-pay features: https://code.ungleich.ch/mravi/ucloud-cli#listing-available-ucloud-products

Corresponding merge request in the ucloud-cli https://code.ungleich.ch/ucloud/ucloud-cli/merge_requests/1

Do let me know if you want any specific explanation or further documentation.

Note:
ucloud-pay currently supports Stripe subscriptions only monthly/yearly based on recurring products. I intend to do one time payment products in the next version.

Actions #6

Updated by Mondi Ravi over 4 years ago

ucloud-pay: Added the functionality to handle one time payment in version 0.5.2 https://code.ungleich.ch/ucloud/ucloud-pay/-/tags/0.5.2

Actions #7

Updated by Nico Schottelius over 4 years ago

  • Description updated (diff)
Actions #8

Updated by Nico Schottelius over 4 years ago

  • Description updated (diff)
Actions #9

Updated by Ahmed Bilal over 4 years ago

@Nico Schottelius

  • To assign an IPv6 to a VM, we need its mac address. What strategy should we adopt to get a unique mac address for a VM. (Currently, this is one of the stopping point to run ucloud similar to what it would look like in production)
  • Depending on this IPv6 assignment, is the ucloud-init and ucloud-metadata services which only works correctly, if each VM is assigned a unique mac.
  • What would be utility of netbox when we can create unique mac addresses and then can compute actual IP address given IP prefix and mac address of machine?
  • I tested ucloud-init and it was working good at least on alpine VMs. However, ucloud-metadata may need a little bit of work.
  • Network design is the most ambiguous part for me yet. I don't currently know whether the implementation (related to network part) I would do for demonstration of ucloud usability wouldn't deprecate when we start thinking/implementing about the network design for final version.
  • ucloud-pay is currently incompatible with other ucloud-* systems. First of all it need user's email to work (Stripe) which we haven't thought about yet (because we are using only OTP). It uses LDAP usernames in etcd while all other ucloud-* systems use OTP names.
  • We need to finalize whether we are going to use LDAP or OTP. They are not 100% compatible with each other e.g OTP can have same name but with different realms. It is real confusing to have two parallel authentication systems.
  • You mentioned Maybe create packages for Alpine as the default OS?. What do you mean by packages for Alpine Linux? ucloud-* are all python based and can be installed anywhere given the dependencies are installed.

Note: Currently, if we ignore payment mechanism for the time being, we can run our own VMs (development/testing) on a bridged network using radvd and rdnssd with 1-2 days effort with the flow you mentioned above.

Actions #10

Updated by Nico Schottelius 3 months ago

  • Status changed from In Progress to Rejected
Actions

Also available in: Atom PDF