- Kimchi-devel - oVirt List Archives

[RFC] About the way Kimchi deals with services (libvirt, nfs, etc)
by Daniel H Barboza 17 Feb '14

17 Feb '14

Hello all, I am working in a nfs related bug where kimchi hungs up if the nfs service stops for some reason while creating a NFS pool. I have a very similar situation Power-only with another service. My idea at first was to verify the service status every time we request a specific service. This could work for actions that requires specific services, such as NFS. However, for this approach make sense, we should verify the status of libvirt for all the operations that depend of it. We would flood the code with "if (libvirt.service is active) " conditionals do to pretty much anything. Thus, I am creating this RFC to ask you: how can we handle Kimchi dependencies on external services in a neat, clean way? Mark suggested to use systemd, for example. Thanks!

2 1

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

17 Feb '14

Changes: v4: Use flag 0 in some libvirt functions v3: rebase with new model. v2: 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/networks.py | 25 ++++++++++++------------- 1 file changed, 12 insertions(+), 13 deletions(-) -- 1.8.3.1

2 2

[PATCH] Fix Software Update rebase issue.
by Paulo Vital 17 Feb '14

17 Feb '14

During the last merge/rebase to apply Software Update feature to the code, an important line was removed. This fix is adding it again and enabling the code to list all host's package updates. Signed-off-by: Paulo Vital <pvital(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 68028b2..ea10370 100644 --- a/src/kimchi/model/host.py +++ b/src/kimchi/model/host.py @@ -262,7 +262,7 @@ class DeviceModel(object): class PackagesUpdateModel(object): def __init__(self, **kargs): - + self.host_swupdate = SoftwareUpdate() self.objstore = kargs['objstore'] self.task = TaskModel(**kargs) -- 1.8.3.1

2 1

[PATCH 0/7 V4] Host's software update support
by Aline Manera 17 Feb '14

17 Feb '14

From: Aline Manera <alinefm(a)br.ibm.com> Hi all, I helped Paulo to apply the suggestions made on reviews and I am resending his patches. Following are the modifications I made. V3 -> V4 - Update API.md - fix type and add the task resource will be returned when doing an update operation - Use cherrypy.expose to expose the update() handler for PackagesUpdate(Collection) - Return a task resource while performing an update operation That way UI can provide good progress messages to the user - Use apt-get command to update Ubuntu system instead of apt binding python to be able to get the output in live time. - Adjust errors messages according refactor exception patches - Expose update tool in Capabilities that way UI can disable update button when no supported tool is found. - Add tests for test_rest.py ------------------------------------------------------------------------------ This patch set provides support to host's software update operations. To test the backend (ONLY mockmodel) execute the following commands: $ cd tests $ sudo ./run_tests.sh test_mockmodel.MockModelTests.test_packages_update To test the REST API, execute the following commands (all them are agnostic of the host's distro): 1) Get list of all packages to be updated in the host: $ curl -H 'Content-type: application/json' -H 'Accept: application/json' http://localhost:8000/host/packagesupdate/ -X GET 2) Update the host system: $ curl -H 'Content-type: application/json' -H 'Accept: application/json' http://localhost:8000/host/packagesupdate/update -X POST -d '' V2 -> V3: * Fixed indent and wrong bullets on docs/API.md * Changed to use Collection and Resource * Removed unnecessary 'exposed' * PEP8 compatibility on mockmodel.py * Removed debug prints from swupdate.py * Fixed indent in swupdate.py * Usage of utils.run_command() to execute Zypper update * Updated swupdate.py and mockmodel.py to make consistent with docs/API.md * Usage of Task element in mockmodel.py * Created test case in test_mockmodel.py V1 -> V2: * rebased to use new model framework * added SLES as Zypper supported distro * PEP8 compatibility * changed import sentences * use of run_command() from utils.py to execute shell commands * usage of Task element to return update status V1: At this point, an agnostic class is providing support to backend and REST API operations. In addition, YUM (for RHEL and Fedora), APT (for Debian and Ubuntu) and ZYPPER (for OpenSuse) specific classes are provided to support the operation os each software update system. Aline Manera (2): host update: Update po files host update: Expose update tool Paulo Vital (5): Host's software update: Update API.md Host's software update: Update REST API Host's software update: Update backend. Host's software update: Update Makefile Host's software update: Update test cases. Makefile.am | 1 + docs/API.md | 35 +++++++ po/en_US.po | 29 +++++- po/kimchi.pot | 29 +++++- po/pt_BR.po | 29 +++++- po/zh_CN.po | 29 +++++- src/kimchi/Makefile.am | 1 + src/kimchi/control/host.py | 29 ++++++ src/kimchi/i18n.py | 5 + src/kimchi/mockmodel.py | 51 +++++++++ src/kimchi/model/config.py | 10 +- src/kimchi/model/host.py | 45 +++++++- src/kimchi/swupdate.py | 247 ++++++++++++++++++++++++++++++++++++++++++++ tests/test_mockmodel.py | 15 +++ tests/test_rest.py | 28 +++++ 15 files changed, 577 insertions(+), 6 deletions(-) create mode 100644 src/kimchi/swupdate.py -- 1.7.10.4

