Zun

Avoid hard-coding of Nova flavor on creating sandbox

Registered by hongbin on 2016-12-13

Right now, when using Nova driver, we hard-code the flavor to m1.small: https://github.com/openstack/zun/blob/master/zun/container/docker/driver.py#L278 . This is obviously not desirable. There are several ways to solve this problem:

1. Specify Nova flavor when creating the container. However, flavor is specific to Nova driver so it requires Zun to expose driver-specific parameters in some ways. For example:

  $ zun create --extra-opts flavor=m1.small ...

2. Auto-select the Nova flavor based on the specified container capacity.

  $ zun create --memory 3G --cpu 2 # this will fit into m1.medium (2 vcpu, 4G).

3. (your proposal here)

Blueprint information

Status:
Complete
Approver:
hongbin
Priority:
Medium
Drafter:
hongbin
Direction:
Approved
Assignee:
Pradeep Kumar Singh
Definition:
Obsolete
Series goal:
None
Implementation:
Not started
Milestone target:
None
Completed by
hongbin on 2018-03-11

Related branches

Sprints

Whiteboard

@Hongbin, its sandbox container which is created in nova right, then why we want to change the memory of sandbox container to same as user container. And when there will be multiple containers related to one sandbox then how it be handled?

@Pradeep, we don't have to make the sandbox and user's container the same. However, the capacity of the sandbox must be bigger than the capacity of the user's container.

@hongbin, i am not aware of such thing, could you plz educate me, any reference would be useful.

@Pradeep, this is an open question so i don't have any reference. The problem is to avoid hard-coding of Nova flavor when creating the sandbox. It is up to you to propose how to fix the problem. What I mentioned is a general idea as followings:
* Allow users to specify the capacity of the sandbox (i.e. S)
* Use the memory of the sandbox to enforce the aggregate resource constraints of all the containers inside (i.e. there are two container, with capacity M and N, then we required S >= M + N).

The idea is inspired by the k8s proposal: https://github.com/kubernetes/kops/blob/master/vendor/k8s.io/kubernetes/docs/proposals/pod-resource-management.md . However, I haven't looked into the details yet.

You don't have to use my idea. Feel free to propose what you thought is right :) .
-- hongbin

(?)

Work Items

This blueprint contains Public information 
Everyone can see this information.