Avoid hard-coding of Nova flavor on creating sandbox
Right now, when using Nova driver, we hard-code the flavor to m1.small: https:/
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
- Started by
- Completed by
- hongbin
Related branches
Related bugs
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:/
You don't have to use my idea. Feel free to propose what you thought is right :) .
-- hongbin