I was looking at the following item in the backlog:
Guests Stats: Display memory utilization (use virt-df or virt-top or ...)
If I understood it right, the idea here is to show the -inner- memory
allocation of the guest. If you have a VM with 4Gb of RAM running an
Ubuntu, we want to know how much memory the Ubuntu OS and its processes
I've done an investigation and I haven't found any tool to accomplish
this. "virt-top", "virsh dommemstat" and the libvirt API retrieves the
information of the memory usage of the guest relative to the host. In
the example mentioned before, supposing that the host has 64Gb of RAM,
all these tools would show that the VM is using 12% of the host RAM.
They do not dive in the VM and shows the actual mem usage of the Ubuntu
and its processes running there.
Haven't found anything useful in other MLs and forums. The common answer
is 'run top in a terminal inside the VM', which of course does not suit
us. My question is: any thoughts about how we can implement this
feature? Because I am starting to think that, in the end, this kind of
info is strict to the guest OS and can't be polled from the outside.
first I want to clarify that the following proposal is targeting the 1.6
release and can wait till we have stabilized the new UI in 1.6.
But I guess that it will take some discussion to come up with a good
solution so I thought I'll start it now even knowing that I'll not be
able to participate in the discussion for the next 2 weeks since I'll be
- there is a set functionalities which are usefull/required in
kimchi and ginger, for example:
- logical volume management:
- required by kimchi to define a storage pool based on LVM
- required by ginger to manage the host owned logical
- networking: VLAN assignement, bridge management
- required by kimchi on virtual network management
- required by ginger outside/without virtualisation
Currently the functionalities mentioned above are part of the kimchi plugin.
Options to address this problem:
1. Implement the functionality in both plugins.
Pros: the current code in kimchi can stay unchanged
Cons: code dupplication, double maintanance
2. Share the source code modules
Pros: no code duplication
Cons: potential module duplication since the plugins are in
3. "Interfacing" between the plugins: one plugin implements the
functionality and is exposing an interface for other plugins
Pros: clean separation
Cons: dependency between plugins (but we have that anyhow
already between kimchi and gingercommon)
My preffered Option would be 3. but potentially there are othere options
and aspect I may have missed.
I noticed that the new-ui design pattern for typography specifies Helvetica Neue family in four different styles. This font family is shipped with the latest versions of Mac OS X and iOS but it is not available for free on Windows and Linux distributions.
I believe this might conflict with Kimchi license. Even if we buy or rent a webfont license we can't distribute the TTF, EOT, WOFF and SVG files in our repositories. I think that we can't even use a webfont license in this case (pointing to a remote location or service like Adobe Typekit or MyFonts) because most font-licensing services are charging based on pre-paid pageviews.
Usually for web apps, mobile web apps and cloud based services we have to buy a server license to store the webfont files within our servers, but since Kimchi is an open-source project that anyone can check out and run, every kimchi instance would have to buy their own font license.
We can set Helvetica as the default font-family in the CSS and if the user doesn't have this font installed the browser will load the next available font (Arial or any other Sans-Serif) but since each font has different sizes, some elements may not fit in the screen exactly like they were seen in the mockups. Also, the UI specs recommends Helvetica Neue in 5 different styles (Light, Roman, Regular, Medium and Bold), most system fonts only have 3. We don't have something like "Arial Light" for instance.
My suggestion is that we replace Helvetica Neue for Open Sans because it covers all the style specifications and it is licensed under Apache 2.0. Any thoughts?
From: Paulo Vital <pvital(a)linux.vnet.ibm.com>
Patch set that fixes worng information about Fedora 21 remote ISO and
adds a new option to Fedora 22.
Paulo Vital (2):
Change the version number of remote Fedora image.
Add Fedora 22 information as remote ISO option
src/distros.d/fedora.json | 11 +++++++++--
1 file changed, 9 insertions(+), 2 deletions(-)
The debugreports and screenshots generated were being saved to
/var/lib/wok instead of /var/lib/kimchi, due to absence of
plugin-specific state_dir config. This patch adds it.
Now, when the plugin is installed, those files are saved to
/var/lib/<plugin_name>, and, when running from source, to
That also affects Ginger, which backups are now saved to
Signed-off-by: Lucio Correia <luciojhc(a)linux.vnet.ibm.com>
src/wok/config.py.in | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/src/wok/config.py.in b/src/wok/config.py.in
index 5ffa936..08da028 100644
@@ -88,10 +88,13 @@ class PluginPaths(Paths):
self.plugin_dir = os.path.join('plugins', name)
+ self.state_dir = '@localstatedir@/lib/%s' % name
self.conf_dir = '@sysconfdir(a)/wok/plugins.d'
self.src_dir = os.path.join('@wokdir@', self.plugin_dir)
self.mo_dir = '@prefix@/share/locale'
+ self.state_dir = self.add_prefix(os.path.join(self.plugin_dir,
self.conf_dir = self.add_prefix(self.plugin_dir)
self.src_dir = self.add_prefix(self.plugin_dir)
self.mo_dir = self.add_prefix(os.path.join(self.plugin_dir, 'mo'))