[Kimchi-devel] Proposals for next release

[Aline Manera]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/kimchi-devel/attachments/20140930/df6c279f/attachment.html>