5 15

[PATCH RFC] doc: Add DITA help pages
by Crístian Viana 17 Feb '14

17 Feb '14

Hi! I am starting to create this patch to add documentation pages to Kimchi. The idea is to have the help content in XML files in a help-specific format (DITA) which will be processed, using XSTL, to generate the HTML pages. I am sending three sample DITA files (Storage, Templates and Virtual Machines), the XSL file and also the generated HTML files for that documentation. Please note that the HTML files will not be added to the final versions, they will be generated dynamically (e.g. via Makefile) when building the distribution package. The command "xsltproc <XSL file> <DITA file>" generates the HTML output corresponding to the DITA file processed by the XSL file. The current version of the XSL file generates a simple HTML output, but we will enhance it over time. And, obviously, we can apply a CSS file to make it look pretty. Instead of preprocessing the DITA files to generate the HTML files statically, there is also the option to process them in the client side using the client's browser. A single line in the DITA file can tell the browser to do so. Most modern browsers are able to process XML files linked to an XSL file dynamically. However, for security reasons, Google Chrome does not allow a local file to load another local file (i.e. the DITA file cannot load the XSL file), so this client-side process does not work on Chrome locally. When we improve this patch and integrate it to Kimchi, when the files will be served using a web server, I believe Chrome will transform them correctly. But that is only another way of displaying the HTML files; we can always process them statically to generate the HTML files. We can decide later which approach we will use. Keep in mind that this patch is not finished yet. Any feedback is welcome. Crístian Viana (1): doc: Add DITA help pages dita/dita.xsl | 23 +++++++++++++++++++++ dita/kimhstor.dita | 45 ++++++++++++++++++++++++++++++++++++++++ dita/kimhstor.html | 31 ++++++++++++++++++++++++++++ dita/kimhtempl.dita | 59 +++++++++++++++++++++++++++++++++++++++++++++++++++++ dita/kimhtempl.html | 38 ++++++++++++++++++++++++++++++++++ dita/kimhvirtm.dita | 47 ++++++++++++++++++++++++++++++++++++++++++ dita/kimhvirtm.html | 30 +++++++++++++++++++++++++++ 7 files changed, 273 insertions(+) create mode 100644 dita/dita.xsl create mode 100644 dita/kimhstor.dita create mode 100644 dita/kimhstor.html create mode 100644 dita/kimhtempl.dita create mode 100644 dita/kimhtempl.html create mode 100644 dita/kimhvirtm.dita create mode 100644 dita/kimhvirtm.html -- 1.8.5.3

2 3

[PATCH 0/4] Add DITA help pages
by Crístian Viana 17 Feb '14

