January 2014 - Kimchi-devel - oVirt List Archives

[WIP 0/4] Authorization utililty modules
by Shu Ming 17 Feb '14

17 Feb '14

The following patches provide modules to manage groups for the users Also pam modules are provided to check if a user is in one specific group Shu Ming (4): A module to manage the groups of the users A module to do pam account managment An example to demo how pam_members.so is used Configuration files for pam services src/kimchi/pam_members.c | 103 ++++++++++++++++++++++++++++++++++++++++++++++ src/kimchi/pamauth_acc.py | 51 +++++++++++++++++++++++ src/kimchi/rolegroups.py | 36 ++++++++++++++++ src/kimchi/superadmin | 5 +++ src/kimchi/vmadmin | 5 +++ src/kimchi/vmuser | 5 +++ 6 files changed, 205 insertions(+) create mode 100644 src/kimchi/pam_members.c create mode 100644 src/kimchi/pamauth_acc.py create mode 100644 src/kimchi/rolegroups.py create mode 100644 src/kimchi/superadmin create mode 100644 src/kimchi/vmadmin create mode 100644 src/kimchi/vmuser -- 1.8.1.4

3 9

Fwd: [project-kimchi] NFS img permission problem
by Royce Lv 12 Feb '14

12 Feb '14

Guys, When testing with kimchi nfs feature, I filed two issues related to nfs image permission problem: 1. volume creation failure: Because of storage pool permission is not configured to make write permission.(https://github.com/kimchi-project/kimchi/issues/261) 2. vm with volume cannot be started: Root users are mapped to nobody, so img it created cannot be accessed by libvirt-qemu(on ubuntu) user.(https://github.com/kimchi-project/kimchi/issues/267) After discussed with Mark Wu, we would like to propose the following to resolve these two problem: 1. To allow creation: export with all_squash(gid = kimchi_guid) and group allow write permission. Also with planned nfs-pool prevalidation (a timeout try mount in a process), we can check if the gid and permission is right. This will save us from future trouble. 2. To allow qemu process(started by libvirt) to access img, we add uid ('qemu' under fedora and 'libvirt-qemu' under ubuntu) which running qemu process to 'kimchi' group to allow the write access of the img. I am also investigating other possibilities like using storage pool permissions and so on. Welcome thoughts on it! -- project-kimchi mailing list <project-kimchi(a)googlegroups.com> https://groups.google.com/forum/#!forum/project-kimchi --- You received this message because you are subscribed to the Google Groups "project-kimchi" group. To unsubscribe from this group and stop receiving emails from it, send an email to project-kimchi+unsubscribe(a)googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.

2 2

[RFC]: for template cloning.
by Sheldon 10 Feb '14

10 Feb '14

template cloning: <https://github.com/kimchi-project/kimchi/wiki/template-cloning-and-customiz…> |1|||clone a template| from|||template| The user may clone a template from an existing template with different name. Later he can customize some parts of the template to save the effort to create a full new template. For example, he can update the network of the template cloned to have a new different template. 2.||we should also also user||||clone a template| from vm| |I just concern the image volume. For vm may has no CDROM attribute. Then does the template need to copy the image volume. |For VM clone, can we make the the vm image as a backing file(or we can call it base image). Then we can create two new images for this vm and new vm. All these two new images are a read/write snapshot of the original image, -- any changes to new images will not be reflected in original image. http://libvirt.org/formatstorage.html#StorageVolBacking http://wiki.qemu.org/Documentation/CreateSnapshot | -- Thanks and best regards! Sheldon Feng(???)<shaohef(a)linux.vnet.ibm.com> IBM Linux Technology Center

4 5

[PATCH] Bug fix #309 - network: Unable to create vlan tagged on Ubuntu v2
by Ramon Medeiros 10 Feb '14

10 Feb '14

Changes: v1: Put the rollback function above the raise, unless, the line will never run. Ramon Medeiros (1): Bug fix #309 - network: Unable to create vlan tagged on Ubuntu src/kimchi/model.py | 21 +++++++++++---------- 1 file changed, 11 insertions(+), 10 deletions(-) -- 1.8.3.1

3 4

Discussion: 312 - LVM VG is left when removing logical storage pool
by Ramon Medeiros 10 Feb '14

10 Feb '14

Well, you can also test using virsh. Libvirt is not removing the vg and the pv when you delete a logical storage pool. The question is: is it better to fix libvirt, submiting a patch for they, or just remove the vg and pv on kimchi? -- Ramon Nunes Medeiros Software Engineer - Linux Technology Center Brazil IBM Systems & Technology Group Phone : +55 19 2132 7878 ramonn(a)br.ibm.com

2 3

Kimchi at Wikipedia
by Ramon Medeiros 10 Feb '14

10 Feb '14

Hi Guys, i did a scratch page for Kimchi at Wikipedia. Also linked this with KVM page. Can you please review this. https://en.wikipedia.org/wiki/KIMCHI https://en.wikipedia.org/wiki/Kernel-based_Virtual_Machine -- Ramon Nunes Medeiros Software Engineer - Linux Technology Center Brazil IBM Systems & Technology Group Phone : +55 19 2132 7878 ramonn(a)br.ibm.com

3 6

[RFC] Host's repositories support
by Paulo Ricardo Paz Vital 05 Feb '14

05 Feb '14

Hello guys. This is the RFC for the Host's repositories support (task "Register YUM, apt, zypper repos" of 1.2 sprint 3). The support will be provided by adding in the control/host.py a new collection (Repositories), responsible to manage all repositories of the system, and a new resource (Repository), responsible to operate with a specific repository. All this management/operations will be transparent to host's package management system, being provided by one of the new back end classes. The back end support provides 4 new classes: 1) Repositories (object): Class to represent and operate with repositories information in Kimchi's perspective. It's transparent to host's package management system, and can execute all operations necessary: add repository, get all repositories list, get information about one repository, update a repository, enable and disable a repository and remove a repository. This class will load in run time the necessary classes to work with the host's package management: YumRepo for YUM systems based, AptRepo for APT systems based and ZypperRepo for Zypper systems based; 2) YumRepo (object): Class to represent and operate with YUM repositories. Loaded only on those systems that supports YUM (e.g. Fedora and RHEL), it's responsible to connect, collect and provide information of YUM repositories in the system. Also it's responsible to create/delete the files in disk to maintain the repositories in system after disconnection. 3) AptRepo (object): Class to represent and operate with APT repositories. Loaded only on those systems that supports APT (e.g. Debian and Ubuntu), it's responsible to connect, collect and provide information of APT repositories in the system. Also it's responsible to create/delete the files in disk to maintain the repositories in system after disconnection. 4) ZypperRepo (object): Class to represent and operate with Zypper repositories. Loaded only on those systems that supports Zypper (e.g. OpenSuse), it's responsible to connect, collect and provide information of Zypper repositories in the system. Also it's responsible to create/delete the files in disk to maintain the repositories in system after disconnection. Bellow I present the REST API for the repositories support. ### Collection: Host Repositories **URI:** /host/repositories **Methods:** * **GET**: Retrieve a summarized list of all repositories available * **POST**: Add a new repository * repo_id : Unique repository name for each repository, one word. * repo_name: Human-readable string describing the repository. * baseurl: URL to the repodata directory when "is_mirror" is false. Otherwise, it can be URL to the mirror system for YUM. Can be an http://, ftp:// or file:// URL. * is_mirror *(optional)*: Set the given URI of baseurl as a mirror list, instead of use baseurl in repository configuration. * url_args *(optional)*: Arguments to be passed to baseurl, like the list of APT repositories provided by the same baseurl. * enabled *(optional)*: Indicates if repository should be included as a package source: * false: Do not include the repository. * true: Include the repository. * gpgcheck *(optional)*: Indicates if a GPG signature check on the packages gotten from repository should be performed: * false: Do not check GPG signature * true: Check GPG signature * gpgkey *(optional)*: URL pointing to the ASCII-armored GPG key file for the repository. This option is used if yum needs a public key to verify a package and the required key hasn't been imported into the RPM database. ### Resource: Repository **URI:** /host/repositories/*:repo-id* **Methods:** * **GET**: Retrieve the full description of a Repository * repo_id : Unique repository name for each repository, one word. * repo_type: Indicates which type of repository is: * yum: Indicates it is a YUM repository. * deb: Indicates it is a APT repository. * zyp: Indicates it is a Zypper repository. * repo_name: Human-readable string describing the repository. * baseurl: URL to the repodata directory when "is_mirror" is false. Otherwise, it can be URL to the mirror system for YUM. Can be an http://, ftp:// or file:// URL. * url_args *(optional)*: Arguments to be passed to baseurl, like the list of APT repositories provided by the same baseurl. * enabled *(optional)*: Indicates if repository should be included as a package source: * false: Do not include the repository. * true: Include the repository. * gpgcheck *(optional)*: Indicates if a GPG signature check on the packages gotten from repository should be performed: * false: Do not check GPG signature * true: Check GPG signature * gpgkey *(optional)*: URL pointing to the ASCII-armored GPG key file for the repository. This option is used if yum needs a public key to verify a package and the required key hasn't been imported into the RPM database. * **DELETE**: Remove the Repository * **POST**: *See Repository Actions* * **PUT**: update the parameters of existing Repository * repo_id *(otional)*: Unique repository name for each repository, one word. * repo_name *(otional)*: Human-readable string describing the repository. * baseurl *(optional)*: URL to the repodata directory when "is_mirror" is false. Otherwise, it can be URL to the mirror system for YUM. Can be an http://, ftp:// or file:// URL. * is_mirror *(optional)*: Set the given URI of baseurl as a mirror list, instead of use baseurl in repository configuration. * url_args *(optional)*: Arguments to be passed to baseurl, like the list of APT repositories provided by the same baseurl. * enabled *(optional)*: Indicates if repository should be included as a package source: * false: Do not include the repository. * true: Include the repository. * gpgcheck *(optional)*: Indicates if a GPG signature check on the packages gotten from repository should be performed: * false: Do not check GPG signature * true: Check GPG signature * gpgkey *(optional)*: URL pointing to the ASCII-armored GPG key file for the repository. This option is used if yum needs a public key to verify a package and the required key hasn't been imported into the RPM database. **Actions (POST):** * enable: Enable the Repository as package source * disable: Disable the Repository as package source

