Support deployment on small physical environments
Reduced footprint Change-Id: I284aed05564ed66977e116f9924dcaa04d57b250 Implements: blueprint reduced-footprint
This commit is contained in:
Bartosz Kupidura
parent
b4b03b8730
commit
2e41e66682
296
specs/7.0/reduced-footprint.rst
Normal file
296
specs/7.0/reduced-footprint.rst
Normal file
@ -0,0 +1,296 @@
|
||||
=================
|
||||
Reduced footprint
|
||||
=================
|
||||
|
||||
https://blueprints.launchpad.net/fuel/+spec/reduced-footprint
|
||||
|
||||
Reduced footprint is about deployment on reduced number of physical nodes.
|
||||
The minimal nodes count is 5 for the current implementation and HA mode
|
||||
(1 master, 3 controllers, 1 compute/storage).
|
||||
The requirement is a 2 node cluster should be supported with possibility to
|
||||
migrate Fuel master node to VM.
|
||||
Fuel master can be installed not only on dedicated server, but also on laptop
|
||||
or other machine.
|
||||
|
||||
Problem description
|
||||
===================
|
||||
|
||||
In some cases user want to deploy OpenStack with Fuel in small environment.
|
||||
This will not deliver production ready setup on 1 node, but allow to play and
|
||||
test OpenStack and Fuel itself. Full working HA will be possible with 3
|
||||
physical nodes (each controller located on other physical server).
|
||||
|
||||
This require to support 2 baremetal server deployments.
|
||||
All reduced deployments should be capable to be migrated to proper HA setup.
|
||||
After deployment, user should have possibility to migrate Fuel to VM, and use
|
||||
Mirantis OpenStack on single physical machine.
|
||||
|
||||
Proposed change
|
||||
===============
|
||||
|
||||
Allow user to create additional virtual machines (KVM) on single physical
|
||||
machine.
|
||||
This should be possible by assigning new role named "virt" to physical server,
|
||||
after that user should upload VMs properties as node attributes.
|
||||
|
||||
Virtual machines will be treated by Fuel as standard bare metal servers.
|
||||
Fuel will allow only to start/deploy VMs.
|
||||
User should take care about VMs maintenance.
|
||||
We will deliver fire-and-forget solution.
|
||||
|
||||
New "virt" role can be mixed with "compute" role.
|
||||
|
||||
We will introduce new feature group ex. "Advanced/expert mode" and put
|
||||
reduced-footprint inside.
|
||||
|
||||
We should also prepare possibility to move running Fuel to
|
||||
virtual machine running on our bare metal.
|
||||
|
||||
Deployment flow:
|
||||
|
||||
- Install Fuel on baremetal/virtual machine
|
||||
- Boot another bare metal server via Fuel PXE
|
||||
- Create new environment in Fuel
|
||||
- Assign "virt" role to bare metal
|
||||
- Upload virtual machines details to Fuel
|
||||
- Provision bare metal with "virt" role
|
||||
- Execute dedicated granular tasks to spawn VMs
|
||||
- Assign controller roles to virtual machines
|
||||
- Deploy environment
|
||||
- Migrate Fuel server (#1) as additional virtual machine located on physical
|
||||
server
|
||||
|
||||
Migration of Fuel server will be done by dedicated script.
|
||||
|
||||
Migration script flow:
|
||||
|
||||
- Determine/get from command line/configuration needed parameters
|
||||
(destination compute, admin network parameters, disk schema)
|
||||
- Use libvirt template XML to define VM on destination node
|
||||
- Start destination node (bootstrap with PXE from source node)
|
||||
- Prepare destination node (partitioning)
|
||||
- Reboot source Fuel to runlevel with disabled all services (containers)
|
||||
- Sync data between source Fuel and destination VM (with rsync+dd)
|
||||
- Run post-migrate script on destination VM (fix udev rules, ...)
|
||||
- Reboot destination VM to final image
|
||||
- Stop network on source node and up admin interface with temporary address
|
||||
|
||||
Alternatives
|
||||
------------
|
||||
|
||||
1) Assign compute and controller role on single machine
|
||||
|
||||
Allow to assign compute and controller role to single machine.
|
||||
|
||||
Cons:
|
||||
- No possibility to easy separate resources used by controller processes
|
||||
from compute processes
|
||||
|
||||
Pros:
|
||||
- Better performance.
|
||||
- Easy implementation.
|
||||
|
||||
2) Single node OpenStack setup + additional VMs located on OpenStack
|
||||
|
||||
Prepare dedicated Glance image for 'infrastructure node'.
|
||||
This image can be spawned as additional slave on OpenStack.
|
||||
This image will be pre-provisioned Fuel slave (nailgun agent, mcollective),
|
||||
ready to be discovered and/or deployed by Fuel.
|
||||
|
||||
Flow:
|
||||
- Deploy controller and compute as single node setup
|
||||
- Upload precreated glance image
|
||||
- Spawn OpenStack VM from dedicated image
|
||||
- Add OpenStack VM to the existing Fuel environment
|
||||
- Assign roles and continue deployment as always
|
||||
|
||||
Cons:
|
||||
- Very different deployment flow from what we already have
|
||||
- We need to implement possibility combination of compute and
|
||||
controller role
|
||||
- We need to prepare dedicated Glance image
|
||||
|
||||
Pros:
|
||||
- All 'run VM' logic will be handled by OpenStack
|
||||
|
||||
Data model impact
|
||||
-----------------
|
||||
|
||||
VMs details will be stored inside node attributes. Data will be stored
|
||||
as JSON list.
|
||||
|
||||
node:
|
||||
attributes:
|
||||
vm_configuration:
|
||||
- {'id': 0, 'cpu': 2, 'ram': 4, 'new_value': 'example'}
|
||||
- {'id': 1, 'cpu': 4, 'ram': 8, 'new_value': 'ex'}
|
||||
- {'id': 2, 'cpu': 2, 'ram': 4, 'new_value': 'example2'}
|
||||
|
||||
|
||||
Details from nodes attributes will be used inside libvirt XML template.
|
||||
Libvirt XML template will be stored as normal file inside fuel-library.
|
||||
|
||||
.. code-block:: xml
|
||||
|
||||
<domain type='kvm'>
|
||||
<name>{id}</name>
|
||||
<memory unit='GiB'>{ram}</memory>
|
||||
<vcpu placement='static'>{cpu}</vcpu>
|
||||
</domain>
|
||||
|
||||
If user want to modify libvirt template, and introduce new variable it only
|
||||
require to upload new libvirt xml template with new variables.
|
||||
|
||||
.. code-block:: xml
|
||||
|
||||
<domain type='kvm'>
|
||||
<something new>{new_value}</something new>
|
||||
</domain>
|
||||
|
||||
In that case "new_value" from node attributes will be injected into template.
|
||||
|
||||
When user pass in node attribute value which is not used inside libvirt
|
||||
template, nothing happend.
|
||||
|
||||
When user dont pass in node attribute value which is used inside libvirt
|
||||
template, template will be generated with empty value.
|
||||
|
||||
REST API impact
|
||||
---------------
|
||||
|
||||
We should introduce new API call which will allow to run virtual machines
|
||||
on given node with "virt" role assigned.
|
||||
This API call will execute all needed granular tasks on "virt" node.
|
||||
|
||||
Upgrade impact
|
||||
--------------
|
||||
|
||||
None
|
||||
|
||||
Security impact
|
||||
---------------
|
||||
|
||||
In this scenario controller is located in KVM on computes where tenants VMs
|
||||
are running. This can lead to unknown security vulnerabilities.
|
||||
|
||||
Notifications impact
|
||||
--------------------
|
||||
|
||||
None
|
||||
|
||||
Other end user impact
|
||||
---------------------
|
||||
|
||||
When user want to use virtual machines as controller, he should run additional
|
||||
steps before deployment:
|
||||
|
||||
- Upload VMs configuration as node attributes.
|
||||
- Provision environment.
|
||||
- Deploy environment.
|
||||
|
||||
Performance Impact
|
||||
------------------
|
||||
|
||||
Running all OpenStack components on single physical machine in KVM will lead
|
||||
to bad performance. Also tenants VMs can affect reduced-footprint VMs
|
||||
performance.
|
||||
But we should remember that reduced-footprint will be available only for
|
||||
advanced users.
|
||||
|
||||
Other deployer impact
|
||||
---------------------
|
||||
|
||||
None
|
||||
|
||||
Developer impact
|
||||
----------------
|
||||
|
||||
None
|
||||
|
||||
UX impact
|
||||
---------
|
||||
|
||||
When user want to use virtual machines located on "virt", proper flow will
|
||||
be:
|
||||
|
||||
- User sees just one available node on Fuel UI
|
||||
- User assigns "virt" role to this node
|
||||
- User uploads VMs configuration
|
||||
- User start provisioning
|
||||
- New servers will be available in Fuel
|
||||
- User assigns roles to new nodes
|
||||
- User runs deployment of the cluster
|
||||
|
||||
Uploading VMs detail will be only needed when "virt" role in use.
|
||||
VMs details will be only visible on nodes with "virt" role assigned.
|
||||
|
||||
When "virt" role will be used in environment, new button comes up in UI.
|
||||
This button will call API, which will prepare/start VMs.
|
||||
|
||||
roles_metadata:
|
||||
virt:
|
||||
name: "virt"
|
||||
allow_provision_only: true
|
||||
|
||||
Both VMs details and "virt" role limitations will be created inside
|
||||
openstack.yaml, as other UI parts.
|
||||
|
||||
vm_configuration:
|
||||
metadata:
|
||||
label: "VMs configuration"
|
||||
type: "textarea"
|
||||
value: "{'id': 0, 'cpu': 2, 'ram': 4}"
|
||||
weight: 20
|
||||
restrictions:
|
||||
- condition: "not ('advanced' in version:feature_groups) and
|
||||
not ('virt' in node:roles)"
|
||||
action: "hide"
|
||||
|
||||
Implementation
|
||||
==============
|
||||
|
||||
Assignee(s)
|
||||
-----------
|
||||
|
||||
Primary assignee:
|
||||
Bartosz Kupidura (zynzel)
|
||||
|
||||
Work Items
|
||||
----------
|
||||
|
||||
- Implement new granular tasks to create virtual machines on "virt" when
|
||||
choosen.
|
||||
- Add new action in webUI which allows to provision servers before
|
||||
deployment.
|
||||
- Add new action in webUI which allows to configure virtual servers on
|
||||
given node.
|
||||
- Create script to migrate Fuel to VM
|
||||
- Create procedure/documentation how to move installed Fuel node to virtual
|
||||
machine located on compute.
|
||||
|
||||
Dependencies
|
||||
============
|
||||
|
||||
None
|
||||
|
||||
Testing
|
||||
=======
|
||||
|
||||
Acceptance criteria:
|
||||
|
||||
- User can spawn VMs on node with role "virt".
|
||||
- VMs are visible in Fuel as standard physical server.
|
||||
- Show warning before delete node with "virt" role.
|
||||
|
||||
Documentation Impact
|
||||
====================
|
||||
|
||||
We need to prepare new section in documentation describing new feature and
|
||||
proper flow of deployment.
|
||||
We will put BIG disclaimer about performance impact in case of using
|
||||
reduced-footprint. User should be aware of all limitations.
|
||||
|
||||
References
|
||||
==========
|
||||
|
||||
- https://blueprints.launchpad.net/fuel/+spec/reduced-footprint
|
||||
Loading…
Reference in New Issue
Block a user