[PATCH 0/3] Add disks to LVM pool backend
by Daniel Barboza
From: Daniel Henrique Barboza <danielhb(a)linux.vnet.ibm.com>
This patch series implements the backend changes to allow disks/partitions to
be added to an existing LVM (logical) pool.
The process, as discussed previously in kimchi mailing list, is to use
'vgextend' and 'virsh pool-refresh' commands to add the disks and then
refresh the pool.
It is also worth noticing that the existing data from the disks/partitions
being added to the pool will be erased/lost.
To test the patch:
$ curl -u root -H 'Content-type: application/json' -H 'Accept: application/json' -X PUT localhost:8000/storagepools/<pool_name> -d '{"disks": ["/path/to/disk1", "/path/to/disk2"] }'
Tip: to test the patch over and over with the same pool and disks
without the need to destroy/create the pool:
$ vgreduce <pool_name> disk1 disk2
$ virsh pool-refresh <pool_name>
The above commands will restore the logical pool to its previous state,
before adding disks 'disk1' and 'disk2'
Daniel Henrique Barboza (3):
Add disks to LVM pool: control and model changes
Add disks to LVM pool: API changes
Add disks to LVM pool: mockmodel changes
docs/API.md | 5 ++++-
src/kimchi/control/storagepools.py | 2 +-
src/kimchi/mockmodel.py | 12 ++++++------
src/kimchi/model/storagepools.py | 35 +++++++++++++++++++++++++++--------
4 files changed, 38 insertions(+), 16 deletions(-)
--
1.8.3.1
11 years, 1 month
[PATCH 0/5] Host's repositories management support
by Paulo Vital
WIP: This V1 supports only YUM. APT will come in V2 due to finish tests.
This patch set provides support to host's repositories management operations.
At this point, an agnostic class is providing support to backend and
REST API operations. In addition, YUM (for RHEL, Fedora, SLES and OpenSuse)
and APT (for Debian and Ubuntu) specific classes are provided to support the
operation os each software update system.
To test the backend execute the following commands:
$ cd tests
$ sudo ./run_tests.sh test_model.ModelTests.test_repository_create
$ sudo ./run_tests.sh test_model.ModelTests.test_repository_update
$ sudo ./run_tests.sh test_model.ModelTests.test_repository_disable_enable
To test the REST API, execute the following commands (all them are agnostic of the
host's distro):
1) Get list of all repositories enabled in the host:
$ curl -u <USER> -H 'Content-type: application/json' -H 'Accept: application/json' http://localhost:8000/host/repositories/ -X GET
2) Create a new repository:
$ curl -u <USER> -H 'Content-type: application/json' -H 'Accept: application/json' http://localhost:8000/host/repositories/ -X POST -d'
{
"repo_id": "fedora-fake",
"baseurl": "http://www.fedora.org",
"gpgkey": "file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-fake-19"
}
'
3) Get information from a specific repository:
$ curl -u <USER> -H 'Content-type: application/json' -H 'Accept: application/json' http://localhost:8000/host/repositories/fedora-fake
4) Update a specific repository:
$ curl -u <USER> -H 'Content-type: application/json' -H 'Accept: application/json' http://localhost:8000/host/repositories/fedora-fake -X PUT -d'
{
"repo_id":"fedora-fake",
"repo_name":"Fedora 19 FAKEs",
"baseurl": "http://www.fedora.org/downloads"
}
'
5) Disable a specific repository:
$ curl -u <USER> -H 'Content-type: application/json' -H 'Accept: application/json' http://localhost:8000/host/repositories/fedora-fake/disable -X POST -d ''
6) Enable a specific repository:
$ curl -u <USER> -H 'Content-type: application/json' -H 'Accept: application/json' http://localhost:8000/host/repositories/fedora-fake/enable -X POST -d ''
7) Delete a specific repository:
$ curl -u <USER> -H 'Content-type: application/json' -H 'Accept: application/json' http://localhost:8000/host/repositories/fedora-fake -X DELETE
Paulo Vital (5):
Host's repositories management: Update API.md
Host's repositories management: Update REST API
Host's repositories management: Update backend.
Host's repositories management: Update Makefile
Host's repositories management: Update test-cases.
Makefile.am | 1 +
docs/API.md | 80 +++++++++
src/kimchi/API.json | 63 +++++++
src/kimchi/Makefile.am | 1 +
src/kimchi/control/host.py | 21 +++
src/kimchi/mockmodel.py | 34 ++++
src/kimchi/model/host.py | 50 +++++-
src/kimchi/repositories.py | 418 +++++++++++++++++++++++++++++++++++++++++++++
tests/test_model.py | 99 +++++++++++
tests/test_rest.py | 32 ++++
10 files changed, 798 insertions(+), 1 deletion(-)
create mode 100644 src/kimchi/repositories.py
--
1.8.3.1
11 years, 1 month
[RFC]: for template cloning.
by Sheldon
template cloning:
<https://github.com/kimchi-project/kimchi/wiki/template-cloning-and-custom...>
|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
11 years, 1 month
[PATCH] Bug fix #309 - network: Unable to create vlan tagged on Ubuntu v2
by Ramon Medeiros
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
11 years, 1 month
Discussion: 312 - LVM VG is left when removing logical storage pool
by Ramon Medeiros
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
11 years, 1 month
[PATCH] Fix controller base code: Update function is not using model_args
by Rodrigo Trujillo
The model_args variable is used to pass information to functions.
Specially in functions of sub-collections and sub-resources, it is used
to pass the main collections and resources names/classes. The wrapper
update function from control base was not using model_args, then some
resouces might miss this information.
Signed-off-by: Rodrigo Trujillo <rodrigo.trujillo(a)linux.vnet.ibm.com>
---
src/kimchi/control/base.py | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/kimchi/control/base.py b/src/kimchi/control/base.py
index f50ff6e..8cee06d 100644
--- a/src/kimchi/control/base.py
+++ b/src/kimchi/control/base.py
@@ -151,7 +151,8 @@ class Resource(object):
error = "%s are not allowed to be updated" % invalids
raise cherrypy.HTTPError(405, error)
- ident = update(self.ident, params)
+ args = self.model_args + [params]
+ ident = update(*args)
if ident != self.ident:
uri_params = list(self.model_args[:-1])
uri_params += [urllib2.quote(ident.encode('utf8'))]
--
1.8.5.3
11 years, 1 month
[PATCH] Add os_arch field to distros
by Christy Perez
Adding an os_arch field to the distro so we can filter distros
on systems with other architectures. This prevents a user from
creating unusable templates.
Signed-off-by: Christy Perez <christy(a)linux.vnet.ibm.com>
---
src/distros.d/debian.json | 1 +
src/distros.d/fedora.json | 3 +++
src/distros.d/gentoo.json | 1 +
src/distros.d/opensuse.json | 1 +
src/distros.d/ubuntu.json | 2 ++
src/kimchi/distroloader.py | 3 ++-
6 files changed, 10 insertions(+), 1 deletion(-)
diff --git a/src/distros.d/debian.json b/src/distros.d/debian.json
index 0a00ae0..0754cf3 100644
--- a/src/distros.d/debian.json
+++ b/src/distros.d/debian.json
@@ -2,6 +2,7 @@
{
"name": "debian-Wheezy",
"os_distro": "debian",
+ "os_arch": "x86_64",
"os_version": "7.2.0",
"path": "http://cdimage.debian.org/debian-cd/7.2.0-live/amd64/iso-hybrid/debian-li..."
}
diff --git a/src/distros.d/fedora.json b/src/distros.d/fedora.json
index b4a82eb..d78205b 100644
--- a/src/distros.d/fedora.json
+++ b/src/distros.d/fedora.json
@@ -2,18 +2,21 @@
{
"name": "fedora-18",
"os_distro": "fedora",
+ "os_arch": "x86_64",
"os_version": "18",
"path": "http://fedora.mirrors.tds.net/pub/fedora/releases/18/Live/x86_64/Fedora-1..."
},
{
"name": "fedora-19",
"os_distro": "fedora",
+ "os_arch": "x86_64",
"os_version": "19",
"path": "http://fedora.mirrors.tds.net/pub/fedora/releases/19/Live/x86_64/Fedora-L..."
},
{
"name": "fedora-20",
"os_distro": "fedora",
+ "os_arch": "x86_64",
"os_version": "20",
"path": "http://fedora.mirrors.tds.net/pub/fedora/releases/20/Live/x86_64/Fedora-L..."
}
diff --git a/src/distros.d/gentoo.json b/src/distros.d/gentoo.json
index dffeadf..fa5e55b 100644
--- a/src/distros.d/gentoo.json
+++ b/src/distros.d/gentoo.json
@@ -2,6 +2,7 @@
{
"name": "gentoo-20131010",
"os_distro": "gentoo",
+ "os_arch": "x86_64",
"os_version": "20131010",
"path": "http://distfiles.gentoo.org/releases/amd64/autobuilds/current-iso/install..."
}
diff --git a/src/distros.d/opensuse.json b/src/distros.d/opensuse.json
index ff03f41..315cf78 100644
--- a/src/distros.d/opensuse.json
+++ b/src/distros.d/opensuse.json
@@ -2,6 +2,7 @@
{
"name": "opensuse-12.3",
"os_distro": "opensuse",
+ "os_arch": "x86_64",
"os_version": "12.3",
"path": "http://suse.mirrors.tds.net/pub/opensuse/distribution/12.3/iso/openSUSE-1..."
}
diff --git a/src/distros.d/ubuntu.json b/src/distros.d/ubuntu.json
index 4ad6a19..fbd931a 100644
--- a/src/distros.d/ubuntu.json
+++ b/src/distros.d/ubuntu.json
@@ -2,12 +2,14 @@
{
"name": "Ubuntu 13.04 (Raring Ringtail)",
"os_distro": "ubuntu",
+ "os_arch": "x86_64",
"os_version": "13.04",
"path": "http://ubuntu-releases.cs.umn.edu/13.04/ubuntu-13.04-desktop-amd64.iso"
},
{
"name": "Ubuntu 13.10 (Saucy Salamander)",
"os_distro": "ubuntu",
+ "os_arch": "x86_64",
"os_version": "13.10",
"path": "http://ubuntu-releases.cs.umn.edu/13.10/ubuntu-13.10-desktop-amd64.iso"
}
diff --git a/src/kimchi/distroloader.py b/src/kimchi/distroloader.py
index 98fd764..d8e76bf 100644
--- a/src/kimchi/distroloader.py
+++ b/src/kimchi/distroloader.py
@@ -51,9 +51,10 @@ class DistroLoader(object):
raise OperationFailed(msg)
def get(self):
+ arch = os.uname()[4]
all_json_files = glob.glob("%s/%s" % (self.location, "*.json"))
distros = []
for f in all_json_files:
distros.extend(self._get_json_info(f))
- return dict([(distro['name'], distro) for distro in distros])
+ return dict([(distro['name'], distro) for distro in distros if distro['os_arch'] == arch])
--
1.8.5.3
11 years, 1 month
[RFC V2] Host's repositories support
by Paulo Ricardo Paz Vital
Hello guys. Here is the v2 of this RFC.
v2 -> v1:
* Changed repo_id to be optional in collection POST. Back end will
create one if user doesn't provide one;
* Dropped repo_name from collection POST. This will be automatically
inferred by the baseurl;
* Dropped enabled from collection POST. Each repository added by user
will be disabled by default. User needs enabled it after the creation;
* Dropped gpgcheck from collection POST. This will be automatically
inferred by the presence of a gpgkey;
* Dropped repo_type from resource GET;
* Changed enabled to be required in resource GET;
v1:
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 *(optional)*: Unique repository name for each repository,
one word.
* 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.
* 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_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: 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
11 years, 1 month
[PATCH] Fix debug report - NEED TESTS
by Rodrigo Trujillo
In Fedora 20, the sosreport tool saves the report file in /var/tmp, which
crashes kimchi. The --tmp-dir options should be the right approach but it
is crashing in Fedora 20 (RHEL works). While waiting sosreport fix, this
patch feache the file path and name from sosreport output.
This code works on Fedora 20. Need more tests in Ubuntu(s), RHEL and older
Fedora.
Rodrigo Trujillo (1):
Fix host debug report for Fedora 20
src/kimchi/model/debugreports.py | 40 +++++++++++++++++-----------------------
1 file changed, 17 insertions(+), 23 deletions(-)
--
1.8.5.3
11 years, 1 month
