ISO pool: Support to download ISO from URL (vianac)

Hi all,

        As agreed in the last scrum meeting (http://kimchi-project.github.io/kimchi/meetings/kimchi.scrum.2014-08-13-13.02.html),

        I am sending to you an overview about the sprint 2 tasks.

        That way everyone can be aware of what is expected in each task
        and we don't block the UI development.

        Just to make clear, this is my view on each task!

        Maybe you - the task owner - have a different view on that. In
        this case, share your ideas with us.

        And don't forget to send a RFC, V1 patch, UI mockup or
        something related to your task by next Monday (08/18)

        This email is just a summary to motivate you!  ;-) 
ISO pool: Support to
            download ISO from URL (vianac)
The idea here is to provide a way to user download a ISO from
        URL to the OOTB pool (ISO pool)

        POST /storagepools/ISO/storagevolumes/ {'name':
        <vol-name>, 'url': <http|https|ftp://url>}

I prefer using an action rather than POST to collection itself,
      reasons:

    1. If upload share the same REST API with create volume, the
      model logic of create volume will be messed up. Since upload and
      create fulfill different tasks, we have reason to distinguish
      them.

          2. If in the future, we support create volume based on another
      storage volume, we may use identical parameters and API as this
      one. That will confuse user.

             So to make the REST API match its function, I prefer to use
      "POST upload".

      I think upload and download can share same REST API.

        - name can be optional. We can generate one automatically based
        on ISO path when any name is provided by user.

        - url is required.

        Questions:

        - Which protocols will we support? http, https, ftp? Any other?

As I have proposed to utilize libcurl, I think we can keep in
      line with protocols libcurl support.

      Also qemu iso streaming uses libcurl, so if a user found an ISO
      useful when using iso streaming, he may want to download it with
      kimchi.

      If we keep same protocol, same urls can be used.

        - About the UI, how do we show this feature to user?

          Basically we have 2 options:

          1) In the storage tab:

             Add an option "Add ISO" to the ISO pool (or any pool ?);
        get the URL and display a progress bar.

          2) While creating a template:

             Add an option "Download ISO"; get the URL and display a
        progress bar.

             When the download is completed, we create a template using
        the new ISO.

          I prefer the first option (storage tab) as it can also be used
        for upload ISO (see below)

ACK.

ISO pool: Support to upload
            ISO
This has a similar idea from downloading ISO from URL, but
        instead of providing a URL the user will select a local file on
        client side.

        POST /storagepools/ISO/storagevolumes/ {'name':
        <vol-name>, 'filepath': filepath}

        For the UI we also have the same 2 options from downloading ISO
        from URL feature

        I prefer the first one (storage tab) as we can use the same UI
        for both cases, download and upload.

        While selection "Add ISO" option, a new dialog will be displayed
        with a radio box: a browser input box (for upload) and a simple
        input box for URL (for download). The user can only select one
        option and confirm the operation.

Create template from VM (rotru)
This will use the same backing storage mechanism used to
        create a template from a IMG file.

        POST /templates {'name': <template-name>, 'vm':
        <vm-name>}

        About the UI:

        We have 2 options:

        1) When creating a template:

           Add an option "From guest"; then list all guests to user
        choose one (or multiples ? ) and do the requests

        2) On guests Actions menu

           Add an option "Create template" and do the request

        I prefer the first option (while creating a template)

ACK.

Discover Kimchi
              peers（alinefm)
This will use openSLP to register and discover Kimchi peers in
        the same network.

        GET /peers will return the Kimchi peers

        [{server: "https://1.2.3.4:8001"},
        {server: "https://1.2.3.5:8001"}...]

        I think this feature should be optional, ie, we will have a
        config file entry that can be enabled/disabled - as this feature
        is not critical for virtualization and requires additional
        software installation (openSLP) and configuration.

        federation = enable|disable

        When enabled, the kimchi server will be register in the openSLP
        tool and when requesting /peers we will search for peers

        When disabled, /peers will return an empty list. Maybe it would
        be good to also display a message on UI "Federation feature is
        disabled for your Kimchi server."

        To display that message, we need to update /config/capabilities
        to also return this info.

        GET /config/capabilities

        { ...

          federation: enable|disable

        }

Migration（Simon Jin)
This task was added after we have finished the 1.3 Plan. So it
        would be difficult to accommodate the UI for it in out current
        plan.

        So I'd say I only expect to have the backend done for 1.3
        release.

        POST /vms/<name>/migrate {server:
        <other-kimchi-server-ip>}

Asynchronous event
            notify（Sheldon Feng/Zhengsheng Zhou）[backend]
Asynchronous event
              notify（WenWang）[UI]
This is an important and big task. But I am not sure we will
        be able to finish it on time for 1.3 release.

        We have already started some discussion on ML "[Kimchi-devel]
        [RFC] Improve task management for kimchi" (http://lists.ovirt.org/pipermail/kimchi-devel/2014-June/006230.html)

Authorization:

              Allow admin user change permission settings when VM is
              running (WenWang)

The idea is display the
            same "Edit" dialog view when vm is running or not.

            And when vm is running only enable the information that can
            be updated with running vm for editing.

            That way we eliminate the "Manage Media" option and keep the
            UI consistent. And also provide a way to user checks the vm
            configuration (https://github.com/kimchi-project/kimchi/issues/387)

VM
            ticket: update novnc/spice code (sheldon)

POST /vms/<name>/connect will automatically set a
        random console password for the VM and sets its expiration time
        to 10 seconds later.

        When accessing the console URL, we need to pass the password as
        a parameter (password=...) so noVNC/Spice can do the connection
        to the guest console.

Display iSCSI targets
            when iSCSI server is provided (backend done in 3c6c5c) (Yu
            Xin)

        It is similar to what we did for NFS servers. But in this case
        we will list the iSCSI targets for a given server.

        GET /storageservers?_target_type=iscsi

        [

          { "host":"127.0.0.1"

            "port":"3260"

          }

        ]

        GET
/storageservers/<server>/storagetargets?_target_type=iscsi&_server_port=<port>

        [

          {

            "host":"127.0.0.1",

        "target":"iqn.2003-01.org.linux-iscsi.localhost.x8664:sn.edb1a004dc57",

            "target_type":"iscsi"

          }

        ]

        -----------

        And thanks for your patience if you were reading this line now!  :-) 

        I know it is a big email but it could not be different based on
        the tasks we have for sprint 2.

        Feel free to use it as base for your RFC email.

        I am looking forward to see all that done.

        Regards,

        Aline Manera
_______________________________________________
Kimchi-devel mailing list
Kimchi-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/kimchi-devel