From rgolan at redhat.com  Sun Sep  1 08:07:19 2013
From: rgolan at redhat.com (Roy Golan)
Date: Sun, 01 Sep 2013 11:07:19 +0300
Subject: [Engine-devel] Cluster default with empty processor name with
 PPC64 support
In-Reply-To: <50EB20226B72D6419356FC320AB62B8719173370@SERV070.corp.eldorado.org.br>
References: <50EB20226B72D6419356FC320AB62B8719173370@SERV070.corp.eldorado.org.br>
Message-ID: <5222F5B7.5060603@redhat.com>

On 08/30/2013 10:51 PM, Leonardo Bianconi wrote:
>
> Hi everyone!
>
> During the development of PPC64 support in the engine, we faced some 
> UX issues regarding the default Cluster (that Cluster with empty 
> processor name).
>
> Currently, oVirt engine allows the default Cluster to contain empty 
> processor name, and the administrator can add VMs and/or Templates to 
> it. The processor name can be assigned later, editing the cluster or 
> assigning a valid host to it.
>
> During the implementation of PPC64 support on the engine, the field 
> "architecture" was added to Clusters, VMs and Templates entities.
>
> So we have the following questions regarding how the UI should behave:
>
> - Shall we keep allowing the administrator to assign VMs and Templates 
> to the Cluster with no processor name or assigned architecture ?
>
>              -> If we have an "yes" for the question above:
>
>              -- We will have to assign the architecture to the Cluster 
> based on the OS of the first assigned VM, and  the processor name 
> could be defined the same way as currently ... editing the Cluster or 
> assigning a compatible Host to it.
>
> -- The VM creation popup will have to be able to indicate the 
> architecture of each OS ... some OSes have the same name, and it may 
> get ambiguous since the Cluster architecture is still undefined at 
> that point (before the first VM get already created).
>
> Thanks!
>
> Regards.
>
> Leonardo Bianconi
>

To add VMs you anyway need a running host in the cluster which means the 
cpu name and the architecture would be the host's.
So we can keep the cluster attributes - "cpu name" and "arch" consistent 
and allow them to be empty on creation.
>
>
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20130901/21d42ef3/attachment.html>

From emesika at redhat.com  Sun Sep  1 08:35:43 2013
From: emesika at redhat.com (Eli Mesika)
Date: Sun, 1 Sep 2013 04:35:43 -0400 (EDT)
Subject: [Engine-devel] Opimizing Postgres Stored Procedures
In-Reply-To: <21621864.7739664.1377879452271.JavaMail.root@redhat.com>
References: <663980392.3966209.1377508940587.JavaMail.root@redhat.com>
	<1800102915.5779668.1377592827358.JavaMail.root@redhat.com>
	<1515360945.5323688.1377683114018.JavaMail.root@redhat.com>
	<1219881405.6480591.1377687738151.JavaMail.root@redhat.com>
	<21621864.7739664.1377879452271.JavaMail.root@redhat.com>
Message-ID: <174208329.7527425.1378024543954.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Laszlo Hornyak" <lhornyak at redhat.com>
> To: "Eli Mesika" <emesika at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>
> Sent: Friday, August 30, 2013 7:17:32 PM
> Subject: Re: [Engine-devel] Opimizing Postgres Stored Procedures
> 
> Hi Eli,
> 
> I wrote a quick benchmark to see if there is any difference when using STABLE
> modifier on functions running queries the way the engine does it (calling it
> from JDBC, one function in a single statement)
> 
> with a stable function:
> create function getKakukk(_id int) returns VARCHAR STABLE as 'select val from
> kakukk where id = $1' language sql;
> and one not marked as stable
> create function getKakukk_(_id int) returns VARCHAR as 'select val from
> kakukk where id = $1' language sql;
> the table is this simple:
> create table kakukk(id int primary key, val varchar);
> and the only content is:
> insert into kakukk (id, val) values (1, 'bla bla bla');
> 
> Now the benchmark code:
> 
> package com.foobar;
> 
> import java.sql.Connection;
> import java.sql.DriverManager;
> import java.sql.PreparedStatement;
> import java.sql.ResultSet;
> import java.sql.SQLException;
> 
> import org.junit.After;
> import org.junit.Before;
> import org.junit.Test;
> 
> public class SpeedTest {
> 
>     Connection connection;
> 
>     @Before
>     public void connect() throws SQLException {
>         connection =
>         DriverManager.getConnection("jdbc:postgresql://localhost/stabletest",
>         "engine", "engine");
>     }
> 
>     @After
>     public void disconnect() throws SQLException {
>         connection.close();
>     }
> 
>     private long measure(Runnable runnable, int times) {
>         final long start = System.currentTimeMillis();
>         for (int i = 0; i < times; i++) {
>             runnable.run();
>         }
>         final long end = System.currentTimeMillis();
>         return end - start;
>     }
> 
>     public static class Select implements Runnable {
> 
>         public Select(PreparedStatement preparedStatement) {
>             super();
>             this.preparedStatement = preparedStatement;
>         }
> 
>         final PreparedStatement preparedStatement;
> 
>         public void run() {
>             try (
>                     ResultSet resultSet = preparedStatement.executeQuery();)
>                     {
>                 while (resultSet.next()) {
>                     // nothing, just next
>                 }
>             } catch (SQLException e) {
>                 // TODO Auto-generated catch block
>                 e.printStackTrace();
>             }
>         }
>     }
> 
>     @Test
>     public void performTest() throws SQLException {
>         for (int i = 0; i < 10; i++) {
>             try (
>                     PreparedStatement stable =
>                     connection.prepareStatement("select getKakukk(1)");
>                     PreparedStatement notStable =
>                     connection.prepareStatement("select getKakukk_(1)");) {
>                 System.out.println("STABLE: " + measure(new Select(stable),
>                 100000));
>                 System.out.println("not STABLE: " + measure(new
>                 Select(notStable), 100000));
>                 System.out.println("---");
> 
>             }
>         }
>     }
> }
> 
> 
> --
> 
> The results are very similar, seemingly no difference at all.
> Therefore, it seems we do not need those STABLE markers for performance
> reasons.

Please refer to http://www.postgresql.org/docs/8.3/static/xfunc-volatility.html
It says :

"For best optimization results, you should label your functions with the strictest volatility category that is valid for them."

So , using STABLE , IMMUTABLE , STRICT is mandatory from now on.

Thanks  
Eli


> 
> Thank you,
> Laszlo
> 
> ----- Original Message -----
> > From: "Laszlo Hornyak" <lhornyak at redhat.com>
> > To: "Eli Mesika" <emesika at redhat.com>
> > Cc: "engine-devel" <engine-devel at ovirt.org>
> > Sent: Wednesday, August 28, 2013 1:02:18 PM
> > Subject: Re: [Engine-devel] Opimizing Postgres Stored Procedures
> > 
> > 
> > ----- Original Message -----
> > > From: "Eli Mesika" <emesika at redhat.com>
> > > To: "Laszlo Hornyak" <lhornyak at redhat.com>
> > > Cc: "engine-devel" <engine-devel at ovirt.org>
> > > Sent: Wednesday, August 28, 2013 11:45:14 AM
> > > Subject: Re: [Engine-devel] Opimizing Postgres Stored Procedures
> > > 
> > > 
> > > 
> > > ----- Original Message -----
> > > > From: "Laszlo Hornyak" <lhornyak at redhat.com>
> > > > To: "Eli Mesika" <emesika at redhat.com>
> > > > Cc: "engine-devel" <engine-devel at ovirt.org>
> > > > Sent: Tuesday, August 27, 2013 11:40:27 AM
> > > > Subject: Re: [Engine-devel] Opimizing Postgres Stored Procedures
> > > > 
> > > > Hi Eli,
> > > > 
> > > > Most of the functions that we have in the DB are doing very simple jobs
> > > > like
> > > > run a query, insert/update and I see that now you have all QUERY
> > > > functions
> > > > as STABLE.
> > > > My questions:
> > > > Is this required for new functions from now on?
> > > Yes and a email asking that was posted to engine_devel
> > > 
> > > > Is this done in order to improve performance?
> > > Yes
> > 
> > Do you have any documents/benchmarks on how and why does this improve
> > performance?
> > STABLE functions should improve performance if they return the same result
> > for the same parameters in the same statement.
> > E.g. if you have a stable function like "select foo(x) from y" then the
> > function can be invoked only once to evaluate each distinct value of y.x -
> > this is kind of useful
> > Functions running queries for the ovirt engine are typically invoked from
> > client side, therefore they are only ivoked once from the parameters list
> > and therefore will be only executed once for that single statement.
> > 
> > > 
> > > > 
> > > > Thank you,
> > > > Laszlo
> > > > 
> > > > ----- Original Message -----
> > > > > From: "Eli Mesika" <emesika at redhat.com>
> > > > > To: "engine-devel" <engine-devel at ovirt.org>
> > > > > Sent: Monday, August 26, 2013 11:22:20 AM
> > > > > Subject: [Engine-devel] Opimizing Postgres Stored Procedures
> > > > > 
> > > > > Hi
> > > > > 
> > > > > I had merged the following patch
> > > > > http://gerrit.ovirt.org/#/c/17962/
> > > > > 
> > > > > This patch introduce usage of the IMMUTABLE, STABLE and STRICT
> > > > > keywords
> > > > > in
> > > > > order to boost performance of the Postgres SPs.
> > > > > 
> > > > > Please make sure that your current/and future DB scripts applied
> > > > > that.
> > > > > 
> > > > > 
> > > > > Volatility
> > > > > ----------
> > > > > * A function should be marked as IMMUTABLE if it doesn't change the
> > > > > database,
> > > > > and if it doesn't perform any lookups (even for database
> > > > > configuration
> > > > > values) during its operation.
> > > > > * A function should be marked STABLE if it doesn't change the
> > > > > database,
> > > > > but
> > > > > might perform lookups (IMMUTABLE is preferable if function meets the
> > > > > requirements).
> > > > > * A function doesn't need to be marked VOLATILE, because that's the
> > > > > default.
> > > > > 
> > > > > STRICTNESS
> > > > > ----------
> > > > > A function should be marked STRICT if it should return NULL when it
> > > > > is
> > > > > passed
> > > > > a NULL argument, and then the function won't even be called if it is
> > > > > indeed
> > > > > passed a NULL argument.
> > > > > 
> > > > > 
> > > > > I am available for any questions.
> > > > > 
> > > > > Thanks
> > > > > 
> > > > > Eli
> > > > > _______________________________________________
> > > > > Engine-devel mailing list
> > > > > Engine-devel at ovirt.org
> > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > > > 
> > > > 
> > > 
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > 
> 


From rgolan at redhat.com  Sun Sep  1 10:28:08 2013
From: rgolan at redhat.com (Roy Golan)
Date: Sun, 01 Sep 2013 13:28:08 +0300
Subject: [Engine-devel] Mapping between supported display protocols and
 video devices
In-Reply-To: <B2CAFC4D5E2D574A883EF61ACD5ADE3301812218@SERV070.corp.eldorado.org.br>
References: <B2CAFC4D5E2D574A883EF61ACD5ADE3301812218@SERV070.corp.eldorado.org.br>
Message-ID: <522316B8.10603@redhat.com>

On 08/30/2013 07:33 PM, Vitor de Lima wrote:
> Hi everyone,
>
> Recently the changes #18150, #18677 and #17885 were submitted in order to avoid the selection of display protocols and virtual video cards that are incompatible with the PPC64 architecture and to map the VNC protocol with the standard VGA virtual device, since the Cirrus Logic device is not supported in the PPC64 architecture. I would like some feedback about that.
>
> So far, these changes use an existing parameter in the osinfo (called "spiceSupport") to validate if the selected operating system supports SPICE and hide it in the frontend in case it doesn't. They also change the default virtual video card for each display protocol according to new properties in the osinfo, e.g.:
>
> os.other.spiceSupport.value = true
> os.other.devices.vnc.vmDeviceType.value = cirrus os.other.devices.qxl.vmDeviceType.value = qxl
> os.other_ppc64.spiceSupport.value = false os.other_ppc64.devices.vnc.vmDeviceType.value = vga
> (This maps the qxl protocol into the qxl device and the VNC protocol into the cirrus device in the x86_64 arch, and the VNC protocol into the VGA device in the PPC64)
>
> However, this still has some limitations, such as:
>
> * It doesn't allow the user to choose between the different virtual devices that exist and can be used in the VNC protocol (such as the QXL and VMware VGA)
> * The syntax is ugly. As suggested in the code reviews, it could be a list of supported protocols, e.g.:
> os.other.displayProtocols = vnc, spice
+1 list style is cleaner, expressive and easy to use. spiceSupport was 
just the way to convert the old code to the osinfo style.

protocol-device mapping can be achieved by pairing them literally -

os.other.displayProtocols.value = vnc/cirrus, spice/qxl

which reads VNC over cirrus device, SPICE over qxl device.

and for ppc64:

os.other_ppc64.displayProtocols.value = vnc/qxl, spice/qxl


I like this approach better than naming the keys with terms 
...devices.vnc.VMDviceType....

> So, how should the engine be modified to allow multiple video cards for each display protocol? What do you think should be done?

> Thanks,
> Vitor de Lima
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel



From lhornyak at redhat.com  Sun Sep  1 11:47:02 2013
From: lhornyak at redhat.com (Laszlo Hornyak)
Date: Sun, 1 Sep 2013 07:47:02 -0400 (EDT)
Subject: [Engine-devel] Opimizing Postgres Stored Procedures
In-Reply-To: <174208329.7527425.1378024543954.JavaMail.root@redhat.com>
References: <663980392.3966209.1377508940587.JavaMail.root@redhat.com>
	<1800102915.5779668.1377592827358.JavaMail.root@redhat.com>
	<1515360945.5323688.1377683114018.JavaMail.root@redhat.com>
	<1219881405.6480591.1377687738151.JavaMail.root@redhat.com>
	<21621864.7739664.1377879452271.JavaMail.root@redhat.com>
	<174208329.7527425.1378024543954.JavaMail.root@redhat.com>
Message-ID: <750017409.7975042.1378036022716.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Eli Mesika" <emesika at redhat.com>
> To: "Laszlo Hornyak" <lhornyak at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>
> Sent: Sunday, September 1, 2013 10:35:43 AM
> Subject: Re: [Engine-devel] Opimizing Postgres Stored Procedures
> 
> 
> 
> ----- Original Message -----
> > From: "Laszlo Hornyak" <lhornyak at redhat.com>
> > To: "Eli Mesika" <emesika at redhat.com>
> > Cc: "engine-devel" <engine-devel at ovirt.org>
> > Sent: Friday, August 30, 2013 7:17:32 PM
> > Subject: Re: [Engine-devel] Opimizing Postgres Stored Procedures
> > 
> > Hi Eli,
> > 
> > I wrote a quick benchmark to see if there is any difference when using
> > STABLE
> > modifier on functions running queries the way the engine does it (calling
> > it
> > from JDBC, one function in a single statement)
> > 
> > with a stable function:
> > create function getKakukk(_id int) returns VARCHAR STABLE as 'select val
> > from
> > kakukk where id = $1' language sql;
> > and one not marked as stable
> > create function getKakukk_(_id int) returns VARCHAR as 'select val from
> > kakukk where id = $1' language sql;
> > the table is this simple:
> > create table kakukk(id int primary key, val varchar);
> > and the only content is:
> > insert into kakukk (id, val) values (1, 'bla bla bla');
> > 
> > Now the benchmark code:
> > 
> > package com.foobar;
> > 
> > import java.sql.Connection;
> > import java.sql.DriverManager;
> > import java.sql.PreparedStatement;
> > import java.sql.ResultSet;
> > import java.sql.SQLException;
> > 
> > import org.junit.After;
> > import org.junit.Before;
> > import org.junit.Test;
> > 
> > public class SpeedTest {
> > 
> >     Connection connection;
> > 
> >     @Before
> >     public void connect() throws SQLException {
> >         connection =
> >         DriverManager.getConnection("jdbc:postgresql://localhost/stabletest",
> >         "engine", "engine");
> >     }
> > 
> >     @After
> >     public void disconnect() throws SQLException {
> >         connection.close();
> >     }
> > 
> >     private long measure(Runnable runnable, int times) {
> >         final long start = System.currentTimeMillis();
> >         for (int i = 0; i < times; i++) {
> >             runnable.run();
> >         }
> >         final long end = System.currentTimeMillis();
> >         return end - start;
> >     }
> > 
> >     public static class Select implements Runnable {
> > 
> >         public Select(PreparedStatement preparedStatement) {
> >             super();
> >             this.preparedStatement = preparedStatement;
> >         }
> > 
> >         final PreparedStatement preparedStatement;
> > 
> >         public void run() {
> >             try (
> >                     ResultSet resultSet =
> >                     preparedStatement.executeQuery();)
> >                     {
> >                 while (resultSet.next()) {
> >                     // nothing, just next
> >                 }
> >             } catch (SQLException e) {
> >                 // TODO Auto-generated catch block
> >                 e.printStackTrace();
> >             }
> >         }
> >     }
> > 
> >     @Test
> >     public void performTest() throws SQLException {
> >         for (int i = 0; i < 10; i++) {
> >             try (
> >                     PreparedStatement stable =
> >                     connection.prepareStatement("select getKakukk(1)");
> >                     PreparedStatement notStable =
> >                     connection.prepareStatement("select getKakukk_(1)");) {
> >                 System.out.println("STABLE: " + measure(new Select(stable),
> >                 100000));
> >                 System.out.println("not STABLE: " + measure(new
> >                 Select(notStable), 100000));
> >                 System.out.println("---");
> > 
> >             }
> >         }
> >     }
> > }
> > 
> > 
> > --
> > 
> > The results are very similar, seemingly no difference at all.
> > Therefore, it seems we do not need those STABLE markers for performance
> > reasons.
> 
> Please refer to
> http://www.postgresql.org/docs/8.3/static/xfunc-volatility.html
> It says :
> 
> "For best optimization results, you should label your functions with the
> strictest volatility category that is valid for them."

I am sure the postgres guys did not mean "without even thinking about it" :)
The way the enginge is using these functions, it will not improve performance, which is not a problem. The problem in my opinion is that more requirements increase the time needed for review procedure, which is already quite lengthy. This new requirement does not seem to have any benefit. If we want to improve the development process then we should not have requirements that do not come with benefits.

Best regards,
Laszlo

> 
> So , using STABLE , IMMUTABLE , STRICT is mandatory from now on.
> 
> Thanks
> Eli
> 
> 
> > 
> > Thank you,
> > Laszlo
> > 
> > ----- Original Message -----
> > > From: "Laszlo Hornyak" <lhornyak at redhat.com>
> > > To: "Eli Mesika" <emesika at redhat.com>
> > > Cc: "engine-devel" <engine-devel at ovirt.org>
> > > Sent: Wednesday, August 28, 2013 1:02:18 PM
> > > Subject: Re: [Engine-devel] Opimizing Postgres Stored Procedures
> > > 
> > > 
> > > ----- Original Message -----
> > > > From: "Eli Mesika" <emesika at redhat.com>
> > > > To: "Laszlo Hornyak" <lhornyak at redhat.com>
> > > > Cc: "engine-devel" <engine-devel at ovirt.org>
> > > > Sent: Wednesday, August 28, 2013 11:45:14 AM
> > > > Subject: Re: [Engine-devel] Opimizing Postgres Stored Procedures
> > > > 
> > > > 
> > > > 
> > > > ----- Original Message -----
> > > > > From: "Laszlo Hornyak" <lhornyak at redhat.com>
> > > > > To: "Eli Mesika" <emesika at redhat.com>
> > > > > Cc: "engine-devel" <engine-devel at ovirt.org>
> > > > > Sent: Tuesday, August 27, 2013 11:40:27 AM
> > > > > Subject: Re: [Engine-devel] Opimizing Postgres Stored Procedures
> > > > > 
> > > > > Hi Eli,
> > > > > 
> > > > > Most of the functions that we have in the DB are doing very simple
> > > > > jobs
> > > > > like
> > > > > run a query, insert/update and I see that now you have all QUERY
> > > > > functions
> > > > > as STABLE.
> > > > > My questions:
> > > > > Is this required for new functions from now on?
> > > > Yes and a email asking that was posted to engine_devel
> > > > 
> > > > > Is this done in order to improve performance?
> > > > Yes
> > > 
> > > Do you have any documents/benchmarks on how and why does this improve
> > > performance?
> > > STABLE functions should improve performance if they return the same
> > > result
> > > for the same parameters in the same statement.
> > > E.g. if you have a stable function like "select foo(x) from y" then the
> > > function can be invoked only once to evaluate each distinct value of y.x
> > > -
> > > this is kind of useful
> > > Functions running queries for the ovirt engine are typically invoked from
> > > client side, therefore they are only ivoked once from the parameters list
> > > and therefore will be only executed once for that single statement.
> > > 
> > > > 
> > > > > 
> > > > > Thank you,
> > > > > Laszlo
> > > > > 
> > > > > ----- Original Message -----
> > > > > > From: "Eli Mesika" <emesika at redhat.com>
> > > > > > To: "engine-devel" <engine-devel at ovirt.org>
> > > > > > Sent: Monday, August 26, 2013 11:22:20 AM
> > > > > > Subject: [Engine-devel] Opimizing Postgres Stored Procedures
> > > > > > 
> > > > > > Hi
> > > > > > 
> > > > > > I had merged the following patch
> > > > > > http://gerrit.ovirt.org/#/c/17962/
> > > > > > 
> > > > > > This patch introduce usage of the IMMUTABLE, STABLE and STRICT
> > > > > > keywords
> > > > > > in
> > > > > > order to boost performance of the Postgres SPs.
> > > > > > 
> > > > > > Please make sure that your current/and future DB scripts applied
> > > > > > that.
> > > > > > 
> > > > > > 
> > > > > > Volatility
> > > > > > ----------
> > > > > > * A function should be marked as IMMUTABLE if it doesn't change the
> > > > > > database,
> > > > > > and if it doesn't perform any lookups (even for database
> > > > > > configuration
> > > > > > values) during its operation.
> > > > > > * A function should be marked STABLE if it doesn't change the
> > > > > > database,
> > > > > > but
> > > > > > might perform lookups (IMMUTABLE is preferable if function meets
> > > > > > the
> > > > > > requirements).
> > > > > > * A function doesn't need to be marked VOLATILE, because that's the
> > > > > > default.
> > > > > > 
> > > > > > STRICTNESS
> > > > > > ----------
> > > > > > A function should be marked STRICT if it should return NULL when it
> > > > > > is
> > > > > > passed
> > > > > > a NULL argument, and then the function won't even be called if it
> > > > > > is
> > > > > > indeed
> > > > > > passed a NULL argument.
> > > > > > 
> > > > > > 
> > > > > > I am available for any questions.
> > > > > > 
> > > > > > Thanks
> > > > > > 
> > > > > > Eli
> > > > > > _______________________________________________
> > > > > > Engine-devel mailing list
> > > > > > Engine-devel at ovirt.org
> > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > > > > 
> > > > > 
> > > > 
> > > _______________________________________________
> > > Engine-devel mailing list
> > > Engine-devel at ovirt.org
> > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > 
> > 
> 


From emesika at redhat.com  Sun Sep  1 13:29:06 2013
From: emesika at redhat.com (Eli Mesika)
Date: Sun, 1 Sep 2013 09:29:06 -0400 (EDT)
Subject: [Engine-devel] Opimizing Postgres Stored Procedures
In-Reply-To: <750017409.7975042.1378036022716.JavaMail.root@redhat.com>
References: <663980392.3966209.1377508940587.JavaMail.root@redhat.com>
	<1800102915.5779668.1377592827358.JavaMail.root@redhat.com>
	<1515360945.5323688.1377683114018.JavaMail.root@redhat.com>
	<1219881405.6480591.1377687738151.JavaMail.root@redhat.com>
	<21621864.7739664.1377879452271.JavaMail.root@redhat.com>
	<174208329.7527425.1378024543954.JavaMail.root@redhat.com>
	<750017409.7975042.1378036022716.JavaMail.root@redhat.com>
Message-ID: <1299252547.7554802.1378042146981.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Laszlo Hornyak" <lhornyak at redhat.com>
> To: "Eli Mesika" <emesika at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>
> Sent: Sunday, September 1, 2013 2:47:02 PM
> Subject: Re: [Engine-devel] Opimizing Postgres Stored Procedures
> 
> 
> 
> ----- Original Message -----
> > From: "Eli Mesika" <emesika at redhat.com>
> > To: "Laszlo Hornyak" <lhornyak at redhat.com>
> > Cc: "engine-devel" <engine-devel at ovirt.org>
> > Sent: Sunday, September 1, 2013 10:35:43 AM
> > Subject: Re: [Engine-devel] Opimizing Postgres Stored Procedures
> > 
> > 
> > 
> > ----- Original Message -----
> > > From: "Laszlo Hornyak" <lhornyak at redhat.com>
> > > To: "Eli Mesika" <emesika at redhat.com>
> > > Cc: "engine-devel" <engine-devel at ovirt.org>
> > > Sent: Friday, August 30, 2013 7:17:32 PM
> > > Subject: Re: [Engine-devel] Opimizing Postgres Stored Procedures
> > > 
> > > Hi Eli,
> > > 
> > > I wrote a quick benchmark to see if there is any difference when using
> > > STABLE
> > > modifier on functions running queries the way the engine does it (calling
> > > it
> > > from JDBC, one function in a single statement)
> > > 
> > > with a stable function:
> > > create function getKakukk(_id int) returns VARCHAR STABLE as 'select val
> > > from
> > > kakukk where id = $1' language sql;
> > > and one not marked as stable
> > > create function getKakukk_(_id int) returns VARCHAR as 'select val from
> > > kakukk where id = $1' language sql;
> > > the table is this simple:
> > > create table kakukk(id int primary key, val varchar);
> > > and the only content is:
> > > insert into kakukk (id, val) values (1, 'bla bla bla');
> > > 
> > > Now the benchmark code:
> > > 
> > > package com.foobar;
> > > 
> > > import java.sql.Connection;
> > > import java.sql.DriverManager;
> > > import java.sql.PreparedStatement;
> > > import java.sql.ResultSet;
> > > import java.sql.SQLException;
> > > 
> > > import org.junit.After;
> > > import org.junit.Before;
> > > import org.junit.Test;
> > > 
> > > public class SpeedTest {
> > > 
> > >     Connection connection;
> > > 
> > >     @Before
> > >     public void connect() throws SQLException {
> > >         connection =
> > >         DriverManager.getConnection("jdbc:postgresql://localhost/stabletest",
> > >         "engine", "engine");
> > >     }
> > > 
> > >     @After
> > >     public void disconnect() throws SQLException {
> > >         connection.close();
> > >     }
> > > 
> > >     private long measure(Runnable runnable, int times) {
> > >         final long start = System.currentTimeMillis();
> > >         for (int i = 0; i < times; i++) {
> > >             runnable.run();
> > >         }
> > >         final long end = System.currentTimeMillis();
> > >         return end - start;
> > >     }
> > > 
> > >     public static class Select implements Runnable {
> > > 
> > >         public Select(PreparedStatement preparedStatement) {
> > >             super();
> > >             this.preparedStatement = preparedStatement;
> > >         }
> > > 
> > >         final PreparedStatement preparedStatement;
> > > 
> > >         public void run() {
> > >             try (
> > >                     ResultSet resultSet =
> > >                     preparedStatement.executeQuery();)
> > >                     {
> > >                 while (resultSet.next()) {
> > >                     // nothing, just next
> > >                 }
> > >             } catch (SQLException e) {
> > >                 // TODO Auto-generated catch block
> > >                 e.printStackTrace();
> > >             }
> > >         }
> > >     }
> > > 
> > >     @Test
> > >     public void performTest() throws SQLException {
> > >         for (int i = 0; i < 10; i++) {
> > >             try (
> > >                     PreparedStatement stable =
> > >                     connection.prepareStatement("select getKakukk(1)");
> > >                     PreparedStatement notStable =
> > >                     connection.prepareStatement("select getKakukk_(1)");)
> > >                     {
> > >                 System.out.println("STABLE: " + measure(new
> > >                 Select(stable),
> > >                 100000));
> > >                 System.out.println("not STABLE: " + measure(new
> > >                 Select(notStable), 100000));
> > >                 System.out.println("---");
> > > 
> > >             }
> > >         }
> > >     }
> > > }
> > > 
> > > 
> > > --
> > > 
> > > The results are very similar, seemingly no difference at all.
> > > Therefore, it seems we do not need those STABLE markers for performance
> > > reasons.
> > 
> > Please refer to
> > http://www.postgresql.org/docs/8.3/static/xfunc-volatility.html
> > It says :
> > 
> > "For best optimization results, you should label your functions with the
> > strictest volatility category that is valid for them."
> 
> I am sure the postgres guys did not mean "without even thinking about it" :)
> The way the enginge is using these functions, it will not improve
> performance, which is not a problem. The problem in my opinion is that more
> requirements increase the time needed for review procedure, which is already
> quite lengthy. This new requirement does not seem to have any benefit. If we
> want to improve the development process then we should not have requirements
> that do not come with benefits.

I totally disagree, I think the opposite , if this will not be a clear rule of thumb , it will be used incorrectly.
Thinking on each SP if you will benefit or not  in terms of performance if you use those keywords will increase the review time when any reviewer will need to think if he needs that or not.
I don't think that adding a word to the SP will affect development or review time , it should be like you are writing the word FUNCTION for a SP definition and will become a habit.
I am against complicated rules like "add those keywords whenever you like" , if the documentations says a clear instruction to use those keywords in certain circumstances, that's what I would exactly do and  recommend to others.

Thanks
 

> 
> Best regards,
> Laszlo
> 
> > 
> > So , using STABLE , IMMUTABLE , STRICT is mandatory from now on.
> > 
> > Thanks
> > Eli
> > 
> > 
> > > 
> > > Thank you,
> > > Laszlo
> > > 
> > > ----- Original Message -----
> > > > From: "Laszlo Hornyak" <lhornyak at redhat.com>
> > > > To: "Eli Mesika" <emesika at redhat.com>
> > > > Cc: "engine-devel" <engine-devel at ovirt.org>
> > > > Sent: Wednesday, August 28, 2013 1:02:18 PM
> > > > Subject: Re: [Engine-devel] Opimizing Postgres Stored Procedures
> > > > 
> > > > 
> > > > ----- Original Message -----
> > > > > From: "Eli Mesika" <emesika at redhat.com>
> > > > > To: "Laszlo Hornyak" <lhornyak at redhat.com>
> > > > > Cc: "engine-devel" <engine-devel at ovirt.org>
> > > > > Sent: Wednesday, August 28, 2013 11:45:14 AM
> > > > > Subject: Re: [Engine-devel] Opimizing Postgres Stored Procedures
> > > > > 
> > > > > 
> > > > > 
> > > > > ----- Original Message -----
> > > > > > From: "Laszlo Hornyak" <lhornyak at redhat.com>
> > > > > > To: "Eli Mesika" <emesika at redhat.com>
> > > > > > Cc: "engine-devel" <engine-devel at ovirt.org>
> > > > > > Sent: Tuesday, August 27, 2013 11:40:27 AM
> > > > > > Subject: Re: [Engine-devel] Opimizing Postgres Stored Procedures
> > > > > > 
> > > > > > Hi Eli,
> > > > > > 
> > > > > > Most of the functions that we have in the DB are doing very simple
> > > > > > jobs
> > > > > > like
> > > > > > run a query, insert/update and I see that now you have all QUERY
> > > > > > functions
> > > > > > as STABLE.
> > > > > > My questions:
> > > > > > Is this required for new functions from now on?
> > > > > Yes and a email asking that was posted to engine_devel
> > > > > 
> > > > > > Is this done in order to improve performance?
> > > > > Yes
> > > > 
> > > > Do you have any documents/benchmarks on how and why does this improve
> > > > performance?
> > > > STABLE functions should improve performance if they return the same
> > > > result
> > > > for the same parameters in the same statement.
> > > > E.g. if you have a stable function like "select foo(x) from y" then the
> > > > function can be invoked only once to evaluate each distinct value of
> > > > y.x
> > > > -
> > > > this is kind of useful
> > > > Functions running queries for the ovirt engine are typically invoked
> > > > from
> > > > client side, therefore they are only ivoked once from the parameters
> > > > list
> > > > and therefore will be only executed once for that single statement.
> > > > 
> > > > > 
> > > > > > 
> > > > > > Thank you,
> > > > > > Laszlo
> > > > > > 
> > > > > > ----- Original Message -----
> > > > > > > From: "Eli Mesika" <emesika at redhat.com>
> > > > > > > To: "engine-devel" <engine-devel at ovirt.org>
> > > > > > > Sent: Monday, August 26, 2013 11:22:20 AM
> > > > > > > Subject: [Engine-devel] Opimizing Postgres Stored Procedures
> > > > > > > 
> > > > > > > Hi
> > > > > > > 
> > > > > > > I had merged the following patch
> > > > > > > http://gerrit.ovirt.org/#/c/17962/
> > > > > > > 
> > > > > > > This patch introduce usage of the IMMUTABLE, STABLE and STRICT
> > > > > > > keywords
> > > > > > > in
> > > > > > > order to boost performance of the Postgres SPs.
> > > > > > > 
> > > > > > > Please make sure that your current/and future DB scripts applied
> > > > > > > that.
> > > > > > > 
> > > > > > > 
> > > > > > > Volatility
> > > > > > > ----------
> > > > > > > * A function should be marked as IMMUTABLE if it doesn't change
> > > > > > > the
> > > > > > > database,
> > > > > > > and if it doesn't perform any lookups (even for database
> > > > > > > configuration
> > > > > > > values) during its operation.
> > > > > > > * A function should be marked STABLE if it doesn't change the
> > > > > > > database,
> > > > > > > but
> > > > > > > might perform lookups (IMMUTABLE is preferable if function meets
> > > > > > > the
> > > > > > > requirements).
> > > > > > > * A function doesn't need to be marked VOLATILE, because that's
> > > > > > > the
> > > > > > > default.
> > > > > > > 
> > > > > > > STRICTNESS
> > > > > > > ----------
> > > > > > > A function should be marked STRICT if it should return NULL when
> > > > > > > it
> > > > > > > is
> > > > > > > passed
> > > > > > > a NULL argument, and then the function won't even be called if it
> > > > > > > is
> > > > > > > indeed
> > > > > > > passed a NULL argument.
> > > > > > > 
> > > > > > > 
> > > > > > > I am available for any questions.
> > > > > > > 
> > > > > > > Thanks
> > > > > > > 
> > > > > > > Eli
> > > > > > > _______________________________________________
> > > > > > > Engine-devel mailing list
> > > > > > > Engine-devel at ovirt.org
> > > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > > > > > 
> > > > > > 
> > > > > 
> > > > _______________________________________________
> > > > Engine-devel mailing list
> > > > Engine-devel at ovirt.org
> > > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > > 
> > > 
> > 
> 


From ehildesh at redhat.com  Sun Sep  1 13:41:07 2013
From: ehildesh at redhat.com (Eldan Hildesheim)
Date: Sun, 1 Sep 2013 09:41:07 -0400 (EDT)
Subject: [Engine-devel] UX inputs on gluster volume async tasks
In-Reply-To: <272457150.6004512.1377868964117.JavaMail.root@redhat.com>
References: <521DDF73.9090505@redhat.com>
	<272457150.6004512.1377868964117.JavaMail.root@redhat.com>
Message-ID: <1378943009.5182853.1378042867887.JavaMail.root@redhat.com>

Hi all,
I have few more questions.
1. How often do we get the data of the activity changes: I wonder if we can change the activity icon by a progress one.
2. Normally in oVirt / Rhev we show more data as a "sub tab". Can we assume that Rebalance status is like "more data" and then put all the data that is now in the modal inside a new sub tab name (activity)?
3. The icon of "Migration data from Brick in progress": Is this apart of the Rebalance process? Is this a derived aspect of the rebalance?
4. Do you have a phone num we can call Monday?
Thanks,
Eldan
 

----- Original Message -----
From: "Malini Rao" <mrao at redhat.com>
To: "Sahina Bose" <sabose at redhat.com>
Cc: "Eldan Hildesheim" <ehildesh at redhat.com>, "engine-devel" <engine-devel at ovirt.org>, "Dusmant Pati" <dpati at redhat.com>
Sent: Friday, August 30, 2013 4:22:44 PM
Subject: Re: UX inputs on gluster volume async tasks

Sahina, 

Attached are my detailed comments and questions about this feature from a UX perspective. If it is easier, we can get on a call to discuss the questions and other points. Let me know what you prefer.

Thanks 
Malini

----- Original Message -----
From: "Sahina Bose" <sabose at redhat.com>
To: "Malini Rao" <mrao at redhat.com>, "Eldan Hildesheim" <ehildesh at redhat.com>
Cc: "engine-devel" <engine-devel at ovirt.org>, "Dusmant Pati" <dpati at redhat.com>
Sent: Wednesday, August 28, 2013 7:30:59 AM
Subject: UX inputs on gluster volume async tasks

Hi Malini, Eldan,

Could you provide feedback from UX perspective on this feature?

The feature description and User flows are at
http://www.ovirt.org/Features/Gluster_Volume_Asynchronous_Tasks_Management

thanks
sahina



From lhornyak at redhat.com  Sun Sep  1 14:13:39 2013
From: lhornyak at redhat.com (Laszlo Hornyak)
Date: Sun, 1 Sep 2013 10:13:39 -0400 (EDT)
Subject: [Engine-devel] Opimizing Postgres Stored Procedures
In-Reply-To: <1299252547.7554802.1378042146981.JavaMail.root@redhat.com>
References: <663980392.3966209.1377508940587.JavaMail.root@redhat.com>
	<1800102915.5779668.1377592827358.JavaMail.root@redhat.com>
	<1515360945.5323688.1377683114018.JavaMail.root@redhat.com>
	<1219881405.6480591.1377687738151.JavaMail.root@redhat.com>
	<21621864.7739664.1377879452271.JavaMail.root@redhat.com>
	<174208329.7527425.1378024543954.JavaMail.root@redhat.com>
	<750017409.7975042.1378036022716.JavaMail.root@redhat.com>
	<1299252547.7554802.1378042146981.JavaMail.root@redhat.com>
Message-ID: <1199015638.7978864.1378044819900.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Eli Mesika" <emesika at redhat.com>
> To: "Laszlo Hornyak" <lhornyak at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>
> Sent: Sunday, September 1, 2013 3:29:06 PM
> Subject: Re: [Engine-devel] Opimizing Postgres Stored Procedures
> 
> 
> 
> ----- Original Message -----
> > From: "Laszlo Hornyak" <lhornyak at redhat.com>
> > To: "Eli Mesika" <emesika at redhat.com>
> > Cc: "engine-devel" <engine-devel at ovirt.org>
> > Sent: Sunday, September 1, 2013 2:47:02 PM
> > Subject: Re: [Engine-devel] Opimizing Postgres Stored Procedures
> > 
> > 
> > 
> > ----- Original Message -----
> > > From: "Eli Mesika" <emesika at redhat.com>
> > > To: "Laszlo Hornyak" <lhornyak at redhat.com>
> > > Cc: "engine-devel" <engine-devel at ovirt.org>
> > > Sent: Sunday, September 1, 2013 10:35:43 AM
> > > Subject: Re: [Engine-devel] Opimizing Postgres Stored Procedures
> > > 
> > > 
> > > 
> > > ----- Original Message -----
> > > > From: "Laszlo Hornyak" <lhornyak at redhat.com>
> > > > To: "Eli Mesika" <emesika at redhat.com>
> > > > Cc: "engine-devel" <engine-devel at ovirt.org>
> > > > Sent: Friday, August 30, 2013 7:17:32 PM
> > > > Subject: Re: [Engine-devel] Opimizing Postgres Stored Procedures
> > > > 
> > > > Hi Eli,
> > > > 
> > > > I wrote a quick benchmark to see if there is any difference when using
> > > > STABLE
> > > > modifier on functions running queries the way the engine does it
> > > > (calling
> > > > it
> > > > from JDBC, one function in a single statement)
> > > > 
> > > > with a stable function:
> > > > create function getKakukk(_id int) returns VARCHAR STABLE as 'select
> > > > val
> > > > from
> > > > kakukk where id = $1' language sql;
> > > > and one not marked as stable
> > > > create function getKakukk_(_id int) returns VARCHAR as 'select val from
> > > > kakukk where id = $1' language sql;
> > > > the table is this simple:
> > > > create table kakukk(id int primary key, val varchar);
> > > > and the only content is:
> > > > insert into kakukk (id, val) values (1, 'bla bla bla');
> > > > 
> > > > Now the benchmark code:
> > > > 
> > > > package com.foobar;
> > > > 
> > > > import java.sql.Connection;
> > > > import java.sql.DriverManager;
> > > > import java.sql.PreparedStatement;
> > > > import java.sql.ResultSet;
> > > > import java.sql.SQLException;
> > > > 
> > > > import org.junit.After;
> > > > import org.junit.Before;
> > > > import org.junit.Test;
> > > > 
> > > > public class SpeedTest {
> > > > 
> > > >     Connection connection;
> > > > 
> > > >     @Before
> > > >     public void connect() throws SQLException {
> > > >         connection =
> > > >         DriverManager.getConnection("jdbc:postgresql://localhost/stabletest",
> > > >         "engine", "engine");
> > > >     }
> > > > 
> > > >     @After
> > > >     public void disconnect() throws SQLException {
> > > >         connection.close();
> > > >     }
> > > > 
> > > >     private long measure(Runnable runnable, int times) {
> > > >         final long start = System.currentTimeMillis();
> > > >         for (int i = 0; i < times; i++) {
> > > >             runnable.run();
> > > >         }
> > > >         final long end = System.currentTimeMillis();
> > > >         return end - start;
> > > >     }
> > > > 
> > > >     public static class Select implements Runnable {
> > > > 
> > > >         public Select(PreparedStatement preparedStatement) {
> > > >             super();
> > > >             this.preparedStatement = preparedStatement;
> > > >         }
> > > > 
> > > >         final PreparedStatement preparedStatement;
> > > > 
> > > >         public void run() {
> > > >             try (
> > > >                     ResultSet resultSet =
> > > >                     preparedStatement.executeQuery();)
> > > >                     {
> > > >                 while (resultSet.next()) {
> > > >                     // nothing, just next
> > > >                 }
> > > >             } catch (SQLException e) {
> > > >                 // TODO Auto-generated catch block
> > > >                 e.printStackTrace();
> > > >             }
> > > >         }
> > > >     }
> > > > 
> > > >     @Test
> > > >     public void performTest() throws SQLException {
> > > >         for (int i = 0; i < 10; i++) {
> > > >             try (
> > > >                     PreparedStatement stable =
> > > >                     connection.prepareStatement("select getKakukk(1)");
> > > >                     PreparedStatement notStable =
> > > >                     connection.prepareStatement("select
> > > >                     getKakukk_(1)");)
> > > >                     {
> > > >                 System.out.println("STABLE: " + measure(new
> > > >                 Select(stable),
> > > >                 100000));
> > > >                 System.out.println("not STABLE: " + measure(new
> > > >                 Select(notStable), 100000));
> > > >                 System.out.println("---");
> > > > 
> > > >             }
> > > >         }
> > > >     }
> > > > }
> > > > 
> > > > 
> > > > --
> > > > 
> > > > The results are very similar, seemingly no difference at all.
> > > > Therefore, it seems we do not need those STABLE markers for performance
> > > > reasons.
> > > 
> > > Please refer to
> > > http://www.postgresql.org/docs/8.3/static/xfunc-volatility.html
> > > It says :
> > > 
> > > "For best optimization results, you should label your functions with the
> > > strictest volatility category that is valid for them."
> > 
> > I am sure the postgres guys did not mean "without even thinking about it"
> > :)
> > The way the enginge is using these functions, it will not improve
> > performance, which is not a problem. The problem in my opinion is that more
> > requirements increase the time needed for review procedure, which is
> > already
> > quite lengthy. This new requirement does not seem to have any benefit. If
> > we
> > want to improve the development process then we should not have
> > requirements
> > that do not come with benefits.
> 
> I totally disagree, I think the opposite , if this will not be a clear rule
> of thumb , it will be used incorrectly.
> Thinking on each SP if you will benefit or not  in terms of performance if
> you use those keywords will increase the review time when any reviewer will
> need to think if he needs that or not.
> I don't think that adding a word to the SP will affect development or review
> time , it should be like you are writing the word FUNCTION for a SP
> definition and will become a habit.
> I am against complicated rules like "add those keywords whenever you like" ,

No, it is even more simple than that: do not add those keywords, it would only make someone believe it will improve database performance, while it clearly won't :)

> if the documentations says a clear instruction to use those keywords in
> certain circumstances, that's what I would exactly do and  recommend to
> others.
> 
> Thanks
>  
> 
> > 
> > Best regards,
> > Laszlo
> > 
> > > 
> > > So , using STABLE , IMMUTABLE , STRICT is mandatory from now on.
> > > 
> > > Thanks
> > > Eli
> > > 
> > > 
> > > > 
> > > > Thank you,
> > > > Laszlo
> > > > 
> > > > ----- Original Message -----
> > > > > From: "Laszlo Hornyak" <lhornyak at redhat.com>
> > > > > To: "Eli Mesika" <emesika at redhat.com>
> > > > > Cc: "engine-devel" <engine-devel at ovirt.org>
> > > > > Sent: Wednesday, August 28, 2013 1:02:18 PM
> > > > > Subject: Re: [Engine-devel] Opimizing Postgres Stored Procedures
> > > > > 
> > > > > 
> > > > > ----- Original Message -----
> > > > > > From: "Eli Mesika" <emesika at redhat.com>
> > > > > > To: "Laszlo Hornyak" <lhornyak at redhat.com>
> > > > > > Cc: "engine-devel" <engine-devel at ovirt.org>
> > > > > > Sent: Wednesday, August 28, 2013 11:45:14 AM
> > > > > > Subject: Re: [Engine-devel] Opimizing Postgres Stored Procedures
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > ----- Original Message -----
> > > > > > > From: "Laszlo Hornyak" <lhornyak at redhat.com>
> > > > > > > To: "Eli Mesika" <emesika at redhat.com>
> > > > > > > Cc: "engine-devel" <engine-devel at ovirt.org>
> > > > > > > Sent: Tuesday, August 27, 2013 11:40:27 AM
> > > > > > > Subject: Re: [Engine-devel] Opimizing Postgres Stored Procedures
> > > > > > > 
> > > > > > > Hi Eli,
> > > > > > > 
> > > > > > > Most of the functions that we have in the DB are doing very
> > > > > > > simple
> > > > > > > jobs
> > > > > > > like
> > > > > > > run a query, insert/update and I see that now you have all QUERY
> > > > > > > functions
> > > > > > > as STABLE.
> > > > > > > My questions:
> > > > > > > Is this required for new functions from now on?
> > > > > > Yes and a email asking that was posted to engine_devel
> > > > > > 
> > > > > > > Is this done in order to improve performance?
> > > > > > Yes
> > > > > 
> > > > > Do you have any documents/benchmarks on how and why does this improve
> > > > > performance?
> > > > > STABLE functions should improve performance if they return the same
> > > > > result
> > > > > for the same parameters in the same statement.
> > > > > E.g. if you have a stable function like "select foo(x) from y" then
> > > > > the
> > > > > function can be invoked only once to evaluate each distinct value of
> > > > > y.x
> > > > > -
> > > > > this is kind of useful
> > > > > Functions running queries for the ovirt engine are typically invoked
> > > > > from
> > > > > client side, therefore they are only ivoked once from the parameters
> > > > > list
> > > > > and therefore will be only executed once for that single statement.
> > > > > 
> > > > > > 
> > > > > > > 
> > > > > > > Thank you,
> > > > > > > Laszlo
> > > > > > > 
> > > > > > > ----- Original Message -----
> > > > > > > > From: "Eli Mesika" <emesika at redhat.com>
> > > > > > > > To: "engine-devel" <engine-devel at ovirt.org>
> > > > > > > > Sent: Monday, August 26, 2013 11:22:20 AM
> > > > > > > > Subject: [Engine-devel] Opimizing Postgres Stored Procedures
> > > > > > > > 
> > > > > > > > Hi
> > > > > > > > 
> > > > > > > > I had merged the following patch
> > > > > > > > http://gerrit.ovirt.org/#/c/17962/
> > > > > > > > 
> > > > > > > > This patch introduce usage of the IMMUTABLE, STABLE and STRICT
> > > > > > > > keywords
> > > > > > > > in
> > > > > > > > order to boost performance of the Postgres SPs.
> > > > > > > > 
> > > > > > > > Please make sure that your current/and future DB scripts
> > > > > > > > applied
> > > > > > > > that.
> > > > > > > > 
> > > > > > > > 
> > > > > > > > Volatility
> > > > > > > > ----------
> > > > > > > > * A function should be marked as IMMUTABLE if it doesn't change
> > > > > > > > the
> > > > > > > > database,
> > > > > > > > and if it doesn't perform any lookups (even for database
> > > > > > > > configuration
> > > > > > > > values) during its operation.
> > > > > > > > * A function should be marked STABLE if it doesn't change the
> > > > > > > > database,
> > > > > > > > but
> > > > > > > > might perform lookups (IMMUTABLE is preferable if function
> > > > > > > > meets
> > > > > > > > the
> > > > > > > > requirements).
> > > > > > > > * A function doesn't need to be marked VOLATILE, because that's
> > > > > > > > the
> > > > > > > > default.
> > > > > > > > 
> > > > > > > > STRICTNESS
> > > > > > > > ----------
> > > > > > > > A function should be marked STRICT if it should return NULL
> > > > > > > > when
> > > > > > > > it
> > > > > > > > is
> > > > > > > > passed
> > > > > > > > a NULL argument, and then the function won't even be called if
> > > > > > > > it
> > > > > > > > is
> > > > > > > > indeed
> > > > > > > > passed a NULL argument.
> > > > > > > > 
> > > > > > > > 
> > > > > > > > I am available for any questions.
> > > > > > > > 
> > > > > > > > Thanks
> > > > > > > > 
> > > > > > > > Eli
> > > > > > > > _______________________________________________
> > > > > > > > Engine-devel mailing list
> > > > > > > > Engine-devel at ovirt.org
> > > > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > > > > > > 
> > > > > > > 
> > > > > > 
> > > > > _______________________________________________
> > > > > Engine-devel mailing list
> > > > > Engine-devel at ovirt.org
> > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > > > 
> > > > 
> > > 
> > 
> 


From emesika at redhat.com  Sun Sep  1 15:06:42 2013
From: emesika at redhat.com (Eli Mesika)
Date: Sun, 1 Sep 2013 11:06:42 -0400 (EDT)
Subject: [Engine-devel] Opimizing Postgres Stored Procedures
In-Reply-To: <1199015638.7978864.1378044819900.JavaMail.root@redhat.com>
References: <663980392.3966209.1377508940587.JavaMail.root@redhat.com>
	<1515360945.5323688.1377683114018.JavaMail.root@redhat.com>
	<1219881405.6480591.1377687738151.JavaMail.root@redhat.com>
	<21621864.7739664.1377879452271.JavaMail.root@redhat.com>
	<174208329.7527425.1378024543954.JavaMail.root@redhat.com>
	<750017409.7975042.1378036022716.JavaMail.root@redhat.com>
	<1299252547.7554802.1378042146981.JavaMail.root@redhat.com>
	<1199015638.7978864.1378044819900.JavaMail.root@redhat.com>
Message-ID: <292032640.7563242.1378048002461.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Laszlo Hornyak" <lhornyak at redhat.com>
> To: "Eli Mesika" <emesika at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>
> Sent: Sunday, September 1, 2013 5:13:39 PM
> Subject: Re: [Engine-devel] Opimizing Postgres Stored Procedures
> 
> 
> 
> ----- Original Message -----
> > From: "Eli Mesika" <emesika at redhat.com>
> > To: "Laszlo Hornyak" <lhornyak at redhat.com>
> > Cc: "engine-devel" <engine-devel at ovirt.org>
> > Sent: Sunday, September 1, 2013 3:29:06 PM
> > Subject: Re: [Engine-devel] Opimizing Postgres Stored Procedures
> > 
> > 
> > 
> > ----- Original Message -----
> > > From: "Laszlo Hornyak" <lhornyak at redhat.com>
> > > To: "Eli Mesika" <emesika at redhat.com>
> > > Cc: "engine-devel" <engine-devel at ovirt.org>
> > > Sent: Sunday, September 1, 2013 2:47:02 PM
> > > Subject: Re: [Engine-devel] Opimizing Postgres Stored Procedures
> > > 
> > > 
> > > 
> > > ----- Original Message -----
> > > > From: "Eli Mesika" <emesika at redhat.com>
> > > > To: "Laszlo Hornyak" <lhornyak at redhat.com>
> > > > Cc: "engine-devel" <engine-devel at ovirt.org>
> > > > Sent: Sunday, September 1, 2013 10:35:43 AM
> > > > Subject: Re: [Engine-devel] Opimizing Postgres Stored Procedures
> > > > 
> > > > 
> > > > 
> > > > ----- Original Message -----
> > > > > From: "Laszlo Hornyak" <lhornyak at redhat.com>
> > > > > To: "Eli Mesika" <emesika at redhat.com>
> > > > > Cc: "engine-devel" <engine-devel at ovirt.org>
> > > > > Sent: Friday, August 30, 2013 7:17:32 PM
> > > > > Subject: Re: [Engine-devel] Opimizing Postgres Stored Procedures
> > > > > 
> > > > > Hi Eli,
> > > > > 
> > > > > I wrote a quick benchmark to see if there is any difference when
> > > > > using
> > > > > STABLE
> > > > > modifier on functions running queries the way the engine does it
> > > > > (calling
> > > > > it
> > > > > from JDBC, one function in a single statement)
> > > > > 
> > > > > with a stable function:
> > > > > create function getKakukk(_id int) returns VARCHAR STABLE as 'select
> > > > > val
> > > > > from
> > > > > kakukk where id = $1' language sql;
> > > > > and one not marked as stable
> > > > > create function getKakukk_(_id int) returns VARCHAR as 'select val
> > > > > from
> > > > > kakukk where id = $1' language sql;
> > > > > the table is this simple:
> > > > > create table kakukk(id int primary key, val varchar);
> > > > > and the only content is:
> > > > > insert into kakukk (id, val) values (1, 'bla bla bla');
> > > > > 
> > > > > Now the benchmark code:
> > > > > 
> > > > > package com.foobar;
> > > > > 
> > > > > import java.sql.Connection;
> > > > > import java.sql.DriverManager;
> > > > > import java.sql.PreparedStatement;
> > > > > import java.sql.ResultSet;
> > > > > import java.sql.SQLException;
> > > > > 
> > > > > import org.junit.After;
> > > > > import org.junit.Before;
> > > > > import org.junit.Test;
> > > > > 
> > > > > public class SpeedTest {
> > > > > 
> > > > >     Connection connection;
> > > > > 
> > > > >     @Before
> > > > >     public void connect() throws SQLException {
> > > > >         connection =
> > > > >         DriverManager.getConnection("jdbc:postgresql://localhost/stabletest",
> > > > >         "engine", "engine");
> > > > >     }
> > > > > 
> > > > >     @After
> > > > >     public void disconnect() throws SQLException {
> > > > >         connection.close();
> > > > >     }
> > > > > 
> > > > >     private long measure(Runnable runnable, int times) {
> > > > >         final long start = System.currentTimeMillis();
> > > > >         for (int i = 0; i < times; i++) {
> > > > >             runnable.run();
> > > > >         }
> > > > >         final long end = System.currentTimeMillis();
> > > > >         return end - start;
> > > > >     }
> > > > > 
> > > > >     public static class Select implements Runnable {
> > > > > 
> > > > >         public Select(PreparedStatement preparedStatement) {
> > > > >             super();
> > > > >             this.preparedStatement = preparedStatement;
> > > > >         }
> > > > > 
> > > > >         final PreparedStatement preparedStatement;
> > > > > 
> > > > >         public void run() {
> > > > >             try (
> > > > >                     ResultSet resultSet =
> > > > >                     preparedStatement.executeQuery();)
> > > > >                     {
> > > > >                 while (resultSet.next()) {
> > > > >                     // nothing, just next
> > > > >                 }
> > > > >             } catch (SQLException e) {
> > > > >                 // TODO Auto-generated catch block
> > > > >                 e.printStackTrace();
> > > > >             }
> > > > >         }
> > > > >     }
> > > > > 
> > > > >     @Test
> > > > >     public void performTest() throws SQLException {
> > > > >         for (int i = 0; i < 10; i++) {
> > > > >             try (
> > > > >                     PreparedStatement stable =
> > > > >                     connection.prepareStatement("select
> > > > >                     getKakukk(1)");
> > > > >                     PreparedStatement notStable =
> > > > >                     connection.prepareStatement("select
> > > > >                     getKakukk_(1)");)
> > > > >                     {
> > > > >                 System.out.println("STABLE: " + measure(new
> > > > >                 Select(stable),
> > > > >                 100000));
> > > > >                 System.out.println("not STABLE: " + measure(new
> > > > >                 Select(notStable), 100000));
> > > > >                 System.out.println("---");
> > > > > 
> > > > >             }
> > > > >         }
> > > > >     }
> > > > > }
> > > > > 
> > > > > 
> > > > > --
> > > > > 
> > > > > The results are very similar, seemingly no difference at all.
> > > > > Therefore, it seems we do not need those STABLE markers for
> > > > > performance
> > > > > reasons.
> > > > 
> > > > Please refer to
> > > > http://www.postgresql.org/docs/8.3/static/xfunc-volatility.html
> > > > It says :
> > > > 
> > > > "For best optimization results, you should label your functions with
> > > > the
> > > > strictest volatility category that is valid for them."
> > > 
> > > I am sure the postgres guys did not mean "without even thinking about it"
> > > :)
> > > The way the enginge is using these functions, it will not improve
> > > performance, which is not a problem. The problem in my opinion is that
> > > more
> > > requirements increase the time needed for review procedure, which is
> > > already
> > > quite lengthy. This new requirement does not seem to have any benefit. If
> > > we
> > > want to improve the development process then we should not have
> > > requirements
> > > that do not come with benefits.
> > 
> > I totally disagree, I think the opposite , if this will not be a clear rule
> > of thumb , it will be used incorrectly.
> > Thinking on each SP if you will benefit or not  in terms of performance if
> > you use those keywords will increase the review time when any reviewer will
> > need to think if he needs that or not.
> > I don't think that adding a word to the SP will affect development or
> > review
> > time , it should be like you are writing the word FUNCTION for a SP
> > definition and will become a habit.
> > I am against complicated rules like "add those keywords whenever you like"
> > ,
> 
> No, it is even more simple than that: do not add those keywords, it would
> only make someone believe it will improve database performance, while it
> clearly won't :)

1) You just had tested a simple select statement which does not represent application complex queries and therefor you can not assume that your results are relevant to oVirt queries 
2) You did not test repetitive calls with the same arguments to the functions which will use PG cache to return the result when  STABLE and IMMUTABLE are used
3) You can google around on "postgres STABLE IMMUTABLE performance" and see some examples when STABLE and IMMUTABLE does affect performance
4) Please use those keywords in your DB patches 

Thanks


> 
> > if the documentations says a clear instruction to use those keywords in
> > certain circumstances, that's what I would exactly do and  recommend to
> > others.
> > 
> > Thanks
> >  
> > 
> > > 
> > > Best regards,
> > > Laszlo
> > > 
> > > > 
> > > > So , using STABLE , IMMUTABLE , STRICT is mandatory from now on.
> > > > 
> > > > Thanks
> > > > Eli
> > > > 
> > > > 
> > > > > 
> > > > > Thank you,
> > > > > Laszlo
> > > > > 
> > > > > ----- Original Message -----
> > > > > > From: "Laszlo Hornyak" <lhornyak at redhat.com>
> > > > > > To: "Eli Mesika" <emesika at redhat.com>
> > > > > > Cc: "engine-devel" <engine-devel at ovirt.org>
> > > > > > Sent: Wednesday, August 28, 2013 1:02:18 PM
> > > > > > Subject: Re: [Engine-devel] Opimizing Postgres Stored Procedures
> > > > > > 
> > > > > > 
> > > > > > ----- Original Message -----
> > > > > > > From: "Eli Mesika" <emesika at redhat.com>
> > > > > > > To: "Laszlo Hornyak" <lhornyak at redhat.com>
> > > > > > > Cc: "engine-devel" <engine-devel at ovirt.org>
> > > > > > > Sent: Wednesday, August 28, 2013 11:45:14 AM
> > > > > > > Subject: Re: [Engine-devel] Opimizing Postgres Stored Procedures
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > ----- Original Message -----
> > > > > > > > From: "Laszlo Hornyak" <lhornyak at redhat.com>
> > > > > > > > To: "Eli Mesika" <emesika at redhat.com>
> > > > > > > > Cc: "engine-devel" <engine-devel at ovirt.org>
> > > > > > > > Sent: Tuesday, August 27, 2013 11:40:27 AM
> > > > > > > > Subject: Re: [Engine-devel] Opimizing Postgres Stored
> > > > > > > > Procedures
> > > > > > > > 
> > > > > > > > Hi Eli,
> > > > > > > > 
> > > > > > > > Most of the functions that we have in the DB are doing very
> > > > > > > > simple
> > > > > > > > jobs
> > > > > > > > like
> > > > > > > > run a query, insert/update and I see that now you have all
> > > > > > > > QUERY
> > > > > > > > functions
> > > > > > > > as STABLE.
> > > > > > > > My questions:
> > > > > > > > Is this required for new functions from now on?
> > > > > > > Yes and a email asking that was posted to engine_devel
> > > > > > > 
> > > > > > > > Is this done in order to improve performance?
> > > > > > > Yes
> > > > > > 
> > > > > > Do you have any documents/benchmarks on how and why does this
> > > > > > improve
> > > > > > performance?
> > > > > > STABLE functions should improve performance if they return the same
> > > > > > result
> > > > > > for the same parameters in the same statement.
> > > > > > E.g. if you have a stable function like "select foo(x) from y" then
> > > > > > the
> > > > > > function can be invoked only once to evaluate each distinct value
> > > > > > of
> > > > > > y.x
> > > > > > -
> > > > > > this is kind of useful
> > > > > > Functions running queries for the ovirt engine are typically
> > > > > > invoked
> > > > > > from
> > > > > > client side, therefore they are only ivoked once from the
> > > > > > parameters
> > > > > > list
> > > > > > and therefore will be only executed once for that single statement.
> > > > > > 
> > > > > > > 
> > > > > > > > 
> > > > > > > > Thank you,
> > > > > > > > Laszlo
> > > > > > > > 
> > > > > > > > ----- Original Message -----
> > > > > > > > > From: "Eli Mesika" <emesika at redhat.com>
> > > > > > > > > To: "engine-devel" <engine-devel at ovirt.org>
> > > > > > > > > Sent: Monday, August 26, 2013 11:22:20 AM
> > > > > > > > > Subject: [Engine-devel] Opimizing Postgres Stored Procedures
> > > > > > > > > 
> > > > > > > > > Hi
> > > > > > > > > 
> > > > > > > > > I had merged the following patch
> > > > > > > > > http://gerrit.ovirt.org/#/c/17962/
> > > > > > > > > 
> > > > > > > > > This patch introduce usage of the IMMUTABLE, STABLE and
> > > > > > > > > STRICT
> > > > > > > > > keywords
> > > > > > > > > in
> > > > > > > > > order to boost performance of the Postgres SPs.
> > > > > > > > > 
> > > > > > > > > Please make sure that your current/and future DB scripts
> > > > > > > > > applied
> > > > > > > > > that.
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > Volatility
> > > > > > > > > ----------
> > > > > > > > > * A function should be marked as IMMUTABLE if it doesn't
> > > > > > > > > change
> > > > > > > > > the
> > > > > > > > > database,
> > > > > > > > > and if it doesn't perform any lookups (even for database
> > > > > > > > > configuration
> > > > > > > > > values) during its operation.
> > > > > > > > > * A function should be marked STABLE if it doesn't change the
> > > > > > > > > database,
> > > > > > > > > but
> > > > > > > > > might perform lookups (IMMUTABLE is preferable if function
> > > > > > > > > meets
> > > > > > > > > the
> > > > > > > > > requirements).
> > > > > > > > > * A function doesn't need to be marked VOLATILE, because
> > > > > > > > > that's
> > > > > > > > > the
> > > > > > > > > default.
> > > > > > > > > 
> > > > > > > > > STRICTNESS
> > > > > > > > > ----------
> > > > > > > > > A function should be marked STRICT if it should return NULL
> > > > > > > > > when
> > > > > > > > > it
> > > > > > > > > is
> > > > > > > > > passed
> > > > > > > > > a NULL argument, and then the function won't even be called
> > > > > > > > > if
> > > > > > > > > it
> > > > > > > > > is
> > > > > > > > > indeed
> > > > > > > > > passed a NULL argument.
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > I am available for any questions.
> > > > > > > > > 
> > > > > > > > > Thanks
> > > > > > > > > 
> > > > > > > > > Eli
> > > > > > > > > _______________________________________________
> > > > > > > > > Engine-devel mailing list
> > > > > > > > > Engine-devel at ovirt.org
> > > > > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > > > > > > > 
> > > > > > > > 
> > > > > > > 
> > > > > > _______________________________________________
> > > > > > Engine-devel mailing list
> > > > > > Engine-devel at ovirt.org
> > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > > > > 
> > > > > 
> > > > 
> > > 
> > 
> 


From lhornyak at redhat.com  Sun Sep  1 17:55:44 2013
From: lhornyak at redhat.com (Laszlo Hornyak)
Date: Sun, 1 Sep 2013 13:55:44 -0400 (EDT)
Subject: [Engine-devel] Opimizing Postgres Stored Procedures
In-Reply-To: <292032640.7563242.1378048002461.JavaMail.root@redhat.com>
References: <663980392.3966209.1377508940587.JavaMail.root@redhat.com>
	<1219881405.6480591.1377687738151.JavaMail.root@redhat.com>
	<21621864.7739664.1377879452271.JavaMail.root@redhat.com>
	<174208329.7527425.1378024543954.JavaMail.root@redhat.com>
	<750017409.7975042.1378036022716.JavaMail.root@redhat.com>
	<1299252547.7554802.1378042146981.JavaMail.root@redhat.com>
	<1199015638.7978864.1378044819900.JavaMail.root@redhat.com>
	<292032640.7563242.1378048002461.JavaMail.root@redhat.com>
Message-ID: <538325122.7984875.1378058144340.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Eli Mesika" <emesika at redhat.com>
> To: "Laszlo Hornyak" <lhornyak at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>
> Sent: Sunday, September 1, 2013 5:06:42 PM
> Subject: Re: [Engine-devel] Opimizing Postgres Stored Procedures
> 
> 
> 
> ----- Original Message -----
> > From: "Laszlo Hornyak" <lhornyak at redhat.com>
> > To: "Eli Mesika" <emesika at redhat.com>
> > Cc: "engine-devel" <engine-devel at ovirt.org>
> > Sent: Sunday, September 1, 2013 5:13:39 PM
> > Subject: Re: [Engine-devel] Opimizing Postgres Stored Procedures
> > 
> > 
> > 
> > ----- Original Message -----
> > > From: "Eli Mesika" <emesika at redhat.com>
> > > To: "Laszlo Hornyak" <lhornyak at redhat.com>
> > > Cc: "engine-devel" <engine-devel at ovirt.org>
> > > Sent: Sunday, September 1, 2013 3:29:06 PM
> > > Subject: Re: [Engine-devel] Opimizing Postgres Stored Procedures
> > > 
> > > 
> > > 
> > > ----- Original Message -----
> > > > From: "Laszlo Hornyak" <lhornyak at redhat.com>
> > > > To: "Eli Mesika" <emesika at redhat.com>
> > > > Cc: "engine-devel" <engine-devel at ovirt.org>
> > > > Sent: Sunday, September 1, 2013 2:47:02 PM
> > > > Subject: Re: [Engine-devel] Opimizing Postgres Stored Procedures
> > > > 
> > > > 
> > > > 
> > > > ----- Original Message -----
> > > > > From: "Eli Mesika" <emesika at redhat.com>
> > > > > To: "Laszlo Hornyak" <lhornyak at redhat.com>
> > > > > Cc: "engine-devel" <engine-devel at ovirt.org>
> > > > > Sent: Sunday, September 1, 2013 10:35:43 AM
> > > > > Subject: Re: [Engine-devel] Opimizing Postgres Stored Procedures
> > > > > 
> > > > > 
> > > > > 
> > > > > ----- Original Message -----
> > > > > > From: "Laszlo Hornyak" <lhornyak at redhat.com>
> > > > > > To: "Eli Mesika" <emesika at redhat.com>
> > > > > > Cc: "engine-devel" <engine-devel at ovirt.org>
> > > > > > Sent: Friday, August 30, 2013 7:17:32 PM
> > > > > > Subject: Re: [Engine-devel] Opimizing Postgres Stored Procedures
> > > > > > 
> > > > > > Hi Eli,
> > > > > > 
> > > > > > I wrote a quick benchmark to see if there is any difference when
> > > > > > using
> > > > > > STABLE
> > > > > > modifier on functions running queries the way the engine does it
> > > > > > (calling
> > > > > > it
> > > > > > from JDBC, one function in a single statement)
> > > > > > 
> > > > > > with a stable function:
> > > > > > create function getKakukk(_id int) returns VARCHAR STABLE as
> > > > > > 'select
> > > > > > val
> > > > > > from
> > > > > > kakukk where id = $1' language sql;
> > > > > > and one not marked as stable
> > > > > > create function getKakukk_(_id int) returns VARCHAR as 'select val
> > > > > > from
> > > > > > kakukk where id = $1' language sql;
> > > > > > the table is this simple:
> > > > > > create table kakukk(id int primary key, val varchar);
> > > > > > and the only content is:
> > > > > > insert into kakukk (id, val) values (1, 'bla bla bla');
> > > > > > 
> > > > > > Now the benchmark code:
> > > > > > 
> > > > > > package com.foobar;
> > > > > > 
> > > > > > import java.sql.Connection;
> > > > > > import java.sql.DriverManager;
> > > > > > import java.sql.PreparedStatement;
> > > > > > import java.sql.ResultSet;
> > > > > > import java.sql.SQLException;
> > > > > > 
> > > > > > import org.junit.After;
> > > > > > import org.junit.Before;
> > > > > > import org.junit.Test;
> > > > > > 
> > > > > > public class SpeedTest {
> > > > > > 
> > > > > >     Connection connection;
> > > > > > 
> > > > > >     @Before
> > > > > >     public void connect() throws SQLException {
> > > > > >         connection =
> > > > > >         DriverManager.getConnection("jdbc:postgresql://localhost/stabletest",
> > > > > >         "engine", "engine");
> > > > > >     }
> > > > > > 
> > > > > >     @After
> > > > > >     public void disconnect() throws SQLException {
> > > > > >         connection.close();
> > > > > >     }
> > > > > > 
> > > > > >     private long measure(Runnable runnable, int times) {
> > > > > >         final long start = System.currentTimeMillis();
> > > > > >         for (int i = 0; i < times; i++) {
> > > > > >             runnable.run();
> > > > > >         }
> > > > > >         final long end = System.currentTimeMillis();
> > > > > >         return end - start;
> > > > > >     }
> > > > > > 
> > > > > >     public static class Select implements Runnable {
> > > > > > 
> > > > > >         public Select(PreparedStatement preparedStatement) {
> > > > > >             super();
> > > > > >             this.preparedStatement = preparedStatement;
> > > > > >         }
> > > > > > 
> > > > > >         final PreparedStatement preparedStatement;
> > > > > > 
> > > > > >         public void run() {
> > > > > >             try (
> > > > > >                     ResultSet resultSet =
> > > > > >                     preparedStatement.executeQuery();)
> > > > > >                     {
> > > > > >                 while (resultSet.next()) {
> > > > > >                     // nothing, just next
> > > > > >                 }
> > > > > >             } catch (SQLException e) {
> > > > > >                 // TODO Auto-generated catch block
> > > > > >                 e.printStackTrace();
> > > > > >             }
> > > > > >         }
> > > > > >     }
> > > > > > 
> > > > > >     @Test
> > > > > >     public void performTest() throws SQLException {
> > > > > >         for (int i = 0; i < 10; i++) {
> > > > > >             try (
> > > > > >                     PreparedStatement stable =
> > > > > >                     connection.prepareStatement("select
> > > > > >                     getKakukk(1)");
> > > > > >                     PreparedStatement notStable =
> > > > > >                     connection.prepareStatement("select
> > > > > >                     getKakukk_(1)");)
> > > > > >                     {
> > > > > >                 System.out.println("STABLE: " + measure(new
> > > > > >                 Select(stable),
> > > > > >                 100000));
> > > > > >                 System.out.println("not STABLE: " + measure(new
> > > > > >                 Select(notStable), 100000));
> > > > > >                 System.out.println("---");
> > > > > > 
> > > > > >             }
> > > > > >         }
> > > > > >     }
> > > > > > }
> > > > > > 
> > > > > > 
> > > > > > --
> > > > > > 
> > > > > > The results are very similar, seemingly no difference at all.
> > > > > > Therefore, it seems we do not need those STABLE markers for
> > > > > > performance
> > > > > > reasons.
> > > > > 
> > > > > Please refer to
> > > > > http://www.postgresql.org/docs/8.3/static/xfunc-volatility.html
> > > > > It says :
> > > > > 
> > > > > "For best optimization results, you should label your functions with
> > > > > the
> > > > > strictest volatility category that is valid for them."
> > > > 
> > > > I am sure the postgres guys did not mean "without even thinking about
> > > > it"
> > > > :)
> > > > The way the enginge is using these functions, it will not improve
> > > > performance, which is not a problem. The problem in my opinion is that
> > > > more
> > > > requirements increase the time needed for review procedure, which is
> > > > already
> > > > quite lengthy. This new requirement does not seem to have any benefit.
> > > > If
> > > > we
> > > > want to improve the development process then we should not have
> > > > requirements
> > > > that do not come with benefits.
> > > 
> > > I totally disagree, I think the opposite , if this will not be a clear
> > > rule
> > > of thumb , it will be used incorrectly.
> > > Thinking on each SP if you will benefit or not  in terms of performance
> > > if
> > > you use those keywords will increase the review time when any reviewer
> > > will
> > > need to think if he needs that or not.
> > > I don't think that adding a word to the SP will affect development or
> > > review
> > > time , it should be like you are writing the word FUNCTION for a SP
> > > definition and will become a habit.
> > > I am against complicated rules like "add those keywords whenever you
> > > like"
> > > ,
> > 
> > No, it is even more simple than that: do not add those keywords, it would
> > only make someone believe it will improve database performance, while it
> > clearly won't :)
> 
> 1) You just had tested a simple select statement which does not represent
> application complex queries and therefor you can not assume that your
> results are relevant to oVirt queries

I am talking about the functions that are running a single query and they are typically invoked from JDBC and only one of this functions in a single statement.
The above test simulates this scenario.

> 2) You did not test repetitive calls with the same arguments to the functions
> which will use PG cache to return the result when  STABLE and IMMUTABLE are
> used

Sure, this test is doing repetitive calls just like engine, only a little more.
The point is that STABLE is invoked with the same args only once in the same statement. Not transaction, the pg documentation also puts it clear:
"all rows within a single statement"

Therefore when these functions are invoked, from two subsequent statements, there is no performance gain whatsoever. But of course, why would you call "GetDisksVmGuid" twice in the same statement?

I do not think this is a cache solution in PostgreSQL, it allows the PostgreSQL query planner to optimize the function usage in your queries in case the query need to be evaluated several times. But it's scope is only one statement. Therefore it will not be any helpful in a typical "GetSomethingBySomething" function.

No big deal if this does not improve performance (and it seems it doesn't), the problem is that we MUST use it regardless.
We could comment there: -- this is here to make the reviewer happy, it does not actually improve performance :)

> 3) You can google around on "postgres STABLE IMMUTABLE performance" and see
> some examples when STABLE and IMMUTABLE does affect performance

I did already, I am not quite new to postgresql functions, however, I am always happy to learn something new. This is why I started with asking you if you can show any banchmarks/documentation on why does it improve performance. It did not seem to be logical, and the actual results show no improvement.

> 4) Please use those keywords in your DB patches

In case I will have to write one more DB patch, I will, but I hope by then we resolve this misunderstanding.

> 
> Thanks
> 
> 
> > 
> > > if the documentations says a clear instruction to use those keywords in
> > > certain circumstances, that's what I would exactly do and  recommend to
> > > others.
> > > 
> > > Thanks
> > >  
> > > 
> > > > 
> > > > Best regards,
> > > > Laszlo
> > > > 
> > > > > 
> > > > > So , using STABLE , IMMUTABLE , STRICT is mandatory from now on.
> > > > > 
> > > > > Thanks
> > > > > Eli
> > > > > 
> > > > > 
> > > > > > 
> > > > > > Thank you,
> > > > > > Laszlo
> > > > > > 
> > > > > > ----- Original Message -----
> > > > > > > From: "Laszlo Hornyak" <lhornyak at redhat.com>
> > > > > > > To: "Eli Mesika" <emesika at redhat.com>
> > > > > > > Cc: "engine-devel" <engine-devel at ovirt.org>
> > > > > > > Sent: Wednesday, August 28, 2013 1:02:18 PM
> > > > > > > Subject: Re: [Engine-devel] Opimizing Postgres Stored Procedures
> > > > > > > 
> > > > > > > 
> > > > > > > ----- Original Message -----
> > > > > > > > From: "Eli Mesika" <emesika at redhat.com>
> > > > > > > > To: "Laszlo Hornyak" <lhornyak at redhat.com>
> > > > > > > > Cc: "engine-devel" <engine-devel at ovirt.org>
> > > > > > > > Sent: Wednesday, August 28, 2013 11:45:14 AM
> > > > > > > > Subject: Re: [Engine-devel] Opimizing Postgres Stored
> > > > > > > > Procedures
> > > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > ----- Original Message -----
> > > > > > > > > From: "Laszlo Hornyak" <lhornyak at redhat.com>
> > > > > > > > > To: "Eli Mesika" <emesika at redhat.com>
> > > > > > > > > Cc: "engine-devel" <engine-devel at ovirt.org>
> > > > > > > > > Sent: Tuesday, August 27, 2013 11:40:27 AM
> > > > > > > > > Subject: Re: [Engine-devel] Opimizing Postgres Stored
> > > > > > > > > Procedures
> > > > > > > > > 
> > > > > > > > > Hi Eli,
> > > > > > > > > 
> > > > > > > > > Most of the functions that we have in the DB are doing very
> > > > > > > > > simple
> > > > > > > > > jobs
> > > > > > > > > like
> > > > > > > > > run a query, insert/update and I see that now you have all
> > > > > > > > > QUERY
> > > > > > > > > functions
> > > > > > > > > as STABLE.
> > > > > > > > > My questions:
> > > > > > > > > Is this required for new functions from now on?
> > > > > > > > Yes and a email asking that was posted to engine_devel
> > > > > > > > 
> > > > > > > > > Is this done in order to improve performance?
> > > > > > > > Yes
> > > > > > > 
> > > > > > > Do you have any documents/benchmarks on how and why does this
> > > > > > > improve
> > > > > > > performance?
> > > > > > > STABLE functions should improve performance if they return the
> > > > > > > same
> > > > > > > result
> > > > > > > for the same parameters in the same statement.
> > > > > > > E.g. if you have a stable function like "select foo(x) from y"
> > > > > > > then
> > > > > > > the
> > > > > > > function can be invoked only once to evaluate each distinct value
> > > > > > > of
> > > > > > > y.x
> > > > > > > -
> > > > > > > this is kind of useful
> > > > > > > Functions running queries for the ovirt engine are typically
> > > > > > > invoked
> > > > > > > from
> > > > > > > client side, therefore they are only ivoked once from the
> > > > > > > parameters
> > > > > > > list
> > > > > > > and therefore will be only executed once for that single
> > > > > > > statement.
> > > > > > > 
> > > > > > > > 
> > > > > > > > > 
> > > > > > > > > Thank you,
> > > > > > > > > Laszlo
> > > > > > > > > 
> > > > > > > > > ----- Original Message -----
> > > > > > > > > > From: "Eli Mesika" <emesika at redhat.com>
> > > > > > > > > > To: "engine-devel" <engine-devel at ovirt.org>
> > > > > > > > > > Sent: Monday, August 26, 2013 11:22:20 AM
> > > > > > > > > > Subject: [Engine-devel] Opimizing Postgres Stored
> > > > > > > > > > Procedures
> > > > > > > > > > 
> > > > > > > > > > Hi
> > > > > > > > > > 
> > > > > > > > > > I had merged the following patch
> > > > > > > > > > http://gerrit.ovirt.org/#/c/17962/
> > > > > > > > > > 
> > > > > > > > > > This patch introduce usage of the IMMUTABLE, STABLE and
> > > > > > > > > > STRICT
> > > > > > > > > > keywords
> > > > > > > > > > in
> > > > > > > > > > order to boost performance of the Postgres SPs.
> > > > > > > > > > 
> > > > > > > > > > Please make sure that your current/and future DB scripts
> > > > > > > > > > applied
> > > > > > > > > > that.
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > Volatility
> > > > > > > > > > ----------
> > > > > > > > > > * A function should be marked as IMMUTABLE if it doesn't
> > > > > > > > > > change
> > > > > > > > > > the
> > > > > > > > > > database,
> > > > > > > > > > and if it doesn't perform any lookups (even for database
> > > > > > > > > > configuration
> > > > > > > > > > values) during its operation.
> > > > > > > > > > * A function should be marked STABLE if it doesn't change
> > > > > > > > > > the
> > > > > > > > > > database,
> > > > > > > > > > but
> > > > > > > > > > might perform lookups (IMMUTABLE is preferable if function
> > > > > > > > > > meets
> > > > > > > > > > the
> > > > > > > > > > requirements).
> > > > > > > > > > * A function doesn't need to be marked VOLATILE, because
> > > > > > > > > > that's
> > > > > > > > > > the
> > > > > > > > > > default.
> > > > > > > > > > 
> > > > > > > > > > STRICTNESS
> > > > > > > > > > ----------
> > > > > > > > > > A function should be marked STRICT if it should return NULL
> > > > > > > > > > when
> > > > > > > > > > it
> > > > > > > > > > is
> > > > > > > > > > passed
> > > > > > > > > > a NULL argument, and then the function won't even be called
> > > > > > > > > > if
> > > > > > > > > > it
> > > > > > > > > > is
> > > > > > > > > > indeed
> > > > > > > > > > passed a NULL argument.
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > I am available for any questions.
> > > > > > > > > > 
> > > > > > > > > > Thanks
> > > > > > > > > > 
> > > > > > > > > > Eli
> > > > > > > > > > _______________________________________________
> > > > > > > > > > Engine-devel mailing list
> > > > > > > > > > Engine-devel at ovirt.org
> > > > > > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > > > > > > > > 
> > > > > > > > > 
> > > > > > > > 
> > > > > > > _______________________________________________
> > > > > > > Engine-devel mailing list
> > > > > > > Engine-devel at ovirt.org
> > > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > > > > > 
> > > > > > 
> > > > > 
> > > > 
> > > 
> > 
> 


From sabose at redhat.com  Mon Sep  2 08:54:46 2013
From: sabose at redhat.com (Sahina Bose)
Date: Mon, 02 Sep 2013 14:24:46 +0530
Subject: [Engine-devel] UX inputs on gluster volume async tasks
In-Reply-To: <1378943009.5182853.1378042867887.JavaMail.root@redhat.com>
References: <521DDF73.9090505@redhat.com>
	<272457150.6004512.1377868964117.JavaMail.root@redhat.com>
	<1378943009.5182853.1378042867887.JavaMail.root@redhat.com>
Message-ID: <52245256.4040401@redhat.com>

Hi Malini, Eldan

Thanks so much for the detailed feedback. Comments inline

On 09/01/2013 07:11 PM, Eldan Hildesheim wrote:
> Hi all,
> I have few more questions.
> 1. How often do we get the data of the activity changes: I wonder if we can change the activity icon by a progress one.
The refresh of data can be configured, defaulting it to 30 seconds. We 
have no way however of knowing the time left / number of files yet to be 
rebalanced on a volume. So a progress bar may not be possible.
> 2. Normally in oVirt / Rhev we show more data as a "sub tab". Can we assume that Rebalance status is like "more data" and then put all the data that is now in the modal inside a new sub tab name (activity)?
We were averse to creating a new sub tab -
1. To avoid proliferation of sub tabs
2. since this sub-tab will only be relevant when rebalance operation is 
going on.
> 3. The icon of "Migration data from Brick in progress": Is this apart of the Rebalance process? Is this a derived aspect of the rebalance?
This is for remove brick...Not rebalance
> 4. Do you have a phone num we can call Monday?
Will contact you off list.
> Thanks,
> Eldan
>   
>
> ----- Original Message -----
> From: "Malini Rao" <mrao at redhat.com>
> To: "Sahina Bose" <sabose at redhat.com>
> Cc: "Eldan Hildesheim" <ehildesh at redhat.com>, "engine-devel" <engine-devel at ovirt.org>, "Dusmant Pati" <dpati at redhat.com>
> Sent: Friday, August 30, 2013 4:22:44 PM
> Subject: Re: UX inputs on gluster volume async tasks
>
> Sahina,
>
> Attached are my detailed comments and questions about this feature from a UX perspective. If it is easier, we can get on a call to discuss the questions and other points. Let me know what you prefer.
>
> Thanks
> Malini
>
> ----- Original Message -----
> From: "Sahina Bose" <sabose at redhat.com>
> To: "Malini Rao" <mrao at redhat.com>, "Eldan Hildesheim" <ehildesh at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>, "Dusmant Pati" <dpati at redhat.com>
> Sent: Wednesday, August 28, 2013 7:30:59 AM
> Subject: UX inputs on gluster volume async tasks
>
> Hi Malini, Eldan,
>
> Could you provide feedback from UX perspective on this feature?
>
> The feature description and User flows are at
> http://www.ovirt.org/Features/Gluster_Volume_Asynchronous_Tasks_Management
>
> thanks
> sahina
>



From leonardo.bianconi at eldorado.org.br  Mon Sep  2 12:35:27 2013
From: leonardo.bianconi at eldorado.org.br (Leonardo Bianconi)
Date: Mon, 2 Sep 2013 12:35:27 +0000
Subject: [Engine-devel] Cluster default with empty processor name with
 PPC64 support
In-Reply-To: <5222F5B7.5060603@redhat.com>
References: <50EB20226B72D6419356FC320AB62B8719173370@SERV070.corp.eldorado.org.br>
	<5222F5B7.5060603@redhat.com>
Message-ID: <50EB20226B72D6419356FC320AB62B87191733F5@SERV070.corp.eldorado.org.br>



> > From: Roy Golan [mailto:rgolan at redhat.com] 
> > Sent: domingo, 1 de setembro de 2013 05:07
> > To: Leonardo Bianconi
> > Cc: engine-devel at ovirt.org
> > Subject: Re: [Engine-devel] Cluster default with empty processor name with PPC64 support
> >
> > On 08/30/2013 10:51 PM, Leonardo Bianconi wrote:
> > Hi everyone!
> >  
> > During the development of PPC64 support in the engine, we faced some UX issues regarding the default Cluster (that Cluster with empty processor name).
> >  
> > Currently, oVirt engine allows the default Cluster to contain empty processor name, and the administrator can add VMs and/or Templates to it. The processor name can be assigned later, editing the cluster or assigning a valid host to it.
> >  
> > During the implementation of PPC64 support on the engine, the field "architecture" was added to Clusters, VMs and Templates entities.
> >  
> > So we have the following questions regarding how the UI should behave:
> >  
> > - Shall we keep allowing the administrator to assign VMs and Templates to the Cluster with no processor name or assigned architecture ?
> >              -> If we have an "yes" for the question above:
> >              -- We will have to assign the architecture to the Cluster based on the OS of the first assigned VM, and  the processor name could be defined the same way as currently ... editing the Cluster or assigning a compatible Host to it.
> >                              -- The VM creation popup will have to be able to indicate the architecture of each OS ... some OSes have the same name, and it may get ambiguous since the Cluster architecture is still undefined at that point (before the first VM get already created).
> >  
> > Thanks!
> > Regards.
> > Leonardo Bianconi
> >
> To add VMs you anyway need a running host in the cluster which means the cpu name and the architecture would be the host's. 
> So we can keep the cluster attributes - "cpu name" and "arch" consistent and allow them to be empty on creation. 
>
>
Hi Roy!

There is a way to add VMs in a cluster with no hosts running. Steps to reproduce:
- Initialize the oVirt engine with a new data base
- Create a new Cluster (I will call it of newCluster) in the Data Center Default
- Add a host in the newCluster
- Add a Storage
- Create a VM in the Cluster Default
Result: The system allows a VM in a cluster with no Hosts running in it.

Is it a bug or a system functionality? If it's a functionality, the issue above can happen.

Thanks!!
Regards.
Leonardo Bianconi
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel



From vszocs at redhat.com  Mon Sep  2 13:18:22 2013
From: vszocs at redhat.com (Vojtech Szocs)
Date: Mon, 2 Sep 2013 09:18:22 -0400 (EDT)
Subject: [Engine-devel] ok to sort login domains on backend?
In-Reply-To: <1575159724.3889137.1377882853822.JavaMail.root@redhat.com>
References: <929908188.3762590.1377865608373.JavaMail.root@redhat.com>
	<574759461.3785515.1377869566020.JavaMail.root@redhat.com>
	<1308542300.10459171.1377871957628.JavaMail.root@redhat.com>
	<1215612194.3877118.1377880524332.JavaMail.root@redhat.com>
	<1309022259.10791445.1377881773862.JavaMail.root@redhat.com>
	<1575159724.3889137.1377882853822.JavaMail.root@redhat.com>
Message-ID: <1714194246.7409273.1378127902640.JavaMail.root@redhat.com>

Hi Alon,

GetDomainListQuery already sorts domains by name before returning domain list to client (GetDomainListQuery:23), so what's the big deal with adding internal admin domain (ConfigValues.AdminDomain) as the last entry anyway?

If I understand correctly, GetDomainListQuery already sorts domains not due to presentation purposes, but to make resulting domain list more consistent for clients to process (and humans to inspect).

Vojtech


----- Original Message -----
> From: "Alon Bar-Lev" <alonbl at redhat.com>
> To: "Einav Cohen" <ecohen at redhat.com>
> Cc: engine-devel at ovirt.org
> Sent: Friday, August 30, 2013 7:14:13 PM
> Subject: Re: [Engine-devel] ok to sort login domains on backend?
> 
> 
> 
> ----- Original Message -----
> > From: "Einav Cohen" <ecohen at redhat.com>
> > To: "Alon Bar-Lev" <alonbl at redhat.com>
> > Cc: engine-devel at ovirt.org
> > Sent: Friday, August 30, 2013 7:56:13 PM
> > Subject: Re: [Engine-devel] ok to sort login domains on backend?
> > 
> > > ----- Original Message -----
> > > From: "Alon Bar-Lev" <alonbl at redhat.com>
> > > Sent: Friday, August 30, 2013 12:35:24 PM
> > > 
> > > 
> > > 
> > > ----- Original Message -----
> > > > From: "Einav Cohen" <ecohen at redhat.com>
> > > > To: "Alon Bar-Lev" <alonbl at redhat.com>
> > > > Cc: "Greg Sheremeta" <gshereme at redhat.com>, engine-devel at ovirt.org
> > > > Sent: Friday, August 30, 2013 5:12:37 PM
> > > > Subject: Re: [Engine-devel] ok to sort login domains on backend?
> > > > 
> > > > > ----- Original Message -----
> > > > > From: "Alon Bar-Lev" <alonbl at redhat.com>
> > > > > Sent: Friday, August 30, 2013 9:32:46 AM
> > > > > 
> > > > > 
> > > > > 
> > > > > ----- Original Message -----
> > > > > > From: "Greg Sheremeta" <gshereme at redhat.com>
> > > > > > To: engine-devel at ovirt.org
> > > > > > Sent: Friday, August 30, 2013 3:26:48 PM
> > > > > > Subject: [Engine-devel] ok to sort login domains on backend?
> > > > > > 
> > > > > > Hi,
> > > > > > 
> > > > > > I'm working on https://bugzilla.redhat.com/785555 -- "domain
> > > > > > selection
> > > > > > list
> > > > > > in login screen should be sorted alphabetically"
> > > > > > 
> > > > > > I was going to put the sort logic in the web apps, but it makes
> > > > > > sense
> > > > > > to
> > > > > > just
> > > > > > put it in the backend, specifically in GetDomainListQuery. (There
> > > > > > is
> > > > > > already
> > > > > > a sort there, but it needs to be tweaked to put "internal" always
> > > > > > last.)
> > > > > > This would affect non-webapp clients (REST API), so I want to make
> > > > > > sure
> > > > > > there are no objections. Unit tests pass and it seems to work fine
> > > > > > (screen
> > > > > > attached).
> > > > > > 
> > > > > > Any objections?
> > > > > 
> > > > > I think that sorting of visualization is presentation layer role.
> > > > 
> > > > true in general, but I think that there is no harm in returning items
> > > > from the backend in some default order, especially if this is a list
> > > > of simple items that have only one possible order that makes sense.
> > > 
> > > Even if that so, there is no reason to relay on it.
> > 
> > if this method will return a sorted list *by definition*, there would be
> > no reason to NOT relay on it.
> > for this particular case, I think that it would be a bit of waste if the
> > exact same sorting logic will be duplicated across the different clients'
> > code (including 3rd-party clients). If we can make it a little bit easier
> > on the clients, I don't see why not to do it.
> > 
> > > If sort is required at presentation, presentation layer should apply
> > > sort.
> > 
> > define "presentation"; looking at the xml response of a rest-api GET
> > request
> > in a browser is also "presentation", but I can't really apply sort there;
> > yes,
> > I can change the rest-api code to sort the results, but why not simply make
> > it
> > a bit easier for *all* clients, and return the results from the backend
> > already
> > sorted in the way which is probably the most comfortable for everyone?
> > 
> > [again - you are generally correct, but in this particular case, of simple
> > business entities which have pretty much only one way of sorting that makes
> > sense, I don't see why not make an exception and apply the sort on the
> > backend]
> 
> Well, we can agree to disagree.
> 
> RestAPI is not presentation, the fact that browser has presentation layer to
> interact with RestAPI does not mean that the server side is responsible on
> ordering etc. The RestAPI presentation layer may allow sorting.
> 
> I do not think that API should have any sense of presentation ordering it
> only makes it more complex without a reason.
> 
> Let's assume the API sort is based on plain text, and you have a bug to sort
> using case insensitive, so API definition should be fixed? so you pass a
> parameter to request specific casing?
> 
> Let's assume that each domain has value and description, you agree that sort
> should be based on description, right? Now, let's say that description can
> be localized, which sort can the server apply?
> 
> These are the reason why presentation layer was split out, ever since IBM
> Mainframe 3270 the layer is running on the client side.
> 
> Regards,
> Alon Bar-Lev
> 
> > 
> > > 
> > > > 
> > > > > 
> > > > > > 
> > > > > > Thanks,
> > > > > > Greg
> > > > > > 
> > > > > > 
> > > > > > Greg Sheremeta
> > > > > > Red Hat, Inc.
> > > > > > Sr. Software Engineer, RHEV
> > > > > > Cell: 919-807-1086
> > > > > > gshereme at redhat.com
> > > > > > _______________________________________________
> > > > > > Engine-devel mailing list
> > > > > > Engine-devel at ovirt.org
> > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > > > > 
> > > > > _______________________________________________
> > > > > Engine-devel mailing list
> > > > > Engine-devel at ovirt.org
> > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > > > 
> > > > > 
> > > > > 
> > > > 
> > > _______________________________________________
> > > Engine-devel mailing list
> > > Engine-devel at ovirt.org
> > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > 
> > > 
> > > 
> > 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From iheim at redhat.com  Mon Sep  2 13:28:38 2013
From: iheim at redhat.com (Itamar Heim)
Date: Mon, 02 Sep 2013 16:28:38 +0300
Subject: [Engine-devel] Cluster default with empty processor name with
 PPC64 support
In-Reply-To: <50EB20226B72D6419356FC320AB62B87191733F5@SERV070.corp.eldorado.org.br>
References: <50EB20226B72D6419356FC320AB62B8719173370@SERV070.corp.eldorado.org.br>
	<5222F5B7.5060603@redhat.com>
	<50EB20226B72D6419356FC320AB62B87191733F5@SERV070.corp.eldorado.org.br>
Message-ID: <52249286.5010009@redhat.com>

On 09/02/2013 03:35 PM, Leonardo Bianconi wrote:
>
>
>>> From: Roy Golan [mailto:rgolan at redhat.com]
>>> Sent: domingo, 1 de setembro de 2013 05:07
>>> To: Leonardo Bianconi
>>> Cc: engine-devel at ovirt.org
>>> Subject: Re: [Engine-devel] Cluster default with empty processor name with PPC64 support
>>>
>>> On 08/30/2013 10:51 PM, Leonardo Bianconi wrote:
>>> Hi everyone!
>>>
>>> During the development of PPC64 support in the engine, we faced some UX issues regarding the default Cluster (that Cluster with empty processor name).
>>>
>>> Currently, oVirt engine allows the default Cluster to contain empty processor name, and the administrator can add VMs and/or Templates to it. The processor name can be assigned later, editing the cluster or assigning a valid host to it.
>>>
>>> During the implementation of PPC64 support on the engine, the field "architecture" was added to Clusters, VMs and Templates entities.
>>>
>>> So we have the following questions regarding how the UI should behave:
>>>
>>> - Shall we keep allowing the administrator to assign VMs and Templates to the Cluster with no processor name or assigned architecture ?
>>>               -> If we have an "yes" for the question above:
>>>               -- We will have to assign the architecture to the Cluster based on the OS of the first assigned VM, and  the processor name could be defined the same way as currently ... editing the Cluster or assigning a compatible Host to it.
>>>                               -- The VM creation popup will have to be able to indicate the architecture of each OS ... some OSes have the same name, and it may get ambiguous since the Cluster architecture is still undefined at that point (before the first VM get already created).
>>>
>>> Thanks!
>>> Regards.
>>> Leonardo Bianconi
>>>
>> To add VMs you anyway need a running host in the cluster which means the cpu name and the architecture would be the host's.
>> So we can keep the cluster attributes - "cpu name" and "arch" consistent and allow them to be empty on creation.
>>
>>
> Hi Roy!
>
> There is a way to add VMs in a cluster with no hosts running. Steps to reproduce:
> - Initialize the oVirt engine with a new data base
> - Create a new Cluster (I will call it of newCluster) in the Data Center Default
> - Add a host in the newCluster
> - Add a Storage
> - Create a VM in the Cluster Default
> Result: The system allows a VM in a cluster with no Hosts running in it.
>
> Is it a bug or a system functionality? If it's a functionality, the issue above can happen.

while above can happen, is it really an interesting use case to solve?
can user edit the arch field of a vm? if so, i'd just block running it 
on incorrect cluster (just like we block on moving it between 
incompatible clusters) until user fix the issue



From alonbl at redhat.com  Mon Sep  2 13:29:59 2013
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Mon, 2 Sep 2013 09:29:59 -0400 (EDT)
Subject: [Engine-devel] ok to sort login domains on backend?
In-Reply-To: <1714194246.7409273.1378127902640.JavaMail.root@redhat.com>
References: <929908188.3762590.1377865608373.JavaMail.root@redhat.com>
	<574759461.3785515.1377869566020.JavaMail.root@redhat.com>
	<1308542300.10459171.1377871957628.JavaMail.root@redhat.com>
	<1215612194.3877118.1377880524332.JavaMail.root@redhat.com>
	<1309022259.10791445.1377881773862.JavaMail.root@redhat.com>
	<1575159724.3889137.1377882853822.JavaMail.root@redhat.com>
	<1714194246.7409273.1378127902640.JavaMail.root@redhat.com>
Message-ID: <803764020.4192657.1378128599239.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Vojtech Szocs" <vszocs at redhat.com>
> To: "Alon Bar-Lev" <alonbl at redhat.com>
> Cc: "Einav Cohen" <ecohen at redhat.com>, engine-devel at ovirt.org
> Sent: Monday, September 2, 2013 4:18:22 PM
> Subject: Re: [Engine-devel] ok to sort login domains on backend?
> 
> Hi Alon,
> 
> GetDomainListQuery already sorts domains by name before returning domain list
> to client (GetDomainListQuery:23), so what's the big deal with adding
> internal admin domain (ConfigValues.AdminDomain) as the last entry anyway?

No big deal... :)
We were asked for opinions...
So you have mine...

I have strict rules for cases such of this, and I do not really interested what is currently implemented as it may be completely wrong (in my view).

Presentation layer should perform presentation adjustments.
In fat client application (ours) it is very easy to know where presentation layer is.
In server pages application it is also very easy for most people to understand that the jsp is presentation layer...

You can safely ignore.

Regards,
Alon 

> 
> If I understand correctly, GetDomainListQuery already sorts domains not due
> to presentation purposes, but to make resulting domain list more consistent
> for clients to process (and humans to inspect).
> 
> Vojtech
> 
> 
> ----- Original Message -----
> > From: "Alon Bar-Lev" <alonbl at redhat.com>
> > To: "Einav Cohen" <ecohen at redhat.com>
> > Cc: engine-devel at ovirt.org
> > Sent: Friday, August 30, 2013 7:14:13 PM
> > Subject: Re: [Engine-devel] ok to sort login domains on backend?
> > 
> > 
> > 
> > ----- Original Message -----
> > > From: "Einav Cohen" <ecohen at redhat.com>
> > > To: "Alon Bar-Lev" <alonbl at redhat.com>
> > > Cc: engine-devel at ovirt.org
> > > Sent: Friday, August 30, 2013 7:56:13 PM
> > > Subject: Re: [Engine-devel] ok to sort login domains on backend?
> > > 
> > > > ----- Original Message -----
> > > > From: "Alon Bar-Lev" <alonbl at redhat.com>
> > > > Sent: Friday, August 30, 2013 12:35:24 PM
> > > > 
> > > > 
> > > > 
> > > > ----- Original Message -----
> > > > > From: "Einav Cohen" <ecohen at redhat.com>
> > > > > To: "Alon Bar-Lev" <alonbl at redhat.com>
> > > > > Cc: "Greg Sheremeta" <gshereme at redhat.com>, engine-devel at ovirt.org
> > > > > Sent: Friday, August 30, 2013 5:12:37 PM
> > > > > Subject: Re: [Engine-devel] ok to sort login domains on backend?
> > > > > 
> > > > > > ----- Original Message -----
> > > > > > From: "Alon Bar-Lev" <alonbl at redhat.com>
> > > > > > Sent: Friday, August 30, 2013 9:32:46 AM
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > ----- Original Message -----
> > > > > > > From: "Greg Sheremeta" <gshereme at redhat.com>
> > > > > > > To: engine-devel at ovirt.org
> > > > > > > Sent: Friday, August 30, 2013 3:26:48 PM
> > > > > > > Subject: [Engine-devel] ok to sort login domains on backend?
> > > > > > > 
> > > > > > > Hi,
> > > > > > > 
> > > > > > > I'm working on https://bugzilla.redhat.com/785555 -- "domain
> > > > > > > selection
> > > > > > > list
> > > > > > > in login screen should be sorted alphabetically"
> > > > > > > 
> > > > > > > I was going to put the sort logic in the web apps, but it makes
> > > > > > > sense
> > > > > > > to
> > > > > > > just
> > > > > > > put it in the backend, specifically in GetDomainListQuery. (There
> > > > > > > is
> > > > > > > already
> > > > > > > a sort there, but it needs to be tweaked to put "internal" always
> > > > > > > last.)
> > > > > > > This would affect non-webapp clients (REST API), so I want to
> > > > > > > make
> > > > > > > sure
> > > > > > > there are no objections. Unit tests pass and it seems to work
> > > > > > > fine
> > > > > > > (screen
> > > > > > > attached).
> > > > > > > 
> > > > > > > Any objections?
> > > > > > 
> > > > > > I think that sorting of visualization is presentation layer role.
> > > > > 
> > > > > true in general, but I think that there is no harm in returning items
> > > > > from the backend in some default order, especially if this is a list
> > > > > of simple items that have only one possible order that makes sense.
> > > > 
> > > > Even if that so, there is no reason to relay on it.
> > > 
> > > if this method will return a sorted list *by definition*, there would be
> > > no reason to NOT relay on it.
> > > for this particular case, I think that it would be a bit of waste if the
> > > exact same sorting logic will be duplicated across the different clients'
> > > code (including 3rd-party clients). If we can make it a little bit easier
> > > on the clients, I don't see why not to do it.
> > > 
> > > > If sort is required at presentation, presentation layer should apply
> > > > sort.
> > > 
> > > define "presentation"; looking at the xml response of a rest-api GET
> > > request
> > > in a browser is also "presentation", but I can't really apply sort there;
> > > yes,
> > > I can change the rest-api code to sort the results, but why not simply
> > > make
> > > it
> > > a bit easier for *all* clients, and return the results from the backend
> > > already
> > > sorted in the way which is probably the most comfortable for everyone?
> > > 
> > > [again - you are generally correct, but in this particular case, of
> > > simple
> > > business entities which have pretty much only one way of sorting that
> > > makes
> > > sense, I don't see why not make an exception and apply the sort on the
> > > backend]
> > 
> > Well, we can agree to disagree.
> > 
> > RestAPI is not presentation, the fact that browser has presentation layer
> > to
> > interact with RestAPI does not mean that the server side is responsible on
> > ordering etc. The RestAPI presentation layer may allow sorting.
> > 
> > I do not think that API should have any sense of presentation ordering it
> > only makes it more complex without a reason.
> > 
> > Let's assume the API sort is based on plain text, and you have a bug to
> > sort
> > using case insensitive, so API definition should be fixed? so you pass a
> > parameter to request specific casing?
> > 
> > Let's assume that each domain has value and description, you agree that
> > sort
> > should be based on description, right? Now, let's say that description can
> > be localized, which sort can the server apply?
> > 
> > These are the reason why presentation layer was split out, ever since IBM
> > Mainframe 3270 the layer is running on the client side.
> > 
> > Regards,
> > Alon Bar-Lev
> > 
> > > 
> > > > 
> > > > > 
> > > > > > 
> > > > > > > 
> > > > > > > Thanks,
> > > > > > > Greg
> > > > > > > 
> > > > > > > 
> > > > > > > Greg Sheremeta
> > > > > > > Red Hat, Inc.
> > > > > > > Sr. Software Engineer, RHEV
> > > > > > > Cell: 919-807-1086
> > > > > > > gshereme at redhat.com
> > > > > > > _______________________________________________
> > > > > > > Engine-devel mailing list
> > > > > > > Engine-devel at ovirt.org
> > > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > > > > > 
> > > > > > _______________________________________________
> > > > > > Engine-devel mailing list
> > > > > > Engine-devel at ovirt.org
> > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > 
> > > > _______________________________________________
> > > > Engine-devel mailing list
> > > > Engine-devel at ovirt.org
> > > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > > 
> > > > 
> > > > 
> > > 
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > 
> 


From michal.skrivanek at redhat.com  Mon Sep  2 13:35:21 2013
From: michal.skrivanek at redhat.com (Michal Skrivanek)
Date: Mon, 2 Sep 2013 15:35:21 +0200
Subject: [Engine-devel] Mapping between supported display protocols and
	video devices
In-Reply-To: <522316B8.10603@redhat.com>
References: <B2CAFC4D5E2D574A883EF61ACD5ADE3301812218@SERV070.corp.eldorado.org.br>
	<522316B8.10603@redhat.com>
Message-ID: <D3F39E76-1892-4D99-9794-AE1AD68BCE8A@redhat.com>


On Sep 1, 2013, at 12:28 , Roy Golan <rgolan at redhat.com> wrote:

> On 08/30/2013 07:33 PM, Vitor de Lima wrote:
>> Hi everyone,
>> 
>> Recently the changes #18150, #18677 and #17885 were submitted in order to avoid the selection of display protocols and virtual video cards that are incompatible with the PPC64 architecture and to map the VNC protocol with the standard VGA virtual device, since the Cirrus Logic device is not supported in the PPC64 architecture. I would like some feedback about that.
>> 
>> So far, these changes use an existing parameter in the osinfo (called "spiceSupport") to validate if the selected operating system supports SPICE and hide it in the frontend in case it doesn't. They also change the default virtual video card for each display protocol according to new properties in the osinfo, e.g.:
>> 
>> os.other.spiceSupport.value = true
>> os.other.devices.vnc.vmDeviceType.value = cirrus os.other.devices.qxl.vmDeviceType.value = qxl
>> os.other_ppc64.spiceSupport.value = false os.other_ppc64.devices.vnc.vmDeviceType.value = vga
>> (This maps the qxl protocol into the qxl device and the VNC protocol into the cirrus device in the x86_64 arch, and the VNC protocol into the VGA device in the PPC64)
>> 
>> However, this still has some limitations, such as:
>> 
>> * It doesn't allow the user to choose between the different virtual devices that exist and can be used in the VNC protocol (such as the QXL and VMware VGA)
>> * The syntax is ugly. As suggested in the code reviews, it could be a list of supported protocols, e.g.:
>> os.other.displayProtocols = vnc, spice
> +1 list style is cleaner, expressive and easy to use. spiceSupport was just the way to convert the old code to the osinfo style.
> 
> protocol-device mapping can be achieved by pairing them literally -
> 
> os.other.displayProtocols.value = vnc/cirrus, spice/qxl
> 
> which reads VNC over cirrus device, SPICE over qxl device.
> 
> and for ppc64:
> 
> os.other_ppc64.displayProtocols.value = vnc/qxl, spice/qxl
> 
> 
> I like this approach better than naming the keys with terms ...devices.vnc.VMDviceType?.

+1 if not too much complicated

> 
>> So, how should the engine be modified to allow multiple video cards for each display protocol? What do you think should be done?
> 
>> Thanks,
>> Vitor de Lima
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel



From oschreib at redhat.com  Mon Sep  2 14:06:44 2013
From: oschreib at redhat.com (Ofer Schreiber)
Date: Mon, 2 Sep 2013 10:06:44 -0400 (EDT)
Subject: [Engine-devel] oVirt 3.3 Release Go/No-Go meeting
Message-ID: <1783693160.8326287.1378130804021.JavaMail.root@redhat.com>

The following is a new meeting request:

Subject: oVirt 3.3 Release Go/No-Go meeting 
Organizer: "Ofer Schreiber" <oschreib at redhat.com> 

Location: #ovirt IRC channel @oftc 
Time: Tuesday, September 3, 2013, 4:00:00 PM - 4:30:00 PM GMT +02:00 Jerusalem
 
Invitees: board at ovirt.org; users at ovirt.org; engine-devel at ovirt.org 


*~*~*~*~*~*~*~*~*~*

oVirt 3.3 Release Go/No-Go meeting 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: meeting.ics
Type: text/calendar
Size: 1664 bytes
Desc: not available
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20130902/d60361d5/attachment.ics>

From leonardo.bianconi at eldorado.org.br  Mon Sep  2 15:43:03 2013
From: leonardo.bianconi at eldorado.org.br (Leonardo Bianconi)
Date: Mon, 2 Sep 2013 15:43:03 +0000
Subject: [Engine-devel] Cluster default with empty processor name with
 PPC64 support
In-Reply-To: <52249286.5010009@redhat.com>
References: <50EB20226B72D6419356FC320AB62B8719173370@SERV070.corp.eldorado.org.br>
	<5222F5B7.5060603@redhat.com>
	<50EB20226B72D6419356FC320AB62B87191733F5@SERV070.corp.eldorado.org.br>
	<52249286.5010009@redhat.com>
Message-ID: <50EB20226B72D6419356FC320AB62B8719173455@SERV070.corp.eldorado.org.br>



>-----Original Message-----
>From: Itamar Heim [mailto:iheim at redhat.com]
>Sent: segunda-feira, 2 de setembro de 2013 10:29
>To: Leonardo Bianconi
>Cc: Roy Golan; engine-devel at ovirt.org
>Subject: Re: [Engine-devel] Cluster default with empty processor name with PPC64 support
>
>On 09/02/2013 03:35 PM, Leonardo Bianconi wrote:
>>
>>
>>>> From: Roy Golan [mailto:rgolan at redhat.com]
>>>> Sent: domingo, 1 de setembro de 2013 05:07
>>>> To: Leonardo Bianconi
>>>> Cc: engine-devel at ovirt.org
>>>> Subject: Re: [Engine-devel] Cluster default with empty processor
>>>> name with PPC64 support
>>>>
>>>> On 08/30/2013 10:51 PM, Leonardo Bianconi wrote:
>>>> Hi everyone!
>>>>
>>>> During the development of PPC64 support in the engine, we faced some UX issues regarding the default Cluster (that Cluster with
>empty processor name).
>>>>
>>>> Currently, oVirt engine allows the default Cluster to contain empty processor name, and the administrator can add VMs and/or
>Templates to it. The processor name can be assigned later, editing the cluster or assigning a valid host to it.
>>>>
>>>> During the implementation of PPC64 support on the engine, the field "architecture" was added to Clusters, VMs and Templates
>entities.
>>>> herdado
>>>> So we have the following questions regarding how the UI should behave:
>>>>
>>>> - Shall we keep allowing the administrator to assign VMs and Templates to the Cluster with no processor name or assigned
>architecture ?
>>>>               -> If we have an "yes" for the question above:
>>>>               -- We will have to assign the architecture to the Cluster based on the OS of the first assigned VM, and  the processor name
>could be defined the same way as currently ... editing the Cluster or assigning a compatible Host to it.
>>>>                               -- The VM creation popup will have to be able to indicate the architecture of each OS ... some OSes have the same
>name, and it may get ambiguous since the Cluster architecture is still undefined at that point (before the first VM get already created).
>>>>
>>>> Thanks!
>>>> Regards.
>>>> Leonardo Bianconi
>>>>
>>> To add VMs you anyway need a running host in the cluster which means the cpu name and the architecture would be the host's.
>>> So we can keep the cluster attributes - "cpu name" and "arch" consistent and allow them to be empty on creation.
>>>
>>>
>> Hi Roy!
>>
>> There is a way to add VMs in a cluster with no hosts running. Steps to reproduce:
>> - Initialize the oVirt engine with a new data base
>> - Create a new Cluster (I will call it of newCluster) in the Data
>> Center Default
>> - Add a host in the newCluster
>> - Add a Storage
>> - Create a VM in the Cluster Default
>> Result: The system allows a VM in a cluster with no Hosts running in it.
>>
>> Is it a bug or a system functionality? If it's a functionality, the issue above can happen.
>
>while above can happen, is it really an interesting use case to solve?
>can user edit the arch field of a vm? if so, i'd just block running it on incorrect cluster (just like we block on moving it between
>incompatible clusters) until user fix the issue

Yes, it's interesting solve, because we use the cluster architecture when creating VMs.
The user cannot edit the arch field, because there is no field for that, it is inherited from the cluster. The arch is important on creating VMs, because it filters the OS list and defines the VM architecture.
What should we do?

Thanks!!


From iheim at redhat.com  Mon Sep  2 16:45:57 2013
From: iheim at redhat.com (Itamar Heim)
Date: Mon, 02 Sep 2013 19:45:57 +0300
Subject: [Engine-devel] Cluster default with empty processor name with
 PPC64 support
In-Reply-To: <50EB20226B72D6419356FC320AB62B8719173455@SERV070.corp.eldorado.org.br>
References: <50EB20226B72D6419356FC320AB62B8719173370@SERV070.corp.eldorado.org.br>
	<5222F5B7.5060603@redhat.com>
	<50EB20226B72D6419356FC320AB62B87191733F5@SERV070.corp.eldorado.org.br>
	<52249286.5010009@redhat.com>
	<50EB20226B72D6419356FC320AB62B8719173455@SERV070.corp.eldorado.org.br>
Message-ID: <5224C0C5.1030100@redhat.com>

On 09/02/2013 06:43 PM, Leonardo Bianconi wrote:
>
>
>> -----Original Message-----
>> From: Itamar Heim [mailto:iheim at redhat.com]
>> Sent: segunda-feira, 2 de setembro de 2013 10:29
>> To: Leonardo Bianconi
>> Cc: Roy Golan; engine-devel at ovirt.org
>> Subject: Re: [Engine-devel] Cluster default with empty processor name with PPC64 support
>>
>> On 09/02/2013 03:35 PM, Leonardo Bianconi wrote:
>>>
>>>
>>>>> From: Roy Golan [mailto:rgolan at redhat.com]
>>>>> Sent: domingo, 1 de setembro de 2013 05:07
>>>>> To: Leonardo Bianconi
>>>>> Cc: engine-devel at ovirt.org
>>>>> Subject: Re: [Engine-devel] Cluster default with empty processor
>>>>> name with PPC64 support
>>>>>
>>>>> On 08/30/2013 10:51 PM, Leonardo Bianconi wrote:
>>>>> Hi everyone!
>>>>>
>>>>> During the development of PPC64 support in the engine, we faced some UX issues regarding the default Cluster (that Cluster with
>> empty processor name).
>>>>>
>>>>> Currently, oVirt engine allows the default Cluster to contain empty processor name, and the administrator can add VMs and/or
>> Templates to it. The processor name can be assigned later, editing the cluster or assigning a valid host to it.
>>>>>
>>>>> During the implementation of PPC64 support on the engine, the field "architecture" was added to Clusters, VMs and Templates
>> entities.
>>>>> herdado
>>>>> So we have the following questions regarding how the UI should behave:
>>>>>
>>>>> - Shall we keep allowing the administrator to assign VMs and Templates to the Cluster with no processor name or assigned
>> architecture ?
>>>>>                -> If we have an "yes" for the question above:
>>>>>                -- We will have to assign the architecture to the Cluster based on the OS of the first assigned VM, and  the processor name
>> could be defined the same way as currently ... editing the Cluster or assigning a compatible Host to it.
>>>>>                                -- The VM creation popup will have to be able to indicate the architecture of each OS ... some OSes have the same
>> name, and it may get ambiguous since the Cluster architecture is still undefined at that point (before the first VM get already created).
>>>>>
>>>>> Thanks!
>>>>> Regards.
>>>>> Leonardo Bianconi
>>>>>
>>>> To add VMs you anyway need a running host in the cluster which means the cpu name and the architecture would be the host's.
>>>> So we can keep the cluster attributes - "cpu name" and "arch" consistent and allow them to be empty on creation.
>>>>
>>>>
>>> Hi Roy!
>>>
>>> There is a way to add VMs in a cluster with no hosts running. Steps to reproduce:
>>> - Initialize the oVirt engine with a new data base
>>> - Create a new Cluster (I will call it of newCluster) in the Data
>>> Center Default
>>> - Add a host in the newCluster
>>> - Add a Storage
>>> - Create a VM in the Cluster Default
>>> Result: The system allows a VM in a cluster with no Hosts running in it.
>>>
>>> Is it a bug or a system functionality? If it's a functionality, the issue above can happen.
>>
>> while above can happen, is it really an interesting use case to solve?
>> can user edit the arch field of a vm? if so, i'd just block running it on incorrect cluster (just like we block on moving it between
>> incompatible clusters) until user fix the issue
>
> Yes, it's interesting solve, because we use the cluster architecture when creating VMs.
> The user cannot edit the arch field, because there is no field for that, it is inherited from the cluster. The arch is important on creating VMs, because it filters the OS list and defines the VM architecture.
> What should we do?
>
> Thanks!!
>

so worst case the list is not filtered while creating the VM for that 
corner case?

thinking about this some more, with all due respect to PPC and this 
corner case, I'd just assume if cluster arch is not yet defined, OS list 
should be filtered as x86_64.
or, we block creating VMs on clusters which have no arch defined (I'm 
specifically not saying no hosts, just in case its useful somehow)


From leonardo.bianconi at eldorado.org.br  Mon Sep  2 19:50:21 2013
From: leonardo.bianconi at eldorado.org.br (Leonardo Bianconi)
Date: Mon, 2 Sep 2013 19:50:21 +0000
Subject: [Engine-devel] Importing OVF files for x86/PPC64
Message-ID: <50EB20226B72D6419356FC320AB62B87191734DB@SERV070.corp.eldorado.org.br>

Hi!

We are about to implement and propose changes in VM import UI ... for oVirt PPC64 (multiplatform). 
Currently it's possible to select more than one item to be imported. This may create a problem since administrators will be able  to select items with different architectures (e.g. x86 a PPC64) and import them into the same cluster.
We propose to add a column in the tables (VM Import and Template Import) to display the identified architecture of each VM to be imported.
The validation will occur by hitting the "Import" button action, that may block the operation in case there were items related to different architectures.

We'd like to know your opinion about it, because it will change how the user interacts (UX) with this feature.

Regards,
Leonardo Bianconi


From leonardo.bianconi at eldorado.org.br  Tue Sep  3 11:39:18 2013
From: leonardo.bianconi at eldorado.org.br (Leonardo Bianconi)
Date: Tue, 3 Sep 2013 11:39:18 +0000
Subject: [Engine-devel] Cluster default with empty processor name with
 PPC64 support
In-Reply-To: <5224C0C5.1030100@redhat.com>
References: <50EB20226B72D6419356FC320AB62B8719173370@SERV070.corp.eldorado.org.br>
	<5222F5B7.5060603@redhat.com>
	<50EB20226B72D6419356FC320AB62B87191733F5@SERV070.corp.eldorado.org.br>
	<52249286.5010009@redhat.com>
	<50EB20226B72D6419356FC320AB62B8719173455@SERV070.corp.eldorado.org.br>
	<5224C0C5.1030100@redhat.com>
Message-ID: <50EB20226B72D6419356FC320AB62B8719173508@SERV070.corp.eldorado.org.br>



>-----Original Message-----
>From: Itamar Heim [mailto:iheim at redhat.com]
>Sent: segunda-feira, 2 de setembro de 2013 13:46
>To: Leonardo Bianconi
>Cc: Roy Golan; engine-devel at ovirt.org
>Subject: Re: [Engine-devel] Cluster default with empty processor name with PPC64 support
>
>On 09/02/2013 06:43 PM, Leonardo Bianconi wrote:
>>
>>
>>> -----Original Message-----
>>> From: Itamar Heim [mailto:iheim at redhat.com]
>>> Sent: segunda-feira, 2 de setembro de 2013 10:29
>>> To: Leonardo Bianconi
>>> Cc: Roy Golan; engine-devel at ovirt.org
>>> Subject: Re: [Engine-devel] Cluster default with empty processor name
>>> with PPC64 support
>>>
>>> On 09/02/2013 03:35 PM, Leonardo Bianconi wrote:
>>>>
>>>>
>>>>>> From: Roy Golan [mailto:rgolan at redhat.com]
>>>>>> Sent: domingo, 1 de setembro de 2013 05:07
>>>>>> To: Leonardo Bianconi
>>>>>> Cc: engine-devel at ovirt.org
>>>>>> Subject: Re: [Engine-devel] Cluster default with empty processor
>>>>>> name with PPC64 support
>>>>>>
>>>>>> On 08/30/2013 10:51 PM, Leonardo Bianconi wrote:
>>>>>> Hi everyone!
>>>>>>
>>>>>> During the development of PPC64 support in the engine, we faced
>>>>>> some UX issues regarding the default Cluster (that Cluster with
>>> empty processor name).
>>>>>>
>>>>>> Currently, oVirt engine allows the default Cluster to contain
>>>>>> empty processor name, and the administrator can add VMs and/or
>>> Templates to it. The processor name can be assigned later, editing the cluster or assigning a valid host to it.
>>>>>>
>>>>>> During the implementation of PPC64 support on the engine, the
>>>>>> field "architecture" was added to Clusters, VMs and Templates
>>> entities.
>>>>>> herdado
>>>>>> So we have the following questions regarding how the UI should behave:
>>>>>>
>>>>>> - Shall we keep allowing the administrator to assign VMs and
>>>>>> Templates to the Cluster with no processor name or assigned
>>> architecture ?
>>>>>>                -> If we have an "yes" for the question above:
>>>>>>                -- We will have to assign the architecture to the
>>>>>> Cluster based on the OS of the first assigned VM, and  the
>>>>>> processor name
>>> could be defined the same way as currently ... editing the Cluster or assigning a compatible Host to it.
>>>>>>                                -- The VM creation popup will have
>>>>>> to be able to indicate the architecture of each OS ... some OSes
>>>>>> have the same
>>> name, and it may get ambiguous since the Cluster architecture is still undefined at that point (before the first VM get already
>created).
>>>>>>
>>>>>> Thanks!
>>>>>> Regards.
>>>>>> Leonardo Bianconi
>>>>>>
>>>>> To add VMs you anyway need a running host in the cluster which means the cpu name and the architecture would be the host's.
>>>>> So we can keep the cluster attributes - "cpu name" and "arch" consistent and allow them to be empty on creation.
>>>>>
>>>>>
>>>> Hi Roy!
>>>>
>>>> There is a way to add VMs in a cluster with no hosts running. Steps to reproduce:
>>>> - Initialize the oVirt engine with a new data base
>>>> - Create a new Cluster (I will call it of newCluster) in the Data
>>>> Center Default
>>>> - Add a host in the newCluster
>>>> - Add a Storage
>>>> - Create a VM in the Cluster Default
>>>> Result: The system allows a VM in a cluster with no Hosts running in it.
>>>>
>>>> Is it a bug or a system functionality? If it's a functionality, the issue above can happen.
>>>
>>> while above can happen, is it really an interesting use case to solve?
>>> can user edit the arch field of a vm? if so, i'd just block running
>>> it on incorrect cluster (just like we block on moving it between
>>> incompatible clusters) until user fix the issue
>>
>> Yes, it's interesting solve, because we use the cluster architecture when creating VMs.
>> The user cannot edit the arch field, because there is no field for that, it is inherited from the cluster. The arch is important on
>creating VMs, because it filters the OS list and defines the VM architecture.
>> What should we do?
>>
>> Thanks!!
>>
>
>so worst case the list is not filtered while creating the VM for that corner case?
>
>thinking about this some more, with all due respect to PPC and this corner case, I'd just assume if cluster arch is not yet defined, OS list
>should be filtered as x86_64.
>or, we block creating VMs on clusters which have no arch defined (I'm specifically not saying no hosts, just in case its useful somehow)

I think both are good solutions, but looking the system behavior, I think the first solution will be weird for new users and the second has problems when upgrading the data base.
I would suggest the following behavior:

1. For new data bases: Block the admin to add VMs in the cluster with no processor name (Cluster Default), i. e. no architecture.
2. For upgraded data bases, If the cluster with no processor name (Cluster Default) has:
  2.1 - VMs: Set the cluster architecture for x86_64 and allow admin use it as x86_64.
  2.2 - no VMs: Keep the cluster with no processor name, i. e. no architecture (it will keep the same behavior of the cluster for new data base - item 1)

On the item 2.1, when setting the architecture of the cluster (Cluster Default) for x86_64, the processor name will be empty. Should we set it for the lowest x86_64 level?

What do you think?

Thanks!!


From iheim at redhat.com  Tue Sep  3 11:49:53 2013
From: iheim at redhat.com (Itamar Heim)
Date: Tue, 03 Sep 2013 14:49:53 +0300
Subject: [Engine-devel] Cluster default with empty processor name with
 PPC64 support
In-Reply-To: <50EB20226B72D6419356FC320AB62B8719173508@SERV070.corp.eldorado.org.br>
References: <50EB20226B72D6419356FC320AB62B8719173370@SERV070.corp.eldorado.org.br>
	<5222F5B7.5060603@redhat.com>
	<50EB20226B72D6419356FC320AB62B87191733F5@SERV070.corp.eldorado.org.br>
	<52249286.5010009@redhat.com>
	<50EB20226B72D6419356FC320AB62B8719173455@SERV070.corp.eldorado.org.br>
	<5224C0C5.1030100@redhat.com>
	<50EB20226B72D6419356FC320AB62B8719173508@SERV070.corp.eldorado.org.br>
Message-ID: <5225CCE1.5010909@redhat.com>

On 09/03/2013 02:39 PM, Leonardo Bianconi wrote:
>
>
>> -----Original Message-----
>> From: Itamar Heim [mailto:iheim at redhat.com]
>> Sent: segunda-feira, 2 de setembro de 2013 13:46
>> To: Leonardo Bianconi
>> Cc: Roy Golan; engine-devel at ovirt.org
>> Subject: Re: [Engine-devel] Cluster default with empty processor name with PPC64 support
>>
>> On 09/02/2013 06:43 PM, Leonardo Bianconi wrote:
>>>
>>>
>>>> -----Original Message-----
>>>> From: Itamar Heim [mailto:iheim at redhat.com]
>>>> Sent: segunda-feira, 2 de setembro de 2013 10:29
>>>> To: Leonardo Bianconi
>>>> Cc: Roy Golan; engine-devel at ovirt.org
>>>> Subject: Re: [Engine-devel] Cluster default with empty processor name
>>>> with PPC64 support
>>>>
>>>> On 09/02/2013 03:35 PM, Leonardo Bianconi wrote:
>>>>>
>>>>>
>>>>>>> From: Roy Golan [mailto:rgolan at redhat.com]
>>>>>>> Sent: domingo, 1 de setembro de 2013 05:07
>>>>>>> To: Leonardo Bianconi
>>>>>>> Cc: engine-devel at ovirt.org
>>>>>>> Subject: Re: [Engine-devel] Cluster default with empty processor
>>>>>>> name with PPC64 support
>>>>>>>
>>>>>>> On 08/30/2013 10:51 PM, Leonardo Bianconi wrote:
>>>>>>> Hi everyone!
>>>>>>>
>>>>>>> During the development of PPC64 support in the engine, we faced
>>>>>>> some UX issues regarding the default Cluster (that Cluster with
>>>> empty processor name).
>>>>>>>
>>>>>>> Currently, oVirt engine allows the default Cluster to contain
>>>>>>> empty processor name, and the administrator can add VMs and/or
>>>> Templates to it. The processor name can be assigned later, editing the cluster or assigning a valid host to it.
>>>>>>>
>>>>>>> During the implementation of PPC64 support on the engine, the
>>>>>>> field "architecture" was added to Clusters, VMs and Templates
>>>> entities.
>>>>>>> herdado
>>>>>>> So we have the following questions regarding how the UI should behave:
>>>>>>>
>>>>>>> - Shall we keep allowing the administrator to assign VMs and
>>>>>>> Templates to the Cluster with no processor name or assigned
>>>> architecture ?
>>>>>>>                 -> If we have an "yes" for the question above:
>>>>>>>                 -- We will have to assign the architecture to the
>>>>>>> Cluster based on the OS of the first assigned VM, and  the
>>>>>>> processor name
>>>> could be defined the same way as currently ... editing the Cluster or assigning a compatible Host to it.
>>>>>>>                                 -- The VM creation popup will have
>>>>>>> to be able to indicate the architecture of each OS ... some OSes
>>>>>>> have the same
>>>> name, and it may get ambiguous since the Cluster architecture is still undefined at that point (before the first VM get already
>> created).
>>>>>>>
>>>>>>> Thanks!
>>>>>>> Regards.
>>>>>>> Leonardo Bianconi
>>>>>>>
>>>>>> To add VMs you anyway need a running host in the cluster which means the cpu name and the architecture would be the host's.
>>>>>> So we can keep the cluster attributes - "cpu name" and "arch" consistent and allow them to be empty on creation.
>>>>>>
>>>>>>
>>>>> Hi Roy!
>>>>>
>>>>> There is a way to add VMs in a cluster with no hosts running. Steps to reproduce:
>>>>> - Initialize the oVirt engine with a new data base
>>>>> - Create a new Cluster (I will call it of newCluster) in the Data
>>>>> Center Default
>>>>> - Add a host in the newCluster
>>>>> - Add a Storage
>>>>> - Create a VM in the Cluster Default
>>>>> Result: The system allows a VM in a cluster with no Hosts running in it.
>>>>>
>>>>> Is it a bug or a system functionality? If it's a functionality, the issue above can happen.
>>>>
>>>> while above can happen, is it really an interesting use case to solve?
>>>> can user edit the arch field of a vm? if so, i'd just block running
>>>> it on incorrect cluster (just like we block on moving it between
>>>> incompatible clusters) until user fix the issue
>>>
>>> Yes, it's interesting solve, because we use the cluster architecture when creating VMs.
>>> The user cannot edit the arch field, because there is no field for that, it is inherited from the cluster. The arch is important on
>> creating VMs, because it filters the OS list and defines the VM architecture.
>>> What should we do?
>>>
>>> Thanks!!
>>>
>>
>> so worst case the list is not filtered while creating the VM for that corner case?
>>
>> thinking about this some more, with all due respect to PPC and this corner case, I'd just assume if cluster arch is not yet defined, OS list
>> should be filtered as x86_64.
>> or, we block creating VMs on clusters which have no arch defined (I'm specifically not saying no hosts, just in case its useful somehow)
>
> I think both are good solutions, but looking the system behavior, I think the first solution will be weird for new users and the second has problems when upgrading the data base.
> I would suggest the following behavior:
>
> 1. For new data bases: Block the admin to add VMs in the cluster with no processor name (Cluster Default), i. e. no architecture.
> 2. For upgraded data bases, If the cluster with no processor name (Cluster Default) has:
>    2.1 - VMs: Set the cluster architecture for x86_64 and allow admin use it as x86_64.
>    2.2 - no VMs: Keep the cluster with no processor name, i. e. no architecture (it will keep the same behavior of the cluster for new data base - item 1)
>
> On the item 2.1, when setting the architecture of the cluster (Cluster Default) for x86_64, the processor name will be empty. Should we set it for the lowest x86_64 level?
>
> What do you think?
>
> Thanks!!
>

sounds good to me. roy/omer/michal?


From gustavo.pedrosa at eldorado.org.br  Tue Sep  3 12:14:26 2013
From: gustavo.pedrosa at eldorado.org.br (Gustavo Frederico Temple Pedrosa)
Date: Tue, 3 Sep 2013 12:14:26 +0000
Subject: [Engine-devel] Question about API REST
Message-ID: <EF26FC1776F7FF46BFC072393EFD13A29A40C6@SERV070.corp.eldorado.org.br>

Hello everyone,

I'm adding the architecture meta-field of VMs, Templates and Clusters in REST API (see change #16700 in gerrit). It's a read-only field (like a "final" in Java), that the administrator cannot change it, but there are some situations where there might be a value for it, such as when an entity is received from the API, slightly modified and then its update method is called. So I would like to ask these questions about how to implement it:

1) Should this attribute be mapped both ways (from the REST API to the engine and vice-versa)?
2) How should this field be declared in the rdsl_metadata? Do I have to explicitly put it in the optional arguments or should I omit it?
3) How can I make this field strictly immutable (like the ID field is), given that the architecture is a field of the CPU entity, and the methods used to check for invalid updates can only operate on fields that belong directly to the main entity?

Thanks.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20130903/9525154d/attachment.html>

From mpastern at redhat.com  Tue Sep  3 12:28:52 2013
From: mpastern at redhat.com (Michael Pasternak)
Date: Tue, 03 Sep 2013 15:28:52 +0300
Subject: [Engine-devel] Question about API REST
In-Reply-To: <EF26FC1776F7FF46BFC072393EFD13A29A40C6@SERV070.corp.eldorado.org.br>
References: <EF26FC1776F7FF46BFC072393EFD13A29A40C6@SERV070.corp.eldorado.org.br>
Message-ID: <5225D604.5020904@redhat.com>

On 09/03/2013 03:14 PM, Gustavo Frederico Temple Pedrosa wrote:
> Hello everyone,
> 
>  
> 
> I'm adding the architecture meta-field of VMs, Templates and Clusters in REST API (see change #16700 in gerrit). It's a read-only field (like a ?final? in Java), that the
> administrator cannot change it, but there are some situations where there might be a value for it, such as when an entity is received from the API, slightly modified and
> then its update method is called. So I would like to ask these questions about how to implement it:

not sure i follow, do you want it to be updatable or not?, can you elaborate a bit? do

> 
>  
> 
> 1) Should this attribute be mapped both ways (from the REST API to the engine and vice-versa)?

if you want it to be updateable, - yes.

> 
> 2) How should this field be declared in the rdsl_metadata? Do I have to explicitly put it in the optional arguments or should I omit it?

if they're valid for update - "put it in the optional arguments"

> 
> 3) How can I make this field strictly immutable (like the ID field is), 

currently we using immutability constraint in api for id only

> given that the architecture is a field of the CPU entity, and the methods used to check for invalid
> updates can only operate on fields that belong directly to the main entity?

this is not a api logic, consider adding CAN-DO-ACTION check at UPDATE command instead.

> 
>  
> 
> Thanks.
> 
>  
> 
> 
> 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


-- 

Michael Pasternak
RedHat, ENG-Virtualization R&D


From leonardo.bianconi at eldorado.org.br  Tue Sep  3 12:25:23 2013
From: leonardo.bianconi at eldorado.org.br (Leonardo Bianconi)
Date: Tue, 3 Sep 2013 12:25:23 +0000
Subject: [Engine-devel] Cluster default with empty processor name with
 PPC64 support
In-Reply-To: <92F7B641-3330-43DF-AA5B-523025BCF542@redhat.com>
References: <50EB20226B72D6419356FC320AB62B8719173370@SERV070.corp.eldorado.org.br>
	<5222F5B7.5060603@redhat.com>
	<50EB20226B72D6419356FC320AB62B87191733F5@SERV070.corp.eldorado.org.br>
	<52249286.5010009@redhat.com>
	<50EB20226B72D6419356FC320AB62B8719173455@SERV070.corp.eldorado.org.br>
	<5224C0C5.1030100@redhat.com>
	<50EB20226B72D6419356FC320AB62B8719173508@SERV070.corp.eldorado.org.br>
	<5225CCE1.5010909@redhat.com>
	<92F7B641-3330-43DF-AA5B-523025BCF542@redhat.com>
Message-ID: <50EB20226B72D6419356FC320AB62B8719173549@SERV070.corp.eldorado.org.br>



>-----Original Message-----
>From: Michal Skrivanek [mailto:mskrivan at redhat.com]
>Sent: ter?a-feira, 3 de setembro de 2013 09:19
>To: Leonardo Bianconi
>Cc: engine-devel at ovirt.org
>Subject: Re: [Engine-devel] Cluster default with empty processor name with PPC64 support
>
>
>On Sep 3, 2013, at 13:49 , Itamar Heim <iheim at redhat.com> wrote:
>
>> On 09/03/2013 02:39 PM, Leonardo Bianconi wrote:
>>>
>>>
>>>> -----Original Message-----
>>>> From: Itamar Heim [mailto:iheim at redhat.com]
>>>> Sent: segunda-feira, 2 de setembro de 2013 13:46
>>>> To: Leonardo Bianconi
>>>> Cc: Roy Golan; engine-devel at ovirt.org
>>>> Subject: Re: [Engine-devel] Cluster default with empty processor
>>>> name with PPC64 support
>>>>
>>>> On 09/02/2013 06:43 PM, Leonardo Bianconi wrote:
>>>>>
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Itamar Heim [mailto:iheim at redhat.com]
>>>>>> Sent: segunda-feira, 2 de setembro de 2013 10:29
>>>>>> To: Leonardo Bianconi
>>>>>> Cc: Roy Golan; engine-devel at ovirt.org
>>>>>> Subject: Re: [Engine-devel] Cluster default with empty processor
>>>>>> name with PPC64 support
>>>>>>
>>>>>> On 09/02/2013 03:35 PM, Leonardo Bianconi wrote:
>>>>>>>
>>>>>>>
>>>>>>>>> From: Roy Golan [mailto:rgolan at redhat.com]
>>>>>>>>> Sent: domingo, 1 de setembro de 2013 05:07
>>>>>>>>> To: Leonardo Bianconi
>>>>>>>>> Cc: engine-devel at ovirt.org
>>>>>>>>> Subject: Re: [Engine-devel] Cluster default with empty
>>>>>>>>> processor name with PPC64 support
>>>>>>>>>
>>>>>>>>> On 08/30/2013 10:51 PM, Leonardo Bianconi wrote:
>>>>>>>>> Hi everyone!
>>>>>>>>>
>>>>>>>>> During the development of PPC64 support in the engine, we faced
>>>>>>>>> some UX issues regarding the default Cluster (that Cluster with
>>>>>> empty processor name).
>>>>>>>>>
>>>>>>>>> Currently, oVirt engine allows the default Cluster to contain
>>>>>>>>> empty processor name, and the administrator can add VMs and/or
>>>>>> Templates to it. The processor name can be assigned later, editing the cluster or assigning a valid host to it.
>>>>>>>>>
>>>>>>>>> During the implementation of PPC64 support on the engine, the
>>>>>>>>> field "architecture" was added to Clusters, VMs and Templates
>>>>>> entities.
>>>>>>>>> herdado
>>>>>>>>> So we have the following questions regarding how the UI should behave:
>>>>>>>>>
>>>>>>>>> - Shall we keep allowing the administrator to assign VMs and
>>>>>>>>> Templates to the Cluster with no processor name or assigned
>>>>>> architecture ?
>>>>>>>>>                -> If we have an "yes" for the question above:
>>>>>>>>>                -- We will have to assign the architecture to
>>>>>>>>> the Cluster based on the OS of the first assigned VM, and  the
>>>>>>>>> processor name
>>>>>> could be defined the same way as currently ... editing the Cluster or assigning a compatible Host to it.
>>>>>>>>>                                -- The VM creation popup will
>>>>>>>>> have to be able to indicate the architecture of each OS ...
>>>>>>>>> some OSes have the same
>>>>>> name, and it may get ambiguous since the Cluster architecture is
>>>>>> still undefined at that point (before the first VM get already
>>>> created).
>>>>>>>>>
>>>>>>>>> Thanks!
>>>>>>>>> Regards.
>>>>>>>>> Leonardo Bianconi
>>>>>>>>>
>>>>>>>> To add VMs you anyway need a running host in the cluster which means the cpu name and the architecture would be the
>host's.
>>>>>>>> So we can keep the cluster attributes - "cpu name" and "arch" consistent and allow them to be empty on creation.
>>>>>>>>
>>>>>>>>
>>>>>>> Hi Roy!
>>>>>>>
>>>>>>> There is a way to add VMs in a cluster with no hosts running. Steps to reproduce:
>>>>>>> - Initialize the oVirt engine with a new data base
>>>>>>> - Create a new Cluster (I will call it of newCluster) in the Data
>>>>>>> Center Default
>>>>>>> - Add a host in the newCluster
>>>>>>> - Add a Storage
>>>>>>> - Create a VM in the Cluster Default
>>>>>>> Result: The system allows a VM in a cluster with no Hosts running in it.
>>>>>>>
>>>>>>> Is it a bug or a system functionality? If it's a functionality, the issue above can happen.
>>>>>>
>>>>>> while above can happen, is it really an interesting use case to solve?
>>>>>> can user edit the arch field of a vm? if so, i'd just block
>>>>>> running it on incorrect cluster (just like we block on moving it
>>>>>> between incompatible clusters) until user fix the issue
>>>>>
>>>>> Yes, it's interesting solve, because we use the cluster architecture when creating VMs.
>>>>> The user cannot edit the arch field, because there is no field for
>>>>> that, it is inherited from the cluster. The arch is important on
>>>> creating VMs, because it filters the OS list and defines the VM architecture.
>>>>> What should we do?
>>>>>
>>>>> Thanks!!
>>>>>
>>>>
>>>> so worst case the list is not filtered while creating the VM for that corner case?
>>>>
>>>> thinking about this some more, with all due respect to PPC and this
>>>> corner case, I'd just assume if cluster arch is not yet defined, OS list should be filtered as x86_64.
>>>> or, we block creating VMs on clusters which have no arch defined
>>>> (I'm specifically not saying no hosts, just in case its useful
>>>> somehow)
>>>
>>> I think both are good solutions, but looking the system behavior, I think the first solution will be weird for new users and the
>second has problems when upgrading the data base.
>>> I would suggest the following behavior:
>>>
>>> 1. For new data bases: Block the admin to add VMs in the cluster with no processor name (Cluster Default), i. e. no architecture.
>>> 2. For upgraded data bases, If the cluster with no processor name (Cluster Default) has:
>>>   2.1 - VMs: Set the cluster architecture for x86_64 and allow admin use it as x86_64.
>
>as an upgrade script, right?

Yes.

>
>>>   2.2 - no VMs: Keep the cluster with no processor name, i. e. no
>>> architecture (it will keep the same behavior of the cluster for new
>>> data base - item 1)
>>>
>>> On the item 2.1, when setting the architecture of the cluster (Cluster Default) for x86_64, the processor name will be empty.
>Should we set it for the lowest x86_64 level?

How about the processor name for this case, Any thoughts?

>
>sounds good enough
>
>Thanks,
>michal
>
>>>
>>> What do you think?
>>>
>>> Thanks!!
>>>
>>
>> sounds good to me. roy/omer/michal?
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel



From sabose at redhat.com  Tue Sep  3 13:16:53 2013
From: sabose at redhat.com (Sahina Bose)
Date: Tue, 03 Sep 2013 18:46:53 +0530
Subject: [Engine-devel] Storing command parameters
Message-ID: <5225E145.8040005@redhat.com>

Hi all,

As part of the gluster volume asynchronous tasks, we ran into a 
requirement wherein when we start a command, we need to remember the 
parameters that the command was started with.

Is there any infrastructure available to do this, or should we build 
something?

thanks
sahina


From gustavo.pedrosa at eldorado.org.br  Tue Sep  3 16:34:54 2013
From: gustavo.pedrosa at eldorado.org.br (Gustavo Frederico Temple Pedrosa)
Date: Tue, 3 Sep 2013 16:34:54 +0000
Subject: [Engine-devel] Question about API REST
In-Reply-To: <5225D604.5020904@redhat.com>
References: <EF26FC1776F7FF46BFC072393EFD13A29A40C6@SERV070.corp.eldorado.org.br>
	<5225D604.5020904@redhat.com>
Message-ID: <EF26FC1776F7FF46BFC072393EFD13A29A45BA@SERV070.corp.eldorado.org.br>

Thank you very much!




> -----Original Message-----
> From: Michael Pasternak [mailto:mpastern at redhat.com]
> Sent: ter?a-feira, 3 de setembro de 2013 09:29
> To: Gustavo Frederico Temple Pedrosa
> Cc: engine-devel at ovirt.org
> Subject: Re: [Engine-devel] Question about API REST
> 
> On 09/03/2013 03:14 PM, Gustavo Frederico Temple Pedrosa wrote:
> > Hello everyone,
> >
> >
> >
> > I'm adding the architecture meta-field of VMs, Templates and Clusters
> > in REST API (see change #16700 in gerrit). It's a read-only field
> > (like a "final" in Java), that the administrator cannot change it, but there are
> some situations where there might be a value for it, such as when an entity is
> received from the API, slightly modified and then its update method is called.
> So I would like to ask these questions about how to implement it:
> 
> not sure i follow, do you want it to be updatable or not?, can you elaborate a
> bit? do
> 
> >
> >
> >
> > 1) Should this attribute be mapped both ways (from the REST API to the
> engine and vice-versa)?
> 
> if you want it to be updateable, - yes.
> 
> >
> > 2) How should this field be declared in the rdsl_metadata? Do I have to
> explicitly put it in the optional arguments or should I omit it?
> 
> if they're valid for update - "put it in the optional arguments"
> 
> >
> > 3) How can I make this field strictly immutable (like the ID field
> > is),
> 
> currently we using immutability constraint in api for id only
> 
> > given that the architecture is a field of the CPU entity, and the
> > methods used to check for invalid updates can only operate on fields that
> belong directly to the main entity?
> 
> this is not a api logic, consider adding CAN-DO-ACTION check at UPDATE
> command instead.
> 
> >
> >
> >
> > Thanks.
> >
> >
> >
> >
> >
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> >
> 
> 
> --
> 
> Michael Pasternak
> RedHat, ENG-Virtualization R&D


From thildred at redhat.com  Wed Sep  4 02:13:12 2013
From: thildred at redhat.com (Tim Hildred)
Date: Tue, 3 Sep 2013 22:13:12 -0400 (EDT)
Subject: [Engine-devel] Big up Assaf Muller
In-Reply-To: <1630255238.9512237.1378260157739.JavaMail.root@redhat.com>
Message-ID: <672440274.9514855.1378260792215.JavaMail.root@redhat.com>

I just wanted to say what an amazing feature page this is:

http://www.ovirt.org/Features/Multiple_Gateways

I especially like the "Why do we need this feature" part. It is all so well laid out and presented. 

Nice work Assaf!

Tim Hildred, RHCE, RHCVA
Content Author II - Engineering Content Services, Red Hat, Inc.
Brisbane, Australia
Email: thildred at redhat.com
Internal: 8588287
Mobile: +61 4 666 25242
IRC: thildred



From amuller at redhat.com  Wed Sep  4 07:33:56 2013
From: amuller at redhat.com (Assaf Muller)
Date: Wed, 4 Sep 2013 03:33:56 -0400 (EDT)
Subject: [Engine-devel] Big up Assaf Muller
In-Reply-To: <672440274.9514855.1378260792215.JavaMail.root@redhat.com>
References: <672440274.9514855.1378260792215.JavaMail.root@redhat.com>
Message-ID: <617022879.9646577.1378280036426.JavaMail.root@redhat.com>

Thank you :)

----- Original Message -----
From: "Tim Hildred" <thildred at redhat.com>
To: engine-devel at ovirt.org
Cc: "Assaf Muller" <amuller at redhat.com>
Sent: Wednesday, September 4, 2013 4:13:12 AM
Subject: Big up Assaf Muller

I just wanted to say what an amazing feature page this is:

http://www.ovirt.org/Features/Multiple_Gateways

I especially like the "Why do we need this feature" part. It is all so well laid out and presented. 

Nice work Assaf!

Tim Hildred, RHCE, RHCVA
Content Author II - Engineering Content Services, Red Hat, Inc.
Brisbane, Australia
Email: thildred at redhat.com
Internal: 8588287
Mobile: +61 4 666 25242
IRC: thildred



From rgolan at redhat.com  Wed Sep  4 10:07:43 2013
From: rgolan at redhat.com (Roy Golan)
Date: Wed, 04 Sep 2013 13:07:43 +0300
Subject: [Engine-devel] Cluster default with empty processor name with
 PPC64 support
In-Reply-To: <50EB20226B72D6419356FC320AB62B87191733F5@SERV070.corp.eldorado.org.br>
References: <50EB20226B72D6419356FC320AB62B8719173370@SERV070.corp.eldorado.org.br>
	<5222F5B7.5060603@redhat.com>
	<50EB20226B72D6419356FC320AB62B87191733F5@SERV070.corp.eldorado.org.br>
Message-ID: <5227066F.7060509@redhat.com>

On 09/02/2013 03:35 PM, Leonardo Bianconi wrote:
>>> From: Roy Golan [mailto:rgolan at redhat.com]
>>> Sent: domingo, 1 de setembro de 2013 05:07
>>> To: Leonardo Bianconi
>>> Cc:engine-devel at ovirt.org
>>> Subject: Re: [Engine-devel] Cluster default with empty processor name with PPC64 support
>>>
>>> On 08/30/2013 10:51 PM, Leonardo Bianconi wrote:
>>> Hi everyone!
>>>   
>>> During the development of PPC64 support in the engine, we faced some UX issues regarding the default Cluster (that Cluster with empty processor name).
>>>   
>>> Currently, oVirt engine allows the default Cluster to contain empty processor name, and the administrator can add VMs and/or Templates to it. The processor name can be assigned later, editing the cluster or assigning a valid host to it.
>>>   
>>> During the implementation of PPC64 support on the engine, the field "architecture" was added to Clusters, VMs and Templates entities.
>>>   
>>> So we have the following questions regarding how the UI should behave:
>>>   
>>> - Shall we keep allowing the administrator to assign VMs and Templates to the Cluster with no processor name or assigned architecture ?
>>>               -> If we have an "yes" for the question above:
>>>               -- We will have to assign the architecture to the Cluster based on the OS of the first assigned VM, and  the processor name could be defined the same way as currently ... editing the Cluster or assigning a compatible Host to it.
>>>                               -- The VM creation popup will have to be able to indicate the architecture of each OS ... some OSes have the same name, and it may get ambiguous since the Cluster architecture is still undefined at that point (before the first VM get already created).
>>>   
>>> Thanks!
>>> Regards.
>>> Leonardo Bianconi
>>>
>> To add VMs you anyway need a running host in the cluster which means the cpu name and the architecture would be the host's.
>> So we can keep the cluster attributes - "cpu name" and "arch" consistent and allow them to be empty on creation.
>>
>>
> Hi Roy!
>
> There is a way to add VMs in a cluster with no hosts running. Steps to reproduce:
> - Initialize the oVirt engine with a new data base
> - Create a new Cluster (I will call it of newCluster) in the Data Center Default
> - Add a host in the newCluster
> - Add a Storage
> - Create a VM in the Cluster Default
> Result: The system allows a VM in a cluster with no Hosts running in it.
>
> Is it a bug or a system functionality? If it's a functionality, the issue above can happen.
Just to clear this one - its a functional thing. its a bit confusing but 
not too complicated:

Storage and all its related actions/entities are related to the Data 
Center (aka, code-wise storage pool). Its possible to
create a VM once the DC is up, without a cluster i.e also provision 
disks to it and so on.

Cluster is know as the "migration domain" wrt VMs. so CPU arch stuff, 
network config (also has a DC part though) and various other vars, must 
be homogeneous in order
for VMs to migrate between hosts. So cluster isn't really fully 
configured till it has at least 1 host up.

hope this make things clearer


> Thanks!!
> Regards.
> Leonardo Bianconi
>>> _______________________________________________
>>> Engine-devel mailing list
>>> Engine-devel at ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/engine-devel



From rgolan at redhat.com  Wed Sep  4 11:13:22 2013
From: rgolan at redhat.com (Roy Golan)
Date: Wed, 04 Sep 2013 14:13:22 +0300
Subject: [Engine-devel] Cluster default with empty processor name with
 PPC64 support
In-Reply-To: <50EB20226B72D6419356FC320AB62B87191733F5@SERV070.corp.eldorado.org.br>
References: <50EB20226B72D6419356FC320AB62B8719173370@SERV070.corp.eldorado.org.br>
	<5222F5B7.5060603@redhat.com>
	<50EB20226B72D6419356FC320AB62B87191733F5@SERV070.corp.eldorado.org.br>
Message-ID: <522715D2.8080103@redhat.com>

On 09/02/2013 03:35 PM, Leonardo Bianconi wrote:
>
>>> From: Roy Golan [mailto:rgolan at redhat.com]
>>> Sent: domingo, 1 de setembro de 2013 05:07
>>> To: Leonardo Bianconi
>>> Cc: engine-devel at ovirt.org
>>> Subject: Re: [Engine-devel] Cluster default with empty processor name with PPC64 support
>>>
>>> On 08/30/2013 10:51 PM, Leonardo Bianconi wrote:
>>> Hi everyone!
>>>   
>>> During the development of PPC64 support in the engine, we faced some UX issues regarding the default Cluster (that Cluster with empty processor name).
>>>   
>>> Currently, oVirt engine allows the default Cluster to contain empty processor name, and the administrator can add VMs and/or Templates to it. The processor name can be assigned later, editing the cluster or assigning a valid host to it.
>>>   
>>> During the implementation of PPC64 support on the engine, the field "architecture" was added to Clusters, VMs and Templates entities.
>>>   
>>> So we have the following questions regarding how the UI should behave:
>>>   
>>> - Shall we keep allowing the administrator to assign VMs and Templates to the Cluster with no processor name or assigned architecture ?
>>>               -> If we have an "yes" for the question above:
>>>               -- We will have to assign the architecture to the Cluster based on the OS of the first assigned VM, and  the processor name could be defined the same way as currently ... editing the Cluster or assigning a compatible Host to it.
>>>                               -- The VM creation popup will have to be able to indicate the architecture of each OS ... some OSes have the same name, and it may get ambiguous since the Cluster architecture is still undefined at that point (before the first VM get already created).
>>>   
>>> Thanks!
>>> Regards.
>>> Leonardo Bianconi
>>>
>> To add VMs you anyway need a running host in the cluster which means the cpu name and the architecture would be the host's.
>> So we can keep the cluster attributes - "cpu name" and "arch" consistent and allow them to be empty on creation.
>>
>>
> Hi Roy!
>
> There is a way to add VMs in a cluster with no hosts running. Steps to reproduce:
> - Initialize the oVirt engine with a new data base
> - Create a new Cluster (I will call it of newCluster) in the Data Center Default
> - Add a host in the newCluster
> - Add a Storage
> - Create a VM in the Cluster Default
> Result: The system allows a VM in a cluster with no Hosts running in it.
>
> Is it a bug or a system functionality? If it's a functionality, the issue above can happen.
Just to clear this one - its a functional thing. its a bit confusing but 
not too complicated:

Storage and all its related actions/entities are related to the Data 
Center (aka, code-wise storage pool). Its possible to
create a VM once the DC is up, without a cluster i.e also provision 
disks to it and so on.

Cluster is know as the "migration domain" wrt VMs. so CPU arch stuff, 
network config etc, must be homogeneous in order
for VMs to migrate between hosts which means we must have a running 
cluster i.e at least 1 running host in it.


>
> Thanks!!
> Regards.
> Leonardo Bianconi
>>> _______________________________________________
>>> Engine-devel mailing list
>>> Engine-devel at ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/engine-devel



From leonardo.bianconi at eldorado.org.br  Wed Sep  4 12:50:02 2013
From: leonardo.bianconi at eldorado.org.br (Leonardo Bianconi)
Date: Wed, 4 Sep 2013 12:50:02 +0000
Subject: [Engine-devel] Cluster default with empty processor name with
 PPC64 support
In-Reply-To: <522715D2.8080103@redhat.com>
References: <50EB20226B72D6419356FC320AB62B8719173370@SERV070.corp.eldorado.org.br>
	<5222F5B7.5060603@redhat.com>
	<50EB20226B72D6419356FC320AB62B87191733F5@SERV070.corp.eldorado.org.br>
	<522715D2.8080103@redhat.com>
Message-ID: <50EB20226B72D6419356FC320AB62B8719173649@SERV070.corp.eldorado.org.br>



>-----Original Message-----
>From: Roy Golan [mailto:rgolan at redhat.com]
>Sent: quarta-feira, 4 de setembro de 2013 08:13
>To: Leonardo Bianconi
>Cc: engine-devel at ovirt.org
>Subject: Re: [Engine-devel] Cluster default with empty processor name with PPC64 support
>
>On 09/02/2013 03:35 PM, Leonardo Bianconi wrote:
>>
>>>> From: Roy Golan [mailto:rgolan at redhat.com]
>>>> Sent: domingo, 1 de setembro de 2013 05:07
>>>> To: Leonardo Bianconi
>>>> Cc: engine-devel at ovirt.org
>>>> Subject: Re: [Engine-devel] Cluster default with empty processor
>>>> name with PPC64 support
>>>>
>>>> On 08/30/2013 10:51 PM, Leonardo Bianconi wrote:
>>>> Hi everyone!
>>>>
>>>> During the development of PPC64 support in the engine, we faced some UX issues regarding the default Cluster (that Cluster with
>empty processor name).
>>>>
>>>> Currently, oVirt engine allows the default Cluster to contain empty processor name, and the administrator can add VMs and/or
>Templates to it. The processor name can be assigned later, editing the cluster or assigning a valid host to it.
>>>>
>>>> During the implementation of PPC64 support on the engine, the field "architecture" was added to Clusters, VMs and Templates
>entities.
>>>>
>>>> So we have the following questions regarding how the UI should behave:
>>>>
>>>> - Shall we keep allowing the administrator to assign VMs and Templates to the Cluster with no processor name or assigned
>architecture ?
>>>>               -> If we have an "yes" for the question above:
>>>>               -- We will have to assign the architecture to the Cluster based on the OS of the first assigned VM, and  the processor name
>could be defined the same way as currently ... editing the Cluster or assigning a compatible Host to it.
>>>>                               -- The VM creation popup will have to be able to indicate the architecture of each OS ... some OSes have the same
>name, and it may get ambiguous since the Cluster architecture is still undefined at that point (before the first VM get already created).
>>>>
>>>> Thanks!
>>>> Regards.
>>>> Leonardo Bianconi
>>>>
>>> To add VMs you anyway need a running host in the cluster which means the cpu name and the architecture would be the host's.
>>> So we can keep the cluster attributes - "cpu name" and "arch" consistent and allow them to be empty on creation.
>>>
>>>
>> Hi Roy!
>>
>> There is a way to add VMs in a cluster with no hosts running. Steps to reproduce:
>> - Initialize the oVirt engine with a new data base
>> - Create a new Cluster (I will call it of newCluster) in the Data
>> Center Default
>> - Add a host in the newCluster
>> - Add a Storage
>> - Create a VM in the Cluster Default
>> Result: The system allows a VM in a cluster with no Hosts running in it.
>>
>> Is it a bug or a system functionality? If it's a functionality, the issue above can happen.
>Just to clear this one - its a functional thing. its a bit confusing but not too complicated:
>
>Storage and all its related actions/entities are related to the Data Center (aka, code-wise storage pool). Its possible to create a VM
>once the DC is up, without a cluster i.e also provision disks to it and so on.
>
>Cluster is know as the "migration domain" wrt VMs. so CPU arch stuff, network config etc, must be homogeneous in order for VMs to
>migrate between hosts which means we must have a running cluster i.e at least 1 running host in it.
>
Roy, thank you for the explanation! It`s clear now
>
>>
>> Thanks!!
>> Regards.
>> Leonardo Bianconi
>>>> _______________________________________________
>>>> Engine-devel mailing list
>>>> Engine-devel at ovirt.org
>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel



From emesika at redhat.com  Sun Sep  8 07:44:43 2013
From: emesika at redhat.com (Eli Mesika)
Date: Sun, 8 Sep 2013 03:44:43 -0400 (EDT)
Subject: [Engine-devel] Storing command parameters
In-Reply-To: <5225E145.8040005@redhat.com>
References: <5225E145.8040005@redhat.com>
Message-ID: <354689278.10863244.1378626283421.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Sahina Bose" <sabose at redhat.com>
> To: "Yair Zaslavsky" <yzaslavs at redhat.com>, "engine-devel" <engine-devel at ovirt.org>
> Sent: Tuesday, September 3, 2013 4:16:53 PM
> Subject: [Engine-devel] Storing command parameters
> 
> Hi all,
> 
> As part of the gluster volume asynchronous tasks, we ran into a
> requirement wherein when we start a command, we need to remember the
> parameters that the command was started with.
> 
> Is there any infrastructure available to do this, or should we build
> something?

Hi Sahina 
There is such a mechanism , it is called Compensation 
You can look at backend:compensate to see how it is used to rollback commands in the case of failure.

Yair can elaborate & help on that since he is the owner of 6this code 


> 
> thanks
> sahina
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From yzaslavs at redhat.com  Sun Sep  8 07:55:48 2013
From: yzaslavs at redhat.com (Yair Zaslavsky)
Date: Sun, 8 Sep 2013 03:55:48 -0400 (EDT)
Subject: [Engine-devel] Storing command parameters
In-Reply-To: <354689278.10863244.1378626283421.JavaMail.root@redhat.com>
References: <5225E145.8040005@redhat.com>
	<354689278.10863244.1378626283421.JavaMail.root@redhat.com>
Message-ID: <696224177.9766244.1378626948030.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Eli Mesika" <emesika at redhat.com>
> To: "Sahina Bose" <sabose at redhat.com>
> Cc: "Yair Zaslavsky" <yzaslavs at redhat.com>, "engine-devel" <engine-devel at ovirt.org>
> Sent: Sunday, September 8, 2013 10:44:43 AM
> Subject: Re: [Engine-devel] Storing command parameters
> 
> 
> 
> ----- Original Message -----
> > From: "Sahina Bose" <sabose at redhat.com>
> > To: "Yair Zaslavsky" <yzaslavs at redhat.com>, "engine-devel"
> > <engine-devel at ovirt.org>
> > Sent: Tuesday, September 3, 2013 4:16:53 PM
> > Subject: [Engine-devel] Storing command parameters
> > 
> > Hi all,
> > 
> > As part of the gluster volume asynchronous tasks, we ran into a
> > requirement wherein when we start a command, we need to remember the
> > parameters that the command was started with.
> > 
> > Is there any infrastructure available to do this, or should we build
> > something?
> 
> Hi Sahina
> There is such a mechanism , it is called Compensation
> You can look at backend:compensate to see how it is used to rollback commands
> in the case of failure.
> 
> Yair can elaborate & help on that since he is the owner of this code

Eli, I think using compensation here is an abuse.
Compensation is used to take snapshots of entities, and snapshots only classes THAT ARE (a plural of the "IS A" inheritance rule :) ) business entities.
The closest thing we have today to what Sahina needs, is IMHO async_tasks table which have command_id and parameters stored.
However, storing command parameters at tasks table is somewhat awkward (yes, I know we're doing it until this very moment) and we should revisit this, and have a real
table to store commands and associated parameters.

Yair


> 
> 
> > 
> > thanks
> > sahina
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > 
> 


From emesika at redhat.com  Sun Sep  8 08:00:35 2013
From: emesika at redhat.com (Eli Mesika)
Date: Sun, 8 Sep 2013 04:00:35 -0400 (EDT)
Subject: [Engine-devel] Storing command parameters
In-Reply-To: <696224177.9766244.1378626948030.JavaMail.root@redhat.com>
References: <5225E145.8040005@redhat.com>
	<354689278.10863244.1378626283421.JavaMail.root@redhat.com>
	<696224177.9766244.1378626948030.JavaMail.root@redhat.com>
Message-ID: <1469553218.10863916.1378627235849.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Yair Zaslavsky" <yzaslavs at redhat.com>
> To: "Eli Mesika" <emesika at redhat.com>
> Cc: "Sahina Bose" <sabose at redhat.com>, "engine-devel" <engine-devel at ovirt.org>
> Sent: Sunday, September 8, 2013 10:55:48 AM
> Subject: Re: [Engine-devel] Storing command parameters
> 
> 
> 
> ----- Original Message -----
> > From: "Eli Mesika" <emesika at redhat.com>
> > To: "Sahina Bose" <sabose at redhat.com>
> > Cc: "Yair Zaslavsky" <yzaslavs at redhat.com>, "engine-devel"
> > <engine-devel at ovirt.org>
> > Sent: Sunday, September 8, 2013 10:44:43 AM
> > Subject: Re: [Engine-devel] Storing command parameters
> > 
> > 
> > 
> > ----- Original Message -----
> > > From: "Sahina Bose" <sabose at redhat.com>
> > > To: "Yair Zaslavsky" <yzaslavs at redhat.com>, "engine-devel"
> > > <engine-devel at ovirt.org>
> > > Sent: Tuesday, September 3, 2013 4:16:53 PM
> > > Subject: [Engine-devel] Storing command parameters
> > > 
> > > Hi all,
> > > 
> > > As part of the gluster volume asynchronous tasks, we ran into a
> > > requirement wherein when we start a command, we need to remember the
> > > parameters that the command was started with.
> > > 
> > > Is there any infrastructure available to do this, or should we build
> > > something?
> > 
> > Hi Sahina
> > There is such a mechanism , it is called Compensation
> > You can look at backend:compensate to see how it is used to rollback
> > commands
> > in the case of failure.
> > 
> > Yair can elaborate & help on that since he is the owner of this code
> 
> Eli, I think using compensation here is an abuse.

Sure, I just meant to see what is done there as a code sample

> Compensation is used to take snapshots of entities, and snapshots only
> classes THAT ARE (a plural of the "IS A" inheritance rule :) ) business
> entities.
> The closest thing we have today to what Sahina needs, is IMHO async_tasks
> table which have command_id and parameters stored.
> However, storing command parameters at tasks table is somewhat awkward (yes,
> I know we're doing it until this very moment) and we should revisit this,
> and have a real
> table to store commands and associated parameters.

So, since Gluster has there own async tasks , do you recommend to have a separate table for their tasks ???
I think that they can use the current one , maybe we need additional column in async_tasks to distinguish between Gluster & our tasks ...


> 
> Yair
> 
> 
> > 
> > 
> > > 
> > > thanks
> > > sahina
> > > _______________________________________________
> > > Engine-devel mailing list
> > > Engine-devel at ovirt.org
> > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > 
> > 
> 


From mpastern at redhat.com  Sun Sep  8 09:20:20 2013
From: mpastern at redhat.com (Michael Pasternak)
Date: Sun, 08 Sep 2013 12:20:20 +0300
Subject: [Engine-devel] Minor question concerning ServerException class
In-Reply-To: <CE4F97DA.730F%rickyh@netapp.com>
References: <CE4F97DA.730F%rickyh@netapp.com>
Message-ID: <522C4154.2050401@redhat.com>

Hi Ricky,

On 09/06/2013 09:31 PM, Hopper, Richard wrote:
> Hi Michael,
> 
> While working with the ovirt-engine-sdk-java, 
> I came across a small issue concerning the ServerException class. I wrote a utility to handle different types of exceptions
> (ServerException being one of those) for our plugin and found that ServerException does not meet GWT's specific serialization requirements due to the lack of a no-arg
> constructor of any visibility level. Is there an explicit reason for the lack of such a constructor? 

no, not at all, addressed at [1].

[1] http://gerrit.ovirt.org/#/c/18960/

thanks for reporting this.

> I was able to work around this, it's just a minor concern as far as GWT
> goes, and it could be useful to others if such types were serializable as well.
> 
> Thanks,
> 
> - Ricky


-- 

Michael Pasternak
RedHat, ENG-Virtualization R&D


From gustavo.pedrosa at eldorado.org.br  Mon Sep  9 18:48:25 2013
From: gustavo.pedrosa at eldorado.org.br (Gustavo Frederico Temple Pedrosa)
Date: Mon, 9 Sep 2013 18:48:25 +0000
Subject: [Engine-devel] Question about HotPlug
Message-ID: <EF26FC1776F7FF46BFC072393EFD13A29A4E1F@SERV070.corp.eldorado.org.br>

Hi all,

Currently there is an option in the "vdc_options" table which indicates the operating systems that do not support NIC hotplug. I think it would be a better idea to use the osinfo properties file to enable or disable NIC hotplugging, since in this file an operating system can inherit properties from another one. The main idea is to disable NIC hotplugging in PPC64 VMs, but listing explicitly every ppc64 os in "HotPlugUnsupportedOsList" config value does not look like a clean way to do so. Do you agree with this? Should this parameter be included in the osinfo properties file?

Thanks,
Leonardo Bianconi/Vitor de Lima/Gustavo Pedrosa
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20130909/2f76388a/attachment.html>

From masayag at redhat.com  Tue Sep 10 07:08:00 2013
From: masayag at redhat.com (Moti Asayag)
Date: Tue, 10 Sep 2013 03:08:00 -0400 (EDT)
Subject: [Engine-devel] Question about HotPlug
In-Reply-To: <EF26FC1776F7FF46BFC072393EFD13A29A4E1F@SERV070.corp.eldorado.org.br>
References: <EF26FC1776F7FF46BFC072393EFD13A29A4E1F@SERV070.corp.eldorado.org.br>
Message-ID: <499037462.10156021.1378796880305.JavaMail.root@redhat.com>

Hi Gustavo,

----- Original Message -----
> From: "Gustavo Frederico Temple Pedrosa" <gustavo.pedrosa at eldorado.org.br>
> To: engine-devel at ovirt.org
> Sent: Monday, September 9, 2013 8:48:25 PM
> Subject: [Engine-devel] Question about HotPlug
> 
> 
> 
> Hi all,
> 
> Currently there is an option in the "vdc_options" table which indicates the
> operating systems that do not support NIC hotplug. I think it would be a
> better idea to use the osinfo properties file to enable or disable NIC
> hotplugging, since in this file an operating system can inherit properties
> from another one. The main idea is to disable NIC hotplugging in PPC64 VMs,
> but listing explicitly every ppc64 os in "HotPlugUnsupportedOsList" config
> value does not look like a clean way to do so. Do you agree with this?
> Should this parameter be included in the osinfo properties file?

The hotplug capability of the OS refers also to disk hotplug in addition to 
vnics hotplug.

The VmCommand.isOsSupportingHotPlug() handles the logic of the operating systems
that don't support hotplug.

+1 for moving it as a parameter in the osinfo-defaults.properties for the relevant
os.


> 
> 
> 
> Thanks,
> 
> Leonardo Bianconi/Vitor de Lima/Gustavo Pedrosa
> 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From iheim at redhat.com  Tue Sep 10 08:42:36 2013
From: iheim at redhat.com (Itamar Heim)
Date: Tue, 10 Sep 2013 11:42:36 +0300
Subject: [Engine-devel] Question about HotPlug
In-Reply-To: <499037462.10156021.1378796880305.JavaMail.root@redhat.com>
References: <EF26FC1776F7FF46BFC072393EFD13A29A4E1F@SERV070.corp.eldorado.org.br>
	<499037462.10156021.1378796880305.JavaMail.root@redhat.com>
Message-ID: <522EDB7C.5000901@redhat.com>

On 09/10/2013 10:08 AM, Moti Asayag wrote:
> Hi Gustavo,
>
> ----- Original Message -----
>> From: "Gustavo Frederico Temple Pedrosa" <gustavo.pedrosa at eldorado.org.br>
>> To: engine-devel at ovirt.org
>> Sent: Monday, September 9, 2013 8:48:25 PM
>> Subject: [Engine-devel] Question about HotPlug
>>
>>
>>
>> Hi all,
>>
>> Currently there is an option in the "vdc_options" table which indicates the
>> operating systems that do not support NIC hotplug. I think it would be a
>> better idea to use the osinfo properties file to enable or disable NIC
>> hotplugging, since in this file an operating system can inherit properties
>> from another one. The main idea is to disable NIC hotplugging in PPC64 VMs,
>> but listing explicitly every ppc64 os in "HotPlugUnsupportedOsList" config
>> value does not look like a clean way to do so. Do you agree with this?
>> Should this parameter be included in the osinfo properties file?
>
> The hotplug capability of the OS refers also to disk hotplug in addition to
> vnics hotplug.
>
> The VmCommand.isOsSupportingHotPlug() handles the logic of the operating systems
> that don't support hotplug.
>
> +1 for moving it as a parameter in the osinfo-defaults.properties for the relevant
> os.

+1
I'd also separate between hotplugdisk/nic
(and from what i hear, for some operations like cpu/ram, we'll need to 
distinguish between hotplug and hot unplug, but this can wait for them)

>
>
>>
>>
>>
>> Thanks,
>>
>> Leonardo Bianconi/Vitor de Lima/Gustavo Pedrosa
>>
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>



From rgolan at redhat.com  Tue Sep 10 09:31:46 2013
From: rgolan at redhat.com (Roy Golan)
Date: Tue, 10 Sep 2013 12:31:46 +0300
Subject: [Engine-devel] Question about HotPlug
In-Reply-To: <522EDB7C.5000901@redhat.com>
References: <EF26FC1776F7FF46BFC072393EFD13A29A4E1F@SERV070.corp.eldorado.org.br>
	<499037462.10156021.1378796880305.JavaMail.root@redhat.com>
	<522EDB7C.5000901@redhat.com>
Message-ID: <522EE702.400@redhat.com>

On Tue 10 Sep 2013 11:42:36 AM IDT, Itamar Heim wrote:
> On 09/10/2013 10:08 AM, Moti Asayag wrote:
>> Hi Gustavo,
>>
>> ----- Original Message -----
>>> From: "Gustavo Frederico Temple Pedrosa"
>>> <gustavo.pedrosa at eldorado.org.br>
>>> To: engine-devel at ovirt.org
>>> Sent: Monday, September 9, 2013 8:48:25 PM
>>> Subject: [Engine-devel] Question about HotPlug
>>>
>>>
>>>
>>> Hi all,
>>>
>>> Currently there is an option in the "vdc_options" table which
>>> indicates the
>>> operating systems that do not support NIC hotplug. I think it would
>>> be a
>>> better idea to use the osinfo properties file to enable or disable NIC
>>> hotplugging, since in this file an operating system can inherit
>>> properties
>>> from another one. The main idea is to disable NIC hotplugging in
>>> PPC64 VMs,
>>> but listing explicitly every ppc64 os in "HotPlugUnsupportedOsList"
>>> config
>>> value does not look like a clean way to do so. Do you agree with this?
>>> Should this parameter be included in the osinfo properties file?
>>
>> The hotplug capability of the OS refers also to disk hotplug in
>> addition to
>> vnics hotplug.
>>
>> The VmCommand.isOsSupportingHotPlug() handles the logic of the
>> operating systems
>> that don't support hotplug.
>>
>> +1 for moving it as a parameter in the osinfo-defaults.properties for
>> the relevant
>> os.
>
> +1
> I'd also separate between hotplugdisk/nic
> (and from what i hear, for some operations like cpu/ram, we'll need to
> distinguish between hotplug and hot unplug, but this can wait for them)
>
>>
>>
+1 whats the namespace you had in mind for it?
e.g.
 os.{id}.hotplugSupported.network.value = true

 or an existing devices namespace is also an option:

os.{id}.devices.network.hotplugSupport.value = true




>>>
>>>
>>>
>>> Thanks,
>>>
>>> Leonardo Bianconi/Vitor de Lima/Gustavo Pedrosa
>>>
>>> _______________________________________________
>>> Engine-devel mailing list
>>> Engine-devel at ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>
>
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel




From lzelkha at redhat.com  Tue Sep 10 12:23:02 2013
From: lzelkha at redhat.com (Liran Zelkha)
Date: Tue, 10 Sep 2013 08:23:02 -0400 (EDT)
Subject: [Engine-devel] Profiling presentation
Message-ID: <469596706.11679308.1378815782337.JavaMail.root@redhat.com>

Hi all,

For those who attended the profiling session today, or for anyone who wants to run a profiler on ovirt, please see today's presentation at http://www.slideshare.net/lzelkha/jprofiler8-ovirt


From gustavo.pedrosa at eldorado.org.br  Tue Sep 10 13:16:07 2013
From: gustavo.pedrosa at eldorado.org.br (Gustavo Frederico Temple Pedrosa)
Date: Tue, 10 Sep 2013 13:16:07 +0000
Subject: [Engine-devel] Question about HotPlug
In-Reply-To: <522EE702.400@redhat.com>
References: <EF26FC1776F7FF46BFC072393EFD13A29A4E1F@SERV070.corp.eldorado.org.br>
	<499037462.10156021.1378796880305.JavaMail.root@redhat.com>
	<522EDB7C.5000901@redhat.com> <522EE702.400@redhat.com>
Message-ID: <EF26FC1776F7FF46BFC072393EFD13A29A4EF0@SERV070.corp.eldorado.org.br>

Thank you all !

Roy, we will use your second suggestion, thank you very much.





> -----Original Message-----
> From: Roy Golan [mailto:rgolan at redhat.com]
> Sent: ter?a-feira, 10 de setembro de 2013 06:32
> To: Itamar Heim
> Cc: Gustavo Frederico Temple Pedrosa; engine-devel at ovirt.org; Moti Asayag
> Subject: Re: [Engine-devel] Question about HotPlug
> 
> On Tue 10 Sep 2013 11:42:36 AM IDT, Itamar Heim wrote:
> > On 09/10/2013 10:08 AM, Moti Asayag wrote:
> >> Hi Gustavo,
> >>
> >> ----- Original Message -----
> >>> From: "Gustavo Frederico Temple Pedrosa"
> >>> <gustavo.pedrosa at eldorado.org.br>
> >>> To: engine-devel at ovirt.org
> >>> Sent: Monday, September 9, 2013 8:48:25 PM
> >>> Subject: [Engine-devel] Question about HotPlug
> >>>
> >>>
> >>>
> >>> Hi all,
> >>>
> >>> Currently there is an option in the "vdc_options" table which
> >>> indicates the operating systems that do not support NIC hotplug. I
> >>> think it would be a better idea to use the osinfo properties file to
> >>> enable or disable NIC hotplugging, since in this file an operating
> >>> system can inherit properties from another one. The main idea is to
> >>> disable NIC hotplugging in
> >>> PPC64 VMs,
> >>> but listing explicitly every ppc64 os in "HotPlugUnsupportedOsList"
> >>> config
> >>> value does not look like a clean way to do so. Do you agree with this?
> >>> Should this parameter be included in the osinfo properties file?
> >>
> >> The hotplug capability of the OS refers also to disk hotplug in
> >> addition to vnics hotplug.
> >>
> >> The VmCommand.isOsSupportingHotPlug() handles the logic of the
> >> operating systems that don't support hotplug.
> >>
> >> +1 for moving it as a parameter in the osinfo-defaults.properties for
> >> the relevant
> >> os.
> >
> > +1
> > I'd also separate between hotplugdisk/nic (and from what i hear, for
> > some operations like cpu/ram, we'll need to distinguish between
> > hotplug and hot unplug, but this can wait for them)
> >
> >>
> >>
> +1 whats the namespace you had in mind for it?
> e.g.
>  os.{id}.hotplugSupported.network.value = true
> 
>  or an existing devices namespace is also an option:
> 
> os.{id}.devices.network.hotplugSupport.value = true
> 
> 
> 
> 
> >>>
> >>>
> >>>
> >>> Thanks,
> >>>
> >>> Leonardo Bianconi/Vitor de Lima/Gustavo Pedrosa
> >>>
> >>> _______________________________________________
> >>> Engine-devel mailing list
> >>> Engine-devel at ovirt.org
> >>> http://lists.ovirt.org/mailman/listinfo/engine-devel
> >>>
> >> _______________________________________________
> >> Engine-devel mailing list
> >> Engine-devel at ovirt.org
> >> http://lists.ovirt.org/mailman/listinfo/engine-devel
> >>
> >
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From bigclouds at 163.com  Tue Sep 10 13:44:17 2013
From: bigclouds at 163.com (bigclouds)
Date: Tue, 10 Sep 2013 21:44:17 +0800 (CST)
Subject: [Engine-devel] question related to sysprep and AD
Message-ID: <7b8c4691.1ec76.141081d9277.Coremail.bigclouds@163.com>

hi,all
 1.
it seems that ovirt has implemented to sysprep a windows.
if this feature works and how to take advantage of it.
 
2.on UI, there are several input places for AD(domain), if its goal is to add a guestvm into a domain?
how to use it and add a guest into domain?
 
3.if there is a way to add a guestvm into domain without reboot?
 
thanks.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20130910/fd350b1b/attachment.html>

From gustavo.pedrosa at eldorado.org.br  Tue Sep 10 18:20:32 2013
From: gustavo.pedrosa at eldorado.org.br (Gustavo Frederico Temple Pedrosa)
Date: Tue, 10 Sep 2013 18:20:32 +0000
Subject: [Engine-devel] Question about Disk Hotplug
Message-ID: <EF26FC1776F7FF46BFC072393EFD13A29A4FC8@SERV070.corp.eldorado.org.br>

Hi everyone,

We proposed some changes in how to query if an operating system supports hotplug, then Itamar suggested that disk hotplugging and NIC hotplugging could be separated from each other. While it is pretty clear how to put info about NIC hotplugging in the osinfo, here are a few issues when trying to introduce the same concept for disk hotplugging.

Some disk interfaces do not support hotplugging at all (like IDE), some of them support it in the x86_64, but not in the ppc64 architecture (like the VirtIO blk) and others support it in both architectures (like VirtIO SCSI). There is also a ppc64 specific controller called SPAPR VSCSI, which supports it too.

So, how do you propose a syntax to cover all these cases?

I thought about something along the lines of:
os.{id}.devices.disk.hotpluggableInterfaces = VirtIO_SCSI, VirtIO

Thanks,
Leonardo Bianconi/Vitor de Lima/Gustavo Pedrosa
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20130910/bfc2bc7c/attachment.html>

From mburns at redhat.com  Tue Sep 10 20:52:58 2013
From: mburns at redhat.com (Mike Burns)
Date: Tue, 10 Sep 2013 16:52:58 -0400
Subject: [Engine-devel] Fwd: PostgreSQL 9.3 in Fedora 20?
In-Reply-To: <CAERoc3qeDgqohzNEehH39UcMJC+dy9sQXYm6zweo9aLGrh_=nA@mail.gmail.com>
References: <CAERoc3qeDgqohzNEehH39UcMJC+dy9sQXYm6zweo9aLGrh_=nA@mail.gmail.com>
Message-ID: <522F86AA.1030502@redhat.com>

Just fyi -- this looks to be landing in Fedora 20.

Mike


-------- Original Message --------
Subject: 	PostgreSQL 9.3 in Fedora 20?
Date: 	Mon, 9 Sep 2013 17:19:54 +0200
From: 	Micha? Piotrowski <mkkp4x4 at gmail.com>
Reply-To: 	Development discussions related to Fedora
<devel at lists.fedoraproject.org>
To: 	Development discussions related to Fedora
<devel at lists.fedoraproject.org>



Hi,

I know that currently Fedora 20 is in feature freeze state. But Alpha
version is still not released and PosgreSQL developers released new
latest and greates version
http://www.postgresql.org/docs/9.3/static/release-9-3.html with cool
features. Are there chances to get this version for F20?

-- 
Best regards,
Michal

http://eventhorizon.pl/


-------------- next part --------------
-- 
devel mailing list
devel at lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

From rgolan at redhat.com  Wed Sep 11 08:27:04 2013
From: rgolan at redhat.com (Roy Golan)
Date: Wed, 11 Sep 2013 11:27:04 +0300
Subject: [Engine-devel] Question about Disk Hotplug
In-Reply-To: <EF26FC1776F7FF46BFC072393EFD13A29A4FC8@SERV070.corp.eldorado.org.br>
References: <EF26FC1776F7FF46BFC072393EFD13A29A4FC8@SERV070.corp.eldorado.org.br>
Message-ID: <52302958.8090903@redhat.com>

On Tue 10 Sep 2013 09:20:32 PM IDT, Gustavo Frederico Temple Pedrosa 
wrote:
> Hi everyone,
>
> We proposed some changes in how to query if an operating system
> supports hotplug, then Itamar suggested that disk hotplugging and NIC
> hotplugging could be separated from each other. While it is pretty
> clear how to put info about NIC hotplugging in the osinfo, here are a
> few issues when trying to introduce the same concept for disk hotplugging.
>
> Some disk interfaces do not support hotplugging at all (like IDE),
> some of them support it in the x86_64, but not in the ppc64
> architecture (like the VirtIO blk) and others support it in both
> architectures (like VirtIO SCSI). There is also a ppc64 specific
> controller called SPAPR VSCSI, which supports it too.
>
> So, how do you propose a syntax to cover all these cases?
>
> I thought about something along the lines of:
>
> os.{id}.devices.disk.hotpluggableInterfaces = VirtIO_SCSI, VirtIO
>
> Thanks,
>
> Leonardo Bianconi/Vitor de Lima/Gustavo Pedrosa
>

"storage" is a better term than "disk" so:

os.{id}.devices.storage...


maybe in the future we may expand the metadata model to hold devices 
and hook it to an OS

device.{id}....
os.{id}.devices={deviceId}

just a thought, its unnecessary for now.






From iheim at redhat.com  Wed Sep 11 09:06:40 2013
From: iheim at redhat.com (Itamar Heim)
Date: Wed, 11 Sep 2013 12:06:40 +0300
Subject: [Engine-devel] Question about Disk Hotplug
In-Reply-To: <52302958.8090903@redhat.com>
References: <EF26FC1776F7FF46BFC072393EFD13A29A4FC8@SERV070.corp.eldorado.org.br>
	<52302958.8090903@redhat.com>
Message-ID: <523032A0.9020400@redhat.com>

On 09/11/2013 11:27 AM, Roy Golan wrote:
> On Tue 10 Sep 2013 09:20:32 PM IDT, Gustavo Frederico Temple Pedrosa wrote:
>> Hi everyone,
>>
>> We proposed some changes in how to query if an operating system
>> supports hotplug, then Itamar suggested that disk hotplugging and NIC
>> hotplugging could be separated from each other. While it is pretty
>> clear how to put info about NIC hotplugging in the osinfo, here are a
>> few issues when trying to introduce the same concept for disk
>> hotplugging.
>>
>> Some disk interfaces do not support hotplugging at all (like IDE),
>> some of them support it in the x86_64, but not in the ppc64
>> architecture (like the VirtIO blk) and others support it in both
>> architectures (like VirtIO SCSI). There is also a ppc64 specific
>> controller called SPAPR VSCSI, which supports it too.
>>
>> So, how do you propose a syntax to cover all these cases?
>>
>> I thought about something along the lines of:
>>
>> os.{id}.devices.disk.hotpluggableInterfaces = VirtIO_SCSI, VirtIO
>>
>> Thanks,
>>
>> Leonardo Bianconi/Vitor de Lima/Gustavo Pedrosa
>>
>
> "storage" is a better term than "disk" so:

why? this is about a vdisk, isn't it?

>
> os.{id}.devices.storage...
>
>
> maybe in the future we may expand the metadata model to hold devices and
> hook it to an OS
>
> device.{id}....
> os.{id}.devices={deviceId}
>
> just a thought, its unnecessary for now.
>
>
>
>
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel



From lhornyak at redhat.com  Wed Sep 11 11:15:49 2013
From: lhornyak at redhat.com (Laszlo Hornyak)
Date: Wed, 11 Sep 2013 07:15:49 -0400 (EDT)
Subject: [Engine-devel] -1
In-Reply-To: <600865809.11042972.1378709489308.JavaMail.root@redhat.com>
Message-ID: <1953939643.12155097.1378898149074.JavaMail.root@redhat.com>

Hi,

This was my last week with oVirt, I give back my maintainer permissions.
Good luck guys! :)

Best regards,
Laszlo


From tjelinek at redhat.com  Wed Sep 11 11:23:46 2013
From: tjelinek at redhat.com (Tomas Jelinek)
Date: Wed, 11 Sep 2013 07:23:46 -0400 (EDT)
Subject: [Engine-devel] -1
In-Reply-To: <1953939643.12155097.1378898149074.JavaMail.root@redhat.com>
References: <1953939643.12155097.1378898149074.JavaMail.root@redhat.com>
Message-ID: <1301423103.12324703.1378898626432.JavaMail.root@redhat.com>

Hi Laszlo,

it is sad that you are leaving. 

But anyway, good luck in your new position!

H?ty?k M?r?!
Tomas

----- Original Message -----
> From: "Laszlo Hornyak" <lhornyak at redhat.com>
> To: "engine-devel" <engine-devel at ovirt.org>
> Sent: Wednesday, September 11, 2013 1:15:49 PM
> Subject: [Engine-devel] -1
> 
> Hi,
> 
> This was my last week with oVirt, I give back my maintainer permissions.
> Good luck guys! :)
> 
> Best regards,
> Laszlo
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From mpastern at redhat.com  Wed Sep 11 11:30:14 2013
From: mpastern at redhat.com (Michael Pasternak)
Date: Wed, 11 Sep 2013 14:30:14 +0300
Subject: [Engine-devel] ovirt-engine-sdk-java 1.0.0.17-1 released
In-Reply-To: <51E55894.6080904@redhat.com>
References: <51DACB05.2080908@redhat.com> <51E55894.6080904@redhat.com>
Message-ID: <52305446.9010704@redhat.com>


More details can be found at [1],
(note: change-log for [2] describing changes that took place from the last release 1.0.0.11-1)

[1] http://www.ovirt.org/Java-sdk-changelog
[2] 1.0.0.16 -1, 1.0.0.15 -1, 1.0.0.14 -1, 1.0.0.13 -1

-- 

Michael Pasternak
RedHat, ENG-Virtualization R&D


From mpastern at redhat.com  Wed Sep 11 11:38:35 2013
From: mpastern at redhat.com (Michael Pasternak)
Date: Wed, 11 Sep 2013 14:38:35 +0300
Subject: [Engine-devel] ovirt-engine-sdk-python 3.3.0.6-1 released
In-Reply-To: <51E5523C.6010301@redhat.com>
References: <515AD1E4.7050506@redhat.com> <51E5523C.6010301@redhat.com>
Message-ID: <5230563B.4030004@redhat.com>


For more details see [1],
(note: change-log for [2] describing changes that took place from the last release 3.3.0.3-1)

[1] http://wiki.ovirt.org/Python-sdk-changelog
[2] 3.3.0.5-1, 3.3.0.4-1

-- 

Michael Pasternak
RedHat, ENG-Virtualization R&D


From michal.skrivanek at redhat.com  Wed Sep 11 11:45:14 2013
From: michal.skrivanek at redhat.com (Michal Skrivanek)
Date: Wed, 11 Sep 2013 13:45:14 +0200
Subject: [Engine-devel] -1
In-Reply-To: <1301423103.12324703.1378898626432.JavaMail.root@redhat.com>
References: <1953939643.12155097.1378898149074.JavaMail.root@redhat.com>
	<1301423103.12324703.1378898626432.JavaMail.root@redhat.com>
Message-ID: <8D21B6BC-6D6E-4FB1-AE69-9CB143BA4982@redhat.com>

Hey, Hungry Hungarian,
I'm sorry to see you go, enjoy your new endeavors!

good luck!
michal

On Sep 11, 2013, at 13:23 , Tomas Jelinek <tjelinek at redhat.com> wrote:

> Hi Laszlo,
> 
> it is sad that you are leaving. 
> 
> But anyway, good luck in your new position!
> 
> H?ty?k M?r?!
> Tomas
> 
> ----- Original Message -----
>> From: "Laszlo Hornyak" <lhornyak at redhat.com>
>> To: "engine-devel" <engine-devel at ovirt.org>
>> Sent: Wednesday, September 11, 2013 1:15:49 PM
>> Subject: [Engine-devel] -1
>> 
>> Hi,
>> 
>> This was my last week with oVirt, I give back my maintainer permissions.
>> Good luck guys! :)
>> 
>> Best regards,
>> Laszlo
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>> 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel



From rgolan at redhat.com  Wed Sep 11 13:51:08 2013
From: rgolan at redhat.com (Roy Golan)
Date: Wed, 11 Sep 2013 16:51:08 +0300
Subject: [Engine-devel] Question about Disk Hotplug
In-Reply-To: <523032A0.9020400@redhat.com>
References: <EF26FC1776F7FF46BFC072393EFD13A29A4FC8@SERV070.corp.eldorado.org.br>
	<52302958.8090903@redhat.com> <523032A0.9020400@redhat.com>
Message-ID: <5230754C.9030809@redhat.com>

On Wed 11 Sep 2013 12:06:40 PM IDT, Itamar Heim wrote:
> On 09/11/2013 11:27 AM, Roy Golan wrote:
>> On Tue 10 Sep 2013 09:20:32 PM IDT, Gustavo Frederico Temple Pedrosa
>> wrote:
>>> Hi everyone,
>>>
>>> We proposed some changes in how to query if an operating system
>>> supports hotplug, then Itamar suggested that disk hotplugging and NIC
>>> hotplugging could be separated from each other. While it is pretty
>>> clear how to put info about NIC hotplugging in the osinfo, here are a
>>> few issues when trying to introduce the same concept for disk
>>> hotplugging.
>>>
>>> Some disk interfaces do not support hotplugging at all (like IDE),
>>> some of them support it in the x86_64, but not in the ppc64
>>> architecture (like the VirtIO blk) and others support it in both
>>> architectures (like VirtIO SCSI). There is also a ppc64 specific
>>> controller called SPAPR VSCSI, which supports it too.
>>>
>>> So, how do you propose a syntax to cover all these cases?
>>>
>>> I thought about something along the lines of:
>>>
>>> os.{id}.devices.disk.hotpluggableInterfaces = VirtIO_SCSI, VirtIO
>>>
>>> Thanks,
>>>
>>> Leonardo Bianconi/Vitor de Lima/Gustavo Pedrosa
>>>
>>
>> "storage" is a better term than "disk" so:
>
> why? this is about a vdisk, isn't it?
well a vnic and vdisk are the building blocks in the end. so either we 
use vnic vdisk etc or storage,network etc for all

>
>>
>> os.{id}.devices.storage...
>>
>>
>> maybe in the future we may expand the metadata model to hold devices and
>> hook it to an OS
>>
>> device.{id}....
>> os.{id}.devices={deviceId}
>>
>> just a thought, its unnecessary for now.
>>
>>
>>
>>
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>




From iheim at redhat.com  Wed Sep 11 14:16:04 2013
From: iheim at redhat.com (Itamar Heim)
Date: Wed, 11 Sep 2013 17:16:04 +0300
Subject: [Engine-devel] Question about Disk Hotplug
In-Reply-To: <5230754C.9030809@redhat.com>
References: <EF26FC1776F7FF46BFC072393EFD13A29A4FC8@SERV070.corp.eldorado.org.br>
	<52302958.8090903@redhat.com> <523032A0.9020400@redhat.com>
	<5230754C.9030809@redhat.com>
Message-ID: <52307B24.7080304@redhat.com>

On 09/11/2013 04:51 PM, Roy Golan wrote:
> On Wed 11 Sep 2013 12:06:40 PM IDT, Itamar Heim wrote:
>> On 09/11/2013 11:27 AM, Roy Golan wrote:
>>> On Tue 10 Sep 2013 09:20:32 PM IDT, Gustavo Frederico Temple Pedrosa
>>> wrote:
>>>> Hi everyone,
>>>>
>>>> We proposed some changes in how to query if an operating system
>>>> supports hotplug, then Itamar suggested that disk hotplugging and NIC
>>>> hotplugging could be separated from each other. While it is pretty
>>>> clear how to put info about NIC hotplugging in the osinfo, here are a
>>>> few issues when trying to introduce the same concept for disk
>>>> hotplugging.
>>>>
>>>> Some disk interfaces do not support hotplugging at all (like IDE),
>>>> some of them support it in the x86_64, but not in the ppc64
>>>> architecture (like the VirtIO blk) and others support it in both
>>>> architectures (like VirtIO SCSI). There is also a ppc64 specific
>>>> controller called SPAPR VSCSI, which supports it too.
>>>>
>>>> So, how do you propose a syntax to cover all these cases?
>>>>
>>>> I thought about something along the lines of:
>>>>
>>>> os.{id}.devices.disk.hotpluggableInterfaces = VirtIO_SCSI, VirtIO
>>>>
>>>> Thanks,
>>>>
>>>> Leonardo Bianconi/Vitor de Lima/Gustavo Pedrosa
>>>>
>>>
>>> "storage" is a better term than "disk" so:
>>
>> why? this is about a vdisk, isn't it?
> well a vnic and vdisk are the building blocks in the end. so either we
> use vnic vdisk etc or storage,network etc for all

we could have other "storage" things than disks?

>
>>
>>>
>>> os.{id}.devices.storage...
>>>
>>>
>>> maybe in the future we may expand the metadata model to hold devices and
>>> hook it to an OS
>>>
>>> device.{id}....
>>> os.{id}.devices={deviceId}
>>>
>>> just a thought, its unnecessary for now.
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Engine-devel mailing list
>>> Engine-devel at ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>
>
>



From oschreib at redhat.com  Wed Sep 11 15:26:39 2013
From: oschreib at redhat.com (Ofer Schreiber)
Date: Wed, 11 Sep 2013 11:26:39 -0400 (EDT)
Subject: [Engine-devel] oVirt 3.3.1 Release - Rebase/Cherry-picks
In-Reply-To: <843102480.12992287.1378912986862.JavaMail.root@redhat.com>
Message-ID: <1314583082.12994296.1378913199492.JavaMail.root@redhat.com>

During the oVirt weekly meeting today we discussed the possibility of rebasing ovirt-engine-3.3 branch upon master for the coming 3.3.1 release.
If you have any comment or thoughts about it, please do so now.
The final decision will take place during the next oVirt weekly meeting.

Regards,

--
Ofer Schreiber


From eedri at redhat.com  Wed Sep 11 19:08:25 2013
From: eedri at redhat.com (Eyal Edri)
Date: Wed, 11 Sep 2013 15:08:25 -0400 (EDT)
Subject: [Engine-devel] [action needed] failing jenkins job "ovirt db report
	engine"
In-Reply-To: <34737970.11548537.1378926331468.JavaMail.root@redhat.com>
Message-ID: <597809255.11549166.1378926505830.JavaMail.root@redhat.com>

fyi,

the following job [1] is failing due to missing files on the slave (it used local files/software).
the original slave is now not available.

does this jobs is still needed? is so, the owner of the job should write a puppet class
to install needed files for it so it won't be locally only on the jenkins slaves (which should be stateless).

job will be disabled until fixed.

[1] http://jenkins.ovirt.org/job/ovirt_db_report_engine/

thank you,

eyal edri,
oVirt infra team.


From emesika at redhat.com  Thu Sep 12 08:03:06 2013
From: emesika at redhat.com (Eli Mesika)
Date: Thu, 12 Sep 2013 04:03:06 -0400 (EDT)
Subject: [Engine-devel] Fwd: PostgreSQL 9.3 in Fedora 20?
In-Reply-To: <522F86AA.1030502@redhat.com>
References: <CAERoc3qeDgqohzNEehH39UcMJC+dy9sQXYm6zweo9aLGrh_=nA@mail.gmail.com>
	<522F86AA.1030502@redhat.com>
Message-ID: <1800505458.13312998.1378972986601.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Mike Burns" <mburns at redhat.com>
> To: engine-devel at ovirt.org
> Sent: Tuesday, September 10, 2013 11:52:58 PM
> Subject: [Engine-devel] Fwd: PostgreSQL 9.3 in Fedora 20?
> 
> Just fyi -- this looks to be landing in Fedora 20.

Seems like a great version with features for which we are waiting for years.
My top 3 :

1) Add materialized views
2) Make simple views auto-updatable
3) Greatly reduce System V shared memory requirements


> 
> Mike
> 
> 
> -------- Original Message --------
> Subject: 	PostgreSQL 9.3 in Fedora 20?
> Date: 	Mon, 9 Sep 2013 17:19:54 +0200
> From: 	Micha? Piotrowski <mkkp4x4 at gmail.com>
> Reply-To: 	Development discussions related to Fedora
> <devel at lists.fedoraproject.org>
> To: 	Development discussions related to Fedora
> <devel at lists.fedoraproject.org>
> 
> 
> 
> Hi,
> 
> I know that currently Fedora 20 is in feature freeze state. But Alpha
> version is still not released and PosgreSQL developers released new
> latest and greates version
> http://www.postgresql.org/docs/9.3/static/release-9-3.html with cool
> features. Are there chances to get this version for F20?
> 
> --
> Best regards,
> Michal
> 
> http://eventhorizon.pl/
> 
> 
> 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From mtayer at redhat.com  Thu Sep 12 08:54:34 2013
From: mtayer at redhat.com (Mooli Tayer)
Date: Thu, 12 Sep 2013 04:54:34 -0400 (EDT)
Subject: [Engine-devel] A maven question
In-Reply-To: <988905139.12947189.1378974707232.JavaMail.root@redhat.com>
Message-ID: <268438611.12959358.1378976074811.JavaMail.root@redhat.com>

(Moving here from a patch disscission)

in our main aggregator pom.xml we use properties to manage dependencies

Why do we use those vars and not put the version in the dependencyManagement tag in our aggregator pom and in a project's pom declare dependencies without the version (gets weirder when we have a var we use only in a dependencyManagement tag - why use the var?)
as I currently understand our container we cannot use different versions of a dependency (although it is possible in jboss) - is that true?


From dneary at redhat.com  Thu Sep 12 13:44:21 2013
From: dneary at redhat.com (Dave Neary)
Date: Thu, 12 Sep 2013 15:44:21 +0200
Subject: [Engine-devel] -1
In-Reply-To: <1953939643.12155097.1378898149074.JavaMail.root@redhat.com>
References: <1953939643.12155097.1378898149074.JavaMail.root@redhat.com>
Message-ID: <5231C535.8090606@redhat.com>

Hi Laszlo,

If you want to hand back permissions for oVirt, then by all means, I'll
take care of it. But the nature of community projects is that you're
still trusted, even if you're changing jobs. So you are welcome to
remain an administrator for as long as you would like.

Thanks,
Dave.

On 09/11/2013 01:15 PM, Laszlo Hornyak wrote:
> Hi,
> 
> This was my last week with oVirt, I give back my maintainer permissions.
> Good luck guys! :)
> 
> Best regards,
> Laszlo
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 

-- 
Dave Neary - Community Action and Impact
Open Source and Standards, Red Hat - http://community.redhat.com
Ph: +33 9 50 71 55 62 / Cell: +33 6 77 01 92 13


From tjelinek at redhat.com  Fri Sep 13 06:48:18 2013
From: tjelinek at redhat.com (Tomas Jelinek)
Date: Fri, 13 Sep 2013 02:48:18 -0400 (EDT)
Subject: [Engine-devel]  fake VDSM as oVirt project?
In-Reply-To: <1732541231.13807474.1379053254880.JavaMail.root@redhat.com>
Message-ID: <2124371524.13814658.1379054898078.JavaMail.root@redhat.com>

Hi all,

some time ago Libor Spevak created a simple web app called vdsm fake:
documented: http://www.ovirt.org/VDSM_Fake
published: https://github.com/lspevak/ovirt-vdsmfake

It is basically a simple hackable java web application which can emulate the VDSM so you can connect the 
engine to it. It is especially useful for:
- having tons of cheap fake hosts on one machine to stress your engine
- doing some experiments with VDSM API (e.g. vfeenstr proposes a new VDSM API to lower the network traffic between 
  engine <-> VDSM and uses the vdsm fake to implement it and do some tests to get some numbers on how does this change the things)

Omer came up with an idea of making this app as one of oVirt's project (http://www.ovirt.org/Subprojects) maybe with repository on 
oVirt's gerrit making it more accessible for getting/contributing for the whole community.

What do you think about it?

Tomas


From liran.zelkha at gmail.com  Fri Sep 13 06:52:42 2013
From: liran.zelkha at gmail.com (Liran Zelkha)
Date: Fri, 13 Sep 2013 08:52:42 +0200
Subject: [Engine-devel] fake VDSM as oVirt project?
In-Reply-To: <2124371524.13814658.1379054898078.JavaMail.root@redhat.com>
References: <1732541231.13807474.1379053254880.JavaMail.root@redhat.com>
	<2124371524.13814658.1379054898078.JavaMail.root@redhat.com>
Message-ID: <CAJ3aYLdQoXwYpOZ=uRa8pj5jbzoEzjndb2bJAeB5N76QVtHZ8Q@mail.gmail.com>

+1 I use it constantly.


On Fri, Sep 13, 2013 at 8:48 AM, Tomas Jelinek <tjelinek at redhat.com> wrote:

> Hi all,
>
> some time ago Libor Spevak created a simple web app called vdsm fake:
> documented: http://www.ovirt.org/VDSM_Fake
> published: https://github.com/lspevak/ovirt-vdsmfake
>
> It is basically a simple hackable java web application which can emulate
> the VDSM so you can connect the
> engine to it. It is especially useful for:
> - having tons of cheap fake hosts on one machine to stress your engine
> - doing some experiments with VDSM API (e.g. vfeenstr proposes a new VDSM
> API to lower the network traffic between
>   engine <-> VDSM and uses the vdsm fake to implement it and do some tests
> to get some numbers on how does this change the things)
>
> Omer came up with an idea of making this app as one of oVirt's project (
> http://www.ovirt.org/Subprojects) maybe with repository on
> oVirt's gerrit making it more accessible for getting/contributing for the
> whole community.
>
> What do you think about it?
>
> Tomas
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20130913/b9683f39/attachment.html>

From eedri at redhat.com  Sun Sep 15 08:22:12 2013
From: eedri at redhat.com (Eyal Edri)
Date: Sun, 15 Sep 2013 04:22:12 -0400 (EDT)
Subject: [Engine-devel] fake VDSM as oVirt project?
In-Reply-To: <CAJ3aYLdQoXwYpOZ=uRa8pj5jbzoEzjndb2bJAeB5N76QVtHZ8Q@mail.gmail.com>
References: <1732541231.13807474.1379053254880.JavaMail.root@redhat.com>
	<2124371524.13814658.1379054898078.JavaMail.root@redhat.com>
	<CAJ3aYLdQoXwYpOZ=uRa8pj5jbzoEzjndb2bJAeB5N76QVtHZ8Q@mail.gmail.com>
Message-ID: <1246731265.13681961.1379233332597.JavaMail.root@redhat.com>

shouldn't this be on vdsm-devel?

[adding relevant groups]

----- Original Message -----
> From: "Liran Zelkha" <liran.zelkha at gmail.com>
> To: "Tomas Jelinek" <tjelinek at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>
> Sent: Friday, September 13, 2013 9:52:42 AM
> Subject: Re: [Engine-devel] fake VDSM as oVirt project?
> 
> +1 I use it constantly.
> 
> 
> On Fri, Sep 13, 2013 at 8:48 AM, Tomas Jelinek < tjelinek at redhat.com > wrote:
> 
> 
> Hi all,
> 
> some time ago Libor Spevak created a simple web app called vdsm fake:
> documented: http://www.ovirt.org/VDSM_Fake
> published: https://github.com/lspevak/ovirt-vdsmfake
> 
> It is basically a simple hackable java web application which can emulate the
> VDSM so you can connect the
> engine to it. It is especially useful for:
> - having tons of cheap fake hosts on one machine to stress your engine
> - doing some experiments with VDSM API (e.g. vfeenstr proposes a new VDSM API
> to lower the network traffic between
> engine <-> VDSM and uses the vdsm fake to implement it and do some tests to
> get some numbers on how does this change the things)
> 
> Omer came up with an idea of making this app as one of oVirt's project (
> http://www.ovirt.org/Subprojects ) maybe with repository on
> oVirt's gerrit making it more accessible for getting/contributing for the
> whole community.
> 
> What do you think about it?
> 
> Tomas
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 
> 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From iheim at redhat.com  Sun Sep 15 09:57:29 2013
From: iheim at redhat.com (Itamar Heim)
Date: Sun, 15 Sep 2013 12:57:29 +0300
Subject: [Engine-devel] fake VDSM as oVirt project?
In-Reply-To: <CAJ3aYLdQoXwYpOZ=uRa8pj5jbzoEzjndb2bJAeB5N76QVtHZ8Q@mail.gmail.com>
References: <1732541231.13807474.1379053254880.JavaMail.root@redhat.com>
	<2124371524.13814658.1379054898078.JavaMail.root@redhat.com>
	<CAJ3aYLdQoXwYpOZ=uRa8pj5jbzoEzjndb2bJAeB5N76QVtHZ8Q@mail.gmail.com>
Message-ID: <52358489.5050208@redhat.com>

On 09/13/2013 09:52 AM, Liran Zelkha wrote:
> +1 I use it constantly.

+1
adding infra, where new git repo's are usually requested.
(we also ask board if a new project scope, but this seems like just a 
repo for a help/test program)

if more +1's and no objections, ping next week to create  repo.

thanks,
    Itamar

>
>
> On Fri, Sep 13, 2013 at 8:48 AM, Tomas Jelinek <tjelinek at redhat.com
> <mailto:tjelinek at redhat.com>> wrote:
>
>     Hi all,
>
>     some time ago Libor Spevak created a simple web app called vdsm fake:
>     documented: http://www.ovirt.org/VDSM_Fake
>     published: https://github.com/lspevak/ovirt-vdsmfake
>
>     It is basically a simple hackable java web application which can
>     emulate the VDSM so you can connect the
>     engine to it. It is especially useful for:
>     - having tons of cheap fake hosts on one machine to stress your engine
>     - doing some experiments with VDSM API (e.g. vfeenstr proposes a new
>     VDSM API to lower the network traffic between
>        engine <-> VDSM and uses the vdsm fake to implement it and do
>     some tests to get some numbers on how does this change the things)
>
>     Omer came up with an idea of making this app as one of oVirt's
>     project (http://www.ovirt.org/Subprojects) maybe with repository on
>     oVirt's gerrit making it more accessible for getting/contributing
>     for the whole community.
>
>     What do you think about it?
>
>     Tomas
>     _______________________________________________
>     Engine-devel mailing list
>     Engine-devel at ovirt.org <mailto:Engine-devel at ovirt.org>
>     http://lists.ovirt.org/mailman/listinfo/engine-devel
>
>
>
>
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>



From mpastern at redhat.com  Sun Sep 15 10:48:51 2013
From: mpastern at redhat.com (Michael Pasternak)
Date: Sun, 15 Sep 2013 13:48:51 +0300
Subject: [Engine-devel] what is the difference between
 origin/ovirt-engine-3.3.0 and origin/ovirt-engine-3.3 branches?
Message-ID: <52359093.9040309@redhat.com>


Thanks.

-- 

Michael Pasternak
RedHat, ENG-Virtualization R&D


From rgolan at redhat.com  Sun Sep 15 10:47:07 2013
From: rgolan at redhat.com (Roy Golan)
Date: Sun, 15 Sep 2013 13:47:07 +0300
Subject: [Engine-devel] fake VDSM as oVirt project?
In-Reply-To: <2124371524.13814658.1379054898078.JavaMail.root@redhat.com>
References: <2124371524.13814658.1379054898078.JavaMail.root@redhat.com>
Message-ID: <5235902B.3040307@redhat.com>

On 09/13/2013 09:48 AM, Tomas Jelinek wrote:
> Hi all,
>
> some time ago Libor Spevak created a simple web app called vdsm fake:
> documented: http://www.ovirt.org/VDSM_Fake
> published: https://github.com/lspevak/ovirt-vdsmfake
>
> It is basically a simple hackable java web application which can emulate the VDSM so you can connect the
> engine to it. It is especially useful for:
> - having tons of cheap fake hosts on one machine to stress your engine
> - doing some experiments with VDSM API (e.g. vfeenstr proposes a new VDSM API to lower the network traffic between
>    engine <-> VDSM and uses the vdsm fake to implement it and do some tests to get some numbers on how does this change the things)
>
> Omer came up with an idea of making this app as one of oVirt's project (http://www.ovirt.org/Subprojects) maybe with repository on
> oVirt's gerrit making it more accessible for getting/contributing for the whole community.
>
> What do you think about it?
>
> Tomas
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
+1



From ahadas at redhat.com  Sun Sep 15 11:02:59 2013
From: ahadas at redhat.com (Arik Hadas)
Date: Sun, 15 Sep 2013 07:02:59 -0400 (EDT)
Subject: [Engine-devel] fake VDSM as oVirt project?
In-Reply-To: <5235902B.3040307@redhat.com>
References: <2124371524.13814658.1379054898078.JavaMail.root@redhat.com>
	<5235902B.3040307@redhat.com>
Message-ID: <1991707523.13585717.1379242979584.JavaMail.root@redhat.com>



----- Original Message -----
> On 09/13/2013 09:48 AM, Tomas Jelinek wrote:
> > Hi all,
> >
> > some time ago Libor Spevak created a simple web app called vdsm fake:
> > documented: http://www.ovirt.org/VDSM_Fake
> > published: https://github.com/lspevak/ovirt-vdsmfake
> >
> > It is basically a simple hackable java web application which can emulate
> > the VDSM so you can connect the
> > engine to it. It is especially useful for:
> > - having tons of cheap fake hosts on one machine to stress your engine
> > - doing some experiments with VDSM API (e.g. vfeenstr proposes a new VDSM
> > API to lower the network traffic between
> >    engine <-> VDSM and uses the vdsm fake to implement it and do some tests
> >    to get some numbers on how does this change the things)
> >
> > Omer came up with an idea of making this app as one of oVirt's project
> > (http://www.ovirt.org/Subprojects) maybe with repository on
> > oVirt's gerrit making it more accessible for getting/contributing for the
> > whole community.
> >
> > What do you think about it?
> >
> > Tomas
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> +1

+1

> 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From danken at redhat.com  Sun Sep 15 11:13:47 2013
From: danken at redhat.com (Dan Kenigsberg)
Date: Sun, 15 Sep 2013 12:13:47 +0100
Subject: [Engine-devel] fake VDSM as oVirt project?
In-Reply-To: <52358489.5050208@redhat.com>
References: <1732541231.13807474.1379053254880.JavaMail.root@redhat.com>
	<2124371524.13814658.1379054898078.JavaMail.root@redhat.com>
	<CAJ3aYLdQoXwYpOZ=uRa8pj5jbzoEzjndb2bJAeB5N76QVtHZ8Q@mail.gmail.com>
	<52358489.5050208@redhat.com>
Message-ID: <20130915111347.GF19210@redhat.com>

On Sun, Sep 15, 2013 at 12:57:29PM +0300, Itamar Heim wrote:
> On 09/13/2013 09:52 AM, Liran Zelkha wrote:
> >+1 I use it constantly.
> 
> +1
> adding infra, where new git repo's are usually requested.
> (we also ask board if a new project scope, but this seems like just
> a repo for a help/test program)
> 
> if more +1's and no objections, ping next week to create  repo.

It would have been much cooler to fix the real vdsm so it can be run in
a crippled mode with no root-related privileges. But I admit it would
require more work, and would miss some of the comforts of a Java-only
stub. So +1 from me.


From ybronhei at redhat.com  Sun Sep 15 17:11:05 2013
From: ybronhei at redhat.com (Yaniv Bronheim)
Date: Sun, 15 Sep 2013 13:11:05 -0400 (EDT)
Subject: [Engine-devel] fake VDSM as oVirt project?
In-Reply-To: <52358489.5050208@redhat.com>
References: <1732541231.13807474.1379053254880.JavaMail.root@redhat.com>
	<2124371524.13814658.1379054898078.JavaMail.root@redhat.com>
	<CAJ3aYLdQoXwYpOZ=uRa8pj5jbzoEzjndb2bJAeB5N76QVtHZ8Q@mail.gmail.com>
	<52358489.5050208@redhat.com>
Message-ID: <876573605.8028286.1379265065900.JavaMail.root@redhat.com>

+1

----- Original Message -----
> From: "Itamar Heim" <iheim at redhat.com>
> To: "Liran Zelkha" <liran.zelkha at gmail.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>, "infra" <infra at ovirt.org>
> Sent: Sunday, September 15, 2013 12:57:29 PM
> Subject: Re: [Engine-devel] fake VDSM as oVirt project?
> 
> On 09/13/2013 09:52 AM, Liran Zelkha wrote:
> > +1 I use it constantly.
> 
> +1
> adding infra, where new git repo's are usually requested.
> (we also ask board if a new project scope, but this seems like just a
> repo for a help/test program)
> 
> if more +1's and no objections, ping next week to create  repo.
> 
> thanks,
>     Itamar
> 
> >
> >
> > On Fri, Sep 13, 2013 at 8:48 AM, Tomas Jelinek <tjelinek at redhat.com
> > <mailto:tjelinek at redhat.com>> wrote:
> >
> >     Hi all,
> >
> >     some time ago Libor Spevak created a simple web app called vdsm fake:
> >     documented: http://www.ovirt.org/VDSM_Fake
> >     published: https://github.com/lspevak/ovirt-vdsmfake
> >
> >     It is basically a simple hackable java web application which can
> >     emulate the VDSM so you can connect the
> >     engine to it. It is especially useful for:
> >     - having tons of cheap fake hosts on one machine to stress your engine
> >     - doing some experiments with VDSM API (e.g. vfeenstr proposes a new
> >     VDSM API to lower the network traffic between
> >        engine <-> VDSM and uses the vdsm fake to implement it and do
> >     some tests to get some numbers on how does this change the things)
> >
> >     Omer came up with an idea of making this app as one of oVirt's
> >     project (http://www.ovirt.org/Subprojects) maybe with repository on
> >     oVirt's gerrit making it more accessible for getting/contributing
> >     for the whole community.
> >
> >     What do you think about it?
> >
> >     Tomas
> >     _______________________________________________
> >     Engine-devel mailing list
> >     Engine-devel at ovirt.org <mailto:Engine-devel at ovirt.org>
> >     http://lists.ovirt.org/mailman/listinfo/engine-devel
> >
> >
> >
> >
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> >
> 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From yzaslavs at redhat.com  Sun Sep 15 19:20:27 2013
From: yzaslavs at redhat.com (Yair Zaslavsky)
Date: Sun, 15 Sep 2013 15:20:27 -0400 (EDT)
Subject: [Engine-devel] fake VDSM as oVirt project?
In-Reply-To: <876573605.8028286.1379265065900.JavaMail.root@redhat.com>
References: <1732541231.13807474.1379053254880.JavaMail.root@redhat.com>
	<2124371524.13814658.1379054898078.JavaMail.root@redhat.com>
	<CAJ3aYLdQoXwYpOZ=uRa8pj5jbzoEzjndb2bJAeB5N76QVtHZ8Q@mail.gmail.com>
	<52358489.5050208@redhat.com>
	<876573605.8028286.1379265065900.JavaMail.root@redhat.com>
Message-ID: <543995523.13162271.1379272827176.JavaMail.root@redhat.com>


+1

----- Original Message -----
> From: "Yaniv Bronheim" <ybronhei at redhat.com>
> To: "Itamar Heim" <iheim at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>, "Liran Zelkha" <liran.zelkha at gmail.com>, "infra" <infra at ovirt.org>
> Sent: Sunday, September 15, 2013 8:11:05 PM
> Subject: Re: [Engine-devel] fake VDSM as oVirt project?
> 
> +1
> 
> ----- Original Message -----
> > From: "Itamar Heim" <iheim at redhat.com>
> > To: "Liran Zelkha" <liran.zelkha at gmail.com>
> > Cc: "engine-devel" <engine-devel at ovirt.org>, "infra" <infra at ovirt.org>
> > Sent: Sunday, September 15, 2013 12:57:29 PM
> > Subject: Re: [Engine-devel] fake VDSM as oVirt project?
> > 
> > On 09/13/2013 09:52 AM, Liran Zelkha wrote:
> > > +1 I use it constantly.
> > 
> > +1
> > adding infra, where new git repo's are usually requested.
> > (we also ask board if a new project scope, but this seems like just a
> > repo for a help/test program)
> > 
> > if more +1's and no objections, ping next week to create  repo.
> > 
> > thanks,
> >     Itamar
> > 
> > >
> > >
> > > On Fri, Sep 13, 2013 at 8:48 AM, Tomas Jelinek <tjelinek at redhat.com
> > > <mailto:tjelinek at redhat.com>> wrote:
> > >
> > >     Hi all,
> > >
> > >     some time ago Libor Spevak created a simple web app called vdsm fake:
> > >     documented: http://www.ovirt.org/VDSM_Fake
> > >     published: https://github.com/lspevak/ovirt-vdsmfake
> > >
> > >     It is basically a simple hackable java web application which can
> > >     emulate the VDSM so you can connect the
> > >     engine to it. It is especially useful for:
> > >     - having tons of cheap fake hosts on one machine to stress your
> > >     engine
> > >     - doing some experiments with VDSM API (e.g. vfeenstr proposes a new
> > >     VDSM API to lower the network traffic between
> > >        engine <-> VDSM and uses the vdsm fake to implement it and do
> > >     some tests to get some numbers on how does this change the things)
> > >
> > >     Omer came up with an idea of making this app as one of oVirt's
> > >     project (http://www.ovirt.org/Subprojects) maybe with repository on
> > >     oVirt's gerrit making it more accessible for getting/contributing
> > >     for the whole community.
> > >
> > >     What do you think about it?
> > >
> > >     Tomas
> > >     _______________________________________________
> > >     Engine-devel mailing list
> > >     Engine-devel at ovirt.org <mailto:Engine-devel at ovirt.org>
> > >     http://lists.ovirt.org/mailman/listinfo/engine-devel
> > >
> > >
> > >
> > >
> > > _______________________________________________
> > > Engine-devel mailing list
> > > Engine-devel at ovirt.org
> > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > >
> > 
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > 
> _______________________________________________
> Infra mailing list
> Infra at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/infra
> 


From wlbleaboy at 126.com  Mon Sep 16 02:45:39 2013
From: wlbleaboy at 126.com (leaboy wang)
Date: Mon, 16 Sep 2013 10:45:39 +0800
Subject: [Engine-devel] ovirt3.3,all in one, network configuration
Message-ID: <CE5C91D2.B1D%wlbleaboy@126.com>

Hi,all:
    I got ovirt3.3 from
yum localinstall 
http://resources.ovirt.org/releases/ovirt-release-el6-8-1.noarch.rpm -y
yum localinstall 
http://dl.fedoraproject.org/pub/epel/6/x86_64/epel-release-6-8.noarch.rpm ?y
    And when I run engine-setup in NETWORK CONFIGURATION step, I got this
error:

[ ERROR ] Host name is not valid: The following addresses: 192.168.1.207 did
not reverseresolve into leaboy.test.com
          Host fully qualified DNS name of this server [leaboy.test.com]:

    Is anyone got this error, and how could I resolve it.

Thanks,Leaboy.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20130916/1d7e40f7/attachment.html>

From alonbl at redhat.com  Mon Sep 16 06:22:36 2013
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Mon, 16 Sep 2013 02:22:36 -0400 (EDT)
Subject: [Engine-devel] ovirt3.3,all in one, network configuration
In-Reply-To: <CE5C91D2.B1D%wlbleaboy@126.com>
References: <CE5C91D2.B1D%wlbleaboy@126.com>
Message-ID: <1792102649.8098875.1379312556075.JavaMail.root@redhat.com>



----- Original Message -----
> From: "leaboy wang" <wlbleaboy at 126.com>
> To: engine-devel at ovirt.org
> Sent: Monday, September 16, 2013 5:45:39 AM
> Subject: [Engine-devel] ovirt3.3,all in one, network configuration
> 
> Hi,all:
> I got ovirt3.3 from
> yum localinstall
> http://resources.ovirt.org/releases/ovirt-release-el6-8-1.noarch.rpm -y
> yum localinstall
> http://dl.fedoraproject.org/pub/epel/6/x86_64/epel-release-6-8.noarch.rpm ?y
> And when I run engine-setup in NETWORK CONFIGURATION step, I got this error:
> 
> [ ERROR ] Host name is not valid: The following addresses: 192.168.1.207 did
> not reverseresolve into leaboy.test.com
> Host fully qualified DNS name of this server [leaboy.test.com]:
> 
> Is anyone got this error, and how could I resolve it.

In case of all-in-one you should have proper reverse dns setup into the host name.

Alon


From liran.zelkha at gmail.com  Mon Sep 16 06:25:15 2013
From: liran.zelkha at gmail.com (Liran Zelkha)
Date: Mon, 16 Sep 2013 08:25:15 +0200
Subject: [Engine-devel] ovirt3.3,all in one, network configuration
In-Reply-To: <1792102649.8098875.1379312556075.JavaMail.root@redhat.com>
References: <CE5C91D2.B1D%wlbleaboy@126.com>
	<1792102649.8098875.1379312556075.JavaMail.root@redhat.com>
Message-ID: <CAJ3aYLfkNSwZZ28u6dogmMghYsng--61ECNfPL=02vLekQGPJg@mail.gmail.com>

See here for more info http://www.ovirt.org/Troubleshooting#Installation


On Mon, Sep 16, 2013 at 8:22 AM, Alon Bar-Lev <alonbl at redhat.com> wrote:

>
>
> ----- Original Message -----
> > From: "leaboy wang" <wlbleaboy at 126.com>
> > To: engine-devel at ovirt.org
> > Sent: Monday, September 16, 2013 5:45:39 AM
> > Subject: [Engine-devel] ovirt3.3,all in one, network configuration
> >
> > Hi,all:
> > I got ovirt3.3 from
> > yum localinstall
> > http://resources.ovirt.org/releases/ovirt-release-el6-8-1.noarch.rpm -y
> > yum localinstall
> >
> http://dl.fedoraproject.org/pub/epel/6/x86_64/epel-release-6-8.noarch.rpm?y
> > And when I run engine-setup in NETWORK CONFIGURATION step, I got this
> error:
> >
> > [ ERROR ] Host name is not valid: The following addresses: 192.168.1.207
> did
> > not reverseresolve into leaboy.test.com
> > Host fully qualified DNS name of this server [leaboy.test.com]:
> >
> > Is anyone got this error, and how could I resolve it.
>
> In case of all-in-one you should have proper reverse dns setup into the
> host name.
>
> Alon
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20130916/94505608/attachment.html>

From wlbleaboy at 126.com  Mon Sep 16 07:07:53 2013
From: wlbleaboy at 126.com (wlbleaboy@126)
Date: Mon, 16 Sep 2013 15:07:53 +0800
Subject: [Engine-devel] ovirt3.3,all in one, network configuration
In-Reply-To: <CAJ3aYLfkNSwZZ28u6dogmMghYsng--61ECNfPL=02vLekQGPJg@mail.gmail.com>
References: <CE5C91D2.B1D%wlbleaboy@126.com>	<1792102649.8098875.1379312556075.JavaMail.root@redhat.com>
	<CAJ3aYLfkNSwZZ28u6dogmMghYsng--61ECNfPL=02vLekQGPJg@mail.gmail.com>
Message-ID: <006101ceb2ab$776a73e0$663f5ba0$@com>

Hi, Alon:

         Could I set the DNS with all-in-one in the same Centos?

 

From: Liran Zelkha [mailto:liran.zelkha at gmail.com] 
Sent: Monday, September 16, 2013 2:25 PM
To: Alon Bar-Lev
Cc: leaboy wang; engine-devel
Subject: Re: [Engine-devel] ovirt3.3,all in one, network configuration

 

See here for more info http://www.ovirt.org/Troubleshooting#Installation

 

On Mon, Sep 16, 2013 at 8:22 AM, Alon Bar-Lev <alonbl at redhat.com> wrote:



----- Original Message -----
> From: "leaboy wang" <wlbleaboy at 126.com>
> To: engine-devel at ovirt.org
> Sent: Monday, September 16, 2013 5:45:39 AM
> Subject: [Engine-devel] ovirt3.3,all in one, network configuration
>
> Hi,all:
> I got ovirt3.3 from
> yum localinstall
> http://resources.ovirt.org/releases/ovirt-release-el6-8-1.noarch.rpm -y
> yum localinstall
> http://dl.fedoraproject.org/pub/epel/6/x86_64/epel-release-6-8.noarch.rpm
?Cy
> And when I run engine-setup in NETWORK CONFIGURATION step, I got this
error:
>
> [ ERROR ] Host name is not valid: The following addresses: 192.168.1.207
did
> not reverseresolve into leaboy.test.com
> Host fully qualified DNS name of this server [leaboy.test.com]:
>
> Is anyone got this error, and how could I resolve it.

In case of all-in-one you should have proper reverse dns setup into the host
name.

Alon
_______________________________________________
Engine-devel mailing list
Engine-devel at ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20130916/25ba101d/attachment.html>

From alonbl at redhat.com  Mon Sep 16 07:09:40 2013
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Mon, 16 Sep 2013 03:09:40 -0400 (EDT)
Subject: [Engine-devel] ovirt3.3,all in one, network configuration
In-Reply-To: <006101ceb2ab$776a73e0$663f5ba0$@com>
References: <CE5C91D2.B1D%wlbleaboy@126.com>
	<1792102649.8098875.1379312556075.JavaMail.root@redhat.com>
	<CAJ3aYLfkNSwZZ28u6dogmMghYsng--61ECNfPL=02vLekQGPJg@mail.gmail.com>
	<006101ceb2ab$776a73e0$663f5ba0$@com>
Message-ID: <770037176.8112367.1379315380514.JavaMail.root@redhat.com>



----- Original Message -----
> From: "wlbleaboy at 126" <wlbleaboy at 126.com>
> To: "Liran Zelkha" <liran.zelkha at gmail.com>, "Alon Bar-Lev" <alonbl at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>
> Sent: Monday, September 16, 2013 10:07:53 AM
> Subject: RE: [Engine-devel] ovirt3.3,all in one, network configuration
> 
> Hi, Alon:
> 
>          Could I set the DNS with all-in-one in the same Centos?

if set == install, then yes.

>  
> 
> From: Liran Zelkha [mailto:liran.zelkha at gmail.com]
> Sent: Monday, September 16, 2013 2:25 PM
> To: Alon Bar-Lev
> Cc: leaboy wang; engine-devel
> Subject: Re: [Engine-devel] ovirt3.3,all in one, network configuration
> 
>  
> 
> See here for more info http://www.ovirt.org/Troubleshooting#Installation
> 
>  
> 
> On Mon, Sep 16, 2013 at 8:22 AM, Alon Bar-Lev <alonbl at redhat.com> wrote:
> 
> 
> 
> ----- Original Message -----
> > From: "leaboy wang" <wlbleaboy at 126.com>
> > To: engine-devel at ovirt.org
> > Sent: Monday, September 16, 2013 5:45:39 AM
> > Subject: [Engine-devel] ovirt3.3,all in one, network configuration
> >
> > Hi,all:
> > I got ovirt3.3 from
> > yum localinstall
> > http://resources.ovirt.org/releases/ovirt-release-el6-8-1.noarch.rpm -y
> > yum localinstall
> > http://dl.fedoraproject.org/pub/epel/6/x86_64/epel-release-6-8.noarch.rpm
> ?y
> > And when I run engine-setup in NETWORK CONFIGURATION step, I got this
> error:
> >
> > [ ERROR ] Host name is not valid: The following addresses: 192.168.1.207
> did
> > not reverseresolve into leaboy.test.com
> > Host fully qualified DNS name of this server [leaboy.test.com]:
> >
> > Is anyone got this error, and how could I resolve it.
> 
> In case of all-in-one you should have proper reverse dns setup into the host
> name.
> 
> Alon
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 
>  
> 
> 


From wlbleaboy at 126.com  Mon Sep 16 07:19:34 2013
From: wlbleaboy at 126.com (wlbleaboy@126)
Date: Mon, 16 Sep 2013 15:19:34 +0800
Subject: [Engine-devel] ovirt3.3,all in one, network configuration
In-Reply-To: <770037176.8112367.1379315380514.JavaMail.root@redhat.com>
References: <CE5C91D2.B1D%wlbleaboy@126.com>
	<1792102649.8098875.1379312556075.JavaMail.root@redhat.com>
	<CAJ3aYLfkNSwZZ28u6dogmMghYsng--61ECNfPL=02vLekQGPJg@mail.gmail.com>
	<006101ceb2ab$776a73e0$663f5ba0$@com>
	<770037176.8112367.1379315380514.JavaMail.root@redhat.com>
Message-ID: <006901ceb2ad$195859f0$4c090dd0$@com>

Is there any explicit instruction for install all-in-one step-by-step,
I just don't know how to install a DNS and LDAP server in local,with 
All-in-one.

					Thanks.^_^

-----Original Message-----
From: abarlev at redhat.com [mailto:abarlev at redhat.com] On Behalf Of Alon Bar-Lev
Sent: Monday, September 16, 2013 3:10 PM
To: wlbleaboy at 126
Cc: Liran Zelkha; engine-devel
Subject: Re: [Engine-devel] ovirt3.3,all in one, network configuration



----- Original Message -----
> From: "wlbleaboy at 126" <wlbleaboy at 126.com>
> To: "Liran Zelkha" <liran.zelkha at gmail.com>, "Alon Bar-Lev" <alonbl at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>
> Sent: Monday, September 16, 2013 10:07:53 AM
> Subject: RE: [Engine-devel] ovirt3.3,all in one, network configuration
> 
> Hi, Alon:
> 
>          Could I set the DNS with all-in-one in the same Centos?

if set == install, then yes.

>  
> 
> From: Liran Zelkha [mailto:liran.zelkha at gmail.com]
> Sent: Monday, September 16, 2013 2:25 PM
> To: Alon Bar-Lev
> Cc: leaboy wang; engine-devel
> Subject: Re: [Engine-devel] ovirt3.3,all in one, network configuration
> 
>  
> 
> See here for more info http://www.ovirt.org/Troubleshooting#Installation
> 
>  
> 
> On Mon, Sep 16, 2013 at 8:22 AM, Alon Bar-Lev <alonbl at redhat.com> wrote:
> 
> 
> 
> ----- Original Message -----
> > From: "leaboy wang" <wlbleaboy at 126.com>
> > To: engine-devel at ovirt.org
> > Sent: Monday, September 16, 2013 5:45:39 AM
> > Subject: [Engine-devel] ovirt3.3,all in one, network configuration
> >
> > Hi,all:
> > I got ovirt3.3 from
> > yum localinstall
> > http://resources.ovirt.org/releases/ovirt-release-el6-8-1.noarch.rpm -y
> > yum localinstall
> > http://dl.fedoraproject.org/pub/epel/6/x86_64/epel-release-6-8.noarch.rpm
> ?y
> > And when I run engine-setup in NETWORK CONFIGURATION step, I got this
> error:
> >
> > [ ERROR ] Host name is not valid: The following addresses: 192.168.1.207
> did
> > not reverseresolve into leaboy.test.com
> > Host fully qualified DNS name of this server [leaboy.test.com]:
> >
> > Is anyone got this error, and how could I resolve it.
> 
> In case of all-in-one you should have proper reverse dns setup into the host
> name.
> 
> Alon
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 
>  
> 
> 




From oschreib at redhat.com  Mon Sep 16 07:50:16 2013
From: oschreib at redhat.com (Ofer Schreiber)
Date: Mon, 16 Sep 2013 03:50:16 -0400 (EDT)
Subject: [Engine-devel] what is the difference between
 origin/ovirt-engine-3.3.0 and origin/ovirt-engine-3.3 branches?
In-Reply-To: <52359093.9040309@redhat.com>
References: <52359093.9040309@redhat.com>
Message-ID: <1866520148.14858810.1379317816126.JavaMail.root@redhat.com>

ovirt-engine-3.3 is the "next" 3.3 branch (e.g. 3.3.1)
ovirt-engine.3.3.0 is the 3.3.0 branch (GA is today)

----- Original Message -----
> 
> Thanks.
> 
> --
> 
> Michael Pasternak
> RedHat, ENG-Virtualization R&D
> 


From didi at redhat.com  Tue Sep 17 08:30:41 2013
From: didi at redhat.com (Yedidyah Bar David)
Date: Tue, 17 Sep 2013 04:30:41 -0400 (EDT)
Subject: [Engine-devel] ovirt3.3,all in one, network configuration
In-Reply-To: <006901ceb2ad$195859f0$4c090dd0$@com>
References: <CE5C91D2.B1D%wlbleaboy@126.com>
	<1792102649.8098875.1379312556075.JavaMail.root@redhat.com>
	<CAJ3aYLfkNSwZZ28u6dogmMghYsng--61ECNfPL=02vLekQGPJg@mail.gmail.com>
	<006101ceb2ab$776a73e0$663f5ba0$@com>
	<770037176.8112367.1379315380514.JavaMail.root@redhat.com>
	<006901ceb2ad$195859f0$4c090dd0$@com>
Message-ID: <382637996.15507456.1379406641215.JavaMail.root@redhat.com>

Hi,

----- Original Message -----
> From: "wlbleaboy at 126" <wlbleaboy at 126.com>
> To: "Alon Bar-Lev" <alonbl at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>
> Sent: Monday, September 16, 2013 10:19:34 AM
> Subject: Re: [Engine-devel] ovirt3.3,all in one, network configuration
> 
> Is there any explicit instruction for install all-in-one step-by-step,
> I just don't know how to install a DNS and LDAP server in local,with
> All-in-one.

You can try to simply add a line to /etc/hosts, if you do not really
need DNS, and use the internal 'admin' if you do not need LDAP.

If you do need DNS/LDAP, it's up to you setup - ovirt-engine can use them,
but will not setup/manage them.
-- 
Didi


From obasan at redhat.com  Tue Sep 17 08:36:58 2013
From: obasan at redhat.com (Ohad Basan)
Date: Tue, 17 Sep 2013 04:36:58 -0400 (EDT)
Subject: [Engine-devel] We've been mentioned in phoronix
In-Reply-To: <1728448368.22778371.1379406988079.JavaMail.root@redhat.com>
Message-ID: <663360985.22778579.1379407018221.JavaMail.root@redhat.com>

Hello,

One of the biggest open source sites wrote an article about oVirt 3.3 release.

http://www.phoronix.com/scan.php?page=news_item&px=MTQ2MzQ

Thanks,

Ohad


From jhernand at redhat.com  Mon Sep 16 10:22:53 2013
From: jhernand at redhat.com (Juan Hernandez)
Date: Mon, 16 Sep 2013 12:22:53 +0200
Subject: [Engine-devel] A maven question
In-Reply-To: <268438611.12959358.1378976074811.JavaMail.root@redhat.com>
References: <268438611.12959358.1378976074811.JavaMail.root@redhat.com>
Message-ID: <5236DBFD.6070905@redhat.com>

On 09/12/2013 10:54 AM, Mooli Tayer wrote:
> (Moving here from a patch disscission)
> 
> in our main aggregator pom.xml we use properties to manage dependencies
> 
> Why do we use those vars and not put the version in the dependencyManagement tag in our aggregator pom and in a project's pom declare dependencies without the version (gets weirder when we have a var we use only in a dependencyManagement tag - why use the var?)
> as I currently understand our container we cannot use different versions of a dependency (although it is possible in jboss) - is that true?

In my opinion it is better to avoid those properties and use the
dependencyManagement section, as you suggest.

We can use different versions of a dependency, this is one of the
benefits of using JBoss modules. However we didn't have that need yet.

-- 
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.


From mobixsw at gmail.com  Wed Sep 18 15:27:38 2013
From: mobixsw at gmail.com (=?GB2312?B?wOi+sg==?=)
Date: Wed, 18 Sep 2013 23:27:38 +0800
Subject: [Engine-devel] Which styles it actually makes sense to externalize
	for branding mechanism
Message-ID: <CANv4pCgGnseJ2ox5wpDMGfzu=SzDN_Tcmus3no4vYft3ota=Cw@mail.gmail.com>

Hi!

I am about to do some work about branding mechanism. Currently, the styles
which being externalized  are about general theme colors or top banner
image. But I can't find out any more bout that ,can I expose some other
styles, anybody can give me some advice? Thanks.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20130918/425c6dc5/attachment.html>

From Christopher.Morrissey at netapp.com  Wed Sep 18 21:50:38 2013
From: Christopher.Morrissey at netapp.com (Morrissey, Christopher)
Date: Wed, 18 Sep 2013 21:50:38 +0000
Subject: [Engine-devel] External events and flood rate
Message-ID: <D290AD8432118048947689BA3AE8A9B33C9B351C@SACEXCMBX04-PRD.hq.netapp.com>

Hi All,

I've been working on submitting external events to oVirt through the REST API. It seems to be working in general, although it appears that, no matter what value I put for the flood rate in the event, only 1 or so events are allowed every 30 seconds. If I send another event during this time, I get an operation failed exception. Should the flood rate have any impact on this? Is there any way to allow my code to get an event through when needed or should I have a thread that shoots them off every 30 seconds if several occur too quickly together?

-Chris

Chris Morrissey
Software Engineer
NetApp Inc.
919.476.4428

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20130918/cbc79bbe/attachment.html>

From tjelinek at redhat.com  Thu Sep 19 06:25:11 2013
From: tjelinek at redhat.com (Tomas Jelinek)
Date: Thu, 19 Sep 2013 02:25:11 -0400 (EDT)
Subject: [Engine-devel] fake VDSM as oVirt project?
In-Reply-To: <543995523.13162271.1379272827176.JavaMail.root@redhat.com>
References: <1732541231.13807474.1379053254880.JavaMail.root@redhat.com>
	<2124371524.13814658.1379054898078.JavaMail.root@redhat.com>
	<CAJ3aYLdQoXwYpOZ=uRa8pj5jbzoEzjndb2bJAeB5N76QVtHZ8Q@mail.gmail.com>
	<52358489.5050208@redhat.com>
	<876573605.8028286.1379265065900.JavaMail.root@redhat.com>
	<543995523.13162271.1379272827176.JavaMail.root@redhat.com>
Message-ID: <2049314305.16902019.1379571911411.JavaMail.root@redhat.com>

Thank all of you for the +1s!

The Fake VDSM has been made an oVirt subproject:

git: http://gerrit.ovirt.org/gitweb?p=ovirt-vdsmfake.git
subprojects: http://www.ovirt.org/Subprojects
wiki: http://www.ovirt.org/VDSM_Fake#Project

Tomas

----- Original Message -----
> From: "Yair Zaslavsky" <yzaslavs at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>, "infra" <infra at ovirt.org>
> Sent: Sunday, September 15, 2013 9:20:27 PM
> Subject: Re: [Engine-devel] fake VDSM as oVirt project?
> 
> 
> +1
> 
> ----- Original Message -----
> > From: "Yaniv Bronheim" <ybronhei at redhat.com>
> > To: "Itamar Heim" <iheim at redhat.com>
> > Cc: "engine-devel" <engine-devel at ovirt.org>, "Liran Zelkha"
> > <liran.zelkha at gmail.com>, "infra" <infra at ovirt.org>
> > Sent: Sunday, September 15, 2013 8:11:05 PM
> > Subject: Re: [Engine-devel] fake VDSM as oVirt project?
> > 
> > +1
> > 
> > ----- Original Message -----
> > > From: "Itamar Heim" <iheim at redhat.com>
> > > To: "Liran Zelkha" <liran.zelkha at gmail.com>
> > > Cc: "engine-devel" <engine-devel at ovirt.org>, "infra" <infra at ovirt.org>
> > > Sent: Sunday, September 15, 2013 12:57:29 PM
> > > Subject: Re: [Engine-devel] fake VDSM as oVirt project?
> > > 
> > > On 09/13/2013 09:52 AM, Liran Zelkha wrote:
> > > > +1 I use it constantly.
> > > 
> > > +1
> > > adding infra, where new git repo's are usually requested.
> > > (we also ask board if a new project scope, but this seems like just a
> > > repo for a help/test program)
> > > 
> > > if more +1's and no objections, ping next week to create  repo.
> > > 
> > > thanks,
> > >     Itamar
> > > 
> > > >
> > > >
> > > > On Fri, Sep 13, 2013 at 8:48 AM, Tomas Jelinek <tjelinek at redhat.com
> > > > <mailto:tjelinek at redhat.com>> wrote:
> > > >
> > > >     Hi all,
> > > >
> > > >     some time ago Libor Spevak created a simple web app called vdsm
> > > >     fake:
> > > >     documented: http://www.ovirt.org/VDSM_Fake
> > > >     published: https://github.com/lspevak/ovirt-vdsmfake
> > > >
> > > >     It is basically a simple hackable java web application which can
> > > >     emulate the VDSM so you can connect the
> > > >     engine to it. It is especially useful for:
> > > >     - having tons of cheap fake hosts on one machine to stress your
> > > >     engine
> > > >     - doing some experiments with VDSM API (e.g. vfeenstr proposes a
> > > >     new
> > > >     VDSM API to lower the network traffic between
> > > >        engine <-> VDSM and uses the vdsm fake to implement it and do
> > > >     some tests to get some numbers on how does this change the things)
> > > >
> > > >     Omer came up with an idea of making this app as one of oVirt's
> > > >     project (http://www.ovirt.org/Subprojects) maybe with repository on
> > > >     oVirt's gerrit making it more accessible for getting/contributing
> > > >     for the whole community.
> > > >
> > > >     What do you think about it?
> > > >
> > > >     Tomas
> > > >     _______________________________________________
> > > >     Engine-devel mailing list
> > > >     Engine-devel at ovirt.org <mailto:Engine-devel at ovirt.org>
> > > >     http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > >
> > > >
> > > >
> > > >
> > > > _______________________________________________
> > > > Engine-devel mailing list
> > > > Engine-devel at ovirt.org
> > > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > >
> > > 
> > > _______________________________________________
> > > Engine-devel mailing list
> > > Engine-devel at ovirt.org
> > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > 
> > _______________________________________________
> > Infra mailing list
> > Infra at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/infra
> > 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From deadhorseconsulting at gmail.com  Fri Sep 20 19:15:55 2013
From: deadhorseconsulting at gmail.com (Dead Horse)
Date: Fri, 20 Sep 2013 14:15:55 -0500
Subject: [Engine-devel] disk quota broken in latest master
Message-ID: <CAEWPe=qQH=rzNXdo=aU-urayOtvW=Ja6M0B_t57MAVnGi73FYA@mail.gmail.com>

When attempting to add a disk from either the admin or power user portals
the according disk quota associated with the requested storage domain
cannot be assigned to the disk. The disk quota pull-down only will only
display whatever quota is first in the list alphabetically.
- DHC

engine and vdsm logs attached.

2013-09-20 13:56:36,810 INFO  [org.ovirt.engine.core.bll.
LoginUserCommand] (ajp--127.0.0.1-8702-4) Running command: LoginUserCommand
internal: false.
2013-09-20 13:56:36,833 INFO
[org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
(ajp--127.0.0.1-8702-4) Correlation ID: null, Call Stack: null, Custom
Event ID: -1, Message: User admin at internal logged in.
2013-09-20 13:56:45,775 ERROR
[org.ovirt.engine.core.utils.servlet.ServletUtils] (ajp--127.0.0.1-8702-6)
Can't read file "/usr/share/doc/ovirt-engine/manual/DocumentationPath.csv"
for request "/docs/DocumentationPath.csv", will send a 404 error response.
2013-09-20 13:57:00,456 INFO
[org.ovirt.engine.core.bll.quota.QuotaManager]
(DefaultQuartzScheduler_Worker-72) Quota Cache updated. (26 msec)
2013-09-20 13:57:01,810 INFO  [org.ovirt.engine.core.bll.AddDiskCommand]
(ajp--127.0.0.1-8702-10) Lock Acquired to object EngineLock
[exclusiveLocks= key: ca3cecf1-090e-469a-aaad-e26ce47f89d8 value:
VM_DISK_BOOT
, sharedLocks= key: ca3cecf1-090e-469a-aaad-e26ce47f89d8 value: VM
]
2013-09-20 13:57:01,863 ERROR
[org.ovirt.engine.core.bll.quota.QuotaManager] (ajp--127.0.0.1-8702-10)
Quota storage parameters from command:
org.ovirt.engine.core.bll.AddDiskCommand. Storage domain does not match
quota
2013-09-20 13:57:01,901 INFO
[org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
(ajp--127.0.0.1-8702-10) Correlation ID: 5790e811, Job ID:
7abd0b95-4cd4-4cb5-864c-d51c4446a42d, Call Stack: null, Custom Event ID:
-1, Message: Missing Quota for Disk, proceeding since in Permissive (Audit)
mode.
2013-09-20 13:57:01,937 INFO  [org.ovirt.engine.core.bll.AddDiskCommand]
(ajp--127.0.0.1-8702-10) Running command: AddDiskCommand internal: false.
Entities affected :  ID: ca3cecf1-090e-469a-aaad-e26ce47f89d8 Type: VM,
ID: 26be0640-01a3-415d-82c9-0a92f2f84c3f Type: Storage
2013-09-20 13:57:02,325 INFO
[org.ovirt.engine.core.bll.AddImageFromScratchCommand]
(ajp--127.0.0.1-8702-10) Running command: AddImageFromScratchCommand
internal: true. Entities affected :  ID:
26be0640-01a3-415d-82c9-0a92f2f84c3f Type: Storage
2013-09-20 13:57:02,446 INFO
[org.ovirt.engine.core.bll.AddImageFromScratchCommand]
(ajp--127.0.0.1-8702-10) Lock freed to object EngineLock [exclusiveLocks=
key: ca3cecf1-090e-469a-aaad-e26ce47f89d8 value: VM_DISK_BOOT
, sharedLocks= key: ca3cecf1-090e-469a-aaad-e26ce47f89d8 value: VM
]
2013-09-20 13:57:02,451 INFO
[org.ovirt.engine.core.vdsbroker.irsbroker.CreateImageVDSCommand]
(ajp--127.0.0.1-8702-10) START, CreateImageVDSCommand( storagePoolId =
5849b030-626e-47cb-ad90-3ce782d831b3, ignoreFailoverLimit = false,
storageDomainId = 26be0640-01a3-415d-82c9-0a92f2f84c3f, imageGroupId =
bf6458bc-627a-4399-822d-f72751edf303, imageSizeInBytes = 1073741824,
volumeFormat = RAW, newImageId = 165089b7-4737-4900-9a7f-d2d888ec3514,
newImageDescription = ), log id: 1ef8212d
2013-09-20 13:57:02,454 INFO
[org.ovirt.engine.core.vdsbroker.irsbroker.CreateImageVDSCommand]
(ajp--127.0.0.1-8702-10) -- executeIrsBrokerCommand: calling 'createVolume'
with two new parameters: description and UUID
2013-09-20 13:57:02,456 INFO
[org.ovirt.engine.core.vdsbroker.irsbroker.CreateImageVDSCommand]
(ajp--127.0.0.1-8702-10) -- createVolume parameters:

                sdUUID=26be0640-01a3-415d-82c9-0a92f2f84c3f

                spUUID=5849b030-626e-47cb-ad90-3ce782d831b3

                imgGUID=bf6458bc-627a-4399-822d-f72751edf303

                size=1,073,741,824 bytes

                volFormat=RAW

                volType=Sparse

                volUUID=165089b7-4737-4900-9a7f-d2d888ec3514

                descr=

                srcImgGUID=00000000-0000-0000-0000-000000000000

                srcVolUUID=00000000-0000-0000-0000-000000000000


2013-09-20 13:57:02,489 INFO
[org.ovirt.engine.core.vdsbroker.irsbroker.CreateImageVDSCommand]
(ajp--127.0.0.1-8702-10) FINISH, CreateImageVDSCommand, return:
165089b7-4737-4900-9a7f-d2d888ec3514, log id: 1ef8212d
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20130920/7ba205a8/attachment.html>

From deadhorseconsulting at gmail.com  Fri Sep 20 19:24:58 2013
From: deadhorseconsulting at gmail.com (Dead Horse)
Date: Fri, 20 Sep 2013 14:24:58 -0500
Subject: [Engine-devel] disk quota broken in latest master
In-Reply-To: <CAEWPe=qQH=rzNXdo=aU-urayOtvW=Ja6M0B_t57MAVnGi73FYA@mail.gmail.com>
References: <CAEWPe=qQH=rzNXdo=aU-urayOtvW=Ja6M0B_t57MAVnGi73FYA@mail.gmail.com>
Message-ID: <CAEWPe=rnx2xTwBtLtWy+yOW25OARN4ApN_aYxntOst-ETnMq5g@mail.gmail.com>

really attach the logs

I also notice that disks tab is no longer showing a disk inventory as well.

 - DHC


On Fri, Sep 20, 2013 at 2:15 PM, Dead Horse
<deadhorseconsulting at gmail.com>wrote:

> When attempting to add a disk from either the admin or power user portals
> the according disk quota associated with the requested storage domain
> cannot be assigned to the disk. The disk quota pull-down only will only
> display whatever quota is first in the list alphabetically.
> - DHC
>
> engine and vdsm logs attached.
>
> 2013-09-20 13:56:36,810 INFO  [org.ovirt.engine.core.bll.
> LoginUserCommand] (ajp--127.0.0.1-8702-4) Running command:
> LoginUserCommand internal: false.
> 2013-09-20 13:56:36,833 INFO
> [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
> (ajp--127.0.0.1-8702-4) Correlation ID: null, Call Stack: null, Custom
> Event ID: -1, Message: User admin at internal logged in.
> 2013-09-20 13:56:45,775 ERROR
> [org.ovirt.engine.core.utils.servlet.ServletUtils] (ajp--127.0.0.1-8702-6)
> Can't read file "/usr/share/doc/ovirt-engine/manual/DocumentationPath.csv"
> for request "/docs/DocumentationPath.csv", will send a 404 error response.
> 2013-09-20 13:57:00,456 INFO
> [org.ovirt.engine.core.bll.quota.QuotaManager]
> (DefaultQuartzScheduler_Worker-72) Quota Cache updated. (26 msec)
> 2013-09-20 13:57:01,810 INFO  [org.ovirt.engine.core.bll.AddDiskCommand]
> (ajp--127.0.0.1-8702-10) Lock Acquired to object EngineLock
> [exclusiveLocks= key: ca3cecf1-090e-469a-aaad-e26ce47f89d8 value:
> VM_DISK_BOOT
> , sharedLocks= key: ca3cecf1-090e-469a-aaad-e26ce47f89d8 value: VM
> ]
> 2013-09-20 13:57:01,863 ERROR
> [org.ovirt.engine.core.bll.quota.QuotaManager] (ajp--127.0.0.1-8702-10)
> Quota storage parameters from command:
> org.ovirt.engine.core.bll.AddDiskCommand. Storage domain does not match
> quota
> 2013-09-20 13:57:01,901 INFO
> [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
> (ajp--127.0.0.1-8702-10) Correlation ID: 5790e811, Job ID:
> 7abd0b95-4cd4-4cb5-864c-d51c4446a42d, Call Stack: null, Custom Event ID:
> -1, Message: Missing Quota for Disk, proceeding since in Permissive (Audit)
> mode.
> 2013-09-20 13:57:01,937 INFO  [org.ovirt.engine.core.bll.AddDiskCommand]
> (ajp--127.0.0.1-8702-10) Running command: AddDiskCommand internal: false.
> Entities affected :  ID: ca3cecf1-090e-469a-aaad-e26ce47f89d8 Type: VM,
> ID: 26be0640-01a3-415d-82c9-0a92f2f84c3f Type: Storage
> 2013-09-20 13:57:02,325 INFO
> [org.ovirt.engine.core.bll.AddImageFromScratchCommand]
> (ajp--127.0.0.1-8702-10) Running command: AddImageFromScratchCommand
> internal: true. Entities affected :  ID:
> 26be0640-01a3-415d-82c9-0a92f2f84c3f Type: Storage
> 2013-09-20 13:57:02,446 INFO
> [org.ovirt.engine.core.bll.AddImageFromScratchCommand]
> (ajp--127.0.0.1-8702-10) Lock freed to object EngineLock [exclusiveLocks=
> key: ca3cecf1-090e-469a-aaad-e26ce47f89d8 value: VM_DISK_BOOT
> , sharedLocks= key: ca3cecf1-090e-469a-aaad-e26ce47f89d8 value: VM
> ]
> 2013-09-20 13:57:02,451 INFO
> [org.ovirt.engine.core.vdsbroker.irsbroker.CreateImageVDSCommand]
> (ajp--127.0.0.1-8702-10) START, CreateImageVDSCommand( storagePoolId =
> 5849b030-626e-47cb-ad90-3ce782d831b3, ignoreFailoverLimit = false,
> storageDomainId = 26be0640-01a3-415d-82c9-0a92f2f84c3f, imageGroupId =
> bf6458bc-627a-4399-822d-f72751edf303, imageSizeInBytes = 1073741824,
> volumeFormat = RAW, newImageId = 165089b7-4737-4900-9a7f-d2d888ec3514,
> newImageDescription = ), log id: 1ef8212d
> 2013-09-20 13:57:02,454 INFO
> [org.ovirt.engine.core.vdsbroker.irsbroker.CreateImageVDSCommand]
> (ajp--127.0.0.1-8702-10) -- executeIrsBrokerCommand: calling 'createVolume'
> with two new parameters: description and UUID
> 2013-09-20 13:57:02,456 INFO
> [org.ovirt.engine.core.vdsbroker.irsbroker.CreateImageVDSCommand]
> (ajp--127.0.0.1-8702-10) -- createVolume parameters:
>
>                 sdUUID=26be0640-01a3-415d-82c9-0a92f2f84c3f
>
>                 spUUID=5849b030-626e-47cb-ad90-3ce782d831b3
>
>                 imgGUID=bf6458bc-627a-4399-822d-f72751edf303
>
>                 size=1,073,741,824 bytes
>
>                 volFormat=RAW
>
>                 volType=Sparse
>
>                 volUUID=165089b7-4737-4900-9a7f-d2d888ec3514
>
>                 descr=
>
>                 srcImgGUID=00000000-0000-0000-0000-000000000000
>
>                 srcVolUUID=00000000-0000-0000-0000-000000000000
>
>
> 2013-09-20 13:57:02,489 INFO
> [org.ovirt.engine.core.vdsbroker.irsbroker.CreateImageVDSCommand]
> (ajp--127.0.0.1-8702-10) FINISH, CreateImageVDSCommand, return:
> 165089b7-4737-4900-9a7f-d2d888ec3514, log id: 1ef8212d
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20130920/54ffc841/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: engine.log
Type: application/octet-stream
Size: 96861 bytes
Desc: not available
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20130920/54ffc841/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: vdsm.log
Type: application/octet-stream
Size: 652521 bytes
Desc: not available
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20130920/54ffc841/attachment-0001.obj>

From deadhorseconsulting at gmail.com  Fri Sep 20 19:44:20 2013
From: deadhorseconsulting at gmail.com (Dead Horse)
Date: Fri, 20 Sep 2013 14:44:20 -0500
Subject: [Engine-devel] disk quota broken in latest master
In-Reply-To: <CAEWPe=rnx2xTwBtLtWy+yOW25OARN4ApN_aYxntOst-ETnMq5g@mail.gmail.com>
References: <CAEWPe=qQH=rzNXdo=aU-urayOtvW=Ja6M0B_t57MAVnGi73FYA@mail.gmail.com>
	<CAEWPe=rnx2xTwBtLtWy+yOW25OARN4ApN_aYxntOst-ETnMq5g@mail.gmail.com>
Message-ID: <CAEWPe=qcue=wXSojoyVy1WORK=vLuaDSTVCEAwsUXjdX5zHUeA@mail.gmail.com>

In further testing I note that assign quota under the disks tab of the
associated vm in the admin portal does work.
- DHC


On Fri, Sep 20, 2013 at 2:24 PM, Dead Horse
<deadhorseconsulting at gmail.com>wrote:

>
> really attach the logs
>
> I also notice that disks tab is no longer showing a disk inventory as well.
>
>  - DHC
>
>
> On Fri, Sep 20, 2013 at 2:15 PM, Dead Horse <deadhorseconsulting at gmail.com
> > wrote:
>
>> When attempting to add a disk from either the admin or power user portals
>> the according disk quota associated with the requested storage domain
>> cannot be assigned to the disk. The disk quota pull-down only will only
>> display whatever quota is first in the list alphabetically.
>> - DHC
>>
>> engine and vdsm logs attached.
>>
>> 2013-09-20 13:56:36,810 INFO  [org.ovirt.engine.core.bll.
>> LoginUserCommand] (ajp--127.0.0.1-8702-4) Running command:
>> LoginUserCommand internal: false.
>> 2013-09-20 13:56:36,833 INFO
>> [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
>> (ajp--127.0.0.1-8702-4) Correlation ID: null, Call Stack: null, Custom
>> Event ID: -1, Message: User admin at internal logged in.
>> 2013-09-20 13:56:45,775 ERROR
>> [org.ovirt.engine.core.utils.servlet.ServletUtils] (ajp--127.0.0.1-8702-6)
>> Can't read file "/usr/share/doc/ovirt-engine/manual/DocumentationPath.csv"
>> for request "/docs/DocumentationPath.csv", will send a 404 error response.
>> 2013-09-20 13:57:00,456 INFO
>> [org.ovirt.engine.core.bll.quota.QuotaManager]
>> (DefaultQuartzScheduler_Worker-72) Quota Cache updated. (26 msec)
>> 2013-09-20 13:57:01,810 INFO  [org.ovirt.engine.core.bll.AddDiskCommand]
>> (ajp--127.0.0.1-8702-10) Lock Acquired to object EngineLock
>> [exclusiveLocks= key: ca3cecf1-090e-469a-aaad-e26ce47f89d8 value:
>> VM_DISK_BOOT
>> , sharedLocks= key: ca3cecf1-090e-469a-aaad-e26ce47f89d8 value: VM
>> ]
>> 2013-09-20 13:57:01,863 ERROR
>> [org.ovirt.engine.core.bll.quota.QuotaManager] (ajp--127.0.0.1-8702-10)
>> Quota storage parameters from command:
>> org.ovirt.engine.core.bll.AddDiskCommand. Storage domain does not match
>> quota
>> 2013-09-20 13:57:01,901 INFO
>> [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
>> (ajp--127.0.0.1-8702-10) Correlation ID: 5790e811, Job ID:
>> 7abd0b95-4cd4-4cb5-864c-d51c4446a42d, Call Stack: null, Custom Event ID:
>> -1, Message: Missing Quota for Disk, proceeding since in Permissive (Audit)
>> mode.
>> 2013-09-20 13:57:01,937 INFO  [org.ovirt.engine.core.bll.AddDiskCommand]
>> (ajp--127.0.0.1-8702-10) Running command: AddDiskCommand internal: false.
>> Entities affected :  ID: ca3cecf1-090e-469a-aaad-e26ce47f89d8 Type: VM,
>> ID: 26be0640-01a3-415d-82c9-0a92f2f84c3f Type: Storage
>> 2013-09-20 13:57:02,325 INFO
>> [org.ovirt.engine.core.bll.AddImageFromScratchCommand]
>> (ajp--127.0.0.1-8702-10) Running command: AddImageFromScratchCommand
>> internal: true. Entities affected :  ID:
>> 26be0640-01a3-415d-82c9-0a92f2f84c3f Type: Storage
>> 2013-09-20 13:57:02,446 INFO
>> [org.ovirt.engine.core.bll.AddImageFromScratchCommand]
>> (ajp--127.0.0.1-8702-10) Lock freed to object EngineLock [exclusiveLocks=
>> key: ca3cecf1-090e-469a-aaad-e26ce47f89d8 value: VM_DISK_BOOT
>> , sharedLocks= key: ca3cecf1-090e-469a-aaad-e26ce47f89d8 value: VM
>> ]
>> 2013-09-20 13:57:02,451 INFO
>> [org.ovirt.engine.core.vdsbroker.irsbroker.CreateImageVDSCommand]
>> (ajp--127.0.0.1-8702-10) START, CreateImageVDSCommand( storagePoolId =
>> 5849b030-626e-47cb-ad90-3ce782d831b3, ignoreFailoverLimit = false,
>> storageDomainId = 26be0640-01a3-415d-82c9-0a92f2f84c3f, imageGroupId =
>> bf6458bc-627a-4399-822d-f72751edf303, imageSizeInBytes = 1073741824,
>> volumeFormat = RAW, newImageId = 165089b7-4737-4900-9a7f-d2d888ec3514,
>> newImageDescription = ), log id: 1ef8212d
>> 2013-09-20 13:57:02,454 INFO
>> [org.ovirt.engine.core.vdsbroker.irsbroker.CreateImageVDSCommand]
>> (ajp--127.0.0.1-8702-10) -- executeIrsBrokerCommand: calling 'createVolume'
>> with two new parameters: description and UUID
>> 2013-09-20 13:57:02,456 INFO
>> [org.ovirt.engine.core.vdsbroker.irsbroker.CreateImageVDSCommand]
>> (ajp--127.0.0.1-8702-10) -- createVolume parameters:
>>
>>                 sdUUID=26be0640-01a3-415d-82c9-0a92f2f84c3f
>>
>>                 spUUID=5849b030-626e-47cb-ad90-3ce782d831b3
>>
>>                 imgGUID=bf6458bc-627a-4399-822d-f72751edf303
>>
>>                 size=1,073,741,824 bytes
>>
>>                 volFormat=RAW
>>
>>                 volType=Sparse
>>
>>                 volUUID=165089b7-4737-4900-9a7f-d2d888ec3514
>>
>>                 descr=
>>
>>                 srcImgGUID=00000000-0000-0000-0000-000000000000
>>
>>                 srcVolUUID=00000000-0000-0000-0000-000000000000
>>
>>
>> 2013-09-20 13:57:02,489 INFO
>> [org.ovirt.engine.core.vdsbroker.irsbroker.CreateImageVDSCommand]
>> (ajp--127.0.0.1-8702-10) FINISH, CreateImageVDSCommand, return:
>> 165089b7-4737-4900-9a7f-d2d888ec3514, log id: 1ef8212d
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20130920/66ba372c/attachment.html>

From emesika at redhat.com  Sat Sep 21 20:54:17 2013
From: emesika at redhat.com (Eli Mesika)
Date: Sat, 21 Sep 2013 16:54:17 -0400 (EDT)
Subject: [Engine-devel] External events and flood rate
In-Reply-To: <D290AD8432118048947689BA3AE8A9B33C9B351C@SACEXCMBX04-PRD.hq.netapp.com>
References: <D290AD8432118048947689BA3AE8A9B33C9B351C@SACEXCMBX04-PRD.hq.netapp.com>
Message-ID: <325725355.81020.1379796857795.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Christopher Morrissey" <Christopher.Morrissey at netapp.com>
> To: engine-devel at ovirt.org
> Sent: Thursday, September 19, 2013 12:50:38 AM
> Subject: [Engine-devel] External events and flood rate
> 
> 
> 
> Hi All,
> 
> 
> 
> I?ve been working on submitting external events to oVirt through the REST
> API. It seems to be working in general, although it appears that, no matter
> what value I put for the flood rate in the event, only 1 or so events are
> allowed every 30 seconds. If I send another event during this time, I get an
> operation failed exception. Should the flood rate have any impact on this?
> Is there any way to allow my code to get an event through when needed or
> should I have a thread that shoots them off every 30 seconds if several
> occur too quickly together?

Well, the 30 sec is the default if no flood rate is given 
This is an example of how the flood rate should be set by the REST API 

<event>
        <description>any description</description>
        <severity>normal</severity>
        <origin>Customer1</origin>
        <custom_id>1</custom_id>
        <flood_rate>10</flood_rate>
</event>

Can you please check that the format you are using matches that ?
If you are using the same format and it still not working for you , please open a BZ

Thanks

Eli Mesika



> 
> 
> 
> -Chris
> 
> 
> 
> Chris Morrissey
> 
> Software Engineer
> 
> NetApp Inc.
> 
> 919.476.4428
> 
> 
> 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From gchaplik at redhat.com  Sun Sep 22 07:15:44 2013
From: gchaplik at redhat.com (Gilad Chaplik)
Date: Sun, 22 Sep 2013 03:15:44 -0400 (EDT)
Subject: [Engine-devel] disk quota broken in latest master
In-Reply-To: <CAEWPe=qcue=wXSojoyVy1WORK=vLuaDSTVCEAwsUXjdX5zHUeA@mail.gmail.com>
References: <CAEWPe=qQH=rzNXdo=aU-urayOtvW=Ja6M0B_t57MAVnGi73FYA@mail.gmail.com>
	<CAEWPe=rnx2xTwBtLtWy+yOW25OARN4ApN_aYxntOst-ETnMq5g@mail.gmail.com>
	<CAEWPe=qcue=wXSojoyVy1WORK=vLuaDSTVCEAwsUXjdX5zHUeA@mail.gmail.com>
Message-ID: <1457079272.184456.1379834144326.JavaMail.root@redhat.com>

Hi,

looks like the quota drop-down isn't getting refreshed according to selected storage domain.
can you please open a bug?

Thanks, 
Gilad.

----- Original Message -----
> From: "Dead Horse" <deadhorseconsulting at gmail.com>
> To: "engine-devel" <engine-devel at ovirt.org>
> Sent: Friday, September 20, 2013 9:44:20 PM
> Subject: Re: [Engine-devel] disk quota broken in latest master
> 
> In further testing I note that assign quota under the disks tab of the
> associated vm in the admin portal does work.
> - DHC
> 
> 
> On Fri, Sep 20, 2013 at 2:24 PM, Dead Horse < deadhorseconsulting at gmail.com >
> wrote:
> 
> 
> 
> 
> really attach the logs
> 
> I also notice that disks tab is no longer showing a disk inventory as well.
> 
> - DHC
> 
> 
> On Fri, Sep 20, 2013 at 2:15 PM, Dead Horse < deadhorseconsulting at gmail.com >
> wrote:
> 
> 
> 
> When attempting to add a disk from either the admin or power user portals the
> according disk quota associated with the requested storage domain cannot be
> assigned to the disk. The disk quota pull-down only will only display
> whatever quota is first in the list alphabetically.
> - DHC
> 
> engine and vdsm logs attached.
> 
> 2013-09-20 13:56:36,810 INFO [org.ovirt.engine.core.bll.
> LoginUserCommand] (ajp--127.0.0.1-8702-4) Running command: LoginUserCommand
> internal: false.
> 2013-09-20 13:56:36,833 INFO
> [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
> (ajp--127.0.0.1-8702-4) Correlation ID: null, Call Stack: null, Custom Event
> ID: -1, Message: User admin at internal logged in.
> 2013-09-20 13:56:45,775 ERROR
> [org.ovirt.engine.core.utils.servlet.ServletUtils] (ajp--127.0.0.1-8702-6)
> Can't read file "/usr/share/doc/ovirt-engine/manual/DocumentationPath.csv"
> for request "/docs/DocumentationPath.csv", will send a 404 error response.
> 2013-09-20 13:57:00,456 INFO [org.ovirt.engine.core.bll.quota.QuotaManager]
> (DefaultQuartzScheduler_Worker-72) Quota Cache updated. (26 msec)
> 2013-09-20 13:57:01,810 INFO [org.ovirt.engine.core.bll.AddDiskCommand]
> (ajp--127.0.0.1-8702-10) Lock Acquired to object EngineLock [exclusiveLocks=
> key: ca3cecf1-090e-469a-aaad-e26ce47f89d8 value: VM_DISK_BOOT
> , sharedLocks= key: ca3cecf1-090e-469a-aaad-e26ce47f89d8 value: VM
> ]
> 2013-09-20 13:57:01,863 ERROR [org.ovirt.engine.core.bll.quota.QuotaManager]
> (ajp--127.0.0.1-8702-10) Quota storage parameters from command:
> org.ovirt.engine.core.bll.AddDiskCommand. Storage domain does not match
> quota
> 2013-09-20 13:57:01,901 INFO
> [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
> (ajp--127.0.0.1-8702-10) Correlation ID: 5790e811, Job ID:
> 7abd0b95-4cd4-4cb5-864c-d51c4446a42d, Call Stack: null, Custom Event ID: -1,
> Message: Missing Quota for Disk, proceeding since in Permissive (Audit)
> mode.
> 2013-09-20 13:57:01,937 INFO [org.ovirt.engine.core.bll.AddDiskCommand]
> (ajp--127.0.0.1-8702-10) Running command: AddDiskCommand internal: false.
> Entities affected : ID: ca3cecf1-090e-469a-aaad-e26ce47f89d8 Type: VM, ID:
> 26be0640-01a3-415d-82c9-0a92f2f84c3f Type: Storage
> 2013-09-20 13:57:02,325 INFO
> [org.ovirt.engine.core.bll.AddImageFromScratchCommand]
> (ajp--127.0.0.1-8702-10) Running command: AddImageFromScratchCommand
> internal: true. Entities affected : ID: 26be0640-01a3-415d-82c9-0a92f2f84c3f
> Type: Storage
> 2013-09-20 13:57:02,446 INFO
> [org.ovirt.engine.core.bll.AddImageFromScratchCommand]
> (ajp--127.0.0.1-8702-10) Lock freed to object EngineLock [exclusiveLocks=
> key: ca3cecf1-090e-469a-aaad-e26ce47f89d8 value: VM_DISK_BOOT
> , sharedLocks= key: ca3cecf1-090e-469a-aaad-e26ce47f89d8 value: VM
> ]
> 2013-09-20 13:57:02,451 INFO
> [org.ovirt.engine.core.vdsbroker.irsbroker.CreateImageVDSCommand]
> (ajp--127.0.0.1-8702-10) START, CreateImageVDSCommand( storagePoolId =
> 5849b030-626e-47cb-ad90-3ce782d831b3, ignoreFailoverLimit = false,
> storageDomainId = 26be0640-01a3-415d-82c9-0a92f2f84c3f, imageGroupId =
> bf6458bc-627a-4399-822d-f72751edf303, imageSizeInBytes = 1073741824,
> volumeFormat = RAW, newImageId = 165089b7-4737-4900-9a7f-d2d888ec3514,
> newImageDescription = ), log id: 1ef8212d
> 2013-09-20 13:57:02,454 INFO
> [org.ovirt.engine.core.vdsbroker.irsbroker.CreateImageVDSCommand]
> (ajp--127.0.0.1-8702-10) -- executeIrsBrokerCommand: calling 'createVolume'
> with two new parameters: description and UUID
> 2013-09-20 13:57:02,456 INFO
> [org.ovirt.engine.core.vdsbroker.irsbroker.CreateImageVDSCommand]
> (ajp--127.0.0.1-8702-10) -- createVolume parameters:
> 
> sdUUID=26be0640-01a3-415d-82c9-0a92f2f84c3f
> 
> spUUID=5849b030-626e-47cb-ad90-3ce782d831b3
> 
> imgGUID=bf6458bc-627a-4399-822d-f72751edf303
> 
> size=1,073,741,824 bytes
> 
> volFormat=RAW
> 
> volType=Sparse
> 
> volUUID=165089b7-4737-4900-9a7f-d2d888ec3514
> 
> descr=
> 
> srcImgGUID=00000000-0000-0000-0000-000000000000
> 
> srcVolUUID=00000000-0000-0000-0000-000000000000
> 
> 
> 2013-09-20 13:57:02,489 INFO
> [org.ovirt.engine.core.vdsbroker.irsbroker.CreateImageVDSCommand]
> (ajp--127.0.0.1-8702-10) FINISH, CreateImageVDSCommand, return:
> 165089b7-4737-4900-9a7f-d2d888ec3514, log id: 1ef8212d
> 
> 
> 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From gchaplik at redhat.com  Mon Sep 23 08:44:43 2013
From: gchaplik at redhat.com (Gilad Chaplik)
Date: Mon, 23 Sep 2013 04:44:43 -0400 (EDT)
Subject: [Engine-devel] disk quota broken in latest master
In-Reply-To: <1457079272.184456.1379834144326.JavaMail.root@redhat.com>
References: <CAEWPe=qQH=rzNXdo=aU-urayOtvW=Ja6M0B_t57MAVnGi73FYA@mail.gmail.com>
	<CAEWPe=rnx2xTwBtLtWy+yOW25OARN4ApN_aYxntOst-ETnMq5g@mail.gmail.com>
	<CAEWPe=qcue=wXSojoyVy1WORK=vLuaDSTVCEAwsUXjdX5zHUeA@mail.gmail.com>
	<1457079272.184456.1379834144326.JavaMail.root@redhat.com>
Message-ID: <150921523.425174.1379925883501.JavaMail.root@redhat.com>

http://gerrit.ovirt.org/#/c/19432/ [merged] should fix it.

Thanks, 
Gilad.

----- Original Message -----
> From: "Gilad Chaplik" <gchaplik at redhat.com>
> To: "Dead Horse" <deadhorseconsulting at gmail.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>
> Sent: Sunday, September 22, 2013 9:15:44 AM
> Subject: Re: [Engine-devel] disk quota broken in latest master
> 
> Hi,
> 
> looks like the quota drop-down isn't getting refreshed according to selected
> storage domain.
> can you please open a bug?
> 
> Thanks,
> Gilad.
> 
> ----- Original Message -----
> > From: "Dead Horse" <deadhorseconsulting at gmail.com>
> > To: "engine-devel" <engine-devel at ovirt.org>
> > Sent: Friday, September 20, 2013 9:44:20 PM
> > Subject: Re: [Engine-devel] disk quota broken in latest master
> > 
> > In further testing I note that assign quota under the disks tab of the
> > associated vm in the admin portal does work.
> > - DHC
> > 
> > 
> > On Fri, Sep 20, 2013 at 2:24 PM, Dead Horse < deadhorseconsulting at gmail.com
> > >
> > wrote:
> > 
> > 
> > 
> > 
> > really attach the logs
> > 
> > I also notice that disks tab is no longer showing a disk inventory as well.
> > 
> > - DHC
> > 
> > 
> > On Fri, Sep 20, 2013 at 2:15 PM, Dead Horse < deadhorseconsulting at gmail.com
> > >
> > wrote:
> > 
> > 
> > 
> > When attempting to add a disk from either the admin or power user portals
> > the
> > according disk quota associated with the requested storage domain cannot be
> > assigned to the disk. The disk quota pull-down only will only display
> > whatever quota is first in the list alphabetically.
> > - DHC
> > 
> > engine and vdsm logs attached.
> > 
> > 2013-09-20 13:56:36,810 INFO [org.ovirt.engine.core.bll.
> > LoginUserCommand] (ajp--127.0.0.1-8702-4) Running command: LoginUserCommand
> > internal: false.
> > 2013-09-20 13:56:36,833 INFO
> > [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
> > (ajp--127.0.0.1-8702-4) Correlation ID: null, Call Stack: null, Custom
> > Event
> > ID: -1, Message: User admin at internal logged in.
> > 2013-09-20 13:56:45,775 ERROR
> > [org.ovirt.engine.core.utils.servlet.ServletUtils] (ajp--127.0.0.1-8702-6)
> > Can't read file "/usr/share/doc/ovirt-engine/manual/DocumentationPath.csv"
> > for request "/docs/DocumentationPath.csv", will send a 404 error response.
> > 2013-09-20 13:57:00,456 INFO [org.ovirt.engine.core.bll.quota.QuotaManager]
> > (DefaultQuartzScheduler_Worker-72) Quota Cache updated. (26 msec)
> > 2013-09-20 13:57:01,810 INFO [org.ovirt.engine.core.bll.AddDiskCommand]
> > (ajp--127.0.0.1-8702-10) Lock Acquired to object EngineLock
> > [exclusiveLocks=
> > key: ca3cecf1-090e-469a-aaad-e26ce47f89d8 value: VM_DISK_BOOT
> > , sharedLocks= key: ca3cecf1-090e-469a-aaad-e26ce47f89d8 value: VM
> > ]
> > 2013-09-20 13:57:01,863 ERROR
> > [org.ovirt.engine.core.bll.quota.QuotaManager]
> > (ajp--127.0.0.1-8702-10) Quota storage parameters from command:
> > org.ovirt.engine.core.bll.AddDiskCommand. Storage domain does not match
> > quota
> > 2013-09-20 13:57:01,901 INFO
> > [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
> > (ajp--127.0.0.1-8702-10) Correlation ID: 5790e811, Job ID:
> > 7abd0b95-4cd4-4cb5-864c-d51c4446a42d, Call Stack: null, Custom Event ID:
> > -1,
> > Message: Missing Quota for Disk, proceeding since in Permissive (Audit)
> > mode.
> > 2013-09-20 13:57:01,937 INFO [org.ovirt.engine.core.bll.AddDiskCommand]
> > (ajp--127.0.0.1-8702-10) Running command: AddDiskCommand internal: false.
> > Entities affected : ID: ca3cecf1-090e-469a-aaad-e26ce47f89d8 Type: VM, ID:
> > 26be0640-01a3-415d-82c9-0a92f2f84c3f Type: Storage
> > 2013-09-20 13:57:02,325 INFO
> > [org.ovirt.engine.core.bll.AddImageFromScratchCommand]
> > (ajp--127.0.0.1-8702-10) Running command: AddImageFromScratchCommand
> > internal: true. Entities affected : ID:
> > 26be0640-01a3-415d-82c9-0a92f2f84c3f
> > Type: Storage
> > 2013-09-20 13:57:02,446 INFO
> > [org.ovirt.engine.core.bll.AddImageFromScratchCommand]
> > (ajp--127.0.0.1-8702-10) Lock freed to object EngineLock [exclusiveLocks=
> > key: ca3cecf1-090e-469a-aaad-e26ce47f89d8 value: VM_DISK_BOOT
> > , sharedLocks= key: ca3cecf1-090e-469a-aaad-e26ce47f89d8 value: VM
> > ]
> > 2013-09-20 13:57:02,451 INFO
> > [org.ovirt.engine.core.vdsbroker.irsbroker.CreateImageVDSCommand]
> > (ajp--127.0.0.1-8702-10) START, CreateImageVDSCommand( storagePoolId =
> > 5849b030-626e-47cb-ad90-3ce782d831b3, ignoreFailoverLimit = false,
> > storageDomainId = 26be0640-01a3-415d-82c9-0a92f2f84c3f, imageGroupId =
> > bf6458bc-627a-4399-822d-f72751edf303, imageSizeInBytes = 1073741824,
> > volumeFormat = RAW, newImageId = 165089b7-4737-4900-9a7f-d2d888ec3514,
> > newImageDescription = ), log id: 1ef8212d
> > 2013-09-20 13:57:02,454 INFO
> > [org.ovirt.engine.core.vdsbroker.irsbroker.CreateImageVDSCommand]
> > (ajp--127.0.0.1-8702-10) -- executeIrsBrokerCommand: calling 'createVolume'
> > with two new parameters: description and UUID
> > 2013-09-20 13:57:02,456 INFO
> > [org.ovirt.engine.core.vdsbroker.irsbroker.CreateImageVDSCommand]
> > (ajp--127.0.0.1-8702-10) -- createVolume parameters:
> > 
> > sdUUID=26be0640-01a3-415d-82c9-0a92f2f84c3f
> > 
> > spUUID=5849b030-626e-47cb-ad90-3ce782d831b3
> > 
> > imgGUID=bf6458bc-627a-4399-822d-f72751edf303
> > 
> > size=1,073,741,824 bytes
> > 
> > volFormat=RAW
> > 
> > volType=Sparse
> > 
> > volUUID=165089b7-4737-4900-9a7f-d2d888ec3514
> > 
> > descr=
> > 
> > srcImgGUID=00000000-0000-0000-0000-000000000000
> > 
> > srcVolUUID=00000000-0000-0000-0000-000000000000
> > 
> > 
> > 2013-09-20 13:57:02,489 INFO
> > [org.ovirt.engine.core.vdsbroker.irsbroker.CreateImageVDSCommand]
> > (ajp--127.0.0.1-8702-10) FINISH, CreateImageVDSCommand, return:
> > 165089b7-4737-4900-9a7f-d2d888ec3514, log id: 1ef8212d
> > 
> > 
> > 
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From iheim at redhat.com  Mon Sep 23 10:09:29 2013
From: iheim at redhat.com (Itamar Heim)
Date: Mon, 23 Sep 2013 13:09:29 +0300
Subject: [Engine-devel] 3.3.1/stable branch
Message-ID: <52401359.9050005@redhat.com>

to recap on previous discussions in ovirt meetings and emails:
- 3.3.1 will be rebased off master branch for ovirt-engine/vdsm
- for vdsm, danken will send more details, but general plan is to issue
   a release next week then create a stable branch for it
- for engine, a stable ovirt-engine-3.3 branch was created today.
   all backports for patches to stabilize 3.3 should go to this branch.
- will give this branch a few weeks to stabilize before releasing
   updates from it.
- critical updates for 3.3.0 should be backported to both ovirt-
   engine-3.3 and ovirt-engine-3.3.0 branches.

Thanks,
    Itamar


From mpastern at redhat.com  Mon Sep 23 10:35:43 2013
From: mpastern at redhat.com (Michael Pasternak)
Date: Mon, 23 Sep 2013 13:35:43 +0300
Subject: [Engine-devel] External events and flood rate
In-Reply-To: <D290AD8432118048947689BA3AE8A9B33C9B351C@SACEXCMBX04-PRD.hq.netapp.com>
References: <D290AD8432118048947689BA3AE8A9B33C9B351C@SACEXCMBX04-PRD.hq.netapp.com>
Message-ID: <5240197F.7090708@redhat.com>

Eli,

any reason for hardcoding this [1]? i'd move it to vdc_config.

[1] Math.max(auditLogable.getEventFloodInSec(), 30) // Min duration for External Events is 30 sec

On 09/19/2013 12:50 AM, Morrissey, Christopher wrote:
> Hi All,
> 
>  
> 
> I?ve been working on submitting external events to oVirt through the REST API. It seems to be working in general, although it appears that, no matter what value I put for
> the flood rate in the event, only 1 or so events are allowed every 30 seconds. If I send another event during this time, I get an operation failed exception. Should the
> flood rate have any impact on this? Is there any way to allow my code to get an event through when needed or should I have a thread that shoots them off every 30 seconds if
> several occur too quickly together?
> 
>  
> 
> -Chris
> 
>  
> 
> *Chris Morrissey*
> 
> Software Engineer
> 
> NetApp Inc.
> 
> 919.476.4428
> 
>  
> 
> 
> 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


-- 

Michael Pasternak
RedHat, ENG-Virtualization R&D


From iheim at redhat.com  Mon Sep 23 10:36:58 2013
From: iheim at redhat.com (Itamar Heim)
Date: Mon, 23 Sep 2013 13:36:58 +0300
Subject: [Engine-devel] stale gerrit patches
Message-ID: <524019CA.3080608@redhat.com>

we have some very old gerrit patches.
I'm for abandoning patches which were not touched over 60 days (to begin 
with, I think the number should actually be lower).
they can always be re-opened by any interested party post their closure.

i.e., looking at gerrit, the patch list should actually get attention, 
and not be a few worth looking at, with a "lot of old patches"

thoughts?

Thanks,
    Itamar


From dcaroest at redhat.com  Mon Sep 23 10:46:12 2013
From: dcaroest at redhat.com (David Caro)
Date: Mon, 23 Sep 2013 12:46:12 +0200
Subject: [Engine-devel] [vdsm] stale gerrit patches
In-Reply-To: <524019CA.3080608@redhat.com>
References: <524019CA.3080608@redhat.com>
Message-ID: <52401BF4.5090800@redhat.com>

On Mon 23 Sep 2013 12:36:58 PM CEST, Itamar Heim wrote:
> we have some very old gerrit patches.
> I'm for abandoning patches which were not touched over 60 days (to
> begin with, I think the number should actually be lower).
> they can always be re-opened by any interested party post their closure.
>
> i.e., looking at gerrit, the patch list should actually get attention,
> and not be a few worth looking at, with a "lot of old patches"
>
> thoughts?
>
> Thanks,
>    Itamar
> _______________________________________________
> vdsm-devel mailing list
> vdsm-devel at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel

It might helpful to have a cron-like script that checks the age of the 
posts and first notifies the sender, the reviewers and the maintainer, 
and if the patch is not updated in a certain period just abandons it.


--
David Caro

Red Hat Czech s.r.o.
Continuous Integration Engineer - EMEA ENG Virtualization R&D

Tel.: +420 532 294 605
Email: dcaro at redhat.com
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purky?ova 99/71, 612 45, Brno, Czech Republic
RHT Global #: 82-62605


From iheim at redhat.com  Mon Sep 23 10:47:47 2013
From: iheim at redhat.com (Itamar Heim)
Date: Mon, 23 Sep 2013 13:47:47 +0300
Subject: [Engine-devel] [vdsm] stale gerrit patches
In-Reply-To: <52401BF4.5090800@redhat.com>
References: <524019CA.3080608@redhat.com> <52401BF4.5090800@redhat.com>
Message-ID: <52401C53.20702@redhat.com>

On 09/23/2013 01:46 PM, David Caro wrote:
> On Mon 23 Sep 2013 12:36:58 PM CEST, Itamar Heim wrote:
>> we have some very old gerrit patches.
>> I'm for abandoning patches which were not touched over 60 days (to
>> begin with, I think the number should actually be lower).
>> they can always be re-opened by any interested party post their closure.
>>
>> i.e., looking at gerrit, the patch list should actually get attention,
>> and not be a few worth looking at, with a "lot of old patches"
>>
>> thoughts?
>>
>> Thanks,
>>     Itamar
>> _______________________________________________
>> vdsm-devel mailing list
>> vdsm-devel at lists.fedorahosted.org
>> https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
>
> It might helpful to have a cron-like script that checks the age of the
> posts and first notifies the sender, the reviewers and the maintainer,
> and if the patch is not updated in a certain period just abandons it.
>

yep - warn after X days via email to just owner (or all subscribed to 
the patch), and close if no activity for X+14 days or something like that.



From oschreib at redhat.com  Mon Sep 23 10:49:36 2013
From: oschreib at redhat.com (Ofer Schreiber)
Date: Mon, 23 Sep 2013 06:49:36 -0400 (EDT)
Subject: [Engine-devel] Suggesting new packaging and setup maintainer
In-Reply-To: <829554339.13340898.1378975742946.JavaMail.root@redhat.com>
Message-ID: <1271829417.461834.1379933376488.JavaMail.root@redhat.com>

Nominating Sandro Bonazzola as packaging and setup maintainer
----------------------------------------------------------

During his recent year of participation in ovirt-engine development,
Sandro demonstrated a genuine care for the product health, great coding abilities,
and great responsibility to the setup and packaging components.

Sandro's contribution the the project is undoubtable, he's responsible for over 70 patches in ovirt-engine, 
and he's the maintainer of log-collector, iso-uploader and image-uploader packages.

I suggest that Sandro will obtain +2 and merge rights in the ovirt-engine gerrit project,
in the understanding that those rights should be used only in packaging and setup parts of the code.

--
Ofer Schreiber.


From alonbl at redhat.com  Mon Sep 23 10:49:51 2013
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Mon, 23 Sep 2013 06:49:51 -0400 (EDT)
Subject: [Engine-devel] [vdsm] stale gerrit patches
In-Reply-To: <52401C53.20702@redhat.com>
References: <524019CA.3080608@redhat.com> <52401BF4.5090800@redhat.com>
	<52401C53.20702@redhat.com>
Message-ID: <661632990.218831.1379933391058.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Itamar Heim" <iheim at redhat.com>
> To: "David Caro" <dcaroest at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>, vdsm-devel at lists.fedorahosted.org
> Sent: Monday, September 23, 2013 1:47:47 PM
> Subject: Re: [vdsm] stale gerrit patches
> 
> On 09/23/2013 01:46 PM, David Caro wrote:
> > On Mon 23 Sep 2013 12:36:58 PM CEST, Itamar Heim wrote:
> >> we have some very old gerrit patches.
> >> I'm for abandoning patches which were not touched over 60 days (to
> >> begin with, I think the number should actually be lower).
> >> they can always be re-opened by any interested party post their closure.
> >>
> >> i.e., looking at gerrit, the patch list should actually get attention,
> >> and not be a few worth looking at, with a "lot of old patches"
> >>
> >> thoughts?
> >>
> >> Thanks,
> >>     Itamar
> >> _______________________________________________
> >> vdsm-devel mailing list
> >> vdsm-devel at lists.fedorahosted.org
> >> https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
> >
> > It might helpful to have a cron-like script that checks the age of the
> > posts and first notifies the sender, the reviewers and the maintainer,
> > and if the patch is not updated in a certain period just abandons it.
> >
> 
> yep - warn after X days via email to just owner (or all subscribed to
> the patch), and close if no activity for X+14 days or something like that.

This will be annoying.

And there are patches that pending with good reason.

Maintainers can close patches that are no interest nor progress.

Alon


From iheim at redhat.com  Mon Sep 23 10:50:35 2013
From: iheim at redhat.com (Itamar Heim)
Date: Mon, 23 Sep 2013 13:50:35 +0300
Subject: [Engine-devel] [vdsm] stale gerrit patches
In-Reply-To: <661632990.218831.1379933391058.JavaMail.root@redhat.com>
References: <524019CA.3080608@redhat.com> <52401BF4.5090800@redhat.com>
	<52401C53.20702@redhat.com>
	<661632990.218831.1379933391058.JavaMail.root@redhat.com>
Message-ID: <52401CFB.1040300@redhat.com>

On 09/23/2013 01:49 PM, Alon Bar-Lev wrote:
>
>
> ----- Original Message -----
>> From: "Itamar Heim" <iheim at redhat.com>
>> To: "David Caro" <dcaroest at redhat.com>
>> Cc: "engine-devel" <engine-devel at ovirt.org>, vdsm-devel at lists.fedorahosted.org
>> Sent: Monday, September 23, 2013 1:47:47 PM
>> Subject: Re: [vdsm] stale gerrit patches
>>
>> On 09/23/2013 01:46 PM, David Caro wrote:
>>> On Mon 23 Sep 2013 12:36:58 PM CEST, Itamar Heim wrote:
>>>> we have some very old gerrit patches.
>>>> I'm for abandoning patches which were not touched over 60 days (to
>>>> begin with, I think the number should actually be lower).
>>>> they can always be re-opened by any interested party post their closure.
>>>>
>>>> i.e., looking at gerrit, the patch list should actually get attention,
>>>> and not be a few worth looking at, with a "lot of old patches"
>>>>
>>>> thoughts?
>>>>
>>>> Thanks,
>>>>      Itamar
>>>> _______________________________________________
>>>> vdsm-devel mailing list
>>>> vdsm-devel at lists.fedorahosted.org
>>>> https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
>>>
>>> It might helpful to have a cron-like script that checks the age of the
>>> posts and first notifies the sender, the reviewers and the maintainer,
>>> and if the patch is not updated in a certain period just abandons it.
>>>
>>
>> yep - warn after X days via email to just owner (or all subscribed to
>> the patch), and close if no activity for X+14 days or something like that.
>
> This will be annoying.
>
> And there are patches that pending with good reason.

pending for 60 days with zero activity on them (no comment, no rebase, 
nothing)?

>
> Maintainers can close patches that are no interest nor progress.
>
> Alon
>



From alonbl at redhat.com  Mon Sep 23 10:52:56 2013
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Mon, 23 Sep 2013 06:52:56 -0400 (EDT)
Subject: [Engine-devel] [vdsm] stale gerrit patches
In-Reply-To: <52401CFB.1040300@redhat.com>
References: <524019CA.3080608@redhat.com> <52401BF4.5090800@redhat.com>
	<52401C53.20702@redhat.com>
	<661632990.218831.1379933391058.JavaMail.root@redhat.com>
	<52401CFB.1040300@redhat.com>
Message-ID: <444143941.219431.1379933576061.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Itamar Heim" <iheim at redhat.com>
> To: "Alon Bar-Lev" <alonbl at redhat.com>
> Cc: "David Caro" <dcaroest at redhat.com>, "engine-devel" <engine-devel at ovirt.org>, vdsm-devel at lists.fedorahosted.org
> Sent: Monday, September 23, 2013 1:50:35 PM
> Subject: Re: [vdsm] stale gerrit patches
> 
> On 09/23/2013 01:49 PM, Alon Bar-Lev wrote:
> >
> >
> > ----- Original Message -----
> >> From: "Itamar Heim" <iheim at redhat.com>
> >> To: "David Caro" <dcaroest at redhat.com>
> >> Cc: "engine-devel" <engine-devel at ovirt.org>,
> >> vdsm-devel at lists.fedorahosted.org
> >> Sent: Monday, September 23, 2013 1:47:47 PM
> >> Subject: Re: [vdsm] stale gerrit patches
> >>
> >> On 09/23/2013 01:46 PM, David Caro wrote:
> >>> On Mon 23 Sep 2013 12:36:58 PM CEST, Itamar Heim wrote:
> >>>> we have some very old gerrit patches.
> >>>> I'm for abandoning patches which were not touched over 60 days (to
> >>>> begin with, I think the number should actually be lower).
> >>>> they can always be re-opened by any interested party post their closure.
> >>>>
> >>>> i.e., looking at gerrit, the patch list should actually get attention,
> >>>> and not be a few worth looking at, with a "lot of old patches"
> >>>>
> >>>> thoughts?
> >>>>
> >>>> Thanks,
> >>>>      Itamar
> >>>> _______________________________________________
> >>>> vdsm-devel mailing list
> >>>> vdsm-devel at lists.fedorahosted.org
> >>>> https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
> >>>
> >>> It might helpful to have a cron-like script that checks the age of the
> >>> posts and first notifies the sender, the reviewers and the maintainer,
> >>> and if the patch is not updated in a certain period just abandons it.
> >>>
> >>
> >> yep - warn after X days via email to just owner (or all subscribed to
> >> the patch), and close if no activity for X+14 days or something like that.
> >
> > This will be annoying.
> >
> > And there are patches that pending with good reason.
> 
> pending for 60 days with zero activity on them (no comment, no rebase,
> nothing)?

http://gerrit.ovirt.org/#/q/status:open+project:ovirt-engine+branch:master+topic:independent_deployments,n,z

> 
> >
> > Maintainers can close patches that are no interest nor progress.
> >
> > Alon
> >
> 
> 


From alonbl at redhat.com  Mon Sep 23 10:53:46 2013
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Mon, 23 Sep 2013 06:53:46 -0400 (EDT)
Subject: [Engine-devel] [vdsm] stale gerrit patches
In-Reply-To: <444143941.219431.1379933576061.JavaMail.root@redhat.com>
References: <524019CA.3080608@redhat.com> <52401BF4.5090800@redhat.com>
	<52401C53.20702@redhat.com>
	<661632990.218831.1379933391058.JavaMail.root@redhat.com>
	<52401CFB.1040300@redhat.com>
	<444143941.219431.1379933576061.JavaMail.root@redhat.com>
Message-ID: <1898319007.219743.1379933626015.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Alon Bar-Lev" <alonbl at redhat.com>
> To: "Itamar Heim" <iheim at redhat.com>
> Cc: "David Caro" <dcaroest at redhat.com>, "engine-devel" <engine-devel at ovirt.org>, vdsm-devel at lists.fedorahosted.org
> Sent: Monday, September 23, 2013 1:52:56 PM
> Subject: Re: [vdsm] stale gerrit patches
> 
> 
> 
> ----- Original Message -----
> > From: "Itamar Heim" <iheim at redhat.com>
> > To: "Alon Bar-Lev" <alonbl at redhat.com>
> > Cc: "David Caro" <dcaroest at redhat.com>, "engine-devel"
> > <engine-devel at ovirt.org>, vdsm-devel at lists.fedorahosted.org
> > Sent: Monday, September 23, 2013 1:50:35 PM
> > Subject: Re: [vdsm] stale gerrit patches
> > 
> > On 09/23/2013 01:49 PM, Alon Bar-Lev wrote:
> > >
> > >
> > > ----- Original Message -----
> > >> From: "Itamar Heim" <iheim at redhat.com>
> > >> To: "David Caro" <dcaroest at redhat.com>
> > >> Cc: "engine-devel" <engine-devel at ovirt.org>,
> > >> vdsm-devel at lists.fedorahosted.org
> > >> Sent: Monday, September 23, 2013 1:47:47 PM
> > >> Subject: Re: [vdsm] stale gerrit patches
> > >>
> > >> On 09/23/2013 01:46 PM, David Caro wrote:
> > >>> On Mon 23 Sep 2013 12:36:58 PM CEST, Itamar Heim wrote:
> > >>>> we have some very old gerrit patches.
> > >>>> I'm for abandoning patches which were not touched over 60 days (to
> > >>>> begin with, I think the number should actually be lower).
> > >>>> they can always be re-opened by any interested party post their
> > >>>> closure.
> > >>>>
> > >>>> i.e., looking at gerrit, the patch list should actually get attention,
> > >>>> and not be a few worth looking at, with a "lot of old patches"
> > >>>>
> > >>>> thoughts?
> > >>>>
> > >>>> Thanks,
> > >>>>      Itamar
> > >>>> _______________________________________________
> > >>>> vdsm-devel mailing list
> > >>>> vdsm-devel at lists.fedorahosted.org
> > >>>> https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
> > >>>
> > >>> It might helpful to have a cron-like script that checks the age of the
> > >>> posts and first notifies the sender, the reviewers and the maintainer,
> > >>> and if the patch is not updated in a certain period just abandons it.
> > >>>
> > >>
> > >> yep - warn after X days via email to just owner (or all subscribed to
> > >> the patch), and close if no activity for X+14 days or something like
> > >> that.
> > >
> > > This will be annoying.
> > >
> > > And there are patches that pending with good reason.
> > 
> > pending for 60 days with zero activity on them (no comment, no rebase,
> > nothing)?
> 
> http://gerrit.ovirt.org/#/q/status:open+project:ovirt-engine+branch:master+topic:independent_deployments,n,z

http://gerrit.ovirt.org/#/q/status:open+project:ovirt-engine+branch:master+topic:ldap_independence,n,z

> 
> > 
> > >
> > > Maintainers can close patches that are no interest nor progress.
> > >
> > > Alon
> > >
> > 
> > 
> 


From iheim at redhat.com  Mon Sep 23 10:54:39 2013
From: iheim at redhat.com (Itamar Heim)
Date: Mon, 23 Sep 2013 13:54:39 +0300
Subject: [Engine-devel] [vdsm] stale gerrit patches
In-Reply-To: <444143941.219431.1379933576061.JavaMail.root@redhat.com>
References: <524019CA.3080608@redhat.com> <52401BF4.5090800@redhat.com>
	<52401C53.20702@redhat.com>
	<661632990.218831.1379933391058.JavaMail.root@redhat.com>
	<52401CFB.1040300@redhat.com>
	<444143941.219431.1379933576061.JavaMail.root@redhat.com>
Message-ID: <52401DEF.10607@redhat.com>

On 09/23/2013 01:52 PM, Alon Bar-Lev wrote:
>
>
> ----- Original Message -----
>> From: "Itamar Heim" <iheim at redhat.com>
>> To: "Alon Bar-Lev" <alonbl at redhat.com>
>> Cc: "David Caro" <dcaroest at redhat.com>, "engine-devel" <engine-devel at ovirt.org>, vdsm-devel at lists.fedorahosted.org
>> Sent: Monday, September 23, 2013 1:50:35 PM
>> Subject: Re: [vdsm] stale gerrit patches
>>
>> On 09/23/2013 01:49 PM, Alon Bar-Lev wrote:
>>>
>>>
>>> ----- Original Message -----
>>>> From: "Itamar Heim" <iheim at redhat.com>
>>>> To: "David Caro" <dcaroest at redhat.com>
>>>> Cc: "engine-devel" <engine-devel at ovirt.org>,
>>>> vdsm-devel at lists.fedorahosted.org
>>>> Sent: Monday, September 23, 2013 1:47:47 PM
>>>> Subject: Re: [vdsm] stale gerrit patches
>>>>
>>>> On 09/23/2013 01:46 PM, David Caro wrote:
>>>>> On Mon 23 Sep 2013 12:36:58 PM CEST, Itamar Heim wrote:
>>>>>> we have some very old gerrit patches.
>>>>>> I'm for abandoning patches which were not touched over 60 days (to
>>>>>> begin with, I think the number should actually be lower).
>>>>>> they can always be re-opened by any interested party post their closure.
>>>>>>
>>>>>> i.e., looking at gerrit, the patch list should actually get attention,
>>>>>> and not be a few worth looking at, with a "lot of old patches"
>>>>>>
>>>>>> thoughts?
>>>>>>
>>>>>> Thanks,
>>>>>>       Itamar
>>>>>> _______________________________________________
>>>>>> vdsm-devel mailing list
>>>>>> vdsm-devel at lists.fedorahosted.org
>>>>>> https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
>>>>>
>>>>> It might helpful to have a cron-like script that checks the age of the
>>>>> posts and first notifies the sender, the reviewers and the maintainer,
>>>>> and if the patch is not updated in a certain period just abandons it.
>>>>>
>>>>
>>>> yep - warn after X days via email to just owner (or all subscribed to
>>>> the patch), and close if no activity for X+14 days or something like that.
>>>
>>> This will be annoying.
>>>
>>> And there are patches that pending with good reason.
>>
>> pending for 60 days with zero activity on them (no comment, no rebase,
>> nothing)?
>
> http://gerrit.ovirt.org/#/q/status:open+project:ovirt-engine+branch:master+topic:independent_deployments,n,z

so how does it help us to have these patches, some without any comment 
from any reviewer.
lets get them reviewed and decide one way or the other, rather than let 
them get old and stay forever

>
>>
>>>
>>> Maintainers can close patches that are no interest nor progress.
>>>
>>> Alon
>>>
>>
>>



From alonbl at redhat.com  Mon Sep 23 10:59:11 2013
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Mon, 23 Sep 2013 06:59:11 -0400 (EDT)
Subject: [Engine-devel] [vdsm] stale gerrit patches
In-Reply-To: <52401DEF.10607@redhat.com>
References: <524019CA.3080608@redhat.com> <52401BF4.5090800@redhat.com>
	<52401C53.20702@redhat.com>
	<661632990.218831.1379933391058.JavaMail.root@redhat.com>
	<52401CFB.1040300@redhat.com>
	<444143941.219431.1379933576061.JavaMail.root@redhat.com>
	<52401DEF.10607@redhat.com>
Message-ID: <12011846.220527.1379933951518.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Itamar Heim" <iheim at redhat.com>
> To: "Alon Bar-Lev" <alonbl at redhat.com>
> Cc: "David Caro" <dcaroest at redhat.com>, "engine-devel" <engine-devel at ovirt.org>, vdsm-devel at lists.fedorahosted.org
> Sent: Monday, September 23, 2013 1:54:39 PM
> Subject: Re: [vdsm] stale gerrit patches
> 
> On 09/23/2013 01:52 PM, Alon Bar-Lev wrote:
> >
> >
> > ----- Original Message -----
> >> From: "Itamar Heim" <iheim at redhat.com>
> >> To: "Alon Bar-Lev" <alonbl at redhat.com>
> >> Cc: "David Caro" <dcaroest at redhat.com>, "engine-devel"
> >> <engine-devel at ovirt.org>, vdsm-devel at lists.fedorahosted.org
> >> Sent: Monday, September 23, 2013 1:50:35 PM
> >> Subject: Re: [vdsm] stale gerrit patches
> >>
> >> On 09/23/2013 01:49 PM, Alon Bar-Lev wrote:
> >>>
> >>>
> >>> ----- Original Message -----
> >>>> From: "Itamar Heim" <iheim at redhat.com>
> >>>> To: "David Caro" <dcaroest at redhat.com>
> >>>> Cc: "engine-devel" <engine-devel at ovirt.org>,
> >>>> vdsm-devel at lists.fedorahosted.org
> >>>> Sent: Monday, September 23, 2013 1:47:47 PM
> >>>> Subject: Re: [vdsm] stale gerrit patches
> >>>>
> >>>> On 09/23/2013 01:46 PM, David Caro wrote:
> >>>>> On Mon 23 Sep 2013 12:36:58 PM CEST, Itamar Heim wrote:
> >>>>>> we have some very old gerrit patches.
> >>>>>> I'm for abandoning patches which were not touched over 60 days (to
> >>>>>> begin with, I think the number should actually be lower).
> >>>>>> they can always be re-opened by any interested party post their
> >>>>>> closure.
> >>>>>>
> >>>>>> i.e., looking at gerrit, the patch list should actually get attention,
> >>>>>> and not be a few worth looking at, with a "lot of old patches"
> >>>>>>
> >>>>>> thoughts?
> >>>>>>
> >>>>>> Thanks,
> >>>>>>       Itamar
> >>>>>> _______________________________________________
> >>>>>> vdsm-devel mailing list
> >>>>>> vdsm-devel at lists.fedorahosted.org
> >>>>>> https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
> >>>>>
> >>>>> It might helpful to have a cron-like script that checks the age of the
> >>>>> posts and first notifies the sender, the reviewers and the maintainer,
> >>>>> and if the patch is not updated in a certain period just abandons it.
> >>>>>
> >>>>
> >>>> yep - warn after X days via email to just owner (or all subscribed to
> >>>> the patch), and close if no activity for X+14 days or something like
> >>>> that.
> >>>
> >>> This will be annoying.
> >>>
> >>> And there are patches that pending with good reason.
> >>
> >> pending for 60 days with zero activity on them (no comment, no rebase,
> >> nothing)?
> >
> > http://gerrit.ovirt.org/#/q/status:open+project:ovirt-engine+branch:master+topic:independent_deployments,n,z
> 
> so how does it help us to have these patches, some without any comment
> from any reviewer.
> lets get them reviewed and decide one way or the other, rather than let
> them get old and stay forever

Again... maintainer can close these if he likes.
Owner can close these if he likes.

The problem is that maintainers avoid closing.
And that there are people who submitted patches without CC anyone and gone.

So a simple logic can be applied after we add metadata into tree:

1. If no maintainer is CCed on change, close that change within short cycle (can be even a week).
2. Maintainer to close patches that have no interest in.

> 
> >
> >>
> >>>
> >>> Maintainers can close patches that are no interest nor progress.
> >>>
> >>> Alon
> >>>
> >>
> >>
> 
> 


From alourie at redhat.com  Mon Sep 23 13:38:17 2013
From: alourie at redhat.com (Alex Lourie)
Date: Mon, 23 Sep 2013 09:38:17 -0400 (EDT)
Subject: [Engine-devel] Suggesting new packaging and setup maintainer
In-Reply-To: <1271829417.461834.1379933376488.JavaMail.root@redhat.com>
References: <1271829417.461834.1379933376488.JavaMail.root@redhat.com>
Message-ID: <285143418.448143.1379943497659.JavaMail.root@redhat.com>

Absolutely agree. Sandro has done a great work on the project, and personally helped me solve a lot of issues in the development of installation utilities and packaging. I think he'll be a responsible maintainer.

-- 

Best regards,

Alex Lourie
Software Developer in Integration
Red Hat


----- Original Message -----
> From: "Ofer Schreiber" <oschreib at redhat.com>
> To: "board" <board at ovirt.org>, "engine-devel" <engine-devel at ovirt.org>
> Sent: Monday, September 23, 2013 12:49:36 PM
> Subject: [Engine-devel] Suggesting new packaging and setup maintainer
> 
> Nominating Sandro Bonazzola as packaging and setup maintainer
> ----------------------------------------------------------
> 
> During his recent year of participation in ovirt-engine development,
> Sandro demonstrated a genuine care for the product health, great coding
> abilities,
> and great responsibility to the setup and packaging components.
> 
> Sandro's contribution the the project is undoubtable, he's responsible for
> over 70 patches in ovirt-engine,
> and he's the maintainer of log-collector, iso-uploader and image-uploader
> packages.
> 
> I suggest that Sandro will obtain +2 and merge rights in the ovirt-engine
> gerrit project,
> in the understanding that those rights should be used only in packaging and
> setup parts of the code.
> 
> --
> Ofer Schreiber.
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From Christopher.Morrissey at netapp.com  Mon Sep 23 13:43:40 2013
From: Christopher.Morrissey at netapp.com (Morrissey, Christopher)
Date: Mon, 23 Sep 2013 13:43:40 +0000
Subject: [Engine-devel] External events and flood rate
In-Reply-To: <5240197F.7090708@redhat.com>
References: <D290AD8432118048947689BA3AE8A9B33C9B351C@SACEXCMBX04-PRD.hq.netapp.com>
	<5240197F.7090708@redhat.com>
Message-ID: <D290AD8432118048947689BA3AE8A9B33C9B6BA2@SACEXCMBX04-PRD.hq.netapp.com>

Thanks for looking into this Michael. Only allowing one external event every 30 seconds seems like kind of a high initial setting. However, I've put in a workaround on our side that will retry sending the event after 30 seconds and queue the rest if an error is received while logging.

-Chris

> -----Original Message-----
> From: Michael Pasternak [mailto:mpastern at redhat.com]
> Sent: Monday, September 23, 2013 6:36 AM
> To: Eli Mesika
> Cc: Morrissey, Christopher; engine-devel at ovirt.org
> Subject: Re: [Engine-devel] External events and flood rate
> 
> Eli,
> 
> any reason for hardcoding this [1]? i'd move it to vdc_config.
> 
> [1] Math.max(auditLogable.getEventFloodInSec(), 30) // Min duration for
> External Events is 30 sec
> 
> On 09/19/2013 12:50 AM, Morrissey, Christopher wrote:
> > Hi All,
> >
> >
> >
> > I've been working on submitting external events to oVirt through the
> > REST API. It seems to be working in general, although it appears that,
> > no matter what value I put for the flood rate in the event, only 1 or
> > so events are allowed every 30 seconds. If I send another event during this
> time, I get an operation failed exception. Should the flood rate have any
> impact on this? Is there any way to allow my code to get an event through
> when needed or should I have a thread that shoots them off every 30
> seconds if several occur too quickly together?
> >
> >
> >
> > -Chris
> >
> >
> >
> > *Chris Morrissey*
> >
> > Software Engineer
> >
> > NetApp Inc.
> >
> > 919.476.4428
> >
> >
> >
> >
> >
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> >
> 
> 
> --
> 
> Michael Pasternak
> RedHat, ENG-Virtualization R&D


From eedri at redhat.com  Mon Sep 23 14:10:40 2013
From: eedri at redhat.com (Eyal Edri)
Date: Mon, 23 Sep 2013 10:10:40 -0400 (EDT)
Subject: [Engine-devel] Suggesting new packaging and setup maintainer
In-Reply-To: <1271829417.461834.1379933376488.JavaMail.root@redhat.com>
References: <1271829417.461834.1379933376488.JavaMail.root@redhat.com>
Message-ID: <111394145.784109.1379945440471.JavaMail.root@redhat.com>

+1.

Agree and fully support the nomination for sandro as maintainer for ovirt-engine.

Eyal.

----- Original Message -----
> From: "Ofer Schreiber" <oschreib at redhat.com>
> To: "board" <board at ovirt.org>, "engine-devel" <engine-devel at ovirt.org>
> Sent: Monday, September 23, 2013 1:49:36 PM
> Subject: [Engine-devel] Suggesting new packaging and setup maintainer
> 
> Nominating Sandro Bonazzola as packaging and setup maintainer
> ----------------------------------------------------------
> 
> During his recent year of participation in ovirt-engine development,
> Sandro demonstrated a genuine care for the product health, great coding
> abilities,
> and great responsibility to the setup and packaging components.
> 
> Sandro's contribution the the project is undoubtable, he's responsible for
> over 70 patches in ovirt-engine,
> and he's the maintainer of log-collector, iso-uploader and image-uploader
> packages.
> 
> I suggest that Sandro will obtain +2 and merge rights in the ovirt-engine
> gerrit project,
> in the understanding that those rights should be used only in packaging and
> setup parts of the code.
> 
> --
> Ofer Schreiber.
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From deadhorseconsulting at gmail.com  Mon Sep 23 17:32:17 2013
From: deadhorseconsulting at gmail.com (Dead Horse)
Date: Mon, 23 Sep 2013 12:32:17 -0500
Subject: [Engine-devel] disk quota broken in latest master
In-Reply-To: <150921523.425174.1379925883501.JavaMail.root@redhat.com>
References: <CAEWPe=qQH=rzNXdo=aU-urayOtvW=Ja6M0B_t57MAVnGi73FYA@mail.gmail.com>
	<CAEWPe=rnx2xTwBtLtWy+yOW25OARN4ApN_aYxntOst-ETnMq5g@mail.gmail.com>
	<CAEWPe=qcue=wXSojoyVy1WORK=vLuaDSTVCEAwsUXjdX5zHUeA@mail.gmail.com>
	<1457079272.184456.1379834144326.JavaMail.root@redhat.com>
	<150921523.425174.1379925883501.JavaMail.root@redhat.com>
Message-ID: <CAEWPe=oR-_Lep34t4wy4ENo6t30AUY3p5uCMPTWgMbJBj8LgDg@mail.gmail.com>

BZ1011175 (https://bugzilla.redhat.com/show_bug.cgi?id=1011175) Opened
- DHC


On Mon, Sep 23, 2013 at 3:44 AM, Gilad Chaplik <gchaplik at redhat.com> wrote:

> http://gerrit.ovirt.org/#/c/19432/ [merged] should fix it.
>
> Thanks,
> Gilad.
>
> ----- Original Message -----
> > From: "Gilad Chaplik" <gchaplik at redhat.com>
> > To: "Dead Horse" <deadhorseconsulting at gmail.com>
> > Cc: "engine-devel" <engine-devel at ovirt.org>
> > Sent: Sunday, September 22, 2013 9:15:44 AM
> > Subject: Re: [Engine-devel] disk quota broken in latest master
> >
> > Hi,
> >
> > looks like the quota drop-down isn't getting refreshed according to
> selected
> > storage domain.
> > can you please open a bug?
> >
> > Thanks,
> > Gilad.
> >
> > ----- Original Message -----
> > > From: "Dead Horse" <deadhorseconsulting at gmail.com>
> > > To: "engine-devel" <engine-devel at ovirt.org>
> > > Sent: Friday, September 20, 2013 9:44:20 PM
> > > Subject: Re: [Engine-devel] disk quota broken in latest master
> > >
> > > In further testing I note that assign quota under the disks tab of the
> > > associated vm in the admin portal does work.
> > > - DHC
> > >
> > >
> > > On Fri, Sep 20, 2013 at 2:24 PM, Dead Horse <
> deadhorseconsulting at gmail.com
> > > >
> > > wrote:
> > >
> > >
> > >
> > >
> > > really attach the logs
> > >
> > > I also notice that disks tab is no longer showing a disk inventory as
> well.
> > >
> > > - DHC
> > >
> > >
> > > On Fri, Sep 20, 2013 at 2:15 PM, Dead Horse <
> deadhorseconsulting at gmail.com
> > > >
> > > wrote:
> > >
> > >
> > >
> > > When attempting to add a disk from either the admin or power user
> portals
> > > the
> > > according disk quota associated with the requested storage domain
> cannot be
> > > assigned to the disk. The disk quota pull-down only will only display
> > > whatever quota is first in the list alphabetically.
> > > - DHC
> > >
> > > engine and vdsm logs attached.
> > >
> > > 2013-09-20 13:56:36,810 INFO [org.ovirt.engine.core.bll.
> > > LoginUserCommand] (ajp--127.0.0.1-8702-4) Running command:
> LoginUserCommand
> > > internal: false.
> > > 2013-09-20 13:56:36,833 INFO
> > > [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
> > > (ajp--127.0.0.1-8702-4) Correlation ID: null, Call Stack: null, Custom
> > > Event
> > > ID: -1, Message: User admin at internal logged in.
> > > 2013-09-20 13:56:45,775 ERROR
> > > [org.ovirt.engine.core.utils.servlet.ServletUtils]
> (ajp--127.0.0.1-8702-6)
> > > Can't read file
> "/usr/share/doc/ovirt-engine/manual/DocumentationPath.csv"
> > > for request "/docs/DocumentationPath.csv", will send a 404 error
> response.
> > > 2013-09-20 13:57:00,456 INFO
> [org.ovirt.engine.core.bll.quota.QuotaManager]
> > > (DefaultQuartzScheduler_Worker-72) Quota Cache updated. (26 msec)
> > > 2013-09-20 13:57:01,810 INFO [org.ovirt.engine.core.bll.AddDiskCommand]
> > > (ajp--127.0.0.1-8702-10) Lock Acquired to object EngineLock
> > > [exclusiveLocks=
> > > key: ca3cecf1-090e-469a-aaad-e26ce47f89d8 value: VM_DISK_BOOT
> > > , sharedLocks= key: ca3cecf1-090e-469a-aaad-e26ce47f89d8 value: VM
> > > ]
> > > 2013-09-20 13:57:01,863 ERROR
> > > [org.ovirt.engine.core.bll.quota.QuotaManager]
> > > (ajp--127.0.0.1-8702-10) Quota storage parameters from command:
> > > org.ovirt.engine.core.bll.AddDiskCommand. Storage domain does not match
> > > quota
> > > 2013-09-20 13:57:01,901 INFO
> > > [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
> > > (ajp--127.0.0.1-8702-10) Correlation ID: 5790e811, Job ID:
> > > 7abd0b95-4cd4-4cb5-864c-d51c4446a42d, Call Stack: null, Custom Event
> ID:
> > > -1,
> > > Message: Missing Quota for Disk, proceeding since in Permissive (Audit)
> > > mode.
> > > 2013-09-20 13:57:01,937 INFO [org.ovirt.engine.core.bll.AddDiskCommand]
> > > (ajp--127.0.0.1-8702-10) Running command: AddDiskCommand internal:
> false.
> > > Entities affected : ID: ca3cecf1-090e-469a-aaad-e26ce47f89d8 Type: VM,
> ID:
> > > 26be0640-01a3-415d-82c9-0a92f2f84c3f Type: Storage
> > > 2013-09-20 13:57:02,325 INFO
> > > [org.ovirt.engine.core.bll.AddImageFromScratchCommand]
> > > (ajp--127.0.0.1-8702-10) Running command: AddImageFromScratchCommand
> > > internal: true. Entities affected : ID:
> > > 26be0640-01a3-415d-82c9-0a92f2f84c3f
> > > Type: Storage
> > > 2013-09-20 13:57:02,446 INFO
> > > [org.ovirt.engine.core.bll.AddImageFromScratchCommand]
> > > (ajp--127.0.0.1-8702-10) Lock freed to object EngineLock
> [exclusiveLocks=
> > > key: ca3cecf1-090e-469a-aaad-e26ce47f89d8 value: VM_DISK_BOOT
> > > , sharedLocks= key: ca3cecf1-090e-469a-aaad-e26ce47f89d8 value: VM
> > > ]
> > > 2013-09-20 13:57:02,451 INFO
> > > [org.ovirt.engine.core.vdsbroker.irsbroker.CreateImageVDSCommand]
> > > (ajp--127.0.0.1-8702-10) START, CreateImageVDSCommand( storagePoolId =
> > > 5849b030-626e-47cb-ad90-3ce782d831b3, ignoreFailoverLimit = false,
> > > storageDomainId = 26be0640-01a3-415d-82c9-0a92f2f84c3f, imageGroupId =
> > > bf6458bc-627a-4399-822d-f72751edf303, imageSizeInBytes = 1073741824,
> > > volumeFormat = RAW, newImageId = 165089b7-4737-4900-9a7f-d2d888ec3514,
> > > newImageDescription = ), log id: 1ef8212d
> > > 2013-09-20 13:57:02,454 INFO
> > > [org.ovirt.engine.core.vdsbroker.irsbroker.CreateImageVDSCommand]
> > > (ajp--127.0.0.1-8702-10) -- executeIrsBrokerCommand: calling
> 'createVolume'
> > > with two new parameters: description and UUID
> > > 2013-09-20 13:57:02,456 INFO
> > > [org.ovirt.engine.core.vdsbroker.irsbroker.CreateImageVDSCommand]
> > > (ajp--127.0.0.1-8702-10) -- createVolume parameters:
> > >
> > > sdUUID=26be0640-01a3-415d-82c9-0a92f2f84c3f
> > >
> > > spUUID=5849b030-626e-47cb-ad90-3ce782d831b3
> > >
> > > imgGUID=bf6458bc-627a-4399-822d-f72751edf303
> > >
> > > size=1,073,741,824 bytes
> > >
> > > volFormat=RAW
> > >
> > > volType=Sparse
> > >
> > > volUUID=165089b7-4737-4900-9a7f-d2d888ec3514
> > >
> > > descr=
> > >
> > > srcImgGUID=00000000-0000-0000-0000-000000000000
> > >
> > > srcVolUUID=00000000-0000-0000-0000-000000000000
> > >
> > >
> > > 2013-09-20 13:57:02,489 INFO
> > > [org.ovirt.engine.core.vdsbroker.irsbroker.CreateImageVDSCommand]
> > > (ajp--127.0.0.1-8702-10) FINISH, CreateImageVDSCommand, return:
> > > 165089b7-4737-4900-9a7f-d2d888ec3514, log id: 1ef8212d
> > >
> > >
> > >
> > > _______________________________________________
> > > Engine-devel mailing list
> > > Engine-devel at ovirt.org
> > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > >
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20130923/f26358d9/attachment.html>

From ewoud+ovirt at kohlvanwijngaarden.nl  Mon Sep 23 18:39:31 2013
From: ewoud+ovirt at kohlvanwijngaarden.nl (Ewoud Kohl van Wijngaarden)
Date: Mon, 23 Sep 2013 20:39:31 +0200
Subject: [Engine-devel] Jenkins upgrade on Thursday at 20:00 UTC
Message-ID: <20130923183931.GB12411@bogey.xentower.nl>

As in the subject, on Thursday at 20:00 UTC I'll update jenkins to the
latest LTS release. The downtime is expected to be minimal.


From vitor.lima at eldorado.org.br  Mon Sep 23 19:42:39 2013
From: vitor.lima at eldorado.org.br (Vitor de Lima)
Date: Mon, 23 Sep 2013 19:42:39 +0000
Subject: [Engine-devel] Issues with VirtIO-SCSI
Message-ID: <B2CAFC4D5E2D574A883EF61ACD5ADE330181AB51@SERV070.corp.eldorado.org.br>

Hi everyone,

I have found some issues with this patch:

http://gerrit.ovirt.org/#/c/18638/

It allows the user to disable the VirtIO-SCSI disk interface during the VM creation. The problem is that the user still can add, attach and hotplug disks with the VirtIO-SCSI interface type, but when the user does so, libvirt automatically creates a LSI Logic SCSI controller and connects the new disk to it.

How can this problem be solved? Should the VirtIO-SCSI interface type be hidden from the user in case it wasn't enabled, or should the engine enable the VirtIO-SCSI controller, hotplug it, then hotplug the disk into it transparently?

Thanks,
Vitor de Lima



From derez at redhat.com  Mon Sep 23 20:05:41 2013
From: derez at redhat.com (Daniel Erez)
Date: Mon, 23 Sep 2013 16:05:41 -0400 (EDT)
Subject: [Engine-devel] Issues with VirtIO-SCSI
In-Reply-To: <B2CAFC4D5E2D574A883EF61ACD5ADE330181AB51@SERV070.corp.eldorado.org.br>
References: <B2CAFC4D5E2D574A883EF61ACD5ADE330181AB51@SERV070.corp.eldorado.org.br>
Message-ID: <1435657800.857208.1379966741270.JavaMail.root@redhat.com>

Hi Vitor,

The new VirtIO-SCSI enabled checkbox is an indication whether to
attach a VirtIO-SCSI controller when running the VM.
It should be enabled automatically on cluster >= 3.3.

When disabled, I think it's preferable not to add a new controller
automatically when running the VM as it requires creating/attaching
a new VmDevice - which we refrain of on VmInfoBuilder flows
(and since it might be confusing to the user...).

As an alternative, I've planned to add a warning in the dialog
or create a canDo message to prevent running the VM at all.
I'm not sure we should hide the option from disk interfaces
list as it's already being filtered using VirtIoScsiEnabled
ConfigurationValue (and using OsInfo soon...).

Let me know what you think and thanks a lot for the input!

Daniel

----- Original Message -----
> From: "Vitor de Lima" <vitor.lima at eldorado.org.br>
> To: engine-devel at ovirt.org
> Sent: Monday, September 23, 2013 10:42:39 PM
> Subject: [Engine-devel] Issues with VirtIO-SCSI
> 
> Hi everyone,
> 
> I have found some issues with this patch:
> 
> http://gerrit.ovirt.org/#/c/18638/
> 
> It allows the user to disable the VirtIO-SCSI disk interface during the VM
> creation. The problem is that the user still can add, attach and hotplug
> disks with the VirtIO-SCSI interface type, but when the user does so,
> libvirt automatically creates a LSI Logic SCSI controller and connects the
> new disk to it.
> 
> How can this problem be solved? Should the VirtIO-SCSI interface type be
> hidden from the user in case it wasn't enabled, or should the engine enable
> the VirtIO-SCSI controller, hotplug it, then hotplug the disk into it
> transparently?
> 
> Thanks,
> Vitor de Lima
> 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From abaron at redhat.com  Mon Sep 23 21:21:23 2013
From: abaron at redhat.com (Ayal Baron)
Date: Mon, 23 Sep 2013 17:21:23 -0400 (EDT)
Subject: [Engine-devel] [vdsm] stale gerrit patches
In-Reply-To: <12011846.220527.1379933951518.JavaMail.root@redhat.com>
References: <524019CA.3080608@redhat.com> <52401BF4.5090800@redhat.com>
	<52401C53.20702@redhat.com>
	<661632990.218831.1379933391058.JavaMail.root@redhat.com>
	<52401CFB.1040300@redhat.com>
	<444143941.219431.1379933576061.JavaMail.root@redhat.com>
	<52401DEF.10607@redhat.com>
	<12011846.220527.1379933951518.JavaMail.root@redhat.com>
Message-ID: <370781592.886801.1379971283176.JavaMail.root@redhat.com>



----- Original Message -----
> 
> 
> ----- Original Message -----
> > From: "Itamar Heim" <iheim at redhat.com>
> > To: "Alon Bar-Lev" <alonbl at redhat.com>
> > Cc: "David Caro" <dcaroest at redhat.com>, "engine-devel"
> > <engine-devel at ovirt.org>, vdsm-devel at lists.fedorahosted.org
> > Sent: Monday, September 23, 2013 1:54:39 PM
> > Subject: Re: [vdsm] stale gerrit patches
> > 
> > On 09/23/2013 01:52 PM, Alon Bar-Lev wrote:
> > >
> > >
> > > ----- Original Message -----
> > >> From: "Itamar Heim" <iheim at redhat.com>
> > >> To: "Alon Bar-Lev" <alonbl at redhat.com>
> > >> Cc: "David Caro" <dcaroest at redhat.com>, "engine-devel"
> > >> <engine-devel at ovirt.org>, vdsm-devel at lists.fedorahosted.org
> > >> Sent: Monday, September 23, 2013 1:50:35 PM
> > >> Subject: Re: [vdsm] stale gerrit patches
> > >>
> > >> On 09/23/2013 01:49 PM, Alon Bar-Lev wrote:
> > >>>
> > >>>
> > >>> ----- Original Message -----
> > >>>> From: "Itamar Heim" <iheim at redhat.com>
> > >>>> To: "David Caro" <dcaroest at redhat.com>
> > >>>> Cc: "engine-devel" <engine-devel at ovirt.org>,
> > >>>> vdsm-devel at lists.fedorahosted.org
> > >>>> Sent: Monday, September 23, 2013 1:47:47 PM
> > >>>> Subject: Re: [vdsm] stale gerrit patches
> > >>>>
> > >>>> On 09/23/2013 01:46 PM, David Caro wrote:
> > >>>>> On Mon 23 Sep 2013 12:36:58 PM CEST, Itamar Heim wrote:
> > >>>>>> we have some very old gerrit patches.
> > >>>>>> I'm for abandoning patches which were not touched over 60 days (to
> > >>>>>> begin with, I think the number should actually be lower).
> > >>>>>> they can always be re-opened by any interested party post their
> > >>>>>> closure.
> > >>>>>>
> > >>>>>> i.e., looking at gerrit, the patch list should actually get
> > >>>>>> attention,
> > >>>>>> and not be a few worth looking at, with a "lot of old patches"
> > >>>>>>
> > >>>>>> thoughts?
> > >>>>>>
> > >>>>>> Thanks,
> > >>>>>>       Itamar
> > >>>>>> _______________________________________________
> > >>>>>> vdsm-devel mailing list
> > >>>>>> vdsm-devel at lists.fedorahosted.org
> > >>>>>> https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
> > >>>>>
> > >>>>> It might helpful to have a cron-like script that checks the age of
> > >>>>> the
> > >>>>> posts and first notifies the sender, the reviewers and the
> > >>>>> maintainer,
> > >>>>> and if the patch is not updated in a certain period just abandons it.
> > >>>>>
> > >>>>
> > >>>> yep - warn after X days via email to just owner (or all subscribed to
> > >>>> the patch), and close if no activity for X+14 days or something like
> > >>>> that.
> > >>>
> > >>> This will be annoying.
> > >>>
> > >>> And there are patches that pending with good reason.
> > >>
> > >> pending for 60 days with zero activity on them (no comment, no rebase,
> > >> nothing)?
> > >
> > > http://gerrit.ovirt.org/#/q/status:open+project:ovirt-engine+branch:master+topic:independent_deployments,n,z
> > 
> > so how does it help us to have these patches, some without any comment
> > from any reviewer.
> > lets get them reviewed and decide one way or the other, rather than let
> > them get old and stay forever
> 
> Again... maintainer can close these if he likes.
> Owner can close these if he likes.

right, but why?
a patch without activity being abandoned might actually spur someone into motion (rebasing and resubmitting, prodding maintainers etc).
I'm +1 for automatically abandoning old patches.

> 
> The problem is that maintainers avoid closing.
> And that there are people who submitted patches without CC anyone and gone.
> 
> So a simple logic can be applied after we add metadata into tree:
> 
> 1. If no maintainer is CCed on change, close that change within short cycle
> (can be even a week).
> 2. Maintainer to close patches that have no interest in.
> 
> > 
> > >
> > >>
> > >>>
> > >>> Maintainers can close patches that are no interest nor progress.
> > >>>
> > >>> Alon
> > >>>
> > >>
> > >>
> > 
> > 
> _______________________________________________
> vdsm-devel mailing list
> vdsm-devel at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
> 


From vitor.lima at eldorado.org.br  Mon Sep 23 21:34:17 2013
From: vitor.lima at eldorado.org.br (Vitor de Lima)
Date: Mon, 23 Sep 2013 21:34:17 +0000
Subject: [Engine-devel] Issues with VirtIO-SCSI
In-Reply-To: <1435657800.857208.1379966741270.JavaMail.root@redhat.com>
References: <B2CAFC4D5E2D574A883EF61ACD5ADE330181AB51@SERV070.corp.eldorado.org.br>
	<1435657800.857208.1379966741270.JavaMail.root@redhat.com>
Message-ID: <B2CAFC4D5E2D574A883EF61ACD5ADE330181AC9B@SERV070.corp.eldorado.org.br>

Hi Daniel,

I asked this question because I have implemented a filter to show only compatible disk interfaces (in change #17964). The main purpose of this patch is to hide the IDE interface type when creating disks for PPC64 VMs (since IDE is not supported on this architecture). If it was decided that the VirtIO-SCSI interface type should be hidden from the user in case it was disabled, I would have to modify that patch a little bit.

Another issue is that in change #18622 the support for a PPC64-specific controller, the SPAPR VSCSI controller, was introduced. But the code was created based on the assumption that the VirtIO-SCSI controller was always present, and this isn't the case anymore. And another patch that I will work on really soon will add support to create disks that are connected to this interface.

So, I would like some feedback before changing these patches. Is a validation on the backend enough to block the user from using an inexistent controller? Should the frontend be changed as well? What would be a good approach to handle multiple SCSI controllers in a VM (were the presence of one of them is optional)?

Thanks,
Vitor



>-----Original Message-----
>From: Daniel Erez [mailto:derez at redhat.com]
>Sent: segunda-feira, 23 de setembro de 2013 17:06
>To: Vitor de Lima
>Cc: engine-devel at ovirt.org
>Subject: Re: [Engine-devel] Issues with VirtIO-SCSI
>
>Hi Vitor,
>
>The new VirtIO-SCSI enabled checkbox is an indication whether to attach a
>VirtIO-SCSI controller when running the VM.
>It should be enabled automatically on cluster >= 3.3.
>
>When disabled, I think it's preferable not to add a new controller automatically
>when running the VM as it requires creating/attaching a new VmDevice -
>which we refrain of on VmInfoBuilder flows (and since it might be confusing to
>the user...).
>
>As an alternative, I've planned to add a warning in the dialog or create a canDo
>message to prevent running the VM at all.
>I'm not sure we should hide the option from disk interfaces list as it's already
>being filtered using VirtIoScsiEnabled ConfigurationValue (and using OsInfo
>soon...).
>
>Let me know what you think and thanks a lot for the input!
>
>Daniel
>
>----- Original Message -----
>> From: "Vitor de Lima" <vitor.lima at eldorado.org.br>
>> To: engine-devel at ovirt.org
>> Sent: Monday, September 23, 2013 10:42:39 PM
>> Subject: [Engine-devel] Issues with VirtIO-SCSI
>>
>> Hi everyone,
>>
>> I have found some issues with this patch:
>>
>> http://gerrit.ovirt.org/#/c/18638/
>>
>> It allows the user to disable the VirtIO-SCSI disk interface during
>> the VM creation. The problem is that the user still can add, attach
>> and hotplug disks with the VirtIO-SCSI interface type, but when the
>> user does so, libvirt automatically creates a LSI Logic SCSI
>> controller and connects the new disk to it.
>>
>> How can this problem be solved? Should the VirtIO-SCSI interface type
>> be hidden from the user in case it wasn't enabled, or should the
>> engine enable the VirtIO-SCSI controller, hotplug it, then hotplug the
>> disk into it transparently?
>>
>> Thanks,
>> Vitor de Lima
>>
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>

From abaron at redhat.com  Mon Sep 23 22:23:43 2013
From: abaron at redhat.com (Ayal Baron)
Date: Mon, 23 Sep 2013 18:23:43 -0400 (EDT)
Subject: [Engine-devel] Issues with VirtIO-SCSI
In-Reply-To: <B2CAFC4D5E2D574A883EF61ACD5ADE330181AC9B@SERV070.corp.eldorado.org.br>
References: <B2CAFC4D5E2D574A883EF61ACD5ADE330181AB51@SERV070.corp.eldorado.org.br>
	<1435657800.857208.1379966741270.JavaMail.root@redhat.com>
	<B2CAFC4D5E2D574A883EF61ACD5ADE330181AC9B@SERV070.corp.eldorado.org.br>
Message-ID: <110977464.903665.1379975023607.JavaMail.root@redhat.com>



----- Original Message -----
> Hi Daniel,
> 
> I asked this question because I have implemented a filter to show only
> compatible disk interfaces (in change #17964). The main purpose of this
> patch is to hide the IDE interface type when creating disks for PPC64 VMs
> (since IDE is not supported on this architecture). If it was decided that
> the VirtIO-SCSI interface type should be hidden from the user in case it was
> disabled, I would have to modify that patch a little bit.

That is not the case.  Point is to allow users to add a scsi controller to a VM that does not have any scsi disks. This is needed in case the user would later on like to hotplug scsi disks.  Without this, hotplug would fail since there is no scsi controller in the VM.
When the VM is down, you can always attach a scsi disk and if there is no scsi controller then engine will automatically add one.

> 
> Another issue is that in change #18622 the support for a PPC64-specific
> controller, the SPAPR VSCSI controller, was introduced. But the code was
> created based on the assumption that the VirtIO-SCSI controller was always
> present, and this isn't the case anymore. And another patch that I will work
> on really soon will add support to create disks that are connected to this
> interface.
> 
> So, I would like some feedback before changing these patches. Is a validation
> on the backend enough to block the user from using an inexistent controller?
> Should the frontend be changed as well? What would be a good approach to
> handle multiple SCSI controllers in a VM (were the presence of one of them
> is optional)?

If you have a need for a VM with more than 256 LUNs then I'd say that the easiest behaviour to understand would be to hide the existence of the controllers from the user altogether and just add support to automatically hotplug controllers on the fly when existing controllers are reaching their limit.


> 
> Thanks,
> Vitor
> 
> 
> 
> >-----Original Message-----
> >From: Daniel Erez [mailto:derez at redhat.com]
> >Sent: segunda-feira, 23 de setembro de 2013 17:06
> >To: Vitor de Lima
> >Cc: engine-devel at ovirt.org
> >Subject: Re: [Engine-devel] Issues with VirtIO-SCSI
> >
> >Hi Vitor,
> >
> >The new VirtIO-SCSI enabled checkbox is an indication whether to attach a
> >VirtIO-SCSI controller when running the VM.
> >It should be enabled automatically on cluster >= 3.3.
> >
> >When disabled, I think it's preferable not to add a new controller
> >automatically
> >when running the VM as it requires creating/attaching a new VmDevice -
> >which we refrain of on VmInfoBuilder flows (and since it might be confusing
> >to
> >the user...).
> >
> >As an alternative, I've planned to add a warning in the dialog or create a
> >canDo
> >message to prevent running the VM at all.
> >I'm not sure we should hide the option from disk interfaces list as it's
> >already
> >being filtered using VirtIoScsiEnabled ConfigurationValue (and using OsInfo
> >soon...).
> >
> >Let me know what you think and thanks a lot for the input!
> >
> >Daniel
> >
> >----- Original Message -----
> >> From: "Vitor de Lima" <vitor.lima at eldorado.org.br>
> >> To: engine-devel at ovirt.org
> >> Sent: Monday, September 23, 2013 10:42:39 PM
> >> Subject: [Engine-devel] Issues with VirtIO-SCSI
> >>
> >> Hi everyone,
> >>
> >> I have found some issues with this patch:
> >>
> >> http://gerrit.ovirt.org/#/c/18638/
> >>
> >> It allows the user to disable the VirtIO-SCSI disk interface during
> >> the VM creation. The problem is that the user still can add, attach
> >> and hotplug disks with the VirtIO-SCSI interface type, but when the
> >> user does so, libvirt automatically creates a LSI Logic SCSI
> >> controller and connects the new disk to it.
> >>
> >> How can this problem be solved? Should the VirtIO-SCSI interface type
> >> be hidden from the user in case it wasn't enabled, or should the
> >> engine enable the VirtIO-SCSI controller, hotplug it, then hotplug the
> >> disk into it transparently?
> >>
> >> Thanks,
> >> Vitor de Lima
> >>
> >> _______________________________________________
> >> Engine-devel mailing list
> >> Engine-devel at ovirt.org
> >> http://lists.ovirt.org/mailman/listinfo/engine-devel
> >>
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From alonbl at redhat.com  Tue Sep 24 06:17:42 2013
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Tue, 24 Sep 2013 02:17:42 -0400 (EDT)
Subject: [Engine-devel] [vdsm] stale gerrit patches
In-Reply-To: <370781592.886801.1379971283176.JavaMail.root@redhat.com>
References: <524019CA.3080608@redhat.com> <52401C53.20702@redhat.com>
	<661632990.218831.1379933391058.JavaMail.root@redhat.com>
	<52401CFB.1040300@redhat.com>
	<444143941.219431.1379933576061.JavaMail.root@redhat.com>
	<52401DEF.10607@redhat.com>
	<12011846.220527.1379933951518.JavaMail.root@redhat.com>
	<370781592.886801.1379971283176.JavaMail.root@redhat.com>
Message-ID: <207419978.654820.1380003462357.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Ayal Baron" <abaron at redhat.com>
> To: "Alon Bar-Lev" <alonbl at redhat.com>
> Cc: "Itamar Heim" <iheim at redhat.com>, "engine-devel" <engine-devel at ovirt.org>, vdsm-devel at lists.fedorahosted.org
> Sent: Tuesday, September 24, 2013 12:21:23 AM
> Subject: Re: [vdsm] stale gerrit patches
> 
> 
> 
> ----- Original Message -----
> > 
> > 
> > ----- Original Message -----
> > > From: "Itamar Heim" <iheim at redhat.com>
> > > To: "Alon Bar-Lev" <alonbl at redhat.com>
> > > Cc: "David Caro" <dcaroest at redhat.com>, "engine-devel"
> > > <engine-devel at ovirt.org>, vdsm-devel at lists.fedorahosted.org
> > > Sent: Monday, September 23, 2013 1:54:39 PM
> > > Subject: Re: [vdsm] stale gerrit patches
> > > 
> > > On 09/23/2013 01:52 PM, Alon Bar-Lev wrote:
> > > >
> > > >
> > > > ----- Original Message -----
> > > >> From: "Itamar Heim" <iheim at redhat.com>
> > > >> To: "Alon Bar-Lev" <alonbl at redhat.com>
> > > >> Cc: "David Caro" <dcaroest at redhat.com>, "engine-devel"
> > > >> <engine-devel at ovirt.org>, vdsm-devel at lists.fedorahosted.org
> > > >> Sent: Monday, September 23, 2013 1:50:35 PM
> > > >> Subject: Re: [vdsm] stale gerrit patches
> > > >>
> > > >> On 09/23/2013 01:49 PM, Alon Bar-Lev wrote:
> > > >>>
> > > >>>
> > > >>> ----- Original Message -----
> > > >>>> From: "Itamar Heim" <iheim at redhat.com>
> > > >>>> To: "David Caro" <dcaroest at redhat.com>
> > > >>>> Cc: "engine-devel" <engine-devel at ovirt.org>,
> > > >>>> vdsm-devel at lists.fedorahosted.org
> > > >>>> Sent: Monday, September 23, 2013 1:47:47 PM
> > > >>>> Subject: Re: [vdsm] stale gerrit patches
> > > >>>>
> > > >>>> On 09/23/2013 01:46 PM, David Caro wrote:
> > > >>>>> On Mon 23 Sep 2013 12:36:58 PM CEST, Itamar Heim wrote:
> > > >>>>>> we have some very old gerrit patches.
> > > >>>>>> I'm for abandoning patches which were not touched over 60 days (to
> > > >>>>>> begin with, I think the number should actually be lower).
> > > >>>>>> they can always be re-opened by any interested party post their
> > > >>>>>> closure.
> > > >>>>>>
> > > >>>>>> i.e., looking at gerrit, the patch list should actually get
> > > >>>>>> attention,
> > > >>>>>> and not be a few worth looking at, with a "lot of old patches"
> > > >>>>>>
> > > >>>>>> thoughts?
> > > >>>>>>
> > > >>>>>> Thanks,
> > > >>>>>>       Itamar
> > > >>>>>> _______________________________________________
> > > >>>>>> vdsm-devel mailing list
> > > >>>>>> vdsm-devel at lists.fedorahosted.org
> > > >>>>>> https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
> > > >>>>>
> > > >>>>> It might helpful to have a cron-like script that checks the age of
> > > >>>>> the
> > > >>>>> posts and first notifies the sender, the reviewers and the
> > > >>>>> maintainer,
> > > >>>>> and if the patch is not updated in a certain period just abandons
> > > >>>>> it.
> > > >>>>>
> > > >>>>
> > > >>>> yep - warn after X days via email to just owner (or all subscribed
> > > >>>> to
> > > >>>> the patch), and close if no activity for X+14 days or something like
> > > >>>> that.
> > > >>>
> > > >>> This will be annoying.
> > > >>>
> > > >>> And there are patches that pending with good reason.
> > > >>
> > > >> pending for 60 days with zero activity on them (no comment, no rebase,
> > > >> nothing)?
> > > >
> > > > http://gerrit.ovirt.org/#/q/status:open+project:ovirt-engine+branch:master+topic:independent_deployments,n,z
> > > 
> > > so how does it help us to have these patches, some without any comment
> > > from any reviewer.
> > > lets get them reviewed and decide one way or the other, rather than let
> > > them get old and stay forever
> > 
> > Again... maintainer can close these if he likes.
> > Owner can close these if he likes.
> 
> right, but why?
> a patch without activity being abandoned might actually spur someone into
> motion (rebasing and resubmitting, prodding maintainers etc).
> I'm +1 for automatically abandoning old patches.
> 

I do not understand why maintainer should not have human interaction with its contributers.

> > 
> > The problem is that maintainers avoid closing.
> > And that there are people who submitted patches without CC anyone and gone.
> > 
> > So a simple logic can be applied after we add metadata into tree:
> > 
> > 1. If no maintainer is CCed on change, close that change within short cycle
> > (can be even a week).
> > 2. Maintainer to close patches that have no interest in.
> > 
> > > 
> > > >
> > > >>
> > > >>>
> > > >>> Maintainers can close patches that are no interest nor progress.
> > > >>>
> > > >>> Alon
> > > >>>
> > > >>
> > > >>
> > > 
> > > 
> > _______________________________________________
> > vdsm-devel mailing list
> > vdsm-devel at lists.fedorahosted.org
> > https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
> > 
> 


From abaron at redhat.com  Tue Sep 24 06:20:55 2013
From: abaron at redhat.com (Ayal Baron)
Date: Tue, 24 Sep 2013 02:20:55 -0400 (EDT)
Subject: [Engine-devel] [vdsm] stale gerrit patches
In-Reply-To: <207419978.654820.1380003462357.JavaMail.root@redhat.com>
References: <524019CA.3080608@redhat.com>
	<661632990.218831.1379933391058.JavaMail.root@redhat.com>
	<52401CFB.1040300@redhat.com>
	<444143941.219431.1379933576061.JavaMail.root@redhat.com>
	<52401DEF.10607@redhat.com>
	<12011846.220527.1379933951518.JavaMail.root@redhat.com>
	<370781592.886801.1379971283176.JavaMail.root@redhat.com>
	<207419978.654820.1380003462357.JavaMail.root@redhat.com>
Message-ID: <1431317823.1024654.1380003655261.JavaMail.root@redhat.com>



----- Original Message -----
> 
> 
> ----- Original Message -----
> > From: "Ayal Baron" <abaron at redhat.com>
> > To: "Alon Bar-Lev" <alonbl at redhat.com>
> > Cc: "Itamar Heim" <iheim at redhat.com>, "engine-devel"
> > <engine-devel at ovirt.org>, vdsm-devel at lists.fedorahosted.org
> > Sent: Tuesday, September 24, 2013 12:21:23 AM
> > Subject: Re: [vdsm] stale gerrit patches
> > 
> > 
> > 
> > ----- Original Message -----
> > > 
> > > 
> > > ----- Original Message -----
> > > > From: "Itamar Heim" <iheim at redhat.com>
> > > > To: "Alon Bar-Lev" <alonbl at redhat.com>
> > > > Cc: "David Caro" <dcaroest at redhat.com>, "engine-devel"
> > > > <engine-devel at ovirt.org>, vdsm-devel at lists.fedorahosted.org
> > > > Sent: Monday, September 23, 2013 1:54:39 PM
> > > > Subject: Re: [vdsm] stale gerrit patches
> > > > 
> > > > On 09/23/2013 01:52 PM, Alon Bar-Lev wrote:
> > > > >
> > > > >
> > > > > ----- Original Message -----
> > > > >> From: "Itamar Heim" <iheim at redhat.com>
> > > > >> To: "Alon Bar-Lev" <alonbl at redhat.com>
> > > > >> Cc: "David Caro" <dcaroest at redhat.com>, "engine-devel"
> > > > >> <engine-devel at ovirt.org>, vdsm-devel at lists.fedorahosted.org
> > > > >> Sent: Monday, September 23, 2013 1:50:35 PM
> > > > >> Subject: Re: [vdsm] stale gerrit patches
> > > > >>
> > > > >> On 09/23/2013 01:49 PM, Alon Bar-Lev wrote:
> > > > >>>
> > > > >>>
> > > > >>> ----- Original Message -----
> > > > >>>> From: "Itamar Heim" <iheim at redhat.com>
> > > > >>>> To: "David Caro" <dcaroest at redhat.com>
> > > > >>>> Cc: "engine-devel" <engine-devel at ovirt.org>,
> > > > >>>> vdsm-devel at lists.fedorahosted.org
> > > > >>>> Sent: Monday, September 23, 2013 1:47:47 PM
> > > > >>>> Subject: Re: [vdsm] stale gerrit patches
> > > > >>>>
> > > > >>>> On 09/23/2013 01:46 PM, David Caro wrote:
> > > > >>>>> On Mon 23 Sep 2013 12:36:58 PM CEST, Itamar Heim wrote:
> > > > >>>>>> we have some very old gerrit patches.
> > > > >>>>>> I'm for abandoning patches which were not touched over 60 days
> > > > >>>>>> (to
> > > > >>>>>> begin with, I think the number should actually be lower).
> > > > >>>>>> they can always be re-opened by any interested party post their
> > > > >>>>>> closure.
> > > > >>>>>>
> > > > >>>>>> i.e., looking at gerrit, the patch list should actually get
> > > > >>>>>> attention,
> > > > >>>>>> and not be a few worth looking at, with a "lot of old patches"
> > > > >>>>>>
> > > > >>>>>> thoughts?
> > > > >>>>>>
> > > > >>>>>> Thanks,
> > > > >>>>>>       Itamar
> > > > >>>>>> _______________________________________________
> > > > >>>>>> vdsm-devel mailing list
> > > > >>>>>> vdsm-devel at lists.fedorahosted.org
> > > > >>>>>> https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
> > > > >>>>>
> > > > >>>>> It might helpful to have a cron-like script that checks the age
> > > > >>>>> of
> > > > >>>>> the
> > > > >>>>> posts and first notifies the sender, the reviewers and the
> > > > >>>>> maintainer,
> > > > >>>>> and if the patch is not updated in a certain period just abandons
> > > > >>>>> it.
> > > > >>>>>
> > > > >>>>
> > > > >>>> yep - warn after X days via email to just owner (or all subscribed
> > > > >>>> to
> > > > >>>> the patch), and close if no activity for X+14 days or something
> > > > >>>> like
> > > > >>>> that.
> > > > >>>
> > > > >>> This will be annoying.
> > > > >>>
> > > > >>> And there are patches that pending with good reason.
> > > > >>
> > > > >> pending for 60 days with zero activity on them (no comment, no
> > > > >> rebase,
> > > > >> nothing)?
> > > > >
> > > > > http://gerrit.ovirt.org/#/q/status:open+project:ovirt-engine+branch:master+topic:independent_deployments,n,z
> > > > 
> > > > so how does it help us to have these patches, some without any comment
> > > > from any reviewer.
> > > > lets get them reviewed and decide one way or the other, rather than let
> > > > them get old and stay forever
> > > 
> > > Again... maintainer can close these if he likes.
> > > Owner can close these if he likes.
> > 
> > right, but why?
> > a patch without activity being abandoned might actually spur someone into
> > motion (rebasing and resubmitting, prodding maintainers etc).
> > I'm +1 for automatically abandoning old patches.
> > 
> 
> I do not understand why maintainer should not have human interaction with its
> contributers.

I do not understand the relation between the subject and the things you're saying.
Right now these patches are stale and are rotting, abandoning them could actually spur those interactions into motion.

> 
> > > 
> > > The problem is that maintainers avoid closing.
> > > And that there are people who submitted patches without CC anyone and
> > > gone.
> > > 
> > > So a simple logic can be applied after we add metadata into tree:
> > > 
> > > 1. If no maintainer is CCed on change, close that change within short
> > > cycle
> > > (can be even a week).
> > > 2. Maintainer to close patches that have no interest in.
> > > 
> > > > 
> > > > >
> > > > >>
> > > > >>>
> > > > >>> Maintainers can close patches that are no interest nor progress.
> > > > >>>
> > > > >>> Alon
> > > > >>>
> > > > >>
> > > > >>
> > > > 
> > > > 
> > > _______________________________________________
> > > vdsm-devel mailing list
> > > vdsm-devel at lists.fedorahosted.org
> > > https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
> > > 
> > 
> 


From sbonazzo at redhat.com  Tue Sep 24 06:30:11 2013
From: sbonazzo at redhat.com (Sandro Bonazzola)
Date: Tue, 24 Sep 2013 08:30:11 +0200
Subject: [Engine-devel] Jenkins job for ovirt-iso-uploader and
	ovirt-image-uploader
In-Reply-To: <1441035513.10888819.1378886213626.JavaMail.root@redhat.com>
References: <52300E48.2010504@redhat.com>
	<1441035513.10888819.1378886213626.JavaMail.root@redhat.com>
Message-ID: <52413173.2060708@redhat.com>

Hi oVirt community,
  following the previous discussion with infra team, I need to get power user rights for jenkins
in order to create a jenkins job for basic sanity testing of ovirt-iso-uploader and ovirt-image-uploader.
That said, I formally request a power user for jenkins (for those tools I'm already the maintainer)
in order to create new jobs for them as well and ask the community for acks.
Thanks,

Sandro Bonazzola



Il 11/09/2013 09:56, Eyal Edri ha scritto:
> Hi Sandro,
> 
> I assume we can create a new vm on rackspace to act as NFS server for the job,
> or even convert one of the existing jenkins slave vms to be one.
> 
> any other thoughts from the infra team?
> 
> Also, you will need to get a power user for jenkins (for tools) in order to create new jobs
> for them as well.
> The process for that is sending email to this list & engine-devel to request it formally and
> get acks from the community.
> 
> Eyal.
> 
> 
> ----- Original Message -----
>> From: "Sandro Bonazzola" <sbonazzo at redhat.com>
>> To: "infra" <infra at ovirt.org>
>> Sent: Wednesday, September 11, 2013 9:31:36 AM
>> Subject: Jenkins job for ovirt-iso-uploader and ovirt-image-uploader
>>
>> Hi,
>> I would like to introduce a jenkins job for basic sanity testing of
>> ovirt-iso-uploader and ovirt-image-uploader.
>> For covering NFS upload it will be needed an NFS share where to upload the
>> images, writable by an user having UID and GID of 36.
>> For covering SSH uploads it would be needed also SSH access with a user
>> having UID and GID of 36.
>> For covering upload using the domain id it would be needed a running
>> ovirt-engine instance.
>>
>> The space needed for the images may be little: sample ovf provided by
>> ovirt-image-uploader is ~2kb and for the iso image any non empty file should
>> be
>> enough. The uploaded images will be deleted by the job after running.
>>
>> Is it possible for infra to provide the needed services?
>> Thanks,
>> --
>> Sandro Bonazzola
>> Better technology. Faster innovation. Powered by community collaboration.
>> See how it works at redhat.com
>> _______________________________________________
>> Infra mailing list
>> Infra at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/infra
>>


-- 
Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com


From alonbl at redhat.com  Tue Sep 24 06:30:39 2013
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Tue, 24 Sep 2013 02:30:39 -0400 (EDT)
Subject: [Engine-devel] [vdsm] stale gerrit patches
In-Reply-To: <1431317823.1024654.1380003655261.JavaMail.root@redhat.com>
References: <524019CA.3080608@redhat.com> <52401CFB.1040300@redhat.com>
	<444143941.219431.1379933576061.JavaMail.root@redhat.com>
	<52401DEF.10607@redhat.com>
	<12011846.220527.1379933951518.JavaMail.root@redhat.com>
	<370781592.886801.1379971283176.JavaMail.root@redhat.com>
	<207419978.654820.1380003462357.JavaMail.root@redhat.com>
	<1431317823.1024654.1380003655261.JavaMail.root@redhat.com>
Message-ID: <1542539080.656258.1380004239418.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Ayal Baron" <abaron at redhat.com>
> To: "Alon Bar-Lev" <alonbl at redhat.com>
> Cc: "Itamar Heim" <iheim at redhat.com>, "engine-devel" <engine-devel at ovirt.org>, vdsm-devel at lists.fedorahosted.org
> Sent: Tuesday, September 24, 2013 9:20:55 AM
> Subject: Re: [vdsm] stale gerrit patches
> 
> 
> 
> ----- Original Message -----
> > 
> > 
> > ----- Original Message -----
> > > From: "Ayal Baron" <abaron at redhat.com>
> > > To: "Alon Bar-Lev" <alonbl at redhat.com>
> > > Cc: "Itamar Heim" <iheim at redhat.com>, "engine-devel"
> > > <engine-devel at ovirt.org>, vdsm-devel at lists.fedorahosted.org
> > > Sent: Tuesday, September 24, 2013 12:21:23 AM
> > > Subject: Re: [vdsm] stale gerrit patches
> > > 
> > > 
> > > 
> > > ----- Original Message -----
> > > > 
> > > > 
> > > > ----- Original Message -----
> > > > > From: "Itamar Heim" <iheim at redhat.com>
> > > > > To: "Alon Bar-Lev" <alonbl at redhat.com>
> > > > > Cc: "David Caro" <dcaroest at redhat.com>, "engine-devel"
> > > > > <engine-devel at ovirt.org>, vdsm-devel at lists.fedorahosted.org
> > > > > Sent: Monday, September 23, 2013 1:54:39 PM
> > > > > Subject: Re: [vdsm] stale gerrit patches
> > > > > 
> > > > > On 09/23/2013 01:52 PM, Alon Bar-Lev wrote:
> > > > > >
> > > > > >
> > > > > > ----- Original Message -----
> > > > > >> From: "Itamar Heim" <iheim at redhat.com>
> > > > > >> To: "Alon Bar-Lev" <alonbl at redhat.com>
> > > > > >> Cc: "David Caro" <dcaroest at redhat.com>, "engine-devel"
> > > > > >> <engine-devel at ovirt.org>, vdsm-devel at lists.fedorahosted.org
> > > > > >> Sent: Monday, September 23, 2013 1:50:35 PM
> > > > > >> Subject: Re: [vdsm] stale gerrit patches
> > > > > >>
> > > > > >> On 09/23/2013 01:49 PM, Alon Bar-Lev wrote:
> > > > > >>>
> > > > > >>>
> > > > > >>> ----- Original Message -----
> > > > > >>>> From: "Itamar Heim" <iheim at redhat.com>
> > > > > >>>> To: "David Caro" <dcaroest at redhat.com>
> > > > > >>>> Cc: "engine-devel" <engine-devel at ovirt.org>,
> > > > > >>>> vdsm-devel at lists.fedorahosted.org
> > > > > >>>> Sent: Monday, September 23, 2013 1:47:47 PM
> > > > > >>>> Subject: Re: [vdsm] stale gerrit patches
> > > > > >>>>
> > > > > >>>> On 09/23/2013 01:46 PM, David Caro wrote:
> > > > > >>>>> On Mon 23 Sep 2013 12:36:58 PM CEST, Itamar Heim wrote:
> > > > > >>>>>> we have some very old gerrit patches.
> > > > > >>>>>> I'm for abandoning patches which were not touched over 60 days
> > > > > >>>>>> (to
> > > > > >>>>>> begin with, I think the number should actually be lower).
> > > > > >>>>>> they can always be re-opened by any interested party post
> > > > > >>>>>> their
> > > > > >>>>>> closure.
> > > > > >>>>>>
> > > > > >>>>>> i.e., looking at gerrit, the patch list should actually get
> > > > > >>>>>> attention,
> > > > > >>>>>> and not be a few worth looking at, with a "lot of old patches"
> > > > > >>>>>>
> > > > > >>>>>> thoughts?
> > > > > >>>>>>
> > > > > >>>>>> Thanks,
> > > > > >>>>>>       Itamar
> > > > > >>>>>> _______________________________________________
> > > > > >>>>>> vdsm-devel mailing list
> > > > > >>>>>> vdsm-devel at lists.fedorahosted.org
> > > > > >>>>>> https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
> > > > > >>>>>
> > > > > >>>>> It might helpful to have a cron-like script that checks the age
> > > > > >>>>> of
> > > > > >>>>> the
> > > > > >>>>> posts and first notifies the sender, the reviewers and the
> > > > > >>>>> maintainer,
> > > > > >>>>> and if the patch is not updated in a certain period just
> > > > > >>>>> abandons
> > > > > >>>>> it.
> > > > > >>>>>
> > > > > >>>>
> > > > > >>>> yep - warn after X days via email to just owner (or all
> > > > > >>>> subscribed
> > > > > >>>> to
> > > > > >>>> the patch), and close if no activity for X+14 days or something
> > > > > >>>> like
> > > > > >>>> that.
> > > > > >>>
> > > > > >>> This will be annoying.
> > > > > >>>
> > > > > >>> And there are patches that pending with good reason.
> > > > > >>
> > > > > >> pending for 60 days with zero activity on them (no comment, no
> > > > > >> rebase,
> > > > > >> nothing)?
> > > > > >
> > > > > > http://gerrit.ovirt.org/#/q/status:open+project:ovirt-engine+branch:master+topic:independent_deployments,n,z
> > > > > 
> > > > > so how does it help us to have these patches, some without any
> > > > > comment
> > > > > from any reviewer.
> > > > > lets get them reviewed and decide one way or the other, rather than
> > > > > let
> > > > > them get old and stay forever
> > > > 
> > > > Again... maintainer can close these if he likes.
> > > > Owner can close these if he likes.
> > > 
> > > right, but why?
> > > a patch without activity being abandoned might actually spur someone into
> > > motion (rebasing and resubmitting, prodding maintainers etc).
> > > I'm +1 for automatically abandoning old patches.
> > > 
> > 
> > I do not understand why maintainer should not have human interaction with
> > its
> > contributers.
> 
> I do not understand the relation between the subject and the things you're
> saying.
> Right now these patches are stale and are rotting, abandoning them could
> actually spur those interactions into motion.

You prefer machines to interact with contributers to kick them in motion.
I believe that human interaction and discussion between maintainer and contributer is the way to go.
It is much more polite and cooperative for maintainer that is not aware of anything blocking a progress to kindly interact with contributer and finally close the change if contributer is unresponsive and/or change has no value.

> 
> > 
> > > > 
> > > > The problem is that maintainers avoid closing.
> > > > And that there are people who submitted patches without CC anyone and
> > > > gone.
> > > > 
> > > > So a simple logic can be applied after we add metadata into tree:
> > > > 
> > > > 1. If no maintainer is CCed on change, close that change within short
> > > > cycle
> > > > (can be even a week).
> > > > 2. Maintainer to close patches that have no interest in.
> > > > 
> > > > > 
> > > > > >
> > > > > >>
> > > > > >>>
> > > > > >>> Maintainers can close patches that are no interest nor progress.
> > > > > >>>
> > > > > >>> Alon
> > > > > >>>
> > > > > >>
> > > > > >>
> > > > > 
> > > > > 
> > > > _______________________________________________
> > > > vdsm-devel mailing list
> > > > vdsm-devel at lists.fedorahosted.org
> > > > https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
> > > > 
> > > 
> > 
> 


From eedri at redhat.com  Tue Sep 24 06:39:07 2013
From: eedri at redhat.com (Eyal Edri)
Date: Tue, 24 Sep 2013 02:39:07 -0400 (EDT)
Subject: [Engine-devel] Jenkins job for ovirt-iso-uploader and
	ovirt-image-uploader
In-Reply-To: <52413173.2060708@redhat.com>
References: <52300E48.2010504@redhat.com>
	<1441035513.10888819.1378886213626.JavaMail.root@redhat.com>
	<52413173.2060708@redhat.com>
Message-ID: <1551579021.1185893.1380004747063.JavaMail.root@redhat.com>

+1,

Sandro is indeed already ovirt-engine-tools maintainer and is more than capable of 
creating jobs for testing them.

Eyal.

----- Original Message -----
> From: "Sandro Bonazzola" <sbonazzo at redhat.com>
> To: "infra" <infra at ovirt.org>, "engine-devel" <engine-devel at ovirt.org>
> Cc: "Eyal Edri" <eedri at redhat.com>
> Sent: Tuesday, September 24, 2013 9:30:11 AM
> Subject: Re: Jenkins job for ovirt-iso-uploader and ovirt-image-uploader
> 
> Hi oVirt community,
>   following the previous discussion with infra team, I need to get power user
>   rights for jenkins
> in order to create a jenkins job for basic sanity testing of
> ovirt-iso-uploader and ovirt-image-uploader.
> That said, I formally request a power user for jenkins (for those tools I'm
> already the maintainer)
> in order to create new jobs for them as well and ask the community for acks.
> Thanks,
> 
> Sandro Bonazzola
> 
> 
> 
> Il 11/09/2013 09:56, Eyal Edri ha scritto:
> > Hi Sandro,
> > 
> > I assume we can create a new vm on rackspace to act as NFS server for the
> > job,
> > or even convert one of the existing jenkins slave vms to be one.
> > 
> > any other thoughts from the infra team?
> > 
> > Also, you will need to get a power user for jenkins (for tools) in order to
> > create new jobs
> > for them as well.
> > The process for that is sending email to this list & engine-devel to
> > request it formally and
> > get acks from the community.
> > 
> > Eyal.
> > 
> > 
> > ----- Original Message -----
> >> From: "Sandro Bonazzola" <sbonazzo at redhat.com>
> >> To: "infra" <infra at ovirt.org>
> >> Sent: Wednesday, September 11, 2013 9:31:36 AM
> >> Subject: Jenkins job for ovirt-iso-uploader and ovirt-image-uploader
> >>
> >> Hi,
> >> I would like to introduce a jenkins job for basic sanity testing of
> >> ovirt-iso-uploader and ovirt-image-uploader.
> >> For covering NFS upload it will be needed an NFS share where to upload the
> >> images, writable by an user having UID and GID of 36.
> >> For covering SSH uploads it would be needed also SSH access with a user
> >> having UID and GID of 36.
> >> For covering upload using the domain id it would be needed a running
> >> ovirt-engine instance.
> >>
> >> The space needed for the images may be little: sample ovf provided by
> >> ovirt-image-uploader is ~2kb and for the iso image any non empty file
> >> should
> >> be
> >> enough. The uploaded images will be deleted by the job after running.
> >>
> >> Is it possible for infra to provide the needed services?
> >> Thanks,
> >> --
> >> Sandro Bonazzola
> >> Better technology. Faster innovation. Powered by community collaboration.
> >> See how it works at redhat.com
> >> _______________________________________________
> >> Infra mailing list
> >> Infra at ovirt.org
> >> http://lists.ovirt.org/mailman/listinfo/infra
> >>
> 
> 
> --
> Sandro Bonazzola
> Better technology. Faster innovation. Powered by community collaboration.
> See how it works at redhat.com
> 


From abaron at redhat.com  Tue Sep 24 07:09:46 2013
From: abaron at redhat.com (Ayal Baron)
Date: Tue, 24 Sep 2013 03:09:46 -0400 (EDT)
Subject: [Engine-devel] [vdsm] stale gerrit patches
In-Reply-To: <1542539080.656258.1380004239418.JavaMail.root@redhat.com>
References: <524019CA.3080608@redhat.com>
	<444143941.219431.1379933576061.JavaMail.root@redhat.com>
	<52401DEF.10607@redhat.com>
	<12011846.220527.1379933951518.JavaMail.root@redhat.com>
	<370781592.886801.1379971283176.JavaMail.root@redhat.com>
	<207419978.654820.1380003462357.JavaMail.root@redhat.com>
	<1431317823.1024654.1380003655261.JavaMail.root@redhat.com>
	<1542539080.656258.1380004239418.JavaMail.root@redhat.com>
Message-ID: <988283501.1050431.1380006586565.JavaMail.root@redhat.com>



----- Original Message -----
> 
> 
> ----- Original Message -----
> > From: "Ayal Baron" <abaron at redhat.com>
> > To: "Alon Bar-Lev" <alonbl at redhat.com>
> > Cc: "Itamar Heim" <iheim at redhat.com>, "engine-devel"
> > <engine-devel at ovirt.org>, vdsm-devel at lists.fedorahosted.org
> > Sent: Tuesday, September 24, 2013 9:20:55 AM
> > Subject: Re: [vdsm] stale gerrit patches
> > 
> > 
> > 
> > ----- Original Message -----
> > > 
> > > 
> > > ----- Original Message -----
> > > > From: "Ayal Baron" <abaron at redhat.com>
> > > > To: "Alon Bar-Lev" <alonbl at redhat.com>
> > > > Cc: "Itamar Heim" <iheim at redhat.com>, "engine-devel"
> > > > <engine-devel at ovirt.org>, vdsm-devel at lists.fedorahosted.org
> > > > Sent: Tuesday, September 24, 2013 12:21:23 AM
> > > > Subject: Re: [vdsm] stale gerrit patches
> > > > 
> > > > 
> > > > 
> > > > ----- Original Message -----
> > > > > 
> > > > > 
> > > > > ----- Original Message -----
> > > > > > From: "Itamar Heim" <iheim at redhat.com>
> > > > > > To: "Alon Bar-Lev" <alonbl at redhat.com>
> > > > > > Cc: "David Caro" <dcaroest at redhat.com>, "engine-devel"
> > > > > > <engine-devel at ovirt.org>, vdsm-devel at lists.fedorahosted.org
> > > > > > Sent: Monday, September 23, 2013 1:54:39 PM
> > > > > > Subject: Re: [vdsm] stale gerrit patches
> > > > > > 
> > > > > > On 09/23/2013 01:52 PM, Alon Bar-Lev wrote:
> > > > > > >
> > > > > > >
> > > > > > > ----- Original Message -----
> > > > > > >> From: "Itamar Heim" <iheim at redhat.com>
> > > > > > >> To: "Alon Bar-Lev" <alonbl at redhat.com>
> > > > > > >> Cc: "David Caro" <dcaroest at redhat.com>, "engine-devel"
> > > > > > >> <engine-devel at ovirt.org>, vdsm-devel at lists.fedorahosted.org
> > > > > > >> Sent: Monday, September 23, 2013 1:50:35 PM
> > > > > > >> Subject: Re: [vdsm] stale gerrit patches
> > > > > > >>
> > > > > > >> On 09/23/2013 01:49 PM, Alon Bar-Lev wrote:
> > > > > > >>>
> > > > > > >>>
> > > > > > >>> ----- Original Message -----
> > > > > > >>>> From: "Itamar Heim" <iheim at redhat.com>
> > > > > > >>>> To: "David Caro" <dcaroest at redhat.com>
> > > > > > >>>> Cc: "engine-devel" <engine-devel at ovirt.org>,
> > > > > > >>>> vdsm-devel at lists.fedorahosted.org
> > > > > > >>>> Sent: Monday, September 23, 2013 1:47:47 PM
> > > > > > >>>> Subject: Re: [vdsm] stale gerrit patches
> > > > > > >>>>
> > > > > > >>>> On 09/23/2013 01:46 PM, David Caro wrote:
> > > > > > >>>>> On Mon 23 Sep 2013 12:36:58 PM CEST, Itamar Heim wrote:
> > > > > > >>>>>> we have some very old gerrit patches.
> > > > > > >>>>>> I'm for abandoning patches which were not touched over 60
> > > > > > >>>>>> days
> > > > > > >>>>>> (to
> > > > > > >>>>>> begin with, I think the number should actually be lower).
> > > > > > >>>>>> they can always be re-opened by any interested party post
> > > > > > >>>>>> their
> > > > > > >>>>>> closure.
> > > > > > >>>>>>
> > > > > > >>>>>> i.e., looking at gerrit, the patch list should actually get
> > > > > > >>>>>> attention,
> > > > > > >>>>>> and not be a few worth looking at, with a "lot of old
> > > > > > >>>>>> patches"
> > > > > > >>>>>>
> > > > > > >>>>>> thoughts?
> > > > > > >>>>>>
> > > > > > >>>>>> Thanks,
> > > > > > >>>>>>       Itamar
> > > > > > >>>>>> _______________________________________________
> > > > > > >>>>>> vdsm-devel mailing list
> > > > > > >>>>>> vdsm-devel at lists.fedorahosted.org
> > > > > > >>>>>> https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
> > > > > > >>>>>
> > > > > > >>>>> It might helpful to have a cron-like script that checks the
> > > > > > >>>>> age
> > > > > > >>>>> of
> > > > > > >>>>> the
> > > > > > >>>>> posts and first notifies the sender, the reviewers and the
> > > > > > >>>>> maintainer,
> > > > > > >>>>> and if the patch is not updated in a certain period just
> > > > > > >>>>> abandons
> > > > > > >>>>> it.
> > > > > > >>>>>
> > > > > > >>>>
> > > > > > >>>> yep - warn after X days via email to just owner (or all
> > > > > > >>>> subscribed
> > > > > > >>>> to
> > > > > > >>>> the patch), and close if no activity for X+14 days or
> > > > > > >>>> something
> > > > > > >>>> like
> > > > > > >>>> that.
> > > > > > >>>
> > > > > > >>> This will be annoying.
> > > > > > >>>
> > > > > > >>> And there are patches that pending with good reason.
> > > > > > >>
> > > > > > >> pending for 60 days with zero activity on them (no comment, no
> > > > > > >> rebase,
> > > > > > >> nothing)?
> > > > > > >
> > > > > > > http://gerrit.ovirt.org/#/q/status:open+project:ovirt-engine+branch:master+topic:independent_deployments,n,z
> > > > > > 
> > > > > > so how does it help us to have these patches, some without any
> > > > > > comment
> > > > > > from any reviewer.
> > > > > > lets get them reviewed and decide one way or the other, rather than
> > > > > > let
> > > > > > them get old and stay forever
> > > > > 
> > > > > Again... maintainer can close these if he likes.
> > > > > Owner can close these if he likes.
> > > > 
> > > > right, but why?
> > > > a patch without activity being abandoned might actually spur someone
> > > > into
> > > > motion (rebasing and resubmitting, prodding maintainers etc).
> > > > I'm +1 for automatically abandoning old patches.
> > > > 
> > > 
> > > I do not understand why maintainer should not have human interaction with
> > > its
> > > contributers.
> > 
> > I do not understand the relation between the subject and the things you're
> > saying.
> > Right now these patches are stale and are rotting, abandoning them could
> > actually spur those interactions into motion.
> 
> You prefer machines to interact with contributers to kick them in motion.
> I believe that human interaction and discussion between maintainer and
> contributer is the way to go.
> It is much more polite and cooperative for maintainer that is not aware of
> anything blocking a progress to kindly interact with contributer and finally
> close the change if contributer is unresponsive and/or change has no value.

Personally I see nothing impolite about automatically abandoning patches if it is clear to contributors that this the expected behaviour.
Other projects abandon automatically after a week and from what I've seen that is working well to get things in motion and get those interactions that you (and I) want, rolling.

> 
> > 
> > > 
> > > > > 
> > > > > The problem is that maintainers avoid closing.
> > > > > And that there are people who submitted patches without CC anyone and
> > > > > gone.
> > > > > 
> > > > > So a simple logic can be applied after we add metadata into tree:
> > > > > 
> > > > > 1. If no maintainer is CCed on change, close that change within short
> > > > > cycle
> > > > > (can be even a week).
> > > > > 2. Maintainer to close patches that have no interest in.
> > > > > 
> > > > > > 
> > > > > > >
> > > > > > >>
> > > > > > >>>
> > > > > > >>> Maintainers can close patches that are no interest nor
> > > > > > >>> progress.
> > > > > > >>>
> > > > > > >>> Alon
> > > > > > >>>
> > > > > > >>
> > > > > > >>
> > > > > > 
> > > > > > 
> > > > > _______________________________________________
> > > > > vdsm-devel mailing list
> > > > > vdsm-devel at lists.fedorahosted.org
> > > > > https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
> > > > > 
> > > > 
> > > 
> > 
> 


From alonbl at redhat.com  Tue Sep 24 07:18:12 2013
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Tue, 24 Sep 2013 03:18:12 -0400 (EDT)
Subject: [Engine-devel] [vdsm] stale gerrit patches
In-Reply-To: <988283501.1050431.1380006586565.JavaMail.root@redhat.com>
References: <524019CA.3080608@redhat.com> <52401DEF.10607@redhat.com>
	<12011846.220527.1379933951518.JavaMail.root@redhat.com>
	<370781592.886801.1379971283176.JavaMail.root@redhat.com>
	<207419978.654820.1380003462357.JavaMail.root@redhat.com>
	<1431317823.1024654.1380003655261.JavaMail.root@redhat.com>
	<1542539080.656258.1380004239418.JavaMail.root@redhat.com>
	<988283501.1050431.1380006586565.JavaMail.root@redhat.com>
Message-ID: <2038048399.662225.1380007092494.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Ayal Baron" <abaron at redhat.com>
> To: "Alon Bar-Lev" <alonbl at redhat.com>
> Cc: "Itamar Heim" <iheim at redhat.com>, "engine-devel" <engine-devel at ovirt.org>, vdsm-devel at lists.fedorahosted.org
> Sent: Tuesday, September 24, 2013 10:09:46 AM
> Subject: Re: [vdsm] stale gerrit patches
> 
> 
> 
> ----- Original Message -----
> > 
> > 
> > ----- Original Message -----
> > > From: "Ayal Baron" <abaron at redhat.com>
> > > To: "Alon Bar-Lev" <alonbl at redhat.com>
> > > Cc: "Itamar Heim" <iheim at redhat.com>, "engine-devel"
> > > <engine-devel at ovirt.org>, vdsm-devel at lists.fedorahosted.org
> > > Sent: Tuesday, September 24, 2013 9:20:55 AM
> > > Subject: Re: [vdsm] stale gerrit patches
> > > 
> > > 
> > > 
> > > ----- Original Message -----
> > > > 
> > > > 
> > > > ----- Original Message -----
> > > > > From: "Ayal Baron" <abaron at redhat.com>
> > > > > To: "Alon Bar-Lev" <alonbl at redhat.com>
> > > > > Cc: "Itamar Heim" <iheim at redhat.com>, "engine-devel"
> > > > > <engine-devel at ovirt.org>, vdsm-devel at lists.fedorahosted.org
> > > > > Sent: Tuesday, September 24, 2013 12:21:23 AM
> > > > > Subject: Re: [vdsm] stale gerrit patches
> > > > > 
> > > > > 
> > > > > 
> > > > > ----- Original Message -----
> > > > > > 
> > > > > > 
> > > > > > ----- Original Message -----
> > > > > > > From: "Itamar Heim" <iheim at redhat.com>
> > > > > > > To: "Alon Bar-Lev" <alonbl at redhat.com>
> > > > > > > Cc: "David Caro" <dcaroest at redhat.com>, "engine-devel"
> > > > > > > <engine-devel at ovirt.org>, vdsm-devel at lists.fedorahosted.org
> > > > > > > Sent: Monday, September 23, 2013 1:54:39 PM
> > > > > > > Subject: Re: [vdsm] stale gerrit patches
> > > > > > > 
> > > > > > > On 09/23/2013 01:52 PM, Alon Bar-Lev wrote:
> > > > > > > >
> > > > > > > >
> > > > > > > > ----- Original Message -----
> > > > > > > >> From: "Itamar Heim" <iheim at redhat.com>
> > > > > > > >> To: "Alon Bar-Lev" <alonbl at redhat.com>
> > > > > > > >> Cc: "David Caro" <dcaroest at redhat.com>, "engine-devel"
> > > > > > > >> <engine-devel at ovirt.org>, vdsm-devel at lists.fedorahosted.org
> > > > > > > >> Sent: Monday, September 23, 2013 1:50:35 PM
> > > > > > > >> Subject: Re: [vdsm] stale gerrit patches
> > > > > > > >>
> > > > > > > >> On 09/23/2013 01:49 PM, Alon Bar-Lev wrote:
> > > > > > > >>>
> > > > > > > >>>
> > > > > > > >>> ----- Original Message -----
> > > > > > > >>>> From: "Itamar Heim" <iheim at redhat.com>
> > > > > > > >>>> To: "David Caro" <dcaroest at redhat.com>
> > > > > > > >>>> Cc: "engine-devel" <engine-devel at ovirt.org>,
> > > > > > > >>>> vdsm-devel at lists.fedorahosted.org
> > > > > > > >>>> Sent: Monday, September 23, 2013 1:47:47 PM
> > > > > > > >>>> Subject: Re: [vdsm] stale gerrit patches
> > > > > > > >>>>
> > > > > > > >>>> On 09/23/2013 01:46 PM, David Caro wrote:
> > > > > > > >>>>> On Mon 23 Sep 2013 12:36:58 PM CEST, Itamar Heim wrote:
> > > > > > > >>>>>> we have some very old gerrit patches.
> > > > > > > >>>>>> I'm for abandoning patches which were not touched over 60
> > > > > > > >>>>>> days
> > > > > > > >>>>>> (to
> > > > > > > >>>>>> begin with, I think the number should actually be lower).
> > > > > > > >>>>>> they can always be re-opened by any interested party post
> > > > > > > >>>>>> their
> > > > > > > >>>>>> closure.
> > > > > > > >>>>>>
> > > > > > > >>>>>> i.e., looking at gerrit, the patch list should actually
> > > > > > > >>>>>> get
> > > > > > > >>>>>> attention,
> > > > > > > >>>>>> and not be a few worth looking at, with a "lot of old
> > > > > > > >>>>>> patches"
> > > > > > > >>>>>>
> > > > > > > >>>>>> thoughts?
> > > > > > > >>>>>>
> > > > > > > >>>>>> Thanks,
> > > > > > > >>>>>>       Itamar
> > > > > > > >>>>>> _______________________________________________
> > > > > > > >>>>>> vdsm-devel mailing list
> > > > > > > >>>>>> vdsm-devel at lists.fedorahosted.org
> > > > > > > >>>>>> https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
> > > > > > > >>>>>
> > > > > > > >>>>> It might helpful to have a cron-like script that checks the
> > > > > > > >>>>> age
> > > > > > > >>>>> of
> > > > > > > >>>>> the
> > > > > > > >>>>> posts and first notifies the sender, the reviewers and the
> > > > > > > >>>>> maintainer,
> > > > > > > >>>>> and if the patch is not updated in a certain period just
> > > > > > > >>>>> abandons
> > > > > > > >>>>> it.
> > > > > > > >>>>>
> > > > > > > >>>>
> > > > > > > >>>> yep - warn after X days via email to just owner (or all
> > > > > > > >>>> subscribed
> > > > > > > >>>> to
> > > > > > > >>>> the patch), and close if no activity for X+14 days or
> > > > > > > >>>> something
> > > > > > > >>>> like
> > > > > > > >>>> that.
> > > > > > > >>>
> > > > > > > >>> This will be annoying.
> > > > > > > >>>
> > > > > > > >>> And there are patches that pending with good reason.
> > > > > > > >>
> > > > > > > >> pending for 60 days with zero activity on them (no comment, no
> > > > > > > >> rebase,
> > > > > > > >> nothing)?
> > > > > > > >
> > > > > > > > http://gerrit.ovirt.org/#/q/status:open+project:ovirt-engine+branch:master+topic:independent_deployments,n,z
> > > > > > > 
> > > > > > > so how does it help us to have these patches, some without any
> > > > > > > comment
> > > > > > > from any reviewer.
> > > > > > > lets get them reviewed and decide one way or the other, rather
> > > > > > > than
> > > > > > > let
> > > > > > > them get old and stay forever
> > > > > > 
> > > > > > Again... maintainer can close these if he likes.
> > > > > > Owner can close these if he likes.
> > > > > 
> > > > > right, but why?
> > > > > a patch without activity being abandoned might actually spur someone
> > > > > into
> > > > > motion (rebasing and resubmitting, prodding maintainers etc).
> > > > > I'm +1 for automatically abandoning old patches.
> > > > > 
> > > > 
> > > > I do not understand why maintainer should not have human interaction
> > > > with
> > > > its
> > > > contributers.
> > > 
> > > I do not understand the relation between the subject and the things
> > > you're
> > > saying.
> > > Right now these patches are stale and are rotting, abandoning them could
> > > actually spur those interactions into motion.
> > 
> > You prefer machines to interact with contributers to kick them in motion.
> > I believe that human interaction and discussion between maintainer and
> > contributer is the way to go.
> > It is much more polite and cooperative for maintainer that is not aware of
> > anything blocking a progress to kindly interact with contributer and
> > finally
> > close the change if contributer is unresponsive and/or change has no value.
> 
> Personally I see nothing impolite about automatically abandoning patches if
> it is clear to contributors that this the expected behaviour.

It has nothing to do with polite, but build relationship between people and not force people to reopen important changes and explain them-selves every time a machine decides to.

> Other projects abandon automatically after a week and from what I've seen
> that is working well to get things in motion and get those interactions that
> you (and I) want, rolling.

The herd argument is never accepted by me, the herd seldom has definite wisdom.

I would like maintainers to build human relationship with their contributers it is more important than having one or two extra changes in queue, as these relationships will serve us at other plains as well.

So our mission is indeed different... you are interested in rolling, while I am in creating ecosystem of people, which eventually will roll much faster.

> > 
> > > 
> > > > 
> > > > > > 
> > > > > > The problem is that maintainers avoid closing.
> > > > > > And that there are people who submitted patches without CC anyone
> > > > > > and
> > > > > > gone.
> > > > > > 
> > > > > > So a simple logic can be applied after we add metadata into tree:
> > > > > > 
> > > > > > 1. If no maintainer is CCed on change, close that change within
> > > > > > short
> > > > > > cycle
> > > > > > (can be even a week).
> > > > > > 2. Maintainer to close patches that have no interest in.
> > > > > > 
> > > > > > > 
> > > > > > > >
> > > > > > > >>
> > > > > > > >>>
> > > > > > > >>> Maintainers can close patches that are no interest nor
> > > > > > > >>> progress.
> > > > > > > >>>
> > > > > > > >>> Alon
> > > > > > > >>>
> > > > > > > >>
> > > > > > > >>
> > > > > > > 
> > > > > > > 
> > > > > > _______________________________________________
> > > > > > vdsm-devel mailing list
> > > > > > vdsm-devel at lists.fedorahosted.org
> > > > > > https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
> > > > > > 
> > > > > 
> > > > 
> > > 
> > 
> 


From didi at redhat.com  Tue Sep 24 07:19:57 2013
From: didi at redhat.com (Yedidyah Bar David)
Date: Tue, 24 Sep 2013 03:19:57 -0400 (EDT)
Subject: [Engine-devel] Suggesting new packaging and setup maintainer
In-Reply-To: <1271829417.461834.1379933376488.JavaMail.root@redhat.com>
References: <1271829417.461834.1379933376488.JavaMail.root@redhat.com>
Message-ID: <1545714952.1070452.1380007197014.JavaMail.root@redhat.com>

+1

>From the many code reviews Sandro did to my changes, I can definitely
say he has a good taste and a sense of responsibility.
-- 
Didi

----- Original Message -----
> From: "Ofer Schreiber" <oschreib at redhat.com>
> To: "board" <board at ovirt.org>, "engine-devel" <engine-devel at ovirt.org>
> Sent: Monday, September 23, 2013 1:49:36 PM
> Subject: [Engine-devel] Suggesting new packaging and setup maintainer
> 
> Nominating Sandro Bonazzola as packaging and setup maintainer
> ----------------------------------------------------------
> 
> During his recent year of participation in ovirt-engine development,
> Sandro demonstrated a genuine care for the product health, great coding
> abilities,
> and great responsibility to the setup and packaging components.
> 
> Sandro's contribution the the project is undoubtable, he's responsible for
> over 70 patches in ovirt-engine,
> and he's the maintainer of log-collector, iso-uploader and image-uploader
> packages.
> 
> I suggest that Sandro will obtain +2 and merge rights in the ovirt-engine
> gerrit project,
> in the understanding that those rights should be used only in packaging and
> setup parts of the code.
> 
> --
> Ofer Schreiber.
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From sbonazzo at redhat.com  Tue Sep 24 07:52:06 2013
From: sbonazzo at redhat.com (Sandro Bonazzola)
Date: Tue, 24 Sep 2013 09:52:06 +0200
Subject: [Engine-devel] Suggesting new packaging and setup maintainer
In-Reply-To: <1271829417.461834.1379933376488.JavaMail.root@redhat.com>
References: <1271829417.461834.1379933376488.JavaMail.root@redhat.com>
Message-ID: <524144A6.1010609@redhat.com>

Il 23/09/2013 12:49, Ofer Schreiber ha scritto:
> Nominating Sandro Bonazzola as packaging and setup maintainer
> ----------------------------------------------------------
> 
> During his recent year of participation in ovirt-engine development,
> Sandro demonstrated a genuine care for the product health, great coding abilities,
> and great responsibility to the setup and packaging components.
> 
> Sandro's contribution the the project is undoubtable, he's responsible for over 70 patches in ovirt-engine, 
> and he's the maintainer of log-collector, iso-uploader and image-uploader packages.
> 
> I suggest that Sandro will obtain +2 and merge rights in the ovirt-engine gerrit project,
> in the understanding that those rights should be used only in packaging and setup parts of the code.

Thanks for suggesting me as maintainer and for the words you all used in your +1 vote!
They're really appreciated.

> 
> --
> Ofer Schreiber.
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


-- 
Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com


From abaron at redhat.com  Tue Sep 24 08:06:48 2013
From: abaron at redhat.com (Ayal Baron)
Date: Tue, 24 Sep 2013 04:06:48 -0400 (EDT)
Subject: [Engine-devel] [vdsm] stale gerrit patches
In-Reply-To: <2038048399.662225.1380007092494.JavaMail.root@redhat.com>
References: <524019CA.3080608@redhat.com>
	<12011846.220527.1379933951518.JavaMail.root@redhat.com>
	<370781592.886801.1379971283176.JavaMail.root@redhat.com>
	<207419978.654820.1380003462357.JavaMail.root@redhat.com>
	<1431317823.1024654.1380003655261.JavaMail.root@redhat.com>
	<1542539080.656258.1380004239418.JavaMail.root@redhat.com>
	<988283501.1050431.1380006586565.JavaMail.root@redhat.com>
	<2038048399.662225.1380007092494.JavaMail.root@redhat.com>
Message-ID: <1269529881.1076728.1380010008604.JavaMail.root@redhat.com>



----- Original Message -----
> 
> 
> ----- Original Message -----
> > From: "Ayal Baron" <abaron at redhat.com>
> > To: "Alon Bar-Lev" <alonbl at redhat.com>
> > Cc: "Itamar Heim" <iheim at redhat.com>, "engine-devel"
> > <engine-devel at ovirt.org>, vdsm-devel at lists.fedorahosted.org
> > Sent: Tuesday, September 24, 2013 10:09:46 AM
> > Subject: Re: [vdsm] stale gerrit patches
> > 
> > 
> > 
> > ----- Original Message -----
> > > 
> > > 
> > > ----- Original Message -----
> > > > From: "Ayal Baron" <abaron at redhat.com>
> > > > To: "Alon Bar-Lev" <alonbl at redhat.com>
> > > > Cc: "Itamar Heim" <iheim at redhat.com>, "engine-devel"
> > > > <engine-devel at ovirt.org>, vdsm-devel at lists.fedorahosted.org
> > > > Sent: Tuesday, September 24, 2013 9:20:55 AM
> > > > Subject: Re: [vdsm] stale gerrit patches
> > > > 
> > > > 
> > > > 
> > > > ----- Original Message -----
> > > > > 
> > > > > 
> > > > > ----- Original Message -----
> > > > > > From: "Ayal Baron" <abaron at redhat.com>
> > > > > > To: "Alon Bar-Lev" <alonbl at redhat.com>
> > > > > > Cc: "Itamar Heim" <iheim at redhat.com>, "engine-devel"
> > > > > > <engine-devel at ovirt.org>, vdsm-devel at lists.fedorahosted.org
> > > > > > Sent: Tuesday, September 24, 2013 12:21:23 AM
> > > > > > Subject: Re: [vdsm] stale gerrit patches
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > ----- Original Message -----
> > > > > > > 
> > > > > > > 
> > > > > > > ----- Original Message -----
> > > > > > > > From: "Itamar Heim" <iheim at redhat.com>
> > > > > > > > To: "Alon Bar-Lev" <alonbl at redhat.com>
> > > > > > > > Cc: "David Caro" <dcaroest at redhat.com>, "engine-devel"
> > > > > > > > <engine-devel at ovirt.org>, vdsm-devel at lists.fedorahosted.org
> > > > > > > > Sent: Monday, September 23, 2013 1:54:39 PM
> > > > > > > > Subject: Re: [vdsm] stale gerrit patches
> > > > > > > > 
> > > > > > > > On 09/23/2013 01:52 PM, Alon Bar-Lev wrote:
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > ----- Original Message -----
> > > > > > > > >> From: "Itamar Heim" <iheim at redhat.com>
> > > > > > > > >> To: "Alon Bar-Lev" <alonbl at redhat.com>
> > > > > > > > >> Cc: "David Caro" <dcaroest at redhat.com>, "engine-devel"
> > > > > > > > >> <engine-devel at ovirt.org>, vdsm-devel at lists.fedorahosted.org
> > > > > > > > >> Sent: Monday, September 23, 2013 1:50:35 PM
> > > > > > > > >> Subject: Re: [vdsm] stale gerrit patches
> > > > > > > > >>
> > > > > > > > >> On 09/23/2013 01:49 PM, Alon Bar-Lev wrote:
> > > > > > > > >>>
> > > > > > > > >>>
> > > > > > > > >>> ----- Original Message -----
> > > > > > > > >>>> From: "Itamar Heim" <iheim at redhat.com>
> > > > > > > > >>>> To: "David Caro" <dcaroest at redhat.com>
> > > > > > > > >>>> Cc: "engine-devel" <engine-devel at ovirt.org>,
> > > > > > > > >>>> vdsm-devel at lists.fedorahosted.org
> > > > > > > > >>>> Sent: Monday, September 23, 2013 1:47:47 PM
> > > > > > > > >>>> Subject: Re: [vdsm] stale gerrit patches
> > > > > > > > >>>>
> > > > > > > > >>>> On 09/23/2013 01:46 PM, David Caro wrote:
> > > > > > > > >>>>> On Mon 23 Sep 2013 12:36:58 PM CEST, Itamar Heim wrote:
> > > > > > > > >>>>>> we have some very old gerrit patches.
> > > > > > > > >>>>>> I'm for abandoning patches which were not touched over
> > > > > > > > >>>>>> 60
> > > > > > > > >>>>>> days
> > > > > > > > >>>>>> (to
> > > > > > > > >>>>>> begin with, I think the number should actually be
> > > > > > > > >>>>>> lower).
> > > > > > > > >>>>>> they can always be re-opened by any interested party
> > > > > > > > >>>>>> post
> > > > > > > > >>>>>> their
> > > > > > > > >>>>>> closure.
> > > > > > > > >>>>>>
> > > > > > > > >>>>>> i.e., looking at gerrit, the patch list should actually
> > > > > > > > >>>>>> get
> > > > > > > > >>>>>> attention,
> > > > > > > > >>>>>> and not be a few worth looking at, with a "lot of old
> > > > > > > > >>>>>> patches"
> > > > > > > > >>>>>>
> > > > > > > > >>>>>> thoughts?
> > > > > > > > >>>>>>
> > > > > > > > >>>>>> Thanks,
> > > > > > > > >>>>>>       Itamar
> > > > > > > > >>>>>> _______________________________________________
> > > > > > > > >>>>>> vdsm-devel mailing list
> > > > > > > > >>>>>> vdsm-devel at lists.fedorahosted.org
> > > > > > > > >>>>>> https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
> > > > > > > > >>>>>
> > > > > > > > >>>>> It might helpful to have a cron-like script that checks
> > > > > > > > >>>>> the
> > > > > > > > >>>>> age
> > > > > > > > >>>>> of
> > > > > > > > >>>>> the
> > > > > > > > >>>>> posts and first notifies the sender, the reviewers and
> > > > > > > > >>>>> the
> > > > > > > > >>>>> maintainer,
> > > > > > > > >>>>> and if the patch is not updated in a certain period just
> > > > > > > > >>>>> abandons
> > > > > > > > >>>>> it.
> > > > > > > > >>>>>
> > > > > > > > >>>>
> > > > > > > > >>>> yep - warn after X days via email to just owner (or all
> > > > > > > > >>>> subscribed
> > > > > > > > >>>> to
> > > > > > > > >>>> the patch), and close if no activity for X+14 days or
> > > > > > > > >>>> something
> > > > > > > > >>>> like
> > > > > > > > >>>> that.
> > > > > > > > >>>
> > > > > > > > >>> This will be annoying.
> > > > > > > > >>>
> > > > > > > > >>> And there are patches that pending with good reason.
> > > > > > > > >>
> > > > > > > > >> pending for 60 days with zero activity on them (no comment,
> > > > > > > > >> no
> > > > > > > > >> rebase,
> > > > > > > > >> nothing)?
> > > > > > > > >
> > > > > > > > > http://gerrit.ovirt.org/#/q/status:open+project:ovirt-engine+branch:master+topic:independent_deployments,n,z
> > > > > > > > 
> > > > > > > > so how does it help us to have these patches, some without any
> > > > > > > > comment
> > > > > > > > from any reviewer.
> > > > > > > > lets get them reviewed and decide one way or the other, rather
> > > > > > > > than
> > > > > > > > let
> > > > > > > > them get old and stay forever
> > > > > > > 
> > > > > > > Again... maintainer can close these if he likes.
> > > > > > > Owner can close these if he likes.
> > > > > > 
> > > > > > right, but why?
> > > > > > a patch without activity being abandoned might actually spur
> > > > > > someone
> > > > > > into
> > > > > > motion (rebasing and resubmitting, prodding maintainers etc).
> > > > > > I'm +1 for automatically abandoning old patches.
> > > > > > 
> > > > > 
> > > > > I do not understand why maintainer should not have human interaction
> > > > > with
> > > > > its
> > > > > contributers.
> > > > 
> > > > I do not understand the relation between the subject and the things
> > > > you're
> > > > saying.
> > > > Right now these patches are stale and are rotting, abandoning them
> > > > could
> > > > actually spur those interactions into motion.
> > > 
> > > You prefer machines to interact with contributers to kick them in motion.
> > > I believe that human interaction and discussion between maintainer and
> > > contributer is the way to go.
> > > It is much more polite and cooperative for maintainer that is not aware
> > > of
> > > anything blocking a progress to kindly interact with contributer and
> > > finally
> > > close the change if contributer is unresponsive and/or change has no
> > > value.
> > 
> > Personally I see nothing impolite about automatically abandoning patches if
> > it is clear to contributors that this the expected behaviour.
> 
> It has nothing to do with polite, but build relationship between people and
> not force people to reopen important changes and explain them-selves every
> time a machine decides to.
> 
> > Other projects abandon automatically after a week and from what I've seen
> > that is working well to get things in motion and get those interactions
> > that
> > you (and I) want, rolling.
> 
> The herd argument is never accepted by me, the herd seldom has definite
> wisdom.
> 
> I would like maintainers to build human relationship with their contributers
> it is more important than having one or two extra changes in queue, as these
> relationships will serve us at other plains as well.
> 
> So our mission is indeed different... you are interested in rolling, while I
> am in creating ecosystem of people, which eventually will roll much faster.

I'm amused by your insistent efforts in trying to spin what I say and misinterpret my words.
I am interested in exactly the same thing as you are.  Practically though, you are not suggesting anything different than what exists today which is getting us today's results which neither you nor I are satisfied with.  I am trying to change the dynamics and test what works to get things in the direction we both want them to, you are saying 'this is the way things should be' and are not willing to try new things that may actually get us there.


> 
> > > 
> > > > 
> > > > > 
> > > > > > > 
> > > > > > > The problem is that maintainers avoid closing.
> > > > > > > And that there are people who submitted patches without CC anyone
> > > > > > > and
> > > > > > > gone.
> > > > > > > 
> > > > > > > So a simple logic can be applied after we add metadata into tree:
> > > > > > > 
> > > > > > > 1. If no maintainer is CCed on change, close that change within
> > > > > > > short
> > > > > > > cycle
> > > > > > > (can be even a week).
> > > > > > > 2. Maintainer to close patches that have no interest in.
> > > > > > > 
> > > > > > > > 
> > > > > > > > >
> > > > > > > > >>
> > > > > > > > >>>
> > > > > > > > >>> Maintainers can close patches that are no interest nor
> > > > > > > > >>> progress.
> > > > > > > > >>>
> > > > > > > > >>> Alon
> > > > > > > > >>>
> > > > > > > > >>
> > > > > > > > >>
> > > > > > > > 
> > > > > > > > 
> > > > > > > _______________________________________________
> > > > > > > vdsm-devel mailing list
> > > > > > > vdsm-devel at lists.fedorahosted.org
> > > > > > > https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
> > > > > > > 
> > > > > > 
> > > > > 
> > > > 
> > > 
> > 
> 


From jhernand at redhat.com  Tue Sep 24 08:56:06 2013
From: jhernand at redhat.com (Juan Hernandez)
Date: Tue, 24 Sep 2013 10:56:06 +0200
Subject: [Engine-devel] Suggesting new packaging and setup maintainer
In-Reply-To: <1271829417.461834.1379933376488.JavaMail.root@redhat.com>
References: <1271829417.461834.1379933376488.JavaMail.root@redhat.com>
Message-ID: <524153A6.6070804@redhat.com>

On 09/23/2013 12:49 PM, Ofer Schreiber wrote:
> Nominating Sandro Bonazzola as packaging and setup maintainer
> ----------------------------------------------------------
> 
> During his recent year of participation in ovirt-engine development,
> Sandro demonstrated a genuine care for the product health, great coding abilities,
> and great responsibility to the setup and packaging components.
> 
> Sandro's contribution the the project is undoubtable, he's responsible for over 70 patches in ovirt-engine, 
> and he's the maintainer of log-collector, iso-uploader and image-uploader packages.
> 
> I suggest that Sandro will obtain +2 and merge rights in the ovirt-engine gerrit project,
> in the understanding that those rights should be used only in packaging and setup parts of the code.
> 

+1

-- 
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.


From kroberts at redhat.com  Tue Sep 24 11:11:49 2013
From: kroberts at redhat.com (Keith Robertson)
Date: Tue, 24 Sep 2013 07:11:49 -0400 (EDT)
Subject: [Engine-devel] Suggesting new packaging and setup maintainer
In-Reply-To: <524153A6.6070804@redhat.com>
References: <1271829417.461834.1379933376488.JavaMail.root@redhat.com>
	<524153A6.6070804@redhat.com>
Message-ID: <1251753356.926231.1380021109609.JavaMail.root@redhat.com>

+1



> On 09/23/2013 12:49 PM, Ofer Schreiber wrote:
> > Nominating Sandro Bonazzola as packaging and setup maintainer
> > ----------------------------------------------------------
> > 
> > During his recent year of participation in ovirt-engine development,
> > Sandro demonstrated a genuine care for the product health, great coding
> > abilities,
> > and great responsibility to the setup and packaging components.
> > 
> > Sandro's contribution the the project is undoubtable, he's responsible for
> > over 70 patches in ovirt-engine,
> > and he's the maintainer of log-collector, iso-uploader and image-uploader
> > packages.
> > 
> > I suggest that Sandro will obtain +2 and merge rights in the ovirt-engine
> > gerrit project,
> > in the understanding that those rights should be used only in packaging and
> > setup parts of the code.
> > 


From derez at redhat.com  Tue Sep 24 12:31:01 2013
From: derez at redhat.com (Daniel Erez)
Date: Tue, 24 Sep 2013 08:31:01 -0400 (EDT)
Subject: [Engine-devel] Issues with VirtIO-SCSI
In-Reply-To: <B2CAFC4D5E2D574A883EF61ACD5ADE330181AC9B@SERV070.corp.eldorado.org.br>
References: <B2CAFC4D5E2D574A883EF61ACD5ADE330181AB51@SERV070.corp.eldorado.org.br>
	<1435657800.857208.1379966741270.JavaMail.root@redhat.com>
	<B2CAFC4D5E2D574A883EF61ACD5ADE330181AC9B@SERV070.corp.eldorado.org.br>
Message-ID: <814611274.1166105.1380025861475.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Vitor de Lima" <vitor.lima at eldorado.org.br>
> To: "Daniel Erez" <derez at redhat.com>
> Cc: engine-devel at ovirt.org
> Sent: Tuesday, September 24, 2013 12:34:17 AM
> Subject: RE: [Engine-devel] Issues with VirtIO-SCSI
> 
> Hi Daniel,
> 
> I asked this question because I have implemented a filter to show only
> compatible disk interfaces (in change #17964). The main purpose of this
> patch is to hide the IDE interface type when creating disks for PPC64 VMs
> (since IDE is not supported on this architecture). If it was decided that
> the VirtIO-SCSI interface type should be hidden from the user in case it was
> disabled, I would have to modify that patch a little bit.

For consistency, I'll filter the interface from the list when VirtIO-SCSI is disabled.
So yeah, keep that in mind when modifying your patch.

> 
> Another issue is that in change #18622 the support for a PPC64-specific
> controller, the SPAPR VSCSI controller, was introduced. But the code was
> created based on the assumption that the VirtIO-SCSI controller was always
> present, and this isn't the case anymore. And another patch that I will work
> on really soon will add support to create disks that are connected to this
> interface.

Can you filter the option out or add a warning when VirtIO-SCSI is disabled?

> 
> So, I would like some feedback before changing these patches. Is a validation
> on the backend enough to block the user from using an inexistent controller?
> Should the frontend be changed as well? What would be a good approach to
> handle multiple SCSI controllers in a VM (were the presence of one of them
> is optional)?

You should block it in the engine on canDo and filter the option / warn about it in the UI.
Regarding multiple controllers, are you referring to multiple types of controllers
or just multiple VirtIO-SCSI devices?

> 
> Thanks,
> Vitor
> 
> 
> 
> >-----Original Message-----
> >From: Daniel Erez [mailto:derez at redhat.com]
> >Sent: segunda-feira, 23 de setembro de 2013 17:06
> >To: Vitor de Lima
> >Cc: engine-devel at ovirt.org
> >Subject: Re: [Engine-devel] Issues with VirtIO-SCSI
> >
> >Hi Vitor,
> >
> >The new VirtIO-SCSI enabled checkbox is an indication whether to attach a
> >VirtIO-SCSI controller when running the VM.
> >It should be enabled automatically on cluster >= 3.3.
> >
> >When disabled, I think it's preferable not to add a new controller
> >automatically
> >when running the VM as it requires creating/attaching a new VmDevice -
> >which we refrain of on VmInfoBuilder flows (and since it might be confusing
> >to
> >the user...).
> >
> >As an alternative, I've planned to add a warning in the dialog or create a
> >canDo
> >message to prevent running the VM at all.
> >I'm not sure we should hide the option from disk interfaces list as it's
> >already
> >being filtered using VirtIoScsiEnabled ConfigurationValue (and using OsInfo
> >soon...).
> >
> >Let me know what you think and thanks a lot for the input!
> >
> >Daniel
> >
> >----- Original Message -----
> >> From: "Vitor de Lima" <vitor.lima at eldorado.org.br>
> >> To: engine-devel at ovirt.org
> >> Sent: Monday, September 23, 2013 10:42:39 PM
> >> Subject: [Engine-devel] Issues with VirtIO-SCSI
> >>
> >> Hi everyone,
> >>
> >> I have found some issues with this patch:
> >>
> >> http://gerrit.ovirt.org/#/c/18638/
> >>
> >> It allows the user to disable the VirtIO-SCSI disk interface during
> >> the VM creation. The problem is that the user still can add, attach
> >> and hotplug disks with the VirtIO-SCSI interface type, but when the
> >> user does so, libvirt automatically creates a LSI Logic SCSI
> >> controller and connects the new disk to it.
> >>
> >> How can this problem be solved? Should the VirtIO-SCSI interface type
> >> be hidden from the user in case it wasn't enabled, or should the
> >> engine enable the VirtIO-SCSI controller, hotplug it, then hotplug the
> >> disk into it transparently?
> >>
> >> Thanks,
> >> Vitor de Lima
> >>
> >> _______________________________________________
> >> Engine-devel mailing list
> >> Engine-devel at ovirt.org
> >> http://lists.ovirt.org/mailman/listinfo/engine-devel
> >>
> 


From vitor.lima at eldorado.org.br  Tue Sep 24 15:52:46 2013
From: vitor.lima at eldorado.org.br (Vitor de Lima)
Date: Tue, 24 Sep 2013 15:52:46 +0000
Subject: [Engine-devel] Issues with VirtIO-SCSI
In-Reply-To: <814611274.1166105.1380025861475.JavaMail.root@redhat.com>
References: <B2CAFC4D5E2D574A883EF61ACD5ADE330181AB51@SERV070.corp.eldorado.org.br>
	<1435657800.857208.1379966741270.JavaMail.root@redhat.com>
	<B2CAFC4D5E2D574A883EF61ACD5ADE330181AC9B@SERV070.corp.eldorado.org.br>
	<814611274.1166105.1380025861475.JavaMail.root@redhat.com>
Message-ID: <B2CAFC4D5E2D574A883EF61ACD5ADE330181B486@SERV070.corp.eldorado.org.br>

Hi Daniel,

I was referring to multiple types of controllers. For now, I think it is enough to have only one optional VirtIO-SCSI controller per VM, and (on the ppc64) one obligatory SPAPR VSCSI controller. The main question is how to handle the addresses when the VirtIO-SCSI is disabled and there is only the SPAPR VSCSI controller, and how to handle if the user enables VirtIO-SCSI after the creation of the VM (I think the addresses for the existing disks must remain stable, so the controller index must be 1 for the VirtIO-SCSI and 0 for the SPAPR VSCSI in this case).

Do you have any tips on how to implement the disk/cdrom addressing in these cases?

Thanks,
Vitor


>-----Original Message-----
>From: Daniel Erez [mailto:derez at redhat.com]
>Sent: ter?a-feira, 24 de setembro de 2013 09:31
>To: Vitor de Lima
>Cc: engine-devel at ovirt.org
>Subject: Re: [Engine-devel] Issues with VirtIO-SCSI
>
>
>
>----- Original Message -----
>> From: "Vitor de Lima" <vitor.lima at eldorado.org.br>
>> To: "Daniel Erez" <derez at redhat.com>
>> Cc: engine-devel at ovirt.org
>> Sent: Tuesday, September 24, 2013 12:34:17 AM
>> Subject: RE: [Engine-devel] Issues with VirtIO-SCSI
>>
>> Hi Daniel,
>>
>> I asked this question because I have implemented a filter to show only
>> compatible disk interfaces (in change #17964). The main purpose of
>> this patch is to hide the IDE interface type when creating disks for
>> PPC64 VMs (since IDE is not supported on this architecture). If it was
>> decided that the VirtIO-SCSI interface type should be hidden from the
>> user in case it was disabled, I would have to modify that patch a little bit.
>
>For consistency, I'll filter the interface from the list when VirtIO-SCSI is
>disabled.
>So yeah, keep that in mind when modifying your patch.
>
>>
>> Another issue is that in change #18622 the support for a
>> PPC64-specific controller, the SPAPR VSCSI controller, was introduced.
>> But the code was created based on the assumption that the VirtIO-SCSI
>> controller was always present, and this isn't the case anymore. And
>> another patch that I will work on really soon will add support to
>> create disks that are connected to this interface.
>
>Can you filter the option out or add a warning when VirtIO-SCSI is disabled?
>
>>
>> So, I would like some feedback before changing these patches. Is a
>> validation on the backend enough to block the user from using an inexistent
>controller?
>> Should the frontend be changed as well? What would be a good approach
>> to handle multiple SCSI controllers in a VM (were the presence of one
>> of them is optional)?
>
>You should block it in the engine on canDo and filter the option / warn about it
>in the UI.
>Regarding multiple controllers, are you referring to multiple types of
>controllers or just multiple VirtIO-SCSI devices?
>
>>
>> Thanks,
>> Vitor
>>
>>
>>
>> >-----Original Message-----
>> >From: Daniel Erez [mailto:derez at redhat.com]
>> >Sent: segunda-feira, 23 de setembro de 2013 17:06
>> >To: Vitor de Lima
>> >Cc: engine-devel at ovirt.org
>> >Subject: Re: [Engine-devel] Issues with VirtIO-SCSI
>> >
>> >Hi Vitor,
>> >
>> >The new VirtIO-SCSI enabled checkbox is an indication whether to
>> >attach a VirtIO-SCSI controller when running the VM.
>> >It should be enabled automatically on cluster >= 3.3.
>> >
>> >When disabled, I think it's preferable not to add a new controller
>> >automatically when running the VM as it requires creating/attaching a
>> >new VmDevice - which we refrain of on VmInfoBuilder flows (and since
>> >it might be confusing to the user...).
>> >
>> >As an alternative, I've planned to add a warning in the dialog or
>> >create a canDo message to prevent running the VM at all.
>> >I'm not sure we should hide the option from disk interfaces list as
>> >it's already being filtered using VirtIoScsiEnabled
>> >ConfigurationValue (and using OsInfo soon...).
>> >
>> >Let me know what you think and thanks a lot for the input!
>> >
>> >Daniel
>> >
>> >----- Original Message -----
>> >> From: "Vitor de Lima" <vitor.lima at eldorado.org.br>
>> >> To: engine-devel at ovirt.org
>> >> Sent: Monday, September 23, 2013 10:42:39 PM
>> >> Subject: [Engine-devel] Issues with VirtIO-SCSI
>> >>
>> >> Hi everyone,
>> >>
>> >> I have found some issues with this patch:
>> >>
>> >> http://gerrit.ovirt.org/#/c/18638/
>> >>
>> >> It allows the user to disable the VirtIO-SCSI disk interface during
>> >> the VM creation. The problem is that the user still can add, attach
>> >> and hotplug disks with the VirtIO-SCSI interface type, but when the
>> >> user does so, libvirt automatically creates a LSI Logic SCSI
>> >> controller and connects the new disk to it.
>> >>
>> >> How can this problem be solved? Should the VirtIO-SCSI interface
>> >> type be hidden from the user in case it wasn't enabled, or should
>> >> the engine enable the VirtIO-SCSI controller, hotplug it, then
>> >> hotplug the disk into it transparently?
>> >>
>> >> Thanks,
>> >> Vitor de Lima
>> >>
>> >> _______________________________________________
>> >> Engine-devel mailing list
>> >> Engine-devel at ovirt.org
>> >> http://lists.ovirt.org/mailman/listinfo/engine-devel
>> >>
>>

From derez at redhat.com  Tue Sep 24 17:58:04 2013
From: derez at redhat.com (Daniel Erez)
Date: Tue, 24 Sep 2013 13:58:04 -0400 (EDT)
Subject: [Engine-devel] Issues with VirtIO-SCSI
In-Reply-To: <B2CAFC4D5E2D574A883EF61ACD5ADE330181B486@SERV070.corp.eldorado.org.br>
References: <B2CAFC4D5E2D574A883EF61ACD5ADE330181AB51@SERV070.corp.eldorado.org.br>
	<1435657800.857208.1379966741270.JavaMail.root@redhat.com>
	<B2CAFC4D5E2D574A883EF61ACD5ADE330181AC9B@SERV070.corp.eldorado.org.br>
	<814611274.1166105.1380025861475.JavaMail.root@redhat.com>
	<B2CAFC4D5E2D574A883EF61ACD5ADE330181B486@SERV070.corp.eldorado.org.br>
Message-ID: <1165770807.1339526.1380045484954.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Vitor de Lima" <vitor.lima at eldorado.org.br>
> To: "Daniel Erez" <derez at redhat.com>
> Cc: engine-devel at ovirt.org
> Sent: Tuesday, September 24, 2013 6:52:46 PM
> Subject: RE: [Engine-devel] Issues with VirtIO-SCSI
> 
> Hi Daniel,
> 
> I was referring to multiple types of controllers. For now, I think it is
> enough to have only one optional VirtIO-SCSI controller per VM, and (on the
> ppc64) one obligatory SPAPR VSCSI controller. The main question is how to
> handle the addresses when the VirtIO-SCSI is disabled and there is only the
> SPAPR VSCSI controller, and how to handle if the user enables VirtIO-SCSI
> after the creation of the VM (I think the addresses for the existing disks
> must remain stable, so the controller index must be 1 for the VirtIO-SCSI
> and 0 for the SPAPR VSCSI in this case).
> 
> Do you have any tips on how to implement the disk/cdrom addressing in these
> cases?

Regarding the controllers, the address of each controller should be kept
separately - i.e. saved as a VmDevice for maintaining a stable address.
Most changes should probably be done on VmDeviceUtils (look at updateVmDevices 
and copyVmDevice methods) and VmInfoBuilder. Disk/cdrom devices should
be treated similarly. 
As for changing the disk interface, we're clearing the device's address
when switching an interface; so I don't think there's an issue there.
More info on stable addresses can be found here:
http://www.ovirt.org/Features/Design/StableDeviceAddresses

> 
> Thanks,
> Vitor
> 
> 
> >-----Original Message-----
> >From: Daniel Erez [mailto:derez at redhat.com]
> >Sent: ter?a-feira, 24 de setembro de 2013 09:31
> >To: Vitor de Lima
> >Cc: engine-devel at ovirt.org
> >Subject: Re: [Engine-devel] Issues with VirtIO-SCSI
> >
> >
> >
> >----- Original Message -----
> >> From: "Vitor de Lima" <vitor.lima at eldorado.org.br>
> >> To: "Daniel Erez" <derez at redhat.com>
> >> Cc: engine-devel at ovirt.org
> >> Sent: Tuesday, September 24, 2013 12:34:17 AM
> >> Subject: RE: [Engine-devel] Issues with VirtIO-SCSI
> >>
> >> Hi Daniel,
> >>
> >> I asked this question because I have implemented a filter to show only
> >> compatible disk interfaces (in change #17964). The main purpose of
> >> this patch is to hide the IDE interface type when creating disks for
> >> PPC64 VMs (since IDE is not supported on this architecture). If it was
> >> decided that the VirtIO-SCSI interface type should be hidden from the
> >> user in case it was disabled, I would have to modify that patch a little
> >> bit.
> >
> >For consistency, I'll filter the interface from the list when VirtIO-SCSI is
> >disabled.
> >So yeah, keep that in mind when modifying your patch.
> >
> >>
> >> Another issue is that in change #18622 the support for a
> >> PPC64-specific controller, the SPAPR VSCSI controller, was introduced.
> >> But the code was created based on the assumption that the VirtIO-SCSI
> >> controller was always present, and this isn't the case anymore. And
> >> another patch that I will work on really soon will add support to
> >> create disks that are connected to this interface.
> >
> >Can you filter the option out or add a warning when VirtIO-SCSI is disabled?
> >
> >>
> >> So, I would like some feedback before changing these patches. Is a
> >> validation on the backend enough to block the user from using an
> >> inexistent
> >controller?
> >> Should the frontend be changed as well? What would be a good approach
> >> to handle multiple SCSI controllers in a VM (were the presence of one
> >> of them is optional)?
> >
> >You should block it in the engine on canDo and filter the option / warn
> >about it
> >in the UI.
> >Regarding multiple controllers, are you referring to multiple types of
> >controllers or just multiple VirtIO-SCSI devices?
> >
> >>
> >> Thanks,
> >> Vitor
> >>
> >>
> >>
> >> >-----Original Message-----
> >> >From: Daniel Erez [mailto:derez at redhat.com]
> >> >Sent: segunda-feira, 23 de setembro de 2013 17:06
> >> >To: Vitor de Lima
> >> >Cc: engine-devel at ovirt.org
> >> >Subject: Re: [Engine-devel] Issues with VirtIO-SCSI
> >> >
> >> >Hi Vitor,
> >> >
> >> >The new VirtIO-SCSI enabled checkbox is an indication whether to
> >> >attach a VirtIO-SCSI controller when running the VM.
> >> >It should be enabled automatically on cluster >= 3.3.
> >> >
> >> >When disabled, I think it's preferable not to add a new controller
> >> >automatically when running the VM as it requires creating/attaching a
> >> >new VmDevice - which we refrain of on VmInfoBuilder flows (and since
> >> >it might be confusing to the user...).
> >> >
> >> >As an alternative, I've planned to add a warning in the dialog or
> >> >create a canDo message to prevent running the VM at all.
> >> >I'm not sure we should hide the option from disk interfaces list as
> >> >it's already being filtered using VirtIoScsiEnabled
> >> >ConfigurationValue (and using OsInfo soon...).
> >> >
> >> >Let me know what you think and thanks a lot for the input!
> >> >
> >> >Daniel
> >> >
> >> >----- Original Message -----
> >> >> From: "Vitor de Lima" <vitor.lima at eldorado.org.br>
> >> >> To: engine-devel at ovirt.org
> >> >> Sent: Monday, September 23, 2013 10:42:39 PM
> >> >> Subject: [Engine-devel] Issues with VirtIO-SCSI
> >> >>
> >> >> Hi everyone,
> >> >>
> >> >> I have found some issues with this patch:
> >> >>
> >> >> http://gerrit.ovirt.org/#/c/18638/
> >> >>
> >> >> It allows the user to disable the VirtIO-SCSI disk interface during
> >> >> the VM creation. The problem is that the user still can add, attach
> >> >> and hotplug disks with the VirtIO-SCSI interface type, but when the
> >> >> user does so, libvirt automatically creates a LSI Logic SCSI
> >> >> controller and connects the new disk to it.
> >> >>
> >> >> How can this problem be solved? Should the VirtIO-SCSI interface
> >> >> type be hidden from the user in case it wasn't enabled, or should
> >> >> the engine enable the VirtIO-SCSI controller, hotplug it, then
> >> >> hotplug the disk into it transparently?
> >> >>
> >> >> Thanks,
> >> >> Vitor de Lima
> >> >>
> >> >> _______________________________________________
> >> >> Engine-devel mailing list
> >> >> Engine-devel at ovirt.org
> >> >> http://lists.ovirt.org/mailman/listinfo/engine-devel
> >> >>
> >>
>


From zhshzhou at linux.vnet.ibm.com  Wed Sep 25 02:16:16 2013
From: zhshzhou at linux.vnet.ibm.com (Zhou Zheng Sheng)
Date: Wed, 25 Sep 2013 10:16:16 +0800
Subject: [Engine-devel] [vdsm] stale gerrit patches
In-Reply-To: <370781592.886801.1379971283176.JavaMail.root@redhat.com>
References: <524019CA.3080608@redhat.com> <52401BF4.5090800@redhat.com>
	<52401C53.20702@redhat.com>
	<661632990.218831.1379933391058.JavaMail.root@redhat.com>
	<52401CFB.1040300@redhat.com>
	<444143941.219431.1379933576061.JavaMail.root@redhat.com>
	<52401DEF.10607@redhat.com>
	<12011846.220527.1379933951518.JavaMail.root@redhat.com>
	<370781592.886801.1379971283176.JavaMail.root@redhat.com>
Message-ID: <52424770.6060102@linux.vnet.ibm.com>



on 2013/09/24 05:21, Ayal Baron wrote:
> 
> 
> ----- Original Message -----
>>
>>
>> ----- Original Message -----
>>> From: "Itamar Heim" <iheim at redhat.com>
>>> To: "Alon Bar-Lev" <alonbl at redhat.com>
>>> Cc: "David Caro" <dcaroest at redhat.com>, "engine-devel"
>>> <engine-devel at ovirt.org>, vdsm-devel at lists.fedorahosted.org
>>> Sent: Monday, September 23, 2013 1:54:39 PM
>>> Subject: Re: [vdsm] stale gerrit patches
>>>
>>> On 09/23/2013 01:52 PM, Alon Bar-Lev wrote:
>>>>
>>>>
>>>> ----- Original Message -----
>>>>> From: "Itamar Heim" <iheim at redhat.com>
>>>>> To: "Alon Bar-Lev" <alonbl at redhat.com>
>>>>> Cc: "David Caro" <dcaroest at redhat.com>, "engine-devel"
>>>>> <engine-devel at ovirt.org>, vdsm-devel at lists.fedorahosted.org
>>>>> Sent: Monday, September 23, 2013 1:50:35 PM
>>>>> Subject: Re: [vdsm] stale gerrit patches
>>>>>
>>>>> On 09/23/2013 01:49 PM, Alon Bar-Lev wrote:
>>>>>>
>>>>>>
>>>>>> ----- Original Message -----
>>>>>>> From: "Itamar Heim" <iheim at redhat.com>
>>>>>>> To: "David Caro" <dcaroest at redhat.com>
>>>>>>> Cc: "engine-devel" <engine-devel at ovirt.org>,
>>>>>>> vdsm-devel at lists.fedorahosted.org
>>>>>>> Sent: Monday, September 23, 2013 1:47:47 PM
>>>>>>> Subject: Re: [vdsm] stale gerrit patches
>>>>>>>
>>>>>>> On 09/23/2013 01:46 PM, David Caro wrote:
>>>>>>>> On Mon 23 Sep 2013 12:36:58 PM CEST, Itamar Heim wrote:
>>>>>>>>> we have some very old gerrit patches.
>>>>>>>>> I'm for abandoning patches which were not touched over 60 days (to
>>>>>>>>> begin with, I think the number should actually be lower).
>>>>>>>>> they can always be re-opened by any interested party post their
>>>>>>>>> closure.
>>>>>>>>>
>>>>>>>>> i.e., looking at gerrit, the patch list should actually get
>>>>>>>>> attention,
>>>>>>>>> and not be a few worth looking at, with a "lot of old patches"
>>>>>>>>>
>>>>>>>>> thoughts?
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>>       Itamar
>>>>>>>>> _______________________________________________
>>>>>>>>> vdsm-devel mailing list
>>>>>>>>> vdsm-devel at lists.fedorahosted.org
>>>>>>>>> https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
>>>>>>>>
>>>>>>>> It might helpful to have a cron-like script that checks the age of
>>>>>>>> the
>>>>>>>> posts and first notifies the sender, the reviewers and the
>>>>>>>> maintainer,
>>>>>>>> and if the patch is not updated in a certain period just abandons it.
>>>>>>>>
>>>>>>>
>>>>>>> yep - warn after X days via email to just owner (or all subscribed to
>>>>>>> the patch), and close if no activity for X+14 days or something like
>>>>>>> that.
>>>>>>
>>>>>> This will be annoying.
>>>>>>
>>>>>> And there are patches that pending with good reason.
>>>>>
>>>>> pending for 60 days with zero activity on them (no comment, no rebase,
>>>>> nothing)?
>>>>
>>>> http://gerrit.ovirt.org/#/q/status:open+project:ovirt-engine+branch:master+topic:independent_deployments,n,z
>>>
>>> so how does it help us to have these patches, some without any comment
>>> from any reviewer.
>>> lets get them reviewed and decide one way or the other, rather than let
>>> them get old and stay forever
>>
>> Again... maintainer can close these if he likes.
>> Owner can close these if he likes.
> 
> right, but why?
> a patch without activity being abandoned might actually spur someone into motion (rebasing and resubmitting, prodding maintainers etc).
> I'm +1 for automatically abandoning old patches.
> 

At least we all agree on that old patches should be abandoned.

I think we can do this in a semi-automatic way. A cron job checks the
patch's freshness, and sends an email to warn the author and reviewers
of an old patch. If the someone has a good reason to keep the patch, he
can leave a comment on the gerrit web page saying "I want to #keep the
patch# because ...". Then the system skips the patches whose last
comment contains "#keep the patch#". If no one cares it, the patch is
abandoned after some time.
-- 
Thanks and best regards!

Zhou Zheng Sheng / ???
E-mail: zhshzhou at linux.vnet.ibm.com
Telephone: 86-10-82454397



From oschreib at redhat.com  Wed Sep 25 07:40:33 2013
From: oschreib at redhat.com (Ofer Schreiber)
Date: Wed, 25 Sep 2013 03:40:33 -0400 (EDT)
Subject: [Engine-devel] 3.3.0.1 Release branch and tracker
In-Reply-To: <346535272.1580513.1380094466740.JavaMail.root@redhat.com>
Message-ID: <908884064.1583325.1380094833753.JavaMail.root@redhat.com>

Hey,

As you may know, we're planning to release oVirt 3.3.0.1 soon.
I've created a tracker bug (https://bugzilla.redhat.com/show_bug.cgi?id=1011800) and a git branch (ovirt-engine-3.3.0.1, based on 3.3.0) for this release.

If you're working on a really urgent bug, please notify me or Mike, so it will be included in next version, otherwise, most issues will be included in 3.3.1 which will be based on the ovirt-engine-3.3 branch.
Please don't merge anything into 3.3.0.1 without consulting.
If all those branches and releases makes you dizzy, ping me on IRC and I'll try to clear it out.

Thanks,

Ofer Schreiber


From alonbl at redhat.com  Wed Sep 25 07:49:40 2013
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Wed, 25 Sep 2013 03:49:40 -0400 (EDT)
Subject: [Engine-devel] 3.3.0.1 Release branch and tracker
In-Reply-To: <908884064.1583325.1380094833753.JavaMail.root@redhat.com>
References: <908884064.1583325.1380094833753.JavaMail.root@redhat.com>
Message-ID: <685899658.1169021.1380095380623.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Ofer Schreiber" <oschreib at redhat.com>
> To: "engine-devel" <engine-devel at ovirt.org>
> Sent: Wednesday, September 25, 2013 10:40:33 AM
> Subject: [Engine-devel] 3.3.0.1 Release branch and tracker
> 
> Hey,
> 
> As you may know, we're planning to release oVirt 3.3.0.1 soon.
> I've created a tracker bug
> (https://bugzilla.redhat.com/show_bug.cgi?id=1011800) and a git branch
> (ovirt-engine-3.3.0.1, based on 3.3.0) for this release.
> 

Once again, I do not understand why go into 4 digit version and not release 3.3.1 as z-stream, deferring remaining queue to 3.3.2.

The argument of small/large change is irrelevant in z-stream as something small for one can be important for other.

The number should not be important, whenever z-stream is released you take last+1.

Regards,
Alon Bar-Lev.


From danken at redhat.com  Wed Sep 25 08:53:46 2013
From: danken at redhat.com (Dan Kenigsberg)
Date: Wed, 25 Sep 2013 09:53:46 +0100
Subject: [Engine-devel] 3.3.0.1 Release branch and tracker
In-Reply-To: <685899658.1169021.1380095380623.JavaMail.root@redhat.com>
References: <908884064.1583325.1380094833753.JavaMail.root@redhat.com>
	<685899658.1169021.1380095380623.JavaMail.root@redhat.com>
Message-ID: <20130925085346.GD12879@redhat.com>

On Wed, Sep 25, 2013 at 03:49:40AM -0400, Alon Bar-Lev wrote:
> 
> 
> ----- Original Message -----
> > From: "Ofer Schreiber" <oschreib at redhat.com>
> > To: "engine-devel" <engine-devel at ovirt.org>
> > Sent: Wednesday, September 25, 2013 10:40:33 AM
> > Subject: [Engine-devel] 3.3.0.1 Release branch and tracker
> > 
> > Hey,
> > 
> > As you may know, we're planning to release oVirt 3.3.0.1 soon.
> > I've created a tracker bug
> > (https://bugzilla.redhat.com/show_bug.cgi?id=1011800) and a git branch
> > (ovirt-engine-3.3.0.1, based on 3.3.0) for this release.
> > 
> 
> Once again, I do not understand why go into 4 digit version and not release 3.3.1 as z-stream, deferring remaining queue to 3.3.2.
> 
> The argument of small/large change is irrelevant in z-stream as something small for one can be important for other.
> 
> The number should not be important, whenever z-stream is released you take last+1.

hear hear. Z is the last letter of the English alphabet. We should not
go past it, unless 3.3.1 was already in beta and we have to ship a quick
3.3.0.1.


From iheim at redhat.com  Wed Sep 25 11:18:42 2013
From: iheim at redhat.com (Itamar Heim)
Date: Wed, 25 Sep 2013 14:18:42 +0300
Subject: [Engine-devel] 3.3.0.1 Release branch and tracker
In-Reply-To: <20130925085346.GD12879@redhat.com>
References: <908884064.1583325.1380094833753.JavaMail.root@redhat.com>
	<685899658.1169021.1380095380623.JavaMail.root@redhat.com>
	<20130925085346.GD12879@redhat.com>
Message-ID: <5242C692.5020608@redhat.com>

On 09/25/2013 11:53 AM, Dan Kenigsberg wrote:
> On Wed, Sep 25, 2013 at 03:49:40AM -0400, Alon Bar-Lev wrote:
>>
>>
>> ----- Original Message -----
>>> From: "Ofer Schreiber" <oschreib at redhat.com>
>>> To: "engine-devel" <engine-devel at ovirt.org>
>>> Sent: Wednesday, September 25, 2013 10:40:33 AM
>>> Subject: [Engine-devel] 3.3.0.1 Release branch and tracker
>>>
>>> Hey,
>>>
>>> As you may know, we're planning to release oVirt 3.3.0.1 soon.
>>> I've created a tracker bug
>>> (https://bugzilla.redhat.com/show_bug.cgi?id=1011800) and a git branch
>>> (ovirt-engine-3.3.0.1, based on 3.3.0) for this release.
>>>
>>
>> Once again, I do not understand why go into 4 digit version and not release 3.3.1 as z-stream, deferring remaining queue to 3.3.2.
>>
>> The argument of small/large change is irrelevant in z-stream as something small for one can be important for other.
>>
>> The number should not be important, whenever z-stream is released you take last+1.
>
> hear hear. Z is the last letter of the English alphabet. We should not
> go past it, unless 3.3.1 was already in beta and we have to ship a quick
> 3.3.0.1.
>

because we should be able to number things and plan to them. not have to 
revisit all ovirt bugs targeted to 3.3.1 and change them to 3.3.2, since 
we need to do something in async, etc.
we also communicated 3.3.1 will have a rebase, or will have something 
specific around it. we can't re-number the messaging for every async update.


From iheim at redhat.com  Wed Sep 25 11:19:24 2013
From: iheim at redhat.com (Itamar Heim)
Date: Wed, 25 Sep 2013 14:19:24 +0300
Subject: [Engine-devel] 3.3.0.1 Release branch and tracker
In-Reply-To: <908884064.1583325.1380094833753.JavaMail.root@redhat.com>
References: <908884064.1583325.1380094833753.JavaMail.root@redhat.com>
Message-ID: <5242C6BC.2000002@redhat.com>

On 09/25/2013 10:40 AM, Ofer Schreiber wrote:
> Hey,
>
> As you may know, we're planning to release oVirt 3.3.0.1 soon.
> I've created a tracker bug (https://bugzilla.redhat.com/show_bug.cgi?id=1011800) and a git branch (ovirt-engine-3.3.0.1, based on 3.3.0) for this release.
>
> If you're working on a really urgent bug, please notify me or Mike, so it will be included in next version, otherwise, most issues will be included in 3.3.1 which will be based on the ovirt-engine-3.3 branch.
> Please don't merge anything into 3.3.0.1 without consulting.
> If all those branches and releases makes you dizzy, ping me on IRC and I'll try to clear it out.
>
> Thanks,
>
> Ofer Schreiber
>

also, please make sure any bug going to a stable branch has a bug-url, 
to allow decent release notes on stable releases.

Thanks,
    Itamar


From alonbl at redhat.com  Wed Sep 25 11:26:14 2013
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Wed, 25 Sep 2013 07:26:14 -0400 (EDT)
Subject: [Engine-devel] 3.3.0.1 Release branch and tracker
In-Reply-To: <5242C692.5020608@redhat.com>
References: <908884064.1583325.1380094833753.JavaMail.root@redhat.com>
	<685899658.1169021.1380095380623.JavaMail.root@redhat.com>
	<20130925085346.GD12879@redhat.com> <5242C692.5020608@redhat.com>
Message-ID: <544835708.1258248.1380108374922.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Itamar Heim" <iheim at redhat.com>
> To: "Dan Kenigsberg" <danken at redhat.com>
> Cc: "Alon Bar-Lev" <alonbl at redhat.com>, "Ofer Schreiber" <oschreib at redhat.com>, "engine-devel"
> <engine-devel at ovirt.org>
> Sent: Wednesday, September 25, 2013 2:18:42 PM
> Subject: Re: [Engine-devel] 3.3.0.1 Release branch and tracker
> 
> On 09/25/2013 11:53 AM, Dan Kenigsberg wrote:
> > On Wed, Sep 25, 2013 at 03:49:40AM -0400, Alon Bar-Lev wrote:
> >>
> >>
> >> ----- Original Message -----
> >>> From: "Ofer Schreiber" <oschreib at redhat.com>
> >>> To: "engine-devel" <engine-devel at ovirt.org>
> >>> Sent: Wednesday, September 25, 2013 10:40:33 AM
> >>> Subject: [Engine-devel] 3.3.0.1 Release branch and tracker
> >>>
> >>> Hey,
> >>>
> >>> As you may know, we're planning to release oVirt 3.3.0.1 soon.
> >>> I've created a tracker bug
> >>> (https://bugzilla.redhat.com/show_bug.cgi?id=1011800) and a git branch
> >>> (ovirt-engine-3.3.0.1, based on 3.3.0) for this release.
> >>>
> >>
> >> Once again, I do not understand why go into 4 digit version and not
> >> release 3.3.1 as z-stream, deferring remaining queue to 3.3.2.
> >>
> >> The argument of small/large change is irrelevant in z-stream as something
> >> small for one can be important for other.
> >>
> >> The number should not be important, whenever z-stream is released you take
> >> last+1.
> >
> > hear hear. Z is the last letter of the English alphabet. We should not
> > go past it, unless 3.3.1 was already in beta and we have to ship a quick
> > 3.3.0.1.
> >
> 
> because we should be able to number things and plan to them. not have to
> revisit all ovirt bugs targeted to 3.3.1 and change them to 3.3.2, since
> we need to do something in async, etc.
> we also communicated 3.3.1 will have a rebase, or will have something
> specific around it. we can't re-number the messaging for every async update.
> 

We are not the only project that cope with z-stream. There is no reason to be unique.

There is expected scheme of release management and versioning scheme, let's not re-invent the wheel.

Pushing in bugzilla all 3.3.1 -> 3.3.2 is simple task, and as release maintainer does that, he may find that some of the fixes applied to 3.3.1 should remain in 3.3.1 and better released at that chance.

Regards,
Alon


From mburns at redhat.com  Wed Sep 25 12:19:44 2013
From: mburns at redhat.com (Mike Burns)
Date: Wed, 25 Sep 2013 08:19:44 -0400
Subject: [Engine-devel] 3.3.0.1 Release branch and tracker
In-Reply-To: <5242C6BC.2000002@redhat.com>
References: <908884064.1583325.1380094833753.JavaMail.root@redhat.com>
	<5242C6BC.2000002@redhat.com>
Message-ID: <5242D4E0.90900@redhat.com>

On 09/25/2013 07:19 AM, Itamar Heim wrote:
> On 09/25/2013 10:40 AM, Ofer Schreiber wrote:
>> Hey,
>>
>> As you may know, we're planning to release oVirt 3.3.0.1 soon.
>> I've created a tracker bug
>> (https://bugzilla.redhat.com/show_bug.cgi?id=1011800) and a git branch
>> (ovirt-engine-3.3.0.1, based on 3.3.0) for this release.
>>
>> If you're working on a really urgent bug, please notify me or Mike, so
>> it will be included in next version, otherwise, most issues will be
>> included in 3.3.1 which will be based on the ovirt-engine-3.3 branch.
>> Please don't merge anything into 3.3.0.1 without consulting.
>> If all those branches and releases makes you dizzy, ping me on IRC and
>> I'll try to clear it out.
>>
>> Thanks,
>>
>> Ofer Schreiber
>>
>
> also, please make sure any bug going to a stable branch has a bug-url,
> to allow decent release notes on stable releases.
>
> Thanks,
>     Itamar

I assume that it goes without saying (but I'll say it anyway) that 
patches should go to master before going to any release specific branch.

Mike


From michal.skrivanek at redhat.com  Thu Sep 26 14:00:20 2013
From: michal.skrivanek at redhat.com (Michal Skrivanek)
Date: Thu, 26 Sep 2013 16:00:20 +0200
Subject: [Engine-devel] 3.3.0.1 Release branch and tracker
In-Reply-To: <908884064.1583325.1380094833753.JavaMail.root@redhat.com>
References: <908884064.1583325.1380094833753.JavaMail.root@redhat.com>
Message-ID: <5F986E20-71D2-45B8-B92A-9BFA1D499193@redhat.com>

Hi,
bug 1011547 may deserve it?
let me/Martin know what you think
If not we'll just go with 3.3.1

Thanks,
michal

On Sep 25, 2013, at 09:40 , Ofer Schreiber <oschreib at redhat.com> wrote:

> Hey,
> 
> As you may know, we're planning to release oVirt 3.3.0.1 soon.
> I've created a tracker bug (https://bugzilla.redhat.com/show_bug.cgi?id=1011800) and a git branch (ovirt-engine-3.3.0.1, based on 3.3.0) for this release.
> 
> If you're working on a really urgent bug, please notify me or Mike, so it will be included in next version, otherwise, most issues will be included in 3.3.1 which will be based on the ovirt-engine-3.3 branch.
> Please don't merge anything into 3.3.0.1 without consulting.
> If all those branches and releases makes you dizzy, ping me on IRC and I'll try to clear it out.
> 
> Thanks,
> 
> Ofer Schreiber
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel



From iheim at redhat.com  Thu Sep 26 14:45:17 2013
From: iheim at redhat.com (Itamar Heim)
Date: Thu, 26 Sep 2013 17:45:17 +0300
Subject: [Engine-devel] 3.3.0.1 Release branch and tracker
In-Reply-To: <5F986E20-71D2-45B8-B92A-9BFA1D499193@redhat.com>
References: <908884064.1583325.1380094833753.JavaMail.root@redhat.com>
	<5F986E20-71D2-45B8-B92A-9BFA1D499193@redhat.com>
Message-ID: <5244487D.9060907@redhat.com>

On 09/26/2013 05:00 PM, Michal Skrivanek wrote:
> Hi,
> bug 1011547 may deserve it?
> let me/Martin know what you think
> If not we'll just go with 3.3.1

makes sense. just make sure its backported to 3.3.1 (ovirt-engine-3.3) 
stable and 3.3.0.1 (ovirt-engine-3.3.0) branches.

>
> Thanks,
> michal
>
> On Sep 25, 2013, at 09:40 , Ofer Schreiber <oschreib at redhat.com> wrote:
>
>> Hey,
>>
>> As you may know, we're planning to release oVirt 3.3.0.1 soon.
>> I've created a tracker bug (https://bugzilla.redhat.com/show_bug.cgi?id=1011800) and a git branch (ovirt-engine-3.3.0.1, based on 3.3.0) for this release.
>>
>> If you're working on a really urgent bug, please notify me or Mike, so it will be included in next version, otherwise, most issues will be included in 3.3.1 which will be based on the ovirt-engine-3.3 branch.
>> Please don't merge anything into 3.3.0.1 without consulting.
>> If all those branches and releases makes you dizzy, ping me on IRC and I'll try to clear it out.
>>
>> Thanks,
>>
>> Ofer Schreiber
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>



From oschreib at redhat.com  Thu Sep 26 15:17:57 2013
From: oschreib at redhat.com (Ofer Schreiber)
Date: Thu, 26 Sep 2013 11:17:57 -0400 (EDT)
Subject: [Engine-devel] 3.3.0.1 Release branch and tracker
In-Reply-To: <5244487D.9060907@redhat.com>
References: <908884064.1583325.1380094833753.JavaMail.root@redhat.com>
	<5F986E20-71D2-45B8-B92A-9BFA1D499193@redhat.com>
	<5244487D.9060907@redhat.com>
Message-ID: <59C573D1-E47F-4FA9-AA8C-68A8569D9FC2@redhat.com>

3.3.0.1 is ovirt-engine-3.3.0.1



??-26 Sep 2013, ???? 17:45, ?Itamar Heim <iheim at redhat.com> ???/?:?

>> On 09/26/2013 05:00 PM, Michal Skrivanek wrote:
>> Hi,
>> bug 1011547 may deserve it?
>> let me/Martin know what you think
>> If not we'll just go with 3.3.1
> 
> makes sense. just make sure its backported to 3.3.1 (ovirt-engine-3.3) stable and 3.3.0.1 (ovirt-engine-3.3.0) branches.
> 
>> 
>> Thanks,
>> michal
>> 
>>> On Sep 25, 2013, at 09:40 , Ofer Schreiber <oschreib at redhat.com> wrote:
>>> 
>>> Hey,
>>> 
>>> As you may know, we're planning to release oVirt 3.3.0.1 soon.
>>> I've created a tracker bug (https://bugzilla.redhat.com/show_bug.cgi?id=1011800) and a git branch (ovirt-engine-3.3.0.1, based on 3.3.0) for this release.
>>> 
>>> If you're working on a really urgent bug, please notify me or Mike, so it will be included in next version, otherwise, most issues will be included in 3.3.1 which will be based on the ovirt-engine-3.3 branch.
>>> Please don't merge anything into 3.3.0.1 without consulting.
>>> If all those branches and releases makes you dizzy, ping me on IRC and I'll try to clear it out.
>>> 
>>> Thanks,
>>> 
>>> Ofer Schreiber
>>> _______________________________________________
>>> Engine-devel mailing list
>>> Engine-devel at ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>> 
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20130926/c69e2d55/attachment.html>

From emesika at redhat.com  Thu Sep 26 20:01:31 2013
From: emesika at redhat.com (Eli Mesika)
Date: Thu, 26 Sep 2013 16:01:31 -0400 (EDT)
Subject: [Engine-devel] External events and flood rate
In-Reply-To: <5240197F.7090708@redhat.com>
References: <D290AD8432118048947689BA3AE8A9B33C9B351C@SACEXCMBX04-PRD.hq.netapp.com>
	<5240197F.7090708@redhat.com>
Message-ID: <323635173.3003190.1380225691777.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Michael Pasternak" <mpastern at redhat.com>
> To: "Eli Mesika" <emesika at redhat.com>
> Cc: "Christopher Morrissey" <Christopher.Morrissey at netapp.com>, engine-devel at ovirt.org
> Sent: Monday, September 23, 2013 1:35:43 PM
> Subject: Re: [Engine-devel] External events and flood rate
> 
> Eli,
> 
> any reason for hardcoding this [1]? i'd move it to vdc_config.

The reason was to lower the risk of external event flooding , but I agree that it can be configurable....

> 
> [1] Math.max(auditLogable.getEventFloodInSec(), 30) // Min duration for
> External Events is 30 sec
> 
> On 09/19/2013 12:50 AM, Morrissey, Christopher wrote:
> > Hi All,
> > 
> >  
> > 
> > I?ve been working on submitting external events to oVirt through the REST
> > API. It seems to be working in general, although it appears that, no
> > matter what value I put for
> > the flood rate in the event, only 1 or so events are allowed every 30
> > seconds. If I send another event during this time, I get an operation
> > failed exception. Should the
> > flood rate have any impact on this? Is there any way to allow my code to
> > get an event through when needed or should I have a thread that shoots
> > them off every 30 seconds if
> > several occur too quickly together?
> > 
> >  
> > 
> > -Chris
> > 
> >  
> > 
> > *Chris Morrissey*
> > 
> > Software Engineer
> > 
> > NetApp Inc.
> > 
> > 919.476.4428
> > 
> >  
> > 
> > 
> > 
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > 
> 
> 
> --
> 
> Michael Pasternak
> RedHat, ENG-Virtualization R&D
> 


From tjelinek at redhat.com  Fri Sep 27 11:32:14 2013
From: tjelinek at redhat.com (Tomas Jelinek)
Date: Fri, 27 Sep 2013 07:32:14 -0400 (EDT)
Subject: [Engine-devel] Introducing generics to UiCommon
In-Reply-To: <247427421.11376161.1375688489773.JavaMail.root@redhat.com>
References: <247427421.11376161.1375688489773.JavaMail.root@redhat.com>
Message-ID: <1251012257.4042811.1380281534199.JavaMail.root@redhat.com>

Hey all,

some time ago I have created a patch which introduces generics to UiCommon [1] and one which uses it 
in DataCenterModel [2]. Today I have changed a bit the generic version of the EntityModelTextBox to
be truly generic (since it can edit also e.g. integers) and than a simple subclass StringEntityModelTextBox
which provides the String renderer/parser to simplify the usage. All the other details are available in the previous
mail.

What do you think about it?

Tomas

[1]: http://gerrit.ovirt.org/#/c/17604/
[2]: http://gerrit.ovirt.org/#/c/17605/

----- Original Message -----
> From: "Tomas Jelinek" <tjelinek at redhat.com>
> To: "engine-devel" <engine-devel at ovirt.org>
> Sent: Monday, August 5, 2013 9:41:29 AM
> Subject: [Engine-devel]  Introducing generics to UiCommon
> 
> Hey all,
> 
> as we have passed the oVirt feature freeze I would like to celebrate it with
> a little bit of cleanup :)
> 
> A good candidate for this is to introduce generics into uicommonweb project.
> The fact that it is not generic
> brings quite some hidden expectations into our code, makes it unreadable and
> error prone.
> 
> Also, the gwt-common and both webadmin and userportal are mostly prepared to
> be generic but because the uicommonweb is not, we have code like:
> 
> new ListModelListBoxEditor<Object>(new NullSafeRenderer<Object>() {
>             @Override
>             public String renderNullSafe(Object object)
>                 return ((Version) object).getValue();
>             }
>         });
> 
> which is quite ugly and error prone.
> 
> So I have prepared two patches, one [1] which introduces the generic
> infrastructure (and prepares one widget for it, more about this below) and
> one [2] which uses it and refactors the DataCenterModel
> to use it (I have chosen this model because it is big enough to show how to
> do it and what the benefits are but small enough to be quickly review-able).
> 
> The infrastructure change:
> - changes the ListModel and EntityModel to be genreic
> - adjusts the UiCommonEditorDriverGenerator to work with generics (e.g. to
> make it aware that ListModel<String> is indeed a ListModel, same for
> EntityModel)
> - created a String version of EntityModelTextBox
> 
> The reason why the String EntityModelTextBox had to be created is that the
> EntityModelTextBox is an EditorWidget<Object, ...> so it can work only with
> EntityModel<Object>. I saw 2 ways how to make this work with
> EntityModel<String>:
> 1: Create a String version of this editor inside the .generic sub-package,
> incrementally replace the usage of the non-generic EntityModelTextBox and
> when the non-generic will be completely replaced, delete it and move the
> generic one
>    out from the generic sub-package
> 
> 2: Change the EditorWidget<Object, ...> to EditorWidget<T, ...> and replace
> each usage of the "EntityModelTextBox someWidget" by
> "EntityModelTextBox<Object> someWidget" and than incrementally replace the
> <Object> to <String> as the
>    underlying models will be refactored. After the last one will be
>    refactored, change the EditorWidget<T, ...> to EditorWidget<String, ...>
>    and replace all "EntityModelTextBox<Object> someWidget" by
>    "EntityModelTextBox someWidget"
> 
> I have chosen the first option because:
> - much less classes touched at once (e.g. much more safe)
> - the EntityModelTextBox<T> invites to use something like
> EntityModelTextBox<VM> which is not correct and fails on class cast
> exceptions
> 
> But at the same time I see the disadvantages of this approach (mostly that we
> have two versions of the same class). Please note that far not all the
> widgets will need two versions, only the ones editing only Strings which
> are declared as EditorWidget<Object> which are:
> - EntityModelLabel
> - EntityModelTextAreaLabel (used only in couple of places - can be refactored
> together without the need to have two versions)
> - EntityModelTextBox (already in the [1])
> - EntityModelPasswordBox
> - EntityModelTextArea
> - ListModelSuggestBox (used only in couple of places - can be refactored
> together without the need to have two versions)
> 
> The rest of the widgets should be already prepared to be used in generic
> environment.
> 
> Please let me know what do you think about it,
> 
> have a nice day,
> Tomas
> 
> [1]: http://gerrit.ovirt.org/#/c/17604/
> [2]: http://gerrit.ovirt.org/#/c/17605/
> 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From kiril at redhat.com  Sat Sep 28 12:14:25 2013
From: kiril at redhat.com (Kiril Nesenko)
Date: Sat, 28 Sep 2013 08:14:25 -0400 (EDT)
Subject: [Engine-devel] Suggesting new packaging and setup maintainer
In-Reply-To: <1251753356.926231.1380021109609.JavaMail.root@redhat.com>
References: <1271829417.461834.1379933376488.JavaMail.root@redhat.com>
	<524153A6.6070804@redhat.com>
	<1251753356.926231.1380021109609.JavaMail.root@redhat.com>
Message-ID: <1138215725.46154.1380370465651.JavaMail.root@redhat.com>

+1 from me.

- Kiril

----- Original Message -----
> From: "Keith Robertson" <kroberts at redhat.com>
> To: "board" <board at ovirt.org>, "engine-devel" <engine-devel at ovirt.org>
> Sent: Tuesday, September 24, 2013 2:11:49 PM
> Subject: Re: [Engine-devel] Suggesting new packaging and setup maintainer
> 
> +1
> 
> 
> 
> > On 09/23/2013 12:49 PM, Ofer Schreiber wrote:
> > > Nominating Sandro Bonazzola as packaging and setup maintainer
> > > ----------------------------------------------------------
> > > 
> > > During his recent year of participation in ovirt-engine development,
> > > Sandro demonstrated a genuine care for the product health, great coding
> > > abilities,
> > > and great responsibility to the setup and packaging components.
> > > 
> > > Sandro's contribution the the project is undoubtable, he's responsible
> > > for
> > > over 70 patches in ovirt-engine,
> > > and he's the maintainer of log-collector, iso-uploader and image-uploader
> > > packages.
> > > 
> > > I suggest that Sandro will obtain +2 and merge rights in the ovirt-engine
> > > gerrit project,
> > > in the understanding that those rights should be used only in packaging
> > > and
> > > setup parts of the code.
> > > 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From ybronhei at redhat.com  Sun Sep 29 09:52:53 2013
From: ybronhei at redhat.com (Yaniv Bronheim)
Date: Sun, 29 Sep 2013 05:52:53 -0400 (EDT)
Subject: [Engine-devel] [vdsm] stale gerrit patches
In-Reply-To: <52424770.6060102@linux.vnet.ibm.com>
References: <524019CA.3080608@redhat.com>
	<661632990.218831.1379933391058.JavaMail.root@redhat.com>
	<52401CFB.1040300@redhat.com>
	<444143941.219431.1379933576061.JavaMail.root@redhat.com>
	<52401DEF.10607@redhat.com>
	<12011846.220527.1379933951518.JavaMail.root@redhat.com>
	<370781592.886801.1379971283176.JavaMail.root@redhat.com>
	<52424770.6060102@linux.vnet.ibm.com>
Message-ID: <65434308.52864.1380448373226.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Zhou Zheng Sheng" <zhshzhou at linux.vnet.ibm.com>
> To: "Ayal Baron" <abaron at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>, vdsm-devel at lists.fedorahosted.org
> Sent: Wednesday, September 25, 2013 5:16:16 AM
> Subject: Re: [Engine-devel] [vdsm] stale gerrit patches
> 
> 
> 
> on 2013/09/24 05:21, Ayal Baron wrote:
> > 
> > 
> > ----- Original Message -----
> >>
> >>
> >> ----- Original Message -----
> >>> From: "Itamar Heim" <iheim at redhat.com>
> >>> To: "Alon Bar-Lev" <alonbl at redhat.com>
> >>> Cc: "David Caro" <dcaroest at redhat.com>, "engine-devel"
> >>> <engine-devel at ovirt.org>, vdsm-devel at lists.fedorahosted.org
> >>> Sent: Monday, September 23, 2013 1:54:39 PM
> >>> Subject: Re: [vdsm] stale gerrit patches
> >>>
> >>> On 09/23/2013 01:52 PM, Alon Bar-Lev wrote:
> >>>>
> >>>>
> >>>> ----- Original Message -----
> >>>>> From: "Itamar Heim" <iheim at redhat.com>
> >>>>> To: "Alon Bar-Lev" <alonbl at redhat.com>
> >>>>> Cc: "David Caro" <dcaroest at redhat.com>, "engine-devel"
> >>>>> <engine-devel at ovirt.org>, vdsm-devel at lists.fedorahosted.org
> >>>>> Sent: Monday, September 23, 2013 1:50:35 PM
> >>>>> Subject: Re: [vdsm] stale gerrit patches
> >>>>>
> >>>>> On 09/23/2013 01:49 PM, Alon Bar-Lev wrote:
> >>>>>>
> >>>>>>
> >>>>>> ----- Original Message -----
> >>>>>>> From: "Itamar Heim" <iheim at redhat.com>
> >>>>>>> To: "David Caro" <dcaroest at redhat.com>
> >>>>>>> Cc: "engine-devel" <engine-devel at ovirt.org>,
> >>>>>>> vdsm-devel at lists.fedorahosted.org
> >>>>>>> Sent: Monday, September 23, 2013 1:47:47 PM
> >>>>>>> Subject: Re: [vdsm] stale gerrit patches
> >>>>>>>
> >>>>>>> On 09/23/2013 01:46 PM, David Caro wrote:
> >>>>>>>> On Mon 23 Sep 2013 12:36:58 PM CEST, Itamar Heim wrote:
> >>>>>>>>> we have some very old gerrit patches.
> >>>>>>>>> I'm for abandoning patches which were not touched over 60 days (to
> >>>>>>>>> begin with, I think the number should actually be lower).
> >>>>>>>>> they can always be re-opened by any interested party post their
> >>>>>>>>> closure.
> >>>>>>>>>
> >>>>>>>>> i.e., looking at gerrit, the patch list should actually get
> >>>>>>>>> attention,
> >>>>>>>>> and not be a few worth looking at, with a "lot of old patches"
> >>>>>>>>>
> >>>>>>>>> thoughts?
> >>>>>>>>>
> >>>>>>>>> Thanks,
> >>>>>>>>>       Itamar
> >>>>>>>>> _______________________________________________
> >>>>>>>>> vdsm-devel mailing list
> >>>>>>>>> vdsm-devel at lists.fedorahosted.org
> >>>>>>>>> https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
> >>>>>>>>
> >>>>>>>> It might helpful to have a cron-like script that checks the age of
> >>>>>>>> the
> >>>>>>>> posts and first notifies the sender, the reviewers and the
> >>>>>>>> maintainer,
> >>>>>>>> and if the patch is not updated in a certain period just abandons
> >>>>>>>> it.
> >>>>>>>>
> >>>>>>>
> >>>>>>> yep - warn after X days via email to just owner (or all subscribed to
> >>>>>>> the patch), and close if no activity for X+14 days or something like
> >>>>>>> that.
> >>>>>>
> >>>>>> This will be annoying.
> >>>>>>
> >>>>>> And there are patches that pending with good reason.
> >>>>>
> >>>>> pending for 60 days with zero activity on them (no comment, no rebase,
> >>>>> nothing)?
> >>>>
> >>>> http://gerrit.ovirt.org/#/q/status:open+project:ovirt-engine+branch:master+topic:independent_deployments,n,z
> >>>
> >>> so how does it help us to have these patches, some without any comment
> >>> from any reviewer.
> >>> lets get them reviewed and decide one way or the other, rather than let
> >>> them get old and stay forever
> >>
> >> Again... maintainer can close these if he likes.
> >> Owner can close these if he likes.
> > 
> > right, but why?
> > a patch without activity being abandoned might actually spur someone into
> > motion (rebasing and resubmitting, prodding maintainers etc).
> > I'm +1 for automatically abandoning old patches.
> > 
> 
> At least we all agree on that old patches should be abandoned.
> 
> I think we can do this in a semi-automatic way. A cron job checks the
> patch's freshness, and sends an email to warn the author and reviewers
> of an old patch. If the someone has a good reason to keep the patch, he
> can leave a comment on the gerrit web page saying "I want to #keep the
> patch# because ...". Then the system skips the patches whose last
> comment contains "#keep the patch#". If no one cares it, the patch is
> abandoned after some time.

+1 for Zhou Zheng Sheng.
Much better suggestion than automatically forgetting old patches by removing them.
A reminder can be sent after couple of weeks or even a month, and auto abandon the patch if no response added to the bug within a week.

I like this suggestion if we want to add automation for this process (as we all prefer automation when possible), and it'll probably help a bit to clean our gerrit dash board

> --
> Thanks and best regards!
> 
> Zhou Zheng Sheng / ???
> E-mail: zhshzhou at linux.vnet.ibm.com
> Telephone: 86-10-82454397
> 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>


From iheim at redhat.com  Sun Sep 29 11:55:33 2013
From: iheim at redhat.com (Itamar Heim)
Date: Sun, 29 Sep 2013 14:55:33 +0300
Subject: [Engine-devel] Cluster default with empty processor name with
 PPC64 support
In-Reply-To: <50EB20226B72D6419356FC320AB62B8719173649@SERV070.corp.eldorado.org.br>
References: <50EB20226B72D6419356FC320AB62B8719173370@SERV070.corp.eldorado.org.br>
	<5222F5B7.5060603@redhat.com>
	<50EB20226B72D6419356FC320AB62B87191733F5@SERV070.corp.eldorado.org.br>
	<522715D2.8080103@redhat.com>
	<50EB20226B72D6419356FC320AB62B8719173649@SERV070.corp.eldorado.org.br>
Message-ID: <52481535.1040004@redhat.com>

On 09/04/2013 03:50 PM, Leonardo Bianconi wrote:
>
>
>> -----Original Message-----
>> From: Roy Golan [mailto:rgolan at redhat.com]
>> Sent: quarta-feira, 4 de setembro de 2013 08:13
>> To: Leonardo Bianconi
>> Cc: engine-devel at ovirt.org
>> Subject: Re: [Engine-devel] Cluster default with empty processor name with PPC64 support
>>
>> On 09/02/2013 03:35 PM, Leonardo Bianconi wrote:
>>>
>>>>> From: Roy Golan [mailto:rgolan at redhat.com]
>>>>> Sent: domingo, 1 de setembro de 2013 05:07
>>>>> To: Leonardo Bianconi
>>>>> Cc: engine-devel at ovirt.org
>>>>> Subject: Re: [Engine-devel] Cluster default with empty processor
>>>>> name with PPC64 support
>>>>>
>>>>> On 08/30/2013 10:51 PM, Leonardo Bianconi wrote:
>>>>> Hi everyone!
>>>>>
>>>>> During the development of PPC64 support in the engine, we faced some UX issues regarding the default Cluster (that Cluster with
>> empty processor name).
>>>>>
>>>>> Currently, oVirt engine allows the default Cluster to contain empty processor name, and the administrator can add VMs and/or
>> Templates to it. The processor name can be assigned later, editing the cluster or assigning a valid host to it.
>>>>>
>>>>> During the implementation of PPC64 support on the engine, the field "architecture" was added to Clusters, VMs and Templates
>> entities.
>>>>>
>>>>> So we have the following questions regarding how the UI should behave:
>>>>>
>>>>> - Shall we keep allowing the administrator to assign VMs and Templates to the Cluster with no processor name or assigned
>> architecture ?
>>>>>                -> If we have an "yes" for the question above:
>>>>>                -- We will have to assign the architecture to the Cluster based on the OS of the first assigned VM, and  the processor name
>> could be defined the same way as currently ... editing the Cluster or assigning a compatible Host to it.
>>>>>                                -- The VM creation popup will have to be able to indicate the architecture of each OS ... some OSes have the same
>> name, and it may get ambiguous since the Cluster architecture is still undefined at that point (before the first VM get already created).
>>>>>
>>>>> Thanks!
>>>>> Regards.
>>>>> Leonardo Bianconi
>>>>>
>>>> To add VMs you anyway need a running host in the cluster which means the cpu name and the architecture would be the host's.
>>>> So we can keep the cluster attributes - "cpu name" and "arch" consistent and allow them to be empty on creation.
>>>>
>>>>
>>> Hi Roy!
>>>
>>> There is a way to add VMs in a cluster with no hosts running. Steps to reproduce:
>>> - Initialize the oVirt engine with a new data base
>>> - Create a new Cluster (I will call it of newCluster) in the Data
>>> Center Default
>>> - Add a host in the newCluster
>>> - Add a Storage
>>> - Create a VM in the Cluster Default
>>> Result: The system allows a VM in a cluster with no Hosts running in it.
>>>
>>> Is it a bug or a system functionality? If it's a functionality, the issue above can happen.
>> Just to clear this one - its a functional thing. its a bit confusing but not too complicated:
>>
>> Storage and all its related actions/entities are related to the Data Center (aka, code-wise storage pool). Its possible to create a VM
>> once the DC is up, without a cluster i.e also provision disks to it and so on.
>>
>> Cluster is know as the "migration domain" wrt VMs. so CPU arch stuff, network config etc, must be homogeneous in order for VMs to
>> migrate between hosts which means we must have a running cluster i.e at least 1 running host in it.
>>
> Roy, thank you for the explanation! It`s clear now
>>
>>>
>>> Thanks!!
>>> Regards.
>>> Leonardo Bianconi


Leonardo - slightly related - is this ppc big endian, small endian? any 
thoughts on current and future plans around endianes?

also, can you help with my, well, ignorance - are ppc7+/ppc8[1] a newer 
cpu level, also not backward compatible, etc.?

Thanks,
    Itamar

[1] https://lists.nongnu.org/archive/html/qemu-ppc/2013-08/msg00154.html
(courtesy of rich jones)


From ukiran770 at yahoo.in  Mon Sep 30 04:45:20 2013
From: ukiran770 at yahoo.in (Udaya Kiran P)
Date: Mon, 30 Sep 2013 12:45:20 +0800 (SGT)
Subject: [Engine-devel] oVirt3.3 - Glance and Neutron Integration
Message-ID: <1380516320.6878.YahooMailNeo@web193006.mail.sg3.yahoo.com>

Hi Everyone,

Does oVirt3.3 version support Glance and Neutron Integration.?

Can anybody give me few inputs on the current status of these integrations?

http://www.ovirt.org/OVirt_3.3_release_announcement
http://www.ovirt.org/Features/Detailed_OSN_Integration

Thank You.

Regards,
Udaya Kiran
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20130930/c4a0d4d2/attachment.html>

From sbonazzo at redhat.com  Mon Sep 30 06:21:01 2013
From: sbonazzo at redhat.com (Sandro Bonazzola)
Date: Mon, 30 Sep 2013 08:21:01 +0200
Subject: [Engine-devel] Request for Fedora 20 VM
Message-ID: <5249184D.9090800@redhat.com>

Hi,
Fedora 20 Alpha has been released and can be downloaded from http://fedoraproject.org/get-prerelease.
I think it's time to start running our tests and build nightly also on Fedora 20 in order to discover
possible compatibility issues.
Can infra provide a Fedora 20 VM for jenkins use?
Thanks,

-- 
Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com


From mkolesni at redhat.com  Mon Sep 30 07:26:29 2013
From: mkolesni at redhat.com (Mike Kolesnik)
Date: Mon, 30 Sep 2013 03:26:29 -0400 (EDT)
Subject: [Engine-devel] oVirt3.3 - Glance and Neutron Integration
In-Reply-To: <1380516320.6878.YahooMailNeo@web193006.mail.sg3.yahoo.com>
References: <1380516320.6878.YahooMailNeo@web193006.mail.sg3.yahoo.com>
Message-ID: <84606350.450401.1380525989686.JavaMail.root@redhat.com>

----- Original Message -----

> Hi Everyone,

Hi Udaya, 

> Does oVirt3.3 version support Glance and Neutron Integration.?

Yes, the version supports these features. 

> Can anybody give me few inputs on the current status of these integrations?

> http://www.ovirt.org/OVirt_3.3_release_announcement
> http://www.ovirt.org/Features/Detailed_OSN_Integration

I can say for Neutron that 1st phase is in - you can create a "Neutron" network in oVirt and attach it and use it in your VMs. 
The supported plugins are Linux Bridge & OVS. 
There was an issue raised on the users list that the port is not persisted across VM boots, which we will iron out ASAP. 

> Thank You.

> Regards,
> Udaya Kiran

> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20130930/5f12ae62/attachment.html>

From ukiran770 at yahoo.in  Mon Sep 30 07:40:47 2013
From: ukiran770 at yahoo.in (Udaya Kiran P)
Date: Mon, 30 Sep 2013 15:40:47 +0800 (SGT)
Subject: [Engine-devel] oVirt3.3 - Glance and Neutron Integration
In-Reply-To: <84606350.450401.1380525989686.JavaMail.root@redhat.com>
References: <1380516320.6878.YahooMailNeo@web193006.mail.sg3.yahoo.com>
	<84606350.450401.1380525989686.JavaMail.root@redhat.com>
Message-ID: <1380526847.70759.YahooMailNeo@web193005.mail.sg3.yahoo.com>



Hi Mike,

Thank You for your inputs and update.


I am trying to integrate oVirt3.3 (stable - http://ovirt.org/releases/stable/rpm/Fedora/$releasever/) with OpenStack.


I am not able to see the web interface?for adding Neutron as an external provider as?specified in the deep dive presentation.


Deep Dive Presentation - http://www.ovirt.org/images/e/e7/Ovirt-neutron-integration-deep-dive-2013.pdf

I have attached the screenshots of my oVirt3.3 setup.

Please correct me if using the wrong repository for oVirt3.3.

Also, where the Neutron Server should be configured? Is it at the openstack end or at the oVirt end?

Thank You.

Regards,

Udaya Kiran



________________________________

Hi Everyone,
Hi Udaya,


>
>Does oVirt3.3 version support Glance and Neutron Integration.?
Yes, the version supports these features.


>
>Can anybody give me few inputs on the current status of these integrations?

>
>http://www.ovirt.org/OVirt_3.3_release_announcement
>
>http://www.ovirt.org/Features/Detailed_OSN_Integration
I can say for Neutron that 1st phase is in - you can create a "Neutron" network in oVirt and attach it and use it in your VMs.
The supported plugins are Linux Bridge & OVS.

There was an issue raised on the users list that the port is not persisted across VM boots, which we will iron out ASAP.


>
>
>
>Thank You.
>
>
>Regards,
>Udaya Kiran
>_______________________________________________
>Engine-devel mailing list
>Engine-devel at ovirt.org
>http://lists.ovirt.org/mailman/listinfo/engine-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20130930/1cfeb784/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: DeepDive.png
Type: image/png
Size: 91288 bytes
Desc: not available
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20130930/1cfeb784/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: myOvirt3.3.png
Type: image/png
Size: 12020 bytes
Desc: not available
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20130930/1cfeb784/attachment-0001.png>

From mkolesni at redhat.com  Mon Sep 30 08:10:10 2013
From: mkolesni at redhat.com (Mike Kolesnik)
Date: Mon, 30 Sep 2013 04:10:10 -0400 (EDT)
Subject: [Engine-devel] oVirt3.3 - Glance and Neutron Integration
In-Reply-To: <1380526847.70759.YahooMailNeo@web193005.mail.sg3.yahoo.com>
References: <1380516320.6878.YahooMailNeo@web193006.mail.sg3.yahoo.com>
	<84606350.450401.1380525989686.JavaMail.root@redhat.com>
	<1380526847.70759.YahooMailNeo@web193005.mail.sg3.yahoo.com>
Message-ID: <928873806.476333.1380528610243.JavaMail.root@redhat.com>

----- Original Message -----

> Hi Mike,

> Thank You for your inputs and update.

> I am trying to integrate oVirt3.3 (stable -
> http://ovirt.org/releases/stable/rpm/Fedora/$releasever/ ) with OpenStack.

> I am not able to see the web interface for adding Neutron as an external
> provider as specified in the deep dive presentation.

> Deep Dive Presentation -
> http://www.ovirt.org/images/e/e7/Ovirt-neutron-integration-deep-dive-2013.pdf

> I have attached the screenshots of my oVirt3.3 setup.

This looks like a very old interface that we had while developing the integration, not the final version (that's what you see in the deep dive). 

> Please correct me if using the wrong repository for oVirt3.3.

Let me install oVirt 3.3 that was published and get back to you on this. 

> Also, where the Neutron Server should be configured? Is it at the openstack
> end or at the oVirt end?

I'm not sure what you mean by this, can you please elaborate? 

> Thank You.

> Regards,
> Udaya Kiran

> > Hi Everyone,
> 

> Hi Udaya,

> > Does oVirt3.3 version support Glance and Neutron Integration.?
> 

> Yes, the version supports these features.

> > Can anybody give me few inputs on the current status of these integrations?
> 

> > http://www.ovirt.org/OVirt_3.3_release_announcement
> 
> > http://www.ovirt.org/Features/Detailed_OSN_Integration
> 

> I can say for Neutron that 1st phase is in - you can create a "Neutron"
> network in oVirt and attach it and use it in your VMs.
> The supported plugins are Linux Bridge & OVS.
> There was an issue raised on the users list that the port is not persisted
> across VM boots, which we will iron out ASAP.

> > Thank You.
> 

> > Regards,
> 
> > Udaya Kiran
> 

> > _______________________________________________
> 
> > Engine-devel mailing list
> 
> > Engine-devel at ovirt.org
> 
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20130930/73cfa059/attachment.html>

From ukiran770 at yahoo.in  Mon Sep 30 09:00:50 2013
From: ukiran770 at yahoo.in (Udaya Kiran P)
Date: Mon, 30 Sep 2013 17:00:50 +0800 (SGT)
Subject: [Engine-devel] oVirt3.3 - Glance and Neutron Integration
In-Reply-To: <928873806.476333.1380528610243.JavaMail.root@redhat.com>
References: <1380516320.6878.YahooMailNeo@web193006.mail.sg3.yahoo.com>
	<84606350.450401.1380525989686.JavaMail.root@redhat.com>
	<1380526847.70759.YahooMailNeo@web193005.mail.sg3.yahoo.com>
	<928873806.476333.1380528610243.JavaMail.root@redhat.com>
Message-ID: <1380531650.82884.YahooMailNeo@web193001.mail.sg3.yahoo.com>



Hi Mike,



Thank You for the quick update on this.

Is there any restriction on installing the Neutron server? Should that be installed in the oVirt Engine machine or on the machines which host the openstack services - Compute, Network, Controller?

Thank You,


Regards,
Udaya Kiran



________________________________


>
>Hi Mike,
>
>
>Thank You for your inputs and update.
>
>
>
>I am trying to integrate oVirt3.3 (stable - http://ovirt.org/releases/stable/rpm/Fedora/$releasever/) with OpenStack.
>
>
>
>I am not able to see the web interface?for adding Neutron as an external provider as?specified in the deep dive presentation.
>
>
>
>Deep Dive Presentation - http://www.ovirt.org/images/e/e7/Ovirt-neutron-integration-deep-dive-2013.pdf
>
>
>I have attached the screenshots of my oVirt3.3 setup.
This looks like a very old interface that we had while developing the integration, not the final version (that's what you see in the deep dive).


>
>Please correct me if using the wrong repository for oVirt3.3.
Let me install oVirt 3.3 that was published and get back to you on this.


>
>Also, where the Neutron Server should be configured? Is it at the openstack end or at the oVirt end?
I'm not sure what you mean by this, can you please elaborate?


>
>Thank You.
>
>
>Regards,
>
>Udaya Kiran
>
>
>
>________________________________
>
>Hi Everyone,
>Hi Udaya,
>
>
>>
>>Does oVirt3.3 version support Glance and Neutron Integration.?
>Yes, the version supports these features.
>
>
>>
>>Can anybody give me few inputs on the current status of these integrations?
>
>>
>>http://www.ovirt.org/OVirt_3.3_release_announcement
>>
>>http://www.ovirt.org/Features/Detailed_OSN_Integration
>>
>I can say for Neutron that 1st phase is in - you can create a "Neutron" network in oVirt and attach it and use it in your VMs.
>The supported plugins are Linux Bridge & OVS.
>
>There was an issue raised on the users list that the port is not persisted across VM boots, which we will iron out ASAP.
>
>
>>
>>
>>
>>Thank You.
>>
>>
>>Regards,
>>Udaya Kiran
>>_______________________________________________
>>Engine-devel mailing list
>>Engine-devel at ovirt.org
>>http://lists.ovirt.org/mailman/listinfo/engine-devel
>>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20130930/df4e7bee/attachment.html>

From mkolesni at redhat.com  Mon Sep 30 09:22:02 2013
From: mkolesni at redhat.com (Mike Kolesnik)
Date: Mon, 30 Sep 2013 05:22:02 -0400 (EDT)
Subject: [Engine-devel] oVirt3.3 - Glance and Neutron Integration
In-Reply-To: <1380531650.82884.YahooMailNeo@web193001.mail.sg3.yahoo.com>
References: <1380516320.6878.YahooMailNeo@web193006.mail.sg3.yahoo.com>
	<84606350.450401.1380525989686.JavaMail.root@redhat.com>
	<1380526847.70759.YahooMailNeo@web193005.mail.sg3.yahoo.com>
	<928873806.476333.1380528610243.JavaMail.root@redhat.com>
	<1380531650.82884.YahooMailNeo@web193001.mail.sg3.yahoo.com>
Message-ID: <1351976724.508728.1380532922861.JavaMail.root@redhat.com>

----- Original Message -----

> Hi Mike,

Hi Udaya, 

> Thank You for the quick update on this.

Happy to help, responses inline. 

> Is there any restriction on installing the Neutron server? Should that be
> installed in the oVirt Engine machine or on the machines which host the
> openstack services - Compute, Network, Controller?

The neutron server itself can be installed on the same machine as engine, just make sure not to install horizon there so it won't mess up your oVirt web admin (haven't tried, but I guess they might not play well together).. 

> Thank You,

> Regards,
> Udaya Kiran

> > Hi Mike,
> 

> > Thank You for your inputs and update.
> 

> > I am trying to integrate oVirt3.3 (stable -
> > http://ovirt.org/releases/stable/rpm/Fedora/$releasever/ ) with OpenStack.
> 

> > I am not able to see the web interface for adding Neutron as an external
> > provider as specified in the deep dive presentation.
> 

> > Deep Dive Presentation -
> > http://www.ovirt.org/images/e/e7/Ovirt-neutron-integration-deep-dive-2013.pdf
> 

> > I have attached the screenshots of my oVirt3.3 setup.
> 

> This looks like a very old interface that we had while developing the
> integration, not the final version (that's what you see in the deep dive).

Well, I just installed ovirt from 3.3 and I see the new interface as you posted in the screenshot from the deep dive. 

Can you please make sure this is what is installed? 

[root at localhost ~]# yum provides ovirt-engine 
Loaded plugins: langpacks, refresh-packagekit, versionlock 
ovirt-engine-3.3.0-4.fc19.noarch : Management server for Open Virtualization 
Repo : ovirt-stable 

> > Please correct me if using the wrong repository for oVirt3.3.
> 

> Let me install oVirt 3.3 that was published and get back to you on this.

> > Also, where the Neutron Server should be configured? Is it at the openstack
> > end or at the oVirt end?
> 

> I'm not sure what you mean by this, can you please elaborate?

> > Thank You.
> 

> > Regards,
> 
> > Udaya Kiran
> 

> > > Hi Everyone,
> > 
> 

> > Hi Udaya,
> 

> > > Does oVirt3.3 version support Glance and Neutron Integration.?
> > 
> 

> > Yes, the version supports these features.
> 

> > > Can anybody give me few inputs on the current status of these
> > > integrations?
> > 
> 

> > > http://www.ovirt.org/OVirt_3.3_release_announcement
> > 
> 
> > > http://www.ovirt.org/Features/Detailed_OSN_Integration
> > 
> 

> > I can say for Neutron that 1st phase is in - you can create a "Neutron"
> > network in oVirt and attach it and use it in your VMs.
> 
> > The supported plugins are Linux Bridge & OVS.
> 
> > There was an issue raised on the users list that the port is not persisted
> > across VM boots, which we will iron out ASAP.
> 

> > > Thank You.
> > 
> 

> > > Regards,
> > 
> 
> > > Udaya Kiran
> > 
> 

> > > _______________________________________________
> > 
> 
> > > Engine-devel mailing list
> > 
> 
> > > Engine-devel at ovirt.org
> > 
> 
> > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20130930/72405a57/attachment.html>

From ukiran770 at yahoo.in  Mon Sep 30 09:57:10 2013
From: ukiran770 at yahoo.in (Udaya Kiran P)
Date: Mon, 30 Sep 2013 17:57:10 +0800 (SGT)
Subject: [Engine-devel] oVirt3.3 - Glance and Neutron Integration
In-Reply-To: <1351976724.508728.1380532922861.JavaMail.root@redhat.com>
References: <1380516320.6878.YahooMailNeo@web193006.mail.sg3.yahoo.com>
	<84606350.450401.1380525989686.JavaMail.root@redhat.com>
	<1380526847.70759.YahooMailNeo@web193005.mail.sg3.yahoo.com>
	<928873806.476333.1380528610243.JavaMail.root@redhat.com>
	<1380531650.82884.YahooMailNeo@web193001.mail.sg3.yahoo.com>
	<1351976724.508728.1380532922861.JavaMail.root@redhat.com>
Message-ID: <1380535030.90781.YahooMailNeo@web193005.mail.sg3.yahoo.com>

Hi Mike,

Sounds good.

I am eager to know if the Integration is complete for Glance and Cinder in oVirt3.3?

Thank You.

Regards,
Udaya Kiran



________________________________


>
>Hi Mike,
Hi Udaya,


>
>
>
>Thank You for the quick update on this.
Happy to help, responses inline.


>
>Is there any restriction on installing the Neutron server? Should that be installed in the oVirt Engine machine or on the machines which host the openstack services - Compute, Network, Controller?
The neutron server itself can be installed on the same machine as engine, just make sure not to install horizon there so it won't mess up your oVirt web admin (haven't tried, but I guess they might not play well together)..


>
>Thank You,
>
>
>
>Regards,
>Udaya Kiran
>
>
>
>
>________________________________
>
>
>>
>>Hi Mike,
>>
>>
>>Thank You for your inputs and update.
>>
>>
>>
>>I am trying to integrate oVirt3.3 (stable - http://ovirt.org/releases/stable/rpm/Fedora/$releasever/) with OpenStack.
>>
>>
>>
>>I am not able to see the web interface?for adding Neutron as an external provider as?specified in the deep dive presentation.
>>
>>
>>
>>Deep Dive Presentation - http://www.ovirt.org/images/e/e7/Ovirt-neutron-integration-deep-dive-2013.pdf
>>
>>
>>I have attached the screenshots of my oVirt3.3 setup.
>This looks like a very old interface that we had while developing the integration, not the final version (that's what you see in the deep dive).
Well, I just installed ovirt from 3.3 and I see the new interface as you posted in the screenshot from the deep dive.


Can you please make sure this is what is installed?


[root at localhost ~]# yum provides ovirt-engine
Loaded plugins: langpacks, refresh-packagekit, versionlock
ovirt-engine-3.3.0-4.fc19.noarch : Management server for Open Virtualization
Repo??????? : ovirt-stable



>
>
>>
>>Please correct me if using the wrong repository for oVirt3.3.
>Let me install oVirt 3.3 that was published and get back to you on this.
>
>
>>
>>Also, where the Neutron Server should be configured? Is it at the openstack end or at the oVirt end?
>I'm not sure what you mean by this, can you please elaborate?
>
>
>>
>>Thank You.
>>
>>
>>Regards,
>>
>>Udaya Kiran
>>
>>
>>
>>________________________________
>>
>>Hi Everyone,
>>Hi Udaya,
>>
>>
>>>
>>>Does oVirt3.3 version support Glance and Neutron Integration.?
>>Yes, the version supports these features.
>>
>>
>>>
>>>Can anybody give me few inputs on the current status of these integrations?
>>
>>>
>>>http://www.ovirt.org/OVirt_3.3_release_announcement
>>>
>>>http://www.ovirt.org/Features/Detailed_OSN_Integration
>>>
>>I can say for Neutron that 1st phase is in - you can create a "Neutron" network in oVirt and attach it and use it in your VMs.
>>The supported plugins are Linux Bridge & OVS.
>>
>>There was an issue raised on the users list that the port is not persisted across VM boots, which we will iron out ASAP.
>>
>>
>>>
>>>
>>>
>>>Thank You.
>>>
>>>
>>>Regards,
>>>Udaya Kiran
>>>_______________________________________________
>>>Engine-devel mailing list
>>>Engine-devel at ovirt.org
>>>http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>
>>
>>
>>
>>
>>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20130930/326c06dc/attachment.html>

From michal.skrivanek at redhat.com  Mon Sep 30 10:13:18 2013
From: michal.skrivanek at redhat.com (Michal Skrivanek)
Date: Mon, 30 Sep 2013 12:13:18 +0200
Subject: [Engine-devel] unit tests by default enabled
Message-ID: <91A738D0-2A98-4912-8BEA-C1211316CC0A@redhat.com>

Hi,
since there were quite a few recent breakages of master branch compilation the patch [1] has been proposed (and merged) to run the unit tests during default compilation
Hope it will make oVirt a bit more stable...

Thanks,
michal

[1] http://gerrit.ovirt.org/#/c/19513/

From ukiran770 at yahoo.in  Mon Sep 30 10:13:51 2013
From: ukiran770 at yahoo.in (Udaya Kiran P)
Date: Mon, 30 Sep 2013 18:13:51 +0800 (SGT)
Subject: [Engine-devel] oVirt3.3 - Glance and Neutron Integration
In-Reply-To: <1380535030.90781.YahooMailNeo@web193005.mail.sg3.yahoo.com>
References: <1380516320.6878.YahooMailNeo@web193006.mail.sg3.yahoo.com>
	<84606350.450401.1380525989686.JavaMail.root@redhat.com>
	<1380526847.70759.YahooMailNeo@web193005.mail.sg3.yahoo.com>
	<928873806.476333.1380528610243.JavaMail.root@redhat.com>
	<1380531650.82884.YahooMailNeo@web193001.mail.sg3.yahoo.com>
	<1351976724.508728.1380532922861.JavaMail.root@redhat.com>
	<1380535030.90781.YahooMailNeo@web193005.mail.sg3.yahoo.com>
Message-ID: <1380536031.90927.YahooMailNeo@web193006.mail.sg3.yahoo.com>



Hi Mike,

Please find attached the screenshots for,

1. yum provides ovirt-engine

2. /etc/yum.repos.d/ovirt.repo

Please correct me if some settings has to be changed.

Thank You.

Regards,
Udaya Kiran



________________________________
 


Hi Mike,

Sounds good.

I am eager to know if the Integration is complete for Glance and Cinder in oVirt3.3?

Thank You.

Regards,
Udaya Kiran



________________________________


>
>Hi Mike,
Hi Udaya,


>
>
>
>Thank You for the quick update on this.
Happy to help, responses inline.


>
>Is there any restriction on installing the Neutron server? Should that be installed in the oVirt Engine machine or on the machines which host the openstack services - Compute, Network, Controller?
The neutron server itself can be installed on the same machine as engine, just make sure not to install horizon there so it won't mess up your oVirt web admin (haven't tried, but I guess they might not play well together)..


>
>Thank You,
>
>
>
>Regards,
>Udaya Kiran
>
>
>
>
>________________________________
>
>
>>
>>Hi Mike,
>>
>>
>>Thank You for your inputs and update.
>>
>>
>>
>>I am trying to integrate oVirt3.3 (stable - http://ovirt.org/releases/stable/rpm/Fedora/$releasever/) with OpenStack.
>>
>>
>>
>>I am not able to see the web interface?for adding Neutron as an external provider as?specified in the deep dive presentation.
>>
>>
>>
>>Deep Dive Presentation - http://www.ovirt.org/images/e/e7/Ovirt-neutron-integration-deep-dive-2013.pdf
>>
>>
>>I have attached the screenshots of my oVirt3.3 setup.
>This looks like a very old interface that we had while developing the integration, not the final version (that's what you see in the deep dive).
Well, I just installed ovirt from 3.3 and I see the new interface as you posted in the screenshot from the deep dive.


Can you please make sure this is what is installed?


[root at localhost ~]# yum provides ovirt-engine
Loaded plugins: langpacks, refresh-packagekit, versionlock
ovirt-engine-3.3.0-4.fc19.noarch : Management server for Open Virtualization
Repo??????? : ovirt-stable



>
>
>>
>>Please correct me if using the wrong repository for oVirt3.3.
>Let me install oVirt 3.3 that was published and get back to you on this.
>
>
>>
>>Also, where the Neutron Server should be configured? Is it at the openstack end or at the oVirt end?
>I'm not sure what you mean by this, can you please elaborate?
>
>
>>
>>Thank You.
>>
>>
>>Regards,
>>
>>Udaya Kiran
>>
>>
>>
>>________________________________
>>
>>Hi Everyone,
>>Hi Udaya,
>>
>>
>>>
>>>Does oVirt3.3 version support Glance and Neutron Integration.?
>>Yes, the version supports these features.
>>
>>
>>>
>>>Can anybody give me few inputs on the current status of these integrations?
>>
>>>
>>>http://www.ovirt.org/OVirt_3.3_release_announcement
>>>
>>>http://www.ovirt.org/Features/Detailed_OSN_Integration
>>>
>>I can say for Neutron that 1st phase is in - you can create a "Neutron" network in oVirt and attach it and use it in your VMs.
>>The supported plugins are Linux Bridge & OVS.
>>
>>There was an issue raised on the users list that the port is not persisted across VM boots, which we will iron out ASAP.
>>
>>
>>>
>>>
>>>
>>>Thank You.
>>>
>>>
>>>Regards,
>>>Udaya Kiran
>>>_______________________________________________
>>>Engine-devel mailing list
>>>Engine-devel at ovirt.org
>>>http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>
>>
>>
>>
>>
>>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20130930/0bf5d745/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: oVirtRepo.png
Type: image/png
Size: 23868 bytes
Desc: not available
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20130930/0bf5d745/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: yum_provides.png
Type: image/png
Size: 14318 bytes
Desc: not available
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20130930/0bf5d745/attachment-0001.png>

From mkolesni at redhat.com  Mon Sep 30 11:03:20 2013
From: mkolesni at redhat.com (Mike Kolesnik)
Date: Mon, 30 Sep 2013 07:03:20 -0400 (EDT)
Subject: [Engine-devel] oVirt3.3 - Glance and Neutron Integration
In-Reply-To: <1380536031.90927.YahooMailNeo@web193006.mail.sg3.yahoo.com>
References: <1380516320.6878.YahooMailNeo@web193006.mail.sg3.yahoo.com>
	<84606350.450401.1380525989686.JavaMail.root@redhat.com>
	<1380526847.70759.YahooMailNeo@web193005.mail.sg3.yahoo.com>
	<928873806.476333.1380528610243.JavaMail.root@redhat.com>
	<1380531650.82884.YahooMailNeo@web193001.mail.sg3.yahoo.com>
	<1351976724.508728.1380532922861.JavaMail.root@redhat.com>
	<1380535030.90781.YahooMailNeo@web193005.mail.sg3.yahoo.com>
	<1380536031.90927.YahooMailNeo@web193006.mail.sg3.yahoo.com>
Message-ID: <415428792.558668.1380539000330.JavaMail.root@redhat.com>

----- Original Message -----

> Hi Mike,

Hi Udaya, 

> Please find attached the screenshots for,

> 1. yum provides ovirt-engine
> 2. /etc/yum.repos.d/ovirt.repo

> Please correct me if some settings has to be changed.

As you can see the package you have installed is from ovirt-nightly repo. 
The timestamp indicates it's rather old - 20130624021657 means it's from 02:16:57 24/06/2013 
This is a development version which didn't have those features fully availabe yet. 

Also you can see the package is for f18 - Fedora 18. 
>From the download page ( http://www.ovirt.org/Download ) you can see that Fedora 19 is required. 
I'm rather sure that Fedora 18 is not supported for 3.3, 
so my best suggestion would be to either upgrade the machine or try on a new machine. 
If you upgrade, I'd advise backing up first as fedora upgrade sometimes results (at least for me) in a non-booting disk. 

Regards, 
Mike 

> Thank You.

> Regards,
> Udaya Kiran

> Hi Mike,

> Sounds good.

> I am eager to know if the Integration is complete for Glance and Cinder in
> oVirt3.3?

> Thank You.

> Regards,
> Udaya Kiran

> > Hi Mike,
> 

> Hi Udaya,

> > Thank You for the quick update on this.
> 

> Happy to help, responses inline.

> > Is there any restriction on installing the Neutron server? Should that be
> > installed in the oVirt Engine machine or on the machines which host the
> > openstack services - Compute, Network, Controller?
> 

> The neutron server itself can be installed on the same machine as engine,
> just make sure not to install horizon there so it won't mess up your oVirt
> web admin (haven't tried, but I guess they might not play well together)..

> > Thank You,
> 

> > Regards,
> 
> > Udaya Kiran
> 

> > > Hi Mike,
> > 
> 

> > > Thank You for your inputs and update.
> > 
> 

> > > I am trying to integrate oVirt3.3 (stable -
> > > http://ovirt.org/releases/stable/rpm/Fedora/$releasever/ ) with
> > > OpenStack.
> > 
> 

> > > I am not able to see the web interface for adding Neutron as an external
> > > provider as specified in the deep dive presentation.
> > 
> 

> > > Deep Dive Presentation -
> > > http://www.ovirt.org/images/e/e7/Ovirt-neutron-integration-deep-dive-2013.pdf
> > 
> 

> > > I have attached the screenshots of my oVirt3.3 setup.
> > 
> 

> > This looks like a very old interface that we had while developing the
> > integration, not the final version (that's what you see in the deep dive).
> 

> Well, I just installed ovirt from 3.3 and I see the new interface as you
> posted in the screenshot from the deep dive.

> Can you please make sure this is what is installed?

> [root at localhost ~]# yum provides ovirt-engine
> Loaded plugins: langpacks, refresh-packagekit, versionlock
> ovirt-engine-3.3.0-4.fc19.noarch : Management server for Open Virtualization
> Repo : ovirt-stable

> > > Please correct me if using the wrong repository for oVirt3.3.
> > 
> 

> > Let me install oVirt 3.3 that was published and get back to you on this.
> 

> > > Also, where the Neutron Server should be configured? Is it at the
> > > openstack
> > > end or at the oVirt end?
> > 
> 

> > I'm not sure what you mean by this, can you please elaborate?
> 

> > > Thank You.
> > 
> 

> > > Regards,
> > 
> 
> > > Udaya Kiran
> > 
> 

> > > > Hi Everyone,
> > > 
> > 
> 

> > > Hi Udaya,
> > 
> 

> > > > Does oVirt3.3 version support Glance and Neutron Integration.?
> > > 
> > 
> 

> > > Yes, the version supports these features.
> > 
> 

> > > > Can anybody give me few inputs on the current status of these
> > > > integrations?
> > > 
> > 
> 

> > > > http://www.ovirt.org/OVirt_3.3_release_announcement
> > > 
> > 
> 
> > > > http://www.ovirt.org/Features/Detailed_OSN_Integration
> > > 
> > 
> 

> > > I can say for Neutron that 1st phase is in - you can create a "Neutron"
> > > network in oVirt and attach it and use it in your VMs.
> > 
> 
> > > The supported plugins are Linux Bridge & OVS.
> > 
> 
> > > There was an issue raised on the users list that the port is not
> > > persisted
> > > across VM boots, which we will iron out ASAP.
> > 
> 

> > > > Thank You.
> > > 
> > 
> 

> > > > Regards,
> > > 
> > 
> 
> > > > Udaya Kiran
> > > 
> > 
> 

> > > > _______________________________________________
> > > 
> > 
> 
> > > > Engine-devel mailing list
> > > 
> > 
> 
> > > > Engine-devel at ovirt.org
> > > 
> > 
> 
> > > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > 
> > 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20130930/bafefaac/attachment.html>

From iheim at redhat.com  Mon Sep 30 12:21:38 2013
From: iheim at redhat.com (Itamar Heim)
Date: Mon, 30 Sep 2013 15:21:38 +0300
Subject: [Engine-devel] oVirt3.3 - Glance and Neutron Integration
In-Reply-To: <1380535030.90781.YahooMailNeo@web193005.mail.sg3.yahoo.com>
References: <1380516320.6878.YahooMailNeo@web193006.mail.sg3.yahoo.com>
	<84606350.450401.1380525989686.JavaMail.root@redhat.com>
	<1380526847.70759.YahooMailNeo@web193005.mail.sg3.yahoo.com>
	<928873806.476333.1380528610243.JavaMail.root@redhat.com>
	<1380531650.82884.YahooMailNeo@web193001.mail.sg3.yahoo.com>
	<1351976724.508728.1380532922861.JavaMail.root@redhat.com>
	<1380535030.90781.YahooMailNeo@web193005.mail.sg3.yahoo.com>
Message-ID: <52496CD2.5080906@redhat.com>

On 09/30/2013 12:57 PM, Udaya Kiran P wrote:
> Hi Mike,
>
> Sounds good.
>
> I am eager to know if the Integration is complete for Glance and Cinder
> in oVirt3.3?

glance is also in, cinder is not.
federico can provide more info if you have issues with glance, but first 
please install the GA'd version of ovirt

>
> Thank You.
>
> Regards,
> Udaya Kiran
>
> ------------------------------------------------------------------------
>
>
>     Hi Mike,
>
> Hi Udaya,
>
>
>
>     Thank You for the quick update on this.
>
> Happy to help, responses inline.
>
>
>     Is there any restriction on installing the Neutron server? Should
>     that be installed in the oVirt Engine machine or on the machines
>     which host the openstack services - Compute, Network, Controller?
>
> The neutron server itself can be installed on the same machine as
> engine, just make sure not to install horizon there so it won't mess up
> your oVirt web admin (haven't tried, but I guess they might not play
> well together)..
>
>
>     Thank You,
>
>     Regards,
>     Udaya Kiran
>
>
>     ------------------------------------------------------------------------
>
>
>         Hi Mike,
>
>         Thank You for your inputs and update.
>
>         I am trying to integrate oVirt3.3 (stable -
>         http://ovirt.org/releases/stable/rpm/Fedora/$releasever/) with
>         OpenStack.
>
>         I am not able to see the web interface for adding Neutron as an
>         external provider as specified in the deep dive presentation.
>
>         Deep Dive Presentation -
>         http://www.ovirt.org/images/e/e7/Ovirt-neutron-integration-deep-dive-2013.pdf
>
>         I have attached the screenshots of my oVirt3.3 setup.
>
>     This looks like a very old interface that we had while developing
>     the integration, not the final version (that's what you see in the
>     deep dive).
>
> Well, I just installed ovirt from 3.3 and I see the new interface as you
> posted in the screenshot from the deep dive.
>
> Can you please make sure this is what is installed?
>
> [root at localhost ~]# yum provides ovirt-engine
> Loaded plugins: langpacks, refresh-packagekit, versionlock
> ovirt-engine-3.3.0-4.fc19.noarch : Management server for Open Virtualization
> Repo        : ovirt-stable
>
>
>
>         Please correct me if using the wrong repository for oVirt3.3.
>
>     Let me install oVirt 3.3 that was published and get back to you on this.
>
>
>         Also, where the Neutron Server should be configured? Is it at
>         the openstack end or at the oVirt end?
>
>     I'm not sure what you mean by this, can you please elaborate?
>
>
>         Thank You.
>
>         Regards,
>         Udaya Kiran
>
>         ------------------------------------------------------------------------
>
>             Hi Everyone,
>
>         Hi Udaya,
>
>
>             Does oVirt3.3 version support Glance and Neutron Integration.?
>
>         Yes, the version supports these features.
>
>
>             Can anybody give me few inputs on the current status of
>             these integrations?
>
>
>             http://www.ovirt.org/OVirt_3.3_release_announcement
>             http://www.ovirt.org/Features/Detailed_OSN_Integration
>
>         I can say for Neutron that 1st phase is in - you can create a
>         "Neutron" network in oVirt and attach it and use it in your VMs.
>         The supported plugins are Linux Bridge & OVS.
>         There was an issue raised on the users list that the port is not
>         persisted across VM boots, which we will iron out ASAP.
>
>
>
>             Thank You.
>
>             Regards,
>             Udaya Kiran
>
>             _______________________________________________
>             Engine-devel mailing list
>             Engine-devel at ovirt.org
>             http://lists.ovirt.org/mailman/listinfo/engine-devel
>
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>



From fabiand at redhat.com  Mon Sep 30 12:52:12 2013
From: fabiand at redhat.com (Fabian Deutsch)
Date: Mon, 30 Sep 2013 14:52:12 +0200
Subject: [Engine-devel] Request for Fedora 20 VM
In-Reply-To: <5249184D.9090800@redhat.com>
References: <5249184D.9090800@redhat.com>
Message-ID: <1380545532.2666.13.camel@fdeutsch-laptop.local>

Am Montag, den 30.09.2013, 08:21 +0200 schrieb Sandro Bonazzola:
> Hi,
> Fedora 20 Alpha has been released and can be downloaded from http://fedoraproject.org/get-prerelease.
> I think it's time to start running our tests and build nightly also on Fedora 20 in order to discover
> possible compatibility issues.
> Can infra provide a Fedora 20 VM for jenkins use?

That would also be helpful for us - ovirt-node - to get started with the
F20 migration.

Greetings
fabian



From jenkins at ovirt.org  Mon Sep 30 23:06:07 2013
From: jenkins at ovirt.org (Jenkins ci oVirt Server)
Date: Tue, 1 Oct 2013 00:06:07 +0100 (BST)
Subject: [Engine-devel] [oVirt jenkins] Weekly report on open tasks for
	ovirt-engine
Message-ID: <1783143245.799.1380582375231.JavaMail.jenkins@jenkins.ovirt.org>

An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20131001/f6a6c644/attachment.html>