3 4

[PATCH 0/3 RFC] Refactor exception
by Aline Manera 04 Feb '14

04 Feb '14

From: Aline Manera <alinefm(a)br.ibm.com> Hi all, This is the RFC for the refactor exception task. Sheldon has already done something related to that some time ago. He also created a wiki for that: - https://github.com/kimchi-project/kimchi/wiki/refactor-exception The only change I made in him approach is translating the message in backend and send it to UI That way we don't need to duplicate the messages on backend and UI (as it is explained on wiki) The steps to get it done: 1) Change cherrypy error handler to send the exception data to UI 2) Create a common Exception class (KimchiError) to translate the error message and proper set the parameters 3) Update UI to show the message received from backend to the user I also would like to create a file on backend: __messages__.py which will contain all messages used on backend. For example: # __messages__.py VM_START_FAILED = "<code>: Failed to start virtual machine %(name)s" The contants names should be: <resource>_<action>_<error> The <code> need to be a unique value between all messages. It is needed in order to we identify the error independent of the message language. That way a user running Kimchi in German can easily post his error on mail list or github, and we can identify where the problem is by the message code. I also will add this code in the UI messages. For the code, we can build it like: <resource><BACK|UI><type-of-error><ident> And on backend: VMBACKINFO01 VMBACKERRO01 VMBACKWARN01 And on UI: VMUIINFO01 VMUIERRO01 VMUIWARN01 So we will also need: 4) Create a __messages__ file with all messages used on backend 5) Update build process to add the messages in this file to .po files 6) Update UI messages to add a code for them I made a small patch set with my proposal. This patch set does not include the items 4,5 and 6 In fact, I used an existent message for test (as you can notice on patches) And *just for example* it will *always* raise an exception while starting a VM. Any comments/suggestions are welcome. =) Aline Manera (2): refactor exception: Create a common Exception to translate error messages refator exception: Example of use ShaoHe Feng (1): refactor exception: Add a kimchi special error handler src/kimchi/control/base.py | 5 ++++- src/kimchi/exception.py | 29 ++++++++++++++++++++++------- src/kimchi/model/vms.py | 4 +++- src/kimchi/template.py | 14 ++++++++++++++ ui/js/src/kimchi.guest_main.js | 4 ++-- 5 files changed, 45 insertions(+), 11 deletions(-) -- 1.7.10.4

