[RFC] listing of ovs bridges
by Suresh Babu Angadi
New API:
SimpleCollection: OVSBridges
URI: /plugins/kimchi/ovsbridges
Methods:
GET: Retrieve list of OVS bridges of the host
Back end changes:
Currently ginger plugin has full fledged ovs functionality. So best bet
would be to have listing of ovs bridges to gingerbase which can be used
by kimchi and ginger apis.
--
Regards,
Suresh Babu Angadi
7 years, 8 months
[WIP][Wok 0/2] Use javascript libraries from rpms, not hardcoded
by Ramon Medeiros
This isn't a patch yet since the commit "Change configuration files" are not working well.
I need to change ui/libs/Makefile.am to set SUBDIRS variable (that trigger javascript hardcoded libs build) and
change ui/pages/Makefile.am, to copy the template according to distro.
Can you guys help me on makefile syntax?
Ramon Medeiros (2):
Use javascript libraries from rpms
Change configuration files
configure.ac | 11 ++
docs/fedora-deps.md | 4 +-
docs/ubuntu-deps.md | 3 +-
src/wok/config.py.in | 22 +++
ui/libs/Makefile.am | 10 +-
ui/pages/Makefile.am | 9 ++
ui/pages/login.html.tmpl.fedora | 332 +++++++++++++++++++++++++++++++++++++++
ui/pages/login.html.tmpl.ubuntu | 332 +++++++++++++++++++++++++++++++++++++++
ui/pages/wok-ui.html.tmpl.fedora | 231 +++++++++++++++++++++++++++
ui/pages/wok-ui.html.tmpl.ubuntu | 231 +++++++++++++++++++++++++++
10 files changed, 1182 insertions(+), 3 deletions(-)
create mode 100644 ui/pages/login.html.tmpl.fedora
create mode 100644 ui/pages/login.html.tmpl.ubuntu
create mode 100644 ui/pages/wok-ui.html.tmpl.fedora
create mode 100644 ui/pages/wok-ui.html.tmpl.ubuntu
--
2.5.5
7 years, 8 months
[RFC] integrety: storage pool deactivate/undefine needs to consider vm usage #355
by Ramon Medeiros
Propose: do not deactive or undefine storage pool with vms being used.
Avoid undefine storage pool was already discussed.
Talking about deactive, we've got some questions:
1) Since the storage volume is available, the vm can run with storage
poll on or off. So, we are going only to avoid deactive pools that can
make storage volume unavailable, like nfs?
2) Or we are going to extend this rule to all storage pools?
--
Ramon Nunes Medeiros
Kimchi Developer
Linux Technology Center Brazil
IBM Systems & Technology Group
Phone : +55 19 2132 7878
ramonn(a)br.ibm.com
7 years, 8 months
[PATCH] [Kimchi 0/2] Wok #141 - Adjust imports and wording
by Lucio Correia
Depends on: [Wok 0/7] #141 - Log async tasks status
Lucio Correia (2):
Fix imports for add_task module change
Change wording of user log messages to reflect ongoing task
i18n.py | 18 +++++++++---------
mockmodel.py | 3 ++-
model/storagepools.py | 3 ++-
model/storagevolumes.py | 7 ++++---
model/vmhostdevs.py | 3 ++-
model/vms.py | 5 +++--
model/vmsnapshots.py | 2 +-
tests/test_model.py | 7 ++++---
tests/test_rest.py | 2 +-
9 files changed, 28 insertions(+), 22 deletions(-)
--
1.9.1
7 years, 8 months
[PATCH] [Wok 0/7] #141 - Log async tasks status
by Lucio Correia
IMPORTANT: This patchset requires its counterparts on all plugins to not break.
Lucio Correia (7):
Add get_plugin_from_uri() method to wok utils
Move add_task to asynctask to avoid cyclic import
Log AsyncTask start, success and failure
Sort user log records by microsecond
Put failure details into parenthesis
Update UI to show TASK statuses and search for TASK entries
Remove GET from advanced search form
src/wok/asynctask.py | 74 ++++++++++++++++++++++++++++-----
src/wok/i18n.py | 3 ++
src/wok/reqlogger.py | 27 ++++++++++--
src/wok/utils.py | 18 ++++----
ui/js/wok.user-log.js | 28 +++++++++----
ui/pages/tabs/settings-search.html.tmpl | 2 +-
6 files changed, 120 insertions(+), 32 deletions(-)
--
1.9.1
7 years, 8 months
[Wok] [RFC] Issue #122: Make AsyncTask stoppable.
by Paulo Ricardo Paz Vital
This is an RFC for "Make AsyncTask stoppable" in Wok (and any other plugin). The
main idea is give to user a way to stop a Task that is still running, cleaning
all references and processes and setting the Task status to "killed".
To do this, the Task API need to be modified, by implementing the DELETE method
in Task Resource. Said that, the API will look like:
### Resource: Task
**URI:** /tasks/*:id*
A task represents an asynchronous operation that is being performed by the
server.
**Methods:**
* **GET**: Retrieve the full description of the Task
* id: The Task ID is used to identify this Task in the API.
* status: The current status of the Task
* running: The task is running
* finished: The task has finished successfully
* failed: The task failed
+ * killed: The task was killed by user
* message: Human-readable details about the Task status
* target_uri: Resource URI related to the Task
+* **DELETE**: Delete the Task
* **POST**: *See Task Actions*
**Actions (POST):**
*No actions defined*
Since an AsyncTask is basic a thread running in the system and this thread can
execute a pure Python method or a background command (by using run_command()
from wok.utils), the developer must pass as argument to the add_task() a method
to be executed by the DELETE operation, called here as 'kill_cb'. With this
idea, the add_task() method and also the AsyncTask constructor will be like:
def add_task(target_uri, fn, objstore, kill_cb=None, opaque=None):
class AsyncTask(object):
def __init__(self, id, target_uri, fn, objstore, kill_cb=None, opaque=None):
If none kill_cb is passed, the task will not be able to stopped and an error (or
warning) message will be raised to user if DELETE operation is executed.
Otherwise, the kill_cb method will be executed by kill() method (responsible to
execute the DELETE operation) of AsyncTask class and its status set to 'killed'.
If you have any comments or suggestions, please feel free to reply to ML.
Thanks and bestr regards,
--
Paulo Ricardo Paz Vital
Linux Technology Center, IBM Systems
http://www.ibm.com/linux/ltc/
7 years, 8 months
[RFC] [Wok] Issue 141 - Track asynchronous tasks in user request log
by Lucio Correia
User Request Log needs to be improved to track some special requests of
Kimchi, Ginger and Gingerbase which, when successful, generate an
asynchronous task to do the actual job. Examples are cloning vms,
upgrading software and creating volumes.
Currently those requests are always logged as successful, even when the
generated asynchronous task fails for some reason.
My proposal to solve this issue is to:
1 - Change the wording of all existing user log messages for requests
that generate asynchronous task.
i.e.: change "Clone vm 'name'" to "Start to clone vm 'name'"
2 - Log a couple of additional entries in AsyncTask for each task executed:
- "Started Kimchi task ID 100: /plugins/kimchi/vms/name/clone" when
async task is started successfully
- "Successfully completed Kimchi task ID 100:
/plugins/kimchi/vms/name/clone" when async task works fine *or*
"Failure on Kimchi task ID 100: /plugins/kimchi/vms/name/clone
(KCHVM0001E failed to clone vm 'name')" when async task fails
3 - Backend/UI work to recognize the new type of entry:
{
"time": "11:49:55",
"date": "2016-08-12"
"zone": "BRT",
timezone continues the same
"req": "TASK",
use a specific "request" type for differentiation, i.e. TASK
"user": "",
"ip": "",
user and ip will be blank, since we are out of scope of the request
"status": 1002,
create 3 new status codes, say 1000 for "task started", 1001 for "task
completed successfully", 1002 for "task failed"
"app": "kimchi",
app will be informed by each plugin (backend change)
"msgCode": "WOKASYNC0002L",
async task log message Id, based on status
"detCode": "KCHVM00001E",
failed task details: original exception
}
>>>
{"target_uri": "/plugins/kimchi/vms/name/clone", "task_id": 100}
msgCode params
>>>
{"vm": "name"}
detCode params (optional)
>>>
Failure on Kimchi task ID 100: /plugins/kimchi/vms/name/clone
(KCHVM0001E failed to blah blah)
English log message
A corresponding log entry in text file for this example would be:
[2016-08-12 11:49:55 BRT] TASK 1002 kimchi Failure on Kimchi task ID
100: /plugins/kimchi/vms/name/clone (KCHVM0001E failed to clone vm 'name')
With this implementation it will be possible for an admin to see:
* how much time a task took/is taking to run
* which other requests were done between task start and finish
Thanks,
--
Lucio Correia
Software Engineer
IBM LTC Brazil
7 years, 8 months
RFC: Templates API changes for 'networks' attribute
by Suresh Babu Angadi
Hi All,
To support, attaching a physical interface to guest as macvtap or
attaching ovs bridge to guest without creating libvirt network, I
propose following changes to 'networks' attribute of templates josn.
current implementation:
'networks' attribute expects list of virtual network names
changes:
'networks': list of dictionary
type: can be direct, network or bridge
interface: name of physical interface(type=direct) or
ovs (type=bridge) or virtual network(type=direct)
mode(required if type=direct): bridge or vepa
for macvtap: type is direct and mode can be bridge or vepa
for ovs: type is bridge and mode is not required
for virtual network: type=network(current implementation)
Examples of network xml for attaching macvtap and ovs to guest without
libvirt:
OVS:
<interface type="bridge">
<source bridge="vswitch0"/>
<virtualport type="openvswitch"/>
<model type="virtio"/>
</interface>
macvtap with bridge mode:
<interface type="direct">
<source dev="eth0" mode="bridge"/>
<model type="virtio"/>
</interface>
macvtap with vepa mode:
<interface type="direct">
<source dev="bond0" mode="vepa"/>
<model type="virtio"/>
</interface>
--
Regards,
Suresh Babu Angadi
7 years, 8 months
[PATCH][Kimchi] Allow vm update graphics type
by Ramon Medeiros
Allow vm to choose between spice and vnc
Signed-off-by: Ramon Medeiros <ramonn(a)linux.vnet.ibm.com>
---
API.json | 6 ++++++
docs/API.md | 1 +
i18n.py | 2 +-
model/vms.py | 10 ++++++++++
4 files changed, 18 insertions(+), 1 deletion(-)
diff --git a/API.json b/API.json
index a3af02d..dca6840 100644
--- a/API.json
+++ b/API.json
@@ -377,6 +377,12 @@
"description": "Life time for the graphics password.",
"type": "number",
"error": "KCHVM0032E"
+ },
+ "type": {
+ "description": "Graphics type",
+ "type": "string",
+ "enum": ["spice", "vnc"],
+ "error": "KCHVM0054E"
}
}
},
diff --git a/docs/API.md b/docs/API.md
index 7bd677f..bb8049b 100644
--- a/docs/API.md
+++ b/docs/API.md
@@ -166,6 +166,7 @@ server.
* passwdValidTo *(optional)*: lifetime for the console password. When
omitted the password will be valid just
for 30 seconds.
+ * type *(optional)*: graphics type. VNC os Spice.
* cpu_info *(optional)*: CPU-specific information.
* maxvcpus *(optional)*: The maximum number of vCPUs that can be
assigned to the VM. If topology is specified, maxvcpus must be a
diff --git a/i18n.py b/i18n.py
index e8d9c05..183329e 100644
--- a/i18n.py
+++ b/i18n.py
@@ -106,7 +106,7 @@ messages = {
"KCHVM0051E": _("Cannot reset %(name)s. Virtual machine is already shut off."),
"KCHVM0052E": _("Boot order must be a list. Devices accepted: hd, cdrom, fd or network."),
"KCHVM0053E": _("Bootmenu must be boolean. Values accepted: true of false."),
-
+ "KCHVM0054E": _("Graphics type. Values accepted: vnc or spice."),
"KCHVM0055E": _("Migrate to localhost %(host)s is not allowed."),
"KCHVM0056E": _("To migrate a virtual machine to the remote host %(host)s the user %(user)s must have password-less login to the remote host."),
"KCHVM0057E": _("Can not migrate virtual machine %(name)s when its in %(state)s state."),
diff --git a/model/vms.py b/model/vms.py
index 3380278..cdcb501 100644
--- a/model/vms.py
+++ b/model/vms.py
@@ -290,6 +290,12 @@ class VMModel(object):
# GRAPHICS can be updated offline or online
if 'graphics' in params:
+
+ # some parameters cannot change while vm is running
+ if DOM_STATE_MAP[dom.info()[0]] != 'shutoff':
+ if 'type' in params['graphics']:
+ raise InvalidParameter('KCHVM0074E',
+ {'params': 'graphics type'})
dom = self._update_graphics(dom, params)
# Live updates
@@ -701,6 +707,10 @@ class VMModel(object):
valid_to = time.strftime('%Y-%m-%dT%H:%M:%S', expire_time)
graphics.attrib['passwdValidTo'] = valid_to
+ gtype = params['graphics'].get('type')
+ if gtype is not None:
+ graphics.attrib['type'] = gtype
+
conn = self.conn.get()
if not dom.isActive():
return conn.defineXML(ET.tostring(root, encoding="utf-8"))
--
2.5.5
7 years, 8 months
[RFC] Changes to "disks" attribute of template creation API to support s390 architecture
by Pooja Kulkarni
Hi All,
Since currently s390 does not support libvirt storage pools, we propose
to provide an additional parameter "path" in disks section to specify
the path for a default IMG file to be created in. if "path" attribute is
specified, size parameter should be mandatory.
Two possible ways to implement default values, keeping the current
option of 'pool' as well:
1. If both path and pool options are found in default config file, path
always takes higher precedence over pool irrespective of arch (incase of
s390 pool is ignored)
2. Have a different config file if arch is s390 where only default path
is found (no pool option).
Let me know what you think.
Regards,
Pooja Kulkarni
7 years, 8 months