17 Feb '14

This is the difference between this and the previous patchset (v1): - The *.dita files have more meaningful names. - The Makefile reads all *.dita/*.html files dynamically (no need to list each file). Crístian Viana (4): doc: Add DITA help pages doc: Add help files to dist packages doc: Export the help pages to cherrypy doc: Ignore the generated files .gitignore | 1 + configure.ac | 1 + contrib/DEBIAN/control.in | 2 +- contrib/kimchi.spec.fedora.in | 5 ++++ contrib/kimchi.spec.suse.in | 5 ++++ docs/README.md | 7 ++--- src/kimchi/server.py | 5 ++++ ui/pages/Makefile.am | 2 +- ui/pages/help/Makefile.am | 30 ++++++++++++++++++++++ ui/pages/help/dita-help.xsl | 24 ++++++++++++++++++ ui/pages/help/guests.dita | 47 ++++++++++++++++++++++++++++++++++ ui/pages/help/storage.dita | 45 +++++++++++++++++++++++++++++++++ ui/pages/help/templates.dita | 59 +++++++++++++++++++++++++++++++++++++++++++ 13 files changed, 228 insertions(+), 5 deletions(-) create mode 100644 ui/pages/help/Makefile.am create mode 100644 ui/pages/help/dita-help.xsl create mode 100644 ui/pages/help/guests.dita create mode 100644 ui/pages/help/storage.dita create mode 100644 ui/pages/help/templates.dita -- 1.8.5.3

2 5

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

17 Feb '14

Changes: v3: rebase with new model. v2: 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/networks.py | 22 +++++++++++----------- 1 file changed, 11 insertions(+), 11 deletions(-) -- 1.8.3.1

2 5

[PATCH V2 0/4] template cloning
by shaohef＠linux.vnet.ibm.com 17 Feb '14

17 Feb '14

From: ShaoHe Feng <shaohef(a)linux.vnet.ibm.com> V1 -> V2 clone will just "duplicate the template" with all default in new 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. ShaoHe Feng (4): clone template: update API.md clone template: update controller clone template: update model and mockmodel clone template: update test case docs/API.md | 4 +++- src/kimchi/control/templates.py | 1 + src/kimchi/mockmodel.py | 17 +++++++++++++++++ src/kimchi/model/templates.py | 17 +++++++++++++++++ tests/test_model.py | 18 ++++++++++++++++++ tests/test_rest.py | 15 +++++++++++++++ 6 files changed, 71 insertions(+), 1 deletion(-) -- 1.8.4.2

3 9

[PATCH v2 0/4] Initial authorization support
by Leonardo Garcia 16 Feb '14

16 Feb '14

From: Leonardo Garcia <lagarcia(a)br.ibm.com> Current, in Kimchi, no real authorization support is implemented. We do have authentication support, and, apart from that, no other kind of control is provided in order to authorize or not a Kimchi user to access its features. IOW, today, a user can access everything or nothing Kimchi provides. This patch series tries to implement an initial support for user authorization in Kimchi back-end. Some has already been discussed in the community about this feature [1, 2, 3]. The RFC proposed in [2] and the WIP sent in [3] seems to be diverging from the simple proposal first put in [1] and sustained in replies to [2]. So, the purpose of this patch series is to try to be, as much as possible, compliant to [1] and keep things as simple as possible. In summary, that means we will identify users as having sudo rights or not. This information will be passed to the UI by the /login REST API during logging in. With this information the UI will be able to decide which components (tabs, buttons, etc.) it will show to the user. Additionally, an infrastructure was also built in order to identify a REST API as one that needs sudo rights or not to be accessed. So, if the UI, for some reason, tries to access a REST API in a session whose user does not have sudo rights, the REST API call will return HTTP error 401. [1] https://github.com/kimchi-project/kimchi/wiki/authorization [2] http://lists.ovirt.org/pipermail/kimchi-devel/2014-January/001218.html [3] http://lists.ovirt.org/pipermail/kimchi-devel/2014-January/001898.html Leonardo Garcia (4): Code cleanup. Find out user groups and sudo status during login. Enhance UrlSubNode decorator and kimchiauth tool to check for sudo rights. Limit user access to REST API /host. src/kimchi/auth.py | 85 ++++++++++++++++++++++++++++++++++++--------- src/kimchi/control/host.py | 2 +- src/kimchi/control/utils.py | 9 ++++- src/kimchi/root.py | 4 +-- src/kimchi/server.py | 7 +++- 5 files changed, 86 insertions(+), 21 deletions(-) -- 1.8.5.3

2 6

[PATCH 0/5 V6] CDROM Management
by Aline Manera 14 Feb '14

14 Feb '14

From: Aline Manera <alinefm(a)br.ibm.com> Hi all, I helped Daniel to apply the suggestions made on reviews and I am resending his patches. v6: - Addressed Royce's comments made on v5 ------------------------------------------------------------------------------ This patch set implements host storage devices management. It implements full CDROM device add, remove and update functionality. It implements basic Disk functionalities. Changelog: v5: - Addressed Aline's comments from her review in v4 v4: - Imports fix, author fix, pep8 fixes - Cut off HDD support - lxml changes in model/vms.py - test_model.py changes - add, update and remove cdroms - existing device name verification in model/vms.py - changed the code to use the new exception model V3: - Using lxml to parse the XML information in model/vms.py - Addressed comments/suggestions from the ML in other files V2: - Add devices to mockmodel and add test cases to rest API - Assign name automatically to new devices, if not passed by user - Fix minor errors To test this contribution: - get info of all storages (cdrom and disks) of a VM curl -u <user> -H "Content-Type: application/json" -H "Accept: application/json" http://localhost:8000/vms/<vm_name>/storages -X GET - add a new cdrom to a VM curl -u <user> -H "Content-Type: application/json" -H "Accept: application/json" http://localhost:8000/vms/<vm_name>/storages -X POST -d'{"type": "cdrom", "path": "<path_to_iso>"}' - get specific info from cdrom device curl -u <user> -H "Content-Type: application/json" -H "Accet: application/json" http://localhost:8000/vms/<vm_name>/storages/<dev_name> -X GET - delete a cdrom device from a VM curl -u <user> -H "Content-Type: application/json" -H "Accet: application/json" http://localhost:8000/vms/<vm_name>/storages/<dev_name> -X DELETE - update a cdrom device from a VM curl -u <user> -H "Content-Type: application/json" -H "Accet: application/json" http://localhost:8000/vms/<vm_name>/storages/<dev_name> -X PUT -d '{"path":<path_to_iso>}' Daniel Henrique Barboza (2): CDROM Management: API.md and externalized error messages CDROM Management: changes in tests/test_model.py Rodrigo Trujillo (3): CDROM Management: Update controller and API.json for guest storages CDROM Management: Devices management model implementation CDROM Management: Guest vm storage devices mockmodel and rest api test cases docs/API.md | 21 ++++ po/en_US.po | 70 +++++++++++- po/kimchi.pot | 70 +++++++++++- po/pt_BR.po | 70 +++++++++++- po/zh_CN.po | 70 +++++++++++- src/kimchi/API.json | 37 +++++++ src/kimchi/control/vm/storages.py | 49 ++++++++ src/kimchi/i18n.py | 12 ++ src/kimchi/mockmodel.py | 70 +++++++++++- src/kimchi/model/vmstorages.py | 221 +++++++++++++++++++++++++++++++++++++ tests/test_model.py | 61 ++++++++++ tests/test_rest.py | 75 +++++++++++++ 12 files changed, 817 insertions(+), 9 deletions(-) create mode 100644 src/kimchi/control/vm/storages.py create mode 100644 src/kimchi/model/vmstorages.py -- 1.7.10.4

3 17