[Engine-devel] Java process increasing resident memory
Hi,
I wrote this sample code and the resident memory of the process is
increasing gradually over time. What could be the reason ? I don't see any
obvious leaks in my program. Could it be that the API is not
freeing/deleting memory ?
Regards,
Navin
package ovcollector;
import java.util.*;
import java.io.*;
import java.lang.management.ManagementFactory;
import org.apache.http.client.*;
import org.apache.http.params.*;
import org.ovirt.engine.sdk.Api;
import org.apache.http.pool.*;
import org.ovirt.engine.sdk.decorators.Host;
import org.ovirt.engine.sdk.decorators.HostStatistic;
import org.ovirt.engine.sdk.decorators.StorageDomain;
import org.ovirt.engine.sdk.decorators.VM;
import org.ovirt.engine.sdk.decorators.VMDisk;
import org.ovirt.engine.sdk.decorators.VMDiskStatistic;
import org.ovirt.engine.sdk.decorators.VMStatistic;
import org.ovirt.engine.sdk.decorators.VMs;
import org.ovirt.engine.sdk.entities.CPU;
import org.ovirt.engine.sdk.entities.Value;
import org.ovirt.engine.sdk.exceptions.ServerException;
import org.ovirt.engine.sdk.exceptions.UnsecuredConnectionAttemptError;
import org.ovirt.engine.*;
import javax.swing.JFrame;
import javax.swing.JPanel;
import javax.swing.JScrollPane;
import javax.swing.JTable;
import java.awt.Dimension;
import java.awt.GridLayout;
import java.awt.event.MouseAdapter;
import java.awt.event.MouseEvent;
public class collectHosts extends JPanel {
/**
* @param args
*/
public static String[] columnNames = {Host Name,
Host uuid,
Cpu Cores, Cpu Sockets,
Memory.total,
Memory.used,
Memory.free,
Memory.shared,Memory.buffers,Memory.cached,swap.total,swap.free,swap.used,swap.cached,ksm.cpu.current,
cpu.current.user,cpu.current.system,cpu.current.idle,cpu.load.avg.5m
};
public static Object[][] data =
{
{blankvmname, blankuuid, new Double(0),new Double(0),new Double(0),new
Double(0),new Double(0),new Double(0),new Double(0), new Double(0),
new Double(0),new Double(0),new Double(0),new Double(0),new Double(0),new
Double(0),new Double(0),new Double(0),new Double(0)},
{blankvmname, blankuuid, new Double(0),new Double(0),new Double(0),new
Double(0),new Double(0),new Double(0),new Double(0), new Double(0),
new Double(0),new Double(0),new Double(0),new Double(0),new Double(0),new
Double(0),new Double(0),new Double(0),new Double(0)}
};
public collectHosts() {
super(new GridLayout(1,0));
final JTable table = new JTable(data, columnNames);
table.setPreferredScrollableViewportSize(new Dimension(500, 70));
table.setFillsViewportHeight(true);
//Create the scroll pane and add the table to it.
JScrollPane scrollPane = new JScrollPane(table);
//Add the scroll pane to this panel.
add(scrollPane);
}
/**
* Create the GUI and show it. For thread safety,
* this method should be invoked from the
* event-dispatching thread.
*/
private static void createAndShowGUI() {
//Create and set up the window.
JFrame frame = new JFrame(Hosts);
frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
//Create and set up the content pane.
collectHosts newContentPane = new collectHosts();
newContentPane.setOpaque(true); //content panes must be opaque
frame.setContentPane(newContentPane);
//Display the window.
frame.pack();
frame.setVisible(true);
}
private static final String URL = http://somehost:80/api;;
public static void main(String[] args) throws
ClientProtocolException,ServerException,
UnsecuredConnectionAttemptError,IOException {
// TODO Auto-generated method stub
System.out.println(Hosts);
while (true)
{
Api api = new Api(URL,SOMEUSERNAME,SOMEPASSWORD);
System.out.println(ManagementFactory.getRuntimeMXBean().getName()) ;
ListHost hlist = api.getHosts().list();
Integer i=0,j=0;
for(Host obj: hlist)
{
j=0;
System.out.println(obj.getName()+ : + obj.getId() +:+
obj.getMemory()+: + obj.getCpu().getTopology().getCores() +:+
obj.getCpu().getTopology().getSockets());
data[i][j++]=obj.getName();
data[i][j++]=obj.getId();
data[i][j++]=obj.getCpu().getTopology().getCores();
data[i][j++]=obj.getCpu().getTopology().getSockets();
ListHostStatistic lhs=obj.getStatistics().list();
for(HostStatistic obj1: lhs)
{
System.out.println(obj1.getName());
ListValue vll=obj1.getValues().getValues();
for(Value vl:vll)
{
System.out.println(vl.getDatum());
data[i][j++]=vl.getDatum();
}
}
i++;
}
try {
Thread.sleep(1);
} catch (InterruptedException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
}
/*
javax.swing.SwingUtilities.invokeLater(new Runnable() {
public void run() {
createAndShowGUI();
}
});
ListStorageDomain list_SD=api.getStorageDomains().list();
Integer i=0;
for(StorageDomain obj: list_SD)
{
System.out.println(obj.getName()+ | + obj.getUsed() + | +
obj.getAvailable() + | + obj.getType());
}
*/
}
Re: [Engine-devel] Java process increasing resident memory
Hi Navin,
On 01/29/2013 10:27 AM, navin p wrote:
while (true)
{
Api api = new Api(URL,SOMEUSERNAME,SOMEPASSWORD);
i'd suggest you moving SDK proxy initiation out of this (endless) loop.
--
Michael Pasternak
RedHat, ENG-Virtualization RD
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
[Engine-devel] Improving of exist memory lock infrastructure in ovirt-engine
The following link http://www.ovirt.org/Features/DetailedLockMechanism contains description and design of in memory lock infrastructure. The design is describing already existing infrastructure with additional changes that should be done in order to improve it. The idea is to allow using of in memory locks with commands that can create asynchronous tasks. Regards Michael ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
[Engine-devel] Time for Spring?
Hi, it is rather cold in Europe, but can I ask, what's the current opinion or plans about full integration of Spring Framework into oVirt engine (Backend)? This is a commonly accepted integration framework among Java programmers and industry standard, which solves many pains from small to large projects. And can lead to a better understanding of the program. There are several Spring dependencies inside oVirt project, but mostly for LDAP and database communication (JDBC template). Still missing (sorry, looks like marketing, but..): - dependency injection - aspect-oriented programming (AOP) - enterprise integration patterns Is something true? :-) 1. We tried, but it is too large and overcomplicated, it can be solved better way for the project purpose 2. We tried, but we think, we need just e.g. JDBC, LDAP layer covered now 3. We would like to integrate with e.g. Hibernate soon, EJB, remoting, unit tests, integration tests, ... , probably we will need it soon 4. We understand and need dependency injection, but there are other light DI containers (Pico, Guice, JBoss Seam). etc. Still, I think there is strong potential, probably not clear today. We cannot avoid Guice on frontend side because of GWTP, but the backend lacks something. Or not? Thanks. Regards, Libor ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Watchdog support Feature
- Original Message - From: Dave Allan dal...@redhat.com To: Itamar Heim ih...@redhat.com Cc: engine-devel engine-devel@ovirt.org Sent: Monday, January 28, 2013 7:23:25 PM Subject: Re: [Engine-devel] Watchdog support Feature On Fri, Jan 25, 2013 at 08:34:27AM -0800, Itamar Heim wrote: On 24/01/2013 06:19, Laszlo Hornyak wrote: Hi, Watchdog support in engine will add watchdog to the ovirt UI and REST API. Watchdog cards will be mainly used in HA vm's. http://www.ovirt.org/Features/Watchdog_engine_support Your feedback is welcome! Thank you, Laszlo ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel looks like a nice, simple, addition. dave, anyone more intimate with the watchdog worth giving another look? I had a look at the ovirt feature page and asked some libvirt folks as well, and it all looks good to me except that the libvirt documentation says that an event when watchdog fires will be added in the future. That event has been added. The watchdog should work pretty much identically to the physical world: configure the virtual watchdog card in the guest hardware description and install the watchdog daemon in the guest. Dave Thanks Dave. Do you happen do know why the shutdown action is not recommended? ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Java process increasing resident memory
Hi Michael,
On Tue, Jan 29, 2013 at 2:42 PM, Michael Pasternak mpast...@redhat.comwrote:
Hi Navin,
On 01/29/2013 10:27 AM, navin p wrote:
while (true)
{
Api api = new Api(URL,SOMEUSERNAME,SOMEPASSWORD);
i'd suggest you moving SDK proxy initiation out of this (endless) loop.
I tried that but it didn't help. The Resident memory was increasing in the
top -p output
Regards,
Navin
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Watchdog support Feature
On Tue, Jan 29, 2013 at 08:06:44AM -0500, Doron Fediuck wrote: - Original Message - From: Dave Allan dal...@redhat.com To: Itamar Heim ih...@redhat.com Cc: engine-devel engine-devel@ovirt.org Sent: Monday, January 28, 2013 7:23:25 PM Subject: Re: [Engine-devel] Watchdog support Feature On Fri, Jan 25, 2013 at 08:34:27AM -0800, Itamar Heim wrote: On 24/01/2013 06:19, Laszlo Hornyak wrote: Hi, Watchdog support in engine will add watchdog to the ovirt UI and REST API. Watchdog cards will be mainly used in HA vm's. http://www.ovirt.org/Features/Watchdog_engine_support Your feedback is welcome! Thank you, Laszlo ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel looks like a nice, simple, addition. dave, anyone more intimate with the watchdog worth giving another look? I had a look at the ovirt feature page and asked some libvirt folks as well, and it all looks good to me except that the libvirt documentation says that an event when watchdog fires will be added in the future. That event has been added. The watchdog should work pretty much identically to the physical world: configure the virtual watchdog card in the guest hardware description and install the watchdog daemon in the guest. Dave Thanks Dave. Do you happen do know why the shutdown action is not recommended? Yes--it requires guest cooperation which it's unlikely to get if the guest has gotten into a state where the watchdog fires. Dave ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Instance Types Feature
Some questions: 1. Why do we need a new set of permissions for Create Instance and Instance Owner? Aren't the VmCreator role and the UserVmManager role enough in these use-cases? 2. iiuc, the internal implementation of instance types and images will be done using templates. However, I guess we plan to expose instance types and images as REST resources, right? Thank you, Oved - Original Message - From: Tomas Jelinek tjeli...@redhat.com To: engine-devel@ovirt.org Sent: Tuesday, January 22, 2013 3:09:51 PM Subject: [Engine-devel] Instance Types Feature Hi All, this is the proposed new feature called instance types: http://www.ovirt.org/Features/Instance_Types Long story short - it should basically split the VM template into: - hardware profile called instance types - software profile called image This should enable to do something like: Create a new small VM and attach a disk with RHEL + Postgres installed. Any comments are more than welcome! Tomas ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] oVirt 3.2 test-day
I'll be participating and testing the network scenarios (added to wiki). On 29/01/13 01:30, Moran Goldboim wrote: we were supposed to have test day tomorrow, but we decided to push it to Thursday (Jan 31) to have ovirt-node and proper infra for test day (Mike should announce it's officially soon). I have refreshed http://www.ovirt.org/Testing/OvirtTestDay, but there is action from your part as well: -go over the scenarios (regressions), see if those relevant, add more if needed remove if not. -add basic tests for your new 3.2 features. -assign a contributor to be actively present on helping users on his area -make commitment and participate the test day I would like to review this document by Wednesday on users meeting, please make sure your part is updated by than. Thanks, Moran. ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Watchdog support Feature
- Original Message - From: Dave Allan dal...@redhat.com To: Doron Fediuck dfedi...@redhat.com Cc: engine-devel engine-devel@ovirt.org Sent: Tuesday, January 29, 2013 2:42:42 PM Subject: Re: [Engine-devel] Watchdog support Feature On Tue, Jan 29, 2013 at 08:06:44AM -0500, Doron Fediuck wrote: - Original Message - From: Dave Allan dal...@redhat.com To: Itamar Heim ih...@redhat.com Cc: engine-devel engine-devel@ovirt.org Sent: Monday, January 28, 2013 7:23:25 PM Subject: Re: [Engine-devel] Watchdog support Feature On Fri, Jan 25, 2013 at 08:34:27AM -0800, Itamar Heim wrote: On 24/01/2013 06:19, Laszlo Hornyak wrote: Hi, Watchdog support in engine will add watchdog to the ovirt UI and REST API. Watchdog cards will be mainly used in HA vm's. http://www.ovirt.org/Features/Watchdog_engine_support Your feedback is welcome! Thank you, Laszlo ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel looks like a nice, simple, addition. dave, anyone more intimate with the watchdog worth giving another look? I had a look at the ovirt feature page and asked some libvirt folks as well, and it all looks good to me except that the libvirt documentation says that an event when watchdog fires will be added in the future. That event has been added. The watchdog should work pretty much identically to the physical world: configure the virtual watchdog card in the guest hardware description and install the watchdog daemon in the guest. Dave Thanks Dave. Do you happen do know why the shutdown action is not recommended? Yes--it requires guest cooperation which it's unlikely to get if the guest has gotten into a state where the watchdog fires. Dave Yep, the guest kernel should handle an ACPI signal. I don't know in what circumstances would that work, but vdsm does not support it either, so that decision is already made. ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Java process increasing resident memory
Navin,
It's quite hard to see from your piece of code what exactly causing this,
also i can't reproduce this on my environment running very same sdk code,
can you please run your app with some profiling tool attached and send me
the output?
On 01/29/2013 03:09 PM, navin p wrote:
Hi Michael,
On Tue, Jan 29, 2013 at 2:42 PM, Michael Pasternak mpast...@redhat.com
mailto:mpast...@redhat.com wrote:
Hi Navin,
On 01/29/2013 10:27 AM, navin p wrote:
while (true)
{
Api api = new Api(URL,SOMEUSERNAME,SOMEPASSWORD);
i'd suggest you moving SDK proxy initiation out of this (endless) loop.
I tried that but it didn't help. The Resident memory was increasing in the
top -p output
Regards,
Navin
--
Michael Pasternak
RedHat, ENG-Virtualization RD
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] unit tests failing
I'll need to fix those tests, sorry. Working on it right now. -- Federico - Original Message - From: Alon Bar-Lev alo...@redhat.com To: engine-devel engine-devel@ovirt.org, Federico Simoncelli fsimo...@redhat.com, Ofri Masad oma...@redhat.com Sent: Tuesday, January 29, 2013 3:53:36 PM Subject: unit tests failing Don't know what change exactly caused this: Tests in error: canDoActionInvalidVmStatus(org.ovirt.engine.core.bll.MoveDisksCommandTest) moveDisk(org.ovirt.engine.core.bll.MoveDisksCommandTest) liveMigrateDisk(org.ovirt.engine.core.bll.MoveDisksCommandTest) liveMigrateDiskBasedOnTemplate(org.ovirt.engine.core.bll.MoveDisksCommandTest) moveDiskAndLiveMigrateDisk(org.ovirt.engine.core.bll.MoveDisksCommandTest) ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
[Engine-devel] Change in the RPM release
Hello all, I have just merged a patch (see [1]) into the master branch that changes how the release number of RPMs is created by default. Now it will be like this: 0.1.$(date +%Y%m%d%H%M%S) This may impact you if you are building your own RPMs, but only if you are not explicitly forcing the release number with something like this: make rpm RPM_RELEASE_VERSION=whatever [1] http://gerrit.ovirt.org/9704 Regards, Juan Hernandez -- Dirección Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta 3ºD, 28016 Madrid, Spain Inscrita en el Reg. Mercantil de Madrid – C.I.F. B82657941 - Red Hat S.L. ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] unit tests failing
May I recommend git bisect? See http://lwn.net/Articles/317154/ or http://clock.co.uk/tech-blogs/git-bisect-simple-examples-and-automation as well. First you find a known BAD, for example master. Then you find a known GOOD (for example 100 commits ago in master: master~100). Then we can use a script to determine if it's good. I'm assuming mvn test will be sufficient, but maybe you can refine this to only test for a specific unit test. git bisect start BAD GOOD git bisect run mvn test Now it will do a binary search in your history trying to find the commit that broke mvn test. On Tue, Jan 29, 2013 at 10:13:20AM -0500, Laszlo Hornyak wrote: Probably it is not yours, I removed ff64900b7ae1b2d92e40bb290c61354d846d7d30 and still failing. - Original Message - From: Federico Simoncelli fsimo...@redhat.com To: Alon Bar-Lev alo...@redhat.com Cc: engine-devel engine-devel@ovirt.org Sent: Tuesday, January 29, 2013 4:05:10 PM Subject: Re: [Engine-devel] unit tests failing I'll need to fix those tests, sorry. Working on it right now. -- Federico - Original Message - From: Alon Bar-Lev alo...@redhat.com To: engine-devel engine-devel@ovirt.org, Federico Simoncelli fsimo...@redhat.com, Ofri Masad oma...@redhat.com Sent: Tuesday, January 29, 2013 3:53:36 PM Subject: unit tests failing Don't know what change exactly caused this: Tests in error: canDoActionInvalidVmStatus(org.ovirt.engine.core.bll.MoveDisksCommandTest) moveDisk(org.ovirt.engine.core.bll.MoveDisksCommandTest) liveMigrateDisk(org.ovirt.engine.core.bll.MoveDisksCommandTest) liveMigrateDiskBasedOnTemplate(org.ovirt.engine.core.bll.MoveDisksCommandTest) moveDiskAndLiveMigrateDisk(org.ovirt.engine.core.bll.MoveDisksCommandTest) ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] unit tests failing
- Original Message - From: Ewoud Kohl van Wijngaarden ewoud+ov...@kohlvanwijngaarden.nl To: Laszlo Hornyak lhorn...@redhat.com Cc: engine-devel engine-devel@ovirt.org Sent: Tuesday, January 29, 2013 5:36:35 PM Subject: Re: [Engine-devel] unit tests failing May I recommend git bisect? See http://lwn.net/Articles/317154/ or http://clock.co.uk/tech-blogs/git-bisect-simple-examples-and-automation as well. This is way too time consuming from unrelated party that needs to progress with his own tasks. First you find a known BAD, for example master. Then you find a known GOOD (for example 100 commits ago in master: master~100). Then we can use a script to determine if it's good. I'm assuming mvn test will be sufficient, but maybe you can refine this to only test for a specific unit test. git bisect start BAD GOOD git bisect run mvn test Now it will do a binary search in your history trying to find the commit that broke mvn test. On Tue, Jan 29, 2013 at 10:13:20AM -0500, Laszlo Hornyak wrote: Probably it is not yours, I removed ff64900b7ae1b2d92e40bb290c61354d846d7d30 and still failing. - Original Message - From: Federico Simoncelli fsimo...@redhat.com To: Alon Bar-Lev alo...@redhat.com Cc: engine-devel engine-devel@ovirt.org Sent: Tuesday, January 29, 2013 4:05:10 PM Subject: Re: [Engine-devel] unit tests failing I'll need to fix those tests, sorry. Working on it right now. -- Federico - Original Message - From: Alon Bar-Lev alo...@redhat.com To: engine-devel engine-devel@ovirt.org, Federico Simoncelli fsimo...@redhat.com, Ofri Masad oma...@redhat.com Sent: Tuesday, January 29, 2013 3:53:36 PM Subject: unit tests failing Don't know what change exactly caused this: Tests in error: canDoActionInvalidVmStatus(org.ovirt.engine.core.bll.MoveDisksCommandTest) moveDisk(org.ovirt.engine.core.bll.MoveDisksCommandTest) liveMigrateDisk(org.ovirt.engine.core.bll.MoveDisksCommandTest) liveMigrateDiskBasedOnTemplate(org.ovirt.engine.core.bll.MoveDisksCommandTest) moveDiskAndLiveMigrateDisk(org.ovirt.engine.core.bll.MoveDisksCommandTest) ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Time to move to 3.3.0-SNAPSHOT?
On 01/21/2013 09:45 AM, Michael Pasternak wrote: On 01/21/2013 10:28 AM, Omer Frenkel wrote: - Original Message - From: Yair Zaslavsky yzasl...@redhat.com To: Michael Pasternak mpast...@redhat.com Cc: Juan Hernandez jhern...@redhat.com, engine-devel@ovirt.org Sent: Monday, January 21, 2013 8:27:36 AM Subject: Re: [Engine-devel] Time to move to 3.3.0-SNAPSHOT? - Original Message - From: Michael Pasternak mpast...@redhat.com To: Juan Hernandez jhern...@redhat.com Cc: engine-devel@ovirt.org Sent: Sunday, January 20, 2013 3:24:58 PM Subject: Re: [Engine-devel] Time to move to 3.3.0-SNAPSHOT? On 01/17/2013 01:04 PM, Juan Hernandez wrote: Once 3.2.0 is released I think we should move to 3.3.0-SNAPSHOT in the master branch: +1 I agree, and this is not the only place where should start marking and cluster compatibility version.. all above is true, but Juan meant preparing MVN infra for the next development iteration, while you're talking about engine internals, maybe we should file BZs on that (as next version tasks) or should we define new process of preparing for the next version that will include both? As I don't see hard opposition to this change I will merge it tomorrow. Please raise your hand iif you think it shouldn't be merged. http://gerrit.ovirt.org/11143 -- Dirección Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta 3ºD, 28016 Madrid, Spain Inscrita en el Reg. Mercantil de Madrid – C.I.F. B82657941 - Red Hat S.L. ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] unit tests failing
- Original Message - From: Ewoud Kohl van Wijngaarden ewoud+ov...@kohlvanwijngaarden.nl To: Laszlo Hornyak lhorn...@redhat.com Cc: Federico Simoncelli fsimo...@redhat.com, engine-devel engine-devel@ovirt.org Sent: Tuesday, January 29, 2013 4:36:35 PM Subject: Re: [Engine-devel] unit tests failing May I recommend git bisect? See http://lwn.net/Articles/317154/ or http://clock.co.uk/tech-blogs/git-bisect-simple-examples-and-automation as well. First you find a known BAD, for example master. Then you find a known GOOD (for example 100 commits ago in master: master~100). Then we can use a script to determine if it's good. I'm assuming mvn test will be sufficient, but maybe you can refine this to only test for a specific unit test. git bisect start BAD GOOD git bisect run mvn test Now it will do a binary search in your history trying to find the commit that broke mvn test. It's ff64900b7ae1b2d92e40bb290c61354d846d7d30 I'm working on it as we speak. -- Federico ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Time to move to 3.3.0-SNAPSHOT?
- Original Message - From: Juan Hernandez jhern...@redhat.com Cc: engine-devel@ovirt.org Sent: Tuesday, January 29, 2013 5:44:33 PM Subject: Re: [Engine-devel] Time to move to 3.3.0-SNAPSHOT? On 01/21/2013 09:45 AM, Michael Pasternak wrote: On 01/21/2013 10:28 AM, Omer Frenkel wrote: - Original Message - From: Yair Zaslavsky yzasl...@redhat.com To: Michael Pasternak mpast...@redhat.com Cc: Juan Hernandez jhern...@redhat.com, engine-devel@ovirt.org Sent: Monday, January 21, 2013 8:27:36 AM Subject: Re: [Engine-devel] Time to move to 3.3.0-SNAPSHOT? - Original Message - From: Michael Pasternak mpast...@redhat.com To: Juan Hernandez jhern...@redhat.com Cc: engine-devel@ovirt.org Sent: Sunday, January 20, 2013 3:24:58 PM Subject: Re: [Engine-devel] Time to move to 3.3.0-SNAPSHOT? On 01/17/2013 01:04 PM, Juan Hernandez wrote: Once 3.2.0 is released I think we should move to 3.3.0-SNAPSHOT in the master branch: +1 I agree, and this is not the only place where should start marking and cluster compatibility version.. all above is true, but Juan meant preparing MVN infra for the next development iteration, while you're talking about engine internals, maybe we should file BZs on that (as next version tasks) or should we define new process of preparing for the next version that will include both? As I don't see hard opposition to this change I will merge it tomorrow. Please raise your hand iif you think it shouldn't be merged. http://gerrit.ovirt.org/11143 For the poms, why didn't you use a variable that is inherited? But Java is not my domain. Tarball should be ovirt-engine-3.3.0_master.tar.gz RPM release should be ovirt-engine-3.3.0-0.0.master This will enable us to release milestones, such as beta1, beta2, rc1, rc2 and finally release without suffix. Regards, Alon ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] unit tests failing
Hey Ewoud, +1 for bisect, what's up Ewoud?, this email reminds me good old rhevm-api days. On 01/29/2013 05:36 PM, Ewoud Kohl van Wijngaarden wrote: May I recommend git bisect? See http://lwn.net/Articles/317154/ or http://clock.co.uk/tech-blogs/git-bisect-simple-examples-and-automation as well. First you find a known BAD, for example master. Then you find a known GOOD (for example 100 commits ago in master: master~100). Then we can use a script to determine if it's good. I'm assuming mvn test will be sufficient, but maybe you can refine this to only test for a specific unit test. git bisect start BAD GOOD git bisect run mvn test Now it will do a binary search in your history trying to find the commit that broke mvn test. -- Michael Pasternak RedHat, ENG-Virtualization RD ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] May I apply for a user account on jenkins.ovirt.org to run VDSM functional tests?
yes. zhengsheng has setup a Jenkins job for VDSM functional tests in our lab server. he is doing some works related to Jenkins. On 01/29/2013 07:15 PM, Eyal Edri wrote: - Original Message - From: Zhou Zheng Sheng zhshz...@linux.vnet.ibm.com To: in...@ovirt.org Cc: ShaoHe Feng shao...@linux.vnet.ibm.com Sent: Tuesday, January 29, 2013 12:24:27 PM Subject: May I apply for a user account on jenkins.ovirt.org to run VDSM functional tests? Hi all, I notice there is no VDSM functional tests running in oVirt Jenkins. Currently in VDSM we have some XML-RPC functional test cases for iSCSI, localfs and glusterfs storage as well as creating and destroying VMs on those storage. Functional tests through JSON-RPC are under review. I also submit a patch to Gerrit for running the tests easily (http://gerrit.ovirt.org/#/c/11238/). More test cases will be added to improve test coverage and reduce the chance of regression. Some bugs that can not be covered by unit test can be caught by functional tests. I think it would be helpful to run these functional tests continuously. We can also configure the Gerrit trigger in Jenkins to run functional tests when someone verifies the patch or when it gets approved but not merged. This may be helpful to the maintainer. I've setup a Jenkins job for VDSM functional tests in my lab server. You can refer to the job configuration of my current setup (https://github.com/edwardbadboy/vdsm-jenkins/blob/master/config.xml). After my patch in Gerrit is accepted, the job configuration will be simpler and the hacks can be removed. May I apply a user account for creating job in the oVirt Jenkins? Hi Zhou, Basically there shouldn't be any problem with that. we have an option for giving a 'power-user' permissions for certain users on oVirt misc projects to add and and configure jobs for thier project. it requires knowledge in jenkins, which it seems that you have and recognition from the team/other developers from the relevant project (in this case, VDSM) that you are an active member of the project. (just a formality essentially) I've added engine-devel list to this thread so anyone from vdsm team can vote +1 for adding you as a power user for jenkins. once we'll receive a few +1 and not objections i'll create a user for you and send you the details. you'll be able to: 1. create new jobs 2. update jobs configurations 3. run jobs.. -- Thanks and best regards! Zhou Zheng Sheng / 周征晟 E-mail: zhshz...@linux.vnet.ibm.com Telephone: 86-10-82454397 ___ Infra mailing list in...@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra -- Sheldon Feng(冯少合)shao...@linux.vnet.ibm.com IBM Linux Technology Center ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Time to move to 3.3.0-SNAPSHOT?
On 01/29/2013 04:52 PM, Alon Bar-Lev wrote: - Original Message - From: Juan Hernandez jhern...@redhat.com Cc: engine-devel@ovirt.org Sent: Tuesday, January 29, 2013 5:44:33 PM Subject: Re: [Engine-devel] Time to move to 3.3.0-SNAPSHOT? On 01/21/2013 09:45 AM, Michael Pasternak wrote: On 01/21/2013 10:28 AM, Omer Frenkel wrote: - Original Message - From: Yair Zaslavsky yzasl...@redhat.com To: Michael Pasternak mpast...@redhat.com Cc: Juan Hernandez jhern...@redhat.com, engine-devel@ovirt.org Sent: Monday, January 21, 2013 8:27:36 AM Subject: Re: [Engine-devel] Time to move to 3.3.0-SNAPSHOT? - Original Message - From: Michael Pasternak mpast...@redhat.com To: Juan Hernandez jhern...@redhat.com Cc: engine-devel@ovirt.org Sent: Sunday, January 20, 2013 3:24:58 PM Subject: Re: [Engine-devel] Time to move to 3.3.0-SNAPSHOT? On 01/17/2013 01:04 PM, Juan Hernandez wrote: Once 3.2.0 is released I think we should move to 3.3.0-SNAPSHOT in the master branch: +1 I agree, and this is not the only place where should start marking and cluster compatibility version.. all above is true, but Juan meant preparing MVN infra for the next development iteration, while you're talking about engine internals, maybe we should file BZs on that (as next version tasks) or should we define new process of preparing for the next version that will include both? As I don't see hard opposition to this change I will merge it tomorrow. Please raise your hand iif you think it shouldn't be merged. http://gerrit.ovirt.org/11143 For the poms, why didn't you use a variable that is inherited? But Java is not my domain. Maven doesn't support use of variables in any of the coordinates of the artifacts or of their parents. If you use variables, specially if you use them in the version of the parent project and the variable is inherited from the parent project, there is no way to determine which version of the parent project should be used. Tarball should be ovirt-engine-3.3.0_master.tar.gz RPM release should be ovirt-engine-3.3.0-0.0.master This will enable us to release milestones, such as beta1, beta2, rc1, rc2 and finally release without suffix. -- Dirección Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta 3ºD, 28016 Madrid, Spain Inscrita en el Reg. Mercantil de Madrid – C.I.F. B82657941 - Red Hat S.L. ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Time to move to 3.3.0-SNAPSHOT?
- Original Message -
From: Juan Hernandez jhern...@redhat.com
To: Alon Bar-Lev alo...@redhat.com
Cc: engine-devel@ovirt.org
Sent: Tuesday, January 29, 2013 5:41:13 PM
Subject: Re: [Engine-devel] Time to move to 3.3.0-SNAPSHOT?
On 01/29/2013 04:52 PM, Alon Bar-Lev wrote:
- Original Message -
From: Juan Hernandez jhern...@redhat.com
Cc: engine-devel@ovirt.org
Sent: Tuesday, January 29, 2013 5:44:33 PM
Subject: Re: [Engine-devel] Time to move to 3.3.0-SNAPSHOT?
On 01/21/2013 09:45 AM, Michael Pasternak wrote:
On 01/21/2013 10:28 AM, Omer Frenkel wrote:
- Original Message -
From: Yair Zaslavsky yzasl...@redhat.com
To: Michael Pasternak mpast...@redhat.com
Cc: Juan Hernandez jhern...@redhat.com,
engine-devel@ovirt.org
Sent: Monday, January 21, 2013 8:27:36 AM
Subject: Re: [Engine-devel] Time to move to 3.3.0-SNAPSHOT?
- Original Message -
From: Michael Pasternak mpast...@redhat.com
To: Juan Hernandez jhern...@redhat.com
Cc: engine-devel@ovirt.org
Sent: Sunday, January 20, 2013 3:24:58 PM
Subject: Re: [Engine-devel] Time to move to 3.3.0-SNAPSHOT?
On 01/17/2013 01:04 PM, Juan Hernandez wrote:
Once 3.2.0 is released I think we should move to
3.3.0-SNAPSHOT
in
the master branch:
+1
I agree, and this is not the only place where should start
marking
and cluster compatibility version..
all above is true, but Juan meant preparing MVN infra for the
next
development iteration, while you're talking about engine
internals,
maybe we should file BZs on that (as next version tasks) or
should
we
define new process of preparing for the next version that will
include both?
As I don't see hard opposition to this change I will merge it
tomorrow.
Please raise your hand iif you think it shouldn't be merged.
http://gerrit.ovirt.org/11143
For the poms, why didn't you use a variable that is inherited? But
Java is not my domain.
Maven doesn't support use of variables in any of the coordinates of
the
artifacts or of their parents. If you use variables, specially if you
use them in the version of the parent project and the variable is
inherited from the parent project, there is no way to determine which
version of the parent project should be used.
That's correct, but you can set the version numbers of the ovirt artifacts to
${parent.version}. But let's do it in a next patch, we already spent enough
time on this :) Merge!
Tarball should be ovirt-engine-3.3.0_master.tar.gz
RPM release should be ovirt-engine-3.3.0-0.0.master
This will enable us to release milestones, such as beta1, beta2,
rc1, rc2 and finally release without suffix.
--
Dirección Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta
3ºD, 28016 Madrid, Spain
Inscrita en el Reg. Mercantil de Madrid – C.I.F. B82657941 - Red Hat
S.L.
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Time to move to 3.3.0-SNAPSHOT?
- Original Message -
From: Laszlo Hornyak lhorn...@redhat.com
To: Juan Hernandez jhern...@redhat.com
Cc: engine-devel@ovirt.org, Alon Bar-Lev alo...@redhat.com
Sent: Tuesday, January 29, 2013 6:57:51 PM
Subject: Re: [Engine-devel] Time to move to 3.3.0-SNAPSHOT?
- Original Message -
From: Juan Hernandez jhern...@redhat.com
To: Alon Bar-Lev alo...@redhat.com
Cc: engine-devel@ovirt.org
Sent: Tuesday, January 29, 2013 5:41:13 PM
Subject: Re: [Engine-devel] Time to move to 3.3.0-SNAPSHOT?
On 01/29/2013 04:52 PM, Alon Bar-Lev wrote:
- Original Message -
From: Juan Hernandez jhern...@redhat.com
Cc: engine-devel@ovirt.org
Sent: Tuesday, January 29, 2013 5:44:33 PM
Subject: Re: [Engine-devel] Time to move to 3.3.0-SNAPSHOT?
On 01/21/2013 09:45 AM, Michael Pasternak wrote:
On 01/21/2013 10:28 AM, Omer Frenkel wrote:
- Original Message -
From: Yair Zaslavsky yzasl...@redhat.com
To: Michael Pasternak mpast...@redhat.com
Cc: Juan Hernandez jhern...@redhat.com,
engine-devel@ovirt.org
Sent: Monday, January 21, 2013 8:27:36 AM
Subject: Re: [Engine-devel] Time to move to 3.3.0-SNAPSHOT?
- Original Message -
From: Michael Pasternak mpast...@redhat.com
To: Juan Hernandez jhern...@redhat.com
Cc: engine-devel@ovirt.org
Sent: Sunday, January 20, 2013 3:24:58 PM
Subject: Re: [Engine-devel] Time to move to 3.3.0-SNAPSHOT?
On 01/17/2013 01:04 PM, Juan Hernandez wrote:
Once 3.2.0 is released I think we should move to
3.3.0-SNAPSHOT
in
the master branch:
+1
I agree, and this is not the only place where should start
marking
and cluster compatibility version..
all above is true, but Juan meant preparing MVN infra for the
next
development iteration, while you're talking about engine
internals,
maybe we should file BZs on that (as next version tasks) or
should
we
define new process of preparing for the next version that will
include both?
As I don't see hard opposition to this change I will merge it
tomorrow.
Please raise your hand iif you think it shouldn't be merged.
http://gerrit.ovirt.org/11143
For the poms, why didn't you use a variable that is inherited?
But
Java is not my domain.
Maven doesn't support use of variables in any of the coordinates of
the
artifacts or of their parents. If you use variables, specially if
you
use them in the version of the parent project and the variable is
inherited from the parent project, there is no way to determine
which
version of the parent project should be used.
That's correct, but you can set the version numbers of the ovirt
artifacts to ${parent.version}. But let's do it in a next patch, we
already spent enough time on this :) Merge!
It this is correct, there is no point in merge and fix.
Fix and merge.
Tarball should be ovirt-engine-3.3.0_master.tar.gz
RPM release should be ovirt-engine-3.3.0-0.0.master
This will enable us to release milestones, such as beta1, beta2,
rc1, rc2 and finally release without suffix.
--
Dirección Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3,
planta
3ºD, 28016 Madrid, Spain
Inscrita en el Reg. Mercantil de Madrid – C.I.F. B82657941 - Red
Hat
S.L.
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] 3.2 features for release notes
On 01/24/2013 10:30 AM, Itamar Heim wrote: On 23/01/2013 23:47, Cheryn Tan wrote: Hi all, I'm preparing the oVirt 3.2 release notes, starting with the features listed here: http://www.ovirt.org/OVirt_3.2_release-management#Features Can you please go through the list, and reply to this thread if: a) There are features being released for 3.2 which should be documented, but are not on the list; or b) Some of the planned features on this list are not being released for 3.2; or c) Some of the features on this list are being released for 3.2, but should not be documented. For features which aren't on the wiki, please send a short description or Bugzilla numbers of each feature. Please reply no later than Jan 28. Thank you very much for your help! Cheryn ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel I think most of these made it to 3.2, i'll point fingers at others to give more details... (doesn't mean others weren't involved in them, just picked someone to give the details for release notes). SSIA: Add support for Opteron G5 (Seoul) Add Support for Intel Haswell CPU windows 8/12 - add os type windows 8/12 - default in user portal should be rdp (till we have spice support...) expand tree by default with list of DCs federico: storage live migration tomas: Configure Smartcard for VM including Portal support Allow e1000 to be selected as nic type for Windows VM dynamic frantisek: checkbox at vm level to prevent accidental deletion shahar: vm payload issues (with cd-rom) Arik Changing the name of the virtual machines, created from a pool through web-admin-portal Alona: network as a main tab network permissions network main tab: search for networks (and api) network main tab: show vms by logical network hot-plug network - change networks on the fly Igor: hotplug nic hook Muli: display the VM interface IP per vnic report ipv6 addresses from guest vojtech: ui plugins Greg: cluster policy on hyperthreads usage http://www.ovirt.org/Features/cpu_thread_handling Clusters can now be configured to treat host cpu threads as cores for the purpose of vm resource allocation, migration, etc. Laszlo: -cpu host Ofri: quota - add to resource tab in power user portal moran: ovirt-live daniel erez: slm: move multiple disks (one by one) unicode enablement for OVF fields disks subtab/api under storage domain Tal: delete disk on vm delete flag (for image vs. volume) Liron: move OVF update out of reconstruct master and all other flows as an independent sync process Eli: inject events bootstrap: fetch logs to engine power management proxy (DC or cluster) multiple fencing devices add ilo2/ilo4 in text Yaniv Bronhaim: collect hardware (bios) information juan: engine-vdsm ssl session caching michael kublin: auto-recovery: last host in status up Alon Bar-Lev: bootstrap: install rhev-h without communication to engine 443 bootstrap: pki: use PKCS#12 format to store keys bootstrap: rewrite (ovirt-host-deploy) bootstrap: rewrite (otopi) Yair: rhevm-manage-domains hardcodes the DC's address instead of using DNS lookups Yaniv Dary: cloud provider report Report Daily list of people logged into Spice consoles and their activity add status of storage domain to dwh/reports DC Dashboard should display Storage Domains count single vm uptime - rhevm-reports should be able to report uptime against virtual machines Storage Inventory Report - New report michael pasternak: sdk - allow simultaneous connections to multiple servers cli - disable output redirection to ease testing efforts java sdk Doron: tuned profile for host doron/adam: not sure about status of vdsm-mom in 3.2? shireesh - what about: Forced removal of a host Configuration sync with Gluster CLI Import of existing gluster clusters Thanks, Itamar ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Improving of exist memory lock infrastructure in ovirt-engine
Hi, I fixed some minor typos + have some comments on things need to be clarified. My comments are based on the sections + numbers inside the sections Detailed Description 3. I think you should add: However, this behavior can be controlled as explained later on and a lock may be released after the end of endAction. User-work-flows 2. If needed additional treatment the appropriate command will override getReadLocks() and getWriteLocks() methods of CommandBase BR Don't you mean here the exclusive and shared locks? Failures - 4. In case task is found at DB, but not in SPM - will we want to clean it immediately at the first detection this issue occurs? (We talked about it today, and we think we should do that, giving other people a chance to comment) - Original Message - From: Michael Kublin mkub...@redhat.com To: engine-devel engine-devel@ovirt.org Sent: Tuesday, January 29, 2013 12:01:33 PM Subject: [Engine-devel] Improving of exist memory lock infrastructure in ovirt-engine The following link http://www.ovirt.org/Features/DetailedLockMechanism contains description and design of in memory lock infrastructure. The design is describing already existing infrastructure with additional changes that should be done in order to improve it. The idea is to allow using of in memory locks with commands that can create asynchronous tasks. Regards Michael ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] unit tests failing
- Original Message - From: Federico Simoncelli fsimo...@redhat.com To: Ewoud Kohl van Wijngaarden ewoud+ov...@kohlvanwijngaarden.nl Cc: engine-devel engine-devel@ovirt.org Sent: Tuesday, January 29, 2013 4:45:43 PM Subject: Re: [Engine-devel] unit tests failing - Original Message - From: Ewoud Kohl van Wijngaarden ewoud+ov...@kohlvanwijngaarden.nl To: Laszlo Hornyak lhorn...@redhat.com Cc: Federico Simoncelli fsimo...@redhat.com, engine-devel engine-devel@ovirt.org Sent: Tuesday, January 29, 2013 4:36:35 PM Subject: Re: [Engine-devel] unit tests failing May I recommend git bisect? See http://lwn.net/Articles/317154/ or http://clock.co.uk/tech-blogs/git-bisect-simple-examples-and-automation as well. First you find a known BAD, for example master. Then you find a known GOOD (for example 100 commits ago in master: master~100). Then we can use a script to determine if it's good. I'm assuming mvn test will be sufficient, but maybe you can refine this to only test for a specific unit test. git bisect start BAD GOOD git bisect run mvn test Now it will do a binary search in your history trying to find the commit that broke mvn test. It's ff64900b7ae1b2d92e40bb290c61354d846d7d30 I'm working on it as we speak. This is a quick fix: http://gerrit.ovirt.org/#/c/11510/ I'm sure there's a lot to improve, please review it so we can push it as fast as we can. Thanks. -- Federico ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Watchdog support Feature
- Original Message - From: Laszlo Hornyak lhorn...@redhat.com To: Dave Allan dal...@redhat.com, Doron Fediuck dfedi...@redhat.com Cc: engine-devel engine-devel@ovirt.org Sent: Tuesday, January 29, 2013 4:18:53 PM Subject: Re: [Engine-devel] Watchdog support Feature - Original Message - From: Dave Allan dal...@redhat.com To: Doron Fediuck dfedi...@redhat.com Cc: engine-devel engine-devel@ovirt.org Sent: Tuesday, January 29, 2013 2:42:42 PM Subject: Re: [Engine-devel] Watchdog support Feature On Tue, Jan 29, 2013 at 08:06:44AM -0500, Doron Fediuck wrote: - Original Message - From: Dave Allan dal...@redhat.com To: Itamar Heim ih...@redhat.com Cc: engine-devel engine-devel@ovirt.org Sent: Monday, January 28, 2013 7:23:25 PM Subject: Re: [Engine-devel] Watchdog support Feature On Fri, Jan 25, 2013 at 08:34:27AM -0800, Itamar Heim wrote: On 24/01/2013 06:19, Laszlo Hornyak wrote: Hi, Watchdog support in engine will add watchdog to the ovirt UI and REST API. Watchdog cards will be mainly used in HA vm's. http://www.ovirt.org/Features/Watchdog_engine_support Your feedback is welcome! Thank you, Laszlo ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel looks like a nice, simple, addition. dave, anyone more intimate with the watchdog worth giving another look? I had a look at the ovirt feature page and asked some libvirt folks as well, and it all looks good to me except that the libvirt documentation says that an event when watchdog fires will be added in the future. That event has been added. The watchdog should work pretty much identically to the physical world: configure the virtual watchdog card in the guest hardware description and install the watchdog daemon in the guest. Dave Thanks Dave. Do you happen do know why the shutdown action is not recommended? Yes--it requires guest cooperation which it's unlikely to get if the guest has gotten into a state where the watchdog fires. Dave Yep, the guest kernel should handle an ACPI signal. I don't know in what circumstances would that work, but vdsm does not support it either, so that decision is already made. Makes sense, thanks. ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] 3.2 features for release notes
Thank you everyone who responded to my request for release notes, and thank you Itamar for sending me the list of SMEs for each feature. I've sent questions to the relevant people about features I need more clarification on, but otherwise a draft of the 3.2 release notes can be found here: http://www.ovirt.org/OVirt_3.2_release_notes Your help in reviewing the release notes is greatly appreciated. Feel free to edit the wiki directly or email corrections to me. Thank you! Cheryn ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Instance Types Feature
Of course after introducing the instance type in ovirt, you will still have control over the instance types and create any instance type you like beyond the pre-defined types you have in public cloud, but you will have two things to set: the instance type and the image, which is more administration... You will still have the templates - you will be able to choose a template which defines both. But it will be hidden in advanced part of the dialog. You are right, the simple way is pretty much inspired by public clouds, because they do great job in making the things easy. You basically just say you want a small machine and attach a rhel image to it. Other advantage of separating the HW and SW configuration is that you can just change the HW profile (instance type) on which you are running, or, if the instance type changes, it gets reflected in all machines using this instance type. This is why I think keeping the template as an entity composed out of an image and a instance type would be great. yep, it seems we will keep it :) It just will be hidden in the advanced options (e.g. one more click). Sounds reasonable? - Original Message - From: Laszlo Hornyak lhorn...@redhat.com To: Tomas Jelinek tjeli...@redhat.com Cc: engine-devel@ovirt.org Sent: Monday, January 28, 2013 12:16:00 PM Subject: Re: [Engine-devel] Instance Types Feature hi, This is what I thought of: In public clouds it is common to have pre-defined instance types e.g. amazon small/medium/large/x-large instance, and this is what customers get even if they don't like it. I guess this helps Amazon a lot to simplify the decision logic for vm scheduling and pricing. In a private cloud, you choose the resources your application needs, therefore you can choose just as much as you need. Of course after introducing the instance type in ovirt, you will still have control over the instance types and create any instance type you like beyond the pre-defined types you have in public cloud, but you will have two things to set: the instance type and the image, which is more administration than just working with templates, while most of the cases the templates were enough: you created both the OS image and the virtual hardware profile it is running on. For another image and another workload, I would most likely want to create another one that just fits the needs. This is why I think keeping the template as an entity composed out of an image and a instance type would be great. Laszlo - Original Message - From: Tomas Jelinek tjeli...@redhat.com To: Laszlo Hornyak lhorn...@redhat.com Cc: engine-devel@ovirt.org Sent: Friday, January 25, 2013 1:32:20 PM Subject: Re: [Engine-devel] Instance Types Feature Hi Laszlo, it is not useful just for public clouds - it can be pretty useful for private as well. But to keep the previous way, it could be done this way: - on the advanced screen (after clicking show advanced options you can specify the template) - by default you pick on basic view the instance type (e.g. HW profile) and the Image (e.g. disk with some metadata such as OS type). But, you can select custom instance type (equivalent to blank template) and no Image. In this case the template appears also on basic view and you can select it. What do you think? Tomas - Original Message - From: Laszlo Hornyak lhorn...@redhat.com To: Tomas Jelinek tjeli...@redhat.com Cc: engine-devel@ovirt.org Sent: Tuesday, January 22, 2013 7:16:32 PM Subject: Re: [Engine-devel] Instance Types Feature Hi Tomas, I like the idea in general, but for me the instance types looks like a feature that is typical in public clouds, while in private clouds it looks more like a cool extra feature for special cases. Therefore in my opinion it would be great to keep the old template solution as well to keep it simple for most users. A template could be an instance type and an image together. Only the description overlap, and that could be solved. Thanks, Laszlo - Original Message - From: Tomas Jelinek tjeli...@redhat.com To: engine-devel@ovirt.org Sent: Tuesday, January 22, 2013 3:09:51 PM Subject: [Engine-devel] Instance Types Feature Hi All, this is the proposed new feature called instance types: http://www.ovirt.org/Features/Instance_Types Long story short - it should basically split the VM template into: - hardware profile called instance types - software profile called image This should enable to do something like: Create a new small VM and attach a disk with RHEL + Postgres installed. Any comments are more than welcome! Tomas ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org
Re: [Engine-devel] Instance Types Feature
1. Why do we need a new set of permissions for Create Instance and Instance Owner? Aren't the VmCreator role and the UserVmManager role enough in these use-cases? ccing Andrew, he might know best 2. iiuc, the internal implementation of instance types and images will be done using templates. correct However, I guess we plan to expose instance types and images as REST resources, right? yes, however the REST will be discussed more deeply once there will be an agreement on FE and BE. Tomas - Original Message - From: Oved Ourfalli ov...@redhat.com To: Tomas Jelinek tjeli...@redhat.com Cc: engine-devel@ovirt.org Sent: Tuesday, January 29, 2013 2:54:13 PM Subject: Re: [Engine-devel] Instance Types Feature Some questions: 1. Why do we need a new set of permissions for Create Instance and Instance Owner? Aren't the VmCreator role and the UserVmManager role enough in these use-cases? 2. iiuc, the internal implementation of instance types and images will be done using templates. However, I guess we plan to expose instance types and images as REST resources, right? Thank you, Oved - Original Message - From: Tomas Jelinek tjeli...@redhat.com To: engine-devel@ovirt.org Sent: Tuesday, January 22, 2013 3:09:51 PM Subject: [Engine-devel] Instance Types Feature Hi All, this is the proposed new feature called instance types: http://www.ovirt.org/Features/Instance_Types Long story short - it should basically split the VM template into: - hardware profile called instance types - software profile called image This should enable to do something like: Create a new small VM and attach a disk with RHEL + Postgres installed. Any comments are more than welcome! Tomas ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