3 7

[PATCH V3] Avoid useless libvirt error log produced by featuretest
by Aline Manera 04 Feb '14

04 Feb '14

From: Aline Manera <alinefm(a)br.ibm.com> I am sending the next version for the apporc patch as he may be out for the Chinese holidays. v2 -> v3: 1. Any error on feature tests will be log into kimchi error log file For that, silent cherrypy screen log to avoid displyaing the message on screen. v1 -> -v2: 1. Just hide the portocol type error, leave other error messages as it is. (Thanks Cristian) 2. Unregister the error handler when necessary. (Thanks Cristian) 3. Keep back kimchi log "*** Running feature tests ***", etc. (Thanks Cristian) 4. Move libvirt error handler function inside of Featuretest. (Thanks Aline) v1: Avoid useless libvirt error log produced by featuretest apporc (1): Avoid useless libvirt error log produced by featuretests src/kimchi/featuretests.py | 31 +++++++++++++++++++++++++++++-- 1 file changed, 29 insertions(+), 2 deletions(-) -- 1.7.10.4

4 5

RFC: "Add disk to existing logical storage pool"
by Daniel H Barboza 04 Feb '14

04 Feb '14

Hello! I am almost delivering a first version of this feature but now I am having doubts in how it might work or not. My implementation would use vgextend and add a disk to an existing LVM pool. The question is that, in this process, all existing data in the added partition will be deleted. Is this ok? We can warn the user about it, of course. But I am not sure if this is the intended design. I've spoken with Aline a while ago and she agreed that the implementation would function similar to what we have today when creating a new LVM pool. We simply "do not care" about the potential data loss when adding the disk to an existing pool. Any thoughts? thanks!

3 5