[RFC] Host's repositories support
by Paulo Ricardo Paz Vital
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
10 years, 10 months
[PATCH] bug fix: Set full path to guest page file in guest tab
by Aline Manera
From: Aline Manera <alinefm(a)br.ibm.com>
Commit 6bcbb3f0 changed how the guest tab is loaded to be more robust, but it
was using relative path to guest page which causes errors when Kimchi is
running outside its top directory.
So use full path to avoid those kind of problems.
Signed-off-by: Aline Manera <alinefm(a)br.ibm.com>
---
src/kimchi/root.py | 8 +++++++-
ui/pages/tabs/guests.html.tmpl | 2 +-
2 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/src/kimchi/root.py b/src/kimchi/root.py
index c3d471e..ce4a49c 100644
--- a/src/kimchi/root.py
+++ b/src/kimchi/root.py
@@ -75,8 +75,14 @@ class Root(Resource):
@cherrypy.expose
def tabs(self, page, **kwargs):
+ # In order to load the Guests tab, we also use Cheetah in the tab
+ # template to save the delay of the extra get to the guest page
+ # For that, the tab template needs to know the correct path to ui files
+ data = {}
+ data['ui_dir'] = paths.ui_dir
+
if page.endswith('.html'):
- return template.render('tabs/' + page, None)
+ return template.render('tabs/' + page, data)
raise cherrypy.HTTPError(404)
diff --git a/ui/pages/tabs/guests.html.tmpl b/ui/pages/tabs/guests.html.tmpl
index e2ab173..8b530c7 100644
--- a/ui/pages/tabs/guests.html.tmpl
+++ b/ui/pages/tabs/guests.html.tmpl
@@ -52,7 +52,7 @@
$_("No guests found.")
</div>
<script id="guest-tmpl" type="kimchi/template">
- $ht(file="ui/pages/guest.html.tmpl",searchList=[self,{'lang':$lang}])
+ $ht(file=$data.ui_dir + "/pages/guest.html.tmpl", searchList=[self, {'lang':$lang}])
</script>
<script type="text/javascript">
kimchi.guest_main();
--
1.7.10.4
10 years, 10 months
[PATCH 0/3 RFC] Refactor exception
by Aline Manera
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
10 years, 10 months
[PATCH V3] Avoid useless libvirt error log produced by featuretest
by Aline Manera
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
10 years, 10 months
[RFC] Manage guest CDROM devices
by Rodrigo Trujillo
Reference:
https://github.com/kimchi-project/kimchi/wiki/Todo-1.2
https://github.com/kimchi-project/kimchi/wiki/customize-VM
Royce has created the structure to add/list/lookup cdrom devices in the
guests.
There is a patch in the list (still under revision) with the code:
" Kimchi-devel] [PATCH 0/5] cdrom: support add and query cdrom "
This RFC aims to continue the second part of this work and modify the
API to
allow user to change (UPDATE/POST) attached cd ISOs and delete (DELETE)
cdrom devices.
If necessary I can continue the Royces work.
Aline has suggested to use the API as "/vms/<name>/storages" :
"""
. . . Maybe we can use /vms/<name>/storages
That way we can use the same API to add/remove different kind of
storages to the vm: cdrom, scsi disk, ide disk, etc ...
"""
This is the first decision here
(1) Use api as follow ?
(I propose to use API params to differentiate the storages, like
'?type=cdrom')
**URI:** /vms/*:name*/storages
* **GET**: Retrieve all storages attached to the VM
* **POST**: Attatch new storage to specified virtual machine.
* name : The name of the storage in the VM.
* type: The type of the storage: cdrom, disk
* path *(optional)*: Path of ISO or DISK.
### Sub-resource: storage
**URI:** /vms/*:name*/storage/*:name*
* **GET**: Retrieve the storage information
* path: Path of the storage
* type: Type of the storage
* **PUT**: Update storage information
* name *(optional)*: The name of the storage in the VM.
* path *(optional)*: Path of ISO or DISK.
* **DELETE**: Remove the storage
Examples:
UPDATE {'path': ''} /vms/vm-1/storage/cdrom-1--> to eject the iso
UPDATE {'path': '/root/ubuntu.iso'} /vms/vm-1/storage/cdrom-1-->to
change or insert a media
POST {'path':'abcd', 'bus': 'ide', 'name': 'cdrom-2'} /vms/vm-1/storage
--> to attach a new cdrom
DELETE {} /vms/vm-1/cdroms/cdrom-1-->to detach a cdrom
(2) Should be possible to add and remove storages with the guest running
? (Like hot plug)
Does libvirt provide this ?
(3) The new attached isos should be shown in the guests like changing a CD ?
(4) The specification mention tuning of the devices. Should tuning be
always done in the background, or
allow users to specify tuning parameters ?
Regards,
Rodrigo Trujillo
10 years, 10 months
[PATCH] bug fix: Fix shallow scan broken after model refactoring
by Aline Manera
From: Aline Manera <alinefm(a)br.ibm.com>
The shallow scan is always return an empty array as it is trying to
access the pool name as a libvirt pool object.
Fix it to restore shallow scan functionality.
Signed-off-by: Aline Manera <alinefm(a)br.ibm.com>
---
src/kimchi/model/storagevolumes.py | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/src/kimchi/model/storagevolumes.py b/src/kimchi/model/storagevolumes.py
index 7ff570b..8440a76 100644
--- a/src/kimchi/model/storagevolumes.py
+++ b/src/kimchi/model/storagevolumes.py
@@ -160,8 +160,9 @@ class IsoVolumesModel(object):
pools = conn.listStoragePools()
pools += conn.listDefinedStoragePools()
- for pool in pools:
+ for pool_name in pools:
try:
+ pool = StoragePoolModel.get_storagepool(pool_name, self.conn)
pool.refresh(0)
volumes = pool.listVolumes()
except InvalidOperation:
@@ -169,7 +170,7 @@ class IsoVolumesModel(object):
continue
for volume in volumes:
- res = self.storagevolume.lookup(pool, volume)
+ res = self.storagevolume.lookup(pool_name, volume)
if res['format'] == 'iso':
res['name'] = '%s' % volume
iso_volumes.append(res)
--
1.7.10.4
10 years, 10 months
RFC: "Add disk to existing logical storage pool"
by Daniel H Barboza
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!
10 years, 10 months
[PATCH 0/3] Fix permission of cdrom files
by Aline Manera
From: Aline Manera <alinefm(a)br.ibm.com>
It is a continuation of Sheldon's work.
What I added:
- Run setfacl to add read permission to user who own the file
- Fix permission of cdrom file before starting the virtual machine
Aline Manera (2):
Remove kvmusertests.py
Make sure ISO files have read permission while starting VM
ShaoHe Feng (1):
Add a method to fix read permission on ISO files
src/kimchi/kvmusertests.py | 66 --------------------------------------------
src/kimchi/model/vms.py | 10 ++++++-
src/kimchi/utils.py | 9 ++++--
3 files changed, 16 insertions(+), 69 deletions(-)
delete mode 100644 src/kimchi/kvmusertests.py
--
1.7.10.4
10 years, 10 months
[PATCH] Fix get vms list function name
by Rodrigo Trujillo
The host shutdown function was using a function that does not exist
in the class.
Signed-off-by: Rodrigo Trujillo <rodrigo.trujillo(a)linux.vnet.ibm.com>
---
src/kimchi/model/host.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/kimchi/model/host.py b/src/kimchi/model/host.py
index d068614..816e2e8 100644
--- a/src/kimchi/model/host.py
+++ b/src/kimchi/model/host.py
@@ -66,7 +66,7 @@ class HostModel(object):
def shutdown(self, args=None):
# Check for running vms before shutdown
- running_vms = self.vms_get_list_by_state('running')
+ running_vms = self._get_vms_list_by_state('running')
if len(running_vms) > 0:
raise OperationFailed("Shutdown not allowed: VMs are running!")
kimchi_log.info('Host is going to shutdown.')
--
1.8.5.3
10 years, 10 months
[PATCH] Packaging: add the basemodel.py to src/kimchi/Makefile.am
by Paulo Vital
src/kimchi/basemodel.py is a common model builder and is imported by several models from src/kimchi/model, and it is not in src/kimchi/Makefile.am, so make install, make dist and make rpm do not install or package this file.
Signed-off-by: Paulo Vital <pvital(a)linux.vnet.ibm.com>
---
src/kimchi/Makefile.am | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/kimchi/Makefile.am b/src/kimchi/Makefile.am
index ffcdcad..855eb9e 100644
--- a/src/kimchi/Makefile.am
+++ b/src/kimchi/Makefile.am
@@ -26,6 +26,7 @@ kimchi_PYTHON = \
__init__.py \
asynctask.py \
auth.py \
+ basemodel.py \
cachebust.py \
disks.py \
distroloader.py \
--
1.8.3.1
10 years, 10 months
