Hi all,
I'd like to share with you what I have in mind for the next release.
Most of the items listed below have already come up on ML before.
*A) Upload file to storage pool*
In the current code, the upload function is disabled as it does not
work well with files larger than 500MB.
When trying to upload a file with 500MB the browser stops responding
and after some time it crashes.
From a quick investigation, I identified it happens prior to send
the data to server:
var uploadFile = function() {
var blobFile = $(localFileBox)[0].files[0];
var fileName = blobFile.name;
var fd = new FormData();
fd.append('name', fileName);
*fd.append('file', blobFile)*
....
}
We need check if there is a way to solve it on UI by changing the
data structure or how it is loaded or think about a solution involving
backend.
*B) Reduce imported code*
Kimchi imports some code: python-websockets, novnc, spice and jquery
libs
Some of them (to don't say most of them) are already packaged in
some Linux distributions (Fedora, Ubuntu, etc)
We should check the availability of those packages in the all
supported distros and when possible remove the imported code from git
repository and add it as a dependency.
*It is a requirement**to have Kimchi on Fedora.*
*C) MockModel refactor*
The mockmodel was designed to provide a way to user tests Kimchi
without affecting the system (by "kimchid --test") and also to make the
tests easier to do.
But in fact, we have a bunch of code that completely differs from
the real model, so the developer needs to do 2 kinds of implementations
while developing a new feature.
My proposal is simplify that by using Model() with "test:///default"
URI.
This configuration does not affect the system in real and also can
provide us a way to test the new feature in a closer scenario to the
real one: by connecting to libvirt and doing the operations.
As you may know "test:///default" driver has some limitations that
prevents some operations, for example, screenshots.
To solve it we could only override what is not supported by this
driver and create a simpler mockmodel.
Example:
class MockModel(Model):
super(Model, self).__init__("test:///default")
def vmscreenshot_lookup():
# do some mock code
I think in this way we will have a significant reduction in our
mockmodel code.
*D) VM Template refactor*
More and more the user will be able to change the VM configuration
and it implies in generating a XML code related to the new item to be
attached to the VM.
But it is also done in the Template level. Because that we have a
lot of duplicated code related to the XML generation on VM and Template.
Some of them using etree.builder and others using pure strings.
My idea is to create a xml python module to hold all the XML
manipulation about to element type.
Example:
src/kimchi/xml/iface.py
src/kimchi/xml/disk.py
src/kimchi/xml/graphics.py
src/kimchi/xml/domain.py
Each of these files will be responsible to handle the XML
generation and manipulation using *etree*.
Then when needed, while changing VM configuration or Template, we
use the same code from our xml module.
*E) Allow user adds volumes from different pools to a Template*
*(depends on D)*
Today the user can only use one disk in a Template.
We should provide a way to user select multiple volumes from
different storage pools in a Template.
The user should be able to specific a pool and a disk size to Kimchi
automatically creates a volume according to those inputs.
So user can specify a pool and a volume OR a pool and a disk size.
From UI perspective, we will need a bigger refactor on it. Maybe
displaying the Template information in tabs (the same way we did when
editing a VM)
*F) Guest disk hot plug* *(depends on D)*
Allow attaching a disk to a running guest.
*G) PCI passthrough*
*H) SMT support*
Kimchi should enable SMT on guests when it improves performance
according to host architecture and choose the best configuration to user
(SMT8, 4 or 2)
This kind of information must not be prompted to user as it is only
for expert users and can block entry level users (our main focus)
So our algorithm must be good enough to do the right choice
according to host and guest configuration.
*I) Snapshot support*
Allow users create, revert and delete a snapshot.
*J) Guest cloning*
*K) LDAP authentication support*
We need to think also how to enable authorization on a LDAP
authentication.
In my first view, I think we need to provide a way to sysadmin lists
the IDs to have admin role in the Kimchi config file.
What about the groups? Should we use LDAP domains instead of groups?
And we also need to change UI when setting users and groups, as
there is no way to list all users in a LDAP server.
On Kimchi configuration file we can have an authentication section
like below:
[authentication]
method = pam | ldap
ldap_server =
ldap_search =
ldap_domain =
ldap_admin_users =
*L) Allow user changes graphics type on guest*
User should be able to change from VNC to Spice on a existing guest
*M) Add support for serial console*
*N) Live migration*
Start some investigation on how to do that
----
Yeap! A lot of cool features and just a piece of our backlog... ;-)
That is a brainstorm. So please, your comments/suggestions are more than
welcome!
Thanks,
Aline Manera