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